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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAG_fn=XOguL_++vJk2kFQoxu1msLzFBB5sJiD8Jxr4oUZ7qZ7g@mail.gmail.com>
Date: Mon, 18 Dec 2023 17:16:09 +0100
From: Alexander Potapenko <glider@...gle.com>
To: Yury Norov <yury.norov@...il.com>
Cc: Alexander Lobakin <aleksander.lobakin@...el.com>, 
	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

On Mon, Dec 18, 2023 at 4:57 PM Yury Norov <yury.norov@...il.com> wrote:
>
> + 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.

Yeah, sorry about that. Because the MTE part of the patches was still
awaiting review, I thought it would be better to land the bitmap API
separately, but as you pointed out there should be at least one user
for it, which it wouldn't have in that case.

I don't have a strong preference about whether to submit the patches
before or after the end of year - in fact I don't think they are
urgent enough, and we'd better postpone them till January.

So unless Alexander has urgent fixes depending on my bitmap patches,
I'd suggest waiting till they are taken via the arm64 tree.

> 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



--
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg