[GIT PULL] s390 patches for the 4.17 merge window #1

[GIT PULL] s390 patches for the 4.17 merge window #1

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

	git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus

to receive the following updates:

 * Improvements for the spectre defense:
   - The spectre related code is consolidated to a single file nospec-branch.c
   - Automatic enable/disable for the spectre v2 defenses (expoline vs. nobp)
   - Syslog messages for specve v2 are added
   - Enable CONFIG_GENERIC_CPU_VULNERABILITIES and define the attribute
     functions for spectre v1 and v2

 * Add helper macros for assembler alternatives and use them to shorten
   the code in entry.S.

 * Add support for persistent configuration data via the SCLP Store Data
   interface. The H/W interface requires a page table that uses 4K pages
   only, the code to setup such an address space is added as well.

 * Enable virtio GPU emulation in QEMU. To do this the depends statements
   for a few common Kconfig options are modified.

 * Add support for format-3 channel path descriptors and add a binary
   sysfs interface to export the associated utility strings.

 * Add a sysfs attribute to control the IFCC handling in case of constant
   channel errors.

 * The vfio-ccw changes from Cornelia.

 * Bug fixes and cleanups.

There is a trivial merge conflict in drivers/video/console/Kconfig.

Christian Borntraeger (2):
      s390/sclp_tty: enable line mode tty even if there is an ascii console
      s390/defkeymap: fix global init to zero

Claudio Imbrenda (4):
      s390/sclp: clean up, use sccb_mask_t where appropriate
      s390/sclp: generic event mask accessors
      s390/sclp: 32 bit event mask compatibility mode
      s390/sclp: 64 bit event mask

Cornelia Huck (3):
      s390: fix comment for scsw_cmd_is_valid_sctl
      vfio-ccw: update documentation
      vfio-ccw: fence off transport mode

Farhan Ali (3):
      Kconfig : Remove HAS_IOMEM dependency for Graphics support
      s390/char : Rename EBCDIC keymap variables
      s390/setup : enable display support for KVM guest

Harald Freudenberger (1):
      s390/crypto: Fix kernel crash on aes_s390 module remove.

Heiko Carstens (1):
      s390/mm: provide base_asce_alloc() / base_asce_free() helper functions

Julian Wiedmann (6):
      s390: fix typo in irb description
      s390/qdio: simplify math in get_*_buffer_frontier()
      s390/qdio: don't merge ERROR output buffers
      s390/qdio: restrict buffer merging to eligible devices
      s390/qdio: don't retry EQBS after CCQ 96
      s390/qdio: split up CCQ handling for EQBS / SQBS

Martin Schwidefsky (8):
      s390: move nobp parameter functions to nospec-branch.c
      s390: add automatic detection of the spectre defense
      s390: report spectre mitigation via syslog
      s390: add sysfs attributes for spectre
      s390: add assembler macros for CPU alternatives
      s390/entry.S: use assembler alternatives
      s390/lpp: use assembler alternatives for the LPP instruction
      s390/kvm: improve stack frame constants in entry.S

Peter Oberparleiter (1):
      s390/sclp: Add support for Store Data SCLP interface

Sebastian Ott (4):
      s390/cio: fix unbind of io_subchannel_driver
      s390/cio: rename struct channel_path_desc
      s390/chsc: query utility strings via fmt3 channel path descriptor
      s390/cio: add util_string sysfs attribute

Stefan Haberland (3):
      s390/dasd: configurable IFCC handling
      s390/dasd: remove unneeded sanity check
      s390/dasd: set timestamps unconditionally

Vasily Gorbik (4):
      s390/decompressor: discard __ex_table section
      s390: unify linker symbols usage
      s390: set bzImage as default image for packaging
      s390/decompressor: trim uncompressed image head during the build

 Documentation/s390/vfio-ccw.txt         |  79 +++--
 arch/s390/Kconfig                       |   3 +-
 arch/s390/Makefile                      |   8 +-
 arch/s390/boot/compressed/Makefile      |  16 +-
 arch/s390/boot/compressed/head.S        |   6 +-
 arch/s390/boot/compressed/misc.c        |  10 +-
 arch/s390/boot/compressed/vmlinux.lds.S |   1 +
 arch/s390/crypto/aes_s390.c             |   5 +-
 arch/s390/include/asm/alternative-asm.h | 108 ++++++
 arch/s390/include/asm/ccwdev.h          |   2 +-
 arch/s390/include/asm/chpid.h           |   2 +-
 arch/s390/include/asm/cio.h             |   2 +-
 arch/s390/include/asm/cpu_mf.h          |   4 +-
 arch/s390/include/asm/css_chars.h       |   6 +-
 arch/s390/include/asm/nospec-branch.h   |   6 +-
 arch/s390/include/asm/pgalloc.h         |   3 +
 arch/s390/include/asm/scsw.h            |   4 +-
 arch/s390/include/asm/setup.h           |   2 -
 arch/s390/include/uapi/asm/dasd.h       |  38 ++-
 arch/s390/kernel/Makefile               |   4 +-
 arch/s390/kernel/alternative.c          |  24 +-
 arch/s390/kernel/asm-offsets.c          |   1 +
 arch/s390/kernel/early.c                |   4 +-
 arch/s390/kernel/entry.S                |  96 ++----
 arch/s390/kernel/module.c               |  11 +-
 arch/s390/kernel/nospec-branch.c        | 120 +++++--
 arch/s390/kernel/setup.c                |  22 +-
 arch/s390/kernel/suspend.c              |   4 +-
 arch/s390/mm/dump_pagetables.c          |   4 +-
 arch/s390/mm/pgalloc.c                  | 293 +++++++++++++++-
 drivers/s390/block/dasd.c               |   9 +-
 drivers/s390/block/dasd_3990_erp.c      |  17 +-
 drivers/s390/block/dasd_devmap.c        |  43 ++-
 drivers/s390/block/dasd_eckd.c          |  27 +-
 drivers/s390/char/Makefile              |   2 +-
 drivers/s390/char/defkeymap.c           |  66 ++--
 drivers/s390/char/keyboard.c            |  32 +-
 drivers/s390/char/keyboard.h            |  11 +
 drivers/s390/char/sclp.c                |  58 ++--
 drivers/s390/char/sclp.h                |  61 +++-
 drivers/s390/char/sclp_early.c          |   2 +-
 drivers/s390/char/sclp_early_core.c     |  38 ++-
 drivers/s390/char/sclp_sd.c             | 569 ++++++++++++++++++++++++++++++++
 drivers/s390/char/sclp_tty.c            |   5 +-
 drivers/s390/cio/chp.c                  |  34 +-
 drivers/s390/cio/chp.h                  |   5 +-
 drivers/s390/cio/chsc.c                 |  59 ++--
 drivers/s390/cio/chsc.h                 |  11 +-
 drivers/s390/cio/device.c               |  16 +-
 drivers/s390/cio/device_ops.c           |   4 +-
 drivers/s390/cio/qdio_main.c            | 131 ++++----
 drivers/s390/cio/vfio_ccw_fsm.c         |   5 +
 drivers/s390/net/qeth_core_main.c       |   2 +-
 drivers/tty/Kconfig                     |   2 +-
 drivers/video/Kconfig                   |   5 +-
 drivers/video/console/Kconfig           |   6 +-
 56 files changed, 1633 insertions(+), 475 deletions(-)
 create mode 100644 arch/s390/include/asm/alternative-asm.h
 create mode 100644 drivers/s390/char/sclp_sd.c

Re: [GIT PULL] s390 patches for the 4.17 merge window #1

[Martin Schwidefsky]

Hi Linus,

On Tue, 3 Apr 2018 11:12:42 +0200
Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:

> please pull from the 'for-linus' branch of
> 
> 	git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
> 
> to receive the following updates:
> 
>  * Improvements for the spectre defense:
>    - The spectre related code is consolidated to a single file nospec-branch.c
>    - Automatic enable/disable for the spectre v2 defenses (expoline vs. nobp)
>    - Syslog messages for specve v2 are added
>    - Enable CONFIG_GENERIC_CPU_VULNERABILITIES and define the attribute
>      functions for spectre v1 and v2
> 
>  * Add helper macros for assembler alternatives and use them to shorten
>    the code in entry.S.
> 
>  * Add support for persistent configuration data via the SCLP Store Data
>    interface. The H/W interface requires a page table that uses 4K pages
>    only, the code to setup such an address space is added as well.
> 
>  * Enable virtio GPU emulation in QEMU. To do this the depends statements
>    for a few common Kconfig options are modified.
> 
>  * Add support for format-3 channel path descriptors and add a binary
>    sysfs interface to export the associated utility strings.
> 
>  * Add a sysfs attribute to control the IFCC handling in case of constant
>    channel errors.
> 
>  * The vfio-ccw changes from Cornelia.
> 
>  * Bug fixes and cleanups.
> 
> There is a trivial merge conflict in drivers/video/console/Kconfig.

