[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <028eed419f1ad935b86f3bde678d0b7e02d03d94.camel@physik.fu-berlin.de>
Date: Fri, 16 Jan 2026 18:17:54 +0100
From: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
To: Ludwig Rydberg <ludwig.rydberg@...sler.com>, davem@...emloft.net,
andreas@...sler.com, brauner@...nel.org, shuah@...nel.org
Cc: sparclinux@...r.kernel.org, linux-kselftest@...r.kernel.org,
linux-kernel@...r.kernel.org, arnd@...db.de, geert@...ux-m68k.org,
schuster.simon@...mens-energy.com, kernel@...rcher.dialup.fu-berlin.de
Subject: Re: [PATCH 1/3] sparc: Synchronize user stack on fork and clone
Hi Ludwig
On Fri, 2026-01-16 at 16:30 +0100, Ludwig Rydberg wrote:
> From: Andreas Larsson <andreas@...sler.com>
>
> Flush all uncommitted user windows before calling the generic syscall
> handlers for clone, fork, and vfork.
>
> Prior to entering the arch common handlers sparc_{clone|fork|vfork}, the
> arch-specific syscall wrappers for these syscalls will attempt to flush
> all windows (including user windows).
>
> In the window overflow trap handlers on both SPARC{32|64},
> if the window can't be stored (i.e due to MMU related faults) the routine
> backups the user window and increments a thread counter (wsaved).
>
> By adding a synchronization point after the flush attempt, when fault
> handling is enabled, any uncommitted user windows will be flushed.
I have only seen now that your series fixes two bugs, one is the previously
reported clone() bug and the other one is adding clone3(). I have only tested
the latter so far, so I will add my Tested-by to the second patch.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Powered by blists - more mailing lists