On Tue, Jan 29, 2019 at 05:01:50PM -0800, Andrew Morton wrote:
> On Wed, 30 Jan 2019 09:42:06 +0900 Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:
>
> > > >
> > > > If we want to allow vfree() to sleep, at least we need to test with
> > > > kvmalloc() == vmalloc() (i.e. force kvmalloc()/kvfree() users to use
> > > > vmalloc()/vfree() path). For now, reverting the
> > > > "Context: Either preemptible task context or not-NMI interrupt." change
> > > > will be needed for stable kernels.
> > >
> > > So, the comment for vfree "May sleep if called *not* from interrupt
> > > context." is wrong?
> >
> > Commit bf22e37a641327e3 ("mm: add vfree_atomic()") says
> >
> > We are going to use sleeping lock for freeing vmap. However some
> > vfree() users want to free memory from atomic (but not from interrupt)
> > context. For this we add vfree_atomic() - deferred variation of vfree()
> > which can be used in any atomic context (except NMIs).
> >
> > and commit 52414d3302577bb6 ("kvfree(): fix misleading comment") made
> >
> > - * Context: Any context except NMI.
> > + * Context: Either preemptible task context or not-NMI interrupt.
> >
> > change. But I think that we converted kmalloc() to kvmalloc() without checking
> > context of kvfree() callers. Therefore, I think that kvfree() needs to use
> > vfree_atomic() rather than just saying "vfree() might sleep if called not in
> > interrupt context."...
>
> Whereabouts in the vfree() path can the kernel sleep?
(Sorry for the late reply.)
Adding Andrey Ryabinin, author of commit 52414d3302577bb6
("kvfree(): fix misleading comment"), maybe Andrey remembers
where vfree() can sleep.
In the meantime, does "cond_resched_lock(&vmap_area_lock);" in
__purge_vmap_area_lazy() count as a sleep point?
__purge_vmap_area_lazy() can be called if mutex_trylock on
vmap_purge_lock succeed.
