netdev - Re: [PATCH v4 net-next 2/6] cache: enforce cache groups

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: Thu, 26 Oct 2023 16:50:12 -0700
From: Coco Li <lixiaoyan@...gle.com>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: kuba@...nel.org, andrew@...n.ch, corbet@....net, daniel@...earbox.net, 
	dsahern@...nel.org, edumazet@...gle.com, mubashirq@...gle.com, 
	ncardwell@...gle.com, netdev@...r.kernel.org, pabeni@...hat.com, 
	pnemavat@...gle.com, weiwan@...gle.com, wwchao@...gle.com
Subject: Re: [PATCH v4 net-next 2/6] cache: enforce cache groups

On Thu, Oct 26, 2023 at 4:39 PM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
>
> From: Jakub Kicinski <kuba@...nel.org>
> Date: Thu, 26 Oct 2023 07:17:01 -0700
> > On Thu, 26 Oct 2023 08:19:55 +0000 Coco Li wrote:
> > > Set up build time warnings to safegaurd against future header changes
> > > of organized structs.
> >
> > TBH I had some doubts about the value of these asserts, I thought
> > it was just me but I was talking to Vadim F and he brought up
> > the same question.
> >
> > IIUC these markings will protect us from people moving the members
> > out of the cache lines. Does that actually happen?
> >
> > It'd be less typing to assert the _size_ of each group, which protects
> > from both moving out, and adding stuff haphazardly, which I'd guess is
> > more common. Perhaps we should do that in addition?

SGTM, will add in next patch.

>
> Also, we could assert the size of the struct itself and further
> add ____cacheline_aligned_in_smp to __cacheline_group_begin() ?
>
> If someone adds/removes a member before __cacheline_group_begin(),
> two groups could share the same cacheline.
>
>

I think we shouldn't add
____cacheline_aligned_in_smp/____cacheline_aligned together with
cacheline_group_begin, because especially for read-only cache lines
that are side by side, enforcing them to be in separate cache lines
will result in more total cache lines when we don't care about the
same cache line being shared by multiple cpus.

An example would be tx_read_only group vs rx_read_only group vs
txrx_read_only groups, since there were suggestions that we mark these
cache groups separately.

For cache line separations that we care about (i.e. tcp_sock in tcp.h)
where read and write might potentially be mixed, the
____cacheline_aligned should probably still be only the in header file
only.