From: Matthew Wilcox <willy@infradead.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Theodore Ts'o <tytso@mit.edu>,
Aaro Koskinen <aaro.koskinen@iki.fi>,
Linus Torvalds <torvalds@linux-foundation.org>,
Paul Cercueil <paul@crapouillou.net>,
42.hyeyoo@gmail.com, akpm@linux-foundation.org,
catalin.marinas@arm.com, cl@linux.com, iamjoonsoo.kim@lge.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
penberg@kernel.org, rientjes@google.com, rkovhaev@gmail.com,
roman.gushchin@linux.dev, Feng Tang <feng.tang@intel.com>
Subject: Re: Deprecating and removing SLOB
Date: Thu, 10 Nov 2022 16:20:04 +0000 [thread overview]
Message-ID: <Y20ktNwgPqUbOwxH@casper.infradead.org> (raw)
In-Reply-To: <e610b6fa-aa71-d612-0eb2-03ba6c4a6b46@suse.cz>
On Thu, Nov 10, 2022 at 08:31:31AM +0100, Vlastimil Babka wrote:
> > octeon-hcd will crash the kernel when SLOB is used. This usually happens
> > after the 18-byte control transfer when a device descriptor is read.
> > The DMA engine is always transfering full 32-bit words and if the
> > transfer is shorter, some random garbage appears after the buffer.
> > The problem is not visible with SLUB since it rounds up the allocations
> > to word boundary, and the extra bytes will go undetected.
>
> Ah, actually it wouldn't *now* as SLUB would make the allocation fall into
> kmalloc-32 cache and only add redzone beyond 32 bytes. But with upcoming
> changes by Feng Tang, this should work.
This is kind of "if a bug stings a tree in a forest, does it hurt"
problem. If all allocations of 18 bytes are rounded up to 20 or more
bytes, then it doesn't matter that the device has this bug. Sure, it
may end up hurting in the future if we decide to create 18-byte slab
caches, but it's not actually going to affect anything today (and we
seem to be moving towards less precision in order to get more
performance)
next prev parent reply other threads:[~2022-11-10 16:20 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-09 20:56 Paul Cercueil
2022-11-09 21:39 ` Linus Torvalds
2022-11-09 23:48 ` Aaro Koskinen
2022-11-09 23:51 ` Aaro Koskinen
2022-11-10 4:40 ` Theodore Ts'o
2022-11-10 7:31 ` Vlastimil Babka
2022-11-10 7:54 ` Feng Tang
2022-11-10 16:20 ` Matthew Wilcox [this message]
2022-11-11 9:37 ` David Laight
-- strict thread matches above, loose matches on Subject: below --
2022-11-08 15:55 Vlastimil Babka
2022-11-08 18:18 ` Christophe Leroy
2022-11-08 19:17 ` Andrew Morton
2022-11-08 18:46 ` Roman Gushchin
2022-11-08 20:13 ` Yosry Ahmed
2022-11-09 9:09 ` Vlastimil Babka
2022-11-08 21:44 ` Pasha Tatashin
2022-11-09 9:00 ` Vlastimil Babka
2022-11-09 15:50 ` Aaro Koskinen
2022-11-09 16:45 ` Geert Uytterhoeven
2022-11-09 17:45 ` Mike Rapoport
2022-11-09 21:16 ` Janusz Krzysztofik
2022-11-09 17:57 ` Conor.Dooley
2022-11-09 23:00 ` Damien Le Moal
2022-11-11 10:25 ` Vlastimil Babka
2022-11-12 1:40 ` Damien Le Moal
2022-11-11 10:33 ` Vlastimil Babka
2022-11-11 20:46 ` Conor Dooley
2022-11-12 1:40 ` Damien Le Moal
2022-11-14 1:55 ` Damien Le Moal
2022-11-14 5:48 ` Damien Le Moal
2022-11-14 9:36 ` Vlastimil Babka
2022-11-14 11:35 ` Damien Le Moal
2022-11-14 14:47 ` Hyeonggon Yoo
2022-11-15 4:24 ` Damien Le Moal
2022-11-15 4:28 ` Damien Le Moal
2022-11-16 7:57 ` Matthew Wilcox
2022-11-16 8:02 ` Damien Le Moal
2022-11-16 17:51 ` Vlastimil Babka
2022-11-17 0:22 ` Damien Le Moal
2022-11-21 4:30 ` Damien Le Moal
2022-11-21 17:02 ` Vlastimil Babka
2022-11-14 11:50 ` Hyeonggon Yoo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y20ktNwgPqUbOwxH@casper.infradead.org \
--to=willy@infradead.org \
--cc=42.hyeyoo@gmail.com \
--cc=aaro.koskinen@iki.fi \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=cl@linux.com \
--cc=feng.tang@intel.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=paul@crapouillou.net \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=rkovhaev@gmail.com \
--cc=roman.gushchin@linux.dev \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox