lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 29 Mar 2015 11:02:18 +0300 From: Boaz Harrosh <boaz@...xistor.com> To: Dave Chinner <david@...morbit.com>, Matthew Wilcox <willy@...ux.intel.com> CC: Matthew Wilcox <matthew.r.wilcox@...el.com>, linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org, msharbiani@...pensource.com Subject: Re: Should implementations of ->direct_access be allowed to sleep? On 03/26/2015 09:32 PM, Dave Chinner wrote: <> >> I'm leaning towards the latter. But I'm not sure what GFP flags to >> recommend that brd use ... GFP_NOWAIT | __GFP_ZERO, perhaps? > > What, so we get random IO failures under memory pressure? > > I really think we should allow .direct_access to sleep. It means we > can use existing drivers and it also allows future implementations > that might require, say, RDMA to be performed to update a page > before access is granted. i.e. .direct_access is the first hook into > the persistent device at page fault time.... > I agree with Dave. Last I tried (couple years ago) doing any allocation GFP_NOWAIT on FS IO paths fails really badly in all kind of surprising ways. The Kernel is built in to that allocation pressure. I think that ->direct_access should not be any different then any other block-device access, ie allow to sleep. With brd a user can make sure not to sleep if he pre-allocates ie call ->direct_access at least once on a given offset-length. But I would not like to even do that guaranty. ->direct_access should be allowed to sleep. Well written code has many ways to allow sleep yet be very low latency. (So I do not see what we are missing) > Cheers, > Dave. Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists