Re: [PATCH v2 3/3] arch: define CONFIG_PAGE_SIZE_*KB on all architectures
On Wed, Mar 6, 2024 at 3:15 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most architectures only support a single hardcoded page size. In order
> to ensure that each one of these sets the corresponding Kconfig symbols,
> change over the PAGE_SHIFT definition to the common one and allow
> only the hardware page size to be selected.
>
> Acked-by: Guo Ren
> Acked-by: Heiko Carstens
> Acked-by: Stafford Horne
> Acked-by: Johannes Berg
> Signed-off-by: Arnd Bergmann
> ---
> No changes from v1
> arch/m68k/Kconfig | 3 +++
> arch/m68k/Kconfig.cpu | 2 ++
> arch/m68k/include/asm/page.h | 6 +-
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 3/4] arch: define CONFIG_PAGE_SIZE_*KB on all architectures
Hi Arnd,
CC Greg
On Tue, Feb 27, 2024 at 11:59 AM Arnd Bergmann wrote:
> On Tue, Feb 27, 2024, at 09:54, Geert Uytterhoeven wrote:
> >> diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
> >> index 9dcf245c9cbf..c777a129768a 100644
> >> --- a/arch/m68k/Kconfig.cpu
> >> +++ b/arch/m68k/Kconfig.cpu
> >> @@ -30,6 +30,7 @@ config COLDFIRE
> >> select GENERIC_CSUM
> >> select GPIOLIB
> >> select HAVE_LEGACY_CLK
> >> + select HAVE_PAGE_SIZE_8KB if !MMU
> >
> > if you would drop the !MMU-dependency here.
> >
> >>
> >> endchoice
> >>
> >> @@ -45,6 +46,7 @@ config M68000
> >> select GENERIC_CSUM
> >> select CPU_NO_EFFICIENT_FFS
> >> select HAVE_ARCH_HASH
> >> + select HAVE_PAGE_SIZE_4KB
> >
> > Perhaps replace this by
> >
> > config M68KCLASSIC
> > bool "Classic M68K CPU family support"
> > select HAVE_ARCH_PFN_VALID
> > + select HAVE_PAGE_SIZE_4KB if !MMU
> >
> > so it covers all 680x0 CPUs without MMU?
>
> I was a bit unsure about how to best do this since there
> is not really a need for a fixed page size on nommu kernels,
> whereas the three MMU configs clearly tie the page size to
> the MMU rather than the platform.
>
> There should be no reason for coldfire to have a different
> page size from dragonball if neither of them actually uses
> hardware pages, so one of them could be changed later.
Indeed, in theory, PAGE_SIZE doesn't matter for nommu, but the concept
of pages is used all over the place in Linux.
I'm mostly worried about some Coldfire code relying on the actual value
of PAGE_SIZE in some other context. e.g. for configuring non-cacheable
regions.
And does this impact running nommu binaries on a system with MMU?
I.e. if nommu binaries were built with a 4 KiB PAGE_SIZE, do they
still run on MMU systems with an 8 KiB PAGE_SIZE (coldfire and sun3),
or are there some subtleties to take into account?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 3/4] arch: define CONFIG_PAGE_SIZE_*KB on all architectures
Hi Arnd,
On Mon, Feb 26, 2024 at 5:15 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most architectures only support a single hardcoded page size. In order
> to ensure that each one of these sets the corresponding Kconfig symbols,
> change over the PAGE_SHIFT definition to the common one and allow
> only the hardware page size to be selected.
>
> Signed-off-by: Arnd Bergmann
Thanks for your patch!
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -84,12 +84,15 @@ config MMU
>
> config MMU_MOTOROLA
> bool
> + select HAVE_PAGE_SIZE_4KB
>
> config MMU_COLDFIRE
> + select HAVE_PAGE_SIZE_8KB
I think you can do without this...
> bool
>
> config MMU_SUN3
> bool
> + select HAVE_PAGE_SIZE_8KB
> depends on MMU && !MMU_MOTOROLA && !MMU_COLDFIRE
>
> config ARCH_SUPPORTS_KEXEC
> diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
> index 9dcf245c9cbf..c777a129768a 100644
> --- a/arch/m68k/Kconfig.cpu
> +++ b/arch/m68k/Kconfig.cpu
> @@ -30,6 +30,7 @@ config COLDFIRE
> select GENERIC_CSUM
> select GPIOLIB
> select HAVE_LEGACY_CLK
> + select HAVE_PAGE_SIZE_8KB if !MMU
if you would drop the !MMU-dependency here.
>
> endchoice
>
> @@ -45,6 +46,7 @@ config M68000
> select GENERIC_CSUM
> select CPU_NO_EFFICIENT_FFS
> select HAVE_ARCH_HASH
> + select HAVE_PAGE_SIZE_4KB
Perhaps replace this by
config M68KCLASSIC
bool "Classic M68K CPU family support"
select HAVE_ARCH_PFN_VALID
+ select HAVE_PAGE_SIZE_4KB if !MMU
so it covers all 680x0 CPUs without MMU?
> select LEGACY_TIMER_TICK
> help
> The Freescale (was Motorola) 68000 CPU is the first generation of
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/4] arch: consolidate existing CONFIG_PAGE_SIZE_*KB definitions
Hi Arnd,
On Mon, Feb 26, 2024 at 5:14 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> These four architectures define the same Kconfig symbols for configuring
> the page size. Move the logic into a common place where it can be shared
> with all other architectures.
>
> Signed-off-by: Arnd Bergmann
Thanks for your patch!
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> +config PAGE_SIZE_4KB
> + bool "4KB pages"
Now you got rid of the 4000-byte ("4kB") pages and friends, please
do not replace these by Kelvin-bytes, and use the official binary
prefixes => "4 KiB".
> + depends on HAVE_PAGE_SIZE_4KB
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 13/21] m68k: rename __iounmap and mark it static
Hi Christoph,
On Thu, Oct 17, 2019 at 7:53 PM Christoph Hellwig wrote:
> m68k uses __iounmap as the name for an internal helper that is only
> used for some CPU types. Mark it static and give it a better name.
>
> Signed-off-by: Christoph Hellwig
Thanks for your patch!
> --- a/arch/m68k/mm/kmap.c
> +++ b/arch/m68k/mm/kmap.c
> @@ -52,6 +52,7 @@ static inline void free_io_area(void *addr)
>
> #define IO_SIZE(256*1024)
>
> +static void __free_io_area(void *addr, unsigned long size);
> static struct vm_struct *iolist;
>
> static struct vm_struct *get_io_area(unsigned long size)
> @@ -90,7 +91,7 @@ static inline void free_io_area(void *addr)
> if (tmp->addr == addr) {
> *p = tmp->next;
> /* remove gap added in get_io_area() */
> - __iounmap(tmp->addr, tmp->size - IO_SIZE);
> + __free_io_area(tmp->addr, tmp->size - IO_SIZE);
> kfree(tmp);
> return;
> }
> @@ -249,12 +250,13 @@ void iounmap(void __iomem *addr)
> }
> EXPORT_SYMBOL(iounmap);
>
> +#ifndef CPU_M68040_OR_M68060_ONLY
Can you please move this block up, instead of adding more #ifdef cluttery?
That would also remove the need for a forward declaration.
> /*
> - * __iounmap unmaps nearly everything, so be careful
> + * __free_io_area unmaps nearly everything, so be careful
> * Currently it doesn't free pointer/page tables anymore but this
> * wasn't used anyway and might be added later.
> */
> -void __iounmap(void *addr, unsigned long size)
> +static void __free_io_area(void *addr, unsigned long size)
> {
> unsigned long virtaddr = (unsigned long)addr;
> pgd_t *pgd_dir;
> @@ -297,6 +299,7 @@ void __iounmap(void *addr, unsigned long size)
>
> flush_tlb_all();
> }
> +#endif /* CPU_M68040_OR_M68060_ONLY */
>
> /*
> * Set new cache mode for some kernel address space.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 12/29] vmlinux.lds.h: Replace RO_DATA_SECTION with RO_DATA
On Fri, Oct 11, 2019 at 2:07 AM Kees Cook wrote:
> Finish renaming RO_DATA_SECTION to RO_DATA. (Calling this a "section"
> is a lie, since it's multiple sections and section flags cannot be
> applied to the macro.)
>
> Signed-off-by: Kees Cook
> arch/m68k/kernel/vmlinux-nommu.lds | 2 +-
For m68k:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 13/29] vmlinux.lds.h: Replace RW_DATA_SECTION with RW_DATA
On Fri, Oct 11, 2019 at 2:07 AM Kees Cook wrote:
> Rename RW_DATA_SECTION to RW_DATA. (Calling this a "section" is a lie,
> since it's multiple sections and section flags cannot be applied to
> the macro.)
>
> Signed-off-by: Kees Cook
> arch/m68k/kernel/vmlinux-nommu.lds | 2 +-
> arch/m68k/kernel/vmlinux-std.lds | 2 +-
> arch/m68k/kernel/vmlinux-sun3.lds | 2 +-
For m68k:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 08/26] m68k: simplify ioremap_nocache
Hi Christoph,
On Fri, Aug 30, 2019 at 6:06 PM Christoph Hellwig wrote:
> On Mon, Aug 19, 2019 at 10:56:02AM +0200, Geert Uytterhoeven wrote:
> > On Sat, Aug 17, 2019 at 9:48 AM Christoph Hellwig wrote:
> > > Just define ioremap_nocache to ioremap instead of duplicating the
> > > inline. Also defined ioremap_uc in terms of ioremap instead of
> > > the using a double indirection.
> > >
> > > Signed-off-by: Christoph Hellwig
> >
> > Acked-by: Geert Uytterhoeven
>
> Do you mind picking this up through the m68k tree?
Sure. Applied and queued for v5.4.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 1/2] pid: add pidfd_open()
On Mon, May 20, 2019 at 3:46 PM Christian Brauner wrote:
> This adds the pidfd_open() syscall. It allows a caller to retrieve pollable
> pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a
> process that is created via traditional fork()/clone() calls that is only
> referenced by a PID:
>
> int pidfd = pidfd_open(1234, 0);
> ret = pidfd_send_signal(pidfd, SIGSTOP, NULL, 0);
>
> With the introduction of pidfds through CLONE_PIDFD it is possible to
> created pidfds at process creation time.
> However, a lot of processes get created with traditional PID-based calls
> such as fork() or clone() (without CLONE_PIDFD). For these processes a
> caller can currently not create a pollable pidfd. This is a problem for
> Android's low memory killer (LMK) and service managers such as systemd.
> Both are examples of tools that want to make use of pidfds to get reliable
> notification of process exit for non-parents (pidfd polling) and race-free
> signal sending (pidfd_send_signal()). They intend to switch to this API for
> process supervision/management as soon as possible. Having no way to get
> pollable pidfds from PID-only processes is one of the biggest blockers for
> them in adopting this api. With pidfd_open() making it possible to retrieve
> pidfds for PID-based processes we enable them to adopt this api.
>
> In line with Arnd's recent changes to consolidate syscall numbers across
> architectures, I have added the pidfd_open() syscall to all architectures
> at the same time.
>
> Signed-off-by: Christian Brauner
> Reviewed-by: Oleg Nesterov
> arch/m68k/kernel/syscalls/syscall.tbl | 1 +
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v1 1/2] pid: add pidfd_open()
Hi Christian, David,
On Thu, May 16, 2019 at 4:00 PM Christian Brauner wrote:
> This adds the pidfd_open() syscall. It allows a caller to retrieve pollable
> pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a
> process that is created via traditional fork()/clone() calls that is only
> referenced by a PID:
>
> int pidfd = pidfd_open(1234, 0);
> ret = pidfd_send_signal(pidfd, SIGSTOP, NULL, 0);
>
> With the introduction of pidfds through CLONE_PIDFD it is possible to
> created pidfds at process creation time.
> However, a lot of processes get created with traditional PID-based calls
> such as fork() or clone() (without CLONE_PIDFD). For these processes a
> caller can currently not create a pollable pidfd. This is a huge problem
> for Android's low memory killer (LMK) and service managers such as systemd.
> Both are examples of tools that want to make use of pidfds to get reliable
> notification of process exit for non-parents (pidfd polling) and race-free
> signal sending (pidfd_send_signal()). They intend to switch to this API for
> process supervision/management as soon as possible. Having no way to get
> pollable pidfds from PID-only processes is one of the biggest blockers for
> them in adopting this api. With pidfd_open() making it possible to retrieve
> pidfd for PID-based processes we enable them to adopt this api.
>
> In line with Arnd's recent changes to consolidate syscall numbers across
> architectures, I have added the pidfd_open() syscall to all architectures
> at the same time.
> +428common pidfd_open sys_pidfd_open
This number conflicts with "[PATCH 4/4] uapi: Wire up the mount API
syscalls on non-x86 arches", which is requested to be included before
rc1.
Note that none of this is part of linux-next.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/2] pid: add pidfd_open()
On Wed, May 15, 2019 at 12:04 PM Christian Brauner wrote:
> This adds the pidfd_open() syscall. It allows a caller to retrieve pollable
> pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a
> process that is created via traditional fork()/clone() calls that is only
> referenced by a PID:
>
> int pidfd = pidfd_open(1234, 0);
> ret = pidfd_send_signal(pidfd, SIGSTOP, NULL, 0);
>
> With the introduction of pidfds through CLONE_PIDFD it is possible to
> created pidfds at process creation time.
> However, a lot of processes get created with traditional PID-based calls
> such as fork() or clone() (without CLONE_PIDFD). For these processes a
> caller can currently not create a pollable pidfd. This is a huge problem
> for Android's low memory killer (LMK) and service managers such as systemd.
> Both are examples of tools that want to make use of pidfds to get reliable
> notification of process exit for non-parents (pidfd polling) and race-free
> signal sending (pidfd_send_signal()). They intend to switch to this API for
> process supervision/management as soon as possible. Having no way to get
> pollable pidfds from PID-only processes is one of the biggest blockers for
> them in adopting this api. With pidfd_open() making it possible to retrieve
> pidfd for PID-based processes we enable them to adopt this api.
>
> In line with Arnd's recent changes to consolidate syscall numbers across
> architectures, I have added the pidfd_open() syscall to all architectures
> at the same time.
>
> Signed-off-by: Christian Brauner
> arch/m68k/kernel/syscalls/syscall.tbl | 1 +
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/2] arch: add pidfd and io_uring syscalls everywhere
On Mon, Mar 25, 2019 at 3:48 PM Arnd Bergmann wrote:
> Add the io_uring and pidfd_send_signal system calls to all architectures.
>
> These system calls are designed to handle both native and compat tasks,
> so all entries are the same across architectures, only arm-compat and
> the generic tale still use an old format.
>
> Signed-off-by: Arnd Bergmann
> arch/m68k/kernel/syscalls/syscall.tbl | 4
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] x86: Deprecate a.out support
On Mon, Mar 11, 2019 at 10:46 PM Linus Torvalds
wrote:
> On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann wrote:
> > The main historic use case I've heard of was running Netscape
> > Navigator on Alpha Linux, before there was an open source version.
> > Doing this today to connect to the open internet is probably
> > a bit pointless, but there may be other use cases.
>
> The _really_ main version was that I decided to make my life easier
> for the initial alpha port by trying to run basic (tested) OSF/1
> binaries directly.
>
> Netscape may have been one of the binaries people actually ended up
> using, but it's probably not a reason any more, since the internet has
> moved past that anyway.
Yeah, the alphas on the server side, powering AltaVista, are also long
gone...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] x86: Deprecate a.out support
Hi Borislav,
On Tue, Mar 5, 2019 at 8:04 PM Borislav Petkov wrote:
> On Tue, Mar 05, 2019 at 07:11:38PM +0100, Borislav Petkov wrote:
> > I guess you could Cc arch maintainers with the a.out-core.h removal
> > patch to see if anyone screams.
>
> And they're like two for which we need confirmation:
>
> $ git ls-files | grep a.out-core.h
> arch/alpha/include/asm/a.out-core.h
> arch/m68k/include/asm/a.out-core.h
> arch/um/include/asm/a.out-core.h
> arch/x86/include/asm/a.out-core.h
>
> um and x86 are clear.
>
> Adding alpha and m68k MLs to Cc.
Thanks!
The oldest binaries I still have lying around (an ext2 ramdisk image,
still used from time to time) are ELF, from just after the a.out to ELF
transition on m68k.
I think it's safe to assume no one still runs a.out binaries on m68k.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v4 2/3] locking/rwsem: Remove rwsem-spinlock.c & use rwsem-xadd.c for all archs
On Wed, Feb 13, 2019 at 11:01 PM Waiman Long wrote:
> Currently, we have two different implementation of rwsem:
> 1) CONFIG_RWSEM_GENERIC_SPINLOCK (rwsem-spinlock.c)
> 2) CONFIG_RWSEM_XCHGADD_ALGORITHM (rwsem-xadd.c)
>
> As we are going to use a single generic implementation for rwsem-xadd.c
> and no architecture-specific code will be needed, there is no point
> in keeping two different implementations of rwsem. In most cases, the
> performance of rwsem-spinlock.c will be worse. It also doesn't get all
> the performance tuning and optimizations that had been implemented in
> rwsem-xadd.c over the years.
>
> For simplication, we are going to remove rwsem-spinlock.c and make all
> architectures use a single implementation of rwsem - rwsem-xadd.c.
>
> All references to RWSEM_GENERIC_SPINLOCK and RWSEM_XCHGADD_ALGORITHM
> in the code are removed.
>
> Suggested-by: Peter Zijlstra
> Signed-off-by: Waiman Long
Note that this conflicts with "[PATCH 03/11] kernel/locks: consolidate
RWSEM_GENERIC_* options"
https://lore.kernel.org/lkml/20190213174005.28785-4-...@lst.de/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 14/29] arch: add pkey and rseq syscall numbers everywhere
On Fri, Jan 18, 2019 at 5:20 PM Arnd Bergmann wrote:
> Most architectures define system call numbers for the rseq and pkey system
> calls, even when they don't support the features, and perhaps never will.
>
> Only a few architectures are missing these, so just define them anyway
> for consistency. If we decide to add them later to one of these, the
> system call numbers won't get out of sync then.
>
> Signed-off-by: Arnd Bergmann
> arch/m68k/kernel/syscalls/syscall.tbl | 4
> --- a/arch/m68k/kernel/syscalls/syscall.tbl
> +++ b/arch/m68k/kernel/syscalls/syscall.tbl
> @@ -388,6 +388,10 @@
> 378common pwritev2sys_pwritev2
> 379common statx sys_statx
> 380common seccomp sys_seccomp
> +381common pkey_alloc sys_pkey_alloc
> +382common pkey_free sys_pkey_free
> +383common pkey_mprotect sys_pkey_mprotect
> +384common rseqsys_rseq
Note that all architectures that already define pkey syscalls, list
pkey_mprotect
first.
Regardless, for m68k:
Acked-by: Geert Uytterhoeven
> # room for arch specific calls
> 393common semget sys_semget
> 394common semctl sys_semctl
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Fri, Jan 18, 2019 at 5:25 PM Arnd Bergmann wrote:
> This adds 21 new system calls on each ABI that has 32-bit time_t
> today. All of these have the exact same semantics as their existing
> counterparts, and the new ones all have macro names that end in 'time64'
> for clarification.
>
> This gets us to the point of being able to safely use a C library
> that has 64-bit time_t in user space. There are still a couple of
> loose ends to tie up in various areas of the code, but this is the
> big one, and should be entirely uncontroversial at this point.
>
> In particular, there are four system calls (getitimer, setitimer,
> waitid, and getrusage) that don't have a 64-bit counterpart yet,
> but these can all be safely implemented in the C library by wrapping
> around the existing system calls because the 32-bit time_t they
> pass only counts elapsed time, not time since the epoch. They
> will be dealt with later.
>
> Signed-off-by: Arnd Bergmann
> arch/m68k/kernel/syscalls/syscall.tbl | 20 +
For m68k:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 26/29] y2038: use time32 syscall names on 32-bit
On Fri, Jan 18, 2019 at 5:21 PM Arnd Bergmann wrote:
> This is the big flip, where all 32-bit architectures set COMPAT_32BIT_TIME
> abd use the _time32 system calls from the former compat layer instead
> of the system calls that take __kernel_timespec and similar arguments.
>
> The temporary redirects for __kernel_timespec, __kernel_itimerspec
> and __kernel_timex can get removed with this.
>
> It would be easy to split this commit by architecture, but with the new
> generated system call tables, it's easy enough to do it all at once,
> which makes it a little easier to check that the changes are the same
> in each table.
>
> Signed-off-by: Arnd Bergmann
> arch/m68k/kernel/syscalls/syscall.tbl | 42 +--
For m68k:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 28/29] y2038: rename old time and utime syscalls
On Fri, Jan 18, 2019 at 5:21 PM Arnd Bergmann wrote:
> The time, stime, utime, utimes, and futimesat system calls are only
> used on older architectures, and we do not provide y2038 safe variants
> of them, as they are replaced by clock_gettime64, clock_settime64,
> and utimensat_time64.
>
> However, for consistency it seems better to have the 32-bit architectures
> that still use them call the "time32" entry points (leaving the
> traditional handlers for the 64-bit architectures), like we do for system
> calls that now require two versions.
>
> Note: We used to always define __ARCH_WANT_SYS_TIME and
> __ARCH_WANT_SYS_UTIME and only set __ARCH_WANT_COMPAT_SYS_TIME and
> __ARCH_WANT_SYS_UTIME32 for compat mode on 64-bit kernels. Now this is
> reversed: only 64-bit architectures set __ARCH_WANT_SYS_TIME/UTIME, while
> we need __ARCH_WANT_SYS_TIME32/UTIME32 for 32-bit architectures and compat
> mode. The resulting asm/unistd.h changes look a bit counterintuitive.
>
> This is only a cleanup patch and it should not change any behavior.
>
> Signed-off-by: Arnd Bergmann
> arch/m68k/include/asm/unistd.h | 4 ++--
> arch/m68k/kernel/syscalls/syscall.tbl | 10 +-
For m68k:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 13/29] arch: add split IPC system calls where needed
On Fri, Jan 18, 2019 at 5:20 PM Arnd Bergmann wrote:
> The IPC system call handling is highly inconsistent across architectures,
> some use sys_ipc, some use separate calls, and some use both. We also
> have some architectures that require passing IPC_64 in the flags, and
> others that set it implicitly.
>
> For the additon of a y2083 safe semtimedop() system call, I chose to only
> support the separate entry points, but that requires first supporting
> the regular ones with their own syscall numbers.
>
> The IPC_64 is now implied by the new semctl/shmctl/msgctl system
> calls even on the architectures that require passing it with the ipc()
> multiplexer.
>
> I'm not adding the new semtimedop() or semop() on 32-bit architectures,
> those will get implemented using the new semtimedop_time64() version
> that gets added along with the other time64 calls.
> Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop().
>
> Signed-off-by: Arnd Bergmann
> arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
For m68k:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 08/29] m68k: assign syscall number for seccomp
On Fri, Jan 18, 2019 at 5:20 PM Arnd Bergmann wrote:
> Most architectures have assigned a numbers for the seccomp syscall
> even when they do not implement it.
>
> m68k is an exception here, so for consistency lets add the number.
> Unless CONFIG_SECCOMP is implemented, the system call just
> returns -ENOSYS.
>
> Signed-off-by: Arnd Bergmann
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
Hi Russell,
On Sat, Jan 19, 2019 at 3:29 PM Russell King - ARM Linux admin
wrote:
> On Fri, Jan 18, 2019 at 11:53:25AM -0800, Andy Lutomirski wrote:
> > On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote:
> > > On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote:
> > > > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
> > > > > - Once we get to 512, we clash with the x32 numbers (unless
> > > > > we remove x32 support first), and probably have to skip
> > > > > a few more. I also considered using the 512..547 space
> > > > > for 32-bit-only calls (which never clash with x32), but
> > > > > that also seems to add a bit of complexity.
> > > >
> > > > I have a patch that I'll send soon to make x32 use its own table. As
> > > > far as I'm concerned, 547 is *it*. 548 is just a normal number and is
> > > > not special. But let's please not reuse 512..547 for other purposes
> > > > on x86 variants -- that way lies even more confusion, IMO.
> > >
> > > Fair enough, the space for those numbers is cheap enough here.
> > > I take it you mean we also should not reuse that number space if
> > > we were to decide to remove x32 soon, but you are not worried
> > > about clashing with arch/alpha when everything else uses consistent
> > > numbers?
> > >
> >
> > I think we have two issues if we reuse those numbers for new syscalls.
> > First, I'd really like to see new syscalls be numbered consistently
> > everywhere, or at least on all x86 variants, and we can't on x32
> > because they mean something else. Perhaps more importantly, due to
> > what is arguably a rather severe bug, issuing a native x86_64 syscall
> > (x32 bit clear) with nr in the range 512..547 does *not* return
> > -ENOSYS on a kernel with x32 enabled. Instead it does something that
> > is somewhat arbitrary. With my patch applied, it will return -ENOSYS,
> > but old kernels will still exist, and this will break syscall probing.
> >
> > Can we perhaps just start the consistent numbers above 547 or maybe
> > block out 512..547 in the new regime?
>
> I don't think you gain much with that kind of scheme - it won't take
> very long before an architecture misses having a syscall added, and
> then someone else adds their own. Been there with ARM - I was keeping
> the syscall table in the same order as x86 for new syscalls, but now
Same for m68k, and probably other architectures.
> that others have been adding syscalls to the table since I converted
> ARM to the tabular form, that's now gone out the window.
>
> So, I think it's completely pointless to do what you're suggesting.
> We'll just end up with a big hole in the middle of the syscall table
> and then revert back to random numbering of syscalls thereafter again.
I believe the plan is to add future syscalls for all architectures in a
single commit, to keep everything in sync.
Regardless, I'm wondering what to do with the holes marked "room for
arch specific calls".
When is a syscall really arch-specific, and can it be added there, and
when does it turn out (later) that it isn't, breaking the
synchronization again?
The pkey syscalls may be a bad example, as AFAIU they can be implemented
on some architectures, but not on some others. Still, I had skipped them
when adding new syscalls to m68k.
Perhaps we should get rid of the notion of "arch-specific syscalls", and
reserve a slot everywhere anyway?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 26/29] y2038: use time32 syscall names on 32-bit
Hi Arnd,
On Fri, Jan 18, 2019 at 5:21 PM Arnd Bergmann wrote:
> This is the big flip, where all 32-bit architectures set COMPAT_32BIT_TIME
> abd use the _time32 system calls from the former compat layer instead
and
> of the system calls that take __kernel_timespec and similar arguments.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 14/15] arch: add split IPC system calls where needed
Hi Arnd,
On Tue, Jan 15, 2019 at 4:19 PM Arnd Bergmann wrote:
> On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann wrote:
> > On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman
> > wrote:
> > > Arnd Bergmann writes:
> > > > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
> > > > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++
> > > > arch/powerpc/kernel/syscalls/syscall.tbl | 12
> > >
> > > I have some changes I'd like to make to our syscall table that will
> > > clash with this.
> > >
> > > I'll try and send them today.
> >
> > Ok. Are those for 5.0 or 5.1? If they are intended for 5.0, it would be
> > nice for me to have a branch based on 5.0-rc1 that I can put
> > the other patches on top of.
>
> There is also another change that I considered:
>
> At the end of my series, we have a lot of entries like
>
> 245 32 clock_settime sys_clock_settime32
> 245 64 clock_settime sys_clock_settime
> 245 spu clock_settime sys_clock_settime
>
> which could be folded into
>
> 245 32 clock_settime sys_clock_settime32
> 245 spu64 clock_settime sys_clock_settime
>
> if we just add another option to the ABI field. Any thoughts on
> that?
So "spu64" would mean "spu + 64"?
That makes it more difficult to read, and to grep.
What about allowing multiple ABIs, separated by commas?
So that line would become:
245 spu,64 clock_settime sys_clock_settime
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 00/15] arch: synchronize syscall tables in preparation for y2038
Hi Arnd,
On Thu, Jan 10, 2019 at 11:43 PM Arnd Bergmann wrote:
> On Thu, Jan 10, 2019 at 7:11 PM Geert Uytterhoeven
> wrote:
> > On Thu, Jan 10, 2019 at 6:06 PM Arnd Bergmann wrote:
> > > On Thu, Jan 10, 2019 at 5:59 PM Geert Uytterhoeven
> > > wrote:
> > > > On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann wrote:
> > > > > The system call tables have diverged a bit over the years, and a
> > > > > number
> > > > > of the recent additions never made it into all architectures, for one
> > > > > reason or another.
> > > > >
> > > > > This is an attempt to clean it up as far as we can without breaking
> > > > > compatibility, doing a number of steps:
> > > >
> > > > Thanks a lot!
> > > >
> > > > > - Add system calls that have not yet been integrated into all
> > > > > architectures but that we definitely want there.
> > > >
> > > > It looks like you missed wiring up io_pgetevents() on m68k.
> > > > Is that intentional?
> > >
> > > Yes, I thought I had described that somewhere but maybe I
> > > forgot: semtimedop() and io_pgetevents() get replaced with
> > > time64 versions in the follow-up, so I only added them in
> > > 64-bit architectures. If you think we should have both
> > > io_pgetevents() and io_pgetevents_time32() on all 32-bit
> > > architectures, I can add that as well.
> >
> > Thanks, sounds fine to me.
>
> Just to be sure, you mean it's fine to not add it, not that we should
> add it?
I'm fine with not having the legacy 32-bit ones.
Sorry for being unclear.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 00/15] arch: synchronize syscall tables in preparation for y2038
Hi Arnd,
On Thu, Jan 10, 2019 at 6:06 PM Arnd Bergmann wrote:
> On Thu, Jan 10, 2019 at 5:59 PM Geert Uytterhoeven
> wrote:
> > On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann wrote:
> > > The system call tables have diverged a bit over the years, and a number
> > > of the recent additions never made it into all architectures, for one
> > > reason or another.
> > >
> > > This is an attempt to clean it up as far as we can without breaking
> > > compatibility, doing a number of steps:
> >
> > Thanks a lot!
> >
> > > - Add system calls that have not yet been integrated into all
> > > architectures but that we definitely want there.
> >
> > It looks like you missed wiring up io_pgetevents() on m68k.
> > Is that intentional?
>
> Yes, I thought I had described that somewhere but maybe I
> forgot: semtimedop() and io_pgetevents() get replaced with
> time64 versions in the follow-up, so I only added them in
> 64-bit architectures. If you think we should have both
> io_pgetevents() and io_pgetevents_time32() on all 32-bit
> architectures, I can add that as well.
Thanks, sounds fine to me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 00/15] arch: synchronize syscall tables in preparation for y2038
Hi Arnd,
On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann wrote:
> The system call tables have diverged a bit over the years, and a number
> of the recent additions never made it into all architectures, for one
> reason or another.
>
> This is an attempt to clean it up as far as we can without breaking
> compatibility, doing a number of steps:
Thanks a lot!
> - Add system calls that have not yet been integrated into all
> architectures but that we definitely want there.
It looks like you missed wiring up io_pgetevents() on m68k.
Is that intentional?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_*
On Fri, Dec 14, 2018 at 10:54 AM Geert Uytterhoeven
wrote:
> On Fri, Dec 14, 2018 at 9:26 AM Christoph Hellwig wrote:
> > If we want to map memory from the DMA allocator to userspace it must be
> > zeroed at allocation time to prevent stale data leaks. We already do
> > this on most common architectures, but some architectures don't do this
> > yet, fix them up, either by passing GFP_ZERO when we use the normal page
> > allocator or doing a manual memset otherwise.
> >
> > Signed-off-by: Christoph Hellwig
>
> Thanks for your patch!
>
> > --- a/arch/m68k/kernel/dma.c
> > +++ b/arch/m68k/kernel/dma.c
> > @@ -32,7 +32,7 @@ void *arch_dma_alloc(struct device *dev, size_t size,
> > dma_addr_t *handle,
> > size = PAGE_ALIGN(size);
> > order = get_order(size);
> >
> > - page = alloc_pages(flag, order);
> > + page = alloc_pages(flag | GFP_ZERO, order);
> > if (!page)
> > return NULL;
>
> There's second implementation below, which calls __get_free_pages() and
> does an explicit memset(). As __get_free_pages() calls alloc_pages(), perhaps
> it makes sense to replace the memset() by GFP_ZERO, to increase consistency?
Regardless, for m68k:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_*
Hi Christoph,
On Fri, Dec 14, 2018 at 9:26 AM Christoph Hellwig wrote:
> If we want to map memory from the DMA allocator to userspace it must be
> zeroed at allocation time to prevent stale data leaks. We already do
> this on most common architectures, but some architectures don't do this
> yet, fix them up, either by passing GFP_ZERO when we use the normal page
> allocator or doing a manual memset otherwise.
>
> Signed-off-by: Christoph Hellwig
Thanks for your patch!
> --- a/arch/m68k/kernel/dma.c
> +++ b/arch/m68k/kernel/dma.c
> @@ -32,7 +32,7 @@ void *arch_dma_alloc(struct device *dev, size_t size,
> dma_addr_t *handle,
> size = PAGE_ALIGN(size);
> order = get_order(size);
>
> - page = alloc_pages(flag, order);
> + page = alloc_pages(flag | GFP_ZERO, order);
> if (!page)
> return NULL;
There's second implementation below, which calls __get_free_pages() and
does an explicit memset(). As __get_free_pages() calls alloc_pages(), perhaps
it makes sense to replace the memset() by GFP_ZERO, to increase consistency?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 4/9] PCI: consolidate PCI config entry in drivers/pci
On Thu, Nov 15, 2018 at 8:06 PM Christoph Hellwig wrote:
> There is no good reason to duplicate the PCI menu in every architecture.
> Instead provide a selectable HAVE_PCI symbol that indicates availability
> of PCI support, and a FORCE_PCI symbol to for PCI on and the handle the
> rest in drivers/pci.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Palmer Dabbelt
> Acked-by: Max Filippov
> Acked-by: Thomas Gleixner
> Acked-by: Bjorn Helgaas
For m68k:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v3] time: Make sure jiffies_to_msecs() preserves non-zero time periods
For the common cases where 1000 is a multiple of HZ, or HZ is a multiple of 1000, jiffies_to_msecs() never returns zero when passed a non-zero time period. However, if HZ > 1000 and not an integer multiple of 1000 (e.g. 1024 or 1200, as used on alpha and DECstation), jiffies_to_msecs() may return zero for small non-zero time periods. This may break code that relies on receiving back a non-zero value. jiffies_to_usecs() does not need such a fix: one jiffy can only be less than one µs if HZ > 100, and such large values of HZ are already rejected at build time, twice: - include/linux/jiffies.h does #error if HZ >= 12288, - kernel/time/time.c has BUILD_BUG_ON(HZ > USEC_PER_SEC). Signed-off-by: Geert Uytterhoeven Reviewed-by: Arnd Bergmann Cc: sta...@vger.kernel.org --- Broken since forever. v3: - Add Reviewed-by, - Cc stable, - Explain better why jiffies_to_usecs() does not need a fix, v2: - Add examples of affected systems, - Use DIV_ROUND_UP(). --- kernel/time/time.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/kernel/time/time.c b/kernel/time/time.c index 6fa99213fc720e4b..2b41e8e2d31db26f 100644 --- a/kernel/time/time.c +++ b/kernel/time/time.c @@ -28,6 +28,7 @@ */ #include +#include #include #include #include @@ -314,9 +315,10 @@ unsigned int jiffies_to_msecs(const unsigned long j) return (j + (HZ / MSEC_PER_SEC) - 1)/(HZ / MSEC_PER_SEC); #else # if BITS_PER_LONG == 32 - return (HZ_TO_MSEC_MUL32 * j) >> HZ_TO_MSEC_SHR32; + return (HZ_TO_MSEC_MUL32 * j + (1ULL << HZ_TO_MSEC_SHR32) - 1) >> + HZ_TO_MSEC_SHR32; # else - return (j * HZ_TO_MSEC_NUM) / HZ_TO_MSEC_DEN; + return DIV_ROUND_UP(j * HZ_TO_MSEC_NUM, HZ_TO_MSEC_DEN); # endif #endif } -- 2.17.1 -- To unsubscribe from this list: send the line "unsubscribe linux-alpha" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] time: Make sure jiffies_to_msecs() preserves non-zero time periods
Hi Thomas,
On Fri, Jun 22, 2018 at 2:49 PM Thomas Gleixner wrote:
> On Fri, 22 Jun 2018, Geert Uytterhoeven wrote:
> > For the common cases where 1000 is a multiple of HZ, or HZ is a multiple
> > of 1000, jiffies_to_msecs() never returns zero when passed a non-zero
> > time period.
> >
> > However, if HZ > 1000 and not an integer multiple of 1000 (e.g. 1024 or
> > 1200, as used on alpha and DECstation), jiffies_to_msecs() may return
> > zero for small non-zero time periods. This may break code that relies
> > on receiving back a non-zero value.
> >
> > jiffies_to_usecs() does not need such a fix, as does
> > not support values of HZ larger than 12287, thus rejecting any
> > problematic huge values of HZ.
>
> Sorry, I'm not understanding that sentence at all.
Sorry for being unclear.
1 jiffy can only be less than 1µs if HZ > 100.
But include/linux/jiffies.h checks if HZ >= 12288, and does #error otherwise.
In addition, there's a "BUILD_BUG_ON(HZ > USEC_PER_SEC)" in time.c
> > Signed-off-by: Geert Uytterhoeven
>
> This lacks a stable tag, right?
Up to the maintainer to add, isn't it?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] time: Make sure jiffies_to_msecs() preserves non-zero time periods
CC alpha, mips On Fri, Jun 22, 2018 at 9:54 AM Geert Uytterhoeven wrote: > For the common cases where 1000 is a multiple of HZ, or HZ is a multiple > of 1000, jiffies_to_msecs() never returns zero when passed a non-zero > time period. > > However, if HZ > 1000 and not an integer multiple of 1000 (e.g. 1024 or > 1200, as used on alpha and DECstation), jiffies_to_msecs() may return > zero for small non-zero time periods. This may break code that relies > on receiving back a non-zero value. > > jiffies_to_usecs() does not need such a fix, as does > not support values of HZ larger than 12287, thus rejecting any > problematic huge values of HZ. > > Signed-off-by: Geert Uytterhoeven > --- > v2: > - Add examples of affected systems, > - Use DIV_ROUND_UP(). > --- > kernel/time/time.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/kernel/time/time.c b/kernel/time/time.c > index 6fa99213fc720e4b..2b41e8e2d31db26f 100644 > --- a/kernel/time/time.c > +++ b/kernel/time/time.c > @@ -28,6 +28,7 @@ > */ > > #include > +#include > #include > #include > #include > @@ -314,9 +315,10 @@ unsigned int jiffies_to_msecs(const unsigned long j) > return (j + (HZ / MSEC_PER_SEC) - 1)/(HZ / MSEC_PER_SEC); > #else > # if BITS_PER_LONG == 32 > - return (HZ_TO_MSEC_MUL32 * j) >> HZ_TO_MSEC_SHR32; > + return (HZ_TO_MSEC_MUL32 * j + (1ULL << HZ_TO_MSEC_SHR32) - 1) >> > + HZ_TO_MSEC_SHR32; > # else > - return (j * HZ_TO_MSEC_NUM) / HZ_TO_MSEC_DEN; > + return DIV_ROUND_UP(j * HZ_TO_MSEC_NUM, HZ_TO_MSEC_DEN); > # endif > #endif > } > -- > 2.17.1 -- To unsubscribe from this list: send the line "unsubscribe linux-alpha" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
Hi Michael,
On Wed, Jan 3, 2018 at 7:24 AM, Michael Ellerman <m...@ellerman.id.au> wrote:
> Geert Uytterhoeven <ge...@linux-m68k.org> writes:
>
>> On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman <m...@ellerman.id.au>
>> wrote:
>>> Christoph Hellwig <h...@lst.de> writes:
>>>
>>>> We want to use the dma_direct_ namespace for a generic implementation,
>>>> so rename powerpc to the second best choice: dma_nommu_.
>>>
>>> I'm not a fan of "nommu". Some of the users of direct ops *are* using an
>>> IOMMU, they're just setting up a 1:1 mapping once at init time, rather
>>> than mapping dynamically.
>>>
>>> Though I don't have a good idea for a better name, maybe "1to1",
>>> "linear", "premapped" ?
>>
>> "identity"?
>
> I think that would be wrong, but thanks for trying to help :)
>
> The address on the device side is sometimes (often?) offset from the CPU
> address. So eg. the device can DMA to RAM address 0x0 using address
> 0x800.
>
> Identity would imply 0 == 0 etc.
>
> I think "bijective" is the correct term, but that's probably a bit
> esoteric.
OK, didn't know about the offset.
Then "linear" is what we tend to use, right?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/67] dma-mapping: replace PCI_DMA_BUS_IS_PHYS with a flag in struct dma_map_ops
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig <h...@lst.de> wrote:
> The current PCI_DMA_BUS_IS_PHYS decided if a dma implementation is bound
> by the dma mask in the device because it directly maps to a physical
> address range (modulo an offset in the device), or if it is virtualized
> by an iommu and can map any address (that includes virtual iommus like
> swiotlb). The problem with this scheme is that it is per-architecture and
> not per dma_ops instance, and we are growing more and more setups that
> have multiple different dma operations in use on a single system, for
> which this scheme can't provide a correct answer. Depending on the
> architecture that means we either get a false positive or false negative
> at the moment.
>
> This patch instead extents the is_phys flag in struct dma_map_ops that
> is currently only used by a few architectures to be used tree wide.
>
> Note that this means that we now need a struct device parent in the
> Scsi_Host or netdevice. Every modern driver has these, but there might
> still be a few outdated legacy drivers out there, which now won't make
> an intelligent decision.
>
> Signed-off-by: Christoph Hellwig <h...@lst.de>
For m68k:
Acked-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 22/67] dma-mapping: clear harmful GFP_* flags in common code
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig <h...@lst.de> wrote:
> Life the code from x86 so that we behave consistently. In the future we
> should probably warn if any of these is set.
>
> Signed-off-by: Christoph Hellwig <h...@lst.de>
For m68k:
Acked-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/67] alpha: mark jensen as broken
Hi Christoph,
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig <h...@lst.de> wrote:
> CONFIG_ALPHA_JENSEN has failed to compile since commit aca05038
> ("alpha/dma: use common noop dma ops"), so mark it as broken.
unknown revision or path not in the working tree.
Ah, you dropped the leading "6":
6aca0503847f6329460b15b3ab2b0e30bb752793
is less than 2 years old, though.
>
> Signed-off-by: Christoph Hellwig <h...@lst.de>
> ---
> arch/alpha/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
> index b31b974a03cb..e96adcbcab41 100644
> --- a/arch/alpha/Kconfig
> +++ b/arch/alpha/Kconfig
> @@ -209,6 +209,7 @@ config ALPHA_EIGER
>
> config ALPHA_JENSEN
> bool "Jensen"
> + depends on BROKEN
> help
> DEC PC 150 AXP (aka Jensen): This is a very old Digital system - one
> of the first-generation Alpha systems. A number of these systems
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 29/67] dma-direct: use node local allocations for coherent memory
Missing patch description explaining why this change is desirable.
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig <h...@lst.de> wrote:
> --- a/lib/dma-direct.c
> +++ b/lib/dma-direct.c
> @@ -39,7 +39,7 @@ static void *dma_direct_alloc(struct device *dev, size_t
> size,
> if (gfpflags_allow_blocking(gfp))
> page = dma_alloc_from_contiguous(dev, count, page_order, gfp);
> if (!page)
> - page = alloc_pages(gfp, page_order);
> + page = alloc_pages_node(dev_to_node(dev), gfp, page_order);
> if (!page)
> return NULL;
>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 27/67] dma-direct: add dma address sanity checks
Hi Christoph,
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig <h...@lst.de> wrote:
> Roughly based on the x86 pci-nommu implementation.
>
> Signed-off-by: Christoph Hellwig <h...@lst.de>
Thanks for your patch!
> --- a/lib/dma-direct.c
> +++ b/lib/dma-direct.c
> @@ -9,6 +9,24 @@
> #include
> #include
>
> +#define DIRECT_MAPPING_ERROR 0
> +
> +static bool
> +check_addr(struct device *dev, dma_addr_t dma_addr, size_t size,
> + const char *caller)
> +{
> + if (unlikely(dev && !dma_capable(dev, dma_addr, size))) {
> + if (*dev->dma_mask >= DMA_BIT_MASK(32)) {
> + dev_err(dev,
> + "%s: overflow %llx+%zu of device mask %llx\n",
Please use "%pad" to format dma_addr_t ...
> + caller, (long long)dma_addr, size,
... and use _addr.
> + (long long)*dev->dma_mask);
This cast is not needed, as u64 is unsigned long long in kernelspace on
all architectures.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pci: Add and use PCI_GENERIC_SETUP Kconfig entry
On Mon, Jun 26, 2017 at 7:39 AM, kbuild test robot <l...@intel.com> wrote:
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.12-rc6]
> [cannot apply to next-20170623]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Palmer-Dabbelt/pci-Add-and-use-PCI_GENERIC_SETUP-Kconfig-entry/20170626-043558
> config: m68k-allnoconfig (attached as .config)
> compiler: m68k-linux-gcc (GCC) 4.9.0
> reproduce:
> wget
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=m68k
>
> All warnings (new ones prefixed by >>):
>
> warning: (M68K) selects PCI_GENERIC_SETUP which has unmet direct dependencies
> (MMU)
I can't seem to find this dependency of PCI_GENERIC_SETUP on MMU?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tty: add TIOCGPTPEER ioctl
Hi Aleksa,
On Thu, Jun 1, 2017 at 7:38 PM, Aleksa Sarai <asa...@suse.de> wrote:
> --- a/arch/alpha/include/uapi/asm/ioctls.h
> +++ b/arch/alpha/include/uapi/asm/ioctls.h
> @@ -94,6 +94,7 @@
> #define TIOCSRS485 _IOWR('T', 0x2F, struct serial_rs485)
> #define TIOCGPTN _IOR('T',0x30, unsigned int) /* Get Pty Number (of
> pty-mux device) */
> #define TIOCSPTLCK _IOW('T',0x31, int) /* Lock/unlock Pty */
> +#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */
Shouldn't the list of definitions be kept sorted, by hex number?
(everywhere)
> #define TIOCGDEV _IOR('T',0x32, unsigned int) /* Get primary device
> node of /dev/console */
> #define TIOCSIG_IOW('T',0x36, int) /* Generate signal on
> Pty slave */
> #define TIOCVHANGUP0x5437
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: convert to generated system call tables
On Tue, Oct 25, 2016 at 12:28 PM, Arnd Bergmann <a...@arndb.de> wrote:
> On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
>> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
>> > I see your point, but I think there are serious issues with the current
>> > approach as well:
>> >
>> > - a lot of the less common architectures just don't get updated
>> > in time, out of 22 architectures that don't use asm-generic/unistd.h,
>> > only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
>> >
>> > - some architectures that add all syscalls sometimes make a mistake
>> > and forget one, e.g. alpha apparently never added __NR_bpf, but it
>> > did add the later __NR_execveat.
>>
>> __NR_bpf was not forgotten on Alpha. It was not wired up because
>> extra architecture support is needed which has not been implemented.
>>
>> But maybe we should just wire it up to sys_ni_syscall in the meantime
>> so a syscall number is reserved for it, and user space can call it to
>> get -ENOSYS returned.
>
> Ah, I must have misinterpreted the code then. I assumed that the
> bpf syscall always works on all architectures, but that only the
> jit compiler for it required architecture specific code to make it
> more efficient.
>
> The implementation of sys_bfp is compile-time selectable at the moment
> and falls back to sys_no_syscall if CONFIG_BPF_SYSCALL is disabled.
> If it doesn't work on Alpha, maybe that symbol could have a "depends
> on !ALPHA" or "depends on BPF_SUPPORT"?
Yes, BPF should just work (m68k has it).
> sys_seccomp is another one that falls into a similar category, but
> it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> architectures have assigned a syscall number but not set this symbol.
> This one will actually allow you to set strict seccomp mode even
> without the Kconfig symbol, just not allow to set a filter.
Seccomp needs architecture support (m68k doesn't have it).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/16] genrtc removal
Allo Alexandre,
On Mon, May 30, 2016 at 10:32 PM, Alexandre Belloni
<alexandre.bell...@free-electrons.com> wrote:
> On 30/05/2016 at 20:57:48 +0200, Arnd Bergmann wrote :
>> This is the promised resend of the removal of the genrtc driver and some
>> related code, now that we are at a good time to merge this for the coming
>> merge window.
>>
>
> Thanks a lot!
>
> I'm applying the series right now so it sits in linux-next for a while
> before the next merge window.
>
> I would still happily take any acks, Reviewed-by or Tested-by tags.
Looks like Arnd forgot to include these when reposting:
Acked-by: Geert Uytterhoeven <ge...@linux-m68k.org>
For the m68k bits:
Tested-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch V3] lib: GCD: add binary GCD algorithm
On Thu, Apr 28, 2016 at 6:48 PM, George Spelvin <li...@horizon.com> wrote:
> Another few comments:
>
> 1. Would ARCH_HAS_FAST_FFS involve fewer changes than CPU_NO_EFFICIENT_FFS?
No, as you want to _disable_ ARCH_HAS_FAST_FFS / _enable_
CPU_NO_EFFICIENT_FFS as soon as you're enabling support for a
CPU that doesn't support it.
Logical OR is easier in both the Kconfig and C preprocessor languages
than logical NAND.
E.g. in Kconfig, a CPU core not supporting it can just select
CPU_NO_EFFICIENT_FFS.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/16] genrtc removal
On Thu, Apr 28, 2016 at 12:34 AM, Arnd Bergmann <a...@arndb.de> wrote:
> I ended up stuffing the two patch series into one, as they are now
> more dependent on one another. This now thoroughly removes the
> genrtc driver including the asm/rtc.h headers it uses. For all
> architectures that still have a meaningful asm/rtc.h, this goes
> through two stages:
>
> 1) make the rtc-generic implementation independent of asm/rtc.h
> 2) remove the asm/rtc.h header and disallow the gen_rtc driver
>
> As the last step, the driver itself gets removed.
In general, after fixing the minor nit:
Acked-by: Geert Uytterhoeven <ge...@linux-m68k.org>
For the m68k bits:
Tested-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] rtc: m68k: provide rtc_class_ops directly
Hi Arnd,
On Tue, Apr 26, 2016 at 11:52 PM, Arnd Bergmann <a...@arndb.de> wrote:
> The rtc-generic driver provides an architecture specific
> wrapper on top of the generic rtc_class_ops abstraction,
> and m68k has another abstraction on top, which is a bit
> silly.
>
> This changes the m68k rtc-generic device to provide its
> rtc_class_ops directly, to reduce the number of layers
> by one.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
> arch/m68k/kernel/time.c | 24 ++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c
> index 3857737e3958..fe35890feede 100644
> --- a/arch/m68k/kernel/time.c
> +++ b/arch/m68k/kernel/time.c
> @@ -86,7 +86,24 @@ void read_persistent_clock(struct timespec *ts)
> }
> }
>
> -#ifdef CONFIG_ARCH_USES_GETTIMEOFFSET
> +#if defined(CONFIG_ARCH_USES_GETTIMEOFFSET) &&
> defined(CONFIG_RTC_DRV_GENERIC)
s/defined/IS_ENABLED/ for the modular case.
> @@ -95,7 +112,10 @@ static int __init rtc_init(void)
> if (!mach_hwclk)
> return -ENODEV;
>
> - pdev = platform_device_register_simple("rtc-generic", -1, NULL, 0);
> + /* or just call devm_rtc_device_register instead? */
I guess this comment is a bogus leftover? There's no "dev" parameter to
pass to devm_rtc_device_register() here.
> + pdev = platform_device_register_data(NULL, "rtc-generic", -1,
> +_rtc_ops,
> + sizeof(generic_rtc_ops));
> return PTR_ERR_OR_ZERO(pdev);
> }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] sh, rwsem: drop superfluous arch specific implementation
Dag Peter,
On Wed, Apr 6, 2016 at 11:26 AM, Peter Zijlstra <pet...@infradead.org> wrote:
> +Cc maintainers, linux-sh list is very high signal-to-noise as its been
> appropriated for renesas arm parts.
FTR, Renesas ARM parts have moved to linux-renesas-soc.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
