2018-03-23 10:54:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 00/97] 4.4.124-stable review

This is the start of the stable review cycle for the 4.4.124 release.
There are 97 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 Sun Mar 25 09:41:34 UTC 2018.
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/v4.x/stable-review/patch-4.4.124-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-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

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

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

Leon Romanovsky <[email protected]>
RDMA/ucma: Fix access to non-initialized CM_ID object

Vignesh R <[email protected]>
dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63

Sergej Sawazki <[email protected]>
clk: si5351: Rename internal plls to avoid name collisions

Benjamin Coddington <[email protected]>
nfsd4: permit layoutget of executable-only files

Anton Vasilyev <[email protected]>
RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS

Alexey Kodanev <[email protected]>
ip6_vti: adjust vti mtu according to mtu of lower device

Jerry Snitselaar <[email protected]>
iommu/vt-d: clean up pr_irq if request_threaded_irq fails

Florian Fainelli <[email protected]>
pinctrl: Really force states during suspend/resume

Robert Walker <[email protected]>
coresight: Fix disabling of CoreSight TPIU

Sahara <[email protected]>
pty: cancel pty slave port buf's work in tty_release

Peter Ujfalusi <[email protected]>
drm/omap: DMM: Check for DMM readiness after successful transaction commit

Bjorn Helgaas <[email protected]>
vgacon: Set VGA struct resource types

Artemy Kovalyov <[email protected]>
IB/umem: Fix use of npages/nmap fields

Parav Pandit <[email protected]>
RDMA/cma: Use correct size when writing netlink stats

Erez Shitrit <[email protected]>
IB/ipoib: Avoid memory leak if the SA returns a different DGID

Daniel Drake <[email protected]>
mmc: avoid removing non-removable hosts during suspend

Shawn Nematbakhsh <[email protected]>
platform/chrome: Use proper protocol transfer function

Arnd Bergmann <[email protected]>
cros_ec: fix nul-termination for firmware build info

Ron Economos <[email protected]>
media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart

Christophe JAILLET <[email protected]>
media: bt8xx: Fix err 'bt878_probe()'

Tsang-Shian Lin <[email protected]>
rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled.

Geert Uytterhoeven <[email protected]>
RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo()

Prakash Kamliya <[email protected]>
drm/msm: fix leak in failed get_pages

Gustavo A. R. Silva <[email protected]>
media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt

Loic Poulain <[email protected]>
Bluetooth: hci_qca: Avoid setup failure on missing rampatch

Kim Phillips <[email protected]>
perf tests kmod-path: Don't fail if compressed modules aren't supported

Moritz Fischer <[email protected]>
rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL

Moritz Fischer <[email protected]>
rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt ticks

Dan Carpenter <[email protected]>
cifs: small underflow in cnvrtDosUnixTm()

Timmy Li <[email protected]>
net: hns: fix ethtool_get_strings overflow in hns driver

Alexey Khoroshilov <[email protected]>
sm501fb: don't return zero on failure path in sm501fb_start()

Maksim Salau <[email protected]>
video: fbdev: udlfb: Fix buffer on stack

Dmitry Monakhov <[email protected]>
tcm_fileio: Prevent information leak for short reads

Sergei Trofimovich <[email protected]>
ia64: fix module loading for gcc-5.4

Shaohua Li <[email protected]>
md/raid10: skip spare disk as 'first' disk

Sebastian Reichel <[email protected]>
Input: twl4030-pwrbutton - use correct device for irq request

Michael Trimarchi <[email protected]>
power: supply: pda_power: move from timer to delayed_work

Scott Wood <[email protected]>
bnx2x: Align RX buffers

Mario Kleiner <[email protected]>
drm/nouveau/kms: Increase max retries in scanout position queries.

Hans de Goede <[email protected]>
ACPI / PMIC: xpower: Fix power_table addresses

Robert Lippert <[email protected]>
ipmi/watchdog: fix wdog hang on panic waiting for ipmi response

Kishon Vijay Abraham I <[email protected]>
ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP

yangbo lu <[email protected]>
mmc: sdhci-of-esdhc: limit SD clock for ls1012a/ls1046a

Pan Bian <[email protected]>
staging: wilc1000: fix unchecked return value

Sameer Wadgaonkar <[email protected]>
staging: unisys: visorhba: fix s-Par to boot with option CONFIG_VMAP_STACK set to y

Ming Lei <[email protected]>
mtip32xx: use runtime tag to initialize command header

Keerthy <[email protected]>
mfd: palmas: Reset the POWERHOLD mux during power off

Emmanuel Grumbach <[email protected]>
mac80211: don't parse encrypted management frames in ieee80211_frame_acked

Filipe Manana <[email protected]>
Btrfs: send, fix file hole not being preserved due to inline extent

Pan Bian <[email protected]>
rndis_wlan: add return value validation

Pan Bian <[email protected]>
mt7601u: check return value of alloc_skb

Shrirang Bagul <[email protected]>
iio: st_pressure: st_accel: Initialise sensor platform data properly

NeilBrown <[email protected]>
NFS: don't try to cross a mountpount when there isn't one there.

Vlad Tsyrklevich <[email protected]>
infiniband/uverbs: Fix integer overflows

Finn Thain <[email protected]>
scsi: mac_esp: Replace bogus memory barrier with spinlock

Pan Bian <[email protected]>
qlcnic: fix unchecked return value

Pan Bian <[email protected]>
wan: pc300too: abort path on failure

Dan Carpenter <[email protected]>
mmc: host: omap_hsmmc: checking for NULL instead of IS_ERR()

Jarno Rajahalme <[email protected]>
openvswitch: Delete conntrack entry clashing with an expectation.

Gao Feng <[email protected]>
netfilter: xt_CT: fix refcnt leak on error path

James Smart <[email protected]>
Fix driver usage of 128B WQEs when WQ_CREATE is V1.

Dan Carpenter <[email protected]>
ASoC: Intel: Skylake: Uninitialized variable in probe_codec()

Maor Gottlieb <[email protected]>
IB/mlx4: Change vma from shared to private

Maor Gottlieb <[email protected]>
IB/mlx4: Take write semaphore when changing the vma struct

Dan Carpenter <[email protected]>
HSI: ssi_protocol: double free in ssip_pn_xmit()

Feras Daoud <[email protected]>
IB/ipoib: Update broadcast object if PKey value was changed in index 0

Feras Daoud <[email protected]>
IB/ipoib: Fix deadlock between ipoib_stop and mcast join flow

Mikhail Paulyshka <[email protected]>
ALSA: hda - Fix headset microphone detection for ASUS N551 and N751

Bernd Faust <[email protected]>
e1000e: fix timing for 82579 Gigabit Ethernet controller

Eric Dumazet <[email protected]>
tcp: remove poll() flakes with FastOpen

Benjamin Coddington <[email protected]>
NFS: Fix missing pg_cleanup after nfs_pageio_cond_complete()

Guoqing Jiang <[email protected]>
md/raid10: wait up frozen array in handle_write_completed

Suman Anna <[email protected]>
iommu/omap: Register driver before setting IOMMU ops

Abel Vesa <[email protected]>
ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA and !FRAME_POINTER

Alexey Kardashevskiy <[email protected]>
KVM: PPC: Book3S PR: Exit KVM on failed mapping

David Gibson <[email protected]>
scsi: virtio_scsi: Always try to read VPD pages

Bharat Kumar Reddy Gooty <[email protected]>
clk: ns2: Correct SDIO bits

Mohammed Shafi Shajakhan <[email protected]>
ath: Fix updating radar flags for coutry code India

Marek Vasut <[email protected]>
spi: dw: Disable clock after unregistering the host

Jasmin J <[email protected]>
media/dvb-core: Race condition when writing to CAM

David Ahern <[email protected]>
net: ipv6: send unsolicited NA on admin up

Edgar Cherkasov <[email protected]>
i2c: i2c-scmi: add a MS HID

Hans de Goede <[email protected]>
genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs

Thomas Gleixner <[email protected]>
cpufreq/sh: Replace racy task affinity logic

Thomas Gleixner <[email protected]>
ACPI/processor: Replace racy task affinity logic

Thomas Gleixner <[email protected]>
ACPI/processor: Fix error handling in __acpi_processor_start()

Deepa Dinamani <[email protected]>
time: Change posix clocks ops interfaces to use timespec64

Dmitry Torokhov <[email protected]>
Input: ar1021_i2c - fix too long name in driver's device table

Hans de Goede <[email protected]>
rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs

Hans de Goede <[email protected]>
x86: i8259: export legacy_pic symbol

Dong Aisheng <[email protected]>
regulator: anatop: set default voltage selector for pcie

Santeri Toivonen <[email protected]>
platform/x86: asus-nb-wmi: Add wapf4 quirk for the X302UA

Yisheng Xie <[email protected]>
staging: android: ashmem: Fix possible deadlock in ashmem_ioctl

Pavel Shilovsky <[email protected]>
CIFS: Enable encryption during session setup phase

Steve French <[email protected]>
SMB3: Validate negotiate request must always be signed

Jeremy Boone <[email protected]>
tpm_tis: fix potential buffer overruns caused by bit glitches on the bus

Jeremy Boone <[email protected]>
tpm: fix potential buffer overruns caused by bit glitches on the bus


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

Diffstat:

Makefile | 4 +-
arch/alpha/kernel/console.c | 1 +
arch/arm/kernel/ftrace.c | 11 ++--
arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
arch/ia64/kernel/module.c | 4 +-
arch/powerpc/kvm/book3s_64_mmu_host.c | 5 +-
arch/powerpc/kvm/book3s_pr.c | 6 ++-
arch/x86/kernel/i8259.c | 1 +
drivers/acpi/pmic/intel_pmic_xpower.c | 50 ++++++++---------
drivers/acpi/processor_driver.c | 10 +++-
drivers/acpi/processor_throttling.c | 62 +++++++++++++---------
drivers/block/mtip32xx/mtip32xx.c | 36 ++++++++-----
drivers/bluetooth/hci_qca.c | 3 ++
drivers/char/ipmi/ipmi_watchdog.c | 8 +--
drivers/char/tpm/tpm-interface.c | 5 ++
drivers/char/tpm/tpm2-cmd.c | 6 +++
drivers/char/tpm/tpm_tis.c | 5 +-
drivers/clk/bcm/clk-ns2.c | 2 +-
drivers/clk/clk-si5351.c | 2 +-
drivers/cpufreq/sh-cpufreq.c | 45 +++++++++-------
drivers/dma/ti-dma-crossbar.c | 10 +++-
drivers/gpu/drm/msm/msm_gem.c | 14 +++--
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 5 ++
drivers/hsi/clients/ssi_protocol.c | 5 +-
drivers/hwtracing/coresight/coresight-tpiu.c | 13 +++--
drivers/i2c/busses/i2c-scmi.c | 4 ++
drivers/iio/accel/st_accel_core.c | 7 +--
drivers/iio/pressure/st_pressure_core.c | 8 +--
drivers/infiniband/core/cma.c | 5 +-
drivers/infiniband/core/iwpm_util.c | 1 +
drivers/infiniband/core/umem.c | 2 +-
drivers/infiniband/core/uverbs_cmd.c | 13 ++++-
drivers/infiniband/hw/mlx4/main.c | 6 ++-
drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 2 +-
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 13 +++++
drivers/infiniband/ulp/ipoib/ipoib_main.c | 16 ++++++
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 11 ++--
drivers/input/misc/twl4030-pwrbutton.c | 2 +-
drivers/input/touchscreen/ar1021_i2c.c | 2 +-
drivers/iommu/intel-svm.c | 9 ++--
drivers/iommu/omap-iommu.c | 21 ++++++--
drivers/md/raid10.c | 6 +++
drivers/media/dvb-core/dvb_ca_en50221.c | 23 ++++++++
drivers/media/dvb-frontends/si2168.c | 3 ++
drivers/media/pci/bt8xx/bt878.c | 3 +-
.../media/platform/sti/c8sectpfe/c8sectpfe-core.c | 4 +-
drivers/mfd/palmas.c | 14 +++++
drivers/mmc/core/core.c | 8 +++
drivers/mmc/host/omap_hsmmc.c | 4 +-
drivers/mmc/host/sdhci-of-esdhc.c | 14 +++++
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 1 +
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 2 +-
.../net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c | 2 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 6 +++
.../ethernet/qlogic/qlcnic/qlcnic_sriov_common.c | 2 +
drivers/net/wan/pc300too.c | 1 +
drivers/net/wireless/ath/regd.c | 19 ++++---
drivers/net/wireless/mediatek/mt7601u/mcu.c | 10 +++-
drivers/net/wireless/realtek/rtlwifi/pci.c | 7 +++
drivers/net/wireless/rndis_wlan.c | 4 ++
drivers/pinctrl/core.c | 24 ++++++---
drivers/platform/chrome/cros_ec_proto.c | 8 +--
drivers/platform/chrome/cros_ec_sysfs.c | 2 +-
drivers/platform/x86/asus-nb-wmi.c | 9 ++++
drivers/power/pda_power.c | 49 +++++++++--------
drivers/ptp/ptp_clock.c | 18 +++----
drivers/regulator/anatop-regulator.c | 5 ++
drivers/rtc/rtc-cmos.c | 17 ++++--
drivers/rtc/rtc-ds1374.c | 10 +++-
drivers/scsi/lpfc/lpfc_sli.c | 3 ++
drivers/scsi/mac_esp.c | 33 ++++++++----
drivers/scsi/virtio_scsi.c | 24 +++++++++
drivers/spi/spi-dw-mmio.c | 2 +-
drivers/staging/android/ashmem.c | 8 ++-
drivers/staging/unisys/visorhba/visorhba_main.c | 8 ++-
drivers/staging/wilc1000/linux_mon.c | 2 +
drivers/target/target_core_file.c | 23 +++++---
drivers/tty/tty_io.c | 2 +
drivers/video/console/vgacon.c | 34 +++++++++---
drivers/video/fbdev/sm501fb.c | 1 +
drivers/video/fbdev/udlfb.c | 14 ++++-
fs/btrfs/send.c | 23 +++++++-
fs/cifs/netmisc.c | 6 +--
fs/cifs/sess.c | 22 ++++----
fs/cifs/smb2pdu.c | 11 ++--
fs/nfs/pagelist.c | 6 ++-
fs/nfsd/nfs4proc.c | 6 +--
fs/nfsd/vfs.c | 24 +++++++--
include/linux/posix-clock.h | 10 ++--
kernel/irq/manage.c | 4 +-
kernel/time/posix-clock.c | 34 ++++++++----
net/ipv4/tcp_input.c | 16 +++---
net/ipv6/ip6_vti.c | 20 +++++++
net/ipv6/ndisc.c | 2 +
net/mac80211/status.c | 1 +
net/netfilter/xt_CT.c | 11 +++-
net/openvswitch/conntrack.c | 30 ++++++++++-
sound/pci/hda/patch_realtek.c | 12 ++++-
sound/soc/intel/skylake/skl.c | 2 +-
tools/perf/tests/kmod-path.c | 2 +
103 files changed, 811 insertions(+), 303 deletions(-)




2018-03-23 10:14:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 01/97] tpm: fix potential buffer overruns caused by bit glitches on the bus

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Jeremy Boone <[email protected]>

commit 3be23274755ee85771270a23af7691dc9b3a95db upstream.

Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips. If a bit does
flip it could cause an overrun if it's in one of the size parameters,
so sanity check that we're not overrunning the provided buffer when
doing a memcpy().

Signed-off-by: Jeremy Boone <[email protected]>
Cc: [email protected]
Signed-off-by: James Bottomley <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Tested-by: Jarkko Sakkinen <[email protected]>
Signed-off-by: Jarkko Sakkinen <[email protected]>
Signed-off-by: James Morris <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/char/tpm/tpm-interface.c | 5 +++++
drivers/char/tpm/tpm2-cmd.c | 6 ++++++
2 files changed, 11 insertions(+)

--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1040,6 +1040,11 @@ int tpm_get_random(u32 chip_num, u8 *out
break;

recd = be32_to_cpu(tpm_cmd.params.getrandom_out.rng_data_len);
+ if (recd > num_bytes) {
+ total = -EFAULT;
+ break;
+ }
+
memcpy(dest, tpm_cmd.params.getrandom_out.rng_data, recd);

dest += recd;
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -622,6 +622,11 @@ static int tpm2_unseal_cmd(struct tpm_ch
if (!rc) {
data_len = be16_to_cpup(
(__be16 *) &buf.data[TPM_HEADER_SIZE + 4]);
+ if (data_len < MIN_KEY_SIZE || data_len > MAX_KEY_SIZE + 1) {
+ rc = -EFAULT;
+ goto out;
+ }
+
data = &buf.data[TPM_HEADER_SIZE + 6];

memcpy(payload->key, data, data_len - 1);
@@ -629,6 +634,7 @@ static int tpm2_unseal_cmd(struct tpm_ch
payload->migratable = data[data_len - 1];
}

+out:
tpm_buf_destroy(&buf);
return rc;
}



2018-03-23 10:14:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 14/97] cpufreq/sh: Replace racy task affinity logic

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Thomas Gleixner <[email protected]>


[ Upstream commit 205dcc1ecbc566cbc20acf246e68de3b080b3ecf ]

The target() callback must run on the affected cpu. This is achieved by
temporarily setting the affinity of the calling thread to the requested CPU
and reset it to the original affinity afterwards.

That's racy vs. concurrent affinity settings for that thread resulting in
code executing on the wrong CPU.

Replace it by work_on_cpu(). All call pathes which invoke the callbacks are
already protected against CPU hotplug.

Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Cc: Fenghua Yu <[email protected]>
Cc: Tony Luck <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Sebastian Siewior <[email protected]>
Cc: [email protected]
Cc: Lai Jiangshan <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Tejun Heo <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Len Brown <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/cpufreq/sh-cpufreq.c | 45 +++++++++++++++++++++++++------------------
1 file changed, 27 insertions(+), 18 deletions(-)

--- a/drivers/cpufreq/sh-cpufreq.c
+++ b/drivers/cpufreq/sh-cpufreq.c
@@ -30,54 +30,63 @@

static DEFINE_PER_CPU(struct clk, sh_cpuclk);

+struct cpufreq_target {
+ struct cpufreq_policy *policy;
+ unsigned int freq;
+};
+
static unsigned int sh_cpufreq_get(unsigned int cpu)
{
return (clk_get_rate(&per_cpu(sh_cpuclk, cpu)) + 500) / 1000;
}

-/*
- * Here we notify other drivers of the proposed change and the final change.
- */
-static int sh_cpufreq_target(struct cpufreq_policy *policy,
- unsigned int target_freq,
- unsigned int relation)
+static long __sh_cpufreq_target(void *arg)
{
- unsigned int cpu = policy->cpu;
+ struct cpufreq_target *target = arg;
+ struct cpufreq_policy *policy = target->policy;
+ int cpu = policy->cpu;
struct clk *cpuclk = &per_cpu(sh_cpuclk, cpu);
- cpumask_t cpus_allowed;
struct cpufreq_freqs freqs;
struct device *dev;
long freq;

- cpus_allowed = current->cpus_allowed;
- set_cpus_allowed_ptr(current, cpumask_of(cpu));
-
- BUG_ON(smp_processor_id() != cpu);
+ if (smp_processor_id() != cpu)
+ return -ENODEV;

dev = get_cpu_device(cpu);

/* Convert target_freq from kHz to Hz */
- freq = clk_round_rate(cpuclk, target_freq * 1000);
+ freq = clk_round_rate(cpuclk, target->freq * 1000);

if (freq < (policy->min * 1000) || freq > (policy->max * 1000))
return -EINVAL;

- dev_dbg(dev, "requested frequency %u Hz\n", target_freq * 1000);
+ dev_dbg(dev, "requested frequency %u Hz\n", target->freq * 1000);

freqs.old = sh_cpufreq_get(cpu);
freqs.new = (freq + 500) / 1000;
freqs.flags = 0;

- cpufreq_freq_transition_begin(policy, &freqs);
- set_cpus_allowed_ptr(current, &cpus_allowed);
+ cpufreq_freq_transition_begin(target->policy, &freqs);
clk_set_rate(cpuclk, freq);
- cpufreq_freq_transition_end(policy, &freqs, 0);
+ cpufreq_freq_transition_end(target->policy, &freqs, 0);

dev_dbg(dev, "set frequency %lu Hz\n", freq);
-
return 0;
}

+/*
+ * Here we notify other drivers of the proposed change and the final change.
+ */
+static int sh_cpufreq_target(struct cpufreq_policy *policy,
+ unsigned int target_freq,
+ unsigned int relation)
+{
+ struct cpufreq_target data = { .policy = policy, .freq = target_freq };
+
+ return work_on_cpu(policy->cpu, __sh_cpufreq_target, &data);
+}
+
static int sh_cpufreq_verify(struct cpufreq_policy *policy)
{
struct clk *cpuclk = &per_cpu(sh_cpuclk, policy->cpu);



2018-03-23 10:15:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 29/97] e1000e: fix timing for 82579 Gigabit Ethernet controller

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Bernd Faust <[email protected]>


[ Upstream commit 5313eeccd2d7f486be4e5c7560e3e2be239ec8f7 ]

After an upgrade to Linux kernel v4.x the hardware timestamps of the
82579 Gigabit Ethernet Controller are different than expected.
The values that are being read are almost four times as big as before
the kernel upgrade.

The difference is that after the upgrade the driver sets the clock
frequency to 25MHz, where before the upgrade it was set to 96MHz. Intel
confirmed that the correct frequency for this network adapter is 96MHz.

Signed-off-by: Bernd Faust <[email protected]>
Acked-by: Sasha Neftin <[email protected]>
Acked-by: Jacob Keller <[email protected]>
Tested-by: Aaron Brown <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -3526,6 +3526,12 @@ s32 e1000e_get_base_timinca(struct e1000

switch (hw->mac.type) {
case e1000_pch2lan:
+ /* Stable 96MHz frequency */
+ incperiod = INCPERIOD_96MHz;
+ incvalue = INCVALUE_96MHz;
+ shift = INCVALUE_SHIFT_96MHz;
+ adapter->cc.shift = shift + INCPERIOD_SHIFT_96MHz;
+ break;
case e1000_pch_lpt:
if (er32(TSYNCRXCTL) & E1000_TSYNCRXCTL_SYSCFI) {
/* Stable 96MHz frequency */



2018-03-23 10:16:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 20/97] ath: Fix updating radar flags for coutry code India

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Mohammed Shafi Shajakhan <[email protected]>


[ Upstream commit c0c345d4cacc6a1f39d4856f37dcf6e34f51a5e4 ]

As per latest regulatory update for India, channel 52, 56, 60, 64
is no longer restricted to DFS. Enabling DFS/no infra flags in driver
results in applying all DFS related restrictions (like doing CAC etc
before this channel moves to 'available state') for these channels
even though the country code is programmed as 'India' in he hardware,
fix this by relaxing the frequency range while applying RADAR flags
only if the country code is programmed to India. If the frequency range
needs to modified based on different country code, ath_is_radar_freq
can be extended/modified dynamically.

Signed-off-by: Mohammed Shafi Shajakhan <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/ath/regd.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)

--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -254,8 +254,12 @@ bool ath_is_49ghz_allowed(u16 regdomain)
EXPORT_SYMBOL(ath_is_49ghz_allowed);

/* Frequency is one where radar detection is required */
-static bool ath_is_radar_freq(u16 center_freq)
+static bool ath_is_radar_freq(u16 center_freq,
+ struct ath_regulatory *reg)
+
{
+ if (reg->country_code == CTRY_INDIA)
+ return (center_freq >= 5500 && center_freq <= 5700);
return (center_freq >= 5260 && center_freq <= 5700);
}

@@ -306,7 +310,7 @@ __ath_reg_apply_beaconing_flags(struct w
enum nl80211_reg_initiator initiator,
struct ieee80211_channel *ch)
{
- if (ath_is_radar_freq(ch->center_freq) ||
+ if (ath_is_radar_freq(ch->center_freq, reg) ||
(ch->flags & IEEE80211_CHAN_RADAR))
return;

@@ -395,8 +399,9 @@ ath_reg_apply_ir_flags(struct wiphy *wip
}
}

-/* Always apply Radar/DFS rules on freq range 5260 MHz - 5700 MHz */
-static void ath_reg_apply_radar_flags(struct wiphy *wiphy)
+/* Always apply Radar/DFS rules on freq range 5500 MHz - 5700 MHz */
+static void ath_reg_apply_radar_flags(struct wiphy *wiphy,
+ struct ath_regulatory *reg)
{
struct ieee80211_supported_band *sband;
struct ieee80211_channel *ch;
@@ -409,7 +414,7 @@ static void ath_reg_apply_radar_flags(st

for (i = 0; i < sband->n_channels; i++) {
ch = &sband->channels[i];
- if (!ath_is_radar_freq(ch->center_freq))
+ if (!ath_is_radar_freq(ch->center_freq, reg))
continue;
/* We always enable radar detection/DFS on this
* frequency range. Additionally we also apply on
@@ -505,7 +510,7 @@ void ath_reg_notifier_apply(struct wiphy
struct ath_common *common = container_of(reg, struct ath_common,
regulatory);
/* We always apply this */
- ath_reg_apply_radar_flags(wiphy);
+ ath_reg_apply_radar_flags(wiphy, reg);

/*
* This would happen when we have sent a custom regulatory request
@@ -653,7 +658,7 @@ ath_regd_init_wiphy(struct ath_regulator
}

wiphy_apply_custom_regulatory(wiphy, regd);
- ath_reg_apply_radar_flags(wiphy);
+ ath_reg_apply_radar_flags(wiphy, reg);
ath_reg_apply_world_flags(wiphy, NL80211_REGDOM_SET_BY_DRIVER, reg);
return 0;
}



2018-03-23 10:16:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 39/97] openvswitch: Delete conntrack entry clashing with an expectation.

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Jarno Rajahalme <[email protected]>


[ Upstream commit cf5d70918877c6a6655dc1e92e2ebb661ce904fd ]

Conntrack helpers do not check for a potentially clashing conntrack
entry when creating a new expectation. Also, nf_conntrack_in() will
check expectations (via init_conntrack()) only if a conntrack entry
can not be found. The expectation for a packet which also matches an
existing conntrack entry will not be removed by conntrack, and is
currently handled inconsistently by OVS, as OVS expects the
expectation to be removed when the connection tracking entry matching
that expectation is confirmed.

It should be noted that normally an IP stack would not allow reuse of
a 5-tuple of an old (possibly lingering) connection for a new data
connection, so this is somewhat unlikely corner case. However, it is
possible that a misbehaving source could cause conntrack entries be
created that could then interfere with new related connections.

Fix this in the OVS module by deleting the clashing conntrack entry
after an expectation has been matched. This causes the following
nf_conntrack_in() call also find the expectation and remove it when
creating the new conntrack entry, as well as the forthcoming reply
direction packets to match the new related connection instead of the
old clashing conntrack entry.

Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
Reported-by: Yang Song <[email protected]>
Signed-off-by: Jarno Rajahalme <[email protected]>
Acked-by: Joe Stringer <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/openvswitch/conntrack.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)

--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -361,10 +361,38 @@ ovs_ct_expect_find(struct net *net, cons
u16 proto, const struct sk_buff *skb)
{
struct nf_conntrack_tuple tuple;
+ struct nf_conntrack_expect *exp;

if (!nf_ct_get_tuplepr(skb, skb_network_offset(skb), proto, net, &tuple))
return NULL;
- return __nf_ct_expect_find(net, zone, &tuple);
+
+ exp = __nf_ct_expect_find(net, zone, &tuple);
+ if (exp) {
+ struct nf_conntrack_tuple_hash *h;
+
+ /* Delete existing conntrack entry, if it clashes with the
+ * expectation. This can happen since conntrack ALGs do not
+ * check for clashes between (new) expectations and existing
+ * conntrack entries. nf_conntrack_in() will check the
+ * expectations only if a conntrack entry can not be found,
+ * which can lead to OVS finding the expectation (here) in the
+ * init direction, but which will not be removed by the
+ * nf_conntrack_in() call, if a matching conntrack entry is
+ * found instead. In this case all init direction packets
+ * would be reported as new related packets, while reply
+ * direction packets would be reported as un-related
+ * established packets.
+ */
+ h = nf_conntrack_find_get(net, zone, &tuple);
+ if (h) {
+ struct nf_conn *ct = nf_ct_tuplehash_to_ctrack(h);
+
+ nf_ct_delete(ct, 0, 0);
+ nf_conntrack_put(&ct->ct_general);
+ }
+ }
+
+ return exp;
}

/* Determine whether skb->nfct is equal to the result of conntrack lookup. */



2018-03-23 10:16:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 41/97] wan: pc300too: abort path on failure

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Pan Bian <[email protected]>


[ Upstream commit 2a39e7aa8a98f777f0732ca7125b6c9668791760 ]

In function pc300_pci_init_one(), on the ioremap error path, function
pc300_pci_remove_one() is called to free the allocated memory. However,
the path is not terminated, and the freed memory will be used later,
resulting in use-after-free bugs. This path fixes the bug.

Signed-off-by: Pan Bian <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wan/pc300too.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/wan/pc300too.c
+++ b/drivers/net/wan/pc300too.c
@@ -347,6 +347,7 @@ static int pc300_pci_init_one(struct pci
card->rambase == NULL) {
pr_err("ioremap() failed\n");
pc300_pci_remove_one(pdev);
+ return -ENOMEM;
}

/* PLX PCI 9050 workaround for local configuration register read bug */



2018-03-23 10:16:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 31/97] IB/ipoib: Fix deadlock between ipoib_stop and mcast join flow

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Feras Daoud <[email protected]>


[ Upstream commit 3e31a490e01a6e67cbe9f6e1df2f3ff0fbf48972 ]

Before calling ipoib_stop, rtnl_lock should be taken, then
the flow clears the IPOIB_FLAG_ADMIN_UP and IPOIB_FLAG_OPER_UP
flags, and waits for mcast completion if IPOIB_MCAST_FLAG_BUSY
is set.

On the other hand, the flow of multicast join task initializes
a mcast completion, sets the IPOIB_MCAST_FLAG_BUSY and calls
ipoib_mcast_join. If IPOIB_FLAG_OPER_UP flag is not set, this
call returns EINVAL without setting the mcast completion and
leads to a deadlock.

ipoib_stop |
| |
clear_bit(IPOIB_FLAG_ADMIN_UP) |
| |
Context Switch |
| ipoib_mcast_join_task
| |
| spin_lock_irq(lock)
| |
| init_completion(mcast)
| |
| set_bit(IPOIB_MCAST_FLAG_BUSY)
| |
| Context Switch
| |
clear_bit(IPOIB_FLAG_OPER_UP) |
| |
spin_lock_irqsave(lock) |
| |
Context Switch |
| ipoib_mcast_join
| return (-EINVAL)
| |
| spin_unlock_irq(lock)
| |
| Context Switch
| |
ipoib_mcast_dev_flush |
wait_for_completion(mcast) |

ipoib_stop will wait for mcast completion for ever, and will
not release the rtnl_lock. As a result panic occurs with the
following trace:

[13441.639268] Call Trace:
[13441.640150] [<ffffffff8168b579>] schedule+0x29/0x70
[13441.641038] [<ffffffff81688fc9>] schedule_timeout+0x239/0x2d0
[13441.641914] [<ffffffff810bc017>] ? complete+0x47/0x50
[13441.642765] [<ffffffff810a690d>] ? flush_workqueue_prep_pwqs+0x16d/0x200
[13441.643580] [<ffffffff8168b956>] wait_for_completion+0x116/0x170
[13441.644434] [<ffffffff810c4ec0>] ? wake_up_state+0x20/0x20
[13441.645293] [<ffffffffa05af170>] ipoib_mcast_dev_flush+0x150/0x190 [ib_ipoib]
[13441.646159] [<ffffffffa05ac967>] ipoib_ib_dev_down+0x37/0x60 [ib_ipoib]
[13441.647013] [<ffffffffa05a4805>] ipoib_stop+0x75/0x150 [ib_ipoib]

Fixes: 08bc327629cb ("IB/ipoib: fix for rare multicast join race condition")
Signed-off-by: Feras Daoud <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)

--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -473,6 +473,9 @@ static int ipoib_mcast_join(struct net_d
!test_bit(IPOIB_FLAG_OPER_UP, &priv->flags))
return -EINVAL;

+ init_completion(&mcast->done);
+ set_bit(IPOIB_MCAST_FLAG_BUSY, &mcast->flags);
+
ipoib_dbg_mcast(priv, "joining MGID %pI6\n", mcast->mcmember.mgid.raw);

rec.mgid = mcast->mcmember.mgid;
@@ -631,8 +634,6 @@ void ipoib_mcast_join_task(struct work_s
if (mcast->backoff == 1 ||
time_after_eq(jiffies, mcast->delay_until)) {
/* Found the next unjoined group */
- init_completion(&mcast->done);
- set_bit(IPOIB_MCAST_FLAG_BUSY, &mcast->flags);
if (ipoib_mcast_join(dev, mcast)) {
spin_unlock_irq(&priv->lock);
return;
@@ -652,11 +653,9 @@ out:
queue_delayed_work(priv->wq, &priv->mcast_task,
delay_until - jiffies);
}
- if (mcast) {
- init_completion(&mcast->done);
- set_bit(IPOIB_MCAST_FLAG_BUSY, &mcast->flags);
+ if (mcast)
ipoib_mcast_join(dev, mcast);
- }
+
spin_unlock_irq(&priv->lock);
}




2018-03-23 10:16:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 61/97] power: supply: pda_power: move from timer to delayed_work

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Michael Trimarchi <[email protected]>


[ Upstream commit 633e8799ddc09431be2744c4a1efdbda13af2b0b ]

This changed is needed to avoid locking problem during
boot as shown:

<5>[ 8.824096] Registering SWP/SWPB emulation handler
<6>[ 8.977294] clock: disabling unused clocks to save power
<3>[ 9.108154] BUG: sleeping function called from invalid context at kernel_albert/kernel/mutex.c:269
<3>[ 9.122894] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
<4>[ 9.130249] 3 locks held by swapper/0/1:
<4>[ 9.134613] #0: (&__lockdep_no_validate__){......}, at: [<c0342430>] __driver_attach+0x58/0xa8
<4>[ 9.144500] #1: (&__lockdep_no_validate__){......}, at: [<c0342440>] __driver_attach+0x68/0xa8
<4>[ 9.154357] #2: (&polling_timer){......}, at: [<c0053770>] run_timer_softirq+0x108/0x3ec
<4>[ 9.163726] Backtrace:
<4>[ 9.166473] [<c001269c>] (dump_backtrace+0x0/0x114) from [<c067e5f0>] (dump_stack+0x20/0x24)
<4>[ 9.175811] r6:00203230 r5:0000010d r4:d782e000 r3:60000113
<4>[ 9.182250] [<c067e5d0>] (dump_stack+0x0/0x24) from [<c007441c>] (__might_sleep+0x10c/0x128)
<4>[ 9.191650] [<c0074310>] (__might_sleep+0x0/0x128) from [<c0688f60>] (mutex_lock_nested+0x34/0x36c)
<4>[ 9.201660] r5:c02d5350 r4:d79a0c64
<4>[ 9.205688] [<c0688f2c>] (mutex_lock_nested+0x0/0x36c) from [<c02d5350>] (regulator_set_current_limit+0x30/0x118)
<4>[ 9.217071] [<c02d5320>] (regulator_set_current_limit+0x0/0x118) from [<c0435ce0>] (update_charger+0x84/0xc4)
<4>[ 9.228027] r7:d782fb20 r6:00000101 r5:c1767e94 r4:00000000
<4>[ 9.234436] [<c0435c5c>] (update_charger+0x0/0xc4) from [<c0435d40>] (psy_changed+0x20/0x48)
<4>[ 9.243804] r5:d782e000 r4:c1767e94
<4>[ 9.247802] [<c0435d20>] (psy_changed+0x0/0x48) from [<c0435dec>] (polling_timer_func+0x84/0xb8)
<4>[ 9.257537] r4:c1767e94 r3:00000002
<4>[ 9.261566] [<c0435d68>] (polling_timer_func+0x0/0xb8) from [<c00537e4>] (run_timer_softirq+0x17c/0x3ec)
<4>[ 9.272033] r4:c1767eb0 r3:00000000
<4>[ 9.276062] [<c0053668>] (run_timer_softirq+0x0/0x3ec) from [<c004b000>] (__do_softirq+0xf0/0x298)
<4>[ 9.286010] [<c004af10>] (__do_softirq+0x0/0x298) from [<c004b650>] (irq_exit+0x98/0xa0)
<4>[ 9.295013] [<c004b5b8>] (irq_exit+0x0/0xa0) from [<c000edbc>] (handle_IRQ+0x60/0xc0)
<4>[ 9.303680] r4:c1194e98 r3:c00bc778
<4>[ 9.307708] [<c000ed5c>] (handle_IRQ+0x0/0xc0) from [<c0008504>] (gic_handle_irq+0x34/0x68)
<4>[ 9.316955] r8:000ac383 r7:d782fc3c r6:d782fc08 r5:c11936c4 r4:e0802100
<4>[ 9.324310] r3:c026ba48
<4>[ 9.327301] [<c00084d0>] (gic_handle_irq+0x0/0x68) from [<c068c2c0>] (__irq_svc+0x40/0x74)
<4>[ 9.336456] Exception stack(0xd782fc08 to 0xd782fc50)
<4>[ 9.342041] fc00: d6e30e6c ac383627 00000000 ac383417 ea19c000 ea200000
<4>[ 9.351104] fc20: beffffff 00000667 000ac383 d6e30670 d6e3066c d782fc94 d782fbe8 d782fc50
<4>[ 9.360168] fc40: c026ba48 c001d1f0 00000113 ffffffff

Fixes: b2998049cfae ("[BATTERY] pda_power platform driver")
Signed-off-by: Michael Trimarchi <[email protected]>
Signed-off-by: Anthony Brandon <[email protected]>
Signed-off-by: Sebastian Reichel <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/power/pda_power.c | 49 +++++++++++++++++++++++++---------------------
1 file changed, 27 insertions(+), 22 deletions(-)

--- a/drivers/power/pda_power.c
+++ b/drivers/power/pda_power.c
@@ -30,9 +30,9 @@ static inline unsigned int get_irq_flags
static struct device *dev;
static struct pda_power_pdata *pdata;
static struct resource *ac_irq, *usb_irq;
-static struct timer_list charger_timer;
-static struct timer_list supply_timer;
-static struct timer_list polling_timer;
+static struct delayed_work charger_work;
+static struct delayed_work polling_work;
+static struct delayed_work supply_work;
static int polling;
static struct power_supply *pda_psy_ac, *pda_psy_usb;

@@ -140,7 +140,7 @@ static void update_charger(void)
}
}

