Joel Fernandes wrote: > On Tue, Feb 05, 2019 at 07:28:41PM +0900, Tetsuo Handa wrote: > > ashmem_pin() is calling range_shrink() without checking whether > > range_alloc() succeeded. Since memory allocation fault injection might > > force range_alloc() to fail while range_alloc() is called for only once > > for one ioctl() request, make range_alloc() not to fail. > > Why does this not need to fail? I am worried your change will introduce > unwanted endless looping in the kernel instead of gracefully failing a > pin/unpin request. This patch won't introduce endless looping in the kernel, due to a rule called The "too small to fail" memory-allocation rule https://lwn.net/Articles/627419/ . In short, memory allocation by range_alloc() might fail only if current thread was killed by the OOM killer or memory allocation fault injection mechanism forced it to fail. And this patch helps doing fuzzing test with minimal changes. > > Unless there is a good reason, I suggest to drop this patch from the series; > but let us discuss more if you want. We can allocate memory for range_alloc() before holding ashmem_mutex at ashmem_pin_unpin() if you don't want to use __GFP_NOFAIL. It is better to avoid memory allocation with ashmem_mutex because ashmem_mutex is held by shrinker function. But given that this module is going to be replaced shortly, does it worth moving the memory allocation to the caller? > > thanks, > > - Joel > > From the docs: > __GFP_NOFAIL - Indicate that this allocation is in no way allowed to fail (think twice before using). > The "too small to fail" memory-allocation rule already made almost __GFP_NOFAIL. :-) _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
