linux-kernel - Re: [PATCH 09/12] xfs: refactor the ioend merging code

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: <20190625144513.GB5379@magnolia>
Date:   Tue, 25 Jun 2019 07:45:13 -0700
From:   "Darrick J. Wong" <darrick.wong@...cle.com>
To:     Nikolay Borisov <nborisov@...e.com>
Cc:     Christoph Hellwig <hch@....de>,
        Damien Le Moal <Damien.LeMoal@....com>,
        Andreas Gruenbacher <agruenba@...hat.com>,
        linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 09/12] xfs: refactor the ioend merging code

On Tue, Jun 25, 2019 at 03:42:20PM +0300, Nikolay Borisov wrote:
> 
> 
> On 25.06.19 г. 13:14 ч., Christoph Hellwig wrote:
> > On Mon, Jun 24, 2019 at 07:06:22PM +0300, Nikolay Borisov wrote:
> >>> +{
> >>> +	struct list_head	tmp;
> >>> +
> >>> +	list_replace_init(&ioend->io_list, &tmp);
> >>> +	xfs_destroy_ioend(ioend, error);
> >>> +	while ((ioend = list_pop(&tmp, struct xfs_ioend, io_list)))
> >>> +		xfs_destroy_ioend(ioend, error);
> >>
> >> nit: I'd prefer if the list_pop patch is right before this one since
> >> this is the first user of it.
> > 
> > I try to keep generic infrastructure first instead of interveawing
> > it with subystem-specific patches.
> > 
> >> Additionally, I don't think list_pop is
> >> really a net-negative win 
> > 
> > What is a "net-negative win" ?
> 
> What I meant was 'net-positive win', in terms of making the code more
> readable or optimised.
> 
> > 
> >> in comparison to list_for_each_entry_safe
> >> here. In fact this "delete the list" would seems more idiomatic if
> >> implemented via list_for_each_entry_safe
> > 
> > I disagree.  The for_each loops require an additional next iterator,
> > and also don't clearly express what is going on, but require additional
> > spotting of the list_del.
> 
> That is of course your opinion. At the very least we can agree to disagree.
> 
> What I'm worried about, though, is now you've essentially introduced a
> new idiom to dispose of lists, which is used only in your code. If it
> doesn't become more widespread and gradually start replacing current
> list_for_each_entry_safe usage then you would have increased the public
> list interface to cater for one specific use case, just because it seems
> more natural to you. I guess only time will show whether it makes sense
> to have list_pop_entry

I for one would love to replace all the opencoded "walk a list and drop
each entry before we move on" code in fs/xfs/scrub/ with list_pop_entry.
Quickly scanning fs/xfs/, there seem to be a couple dozen places where
we could probably do that too.

--D