The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:
Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
are available in the Git repository at:
git://git.libc.org/linux-sh tags/sh-for-5.11
for you to fetch changes up to b89bc060b53e7054e5c8ca11feea4bc884d83611:
sh/intc:
On Wed, Jan 20, 2021 at 12:32:16PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Rich!
>
> I have tested or acked the following patches which are fine from my point of
> view.
>
> "Tested" means I have built and booted a current kernel with the patch in
> question,
> "acked" means, I have
On Fri, Jan 15, 2021 at 11:17:09PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 15, 2021 at 9:01 PM David Laight wrote:
> >
> > From: sonicadvan...@gmail.com
> > > Sent: 15 January 2021 07:03
> > > Problem presented:
> > > A backwards compatibility layer that allows running x86-64 and x86
> > >
On Thu, Nov 19, 2020 at 12:32:54PM -0500, Gabriel Krisman Bertazi wrote:
> Rich Felker writes:
>
> > On Thu, Nov 19, 2020 at 11:15:46AM -0500, Gabriel Krisman Bertazi wrote:
> >> Rich Felker writes:
> >>
> >> > On Wed, Nov 18, 2020 at 01:57:26PM -0500
On Thu, Nov 19, 2020 at 11:15:46AM -0500, Gabriel Krisman Bertazi wrote:
> Rich Felker writes:
>
> > On Wed, Nov 18, 2020 at 01:57:26PM -0500, Gabriel Krisman Bertazi via
> > Libc-alpha wrote:
>
> [...]
>
> >
> > SIGSYS (or signal handling
On Wed, Nov 18, 2020 at 01:57:26PM -0500, Gabriel Krisman Bertazi via
Libc-alpha wrote:
> Hi,
>
> I'm proposing a kernel patch for a feature I'm calling Syscall User
> Dispatch (SUD). It is a mechanism to efficiently redirect system calls
> of only part of a binary back to userspace to be
On Sun, Nov 01, 2020 at 06:27:10PM +, Jessica Clarke wrote:
> On 1 Nov 2020, at 18:15, Jessica Clarke wrote:
> >
> > On 1 Nov 2020, at 18:07, Andy Lutomirski wrote:
> >>
> >> On Sat, Oct 31, 2020 at 6:50 PM Rich Felker wrote:
> >>>
> >&
On Sun, Nov 01, 2020 at 01:27:35AM +, Jessica Clarke wrote:
> On 1 Nov 2020, at 01:22, Rich Felker wrote:
> > On Sat, Oct 31, 2020 at 04:30:44PM -0700, Andy Lutomirski wrote:
> >> cc: some libc folks
> >>
> >> On Mon, Oct 12, 2020 at 6:45 AM Jessi
On Sat, Oct 31, 2020 at 04:30:44PM -0700, Andy Lutomirski wrote:
> cc: some libc folks
>
> On Mon, Oct 12, 2020 at 6:45 AM Jessica Clarke wrote:
> >
> > POSIX specifies that the first field of the supplied msgp, namely mtype,
> > is a long, not a __kernel_long_t, and it's a user-defined struct
On Thu, Oct 29, 2020 at 07:58:42AM +, Sargun Dhillon wrote:
> A mechanism for the thing listening on the listener FD to turn itself on or
> off
> and indicate that it is no longer interested in receiving notifications and
> to
> always continue / return an error code, or that it has taken
On Wed, Oct 28, 2020 at 01:42:13PM +0100, Jann Horn wrote:
> +luto just in case he has opinions on this
>
> On Wed, Oct 28, 2020 at 12:18 PM Camille Mougey wrote:
> > From my understanding, there is no way to delay the activation of
> > seccomp filters, for instance "until an _execve_ call".
>
On Wed, Oct 28, 2020 at 07:25:45PM +0100, Jann Horn wrote:
> On Wed, Oct 28, 2020 at 6:52 PM Rich Felker wrote:
> > On Wed, Oct 28, 2020 at 06:34:56PM +0100, Jann Horn wrote:
> > > On Wed, Oct 28, 2020 at 5:49 PM Rich Felker wrote:
> > > > On Wed, Oct 28, 2020
On Wed, Oct 28, 2020 at 07:39:41PM +0100, Jann Horn wrote:
> On Wed, Oct 28, 2020 at 7:35 PM Rich Felker wrote:
> > On Wed, Oct 28, 2020 at 07:25:45PM +0100, Jann Horn wrote:
> > > On Wed, Oct 28, 2020 at 6:52 PM Rich Felker wrote:
> > > > On Wed, Oct 28, 2020
On Wed, Oct 28, 2020 at 06:34:56PM +0100, Jann Horn wrote:
> On Wed, Oct 28, 2020 at 5:49 PM Rich Felker wrote:
> > On Wed, Oct 28, 2020 at 01:42:13PM +0100, Jann Horn wrote:
> > > On Wed, Oct 28, 2020 at 12:18 PM Camille Mougey wrote:
> > > You're just focusing
from ../include/tst_test.h:93,
> from tst_crypto.c:11:
> x86_64-buildroot-linux-musl/sysroot/usr/include/sys/sysinfo.h:10:8: note:
> originally defined here
>
> Suggested-by: Rich Felker
> Signed-off-by: Petr Vorel
> ---
> Changes v2->v3
../include/tst_safe_macros.h:15,
> > > from ../include/tst_test.h:93,
> > > from tst_crypto.c:11:
> > > x86_64-buildroot-linux-musl/sysroot/usr/include/sys/sysinfo.h:10:8: note:
> > > originally defined here
>
> > > [1]
^~~
> In file included from ../include/tst_safe_macros.h:15,
> from ../include/tst_test.h:93,
> from tst_crypto.c:11:
> x86_64-buildroot-linux-musl/sysroot/usr/include/sys/sysinfo.h:10:8: note:
> originally defined here
>
> [1] or , , ,
>
On Wed, Sep 30, 2020 at 11:46:36PM +0200, Petr Vorel wrote:
> for all but glibc libc.
>
> This fixes redefinition on MUSL which also defines struct sysinfo when
> including (which includes via
> ) and .
>
> glibc loads in .
>
> Signed-off-by: Petr Vorel
> ---
> include/uapi/linux/sysinfo.h
On Tue, Sep 15, 2020 at 08:28:45PM -0400, Rich Felker wrote:
> On Tue, Sep 15, 2020 at 12:35:28PM +0200, John Paul Adrian Glaubitz wrote:
> > Hi Rich!
> >
> > On 9/10/20 3:37 PM, Rich Felker wrote:
> > >> Which I reported to Rich on the 2nd and he had me tes
: fix syscall tracing (2020-09-13 21:22:55 -0400)
Fixes for build and function regression.
Rich Felker (2):
sh: remove spurious circular inclusion from asm/smp.h
On Thu, Sep 17, 2020 at 05:15:03AM +0100, Al Viro wrote:
> On Thu, Sep 17, 2020 at 05:07:15AM +0100, Al Viro wrote:
> > On Wed, Sep 16, 2020 at 07:25:53AM +0100, Christoph Hellwig wrote:
> > > On Tue, Sep 15, 2020 at 08:22:54PM -0400, Rich Felker wrote:
> > > > It was
On Wed, Sep 16, 2020 at 08:18:15AM +0200, Greg KH wrote:
> On Tue, Sep 15, 2020 at 08:22:54PM -0400, Rich Felker wrote:
> > It was discovered while implementing userspace emulation of fchmodat
> > AT_SYMLINK_NOFOLLOW (using O_PATH and procfs magic symlinks; otherwise
> &
On Wed, Sep 16, 2020 at 07:25:53AM +0100, Christoph Hellwig wrote:
> On Tue, Sep 15, 2020 at 08:22:54PM -0400, Rich Felker wrote:
> > It was discovered while implementing userspace emulation of fchmodat
> > AT_SYMLINK_NOFOLLOW (using O_PATH and procfs magic symlinks; oth
On Tue, Sep 15, 2020 at 12:35:28PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Rich!
>
> On 9/10/20 3:37 PM, Rich Felker wrote:
> >> Which I reported to Rich on the 2nd and he had me test a one line patch
> >> fixing
> >> it (adding an extra #include) on
and
performing chmod on the corresponding magic symlink in /proc/self/fd.
However, this requires procfs to be mounted and accessible.
Signed-off-by: Rich Felker
---
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm
with EOPNOTSUPP (see glibc issue #14578 and commit
a492b1e5ef). This inconsistency is non-conforming and wrong, and the
consensus seems to be that it was unintentional to allow link modes to
be changed in the first place.
Signed-off-by: Rich Felker
---
fs/open.c | 6 ++
1 file changed, 6
I'm resubmitting this split into two parts, first blocking chmod of
symlinks in chmod_common, then adding the new syscall, as requested by
Christoph. This will make it impossible to chmod symlinks via the
O_PATH magic symlink path. I've also reordered the unsupported flags
test to come first.
qlock, headers: Untangle the spaghetti
monster")
Signed-off-by: Rich Felker
---
arch/sh/include/asm/smp.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/sh/include/asm/smp.h b/arch/sh/include/asm/smp.h
index 1a0d7cf71c10..100bf241340b 100644
--- a/arch/sh/include/asm/smp.h
+++
On Thu, Sep 10, 2020 at 04:18:28PM +0100, Al Viro wrote:
> On Thu, Sep 10, 2020 at 10:23:37AM -0400, Rich Felker wrote:
>
> > It was determined (see glibc issue #14578 and commit a492b1e5ef) that,
> > on some filesystems, performing chmod on the link itself produces a
> &g
On Thu, Sep 10, 2020 at 05:42:34PM +0100, Christoph Hellwig wrote:
> On Thu, Sep 10, 2020 at 12:39:50PM -0400, Rich Felker wrote:
> > On Thu, Sep 10, 2020 at 05:20:59PM +0100, Christoph Hellwig wrote:
> > > On Thu, Sep 10, 2020 at 10:23:37AM -0400, Rich Felker wrote:
> >
On Thu, Sep 10, 2020 at 05:20:59PM +0100, Christoph Hellwig wrote:
> On Thu, Sep 10, 2020 at 10:23:37AM -0400, Rich Felker wrote:
> > userspace emulation done in libc implementations. No change is made to
> > the underlying chmod_common(), so it's still possible to attempt
> &g
On Thu, Sep 10, 2020 at 06:16:15PM +0200, Greg KH wrote:
> On Thu, Sep 10, 2020 at 10:23:37AM -0400, Rich Felker wrote:
> > POSIX defines fchmodat as having a 4th argument, flags, that can be
> > AT_SYMLINK_NOFOLLOW. Support for changing the access mode of symbolic
> &
is made to
the underlying chmod_common(), so it's still possible to attempt
changes via procfs, if desired. If at some point all filesystems have
been fixed, this could be relaxed to allow filesystems to make their
own decision whether changing access mode of links is supported.
Signed-off-by: Rich
On Thu, Sep 10, 2020 at 06:02:05AM -0500, Rob Landley wrote:
> On 9/10/20 4:55 AM, John Paul Adrian Glaubitz wrote:
> > Hi Rich!
> >
> > On 9/7/20 7:44 PM, Rich Felker wrote:
> >>> Can we still get this merged as a hotfix for 5.9?
> >>
> >> Y
On Mon, Sep 07, 2020 at 11:52:20AM +0200, John Paul Adrian Glaubitz wrote:
> Hi Rich!
>
> On 9/3/20 6:16 PM, Rich Felker wrote:
> >> I can confirm that this patch fixes both strace for me and does not break
> >> libseccomp,
> >> I have run the libseccom
On Thu, Sep 03, 2020 at 12:14:43PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Rich!
>
> On 9/3/20 7:48 AM, Rich Felker wrote:
> > Addition of SECCOMP_FILTER exposed a longstanding bug in
> > do_syscall_trace_enter, whereby r0 (the 5th argument register) was
> &g
On Thu, Sep 03, 2020 at 08:04:44AM +0200, John Paul Adrian Glaubitz wrote:
> On 9/3/20 7:46 AM, Rich Felker wrote:
> >
> > OK, I think I have an explanation for the mechanism of the bug, and it
> > really is a combination of the 2008 bug (confusion of r0 vs r3) and
> >
On Wed, Sep 02, 2020 at 12:15:35AM +1000, Nicholas Piggin wrote:
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: linux...@vger.kernel.org
> Signed-off-by: Nicholas Piggin
> ---
>
> Please ack or nack if you object to this being mered via
> Arnd's tree.
Acked-by: Ric
F_NOTIFY_RESUME.")
Signed-off-by: Rich Felker
---
arch/sh/kernel/entry-common.S | 1 -
arch/sh/kernel/ptrace_32.c| 15 +--
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/sh/kernel/entry-common.S b/arch/sh/kernel/entry-common.S
index ad963104d22d..91ab2607a1ff
On Wed, Sep 02, 2020 at 11:56:04PM -0400, Rich Felker wrote:
> On Sat, Aug 29, 2020 at 01:09:43PM +0200, John Paul Adrian Glaubitz wrote:
> > Hi!
> >
> > On 8/29/20 2:49 AM, Rich Felker wrote:
> > > This restored my ability to use strace
> &
On Sat, Aug 29, 2020 at 01:09:43PM +0200, John Paul Adrian Glaubitz wrote:
> Hi!
>
> On 8/29/20 2:49 AM, Rich Felker wrote:
> > This restored my ability to use strace
>
> I can confirm that. However ...
>
> > and I've written and tested a
On Wed, Sep 02, 2020 at 05:51:16PM +0200, Geert Uytterhoeven wrote:
> Hi Rich,
>
> On Wed, Sep 2, 2020 at 5:43 PM Rich Felker wrote:
> > On Wed, Sep 02, 2020 at 10:31:47AM +0200, Ulf Hansson wrote:
> > > On Tue, 1 Sep 2020 at 17:40, Christoph Hellwig wrote:
> > >
On Wed, Sep 02, 2020 at 10:31:47AM +0200, Ulf Hansson wrote:
> On Tue, 1 Sep 2020 at 17:40, Christoph Hellwig wrote:
> >
> > On Tue, Sep 01, 2020 at 05:36:17PM +0200, Ulf Hansson wrote:
> > > > I still don't think this makes sense, as the dma_mask should always
> > > > be non-NULL here.
> > >
> >
On Tue, Sep 01, 2020 at 05:40:49PM +0200, Christoph Hellwig wrote:
> On Tue, Sep 01, 2020 at 05:36:17PM +0200, Ulf Hansson wrote:
> > > I still don't think this makes sense, as the dma_mask should always
> > > be non-NULL here.
> >
> > If that is the case, I wonder how the driver could even have
EOPNOTSUPP, callers will not get wrong behavior on old kernels that
don't support the new flag; the error is reported and the caller can
decide how to handle it.
Signed-off-by: Rich Felker
---
Changes in v2: I've added a check to ensure that RWF_NOAPPEND does not
override O_APPEND for S_APPEND (chattr
"sh: don't allow non-coherent DMA for NOMMU")
> Reported-by: Rich Felker
> Suggested-by: Christoph Hellwig
> Signed-off-by: Ulf Hansson
> ---
> drivers/mmc/host/mmc_spi.c | 86 +++---
> 1 file changed, 52 insertions(+), 34 deletions(-)
&g
On Mon, Aug 31, 2020 at 11:15:57AM +0200, Jann Horn wrote:
> On Mon, Aug 31, 2020 at 3:46 AM Rich Felker wrote:
> > On Mon, Aug 31, 2020 at 03:15:04AM +0200, Jann Horn wrote:
> > > On Sun, Aug 30, 2020 at 10:00 PM Rich Felker wrote:
> > > > On Sun, Aug 30, 2020
On Mon, Aug 31, 2020 at 03:15:04AM +0200, Jann Horn wrote:
> On Sun, Aug 30, 2020 at 10:00 PM Rich Felker wrote:
> > On Sun, Aug 30, 2020 at 09:02:31PM +0200, Jann Horn wrote:
> > > On Sun, Aug 30, 2020 at 8:43 PM Rich Felker wrote:
> > > > On Sun, Aug 30, 2020
On Sun, Aug 30, 2020 at 09:02:31PM +0200, Jann Horn wrote:
> On Sun, Aug 30, 2020 at 8:43 PM Rich Felker wrote:
> > On Sun, Aug 30, 2020 at 08:31:36PM +0200, Jann Horn wrote:
> > > On Sun, Aug 30, 2020 at 6:36 PM Rich Felker wrote:
> > > > So just checking IS
On Sun, Aug 30, 2020 at 08:31:36PM +0200, Jann Horn wrote:
> On Sun, Aug 30, 2020 at 6:36 PM Rich Felker wrote:
> > On Sun, Aug 30, 2020 at 05:05:45PM +0200, Jann Horn wrote:
> > > On Sat, Aug 29, 2020 at 4:00 AM Rich Felker wrote:
> > > > The pwrite function, ori
On Sun, Aug 30, 2020 at 05:05:45PM +0200, Jann Horn wrote:
> On Sat, Aug 29, 2020 at 4:00 AM Rich Felker wrote:
> > The pwrite function, originally defined by POSIX (thus the "p"), is
> > defined to ignore O_APPEND and write at the offset passed as its
> > argume
EOPNOTSUPP, callers will not get wrong behavior on old kernels that
don't support the new flag; the error is reported and the caller can
decide how to handle it.
Signed-off-by: Rich Felker
---
include/linux/fs.h | 4
include/uapi/linux/fs.h | 5 -
2 files changed, 8 insertions(+),
, change the default action from
SECCOMP_RET_KILL_THREAD to SECCOMP_RET_KILL_PROCESS.
Signed-off-by: Rich Felker
---
This fundamental problem with SECCOMP_RET_KILL_THREAD, and that it
should be considered unsafe and deprecated, was recently noted/fixed
seccomp in the man page and its example. Here
On Fri, Aug 28, 2020 at 01:03:00PM -0400, Rich Felker wrote:
> On Fri, Aug 28, 2020 at 06:38:09PM +0200, John Paul Adrian Glaubitz wrote:
> > Hi!
> >
> > On 8/28/20 6:30 PM, Rich Felker wrote:
> > > I'm about to test a patch along these lines and will report what
On Fri, Aug 28, 2020 at 06:38:09PM +0200, John Paul Adrian Glaubitz wrote:
> Hi!
>
> On 8/28/20 6:30 PM, Rich Felker wrote:
> > I'm about to test a patch along these lines and will report what I
> > find.
>
> Let me know when you have something to test and I will test
On Fri, Aug 28, 2020 at 11:50:25AM -0400, Rich Felker wrote:
> On Thu, Jul 23, 2020 at 01:13:21AM +0200, Michael Karcher wrote:
> > Port sh to use the new SECCOMP_FILTER code.
> >
> > Signed-off-by: Michael Karcher
> > ---
> > arch/sh/Kconfig
On Thu, Jul 23, 2020 at 01:13:21AM +0200, Michael Karcher wrote:
> Port sh to use the new SECCOMP_FILTER code.
>
> Signed-off-by: Michael Karcher
> ---
> arch/sh/Kconfig | 1 +
> arch/sh/kernel/entry-common.S | 2 ++
> arch/sh/kernel/ptrace_32.c
On Fri, Aug 28, 2020 at 11:26:57AM +0200, Ulf Hansson wrote:
> On Fri, 28 Aug 2020 at 06:24, Christoph Hellwig wrote:
> >
> > On Thu, Aug 27, 2020 at 10:11:53PM -0400, Rich Felker wrote:
> > > > This change broke SD card support on J2 because MMC_SPI spuriously
On Thu, Aug 27, 2020 at 10:00:48PM -0400, Rich Felker wrote:
> On Tue, Jul 14, 2020 at 02:18:55PM +0200, Christoph Hellwig wrote:
> > The code handling non-coherent DMA depends on being able to remap code
> > as non-cached. But that can't be done without an MMU, so using this
>
On Tue, Jul 14, 2020 at 02:18:55PM +0200, Christoph Hellwig wrote:
> The code handling non-coherent DMA depends on being able to remap code
> as non-cached. But that can't be done without an MMU, so using this
> option on NOMMU builds is broken.
>
> Signed-off-by: Christoph Hellwig
> ---
>
The following changes since commit bcf876870b95592b52519ed4aafcf9d95999bc9c:
Linux 5.8 (2020-08-02 14:21:45 -0700)
are available in the Git repository at:
git://git.libc.org/linux-sh tags/sh-for-5.9
for you to fetch changes up to 0c64a0dce51faa9c706fdf1f957d6f19878f4b81:
sh: landisk:
Hi Linus,
I have some last-minute fixes I hope you can still pull in for 5.8.
One is for a boot regression (mmu code broken) and the other fixes a
long-standing broken syscall number bounds check.
Rich
The following changes since commit 92ed301919932f13b9172e525674157e983d:
Linux
On Wed, Jul 22, 2020 at 04:52:56PM -0700, Guenter Roeck wrote:
> Rich,
>
> On 7/22/20 3:52 PM, Rich Felker wrote:
> > On Tue, Jul 21, 2020 at 07:38:40PM -0700, Guenter Roeck wrote:
> >> On Thu, Dec 12, 2019 at 11:38:43AM +0900, Kuninori Morimoto wrote:
>
On Tue, Jul 21, 2020 at 07:38:40PM -0700, Guenter Roeck wrote:
> On Thu, Dec 12, 2019 at 11:38:43AM +0900, Kuninori Morimoto wrote:
> > From: Kuninori Morimoto
> >
> > __delay() is used from kernel module.
> > We need EXPORT_SYMBOL(), otherwise we will get compile error.
> >
> > ERROR:
On Tue, Jul 21, 2020 at 07:11:34AM +0200, Christoph Hellwig wrote:
> On Mon, Jul 20, 2020 at 11:17:26PM -0400, Rich Felker wrote:
> > On Tue, Jul 14, 2020 at 02:18:54PM +0200, Christoph Hellwig wrote:
> > > Have a single definition that architetures can select.
>
On Mon, Jul 20, 2020 at 10:53:26AM -0400, Rich Felker wrote:
> On Mon, Jul 20, 2020 at 03:42:38PM +0200, John Paul Adrian Glaubitz wrote:
> > Hi Christoph!
> >
> > On 7/20/20 3:38 PM, Christoph Hellwig wrote:
> > > On Wed, Jul 15, 2020 at 01:12:33AM +0200, J
On Tue, Jul 14, 2020 at 02:18:54PM +0200, Christoph Hellwig wrote:
> Have a single definition that architetures can select.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/m68k/Kconfig | 4 +---
> arch/m68k/Kconfig.machine | 1 +
> arch/um/Kconfig | 4 +---
>
bus=%3d devfn=0x%04x "
> diff --git a/arch/sh/drivers/pci/pci.c b/arch/sh/drivers/pci/pci.c
> index c7784e156964..77130f035fdd 100644
> --- a/arch/sh/drivers/pci/pci.c
> +++ b/arch/sh/drivers/pci/pci.c
> @@ -204,7 +204,7 @@ pcibios_bus_report_status_early(struct pci_channe
> -}
> > -EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
> > -#endif
> > -
> > void arch_remove_memory(int nid, u64 start, u64 size,
> > struct vmem_altmap *altmap)
> > {
> >
>
> Reviewed-by: David Hildenbrand
Acked-by: Rich Felker
On Mon, Jun 15, 2020 at 06:23:06PM -0400, Peter Xu wrote:
> Use the new mm_fault_accounting() helper for page fault accounting.
>
> Avoid doing page fault accounting multiple times if the page fault is retried.
>
> CC: Yoshinori Sato
> CC: Rich Felker
> CC: linux...@vge
On Mon, Jul 20, 2020 at 03:42:38PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Christoph!
>
> On 7/20/20 3:38 PM, Christoph Hellwig wrote:
> > On Wed, Jul 15, 2020 at 01:12:33AM +0200, John Paul Adrian Glaubitz wrote:
> >> Hello!
> >>
> >> I have applied Christoph's full series on top of Linus'
On Wed, Jul 15, 2020 at 01:12:33AM +0200, John Paul Adrian Glaubitz wrote:
> Hello!
>
> I have applied Christoph's full series on top of Linus' tree and I can
> confirm that
> the kernel boots fine on my SH-7785LCR board.
>
> Thus, for the whole series of patches:
>
> Tested-by: John Paul
On Tue, Jul 14, 2020 at 02:31:00PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Christoph!
>
> On 7/14/20 2:18 PM, Christoph Hellwig wrote:
> > can you take a look and possibly pick up the series below that untangles
> > and sorts out minor issues with the sh ioremap and dma code?
> >
> > I sent
t; > If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> > If both the HTTP and HTTPS versions
> > return 200 OK and serve the same content:
> > Replace HTTP with HTTPS.
> >
> > Signed-off-by: Alexander A. Klimov
>
The following changes since commit 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162:
Linux 5.7 (2020-05-31 16:49:15 -0700)
are available in the Git repository at:
git://git.libc.org/linux-sh tags/sh-for-5.8
for you to fetch changes up to 37744feebc086908fd89760650f458ab19071750:
sh: remove sh5
On Fri, Jun 05, 2020 at 05:47:34PM +0200, John Paul Adrian Glaubitz wrote:
> On 6/5/20 5:43 PM, Rich Felker wrote:
> >> Can you include the patch as well?
> >
> > This one is outside arch/sh and I'm not sure it's permissible to go up
> > through my tree. I was also
On Fri, Jun 05, 2020 at 05:38:18PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Rich!
>
> On 6/2/20 3:33 AM, Rich Felker wrote:
> >>>> [PATCH 1/2] arch/sh: vmlinux.scr
> >>>> https://marc.info/?l=linux-sh=158429470120959=2
> >>
> >> OK.
On Wed, Jun 03, 2020 at 08:49:54AM -0500, Rob Landley wrote:
> The headers_install_all target got removed last year (commit f3c8d4c7a728 and
> would someone like to update Documentation/kbuild/headers_install.txt which
> still describes it?)
>
> The musl-libc maintainer is using a forked
linux/kernel.h is a uapi header that does almost nothing but define
some internal-use alignment macros and -- oddly -- include
linux/sysinfo.h to provide a definition of struct sysinfo. It's
included only from 6 places in the kernel uapi headers:
include/uapi/linux/lightnvm.h
On Tue, Jun 02, 2020 at 03:00:39PM +1000, Stephen Rothwell wrote:
> Hi Rich,
>
> On Mon, 1 Jun 2020 23:11:39 -0400 Rich Felker wrote:
> >
> > Could you reactivate linux-next pull from my arch/sh for-next branch?
> > It's where it was before, at:
> >
> >
Stephen,
Could you reactivate linux-next pull from my arch/sh for-next branch?
It's where it was before, at:
git://git.libc.org/linux-sh for-next
and has newly accepted patches ready.
Rich
On Mon, Jun 01, 2020 at 07:49:36PM -0700, Andrew Morton wrote:
> On Mon, 1 Jun 2020 21:33:32 -0400 Rich Felker wrote:
>
> > Hmm, it looks like Andrew Morton just pulled most of these into -mm,
> > apparently independently of me getting them in my for-next a few hours
> >
On Mon, Jun 01, 2020 at 02:13:00PM -0400, Rich Felker wrote:
> On Sat, May 30, 2020 at 10:08:09AM +0200, John Paul Adrian Glaubitz wrote:
> > On 5/29/20 7:53 PM, Rich Felker wrote:
> > > Frustratingly, I _still_ don't have an official tree on kernel.org for
> > > the pur
On Mon, Jun 01, 2020 at 10:26:09PM +0200, Michael Karcher wrote:
> Rich Felker schrieb:
> >> >> Can I propose a different solution? For archs where there isn't
> >> >> actually any 64-bit load or store instruction, does it make sense to
> >> >> b
On Sat, May 30, 2020 at 10:08:09AM +0200, John Paul Adrian Glaubitz wrote:
> On 5/29/20 7:53 PM, Rich Felker wrote:
> > Frustratingly, I _still_ don't have an official tree on kernel.org for
> > the purpose of being the canonical place for linux-next to pull from,
> > due t
On Mon, Jun 01, 2020 at 11:13:26AM +0200, John Paul Adrian Glaubitz wrote:
> Hello!
>
> On 6/1/20 11:02 AM, Geert Uytterhoeven wrote:
> >> Can I propose a different solution? For archs where there isn't
> >> actually any 64-bit load or store instruction, does it make sense to
> >> be writing asm
On Sun, May 31, 2020 at 12:43:11PM +0200, Geert Uytterhoeven wrote:
> Hi Adrian,
>
> On Sun, May 31, 2020 at 11:59 AM John Paul Adrian Glaubitz
> wrote:
> > On 5/31/20 11:54 AM, John Paul Adrian Glaubitz wrote:
> > > On 5/31/20 11:52 AM, Geert Uytterhoeven wrote:
> > >> As this is the 64-bit
On Sun, May 31, 2020 at 10:03:13AM +0200, John Paul Adrian Glaubitz wrote:
> On 5/31/20 5:20 AM, Rob Landley wrote:
> > On 5/30/20 3:08 AM, John Paul Adrian Glaubitz wrote:
> >> On 5/29/20 7:53 PM, Rich Felker wrote:
> >>> Frustratingly, I _still_ don't have
On Fri, May 29, 2020 at 07:30:59AM -0700, Christoph Hellwig wrote:
> On Thu, May 28, 2020 at 12:14:16PM -0400, Rich Felker wrote:
> > It is in active use. Please do not act on such a request. I would be
> > much quicker to ack things that actually need ack if I weren't CC'd
On Fri, May 29, 2020 at 12:32:07AM +0200, John Paul Adrian Glaubitz wrote:
> Hello Rich!
>
> On 5/29/20 12:14 AM, Rich Felker wrote:
> > To follow up, I see that there was a patch series of yours (3/24) I
> > missed ack'ing fairly recently. At first glance it looks good. It
&
On Thu, May 28, 2020 at 12:14:16PM -0400, Rich Felker wrote:
> On Wed, May 27, 2020 at 10:46:00PM -0700, Christoph Hellwig wrote:
> > [adding Linus]
> >
> > On Thu, May 07, 2020 at 07:35:52AM -0700, Christoph Hellwig wrote:
> > > Any progress on this? I plan to
On Wed, May 27, 2020 at 10:46:00PM -0700, Christoph Hellwig wrote:
> [adding Linus]
>
> On Thu, May 07, 2020 at 07:35:52AM -0700, Christoph Hellwig wrote:
> > Any progress on this? I plan to resend the sh dma-mapping I've been
> > trying to get upstream for a year again, and they would conflict,
On Wed, May 20, 2020 at 12:08:10PM -0400, Rich Felker wrote:
> On Wed, May 20, 2020 at 04:41:29PM +0100, Szabolcs Nagy wrote:
> > The 05/19/2020 22:31, Arnd Bergmann wrote:
> > > On Tue, May 19, 2020 at 10:24 PM Adhemerval Zanella
> > > wrote:
> > > > O
On Wed, May 20, 2020 at 04:41:29PM +0100, Szabolcs Nagy wrote:
> The 05/19/2020 22:31, Arnd Bergmann wrote:
> > On Tue, May 19, 2020 at 10:24 PM Adhemerval Zanella
> > wrote:
> > > On 19/05/2020 16:54, Arnd Bergmann wrote:
> > > > Jack Schmidt reported a bug for the arm32 clock_gettimeofday64
On Tue, May 19, 2020 at 05:24:18PM -0300, Adhemerval Zanella wrote:
>
>
> On 19/05/2020 16:54, Arnd Bergmann wrote:
> > Jack Schmidt reported a bug for the arm32 clock_gettimeofday64 vdso call
> > last
> > month: https://github.com/richfelker/musl-cross-make/issues/96 and
> >
On Fri, May 01, 2020 at 12:10:05AM +1000, Greg Ungerer wrote:
>
>
> On 30/4/20 9:03 am, Linus Torvalds wrote:
> >On Wed, Apr 29, 2020 at 2:57 PM Russell King - ARM Linux admin
> > wrote:
> >>
> >>I've never had any reason to use FDPIC, and I don't have any binaries
> >>that would use it.
On Sat, Oct 19, 2019 at 10:17:17PM +0200, Hauke Mehrtens wrote:
> musl libc also defines the structures in their arch/aarch64/bits/signal.h
> header file. Some applications like strace and gdb include both of them
> and then the structure definitions are clashing and the build of these
> user
On Fri, Oct 04, 2019 at 03:00:31PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Oct 03, 2019 at 11:29:11AM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > Some time ago I started a discussion about the need for a proper early
> > device
> > probing mechanism[1]. One that
On Wed, Sep 11, 2019 at 09:54:23PM +0200, Florian Weimer wrote:
> * Carlos O'Donell:
>
> > On 9/11/19 3:08 PM, Florian Weimer wrote:
> >> * Carlos O'Donell:
> >>
> >>> It would be easier to merge the patch set if it were just an unconditional
> >>> registration like we do for set_robust_list().
On Wed, Aug 14, 2019 at 10:06:19AM -0700, Linus Torvalds wrote:
> On Wed, Aug 14, 2019 at 9:55 AM Rich Felker wrote:
> >
> > I don't think "downsides" sufficiently conveys that this is hard
> > breakage of a requirement for waitpid.
>
> Well, let's be hone
1 - 100 of 950 matches
Mail list logo
