netdev - Re: [PATCH net-next 1/4] net_sched: remove BH blocking in eight actions

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: <CANn89i+nNZx3QftApMcyb2PBopO=v+4rR-gKZZTbUReZjT41Fg@mail.gmail.com>
Date: Fri, 29 Aug 2025 09:03:45 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	Cong Wang <xiyou.wangcong@...il.com>, Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org, 
	eric.dumazet@...il.com
Subject: Re: [PATCH net-next 1/4] net_sched: remove BH blocking in eight actions

On Fri, Aug 29, 2025 at 12:19 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Thu, Aug 28, 2025 at 8:29 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
> >
> > On Thu, Aug 28, 2025 at 11:26 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
> > >
> > > On Wed, Aug 27, 2025 at 8:53 AM Eric Dumazet <edumazet@...gle.com> wrote:
> > > >
> > > > Followup of f45b45cbfae3 ("Merge branch
> > > > 'net_sched-act-extend-rcu-use-in-dump-methods'")
> > > >
> > > > We never grab tcf_lock from BH context in these modules:
> > > >
> > > >  act_connmark
> > > >  act_csum
> > > >  act_ct
> > > >  act_ctinfo
> > > >  act_mpls
> > > >  act_nat
> > > >  act_pedit
> > > >  act_skbedit
> > > >
> > > > No longer block BH when acquiring tcf_lock from init functions.
> > > >
> > >
> > > Brief glance: isnt  the lock still held in BH context for some actions
> > > like pedit and nat (albeit in corner cases)? Both actions call
> > > tcf_action_update_bstats in their act callbacks.
> > > i.e if the action instance was not created with percpu stats,
> > > tcf_action_update_bstats will grab the lock.
> > >
> >
> > Testing with lockdep should illustrate this..
>
> Thanks, I will take a look shortly !

I guess I missed this because the lock has two names (tcfa_lock and tcf_lock)

Also, it is unclear why a spinlock is taken for updating stats
as dumps do not seem to acquire this lock.

This could be using atomic_inc() and atomic_add()...