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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAB=NE6VfQH3duMGneJnzEnXzAJ1TDYn26WhQCy8X1Mb_T6esgQ@mail.gmail.com>
Date:   Fri, 10 Apr 2020 14:50:40 -0600
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 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.

  Luis