On Tue, 23 May 2017, Michal Hocko wrote: > On Mon 22-05-17 13:35:41, David Rientjes wrote: > > On Mon, 22 May 2017, Mike Snitzer wrote: > [...] > > > While adding the __GFP_NOFAIL flag would serve to document expectations > > > I'm left unconvinced that the memory allocator will _not fail_ for an > > > order-0 page -- as Mikulas said most ioctls don't need more than 4K. > > > > __GFP_NOFAIL would make no sense in kvmalloc() calls, ever, it would never > > fallback to vmalloc :) > > Sorry, I could have been more specific. You would have to opencode > kvmalloc obviously. It is documented to not support this flag for the > reasons you have mentioned above. > > > I'm hoping this can get merged during the 4.12 window to fix the broken > > commit d224e9381897. > > I obviously disagree. Relying on memory reserves for _correctness_ is > clearly broken by design, full stop. But it is dm code and you are going > it is responsibility of the respective maintainers to support this code. Block loop device is broken in the same way - it converts block requests to filesystem reads and writes and those FS reads and writes allocate memory. Network block device needs an userspace daemon to perform I/O. iSCSI also needs to allocate memory to perform I/O. NFS and other networking filesystems are also broken in the same way (they need to receive a packet to acknowledge a write and packet reception needs to allocate memory). So - what should these *broken* drivers do to reduce the possibility of the deadlock? Mikulas > -- > Michal Hocko > SUSE Labs > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
