mbox series

[v2,00/13] arch, mm: deprecate DISCONTIGMEM

Message ID 20201101170454.9567-1-rppt@kernel.org (mailing list archive)
Headers show
Series arch, mm: deprecate DISCONTIGMEM | expand

Message

Mike Rapoport Nov. 1, 2020, 5:04 p.m. UTC
From: Mike Rapoport <rppt@linux.ibm.com>

Hi,

It's been a while since DISCONTIGMEM is generally considered deprecated,
but it is still used by four architectures. This set replaces DISCONTIGMEM
with a different way to handle holes in the memory map and marks
DISCONTIGMEM configuration as BROKEN in Kconfigs of these architectures with
the intention to completely remove it in several releases.

While for 64-bit alpha and ia64 the switch to SPARSEMEM is quite obvious
and was a matter of moving some bits around, for smaller 32-bit arc and
m68k SPARSEMEM is not necessarily the best thing to do.

On 32-bit machines SPARSEMEM would require large sections to make section
index fit in the page flags, but larger sections mean that more memory is
wasted for unused memory map.

Besides, pfn_to_page() and page_to_pfn() become less efficient, at least on
arc.

So I've decided to generalize arm's approach for freeing of unused parts of
the memory map with FLATMEM and enable it for both arc and m68k. The
details are in the description of patches 10 (arc) and 13 (m68k).

v2 changes:
- remove additional stale '#ifdef CONFIG_SINGLE_MEMORY_CHUNK' on m68k
- fix bisectability on m68k

v1:
https://lore.kernel.org/lkml/20201027112955.14157-1-rppt@kernel.org

Mike Rapoport (13):
  alpha: switch from DISCONTIGMEM to SPARSEMEM
  ia64: remove custom __early_pfn_to_nid()
  ia64: remove 'ifdef CONFIG_ZONE_DMA32' statements
  ia64: discontig: paging_init(): remove local max_pfn calculation
  ia64: split virtual map initialization out of paging_init()
  ia64: forbid using VIRTUAL_MEM_MAP with FLATMEM
  ia64: make SPARSEMEM default and disable DISCONTIGMEM
  arm: remove CONFIG_ARCH_HAS_HOLES_MEMORYMODEL
  arm, arm64: move free_unused_memmap() to generic mm
  arc: use FLATMEM with freeing of unused memory map instead of
    DISCONTIGMEM
  m68k/mm: make node data and node setup depend on CONFIG_DISCONTIGMEM
  m68k/mm: enable use of generic memory_model.h for !DISCONTIGMEM
  m68k: deprecate DISCONTIGMEM

 Documentation/vm/memory-model.rst   |  3 +-
 arch/Kconfig                        |  3 ++
 arch/alpha/Kconfig                  |  8 +++
 arch/alpha/include/asm/mmzone.h     | 14 +----
 arch/alpha/include/asm/page.h       |  7 +--
 arch/alpha/include/asm/pgtable.h    | 12 ++---
 arch/alpha/include/asm/sparsemem.h  | 18 +++++++
 arch/alpha/kernel/setup.c           |  1 +
 arch/arc/Kconfig                    |  3 +-
 arch/arc/include/asm/page.h         | 20 ++++++--
 arch/arc/mm/init.c                  | 29 ++++++++---
 arch/arm/Kconfig                    | 10 +---
 arch/arm/mach-bcm/Kconfig           |  1 -
 arch/arm/mach-davinci/Kconfig       |  1 -
 arch/arm/mach-exynos/Kconfig        |  1 -
 arch/arm/mach-highbank/Kconfig      |  1 -
 arch/arm/mach-omap2/Kconfig         |  1 -
 arch/arm/mach-s5pv210/Kconfig       |  1 -
 arch/arm/mach-tango/Kconfig         |  1 -
 arch/arm/mm/init.c                  | 78 ----------------------------
 arch/arm64/Kconfig                  |  4 +-
 arch/arm64/mm/init.c                | 68 ------------------------
 arch/ia64/Kconfig                   | 11 ++--
 arch/ia64/include/asm/meminit.h     |  2 -
 arch/ia64/mm/contig.c               | 58 ++++++++++-----------
 arch/ia64/mm/discontig.c            | 44 ++++++++--------
 arch/ia64/mm/init.c                 | 14 -----
 arch/ia64/mm/numa.c                 | 30 -----------
 arch/m68k/Kconfig.cpu               | 31 +++++++++--
 arch/m68k/include/asm/page.h        |  2 +
 arch/m68k/include/asm/page_mm.h     |  7 ++-
 arch/m68k/include/asm/virtconvert.h |  5 --
 arch/m68k/mm/init.c                 |  8 +--
 fs/proc/kcore.c                     |  2 -
 include/linux/mm.h                  |  3 --
 include/linux/mmzone.h              | 42 ---------------
 mm/memblock.c                       | 80 +++++++++++++++++++++++++++++
 mm/mmzone.c                         | 14 -----
 mm/page_alloc.c                     | 16 ++++--
 mm/vmstat.c                         |  4 --
 40 files changed, 270 insertions(+), 388 deletions(-)
 create mode 100644 arch/alpha/include/asm/sparsemem.h

base-commit: 3650b228f83adda7e5ee532e2b90429c03f7b9ec

Comments

John Paul Adrian Glaubitz Nov. 17, 2020, 5:24 a.m. UTC | #1
Hi!

On 11/1/20 6:04 PM, Mike Rapoport wrote:
> It's been a while since DISCONTIGMEM is generally considered deprecated,
> but it is still used by four architectures. This set replaces DISCONTIGMEM
> with a different way to handle holes in the memory map and marks
> DISCONTIGMEM configuration as BROKEN in Kconfigs of these architectures with
> the intention to completely remove it in several releases.
> 
> While for 64-bit alpha and ia64 the switch to SPARSEMEM is quite obvious
> and was a matter of moving some bits around, for smaller 32-bit arc and
> m68k SPARSEMEM is not necessarily the best thing to do.
> 
> On 32-bit machines SPARSEMEM would require large sections to make section
> index fit in the page flags, but larger sections mean that more memory is
> wasted for unused memory map.
> 
> Besides, pfn_to_page() and page_to_pfn() become less efficient, at least on
> arc.
> 
> So I've decided to generalize arm's approach for freeing of unused parts of
> the memory map with FLATMEM and enable it for both arc and m68k. The
> details are in the description of patches 10 (arc) and 13 (m68k).

Apologies for the late reply. Is this still relevant for testing?

I have already successfully tested v1 of the patch set, shall I test v2?

Adrian
Mike Rapoport Nov. 17, 2020, 6:23 a.m. UTC | #2
Hi Adrian,

On Tue, Nov 17, 2020 at 06:24:51AM +0100, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> On 11/1/20 6:04 PM, Mike Rapoport wrote:
> > It's been a while since DISCONTIGMEM is generally considered deprecated,
> > but it is still used by four architectures. This set replaces DISCONTIGMEM
> > with a different way to handle holes in the memory map and marks
> > DISCONTIGMEM configuration as BROKEN in Kconfigs of these architectures with
> > the intention to completely remove it in several releases.
> > 
> > While for 64-bit alpha and ia64 the switch to SPARSEMEM is quite obvious
> > and was a matter of moving some bits around, for smaller 32-bit arc and
> > m68k SPARSEMEM is not necessarily the best thing to do.
> > 
> > On 32-bit machines SPARSEMEM would require large sections to make section
> > index fit in the page flags, but larger sections mean that more memory is
> > wasted for unused memory map.
> > 
> > Besides, pfn_to_page() and page_to_pfn() become less efficient, at least on
> > arc.
> > 
> > So I've decided to generalize arm's approach for freeing of unused parts of
> > the memory map with FLATMEM and enable it for both arc and m68k. The
> > details are in the description of patches 10 (arc) and 13 (m68k).
> 
> Apologies for the late reply. Is this still relevant for testing?
> 
> I have already successfully tested v1 of the patch set, shall I test v2?

There were minor differences only for m68k between the versions. I've
verified them on ARAnyM but if you have a real machine a run there would
be nice.

> Adrian
> 
> -- 
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz@debian.org
> `. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> 
>
John Paul Adrian Glaubitz Nov. 17, 2020, 8:07 a.m. UTC | #3
Hi Mike!

On 11/17/20 7:23 AM, Mike Rapoport wrote:
> There were minor differences only for m68k between the versions. I've
> verified them on ARAnyM but if you have a real machine a run there would
> be nice.

I do have a real machine (Amiga 68060) but it's currently not set up (but it
will be in the near future). So I'm not sure if I can test the change within
a short time frame.

I will certainly report back when I run into issues on real hardware.

Thanks,
Adrian
Mike Rapoport Nov. 17, 2020, 8:14 a.m. UTC | #4
Hi Adrian,

On Tue, Nov 17, 2020 at 09:07:25AM +0100, John Paul Adrian Glaubitz wrote:
> Hi Mike!
> 
> On 11/17/20 7:23 AM, Mike Rapoport wrote:
> > There were minor differences only for m68k between the versions. I've
> > verified them on ARAnyM but if you have a real machine a run there would
> > be nice.
> 
> I do have a real machine (Amiga 68060) but it's currently not set up (but it
> will be in the near future). So I'm not sure if I can test the change within
> a short time frame.
>
> I will certainly report back when I run into issues on real hardware.

I hope there won't be any :)
John Paul Adrian Glaubitz Dec. 1, 2020, 9:10 a.m. UTC | #5
Hi Mike!

On 11/17/20 7:23 AM, Mike Rapoport wrote:
>> Apologies for the late reply. Is this still relevant for testing?
>>
>> I have already successfully tested v1 of the patch set, shall I test v2?
> 
> There were minor differences only for m68k between the versions. I've
> verified them on ARAnyM but if you have a real machine a run there would
> be nice.

I have just built a fresh kernel from the tip of Linus' tree and it boots
fine on my RX-2600:

root@glendronach:~# uname -a
Linux glendronach 5.10.0-rc6 #6 SMP Tue Dec 1 04:52:49 CET 2020 ia64 GNU/Linux
root@glendronach:~#

No issues observed so far. Looking at the git log, it seems these changes haven't
been merged for 5.10 yet. I assume they will be coming with 5.11?

Adrian
Mike Rapoport Dec. 1, 2020, 10:29 a.m. UTC | #6
Hi Adrian,

On Tue, Dec 01, 2020 at 10:10:56AM +0100, John Paul Adrian Glaubitz wrote:
> Hi Mike!
> 
> On 11/17/20 7:23 AM, Mike Rapoport wrote:
> >> Apologies for the late reply. Is this still relevant for testing?
> >>
> >> I have already successfully tested v1 of the patch set, shall I test v2?
> > 
> > There were minor differences only for m68k between the versions. I've
> > verified them on ARAnyM but if you have a real machine a run there would
> > be nice.
> 
> I have just built a fresh kernel from the tip of Linus' tree and it boots
> fine on my RX-2600:
> 
> root@glendronach:~# uname -a
> Linux glendronach 5.10.0-rc6 #6 SMP Tue Dec 1 04:52:49 CET 2020 ia64 GNU/Linux
> root@glendronach:~#
> 
> No issues observed so far. Looking at the git log, it seems these changes haven't
> been merged for 5.10 yet. I assume they will be coming with 5.11?

These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/
with a mirror at https://github.com/hnaz/linux-mm)

I beleive they will be coming in 5.11.

> Adrian
> 
> -- 
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz@debian.org
> `. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> 
>
John Paul Adrian Glaubitz Dec. 1, 2020, 11:35 a.m. UTC | #7
Hi Mike!

On 12/1/20 11:29 AM, Mike Rapoport wrote: 
> These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/
> with a mirror at https://github.com/hnaz/linux-mm)
> 
> I beleive they will be coming in 5.11.

Just pulled from that tree and gave it a try, it actually fails to build:

  LDS     arch/ia64/kernel/vmlinux.lds
  AS      arch/ia64/kernel/entry.o
arch/ia64/kernel/entry.S: Assembler messages:
arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be a general register
arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by instruction
arch/ia64/kernel/entry.S:848: Error: Operand 2 of `and' should be a general register
arch/ia64/kernel/entry.S:848: Error: qualifying predicate not followed by instruction
  GEN     usr/initramfs_data.cpio
make[1]: *** [scripts/Makefile.build:364: arch/ia64/kernel/entry.o] Error 1
make: *** [Makefile:1797: arch/ia64/kernel] Error 2
make: *** Waiting for unfinished jobs....
  CC      init/do_mounts_initrd.o
  SHIPPED usr/initramfs_inc_data
  AS      usr/initramfs_data.o

Adrian
Mike Rapoport Dec. 1, 2020, 12:10 p.m. UTC | #8
On Tue, Dec 01, 2020 at 12:35:09PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Mike!
> 
> On 12/1/20 11:29 AM, Mike Rapoport wrote: 
> > These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/
> > with a mirror at https://github.com/hnaz/linux-mm)
> > 
> > I beleive they will be coming in 5.11.
> 
> Just pulled from that tree and gave it a try, it actually fails to build:
> 
>   LDS     arch/ia64/kernel/vmlinux.lds
>   AS      arch/ia64/kernel/entry.o
> arch/ia64/kernel/entry.S: Assembler messages:
> arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be a general register
> arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by instruction
> arch/ia64/kernel/entry.S:848: Error: Operand 2 of `and' should be a general register
> arch/ia64/kernel/entry.S:848: Error: qualifying predicate not followed by instruction
>   GEN     usr/initramfs_data.cpio
> make[1]: *** [scripts/Makefile.build:364: arch/ia64/kernel/entry.o] Error 1
> make: *** [Makefile:1797: arch/ia64/kernel] Error 2
> make: *** Waiting for unfinished jobs....
>   CC      init/do_mounts_initrd.o
>   SHIPPED usr/initramfs_inc_data
>   AS      usr/initramfs_data.o

Hmm, it was buidling fine with v5.10-rc2-mmotm-2020-11-07-21-40.
I'll try to see what could cause this.

Do you build with defconfig or do you use a custom config?

> Adrian
> 
> -- 
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz@debian.org
> `. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> 
>
Jens Axboe Dec. 1, 2020, 3:03 p.m. UTC | #9
On 12/1/20 6:56 AM, Mike Rapoport wrote:
> (added Jens)
> 
> On Tue, Dec 01, 2020 at 01:16:05PM +0100, John Paul Adrian Glaubitz wrote:
>> Hi Mike!
>>
>> On 12/1/20 1:10 PM, Mike Rapoport wrote:
>>> On Tue, Dec 01, 2020 at 12:35:09PM +0100, John Paul Adrian Glaubitz wrote:
>>>> Hi Mike!
>>>>
>>>> On 12/1/20 11:29 AM, Mike Rapoport wrote: 
>>>>> These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/
>>>>> with a mirror at https://github.com/hnaz/linux-mm)
>>>>>
>>>>> I beleive they will be coming in 5.11.
>>>>
>>>> Just pulled from that tree and gave it a try, it actually fails to build:
>>>>
>>>>   LDS     arch/ia64/kernel/vmlinux.lds
>>>>   AS      arch/ia64/kernel/entry.o
>>>> arch/ia64/kernel/entry.S: Assembler messages:
>>>> arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be a general register
>>>> arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by instruction
>>>> arch/ia64/kernel/entry.S:848: Error: Operand 2 of `and' should be a general register
>>>> arch/ia64/kernel/entry.S:848: Error: qualifying predicate not followed by instruction
>>>>   GEN     usr/initramfs_data.cpio
>>>> make[1]: *** [scripts/Makefile.build:364: arch/ia64/kernel/entry.o] Error 1
>>>> make: *** [Makefile:1797: arch/ia64/kernel] Error 2
>>>> make: *** Waiting for unfinished jobs....
>>>>   CC      init/do_mounts_initrd.o
>>>>   SHIPPED usr/initramfs_inc_data
>>>>   AS      usr/initramfs_data.o
>>>
>>> Hmm, it was buidling fine with v5.10-rc2-mmotm-2020-11-07-21-40.
>>> I'll try to see what could cause this.
>>>
>>> Do you build with defconfig or do you use a custom config?
>>
>> That's with "localmodconfig", see attached configuration file.
> 
> Thanks.
> It seems that the recent addition of TIF_NOTIFY_SIGNAL to ia64 in
> linux-next caused the issue. Can you please try the below patch?

