public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
* [GIT PULL] more s390 updates for 6.6 merge window
@ 2023-09-07 11:27 Heiko Carstens
  2023-09-07 18:02 ` Linus Torvalds
  2023-09-07 18:03 ` pr-tracker-bot
  0 siblings, 2 replies; 4+ messages in thread
From: Heiko Carstens @ 2023-09-07 11:27 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Vasily Gorbik, Alexander Gordeev, linux-s390, linux-kernel

Hi Linus,

please pull a couple of additional s390 patches for the 6.6 merge
window.

Thanks,
Heiko

The following changes since commit e5b7ca09e9aa4d483ab84c5f2ba88f0cc7c66540:

  Merge tag 's390-6.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux (2023-08-28 17:22:39 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-6.6-2

for you to fetch changes up to 06fc3b0d2251b550f530a1c42e0f9c5d022476dd:

  s390/vmem: do not silently ignore mapping limit (2023-09-05 20:12:52 +0200)

----------------------------------------------------------------
more s390 updates for 6.6 merge window

- Couple of virtual vs physical address confusion fixes

- Rework locking in dcssblk driver to address a lockdep warning

- Remove support for "noexec" kernel command line option since there
  is no use case where it would make sense

- Simplify kernel mapping setup and get rid of quite a bit of code

- Add architecture specific __set_memory_yy() functions which allow to
  modify kernel mappings. Unlike the set_memory_xx() variants they
  take void pointer start and end parameters, which allows to use them
  without the usual casts, and also to use them on areas larger than
  8TB.
  Note that the set_memory_xx() family comes with an int num_pages
  parameter which overflows with 8TB. This could be addressed by
  changing the num_pages parameter to unsigned long, however requires
  to change all architectures, since the module code expects an int
  parameter (see module_set_memory()).
  This was indeed an issue since for debug_pagealloc() we call
  set_memory_4k() on the whole identity mapping. Therefore address
  this for now with the __set_memory_yy() variant, and address common
  code later

- Use dev_set_name() and also fix memory leak in zcrypt driver error
  handling

- Remove unused lsi_mask from airq_struct

- Add warning for invalid kernel mapping requests

----------------------------------------------------------------
Alexander Gordeev (3):
      s390/vmem: fix virtual vs physical address confusion
      s390/mm: fix MAX_DMA_ADDRESS physical vs virtual confusion
      s390/vmem: do not silently ignore mapping limit

Andy Shevchenko (2):
      s390/zcrypt: don't leak memory if dev_set_name() fails
      s390/zcrypt: utilize dev_set_name() ability to use a formatted string

Benjamin Block (1):
      s390/airq: remove lsi_mask from airq_struct

Gerald Schaefer (2):
      s390/monreader: fix virtual vs physical address confusion
      s390/dcssblk: fix lockdep warning

Heiko Carstens (7):
      s390: remove "noexec" option
      s390/mm: simplify kernel mapping setup
      s390/amode31: change type of __samode31, __eamode31, etc
      s390/mm: improve description of mapping permissions of prefix pages
      s390/set_memory: generate all set_memory() functions
      s390/set_memory: add __set_memory() variant
      s390/mm: use __set_memory() variants where useful

 arch/s390/boot/ipl_parm.c          |   7 --
 arch/s390/boot/startup.c           |   4 +-
 arch/s390/boot/vmem.c              |  12 ++-
 arch/s390/include/asm/airq.h       |   1 -
 arch/s390/include/asm/dma.h        |   2 +-
 arch/s390/include/asm/sections.h   |   4 +-
 arch/s390/include/asm/set_memory.h |  64 ++++++++--------
 arch/s390/include/asm/setup.h      |   1 -
 arch/s390/kernel/early.c           |   5 +-
 arch/s390/kernel/machine_kexec.c   |   4 +-
 arch/s390/kernel/setup.c           |  17 ++---
 arch/s390/kvm/interrupt.c          |   3 +-
 arch/s390/mm/dump_pagetables.c     |   4 +-
 arch/s390/mm/init.c                |   4 +-
 arch/s390/mm/pageattr.c            |   2 +-
 arch/s390/mm/vmem.c                | 148 ++++++-------------------------------
 drivers/s390/block/dcssblk.c       |  13 ++--
 drivers/s390/char/monreader.c      |  12 ++-
 drivers/s390/cio/airq.c            |   4 +-
 drivers/s390/crypto/zcrypt_api.c   |  11 +--
 drivers/s390/virtio/virtio_ccw.c   |   1 -
 21 files changed, 99 insertions(+), 224 deletions(-)

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [GIT PULL] more s390 updates for 6.6 merge window
  2023-09-07 11:27 [GIT PULL] more s390 updates for 6.6 merge window Heiko Carstens
