linux-kernel - Re: [RFC v2 5/5] block: revert back to synchronous request

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 14 Apr 2020 03:38:04 +0000
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Bart Van Assche <bvanassche@....org>
Cc:     Jens Axboe <axboe@...nel.dk>, Al Viro <viro@...iv.linux.org.uk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>, Jan Kara <jack@...e.cz>,
        Ming Lei <ming.lei@...hat.com>,
        Nicolai Stange <nstange@...e.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...e.com>, yu kuai <yukuai3@...wei.com>,
        linux-block@...r.kernel.org,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Omar Sandoval <osandov@...com>,
        Hannes Reinecke <hare@...e.com>,
        Michal Hocko <mhocko@...nel.org>
Subject: Re: [RFC v2 5/5] block: revert back to synchronous request_queue
 removal

On Sat, Apr 11, 2020 at 04:21:17PM -0700, Bart Van Assche wrote:
> On 2020-04-10 14:27, Luis Chamberlain wrote:
> > On Fri, Apr 10, 2020 at 2:50 PM Luis Chamberlain <mcgrof@...nel.org> wrote:
> >>
> >> On Fri, Apr 10, 2020 at 8:34 AM Luis Chamberlain <mcgrof@...nel.org> wrote:
> >>> On Thu, Apr 09, 2020 at 08:12:21PM -0700, Bart Van Assche wrote:
> >>>> Please add a might_sleep() call in blk_put_queue() since with this patch
> >>>> applied it is no longer allowed to call blk_put_queue() from atomic context.
> >>>
> >>> Sure thing.
> >>
> >> On second though, I don't think blk_put_queue() would be the right
> >> place for might_sleep(), given we really only care about the *last*
> >> refcount decrement to 0. So I'll move it to blk_release_queue().
> >> Granted, at that point we are too late, and we'd get a splat about
> >> this issue *iff* we really sleep. So yeah, I do suppose that forcing
> >> this check there still makes sense.
> > 
> > I'll add might_sleep() to both blk_release_queue() *and* blk_cleanup_queue().
> 
> Since there is already an unconditional mutex_lock() call in
> blk_cleanup_queue(), do we really need to add a might_sleep() call in
> blk_cleanup_queue()?

You are right, mutex_lock() already has a might_sleep() sprinkled on it.

  Luis