That's a lot of typos in that patch... I wonder why the buildbot hasn't
complained about this. Thanks for fixing this up! I'm going to fold this
into the original to avoid the breakage.
John Paul Adrian Glaubitz Dec. 1, 2020, 3:07 p.m. UTC | #10
On 12/1/20 2:56 PM, Mike Rapoport wrote:
> (added Jens)
> 
> On Tue, Dec 01, 2020 at 01:16:05PM +0100, John Paul Adrian Glaubitz wrote:
>> Hi Mike!
>>
>> On 12/1/20 1:10 PM, Mike Rapoport wrote:
>>> On Tue, Dec 01, 2020 at 12:35:09PM +0100, John Paul Adrian Glaubitz wrote:
>>>> Hi Mike!
>>>>
>>>> On 12/1/20 11:29 AM, Mike Rapoport wrote: 
>>>>> These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/
>>>>> with a mirror at https://github.com/hnaz/linux-mm)
>>>>>
>>>>> I beleive they will be coming in 5.11.
>>>>
>>>> Just pulled from that tree and gave it a try, it actually fails to build:
>>>>
>>>>   LDS     arch/ia64/kernel/vmlinux.lds
>>>>   AS      arch/ia64/kernel/entry.o
>>>> arch/ia64/kernel/entry.S: Assembler messages:
>>>> arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be a general register
>>>> arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by instruction
>>>> arch/ia64/kernel/entry.S:848: Error: Operand 2 of `and' should be a general register
>>>> arch/ia64/kernel/entry.S:848: Error: qualifying predicate not followed by instruction
>>>>   GEN     usr/initramfs_data.cpio
>>>> make[1]: *** [scripts/Makefile.build:364: arch/ia64/kernel/entry.o] Error 1
>>>> make: *** [Makefile:1797: arch/ia64/kernel] Error 2
>>>> make: *** Waiting for unfinished jobs....
>>>>   CC      init/do_mounts_initrd.o
>>>>   SHIPPED usr/initramfs_inc_data
>>>>   AS      usr/initramfs_data.o
>>>
>>> Hmm, it was buidling fine with v5.10-rc2-mmotm-2020-11-07-21-40.
>>> I'll try to see what could cause this.
>>>
>>> Do you build with defconfig or do you use a custom config?
>>
>> That's with "localmodconfig", see attached configuration file.
> 
> Thanks.
> It seems that the recent addition of TIF_NOTIFY_SIGNAL to ia64 in
> linux-next caused the issue. Can you please try the below patch?
> 
> From c4d06cf1c2938e6b2302e7ed0be95c3401181ebb Mon Sep 17 00:00:00 2001
> From: Mike Rapoport <rppt@linux.ibm.com>
> Date: Tue, 1 Dec 2020 15:40:28 +0200
> Subject: [PATCH] ia64: fix TIF_NOTIFY_SIGNAL implementation
> 
> * Replace wrong spelling of TIF_SIGNAL_NOTIFY with the correct
>   TIF_NOTIFY_SIGNAL
> * Remove mistyped plural in test_thread_flag() call in
>   process::do_notify_resume_user()
> * Use number 5 for TIF_NOTIFY_SIGNAL as 7 is too big and assembler is not
>   happy:
> 
>   AS      arch/ia64/kernel/entry.o
> arch/ia64/kernel/entry.S: Assembler messages:
> arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be an 8-bit integer (-128-127)
> arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by instruction
> 
> Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Fixes: bbb026da151c ("ia64: add support for TIF_NOTIFY_SIGNAL")
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> 
> The Fixes tag is based on the commit in next-20201201, I'm not 100% sure
> it is stable
> 
>  arch/ia64/include/asm/thread_info.h | 4 ++--
>  arch/ia64/kernel/process.c          | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/ia64/include/asm/thread_info.h b/arch/ia64/include/asm/thread_info.h
> index 759d7d68a5f2..51d20cb37706 100644
> --- a/arch/ia64/include/asm/thread_info.h
> +++ b/arch/ia64/include/asm/thread_info.h
> @@ -103,8 +103,8 @@ struct thread_info {
>  #define TIF_SYSCALL_TRACE	2	/* syscall trace active */
>  #define TIF_SYSCALL_AUDIT	3	/* syscall auditing active */
>  #define TIF_SINGLESTEP		4	/* restore singlestep on return to user mode */
> +#define TIF_NOTIFY_SIGNAL	5	/* signal notification exist */
>  #define TIF_NOTIFY_RESUME	6	/* resumption notification requested */
> -#define TIF_NOTIFY_SIGNAL	7	/* signal notification exist */
>  #define TIF_MEMDIE		17	/* is terminating due to OOM killer */
>  #define TIF_MCA_INIT		18	/* this task is processing MCA or INIT */
>  #define TIF_DB_DISABLED		19	/* debug trap disabled for fsyscall */
> @@ -116,7 +116,7 @@ struct thread_info {
>  #define _TIF_SINGLESTEP		(1 << TIF_SINGLESTEP)
>  #define _TIF_SYSCALL_TRACEAUDIT	(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SINGLESTEP)
>  #define _TIF_NOTIFY_RESUME	(1 << TIF_NOTIFY_RESUME)
> -#define _TIF_SIGNAL_NOTIFY	(1 << TIF_SIGNAL_NOTIFY)
> +#define _TIF_NOTIFY_SIGNAL	(1 << TIF_NOTIFY_SIGNAL)
>  #define _TIF_SIGPENDING		(1 << TIF_SIGPENDING)
>  #define _TIF_NEED_RESCHED	(1 << TIF_NEED_RESCHED)
>  #define _TIF_MCA_INIT		(1 << TIF_MCA_INIT)
> diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
> index 468525fc64e0..ee394abcc03e 100644
> --- a/arch/ia64/kernel/process.c
> +++ b/arch/ia64/kernel/process.c
> @@ -172,7 +172,7 @@ do_notify_resume_user(sigset_t *unused, struct sigscratch *scr, long in_syscall)
>  
>  	/* deal with pending signal delivery */
>  	if (test_thread_flag(TIF_SIGPENDING) ||
> -	    test_thread_flags(TIF_NOTIFY_SIGNAL)) {
> +	    test_thread_flag(TIF_NOTIFY_SIGNAL)) {
>  		local_irq_enable();	/* force interrupt enable */
>  		ia64_do_signal(scr, in_syscall);
>  	}
> 

This fixes the issue for me.

Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Adrian
Geert Uytterhoeven Dec. 1, 2020, 3:33 p.m. UTC | #11
Hi Jens,

On Tue, Dec 1, 2020 at 4:03 PM Jens Axboe <axboe@kernel.dk> wrote:
> On 12/1/20 6:56 AM, Mike Rapoport wrote:
> > (added Jens)
> >
> > On Tue, Dec 01, 2020 at 01:16:05PM +0100, John Paul Adrian Glaubitz wrote:
> >> Hi Mike!
> >>
> >> On 12/1/20 1:10 PM, Mike Rapoport wrote:
> >>> On Tue, Dec 01, 2020 at 12:35:09PM +0100, John Paul Adrian Glaubitz wrote:
> >>>> Hi Mike!
> >>>>
> >>>> On 12/1/20 11:29 AM, Mike Rapoport wrote:
> >>>>> These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/
> >>>>> with a mirror at https://github.com/hnaz/linux-mm)
> >>>>>
> >>>>> I beleive they will be coming in 5.11.
> >>>>
> >>>> Just pulled from that tree and gave it a try, it actually fails to build:
> >>>>
> >>>>   LDS     arch/ia64/kernel/vmlinux.lds
> >>>>   AS      arch/ia64/kernel/entry.o
> >>>> arch/ia64/kernel/entry.S: Assembler messages:
> >>>> arch/ia64/kernel/entry.S:710: Error: Operand 2 of `and' should be a general register
> >>>> arch/ia64/kernel/entry.S:710: Error: qualifying predicate not followed by instruction
> >>>> arch/ia64/kernel/entry.S:848: Error: Operand 2 of `and' should be a general register
> >>>> arch/ia64/kernel/entry.S:848: Error: qualifying predicate not followed by instruction
> >>>>   GEN     usr/initramfs_data.cpio
> >>>> make[1]: *** [scripts/Makefile.build:364: arch/ia64/kernel/entry.o] Error 1
> >>>> make: *** [Makefile:1797: arch/ia64/kernel] Error 2
> >>>> make: *** Waiting for unfinished jobs....
> >>>>   CC      init/do_mounts_initrd.o
> >>>>   SHIPPED usr/initramfs_inc_data
> >>>>   AS      usr/initramfs_data.o
> >>>
> >>> Hmm, it was buidling fine with v5.10-rc2-mmotm-2020-11-07-21-40.
> >>> I'll try to see what could cause this.
> >>>
> >>> Do you build with defconfig or do you use a custom config?
> >>
> >> That's with "localmodconfig", see attached configuration file.
> >
> > Thanks.
> > It seems that the recent addition of TIF_NOTIFY_SIGNAL to ia64 in
> > linux-next caused the issue. Can you please try the below patch?
>
> That's a lot of typos in that patch... I wonder why the buildbot hasn't
> complained about this. Thanks for fixing this up! I'm going to fold this
> into the original to avoid the breakage.

Does lkp@intel.com do ia64 builds? Yes, it builds zx1_defconfig.

Kisskb doesn't seem to build zx1_defconfig, but generic_defconfig.
http://kisskb.ellerman.id.au/kisskb/target/101883/ shows this has been broken
since Oct 30.  Perhaps kisskb build failures are not emailed to the ia64
maintainers, or not acted upon?
(I do receive kisskb build failure emails for m68k)

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
John Paul Adrian Glaubitz Dec. 1, 2020, 7:55 p.m. UTC | #12
Hi Mike!

On 12/1/20 4:07 PM, John Paul Adrian Glaubitz wrote:
> This fixes the issue for me.
> 
> Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

I just booted the kernel from the linux-mm branch and I can't get the hpsa driver
to work anymore. Even if I compile it into the kernel, the driver is no longer
loaded and hence I can't access the disks.

Any idea what could be wrong?

Adrian
Mike Rapoport Dec. 2, 2020, 7:14 a.m. UTC | #13
Hi Adrian,

On Tue, Dec 01, 2020 at 08:55:37PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Mike!
> 
> On 12/1/20 4:07 PM, John Paul Adrian Glaubitz wrote:
> > This fixes the issue for me.
> > 
> > Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> 
> I just booted the kernel from the linux-mm branch and I can't get the hpsa driver
> to work anymore. Even if I compile it into the kernel, the driver is no longer
> loaded and hence I can't access the disks.
> 
> Any idea what could be wrong?

I know nearly nothing about SCSI, I can only suggest to enable all the
debug options available and see if anything shows up :)

> Adrian
> 
> -- 
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz@debian.org
> `. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> 
>
Christoph Hellwig Dec. 2, 2020, 8:43 a.m. UTC | #14
On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote:
> > That's a lot of typos in that patch... I wonder why the buildbot hasn't
> > complained about this. Thanks for fixing this up! I'm going to fold this
> > into the original to avoid the breakage.
> 
> Does lkp@intel.com do ia64 builds? Yes, it builds zx1_defconfig.

I've never got results.  Which is annoying, as debian doesn't ship an
ia64 cross toolchain either, and I can't find any pre-built one that
works for me.
John Paul Adrian Glaubitz Dec. 2, 2020, 8:45 a.m. UTC | #15
Hi Christoph!

On 12/2/20 9:43 AM, Christoph Hellwig wrote:
> On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote:
>>> That's a lot of typos in that patch... I wonder why the buildbot hasn't
>>> complained about this. Thanks for fixing this up! I'm going to fold this
>>> into the original to avoid the breakage.
>>
>> Does lkp@intel.com do ia64 builds? Yes, it builds zx1_defconfig.
> 
> I've never got results.  Which is annoying, as debian doesn't ship an
> ia64 cross toolchain either, and I can't find any pre-built one that
> works for me.

The ia64 toolchain available from kernel.org works for me for cross-building
a kernel that boots on my RX2600.

It's just not a fully-fledged toolchain due to the limitations with libunwind.

Adrian
Mike Rapoport Dec. 2, 2020, 8:46 a.m. UTC | #16
On Wed, Dec 02, 2020 at 08:43:26AM +0000, Christoph Hellwig wrote:
> On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote:
> > > That's a lot of typos in that patch... I wonder why the buildbot hasn't
> > > complained about this. Thanks for fixing this up! I'm going to fold this
> > > into the original to avoid the breakage.
> > 
> > Does lkp@intel.com do ia64 builds? Yes, it builds zx1_defconfig.
> 
> I've never got results.  Which is annoying, as debian doesn't ship an
> ia64 cross toolchain either, and I can't find any pre-built one that
> works for me.

