netdev - Re: [GIT PULL] parisc architecture updates for v4.3

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-next>] [day] [month] [year] [list]

Date:	Tue, 3 Nov 2015 13:01:21 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Helge Deller <deller@....de>, David Miller <davem@...emloft.net>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Parisc List <linux-parisc@...r.kernel.org>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	John David Anglin <dave.anglin@...l.net>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: [GIT PULL] parisc architecture updates for v4.3

On Sun, Oct 25, 2015 at 4:49 AM, Helge Deller <deller@....de> wrote:
>
> please pull some patches for the parisc architecture for kernel v4.3 from:

So no way was I going to pull that for 4.3, and I delayed it to the
merge window.

However, even now that we're in the merge window, and I look at it again:

> The most important change is that we reduce L1_CACHE_BYTES to 16 bytes, for
> which a trivial patch for XPS in the network layer was needed.

I'd really want the network people involved with that change, and I'm
also wondering why you seem to want to re-define L1_CACHE_BYTES to
something that it isn't.

I doubt the PA-RISC L1 cacheline really is 16 bytes. So this seems to
be more of a hack around the fact that some data structures may be
over-aligned, and using that L1_CACHE_BYTES for aligning things that
really don't want to be that aligned. Maybe it casues less sharing,
but if it does so at the cost of excessive memory use, it's still
wrong.

But that in turn says to me "We should fix the *real* problem, rather
than hack around it by having PA-RISC lie about its L1 cache size".

Is there any particular over-alignment that you have determined to be
the real problem?

Also, just looking at other things, we currently do have openrisc that has

  #define L1_CACHE_BYTES 16

so presumably openrisc would have had an issue with that XPS thing,
and how XPS_MIN_MAP_ALLOC can go negative for a 16-byte case (well,
it's zero on 32-bit architectures).

David: the issue wrt XPS is this:

   #define XPS_MIN_MAP_ALLOC ((L1_CACHE_BYTES - sizeof(struct xps_map))   \
       / sizeof(u16))

Comments?

               Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html