public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Guenter Roeck <[email protected]>,
	"Christoph Lameter (Ampere)" <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>,
	Vlastimil Babka <[email protected]>,
	Pekka Enberg <[email protected]>,
	David Rientjes <[email protected]>,
	Joonsoo Kim <[email protected]>,
	Andrew Morton <[email protected]>,
	Roman Gushchin <[email protected]>,
	Hyeonggon Yoo <[email protected]>,
	Pavel Begunkov <[email protected]>,
	Mike Rapoport <[email protected]>,
	Christian Brauner <[email protected]>,
	Kees Cook <[email protected]>, Jann Horn <[email protected]>,
	[email protected], [email protected],
	[email protected], [email protected]
Subject: Re: [PATCH] slab: Fix too strict alignment check in create_cache()
Date: Thu, 21 Nov 2024 11:35:10 -0700	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 11/21/24 11:30 AM, Guenter Roeck wrote:
> On Thu, Nov 21, 2024 at 09:23:28AM -0800, Christoph Lameter (Ampere) wrote:
>> On Thu, 21 Nov 2024, Geert Uytterhoeven wrote:
>>
>>> Linux has supported m68k since last century.
>>
>> Yeah I fondly remember the 80s where 68K systems were always out of reach
>> for me to have. The dream system that I never could get my hands on. The
>> creme de la creme du jour. I just had to be content with the 6800 and
>> 6502 processors. Then IBM started the sick road down the 8088, 8086
>> that led from crap to more crap. Sigh.
>>
>>> Any new such assumptions are fixed quickly (at least in the kernel).
>>> If you need a specific alignment, make sure to use __aligned and/or
>>> appropriate padding in structures.
>>> And yes, the compiler knows, and provides __alignof__.
>>>
>>>> How do you deal with torn reads/writes in such a scenario? Is this UP
>>>> only?
>>>
>>> Linux does not support (rate) SMP m68k machines.
>>
>> Ah. Ok that explains it.
>>
>> Do we really need to maintain support for a platform that has been
>> obsolete for decade and does not even support SMP?

I asked that earlier in this thread too...

> Since this keeps coming up, I think there is a much more important
> question to ask:
> 
> Do we really need to continue supporting nommu machines ? Is anyone
> but me even boot testing those ?

Getting rid of nommu would be nice for sure in terms of maintenance,
it's one of those things that pop up as a build breaking thing because
nobody is using/testing them.

I'm all for axing relics from the codebase. Doesn't mean they can't be
maintained out-of-tree, but that is where they belong imho.

-- 
Jens Axboe

  reply	other threads:[~2024-11-21 18:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-20 12:46 [PATCH] slab: Fix too strict alignment check in create_cache() Geert Uytterhoeven
2024-11-20 12:49 ` Geert Uytterhoeven
2024-11-20 15:00 ` Guenter Roeck
2024-11-20 15:01 ` Jens Axboe
2024-11-20 15:03 ` Vlastimil Babka
2024-11-20 15:14   ` Guenter Roeck
2024-11-20 15:44     ` Vlastimil Babka
2024-11-20 15:50       ` Geert Uytterhoeven
2024-11-20 17:50   ` Christoph Lameter (Ampere)
2024-11-21  3:51     ` Matthew Wilcox
2024-11-21  8:15     ` Geert Uytterhoeven
2024-11-21 17:23       ` Christoph Lameter (Ampere)
2024-11-21 18:30         ` Guenter Roeck
2024-11-21 18:35           ` Jens Axboe [this message]
2024-11-21 18:50           ` Geert Uytterhoeven
2024-11-21 19:08             ` Guenter Roeck
2024-11-21 19:22               ` Guenter Roeck
2024-11-22  9:45                 ` Lorenzo Stoakes
2024-11-22  0:23           ` Greg Ungerer
2024-11-22  8:12             ` Geert Uytterhoeven
2024-11-22  8:25           ` Max Filippov
2024-11-21 10:19 ` Christian Brauner
2024-11-21 22:02 ` John Paul Adrian Glaubitz
2024-11-22  2:12   ` Finn Thain
2024-11-22  7:55     ` Geert Uytterhoeven

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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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