linux-kernel - Re: [PATCH 4.19 41/80] netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval

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]

Date:   Tue, 19 May 2020 16:06:11 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Stefano Brivio <sbrivio@...hat.com>
Cc:     Pavel Machek <pavel@...x.de>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, Pablo Neira Ayuso <pablo@...filter.org>,
        Sasha Levin <sashal@...nel.org>, Phil Sutter <phil@....cc>
Subject: Re: [PATCH 4.19 41/80] netfilter: nft_set_rbtree: Introduce and use
 nft_rbtree_interval_start()

On Tue, May 19, 2020 at 03:53:00PM +0200, Stefano Brivio wrote:
> On Tue, 19 May 2020 14:51:13 +0200
> Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> 
> > On Tue, May 19, 2020 at 02:19:07PM +0200, Pavel Machek wrote:
> > > On Tue 2020-05-19 14:13:56, Greg Kroah-Hartman wrote:  
> > > > On Tue, May 19, 2020 at 02:06:25PM +0200, Pavel Machek wrote:  
> > > > > Hi!
> > > > >   
> > > > > > [ Upstream commit 6f7c9caf017be8ab0fe3b99509580d0793bf0833 ]
> > > > > > 
> > > > > > Replace negations of nft_rbtree_interval_end() with a new helper,
> > > > > > nft_rbtree_interval_start(), wherever this helps to visualise the
> > > > > > problem at hand, that is, for all the occurrences except for the
> > > > > > comparison against given flags in __nft_rbtree_get().
> > > > > > 
> > > > > > This gets especially useful in the next patch.  
> > > > > 
> > > > > This looks like cleanup in preparation for the next patch. Next patch
> > > > > is there for some series, but not for 4.19.124. Should this be in
> > > > > 4.19, then?  
> > > > 
> > > > What is the "next patch" in this situation?  
> > > 
> > > In 5.4 you have:
> > > 
> > > 9956 O   Greg Kroah ├─>[PATCH 5.4 082/147] netfilter: nft_set_rbtree: Introduce and use nft
> > > 9957     Greg Kroah ├─>[PATCH 5.4 083/147] netfilter: nft_set_rbtree: Add missing expired c
> > > 
> > > In 4.19 you have:
> > > 
> > > 10373 r   Greg Kroah ├─>[PATCH 4.19 41/80] netfilter: nft_set_rbtree: Introduce and use nft
> > > 10376 O   Greg Kroah ├─>[PATCH 4.19 42/80] IB/mlx4: Test return value of calls to ib_get_ca
> > > 
> > > I believe 41/80 can be dropped from 4.19 series, as it is just a
> > > preparation for 083/147... which is not queued for 4.19.  
> > 
> > I've queued it up for 4.19 now, thanks.
> 
> Wait, wait, sorry. I thought you were queuing this up as a missing
> dependency or something, but I see it's not the case. That patch is
> *not* the preparation for:
> 
>   340eaff65116 netfilter: nft_set_rbtree: Add missing expired checks
> 
> ...but rather preparation for:
> 
>   7c84d41416d8 netfilter: nft_set_rbtree: Detect partial overlaps on insertion
> 
> whose fix-up:
> 
>   72239f2795fa netfilter: nft_set_rbtree: Drop spurious condition for overlap detection on insertion
> 
> was queued for 5.6.x (see <20200421131431.GA793882@...ah.com>).
> 
> Now, if you want to backport "Add missing expired checks", it *might* be
> more convenient to also backport:
> 
>   6f7c9caf017b netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()
> 
> and, perhaps (I haven't tried to actually cherry-pick) also:
> 
>   7c84d41416d8 netfilter: nft_set_rbtree: Detect partial overlaps on insertion
>   72239f2795fa netfilter: nft_set_rbtree: Drop spurious condition for overlap detection on insertion
> 
> and it's safe to either:
> 
> - backport only 6f7c9caf017b
> - backport the three of them
> 
> but other than avoiding conflicts, there should be no reason to do that.
> Sasha had already queued them up for 4.19 and 5.4, then dropped them as
> they weren't needed, see <20200413163900.GO27528@...ha-vm>.

Ok, I'll go drop the patch I just added, thanks for clearing this up.


greg k-h