Arnd publishes a bunch of cross compilers here:

https://mirrors.edge.kernel.org/pub/tools/crosstool/
Christoph Hellwig Dec. 2, 2020, 8:46 a.m. UTC | #17
On Wed, Dec 02, 2020 at 09:45:24AM +0100, John Paul Adrian Glaubitz wrote:
> > I've never got results.  Which is annoying, as debian doesn't ship an
> > ia64 cross toolchain either, and I can't find any pre-built one that
> > works for me.
> 
> The ia64 toolchain available from kernel.org works for me for cross-building
> a kernel that boots on my RX2600.
> 
> It's just not a fully-fledged toolchain due to the limitations with libunwind.

Actually, you are right, I did manage to finally get that working a
while ago.  I think openrisc is the one where I failed to get anything
to work at all now that I think of it.
Christoph Hellwig Dec. 2, 2020, 8:47 a.m. UTC | #18
On Wed, Dec 02, 2020 at 10:46:28AM +0200, Mike Rapoport wrote:
> On Wed, Dec 02, 2020 at 08:43:26AM +0000, Christoph Hellwig wrote:
> > On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote:
> > > > That's a lot of typos in that patch... I wonder why the buildbot hasn't
> > > > complained about this. Thanks for fixing this up! I'm going to fold this
> > > > into the original to avoid the breakage.
> > > 
> > > Does lkp@intel.com do ia64 builds? Yes, it builds zx1_defconfig.
> > 
> > I've never got results.  Which is annoying, as debian doesn't ship an
> > ia64 cross toolchain either, and I can't find any pre-built one that
> > works for me.
> 
> Arnd publishes a bunch of cross compilers here:
> 
> https://mirrors.edge.kernel.org/pub/tools/crosstool/

This is my source for those architectures where debian doesn't ship
cross compilers.  I'm stuck with mostly gcc 7/8 so I'm glad to see there
have been some major updates.