-static void supply_timer_func(unsigned long unused)
+static void supply_work_func(struct work_struct *work)
{
if (ac_status == PDA_PSY_TO_CHANGE) {
ac_status = new_ac_status;
@@ -161,11 +161,12 @@ static void psy_changed(void)
* Okay, charger set. Now wait a bit before notifying supplicants,
* charge power should stabilize.
*/
- mod_timer(&supply_timer,
- jiffies + msecs_to_jiffies(pdata->wait_for_charger));
+ cancel_delayed_work(&supply_work);
+ schedule_delayed_work(&supply_work,
+ msecs_to_jiffies(pdata->wait_for_charger));
}

-static void charger_timer_func(unsigned long unused)
+static void charger_work_func(struct work_struct *work)
{
update_status();
psy_changed();
@@ -184,13 +185,14 @@ static irqreturn_t power_changed_isr(int
* Wait a bit before reading ac/usb line status and setting charger,
* because ac/usb status readings may lag from irq.
*/
- mod_timer(&charger_timer,
- jiffies + msecs_to_jiffies(pdata->wait_for_status));
+ cancel_delayed_work(&charger_work);
+ schedule_delayed_work(&charger_work,
+ msecs_to_jiffies(pdata->wait_for_status));

return IRQ_HANDLED;
}

-static void polling_timer_func(unsigned long unused)
+static void polling_work_func(struct work_struct *work)
{
int changed = 0;

@@ -211,8 +213,9 @@ static void polling_timer_func(unsigned
if (changed)
psy_changed();

- mod_timer(&polling_timer,
- jiffies + msecs_to_jiffies(pdata->polling_interval));
+ cancel_delayed_work(&polling_work);
+ schedule_delayed_work(&polling_work,
+ msecs_to_jiffies(pdata->polling_interval));
}

#if IS_ENABLED(CONFIG_USB_PHY)
@@ -250,8 +253,9 @@ static int otg_handle_notification(struc
* Wait a bit before reading ac/usb line status and setting charger,
* because ac/usb status readings may lag from irq.
*/
- mod_timer(&charger_timer,
- jiffies + msecs_to_jiffies(pdata->wait_for_status));
+ cancel_delayed_work(&charger_work);
+ schedule_delayed_work(&charger_work,
+ msecs_to_jiffies(pdata->wait_for_status));

return NOTIFY_OK;
}
@@ -300,8 +304,8 @@ static int pda_power_probe(struct platfo
if (!pdata->ac_max_uA)
pdata->ac_max_uA = 500000;

- setup_timer(&charger_timer, charger_timer_func, 0);
- setup_timer(&supply_timer, supply_timer_func, 0);
+ INIT_DELAYED_WORK(&charger_work, charger_work_func);
+ INIT_DELAYED_WORK(&supply_work, supply_work_func);

ac_irq = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "ac");
usb_irq = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "usb");
@@ -385,9 +389,10 @@ static int pda_power_probe(struct platfo

if (polling) {
dev_dbg(dev, "will poll for status\n");
- setup_timer(&polling_timer, polling_timer_func, 0);
- mod_timer(&polling_timer,
- jiffies + msecs_to_jiffies(pdata->polling_interval));
+ INIT_DELAYED_WORK(&polling_work, polling_work_func);
+ cancel_delayed_work(&polling_work);
+ schedule_delayed_work(&polling_work,
+ msecs_to_jiffies(pdata->polling_interval));
}

if (ac_irq || usb_irq)
@@ -433,9 +438,9 @@ static int pda_power_remove(struct platf
free_irq(ac_irq->start, pda_psy_ac);

if (polling)
- del_timer_sync(&polling_timer);
- del_timer_sync(&charger_timer);
- del_timer_sync(&supply_timer);
+ cancel_delayed_work_sync(&polling_work);
+ cancel_delayed_work_sync(&charger_work);
+ cancel_delayed_work_sync(&supply_work);

if (pdata->is_usb_online)
power_supply_unregister(pda_psy_usb);



2018-03-23 10:17:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 55/97] mmc: sdhci-of-esdhc: limit SD clock for ls1012a/ls1046a

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: yangbo lu <[email protected]>


[ Upstream commit a627f025eb0534052ff451427c16750b3530634c ]

The ls1046a datasheet specified that the max SD clock frequency
for eSDHC SDR104/HS200 was 167MHz, and the ls1012a datasheet
specified it's 125MHz for ls1012a. So this patch is to add the
limitation.

Signed-off-by: Yangbo Lu <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mmc/host/sdhci-of-esdhc.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)

--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -418,6 +418,20 @@ static void esdhc_of_set_clock(struct sd
if (esdhc->vendor_ver < VENDOR_V_23)
pre_div = 2;

+ /*
+ * Limit SD clock to 167MHz for ls1046a according to its datasheet
+ */
+ if (clock > 167000000 &&
+ of_find_compatible_node(NULL, NULL, "fsl,ls1046a-esdhc"))
+ clock = 167000000;
+
+ /*
+ * Limit SD clock to 125MHz for ls1012a according to its datasheet
+ */
+ if (clock > 125000000 &&
+ of_find_compatible_node(NULL, NULL, "fsl,ls1012a-esdhc"))
+ clock = 125000000;
+
/* Workaround to reduce the clock frequency for p1010 esdhc */
if (of_find_compatible_node(NULL, NULL, "fsl,p1010-esdhc")) {
if (clock > 20000000)



2018-03-23 10:17:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 57/97] ipmi/watchdog: fix wdog hang on panic waiting for ipmi response

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Robert Lippert <[email protected]>


[ Upstream commit 2c1175c2e8e5487233cabde358a19577562ac83e ]

Commit c49c097610fe ("ipmi: Don't call receive handler in the
panic context") means that the panic_recv_free is not called during a
panic and the atomic count does not drop to 0.

Fix this by only expecting one decrement of the atomic variable
which comes from panic_smi_free.

Signed-off-by: Robert Lippert <[email protected]>
Signed-off-by: Corey Minyard <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/ipmi/ipmi_watchdog.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/char/ipmi/ipmi_watchdog.c
+++ b/drivers/char/ipmi/ipmi_watchdog.c
@@ -515,7 +515,7 @@ static void panic_halt_ipmi_heartbeat(vo
msg.cmd = IPMI_WDOG_RESET_TIMER;
msg.data = NULL;
msg.data_len = 0;
- atomic_add(2, &panic_done_count);
+ atomic_add(1, &panic_done_count);
rv = ipmi_request_supply_msgs(watchdog_user,
(struct ipmi_addr *) &addr,
0,
@@ -525,7 +525,7 @@ static void panic_halt_ipmi_heartbeat(vo
&panic_halt_heartbeat_recv_msg,
1);
if (rv)
- atomic_sub(2, &panic_done_count);
+ atomic_sub(1, &panic_done_count);
}

static struct ipmi_smi_msg panic_halt_smi_msg = {
@@ -549,12 +549,12 @@ static void panic_halt_ipmi_set_timeout(
/* Wait for the messages to be free. */
while (atomic_read(&panic_done_count) != 0)
ipmi_poll_interface(watchdog_user);
- atomic_add(2, &panic_done_count);
+ atomic_add(1, &panic_done_count);
rv = i_ipmi_set_timeout(&panic_halt_smi_msg,
&panic_halt_recv_msg,
&send_heartbeat_now);
if (rv) {
- atomic_sub(2, &panic_done_count);
+ atomic_sub(1, &panic_done_count);
printk(KERN_WARNING PFX
"Unable to extend the watchdog timeout.");
} else {



2018-03-23 10:17:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 74/97] media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt

4.4-stable review patch. If anyone has any objections, please let me know.

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

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


[ Upstream commit baed3c4bc4c13de93e0dba0a26d601411ebcb389 ]

_channel_ is being dereferenced before it is null checked, hence there is a
potential null pointer dereference. Fix this by moving the pointer dereference
after _channel_ has been null checked.

This issue was detected with the help of Coccinelle.

Fixes: c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support")

Signed-off-by: Gustavo A. R. Silva <[email protected]>
Acked-by: Patrice Chotard <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
+++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
@@ -83,7 +83,7 @@ static void c8sectpfe_timer_interrupt(un
static void channel_swdemux_tsklet(unsigned long data)
{
struct channel_info *channel = (struct channel_info *)data;
- struct c8sectpfei *fei = channel->fei;
+ struct c8sectpfei *fei;
unsigned long wp, rp;
int pos, num_packets, n, size;
u8 *buf;
@@ -91,6 +91,8 @@ static void channel_swdemux_tsklet(unsig
if (unlikely(!channel || !channel->irec))
return;

+ fei = channel->fei;
+
wp = readl(channel->irec + DMA_PRDS_BUSWP_TP(0));
rp = readl(channel->irec + DMA_PRDS_BUSRP_TP(0));




2018-03-23 10:17:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 59/97] drm/nouveau/kms: Increase max retries in scanout position queries.

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Mario Kleiner <[email protected]>


[ Upstream commit 60b95d709525e3ce1c51e1fc93175dcd1755d345 ]

So far we only allowed for 1 retry and just failed the query
- and thereby high precision vblank timestamping - if we did
not get a reasonable result, as such a failure wasn't considered
all too horrible. There are a few NVidia gpu models out there which
may need a bit more than 1 retry to get a successful query result
under some conditions.

Since Linux 4.4 the update code for vblank counter and timestamp
in drm_update_vblank_count() changed so that the implementation
assumes that high precision vblank timestamping of a kms driver
either consistently succeeds or consistently fails for a given
video mode and encoder/connector combo. Iow. switching from success
to fail or vice versa on a modeset or connector change is ok, but
spurious temporary failure for a given setup can confuse the core
code and potentially cause bad miscounting of vblanks and confusion
or hangs in userspace clients which rely on vblank stuff, e.g.,
desktop compositors.

Therefore change the max retry count to a larger number - more than
any gpu so far is known to need to succeed, but still low enough
so that these queries which do also happen in vblank interrupt are
still fast enough to be not disastrously long if something would
go badly wrong with them.

As such sporadic retries only happen seldom even on affected gpu's,
this could mean a vblank irq could take a few dozen microseconds
longer every few hours of uptime -- better than a desktop compositor
randomly hanging every couple of hours or days of uptime in a hard
to reproduce manner.

Signed-off-by: Mario Kleiner <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -104,7 +104,7 @@ nouveau_display_scanoutpos_head(struct d
};
struct nouveau_display *disp = nouveau_display(crtc->dev);
struct drm_vblank_crtc *vblank = &crtc->dev->vblank[drm_crtc_index(crtc)];
- int ret, retry = 1;
+ int ret, retry = 20;

do {
ret = nvif_mthd(&disp->disp, 0, &args, sizeof(args));



2018-03-23 10:18:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 68/97] net: hns: fix ethtool_get_strings overflow in hns driver

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Timmy Li <[email protected]>


[ Upstream commit 412b65d15a7f8a93794653968308fc100f2aa87c ]

hns_get_sset_count() returns HNS_NET_STATS_CNT and the data space allocated
is not enough for ethtool_get_strings(), which will cause random memory
corruption.

When SLAB and DEBUG_SLAB are both enabled, memory corruptions like the
the following can be observed without this patch:
[ 43.115200] Slab corruption (Not tainted): Acpi-ParseExt start=ffff801fb0b69030, len=80
[ 43.115206] Redzone: 0x9f911029d006462/0x5f78745f31657070.
[ 43.115208] Last user: [<5f7272655f746b70>](0x5f7272655f746b70)
[ 43.115214] 010: 70 70 65 31 5f 74 78 5f 70 6b 74 00 6b 6b 6b 6b ppe1_tx_pkt.kkkk
[ 43.115217] 030: 70 70 65 31 5f 74 78 5f 70 6b 74 5f 6f 6b 00 6b ppe1_tx_pkt_ok.k
[ 43.115218] Next obj: start=ffff801fb0b69098, len=80
[ 43.115220] Redzone: 0x706d655f6f666966/0x9f911029d74e35b.
[ 43.115229] Last user: [<ffff0000084b11b0>](acpi_os_release_object+0x28/0x38)
[ 43.115231] 000: 74 79 00 6b 6b 6b 6b 6b 70 70 65 31 5f 74 78 5f ty.kkkkkppe1_tx_
[ 43.115232] 010: 70 6b 74 5f 65 72 72 5f 63 73 75 6d 5f 66 61 69 pkt_err_csum_fai

Signed-off-by: Timmy Li <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
@@ -648,7 +648,7 @@ static void hns_gmac_get_strings(u32 str

static int hns_gmac_get_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
return ARRAY_SIZE(g_gmac_stats_string);

return 0;
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -384,7 +384,7 @@ void hns_ppe_update_stats(struct hns_ppe

int hns_ppe_get_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
return ETH_PPE_STATIC_NUM;
return 0;
}
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -807,7 +807,7 @@ void hns_rcb_get_stats(struct hnae_queue
*/
int hns_rcb_get_ring_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
return HNS_RING_STATIC_REG_NUM;

return 0;
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
@@ -776,7 +776,7 @@ static void hns_xgmac_get_strings(u32 st
*/
static int hns_xgmac_get_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
return ARRAY_SIZE(g_xgmac_stats_string);

return 0;



2018-03-23 10:18:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 72/97] perf tests kmod-path: Dont fail if compressed modules arent supported

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Kim Phillips <[email protected]>


[ Upstream commit 805b151a1afd24414706a7f6ae275fbb9649be74 ]

__kmod_path__parse() uses is_supported_compression() to determine and
parse out compressed module file extensions. On systems without zlib,
this test fails and __kmod_path__parse() continues to strcmp "ko" with
"gz". Don't do this on those systems.

Signed-off-by: Kim Phillips <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Fixes: 3c8a67f50a1e ("perf tools: Add kmod_path__parse function")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/perf/tests/kmod-path.c | 2 ++
1 file changed, 2 insertions(+)

--- a/tools/perf/tests/kmod-path.c
+++ b/tools/perf/tests/kmod-path.c
@@ -60,6 +60,7 @@ int test__kmod_path__parse(void)
M("/xxxx/xxxx/x-x.ko", PERF_RECORD_MISC_KERNEL, true);
M("/xxxx/xxxx/x-x.ko", PERF_RECORD_MISC_USER, false);

+#ifdef HAVE_ZLIB_SUPPORT
/* path alloc_name alloc_ext kmod comp name ext */
T("/xxxx/xxxx/x.ko.gz", true , true , true, true, "[x]", "gz");
T("/xxxx/xxxx/x.ko.gz", false , true , true, true, NULL , "gz");
@@ -95,6 +96,7 @@ int test__kmod_path__parse(void)
M("x.ko.gz", PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
M("x.ko.gz", PERF_RECORD_MISC_KERNEL, true);
M("x.ko.gz", PERF_RECORD_MISC_USER, false);
+#endif

/* path alloc_name alloc_ext kmod comp name ext */
T("[test_module]", true , true , true, false, "[test_module]", NULL);



2018-03-23 10:18:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 93/97] RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Anton Vasilyev <[email protected]>


[ Upstream commit 744820869166c8c78be891240cf5f66e8a333694 ]

Debugfs file reset_stats is created with S_IRUSR permissions,
but ocrdma_dbgfs_ops_read() doesn't support OCRDMA_RESET_STATS,
whereas ocrdma_dbgfs_ops_write() supports only OCRDMA_RESET_STATS.

The patch fixes misstype with permissions.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Vasilyev <[email protected]>
Acked-by: Selvin Xavier <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c
@@ -834,7 +834,7 @@ void ocrdma_add_port_stats(struct ocrdma

dev->reset_stats.type = OCRDMA_RESET_STATS;
dev->reset_stats.dev = dev;
- if (!debugfs_create_file("reset_stats", S_IRUSR, dev->dir,
+ if (!debugfs_create_file("reset_stats", 0200, dev->dir,
&dev->reset_stats, &ocrdma_dbg_ops))
goto err;




2018-03-23 10:18:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 95/97] clk: si5351: Rename internal plls to avoid name collisions

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Sergej Sawazki <[email protected]>


[ Upstream commit cdba9a4fb0b53703959ac861e415816cb61aded4 ]

This drivers probe fails due to a clock name collision if a clock named
'plla' or 'pllb' is already registered when registering this drivers
internal plls.

Fix it by renaming internal plls to avoid name collisions.

Cc: Sebastian Hesselbarth <[email protected]>
Cc: Rabeeh Khoury <[email protected]>
Signed-off-by: Sergej Sawazki <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/clk/clk-si5351.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -72,7 +72,7 @@ static const char * const si5351_input_n
"xtal", "clkin"
};
static const char * const si5351_pll_names[] = {
- "plla", "pllb", "vxco"
+ "si5351_plla", "si5351_pllb", "si5351_vxco"
};
static const char * const si5351_msynth_names[] = {
"ms0", "ms1", "ms2", "ms3", "ms4", "ms5", "ms6", "ms7"



2018-03-23 10:19:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 82/97] mmc: avoid removing non-removable hosts during suspend

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Daniel Drake <[email protected]>


[ Upstream commit de8dcc3d2c0e08e5068ee1e26fc46415c15e3637 ]

The Weibu F3C MiniPC has an onboard AP6255 module, presenting
two SDIO functions on a single MMC host (Bluetooth/btsdio and
WiFi/brcmfmac), and the mmc layer correctly detects this as
non-removable.

After suspend/resume, the wifi and bluetooth interfaces disappear
and do not get probed again.

The conditions here are:

1. During suspend, we reach mmc_pm_notify()

2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can
suspend the SDIO host. However, mmc_sdio_pre_suspend() returns
-ENOSYS because btsdio_driver does not have a suspend method.

3. mmc_pm_notify() proceeds to remove the card

4. Upon resume, mmc_rescan() does nothing with this host, because of
the rescan_entered check which aims to only scan a non-removable
device a single time (i.e. during boot).

Fix the loss of functionality by detecting that we are unable to
suspend a non-removable host, so avoid the forced removal in that
case. The comment above this function already indicates that this
code was only intended for removable devices.

Signed-off-by: Daniel Drake <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mmc/core/core.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2791,6 +2791,14 @@ int mmc_pm_notify(struct notifier_block
if (!err)
break;

+ if (!mmc_card_is_removable(host)) {
+ dev_warn(mmc_dev(host),
+ "pre_suspend failed for non-removable host: "
+ "%d\n", err);
+ /* Avoid removing non-removable hosts */
+ break;
+ }
+
/* Calling bus_ops->remove() with a claimed host can deadlock */
host->bus_ops->remove(host);
mmc_claim_host(host);



2018-03-23 10:36:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 90/97] pinctrl: Really force states during suspend/resume

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Florian Fainelli <[email protected]>


[ Upstream commit 981ed1bfbc6c4660b2ddaa8392893e20a6255048 ]

In case a platform only defaults a "default" set of pins, but not a
"sleep" set of pins, and this particular platform suspends and resumes
in a way that the pin states are not preserved by the hardware, when we
resume, we would call pinctrl_single_resume() -> pinctrl_force_default()
-> pinctrl_select_state() and the first thing we do is check that the
pins state is the same as before, and do nothing.

In order to fix this, decouple the actual state change from
pinctrl_select_state() and move it pinctrl_commit_state(), while keeping
the p->state == state check in pinctrl_select_state() not to change the
caller assumptions. pinctrl_force_sleep() and pinctrl_force_default()
are updated to bypass the state check by calling pinctrl_commit_state().

[Linus Walleij]
The forced pin control states are currently only used in some pin
controller drivers that grab their own reference to their own pins.
This is equal to the pin control hogs: pins taken by pin control
devices since there are no corresponding device in the Linux device
hierarchy, such as memory controller lines or unused GPIO lines,
or GPIO lines that are used orthogonally from the GPIO subsystem
but pincontrol-wise managed as hogs (non-strict mode, allowing
simultaneous use by GPIO and pin control). For this case forcing
the state from the drivers' suspend()/resume() callbacks makes
sense and should semantically match the name of the function.

Fixes: 6e5e959dde0d ("pinctrl: API changes to support multiple states per device")
Signed-off-by: Florian Fainelli <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pinctrl/core.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)

--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -979,19 +979,16 @@ struct pinctrl_state *pinctrl_lookup_sta
EXPORT_SYMBOL_GPL(pinctrl_lookup_state);

/**
- * pinctrl_select_state() - select/activate/program a pinctrl state to HW
+ * pinctrl_commit_state() - select/activate/program a pinctrl state to HW
* @p: the pinctrl handle for the device that requests configuration
* @state: the state handle to select/activate/program
*/
-int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
+static int pinctrl_commit_state(struct pinctrl *p, struct pinctrl_state *state)
{
struct pinctrl_setting *setting, *setting2;
struct pinctrl_state *old_state = p->state;
int ret;

- if (p->state == state)
- return 0;
-
if (p->state) {
/*
* For each pinmux setting in the old state, forget SW's record
@@ -1055,6 +1052,19 @@ unapply_new_state:

return ret;
}
+
+/**
+ * pinctrl_select_state() - select/activate/program a pinctrl state to HW
+ * @p: the pinctrl handle for the device that requests configuration
+ * @state: the state handle to select/activate/program
+ */
+int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
+{
+ if (p->state == state)
+ return 0;
+
+ return pinctrl_commit_state(p, state);
+}
EXPORT_SYMBOL_GPL(pinctrl_select_state);

static void devm_pinctrl_release(struct device *dev, void *res)
@@ -1223,7 +1233,7 @@ void pinctrl_unregister_map(struct pinct
int pinctrl_force_sleep(struct pinctrl_dev *pctldev)
{
if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_sleep))
- return pinctrl_select_state(pctldev->p, pctldev->hog_sleep);
+ return pinctrl_commit_state(pctldev->p, pctldev->hog_sleep);
return 0;
}
EXPORT_SYMBOL_GPL(pinctrl_force_sleep);
@@ -1235,7 +1245,7 @@ EXPORT_SYMBOL_GPL(pinctrl_force_sleep);
int pinctrl_force_default(struct pinctrl_dev *pctldev)
{
if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_default))
- return pinctrl_select_state(pctldev->p, pctldev->hog_default);
+ return pinctrl_commit_state(pctldev->p, pctldev->hog_default);
return 0;
}
EXPORT_SYMBOL_GPL(pinctrl_force_default);



2018-03-23 10:37:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 91/97] iommu/vt-d: clean up pr_irq if request_threaded_irq fails

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Jerry Snitselaar <[email protected]>


[ Upstream commit 72d548113881dd32bf7f0b221d031e6586468437 ]

It is unlikely request_threaded_irq will fail, but if it does for some
reason we should clear iommu->pr_irq in the error path. Also
intel_svm_finish_prq shouldn't try to clean up the page request
interrupt if pr_irq is 0. Without these, if request_threaded_irq were
to fail the following occurs:

fail with no fixes:

[ 0.683147] ------------[ cut here ]------------
[ 0.683148] NULL pointer, cannot free irq
[ 0.683158] WARNING: CPU: 1 PID: 1 at kernel/irq/irqdomain.c:1632 irq_domain_free_irqs+0x126/0x140
[ 0.683160] Modules linked in:
[ 0.683163] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2 #3
[ 0.683165] Hardware name: /NUC7i3BNB, BIOS BNKBL357.86A.0036.2017.0105.1112 01/05/2017
[ 0.683168] RIP: 0010:irq_domain_free_irqs+0x126/0x140
[ 0.683169] RSP: 0000:ffffc90000037ce8 EFLAGS: 00010292
[ 0.683171] RAX: 000000000000001d RBX: ffff880276283c00 RCX: ffffffff81c5e5e8
[ 0.683172] RDX: 0000000000000001 RSI: 0000000000000096 RDI: 0000000000000246
[ 0.683174] RBP: ffff880276283c00 R08: 0000000000000000 R09: 000000000000023c
[ 0.683175] R10: 0000000000000007 R11: 0000000000000000 R12: 000000000000007a
[ 0.683176] R13: 0000000000000001 R14: 0000000000000000 R15: 0000010010000000
[ 0.683178] FS: 0000000000000000(0000) GS:ffff88027ec80000(0000) knlGS:0000000000000000
[ 0.683180] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.683181] CR2: 0000000000000000 CR3: 0000000001c09001 CR4: 00000000003606e0
[ 0.683182] Call Trace:
[ 0.683189] intel_svm_finish_prq+0x3c/0x60
[ 0.683191] free_dmar_iommu+0x1ac/0x1b0
[ 0.683195] init_dmars+0xaaa/0xaea
[ 0.683200] ? klist_next+0x19/0xc0
[ 0.683203] ? pci_do_find_bus+0x50/0x50
[ 0.683205] ? pci_get_dev_by_id+0x52/0x70
[ 0.683208] intel_iommu_init+0x498/0x5c7
[ 0.683211] pci_iommu_init+0x13/0x3c
[ 0.683214] ? e820__memblock_setup+0x61/0x61
[ 0.683217] do_one_initcall+0x4d/0x1a0
[ 0.683220] kernel_init_freeable+0x186/0x20e
[ 0.683222] ? set_debug_rodata+0x11/0x11
[ 0.683225] ? rest_init+0xb0/0xb0
[ 0.683226] kernel_init+0xa/0xff
[ 0.683229] ret_from_fork+0x1f/0x30
[ 0.683259] Code: 89 ee 44 89 e7 e8 3b e8 ff ff 5b 5d 44 89 e7 44 89 ee 41 5c 41 5d 41 5e e9 a8 84 ff ff 48 c7 c7 a8 71 a7 81 31 c0 e8 6a d3 f9 ff <0f> ff 5b 5d 41 5c 41 5d 41 5
e c3 0f 1f 44 00 00 66 2e 0f 1f 84
[ 0.683285] ---[ end trace f7650e42792627ca ]---

with iommu->pr_irq = 0, but no check in intel_svm_finish_prq:

[ 0.669561] ------------[ cut here ]------------
[ 0.669563] Trying to free already-free IRQ 0
[ 0.669573] WARNING: CPU: 3 PID: 1 at kernel/irq/manage.c:1546 __free_irq+0xa4/0x2c0
[ 0.669574] Modules linked in:
[ 0.669577] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2 #4
[ 0.669579] Hardware name: /NUC7i3BNB, BIOS BNKBL357.86A.0036.2017.0105.1112 01/05/2017
[ 0.669581] RIP: 0010:__free_irq+0xa4/0x2c0
[ 0.669582] RSP: 0000:ffffc90000037cc0 EFLAGS: 00010082
[ 0.669584] RAX: 0000000000000021 RBX: 0000000000000000 RCX: ffffffff81c5e5e8
[ 0.669585] RDX: 0000000000000001 RSI: 0000000000000086 RDI: 0000000000000046
[ 0.669587] RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000023c
[ 0.669588] R10: 0000000000000007 R11: 0000000000000000 R12: ffff880276253960
[ 0.669589] R13: ffff8802762538a4 R14: ffff880276253800 R15: ffff880276283600
[ 0.669593] FS: 0000000000000000(0000) GS:ffff88027ed80000(0000) knlGS:0000000000000000
[ 0.669594] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.669596] CR2: 0000000000000000 CR3: 0000000001c09001 CR4: 00000000003606e0
[ 0.669602] Call Trace:
[ 0.669616] free_irq+0x30/0x60
[ 0.669620] intel_svm_finish_prq+0x34/0x60
[ 0.669623] free_dmar_iommu+0x1ac/0x1b0
[ 0.669627] init_dmars+0xaaa/0xaea
[ 0.669631] ? klist_next+0x19/0xc0
[ 0.669634] ? pci_do_find_bus+0x50/0x50
[ 0.669637] ? pci_get_dev_by_id+0x52/0x70
[ 0.669639] intel_iommu_init+0x498/0x5c7
[ 0.669642] pci_iommu_init+0x13/0x3c
[ 0.669645] ? e820__memblock_setup+0x61/0x61
[ 0.669648] do_one_initcall+0x4d/0x1a0
[ 0.669651] kernel_init_freeable+0x186/0x20e
[ 0.669653] ? set_debug_rodata+0x11/0x11
[ 0.669656] ? rest_init+0xb0/0xb0
[ 0.669658] kernel_init+0xa/0xff
[ 0.669661] ret_from_fork+0x1f/0x30
[ 0.669662] Code: 7a 08 75 0e e9 c3 01 00 00 4c 39 7b 08 74 57 48 89 da 48 8b 5a 18 48 85 db 75 ee 89 ee 48 c7 c7 78 67 a7 81 31 c0 e8 4c 37 fa ff <0f> ff 48 8b 34 24 4c 89 ef e
8 0e 4c 68 00 49 8b 46 40 48 8b 80
[ 0.669688] ---[ end trace 58a470248700f2fc ]---

Cc: Alex Williamson <[email protected]>
Cc: Joerg Roedel <[email protected]>
Cc: Ashok Raj <[email protected]>
Signed-off-by: Jerry Snitselaar <[email protected]>
Reviewed-by: Ashok Raj <[email protected]>
Signed-off-by: Alex Williamson <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/iommu/intel-svm.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)

--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -127,6 +127,7 @@ int intel_svm_enable_prq(struct intel_io
pr_err("IOMMU: %s: Failed to request IRQ for page request queue\n",
iommu->name);
dmar_free_hwirq(irq);
+ iommu->pr_irq = 0;
goto err;
}
dmar_writeq(iommu->reg + DMAR_PQH_REG, 0ULL);
@@ -142,9 +143,11 @@ int intel_svm_finish_prq(struct intel_io
dmar_writeq(iommu->reg + DMAR_PQT_REG, 0ULL);
dmar_writeq(iommu->reg + DMAR_PQA_REG, 0ULL);

- free_irq(iommu->pr_irq, iommu);
- dmar_free_hwirq(iommu->pr_irq);
- iommu->pr_irq = 0;
+ if (iommu->pr_irq) {
+ free_irq(iommu->pr_irq, iommu);
+ dmar_free_hwirq(iommu->pr_irq);
+ iommu->pr_irq = 0;
+ }

free_pages((unsigned long)iommu->prq, PRQ_ORDER);
iommu->prq = NULL;



2018-03-23 10:37:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 88/97] pty: cancel pty slave port bufs work in tty_release

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Sahara <[email protected]>


[ Upstream commit 2b022ab7542df60021ab57854b3faaaf42552eaf ]

In case that CONFIG_SLUB_DEBUG is on and pty is used, races between
release_one_tty and flush_to_ldisc work threads may happen and lead
to use-after-free condition on tty->link->port. Because SLUB_DEBUG
is turned on, freed tty->link->port is filled with POISON_FREE value.
So far without SLUB_DEBUG, port was filled with zero and flush_to_ldisc
could return without a problem by checking if tty is NULL.

CPU 0 CPU 1
----- -----
release_tty pty_write
cancel_work_sync(tty) to = tty->link
tty_kref_put(tty->link) tty_schedule_flip(to->port)
<< workqueue >> ...
release_one_tty ...
pty_cleanup ...
kfree(tty->link->port) << workqueue >>
flush_to_ldisc
tty = READ_ONCE(port->itty)
tty is 0x6b6b6b6b6b6b6b6b
!!PANIC!! access tty->ldisc

Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b93
pgd = ffffffc0eb1c3000
[6b6b6b6b6b6b6b93] *pgd=0000000000000000, *pud=0000000000000000
------------[ cut here ]------------
Kernel BUG at ffffff800851154c [verbose debug info unavailable]
Internal error: Oops - BUG: 96000004 [#1] PREEMPT SMP
CPU: 3 PID: 265 Comm: kworker/u8:9 Tainted: G W 3.18.31-g0a58eeb #1
Hardware name: Qualcomm Technologies, Inc. MSM 8996pro v1.1 + PMI8996 Carbide (DT)
Workqueue: events_unbound flush_to_ldisc
task: ffffffc0ed610ec0 ti: ffffffc0ed624000 task.ti: ffffffc0ed624000
PC is at ldsem_down_read_trylock+0x0/0x4c
LR is at tty_ldisc_ref+0x24/0x4c
pc : [<ffffff800851154c>] lr : [<ffffff800850f6c0>] pstate: 80400145
sp : ffffffc0ed627cd0
x29: ffffffc0ed627cd0 x28: 0000000000000000
x27: ffffff8009e05000 x26: ffffffc0d382cfa0
x25: 0000000000000000 x24: ffffff800a012f08
x23: 0000000000000000 x22: ffffffc0703fbc88
x21: 6b6b6b6b6b6b6b6b x20: 6b6b6b6b6b6b6b93
x19: 0000000000000000 x18: 0000000000000001
x17: 00e80000f80d6f53 x16: 0000000000000001
x15: 0000007f7d826fff x14: 00000000000000a0
x13: 0000000000000000 x12: 0000000000000109
x11: 0000000000000000 x10: 0000000000000000
x9 : ffffffc0ed624000 x8 : ffffffc0ed611580
x7 : 0000000000000000 x6 : ffffff800a42e000
x5 : 00000000000003fc x4 : 0000000003bd1201
x3 : 0000000000000001 x2 : 0000000000000001
x1 : ffffff800851004c x0 : 6b6b6b6b6b6b6b93

Signed-off-by: Sahara <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/tty_io.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1694,6 +1694,8 @@ static void release_tty(struct tty_struc
if (tty->link)
tty->link->port->itty = NULL;
tty_buffer_cancel_work(tty->port);
+ if (tty->link)
+ tty_buffer_cancel_work(tty->link->port);

tty_kref_put(tty->link);
tty_kref_put(tty);



2018-03-23 10:37:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 86/97] vgacon: Set VGA struct resource types

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Bjorn Helgaas <[email protected]>


[ Upstream commit c82084117f79bcae085e40da526253736a247120 ]

Set the resource type when we reserve VGA-related I/O port resources.

The resource code doesn't actually look at the type, so it inserts
resources without a type in the tree correctly even without this change.
But if we ever print a resource without a type, it looks like this:

vga+ [??? 0x000003c0-0x000003df flags 0x0]

Setting the type means it will be printed correctly as:

vga+ [io 0x000003c0-0x000003df]

Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/alpha/kernel/console.c | 1 +
drivers/video/console/vgacon.c | 34 ++++++++++++++++++++++++++--------
2 files changed, 27 insertions(+), 8 deletions(-)

--- a/arch/alpha/kernel/console.c
+++ b/arch/alpha/kernel/console.c
@@ -20,6 +20,7 @@
struct pci_controller *pci_vga_hose;
static struct resource alpha_vga = {
.name = "alpha-vga+",
+ .flags = IORESOURCE_IO,
.start = 0x3C0,
.end = 0x3DF
};
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -409,7 +409,10 @@ static const char *vgacon_startup(void)
vga_video_port_val = VGA_CRT_DM;
if ((screen_info.orig_video_ega_bx & 0xff) != 0x10) {
static struct resource ega_console_resource =
- { .name = "ega", .start = 0x3B0, .end = 0x3BF };
+ { .name = "ega",
+ .flags = IORESOURCE_IO,
+ .start = 0x3B0,
+ .end = 0x3BF };
vga_video_type = VIDEO_TYPE_EGAM;
vga_vram_size = 0x8000;
display_desc = "EGA+";
@@ -417,9 +420,15 @@ static const char *vgacon_startup(void)
&ega_console_resource);
} else {
static struct resource mda1_console_resource =
- { .name = "mda", .start = 0x3B0, .end = 0x3BB };
+ { .name = "mda",
+ .flags = IORESOURCE_IO,
+ .start = 0x3B0,
+ .end = 0x3BB };
static struct resource mda2_console_resource =
- { .name = "mda", .start = 0x3BF, .end = 0x3BF };
+ { .name = "mda",
+ .flags = IORESOURCE_IO,
+ .start = 0x3BF,
+ .end = 0x3BF };
vga_video_type = VIDEO_TYPE_MDA;
vga_vram_size = 0x2000;
display_desc = "*MDA";
@@ -441,15 +450,21 @@ static const char *vgacon_startup(void)
vga_vram_size = 0x8000;

if (!screen_info.orig_video_isVGA) {
- static struct resource ega_console_resource
- = { .name = "ega", .start = 0x3C0, .end = 0x3DF };
+ static struct resource ega_console_resource =
+ { .name = "ega",
+ .flags = IORESOURCE_IO,
+ .start = 0x3C0,
+ .end = 0x3DF };
vga_video_type = VIDEO_TYPE_EGAC;
display_desc = "EGA";
request_resource(&ioport_resource,
&ega_console_resource);
} else {
- static struct resource vga_console_resource
- = { .name = "vga+", .start = 0x3C0, .end = 0x3DF };
+ static struct resource vga_console_resource =
+ { .name = "vga+",
+ .flags = IORESOURCE_IO,
+ .start = 0x3C0,
+ .end = 0x3DF };
vga_video_type = VIDEO_TYPE_VGAC;
display_desc = "VGA+";
request_resource(&ioport_resource,
@@ -493,7 +508,10 @@ static const char *vgacon_startup(void)
}
} else {
static struct resource cga_console_resource =
- { .name = "cga", .start = 0x3D4, .end = 0x3D5 };
+ { .name = "cga",
+ .flags = IORESOURCE_IO,
+ .start = 0x3D4,
+ .end = 0x3D5 };
vga_video_type = VIDEO_TYPE_CGA;
vga_vram_size = 0x2000;
display_desc = "*CGA";



2018-03-23 10:38:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 87/97] drm/omap: DMM: Check for DMM readiness after successful transaction commit

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Peter Ujfalusi <[email protected]>


[ Upstream commit b7ea6b286c4051e043f691781785e3c4672f014a ]

Check the status of the DMM engine after it is reported that the
transaction was completed as in rare cases the engine might not reached a
working state.

The wait_status() will print information in case the DMM is not reached the
expected state and the dmm_txn_commit() will return with an error code to
make sure that we are not continuing with a broken setup.

Signed-off-by: Peter Ujfalusi <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -288,7 +288,12 @@ static int dmm_txn_commit(struct dmm_txn
msecs_to_jiffies(100))) {
dev_err(dmm->dev, "timed out waiting for done\n");
ret = -ETIMEDOUT;
+ goto cleanup;
}
+
+ /* Check the engine status before continue */
+ ret = wait_status(engine, DMM_PATSTATUS_READY |
+ DMM_PATSTATUS_VALID | DMM_PATSTATUS_DONE);
}

cleanup:



2018-03-23 10:38:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 85/97] IB/umem: Fix use of npages/nmap fields

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Artemy Kovalyov <[email protected]>


[ Upstream commit edf1a84fe37c51290e2c88154ecaf48dadff3d27 ]

In ib_umem structure npages holds original number of sg entries, while
nmap is number of DMA blocks returned by dma_map_sg.

Fixes: c5d76f130b28 ('IB/core: Add umem function to read data from user-space')
Signed-off-by: Artemy Kovalyov <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/core/umem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -354,7 +354,7 @@ int ib_umem_copy_from(void *dst, struct
return -EINVAL;
}

- ret = sg_pcopy_to_buffer(umem->sg_head.sgl, umem->nmap, dst, length,
+ ret = sg_pcopy_to_buffer(umem->sg_head.sgl, umem->npages, dst, length,
offset + ib_umem_offset(umem));

if (ret < 0)



2018-03-23 10:38:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 97/97] RDMA/ucma: Fix access to non-initialized CM_ID object

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Leon Romanovsky <[email protected]>

commit 7688f2c3bbf55e52388e37ac5d63ca471a7712e1 upstream.

The attempt to join multicast group without ensuring that CMA device
exists will lead to the following crash reported by syzkaller.

[ 64.076794] BUG: KASAN: null-ptr-deref in rdma_join_multicast+0x26e/0x12c0
[ 64.076797] Read of size 8 at addr 00000000000000b0 by task join/691
[ 64.076797]
[ 64.076800] CPU: 1 PID: 691 Comm: join Not tainted 4.16.0-rc1-00219-gb97853b65b93 #23
[ 64.076802] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-proj4
[ 64.076803] Call Trace:
[ 64.076809] dump_stack+0x5c/0x77
[ 64.076817] kasan_report+0x163/0x380
[ 64.085859] ? rdma_join_multicast+0x26e/0x12c0
[ 64.086634] rdma_join_multicast+0x26e/0x12c0
[ 64.087370] ? rdma_disconnect+0xf0/0xf0
[ 64.088579] ? __radix_tree_replace+0xc3/0x110
[ 64.089132] ? node_tag_clear+0x81/0xb0
[ 64.089606] ? idr_alloc_u32+0x12e/0x1a0
[ 64.090517] ? __fprop_inc_percpu_max+0x150/0x150
[ 64.091768] ? tracing_record_taskinfo+0x10/0xc0
[ 64.092340] ? idr_alloc+0x76/0xc0
[ 64.092951] ? idr_alloc_u32+0x1a0/0x1a0
[ 64.093632] ? ucma_process_join+0x23d/0x460
[ 64.094510] ucma_process_join+0x23d/0x460
[ 64.095199] ? ucma_migrate_id+0x440/0x440
[ 64.095696] ? futex_wake+0x10b/0x2a0
[ 64.096159] ucma_join_multicast+0x88/0xe0
[ 64.096660] ? ucma_process_join+0x460/0x460
[ 64.097540] ? _copy_from_user+0x5e/0x90
[ 64.098017] ucma_write+0x174/0x1f0
[ 64.098640] ? ucma_resolve_route+0xf0/0xf0
[ 64.099343] ? rb_erase_cached+0x6c7/0x7f0
[ 64.099839] __vfs_write+0xc4/0x350
[ 64.100622] ? perf_syscall_enter+0xe4/0x5f0
[ 64.101335] ? kernel_read+0xa0/0xa0
[ 64.103525] ? perf_sched_cb_inc+0xc0/0xc0
[ 64.105510] ? syscall_exit_register+0x2a0/0x2a0
[ 64.107359] ? __switch_to+0x351/0x640
[ 64.109285] ? fsnotify+0x899/0x8f0
[ 64.111610] ? fsnotify_unmount_inodes+0x170/0x170
[ 64.113876] ? __fsnotify_update_child_dentry_flags+0x30/0x30
[ 64.115813] ? ring_buffer_record_is_on+0xd/0x20
[ 64.117824] ? __fget+0xa8/0xf0
[ 64.119869] vfs_write+0xf7/0x280
[ 64.122001] SyS_write+0xa1/0x120
[ 64.124213] ? SyS_read+0x120/0x120
[ 64.126644] ? SyS_read+0x120/0x120
[ 64.128563] do_syscall_64+0xeb/0x250
[ 64.130732] entry_SYSCALL_64_after_hwframe+0x21/0x86
[ 64.132984] RIP: 0033:0x7f5c994ade99
[ 64.135699] RSP: 002b:00007f5c99b97d98 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 64.138740] RAX: ffffffffffffffda RBX: 00000000200001e4 RCX: 00007f5c994ade99
[ 64.141056] RDX: 00000000000000a0 RSI: 00000000200001c0 RDI: 0000000000000015
[ 64.143536] RBP: 00007f5c99b97ec0 R08: 0000000000000000 R09: 0000000000000000
[ 64.146017] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f5c99b97fc0
[ 64.148608] R13: 0000000000000000 R14: 00007fff660e1c40 R15: 00007f5c99b989c0
[ 64.151060]
[ 64.153703] Disabling lock debugging due to kernel taint
[ 64.156032] BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0
[ 64.159066] IP: rdma_join_multicast+0x26e/0x12c0
[ 64.161451] PGD 80000001d0298067 P4D 80000001d0298067 PUD 1dea39067 PMD 0
[ 64.164442] Oops: 0000 [#1] SMP KASAN PTI
[ 64.166817] CPU: 1 PID: 691 Comm: join Tainted: G B 4.16.0-rc1-00219-gb97853b65b93 #23
[ 64.170004] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-proj4
[ 64.174985] RIP: 0010:rdma_join_multicast+0x26e/0x12c0
[ 64.177246] RSP: 0018:ffff8801c8207860 EFLAGS: 00010282
[ 64.179901] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff94789522
[ 64.183344] RDX: 1ffffffff2d50fa5 RSI: 0000000000000297 RDI: 0000000000000297
[ 64.186237] RBP: ffff8801c8207a50 R08: 0000000000000000 R09: ffffed0039040ea7
[ 64.189328] R10: 0000000000000001 R11: ffffed0039040ea6 R12: 0000000000000000
[ 64.192634] R13: 0000000000000000 R14: ffff8801e2022800 R15: ffff8801d4ac2400
[ 64.196105] FS: 00007f5c99b98700(0000) GS:ffff8801e5d00000(0000) knlGS:0000000000000000
[ 64.199211] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 64.202046] CR2: 00000000000000b0 CR3: 00000001d1c48004 CR4: 00000000003606a0
[ 64.205032] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 64.208221] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 64.211554] Call Trace:
[ 64.213464] ? rdma_disconnect+0xf0/0xf0
[ 64.216124] ? __radix_tree_replace+0xc3/0x110
[ 64.219337] ? node_tag_clear+0x81/0xb0
[ 64.222140] ? idr_alloc_u32+0x12e/0x1a0
[ 64.224422] ? __fprop_inc_percpu_max+0x150/0x150
[ 64.226588] ? tracing_record_taskinfo+0x10/0xc0
[ 64.229763] ? idr_alloc+0x76/0xc0
[ 64.232186] ? idr_alloc_u32+0x1a0/0x1a0
[ 64.234505] ? ucma_process_join+0x23d/0x460
[ 64.237024] ucma_process_join+0x23d/0x460
[ 64.240076] ? ucma_migrate_id+0x440/0x440
[ 64.243284] ? futex_wake+0x10b/0x2a0
[ 64.245302] ucma_join_multicast+0x88/0xe0
[ 64.247783] ? ucma_process_join+0x460/0x460
[ 64.250841] ? _copy_from_user+0x5e/0x90
[ 64.253878] ucma_write+0x174/0x1f0
[ 64.257008] ? ucma_resolve_route+0xf0/0xf0
[ 64.259877] ? rb_erase_cached+0x6c7/0x7f0
[ 64.262746] __vfs_write+0xc4/0x350
[ 64.265537] ? perf_syscall_enter+0xe4/0x5f0
[ 64.267792] ? kernel_read+0xa0/0xa0
[ 64.270358] ? perf_sched_cb_inc+0xc0/0xc0
[ 64.272575] ? syscall_exit_register+0x2a0/0x2a0
[ 64.275367] ? __switch_to+0x351/0x640
[ 64.277700] ? fsnotify+0x899/0x8f0
[ 64.280530] ? fsnotify_unmount_inodes+0x170/0x170
[ 64.283156] ? __fsnotify_update_child_dentry_flags+0x30/0x30
[ 64.286182] ? ring_buffer_record_is_on+0xd/0x20
[ 64.288749] ? __fget+0xa8/0xf0
[ 64.291136] vfs_write+0xf7/0x280
[ 64.292972] SyS_write+0xa1/0x120
[ 64.294965] ? SyS_read+0x120/0x120
[ 64.297474] ? SyS_read+0x120/0x120
[ 64.299751] do_syscall_64+0xeb/0x250
[ 64.301826] entry_SYSCALL_64_after_hwframe+0x21/0x86
[ 64.304352] RIP: 0033:0x7f5c994ade99
[ 64.306711] RSP: 002b:00007f5c99b97d98 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 64.309577] RAX: ffffffffffffffda RBX: 00000000200001e4 RCX: 00007f5c994ade99
[ 64.312334] RDX: 00000000000000a0 RSI: 00000000200001c0 RDI: 0000000000000015
[ 64.315783] RBP: 00007f5c99b97ec0 R08: 0000000000000000 R09: 0000000000000000
[ 64.318365] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f5c99b97fc0
[ 64.320980] R13: 0000000000000000 R14: 00007fff660e1c40 R15: 00007f5c99b989c0
[ 64.323515] Code: e8 e8 79 08 ff 4c 89 ff 45 0f b6 a7 b8 01 00 00 e8 68 7c 08 ff 49 8b 1f 4d 89 e5 49 c1 e4 04 48 8
[ 64.330753] RIP: rdma_join_multicast+0x26e/0x12c0 RSP: ffff8801c8207860
[ 64.332979] CR2: 00000000000000b0
[ 64.335550] ---[ end trace 0c00c17a408849c1 ]---