Ping.

Did this please-pull get lost or is there a deeper reason that prevents
the upstream integration?

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [GIT PULL] s390 patches for the 4.17 merge window #1

[Linus Torvalds]

On Mon, Apr 9, 2018 at 6:18 AM, Martin Schwidefsky
<schwidefsky@de.ibm.com> wrote:
> Hi Linus,
>
> On Tue, 3 Apr 2018 11:12:42 +0200
> Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
>
>> please pull from the 'for-linus' branch of
>>
>>       git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
>>
>> to receive the following updates:
>
> Ping.
>
> Did this please-pull get lost or is there a deeper reason that prevents
> the upstream integration?

I'm not finding the original at all, and this 'ping' message I found
in my spam-box. Maybe the original was marked as spam too and I didn't
notice, and it got deleted with the other spam.

Anyway, pulled now (even if this ping didn't have the diffstat and
shortlog to check against - everything looks sane)

                Linus

Re: [GIT PULL] s390 patches for the 4.17 merge window #1

[Martin Schwidefsky]

On Mon, 9 Apr 2018 09:07:12 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, Apr 9, 2018 at 6:18 AM, Martin Schwidefsky
> <schwidefsky@de.ibm.com> wrote:
> > Hi Linus,
> >
> > On Tue, 3 Apr 2018 11:12:42 +0200
> > Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
> >  
> >> please pull from the 'for-linus' branch of
> >>
> >>       git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
> >>
> >> to receive the following updates:  
> >
> > Ping.
> >
> > Did this please-pull get lost or is there a deeper reason that prevents
> > the upstream integration?  
> 
> I'm not finding the original at all, and this 'ping' message I found
> in my spam-box. Maybe the original was marked as spam too and I didn't
> notice, and it got deleted with the other spam.

Not good, any idea why the ping message has been marked as spam?
Maybe there is something in the headers that gives a hint.
 
> Anyway, pulled now (even if this ping didn't have the diffstat and
> shortlog to check against - everything looks sane)

Thanks.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [GIT PULL] s390 patches for the 4.17 merge window #1

[Linus Torvalds]

On Mon, Apr 9, 2018 at 9:22 AM, Martin Schwidefsky
<schwidefsky@de.ibm.com> wrote:
>>
>> I'm not finding the original at all, and this 'ping' message I found
>> in my spam-box. Maybe the original was marked as spam too and I didn't
>> notice, and it got deleted with the other spam.
>
> Not good, any idea why the ping message has been marked as spam?
> Maybe there is something in the headers that gives a hint.

There's nothing that looks suspicious to me in the headers, and gmail
doesn't leave any lines around either (ie no spamassassin-like scoring
etc: I don't think they want people gaming the spam detector).

There's the IBM internal spam/AV detector markings (but they all say
"not spam") and spf looks fine too (no dkim).

Maybe it was me fat-fingering the original email, causing the ping to
then be marked spam too. No way to know (although mis-marking email as
spam  without even noticing is definitely not a pattern of mine).

So I suspect it was some random word choice that triggered it.
Hopefully the fact that I marked your ping message as non-spam means
that it won't happen again for me.

I actually check my spam box fairly religiously, because I do get a
ton of spam and kernel emails occasionally do end up being false
positives, and so I check it daily to not be overwhelmed. But I also
obviously just scan it quickly, so the first one being missed and just
deleted in my daily scan is not all that surprising if it triggered
the gmail spam detector randomly.

And even if the false-positive rate is pretty darn small, I get _so_
much spam (because my email address is public and has been so long)
that even a low false-positive rate still means "a couple of
mis-marked messages each week".

              Linus