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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 7 Oct 2017 14:56:40 +0300
From:   Vladimir Davydov <vdavydov.dev@...il.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Jia-Ju Bai <baijiaju1990@....com>, viro@...iv.linux.org.uk,
        torbjorn.lindh@...ta.se, rgooch@...f.csiro.au,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG] fs/super: a possible sleep-in-atomic bug in put_super

Hello,

On Fri, Oct 06, 2017 at 11:06:04AM +0200, Michal Hocko wrote:
> On Fri 06-10-17 16:59:18, Jia-Ju Bai wrote:
> > According to fs/super.c, the kernel may sleep under a spinlock.
> > The function call path is:
> > put_super (acquire the spinlock)
> >   __put_super
> >     destroy_super
> >       list_lru_destroy
> >         list_lru_unregister
> >           mutex_lock --> may sleep
> >         memcg_get_cache_ids
> >           down_read --> may sleep
> > 
> > This bug is found by my static analysis tool and my code review.

This is false-positive: by the time we get to destroy_super(), the lru
lists have already been destroyed - see deactivate_locked_super() - so
list_lru_destroy() will retrun right away without attempting to take any
locks. That's why there's no lockdep warnings regarding this issue.

I think we can move list_lru_destroy() to destroy_super_work() to
suppress this warning. Not sure if it's really worth the trouble though.

Thanks,
Vladimir

Powered by blists - more mailing lists