Linux M68K Architecture development
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Guenter Roeck <linux@roeck-us.net>,
	"Christoph Lameter (Ampere)" <cl@gentwo.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	Pavel Begunkov <asml.silence@gmail.com>,
	Mike Rapoport <rppt@kernel.org>,
	Christian Brauner <brauner@kernel.org>,
	Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
	linux-mm@kvack.org, io-uring@vger.kernel.org,
	linux-m68k@vger.kernel.org, linux-kernel@vger.kernel.org
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: <3fe55eba-1a8c-464f-8598-6068ce03f296@kernel.dk> (raw)
In-Reply-To: <f602e322-af21-4bb3-86d4-52795a581354@roeck-us.net>

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: 27+ 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 12:55                   ` Lorenzo Stoakes
2024-11-22 18:54                   ` Christoph Lameter (Ampere)
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 \
    --in-reply-to=3fe55eba-1a8c-464f-8598-6068ce03f296@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=asml.silence@gmail.com \
    --cc=brauner@kernel.org \
    --cc=cl@gentwo.org \
    --cc=geert@linux-m68k.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=io-uring@vger.kernel.org \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@roeck-us.net \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=rppt@kernel.org \
    --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