Re: possible deadlock in __do_page_fault

[Tetsuo Handa]

On 2019/01/29 1:45, Joel Fernandes wrote:
>>  		freed += range_size(range);
>> +		mutex_unlock(&ashmem_mutex);
>> +		f->f_op->fallocate(f,
>> +				   FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE,
>> +				   start, end - start);
>> +		fput(f);
>> +		if (atomic_dec_and_test(&ashmem_shrink_inflight))
>> +			wake_up_all(&ashmem_shrink_wait);
>> +		mutex_lock(&ashmem_mutex);
> 
> Let us replace mutex_lock with mutex_trylock, as done before the loop? Here
> is there is an opportunity to not block other ashmem operations. Otherwise
> LGTM. Also, CC stable.

If shrinker succeeded to grab ashmem_mutex using mutex_trylock(), it is
guaranteed that that thread is not inside

  mutex_lock(&ashmem_mutex);
  kmalloc(GFP_KERNEL);
  mutex_unlock(&ashmem_mutex);

block. Therefore, I think that it is safe to use mutex_lock() here.

Nonetheless, although syzbot did not find other dependency, I can update this
patch to use mutex_trylock() if you worry about not-yet-discovered dependency.