netdev - Re: [Intel-wired-lan] [PATCH iwl-next v4 0/7] Add PFCP filter support

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 for Android: free password hash cracker in your pocket

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

Date: Mon, 18 Dec 2023 07:57:43 -0800
From: Yury Norov <yury.norov@...il.com>
To: Alexander Lobakin <aleksander.lobakin@...el.com>,
	Alexander Potapenko <glider@...gle.com>
Cc: Marcin Szycik <marcin.szycik@...ux.intel.com>,
	Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net,
	Eric Dumazet <edumazet@...gle.com>, pabeni@...hat.com,
	Tony Nguyen <anthony.l.nguyen@...el.com>,
	michal.swiatkowski@...ux.intel.com, wojciech.drewek@...el.com,
	idosch@...dia.com, jesse.brandeburg@...el.com,
	intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
	jiri@...nulli.us
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 0/7] Add PFCP filter support

+ Alexander Potapenko

On Mon, Dec 18, 2023 at 01:47:01PM +0100, Alexander Lobakin wrote:
> From: Marcin Szycik <marcin.szycik@...ux.intel.com>
> Date: Mon, 18 Dec 2023 11:04:01 +0100
> 
> > 
> > 
> > On 15.12.2023 17:49, Jakub Kicinski wrote:
> >> On Fri, 15 Dec 2023 11:11:23 +0100 Alexander Lobakin wrote:
> >>> Ping? :s
> >>> Or should we resubmit?
> >>
> >> Can you wait for next merge window instead?
> >> We're getting flooded with patches as everyone seemingly tries to get
> >> their own (i.e. the most important!) work merged before the end of 
> >> the year. The set of PRs from the bitmap tree which Linus decided
> >> not to pull is not empty. So we'd have to go figure out what's exactly
> >> is in that branch we're supposed to pull, and whether it's fine.
> >> It probably is, but you see, this is a problem which can be solved by
> >> waiting, and letting Linus pull it himself. While the 150 patches we're
> >> getting a day now have to be looked at.
> > 
> > Let's wait to the next window then.
> 
> Hey Yury,
> 
> Given that PFCP will be resent in the next window...
> 
> Your "boys" tree is in fact self-contained -- those are mostly
> optimizations and cleanups, and for the new API -- bitmap_{read,write}()
> -- it has internal users (after "bitmap: make bitmap_{get,set}_value8()
> use bitmap_{read,write}()"). IOW, I don't see a reason for not merging
> it into your main for-next tree (this week :p).
> What do you think?

I think that there's already enough mess with this patch. Alexander
submitted new version of his MTE series together with the patch.

https://lore.kernel.org/lkml/ZXtciaxTKFBiui%2FX@yury-ThinkPad/T/

Now you're asking me to merge it separately. I don't want to undercut
arm64 folks.

Can you guys decide what you want? If you want to move
bitmap_read/write() with my branch, I need to send it in -next for
testing ASAP. And for that, as I already said, I need at least one
active user in current kernel tree. (Yes, bitmap_get_value8() counts.)

If you want to move it this way, please resend all the patches
together.

Thanks,
Yury