linux-kernel - Re: [GIT PULL] iomap: new code for 5.4

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: <CAHk-=wgFRM=z6WS-QLThxL2T1AaoCQeZSoHzj8ak35uSePQVbA@mail.gmail.com>
Date:   Thu, 19 Sep 2019 10:03:30 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Darrick J. Wong" <darrick.wong@...cle.com>
Cc:     "Darrick J. Wong" <djwong@...nel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-xfs <linux-xfs@...r.kernel.org>,
        Dave Chinner <david@...morbit.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Eric Sandeen <sandeen@...deen.net>,
        Christoph Hellwig <hch@....de>,
        Andreas Gruenbacher <agruenba@...hat.com>,
        Bob Peterson <rpeterso@...hat.com>,
        cluster-devel <cluster-devel@...hat.com>
Subject: Re: [GIT PULL] iomap: new code for 5.4

On Wed, Sep 18, 2019 at 8:45 PM Darrick J. Wong <darrick.wong@...cle.com> wrote:
>
> I propose the following (assuming Linus isn't cranky enough to refuse
> the entire iomap patchpile forever):

Since I don't think the code was _wrong_, it was just that I didn't
want to introduce a new pattern for something we already have, I'd be
ok with just a fix patch on top too.

And if the xfs people really want to use the "pop" model, that's fine
too - just make it specific to just the iomap_ioend type, which is all
you seem to really want to pop, and make the typing (and naming) be
about that particular thing.

As mentioned, I don't think that whole "while (pop)" model is _wrong_
per se.  But I also don't like proliferating new random list users in
general, just because some subsystem has some internal preference.
See?

And I notice that one of the users actually does keep the list around
and modifies it, ie this one:

        while ((ioend = list_pop_entry(&tmp, struct xfs_ioend, io_list))) {
                xfs_ioend_try_merge(ioend, &tmp);
                xfs_end_ioend(ioend);
        }

actually seems to _work_ on the remaining part of the list in that
xfs_ioend_try_merge() function.

So inside of xfs, that "pop ioend from the list" model really may make
perfect sense, and you could just do

    static inline struct xfs_ioend *xfs_pop_ioend(struct list_head *head)
    {
        struct xfs_ioend *ioend = list_first_entry_or_null(head,
struct xfs_ioend *, io_list);
        if (ioend)
                list_del(&ioend->io_list);
        return ioend;
    }

and I don't think it's wrong.

It's just that we've survived three decades without that list_pop(),
and I don't want to make our header files even bigger and more complex
unless we actually have multiple real users.

             Linus