linux-kernel - Re: [PATCH v1 11/17] lib: add light-weight queuing mechanism.

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: <169447439989.19905.9386812394578844629@noble.neil.brown.name>
Date:   Tue, 12 Sep 2023 09:19:59 +1000
From:   "NeilBrown" <neilb@...e.de>
To:     "Andrew Morton" <akpm@...ux-foundation.org>
Cc:     "Chuck Lever III" <chuck.lever@...cle.com>,
        "Chuck Lever" <cel@...nel.org>,
        "Linux NFS Mailing List" <linux-nfs@...r.kernel.org>,
        "Liam Howlett" <liam.howlett@...cle.com>,
        "Kees Cook" <keescook@...omium.org>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        "David Gow" <davidgow@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 11/17] lib: add light-weight queuing mechanism.

On Tue, 12 Sep 2023, Andrew Morton wrote:
> On Mon, 11 Sep 2023 20:30:40 +0000 Chuck Lever III <chuck.lever@...cle.com> wrote:
> 
> > 
> > 
> > > On Sep 11, 2023, at 2:13 PM, Andrew Morton <akpm@...ux-foundation.org> wrote:
> > > 
> > > On Mon, 11 Sep 2023 10:39:43 -0400 Chuck Lever <cel@...nel.org> wrote:
> > > 
> > >> lwq is a FIFO single-linked queue that only requires a spinlock
> > >> for dequeueing, which happens in process context.  Enqueueing is atomic
> > >> with no spinlock and can happen in any context.
> > > 
> > > What is the advantage of this over using one of the library
> > > facilities which we already have?
> > 
> > I'll let the patch author respond to that question, but let me pose
> > one of my own: What pre-existing facilities are you thinking of, so
> > that I may have a look?
> 
> Well, I assume that plain old list_heads could be recruited for this
> requirement.  And I hope that a FIFO could be implemented using kfifo ;)
> 

Plain old list_heads (which the code currently uses) require a spinlock
to be taken to insert something into the queue.  As this is usually in
bh context, it needs to be a spin_lock_bh().  My understanding is that
the real-time developers don't much like us disabling bh.  It isn't an
enormous win switching from a list_head list to a llist_node list, but
there are small gains such as object size reduction and less locking.  I
particularly wanted an easy-to-use library facility that could be
plugged in to two different uses cases in the sunrpc code and there
didn't seem to be one.  I could have written one using list_head, but
llist seemed a better fix.  I think the code in sunrpc that uses this
lwq looks a lot neater after the conversion.

I wasn't aware of kfifo.  Having now looked at it I don't think it would
be suitable.  It is designed to provide a fixed-size buffer for data
with cycling "head" and "tail" pointers - typically for data coming from
or to a device.  It doesn't provide any locking support so we would need
locking both to enqueue and to dequeue.  Thus it would be no better than
the list_head approach, and the different interface style would make it
harder to use (an "impedance mismatch"?).  A simple summary might be
that kfifo provides a buffer, not a queue.

Thanks,
NeilBrown