public inbox for [email protected]
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <[email protected]>
To: Guenter Roeck <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>,
	"Christoph Lameter (Ampere)" <[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]>, Jens Axboe <[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: Fri, 22 Nov 2024 09:45:52 +0000	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On Thu, Nov 21, 2024 at 11:22:58AM -0800, Guenter Roeck wrote:
> On Thu, Nov 21, 2024 at 11:08:54AM -0800, Guenter Roeck wrote:
> > On Thu, Nov 21, 2024 at 07:50:33PM +0100, Geert Uytterhoeven wrote:
> > > On Thu, Nov 21, 2024 at 7:30 PM Guenter Roeck <[email protected]> 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.
> > >
> > > s/rate/rare/
> > >
> > > > > 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?
> > > >
> > > > 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 ?
> > >
> > > Not all m68k platform are nommu.
> > >
> > Yes, I wasn't trying to point to m68k, but to nommu in general.
> >
>
> For some more context: I think it is highly unlikely that anyone is really
> using a recent version of Linux on a nommu machine. Maybe that was the case
> 10 or 20 years ago, but nowadays there are other operating systems which are
> much better suited than Linux for such systems. Yet, there is a _lot_ of
> nommu code in the kernel. In comparison, supporting m68k (mmu based) is a no
> brainer, plus there are actually people like Geert actively supporting it.
>
> If we are talking about dropping m68k support, we should really talk about
> dropping nommu support first to get some _real_ benefit.
>
> Guenter
>
>

I couldn't agree more re: nommu, it is the real source of maintenance
issues at least for us in mm, and one I've personally run into many times.

An aside, but note that there is a proposal to add nommu support to UML,
which would entirely prevent our ability to eliminate it [0] (though it
would make testing it easier! :)

[0]:https://lore.kernel.org/all/[email protected]/

  reply	other threads:[~2024-11-22  9:46 UTC|newest]

Thread overview: 26+ 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
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 [this message]
2024-11-22 12:55                   ` 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] \
    [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