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
Hi Linus,
On Tue, 3 Apr 2018 11:12:42 +0200
Martin Schwidefsky <[email protected]> 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.
On Mon, Apr 9, 2018 at 6:18 AM, Martin Schwidefsky
<[email protected]> wrote:
> Hi Linus,
>
> On Tue, 3 Apr 2018 11:12:42 +0200
> Martin Schwidefsky <[email protected]> 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
On Mon, 9 Apr 2018 09:07:12 -0700
Linus Torvalds <[email protected]> wrote:
> On Mon, Apr 9, 2018 at 6:18 AM, Martin Schwidefsky
> <[email protected]> wrote:
> > Hi Linus,
> >
> > On Tue, 3 Apr 2018 11:12:42 +0200
> > Martin Schwidefsky <[email protected]> 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.
On Mon, Apr 9, 2018 at 9:22 AM, Martin Schwidefsky
<[email protected]> 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