2019-09-18 06:31:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 00/85] 5.2.16-stable review

This is the start of the stable review cycle for the 5.2.16 release.
There are 85 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Fri 20 Sep 2019 06:09:47 AM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.16-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 5.2.16-rc1

Linus Torvalds <[email protected]>
x86/build: Add -Wnoaddress-of-packed-member to REALMODE_CFLAGS, to silence GCC9 build warning

Hui Peng <[email protected]>
rsi: fix a double free bug in rsi_91x_deinit()

Enrico Weigelt <[email protected]>
platform/x86: pcengines-apuv2: use KEY_RESTART for front button

Steffen Dirkwinkel <[email protected]>
platform/x86: pmc_atom: Add CB4063 Beckhoff Automation board to critclk_systems DMI table

Liran Alon <[email protected]>
KVM: SVM: Fix detection of AMD Errata 1096

Jim Mattson <[email protected]>
kvm: nVMX: Remove unnecessary sync_roots from handle_invept

Jessica Yu <[email protected]>
modules: always page-align module section allocations

Yang Yingliang <[email protected]>
modules: fix compile error if don't have strict module rwx

Yang Yingliang <[email protected]>
modules: fix BUG when load module with rodata=n

Olivier Moysan <[email protected]>
iio: adc: stm32-dfsdm: fix data type

Olivier Moysan <[email protected]>
iio: adc: stm32-dfsdm: fix output resolution

Mario Limonciello <[email protected]>
Revert "Bluetooth: btusb: driver to enable the usb-wakeup feature"

Gustavo A. R. Silva <[email protected]>
mm/z3fold.c: fix lock/unlock imbalance in z3fold_page_isolate

Henry Burns <[email protected]>
mm/z3fold.c: remove z3fold_migration trylock

Nishka Dasgupta <[email protected]>
drm/mediatek: mtk_drm_drv.c: Add of_node_put() before goto

Hans de Goede <[email protected]>
drm: panel-orientation-quirks: Add extra quirk table entry for GPD MicroPC

Andrew F. Davis <[email protected]>
firmware: ti_sci: Always request response from firmware

Christophe Leroy <[email protected]>
crypto: talitos - HMAC SNOOP NO AFEU mode requires SW icv checking.

Christophe Leroy <[email protected]>
crypto: talitos - Do not modify req->cryptlen on decryption.

Christophe Leroy <[email protected]>
crypto: talitos - fix ECB algs ivsize

Christophe Leroy <[email protected]>
crypto: talitos - check data blocksize in ablkcipher.

Christophe Leroy <[email protected]>
crypto: talitos - fix CTR alg blocksize

Christophe Leroy <[email protected]>
crypto: talitos - check AES key size

Muchun Song <[email protected]>
driver core: Fix use-after-free and double free on glue directory

Richard Weinberger <[email protected]>
ubifs: Correctly use tnc_next() in search_dh_cookie()

Alex Williamson <[email protected]>
PCI: Always allow probing with driver_override

Xiaolei Li <[email protected]>
mtd: rawnand: mtk: Fix wrongly assigned OOB buffer pointer issue

Douglas Anderson <[email protected]>
clk: rockchip: Don't yell about bad mmc phases when getting

Dan Carpenter <[email protected]>
mt76: mt7615: Use after free in mt7615_mcu_set_bcn()

Dan Carpenter <[email protected]>
mt76: Fix a signedness bug in mt7615_add_interface()

Stephen Boyd <[email protected]>
clk: Simplify debugfs printing and add a newline

Chen-Yu Tsai <[email protected]>
clk: Fix debugfs clk_possible_parents for clks without parent string names

Neil Armstrong <[email protected]>
drm/meson: Add support for XBGR8888 & ABGR8888 formats

Mimi Zohar <[email protected]>
x86/ima: check EFI SetupMode too

Junichi Nomura <[email protected]>
x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernels

YueHaibing <[email protected]>
kernel/module: Fix mem leak in module_add_modinfo_attrs

Suraj Jitindar Singh <[email protected]>
powerpc: Add barrier_nospec to raw_copy_in_user()

Steve Wahl <[email protected]>
x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors

Paolo Bonzini <[email protected]>
KVM: nVMX: handle page fault in vmread

Sean Christopherson <[email protected]>
KVM: x86/mmu: Reintroduce fast invalidate/zap for flushing memslot

Fuqian Huang <[email protected]>
KVM: x86: work around leak of uninitialized stack contents

Thomas Huth <[email protected]>
KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

Igor Mammedov <[email protected]>
KVM: s390: kvm_s390_vm_start_migration: check dirty_bitmap before using it as target for memset()

Andreas Kemnade <[email protected]>
regulator: twl: voltage lists for vdd1/2 on twl4030

Yunfeng Ye <[email protected]>
genirq: Prevent NULL pointer dereference in resend_irqs()

Stanislaw Gruszka <[email protected]>
mt76: mt76x0e: disable 5GHz band for MT7630E

Stanislaw Gruszka <[email protected]>
Revert "rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band"

Alexander Duyck <[email protected]>
ixgbe: Prevent u8 wrapping of ITR value to something less than 10us

Ilya Maximets <[email protected]>
ixgbe: fix double clean of Tx descriptors with xdp

Arnd Bergmann <[email protected]>
ipc: fix sparc64 ipc() wrapper

Arnd Bergmann <[email protected]>
ipc: fix semtimedop for generic 32-bit architectures

Chris Wilson <[email protected]>
drm/i915: Restore relaxed padding (OCL_OOB_SUPPRES_ENABLE) for skl+

Ville Syrjälä <[email protected]>
drm/i915: Limit MST to <= 8bpc once again

Vasily Khoruzhick <[email protected]>
drm/lima: fix lima_gem_wait() return value

Ulf Hansson <[email protected]>
mmc: tmio: Fixup runtime PM management during remove

Ulf Hansson <[email protected]>
mmc: tmio: Fixup runtime PM management during probe

Daniel Drake <[email protected]>
Revert "mmc: sdhci: Remove unneeded quirk2 flag of O2 SD host controller"

Stefan Wahren <[email protected]>
Revert "mmc: bcm2835: Terminate timeout work synchronously"

Roman Gushchin <[email protected]>
cgroup: freezer: fix frozen state inheritance

Filipe Manana <[email protected]>
Btrfs: fix assertion failure during fsync and use of stale transaction

Kent Gibson <[email protected]>
gpio: fix line flag validation in lineevent_create

Kent Gibson <[email protected]>
gpio: fix line flag validation in linehandle_create

Wei Yongjun <[email protected]>
gpio: mockup: add missing single_release()

Hans de Goede <[email protected]>
gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist

John Fastabend <[email protected]>
net: sock_map, fix missing ulp check in sock hash case

Xin Long <[email protected]>
sctp: fix the missing put_user when dumping transport thresholds

Moritz Fischer <[email protected]>
net: fixed_phy: Add forward declaration for struct gpio_desc;

Maciej Żenczykowski <[email protected]>
ipv6: addrconf_f6i_alloc - fix non-null pointer check to !IS_ERR()

Maciej Żenczykowski <[email protected]>
net-ipv6: fix excessive RTF_ADDRCONF flag on ::1/128 local route (and others)

Yang Yingliang <[email protected]>
tun: fix use-after-free when register netdev failed

Xin Long <[email protected]>
tipc: add NULL pointer check before calling kfree_rcu

Neal Cardwell <[email protected]>
tcp: fix tcp_ecn_withdraw_cwr() to clear TCP_ECN_QUEUE_CWR

Xin Long <[email protected]>
sctp: use transport pf_retrans in sctp_do_8_2_transport_strike

Christophe JAILLET <[email protected]>
sctp: Fix the link time qualifier of 'sctp_ctrlsock_exit()'

Cong Wang <[email protected]>
sch_hhf: ensure quantum and hhf_non_hh_weight are non-zero

Eric Dumazet <[email protected]>
net: sched: fix reordering issues

Stefan Chulski <[email protected]>
net: phylink: Fix flow control resolution

Shmulik Ladkani <[email protected]>
net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list

Subash Abhinov Kasiviswanathan <[email protected]>
net: Fix null de-reference of device refcount

Jeff Kirsher <[email protected]>
ixgbevf: Fix secpath usage for IPsec Tx offload

Steffen Klassert <[email protected]>
ixgbe: Fix secpath usage for IPsec TX offload.

Eric Biggers <[email protected]>
isdn/capi: check message length in capi_write()

Christophe JAILLET <[email protected]>
ipv6: Fix the link time qualifier of 'ping_v6_proc_exit_net()'

Bjørn Mork <[email protected]>
cdc_ether: fix rndis support for Mediatek based smartphones

Nicolas Dichtel <[email protected]>
bridge/mdb: remove wrong use of NLM_F_MULTI


-------------

Diffstat:

Makefile | 4 +-
arch/powerpc/include/asm/uaccess.h | 1 +
arch/s390/kvm/interrupt.c | 10 ++
arch/s390/kvm/kvm-s390.c | 4 +-
arch/sparc/kernel/sys_sparc_64.c | 33 +++--
arch/x86/Makefile | 1 +
arch/x86/boot/compressed/acpi.c | 143 +++++++++++++-----
arch/x86/include/asm/kvm_host.h | 2 +
arch/x86/kernel/ima_arch.c | 12 +-
arch/x86/kvm/mmu.c | 101 ++++++++++++-
arch/x86/kvm/svm.c | 42 +++++-
arch/x86/kvm/vmx/nested.c | 12 +-
arch/x86/kvm/x86.c | 7 +
arch/x86/purgatory/Makefile | 35 +++--
drivers/base/core.c | 53 ++++++-
drivers/bluetooth/btusb.c | 5 -
drivers/clk/clk.c | 38 ++++-
drivers/clk/rockchip/clk-mmc-phase.c | 4 +-
drivers/crypto/talitos.c | 70 ++++++---
drivers/firmware/ti_sci.c | 8 +-
drivers/gpio/gpio-mockup.c | 1 +
drivers/gpio/gpiolib-acpi.c | 42 +++++-
drivers/gpio/gpiolib.c | 16 +-
drivers/gpu/drm/drm_panel_orientation_quirks.c | 12 ++
drivers/gpu/drm/i915/intel_dp_mst.c | 10 +-
drivers/gpu/drm/i915/intel_workarounds.c | 5 -
drivers/gpu/drm/lima/lima_gem.c | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +-
drivers/gpu/drm/meson/meson_plane.c | 16 ++
drivers/iio/adc/stm32-dfsdm-adc.c | 162 ++++++++++++++++-----
drivers/iio/adc/stm32-dfsdm.h | 24 ++-
drivers/isdn/capi/capi.c | 10 +-
drivers/mmc/host/bcm2835.c | 2 +-
drivers/mmc/host/sdhci-pci-o2micro.c | 2 +-
drivers/mmc/host/tmio_mmc.h | 1 +
drivers/mmc/host/tmio_mmc_core.c | 16 +-
drivers/mtd/nand/raw/mtk_nand.c | 21 ++-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 29 ++--
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 3 +-
drivers/net/phy/phylink.c | 6 +-
drivers/net/tun.c | 16 +-
drivers/net/usb/cdc_ether.c | 10 +-
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 5 +-
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c | 5 +
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 18 +--
drivers/net/wireless/rsi/rsi_91x_usb.c | 1 -
drivers/pci/pci-driver.c | 3 +-
drivers/platform/x86/pcengines-apuv2.c | 2 +-
drivers/platform/x86/pmc_atom.c | 8 +
drivers/regulator/twl-regulator.c | 23 ++-
fs/btrfs/tree-log.c | 16 +-
fs/ubifs/tnc.c | 16 +-
include/linux/phy_fixed.h | 1 +
include/linux/syscalls.h | 19 +++
include/uapi/asm-generic/unistd.h | 2 +-
include/uapi/linux/isdn/capicmd.h | 1 +
ipc/util.h | 25 +---
kernel/cgroup/cgroup.c | 10 +-
kernel/irq/resend.c | 2 +
kernel/module.c | 51 ++++---
mm/z3fold.c | 7 +-
net/bridge/br_mdb.c | 2 +-
net/core/dev.c | 2 +
net/core/skbuff.c | 19 +++
net/core/sock_map.c | 3 +
net/ipv4/tcp_input.c | 2 +-
net/ipv6/ping.c | 2 +-
net/ipv6/route.c | 8 +-
net/sched/sch_generic.c | 9 +-
net/sched/sch_hhf.c | 2 +-
net/sctp/protocol.c | 2 +-
net/sctp/sm_sideeffect.c | 2 +-
net/sctp/socket.c | 3 +-
net/tipc/name_distr.c | 3 +-
76 files changed, 956 insertions(+), 323 deletions(-)



2019-09-18 06:31:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 82/85] platform/x86: pmc_atom: Add CB4063 Beckhoff Automation board to critclk_systems DMI table

From: Steffen Dirkwinkel <[email protected]>

commit 9452fbf5c6cf5f470e0748fe7a14a683e7765f7a upstream.

The CB4063 board uses pmc_plt_clk* clocks for ethernet controllers. This
adds it to the critclk_systems DMI table so the clocks are marked as
CLK_CRITICAL and not turned off.

Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Signed-off-by: Steffen Dirkwinkel <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/platform/x86/pmc_atom.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/drivers/platform/x86/pmc_atom.c
+++ b/drivers/platform/x86/pmc_atom.c
@@ -414,6 +414,14 @@ static const struct dmi_system_id critcl
},
{
/* pmc_plt_clk* - are used for ethernet controllers */
+ .ident = "Beckhoff CB4063",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
+ DMI_MATCH(DMI_BOARD_NAME, "CB4063"),
+ },
+ },
+ {
+ /* pmc_plt_clk* - are used for ethernet controllers */
.ident = "Beckhoff CB6263",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),


2019-09-18 06:31:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 85/85] x86/build: Add -Wnoaddress-of-packed-member to REALMODE_CFLAGS, to silence GCC9 build warning

From: Linus Torvalds <[email protected]>

commit 42e0e95474fc6076b5cd68cab8fa0340a1797a72 upstream.

One of the very few warnings I have in the current build comes from
arch/x86/boot/edd.c, where I get the following with a gcc9 build:

arch/x86/boot/edd.c: In function ‘query_edd’:
arch/x86/boot/edd.c:148:11: warning: taking address of packed member of ‘struct boot_params’ may result in an unaligned pointer value [-Waddress-of-packed-member]
148 | mbrptr = boot_params.edd_mbr_sig_buffer;
| ^~~~~~~~~~~

This warning triggers because we throw away all the CFLAGS and then make
a new set for REALMODE_CFLAGS, so the -Wno-address-of-packed-member we
added in the following commit is not present:

6f303d60534c ("gcc-9: silence 'address-of-packed-member' warning")

The simplest solution for now is to adjust the warning for this version
of CFLAGS as well, but it would definitely make sense to examine whether
REALMODE_CFLAGS could be derived from CFLAGS, so that it picks up changes
in the compiler flags environment automatically.

Signed-off-by: Linus Torvalds <[email protected]>
Acked-by: Borislav Petkov <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/Makefile | 1 +
1 file changed, 1 insertion(+)

--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -38,6 +38,7 @@ REALMODE_CFLAGS := $(M16_CFLAGS) -g -Os

REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -ffreestanding)
REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -fno-stack-protector)
+REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -Wno-address-of-packed-member)
REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), $(cc_stack_align4))
export REALMODE_CFLAGS



2019-09-18 06:31:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 84/85] rsi: fix a double free bug in rsi_91x_deinit()

From: Hui Peng <[email protected]>

commit 8b51dc7291473093c821195c4b6af85fadedbc2f upstream.

`dev` (struct rsi_91x_usbdev *) field of adapter
(struct rsi_91x_usbdev *) is allocated and initialized in
`rsi_init_usb_interface`. If any error is detected in information
read from the device side, `rsi_init_usb_interface` will be
freed. However, in the higher level error handling code in
`rsi_probe`, if error is detected, `rsi_91x_deinit` is called
again, in which `dev` will be freed again, resulting double free.

This patch fixes the double free by removing the free operation on
`dev` in `rsi_init_usb_interface`, because `rsi_91x_deinit` is also
used in `rsi_disconnect`, in that code path, the `dev` field is not
(and thus needs to be) freed.

This bug was found in v4.19, but is also present in the latest version
of kernel. Fixes CVE-2019-15504.

Reported-by: Hui Peng <[email protected]>
Reported-by: Mathias Payer <[email protected]>
Signed-off-by: Hui Peng <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/rsi/rsi_91x_usb.c | 1 -
1 file changed, 1 deletion(-)

--- a/drivers/net/wireless/rsi/rsi_91x_usb.c
+++ b/drivers/net/wireless/rsi/rsi_91x_usb.c
@@ -645,7 +645,6 @@ fail_rx:
kfree(rsi_dev->tx_buffer);

fail_eps:
- kfree(rsi_dev);

return status;
}


2019-09-18 06:31:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 49/85] powerpc: Add barrier_nospec to raw_copy_in_user()

From: Suraj Jitindar Singh <[email protected]>

commit 6fbcdd59094ade30db63f32316e9502425d7b256 upstream.

Commit ddf35cf3764b ("powerpc: Use barrier_nospec in copy_from_user()")
Added barrier_nospec before loading from user-controlled pointers. The
intention was to order the load from the potentially user-controlled
pointer vs a previous branch based on an access_ok() check or similar.

In order to achieve the same result, add a barrier_nospec to the
raw_copy_in_user() function before loading from such a user-controlled
pointer.

Fixes: ddf35cf3764b ("powerpc: Use barrier_nospec in copy_from_user()")
Signed-off-by: Suraj Jitindar Singh <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/include/asm/uaccess.h | 1 +
1 file changed, 1 insertion(+)

--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -312,6 +312,7 @@ raw_copy_in_user(void __user *to, const
{
unsigned long ret;

+ barrier_nospec();
allow_user_access(to, from, n);
ret = __copy_tofrom_user(to, from, n);
prevent_user_access(to, from, n);


2019-09-18 06:31:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 38/85] ixgbe: Prevent u8 wrapping of ITR value to something less than 10us

From: Alexander Duyck <[email protected]>

commit 377228accbbb8b9738f615d791aa803f41c067e0 upstream.

There were a couple cases where the ITR value generated via the adaptive
ITR scheme could exceed 126. This resulted in the value becoming either 0
or something less than 10. Switching back and forth between a value less
than 10 and a value greater than 10 can cause issues as certain hardware
features such as RSC to not function well when the ITR value has dropped
that low.

CC: [email protected]
Fixes: b4ded8327fea ("ixgbe: Update adaptive ITR algorithm")
Reported-by: Gregg Leventhal <[email protected]>
Signed-off-by: Alexander Duyck <[email protected]>
Tested-by: Andrew Bowers <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -2622,7 +2622,7 @@ adjust_by_size:
/* 16K ints/sec to 9.2K ints/sec */
avg_wire_size *= 15;
avg_wire_size += 11452;
- } else if (avg_wire_size <= 1980) {
+ } else if (avg_wire_size < 1968) {
/* 9.2K ints/sec to 8K ints/sec */
avg_wire_size *= 5;
avg_wire_size += 22420;
@@ -2655,6 +2655,8 @@ adjust_by_size:
case IXGBE_LINK_SPEED_2_5GB_FULL:
case IXGBE_LINK_SPEED_1GB_FULL:
case IXGBE_LINK_SPEED_10_FULL:
+ if (avg_wire_size > 8064)
+ avg_wire_size = 8064;
itr += DIV_ROUND_UP(avg_wire_size,
IXGBE_ITR_ADAPTIVE_MIN_INC * 64) *
IXGBE_ITR_ADAPTIVE_MIN_INC;


2019-09-18 06:31:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 45/85] KVM: x86: work around leak of uninitialized stack contents

From: Fuqian Huang <[email protected]>

commit 541ab2aeb28251bf7135c7961f3a6080eebcc705 upstream.

Emulation of VMPTRST can incorrectly inject a page fault
when passed an operand that points to an MMIO address.
The page fault will use uninitialized kernel stack memory
as the CR2 and error code.

The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR
exit to userspace; however, it is not an easy fix, so for now just ensure
that the error code and CR2 are zero.

Signed-off-by: Fuqian Huang <[email protected]>
Cc: [email protected]
[add comment]
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kvm/x86.c | 7 +++++++
1 file changed, 7 insertions(+)

--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5265,6 +5265,13 @@ int kvm_write_guest_virt_system(struct k
/* kvm_write_guest_virt_system can pull in tons of pages. */
vcpu->arch.l1tf_flush_l1d = true;

+ /*
+ * FIXME: this should call handle_emulation_failure if X86EMUL_IO_NEEDED
+ * is returned, but our callers are not ready for that and they blindly
+ * call kvm_inject_page_fault. Ensure that they at least do not leak
+ * uninitialized kernel stack memory into cr2 and error code.
+ */
+ memset(exception, 0, sizeof(*exception));
return kvm_write_guest_virt_helper(addr, val, bytes, vcpu,
PFERR_WRITE_MASK, exception);
}


2019-09-18 06:31:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 43/85] KVM: s390: kvm_s390_vm_start_migration: check dirty_bitmap before using it as target for memset()

From: Igor Mammedov <[email protected]>

commit 13a17cc0526f08d1df9507f7484176371cd263a0 upstream.

If userspace doesn't set KVM_MEM_LOG_DIRTY_PAGES on memslot before calling
kvm_s390_vm_start_migration(), kernel will oops with:

Unable to handle kernel pointer dereference in virtual kernel address space
Failing address: 0000000000000000 TEID: 0000000000000483
Fault in home space mode while using kernel ASCE.
AS:0000000002a2000b R2:00000001bff8c00b R3:00000001bff88007 S:00000001bff91000 P:000000000000003d
Oops: 0004 ilc:2 [#1] SMP
...
Call Trace:
([<001fffff804ec552>] kvm_s390_vm_set_attr+0x347a/0x3828 [kvm])
[<001fffff804ecfc0>] kvm_arch_vm_ioctl+0x6c0/0x1998 [kvm]
[<001fffff804b67e4>] kvm_vm_ioctl+0x51c/0x11a8 [kvm]
[<00000000008ba572>] do_vfs_ioctl+0x1d2/0xe58
[<00000000008bb284>] ksys_ioctl+0x8c/0xb8
[<00000000008bb2e2>] sys_ioctl+0x32/0x40
[<000000000175552c>] system_call+0x2b8/0x2d8
INFO: lockdep is turned off.
Last Breaking-Event-Address:
[<0000000000dbaf60>] __memset+0xc/0xa0

due to ms->dirty_bitmap being NULL, which might crash the host.

Make sure that ms->dirty_bitmap is set before using it or
return -EINVAL otherwise.

Cc: <[email protected]>
Fixes: afdad61615cc ("KVM: s390: Fix storage attributes migration with memory slots")
Signed-off-by: Igor Mammedov <[email protected]>
Link: https://lore.kernel.org/kvm/[email protected]/
Reviewed-by: David Hildenbrand <[email protected]>
Reviewed-by: Christian Borntraeger <[email protected]>
Reviewed-by: Claudio Imbrenda <[email protected]>
Reviewed-by: Cornelia Huck <[email protected]>
Reviewed-by: Janosch Frank <[email protected]>
Signed-off-by: Janosch Frank <[email protected]>
Signed-off-by: Christian Borntraeger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/s390/kvm/kvm-s390.c | 2 ++
1 file changed, 2 insertions(+)

--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -1013,6 +1013,8 @@ static int kvm_s390_vm_start_migration(s
/* mark all the pages in active slots as dirty */
for (slotnr = 0; slotnr < slots->used_slots; slotnr++) {
ms = slots->memslots + slotnr;
+ if (!ms->dirty_bitmap)
+ return -EINVAL;
/*
* The second half of the bitmap is only used on x86,
* and would be wasted otherwise, so we put it to good


2019-09-18 06:31:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 56/85] mt76: Fix a signedness bug in mt7615_add_interface()

From: Dan Carpenter <[email protected]>

commit b1571a0e77d8cef14227af293c6dda1464a57270 upstream.

The problem is that "mvif->omac_idx" is a u8 so it can't be negative
and the error handling won't work. The get_omac_idx() function returns
-1 on error.

Fixes: 04b8e65922f6 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -77,11 +77,12 @@ static int mt7615_add_interface(struct i
goto out;
}

- mvif->omac_idx = get_omac_idx(vif->type, dev->omac_mask);
- if (mvif->omac_idx < 0) {
+ idx = get_omac_idx(vif->type, dev->omac_mask);
+ if (idx < 0) {
ret = -ENOSPC;
goto out;
}
+ mvif->omac_idx = idx;

/* TODO: DBDC support. Use band 0 and wmm 0 for now */
mvif->band_idx = 0;


2019-09-18 06:31:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 57/85] mt76: mt7615: Use after free in mt7615_mcu_set_bcn()

From: Dan Carpenter <[email protected]>

commit 9db1aec0c2d72a3b7b115ba56e8dbb5b46855333 upstream.

We dereference "skb" when we assign:

req.pkt_len = cpu_to_le16(MT_TXD_SIZE + skb->len);
^^^^^^^^
So this patch just moves the dev_kfree_skb() down a bit to avoid the
use after free.

Fixes: 04b8e65922f6 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets")
Signed-off-by: Dan Carpenter <[email protected]>
Acked-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -1270,7 +1270,6 @@ int mt7615_mcu_set_bcn(struct mt7615_dev
mt7615_mac_write_txwi(dev, (__le32 *)(req.pkt), skb, wcid, NULL,
0, NULL);
memcpy(req.pkt + MT_TXD_SIZE, skb->data, skb->len);
- dev_kfree_skb(skb);

req.omac_idx = mvif->omac_idx;
req.enable = en;
@@ -1281,6 +1280,7 @@ int mt7615_mcu_set_bcn(struct mt7615_dev
req.pkt_len = cpu_to_le16(MT_TXD_SIZE + skb->len);
req.tim_ie_pos = cpu_to_le16(MT_TXD_SIZE + tim_off);

+ dev_kfree_skb(skb);
skb = mt7615_mcu_msg_alloc(&req, sizeof(req));

return mt7615_mcu_msg_send(dev, skb, MCU_EXT_CMD_BCN_OFFLOAD,


2019-09-18 06:31:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 40/85] mt76: mt76x0e: disable 5GHz band for MT7630E

From: Stanislaw Gruszka <[email protected]>

commit 70702265a04aa0ce5a7bde77d13456209992b32f upstream.

MT7630E hardware does support 5GHz, but we do not properly configure phy
for 5GHz channels. Scanning at this band not only do not show any APs
but also can hang the firmware.

Since vendor reference driver do not support 5GHz we don't know how
properly configure 5GHz channels. So disable this band for MT7630E .

Cc: [email protected]
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c
@@ -59,6 +59,11 @@ static void mt76x0_set_chip_cap(struct m
dev_dbg(dev->mt76.dev, "mask out 2GHz support\n");
}

+ if (is_mt7630(dev)) {
+ dev->mt76.cap.has_5ghz = false;
+ dev_dbg(dev->mt76.dev, "mask out 5GHz support\n");
+ }
+
if (!mt76x02_field_valid(nic_conf1 & 0xff))
nic_conf1 &= 0xff00;



2019-09-18 06:31:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 73/85] mm/z3fold.c: fix lock/unlock imbalance in z3fold_page_isolate

From: Gustavo A. R. Silva <[email protected]>

commit 14108b9131a47ff18a3c640f583eb2d625c75c0d upstream.

Fix lock/unlock imbalance by unlocking *zhdr* before return.

Addresses Coverity ID 1452811 ("Missing unlock")

Link: http://lkml.kernel.org/r/20190826030634.GA4379@embeddedor
Fixes: d776aaa9895e ("mm/z3fold.c: fix race between migration and destruction")
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Cc: Henry Burns <[email protected]>
Cc: Vitaly Wool <[email protected]>
Cc: Shakeel Butt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/z3fold.c | 1 +
1 file changed, 1 insertion(+)

--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -1408,6 +1408,7 @@ static bool z3fold_page_isolate(struct p
* should freak out.
*/
WARN(1, "Z3fold is experiencing kref problems\n");
+ z3fold_page_unlock(zhdr);
return false;
}
z3fold_page_unlock(zhdr);


2019-09-18 06:32:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 71/85] drm/mediatek: mtk_drm_drv.c: Add of_node_put() before goto

From: Nishka Dasgupta <[email protected]>

commit 165d42c012be69900f0e2f8545626cb9e7d4a832 upstream.

Each iteration of for_each_child_of_node puts the previous
node, but in the case of a goto from the middle of the loop, there is
no put, thus causing a memory leak. Hence add an of_node_put before the
goto in two places.
Issue found with Coccinelle.

Fixes: 119f5173628a (drm/mediatek: Add DRM Driver for Mediatek SoC MT8173)

Signed-off-by: Nishka Dasgupta <[email protected]>
Signed-off-by: CK Hu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -567,12 +567,15 @@ static int mtk_drm_probe(struct platform
comp = devm_kzalloc(dev, sizeof(*comp), GFP_KERNEL);
if (!comp) {
ret = -ENOMEM;
+ of_node_put(node);
goto err_node;
}

ret = mtk_ddp_comp_init(dev, node, comp, comp_id, NULL);
- if (ret)
+ if (ret) {
+ of_node_put(node);
goto err_node;
+ }

private->ddp_comp[comp_id] = comp;
}


2019-09-18 06:32:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 72/85] mm/z3fold.c: remove z3fold_migration trylock

From: Henry Burns <[email protected]>

commit be03074c9af25d06cf8e9ebddfcd284c0bf7f947 upstream.

z3fold_page_migrate() will never succeed because it attempts to acquire
a lock that has already been taken by migrate.c in __unmap_and_move().

__unmap_and_move() migrate.c
trylock_page(oldpage)
move_to_new_page(oldpage_newpage)
a_ops->migrate_page(oldpage, newpage)
z3fold_page_migrate(oldpage, newpage)
trylock_page(oldpage)

Link: http://lkml.kernel.org/r/[email protected]
Fixes: 1f862989b04a ("mm/z3fold.c: support page migration")
Signed-off-by: Henry Burns <[email protected]>
Reviewed-by: Shakeel Butt <[email protected]>
Cc: Vitaly Wool <[email protected]>
Cc: Vitaly Vul <[email protected]>
Cc: Jonathan Adams <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Snild Dolkow <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/z3fold.c | 6 ------
1 file changed, 6 deletions(-)

--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -1439,16 +1439,11 @@ static int z3fold_page_migrate(struct ad
zhdr = page_address(page);
pool = zhdr_to_pool(zhdr);

- if (!trylock_page(page))
- return -EAGAIN;
-
if (!z3fold_page_trylock(zhdr)) {
- unlock_page(page);
return -EAGAIN;
}
if (zhdr->mapped_count != 0) {
z3fold_page_unlock(zhdr);
- unlock_page(page);
return -EBUSY;
}
if (work_pending(&zhdr->work)) {
@@ -1494,7 +1489,6 @@ static int z3fold_page_migrate(struct ad
spin_unlock(&pool->lock);

page_mapcount_reset(page);
- unlock_page(page);
put_page(page);
return 0;
}


2019-09-18 06:32:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 68/85] crypto: talitos - HMAC SNOOP NO AFEU mode requires SW icv checking.

From: Christophe Leroy <[email protected]>

commit 4bbfb839259a9c96a0be872e16f7471b7136aee5 upstream.

In that mode, hardware ICV verification is not supported.

Signed-off-by: Christophe Leroy <[email protected]>
Fixes: 7405c8d7ff97 ("crypto: talitos - templates for AEAD using HMAC_SNOOP_NO_AFEU")
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/crypto/talitos.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1515,7 +1515,8 @@ static int aead_decrypt(struct aead_requ
if (IS_ERR(edesc))
return PTR_ERR(edesc);

- if ((priv->features & TALITOS_FTR_HW_AUTH_CHECK) &&
+ if ((edesc->desc.hdr & DESC_HDR_TYPE_IPSEC_ESP) &&
+ (priv->features & TALITOS_FTR_HW_AUTH_CHECK) &&
((!edesc->src_nents && !edesc->dst_nents) ||
priv->features & TALITOS_FTR_SRC_LINK_TBL_LEN_INCLUDES_EXTENT)) {



2019-09-18 06:32:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 66/85] crypto: talitos - fix ECB algs ivsize

From: Christophe Leroy <[email protected]>

commit d84cc9c9524ec5973a337533e6d8ccd3e5f05f2b upstream.

ECB's ivsize must be 0.

Signed-off-by: Christophe Leroy <[email protected]>
Fixes: 5e75ae1b3cef ("crypto: talitos - add new crypto modes")
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/crypto/talitos.c | 3 ---
1 file changed, 3 deletions(-)

--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -2814,7 +2814,6 @@ static struct talitos_alg_template drive
.cra_ablkcipher = {
.min_keysize = AES_MIN_KEY_SIZE,
.max_keysize = AES_MAX_KEY_SIZE,
- .ivsize = AES_BLOCK_SIZE,
.setkey = ablkcipher_aes_setkey,
}
},
@@ -2849,7 +2848,6 @@ static struct talitos_alg_template drive
.cra_ablkcipher = {
.min_keysize = DES_KEY_SIZE,
.max_keysize = DES_KEY_SIZE,
- .ivsize = DES_BLOCK_SIZE,
.setkey = ablkcipher_des_setkey,
}
},
@@ -2885,7 +2883,6 @@ static struct talitos_alg_template drive
.cra_ablkcipher = {
.min_keysize = DES3_EDE_KEY_SIZE,
.max_keysize = DES3_EDE_KEY_SIZE,
- .ivsize = DES3_EDE_BLOCK_SIZE,
.setkey = ablkcipher_des3_setkey,
}
},


2019-09-18 06:32:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 54/85] clk: Fix debugfs clk_possible_parents for clks without parent string names

From: Chen-Yu Tsai <[email protected]>

commit 2d156b78ce8febf15cd58a025d7d9d7b7577126a upstream.

Following the commit fc0c209c147f ("clk: Allow parents to be specified
without string names"), the parent name string is not always populated.

Instead, fetch the parents clk_core struct using the appropriate helper,
and read its name directly. If that fails, go through the possible
sources of parent names. The order in which they are used is different
from how parents are looked up, with the global name having precedence
over local fw_name and indices. This makes more sense as a) the
parent_maps structure does not differentiate between legacy global names
and fallback global names, and b) global names likely provide more
information than local fw_names.

Fixes: fc0c209c147f ("clk: Allow parents to be specified without string names")
Signed-off-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/clk/clk.c | 44 +++++++++++++++++++++++++++++++++++++++++---
1 file changed, 41 insertions(+), 3 deletions(-)

--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3023,12 +3023,50 @@ DEFINE_SHOW_ATTRIBUTE(clk_flags);
static int possible_parents_show(struct seq_file *s, void *data)
{
struct clk_core *core = s->private;
+ struct clk_core *parent;
int i;

- for (i = 0; i < core->num_parents - 1; i++)
- seq_printf(s, "%s ", core->parents[i].name);
+ /*
+ * Go through the following options to fetch a parent's name.
+ *
+ * 1. Fetch the registered parent clock and use its name
+ * 2. Use the global (fallback) name if specified
+ * 3. Use the local fw_name if provided
+ * 4. Fetch parent clock's clock-output-name if DT index was set
+ *
+ * This may still fail in some cases, such as when the parent is
+ * specified directly via a struct clk_hw pointer, but it isn't
+ * registered (yet).
+ */
+ for (i = 0; i < core->num_parents - 1; i++) {
+ parent = clk_core_get_parent_by_index(core, i);
+ if (parent)
+ seq_printf(s, "%s ", parent->name);
+ else if (core->parents[i].name)
+ seq_printf(s, "%s ", core->parents[i].name);
+ else if (core->parents[i].fw_name)
+ seq_printf(s, "<%s>(fw) ", core->parents[i].fw_name);
+ else if (core->parents[i].index >= 0)
+ seq_printf(s, "%s ",
+ of_clk_get_parent_name(core->of_node,
+ core->parents[i].index));
+ else
+ seq_puts(s, "(missing) ");
+ }

- seq_printf(s, "%s\n", core->parents[i].name);
+ parent = clk_core_get_parent_by_index(core, i);
+ if (parent)
+ seq_printf(s, "%s", parent->name);
+ else if (core->parents[i].name)
+ seq_printf(s, "%s", core->parents[i].name);
+ else if (core->parents[i].fw_name)
+ seq_printf(s, "<%s>(fw)", core->parents[i].fw_name);
+ else if (core->parents[i].index >= 0)
+ seq_printf(s, "%s",
+ of_clk_get_parent_name(core->of_node,
+ core->parents[i].index));
+ else
+ seq_puts(s, "(missing)");

return 0;
}


2019-09-18 06:32:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 55/85] clk: Simplify debugfs printing and add a newline

From: Stephen Boyd <[email protected]>

commit 11f6c2307caee89370d7752eb6f404f1ed73faaf upstream.

The possible parent printing function duplicates a bunch of if
conditions. Pull that into another function so we can print an extra
character at the end, either a space or a newline. This way we can add
the required newline that got lost here and also shorten the code.

Fixes: 2d156b78ce8f ("clk: Fix debugfs clk_possible_parents for clks without parent string names")
Cc: Chen-Yu Tsai <[email protected]>
Tested-by: Chen-Yu Tsai <[email protected]>
Reviewed-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/clk/clk.c | 34 +++++++++++++++-------------------
1 file changed, 15 insertions(+), 19 deletions(-)

--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3020,11 +3020,10 @@ static int clk_flags_show(struct seq_fil
}
DEFINE_SHOW_ATTRIBUTE(clk_flags);

-static int possible_parents_show(struct seq_file *s, void *data)
+static void possible_parent_show(struct seq_file *s, struct clk_core *core,
+ unsigned int i, char terminator)
{
- struct clk_core *core = s->private;
struct clk_core *parent;
- int i;

/*
* Go through the following options to fetch a parent's name.
@@ -3038,22 +3037,6 @@ static int possible_parents_show(struct
* specified directly via a struct clk_hw pointer, but it isn't
* registered (yet).
*/
- for (i = 0; i < core->num_parents - 1; i++) {
- parent = clk_core_get_parent_by_index(core, i);
- if (parent)
- seq_printf(s, "%s ", parent->name);
- else if (core->parents[i].name)
- seq_printf(s, "%s ", core->parents[i].name);
- else if (core->parents[i].fw_name)
- seq_printf(s, "<%s>(fw) ", core->parents[i].fw_name);
- else if (core->parents[i].index >= 0)
- seq_printf(s, "%s ",
- of_clk_get_parent_name(core->of_node,
- core->parents[i].index));
- else
- seq_puts(s, "(missing) ");
- }
-
parent = clk_core_get_parent_by_index(core, i);
if (parent)
seq_printf(s, "%s", parent->name);
@@ -3068,6 +3051,19 @@ static int possible_parents_show(struct
else
seq_puts(s, "(missing)");

+ seq_putc(s, terminator);
+}
+
+static int possible_parents_show(struct seq_file *s, void *data)
+{
+ struct clk_core *core = s->private;
+ int i;
+
+ for (i = 0; i < core->num_parents - 1; i++)
+ possible_parent_show(s, core, i, ' ');
+
+ possible_parent_show(s, core, i, '\n');
+
return 0;
}
DEFINE_SHOW_ATTRIBUTE(possible_parents);


2019-09-18 06:32:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 52/85] x86/ima: check EFI SetupMode too

From: Mimi Zohar <[email protected]>

commit 980ef4d22a95a3cd84a9b8ffaa7b81b391d173c6 upstream.

Checking "SecureBoot" mode is not sufficient, also check "SetupMode".

Fixes: 399574c64eaf ("x86/ima: retry detecting secure boot mode")
Reported-by: Matthew Garrett <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kernel/ima_arch.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

--- a/arch/x86/kernel/ima_arch.c
+++ b/arch/x86/kernel/ima_arch.c
@@ -11,10 +11,11 @@ extern struct boot_params boot_params;
static enum efi_secureboot_mode get_sb_mode(void)
{
efi_char16_t efi_SecureBoot_name[] = L"SecureBoot";
+ efi_char16_t efi_SetupMode_name[] = L"SecureBoot";
efi_guid_t efi_variable_guid = EFI_GLOBAL_VARIABLE_GUID;
efi_status_t status;
unsigned long size;
- u8 secboot;
+ u8 secboot, setupmode;

size = sizeof(secboot);

@@ -36,7 +37,14 @@ static enum efi_secureboot_mode get_sb_m
return efi_secureboot_mode_unknown;
}

- if (secboot == 0) {
+ size = sizeof(setupmode);
+ status = efi.get_variable(efi_SetupMode_name, &efi_variable_guid,
+ NULL, &size, &setupmode);
+
+ if (status != EFI_SUCCESS) /* ignore unknown SetupMode */
+ setupmode = 0;
+
+ if (secboot == 0 || setupmode == 1) {
pr_info("ima: secureboot mode disabled\n");
return efi_secureboot_mode_disabled;
}


2019-09-18 06:32:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 48/85] x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors

From: Steve Wahl <[email protected]>

commit e16c2983fba0fa6763e43ad10916be35e3d8dc05 upstream.

The last change to this Makefile caused relocation errors when loading
a kdump kernel. Restore -mcmodel=large (not -mcmodel=kernel),
-ffreestanding, and -fno-zero-initialized-bsss, without reverting to
the former practice of resetting KBUILD_CFLAGS.

Purgatory.ro is a standalone binary that is not linked against the
rest of the kernel. Its image is copied into an array that is linked
to the kernel, and from there kexec relocates it wherever it desires.

With the previous change to compiler flags, the error "kexec: Overflow
in relocation type 11 value 0x11fffd000" was encountered when trying
to load the crash kernel. This is from kexec code trying to relocate
the purgatory.ro object.

>From the error message, relocation type 11 is R_X86_64_32S. The
x86_64 ABI says:

"The R_X86_64_32 and R_X86_64_32S relocations truncate the
computed value to 32-bits. The linker must verify that the
generated value for the R_X86_64_32 (R_X86_64_32S) relocation
zero-extends (sign-extends) to the original 64-bit value."

This type of relocation doesn't work when kexec chooses to place the
purgatory binary in memory that is not reachable with 32 bit
addresses.

The compiler flag -mcmodel=kernel allows those type of relocations to
be emitted, so revert to using -mcmodel=large as was done before.

Also restore the -ffreestanding and -fno-zero-initialized-bss flags
because they are appropriate for a stand alone piece of object code
which doesn't explicitly zero the bss, and one other report has said
undefined symbols are encountered without -ffreestanding.

These identical compiler flag changes need to happen for every object
that becomes part of the purgatory.ro object, so gather them together
first into PURGATORY_CFLAGS_REMOVE and PURGATORY_CFLAGS, and then
apply them to each of the objects that have C source. Do not apply
any of these flags to kexec-purgatory.o, which is not part of the
standalone object but part of the kernel proper.

Tested-by: Vaibhav Rustagi <[email protected]>
Tested-by: Andreas Smas <[email protected]>
Signed-off-by: Steve Wahl <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: None
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Fixes: b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS")
Link: https://lkml.kernel.org/r/20190905202346.GA26595@swahl-linux
Signed-off-by: Ingo Molnar <[email protected]>
Cc: Andreas Smas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/purgatory/Makefile | 35 +++++++++++++++++++----------------
1 file changed, 19 insertions(+), 16 deletions(-)

--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -18,37 +18,40 @@ targets += purgatory.ro
KASAN_SANITIZE := n
KCOV_INSTRUMENT := n

+# These are adjustments to the compiler flags used for objects that
+# make up the standalone purgatory.ro
+
+PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel
+PURGATORY_CFLAGS := -mcmodel=large -ffreestanding -fno-zero-initialized-in-bss
+
# Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
# in turn leaves some undefined symbols like __fentry__ in purgatory and not
# sure how to relocate those.
ifdef CONFIG_FUNCTION_TRACER
-CFLAGS_REMOVE_sha256.o += $(CC_FLAGS_FTRACE)
-CFLAGS_REMOVE_purgatory.o += $(CC_FLAGS_FTRACE)
-CFLAGS_REMOVE_string.o += $(CC_FLAGS_FTRACE)
-CFLAGS_REMOVE_kexec-purgatory.o += $(CC_FLAGS_FTRACE)
+PURGATORY_CFLAGS_REMOVE += $(CC_FLAGS_FTRACE)
endif

ifdef CONFIG_STACKPROTECTOR
-CFLAGS_REMOVE_sha256.o += -fstack-protector
-CFLAGS_REMOVE_purgatory.o += -fstack-protector
-CFLAGS_REMOVE_string.o += -fstack-protector
-CFLAGS_REMOVE_kexec-purgatory.o += -fstack-protector
+PURGATORY_CFLAGS_REMOVE += -fstack-protector
endif

ifdef CONFIG_STACKPROTECTOR_STRONG
-CFLAGS_REMOVE_sha256.o += -fstack-protector-strong
-CFLAGS_REMOVE_purgatory.o += -fstack-protector-strong
-CFLAGS_REMOVE_string.o += -fstack-protector-strong
-CFLAGS_REMOVE_kexec-purgatory.o += -fstack-protector-strong
+PURGATORY_CFLAGS_REMOVE += -fstack-protector-strong
endif

ifdef CONFIG_RETPOLINE
-CFLAGS_REMOVE_sha256.o += $(RETPOLINE_CFLAGS)
-CFLAGS_REMOVE_purgatory.o += $(RETPOLINE_CFLAGS)
-CFLAGS_REMOVE_string.o += $(RETPOLINE_CFLAGS)
-CFLAGS_REMOVE_kexec-purgatory.o += $(RETPOLINE_CFLAGS)
+PURGATORY_CFLAGS_REMOVE += $(RETPOLINE_CFLAGS)
endif

+CFLAGS_REMOVE_purgatory.o += $(PURGATORY_CFLAGS_REMOVE)
+CFLAGS_purgatory.o += $(PURGATORY_CFLAGS)
+
+CFLAGS_REMOVE_sha256.o += $(PURGATORY_CFLAGS_REMOVE)
+CFLAGS_sha256.o += $(PURGATORY_CFLAGS)
+
+CFLAGS_REMOVE_string.o += $(PURGATORY_CFLAGS_REMOVE)
+CFLAGS_string.o += $(PURGATORY_CFLAGS)
+
$(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
$(call if_changed,ld)



2019-09-18 06:32:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 77/85] modules: fix BUG when load module with rodata=n

From: Yang Yingliang <[email protected]>

commit 2eef1399a866c57687962e15142b141a4f8e7862 upstream.

When loading a module with rodata=n, it causes an executing
NX-protected page BUG.

[ 32.379191] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[ 32.382917] BUG: unable to handle page fault for address: ffffffffc0005000
[ 32.385947] #PF: supervisor instruction fetch in kernel mode
[ 32.387662] #PF: error_code(0x0011) - permissions violation
[ 32.389352] PGD 240c067 P4D 240c067 PUD 240e067 PMD 421a52067 PTE 8000000421a53063
[ 32.391396] Oops: 0011 [#1] SMP PTI
[ 32.392478] CPU: 7 PID: 2697 Comm: insmod Tainted: G O 5.2.0-rc5+ #202
[ 32.394588] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[ 32.398157] RIP: 0010:ko_test_init+0x0/0x1000 [ko_test]
[ 32.399662] Code: Bad RIP value.
[ 32.400621] RSP: 0018:ffffc900029f3ca8 EFLAGS: 00010246
[ 32.402171] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 32.404332] RDX: 00000000000004c7 RSI: 0000000000000cc0 RDI: ffffffffc0005000
[ 32.406347] RBP: ffffffffc0005000 R08: ffff88842fbebc40 R09: ffffffff810ede4a
[ 32.408392] R10: ffffea00108e3480 R11: 0000000000000000 R12: ffff88842bee21a0
[ 32.410472] R13: 0000000000000001 R14: 0000000000000001 R15: ffffc900029f3e78
[ 32.412609] FS: 00007fb4f0c0a700(0000) GS:ffff88842fbc0000(0000) knlGS:0000000000000000
[ 32.414722] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 32.416290] CR2: ffffffffc0004fd6 CR3: 0000000421a90004 CR4: 0000000000020ee0
[ 32.418471] Call Trace:
[ 32.419136] do_one_initcall+0x41/0x1df
[ 32.420199] ? _cond_resched+0x10/0x40
[ 32.421433] ? kmem_cache_alloc_trace+0x36/0x160
[ 32.422827] do_init_module+0x56/0x1f7
[ 32.423946] load_module+0x1e67/0x2580
[ 32.424947] ? __alloc_pages_nodemask+0x150/0x2c0
[ 32.426413] ? map_vm_area+0x2d/0x40
[ 32.427530] ? __vmalloc_node_range+0x1ef/0x260
[ 32.428850] ? __do_sys_init_module+0x135/0x170
[ 32.430060] ? _cond_resched+0x10/0x40
[ 32.431249] __do_sys_init_module+0x135/0x170
[ 32.432547] do_syscall_64+0x43/0x120
[ 32.433853] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Because if rodata=n, set_memory_x() can't be called, fix this by
calling set_memory_x in complete_formation();

Fixes: f2c65fb3221a ("x86/modules: Avoid breaking W^X while loading modules")
Suggested-by: Jian Cheng <[email protected]>
Reviewed-by: Nadav Amit <[email protected]>
Signed-off-by: Yang Yingliang <[email protected]>
Signed-off-by: Jessica Yu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/module.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)

--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1961,13 +1961,9 @@ void module_enable_ro(const struct modul
set_vm_flush_reset_perms(mod->core_layout.base);
set_vm_flush_reset_perms(mod->init_layout.base);
frob_text(&mod->core_layout, set_memory_ro);
- frob_text(&mod->core_layout, set_memory_x);

frob_rodata(&mod->core_layout, set_memory_ro);
-
frob_text(&mod->init_layout, set_memory_ro);
- frob_text(&mod->init_layout, set_memory_x);
-
frob_rodata(&mod->init_layout, set_memory_ro);

if (after_init)
@@ -2030,6 +2026,12 @@ void set_all_modules_text_ro(void)
static void module_enable_nx(const struct module *mod) { }
#endif

+static void module_enable_x(const struct module *mod)
+{
+ frob_text(&mod->core_layout, set_memory_x);
+ frob_text(&mod->init_layout, set_memory_x);
+}
+
#ifdef CONFIG_LIVEPATCH
/*
* Persist Elf information about a module. Copy the Elf header,
@@ -3626,6 +3628,7 @@ static int complete_formation(struct mod

module_enable_ro(mod, false);
module_enable_nx(mod);
+ module_enable_x(mod);

/* Mark state as coming so strong_try_module_get() ignores us,
* but kallsyms etc. can see us. */


2019-09-18 06:33:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 37/85] ixgbe: fix double clean of Tx descriptors with xdp

From: Ilya Maximets <[email protected]>

commit bf280c0387ebbf8eebad1036fca8f7b85ebfde32 upstream.

Tx code doesn't clear the descriptors' status after cleaning.
So, if the budget is larger than number of used elems in a ring, some
descriptors will be accounted twice and xsk_umem_complete_tx will move
prod_tail far beyond the prod_head breaking the completion queue ring.

Fix that by limiting the number of descriptors to clean by the number
of used descriptors in the Tx ring.

'ixgbe_clean_xdp_tx_irq()' function refactored to look more like
'ixgbe_xsk_clean_tx_ring()' since we're allowed to directly use
'next_to_clean' and 'next_to_use' indexes.

CC: [email protected]
Fixes: 8221c5eba8c1 ("ixgbe: add AF_XDP zero-copy Tx support")
Signed-off-by: Ilya Maximets <[email protected]>
Tested-by: William Tu <[email protected]>
Tested-by: Eelco Chaudron <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 29 ++++++++++-----------------
1 file changed, 11 insertions(+), 18 deletions(-)

--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
@@ -679,19 +679,17 @@ static void ixgbe_clean_xdp_tx_buffer(st
bool ixgbe_clean_xdp_tx_irq(struct ixgbe_q_vector *q_vector,
struct ixgbe_ring *tx_ring, int napi_budget)
{
+ u16 ntc = tx_ring->next_to_clean, ntu = tx_ring->next_to_use;
unsigned int total_packets = 0, total_bytes = 0;
- u32 i = tx_ring->next_to_clean, xsk_frames = 0;
- unsigned int budget = q_vector->tx.work_limit;
struct xdp_umem *umem = tx_ring->xsk_umem;
union ixgbe_adv_tx_desc *tx_desc;
struct ixgbe_tx_buffer *tx_bi;
- bool xmit_done;
+ u32 xsk_frames = 0;

- tx_bi = &tx_ring->tx_buffer_info[i];
- tx_desc = IXGBE_TX_DESC(tx_ring, i);
- i -= tx_ring->count;
+ tx_bi = &tx_ring->tx_buffer_info[ntc];
+ tx_desc = IXGBE_TX_DESC(tx_ring, ntc);

- do {
+ while (ntc != ntu) {
if (!(tx_desc->wb.status & cpu_to_le32(IXGBE_TXD_STAT_DD)))
break;

@@ -708,22 +706,18 @@ bool ixgbe_clean_xdp_tx_irq(struct ixgbe

tx_bi++;
tx_desc++;
- i++;
- if (unlikely(!i)) {
- i -= tx_ring->count;
+ ntc++;
+ if (unlikely(ntc == tx_ring->count)) {
+ ntc = 0;
tx_bi = tx_ring->tx_buffer_info;
tx_desc = IXGBE_TX_DESC(tx_ring, 0);
}

/* issue prefetch for next Tx descriptor */
prefetch(tx_desc);
+ }

- /* update budget accounting */
- budget--;
- } while (likely(budget));
-
- i += tx_ring->count;
- tx_ring->next_to_clean = i;
+ tx_ring->next_to_clean = ntc;

u64_stats_update_begin(&tx_ring->syncp);
tx_ring->stats.bytes += total_bytes;
@@ -735,8 +729,7 @@ bool ixgbe_clean_xdp_tx_irq(struct ixgbe
if (xsk_frames)
xsk_umem_complete_tx(umem, xsk_frames);

- xmit_done = ixgbe_xmit_zc(tx_ring, q_vector->tx.work_limit);
- return budget > 0 && xmit_done;
+ return ixgbe_xmit_zc(tx_ring, q_vector->tx.work_limit);
}

int ixgbe_xsk_async_xmit(struct net_device *dev, u32 qid)


2019-09-18 06:33:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 05/85] ixgbe: Fix secpath usage for IPsec TX offload.

From: Steffen Klassert <[email protected]>

[ Upstream commit f39b683d35dfa93a58f1b400a8ec0ff81296b37c ]

The ixgbe driver currently does IPsec TX offloading
based on an existing secpath. However, the secpath
can also come from the RX side, in this case it is
misinterpreted for TX offload and the packets are
dropped with a "bad sa_idx" error. Fix this by using
the xfrm_offload() function to test for TX offload.

Fixes: 592594704761 ("ixgbe: process the Tx ipsec offload")
Reported-by: Michael Marley <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -36,6 +36,7 @@
#include <net/vxlan.h>
#include <net/mpls.h>
#include <net/xdp_sock.h>
+#include <net/xfrm.h>

#include "ixgbe.h"
#include "ixgbe_common.h"
@@ -8691,7 +8692,7 @@ netdev_tx_t ixgbe_xmit_frame_ring(struct
#endif /* IXGBE_FCOE */

#ifdef CONFIG_IXGBE_IPSEC
- if (secpath_exists(skb) &&
+ if (xfrm_offload(skb) &&
!ixgbe_ipsec_tx(tx_ring, first, &ipsec_tx))
goto out_drop;
#endif


2019-09-18 06:33:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 29/85] Revert "mmc: sdhci: Remove unneeded quirk2 flag of O2 SD host controller"

From: Daniel Drake <[email protected]>

commit 49baa01c8b99ef92958e18fb58ebeb5dfdcde8af upstream.

This reverts commit 414126f9e5abf1973c661d24229543a9458fa8ce.

This commit broke eMMC storage access on a new consumer MiniPC based on
AMD SoC, which has eMMC connected to:

02:00.0 SD Host controller: O2 Micro, Inc. Device 8620 (rev 01) (prog-if 01)
Subsystem: O2 Micro, Inc. Device 0002

During probe, several errors are seen including:

mmc1: Got data interrupt 0x02000000 even though no data operation was in progress.
mmc1: Timeout waiting for hardware interrupt.
mmc1: error -110 whilst initialising MMC card

Reverting this commit allows the eMMC storage to be detected & usable
again.

Signed-off-by: Daniel Drake <[email protected]>
Fixes: 414126f9e5ab ("mmc: sdhci: Remove unneeded quirk2 flag of O2 SD host
controller")
Cc: [email protected] # v5.1+
Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/mmc/host/sdhci-pci-o2micro.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/mmc/host/sdhci-pci-o2micro.c
+++ b/drivers/mmc/host/sdhci-pci-o2micro.c
@@ -432,7 +432,6 @@ int sdhci_pci_o2_probe_slot(struct sdhci
mmc_hostname(host->mmc));
host->flags &= ~SDHCI_SIGNALING_330;
host->flags |= SDHCI_SIGNALING_180;
- host->quirks2 |= SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD;
host->mmc->caps2 |= MMC_CAP2_NO_SD;
host->mmc->caps2 |= MMC_CAP2_NO_SDIO;
pci_write_config_dword(chip->pdev,
@@ -682,6 +681,7 @@ static const struct sdhci_ops sdhci_pci_
const struct sdhci_pci_fixes sdhci_o2 = {
.probe = sdhci_pci_o2_probe,
.quirks = SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
+ .quirks2 = SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD,
.probe_slot = sdhci_pci_o2_probe_slot,
#ifdef CONFIG_PM_SLEEP
.resume = sdhci_pci_o2_resume,


2019-09-18 06:33:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 25/85] gpio: fix line flag validation in lineevent_create

From: Kent Gibson <[email protected]>

commit 5ca2f54b597c816df54ff1b28eb99cf7262b955d upstream.

lineevent_create should not allow any of GPIOHANDLE_REQUEST_OUTPUT,
GPIOHANDLE_REQUEST_OPEN_DRAIN or GPIOHANDLE_REQUEST_OPEN_SOURCE to be set.

Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines")
Cc: stable <[email protected]>
Signed-off-by: Kent Gibson <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpio/gpiolib.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)

--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -934,7 +934,9 @@ static int lineevent_create(struct gpio_
}

/* This is just wrong: we don't look for events on output lines */
- if (lflags & GPIOHANDLE_REQUEST_OUTPUT) {
+ if ((lflags & GPIOHANDLE_REQUEST_OUTPUT) ||
+ (lflags & GPIOHANDLE_REQUEST_OPEN_DRAIN) ||
+ (lflags & GPIOHANDLE_REQUEST_OPEN_SOURCE)) {
ret = -EINVAL;
goto out_free_label;
}
@@ -948,10 +950,6 @@ static int lineevent_create(struct gpio_

if (lflags & GPIOHANDLE_REQUEST_ACTIVE_LOW)
set_bit(FLAG_ACTIVE_LOW, &desc->flags);
- if (lflags & GPIOHANDLE_REQUEST_OPEN_DRAIN)
- set_bit(FLAG_OPEN_DRAIN, &desc->flags);
- if (lflags & GPIOHANDLE_REQUEST_OPEN_SOURCE)
- set_bit(FLAG_OPEN_SOURCE, &desc->flags);

ret = gpiod_direction_input(desc);
if (ret)


2019-09-18 06:33:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 20/85] sctp: fix the missing put_user when dumping transport thresholds

From: Xin Long <[email protected]>

[ Upstream commit f794dc2304d83ab998c2eee5bab0549aff5c53a2 ]

This issue causes SCTP_PEER_ADDR_THLDS sockopt not to be able to dump
a transport thresholds info.

Fix it by adding 'goto' put_user in sctp_getsockopt_paddr_thresholds.

Fixes: 8add543e369d ("sctp: add SCTP_FUTURE_ASSOC for SCTP_PEER_ADDR_THLDS sockopt")
Signed-off-by: Xin Long <[email protected]>
Acked-by: Marcelo Ricardo Leitner <[email protected]>
Acked-by: Neil Horman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sctp/socket.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -7176,7 +7176,7 @@ static int sctp_getsockopt_paddr_thresho
val.spt_pathmaxrxt = trans->pathmaxrxt;
val.spt_pathpfthld = trans->pf_retrans;

- return 0;
+ goto out;
}

asoc = sctp_id2assoc(sk, val.spt_assoc_id);
@@ -7194,6 +7194,7 @@ static int sctp_getsockopt_paddr_thresho
val.spt_pathmaxrxt = sp->pathmaxrxt;
}

+out:
if (put_user(len, optlen) || copy_to_user(optval, &val, len))
return -EFAULT;



2019-09-18 06:33:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 46/85] KVM: x86/mmu: Reintroduce fast invalidate/zap for flushing memslot

From: Sean Christopherson <[email protected]>

commit 002c5f73c508f7df5681bda339831c27f3c1aef4 upstream.

James Harvey reported a livelock that was introduced by commit
d012a06ab1d23 ("Revert "KVM: x86/mmu: Zap only the relevant pages when
removing a memslot"").

The livelock occurs because kvm_mmu_zap_all() as it exists today will
voluntarily reschedule and drop KVM's mmu_lock, which allows other vCPUs
to add shadow pages. With enough vCPUs, kvm_mmu_zap_all() can get stuck
in an infinite loop as it can never zap all pages before observing lock
contention or the need to reschedule. The equivalent of kvm_mmu_zap_all()
that was in use at the time of the reverted commit (4e103134b8623, "KVM:
x86/mmu: Zap only the relevant pages when removing a memslot") employed
a fast invalidate mechanism and was not susceptible to the above livelock.

There are three ways to fix the livelock:

- Reverting the revert (commit d012a06ab1d23) is not a viable option as
the revert is needed to fix a regression that occurs when the guest has
one or more assigned devices. It's unlikely we'll root cause the device
assignment regression soon enough to fix the regression timely.

- Remove the conditional reschedule from kvm_mmu_zap_all(). However, although
removing the reschedule would be a smaller code change, it's less safe
in the sense that the resulting kvm_mmu_zap_all() hasn't been used in
the wild for flushing memslots since the fast invalidate mechanism was
introduced by commit 6ca18b6950f8d ("KVM: x86: use the fast way to
invalidate all pages"), back in 2013.

- Reintroduce the fast invalidate mechanism and use it when zapping shadow
pages in response to a memslot being deleted/moved, which is what this
patch does.

For all intents and purposes, this is a revert of commit ea145aacf4ae8
("Revert "KVM: MMU: fast invalidate all pages"") and a partial revert of
commit 7390de1e99a70 ("Revert "KVM: x86: use the fast way to invalidate
all pages""), i.e. restores the behavior of commit 5304b8d37c2a5 ("KVM:
MMU: fast invalidate all pages") and commit 6ca18b6950f8d ("KVM: x86:
use the fast way to invalidate all pages") respectively.

Fixes: d012a06ab1d23 ("Revert "KVM: x86/mmu: Zap only the relevant pages when removing a memslot"")
Reported-by: James Harvey <[email protected]>
Cc: Alex Willamson <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: [email protected]
Signed-off-by: Sean Christopherson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/include/asm/kvm_host.h | 2
arch/x86/kvm/mmu.c | 101 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 101 insertions(+), 2 deletions(-)

--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -333,6 +333,7 @@ struct kvm_mmu_page {
int root_count; /* Currently serving as active root */
unsigned int unsync_children;
struct kvm_rmap_head parent_ptes; /* rmap pointers to parent sptes */
+ unsigned long mmu_valid_gen;
DECLARE_BITMAP(unsync_child_bitmap, 512);

#ifdef CONFIG_X86_32
@@ -851,6 +852,7 @@ struct kvm_arch {
unsigned long n_requested_mmu_pages;
unsigned long n_max_mmu_pages;
unsigned int indirect_shadow_pages;
+ unsigned long mmu_valid_gen;
struct hlist_head mmu_page_hash[KVM_NUM_MMU_PAGES];
/*
* Hash table of struct kvm_mmu_page.
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2066,6 +2066,12 @@ static struct kvm_mmu_page *kvm_mmu_allo
if (!direct)
sp->gfns = mmu_memory_cache_alloc(&vcpu->arch.mmu_page_cache);
set_page_private(virt_to_page(sp->spt), (unsigned long)sp);
+
+ /*
+ * active_mmu_pages must be a FIFO list, as kvm_zap_obsolete_pages()
+ * depends on valid pages being added to the head of the list. See
+ * comments in kvm_zap_obsolete_pages().
+ */
list_add(&sp->link, &vcpu->kvm->arch.active_mmu_pages);
kvm_mod_used_mmu_pages(vcpu->kvm, +1);
return sp;
@@ -2215,7 +2221,7 @@ static void kvm_mmu_commit_zap_page(stru
#define for_each_valid_sp(_kvm, _sp, _gfn) \
hlist_for_each_entry(_sp, \
&(_kvm)->arch.mmu_page_hash[kvm_page_table_hashfn(_gfn)], hash_link) \
- if ((_sp)->role.invalid) { \
+ if (is_obsolete_sp((_kvm), (_sp)) || (_sp)->role.invalid) { \
} else

#define for_each_gfn_indirect_valid_sp(_kvm, _sp, _gfn) \
@@ -2272,6 +2278,11 @@ static void kvm_mmu_audit(struct kvm_vcp
static void mmu_audit_disable(void) { }
#endif

+static bool is_obsolete_sp(struct kvm *kvm, struct kvm_mmu_page *sp)
+{
+ return unlikely(sp->mmu_valid_gen != kvm->arch.mmu_valid_gen);
+}
+
static bool kvm_sync_page(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp,
struct list_head *invalid_list)
{
@@ -2496,6 +2507,7 @@ static struct kvm_mmu_page *kvm_mmu_get_
if (level > PT_PAGE_TABLE_LEVEL && need_sync)
flush |= kvm_sync_pages(vcpu, gfn, &invalid_list);
}
+ sp->mmu_valid_gen = vcpu->kvm->arch.mmu_valid_gen;
clear_page(sp->spt);
trace_kvm_mmu_get_page(sp, true);

@@ -4229,6 +4241,13 @@ static bool fast_cr3_switch(struct kvm_v
return false;

if (cached_root_available(vcpu, new_cr3, new_role)) {
+ /*
+ * It is possible that the cached previous root page is
+ * obsolete because of a change in the MMU generation
+ * number. However, changing the generation number is
+ * accompanied by KVM_REQ_MMU_RELOAD, which will free
+ * the root set here and allocate a new one.
+ */
kvm_make_request(KVM_REQ_LOAD_CR3, vcpu);
if (!skip_tlb_flush) {
kvm_make_request(KVM_REQ_MMU_SYNC, vcpu);
@@ -5645,11 +5664,89 @@ int kvm_mmu_create(struct kvm_vcpu *vcpu
return alloc_mmu_pages(vcpu);
}

+
+static void kvm_zap_obsolete_pages(struct kvm *kvm)
+{
+ struct kvm_mmu_page *sp, *node;
+ LIST_HEAD(invalid_list);
+ int ign;
+
+restart:
+ list_for_each_entry_safe_reverse(sp, node,
+ &kvm->arch.active_mmu_pages, link) {
+ /*
+ * No obsolete valid page exists before a newly created page
+ * since active_mmu_pages is a FIFO list.
+ */
+ if (!is_obsolete_sp(kvm, sp))
+ break;
+
+ /*
+ * Do not repeatedly zap a root page to avoid unnecessary
+ * KVM_REQ_MMU_RELOAD, otherwise we may not be able to
+ * progress:
+ * vcpu 0 vcpu 1
+ * call vcpu_enter_guest():
+ * 1): handle KVM_REQ_MMU_RELOAD
+ * and require mmu-lock to
+ * load mmu
+ * repeat:
+ * 1): zap root page and
+ * send KVM_REQ_MMU_RELOAD
+ *
+ * 2): if (cond_resched_lock(mmu-lock))
+ *
+ * 2): hold mmu-lock and load mmu
+ *
+ * 3): see KVM_REQ_MMU_RELOAD bit
+ * on vcpu->requests is set
+ * then return 1 to call
+ * vcpu_enter_guest() again.
+ * goto repeat;
+ *
+ * Since we are reversely walking the list and the invalid
+ * list will be moved to the head, skip the invalid page
+ * can help us to avoid the infinity list walking.
+ */
+ if (sp->role.invalid)
+ continue;
+
+ if (need_resched() || spin_needbreak(&kvm->mmu_lock)) {
+ kvm_mmu_commit_zap_page(kvm, &invalid_list);
+ cond_resched_lock(&kvm->mmu_lock);
+ goto restart;
+ }
+
+ if (__kvm_mmu_prepare_zap_page(kvm, sp, &invalid_list, &ign))
+ goto restart;
+ }
+
+ kvm_mmu_commit_zap_page(kvm, &invalid_list);
+}
+
+/*
+ * Fast invalidate all shadow pages and use lock-break technique
+ * to zap obsolete pages.
+ *
+ * It's required when memslot is being deleted or VM is being
+ * destroyed, in these cases, we should ensure that KVM MMU does
+ * not use any resource of the being-deleted slot or all slots
+ * after calling the function.
+ */
+static void kvm_mmu_zap_all_fast(struct kvm *kvm)
+{
+ spin_lock(&kvm->mmu_lock);
+ kvm->arch.mmu_valid_gen++;
+
+ kvm_zap_obsolete_pages(kvm);
+ spin_unlock(&kvm->mmu_lock);
+}
+
static void kvm_mmu_invalidate_zap_pages_in_memslot(struct kvm *kvm,
struct kvm_memory_slot *slot,
struct kvm_page_track_notifier_node *node)
{
- kvm_mmu_zap_all(kvm);
+ kvm_mmu_zap_all_fast(kvm);
}

void kvm_mmu_init_vm(struct kvm *kvm)


2019-09-18 06:33:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 17/85] net-ipv6: fix excessive RTF_ADDRCONF flag on ::1/128 local route (and others)

From: "Maciej Żenczykowski" <[email protected]>

[ Upstream commit d55a2e374a94fa34a3048c6a2be535266e506d97 ]

There is a subtle change in behaviour introduced by:
commit c7a1ce397adacaf5d4bb2eab0a738b5f80dc3e43
'ipv6: Change addrconf_f6i_alloc to use ip6_route_info_create'

Before that patch /proc/net/ipv6_route includes:
00000000000000000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000003 00000000 80200001 lo

Afterwards /proc/net/ipv6_route includes:
00000000000000000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00000000 80240001 lo

ie. the above commit causes the ::1/128 local (automatic) route to be flagged with RTF_ADDRCONF (0x040000).

AFAICT, this is incorrect since these routes are *not* coming from RA's.

As such, this patch restores the old behaviour.

Fixes: c7a1ce397ada ("ipv6: Change addrconf_f6i_alloc to use ip6_route_info_create")
Cc: David Ahern <[email protected]>
Cc: Lorenzo Colitti <[email protected]>
Signed-off-by: Maciej Żenczykowski <[email protected]>
Reviewed-by: David Ahern <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/route.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3841,13 +3841,14 @@ struct fib6_info *addrconf_f6i_alloc(str
struct fib6_config cfg = {
.fc_table = l3mdev_fib_table(idev->dev) ? : RT6_TABLE_LOCAL,
.fc_ifindex = idev->dev->ifindex,
- .fc_flags = RTF_UP | RTF_ADDRCONF | RTF_NONEXTHOP,
+ .fc_flags = RTF_UP | RTF_NONEXTHOP,
.fc_dst = *addr,
.fc_dst_len = 128,
.fc_protocol = RTPROT_KERNEL,
.fc_nlinfo.nl_net = net,
.fc_ignore_dev_down = true,
};
+ struct fib6_info *f6i;

if (anycast) {
cfg.fc_type = RTN_ANYCAST;
@@ -3857,7 +3858,10 @@ struct fib6_info *addrconf_f6i_alloc(str
cfg.fc_flags |= RTF_LOCAL;
}

- return ip6_route_info_create(&cfg, gfp_flags, NULL);
+ f6i = ip6_route_info_create(&cfg, gfp_flags, NULL);
+ if (f6i)
+ f6i->dst_nocount = true;
+ return f6i;
}

/* remove deleted ip from prefsrc entries */


2019-09-18 06:33:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 42/85] regulator: twl: voltage lists for vdd1/2 on twl4030

From: Andreas Kemnade <[email protected]>

commit 3829100a63724f6dbf264b2a7f06e7f638ed952d upstream.

_opp_supported_by_regulators() wrongly ignored errors from
regulator_is_supported_voltage(), so it considered errors as
success. Since
commit 498209445124 ("regulator: core: simplify return value on suported_voltage")
regulator_is_supported_voltage() returns a real boolean, so
errors make _opp_supported_by_regulators() return false.

That reveals a problem with the declaration of the VDD1/2
regulators on twl4030.
The VDD1/VDD2 regulators on twl4030 are neither defined with
voltage lists nor with the continuous flag set, so
regulator_is_supported_voltage() returns false and an error
before above mentioned commit (which was considered success)
The result is that after the above mentioned commit cpufreq
does not work properly e.g. dm3730.

[ 2.490997] core: _opp_supported_by_regulators: OPP minuV: 1012500 maxuV: 1012500, not supported by regulator
[ 2.501617] cpu cpu0: _opp_add: OPP not supported by regulators (300000000)
[ 2.509246] core: _opp_supported_by_regulators: OPP minuV: 1200000 maxuV: 1200000, not supported by regulator
[ 2.519775] cpu cpu0: _opp_add: OPP not supported by regulators (600000000)
[ 2.527313] core: _opp_supported_by_regulators: OPP minuV: 1325000 maxuV: 1325000, not supported by regulator
[ 2.537750] cpu cpu0: _opp_add: OPP not supported by regulators (800000000)

The patch fixes declaration of VDD1/2 regulators by
adding proper voltage lists.

Fixes: 498209445124 ("regulator: core: simplify return value on suported_voltage")
Cc: [email protected]
Signed-off-by: Andreas Kemnade <[email protected]>
Tested-by: Adam Ford <[email protected]> #logicpd-torpedo-37xx-devkit
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/regulator/twl-regulator.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)

--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -359,6 +359,17 @@ static const u16 VINTANA2_VSEL_table[] =
2500, 2750,
};

+/* 600mV to 1450mV in 12.5 mV steps */
+static const struct regulator_linear_range VDD1_ranges[] = {
+ REGULATOR_LINEAR_RANGE(600000, 0, 68, 12500)
+};
+
+/* 600mV to 1450mV in 12.5 mV steps, everything above = 1500mV */
+static const struct regulator_linear_range VDD2_ranges[] = {
+ REGULATOR_LINEAR_RANGE(600000, 0, 68, 12500),
+ REGULATOR_LINEAR_RANGE(1500000, 69, 69, 12500)
+};
+
static int twl4030ldo_list_voltage(struct regulator_dev *rdev, unsigned index)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
@@ -427,6 +438,8 @@ static int twl4030smps_get_voltage(struc
}

static const struct regulator_ops twl4030smps_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+
.set_voltage = twl4030smps_set_voltage,
.get_voltage = twl4030smps_get_voltage,
};
@@ -466,7 +479,8 @@ static const struct twlreg_info TWL4030_
}, \
}

-#define TWL4030_ADJUSTABLE_SMPS(label, offset, num, turnon_delay, remap_conf) \
+#define TWL4030_ADJUSTABLE_SMPS(label, offset, num, turnon_delay, remap_conf, \
+ n_volt) \
static const struct twlreg_info TWL4030_INFO_##label = { \
.base = offset, \
.id = num, \
@@ -479,6 +493,9 @@ static const struct twlreg_info TWL4030_
.owner = THIS_MODULE, \
.enable_time = turnon_delay, \
.of_map_mode = twl4030reg_map_mode, \
+ .n_voltages = n_volt, \
+ .n_linear_ranges = ARRAY_SIZE(label ## _ranges), \
+ .linear_ranges = label ## _ranges, \
}, \
}

@@ -518,8 +535,8 @@ TWL4030_ADJUSTABLE_LDO(VSIM, 0x37, 9, 10
TWL4030_ADJUSTABLE_LDO(VDAC, 0x3b, 10, 100, 0x08);
TWL4030_ADJUSTABLE_LDO(VINTANA2, 0x43, 12, 100, 0x08);
TWL4030_ADJUSTABLE_LDO(VIO, 0x4b, 14, 1000, 0x08);
-TWL4030_ADJUSTABLE_SMPS(VDD1, 0x55, 15, 1000, 0x08);
-TWL4030_ADJUSTABLE_SMPS(VDD2, 0x63, 16, 1000, 0x08);
+TWL4030_ADJUSTABLE_SMPS(VDD1, 0x55, 15, 1000, 0x08, 68);
+TWL4030_ADJUSTABLE_SMPS(VDD2, 0x63, 16, 1000, 0x08, 69);
/* VUSBCP is managed *only* by the USB subchip */
TWL4030_FIXED_LDO(VINTANA1, 0x3f, 1500, 11, 100, 0x08);
TWL4030_FIXED_LDO(VINTDIG, 0x47, 1500, 13, 100, 0x08);


2019-09-18 06:33:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 79/85] modules: always page-align module section allocations

From: Jessica Yu <[email protected]>

commit 38f054d549a869f22a02224cd276a27bf14b6171 upstream.

Some arches (e.g., arm64, x86) have moved towards non-executable
module_alloc() allocations for security hardening reasons. That means
that the module loader will need to set the text section of a module to
executable, regardless of whether or not CONFIG_STRICT_MODULE_RWX is set.

When CONFIG_STRICT_MODULE_RWX=y, module section allocations are always
page-aligned to handle memory rwx permissions. On some arches with
CONFIG_STRICT_MODULE_RWX=n however, when setting the module text to
executable, the BUG_ON() in frob_text() gets triggered since module
section allocations are not page-aligned when CONFIG_STRICT_MODULE_RWX=n.
Since the set_memory_* API works with pages, and since we need to call
set_memory_x() regardless of whether CONFIG_STRICT_MODULE_RWX is set, we
might as well page-align all module section allocations for ease of
managing rwx permissions of module sections (text, rodata, etc).

Fixes: 2eef1399a866 ("modules: fix BUG when load module with rodata=n")
Reported-by: Martin Kaiser <[email protected]>
Reported-by: Bartosz Golaszewski <[email protected]>
Tested-by: David Lechner <[email protected]>
Tested-by: Martin Kaiser <[email protected]>
Tested-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Jessica Yu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/module.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)

--- a/kernel/module.c
+++ b/kernel/module.c
@@ -64,14 +64,9 @@

/*
* Modules' sections will be aligned on page boundaries
- * to ensure complete separation of code and data, but
- * only when CONFIG_STRICT_MODULE_RWX=y
+ * to ensure complete separation of code and data
*/
-#ifdef CONFIG_STRICT_MODULE_RWX
# define debug_align(X) ALIGN(X, PAGE_SIZE)
-#else
-# define debug_align(X) (X)
-#endif

/* If this is set, the section belongs in the init part of the module */
#define INIT_OFFSET_MASK (1UL << (BITS_PER_LONG-1))


2019-09-18 06:33:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 14/85] tcp: fix tcp_ecn_withdraw_cwr() to clear TCP_ECN_QUEUE_CWR

From: Neal Cardwell <[email protected]>

[ Upstream commit af38d07ed391b21f7405fa1f936ca9686787d6d2 ]

Fix tcp_ecn_withdraw_cwr() to clear the correct bit:
TCP_ECN_QUEUE_CWR.

Rationale: basically, TCP_ECN_DEMAND_CWR is a bit that is purely about
the behavior of data receivers, and deciding whether to reflect
incoming IP ECN CE marks as outgoing TCP th->ece marks. The
TCP_ECN_QUEUE_CWR bit is purely about the behavior of data senders,
and deciding whether to send CWR. The tcp_ecn_withdraw_cwr() function
is only called from tcp_undo_cwnd_reduction() by data senders during
an undo, so it should zero the sender-side state,
TCP_ECN_QUEUE_CWR. It does not make sense to stop the reflection of
incoming CE bits on incoming data packets just because outgoing
packets were spuriously retransmitted.

The bug has been reproduced with packetdrill to manifest in a scenario
with RFC3168 ECN, with an incoming data packet with CE bit set and
carrying a TCP timestamp value that causes cwnd undo. Before this fix,
the IP CE bit was ignored and not reflected in the TCP ECE header bit,
and sender sent a TCP CWR ('W') bit on the next outgoing data packet,
even though the cwnd reduction had been undone. After this fix, the
sender properly reflects the CE bit and does not set the W bit.

Note: the bug actually predates 2005 git history; this Fixes footer is
chosen to be the oldest SHA1 I have tested (from Sep 2007) for which
the patch applies cleanly (since before this commit the code was in a
.h file).

Fixes: bdf1ee5d3bd3 ("[TCP]: Move code from tcp_ecn.h to tcp*.c and tcp.h & remove it")
Signed-off-by: Neal Cardwell <[email protected]>
Acked-by: Yuchung Cheng <[email protected]>
Acked-by: Soheil Hassas Yeganeh <[email protected]>
Cc: Eric Dumazet <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/tcp_input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -266,7 +266,7 @@ static void tcp_ecn_accept_cwr(struct so

static void tcp_ecn_withdraw_cwr(struct tcp_sock *tp)
{
- tp->ecn_flags &= ~TCP_ECN_DEMAND_CWR;
+ tp->ecn_flags &= ~TCP_ECN_QUEUE_CWR;
}

static void __tcp_ecn_check_ce(struct sock *sk, const struct sk_buff *skb)


2019-09-18 06:34:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 11/85] sch_hhf: ensure quantum and hhf_non_hh_weight are non-zero

From: Cong Wang <[email protected]>

[ Upstream commit d4d6ec6dac07f263f06d847d6f732d6855522845 ]

In case of TCA_HHF_NON_HH_WEIGHT or TCA_HHF_QUANTUM is zero,
it would make no progress inside the loop in hhf_dequeue() thus
kernel would get stuck.

Fix this by checking this corner case in hhf_change().

Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc")
Reported-by: [email protected]
Reported-by: [email protected]
Reported-by: [email protected]
Cc: Jamal Hadi Salim <[email protected]>
Cc: Jiri Pirko <[email protected]>
Cc: Terry Lam <[email protected]>
Signed-off-by: Cong Wang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sched/sch_hhf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/sched/sch_hhf.c
+++ b/net/sched/sch_hhf.c
@@ -531,7 +531,7 @@ static int hhf_change(struct Qdisc *sch,
new_hhf_non_hh_weight = nla_get_u32(tb[TCA_HHF_NON_HH_WEIGHT]);

non_hh_quantum = (u64)new_quantum * new_hhf_non_hh_weight;
- if (non_hh_quantum > INT_MAX)
+ if (non_hh_quantum == 0 || non_hh_quantum > INT_MAX)
return -EINVAL;

sch_tree_lock(sch);


2019-09-18 06:34:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 22/85] gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist

From: Hans de Goede <[email protected]>

commit 61f7f7c8f978b1c0d80e43c83b7d110ca0496eb4 upstream.

Another day; another DSDT bug we need to workaround...

Since commit ca876c7483b6 ("gpiolib-acpi: make sure we trigger edge events
at least once on boot") we call _AEI edge handlers at boot.

In some rare cases this causes problems. One example of this is the Minix
Neo Z83-4 mini PC, this device has a clear DSDT bug where it has some copy
and pasted code for dealing with Micro USB-B connector host/device role
switching, while the mini PC does not even have a micro-USB connector.
This code, which should not be there, messes with the DDC data pin from
the HDMI connector (switching it to GPIO mode) breaking HDMI support.

To avoid problems like this, this commit adds a new
gpiolib_acpi.run_edge_events_on_boot kernel commandline option, which
allows disabling the running of _AEI edge event handlers at boot.

The default value is -1/auto which uses a DMI based blacklist, the initial
version of this blacklist contains the Neo Z83-4 fixing the HDMI breakage.

Cc: [email protected]
Cc: Daniel Drake <[email protected]>
Cc: Ian W MORRISON <[email protected]>
Reported-by: Ian W MORRISON <[email protected]>
Suggested-by: Ian W MORRISON <[email protected]>
Fixes: ca876c7483b6 ("gpiolib-acpi: make sure we trigger edge events at least once on boot")
Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Mika Westerberg <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Tested-by: Ian W MORRISON <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpio/gpiolib-acpi.c | 42 ++++++++++++++++++++++++++++++++++++++----
1 file changed, 38 insertions(+), 4 deletions(-)

--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -7,6 +7,7 @@
* Mika Westerberg <[email protected]>
*/

+#include <linux/dmi.h>
#include <linux/errno.h>
#include <linux/gpio/consumer.h>
#include <linux/gpio/driver.h>
@@ -19,6 +20,11 @@

#include "gpiolib.h"

+static int run_edge_events_on_boot = -1;
+module_param(run_edge_events_on_boot, int, 0444);
+MODULE_PARM_DESC(run_edge_events_on_boot,
+ "Run edge _AEI event-handlers at boot: 0=no, 1=yes, -1=auto");
+
/**
* struct acpi_gpio_event - ACPI GPIO event handler data
*
@@ -170,10 +176,13 @@ static void acpi_gpiochip_request_irq(st
event->irq_requested = true;

/* Make sure we trigger the initial state of edge-triggered IRQs */
- value = gpiod_get_raw_value_cansleep(event->desc);
- if (((event->irqflags & IRQF_TRIGGER_RISING) && value == 1) ||
- ((event->irqflags & IRQF_TRIGGER_FALLING) && value == 0))
- event->handler(event->irq, event);
+ if (run_edge_events_on_boot &&
+ (event->irqflags & (IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING))) {
+ value = gpiod_get_raw_value_cansleep(event->desc);
+ if (((event->irqflags & IRQF_TRIGGER_RISING) && value == 1) ||
+ ((event->irqflags & IRQF_TRIGGER_FALLING) && value == 0))
+ event->handler(event->irq, event);
+ }
}

static void acpi_gpiochip_request_irqs(struct acpi_gpio_chip *acpi_gpio)
@@ -1283,3 +1292,28 @@ static int acpi_gpio_handle_deferred_req
}
/* We must use _sync so that this runs after the first deferred_probe run */
late_initcall_sync(acpi_gpio_handle_deferred_request_irqs);
+
+static const struct dmi_system_id run_edge_events_on_boot_blacklist[] = {
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "MINIX"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Z83-4"),
+ }
+ },
+ {} /* Terminating entry */
+};
+
+static int acpi_gpio_setup_params(void)
+{
+ if (run_edge_events_on_boot < 0) {
+ if (dmi_check_system(run_edge_events_on_boot_blacklist))
+ run_edge_events_on_boot = 0;
+ else
+ run_edge_events_on_boot = 1;
+ }
+
+ return 0;
+}
+
+/* Directly after dmi_setup() which runs as core_initcall() */
+postcore_initcall(acpi_gpio_setup_params);


2019-09-18 06:34:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 32/85] drm/lima: fix lima_gem_wait() return value

From: Vasily Khoruzhick <[email protected]>

commit 21670bd78a25001cf8ef2679b378c73fb73b904f upstream.

drm_gem_reservation_object_wait() returns 0 if it succeeds and -ETIME
if it timeouts, but lima driver assumed that 0 is error.

Cc: [email protected]
Fixes: a1d2a6339961e ("drm/lima: driver for ARM Mali4xx GPUs")
Signed-off-by: Vasily Khoruzhick <[email protected]>
Signed-off-by: Qiang Yu <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/lima/lima_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@ -342,7 +342,7 @@ int lima_gem_wait(struct drm_file *file,
timeout = drm_timeout_abs_to_jiffies(timeout_ns);

ret = drm_gem_reservation_object_wait(file, handle, write, timeout);
- if (ret == 0)
+ if (ret == -ETIME)
ret = timeout ? -ETIMEDOUT : -EBUSY;

return ret;


2019-09-18 06:34:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 28/85] Revert "mmc: bcm2835: Terminate timeout work synchronously"

From: Stefan Wahren <[email protected]>

commit aea64b583601aa5e0d6ea51a0420e46e43710bd4 upstream.

The commit 37fefadee8bb ("mmc: bcm2835: Terminate timeout work
synchronously") causes lockups in case of hardware timeouts due the
timeout work also calling cancel_delayed_work_sync() on its own.
So revert it.

Fixes: 37fefadee8bb ("mmc: bcm2835: Terminate timeout work synchronously")
Cc: [email protected]
Signed-off-by: Stefan Wahren <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/mmc/host/bcm2835.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/mmc/host/bcm2835.c
+++ b/drivers/mmc/host/bcm2835.c
@@ -597,7 +597,7 @@ static void bcm2835_finish_request(struc
struct dma_chan *terminate_chan = NULL;
struct mmc_request *mrq;

- cancel_delayed_work_sync(&host->timeout_work);
+ cancel_delayed_work(&host->timeout_work);

mrq = host->mrq;



2019-09-18 06:34:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 59/85] mtd: rawnand: mtk: Fix wrongly assigned OOB buffer pointer issue

From: Xiaolei Li <[email protected]>

commit 336d4b138be2dad372b67a2388e42805c48aaa38 upstream.

One main goal of the function mtk_nfc_update_ecc_stats is to check
whether sectors are all empty. If they are empty, set these sectors's
data buffer and OOB buffer as 0xff.

But now, the sector OOB buffer pointer is wrongly assigned. We always
do memset from sector 0.

To fix this issue, pass start sector number to make OOB buffer pointer
be properly assigned.

Fixes: 1d6b1e464950 ("mtd: mediatek: driver for MTK Smart Device")
Signed-off-by: Xiaolei Li <[email protected]>
Reviewed-by: Miquel Raynal <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/mtd/nand/raw/mtk_nand.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)

--- a/drivers/mtd/nand/raw/mtk_nand.c
+++ b/drivers/mtd/nand/raw/mtk_nand.c
@@ -853,19 +853,21 @@ static int mtk_nfc_write_oob_std(struct
return mtk_nfc_write_page_raw(chip, NULL, 1, page);
}

-static int mtk_nfc_update_ecc_stats(struct mtd_info *mtd, u8 *buf, u32 sectors)
+static int mtk_nfc_update_ecc_stats(struct mtd_info *mtd, u8 *buf, u32 start,
+ u32 sectors)
{
struct nand_chip *chip = mtd_to_nand(mtd);
struct mtk_nfc *nfc = nand_get_controller_data(chip);
struct mtk_nfc_nand_chip *mtk_nand = to_mtk_nand(chip);
struct mtk_ecc_stats stats;
+ u32 reg_size = mtk_nand->fdm.reg_size;
int rc, i;

rc = nfi_readl(nfc, NFI_STA) & STA_EMP_PAGE;
if (rc) {
memset(buf, 0xff, sectors * chip->ecc.size);
for (i = 0; i < sectors; i++)
- memset(oob_ptr(chip, i), 0xff, mtk_nand->fdm.reg_size);
+ memset(oob_ptr(chip, start + i), 0xff, reg_size);
return 0;
}

@@ -885,7 +887,7 @@ static int mtk_nfc_read_subpage(struct m
u32 spare = mtk_nand->spare_per_sector;
u32 column, sectors, start, end, reg;
dma_addr_t addr;
- int bitflips;
+ int bitflips = 0;
size_t len;
u8 *buf;
int rc;
@@ -952,14 +954,11 @@ static int mtk_nfc_read_subpage(struct m
if (rc < 0) {
dev_err(nfc->dev, "subpage done timeout\n");
bitflips = -EIO;
- } else {
- bitflips = 0;
- if (!raw) {
- rc = mtk_ecc_wait_done(nfc->ecc, ECC_DECODE);
- bitflips = rc < 0 ? -ETIMEDOUT :
- mtk_nfc_update_ecc_stats(mtd, buf, sectors);
- mtk_nfc_read_fdm(chip, start, sectors);
- }
+ } else if (!raw) {
+ rc = mtk_ecc_wait_done(nfc->ecc, ECC_DECODE);
+ bitflips = rc < 0 ? -ETIMEDOUT :
+ mtk_nfc_update_ecc_stats(mtd, buf, start, sectors);
+ mtk_nfc_read_fdm(chip, start, sectors);
}

dma_unmap_single(nfc->dev, addr, len, DMA_FROM_DEVICE);


2019-09-18 06:35:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 23/85] gpio: mockup: add missing single_release()

From: Wei Yongjun <[email protected]>

commit 59929d3a2eb6c4abafc5b61a20c98aa8728ec378 upstream.

When using single_open() for opening, single_release() should be
used instead of seq_release(), otherwise there is a memory leak.

Fixes: 2a9e27408e12 ("gpio: mockup: rework debugfs interface")
Cc: stable <[email protected]>
Signed-off-by: Wei Yongjun <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpio/gpio-mockup.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/gpio/gpio-mockup.c
+++ b/drivers/gpio/gpio-mockup.c
@@ -309,6 +309,7 @@ static const struct file_operations gpio
.read = gpio_mockup_debugfs_read,
.write = gpio_mockup_debugfs_write,
.llseek = no_llseek,
+ .release = single_release,
};

static void gpio_mockup_debugfs_setup(struct device *dev,


2019-09-18 06:35:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 21/85] net: sock_map, fix missing ulp check in sock hash case

From: John Fastabend <[email protected]>

[ Upstream commit 44580a0118d3ede95fec4dce32df5f75f73cd663 ]

sock_map and ULP only work together when ULP is loaded after the sock
map is loaded. In the sock_map case we added a check for this to fail
the load if ULP is already set. However, we missed the check on the
sock_hash side.

Add a ULP check to the sock_hash update path.

Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface")
Reported-by: [email protected]
Signed-off-by: John Fastabend <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/core/sock_map.c | 3 +++
1 file changed, 3 insertions(+)

--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -661,6 +661,7 @@ static int sock_hash_update_common(struc
struct sock *sk, u64 flags)
{
struct bpf_htab *htab = container_of(map, struct bpf_htab, map);
+ struct inet_connection_sock *icsk = inet_csk(sk);
u32 key_size = map->key_size, hash;
struct bpf_htab_elem *elem, *elem_new;
struct bpf_htab_bucket *bucket;
@@ -671,6 +672,8 @@ static int sock_hash_update_common(struc
WARN_ON_ONCE(!rcu_read_lock_held());
if (unlikely(flags > BPF_EXIST))
return -EINVAL;
+ if (unlikely(icsk->icsk_ulp_data))
+ return -EINVAL;

link = sk_psock_init_link();
if (!link)


2019-09-18 06:36:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 10/85] net: sched: fix reordering issues

From: Eric Dumazet <[email protected]>

[ Upstream commit b88dd52c62bb5c5d58f0963287f41fd084352c57 ]

Whenever MQ is not used on a multiqueue device, we experience
serious reordering problems. Bisection found the cited
commit.

The issue can be described this way :

- A single qdisc hierarchy is shared by all transmit queues.
(eg : tc qdisc replace dev eth0 root fq_codel)

- When/if try_bulk_dequeue_skb_slow() dequeues a packet targetting
a different transmit queue than the one used to build a packet train,
we stop building the current list and save the 'bad' skb (P1) in a
special queue. (bad_txq)

- When dequeue_skb() calls qdisc_dequeue_skb_bad_txq() and finds this
skb (P1), it checks if the associated transmit queues is still in frozen
state. If the queue is still blocked (by BQL or NIC tx ring full),
we leave the skb in bad_txq and return NULL.

- dequeue_skb() calls q->dequeue() to get another packet (P2)

The other packet can target the problematic queue (that we found
in frozen state for the bad_txq packet), but another cpu just ran
TX completion and made room in the txq that is now ready to accept
new packets.

- Packet P2 is sent while P1 is still held in bad_txq, P1 might be sent
at next round. In practice P2 is the lead of a big packet train
(P2,P3,P4 ...) filling the BQL budget and delaying P1 by many packets :/

To solve this problem, we have to block the dequeue process as long
as the first packet in bad_txq can not be sent. Reordering issues
disappear and no side effects have been seen.

Fixes: a53851e2c321 ("net: sched: explicit locking in gso_cpu fallback")
Signed-off-by: Eric Dumazet <[email protected]>
Cc: John Fastabend <[email protected]>
Acked-by: John Fastabend <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sched/sch_generic.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -46,6 +46,8 @@ EXPORT_SYMBOL(default_qdisc_ops);
* - updates to tree and tree walking are only done under the rtnl mutex.
*/

+#define SKB_XOFF_MAGIC ((struct sk_buff *)1UL)
+
static inline struct sk_buff *__skb_dequeue_bad_txq(struct Qdisc *q)
{
const struct netdev_queue *txq = q->dev_queue;
@@ -71,7 +73,7 @@ static inline struct sk_buff *__skb_dequ
q->q.qlen--;
}
} else {
- skb = NULL;
+ skb = SKB_XOFF_MAGIC;
}
}

@@ -253,8 +255,11 @@ validate:
return skb;

skb = qdisc_dequeue_skb_bad_txq(q);
- if (unlikely(skb))
+ if (unlikely(skb)) {
+ if (skb == SKB_XOFF_MAGIC)
+ return NULL;
goto bulk;
+ }
skb = q->dequeue(q);
if (skb) {
bulk:


2019-09-18 08:52:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 60/85] PCI: Always allow probing with driver_override

From: Alex Williamson <[email protected]>

commit 2d2f4273cbe9058d1f5a518e5e880d27d7b3b30f upstream.

Commit 0e7df22401a3 ("PCI: Add sysfs sriov_drivers_autoprobe to control
VF driver binding") introduced the sriov_drivers_autoprobe attribute
which allows users to prevent the kernel from automatically probing a
driver for new VFs as they are created. This allows VFs to be spawned
without automatically binding the new device to a host driver, such as
in cases where the user intends to use the device only with a meta
driver like vfio-pci. However, the current implementation prevents any
use of drivers_probe with the VF while sriov_drivers_autoprobe=0. This
blocks the now current general practice of setting driver_override
followed by using drivers_probe to bind a device to a specified driver.

The kernel never automatically sets a driver_override therefore it seems
we can assume a driver_override reflects the intent of the user. Also,
probing a device using a driver_override match seems outside the scope
of the 'auto' part of sriov_drivers_autoprobe. Therefore, let's allow
driver_override matches regardless of sriov_drivers_autoprobe, which we
can do by simply testing if a driver_override is set for a device as a
'can probe' condition.

Fixes: 0e7df22401a3 ("PCI: Add sysfs sriov_drivers_autoprobe to control VF driver binding")
Link: https://lore.kernel.org/lkml/[email protected]
Link: https://lore.kernel.org/linux-pci/[email protected]/T/#u
Signed-off-by: Alex Williamson <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pci/pci-driver.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -399,7 +399,8 @@ void __weak pcibios_free_irq(struct pci_
#ifdef CONFIG_PCI_IOV
static inline bool pci_device_can_probe(struct pci_dev *pdev)
{
- return (!pdev->is_virtfn || pdev->physfn->sriov->drivers_autoprobe);
+ return (!pdev->is_virtfn || pdev->physfn->sriov->drivers_autoprobe ||
+ pdev->driver_override);
}
#else
static inline bool pci_device_can_probe(struct pci_dev *pdev)


2019-09-18 08:52:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 64/85] crypto: talitos - fix CTR alg blocksize

From: Christophe Leroy <[email protected]>

commit b9a05b6041cb9810a291315569b2af0d63c3680a upstream.

CTR has a blocksize of 1.

Signed-off-by: Christophe Leroy <[email protected]>
Fixes: 5e75ae1b3cef ("crypto: talitos - add new crypto modes")
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/crypto/talitos.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -2792,7 +2792,7 @@ static struct talitos_alg_template drive
.alg.crypto = {
.cra_name = "ctr(aes)",
.cra_driver_name = "ctr-aes-talitos",
- .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_blocksize = 1,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
CRYPTO_ALG_ASYNC,
.cra_ablkcipher = {


2019-09-18 08:52:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 61/85] ubifs: Correctly use tnc_next() in search_dh_cookie()

From: Richard Weinberger <[email protected]>

commit bacfa94b08027b9f66ede7044972e3b066766b3e upstream.

Commit c877154d307f fixed an uninitialized variable and optimized
the function to not call tnc_next() in the first iteration of the
loop. While this seemed perfectly legit and wise, it turned out to
be illegal.
If the lookup function does not find an exact match it will rewind
the cursor by 1.
The rewinded cursor will not match the name hash we are looking for
and this results in a spurious -ENOENT.
So we need to move to the next entry in case of an non-exact match,
but not if the match was exact.

While we are here, update the documentation to avoid further confusion.

Cc: Hyunchul Lee <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Fixes: c877154d307f ("ubifs: Fix uninitialized variable in search_dh_cookie()")
Fixes: 781f675e2d7e ("ubifs: Fix unlink code wrt. double hash lookups")
Signed-off-by: Richard Weinberger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ubifs/tnc.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)

--- a/fs/ubifs/tnc.c
+++ b/fs/ubifs/tnc.c
@@ -1158,8 +1158,8 @@ static struct ubifs_znode *dirty_cow_bot
* o exact match, i.e. the found zero-level znode contains key @key, then %1
* is returned and slot number of the matched branch is stored in @n;
* o not exact match, which means that zero-level znode does not contain
- * @key, then %0 is returned and slot number of the closest branch is stored
- * in @n;
+ * @key, then %0 is returned and slot number of the closest branch or %-1
+ * is stored in @n; In this case calling tnc_next() is mandatory.
* o @key is so small that it is even less than the lowest key of the
* leftmost zero-level node, then %0 is returned and %0 is stored in @n.
*
@@ -1882,13 +1882,19 @@ int ubifs_tnc_lookup_nm(struct ubifs_inf

static int search_dh_cookie(struct ubifs_info *c, const union ubifs_key *key,
struct ubifs_dent_node *dent, uint32_t cookie,
- struct ubifs_znode **zn, int *n)
+ struct ubifs_znode **zn, int *n, int exact)
{
int err;
struct ubifs_znode *znode = *zn;
struct ubifs_zbranch *zbr;
union ubifs_key *dkey;

+ if (!exact) {
+ err = tnc_next(c, &znode, n);
+ if (err)
+ return err;
+ }
+
for (;;) {
zbr = &znode->zbranch[*n];
dkey = &zbr->key;
@@ -1930,7 +1936,7 @@ static int do_lookup_dh(struct ubifs_inf
if (unlikely(err < 0))
goto out_unlock;

- err = search_dh_cookie(c, key, dent, cookie, &znode, &n);
+ err = search_dh_cookie(c, key, dent, cookie, &znode, &n, err);

out_unlock:
mutex_unlock(&c->tnc_mutex);
@@ -2723,7 +2729,7 @@ int ubifs_tnc_remove_dh(struct ubifs_inf
if (unlikely(err < 0))
goto out_free;

- err = search_dh_cookie(c, key, dent, cookie, &znode, &n);
+ err = search_dh_cookie(c, key, dent, cookie, &znode, &n, err);
if (err)
goto out_free;
}


2019-09-18 08:52:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 62/85] driver core: Fix use-after-free and double free on glue directory

From: Muchun Song <[email protected]>

commit ac43432cb1f5c2950408534987e57c2071e24d8f upstream.

There is a race condition between removing glue directory and adding a new
device under the glue dir. It can be reproduced in following test:

CPU1: CPU2:

device_add()
get_device_parent()
class_dir_create_and_add()
kobject_add_internal()
create_dir() // create glue_dir

device_add()
get_device_parent()
kobject_get() // get glue_dir

device_del()
cleanup_glue_dir()
kobject_del(glue_dir)

kobject_add()
kobject_add_internal()
create_dir() // in glue_dir
sysfs_create_dir_ns()
kernfs_create_dir_ns(sd)

sysfs_remove_dir() // glue_dir->sd=NULL
sysfs_put() // free glue_dir->sd

// sd is freed
kernfs_new_node(sd)
kernfs_get(glue_dir)
kernfs_add_one()
kernfs_put()

Before CPU1 remove last child device under glue dir, if CPU2 add a new
device under glue dir, the glue_dir kobject reference count will be
increase to 2 via kobject_get() in get_device_parent(). And CPU2 has
been called kernfs_create_dir_ns(), but not call kernfs_new_node().
Meanwhile, CPU1 call sysfs_remove_dir() and sysfs_put(). This result in
glue_dir->sd is freed and it's reference count will be 0. Then CPU2 call
kernfs_get(glue_dir) will trigger a warning in kernfs_get() and increase
it's reference count to 1. Because glue_dir->sd is freed by CPU1, the next
call kernfs_add_one() by CPU2 will fail(This is also use-after-free)
and call kernfs_put() to decrease reference count. Because the reference
count is decremented to 0, it will also call kmem_cache_free() to free
the glue_dir->sd again. This will result in double free.

In order to avoid this happening, we also should make sure that kernfs_node
for glue_dir is released in CPU1 only when refcount for glue_dir kobj is
1 to fix this race.

The following calltrace is captured in kernel 4.14 with the following patch
applied:

commit 726e41097920 ("drivers: core: Remove glue dirs from sysfs earlier")

--------------------------------------------------------------------------
[ 3.633703] WARNING: CPU: 4 PID: 513 at .../fs/kernfs/dir.c:494
Here is WARN_ON(!atomic_read(&kn->count) in kernfs_get().
....
[ 3.633986] Call trace:
[ 3.633991] kernfs_create_dir_ns+0xa8/0xb0
[ 3.633994] sysfs_create_dir_ns+0x54/0xe8
[ 3.634001] kobject_add_internal+0x22c/0x3f0
[ 3.634005] kobject_add+0xe4/0x118
[ 3.634011] device_add+0x200/0x870
[ 3.634017] _request_firmware+0x958/0xc38
[ 3.634020] request_firmware_into_buf+0x4c/0x70
....
[ 3.634064] kernel BUG at .../mm/slub.c:294!
Here is BUG_ON(object == fp) in set_freepointer().
....
[ 3.634346] Call trace:
[ 3.634351] kmem_cache_free+0x504/0x6b8
[ 3.634355] kernfs_put+0x14c/0x1d8
[ 3.634359] kernfs_create_dir_ns+0x88/0xb0
[ 3.634362] sysfs_create_dir_ns+0x54/0xe8
[ 3.634366] kobject_add_internal+0x22c/0x3f0
[ 3.634370] kobject_add+0xe4/0x118
[ 3.634374] device_add+0x200/0x870
[ 3.634378] _request_firmware+0x958/0xc38
[ 3.634381] request_firmware_into_buf+0x4c/0x70
--------------------------------------------------------------------------

Fixes: 726e41097920 ("drivers: core: Remove glue dirs from sysfs earlier")
Signed-off-by: Muchun Song <[email protected]>
Reviewed-by: Mukesh Ojha <[email protected]>
Signed-off-by: Prateek Sood <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/base/core.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 52 insertions(+), 1 deletion(-)

--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1820,12 +1820,63 @@ static inline struct kobject *get_glue_d
*/
static void cleanup_glue_dir(struct device *dev, struct kobject *glue_dir)
{
+ unsigned int ref;
+
/* see if we live in a "glue" directory */
if (!live_in_glue_dir(glue_dir, dev))
return;

mutex_lock(&gdp_mutex);
- if (!kobject_has_children(glue_dir))
+ /**
+ * There is a race condition between removing glue directory
+ * and adding a new device under the glue directory.
+ *
+ * CPU1: CPU2:
+ *
+ * device_add()
+ * get_device_parent()
+ * class_dir_create_and_add()
+ * kobject_add_internal()
+ * create_dir() // create glue_dir
+ *
+ * device_add()
+ * get_device_parent()
+ * kobject_get() // get glue_dir
+ *
+ * device_del()
+ * cleanup_glue_dir()
+ * kobject_del(glue_dir)
+ *
+ * kobject_add()
+ * kobject_add_internal()
+ * create_dir() // in glue_dir
+ * sysfs_create_dir_ns()
+ * kernfs_create_dir_ns(sd)
+ *
+ * sysfs_remove_dir() // glue_dir->sd=NULL
+ * sysfs_put() // free glue_dir->sd
+ *
+ * // sd is freed
+ * kernfs_new_node(sd)
+ * kernfs_get(glue_dir)
+ * kernfs_add_one()
+ * kernfs_put()
+ *
+ * Before CPU1 remove last child device under glue dir, if CPU2 add
+ * a new device under glue dir, the glue_dir kobject reference count
+ * will be increase to 2 in kobject_get(k). And CPU2 has been called
+ * kernfs_create_dir_ns(). Meanwhile, CPU1 call sysfs_remove_dir()
+ * and sysfs_put(). This result in glue_dir->sd is freed.
+ *
+ * Then the CPU2 will see a stale "empty" but still potentially used
+ * glue dir around in kernfs_new_node().
+ *
+ * In order to avoid this happening, we also should make sure that
+ * kernfs_node for glue_dir is released in CPU1 only when refcount
+ * for glue_dir kobj is 1.
+ */
+ ref = kref_read(&glue_dir->kref);
+ if (!kobject_has_children(glue_dir) && !--ref)
kobject_del(glue_dir);
kobject_put(glue_dir);
mutex_unlock(&gdp_mutex);


2019-09-18 08:53:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 83/85] platform/x86: pcengines-apuv2: use KEY_RESTART for front button

From: Enrico Weigelt <[email protected]>

commit f14312a93b34b9350dc33ff0b4215c24f4c82617 upstream.

The keycode KEY_RESTART is more appropriate for the front button,
as most people use it for things like restart or factory reset.

Signed-off-by: Enrico Weigelt <[email protected]>
Fixes: f8eb0235f659 ("x86: pcengines apuv2 gpio/leds/keys platform driver")
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/platform/x86/pcengines-apuv2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/platform/x86/pcengines-apuv2.c
+++ b/drivers/platform/x86/pcengines-apuv2.c
@@ -93,7 +93,7 @@ struct gpiod_lookup_table gpios_led_tabl

static struct gpio_keys_button apu2_keys_buttons[] = {
{
- .code = KEY_SETUP,
+ .code = KEY_RESTART,
.active_low = 1,
.desc = "front button",
.type = EV_KEY,


2019-09-18 08:54:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 75/85] iio: adc: stm32-dfsdm: fix output resolution

From: Olivier Moysan <[email protected]>

commit 12c8398d8012ead3d3d68422067ab2f9a66ae76a upstream.

In buffered mode, output samples are shifted left
unconditionally. This works for filter order 3,
but this shift is not adapted for other filter orders.
Compute required shift, left or right, and shift
output data accordingly.
Add also saturation management to avoid wrap-around
when maximum positive sample is reached.

Signed-off-by: Olivier Moysan <[email protected]>
Fixes: eca949800d2d ("IIO: ADC: add stm32 DFSDM support for PDM microphone")
Acked-by: Fabrice Gasnier <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/iio/adc/stm32-dfsdm-adc.c | 158 +++++++++++++++++++++++++++++---------
drivers/iio/adc/stm32-dfsdm.h | 24 ++++-
2 files changed, 142 insertions(+), 40 deletions(-)

--- a/drivers/iio/adc/stm32-dfsdm-adc.c
+++ b/drivers/iio/adc/stm32-dfsdm-adc.c
@@ -39,9 +39,16 @@
#define DFSDM_MAX_INT_OVERSAMPLING 256
#define DFSDM_MAX_FL_OVERSAMPLING 1024

-/* Max sample resolutions */
-#define DFSDM_MAX_RES BIT(31)
-#define DFSDM_DATA_RES BIT(23)
+/* Limit filter output resolution to 31 bits. (i.e. sample range is +/-2^30) */
+#define DFSDM_DATA_MAX BIT(30)
+/*
+ * Data are output as two's complement data in a 24 bit field.
+ * Data from filters are in the range +/-2^(n-1)
+ * 2^(n-1) maximum positive value cannot be coded in 2's complement n bits
+ * An extra bit is required to avoid wrap-around of the binary code for 2^(n-1)
+ * So, the resolution of samples from filter is actually limited to 23 bits
+ */
+#define DFSDM_DATA_RES 24

/* Filter configuration */
#define DFSDM_CR1_CFG_MASK (DFSDM_CR1_RCH_MASK | DFSDM_CR1_RCONT_MASK | \
@@ -181,14 +188,15 @@ static int stm32_dfsdm_get_jextsel(struc
return -EINVAL;
}

-static int stm32_dfsdm_set_osrs(struct stm32_dfsdm_filter *fl,
- unsigned int fast, unsigned int oversamp)
+static int stm32_dfsdm_compute_osrs(struct stm32_dfsdm_filter *fl,
+ unsigned int fast, unsigned int oversamp)
{
unsigned int i, d, fosr, iosr;
- u64 res;
- s64 delta;
+ u64 res, max;
+ int bits, shift;
unsigned int m = 1; /* multiplication factor */
unsigned int p = fl->ford; /* filter order (ford) */
+ struct stm32_dfsdm_filter_osr *flo = &fl->flo;

pr_debug("%s: Requested oversampling: %d\n", __func__, oversamp);
/*
@@ -207,11 +215,9 @@ static int stm32_dfsdm_set_osrs(struct s

/*
* Look for filter and integrator oversampling ratios which allows
- * to reach 24 bits data output resolution.
- * Leave as soon as if exact resolution if reached.
- * Otherwise the higher resolution below 32 bits is kept.
+ * to maximize data output resolution.
*/
- fl->res = 0;
+ flo->res = 0;
for (fosr = 1; fosr <= DFSDM_MAX_FL_OVERSAMPLING; fosr++) {
for (iosr = 1; iosr <= DFSDM_MAX_INT_OVERSAMPLING; iosr++) {
if (fast)
@@ -236,32 +242,68 @@ static int stm32_dfsdm_set_osrs(struct s
res = fosr;
for (i = p - 1; i > 0; i--) {
res = res * (u64)fosr;
- if (res > DFSDM_MAX_RES)
+ if (res > DFSDM_DATA_MAX)
break;
}
- if (res > DFSDM_MAX_RES)
+ if (res > DFSDM_DATA_MAX)
continue;
+
res = res * (u64)m * (u64)iosr;
- if (res > DFSDM_MAX_RES)
+ if (res > DFSDM_DATA_MAX)
continue;

- delta = res - DFSDM_DATA_RES;
-
- if (res >= fl->res) {
- fl->res = res;
- fl->fosr = fosr;
- fl->iosr = iosr;
- fl->fast = fast;
- pr_debug("%s: fosr = %d, iosr = %d\n",
- __func__, fl->fosr, fl->iosr);
+ if (res >= flo->res) {
+ flo->res = res;
+ flo->fosr = fosr;
+ flo->iosr = iosr;
+
+ bits = fls(flo->res);
+ /* 8 LBSs in data register contain chan info */
+ max = flo->res << 8;
+
+ /* if resolution is not a power of two */
+ if (flo->res > BIT(bits - 1))
+ bits++;
+ else
+ max--;
+
+ shift = DFSDM_DATA_RES - bits;
+ /*
+ * Compute right/left shift
+ * Right shift is performed by hardware
+ * when transferring samples to data register.
+ * Left shift is done by software on buffer
+ */
+ if (shift > 0) {
+ /* Resolution is lower than 24 bits */
+ flo->rshift = 0;
+ flo->lshift = shift;
+ } else {
+ /*
+ * If resolution is 24 bits or more,
+ * max positive value may be ambiguous
+ * (equal to max negative value as sign
+ * bit is dropped).
+ * Reduce resolution to 23 bits (rshift)
+ * to keep the sign on bit 23 and treat
+ * saturation before rescaling on 24
+ * bits (lshift).
+ */
+ flo->rshift = 1 - shift;
+ flo->lshift = 1;
+ max >>= flo->rshift;
+ }
+ flo->max = (s32)max;
+
+ pr_debug("%s: fast %d, fosr %d, iosr %d, res 0x%llx/%d bits, rshift %d, lshift %d\n",
+ __func__, fast, flo->fosr, flo->iosr,
+ flo->res, bits, flo->rshift,
+ flo->lshift);
}
-
- if (!delta)
- return 0;
}
}

- if (!fl->res)
+ if (!flo->res)
return -EINVAL;

return 0;
@@ -384,6 +426,36 @@ static int stm32_dfsdm_filter_set_trig(s
return 0;
}

+static int stm32_dfsdm_channels_configure(struct stm32_dfsdm_adc *adc,
+ unsigned int fl_id,
+ struct iio_trigger *trig)
+{
+ struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct regmap *regmap = adc->dfsdm->regmap;
+ struct stm32_dfsdm_filter *fl = &adc->dfsdm->fl_list[fl_id];
+ struct stm32_dfsdm_filter_osr *flo = &fl->flo;
+ const struct iio_chan_spec *chan;
+ unsigned int bit;
+ int ret;
+
+ if (!flo->res)
+ return -EINVAL;
+
+ for_each_set_bit(bit, &adc->smask,
+ sizeof(adc->smask) * BITS_PER_BYTE) {
+ chan = indio_dev->channels + bit;
+
+ ret = regmap_update_bits(regmap,
+ DFSDM_CHCFGR2(chan->channel),
+ DFSDM_CHCFGR2_DTRBS_MASK,
+ DFSDM_CHCFGR2_DTRBS(flo->rshift));
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static int stm32_dfsdm_filter_configure(struct stm32_dfsdm_adc *adc,
unsigned int fl_id,
struct iio_trigger *trig)
@@ -391,6 +463,7 @@ static int stm32_dfsdm_filter_configure(
struct iio_dev *indio_dev = iio_priv_to_dev(adc);
struct regmap *regmap = adc->dfsdm->regmap;
struct stm32_dfsdm_filter *fl = &adc->dfsdm->fl_list[fl_id];
+ struct stm32_dfsdm_filter_osr *flo = &fl->flo;
u32 cr1;
const struct iio_chan_spec *chan;
unsigned int bit, jchg = 0;
@@ -398,13 +471,13 @@ static int stm32_dfsdm_filter_configure(

/* Average integrator oversampling */
ret = regmap_update_bits(regmap, DFSDM_FCR(fl_id), DFSDM_FCR_IOSR_MASK,
- DFSDM_FCR_IOSR(fl->iosr - 1));
+ DFSDM_FCR_IOSR(flo->iosr - 1));
if (ret)
return ret;

/* Filter order and Oversampling */
ret = regmap_update_bits(regmap, DFSDM_FCR(fl_id), DFSDM_FCR_FOSR_MASK,
- DFSDM_FCR_FOSR(fl->fosr - 1));
+ DFSDM_FCR_FOSR(flo->fosr - 1));
if (ret)
return ret;

@@ -573,7 +646,7 @@ static int dfsdm_adc_set_samp_freq(struc
"Rate not accurate. requested (%u), actual (%u)\n",
sample_freq, spi_freq / oversamp);

- ret = stm32_dfsdm_set_osrs(fl, 0, oversamp);
+ ret = stm32_dfsdm_compute_osrs(fl, 0, oversamp);
if (ret < 0) {
dev_err(&indio_dev->dev, "No filter parameters that match!\n");
return ret;
@@ -623,6 +696,10 @@ static int stm32_dfsdm_start_conv(struct
struct regmap *regmap = adc->dfsdm->regmap;
int ret;

+ ret = stm32_dfsdm_channels_configure(adc, adc->fl_id, trig);
+ if (ret < 0)
+ return ret;
+
ret = stm32_dfsdm_start_channel(adc);
if (ret < 0)
return ret;
@@ -729,6 +806,8 @@ static void stm32_dfsdm_dma_buffer_done(
{
struct iio_dev *indio_dev = data;
struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
+ struct stm32_dfsdm_filter *fl = &adc->dfsdm->fl_list[adc->fl_id];
+ struct stm32_dfsdm_filter_osr *flo = &fl->flo;
int available = stm32_dfsdm_adc_dma_residue(adc);
size_t old_pos;

@@ -751,10 +830,19 @@ static void stm32_dfsdm_dma_buffer_done(
old_pos = adc->bufi;

while (available >= indio_dev->scan_bytes) {
- u32 *buffer = (u32 *)&adc->rx_buf[adc->bufi];
+ s32 *buffer = (s32 *)&adc->rx_buf[adc->bufi];

/* Mask 8 LSB that contains the channel ID */
- *buffer = (*buffer & 0xFFFFFF00) << 8;
+ *buffer &= 0xFFFFFF00;
+ /* Convert 2^(n-1) sample to 2^(n-1)-1 to avoid wrap-around */
+ if (*buffer > flo->max)
+ *buffer -= 1;
+ /*
+ * Samples from filter are retrieved with 23 bits resolution
+ * or less. Shift left to align MSB on 24 bits.
+ */
+ *buffer <<= flo->lshift;
+
available -= indio_dev->scan_bytes;
adc->bufi += indio_dev->scan_bytes;
if (adc->bufi >= adc->buf_sz) {
@@ -1078,7 +1166,7 @@ static int stm32_dfsdm_write_raw(struct
ret = iio_device_claim_direct_mode(indio_dev);
if (ret)
return ret;
- ret = stm32_dfsdm_set_osrs(fl, 0, val);
+ ret = stm32_dfsdm_compute_osrs(fl, 0, val);
if (!ret)
adc->oversamp = val;
iio_device_release_direct_mode(indio_dev);
@@ -1327,8 +1415,8 @@ static int stm32_dfsdm_adc_init(struct i
int ret, chan_idx;

adc->oversamp = DFSDM_DEFAULT_OVERSAMPLING;
- ret = stm32_dfsdm_set_osrs(&adc->dfsdm->fl_list[adc->fl_id], 0,
- adc->oversamp);
+ ret = stm32_dfsdm_compute_osrs(&adc->dfsdm->fl_list[adc->fl_id], 0,
+ adc->oversamp);
if (ret < 0)
return ret;

--- a/drivers/iio/adc/stm32-dfsdm.h
+++ b/drivers/iio/adc/stm32-dfsdm.h
@@ -243,19 +243,33 @@ enum stm32_dfsdm_sinc_order {
};

/**
- * struct stm32_dfsdm_filter - structure relative to stm32 FDSDM filter
+ * struct stm32_dfsdm_filter_osr - DFSDM filter settings linked to oversampling
* @iosr: integrator oversampling
* @fosr: filter oversampling
- * @ford: filter order
+ * @rshift: output sample right shift (hardware shift)
+ * @lshift: output sample left shift (software shift)
* @res: output sample resolution
+ * @max: output sample maximum positive value
+ */
+struct stm32_dfsdm_filter_osr {
+ unsigned int iosr;
+ unsigned int fosr;
+ unsigned int rshift;
+ unsigned int lshift;
+ u64 res;
+ s32 max;
+};
+
+/**
+ * struct stm32_dfsdm_filter - structure relative to stm32 FDSDM filter
+ * @ford: filter order
+ * @flo: filter oversampling structure
* @sync_mode: filter synchronized with filter 0
* @fast: filter fast mode
*/
struct stm32_dfsdm_filter {
- unsigned int iosr;
- unsigned int fosr;
enum stm32_dfsdm_sinc_order ford;
- u64 res;
+ struct stm32_dfsdm_filter_osr flo;
unsigned int sync_mode;
unsigned int fast;
};


2019-09-18 08:54:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 76/85] iio: adc: stm32-dfsdm: fix data type

From: Olivier Moysan <[email protected]>

commit c6013bf50e2a2a94ab3d012e191096432aa50c6f upstream.

Fix the data type as DFSDM raw output is complements 2,
24bits left aligned in a 32-bit register.
This change does not affect AUDIO path
- Set data as signed for IIO (as for AUDIO)
- Set 8 bit right shift for IIO.
The 8 LSBs bits of data contains channel info and are masked.

Signed-off-by: Olivier Moysan <[email protected]>
Fixes: e2e6771c6462 ("IIO: ADC: add STM32 DFSDM sigma delta ADC support")
Acked-by: Fabrice Gasnier <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/iio/adc/stm32-dfsdm-adc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/iio/adc/stm32-dfsdm-adc.c
+++ b/drivers/iio/adc/stm32-dfsdm-adc.c
@@ -1365,11 +1365,11 @@ static int stm32_dfsdm_adc_chan_init_one
BIT(IIO_CHAN_INFO_SAMP_FREQ);

if (adc->dev_data->type == DFSDM_AUDIO) {
- ch->scan_type.sign = 's';
ch->ext_info = dfsdm_adc_audio_ext_info;
} else {
- ch->scan_type.sign = 'u';
+ ch->scan_type.shift = 8;
}
+ ch->scan_type.sign = 's';
ch->scan_type.realbits = 24;
ch->scan_type.storagebits = 32;



2019-09-18 11:03:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 19/85] net: fixed_phy: Add forward declaration for struct gpio_desc;

From: Moritz Fischer <[email protected]>

[ Upstream commit ebe26aca98fcf9fbe5017b5cbe216413cee69df5 ]

Add forward declaration for struct gpio_desc in order to address
the following:

./include/linux/phy_fixed.h:48:17: error: 'struct gpio_desc' declared inside parameter list [-Werror]
./include/linux/phy_fixed.h:48:17: error: its scope is only this definition or declaration, which is probably not what you want [-Werror]

Fixes: 71bd106d2567 ("net: fixed-phy: Add fixed_phy_register_with_gpiod() API")
Signed-off-by: Moritz Fischer <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/phy_fixed.h | 1 +
1 file changed, 1 insertion(+)

--- a/include/linux/phy_fixed.h
+++ b/include/linux/phy_fixed.h
@@ -11,6 +11,7 @@ struct fixed_phy_status {
};

struct device_node;
+struct gpio_desc;

#if IS_ENABLED(CONFIG_FIXED_PHY)
extern int fixed_phy_change_carrier(struct net_device *dev, bool new_carrier);


2019-09-18 11:06:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 67/85] crypto: talitos - Do not modify req->cryptlen on decryption.

From: Christophe Leroy <[email protected]>

commit 7ede4c36cf7c6516986ee9d75b197c8bf73ea96f upstream.

For decrypt, req->cryptlen includes the size of the authentication
part while all functions of the driver expect cryptlen to be
the size of the encrypted data.

As it is not expected to change req->cryptlen, this patch
implements local calculation of cryptlen.

Signed-off-by: Christophe Leroy <[email protected]>
Fixes: 9c4a79653b35 ("crypto: talitos - Freescale integrated security engine (SEC) driver")
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/crypto/talitos.c | 31 +++++++++++++++++--------------
1 file changed, 17 insertions(+), 14 deletions(-)

--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -994,11 +994,13 @@ static void talitos_sg_unmap(struct devi

static void ipsec_esp_unmap(struct device *dev,
struct talitos_edesc *edesc,
- struct aead_request *areq)
+ struct aead_request *areq, bool encrypt)
{
struct crypto_aead *aead = crypto_aead_reqtfm(areq);
struct talitos_ctx *ctx = crypto_aead_ctx(aead);
unsigned int ivsize = crypto_aead_ivsize(aead);
+ unsigned int authsize = crypto_aead_authsize(aead);
+ unsigned int cryptlen = areq->cryptlen - (encrypt ? 0 : authsize);
bool is_ipsec_esp = edesc->desc.hdr & DESC_HDR_TYPE_IPSEC_ESP;
struct talitos_ptr *civ_ptr = &edesc->desc.ptr[is_ipsec_esp ? 2 : 3];

@@ -1007,7 +1009,7 @@ static void ipsec_esp_unmap(struct devic
DMA_FROM_DEVICE);
unmap_single_talitos_ptr(dev, civ_ptr, DMA_TO_DEVICE);

- talitos_sg_unmap(dev, edesc, areq->src, areq->dst, areq->cryptlen,
+ talitos_sg_unmap(dev, edesc, areq->src, areq->dst, cryptlen,
areq->assoclen);

if (edesc->dma_len)
@@ -1018,7 +1020,7 @@ static void ipsec_esp_unmap(struct devic
unsigned int dst_nents = edesc->dst_nents ? : 1;

sg_pcopy_to_buffer(areq->dst, dst_nents, ctx->iv, ivsize,
- areq->assoclen + areq->cryptlen - ivsize);
+ areq->assoclen + cryptlen - ivsize);
}
}

@@ -1040,7 +1042,7 @@ static void ipsec_esp_encrypt_done(struc

edesc = container_of(desc, struct talitos_edesc, desc);

- ipsec_esp_unmap(dev, edesc, areq);
+ ipsec_esp_unmap(dev, edesc, areq, true);

/* copy the generated ICV to dst */
if (edesc->icv_ool) {
@@ -1074,7 +1076,7 @@ static void ipsec_esp_decrypt_swauth_don

edesc = container_of(desc, struct talitos_edesc, desc);

- ipsec_esp_unmap(dev, edesc, req);
+ ipsec_esp_unmap(dev, edesc, req, false);

if (!err) {
char icvdata[SHA512_DIGEST_SIZE];
@@ -1120,7 +1122,7 @@ static void ipsec_esp_decrypt_hwauth_don

edesc = container_of(desc, struct talitos_edesc, desc);

- ipsec_esp_unmap(dev, edesc, req);
+ ipsec_esp_unmap(dev, edesc, req, false);

/* check ICV auth status */
if (!err && ((desc->hdr_lo & DESC_HDR_LO_ICCR1_MASK) !=
@@ -1223,6 +1225,7 @@ static int talitos_sg_map(struct device
* fill in and submit ipsec_esp descriptor
*/
static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq,
+ bool encrypt,
void (*callback)(struct device *dev,
struct talitos_desc *desc,
void *context, int error))
@@ -1232,7 +1235,7 @@ static int ipsec_esp(struct talitos_edes
struct talitos_ctx *ctx = crypto_aead_ctx(aead);
struct device *dev = ctx->dev;
struct talitos_desc *desc = &edesc->desc;
- unsigned int cryptlen = areq->cryptlen;
+ unsigned int cryptlen = areq->cryptlen - (encrypt ? 0 : authsize);
unsigned int ivsize = crypto_aead_ivsize(aead);
int tbl_off = 0;
int sg_count, ret;
@@ -1359,7 +1362,7 @@ static int ipsec_esp(struct talitos_edes

ret = talitos_submit(dev, ctx->ch, desc, callback, areq);
if (ret != -EINPROGRESS) {
- ipsec_esp_unmap(dev, edesc, areq);
+ ipsec_esp_unmap(dev, edesc, areq, encrypt);
kfree(edesc);
}
return ret;
@@ -1473,9 +1476,10 @@ static struct talitos_edesc *aead_edesc_
unsigned int authsize = crypto_aead_authsize(authenc);
struct talitos_ctx *ctx = crypto_aead_ctx(authenc);
unsigned int ivsize = crypto_aead_ivsize(authenc);
+ unsigned int cryptlen = areq->cryptlen - (encrypt ? 0 : authsize);

return talitos_edesc_alloc(ctx->dev, areq->src, areq->dst,
- iv, areq->assoclen, areq->cryptlen,
+ iv, areq->assoclen, cryptlen,
authsize, ivsize, icv_stashing,
areq->base.flags, encrypt);
}
@@ -1494,7 +1498,7 @@ static int aead_encrypt(struct aead_requ
/* set encrypt */
edesc->desc.hdr = ctx->desc_hdr_template | DESC_HDR_MODE0_ENCRYPT;

- return ipsec_esp(edesc, req, ipsec_esp_encrypt_done);
+ return ipsec_esp(edesc, req, true, ipsec_esp_encrypt_done);
}

static int aead_decrypt(struct aead_request *req)
@@ -1506,8 +1510,6 @@ static int aead_decrypt(struct aead_requ
struct talitos_edesc *edesc;
void *icvdata;

- req->cryptlen -= authsize;
-
/* allocate extended descriptor */
edesc = aead_edesc_alloc(req, req->iv, 1, false);
if (IS_ERR(edesc))
@@ -1524,7 +1526,8 @@ static int aead_decrypt(struct aead_requ

/* reset integrity check result bits */

- return ipsec_esp(edesc, req, ipsec_esp_decrypt_hwauth_done);
+ return ipsec_esp(edesc, req, false,
+ ipsec_esp_decrypt_hwauth_done);
}

/* Have to check the ICV with software */
@@ -1540,7 +1543,7 @@ static int aead_decrypt(struct aead_requ
sg_pcopy_to_buffer(req->src, edesc->src_nents ? : 1, icvdata, authsize,
req->assoclen + req->cryptlen - authsize);

- return ipsec_esp(edesc, req, ipsec_esp_decrypt_swauth_done);
+ return ipsec_esp(edesc, req, false, ipsec_esp_decrypt_swauth_done);
}

static int ablkcipher_setkey(struct crypto_ablkcipher *cipher,


2019-09-18 11:07:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.2 80/85] kvm: nVMX: Remove unnecessary sync_roots from handle_invept

From: Jim Mattson <[email protected]>

commit b119019847fbcac36ed1384f166c91f177d070e7 upstream.

When L0 is executing handle_invept(), the TDP MMU is active. Emulating
an L1 INVEPT does require synchronizing the appropriate shadow EPT
root(s), but a call to kvm_mmu_sync_roots in this context won't do
that. Similarly, the hardware TLB and paging-structure-cache entries
associated with the appropriate shadow EPT root(s) must be flushed,
but requesting a TLB_FLUSH from this context won't do that either.

How did this ever work? KVM always does a sync_roots and TLB flush (in
the correct context) when transitioning from L1 to L2. That isn't the
best choice for nested VM performance, but it effectively papers over
the mistakes here.

Remove the unnecessary operations and leave a comment to try to do
better in the future.

Reported-by: Junaid Shahid <[email protected]>
Fixes: bfd0a56b90005f ("nEPT: Nested INVEPT")
Cc: Xiao Guangrong <[email protected]>
Cc: Nadav Har'El <[email protected]>
Cc: Jun Nakajima <[email protected]>
Cc: Xinhao Xu <[email protected]>
Cc: Yang Zhang <[email protected]>
Cc: Gleb Natapov <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Reviewed-by Peter Shier <[email protected]>
Reviewed-by: Junaid Shahid <[email protected]>
Signed-off-by: Jim Mattson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kvm/vmx/nested.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)

--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -4708,13 +4708,11 @@ static int handle_invept(struct kvm_vcpu

switch (type) {
case VMX_EPT_EXTENT_GLOBAL:
+ case VMX_EPT_EXTENT_CONTEXT:
/*
- * TODO: track mappings and invalidate
- * single context requests appropriately
+ * TODO: Sync the necessary shadow EPT roots here, rather than
+ * at the next emulated VM-entry.
*/
- case VMX_EPT_EXTENT_CONTEXT:
- kvm_mmu_sync_roots(vcpu);
- kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
break;
default:
BUG_ON(1);


2019-09-18 13:21:59

by kernelci.org bot

[permalink] [raw]
Subject: Re: [PATCH 5.2 00/85] 5.2.16-stable review

stable-rc/linux-5.2.y boot: 145 boots: 1 failed, 135 passed with 8 offline, 1 conflict (v5.2.15-86-g2f63f02ef506)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.2.y/kernel/v5.2.15-86-g2f63f02ef506/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.2.y/kernel/v5.2.15-86-g2f63f02ef506/

Tree: stable-rc
Branch: linux-5.2.y
Git Describe: v5.2.15-86-g2f63f02ef506
Git Commit: 2f63f02ef5061324ba168b1cb01c89fd89a0c593
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 82 unique boards, 28 SoC families, 17 builds out of 209

Boot Failure Detected:

arm64:
defconfig:
gcc-8:
rk3399-firefly: 1 failed lab

Offline Platforms:

arm64:

defconfig:
gcc-8
apq8016-sbc: 1 offline lab

arm:

multi_v7_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
qcom-apq8064-ifc6410: 1 offline lab
sun5i-r8-chip: 1 offline lab

davinci_all_defconfig:
gcc-8
dm365evm,legacy: 1 offline lab

qcom_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
qcom-apq8064-ifc6410: 1 offline lab

sunxi_defconfig:
gcc-8
sun5i-r8-chip: 1 offline lab

Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)

arm:
omap2plus_defconfig:
omap4-panda:
lab-baylibre: FAIL (gcc-8)
lab-baylibre-seattle: PASS (gcc-8)
lab-collabora: PASS (gcc-8)

---
For more info write to <[email protected]>

2019-09-18 17:32:26

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.2 00/85] 5.2.16-stable review

On Wed, 18 Sep 2019 at 11:56, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.2.16 release.
> There are 85 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri 20 Sep 2019 06:09:47 AM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.16-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary
------------------------------------------------------------------------

kernel: 5.2.16-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.2.y
git commit: 2f63f02ef5061324ba168b1cb01c89fd89a0c593
git describe: v5.2.15-86-g2f63f02ef506
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.2-oe/build/v5.2.15-86-g2f63f02ef506


No regressions (compared to build v5.2.15)


No fixes (compared to build v5.2.15)

Ran 22511 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* network-basic-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-fs-tests
* ltp-open-posix-tests
* kvm-unit-tests
* ssuite
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

--
Linaro LKFT
https://lkft.linaro.org

2019-09-18 17:37:53

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 5.2 00/85] 5.2.16-stable review


On 18/09/2019 07:18, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.2.16 release.
> There are 85 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri 20 Sep 2019 06:09:47 AM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.16-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

All tests are passing for Tegra ...

Test results for stable-v5.2:
12 builds: 12 pass, 0 fail
22 boots: 22 pass, 0 fail
38 tests: 38 pass, 0 fail

Linux version: 5.2.16-rc1-g2f63f02ef506
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

--
nvpublic

2019-09-19 00:40:53

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.2 00/85] 5.2.16-stable review

On Wed, Sep 18, 2019 at 08:18:18AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.2.16 release.
> There are 85 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri 20 Sep 2019 06:09:47 AM UTC.
> Anything received after that time might be too late.
>

Build results:
total: 159 pass: 159 fail: 0
Qemu test results:
total: 390 pass: 390 fail: 0

Guenter

2019-09-19 01:29:33

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.2 00/85] 5.2.16-stable review

On 9/18/19 12:18 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.2.16 release.
> There are 85 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri 20 Sep 2019 06:09:47 AM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.16-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

2019-09-19 07:36:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.2 00/85] 5.2.16-stable review

On Wed, Sep 18, 2019 at 07:22:50PM -0600, shuah wrote:
> On 9/18/19 12:18 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.2.16 release.
> > There are 85 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri 20 Sep 2019 06:09:47 AM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.16-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

2019-09-19 07:36:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.2 00/85] 5.2.16-stable review

On Wed, Sep 18, 2019 at 08:47:06PM +0530, Naresh Kamboju wrote:
> On Wed, 18 Sep 2019 at 11:56, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.2.16 release.
> > There are 85 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri 20 Sep 2019 06:09:47 AM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.16-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.

Great, thanks for testing all of these and letting me know.

greg k-h

2019-09-19 10:30:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.2 00/85] 5.2.16-stable review

On Wed, Sep 18, 2019 at 05:28:49PM +0100, Jon Hunter wrote:
>
> On 18/09/2019 07:18, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.2.16 release.
> > There are 85 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri 20 Sep 2019 06:09:47 AM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.16-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> All tests are passing for Tegra ...
>
> Test results for stable-v5.2:
> 12 builds: 12 pass, 0 fail
> 22 boots: 22 pass, 0 fail
> 38 tests: 38 pass, 0 fail
>
> Linux version: 5.2.16-rc1-g2f63f02ef506
> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> tegra194-p2972-0000, tegra20-ventana,
> tegra210-p2371-2180, tegra30-cardhu-a04

Thanks for testing all of these and letting me know.

greg k-h