Re: [PATCH 4.14] mm, slub: restore the original intention of prefetch_freepointer()

From: Sven Eckelmann <sven@narfation.org>
To: Sasha Levin <sashal@kernel.org>
Cc: stable@vger.kernel.org, Vlastimil Babka <vbabka@suse.cz>,
	Kees Cook <keescook@chromium.org>,
	Daniel Micay <danielmicay@gmail.com>,
	Eric Dumazet <edumazet@google.com>,
	Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Matthias Schiffer <mschiffer@universe-factory.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 4.14] mm, slub: restore the original intention of prefetch_freepointer()
Date: Mon, 27 Apr 2020 09:01:56 +0200	[thread overview]
Message-ID: <11030934.sCltEm0ppq@bentobox> (raw)
In-Reply-To: <20200426231426.GM13035@sasha-vm>

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

On Monday, 27 April 2020 01:14:26 CEST Sasha Levin wrote:
> On Sun, Apr 26, 2020 at 09:06:17AM +0200, Sven Eckelmann wrote:
> >From: Vlastimil Babka <vbabka@suse.cz>
> >
> >commit 0882ff9190e3bc51e2d78c3aadd7c690eeaa91d5 upstream.
[...]
> >---
> >The original problem is explained in the patch description as
> >performance problem. And maybe this could also be one reason why it was
> >never submitted for a stable kernel.
> >
> >But tests on mips ath79 (OpenWrt ar71xx target) showed that it most likely
> >related to "random" data bus errors. At least applying this patch seemed to
> >have solved it for Matthias Schiffer <mschiffer@universe-factory.net> and
> >some other persons who where debugging/testing this problem with him.
> >
> >More details about it can be found in
> >https://github.com/freifunk-gluon/gluon/issues/1982
> 
> Interesting... I wonder why this issue has started only now.

Unfortunately, I don't know the details. So I (actually we) would love to get 
some feedback from the slub experts. Not that there is another problem which 
we just don't grasp yet.

Just some background information about the "why" from freifunk-gluon's 
perspective:

OpenWrt 19.07 was released (despite its name) at the beginning of 2020. And it 
was the first release using kernel 4.14 on the most used target: ar71xx 
(ath79). The wireless community network firmware projects (freifunk-gluon in 
this example) updated their frameworks to this OpenWrt release in the last 
months and just now started to roll it out on their networks.

And while the wireless community networks around here usually don't track the 
connected clients, the health of the APs is often tracked on some central 
system. And some people then just noticed a sudden spike of reboots on their 
APs. Since ar71xx is (often) the most used architecture at the moment, this 
could be spotted rather easily if you spend some time looking at graphs.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]