@ 2023-09-07 18:02 ` Linus Torvalds
  2023-09-26  7:28   ` Christoph Hellwig
  2023-09-07 18:03 ` pr-tracker-bot
  1 sibling, 1 reply; 4+ messages in thread
From: Linus Torvalds @ 2023-09-07 18:02 UTC (permalink / raw)
  To: Heiko Carstens; +Cc: Vasily Gorbik, Alexander Gordeev, linux-s390, linux-kernel

On Thu, 7 Sept 2023 at 04:27, Heiko Carstens <hca@linux.ibm.com> wrote:
>
>   Note that the set_memory_xx() family comes with an int num_pages
>   parameter which overflows with 8TB. This could be addressed by
>   changing the num_pages parameter to unsigned long, however requires
>   to change all architectures, since the module code expects an int
>   parameter (see module_set_memory()).

Bah. We should just do this. Change the 'start' to a pointer, and
change the page count to 'unsigned long'.

Changing module_set_memory() to take the right kind of function
pointer looks trivial too.

I'm not even sure why we did that "unsigned long addr" thing, but I
assume it is because of our (very very _very_ old) historical
get_free_pages() model.

We should probably change get_free_pages() too, but that literally
goes back to linux-0.01. It's horrendously bad, but it's _very_
traditional, and it comes from the VM code historically using bitops
on the page pointers.

           Linus

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [GIT PULL] more s390 updates for 6.6 merge window
  2023-09-07 11:27 [GIT PULL] more s390 updates for 6.6 merge window Heiko Carstens
  2023-09-07 18:02 ` Linus Torvalds
@ 2023-09-07 18:03 ` pr-tracker-bot
  1 sibling, 0 replies; 4+ messages in thread
From: pr-tracker-bot @ 2023-09-07 18:03 UTC (permalink / raw)
  To: Heiko Carstens
  Cc: Linus Torvalds, Vasily Gorbik, Alexander Gordeev, linux-s390,
	linux-kernel

The pull request you sent on Thu, 7 Sep 2023 13:27:43 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-6.6-2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4a0fc73da97efd23a383ca839e6fe86410268f6b

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [GIT PULL] more s390 updates for 6.6 merge window
  2023-09-07 18:02 ` Linus Torvalds
@ 2023-09-26  7:28   ` Christoph Hellwig
  0 siblings, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2023-09-26  7:28 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Heiko Carstens, Vasily Gorbik, Alexander Gordeev, linux-s390,
	linux-kernel

On Thu, Sep 07, 2023 at 11:02:23AM -0700, Linus Torvalds wrote:
> On Thu, 7 Sept 2023 at 04:27, Heiko Carstens <hca@linux.ibm.com> wrote:
> >
> >   Note that the set_memory_xx() family comes with an int num_pages
> >   parameter which overflows with 8TB. This could be addressed by
> >   changing the num_pages parameter to unsigned long, however requires
> >   to change all architectures, since the module code expects an int
> >   parameter (see module_set_memory()).
> 
> Bah. We should just do this. Change the 'start' to a pointer, and
> change the page count to 'unsigned long'.
> 
> Changing module_set_memory() to take the right kind of function
> pointer looks trivial too.
> 
> I'm not even sure why we did that "unsigned long addr" thing, but I
> assume it is because of our (very very _very_ old) historical
> get_free_pages() model.
> 
> We should probably change get_free_pages() too, but that literally
> goes back to linux-0.01. It's horrendously bad, but it's _very_
> traditional, and it comes from the VM code historically using bitops
> on the page pointers.

Yes, please.  And maybe pick a better name for the void * returning
version.  kmalloc_pages/kfree_pages?  or is that to close to
kmalloc/kfree?


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-09-26  7:28 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-09-07 11:27 [GIT PULL] more s390 updates for 6.6 merge window Heiko Carstens
2023-09-07 18:02 ` Linus Torvalds
2023-09-26  7:28   ` Christoph Hellwig
2023-09-07 18:03 ` pr-tracker-bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox