On Mon, Jul 29, 2019 at 11:28:30AM +0200, Michal Hocko wrote: > On Fri 26-07-19 14:01:37, Matthew Wilcox wrote: > > From: "Matthew Wilcox (Oracle)" <willy@xxxxxxxxxxxxx> > > > > Since vfree() can sleep, calling kvfree() from contexts where sleeping > > is not permitted (eg holding a spinlock) is a bit of a lottery whether > > it'll work. Introduce kvfree_safe() for situations where we know we can > > sleep, but make kvfree() safe by default. > > So now you have converted all kvfree callers to an atomic version. Is > that really desirable? Aren't we adding way too much work to be done in > a deferred context? If not then why a regular vfree cannot do this > already and then we do not need vfree_atomic and kvfree_safe. I know infiniband has kvfree calls under user control, mayne uses of kvfree are related to allocating kernel memory for some potentially large user data on the syscall path.. I'm also nervous about making them all queuing. If we added kvfree_atomic() & a warning how many places would hit the warning and need conversion? Jason