Reported-by: <[email protected]>
Fixes: c8f6a362bf3e ("RDMA/cma: Add multicast communication support")
Signed-off-by: Leon Romanovsky <[email protected]>
Reviewed-by: Sean Hefty <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/core/cma.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -3743,6 +3743,9 @@ int rdma_join_multicast(struct rdma_cm_i
struct cma_multicast *mc;
int ret;

+ if (!id->device)
+ return -EINVAL;
+
id_priv = container_of(id, struct rdma_id_private, id);
if (!cma_comp(id_priv, RDMA_CM_ADDR_BOUND) &&
!cma_comp(id_priv, RDMA_CM_ADDR_RESOLVED))



2018-03-23 10:38:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 84/97] RDMA/cma: Use correct size when writing netlink stats

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Parav Pandit <[email protected]>


[ Upstream commit 7baaa49af3716fb31877c61f59b74d029ce15b75 ]

The code was using the src size when formatting the dst. They are almost
certainly the same value but it reads wrong.

Fixes: ce117ffac2e9 ("RDMA/cma: Export AF_IB statistics")
Signed-off-by: Parav Pandit <[email protected]>
Reviewed-by: Daniel Jurgens <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/core/cma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -4007,7 +4007,7 @@ static int cma_get_id_stats(struct sk_bu
RDMA_NL_RDMA_CM_ATTR_SRC_ADDR))
goto out;
if (ibnl_put_attr(skb, nlh,
- rdma_addr_size(cma_src_addr(id_priv)),
+ rdma_addr_size(cma_dst_addr(id_priv)),
cma_dst_addr(id_priv),
RDMA_NL_RDMA_CM_ATTR_DST_ADDR))
goto out;



2018-03-23 10:38:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 89/97] coresight: Fix disabling of CoreSight TPIU

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Robert Walker <[email protected]>


[ Upstream commit 11595db8e17faaa05fadc25746c870e31276962f ]

The CoreSight TPIU should be disabled when tracing to other sinks to allow
them to operate at full bandwidth.

This patch fixes tpiu_disable_hw() to correctly disable the TPIU by
configuring the TPIU to stop on flush, initiating a manual flush, waiting
for the flush to complete and then waits for the TPIU to indicate it has
stopped.

Signed-off-by: Robert Walker <[email protected]>
Tested-by: Mike Leach <[email protected]>
Signed-off-by: Mathieu Poirier <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hwtracing/coresight/coresight-tpiu.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)

--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -45,8 +45,11 @@
#define TPIU_ITATBCTR0 0xef8

/** register definition **/
+/* FFSR - 0x300 */
+#define FFSR_FT_STOPPED BIT(1)
/* FFCR - 0x304 */
#define FFCR_FON_MAN BIT(6)
+#define FFCR_STOP_FI BIT(12)

/**
* @base: memory mapped base address for this component.
@@ -85,10 +88,14 @@ static void tpiu_disable_hw(struct tpiu_
{
CS_UNLOCK(drvdata->base);

- /* Clear formatter controle reg. */
- writel_relaxed(0x0, drvdata->base + TPIU_FFCR);
+ /* Clear formatter and stop on flush */
+ writel_relaxed(FFCR_STOP_FI, drvdata->base + TPIU_FFCR);
/* Generate manual flush */
- writel_relaxed(FFCR_FON_MAN, drvdata->base + TPIU_FFCR);
+ writel_relaxed(FFCR_STOP_FI | FFCR_FON_MAN, drvdata->base + TPIU_FFCR);
+ /* Wait for flush to complete */
+ coresight_timeout(drvdata->base, TPIU_FFCR, FFCR_FON_MAN, 0);
+ /* Wait for formatter to stop */
+ coresight_timeout(drvdata->base, TPIU_FFSR, FFSR_FT_STOPPED, 1);

CS_LOCK(drvdata->base);
}



2018-03-23 10:39:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 96/97] dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Vignesh R <[email protected]>


[ Upstream commit d087f15786021a9605b20f4c678312510be4cac1 ]

Register layout of a typical TPCC_EVT_MUX_M_N register is such that the
lowest numbered event is at the lowest byte address and highest numbered
event at highest byte address. But TPCC_EVT_MUX_60_63 register layout is
different, in that the lowest numbered event is at the highest address
and highest numbered event is at the lowest address. Therefore, modify
ti_am335x_xbar_write() to handle TPCC_EVT_MUX_60_63 register
accordingly.

Signed-off-by: Vignesh R <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/dma/ti-dma-crossbar.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -51,7 +51,15 @@ struct ti_am335x_xbar_map {

static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u8 val)
{
- writeb_relaxed(val, iomem + event);
+ /*
+ * TPCC_EVT_MUX_60_63 register layout is different than the
+ * rest, in the sense, that event 63 is mapped to lowest byte
+ * and event 60 is mapped to highest, handle it separately.
+ */
+ if (event >= 60 && event <= 63)
+ writeb_relaxed(val, iomem + (63 - event % 4));
+ else
+ writeb_relaxed(val, iomem + event);
}

static void ti_am335x_xbar_free(struct device *dev, void *route_data)



2018-03-23 10:39:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 94/97] nfsd4: permit layoutget of executable-only files

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Benjamin Coddington <[email protected]>


[ Upstream commit 66282ec1cf004c09083c29cb5e49019037937bbd ]

Clients must be able to read a file in order to execute it, and for pNFS
that means the client needs to be able to perform a LAYOUTGET on the file.

This behavior for executable-only files was added for OPEN in commit
a043226bc140 "nfsd4: permit read opens of executable-only files".

This fixes up xfstests generic/126 on block/scsi layouts.

Signed-off-by: Benjamin Coddington <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfsd/nfs4proc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -1245,14 +1245,14 @@ nfsd4_layoutget(struct svc_rqst *rqstp,
const struct nfsd4_layout_ops *ops;
struct nfs4_layout_stateid *ls;
__be32 nfserr;
- int accmode;
+ int accmode = NFSD_MAY_READ_IF_EXEC;

switch (lgp->lg_seg.iomode) {
case IOMODE_READ:
- accmode = NFSD_MAY_READ;
+ accmode |= NFSD_MAY_READ;
break;
case IOMODE_RW:
- accmode = NFSD_MAY_READ | NFSD_MAY_WRITE;
+ accmode |= NFSD_MAY_READ | NFSD_MAY_WRITE;
break;
default:
dprintk("%s: invalid iomode %d\n",



2018-03-23 10:40:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 83/97] IB/ipoib: Avoid memory leak if the SA returns a different DGID

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Erez Shitrit <[email protected]>


[ Upstream commit 439000892ee17a9c92f1e4297818790ef8bb4ced ]

The ipoib path database is organized around DGIDs from the LLADDR, but the
SA is free to return a different GID when asked for path. This causes a
bug because the SA's modified DGID is copied into the database key, even
though it is no longer the correct lookup key, causing a memory leak and
other malfunctions.

Ensure the database key does not change after the SA query completes.

Demonstration of the bug is as follows
ipoib wants to send to GID fe80:0000:0000:0000:0002:c903:00ef:5ee2, it
creates new record in the DB with that gid as a key, and issues a new
request to the SM.
Now, the SM from some reason returns path-record with other SGID (for
example, 2001:0000:0000:0000:0002:c903:00ef:5ee2 that contains the local
subnet prefix) now ipoib will overwrite the current entry with the new
one, and if new request to the original GID arrives ipoib will not find
it in the DB (was overwritten) and will create new record that in its
turn will also be overwritten by the response from the SM, and so on
till the driver eats all the device memory.

Signed-off-by: Erez Shitrit <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)

--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -724,6 +724,22 @@ static void path_rec_completion(int stat
spin_lock_irqsave(&priv->lock, flags);

if (!IS_ERR_OR_NULL(ah)) {
+ /*
+ * pathrec.dgid is used as the database key from the LLADDR,
+ * it must remain unchanged even if the SA returns a different
+ * GID to use in the AH.
+ */
+ if (memcmp(pathrec->dgid.raw, path->pathrec.dgid.raw,
+ sizeof(union ib_gid))) {
+ ipoib_dbg(
+ priv,
+ "%s got PathRec for gid %pI6 while asked for %pI6\n",
+ dev->name, pathrec->dgid.raw,
+ path->pathrec.dgid.raw);
+ memcpy(pathrec->dgid.raw, path->pathrec.dgid.raw,
+ sizeof(union ib_gid));
+ }
+
path->pathrec = *pathrec;

old_ah = path->ah;



2018-03-23 10:40:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 73/97] Bluetooth: hci_qca: Avoid setup failure on missing rampatch

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Loic Poulain <[email protected]>


[ Upstream commit ba8f3597900291a93604643017fff66a14546015 ]

Assuming that the original code idea was to enable in-band sleeping
only if the setup_rome method returns succes and run in 'standard'
mode otherwise, we should not return setup_rome return value which
makes qca_setup fail if no rampatch/nvm file found.

This fixes BT issue on the dragonboard-820C p4 which includes the
following QCA controller:
hci0: Product:0x00000008
hci0: Patch :0x00000111
hci0: ROM :0x00000302
hci0: SOC :0x00000044

Since there is no rampatch for this controller revision, just make
it work as is.

Signed-off-by: Loic Poulain <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/bluetooth/hci_qca.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -936,6 +936,9 @@ static int qca_setup(struct hci_uart *hu
if (!ret) {
set_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags);
qca_debugfs_init(hdev);
+ } else if (ret == -ENOENT) {
+ /* No patch/nvm-config found, run with original fw/config */
+ ret = 0;
}

/* Setup bdaddr */



2018-03-23 10:41:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 71/97] rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Moritz Fischer <[email protected]>


[ Upstream commit 538c08f4c89580fc644e2bc64e0a4b86c925da4e ]

The WDIOC_SETOPTIONS case in the watchdog ioctl would alwayss falls
through to the -EINVAL case. This is wrong since thew watchdog does
actually get stopped or started correctly.

Fixes: 920f91e50c5b ("drivers/rtc/rtc-ds1374.c: add watchdog support")
Signed-off-by: Moritz Fischer <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/rtc/rtc-ds1374.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -548,14 +548,15 @@ static long ds1374_wdt_ioctl(struct file
if (options & WDIOS_DISABLECARD) {
pr_info("disable watchdog\n");
ds1374_wdt_disable();
+ return 0;
}

if (options & WDIOS_ENABLECARD) {
pr_info("enable watchdog\n");
ds1374_wdt_settimeout(wdt_margin);
ds1374_wdt_ping();
+ return 0;
}
-
return -EINVAL;
}
return -ENOTTY;



2018-03-23 10:41:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 70/97] rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt ticks

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Moritz Fischer <[email protected]>


[ Upstream commit 453d0744f6c6ca3f9749b8c57c2e85b5b9f52514 ]

The issue is that the internal counter that triggers the watchdog reset
is actually running at 4096 Hz instead of 1Hz, therefore the value
given by userland (in sec) needs to be multiplied by 4096 to get the
correct behavior.

Fixes: 920f91e50c5b ("drivers/rtc/rtc-ds1374.c: add watchdog support")
Signed-off-by: Moritz Fischer <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/rtc/rtc-ds1374.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -527,6 +527,10 @@ static long ds1374_wdt_ioctl(struct file
if (get_user(new_margin, (int __user *)arg))
return -EFAULT;

+ /* the hardware's tick rate is 4096 Hz, so
+ * the counter value needs to be scaled accordingly
+ */
+ new_margin <<= 12;
if (new_margin < 1 || new_margin > 16777216)
return -EINVAL;

@@ -535,7 +539,8 @@ static long ds1374_wdt_ioctl(struct file
ds1374_wdt_ping();
/* fallthrough */
case WDIOC_GETTIMEOUT:
- return put_user(wdt_margin, (int __user *)arg);
+ /* when returning ... inverse is true */
+ return put_user((wdt_margin >> 12), (int __user *)arg);
case WDIOC_SETOPTIONS:
if (copy_from_user(&options, (int __user *)arg, sizeof(int)))
return -EFAULT;



2018-03-23 10:41:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 69/97] cifs: small underflow in cnvrtDosUnixTm()

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>


[ Upstream commit 564277eceeca01e02b1ef3e141cfb939184601b4 ]

January is month 1. There is no zero-th month. If someone passes a
zero month then it means we read from one space before the start of the
total_days_of_prev_months[] array.

We may as well also be strict about days as well.

Fixes: 1bd5bbcb6531 ("[CIFS] Legacy time handling for Win9x and OS/2 part 1")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/cifs/netmisc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/fs/cifs/netmisc.c
+++ b/fs/cifs/netmisc.c
@@ -980,10 +980,10 @@ struct timespec cnvrtDosUnixTm(__le16 le
cifs_dbg(VFS, "illegal hours %d\n", st->Hours);
days = sd->Day;
month = sd->Month;
- if ((days > 31) || (month > 12)) {
+ if (days < 1 || days > 31 || month < 1 || month > 12) {
cifs_dbg(VFS, "illegal date, month %d day: %d\n", month, days);
- if (month > 12)
- month = 12;
+ days = clamp(days, 1, 31);
+ month = clamp(month, 1, 12);
}
month -= 1;
days += total_days_of_prev_months[month];



2018-03-23 10:41:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 92/97] ip6_vti: adjust vti mtu according to mtu of lower device

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Alexey Kodanev <[email protected]>


[ Upstream commit 53c81e95df1793933f87748d36070a721f6cb287 ]

LTP/udp6_ipsec_vti tests fail when sending large UDP datagrams over
ip6_vti that require fragmentation and the underlying device has an
MTU smaller than 1500 plus some extra space for headers. This happens
because ip6_vti, by default, sets MTU to ETH_DATA_LEN and not updating
it depending on a destination address or link parameter. Further
attempts to send UDP packets may succeed because pmtu gets updated on
ICMPV6_PKT_TOOBIG in vti6_err().

In case the lower device has larger MTU size, e.g. 9000, ip6_vti works
but not using the possible maximum size, output packets have 1500 limit.

The above cases require manual MTU setup after ip6_vti creation. However
ip_vti already updates MTU based on lower device with ip_tunnel_bind_dev().

Here is the example when the lower device MTU is set to 9000:

# ip a sh ltp_ns_veth2
ltp_ns_veth2@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 ...
inet 10.0.0.2/24 scope global ltp_ns_veth2
inet6 fd00::2/64 scope global

# ip li add vti6 type vti6 local fd00::2 remote fd00::1
# ip li show vti6
vti6@NONE: <POINTOPOINT,NOARP> mtu 1500 ...
link/tunnel6 fd00::2 peer fd00::1

After the patch:
# ip li add vti6 type vti6 local fd00::2 remote fd00::1
# ip li show vti6
vti6@NONE: <POINTOPOINT,NOARP> mtu 8832 ...
link/tunnel6 fd00::2 peer fd00::1

Reported-by: Petr Vorel <[email protected]>
Signed-off-by: Alexey Kodanev <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/ip6_vti.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)

--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -614,6 +614,7 @@ static void vti6_link_config(struct ip6_
{
struct net_device *dev = t->dev;
struct __ip6_tnl_parm *p = &t->parms;
+ struct net_device *tdev = NULL;

memcpy(dev->dev_addr, &p->laddr, sizeof(struct in6_addr));
memcpy(dev->broadcast, &p->raddr, sizeof(struct in6_addr));
@@ -626,6 +627,25 @@ static void vti6_link_config(struct ip6_
dev->flags |= IFF_POINTOPOINT;
else
dev->flags &= ~IFF_POINTOPOINT;
+
+ if (p->flags & IP6_TNL_F_CAP_XMIT) {
+ int strict = (ipv6_addr_type(&p->raddr) &
+ (IPV6_ADDR_MULTICAST | IPV6_ADDR_LINKLOCAL));
+ struct rt6_info *rt = rt6_lookup(t->net,
+ &p->raddr, &p->laddr,
+ p->link, strict);
+
+ if (rt)
+ tdev = rt->dst.dev;
+ ip6_rt_put(rt);
+ }
+
+ if (!tdev && p->link)
+ tdev = __dev_get_by_index(t->net, p->link);
+
+ if (tdev)
+ dev->mtu = max_t(int, tdev->mtu - dev->hard_header_len,
+ IPV6_MIN_MTU);
}

/**



2018-03-23 10:41:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 66/97] video: fbdev: udlfb: Fix buffer on stack

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Maksim Salau <[email protected]>


[ Upstream commit 45f580c42e5c125d55dbd8099750a1998de3d917 ]

Allocate buffers on HEAP instead of STACK for local array
that is to be sent using usb_control_msg().

Signed-off-by: Maksim Salau <[email protected]>
Cc: Bernie Thompson <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/video/fbdev/udlfb.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)

--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1487,15 +1487,25 @@ static struct device_attribute fb_device
static int dlfb_select_std_channel(struct dlfb_data *dev)
{
int ret;
- u8 set_def_chn[] = { 0x57, 0xCD, 0xDC, 0xA7,
+ void *buf;
+ static const u8 set_def_chn[] = {
+ 0x57, 0xCD, 0xDC, 0xA7,
0x1C, 0x88, 0x5E, 0x15,
0x60, 0xFE, 0xC6, 0x97,
0x16, 0x3D, 0x47, 0xF2 };

+ buf = kmemdup(set_def_chn, sizeof(set_def_chn), GFP_KERNEL);
+
+ if (!buf)
+ return -ENOMEM;
+
ret = usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev, 0),
NR_USB_REQUEST_CHANNEL,
(USB_DIR_OUT | USB_TYPE_VENDOR), 0, 0,
- set_def_chn, sizeof(set_def_chn), USB_CTRL_SET_TIMEOUT);
+ buf, sizeof(set_def_chn), USB_CTRL_SET_TIMEOUT);
+
+ kfree(buf);
+
return ret;
}




2018-03-23 10:41:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 67/97] sm501fb: dont return zero on failure path in sm501fb_start()

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Alexey Khoroshilov <[email protected]>


[ Upstream commit dc85e9a87420613b3129d5cc5ecd79c58351c546 ]

If fbmem iomemory mapping failed, sm501fb_start() breaks off
initialization, deallocates resources, but returns zero.
As a result, double deallocation can happen in sm501fb_stop().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/video/fbdev/sm501fb.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -1600,6 +1600,7 @@ static int sm501fb_start(struct sm501fb_
info->fbmem = ioremap(res->start, resource_size(res));
if (info->fbmem == NULL) {
dev_err(dev, "cannot remap framebuffer\n");
+ ret = -ENXIO;
goto err_mem_res;
}




2018-03-23 10:41:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 80/97] cros_ec: fix nul-termination for firmware build info

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Arnd Bergmann <[email protected]>


[ Upstream commit 50a0d71a5d20e1d3eff1d974fdc8559ad6d74892 ]

As gcc-8 reports, we zero out the wrong byte:

drivers/platform/chrome/cros_ec_sysfs.c: In function 'show_ec_version':
drivers/platform/chrome/cros_ec_sysfs.c:190:12: error: array subscript 4294967295 is above array bounds of 'uint8_t[]' [-Werror=array-bounds]

This changes the code back to what it did before changing to a
zero-length array structure.

Fixes: a841178445bb ("mfd: cros_ec: Use a zero-length array for command data")
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Benson Leung <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/platform/chrome/cros_ec_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/platform/chrome/cros_ec_sysfs.c
+++ b/drivers/platform/chrome/cros_ec_sysfs.c
@@ -187,7 +187,7 @@ static ssize_t show_ec_version(struct de
count += scnprintf(buf + count, PAGE_SIZE - count,
"Build info: EC error %d\n", msg->result);
else {
- msg->data[sizeof(msg->data) - 1] = '\0';
+ msg->data[EC_HOST_PARAM_SIZE - 1] = '\0';
count += scnprintf(buf + count, PAGE_SIZE - count,
"Build info: %s\n", msg->data);
}



2018-03-23 10:42:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 81/97] platform/chrome: Use proper protocol transfer function

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Shawn Nematbakhsh <[email protected]>


[ Upstream commit d48b8c58c57f6edbe2965f0a5f62c5cf9593ca96 ]

pkt_xfer should be used for protocol v3, and cmd_xfer otherwise. We had
one instance of these functions correct, but not the second, fall-back
case. We use the fall-back only when the first command returns an
IN_PROGRESS status, which is only used on some EC firmwares where we
don't want to constantly poll the bus, but instead back off and
sleep/retry for a little while.

Fixes: 2c7589af3c4d ("mfd: cros_ec: add proto v3 skeleton")
Signed-off-by: Shawn Nematbakhsh <[email protected]>
Signed-off-by: Brian Norris <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Benson Leung <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/platform/chrome/cros_ec_proto.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -59,12 +59,14 @@ static int send_command(struct cros_ec_d
struct cros_ec_command *msg)
{
int ret;
+ int (*xfer_fxn)(struct cros_ec_device *ec, struct cros_ec_command *msg);

if (ec_dev->proto_version > 2)
- ret = ec_dev->pkt_xfer(ec_dev, msg);
+ xfer_fxn = ec_dev->pkt_xfer;
else
- ret = ec_dev->cmd_xfer(ec_dev, msg);
+ xfer_fxn = ec_dev->cmd_xfer;

+ ret = (*xfer_fxn)(ec_dev, msg);
if (msg->result == EC_RES_IN_PROGRESS) {
int i;
struct cros_ec_command *status_msg;
@@ -87,7 +89,7 @@ static int send_command(struct cros_ec_d
for (i = 0; i < EC_COMMAND_RETRIES; i++) {
usleep_range(10000, 11000);

- ret = ec_dev->cmd_xfer(ec_dev, status_msg);
+ ret = (*xfer_fxn)(ec_dev, status_msg);
if (ret < 0)
break;




2018-03-23 10:42:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 78/97] media: bt8xx: Fix err bt878_probe()

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Christophe JAILLET <[email protected]>


[ Upstream commit 45392ff6881dbe56d41ef0b17c2e576065f8ffa1 ]

This is odd to call 'pci_disable_device()' in an error path before a
coresponding successful 'pci_enable_device()'.

Return directly instead.

Fixes: 77e0be12100a ("V4L/DVB (4176): Bug-fix: Fix memory overflow")

Signed-off-by: Christophe JAILLET <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/pci/bt8xx/bt878.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/media/pci/bt8xx/bt878.c
+++ b/drivers/media/pci/bt8xx/bt878.c
@@ -422,8 +422,7 @@ static int bt878_probe(struct pci_dev *d
bt878_num);
if (bt878_num >= BT878_MAX) {
printk(KERN_ERR "bt878: Too many devices inserted\n");
- result = -ENOMEM;
- goto fail0;
+ return -ENOMEM;
}
if (pci_enable_device(dev))
return -EIO;



2018-03-23 10:43:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 77/97] rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled.

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Tsang-Shian Lin <[email protected]>


[ Upstream commit b7573a0a27bfa8270dea9b145448f6884b7cacc1 ]

Reset the driver current tx read/write index to zero when inactiveps
nic out of sync with HW state. Wrong driver tx read/write index will
cause Tx fail.

Signed-off-by: Tsang-Shian Lin <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Larry Finger <[email protected]>
Cc: Yan-Hsuan Chuang <[email protected]>
Cc: Birming Chiu <[email protected]>
Cc: Shaofu <[email protected]>
Cc: Steven Ting <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 7 +++++++
1 file changed, 7 insertions(+)

--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -1572,7 +1572,14 @@ int rtl_pci_reset_trx_ring(struct ieee80
dev_kfree_skb_irq(skb);
ring->idx = (ring->idx + 1) % ring->entries;
}
+
+ if (rtlpriv->use_new_trx_flow) {
+ rtlpci->tx_ring[i].cur_tx_rp = 0;
+ rtlpci->tx_ring[i].cur_tx_wp = 0;
+ }
+
ring->idx = 0;
+ ring->entries = rtlpci->txringcount[i];
}
}
spin_unlock_irqrestore(&rtlpriv->locks.irq_th_lock, flags);



2018-03-23 10:43:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 75/97] drm/msm: fix leak in failed get_pages

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Prakash Kamliya <[email protected]>


[ Upstream commit 62e3a3e342af3c313ab38603811ecdb1fcc79edb ]

get_pages doesn't keep a reference of the pages allocated
when it fails later in the code path. This can lead to
a memory leak. Keep reference of the allocated pages so
that it can be freed when msm_gem_free_object gets called
later during cleanup.

Signed-off-by: Prakash Kamliya <[email protected]>
Signed-off-by: Sharat Masetty <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/msm/msm_gem.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -89,14 +89,17 @@ static struct page **get_pages(struct dr
return p;
}

+ msm_obj->pages = p;
+
msm_obj->sgt = drm_prime_pages_to_sg(p, npages);
if (IS_ERR(msm_obj->sgt)) {
+ void *ptr = ERR_CAST(msm_obj->sgt);
+
dev_err(dev->dev, "failed to allocate sgt\n");
- return ERR_CAST(msm_obj->sgt);
+ msm_obj->sgt = NULL;
+ return ptr;
}

- msm_obj->pages = p;
-
/* For non-cached buffers, ensure the new pages are clean
* because display controller, GPU, etc. are not coherent:
*/
@@ -119,7 +122,10 @@ static void put_pages(struct drm_gem_obj
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
- sg_free_table(msm_obj->sgt);
+
+ if (msm_obj->sgt)
+ sg_free_table(msm_obj->sgt);
+
kfree(msm_obj->sgt);

if (use_pages(obj))



2018-03-23 10:43:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 79/97] media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Ron Economos <[email protected]>


[ Upstream commit 380a6c86457573aa42d27ae11e025eb25941a0b7 ]

On faster CPUs a delay is required after the resume command and the restart command. Without the delay, the restart command often returns -EREMOTEIO and the Si2168 does not restart.

Note that this patch fixes the same issue as https://patchwork.linuxtv.org/patch/44304/, but I believe my udelay() fix addresses the actual problem.

Signed-off-by: Ron Economos <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/dvb-frontends/si2168.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -14,6 +14,8 @@
* GNU General Public License for more details.
*/

+#include <linux/delay.h>
+
#include "si2168_priv.h"

static const struct dvb_frontend_ops si2168_ops;
@@ -420,6 +422,7 @@ static int si2168_init(struct dvb_fronte
if (ret)
goto err;

+ udelay(100);
memcpy(cmd.args, "\x85", 1);
cmd.wlen = 1;
cmd.rlen = 1;



2018-03-23 10:44:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 49/97] Btrfs: send, fix file hole not being preserved due to inline extent

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Filipe Manana <[email protected]>


[ Upstream commit e1cbfd7bf6dabdac561c75d08357571f44040a45 ]

Normally we don't have inline extents followed by regular extents, but
there's currently at least one harmless case where this happens. For
example, when the page size is 4Kb and compression is enabled:

$ mkfs.btrfs -f /dev/sdb
$ mount -o compress /dev/sdb /mnt
$ xfs_io -f -c "pwrite -S 0xaa 0 4K" -c "fsync" /mnt/foobar
$ xfs_io -c "pwrite -S 0xbb 8K 4K" -c "fsync" /mnt/foobar

In this case we get a compressed inline extent, representing 4Kb of
data, followed by a hole extent and then a regular data extent. The
inline extent was not expanded/converted to a regular extent exactly
because it represents 4Kb of data. This does not cause any apparent
problem (such as the issue solved by commit e1699d2d7bf6
("btrfs: add missing memset while reading compressed inline extents"))
except trigger an unexpected case in the incremental send code path
that makes us issue an operation to write a hole when it's not needed,
resulting in more writes at the receiver and wasting space at the
receiver.

So teach the incremental send code to deal with this particular case.

The issue can be currently triggered by running fstests btrfs/137 with
compression enabled (MOUNT_OPTIONS="-o compress" ./check btrfs/137).

Signed-off-by: Filipe Manana <[email protected]>
Reviewed-by: Liu Bo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/send.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)

--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -5008,13 +5008,19 @@ static int is_extent_unchanged(struct se
while (key.offset < ekey->offset + left_len) {
ei = btrfs_item_ptr(eb, slot, struct btrfs_file_extent_item);
right_type = btrfs_file_extent_type(eb, ei);
- if (right_type != BTRFS_FILE_EXTENT_REG) {
+ if (right_type != BTRFS_FILE_EXTENT_REG &&
+ right_type != BTRFS_FILE_EXTENT_INLINE) {
ret = 0;
goto out;
}

right_disknr = btrfs_file_extent_disk_bytenr(eb, ei);
- right_len = btrfs_file_extent_num_bytes(eb, ei);
+ if (right_type == BTRFS_FILE_EXTENT_INLINE) {
+ right_len = btrfs_file_extent_inline_len(eb, slot, ei);
+ right_len = PAGE_ALIGN(right_len);
+ } else {
+ right_len = btrfs_file_extent_num_bytes(eb, ei);
+ }
right_offset = btrfs_file_extent_offset(eb, ei);
right_gen = btrfs_file_extent_generation(eb, ei);

@@ -5028,6 +5034,19 @@ static int is_extent_unchanged(struct se
goto out;
}

+ /*
+ * We just wanted to see if when we have an inline extent, what
+ * follows it is a regular extent (wanted to check the above
+ * condition for inline extents too). This should normally not
+ * happen but it's possible for example when we have an inline
+ * compressed extent representing data with a size matching
+ * the page size (currently the same as sector size).
+ */
+ if (right_type == BTRFS_FILE_EXTENT_INLINE) {
+ ret = 0;
+ goto out;
+ }
+
left_offset_fixed = left_offset;
if (key.offset < ekey->offset) {
/* Fix the right offset for 2a and 7. */



2018-03-23 10:44:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 58/97] ACPI / PMIC: xpower: Fix power_table addresses

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Hans de Goede <[email protected]>


[ Upstream commit 2bde7c32b1db162692f05c6be066b5bcd3d9fdbe ]

The power table addresses should be contiguous, but there was a hole
where 0x34 was missing. On most devices this is not a problem as
addresses above 0x34 are used for the BUC# convertors which are not
used in the DSDTs I've access to but after the BUC# convertors
there is a field named GPI1 in the DSTDs, which does get used in some
cases and ended up turning BUC6 on and off due to the wrong addresses,
resulting in turning the entire device off (or causing it to reboot).

Removing the hole in the addresses fixes this, fixing one of my
Bay Trail tablets turning off while booting the mainline kernel.

While at it add comments with the field names used in the DSDTs to
make it easier to compare the register and bits used at each address
with the datasheet.

Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/acpi/pmic/intel_pmic_xpower.c | 50 +++++++++++++++++-----------------
1 file changed, 25 insertions(+), 25 deletions(-)

--- a/drivers/acpi/pmic/intel_pmic_xpower.c
+++ b/drivers/acpi/pmic/intel_pmic_xpower.c
@@ -28,97 +28,97 @@ static struct pmic_table power_table[] =
.address = 0x00,
.reg = 0x13,
.bit = 0x05,
- },
+ }, /* ALD1 */
{
.address = 0x04,
.reg = 0x13,
.bit = 0x06,
- },
+ }, /* ALD2 */
{
.address = 0x08,
.reg = 0x13,
.bit = 0x07,
- },
+ }, /* ALD3 */
{
.address = 0x0c,
.reg = 0x12,
.bit = 0x03,
- },
+ }, /* DLD1 */
{
.address = 0x10,
.reg = 0x12,
.bit = 0x04,
- },
+ }, /* DLD2 */
{
.address = 0x14,
.reg = 0x12,
.bit = 0x05,
- },
+ }, /* DLD3 */
{
.address = 0x18,
.reg = 0x12,
.bit = 0x06,
- },
+ }, /* DLD4 */
{
.address = 0x1c,
.reg = 0x12,
.bit = 0x00,
- },
+ }, /* ELD1 */
{
.address = 0x20,
.reg = 0x12,
.bit = 0x01,
- },
+ }, /* ELD2 */
{
.address = 0x24,
.reg = 0x12,
.bit = 0x02,
- },
+ }, /* ELD3 */
{
.address = 0x28,
.reg = 0x13,
.bit = 0x02,
- },
+ }, /* FLD1 */
{
.address = 0x2c,
.reg = 0x13,
.bit = 0x03,
- },
+ }, /* FLD2 */
{
.address = 0x30,
.reg = 0x13,
.bit = 0x04,
- },
+ }, /* FLD3 */
{
- .address = 0x38,
+ .address = 0x34,
.reg = 0x10,
.bit = 0x03,
- },
+ }, /* BUC1 */
{
- .address = 0x3c,
+ .address = 0x38,
.reg = 0x10,
.bit = 0x06,
- },
+ }, /* BUC2 */
{
- .address = 0x40,
+ .address = 0x3c,
.reg = 0x10,
.bit = 0x05,
- },
+ }, /* BUC3 */
{
- .address = 0x44,
+ .address = 0x40,
.reg = 0x10,
.bit = 0x04,
- },
+ }, /* BUC4 */
{
- .address = 0x48,
+ .address = 0x44,
.reg = 0x10,
.bit = 0x01,
- },
+ }, /* BUC5 */
{
- .address = 0x4c,
+ .address = 0x48,
.reg = 0x10,
.bit = 0x00
- },
+ }, /* BUC6 */
};

/* TMP0 - TMP5 are the same, all from GPADC */



2018-03-23 10:45:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 56/97] ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Kishon Vijay Abraham I <[email protected]>


[ Upstream commit 2c949ce38f4e81d7487f165fa3b8f77d74a2a6c4 ]

The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should be
set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO in RC
mode. However in EP mode, the host system is not able to access the
MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it.

Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Kishon Vijay Abraham I <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm/mach-omap2/clockdomains7xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
@@ -524,7 +524,7 @@ static struct clockdomain pcie_7xx_clkdm
.dep_bit = DRA7XX_PCIE_STATDEP_SHIFT,
.wkdep_srcs = pcie_wkup_sleep_deps,
.sleepdep_srcs = pcie_wkup_sleep_deps,
- .flags = CLKDM_CAN_HWSUP_SWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};

static struct clockdomain atl_7xx_clkdm = {



2018-03-23 10:45:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 52/97] mtip32xx: use runtime tag to initialize command header

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Ming Lei <[email protected]>


[ Upstream commit a4e84aae8139aca9fbfbced1f45c51ca81b57488 ]

mtip32xx supposes that 'request_idx' passed to .init_request()
is tag of the request, and use that as request's tag to initialize
command header.

After MQ IO scheduler is in, request tag assigned isn't same with
the request index anymore, so cause strange hardware failure on
mtip32xx, even whole system panic is triggered.

This patch fixes the issue by initializing command header via
request's real tag.

Signed-off-by: Ming Lei <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/block/mtip32xx/mtip32xx.c | 36 ++++++++++++++++++++++++------------
1 file changed, 24 insertions(+), 12 deletions(-)

--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -169,6 +169,25 @@ static bool mtip_check_surprise_removal(
return false; /* device present */
}

+/* we have to use runtime tag to setup command header */
+static void mtip_init_cmd_header(struct request *rq)
+{
+ struct driver_data *dd = rq->q->queuedata;
+ struct mtip_cmd *cmd = blk_mq_rq_to_pdu(rq);
+ u32 host_cap_64 = readl(dd->mmio + HOST_CAP) & HOST_CAP_64;
+
+ /* Point the command headers at the command tables. */
+ cmd->command_header = dd->port->command_list +
+ (sizeof(struct mtip_cmd_hdr) * rq->tag);
+ cmd->command_header_dma = dd->port->command_list_dma +
+ (sizeof(struct mtip_cmd_hdr) * rq->tag);
+
+ if (host_cap_64)
+ cmd->command_header->ctbau = __force_bit2int cpu_to_le32((cmd->command_dma >> 16) >> 16);
+
+ cmd->command_header->ctba = __force_bit2int cpu_to_le32(cmd->command_dma & 0xFFFFFFFF);
+}
+
static struct mtip_cmd *mtip_get_int_command(struct driver_data *dd)
{
struct request *rq;
@@ -180,6 +199,9 @@ static struct mtip_cmd *mtip_get_int_com
if (IS_ERR(rq))
return NULL;

+ /* Internal cmd isn't submitted via .queue_rq */
+ mtip_init_cmd_header(rq);
+
return blk_mq_rq_to_pdu(rq);
}

@@ -3818,6 +3840,8 @@ static int mtip_queue_rq(struct blk_mq_h
struct request *rq = bd->rq;
int ret;

+ mtip_init_cmd_header(rq);
+
if (unlikely(mtip_check_unal_depth(hctx, rq)))
return BLK_MQ_RQ_QUEUE_BUSY;

@@ -3849,7 +3873,6 @@ static int mtip_init_cmd(void *data, str
{
struct driver_data *dd = data;
struct mtip_cmd *cmd = blk_mq_rq_to_pdu(rq);
- u32 host_cap_64 = readl(dd->mmio + HOST_CAP) & HOST_CAP_64;

/*
* For flush requests, request_idx starts at the end of the
@@ -3866,17 +3889,6 @@ static int mtip_init_cmd(void *data, str

memset(cmd->command, 0, CMD_DMA_ALLOC_SZ);

- /* Point the command headers at the command tables. */
- cmd->command_header = dd->port->command_list +
- (sizeof(struct mtip_cmd_hdr) * request_idx);
- cmd->command_header_dma = dd->port->command_list_dma +
- (sizeof(struct mtip_cmd_hdr) * request_idx);
-
- if (host_cap_64)
- cmd->command_header->ctbau = __force_bit2int cpu_to_le32((cmd->command_dma >> 16) >> 16);
-
- cmd->command_header->ctba = __force_bit2int cpu_to_le32(cmd->command_dma & 0xFFFFFFFF);
-
sg_init_table(cmd->sg, MTIP_MAX_SG);
return 0;
}



2018-03-23 10:45:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 54/97] staging: wilc1000: fix unchecked return value

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Pan Bian <[email protected]>


[ Upstream commit 9e96652756ad647b7bcc03cb99ffc9756d7b5f93 ]

Function dev_alloc_skb() will return a NULL pointer if there is no
enough memory. However, in function WILC_WFI_mon_xmit(), its return
value is used without validation. This may result in a bad memory access
bug. This patch fixes the bug.

Signed-off-by: Pan Bian <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/wilc1000/linux_mon.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/staging/wilc1000/linux_mon.c
+++ b/drivers/staging/wilc1000/linux_mon.c
@@ -251,6 +251,8 @@ static netdev_tx_t WILC_WFI_mon_xmit(str

if (skb->data[0] == 0xc0 && (!(memcmp(broadcast, &skb->data[4], 6)))) {
skb2 = dev_alloc_skb(skb->len + sizeof(struct wilc_wfi_radiotap_cb_hdr));
+ if (!skb2)
+ return -ENOMEM;

memcpy(skb_put(skb2, skb->len), skb->data, skb->len);




2018-03-23 10:45:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 65/97] tcm_fileio: Prevent information leak for short reads

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Dmitry Monakhov <[email protected]>


[ Upstream commit f11b55d13563e9428c88c873f4f03a6bef11ec0a ]

If we failed to read data from backing file (probably because some one
truncate file under us), we must zerofill cmd's data, otherwise it will
be returned as is. Most likely cmd's data are unitialized pages from
page cache. This result in information leak.

(Change BUG_ON into -EINVAL se_cmd failure - nab)

testcase: https://github.com/dmonakhov/xfstests/commit/e11a1b7b907ca67b1be51a1594025600767366d5
Signed-off-by: Dmitry Monakhov <[email protected]>
Signed-off-by: Nicholas Bellinger <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/target/target_core_file.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)

--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -276,12 +276,11 @@ static int fd_do_rw(struct se_cmd *cmd,
else
ret = vfs_iter_read(fd, &iter, &pos);

- kfree(bvec);
-
if (is_write) {
if (ret < 0 || ret != data_length) {
pr_err("%s() write returned %d\n", __func__, ret);
- return (ret < 0 ? ret : -EINVAL);
+ if (ret >= 0)
+ ret = -EINVAL;
}
} else {
/*
@@ -294,17 +293,29 @@ static int fd_do_rw(struct se_cmd *cmd,
pr_err("%s() returned %d, expecting %u for "
"S_ISBLK\n", __func__, ret,
data_length);
- return (ret < 0 ? ret : -EINVAL);
+ if (ret >= 0)
+ ret = -EINVAL;
}
} else {
if (ret < 0) {
pr_err("%s() returned %d for non S_ISBLK\n",
__func__, ret);
- return ret;
+ } else if (ret != data_length) {
+ /*
+ * Short read case:
+ * Probably some one truncate file under us.
+ * We must explicitly zero sg-pages to prevent
+ * expose uninizialized pages to userspace.
+ */
+ if (ret < data_length)
+ ret += iov_iter_zero(data_length - ret, &iter);
+ else
+ ret = -EINVAL;
}
}
}
- return 1;
+ kfree(bvec);
+ return ret;
}

static sense_reason_t



2018-03-23 10:45:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 53/97] staging: unisys: visorhba: fix s-Par to boot with option CONFIG_VMAP_STACK set to y

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Sameer Wadgaonkar <[email protected]>


[ Upstream commit 3c2bf0bd08123f3497bd3e84bd9088c937b0cb40 ]

The root issue is that we are not allowed to have items on the
stack being passed to "DMA" like operations. In this case we have
a vmcall and an inline completion of scsi command.

This patch fixes the issue by moving the variables on stack in
do_scsi_nolinuxstat() to heap memory.

Signed-off-by: Sameer Wadgaonkar <[email protected]>
Signed-off-by: David Kershner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/unisys/visorhba/visorhba_main.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -792,7 +792,7 @@ static void
do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct scsi_cmnd *scsicmd)
{
struct scsi_device *scsidev;
- unsigned char buf[36];
+ unsigned char *buf;
struct scatterlist *sg;
unsigned int i;
char *this_page;
@@ -807,6 +807,10 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cm
if (cmdrsp->scsi.no_disk_result == 0)
return;

+ buf = kzalloc(sizeof(char) * 36, GFP_KERNEL);
+ if (!buf)
+ return;
+
/* Linux scsi code wants a device at Lun 0
* to issue report luns, but we don't want
* a disk there so we'll present a processor
@@ -820,6 +824,7 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cm
if (scsi_sg_count(scsicmd) == 0) {
memcpy(scsi_sglist(scsicmd), buf,
cmdrsp->scsi.bufflen);
+ kfree(buf);
return;
}

@@ -831,6 +836,7 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cm
memcpy(this_page, buf + bufind, sg[i].length);
kunmap_atomic(this_page_orig);
}
+ kfree(buf);
} else {
devdata = (struct visorhba_devdata *)scsidev->host->hostdata;
for_each_vdisk_match(vdisk, devdata, scsidev) {



2018-03-23 10:46:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 63/97] md/raid10: skip spare disk as first disk

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Shaohua Li <[email protected]>


[ Upstream commit b506335e5d2b4ec687dde392a3bdbf7601778f1d ]

Commit 6f287ca(md/raid10: reset the 'first' at the end of loop) ignores
a case in reshape, the first rdev could be a spare disk, which shouldn't
be accounted as the first disk since it doesn't include the offset info.

Fix: 6f287ca(md/raid10: reset the 'first' at the end of loop)
Cc: Guoqing Jiang <[email protected]>
Cc: NeilBrown <[email protected]>
Signed-off-by: Shaohua Li <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/raid10.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -4044,6 +4044,7 @@ static int raid10_start_reshape(struct m
diff = 0;
if (first || diff < min_offset_diff)
min_offset_diff = diff;
+ first = 0;
}
}




2018-03-23 10:46:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 51/97] mfd: palmas: Reset the POWERHOLD mux during power off

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Keerthy <[email protected]>


[ Upstream commit 85fdaf8eb9bbec1f0f8a52fd5d85659d60738816 ]

POWERHOLD signal has higher priority over the DEV_ON bit.
So power off will not happen if the POWERHOLD is held high.
Hence reset the MUX to GPIO_7 mode to release the POWERHOLD
and the DEV_ON bit to take effect to power off the PMIC.

PMIC Power off happens in dire situations like thermal shutdown
so irrespective of the POWERHOLD setting go ahead and turn off
the powerhold. Currently poweroff is broken on boards that have
powerhold enabled. This fixes poweroff on those boards.

Signed-off-by: Keerthy <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mfd/palmas.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)

--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -430,6 +430,20 @@ static void palmas_power_off(void)
{
unsigned int addr;
int ret, slave;
+ struct device_node *np = palmas_dev->dev->of_node;
+
+ if (of_property_read_bool(np, "ti,palmas-override-powerhold")) {
+ addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
+ PALMAS_PRIMARY_SECONDARY_PAD2);
+ slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
+
+ ret = regmap_update_bits(palmas_dev->regmap[slave], addr,
+ PALMAS_PRIMARY_SECONDARY_PAD2_GPIO_7_MASK, 0);
+ if (ret)
+ dev_err(palmas_dev->dev,
+ "Unable to write PRIMARY_SECONDARY_PAD2 %d\n",
+ ret);
+ }

if (!palmas_dev)
return;



2018-03-23 10:46:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 60/97] bnx2x: Align RX buffers

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Scott Wood <[email protected]>


[ Upstream commit 9b70de6d0266888b3743f03802502e43131043c8 ]

The bnx2x driver is not providing proper alignment on the receive buffers it
passes to build_skb(), causing skb_shared_info to be misaligned.
skb_shared_info contains an atomic, and while PPC normally supports
unaligned accesses, it does not support unaligned atomics.

Aligning the size of rx buffers will ensure that page_frag_alloc() returns
aligned addresses.

This can be reproduced on PPC by setting the network MTU to 1450 (or other
non-multiple-of-4) and then generating sufficient inbound network traffic
(one or two large "wget"s usually does it), producing the following oops:

Unable to handle kernel paging request for unaligned access at address 0xc00000ffc43af656
Faulting instruction address: 0xc00000000080ef8c
Oops: Kernel access of bad area, sig: 7 [#1]
SMP NR_CPUS=2048
NUMA
PowerNV
Modules linked in: vmx_crypto powernv_rng rng_core powernv_op_panel leds_powernv led_class nfsd ip_tables x_tables autofs4 xfs lpfc bnx2x mdio libcrc32c crc_t10dif crct10dif_generic crct10dif_common
CPU: 104 PID: 0 Comm: swapper/104 Not tainted 4.11.0-rc8-00088-g4c761da #2
task: c00000ffd4892400 task.stack: c00000ffd4920000
NIP: c00000000080ef8c LR: c00000000080eee8 CTR: c0000000001f8320
REGS: c00000ffffc33710 TRAP: 0600 Not tainted (4.11.0-rc8-00088-g4c761da)
MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>
CR: 24082042 XER: 00000000
CFAR: c00000000080eea0 DAR: c00000ffc43af656 DSISR: 00000000 SOFTE: 1
GPR00: c000000000907f64 c00000ffffc33990 c000000000dd3b00 c00000ffcaf22100
GPR04: c00000ffcaf22e00 0000000000000000 0000000000000000 0000000000000000
GPR08: 0000000000b80008 c00000ffc43af636 c00000ffc43af656 0000000000000000
GPR12: c0000000001f6f00 c00000000fe1a000 000000000000049f 000000000000c51f
GPR16: 00000000ffffef33 0000000000000000 0000000000008a43 0000000000000001
GPR20: c00000ffc58a90c0 0000000000000000 000000000000dd86 0000000000000000
GPR24: c000007fd0ed10c0 00000000ffffffff 0000000000000158 000000000000014a
GPR28: c00000ffc43af010 c00000ffc9144000 c00000ffcaf22e00 c00000ffcaf22100
NIP [c00000000080ef8c] __skb_clone+0xdc/0x140
LR [c00000000080eee8] __skb_clone+0x38/0x140
Call Trace:
[c00000ffffc33990] [c00000000080fb74] skb_clone+0x74/0x110 (unreliable)
[c00000ffffc339c0] [c000000000907f64] packet_rcv+0x144/0x510
[c00000ffffc33a40] [c000000000827b64] __netif_receive_skb_core+0x5b4/0xd80
[c00000ffffc33b00] [c00000000082b2bc] netif_receive_skb_internal+0x2c/0xc0
[c00000ffffc33b40] [c00000000082c49c] napi_gro_receive+0x11c/0x260
[c00000ffffc33b80] [d000000066483d68] bnx2x_poll+0xcf8/0x17b0 [bnx2x]
[c00000ffffc33d00] [c00000000082babc] net_rx_action+0x31c/0x480
[c00000ffffc33e10] [c0000000000d5a44] __do_softirq+0x164/0x3d0
[c00000ffffc33f00] [c0000000000d60a8] irq_exit+0x108/0x120
[c00000ffffc33f20] [c000000000015b98] __do_irq+0x98/0x200
[c00000ffffc33f90] [c000000000027f14] call_do_irq+0x14/0x24
[c00000ffd4923a90] [c000000000015d94] do_IRQ+0x94/0x110
[c00000ffd4923ae0] [c000000000008d90] hardware_interrupt_common+0x150/0x160

Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -2044,6 +2044,7 @@ static void bnx2x_set_rx_buf_size(struct
ETH_OVREHEAD +
mtu +
BNX2X_FW_RX_ALIGN_END;
+ fp->rx_buf_size = SKB_DATA_ALIGN(fp->rx_buf_size);
/* Note : rx_buf_size doesn't take into account NET_SKB_PAD */
if (fp->rx_buf_size + NET_SKB_PAD <= PAGE_SIZE)
fp->rx_frag_size = fp->rx_buf_size + NET_SKB_PAD;



2018-03-23 10:46:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 62/97] Input: twl4030-pwrbutton - use correct device for irq request

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Sebastian Reichel <[email protected]>


[ Upstream commit 3071e9dd6cd3f2290d770117330f2c8b2e9a97e4 ]

The interrupt should be requested for the platform device
and not for the input device.

Fixes: 7f9ce649d267 ("Input: twl4030-pwrbutton - simplify driver using devm_*")
Signed-off-by: Sebastian Reichel <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/input/misc/twl4030-pwrbutton.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/input/misc/twl4030-pwrbutton.c
+++ b/drivers/input/misc/twl4030-pwrbutton.c
@@ -70,7 +70,7 @@ static int twl4030_pwrbutton_probe(struc
pwr->phys = "twl4030_pwrbutton/input0";
pwr->dev.parent = &pdev->dev;

- err = devm_request_threaded_irq(&pwr->dev, irq, NULL, powerbutton_irq,
+ err = devm_request_threaded_irq(&pdev->dev, irq, NULL, powerbutton_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING |
IRQF_ONESHOT,
"twl4030_pwrbutton", pwr);



2018-03-23 10:47:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 32/97] IB/ipoib: Update broadcast object if PKey value was changed in index 0

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Feras Daoud <[email protected]>


[ Upstream commit 9a9b8112699d78e7f317019b37f377e90023f3ed ]

Update the broadcast address in the priv->broadcast object when the
Pkey value changes in index 0, otherwise the multicast GID value will
keep the previous value of the PKey, and will not be updated.
This leads to interface state down because the interface will keep the
old PKey value.

For example, in SR-IOV environment, if the PF changes the value of PKey
index 0 for one of the VFs, then the VF receives PKey change event that
triggers heavy flush. This flush calls update_parent_pkey that update the
broadcast object and its relevant members. If in this case the multicast
GID will not be updated, the interface state will be down.

Fixes: c2904141696e ("IPoIB: Fix pkey change flow for virtualization environments")
Signed-off-by: Feras Daoud <[email protected]>
Signed-off-by: Erez Shitrit <[email protected]>
Reviewed-by: Alex Vesker <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 13 +++++++++++++
1 file changed, 13 insertions(+)

--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -945,6 +945,19 @@ static inline int update_parent_pkey(str
*/
priv->dev->broadcast[8] = priv->pkey >> 8;
priv->dev->broadcast[9] = priv->pkey & 0xff;
+
+ /*
+ * Update the broadcast address in the priv->broadcast object,
+ * in case it already exists, otherwise no one will do that.
+ */
+ if (priv->broadcast) {
+ spin_lock_irq(&priv->lock);
+ memcpy(priv->broadcast->mcmember.mgid.raw,
+ priv->dev->broadcast + 4,
+ sizeof(union ib_gid));
+ spin_unlock_irq(&priv->lock);
+ }
+
return 0;
}




2018-03-23 10:47:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 50/97] mac80211: dont parse encrypted management frames in ieee80211_frame_acked

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Emmanuel Grumbach <[email protected]>


[ Upstream commit cf147085fdda044622973a12e4e06f1c753ab677 ]

ieee80211_frame_acked is called when a frame is acked by
the peer. In case this is a management frame, we check
if this an SMPS frame, in which case we can update our
antenna configuration.

When we parse the management frame we look at the category
in case it is an action frame. That byte sits after the IV
in case the frame was encrypted. This means that if the
frame was encrypted, we basically look at the IV instead
of looking at the category. It is then theorically
possible that we think that an SMPS action frame was acked
where really we had another frame that was encrypted.

Since the only management frame whose ack needs to be
tracked is the SMPS action frame, and that frame is not
a robust management frame, it will never be encrypted.
The easiest way to fix this problem is then to not look
at frames that were encrypted.

Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/mac80211/status.c | 1 +
1 file changed, 1 insertion(+)

--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -194,6 +194,7 @@ static void ieee80211_frame_acked(struct
}

if (ieee80211_is_action(mgmt->frame_control) &&
+ !ieee80211_has_protected(mgmt->frame_control) &&
mgmt->u.action.category == WLAN_CATEGORY_HT &&
mgmt->u.action.u.ht_smps.action == WLAN_HT_ACTION_SMPS &&
ieee80211_sdata_running(sdata)) {



2018-03-23 10:48:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 40/97] mmc: host: omap_hsmmc: checking for NULL instead of IS_ERR()

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>


[ Upstream commit ec5ab8933772c87f24ad62a4a602fe8949f423c2 ]

devm_pinctrl_get() returns error pointers, it never returns NULL.

Fixes: 455e5cd6f736 ("mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x")
Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: Kishon Vijay Abraham I <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mmc/host/omap_hsmmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1776,8 +1776,8 @@ static int omap_hsmmc_configure_wake_irq
*/
if (host->pdata->controller_flags & OMAP_HSMMC_SWAKEUP_MISSING) {
struct pinctrl *p = devm_pinctrl_get(host->dev);
- if (!p) {
- ret = -ENODEV;
+ if (IS_ERR(p)) {
+ ret = PTR_ERR(p);
goto err_free_irq;
}
if (IS_ERR(pinctrl_lookup_state(p, PINCTRL_STATE_DEFAULT))) {



2018-03-23 10:48:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 37/97] Fix driver usage of 128B WQEs when WQ_CREATE is V1.

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: James Smart <[email protected]>


[ Upstream commit 3f247de750b8dd8f50a2c1390e2a1238790a9dff ]

There are two versions of a structure for queue creation and setup that the
driver shares with FW. The driver was only treating as version 0.

Verify WQ_CREATE with 128B WQEs in V0 and V1.

Code review of another bug showed the driver passing
128B WQEs and 8 pages in WQ CREATE and V0.
Code inspection/instrumentation showed that the driver
uses V0 in WQ_CREATE and if the caller passes queue->entry_size
128B, the driver sets the hdr_version to V1 so all is good.
When I tested the V1 WQ_CREATE, the mailbox failed causing
the driver to unload.

Signed-off-by: Dick Kennedy <[email protected]>
Signed-off-by: James Smart <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/lpfc/lpfc_sli.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -13493,6 +13493,9 @@ lpfc_wq_create(struct lpfc_hba *phba, st
case LPFC_Q_CREATE_VERSION_1:
bf_set(lpfc_mbx_wq_create_wqe_count, &wq_create->u.request_1,
wq->entry_count);
+ bf_set(lpfc_mbox_hdr_version, &shdr->request,
+ LPFC_Q_CREATE_VERSION_1);
+
switch (wq->entry_size) {
default:
case 64:



2018-03-23 10:48:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 38/97] netfilter: xt_CT: fix refcnt leak on error path

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Gao Feng <[email protected]>


[ Upstream commit 470acf55a021713869b9bcc967268ac90c8a0fac ]

There are two cases which causes refcnt leak.

1. When nf_ct_timeout_ext_add failed in xt_ct_set_timeout, it should
free the timeout refcnt.
Now goto the err_put_timeout error handler instead of going ahead.

2. When the time policy is not found, we should call module_put.
Otherwise, the related cthelper module cannot be removed anymore.
It is easy to reproduce by typing the following command:
# iptables -t raw -A OUTPUT -p tcp -j CT --helper ftp --timeout xxx

Signed-off-by: Gao Feng <[email protected]>
Signed-off-by: Liping Zhang <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/netfilter/xt_CT.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)

--- a/net/netfilter/xt_CT.c
+++ b/net/netfilter/xt_CT.c
@@ -168,8 +168,10 @@ xt_ct_set_timeout(struct nf_conn *ct, co
goto err_put_timeout;
}
timeout_ext = nf_ct_timeout_ext_add(ct, timeout, GFP_ATOMIC);
- if (timeout_ext == NULL)
+ if (!timeout_ext) {
ret = -ENOMEM;
+ goto err_put_timeout;
+ }

rcu_read_unlock();
return ret;
@@ -201,6 +203,7 @@ static int xt_ct_tg_check(const struct x
struct xt_ct_target_info_v1 *info)
{
struct nf_conntrack_zone zone;
+ struct nf_conn_help *help;
struct nf_conn *ct;
int ret = -EOPNOTSUPP;

@@ -249,7 +252,7 @@ static int xt_ct_tg_check(const struct x
if (info->timeout[0]) {
ret = xt_ct_set_timeout(ct, par, info->timeout);
if (ret < 0)
- goto err3;
+ goto err4;
}
__set_bit(IPS_CONFIRMED_BIT, &ct->status);
nf_conntrack_get(&ct->ct_general);
@@ -257,6 +260,10 @@ out:
info->ct = ct;
return 0;

+err4:
+ help = nfct_help(ct);
+ if (help)
+ module_put(help->helper->me);
err3:
nf_ct_tmpl_free(ct);
err2:



2018-03-23 10:49:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 36/97] ASoC: Intel: Skylake: Uninitialized variable in probe_codec()

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>


[ Upstream commit e6a33532affd14c12688c0e9b2e773e8b2550f3b ]

My static checker complains that if snd_hdac_bus_get_response() returns
-EIO then "res" is uninitialized. Fix this by initializing it to -1 so
that the error is handled correctly.

Fixes: d8c2dab8381d ("ASoC: Intel: Add Skylake HDA audio driver")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/intel/skylake/skl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/intel/skylake/skl.c
+++ b/sound/soc/intel/skylake/skl.c
@@ -280,7 +280,7 @@ static int probe_codec(struct hdac_ext_b
struct hdac_bus *bus = ebus_to_hbus(ebus);
unsigned int cmd = (addr << 28) | (AC_NODE_ROOT << 20) |
(AC_VERB_PARAMETERS << 8) | AC_PAR_VENDOR_ID;
- unsigned int res;
+ unsigned int res = -1;

mutex_lock(&bus->cmd_mutex);
snd_hdac_bus_send_cmd(bus, cmd);



2018-03-23 10:49:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 34/97] IB/mlx4: Take write semaphore when changing the vma struct

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Maor Gottlieb <[email protected]>


[ Upstream commit 22c3653d04bd0c67b75e99d85e0c0bdf83947df5 ]

When the driver disassociate user context, it changes the vma to
anonymous by setting the vm_ops to null and zap the vma ptes.

In order to avoid race in the kernel, we need to take write lock
before we change the vma entries.

Fixes: ae184ddeca5db ('IB/mlx4_ib: Disassociate support')
Signed-off-by: Maor Gottlieb <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/hw/mlx4/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -1041,7 +1041,7 @@ static void mlx4_ib_disassociate_ucontex
/* need to protect from a race on closing the vma as part of
* mlx4_ib_vma_close().
*/
- down_read(&owning_mm->mmap_sem);
+ down_write(&owning_mm->mmap_sem);
for (i = 0; i < HW_BAR_COUNT; i++) {
vma = context->hw_bar_info[i].vma;
if (!vma)
@@ -1059,7 +1059,7 @@ static void mlx4_ib_disassociate_ucontex
context->hw_bar_info[i].vma->vm_ops = NULL;
}

- up_read(&owning_mm->mmap_sem);
+ up_write(&owning_mm->mmap_sem);
mmput(owning_mm);
put_task_struct(owning_process);
}



2018-03-23 10:49:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 46/97] iio: st_pressure: st_accel: Initialise sensor platform data properly

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Shrirang Bagul <[email protected]>


[ Upstream commit 7383d44b84c94aaca4bf695a6bd8a69f2295ef1a ]

This patch fixes the sensor platform data initialisation for st_pressure
and st_accel device drivers. Without this patch, the driver fails to
register the sensors when the user removes and re-loads the driver.

1. Unload the kernel modules for st_pressure
$ sudo rmmod st_pressure_i2c
$ sudo rmmod st_pressure

2. Re-load the driver
$ sudo insmod st_pressure
$ sudo insmod st_pressure_i2c

Signed-off-by: Jonathan Cameron <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/iio/accel/st_accel_core.c | 7 ++++---
drivers/iio/pressure/st_pressure_core.c | 8 ++++----
2 files changed, 8 insertions(+), 7 deletions(-)

--- a/drivers/iio/accel/st_accel_core.c
+++ b/drivers/iio/accel/st_accel_core.c
@@ -628,6 +628,8 @@ static const struct iio_trigger_ops st_a
int st_accel_common_probe(struct iio_dev *indio_dev)
{
struct st_sensor_data *adata = iio_priv(indio_dev);
+ struct st_sensors_platform_data *pdata =
+ (struct st_sensors_platform_data *)adata->dev->platform_data;
int irq = adata->get_irq_data_ready(indio_dev);
int err;

@@ -652,9 +654,8 @@ int st_accel_common_probe(struct iio_dev
&adata->sensor_settings->fs.fs_avl[0];
adata->odr = adata->sensor_settings->odr.odr_avl[0].hz;

- if (!adata->dev->platform_data)
- adata->dev->platform_data =
- (struct st_sensors_platform_data *)&default_accel_pdata;
+ if (!pdata)
+ pdata = (struct st_sensors_platform_data *)&default_accel_pdata;

err = st_sensors_init_sensor(indio_dev, adata->dev->platform_data);
if (err < 0)
--- a/drivers/iio/pressure/st_pressure_core.c
+++ b/drivers/iio/pressure/st_pressure_core.c
@@ -436,6 +436,8 @@ static const struct iio_trigger_ops st_p
int st_press_common_probe(struct iio_dev *indio_dev)
{
struct st_sensor_data *press_data = iio_priv(indio_dev);
+ struct st_sensors_platform_data *pdata =
+ (struct st_sensors_platform_data *)press_data->dev->platform_data;
int irq = press_data->get_irq_data_ready(indio_dev);
int err;

@@ -464,10 +466,8 @@ int st_press_common_probe(struct iio_dev
press_data->odr = press_data->sensor_settings->odr.odr_avl[0].hz;

/* Some devices don't support a data ready pin. */
- if (!press_data->dev->platform_data &&
- press_data->sensor_settings->drdy_irq.addr)
- press_data->dev->platform_data =
- (struct st_sensors_platform_data *)&default_press_pdata;
+ if (!pdata && press_data->sensor_settings->drdy_irq.addr)
+ pdata = (struct st_sensors_platform_data *)&default_press_pdata;

err = st_sensors_init_sensor(indio_dev, press_data->dev->platform_data);
if (err < 0)



2018-03-23 10:49:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 47/97] mt7601u: check return value of alloc_skb

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Pan Bian <[email protected]>


[ Upstream commit 5fb01e91daf84ad1e50edfcf63116ecbe31e7ba7 ]

Function alloc_skb() will return a NULL pointer if there is no enough
memory. However, in function mt7601u_mcu_msg_alloc(), its return value
is not validated before it is used. This patch fixes it.

Signed-off-by: Pan Bian <[email protected]>
Acked-by: Jakub Kicinski <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/mediatek/mt7601u/mcu.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/mediatek/mt7601u/mcu.c
+++ b/drivers/net/wireless/mediatek/mt7601u/mcu.c
@@ -66,8 +66,10 @@ mt7601u_mcu_msg_alloc(struct mt7601u_dev
WARN_ON(len % 4); /* if length is not divisible by 4 we need to pad */

skb = alloc_skb(len + MT_DMA_HDR_LEN + 4, GFP_KERNEL);
- skb_reserve(skb, MT_DMA_HDR_LEN);
- memcpy(skb_put(skb, len), data, len);
+ if (skb) {
+ skb_reserve(skb, MT_DMA_HDR_LEN);
+ memcpy(skb_put(skb, len), data, len);
+ }

return skb;
}
@@ -170,6 +172,8 @@ static int mt7601u_mcu_function_select(s
};

skb = mt7601u_mcu_msg_alloc(dev, &msg, sizeof(msg));
+ if (!skb)
+ return -ENOMEM;
return mt7601u_mcu_msg_send(dev, skb, CMD_FUN_SET_OP, func == 5);
}

@@ -205,6 +209,8 @@ mt7601u_mcu_calibrate(struct mt7601u_dev
};

skb = mt7601u_mcu_msg_alloc(dev, &msg, sizeof(msg));
+ if (!skb)
+ return -ENOMEM;
return mt7601u_mcu_msg_send(dev, skb, CMD_CALIBRATION_OP, true);
}




2018-03-23 10:50:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 35/97] IB/mlx4: Change vma from shared to private

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Maor Gottlieb <[email protected]>


[ Upstream commit ca37a664a8e4e9988b220988ceb4d79e3316f195 ]

Anonymous VMA (->vm_ops == NULL) cannot be shared, otherwise
it would lead to SIGBUS.

Remove the shared flags from the vma after we change it to be
anonymous.

This is easily reproduced by doing modprobe -r while running a
user-space application such as raw_ethernet_bw.

Fixes: ae184ddeca5db ('IB/mlx4_ib: Disassociate support')
Signed-off-by: Maor Gottlieb <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/hw/mlx4/main.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -1055,6 +1055,8 @@ static void mlx4_ib_disassociate_ucontex
BUG_ON(1);
}

+ context->hw_bar_info[i].vma->vm_flags &=
+ ~(VM_SHARED | VM_MAYSHARE);
/* context going to be destroyed, should not access ops any more */
context->hw_bar_info[i].vma->vm_ops = NULL;
}



2018-03-23 10:50:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 48/97] rndis_wlan: add return value validation

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Pan Bian <[email protected]>


[ Upstream commit 9dc7efd3978aa67ae598129d2a3f240b390ce508 ]

Function create_singlethread_workqueue() will return a NULL pointer if
there is no enough memory, and its return value should be validated
before using. However, in function rndis_wlan_bind(), its return value
is not checked. This may cause NULL dereference bugs. This patch fixes
it.

Signed-off-by: Pan Bian <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/rndis_wlan.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -3425,6 +3425,10 @@ static int rndis_wlan_bind(struct usbnet

/* because rndis_command() sleeps we need to use workqueue */
priv->workqueue = create_singlethread_workqueue("rndis_wlan");
+ if (!priv->workqueue) {
+ wiphy_free(wiphy);
+ return -ENOMEM;
+ }
INIT_WORK(&priv->work, rndis_wlan_worker);
INIT_DELAYED_WORK(&priv->dev_poller_work, rndis_device_poller);
INIT_DELAYED_WORK(&priv->scan_work, rndis_get_scan_results);



2018-03-23 10:50:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 43/97] scsi: mac_esp: Replace bogus memory barrier with spinlock

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Finn Thain <[email protected]>


[ Upstream commit 4da2b1eb230ba4ad19b58984dc52e05b1073df5f ]

Commit da244654c66e ("[SCSI] mac_esp: fix for quadras with two esp
chips") added mac_scsi_esp_intr() to handle the IRQ lines from a pair of
on-board ESP chips (a normal shared IRQ did not work).

Proper mutual exclusion was missing from that patch. This patch fixes
race conditions between comparison and assignment of esp_chips[]
pointers.

Signed-off-by: Finn Thain <[email protected]>
Reviewed-by: Michael Schmitz <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/mac_esp.c | 33 +++++++++++++++++++++++----------
1 file changed, 23 insertions(+), 10 deletions(-)

--- a/drivers/scsi/mac_esp.c
+++ b/drivers/scsi/mac_esp.c
@@ -55,6 +55,7 @@ struct mac_esp_priv {
int error;
};
static struct esp *esp_chips[2];
+static DEFINE_SPINLOCK(esp_chips_lock);

#define MAC_ESP_GET_PRIV(esp) ((struct mac_esp_priv *) \
platform_get_drvdata((struct platform_device *) \
@@ -562,15 +563,18 @@ static int esp_mac_probe(struct platform
}

host->irq = IRQ_MAC_SCSI;
- esp_chips[dev->id] = esp;
- mb();
- if (esp_chips[!dev->id] == NULL) {
- err = request_irq(host->irq, mac_scsi_esp_intr, 0, "ESP", NULL);
- if (err < 0) {
- esp_chips[dev->id] = NULL;
- goto fail_free_priv;
- }
+
+ /* The request_irq() call is intended to succeed for the first device
+ * and fail for the second device.
+ */
+ err = request_irq(host->irq, mac_scsi_esp_intr, 0, "ESP", NULL);
+ spin_lock(&esp_chips_lock);
+ if (err < 0 && esp_chips[!dev->id] == NULL) {
+ spin_unlock(&esp_chips_lock);
+ goto fail_free_priv;
}
+ esp_chips[dev->id] = esp;
+ spin_unlock(&esp_chips_lock);

err = scsi_esp_register(esp, &dev->dev);
if (err)
@@ -579,8 +583,13 @@ static int esp_mac_probe(struct platform
return 0;

fail_free_irq:
- if (esp_chips[!dev->id] == NULL)
+ spin_lock(&esp_chips_lock);
+ esp_chips[dev->id] = NULL;
+ if (esp_chips[!dev->id] == NULL) {
+ spin_unlock(&esp_chips_lock);
free_irq(host->irq, esp);
+ } else
+ spin_unlock(&esp_chips_lock);
fail_free_priv:
kfree(mep);
fail_free_command_block:
@@ -599,9 +608,13 @@ static int esp_mac_remove(struct platfor

scsi_esp_unregister(esp);

+ spin_lock(&esp_chips_lock);
esp_chips[dev->id] = NULL;
- if (!(esp_chips[0] || esp_chips[1]))
+ if (esp_chips[!dev->id] == NULL) {
+ spin_unlock(&esp_chips_lock);
free_irq(irq, NULL);
+ } else
+ spin_unlock(&esp_chips_lock);

kfree(mep);




2018-03-23 10:50:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 45/97] NFS: dont try to cross a mountpount when there isnt one there.

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: NeilBrown <[email protected]>


[ Upstream commit 99bbf6ecc694dfe0b026e15359c5aa2a60b97a93 ]

consider the sequence of commands:
mkdir -p /import/nfs /import/bind /import/etc
mount --bind / /import/bind
mount --make-private /import/bind
mount --bind /import/etc /import/bind/etc

exportfs -o rw,no_root_squash,crossmnt,async,no_subtree_check localhost:/
mount -o vers=4 localhost:/ /import/nfs
ls -l /import/nfs/etc

You would not expect this to report a stale file handle.
Yet it does.

The manipulations under /import/bind cause the dentry for
/etc to get the DCACHE_MOUNTED flag set, even though nothing
is mounted on /etc. This causes nfsd to call
nfsd_cross_mnt() even though there is no mountpoint. So an
upcall to mountd for "/etc" is performed.

The 'crossmnt' flag on the export of / causes mountd to
report that /etc is exported as it is a descendant of /. It
assumes the kernel wouldn't ask about something that wasn't
a mountpoint. The filehandle returned identifies the
filesystem and the inode number of /etc.

When this filehandle is presented to rpc.mountd, via
"nfsd.fh", the inode cannot be found associated with any
name in /etc/exports, or with any mountpoint listed by
getmntent(). So rpc.mountd says the filehandle doesn't
exist. Hence ESTALE.

This is fixed by teaching nfsd not to trust DCACHE_MOUNTED
too much. It is just a hint, not a guarantee.
Change nfsd_mountpoint() to return '1' for a certain mountpoint,
'2' for a possible mountpoint, and 0 otherwise.

Then change nfsd_crossmnt() to check if follow_down()
actually found a mountpount and, if not, to avoid performing
a lookup if the location is not known to certainly require
an export-point.

Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfsd/vfs.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)

--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -92,6 +92,12 @@ nfsd_cross_mnt(struct svc_rqst *rqstp, s
err = follow_down(&path);
if (err < 0)
goto out;
+ if (path.mnt == exp->ex_path.mnt && path.dentry == dentry &&
+ nfsd_mountpoint(dentry, exp) == 2) {
+ /* This is only a mountpoint in some other namespace */
+ path_put(&path);
+ goto out;
+ }

exp2 = rqst_exp_get_by_name(rqstp, &path);
if (IS_ERR(exp2)) {
@@ -165,16 +171,26 @@ static int nfsd_lookup_parent(struct svc
/*
* For nfsd purposes, we treat V4ROOT exports as though there was an
* export at *every* directory.
+ * We return:
+ * '1' if this dentry *must* be an export point,
+ * '2' if it might be, if there is really a mount here, and
+ * '0' if there is no chance of an export point here.
*/
int nfsd_mountpoint(struct dentry *dentry, struct svc_export *exp)
{
- if (d_mountpoint(dentry))
+ if (!d_inode(dentry))
+ return 0;
+ if (exp->ex_flags & NFSEXP_V4ROOT)
return 1;
if (nfsd4_is_junction(dentry))
return 1;
- if (!(exp->ex_flags & NFSEXP_V4ROOT))
- return 0;
- return d_inode(dentry) != NULL;
+ if (d_mountpoint(dentry))
+ /*
+ * Might only be a mountpoint in a different namespace,
+ * but we need to check.
+ */
+ return 2;
+ return 0;
}

__be32



2018-03-23 10:50:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 33/97] HSI: ssi_protocol: double free in ssip_pn_xmit()

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>


[ Upstream commit 3026050179a3a9a6f5c892c414b5e36ecf092081 ]

If skb_pad() fails then it frees skb and we don't need to free it again
at the end of the function.

Fixes: dc7bf5d7 ("HSI: Introduce driver for SSI Protocol")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Sebastian Reichel <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hsi/clients/ssi_protocol.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/hsi/clients/ssi_protocol.c
+++ b/drivers/hsi/clients/ssi_protocol.c
@@ -976,7 +976,7 @@ static int ssip_pn_xmit(struct sk_buff *
goto drop;
/* Pad to 32-bits - FIXME: Revisit*/
if ((skb->len & 3) && skb_pad(skb, 4 - (skb->len & 3)))
- goto drop;
+ goto inc_dropped;

/*
* Modem sends Phonet messages over SSI with its own endianess...
@@ -1028,8 +1028,9 @@ static int ssip_pn_xmit(struct sk_buff *
drop2:
hsi_free_msg(msg);
drop:
- dev->stats.tx_dropped++;
dev_kfree_skb(skb);
+inc_dropped:
+ dev->stats.tx_dropped++;

return 0;
}



2018-03-23 10:51:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 25/97] iommu/omap: Register driver before setting IOMMU ops

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Suman Anna <[email protected]>


[ Upstream commit abaa7e5b054aae567861628b74dbc7fbf8ed79e8 ]

Move the registration of the OMAP IOMMU platform driver before
setting the IOMMU callbacks on the platform bus. This causes
the IOMMU devices to be probed first before the .add_device()
callback is invoked for all registered devices, and allows
the iommu_group support to be added to the OMAP IOMMU driver.

While at this, also check for the return status from bus_set_iommu.

Signed-off-by: Suman Anna <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/iommu/omap-iommu.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)

--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1295,6 +1295,7 @@ static int __init omap_iommu_init(void)
const unsigned long flags = SLAB_HWCACHE_ALIGN;
size_t align = 1 << 10; /* L2 pagetable alignement */
struct device_node *np;
+ int ret;

np = of_find_matching_node(NULL, omap_iommu_of_match);
if (!np)
@@ -1308,11 +1309,25 @@ static int __init omap_iommu_init(void)
return -ENOMEM;
iopte_cachep = p;

- bus_set_iommu(&platform_bus_type, &omap_iommu_ops);
-
omap_iommu_debugfs_init();

- return platform_driver_register(&omap_iommu_driver);
+ ret = platform_driver_register(&omap_iommu_driver);
+ if (ret) {
+ pr_err("%s: failed to register driver\n", __func__);
+ goto fail_driver;
+ }
+
+ ret = bus_set_iommu(&platform_bus_type, &omap_iommu_ops);
+ if (ret)
+ goto fail_bus;
+
+ return 0;
+
+fail_bus:
+ platform_driver_unregister(&omap_iommu_driver);
+fail_driver:
+ kmem_cache_destroy(iopte_cachep);
+ return ret;
}
subsys_initcall(omap_iommu_init);
/* must be ready before omap3isp is probed */



2018-03-23 10:51:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 16/97] i2c: i2c-scmi: add a MS HID

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Edgar Cherkasov <[email protected]>


[ Upstream commit e058e7a4bc89104540a8a303682248614b5df6f1 ]

Description of the problem:
- i2c-scmi driver contains only two identifiers "SMBUS01" and "SMBUSIBM";
- the fist HID (SMBUS01) is clearly defined in "SMBus Control Method
Interface Specification, version 1.0": "Each device must specify
'SMBUS01' as its _HID and use a unique _UID value";
- unfortunately, BIOS vendors (like AMI) seem to ignore this requirement
and implement "SMB0001" HID instead of "SMBUS01";
- I speculate that they do this because only "SMB0001" is hard coded in
Windows SMBus driver produced by Microsoft.

This leads to following situation:
- SMBus works out of box in Windows but not in Linux;
- board vendors are forced to add correct "SMBUS01" HID to BIOS to make
SMBus work in Linux. Moreover the same board vendors complain that
tools (3-rd party ASL compiler) do not like the "SMBUS01" identifier
and produce errors. So they need to constantly patch the compiler for
each new version of BIOS.

As it is very unlikely that BIOS vendors implement a correct HID in
future, I would propose to consider whether it is possible to work around
the problem by adding MS HID to the Linux i2c-scmi driver.

v2: move the definition of the new HID to the driver itself.

Signed-off-by: Edgar Cherkasov <[email protected]>
Signed-off-by: Michael Brunner <[email protected]>
Acked-by: Viktor Krasnov <[email protected]>
Reviewed-by: Jean Delvare <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/i2c/busses/i2c-scmi.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/i2c/busses/i2c-scmi.c
+++ b/drivers/i2c/busses/i2c-scmi.c
@@ -18,6 +18,9 @@
#define ACPI_SMBUS_HC_CLASS "smbus"
#define ACPI_SMBUS_HC_DEVICE_NAME "cmi"

+/* SMBUS HID definition as supported by Microsoft Windows */
+#define ACPI_SMBUS_MS_HID "SMB0001"
+
ACPI_MODULE_NAME("smbus_cmi");

struct smbus_methods_t {
@@ -51,6 +54,7 @@ static const struct smbus_methods_t ibm_
static const struct acpi_device_id acpi_smbus_cmi_ids[] = {
{"SMBUS01", (kernel_ulong_t)&smbus_methods},
{ACPI_SMBUS_IBM_HID, (kernel_ulong_t)&ibm_smbus_methods},
+ {ACPI_SMBUS_MS_HID, (kernel_ulong_t)&smbus_methods},
{"", 0}
};
MODULE_DEVICE_TABLE(acpi, acpi_smbus_cmi_ids);



2018-03-23 10:51:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 44/97] infiniband/uverbs: Fix integer overflows

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Vlad Tsyrklevich <[email protected]>


[ Upstream commit 4f7f4dcfff2c19debbcdbcc861c325610a15e0c5 ]

The 'num_sge' variable is verfied to be smaller than the 'sge_count'
variable; however, since both are user-controlled it's possible to cause
an integer overflow for the kmalloc multiply on 32-bit platforms
(num_sge and sge_count are both defined u32). By crafting an input that
causes a smaller-than-expected allocation it's possible to write
controlled data out-of-bounds.

Signed-off-by: Vlad Tsyrklevich <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/core/uverbs_cmd.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)

--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -2436,9 +2436,13 @@ ssize_t ib_uverbs_destroy_qp(struct ib_u

static void *alloc_wr(size_t wr_size, __u32 num_sge)
{
+ if (num_sge >= (U32_MAX - ALIGN(wr_size, sizeof (struct ib_sge))) /
+ sizeof (struct ib_sge))
+ return NULL;
+
return kmalloc(ALIGN(wr_size, sizeof (struct ib_sge)) +
num_sge * sizeof (struct ib_sge), GFP_KERNEL);
-};
+}

ssize_t ib_uverbs_post_send(struct ib_uverbs_file *file,
struct ib_device *ib_dev,
@@ -2664,6 +2668,13 @@ static struct ib_recv_wr *ib_uverbs_unma
ret = -EINVAL;
goto err;
}
+
+ if (user_wr->num_sge >=
+ (U32_MAX - ALIGN(sizeof *next, sizeof (struct ib_sge))) /
+ sizeof (struct ib_sge)) {
+ ret = -EINVAL;
+ goto err;
+ }

next = kmalloc(ALIGN(sizeof *next, sizeof (struct ib_sge)) +
user_wr->num_sge * sizeof (struct ib_sge),



2018-03-23 10:51:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 24/97] ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA and !FRAME_POINTER

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Abel Vesa <[email protected]>


[ Upstream commit 6f05d0761af612e04572ba4d65b4c0274a88444f ]

The support for dynamic ftrace with CONFIG_DEBUG_RODATA involves
overriding the weak arch_ftrace_update_code() with a variant which makes
the kernel text writable around the patching.

This override was however added under the CONFIG_OLD_MCOUNT ifdef, and
CONFIG_OLD_MCOUNT is only enabled if frame pointers are enabled.

This leads to non-functional dynamic ftrace (ftrace triggers a
WARN_ON()) when CONFIG_DEBUG_RODATA is enabled and CONFIG_FRAME_POINTER
is not.

Move the override out of that ifdef and into the CONFIG_DYNAMIC_FTRACE
ifdef where it belongs.

Fixes: 80d6b0c2eed2a ("ARM: mm: allow text and rodata sections to be read-only")
Suggested-by: Nicolai Stange <[email protected]>
Suggested-by: Rabin Vincent <[email protected]>
Signed-off-by: Abel Vesa <[email protected]>
Acked-by: Rabin Vincent <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/kernel/ftrace.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)

--- a/arch/arm/kernel/ftrace.c
+++ b/arch/arm/kernel/ftrace.c
@@ -29,11 +29,6 @@
#endif

#ifdef CONFIG_DYNAMIC_FTRACE
-#ifdef CONFIG_OLD_MCOUNT
-#define OLD_MCOUNT_ADDR ((unsigned long) mcount)
-#define OLD_FTRACE_ADDR ((unsigned long) ftrace_caller_old)
-
-#define OLD_NOP 0xe1a00000 /* mov r0, r0 */

static int __ftrace_modify_code(void *data)
{
@@ -51,6 +46,12 @@ void arch_ftrace_update_code(int command
stop_machine(__ftrace_modify_code, &command, NULL);
}

+#ifdef CONFIG_OLD_MCOUNT
+#define OLD_MCOUNT_ADDR ((unsigned long) mcount)
+#define OLD_FTRACE_ADDR ((unsigned long) ftrace_caller_old)
+
+#define OLD_NOP 0xe1a00000 /* mov r0, r0 */
+
static unsigned long ftrace_nop_replace(struct dyn_ftrace *rec)
{
return rec->arch.old_mcount ? OLD_NOP : NOP;



2018-03-23 10:52:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 42/97] qlcnic: fix unchecked return value

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Pan Bian <[email protected]>


[ Upstream commit 91ec701a553cb3de470fd471c6fefe3ad1125455 ]

Function pci_find_ext_capability() may return 0, which is an invalid
address. In function qlcnic_sriov_virtid_fn(), its return value is used
without validation. This may result in invalid memory access bugs. This
patch fixes the bug.

Signed-off-by: Pan Bian <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c
@@ -127,6 +127,8 @@ static int qlcnic_sriov_virtid_fn(struct
return 0;

pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_SRIOV);
+ if (!pos)
+ return 0;
pci_read_config_word(dev, pos + PCI_SRIOV_VF_OFFSET, &offset);
pci_read_config_word(dev, pos + PCI_SRIOV_VF_STRIDE, &stride);




2018-03-23 10:52:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 21/97] clk: ns2: Correct SDIO bits

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Bharat Kumar Reddy Gooty <[email protected]>


[ Upstream commit 8973aa4aecac223548366ca81818309a0f0efa6d ]

Corrected the bits for power and iso.

Signed-off-by: Bharat Kumar Reddy Gooty <[email protected]>
Signed-off-by: Jon Mason <[email protected]>
Fixes: f7225a83 ("clk: ns2: add clock support for Broadcom Northstar 2 SoC")
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/clk/bcm/clk-ns2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/clk/bcm/clk-ns2.c
+++ b/drivers/clk/bcm/clk-ns2.c
@@ -103,7 +103,7 @@ CLK_OF_DECLARE(ns2_genpll_src_clk, "brcm

static const struct iproc_pll_ctrl genpll_sw = {
.flags = IPROC_CLK_AON | IPROC_CLK_PLL_SPLIT_STAT_CTRL,
- .aon = AON_VAL(0x0, 2, 9, 8),
+ .aon = AON_VAL(0x0, 1, 11, 10),
.reset = RESET_VAL(0x4, 2, 1),
.dig_filter = DF_VAL(0x0, 9, 3, 5, 4, 2, 3),
.ndiv_int = REG_VAL(0x8, 4, 10),



2018-03-23 10:52:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 23/97] KVM: PPC: Book3S PR: Exit KVM on failed mapping

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Alexey Kardashevskiy <[email protected]>


[ Upstream commit bd9166ffe624000140fc6b606b256df01fc0d060 ]

At the moment kvmppc_mmu_map_page() returns -1 if
mmu_hash_ops.hpte_insert() fails for any reason so the page fault handler
resumes the guest and it faults on the same address again.

This adds distinction to kvmppc_mmu_map_page() to return -EIO if
mmu_hash_ops.hpte_insert() failed for a reason other than full pteg.
At the moment only pSeries_lpar_hpte_insert() returns -2 if
plpar_pte_enter() failed with a code other than H_PTEG_FULL.
Other mmu_hash_ops.hpte_insert() instances can only fail with
-1 "full pteg".

With this change, if PR KVM fails to update HPT, it can signal
the userspace about this instead of returning to guest and having
the very same page fault over and over again.

Signed-off-by: Alexey Kardashevskiy <[email protected]>
Reviewed-by: David Gibson <[email protected]>
Signed-off-by: Paul Mackerras <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/kvm/book3s_64_mmu_host.c | 5 ++++-
arch/powerpc/kvm/book3s_pr.c | 6 +++++-
2 files changed, 9 insertions(+), 2 deletions(-)

--- a/arch/powerpc/kvm/book3s_64_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_host.c
@@ -177,12 +177,15 @@ map_again:
ret = ppc_md.hpte_insert(hpteg, vpn, hpaddr, rflags, vflags,
hpsize, hpsize, MMU_SEGSIZE_256M);

- if (ret < 0) {
+ if (ret == -1) {
/* If we couldn't map a primary PTE, try a secondary */
hash = ~hash;
vflags ^= HPTE_V_SECONDARY;
attempt++;
goto map_again;
+ } else if (ret < 0) {
+ r = -EIO;
+ goto out_unlock;
} else {
trace_kvm_book3s_64_mmu_map(rflags, hpteg,
vpn, hpaddr, orig_pte);
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -625,7 +625,11 @@ int kvmppc_handle_pagefault(struct kvm_r
kvmppc_mmu_unmap_page(vcpu, &pte);
}
/* The guest's PTE is not mapped yet. Map on the host */
- kvmppc_mmu_map_page(vcpu, &pte, iswrite);
+ if (kvmppc_mmu_map_page(vcpu, &pte, iswrite) == -EIO) {
+ /* Exit KVM if mapping failed */
+ run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
+ return RESUME_HOST;
+ }
if (data)
vcpu->stat.sp_storage++;
else if (vcpu->arch.mmu.is_dcbz32(vcpu) &&



2018-03-23 10:52:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 19/97] spi: dw: Disable clock after unregistering the host

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Marek Vasut <[email protected]>


[ Upstream commit 400c18e3dc86e04ef5afec9b86a8586ca629b9e9 ]

The dw_mmio driver disables the block clock before unregistering
the host. The code unregistering the host may access the SPI block
registers. If register access happens with block clock disabled,
this may lead to a bus hang. Disable the clock after unregistering
the host to prevent such situation.

This bug was observed on Altera Cyclone V SoC.

Signed-off-by: Marek Vasut <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Mark Brown <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/spi/spi-dw-mmio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/spi/spi-dw-mmio.c
+++ b/drivers/spi/spi-dw-mmio.c
@@ -120,8 +120,8 @@ static int dw_spi_mmio_remove(struct pla
{
struct dw_spi_mmio *dwsmmio = platform_get_drvdata(pdev);

- clk_disable_unprepare(dwsmmio->clk);
dw_spi_remove_host(&dwsmmio->dws);
+ clk_disable_unprepare(dwsmmio->clk);

return 0;
}



2018-03-23 10:53:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 18/97] [media] media/dvb-core: Race condition when writing to CAM

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Jasmin J <[email protected]>


[ Upstream commit e7080d4471d805d921a9ea21b32f911a91e248cb ]

It started with a sporadic message in syslog: "CAM tried to send a
buffer larger than the ecount size" This message is not the fault
itself, but a consecutive fault, after a read error from the CAM. This
happens only on several CAMs, several hardware, and of course sporadic.

It is a consecutive fault, if the last read from the CAM did fail. I
guess this will not happen on all CAMs, but at least it did on mine.
There was a write error to the CAM and during the re-initialization
procedure, the CAM finished the last read, although it got a RS.

The write error to the CAM happened because a race condition between HC
write, checking DA and FR.

This patch added an additional check for DA(RE), just after checking FR.
It is important to read the CAMs status register again, to give the CAM
the necessary time for a proper reaction to HC. Please note the
description within the source code (patch below).

[[email protected]: make checkpatch happy]

Signed-off-by: Jasmin jessich <[email protected]>
Tested-by: Ralph Metzler <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/dvb-core/dvb_ca_en50221.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)

--- a/drivers/media/dvb-core/dvb_ca_en50221.c
+++ b/drivers/media/dvb-core/dvb_ca_en50221.c
@@ -750,6 +750,29 @@ static int dvb_ca_en50221_write_data(str
goto exit;
}

+ /*
+ * It may need some time for the CAM to settle down, or there might
+ * be a race condition between the CAM, writing HC and our last
+ * check for DA. This happens, if the CAM asserts DA, just after
+ * checking DA before we are setting HC. In this case it might be
+ * a bug in the CAM to keep the FR bit, the lower layer/HW
+ * communication requires a longer timeout or the CAM needs more
+ * time internally. But this happens in reality!
+ * We need to read the status from the HW again and do the same
+ * we did for the previous check for DA
+ */
+ status = ca->pub->read_cam_control(ca->pub, slot, CTRLIF_STATUS);
+ if (status < 0)
+ goto exit;
+
+ if (status & (STATUSREG_DA | STATUSREG_RE)) {
+ if (status & STATUSREG_DA)
+ dvb_ca_en50221_thread_wakeup(ca);
+
+ status = -EAGAIN;
+ goto exit;
+ }
+
/* send the amount of data */
if ((status = ca->pub->write_cam_control(ca->pub, slot, CTRLIF_SIZE_HIGH, bytes_write >> 8)) != 0)
goto exit;



2018-03-23 10:53:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 30/97] ALSA: hda - Fix headset microphone detection for ASUS N551 and N751

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Mikhail Paulyshka <[email protected]>


[ Upstream commit fc7438b1eb12b6c93d7b7a62423779eb5dfc673c ]

Headset microphone does not work out of the box on ASUS Nx51
laptops. This patch fixes it.

Patch tested on Asus N551 laptop. Asus N751 part is not tested, but
according to [1] this laptop uses the same audiosystem.

1. https://bugzilla.kernel.org/show_bug.cgi?id=117781

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195437
Signed-off-by: Mikhail Paulyshka <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/pci/hda/patch_realtek.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6717,6 +6717,7 @@ enum {
ALC668_FIXUP_DELL_DISABLE_AAMIX,
ALC668_FIXUP_DELL_XPS13,
ALC662_FIXUP_ASUS_Nx50,
+ ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE,
ALC668_FIXUP_ASUS_Nx51,
};

@@ -6964,14 +6965,21 @@ static const struct hda_fixup alc662_fix
.chained = true,
.chain_id = ALC662_FIXUP_BASS_1A
},
+ [ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc_fixup_headset_mode_alc668,
+ .chain_id = ALC662_FIXUP_BASS_CHMAP
+ },
[ALC668_FIXUP_ASUS_Nx51] = {
.type = HDA_FIXUP_PINS,
.v.pins = (const struct hda_pintbl[]) {
- {0x1a, 0x90170151}, /* bass speaker */
+ { 0x19, 0x03a1913d }, /* use as headphone mic, without its own jack detect */
+ { 0x1a, 0x90170151 }, /* bass speaker */
+ { 0x1b, 0x03a1113c }, /* use as headset mic, without its own jack detect */
{}
},
.chained = true,
- .chain_id = ALC662_FIXUP_BASS_CHMAP,
+ .chain_id = ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE,
},
};




2018-03-23 10:53:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 22/97] scsi: virtio_scsi: Always try to read VPD pages

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: David Gibson <[email protected]>


[ Upstream commit 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0 ]

Passed through SCSI targets may have transfer limits which come from the
host SCSI controller or something on the host side other than the target
itself.

To make this work properly, the hypervisor can adjust the target's VPD
information to advertise these limits. But for that to work, the guest
has to look at the VPD pages, which we won't do by default if it is an
SPC-2 device, even if it does actually support it.

This adds a workaround to address this, forcing devices attached to a
virtio-scsi controller to always check the VPD pages. This is modelled
on a similar workaround for the storvsc (Hyper-V) SCSI controller,
although that exists for slightly different reasons.

A specific case which causes this is a volume from IBM's IPR RAID
controller (which presents as an SPC-2 device, although it does support
VPD) passed through with qemu's 'scsi-block' device.

[mkp: fixed typo]

Signed-off-by: David Gibson <[email protected]>
Acked-by: Paolo Bonzini <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/virtio_scsi.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)

--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -28,6 +28,7 @@
#include <scsi/scsi_device.h>
#include <scsi/scsi_cmnd.h>
#include <scsi/scsi_tcq.h>
+#include <scsi/scsi_devinfo.h>
#include <linux/seqlock.h>

#define VIRTIO_SCSI_MEMPOOL_SZ 64
@@ -704,6 +705,28 @@ static int virtscsi_device_reset(struct
return virtscsi_tmf(vscsi, cmd);
}

+static int virtscsi_device_alloc(struct scsi_device *sdevice)
+{
+ /*
+ * Passed through SCSI targets (e.g. with qemu's 'scsi-block')
+ * may have transfer limits which come from the host SCSI
+ * controller or something on the host side other than the
+ * target itself.
+ *
+ * To make this work properly, the hypervisor can adjust the
+ * target's VPD information to advertise these limits. But
+ * for that to work, the guest has to look at the VPD pages,
+ * which we won't do by default if it is an SPC-2 device, even
+ * if it does actually support it.
+ *
+ * So, set the blist to always try to read the VPD pages.
+ */
+ sdevice->sdev_bflags = BLIST_TRY_VPD_PAGES;
+
+ return 0;
+}
+
+
/**
* virtscsi_change_queue_depth() - Change a virtscsi target's queue depth
* @sdev: Virtscsi target whose queue depth to change
@@ -775,6 +798,7 @@ static struct scsi_host_template virtscs
.change_queue_depth = virtscsi_change_queue_depth,
.eh_abort_handler = virtscsi_abort,
.eh_device_reset_handler = virtscsi_device_reset,
+ .slave_alloc = virtscsi_device_alloc,

.can_queue = 1024,
.dma_boundary = UINT_MAX,



2018-03-23 10:53:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 28/97] tcp: remove poll() flakes with FastOpen

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Eric Dumazet <[email protected]>


[ Upstream commit 0f9fa831aecfc297b7b45d4f046759bcefcf87f0 ]

When using TCP FastOpen for an active session, we send one wakeup event
from tcp_finish_connect(), right before the data eventually contained in
the received SYNACK is queued to sk->sk_receive_queue.

This means that depending on machine load or luck, poll() users
might receive POLLOUT events instead of POLLIN|POLLOUT

To fix this, we need to move the call to sk->sk_state_change()
after the (optional) call to tcp_rcv_fastopen_synack()

Signed-off-by: Eric Dumazet <[email protected]>
Acked-by: Yuchung Cheng <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/tcp_input.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)

--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5464,10 +5464,6 @@ void tcp_finish_connect(struct sock *sk,
else
tp->pred_flags = 0;

- if (!sock_flag(sk, SOCK_DEAD)) {
- sk->sk_state_change(sk);
- sk_wake_async(sk, SOCK_WAKE_IO, POLL_OUT);
- }
}

static bool tcp_rcv_fastopen_synack(struct sock *sk, struct sk_buff *synack,
@@ -5531,6 +5527,7 @@ static int tcp_rcv_synsent_state_process
struct tcp_sock *tp = tcp_sk(sk);
struct tcp_fastopen_cookie foc = { .len = -1 };
int saved_clamp = tp->rx_opt.mss_clamp;
+ bool fastopen_fail;

tcp_parse_options(skb, &tp->rx_opt, 0, &foc);
if (tp->rx_opt.saw_tstamp && tp->rx_opt.rcv_tsecr)
@@ -5633,10 +5630,15 @@ static int tcp_rcv_synsent_state_process

tcp_finish_connect(sk, skb);

- if ((tp->syn_fastopen || tp->syn_data) &&
- tcp_rcv_fastopen_synack(sk, skb, &foc))
- return -1;
+ fastopen_fail = (tp->syn_fastopen || tp->syn_data) &&
+ tcp_rcv_fastopen_synack(sk, skb, &foc);

+ if (!sock_flag(sk, SOCK_DEAD)) {
+ sk->sk_state_change(sk);
+ sk_wake_async(sk, SOCK_WAKE_IO, POLL_OUT);
+ }
+ if (fastopen_fail)
+ return -1;
if (sk->sk_write_pending ||
icsk->icsk_accept_queue.rskq_defer_accept ||
icsk->icsk_ack.pingpong) {



2018-03-23 10:54:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 26/97] md/raid10: wait up frozen array in handle_write_completed

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Guoqing Jiang <[email protected]>


[ Upstream commit cf25ae78fc50010f66b9be945017796da34c434d ]

Since nr_queued is changed, we need to call wake_up here
if the array is already frozen and waiting for condition
"nr_pending == nr_queued + extra" to be true.

And commit 824e47daddbf ("RAID1: avoid unnecessary spin
locks in I/O barrier code") which has already added the
wake_up for raid1.

Signed-off-by: Guoqing Jiang <[email protected]>
Reviewed-by: NeilBrown <[email protected]>
Signed-off-by: Shaohua Li <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/raid10.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -2698,6 +2698,11 @@ static void handle_write_completed(struc
list_add(&r10_bio->retry_list, &conf->bio_end_io_list);
conf->nr_queued++;
spin_unlock_irq(&conf->device_lock);
+ /*
+ * In case freeze_array() is waiting for condition
+ * nr_pending == nr_queued + extra to be true.
+ */
+ wake_up(&conf->wait_barrier);
md_wakeup_thread(conf->mddev->thread);
} else {
if (test_bit(R10BIO_WriteError,



2018-03-23 10:54:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 17/97] net: ipv6: send unsolicited NA on admin up

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: David Ahern <[email protected]>


[ Upstream commit 4a6e3c5def13c91adf2acc613837001f09af3baa ]

ndisc_notify is the ipv6 equivalent to arp_notify. When arp_notify is
set to 1, gratuitous arp requests are sent when the device is brought up.
The same is expected when ndisc_notify is set to 1 (per ndisc_notify in
Documentation/networking/ip-sysctl.txt). The NA is not sent on NETDEV_UP
event; add it.

Fixes: 5cb04436eef6 ("ipv6: add knob to send unsolicited ND on link-layer address change")
Signed-off-by: David Ahern <[email protected]>
Acked-by: Hannes Frederic Sowa <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/ndisc.c | 2 ++
1 file changed, 2 insertions(+)

--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1686,6 +1686,8 @@ static int ndisc_netdev_event(struct not
case NETDEV_CHANGEADDR:
neigh_changeaddr(&nd_tbl, dev);
fib6_run_gc(0, net, false);
+ /* fallthrough */
+ case NETDEV_UP:
idev = in6_dev_get(dev);
if (!idev)
break;



2018-03-23 10:55:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 09/97] rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Hans de Goede <[email protected]>


[ Upstream commit a1e23a42f1bdc00e32fc4869caef12e4e6272f26 ]

On some systems (e.g. Intel Bay Trail systems) the legacy PIC is not
used, in this case virq 8 will be a random irq, rather then hw_irq 8
from the PIC.

Requesting virq 8 in this case will not help us to get alarm irqs and
may cause problems for other drivers which actually do need virq 8,
for example on an Asus Transformer T100TA this leads to:

[ 28.745155] genirq: Flags mismatch irq 8. 00000088 (mmc0) vs. 00000080 (rtc0)
<snip oops>
[ 28.753700] mmc0: Failed to request IRQ 8: -16
[ 28.975934] sdhci-acpi: probe of 80860F14:01 failed with error -16

This commit fixes this by making the rtc-cmos driver continue
without using an irq rather then claiming irq 8 when no irq is
specified in the pnp-info and there are no legacy-irqs.

Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/rtc/rtc-cmos.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)

--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -41,6 +41,9 @@
#include <linux/pm.h>
#include <linux/of.h>
#include <linux/of_platform.h>
+#ifdef CONFIG_X86
+#include <asm/i8259.h>
+#endif

/* this is for "generic access to PC-style RTC" using CMOS_READ/CMOS_WRITE */
#include <asm-generic/rtc.h>
@@ -1058,17 +1061,23 @@ static int cmos_pnp_probe(struct pnp_dev
{
cmos_wake_setup(&pnp->dev);

- if (pnp_port_start(pnp, 0) == 0x70 && !pnp_irq_valid(pnp, 0))
+ if (pnp_port_start(pnp, 0) == 0x70 && !pnp_irq_valid(pnp, 0)) {
+ unsigned int irq = 0;
+#ifdef CONFIG_X86
/* Some machines contain a PNP entry for the RTC, but
* don't define the IRQ. It should always be safe to
- * hardcode it in these cases
+ * hardcode it on systems with a legacy PIC.
*/
+ if (nr_legacy_irqs())
+ irq = 8;
+#endif
return cmos_do_probe(&pnp->dev,
- pnp_get_resource(pnp, IORESOURCE_IO, 0), 8);
- else
+ pnp_get_resource(pnp, IORESOURCE_IO, 0), irq);
+ } else {
return cmos_do_probe(&pnp->dev,
pnp_get_resource(pnp, IORESOURCE_IO, 0),
pnp_irq(pnp, 0));
+ }
}

static void __exit cmos_pnp_remove(struct pnp_dev *pnp)



2018-03-23 10:55:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 27/97] NFS: Fix missing pg_cleanup after nfs_pageio_cond_complete()

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Benjamin Coddington <[email protected]>


