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: <CAM0EoMknB8MwZ_nPgpjH3N50ahRLsENr4HibKQHdwNGNO5sf9w@mail.gmail.com>
Date: Mon, 1 Sep 2025 00:45:20 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Eric Dumazet <edumazet@...gle.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:03 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> 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.
>

action stats dump does start in tcf_action_copy_stats which will grab
the lock (in either gnet_stats_start_copy_compat or
gnet_stats_start_copy) and releases when it terminates in
gnet_stats_finish_copy.

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

Doable - could be involved...

cheers,
jamal