[ Upstream commit 43b7d964ed30dbca5c83c90cb010985b429ec4f9 ]

Commit a7d42ddb3099727f58366fa006f850a219cce6c8 ("nfs: add mirroring
support to pgio layer") moved pg_cleanup out of the path when there was
non-sequental I/O that needed to be flushed. The result is that for
layouts that have more than one layout segment per file, the pg_lseg is not
cleared, so we can end up hitting the WARN_ON_ONCE(req_start >= seg_end) in
pnfs_generic_pg_test since the pg_lseg will be pointing to that
previously-flushed layout segment.

Signed-off-by: Benjamin Coddington <[email protected]>
Fixes: a7d42ddb3099 ("nfs: add mirroring support to pgio layer")
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfs/pagelist.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/fs/nfs/pagelist.c
+++ b/fs/nfs/pagelist.c
@@ -1273,8 +1273,10 @@ void nfs_pageio_cond_complete(struct nfs
mirror = &desc->pg_mirrors[midx];
if (!list_empty(&mirror->pg_list)) {
prev = nfs_list_entry(mirror->pg_list.prev);
- if (index != prev->wb_index + 1)
- nfs_pageio_complete_mirror(desc, midx);
+ if (index != prev->wb_index + 1) {
+ nfs_pageio_complete(desc);
+ break;
+ }
}
}
}



2018-03-23 10:55:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 07/97] regulator: anatop: set default voltage selector for pcie

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Dong Aisheng <[email protected]>


[ Upstream commit 9bf944548169f6153c3d3778cf983cb5db251a0e ]

Set the initial voltage selector for vddpcie in case it's disabled
by default.

This fixes the below warning:
20c8000.anatop:regulator-vddpcie: Failed to read a valid default voltage selector.
anatop_regulator: probe of 20c8000.anatop:regulator-vddpcie failed with error -22

Cc: Liam Girdwood <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Shawn Guo <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: Robin Gong <[email protected]>
Cc: Richard Zhu <[email protected]>
Signed-off-by: Richard Zhu <[email protected]>
Signed-off-by: Dong Aisheng <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/regulator/anatop-regulator.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/regulator/anatop-regulator.c
+++ b/drivers/regulator/anatop-regulator.c
@@ -296,6 +296,11 @@ static int anatop_regulator_probe(struct
if (!sreg->sel && !strcmp(sreg->name, "vddpu"))
sreg->sel = 22;

+ /* set the default voltage of the pcie phy to be 1.100v */
+ if (!sreg->sel && rdesc->name &&
+ !strcmp(rdesc->name, "vddpcie"))
+ sreg->sel = 0x10;
+
if (!sreg->bypass && !sreg->sel) {
dev_err(&pdev->dev, "Failed to read a valid default voltage selector.\n");
return -EINVAL;



2018-03-23 10:55:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 05/97] staging: android: ashmem: Fix possible deadlock in ashmem_ioctl

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Yisheng Xie <[email protected]>

commit 740a5759bf222332fbb5eda42f89aa25ba38f9b2 upstream.

ashmem_mutex may create a chain of dependencies like:

CPU0 CPU1
mmap syscall ioctl syscall
-> mmap_sem (acquired) -> ashmem_ioctl
-> ashmem_mmap -> ashmem_mutex (acquired)
-> ashmem_mutex (try to acquire) -> copy_from_user
-> mmap_sem (try to acquire)

There is a lock odering problem between mmap_sem and ashmem_mutex causing
a lockdep splat[1] during a syzcaller test. This patch fixes the problem
by move copy_from_user out of ashmem_mutex.

[1] https://www.spinics.net/lists/kernel/msg2733200.html

Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin ioctls)
Reported-by: [email protected]
Signed-off-by: Yisheng Xie <[email protected]>
Cc: "Joel Fernandes (Google)" <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/android/ashmem.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)

--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -703,16 +703,14 @@ static int ashmem_pin_unpin(struct ashme
size_t pgstart, pgend;
int ret = -EINVAL;

+ if (unlikely(copy_from_user(&pin, p, sizeof(pin))))
+ return -EFAULT;
+
mutex_lock(&ashmem_mutex);

if (unlikely(!asma->file))
goto out_unlock;

- if (unlikely(copy_from_user(&pin, p, sizeof(pin)))) {
- ret = -EFAULT;
- goto out_unlock;
- }
-
/* per custom, you can pass zero for len to mean "everything onward" */
if (!pin.len)
pin.len = PAGE_ALIGN(asma->size) - pin.offset;



2018-03-23 10:55:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 06/97] platform/x86: asus-nb-wmi: Add wapf4 quirk for the X302UA

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Santeri Toivonen <[email protected]>


[ Upstream commit f35823619db8bbaa2afea8705f239c3cecb9d22f ]

Asus laptop X302UA starts up with Wi-Fi disabled,
without a way to enable it. Set wapf=4 to fix the problem.

Signed-off-by: Santeri Toivonen <[email protected]>
Signed-off-by: Darren Hart (VMware) <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/platform/x86/asus-nb-wmi.c | 9 +++++++++
1 file changed, 9 insertions(+)

--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -101,6 +101,15 @@ static const struct dmi_system_id asus_q
},
{
.callback = dmi_matched,
+ .ident = "ASUSTeK COMPUTER INC. X302UA",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X302UA"),
+ },
+ .driver_data = &quirk_asus_wapf4,
+ },
+ {
+ .callback = dmi_matched,
.ident = "ASUSTeK COMPUTER INC. X401U",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),



2018-03-23 10:55:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 04/97] CIFS: Enable encryption during session setup phase

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Pavel Shilovsky <[email protected]>

commit cabfb3680f78981d26c078a26e5c748531257ebb upstream.

In order to allow encryption on SMB connection we need to exchange
a session key and generate encryption and decryption keys.

Signed-off-by: Pavel Shilovsky <[email protected]>
Signed-off-by: Srivatsa S. Bhat <[email protected]>
Cc: Steve French <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/cifs/sess.c | 22 ++++++++++------------
fs/cifs/smb2pdu.c | 8 +-------
2 files changed, 11 insertions(+), 19 deletions(-)

--- a/fs/cifs/sess.c
+++ b/fs/cifs/sess.c
@@ -344,13 +344,12 @@ void build_ntlmssp_negotiate_blob(unsign
/* BB is NTLMV2 session security format easier to use here? */
flags = NTLMSSP_NEGOTIATE_56 | NTLMSSP_REQUEST_TARGET |
NTLMSSP_NEGOTIATE_128 | NTLMSSP_NEGOTIATE_UNICODE |
- NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC;
- if (ses->server->sign) {
+ NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC |
+ NTLMSSP_NEGOTIATE_SEAL;
+ if (ses->server->sign)
flags |= NTLMSSP_NEGOTIATE_SIGN;
- if (!ses->server->session_estab ||
- ses->ntlmssp->sesskey_per_smbsess)
- flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
- }
+ if (!ses->server->session_estab || ses->ntlmssp->sesskey_per_smbsess)
+ flags |= NTLMSSP_NEGOTIATE_KEY_XCH;

sec_blob->NegotiateFlags = cpu_to_le32(flags);

@@ -407,13 +406,12 @@ int build_ntlmssp_auth_blob(unsigned cha
flags = NTLMSSP_NEGOTIATE_56 |
NTLMSSP_REQUEST_TARGET | NTLMSSP_NEGOTIATE_TARGET_INFO |
NTLMSSP_NEGOTIATE_128 | NTLMSSP_NEGOTIATE_UNICODE |
- NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC;
- if (ses->server->sign) {
+ NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC |
+ NTLMSSP_NEGOTIATE_SEAL;
+ if (ses->server->sign)
flags |= NTLMSSP_NEGOTIATE_SIGN;
- if (!ses->server->session_estab ||
- ses->ntlmssp->sesskey_per_smbsess)
- flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
- }
+ if (!ses->server->session_estab || ses->ntlmssp->sesskey_per_smbsess)
+ flags |= NTLMSSP_NEGOTIATE_KEY_XCH;

tmp = *pbuffer + sizeof(AUTHENTICATE_MESSAGE);
sec_blob->NegotiateFlags = cpu_to_le32(flags);
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -832,10 +832,8 @@ ssetup_exit:

if (!rc) {
mutex_lock(&server->srv_mutex);
- if (server->sign && server->ops->generate_signingkey) {
+ if (server->ops->generate_signingkey) {
rc = server->ops->generate_signingkey(ses);
- kfree(ses->auth_key.response);
- ses->auth_key.response = NULL;
if (rc) {
cifs_dbg(FYI,
"SMB3 session key generation failed\n");
@@ -857,10 +855,6 @@ ssetup_exit:
}

keygen_exit:
- if (!server->sign) {
- kfree(ses->auth_key.response);
- ses->auth_key.response = NULL;
- }
if (spnego_key) {
key_invalidate(spnego_key);
key_put(spnego_key);



2018-03-23 10:55:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 08/97] x86: i8259: export legacy_pic symbol

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Hans de Goede <[email protected]>


[ Upstream commit 7ee06cb2f840a96be46233181ed4557901a74385 ]

The classic PC rtc-coms driver has a workaround for broken ACPI device
nodes for it which lack an irq resource. This workaround used to
unconditionally hardcode the irq to 8 in these cases.

This was causing irq conflict problems on systems without a legacy-pic
so a recent patch added an if (nr_legacy_irqs()) guard to the
workaround to avoid this irq conflict.

nr_legacy_irqs() uses the legacy_pic symbol under the hood causing
an undefined symbol error if the rtc-cmos code is build as a module.

This commit exports the legacy_pic symbol to fix this.

Cc: [email protected]
Cc: [email protected]
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/i8259.c | 1 +
1 file changed, 1 insertion(+)

--- a/arch/x86/kernel/i8259.c
+++ b/arch/x86/kernel/i8259.c
@@ -418,6 +418,7 @@ struct legacy_pic default_legacy_pic = {
};

struct legacy_pic *legacy_pic = &default_legacy_pic;
+EXPORT_SYMBOL(legacy_pic);

static int __init i8259A_init_ops(void)
{



2018-03-23 10:56:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 02/97] tpm_tis: fix potential buffer overruns caused by bit glitches on the bus

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Jeremy Boone <[email protected]>

commit 6bb320ca4a4a7b5b3db8c8d7250cc40002046878 upstream.

Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips. In all the
driver _recv() functions, we need to use a u32 to unmarshal the
response size, otherwise a bit flip of the 31st bit would cause the
expected variable to go negative, which would then try to read a huge
amount of data. Also sanity check that the expected amount of data is
large enough for the TPM header.

Signed-off-by: Jeremy Boone <[email protected]>
Cc: [email protected]
Signed-off-by: James Bottomley <[email protected]>
Tested-by: Jarkko Sakkinen <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Signed-off-by: Jarkko Sakkinen <[email protected]>
Signed-off-by: James Morris <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/char/tpm/tpm_tis.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -283,7 +283,8 @@ static int recv_data(struct tpm_chip *ch
static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, size_t count)
{
int size = 0;
- int expected, status;
+ int status;
+ u32 expected;

if (count < TPM_HEADER_SIZE) {
size = -EIO;
@@ -298,7 +299,7 @@ static int tpm_tis_recv(struct tpm_chip
}

expected = be32_to_cpu(*(__be32 *) (buf + 2));
- if (expected > count) {
+ if (expected > count || expected < TPM_HEADER_SIZE) {
size = -EIO;
goto out;
}



2018-03-23 10:56:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 03/97] SMB3: Validate negotiate request must always be signed

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Steve French <[email protected]>

commit 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd upstream.

According to MS-SMB2 3.2.55 validate_negotiate request must
always be signed. Some Windows can fail the request if you send it unsigned

See kernel bugzilla bug 197311

CC: Stable <[email protected]>
Acked-by: Ronnie Sahlberg <lsahlber.redhat.com>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Srivatsa S. Bhat <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/cifs/smb2pdu.c | 3 +++
1 file changed, 3 insertions(+)

--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1558,6 +1558,9 @@ SMB2_ioctl(const unsigned int xid, struc
} else
iov[0].iov_len = get_rfc1002_length(req) + 4;

+ /* validate negotiate request must be signed - see MS-SMB2 3.2.5.5 */
+ if (opcode == FSCTL_VALIDATE_NEGOTIATE_INFO)
+ req->hdr.Flags |= SMB2_FLAGS_SIGNED;

rc = SendReceive2(xid, ses, iov, num_iovecs, &resp_buftype, 0);
rsp = (struct smb2_ioctl_rsp *)iov[0].iov_base;



2018-03-23 10:56:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 15/97] genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Hans de Goede <[email protected]>


[ Upstream commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 ]

When requesting a shared irq with IRQF_TRIGGER_NONE then the irqaction
flags get filled with the trigger type from the irq_data:

if (!(new->flags & IRQF_TRIGGER_MASK))
new->flags |= irqd_get_trigger_type(&desc->irq_data);

On the first setup_irq() the trigger type in irq_data is NONE when the
above code executes, then the irq is started up for the first time and
then the actual trigger type gets established, but that's too late to fix
up new->flags.

When then a second user of the irq requests the irq with IRQF_TRIGGER_NONE
its irqaction's triggertype gets set to the actual trigger type and the
following check fails:

if (!((old->flags ^ new->flags) & IRQF_TRIGGER_MASK))

Resulting in the request_irq failing with -EBUSY even though both
users requested the irq with IRQF_SHARED | IRQF_TRIGGER_NONE

Fix this by comparing the new irqaction's trigger type to the trigger type
stored in the irq_data which correctly reflects the actual trigger type
being used for the irq.

Suggested-by: Thomas Gleixner <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Acked-by: Marc Zyngier <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/irq/manage.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1189,8 +1189,10 @@ __setup_irq(unsigned int irq, struct irq
* set the trigger type must match. Also all must
* agree on ONESHOT.
*/
+ unsigned int oldtype = irqd_get_trigger_type(&desc->irq_data);
+
if (!((old->flags & new->flags) & IRQF_SHARED) ||
- ((old->flags ^ new->flags) & IRQF_TRIGGER_MASK) ||
+ (oldtype != (new->flags & IRQF_TRIGGER_MASK)) ||
((old->flags ^ new->flags) & IRQF_ONESHOT))
goto mismatch;




2018-03-23 10:56:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 13/97] ACPI/processor: Replace racy task affinity logic

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Thomas Gleixner <[email protected]>


[ Upstream commit 8153f9ac43897f9f4786b30badc134fcc1a4fb11 ]

acpi_processor_get_throttling() requires to invoke the getter function on
the target CPU. This is achieved by temporarily setting the affinity of the
calling user space thread to the requested CPU and reset it to the original
affinity afterwards.

That's racy vs. CPU hotplug and concurrent affinity settings for that
thread resulting in code executing on the wrong CPU and overwriting the
new affinity setting.

acpi_processor_get_throttling() is invoked in two ways:

1) The CPU online callback, which is already running on the target CPU and
obviously protected against hotplug and not affected by affinity
settings.

2) The ACPI driver probe function, which is not protected against hotplug
during modprobe.

Switch it over to work_on_cpu() and protect the probe function against CPU
hotplug.

Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Fenghua Yu <[email protected]>
Cc: Tony Luck <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Sebastian Siewior <[email protected]>
Cc: Lai Jiangshan <[email protected]>
Cc: [email protected]
Cc: Viresh Kumar <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Tejun Heo <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Len Brown <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/acpi/processor_driver.c | 7 +++-
drivers/acpi/processor_throttling.c | 62 ++++++++++++++++++++----------------
2 files changed, 42 insertions(+), 27 deletions(-)

--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -270,11 +270,16 @@ err_power_exit:
static int acpi_processor_start(struct device *dev)
{
struct acpi_device *device = ACPI_COMPANION(dev);
+ int ret;

if (!device)
return -ENODEV;

- return __acpi_processor_start(device);
+ /* Protect against concurrent CPU hotplug operations */
+ get_online_cpus();
+ ret = __acpi_processor_start(device);
+ put_online_cpus();
+ return ret;
}

static int acpi_processor_stop(struct device *dev)
--- a/drivers/acpi/processor_throttling.c
+++ b/drivers/acpi/processor_throttling.c
@@ -62,8 +62,8 @@ struct acpi_processor_throttling_arg {
#define THROTTLING_POSTCHANGE (2)

static int acpi_processor_get_throttling(struct acpi_processor *pr);
-int acpi_processor_set_throttling(struct acpi_processor *pr,
- int state, bool force);
+static int __acpi_processor_set_throttling(struct acpi_processor *pr,
+ int state, bool force, bool direct);

static int acpi_processor_update_tsd_coord(void)
{
@@ -891,7 +891,8 @@ static int acpi_processor_get_throttling
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Invalid throttling state, reset\n"));
state = 0;
- ret = acpi_processor_set_throttling(pr, state, true);
+ ret = __acpi_processor_set_throttling(pr, state, true,
+ true);
if (ret)
return ret;
}
@@ -901,36 +902,31 @@ static int acpi_processor_get_throttling
return 0;
}

-static int acpi_processor_get_throttling(struct acpi_processor *pr)
+static long __acpi_processor_get_throttling(void *data)
{
- cpumask_var_t saved_mask;
- int ret;
+ struct acpi_processor *pr = data;
+
+ return pr->throttling.acpi_processor_get_throttling(pr);
+}

+static int acpi_processor_get_throttling(struct acpi_processor *pr)
+{
if (!pr)
return -EINVAL;

if (!pr->flags.throttling)
return -ENODEV;

- if (!alloc_cpumask_var(&saved_mask, GFP_KERNEL))
- return -ENOMEM;
-
/*
- * Migrate task to the cpu pointed by pr.
+ * This is either called from the CPU hotplug callback of
+ * processor_driver or via the ACPI probe function. In the latter
+ * case the CPU is not guaranteed to be online. Both call sites are
+ * protected against CPU hotplug.
*/
- cpumask_copy(saved_mask, &current->cpus_allowed);
- /* FIXME: use work_on_cpu() */
- if (set_cpus_allowed_ptr(current, cpumask_of(pr->id))) {
- /* Can't migrate to the target pr->id CPU. Exit */
- free_cpumask_var(saved_mask);
+ if (!cpu_online(pr->id))
return -ENODEV;
- }
- ret = pr->throttling.acpi_processor_get_throttling(pr);
- /* restore the previous state */
- set_cpus_allowed_ptr(current, saved_mask);
- free_cpumask_var(saved_mask);

- return ret;
+ return work_on_cpu(pr->id, __acpi_processor_get_throttling, pr);
}

static int acpi_processor_get_fadt_info(struct acpi_processor *pr)
@@ -1080,8 +1076,15 @@ static long acpi_processor_throttling_fn
arg->target_state, arg->force);
}

-int acpi_processor_set_throttling(struct acpi_processor *pr,
- int state, bool force)
+static int call_on_cpu(int cpu, long (*fn)(void *), void *arg, bool direct)
+{
+ if (direct)
+ return fn(arg);
+ return work_on_cpu(cpu, fn, arg);
+}
+
+static int __acpi_processor_set_throttling(struct acpi_processor *pr,
+ int state, bool force, bool direct)
{
int ret = 0;
unsigned int i;
@@ -1130,7 +1133,8 @@ int acpi_processor_set_throttling(struct
arg.pr = pr;
arg.target_state = state;
arg.force = force;
- ret = work_on_cpu(pr->id, acpi_processor_throttling_fn, &arg);
+ ret = call_on_cpu(pr->id, acpi_processor_throttling_fn, &arg,
+ direct);
} else {
/*
* When the T-state coordination is SW_ALL or HW_ALL,
@@ -1163,8 +1167,8 @@ int acpi_processor_set_throttling(struct
arg.pr = match_pr;
arg.target_state = state;
arg.force = force;
- ret = work_on_cpu(pr->id, acpi_processor_throttling_fn,
- &arg);
+ ret = call_on_cpu(pr->id, acpi_processor_throttling_fn,
+ &arg, direct);
}
}
/*
@@ -1182,6 +1186,12 @@ int acpi_processor_set_throttling(struct
return ret;
}

+int acpi_processor_set_throttling(struct acpi_processor *pr, int state,
+ bool force)
+{
+ return __acpi_processor_set_throttling(pr, state, force, false);
+}
+
int acpi_processor_get_throttling_info(struct acpi_processor *pr)
{
int result = 0;



2018-03-23 10:57:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 12/97] ACPI/processor: Fix error handling in __acpi_processor_start()

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Thomas Gleixner <[email protected]>


[ Upstream commit a5cbdf693a60d5b86d4d21dfedd90f17754eb273 ]

When acpi_install_notify_handler() fails the cooling device stays
registered and the sysfs files created via acpi_pss_perf_init() are
leaked and the function returns success.

Undo acpi_pss_perf_init() and return a proper error code.

Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Fenghua Yu <[email protected]>
Cc: Tony Luck <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Sebastian Siewior <[email protected]>
Cc: Lai Jiangshan <[email protected]>
Cc: [email protected]
Cc: Viresh Kumar <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Tejun Heo <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Len Brown <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/acpi/processor_driver.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -259,6 +259,9 @@ static int __acpi_processor_start(struct
if (ACPI_SUCCESS(status))
return 0;

+ result = -ENODEV;
+ acpi_pss_perf_exit(pr, device);
+
err_power_exit:
acpi_processor_power_exit(pr);
return result;



2018-03-23 10:57:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 10/97] Input: ar1021_i2c - fix too long name in drivers device table

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Dmitry Torokhov <[email protected]>


[ Upstream commit 95123fc43560d6f4a60e74f72836e63cd8848f76 ]

The name field in structure i2c_device_id is 20 characters, and we expect
it to be NULL-terminated, however we are trying to stuff it with 21 bytes
and thus NULL-terminator is lost. This causes issues when one creates
device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the last "C",
and automatic module loading by alias does not work as result.

The -I2C suffix in the device name is superfluous, we know what bus we are
dealing with, so let's drop it. Also, no other driver uses capitals, and
the manufacturer name is normally not included, except in very rare cases
of incompatible name collisions.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211
Fixes: dd4cae8bf166 ("Input: Add Microchip AR1021 i2c touchscreen")
Reviewed-By: Christian Gmeiner <[email protected]>
Tested-by: Martin Kepplinger <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/input/touchscreen/ar1021_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/input/touchscreen/ar1021_i2c.c
+++ b/drivers/input/touchscreen/ar1021_i2c.c
@@ -152,7 +152,7 @@ static int __maybe_unused ar1021_i2c_res
static SIMPLE_DEV_PM_OPS(ar1021_i2c_pm, ar1021_i2c_suspend, ar1021_i2c_resume);

static const struct i2c_device_id ar1021_i2c_id[] = {
- { "MICROCHIP_AR1021_I2C", 0 },
+ { "ar1021", 0 },
{ },
};
MODULE_DEVICE_TABLE(i2c, ar1021_i2c_id);



2018-03-23 10:57:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 11/97] time: Change posix clocks ops interfaces to use timespec64

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Deepa Dinamani <[email protected]>


[ Upstream commit d340266e19ddb70dbd608f9deedcfb35fdb9d419 ]

struct timespec is not y2038 safe on 32 bit machines.

The posix clocks apis use struct timespec directly and through struct
itimerspec.

Replace the posix clock interfaces to use struct timespec64 and struct
itimerspec64 instead. Also fix up their implementations accordingly.

Note that the clock_getres() interface has also been changed to use
timespec64 even though this particular interface is not affected by the
y2038 problem. This helps verification for internal kernel code for y2038
readiness by getting rid of time_t/ timeval/ timespec.

Signed-off-by: Deepa Dinamani <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Richard Cochran <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/ptp/ptp_clock.c | 18 +++++++-----------
include/linux/posix-clock.h | 10 +++++-----
kernel/time/posix-clock.c | 34 ++++++++++++++++++++++++----------
3 files changed, 36 insertions(+), 26 deletions(-)

--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -97,30 +97,26 @@ static s32 scaled_ppm_to_ppb(long ppm)

/* posix clock implementation */

-static int ptp_clock_getres(struct posix_clock *pc, struct timespec *tp)
+static int ptp_clock_getres(struct posix_clock *pc, struct timespec64 *tp)
{
tp->tv_sec = 0;
tp->tv_nsec = 1;
return 0;
}

-static int ptp_clock_settime(struct posix_clock *pc, const struct timespec *tp)
+static int ptp_clock_settime(struct posix_clock *pc, const struct timespec64 *tp)
{
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
- struct timespec64 ts = timespec_to_timespec64(*tp);

- return ptp->info->settime64(ptp->info, &ts);
+ return ptp->info->settime64(ptp->info, tp);
}

-static int ptp_clock_gettime(struct posix_clock *pc, struct timespec *tp)
+static int ptp_clock_gettime(struct posix_clock *pc, struct timespec64 *tp)
{
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
- struct timespec64 ts;
int err;

- err = ptp->info->gettime64(ptp->info, &ts);
- if (!err)
- *tp = timespec64_to_timespec(ts);
+ err = ptp->info->gettime64(ptp->info, tp);
return err;
}

@@ -133,7 +129,7 @@ static int ptp_clock_adjtime(struct posi
ops = ptp->info;

if (tx->modes & ADJ_SETOFFSET) {
- struct timespec ts;
+ struct timespec64 ts;
ktime_t kt;
s64 delta;

@@ -146,7 +142,7 @@ static int ptp_clock_adjtime(struct posi
if ((unsigned long) ts.tv_nsec >= NSEC_PER_SEC)
return -EINVAL;

- kt = timespec_to_ktime(ts);
+ kt = timespec64_to_ktime(ts);
delta = ktime_to_ns(kt);
err = ops->adjtime(ops, delta);
} else if (tx->modes & ADJ_FREQUENCY) {
--- a/include/linux/posix-clock.h
+++ b/include/linux/posix-clock.h
@@ -59,23 +59,23 @@ struct posix_clock_operations {

int (*clock_adjtime)(struct posix_clock *pc, struct timex *tx);

- int (*clock_gettime)(struct posix_clock *pc, struct timespec *ts);
+ int (*clock_gettime)(struct posix_clock *pc, struct timespec64 *ts);

- int (*clock_getres) (struct posix_clock *pc, struct timespec *ts);
+ int (*clock_getres) (struct posix_clock *pc, struct timespec64 *ts);

int (*clock_settime)(struct posix_clock *pc,
- const struct timespec *ts);
+ const struct timespec64 *ts);

int (*timer_create) (struct posix_clock *pc, struct k_itimer *kit);

int (*timer_delete) (struct posix_clock *pc, struct k_itimer *kit);

void (*timer_gettime)(struct posix_clock *pc,
- struct k_itimer *kit, struct itimerspec *tsp);
+ struct k_itimer *kit, struct itimerspec64 *tsp);

int (*timer_settime)(struct posix_clock *pc,
struct k_itimer *kit, int flags,
- struct itimerspec *tsp, struct itimerspec *old);
+ struct itimerspec64 *tsp, struct itimerspec64 *old);
/*
* Optional character device methods:
*/
--- a/kernel/time/posix-clock.c
+++ b/kernel/time/posix-clock.c
@@ -300,14 +300,17 @@ out:
static int pc_clock_gettime(clockid_t id, struct timespec *ts)
{
struct posix_clock_desc cd;
+ struct timespec64 ts64;
int err;

err = get_clock_desc(id, &cd);
if (err)
return err;

- if (cd.clk->ops.clock_gettime)
- err = cd.clk->ops.clock_gettime(cd.clk, ts);
+ if (cd.clk->ops.clock_gettime) {
+ err = cd.clk->ops.clock_gettime(cd.clk, &ts64);
+ *ts = timespec64_to_timespec(ts64);
+ }
else
err = -EOPNOTSUPP;

@@ -319,14 +322,17 @@ static int pc_clock_gettime(clockid_t id
static int pc_clock_getres(clockid_t id, struct timespec *ts)
{
struct posix_clock_desc cd;
+ struct timespec64 ts64;
int err;

err = get_clock_desc(id, &cd);
if (err)
return err;

- if (cd.clk->ops.clock_getres)
- err = cd.clk->ops.clock_getres(cd.clk, ts);
+ if (cd.clk->ops.clock_getres) {
+ err = cd.clk->ops.clock_getres(cd.clk, &ts64);
+ *ts = timespec64_to_timespec(ts64);
+ }
else
err = -EOPNOTSUPP;

@@ -337,6 +343,7 @@ static int pc_clock_getres(clockid_t id,

static int pc_clock_settime(clockid_t id, const struct timespec *ts)
{
+ struct timespec64 ts64 = timespec_to_timespec64(*ts);
struct posix_clock_desc cd;
int err;

@@ -350,7 +357,7 @@ static int pc_clock_settime(clockid_t id
}

if (cd.clk->ops.clock_settime)
- err = cd.clk->ops.clock_settime(cd.clk, ts);
+ err = cd.clk->ops.clock_settime(cd.clk, &ts64);
else
err = -EOPNOTSUPP;
out:
@@ -403,29 +410,36 @@ static void pc_timer_gettime(struct k_it
{
clockid_t id = kit->it_clock;
struct posix_clock_desc cd;
+ struct itimerspec64 ts64;

if (get_clock_desc(id, &cd))
return;

- if (cd.clk->ops.timer_gettime)
- cd.clk->ops.timer_gettime(cd.clk, kit, ts);
-
+ if (cd.clk->ops.timer_gettime) {
+ cd.clk->ops.timer_gettime(cd.clk, kit, &ts64);
+ *ts = itimerspec64_to_itimerspec(&ts64);
+ }
put_clock_desc(&cd);
}

static int pc_timer_settime(struct k_itimer *kit, int flags,
struct itimerspec *ts, struct itimerspec *old)
{
+ struct itimerspec64 ts64 = itimerspec_to_itimerspec64(ts);
clockid_t id = kit->it_clock;
struct posix_clock_desc cd;
+ struct itimerspec64 old64;
int err;

err = get_clock_desc(id, &cd);
if (err)
return err;

- if (cd.clk->ops.timer_settime)
- err = cd.clk->ops.timer_settime(cd.clk, kit, flags, ts, old);
+ if (cd.clk->ops.timer_settime) {
+ err = cd.clk->ops.timer_settime(cd.clk, kit, flags, &ts64, &old64);
+ if (old)
+ *old = itimerspec64_to_itimerspec(&old64);
+ }
else
err = -EOPNOTSUPP;




2018-03-23 14:34:32

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/97] 4.4.124-stable review

On 23 March 2018 at 15:23, Greg Kroah-Hartman
<[email protected]> wrote:
> This is the start of the stable review cycle for the 4.4.124 release.
> There are 97 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 Sun Mar 25 09:41:34 UTC 2018.
> 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/v4.x/stable-review/patch-4.4.124-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-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

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

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

kernel: 4.4.124-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 665508dd74d9b8c63dd59475827d439c62e81df2
git describe: v4.4.123-98-g665508dd74d9
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.123-98-g665508dd74d9


No regressions (compared to build v4.4.123-97-g3054df73e9af)

Boards, architectures and test suites:
-------------------------------------

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 29, pass: 34
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 53, pass: 28
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 152, pass: 998
* ltp-timers-tests - skip: 1, pass: 12

qemu_x86_64
* boot - pass: 22
* kselftest - skip: 33, pass: 47
* kselftest-vsyscall-mode-native - skip: 33, pass: 47
* kselftest-vsyscall-mode-none - skip: 33, pass: 47
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 150, pass: 1000
* ltp-timers-tests - skip: 1, pass: 12

x15 - arm
* boot - pass: 20
* kselftest - skip: 29, pass: 33
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 2, pass: 20
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 98, pass: 1052
* ltp-timers-tests - skip: 1, pass: 12

x86_64
* boot - pass: 22
* kselftest - skip: 31, fail: 1, pass: 48
* kselftest-vsyscall-mode-native - skip: 31, fail: 1, pass: 48
* kselftest-vsyscall-mode-none - skip: 31, fail: 2, pass: 46
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 62
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 5, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 120, pass: 1030
* ltp-timers-tests - skip: 1, pass: 12

Hikey test results,

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

kernel: 4.4.124-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.124-rc1-hikey-20180322-156
git commit: 65a47c692aa0c3b23f55fe0ef2e6e594d9ea8680
git describe: 4.4.124-rc1-hikey-20180322-156
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.124-rc1-hikey-20180322-156


No regressions (compared to build 4.4.123-rc3-hikey-20180321-154)

Boards, architectures and test suites:
-------------------------------------

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 32, pass: 30
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 53, pass: 28
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 154, pass: 996
* ltp-timers-tests - skip: 1, pass: 12

--
Linaro QA (beta)
https://qa-reports.linaro.org

2018-03-23 15:05:00

by Nathan Chancellor

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/97] 4.4.124-stable review

On Fri, Mar 23, 2018 at 10:53:47AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.124 release.
> There are 97 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 Sun Mar 25 09:41:34 UTC 2018.
> 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/v4.x/stable-review/patch-4.4.124-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-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5.

Couple small conflicts from Qualcomm's changes but nothing major, I'm
sure kernel/common will have none.

No initial issues in general usage or dmesg.

Thanks!
Nathan

2018-03-23 16:51:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/97] 4.4.124-stable review

On Fri, Mar 23, 2018 at 08:01:41AM -0700, Nathan Chancellor wrote:
> On Fri, Mar 23, 2018 at 10:53:47AM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.124 release.
> > There are 97 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 Sun Mar 25 09:41:34 UTC 2018.
> > 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/v4.x/stable-review/patch-4.4.124-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-4.4.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5.
>
> Couple small conflicts from Qualcomm's changes but nothing major, I'm
> sure kernel/common will have none.
>
> No initial issues in general usage or dmesg.

Great, thanks for testing and letting me know.

greg k-h

2018-03-23 20:49:10

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/97] 4.4.124-stable review

On 03/23/2018 03:53 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.124 release.
> There are 97 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 Sun Mar 25 09:41:34 UTC 2018.
> 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/v4.x/stable-review/patch-4.4.124-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-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

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

thanks,
-- Shuah

2018-03-24 00:10:16

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.4 00/97] 4.4.124-stable review

On 03/23/2018 02:53 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.124 release.
> There are 97 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 Sun Mar 25 09:41:34 UTC 2018.
> Anything received after that time might be too late.
>

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 127 pass: 127 fail: 0

Guenter

2018-04-03 14:18:54

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 15/97] genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs

On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Hans de Goede <[email protected]>
>
>
> [ Upstream commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 ]
>
> When requesting a shared irq with IRQF_TRIGGER_NONE then the irqaction
> flags get filled with the trigger type from the irq_data:
>
>         if (!(new->flags & IRQF_TRIGGER_MASK))
>                 new->flags |= irqd_get_trigger_type(&desc->irq_data);

The code above was added to __setup_irq() in 4.8, so I don't think this
fix is needed in 3.18 or 4.4; and I suspect it might cause a regression
there.

Ben.

> On the first setup_irq() the trigger type in irq_data is NONE when the
> above code executes, then the irq is started up for the first time and
> then the actual trigger type gets established, but that's too late to fix
> up new->flags.
>
> When then a second user of the irq requests the irq with IRQF_TRIGGER_NONE
> its irqaction's triggertype gets set to the actual trigger type and the
> following check fails:
>
>         if (!((old->flags ^ new->flags) & IRQF_TRIGGER_MASK))
>
> Resulting in the request_irq failing with -EBUSY even though both
> users requested the irq with IRQF_SHARED | IRQF_TRIGGER_NONE
>
> Fix this by comparing the new irqaction's trigger type to the trigger type
> stored in the irq_data which correctly reflects the actual trigger type
> being used for the irq.
>
> Suggested-by: Thomas Gleixner <[email protected]>
> Signed-off-by: Hans de Goede <[email protected]>
> Acked-by: Marc Zyngier <[email protected]>
> Link: http://lkml.kernel.org/r/[email protected]
> Signed-off-by: Thomas Gleixner <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
>  kernel/irq/manage.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -1189,8 +1189,10 @@ __setup_irq(unsigned int irq, struct irq
>    * set the trigger type must match. Also all must
>    * agree on ONESHOT.
>    */
> + unsigned int oldtype = irqd_get_trigger_type(&desc->irq_data);
> +
>   if (!((old->flags & new->flags) & IRQF_SHARED) ||
> -     ((old->flags ^ new->flags) & IRQF_TRIGGER_MASK) ||
> +     (oldtype != (new->flags & IRQF_TRIGGER_MASK)) ||
>       ((old->flags ^ new->flags) & IRQF_ONESHOT))
>   goto mismatch;
>  

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-03 14:55:39

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 22/97] scsi: virtio_scsi: Always try to read VPD pages

On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: David Gibson <[email protected]>
>
>
> [ Upstream commit 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0 ]
[...]

This is an incomplete fix as it only touches the single-queue host
template. The other part is:

commit a680f1d463aeaeb00d22af257a56e111967c2f18
Author: Paolo Bonzini <[email protected]>
Date:   Wed Jul 5 10:30:56 2017 +0200

    scsi: virtio_scsi: always read VPD pages for multiqueue too

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-03 17:40:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 22/97] scsi: virtio_scsi: Always try to read VPD pages

On Tue, Apr 03, 2018 at 03:54:08PM +0100, Ben Hutchings wrote:
> On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: David Gibson <[email protected]>
> >
> >
> > [ Upstream commit 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0 ]
> [...]
>
> This is an incomplete fix as it only touches the single-queue host
> template. The other part is:
>
> commit a680f1d463aeaeb00d22af257a56e111967c2f18
> Author: Paolo Bonzini <[email protected]>
> Date:???Wed Jul 5 10:30:56 2017 +0200
>
> ????scsi: virtio_scsi: always read VPD pages for multiqueue too

Thanks, now queued up.

greg k-h

2018-04-03 17:47:34

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 38/97] netfilter: xt_CT: fix refcnt leak on error path

On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Gao Feng <[email protected]>
>
>
> [ Upstream commit 470acf55a021713869b9bcc967268ac90c8a0fac ]
[...]
> --- a/net/netfilter/xt_CT.c
> +++ b/net/netfilter/xt_CT.c
> @@ -168,8 +168,10 @@ xt_ct_set_timeout(struct nf_conn *ct, co
>   goto err_put_timeout;
>   }
>   timeout_ext = nf_ct_timeout_ext_add(ct, timeout, GFP_ATOMIC);
> - if (timeout_ext == NULL)
> + if (!timeout_ext) {
>   ret = -ENOMEM;
> + goto err_put_timeout;
> + }
>  
>   rcu_read_unlock();
>   return ret;

This part looks fine.

> @@ -201,6 +203,7 @@ static int xt_ct_tg_check(const struct x
> >     struct xt_ct_target_info_v1 *info)
>  {
>   struct nf_conntrack_zone zone;
> + struct nf_conn_help *help;
>   struct nf_conn *ct;
>   int ret = -EOPNOTSUPP;
>  
> @@ -249,7 +252,7 @@ static int xt_ct_tg_check(const struct x
>   if (info->timeout[0]) {
>   ret = xt_ct_set_timeout(ct, par, info->timeout);
>   if (ret < 0)
> - goto err3;
> + goto err4;
>   }
>   __set_bit(IPS_CONFIRMED_BIT, &ct->status);
>   nf_conntrack_get(&ct->ct_general);
> @@ -257,6 +260,10 @@ out:
>   info->ct = ct;
>   return 0;
>  
> +err4:
> + help = nfct_help(ct);
> + if (help)
> + module_put(help->helper->me);
>  err3:
>   nf_ct_tmpl_free(ct);
>  err2:

This does not. nf_ct_tmpl_free() calls nf_ct_ext_destroy() which I
think will call back into xt_ct_tg_destroy(). So I think the module
reference is already dropped here and we mustn't do it twice. Am I
missing something?

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-03 20:50:40

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 51/97] mfd: palmas: Reset the POWERHOLD mux during power off

On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Keerthy <[email protected]>
>
>
> [ Upstream commit 85fdaf8eb9bbec1f0f8a52fd5d85659d60738816 ]
>
> POWERHOLD signal has higher priority  over the DEV_ON bit.
> So power off will not happen if the POWERHOLD is held high.
> Hence reset the MUX to GPIO_7 mode to release the POWERHOLD
> and the DEV_ON bit to take effect to power off the PMIC.
>
> PMIC Power off happens in dire situations like thermal shutdown
> so irrespective of the POWERHOLD setting go ahead and turn off
> the powerhold.  Currently poweroff is broken on boards that have
> powerhold enabled. This fixes poweroff on those boards.
[...]

This is not very useful by itself; I think you should pick these too:

[3.18]
0ea66f76ba17 Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition
7c62de5f3fc9 ARM: dts: dra7: Add power hold and power controller properties to palmas

[4.4]
0ea66f76ba17 Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition
1f166499ce00 ARM: dts: am57xx-beagle-x15-common: Add overide powerhold property
- apply the changes in am57xx-beagle-x15.dts
7c62de5f3fc9 ARM: dts: dra7: Add power hold and power controller properties to palmas

[4.9]
0ea66f76ba17 Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition
1f166499ce00 ARM: dts: am57xx-beagle-x15-common: Add overide powerhold property
8804755bfb1f ARM: dts: am57xx-idk-common: Add overide powerhold
property
7c62de5f3fc9 ARM: dts: dra7: Add power hold and power controller properties to palmas

None of the above are needed for 4.14 and 4.15, but they do have one
more board that needed this property, so please pick this:

aac4619d028e ARM: dts: DRA76-EVM: Set powerhold property for tps65917

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-03 21:03:52

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 52/97] mtip32xx: use runtime tag to initialize command header

On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Ming Lei <[email protected]>
>
>
> [ Upstream commit a4e84aae8139aca9fbfbced1f45c51ca81b57488 ]
>
> mtip32xx supposes that 'request_idx' passed to .init_request()
> is tag of the request, and use that as request's tag to initialize
> command header.
>
> After MQ IO scheduler is in, request tag assigned isn't same with
> the request index anymore, so cause strange hardware failure on
> mtip32xx, even whole system panic is triggered.
[...]

MQ IO schedulers were introduced in 4.11, so this shouldn't be needed
in older branches. It also causes a performance regression (fixed
upstream). Please revert this for 4.4 and 4.9.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-03 21:35:01

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 63/97] md/raid10: skip spare disk as first disk

On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Shaohua Li <[email protected]>
>
>
> [ Upstream commit b506335e5d2b4ec687dde392a3bdbf7601778f1d ]
>
> Commit 6f287ca(md/raid10: reset the 'first' at the end of loop) ignores
> a case in reshape, the first rdev could be a spare disk, which shouldn't
> be accounted as the first disk since it doesn't include the offset info.
>
> Fix: 6f287ca(md/raid10: reset the 'first' at the end of loop)

But that commit hasn't been applied to 4.4-stable. It probably should
be, since it fixes another instance of the problem in the run()
function. Take care not to add the wrongly placed assignment
in raid10_start_reshape().

Ben.

> Cc: Guoqing Jiang <[email protected]>
> Cc: NeilBrown <[email protected]>
> Signed-off-by: Shaohua Li <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
>  drivers/md/raid10.c |    1 +
>  1 file changed, 1 insertion(+)
>
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -4044,6 +4044,7 @@ static int raid10_start_reshape(struct m
>   diff = 0;
>   if (first || diff < min_offset_diff)
>   min_offset_diff = diff;
> + first = 0;
>   }
>   }
>  

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-03 21:42:36

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 68/97] net: hns: fix ethtool_get_strings overflow in hns driver

On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Timmy Li <[email protected]>
>
>
> [ Upstream commit 412b65d15a7f8a93794653968308fc100f2aa87c ]
[...]

This is not a correct fix; please also apply:

commit d61d263c8d82db7c4404a29ebc29674b1c0c05c9
Author: Matthias Brugger <[email protected]>
Date:   Thu Mar 15 17:54:20 2018 +0100

    net: hns: Fix ethtool private flags

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-03 21:47:59

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 70/97] rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt ticks

On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Moritz Fischer <[email protected]>
>
>
> [ Upstream commit 453d0744f6c6ca3f9749b8c57c2e85b5b9f52514 ]
>
> The issue is that the internal counter that triggers the watchdog reset
> is actually running at 4096 Hz instead of 1Hz, therefore the value
> given by userland (in sec) needs to be multiplied by 4096 to get the
> correct behavior.
[...]

The wdt_margin module parameter has the same problem.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-04 00:10:58

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 92/97] ip6_vti: adjust vti mtu according to mtu of lower device

On Fri, 2018-03-23 at 10:55 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Alexey Kodanev <[email protected]>
>
>
> [ Upstream commit 53c81e95df1793933f87748d36070a721f6cb287 ]
[...]

There are a couple of follow-ups to this:

c6741fbed6dc vti6: Properly adjust vti6 MTU from MTU of lower device
7a67e69a339a vti6: Keep set MTU on link creation or change, validate it

The second of those will fail to build on branches older than 4.10
though. It might be better to revert this one instead.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-05 15:38:59

by Stefano Brivio

[permalink] [raw]
Subject: Re: [PATCH 4.4 92/97] ip6_vti: adjust vti mtu according to mtu of lower device

On Wed, 04 Apr 2018 01:09:16 +0100
Ben Hutchings <[email protected]> wrote:

> On Fri, 2018-03-23 at 10:55 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Alexey Kodanev <[email protected]>
> >
> >
> > [ Upstream commit 53c81e95df1793933f87748d36070a721f6cb287 ]
> [...]
>
> There are a couple of follow-ups to this:
>
> c6741fbed6dc vti6: Properly adjust vti6 MTU from MTU of lower device
> 7a67e69a339a vti6: Keep set MTU on link creation or change, validate it
>
> The second of those will fail to build on branches older than 4.10
> though. It might be better to revert this one instead.

Thanks Ben for spotting this.

Actually,
53c81e95df17 ("ip6_vti: adjust vti mtu according to mtu of lower device")
alone improves things already, despite being "fixed" by
c6741fbed6dc ("vti6: Properly adjust vti6 MTU from MTU of lower device")

With just 53c81e95df17 the MTU of a vti6 interface will be somewhat
linked to the MTU of the lower layer, but will be underestimated.

With c6741fbed6dc the calculation of MTU from lower layer will be
accurate instead.

However, without
7a67e69a339a ("vti6: Keep set MTU on link creation or change, validate it")
but with
53c81e95df17 ("ip6_vti: adjust vti mtu according to mtu of lower device")
assignment of MTU on link change is discarded, so this would actually
introduce a bug.

Fixing
7a67e69a339a ("vti6: Keep set MTU on link creation or change, validate it")
for 4.4 up to 4.9 is trivial, we simply need to adjust for the lack of
b96f9afee4eb ("ipv4/6: use core net MTU range checking")
and reflect the change introduced by
f8a554b4aa96 ("vti6: Fix dev->max_mtu setting").

So, Greg, here comes the backport of
7a67e69a339a ("vti6: Keep set MTU on link creation or change, validate it")
based on latest linux-4.4.y branch, in case you want to keep the existing
change and add the follow-ups on top. Please let me know if I should submit
it formally.

diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index 176e79076fb1..f388f54b4162 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -610,7 +610,7 @@ static int vti6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
return 0;
}

-static void vti6_link_config(struct ip6_tnl *t)
+static void vti6_link_config(struct ip6_tnl *t, bool keep_mtu)
{
struct net_device *dev = t->dev;
struct __ip6_tnl_parm *p = &t->parms;
@@ -629,6 +629,13 @@ static void vti6_link_config(struct ip6_tnl *t)
else
dev->flags &= ~IFF_POINTOPOINT;

+ if (keep_mtu && dev->mtu) {
+ dev->mtu = clamp(dev->mtu, (unsigned)IPV6_MIN_MTU,
+ (unsigned)(IP_MAX_MTU -
+ sizeof(struct ipv6hdr)));
+ return;
+ }
+
if (p->flags & IP6_TNL_F_CAP_XMIT) {
int strict = (ipv6_addr_type(&p->raddr) &
(IPV6_ADDR_MULTICAST | IPV6_ADDR_LINKLOCAL));
@@ -656,12 +663,14 @@ static void vti6_link_config(struct ip6_tnl *t)
* vti6_tnl_change - update the tunnel parameters
* @t: tunnel to be changed
* @p: tunnel configuration parameters
+ * @keep_mtu: MTU was set from userspace, don't re-compute it
*
* Description:
* vti6_tnl_change() updates the tunnel parameters
**/
static int
-vti6_tnl_change(struct ip6_tnl *t, const struct __ip6_tnl_parm *p)
+vti6_tnl_change(struct ip6_tnl *t, const struct __ip6_tnl_parm *p,
+ bool keep_mtu)
{
t->parms.laddr = p->laddr;
t->parms.raddr = p->raddr;
@@ -670,11 +679,12 @@ vti6_tnl_change(struct ip6_tnl *t, const struct __ip6_tnl_parm *p)
t->parms.o_key = p->o_key;
t->parms.proto = p->proto;
dst_cache_reset(&t->dst_cache);
- vti6_link_config(t);
+ vti6_link_config(t, keep_mtu);
return 0;
}

-static int vti6_update(struct ip6_tnl *t, struct __ip6_tnl_parm *p)
+static int vti6_update(struct ip6_tnl *t, struct __ip6_tnl_parm *p,
+ bool keep_mtu)
{
struct net *net = dev_net(t->dev);
struct vti6_net *ip6n = net_generic(net, vti6_net_id);
@@ -682,7 +692,7 @@ static int vti6_update(struct ip6_tnl *t, struct __ip6_tnl_parm *p)

vti6_tnl_unlink(ip6n, t);
synchronize_net();
- err = vti6_tnl_change(t, p);
+ err = vti6_tnl_change(t, p, keep_mtu);
vti6_tnl_link(ip6n, t);
netdev_state_change(t->dev);
return err;
@@ -795,7 +805,7 @@ vti6_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
} else
t = netdev_priv(dev);

- err = vti6_update(t, &p1);
+ err = vti6_update(t, &p1, false);
}
if (t) {
err = 0;
@@ -907,7 +917,7 @@ static int vti6_dev_init(struct net_device *dev)

if (err)
return err;
- vti6_link_config(t);
+ vti6_link_config(t, true);
return 0;
}

@@ -1006,7 +1016,7 @@ static int vti6_changelink(struct net_device *dev, struct nlattr *tb[],
} else
t = netdev_priv(dev);

- return vti6_update(t, &p);
+ return vti6_update(t, &p, tb && tb[IFLA_MTU]);
}

static size_t vti6_get_size(const struct net_device *dev)


--
Stefano

2018-04-06 07:23:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 15/97] genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs

On Tue, Apr 03, 2018 at 03:17:16PM +0100, Ben Hutchings wrote:
> On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Hans de Goede <[email protected]>
> >
> >
> > [ Upstream commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 ]
> >
> > When requesting a shared irq with IRQF_TRIGGER_NONE then the irqaction
> > flags get filled with the trigger type from the irq_data:
> >
> > ????????if (!(new->flags & IRQF_TRIGGER_MASK))
> > ????????????????new->flags |= irqd_get_trigger_type(&desc->irq_data);
>
> The code above was added to __setup_irq() in 4.8, so I don't think this
> fix is needed in 3.18 or 4.4; and I suspect it might cause a regression
> there.

Already reverted, thanks!

greg k-h

2018-04-06 07:28:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 51/97] mfd: palmas: Reset the POWERHOLD mux during power off

On Tue, Apr 03, 2018 at 09:49:14PM +0100, Ben Hutchings wrote:
> On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Keerthy <[email protected]>
> >
> >
> > [ Upstream commit 85fdaf8eb9bbec1f0f8a52fd5d85659d60738816 ]
> >
> > POWERHOLD signal has higher priority??over the DEV_ON bit.
> > So power off will not happen if the POWERHOLD is held high.
> > Hence reset the MUX to GPIO_7 mode to release the POWERHOLD
> > and the DEV_ON bit to take effect to power off the PMIC.
> >
> > PMIC Power off happens in dire situations like thermal shutdown
> > so irrespective of the POWERHOLD setting go ahead and turn off
> > the powerhold.??Currently poweroff is broken on boards that have
> > powerhold enabled. This fixes poweroff on those boards.
> [...]
>
> This is not very useful by itself; I think you should pick these too:
>
> [3.18]
> 0ea66f76ba17 Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition
> 7c62de5f3fc9 ARM: dts: dra7: Add power hold and power controller properties to palmas
>
> [4.4]
> 0ea66f76ba17 Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition
> 1f166499ce00 ARM: dts: am57xx-beagle-x15-common: Add overide powerhold property
> - apply the changes in am57xx-beagle-x15.dts
> 7c62de5f3fc9 ARM: dts: dra7: Add power hold and power controller properties to palmas
>
> [4.9]
> 0ea66f76ba17 Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition
> 1f166499ce00 ARM: dts: am57xx-beagle-x15-common: Add overide powerhold property
> 8804755bfb1f ARM: dts: am57xx-idk-common: Add overide powerhold
> property
> 7c62de5f3fc9 ARM: dts: dra7: Add power hold and power controller properties to palmas
>
> None of the above are needed for 4.14 and 4.15, but they do have one
> more board that?needed this property, so please pick this:
>
> aac4619d028e ARM: dts: DRA76-EVM: Set powerhold property for tps65917

Many thanks for this, all now queued up.

greg k-h

2018-04-06 07:30:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 52/97] mtip32xx: use runtime tag to initialize command header

On Tue, Apr 03, 2018 at 10:01:05PM +0100, Ben Hutchings wrote:
> On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Ming Lei <[email protected]>
> >
> >
> > [ Upstream commit a4e84aae8139aca9fbfbced1f45c51ca81b57488 ]
> >
> > mtip32xx supposes that 'request_idx' passed to .init_request()
> > is tag of the request, and use that as request's tag to initialize
> > command header.
> >
> > After MQ IO scheduler is in, request tag assigned isn't same with
> > the request index anymore, so cause strange hardware failure on
> > mtip32xx, even whole system panic is triggered.
> [...]
>
> MQ IO schedulers were introduced in 4.11, so this shouldn't be needed
> in older branches. It also causes a performance regression (fixed
> upstream). Please revert this for 4.4 and 4.9.

Now reverted, thanks.

greg k-h

2018-04-06 07:33:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 63/97] md/raid10: skip spare disk as first disk

On Tue, Apr 03, 2018 at 10:32:09PM +0100, Ben Hutchings wrote:
> On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Shaohua Li <[email protected]>
> >
> >
> > [ Upstream commit b506335e5d2b4ec687dde392a3bdbf7601778f1d ]
> >
> > Commit 6f287ca(md/raid10: reset the 'first' at the end of loop) ignores
> > a case in reshape, the first rdev could be a spare disk, which shouldn't
> > be accounted as the first disk since it doesn't include the offset info.
> >
> > Fix: 6f287ca(md/raid10: reset the 'first' at the end of loop)
>
> But that commit hasn't been applied to 4.4-stable. It probably should
> be, since it fixes another instance of the problem in the run()
> function. Take care not to add the wrongly placed assignment
> in?raid10_start_reshape().

Thanks, now fixed up.

greg k-h

2018-04-06 07:36:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 68/97] net: hns: fix ethtool_get_strings overflow in hns driver

On Tue, Apr 03, 2018 at 10:39:43PM +0100, Ben Hutchings wrote:
> On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Timmy Li <[email protected]>
> >
> >
> > [ Upstream commit 412b65d15a7f8a93794653968308fc100f2aa87c ]
> [...]
>
> This is not a correct fix; please also apply:
>
> commit d61d263c8d82db7c4404a29ebc29674b1c0c05c9
> Author: Matthias Brugger <[email protected]>
> Date:???Thu Mar 15 17:54:20 2018 +0100
>
> ????net: hns: Fix ethtool private flags

Thanks, now queued up.

greg k-h

2018-04-06 07:48:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 92/97] ip6_vti: adjust vti mtu according to mtu of lower device

On Thu, Apr 05, 2018 at 05:36:36PM +0200, Stefano Brivio wrote:
> On Wed, 04 Apr 2018 01:09:16 +0100
> Ben Hutchings <[email protected]> wrote:
>
> > On Fri, 2018-03-23 at 10:55 +0100, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch.??If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Alexey Kodanev <[email protected]>
> > >
> > >
> > > [ Upstream commit 53c81e95df1793933f87748d36070a721f6cb287 ]
> > [...]
> >
> > There are a couple of follow-ups to this:
> >
> > c6741fbed6dc vti6: Properly adjust vti6 MTU from MTU of lower device
> > 7a67e69a339a vti6: Keep set MTU on link creation or change, validate it
> >
> > The second of those will fail to build on branches older than 4.10
> > though. It might be better to revert this one instead.
>
> Thanks Ben for spotting this.
>
> Actually,
> 53c81e95df17 ("ip6_vti: adjust vti mtu according to mtu of lower device")
> alone improves things already, despite being "fixed" by
> c6741fbed6dc ("vti6: Properly adjust vti6 MTU from MTU of lower device")
>
> With just 53c81e95df17 the MTU of a vti6 interface will be somewhat
> linked to the MTU of the lower layer, but will be underestimated.
>
> With c6741fbed6dc the calculation of MTU from lower layer will be
> accurate instead.
>
> However, without
> 7a67e69a339a ("vti6: Keep set MTU on link creation or change, validate it")
> but with
> 53c81e95df17 ("ip6_vti: adjust vti mtu according to mtu of lower device")
> assignment of MTU on link change is discarded, so this would actually
> introduce a bug.
>
> Fixing
> 7a67e69a339a ("vti6: Keep set MTU on link creation or change, validate it")
> for 4.4 up to 4.9 is trivial, we simply need to adjust for the lack of
> b96f9afee4eb ("ipv4/6: use core net MTU range checking")
> and reflect the change introduced by
> f8a554b4aa96 ("vti6: Fix dev->max_mtu setting").
>
> So, Greg, here comes the backport of
> 7a67e69a339a ("vti6: Keep set MTU on link creation or change, validate it")
> based on latest linux-4.4.y branch, in case you want to keep the existing
> change and add the follow-ups on top. Please let me know if I should submit
> it formally.

Ick, that's a mess. How about I just revert this patch from the stable
trees, and then someone sends me either a list of git commits to apply,
or patches, for the different trees if it's really needed?

thanks,

greg k-h

2018-04-10 15:17:56

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 38/97] netfilter: xt_CT: fix refcnt leak on error path

On Tue, 2018-04-03 at 18:46 +0100, Ben Hutchings wrote:
> On Fri, 2018-03-23 at 10:54 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Gao Feng <[email protected]>
> >
> >
> > [ Upstream commit 470acf55a021713869b9bcc967268ac90c8a0fac ]
[...] 
> > @@ -249,7 +252,7 @@ static int xt_ct_tg_check(const struct x
> >   if (info->timeout[0]) {
> >   ret = xt_ct_set_timeout(ct, par, info->timeout);
> >   if (ret < 0)
> > - goto err3;
> > + goto err4;
> >   }
> >   __set_bit(IPS_CONFIRMED_BIT, &ct->status);
> >   nf_conntrack_get(&ct->ct_general);
> > @@ -257,6 +260,10 @@ out:
> >   info->ct = ct;
> >   return 0;
> >  
> > +err4:
> > + help = nfct_help(ct);
> > + if (help)
> > + module_put(help->helper->me);
> >  err3:
> >   nf_ct_tmpl_free(ct);
> >  err2:
>
> This does not.  nf_ct_tmpl_free() calls nf_ct_ext_destroy() which I
> think will call back into xt_ct_tg_destroy().  So I think the module
> reference is already dropped here and we mustn't do it twice.  Am I
> missing something?

I still don't understand this code, but I have verified that the
module_put() is needed on this error path to balance the module
reference count. I.e. this fix is good.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.