2018-05-28 16:06:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 000/268] 4.4.134-stable review

This is the start of the stable review cycle for the 4.4.134 release.
There are 268 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 Wed May 30 10:00:40 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.134-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.134-rc1

Martin Schwidefsky <[email protected]>
s390/ftrace: use expoline for indirect branches

Randy Dunlap <[email protected]>
kdb: make "mdr" command repeat

Larry Finger <[email protected]>
Bluetooth: btusb: Add device ID for RTL8822BE

Sylwester Nawrocki <[email protected]>
ASoC: samsung: i2s: Ensure the RCLK rate is properly determined

Christophe JAILLET <[email protected]>
regulator: of: Add a missing 'of_node_put()' in an error handling path of 'of_regulator_match()'

James Smart <[email protected]>
scsi: lpfc: Fix frequency of Release WQE CQEs

James Smart <[email protected]>
scsi: lpfc: Fix soft lockup in lpfc worker thread during LIP testing

James Smart <[email protected]>
scsi: lpfc: Fix issue_lip if link is disabled

Richard Haines <[email protected]>
netlabel: If PF_INET6, check sk_buff ip header version

Prashant Bhole <[email protected]>
selftests/net: fixes psock_fanout eBPF test case

Jiri Olsa <[email protected]>
perf report: Fix memory corruption in --branch-history mode --branch-history

Jiri Olsa <[email protected]>
perf tests: Use arch__compare_symbol_names to compare symbols

Baoquan He <[email protected]>
x86/apic: Set up through-local-APIC mode on the boot CPU if 'noapic' specified

Ørjan Eide <[email protected]>
drm/rockchip: Respect page offset for PRIME mmap calls

Joe Perches <[email protected]>
MIPS: Octeon: Fix logging messages with spurious periods after newlines

Richard Guy Briggs <[email protected]>
audit: return on memory error to avoid null pointer dereference

Peter Robinson <[email protected]>
crypto: sunxi-ss - Add MODULE_ALIAS to sun4i-ss

Andrzej Hajda <[email protected]>
clk: samsung: exynos3250: Fix PLL rates

Andrzej Hajda <[email protected]>
clk: samsung: exynos5250: Fix PLL rates

Andrzej Hajda <[email protected]>
clk: samsung: exynos5433: Fix PLL rates

Andrzej Hajda <[email protected]>
clk: samsung: exynos5260: Fix PLL rates

Andrzej Hajda <[email protected]>
clk: samsung: s3c2410: Fix PLL rates

Colin Ian King <[email protected]>
media: cx25821: prevent out-of-bounds read on array card

Jan Kara <[email protected]>
udf: Provide saner default for invalid uid / gid

Thomas Vincent-Cross <[email protected]>
PCI: Add function 1 DMA alias quirk for Marvell 88SE9220

Geert Uytterhoeven <[email protected]>
serial: arc_uart: Fix out-of-bounds access through DT alias

Geert Uytterhoeven <[email protected]>
serial: fsl_lpuart: Fix out-of-bounds access through DT alias

Geert Uytterhoeven <[email protected]>
serial: imx: Fix out-of-bounds access through serial port index

Geert Uytterhoeven <[email protected]>
serial: mxs-auart: Fix out-of-bounds access through serial port index

Geert Uytterhoeven <[email protected]>
serial: samsung: Fix out-of-bounds access through serial port index

Geert Uytterhoeven <[email protected]>
serial: xuartps: Fix out-of-bounds access through DT alias

Colin Ian King <[email protected]>
rtc: tx4939: avoid unintended sign extension on a 24 bit shift

Colin Ian King <[email protected]>
staging: rtl8192u: return -ENOMEM on failed allocation of priv->oldaddr

[email protected] <[email protected]>
hwrng: stm32 - add reset during probe

Govindarajulu Varadarajan <[email protected]>
enic: enable rq before updating rq descriptors

Shawn Lin <[email protected]>
clk: rockchip: Prevent calculating mmc phase if clock rate is zero

Brad Love <[email protected]>
media: em28xx: USB bulk packet size fix

Qi Hou <[email protected]>
dmaengine: pl330: fix a race condition in case of threaded irqs

Arnd Bergmann <[email protected]>
media: s3c-camif: fix out-of-bounds array access

Brad Love <[email protected]>
media: cx23885: Set subdev host data to clk_freq pointer

Brad Love <[email protected]>
media: cx23885: Override 888 ImpactVCBe crystal frequency

Takashi Iwai <[email protected]>
ALSA: vmaster: Propagate slave error

Ivan Gorinov <[email protected]>
x86/devicetree: Fix device IRQ settings in DT

Ivan Gorinov <[email protected]>
x86/devicetree: Initialize device tree before using it

Chris Dickens <[email protected]>
usb: gadget: composite: fix incorrect handling of OS desc requests

Wolfram Sang <[email protected]>
usb: gadget: udc: change comparison to bitshift when dealing with a mask

Andreas Gruenbacher <[email protected]>
gfs2: Fix fallocate chunk size

Maurizio Lombardi <[email protected]>
cdrom: do not call check_disk_change() inside cdrom_open()

Guenter Roeck <[email protected]>
hwmon: (pmbus/adm1275) Accept negative page register values

Guenter Roeck <[email protected]>
hwmon: (pmbus/max8688) Accept negative page register values

Peter Zijlstra <[email protected]>
perf/core: Fix perf_output_read_group()

Ranjani Sridharan <[email protected]>
ASoC: topology: create TLV data for dapm widgets

Mathieu Malaterre <[email protected]>
powerpc: Add missing prototype for arch_irq_work_raise()

Lars-Peter Clausen <[email protected]>
usb: gadget: ffs: Execute copy_to_user() with USER_DS set

Lars-Peter Clausen <[email protected]>
usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS

Grigor Tovmasyan <[email protected]>
usb: dwc2: Fix interval type issue

Kamlakant Patel <[email protected]>
ipmi_ssif: Fix kernel panic at msg_done_handler

Rafael J. Wysocki <[email protected]>
PCI: Restore config space on runtime resume despite being unbound

Mathias Kresin <[email protected]>
MIPS: ath79: Fix AR724X_PLL_REG_PCIE_CONFIG offset

Mathias Nyman <[email protected]>
xhci: zero usb device slot_id member when disabling and freeing a xhci slot

Vitaly Kuznetsov <[email protected]>
KVM: lapic: stop advertising DIRECTED_EOI when in-kernel IOAPIC is in use

Gregory CLEMENT <[email protected]>
i2c: mv64xxx: Apply errata delay only in standard mode

Seunghun Han <[email protected]>
ACPICA: acpi: acpica: fix acpi operand cache leak in nseval.c

Erik Schmauss <[email protected]>
ACPICA: Events: add a return on failure from acpi_hw_register_read

Coly Li <[email protected]>
bcache: quit dc->writeback_thread when BCACHE_DEV_DETACHING is set

Michael Schmitz <[email protected]>
zorro: Set up z->dev.dma_mask for the DMA API

Shawn Lin <[email protected]>
clk: Don't show the incorrect clock phase

Chunyu Hu <[email protected]>
cpufreq: cppc_cpufreq: Fix cppc_cpufreq_init() failure path

Thinh Nguyen <[email protected]>
usb: dwc3: Update DWC_usb31 GTXFIFOSIZ reg fields

Philipp Puschmann <[email protected]>
arm: dts: socfpga: fix GIC PPI warning

Jay Vosburgh <[email protected]>
virtio-net: Fix operstate for virtio when no VIRTIO_NET_F_STATUS

Petr Vorel <[email protected]>
ima: Fallback to the builtin hash algorithm

Jiandi An <[email protected]>
ima: Fix Kconfig to select TPM 2.0 CRB interface

Karthikeyan Periyasamy <[email protected]>
ath10k: Fix kernel panic while using worker (ath10k_sta_rc_update_wk)

Leon Romanovsky <[email protected]>
net/mlx5: Protect from command bit overflow

Michael Ellerman <[email protected]>
selftests: Print the test we're running to /dev/kmsg

Frank Asseg <[email protected]>
tools/thermal: tmon: fix for segfault

Michael Ellerman <[email protected]>
powerpc/perf: Fix kernel address leak via sampling registers

Madhavan Srinivasan <[email protected]>
powerpc/perf: Prevent kernel address leak to userspace via BHRB buffer

Alexandre Belloni <[email protected]>
rtc: hctosys: Ensure system time doesn't overflow time_t

Guenter Roeck <[email protected]>
hwmon: (nct6775) Fix writing pwmX_mode

Helge Deller <[email protected]>
parisc/pci: Switch LBA PCI bus from Hard Fail to Soft Fail mode

Greg Ungerer <[email protected]>
m68k: set dma and coherent masks for platform FEC ethernets

Michael Ellerman <[email protected]>
powerpc/mpic: Check if cpu_possible() in mpic_physmask()

Lenny Szubowicz <[email protected]>
ACPI: acpi_pad: Fix memory leak in power saving threads

Dan Carpenter <[email protected]>
xen/acpi: off by one in read_acpi_id()

Jeff Mahoney <[email protected]>
btrfs: fix lockdep splat in btrfs_alloc_subvolume_writers

Filipe Manana <[email protected]>
Btrfs: fix copy_items() return value when logging an inode

Qu Wenruo <[email protected]>
btrfs: tests/qgroup: Fix wrong tree backref level

Vicente Bergas <[email protected]>
Bluetooth: btusb: Add USB ID 7392:a611 for Edimax EW-7611ULB

Florian Fainelli <[email protected]>
net: bgmac: Fix endian access in bgmac_dma_tx_ring_free()

Bryan O'Donoghue <[email protected]>
rtc: snvs: Fix usage of snvs_rtc_enable

David S. Miller <[email protected]>
sparc64: Make atomic_xchg() an inline function rather than a macro.

David Howells <[email protected]>
fscache: Fix hanging wait on page discarded by writeback

Sean Christopherson <[email protected]>
KVM: VMX: raise internal error for exception during invalid protected mode state

Davidlohr Bueso <[email protected]>
sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

Jun Piao <[email protected]>
ocfs2/dlm: don't handle migrate lockres if already in shutdown

Nikolay Borisov <[email protected]>
btrfs: Fix possible softlock on single core machines

Liu Bo <[email protected]>
Btrfs: fix NULL pointer dereference in log_dir_items

Liu Bo <[email protected]>
Btrfs: bail out on error during replay_dir_deletes

Huang Ying <[email protected]>
mm: fix races between address_space dereference and free in page_evicatable

Claudio Imbrenda <[email protected]>
mm/ksm: fix interaction with THP

Esben Haabendal <[email protected]>
dp83640: Ensure against premature access to PHY registers after reset

Dave Carroll <[email protected]>
scsi: aacraid: Insure command thread is not recursively stopped

Shunyong Yang <[email protected]>
cpufreq: CPPC: Initialize shared perf capabilities of CPUs

Carlos Maiolino <[email protected]>
Force log to disk before reading the AGF during a fstrim

Jens Axboe <[email protected]>
sr: get/drop reference to device in revalidate and check_events

Tom Abraham <[email protected]>
swap: divide-by-zero when zero length swap file on ssd

Danilo Krummrich <[email protected]>
fs/proc/proc_sysctl.c: fix potential page fault while unregistering sysctl table

Joerg Roedel <[email protected]>
x86/pgtable: Don't set huge PUD/PMD on non-leaf entries

Rich Felker <[email protected]>
sh: fix debug trap failure to process signals before return to user

Yelena Krivosheev <[email protected]>
net: mvneta: fix enable of all initialized RXQs

Toshiaki Makita <[email protected]>
net: Fix untag for vlan packets without ethernet header

Vinayak Menon <[email protected]>
mm/kmemleak.c: wait for scan completion before disabling free

Cong Wang <[email protected]>
llc: properly handle dev_queue_xmit() return value

Giuseppe Lippolis <[email protected]>
net-usb: add qmi_wwan if on lte modem wistron neweb d18q1

Torsten Hilbrich <[email protected]>
net/usb/qmi_wwan.c: Add USB id for lt4120 modem

Pawel Dembicki <[email protected]>
net: qmi_wwan: add BroadMobi BM806U 2020:2033

Jinbum Park <[email protected]>
ARM: 8748/1: mm: Define vdso_start, vdso_end as array

Linus Lüssing <[email protected]>
batman-adv: fix packet loss for broadcasted DHCP packets to a server

Linus Lüssing <[email protected]>
batman-adv: fix multicast-via-unicast transmission with AP isolation

Masami Hiramatsu <[email protected]>
selftests: ftrace: Add a testcase for probepoint

Masami Hiramatsu <[email protected]>
selftests: ftrace: Add a testcase for string type with kprobe_event

Masami Hiramatsu <[email protected]>
selftests: ftrace: Add probe event argument syntax testcase

Yisheng Xie <[email protected]>
mm/mempolicy.c: avoid use uninitialized preferred_node

Chien Tin Tung <[email protected]>
RDMA/ucma: Correct option size check using optlen

Song Liu <[email protected]>
perf/cgroup: Fix child event counting bug

Stefano Brivio <[email protected]>
vti4: Don't override MTU passed on link creation via IFLA_MTU

Stefano Brivio <[email protected]>
vti4: Don't count header length twice on tunnel setup

Matthias Schiffer <[email protected]>
batman-adv: fix header size check in batadv_dbg_arp()

Toshiaki Makita <[email protected]>
net: Fix vlan untag for bridge and vlan_dev with reorder_hdr off

Rob Herring <[email protected]>
microblaze: switch to NO_BOOTMEM

Cathy Zhou <[email protected]>
sunvnet: does not support GSO for sctp

Sabrina Dubroca <[email protected]>
ipv4: lock mtu in fnhe when received PMTU < net.ipv4.route.min_pmtu

Arvind Yadav <[email protected]>
workqueue: use put_device() instead of kfree()

Michael Chan <[email protected]>
bnxt_en: Check valid VNIC ID in bnxt_hwrm_vnic_set_tpa().

Florian Westphal <[email protected]>
netfilter: ebtables: fix erroneous reject of last rule

Fredrik Noring <[email protected]>
USB: OHCI: Fix NULL dereference in HCDs using HCD_LOCAL_MEM

Arvind Yadav <[email protected]>
xen: xenbus: use put_device() instead of kfree()

Peter Malone <[email protected]>
fbdev: Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in sbusfb_ioctl_helper().

Jeremy Cline <[email protected]>
scsi: sd: Keep disk read-only when re-reading partition

Hannes Reinecke <[email protected]>
scsi: mpt3sas: Do not mark fw_event workqueue as WQ_MEM_RECLAIM

Merlijn Wajer <[email protected]>
usb: musb: call pm_runtime_{get,put}_sync before reading vbus registers

Pierre-Yves Kerbrat <[email protected]>
e1000e: allocate ring descriptors with dma_zalloc_coherent

Benjamin Poirier <[email protected]>
e1000e: Fix check_for_link return value with autoneg off

Igor Pylypiv <[email protected]>
watchdog: f71808e_wdt: Fix magic close handling

Paul Mackerras <[email protected]>
KVM: PPC: Book3S HV: Fix VRMA initialization with 2MB or 1GB memory backing

Michael Ellerman <[email protected]>
selftests/powerpc: Skip the subpage_prot tests if the syscall is unavailable

Filipe Manana <[email protected]>
Btrfs: send, fix issuing write op when processing hole in no data mode

Roger Pau Monne <[email protected]>
xen/pirq: fix error path cleanup when binding MSIs

Joey Pabalinas <[email protected]>
net/tcp/illinois: replace broken algorithm reference link

Claudiu Manoil <[email protected]>
gianfar: Fix Rx byte accounting for ndev stats

Xin Long <[email protected]>
sit: fix IFLA_MTU ignored on NEWLINK

Tang Junhui <[email protected]>
bcache: fix kcrashes with fio in RAID5 backend dev

Yoshihiro Shimoda <[email protected]>
dmaengine: rcar-dmac: fix max_chunk_size for R-Car Gen3

Dave Airlie <[email protected]>
virtio-gpu: fix ioctl and expose the fixed status to userspace.

Eric Dumazet <[email protected]>
r8152: fix tx packets accounting

Colin Ian King <[email protected]>
clocksource/drivers/fsl_ftm_timer: Fix error return checking

Jianchao Wang <[email protected]>
nvme-pci: Fix nvme queue cleanup if IRQ setup fails

Florian Westphal <[email protected]>
netfilter: ebtables: convert BUG_ONs to WARN_ONs

Matthias Schiffer <[email protected]>
batman-adv: invalidate checksum on fragment reassembly

Matthias Schiffer <[email protected]>
batman-adv: fix packet checksum in receive path

Yufen Yu <[email protected]>
md/raid1: fix NULL pointer dereference

Mauro Carvalho Chehab <[email protected]>
media: dmxdev: fix error code for invalid ioctls

Samuel Neves <[email protected]>
x86/topology: Update the 'cpu cores' field in /proc/cpuinfo correctly across CPU hotplug operations

Andrea Parri <[email protected]>
locking/xchg/alpha: Fix xchg() and cmpxchg() memory ordering bugs

Johannes Berg <[email protected]>
regulatory: add NUL to request alpha2

Eric Dumazet <[email protected]>
smsc75xx: fix smsc75xx_set_features()

Tony Lindgren <[email protected]>
ARM: OMAP: Fix dmtimer init for omap1

Sebastian Ott <[email protected]>
s390/cio: clear timer when terminating driver I/O

Sebastian Ott <[email protected]>
s390/cio: fix return code after missing interrupt

Mark Lord <[email protected]>
powerpc/bpf/jit: Fix 32-bit JIT for seccomp_data access

David Rientjes <[email protected]>
kernel/relay.c: limit kmalloc size to KMALLOC_MAX_SIZE

Arnd Bergmann <[email protected]>
md: raid5: avoid string overflow warning

Andrea Parri <[email protected]>
locking/xchg/alpha: Add unconditional memory barrier to cmpxchg()

Andreas Kemnade <[email protected]>
usb: musb: fix enumeration after resume

Markus Elfring <[email protected]>
drm/exynos: g2d: Delete an error message for a failed memory allocation in two functions

Wolfram Sang <[email protected]>
drm/exynos: fix comparison to bitshift when dealing with a mask

Yufen Yu <[email protected]>
md raid10: fix NULL deference in handle_write_completed()

Felix Fietkau <[email protected]>
mac80211: round IEEE80211_TX_STATUS_HEADROOM up to multiple of 4

Kees Cook <[email protected]>
NFC: llcp: Limit size of SDP URI

Geert Uytterhoeven <[email protected]>
ARM: OMAP1: clock: Fix debugfs_create_*() usage

Tony Lindgren <[email protected]>
ARM: OMAP3: Fix prm wake interrupt for resume

Qi Hou <[email protected]>
ARM: OMAP2+: timer: fix a kmemleak caused in omap_get_timer_dt

Manish Rangankar <[email protected]>
scsi: qla4xxx: skip error recovery in case of register disconnect.

Meelis Roos <[email protected]>
scsi: aacraid: fix shutdown crash when init fails

Michael Kelley (EOSG) <[email protected]>
scsi: storvsc: Increase cmd_per_lun for higher speed devices

Anders Roxell <[email protected]>
selftests: memfd: add config fragment for fuse

Vardan Mikayelyan <[email protected]>
usb: dwc2: Fix dwc2_hsotg_core_init_disconnected()

Stefan Agner <[email protected]>
usb: gadget: fsl_udc_core: fix ep valid checks

John Keeping <[email protected]>
usb: gadget: f_uac2: fix bFirstInterface in composite gadget

Ulf Magnusson <[email protected]>
ARC: Fix malformed ARC_EMUL_UNALIGNED default

Bart Van Assche <[email protected]>
scsi: qla2xxx: Avoid triggering undefined behavior in qla2x00_mbx_completion()

Dan Carpenter <[email protected]>
scsi: mptfusion: Add bounds check in mptctl_hp_targetinfo()

Dan Carpenter <[email protected]>
scsi: sym53c8xx_2: iterator underflow in sym_getsync()

Chad Dupuis <[email protected]>
scsi: bnx2fc: Fix check in SCSI completion handler for timed out request

Sujit Reddy Thumma <[email protected]>
scsi: ufs: Enable quirk to ignore sending WRITE_SAME command

Mark Salter <[email protected]>
irqchip/gic-v3: Change pr_debug message to pr_devel

Will Deacon <[email protected]>
locking/qspinlock: Ensure node->count is updated before initialising node

Jesper Dangaard Brouer <[email protected]>
tools/libbpf: handle issues with bpf ELF objects containing .eh_frames

Tang Junhui <[email protected]>
bcache: return attach error when no cache set exist

Tang Junhui <[email protected]>
bcache: fix for data collapse after re-attaching an attached device

Tang Junhui <[email protected]>
bcache: fix for allocator and register thread race

Coly Li <[email protected]>
bcache: properly set task state in bch_writeback_thread()

Arnd Bergmann <[email protected]>
cifs: silence compiler warnings showing up with gcc-8.0.0

Alexey Dobriyan <[email protected]>
proc: fix /proc/*/map_files lookup

Will Deacon <[email protected]>
arm64: spinlock: Fix theoretical trylock() A-B-A with LSE atomics

Guanglei Li <[email protected]>
RDS: IB: Fix null pointer issue

Ross Lagerwall <[email protected]>
xen/grant-table: Use put_page instead of free_page

Ross Lagerwall <[email protected]>
xen-netfront: Fix race between device setup and open

Matt Redfearn <[email protected]>
MIPS: TXx9: use IS_BUILTIN() for CONFIG_LEDS_CLASS

Yonghong Song <[email protected]>
bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y

Chen Yu <[email protected]>
ACPI: processor_perflib: Do not send _PPC change notification if not ready

Jean Delvare <[email protected]>
firmware: dmi_scan: Fix handling of empty DMI strings

Arnd Bergmann <[email protected]>
x86/power: Fix swsusp_arch_resume prototype

Alex Estrin <[email protected]>
IB/ipoib: Fix for potential no-carrier state

Mel Gorman <[email protected]>
mm: pin address_space before dereferencing it while isolating an LRU page

Kirill A. Shutemov <[email protected]>
asm-generic: provide generic_pmdp_establish()

Yisheng Xie <[email protected]>
mm/mempolicy: add nodes_empty check in SYSC_migrate_pages

Yisheng Xie <[email protected]>
mm/mempolicy: fix the check of nodemask from user

piaojun <[email protected]>
ocfs2: return error when we attempt to access a dirty bh in jbd2

piaojun <[email protected]>
ocfs2/acl: use 'ip_xattr_sem' to protect getting extended attribute

piaojun <[email protected]>
ocfs2: return -EROFS to mount.ocfs2 if inode block is invalid

Logan Gunthorpe <[email protected]>
ntb_transport: Fix bug with max_mw_size parameter

Leon Romanovsky <[email protected]>
RDMA/mlx5: Avoid memory leak in case of XRCD dealloc failure

Michael Bringmann <[email protected]>
powerpc/numa: Ensure nodes initialized for hotplug

Michael Bringmann <[email protected]>
powerpc/numa: Use ibm,max-associativity-domains to discover possible nodes

Jake Daryll Obina <[email protected]>
jffs2: Fix use-after-free bug in jffs2_iget()'s error handling path

Dan Carpenter <[email protected]>
HID: roccat: prevent an out of bounds read in kovaplus_profile_activated()

Arnd Bergmann <[email protected]>
scsi: fas216: fix sense buffer initialization

Liu Bo <[email protected]>
Btrfs: fix scrub to repair raid6 corruption

Nikolay Borisov <[email protected]>
btrfs: Fix out of bounds access in btrfs_search_slot

Liu Bo <[email protected]>
Btrfs: set plug for fsync

Wei Yongjun <[email protected]>
ipmi/powernv: Fix error return code in ipmi_powernv_probe()

weiyongjun (A) <[email protected]>
mac80211_hwsim: fix possible memory leak in hwsim_new_radio_nl()

Ulf Magnusson <[email protected]>
kconfig: Fix expr_free() E_NOT leak

Ulf Magnusson <[email protected]>
kconfig: Fix automatic menu creation mem leak

Ulf Magnusson <[email protected]>
kconfig: Don't leak main menus during parsing

Guenter Roeck <[email protected]>
watchdog: sp5100_tco: Fix watchdog disable bit

Jan Chochol <[email protected]>
nfs: Do not convert nfs_idmap_cache_timeout to jiffies

mulhern <[email protected]>
dm thin: fix documentation relative to low water mark threshold

Steven Rostedt (VMware) <[email protected]>
tools lib traceevent: Fix get_field_str() for dynamic strings

Arnaldo Carvalho de Melo <[email protected]>
perf callchain: Fix attr.sample_max_stack setting

Steven Rostedt (VMware) <[email protected]>
tools lib traceevent: Simplify pointer print logic and fix %pF

Alex Williamson <[email protected]>
PCI: Add function 1 DMA alias quirk for Marvell 9128

Anna-Maria Gleixner <[email protected]>
tracing/hrtimer: Fix tracing bugs by taking all clock bases and modes into account

Paolo Bonzini <[email protected]>
kvm: x86: fix KVM_XEN_HVM_CONFIG ioctl

Dan Carpenter <[email protected]>
ASoC: au1x: Fix timeout tests in au1xac97c_ac97_read()

Takashi Iwai <[email protected]>
ALSA: hda - Use IS_REACHABLE() for dependency on input

NeilBrown <[email protected]>
NFSv4: always set NFS_LOCK_LOST when a lock is lost.

Hector Martin <[email protected]>
firewire-ohci: work around oversized DMA reads on JMicron controllers

Al Viro <[email protected]>
do d_instantiate/unlock_new_inode combinations safely

Brian Foster <[email protected]>
xfs: remove racy hasattr check from attr ops

zhongjiang <[email protected]>
kernel/signal.c: avoid undefined behaviour in kill_something_info

Gustavo A. R. Silva <[email protected]>
kernel/sys.c: fix potential Spectre v1 issue

David Hildenbrand <[email protected]>
kasan: fix memory hotplug during boot

Davidlohr Bueso <[email protected]>
ipc/shm: fix shmat() nil address after round-down when remapping

Davidlohr Bueso <[email protected]>
Revert "ipc/shm: Fix shmat mmap nil-page protection"

Joe Jin <[email protected]>
xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent

Sudip Mukherjee <[email protected]>
libata: blacklist Micron 500IT SSD with MU01 firmware

Tejun Heo <[email protected]>
libata: Blacklist some Sandisk SSDs for NCQ

Corneliu Doban <[email protected]>
mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register

Ben Hutchings <[email protected]>
ALSA: timer: Fix pause event notification

Al Viro <[email protected]>
aio: fix io_destroy(2) vs. lookup_ioctx() race

Al Viro <[email protected]>
affs_lookup(): close a race with affs_remove_link()

Colin Ian King <[email protected]>
KVM: Fix spelling mistake: "cop_unsuable" -> "cop_unusable"

Maciej W. Rozycki <[email protected]>
MIPS: Fix ptrace(2) PTRACE_PEEKUSR and PTRACE_POKEUSR accesses to o32 FGRs

Maciej W. Rozycki <[email protected]>
MIPS: ptrace: Expose FIR register through FP regset


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

Diffstat:

Documentation/device-mapper/thin-provisioning.txt | 8 +-
Makefile | 4 +-
arch/alpha/include/asm/xchg.h | 30 +++++--
arch/arc/Kconfig | 1 -
arch/arm/boot/dts/socfpga.dtsi | 2 +-
arch/arm/include/asm/vdso.h | 2 -
arch/arm/kernel/vdso.c | 12 +--
arch/arm/mach-omap1/clock.c | 6 +-
arch/arm/mach-omap2/pm.c | 4 +-
arch/arm/mach-omap2/timer.c | 19 +++--
arch/arm/plat-omap/dmtimer.c | 7 +-
arch/arm64/include/asm/spinlock.h | 4 +-
arch/m68k/coldfire/device.c | 12 ++-
arch/microblaze/Kconfig | 1 +
arch/microblaze/mm/init.c | 56 ++-----------
arch/mips/cavium-octeon/octeon-irq.c | 10 +--
arch/mips/include/asm/mach-ath79/ar71xx_regs.h | 2 +-
arch/mips/kernel/ptrace.c | 22 ++++-
arch/mips/kernel/ptrace32.c | 4 +-
arch/mips/kvm/mips.c | 2 +-
arch/mips/txx9/rbtx4939/setup.c | 4 +-
arch/powerpc/include/asm/irq_work.h | 1 +
arch/powerpc/kvm/book3s_hv.c | 12 +--
arch/powerpc/mm/numa.c | 78 ++++++++++++++---
arch/powerpc/net/bpf_jit_comp.c | 3 +
arch/powerpc/perf/core-book3s.c | 25 ++++++
arch/powerpc/sysdev/mpic.c | 2 +-
arch/s390/include/asm/nospec-insn.h | 13 +++
arch/s390/kernel/asm-offsets.c | 1 +
arch/s390/kernel/mcount.S | 14 ++--
arch/sh/kernel/entry-common.S | 2 +-
arch/sparc/include/asm/atomic_64.h | 6 +-
arch/x86/kernel/apic/apic.c | 2 +-
arch/x86/kernel/devicetree.c | 21 +++--
arch/x86/kernel/smpboot.c | 1 +
arch/x86/kvm/lapic.c | 10 ++-
arch/x86/kvm/vmx.c | 20 +++--
arch/x86/kvm/x86.c | 7 +-
arch/x86/mm/pgtable.c | 9 ++
arch/x86/power/hibernate_32.c | 2 +-
arch/x86/power/hibernate_64.c | 2 +-
drivers/acpi/acpi_pad.c | 3 +
drivers/acpi/acpica/evevent.c | 9 +-
drivers/acpi/acpica/nseval.c | 8 ++
drivers/acpi/processor_perflib.c | 2 +-
drivers/ata/libata-core.c | 6 ++
drivers/block/paride/pcd.c | 2 +
drivers/bluetooth/btusb.c | 6 ++
drivers/cdrom/cdrom.c | 3 -
drivers/cdrom/gdrom.c | 3 +
drivers/char/hw_random/stm32-rng.c | 9 ++
drivers/char/ipmi/ipmi_powernv.c | 5 +-
drivers/char/ipmi/ipmi_ssif.c | 4 +-
drivers/clk/clk.c | 3 +
drivers/clk/rockchip/clk-mmc-phase.c | 23 +++++
drivers/clk/samsung/clk-exynos3250.c | 4 +-
drivers/clk/samsung/clk-exynos5250.c | 8 +-
drivers/clk/samsung/clk-exynos5260.c | 2 +-
drivers/clk/samsung/clk-exynos5433.c | 12 +--
drivers/clk/samsung/clk-s3c2410.c | 16 ++--
drivers/clocksource/fsl_ftm_timer.c | 2 +-
drivers/cpufreq/cppc_cpufreq.c | 23 ++++-
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 1 +
drivers/dma/pl330.c | 6 +-
drivers/dma/sh/rcar-dmac.c | 2 +-
drivers/firewire/ohci.c | 8 +-
drivers/firmware/dmi_scan.c | 22 ++---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 +-
drivers/gpu/drm/exynos/regs-fimc.h | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 7 +-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 17 ++--
drivers/hid/hid-roccat-kovaplus.c | 2 +
drivers/hwmon/nct6775.c | 10 +--
drivers/hwmon/pmbus/adm1275.c | 4 +-
drivers/hwmon/pmbus/max8688.c | 2 +-
drivers/i2c/busses/i2c-mv64xxx.c | 8 +-
drivers/ide/ide-cd.c | 2 +
drivers/infiniband/core/ucma.c | 2 +-
drivers/infiniband/hw/mlx5/qp.c | 5 +-
drivers/infiniband/ulp/ipoib/ipoib_main.c | 3 +
drivers/irqchip/irq-gic-v3.c | 2 +-
drivers/md/bcache/alloc.c | 4 +-
drivers/md/bcache/bcache.h | 2 +-
drivers/md/bcache/btree.c | 9 +-
drivers/md/bcache/request.c | 2 +-
drivers/md/bcache/super.c | 23 +++--
drivers/md/bcache/sysfs.c | 11 ++-
drivers/md/bcache/writeback.c | 27 ++++--
drivers/md/raid1.c | 11 +++
drivers/md/raid10.c | 6 +-
drivers/md/raid5.c | 7 +-
drivers/media/dvb-core/dmxdev.c | 2 +-
drivers/media/pci/cx23885/cx23885-cards.c | 4 +
drivers/media/pci/cx23885/cx23885-core.c | 10 +++
drivers/media/pci/cx25821/cx25821-core.c | 7 +-
drivers/media/platform/s3c-camif/camif-capture.c | 7 +-
drivers/media/usb/em28xx/em28xx.h | 2 +-
drivers/message/fusion/mptctl.c | 2 +
drivers/mmc/host/sdhci-iproc.c | 30 +++++--
drivers/net/ethernet/broadcom/bgmac.c | 3 +-
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 3 +
drivers/net/ethernet/cisco/enic/enic_main.c | 10 ++-
drivers/net/ethernet/freescale/gianfar.c | 7 +-
drivers/net/ethernet/intel/e1000e/ich8lan.c | 2 +-
drivers/net/ethernet/intel/e1000e/mac.c | 2 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 4 +-
drivers/net/ethernet/marvell/mvneta.c | 1 +
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 2 +-
drivers/net/ethernet/sun/sunvnet.c | 2 +-
drivers/net/phy/dp83640.c | 18 ++++
drivers/net/usb/qmi_wwan.c | 5 ++
drivers/net/usb/r8152.c | 2 +-
drivers/net/usb/smsc75xx.c | 7 +-
drivers/net/virtio_net.c | 2 +-
drivers/net/wireless/ath/ath10k/mac.c | 10 +++
drivers/net/wireless/mac80211_hwsim.c | 4 +-
drivers/net/xen-netfront.c | 46 +++++-----
drivers/ntb/ntb_transport.c | 3 +
drivers/nvme/host/pci.c | 5 +-
drivers/parisc/lba_pci.c | 20 ++++-
drivers/pci/pci-driver.c | 17 ++--
drivers/pci/quirks.c | 5 ++
drivers/regulator/of_regulator.c | 1 +
drivers/rtc/hctosys.c | 5 ++
drivers/rtc/rtc-snvs.c | 15 +++-
drivers/rtc/rtc-tx4939.c | 6 +-
drivers/s390/cio/device_fsm.c | 7 +-
drivers/s390/cio/io_sch.h | 1 +
drivers/scsi/aacraid/commsup.c | 4 +-
drivers/scsi/aacraid/linit.c | 5 +-
drivers/scsi/arm/fas216.c | 2 +-
drivers/scsi/bnx2fc/bnx2fc_io.c | 1 +
drivers/scsi/lpfc/lpfc_attr.c | 5 ++
drivers/scsi/lpfc/lpfc_hbadisc.c | 5 +-
drivers/scsi/lpfc/lpfc_sli.c | 2 +
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 2 +-
drivers/scsi/qla2xxx/qla_isr.c | 6 +-
drivers/scsi/qla4xxx/ql4_def.h | 2 +
drivers/scsi/qla4xxx/ql4_os.c | 46 ++++++++++
drivers/scsi/sd.c | 3 +-
drivers/scsi/sr.c | 21 ++++-
drivers/scsi/storvsc_drv.c | 2 +-
drivers/scsi/sym53c8xx_2/sym_hipd.c | 2 +-
drivers/scsi/ufs/ufshcd.c | 2 +
drivers/staging/rtl8192u/r8192U_core.c | 2 +
drivers/tty/serial/arc_uart.c | 5 ++
drivers/tty/serial/fsl_lpuart.c | 4 +
drivers/tty/serial/imx.c | 6 ++
drivers/tty/serial/mxs-auart.c | 4 +
drivers/tty/serial/samsung.c | 4 +
drivers/tty/serial/xilinx_uartps.c | 2 +-
drivers/usb/dwc2/core.h | 2 +-
drivers/usb/dwc2/gadget.c | 12 +--
drivers/usb/dwc3/core.h | 2 +
drivers/usb/gadget/composite.c | 40 +++++----
drivers/usb/gadget/function/f_fs.c | 6 +-
drivers/usb/gadget/function/f_uac2.c | 2 +
drivers/usb/gadget/udc/fsl_udc_core.c | 4 +-
drivers/usb/gadget/udc/goku_udc.h | 2 +-
drivers/usb/host/ohci-hcd.c | 3 +-
drivers/usb/host/xhci-mem.c | 2 +
drivers/usb/musb/musb_core.c | 5 +-
drivers/video/fbdev/sbuslib.c | 4 +-
drivers/watchdog/f71808e_wdt.c | 3 +-
drivers/watchdog/sp5100_tco.h | 2 +-
drivers/xen/events/events_base.c | 4 +-
drivers/xen/grant-table.c | 4 +-
drivers/xen/swiotlb-xen.c | 2 +-
drivers/xen/xen-acpi-processor.c | 6 +-
drivers/xen/xenbus/xenbus_probe.c | 5 +-
drivers/zorro/zorro.c | 12 +++
fs/affs/namei.c | 10 ++-
fs/aio.c | 4 +-
fs/btrfs/ctree.c | 12 ++-
fs/btrfs/disk-io.c | 2 +-
fs/btrfs/extent-tree.c | 1 +
fs/btrfs/file.c | 9 ++
fs/btrfs/inode.c | 16 +---
fs/btrfs/raid56.c | 18 +++-
fs/btrfs/send.c | 3 +
fs/btrfs/tests/qgroup-tests.c | 2 +-
fs/btrfs/tree-log.c | 12 ++-
fs/btrfs/volumes.c | 9 +-
fs/cifs/cifssmb.c | 4 +-
fs/dcache.c | 22 +++++
fs/ecryptfs/inode.c | 3 +-
fs/ext2/namei.c | 6 +-
fs/ext4/namei.c | 6 +-
fs/f2fs/namei.c | 12 +--
fs/fscache/page.c | 13 ++-
fs/gfs2/file.c | 5 +-
fs/gfs2/quota.h | 2 +
fs/jffs2/dir.c | 12 +--
fs/jffs2/fs.c | 1 -
fs/jfs/namei.c | 12 +--
fs/nfs/nfs4proc.c | 12 ++-
fs/nfs/nfs4state.c | 5 +-
fs/nfs/nfs4sysctl.c | 2 +-
fs/nilfs2/namei.c | 6 +-
fs/ocfs2/acl.c | 6 ++
fs/ocfs2/dlm/dlmdomain.c | 14 ----
fs/ocfs2/dlm/dlmdomain.h | 25 +++++-
fs/ocfs2/dlm/dlmrecovery.c | 9 ++
fs/ocfs2/journal.c | 23 ++---
fs/ocfs2/super.c | 5 +-
fs/ocfs2/xattr.c | 2 +
fs/proc/base.c | 29 ++++++-
fs/proc/proc_sysctl.c | 3 +
fs/reiserfs/namei.c | 12 +--
fs/udf/namei.c | 6 +-
fs/udf/super.c | 5 +-
fs/ufs/namei.c | 6 +-
fs/xfs/libxfs/xfs_attr.c | 6 --
fs/xfs/xfs_discard.c | 14 ++--
include/asm-generic/pgtable.h | 15 ++++
include/linux/dcache.h | 1 +
include/linux/suspend.h | 2 +
include/linux/usb/composite.h | 3 +
include/net/ip.h | 11 ++-
include/net/ip_fib.h | 1 +
include/net/llc_conn.h | 2 +-
include/net/mac80211.h | 2 +-
include/net/regulatory.h | 2 +-
include/net/route.h | 3 +-
include/trace/events/timer.h | 20 ++++-
include/uapi/drm/virtgpu_drm.h | 1 +
include/uapi/linux/if_ether.h | 1 +
ipc/shm.c | 19 +++--
kernel/audit.c | 2 +
kernel/debug/kdb/kdb_main.c | 27 ++++--
kernel/events/core.c | 24 ++++--
kernel/locking/qspinlock.c | 8 ++
kernel/power/power.h | 3 -
kernel/relay.c | 2 +-
kernel/sched/rt.c | 2 +
kernel/signal.c | 4 +
kernel/sys.c | 3 +
kernel/workqueue.c | 2 +-
lib/test_bpf.c | 31 +++++--
mm/kasan/kasan.c | 2 +-
mm/kmemleak.c | 12 +--
mm/ksm.c | 28 +++++++
mm/mempolicy.c | 36 ++++++--
mm/swapfile.c | 4 +
mm/vmscan.c | 22 ++++-
net/batman-adv/distributed-arp-table.c | 2 +-
net/batman-adv/fragmentation.c | 3 +-
net/batman-adv/gateway_client.c | 3 +
net/batman-adv/multicast.c | 4 +-
net/batman-adv/soft-interface.c | 8 +-
net/bridge/netfilter/ebtables.c | 33 +++++---
net/core/skbuff.c | 9 +-
net/ipv4/ip_vti.c | 2 -
net/ipv4/route.c | 26 ++++--
net/ipv4/tcp_illinois.c | 2 +-
net/ipv4/xfrm4_policy.c | 1 +
net/ipv6/sit.c | 7 ++
net/llc/llc_c_ac.c | 15 ++--
net/llc/llc_conn.c | 32 +++++--
net/netlabel/netlabel_unlabeled.c | 10 +++
net/nfc/llcp_commands.c | 4 +
net/nfc/netlink.c | 3 +-
net/rds/ib.c | 3 +-
scripts/kconfig/expr.c | 2 +-
scripts/kconfig/menu.c | 1 +
scripts/kconfig/zconf.y | 33 ++++++--
security/integrity/ima/Kconfig | 1 +
security/integrity/ima/ima_crypto.c | 2 +
security/integrity/ima/ima_main.c | 13 +++
sound/core/timer.c | 4 +-
sound/core/vmaster.c | 5 +-
sound/pci/hda/Kconfig | 1 -
sound/pci/hda/patch_realtek.c | 5 ++
sound/soc/au1x/ac97c.c | 6 +-
sound/soc/samsung/i2s.c | 13 ++-
sound/soc/soc-topology.c | 3 +
tools/lib/bpf/libbpf.c | 26 ++++++
tools/lib/traceevent/event-parse.c | 17 ++--
tools/lib/traceevent/parse-filter.c | 10 ++-
tools/perf/tests/vmlinux-kallsyms.c | 2 +-
tools/perf/util/evsel.c | 8 +-
tools/perf/util/hist.c | 4 +-
tools/perf/util/hist.h | 1 -
tools/testing/selftests/Makefile | 1 +
.../ftrace/test.d/kprobe/kprobe_args_string.tc | 46 ++++++++++
.../ftrace/test.d/kprobe/kprobe_args_syntax.tc | 97 ++++++++++++++++++++++
.../selftests/ftrace/test.d/kprobe/probepoint.tc | 43 ++++++++++
tools/testing/selftests/memfd/config | 1 +
tools/testing/selftests/net/psock_fanout.c | 3 +-
tools/testing/selftests/powerpc/mm/subpage_prot.c | 14 ++++
tools/thermal/tmon/sysfs.c | 12 +--
tools/thermal/tmon/tmon.c | 1 -
292 files changed, 1883 insertions(+), 687 deletions(-)




2018-05-28 10:14:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 004/268] affs_lookup(): close a race with affs_remove_link()

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

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

From: Al Viro <[email protected]>

commit 30da870ce4a4e007c901858a96e9e394a1daa74a upstream.

we unlock the directory hash too early - if we are looking at secondary
link and primary (in another directory) gets removed just as we unlock,
we could have the old primary moved in place of the secondary, leaving
us to look into freed entry (and leaving our dentry with ->d_fsdata
pointing to a freed entry).

Cc: [email protected] # 2.4.4+
Acked-by: David Sterba <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/affs/namei.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)

--- a/fs/affs/namei.c
+++ b/fs/affs/namei.c
@@ -224,9 +224,10 @@ affs_lookup(struct inode *dir, struct de

affs_lock_dir(dir);
bh = affs_find_entry(dir, dentry);
- affs_unlock_dir(dir);
- if (IS_ERR(bh))
+ if (IS_ERR(bh)) {
+ affs_unlock_dir(dir);
return ERR_CAST(bh);
+ }
if (bh) {
u32 ino = bh->b_blocknr;

@@ -240,10 +241,13 @@ affs_lookup(struct inode *dir, struct de
}
affs_brelse(bh);
inode = affs_iget(sb, ino);
- if (IS_ERR(inode))
+ if (IS_ERR(inode)) {
+ affs_unlock_dir(dir);
return ERR_CAST(inode);
+ }
}
d_add(dentry, inode);
+ affs_unlock_dir(dir);
return NULL;
}




2018-05-28 10:15:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 018/268] firewire-ohci: work around oversized DMA reads on JMicron controllers

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

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

From: Hector Martin <[email protected]>

[ Upstream commit 188775181bc05f29372b305ef96485840e351fde ]

At least some JMicron controllers issue buggy oversized DMA reads when
fetching context descriptors, always fetching 0x20 bytes at once for
descriptors which are only 0x10 bytes long. This is often harmless, but
can cause page faults on modern systems with IOMMUs:

DMAR: [DMA Read] Request device [05:00.0] fault addr fff56000 [fault reason 06] PTE Read access is not set
firewire_ohci 0000:05:00.0: DMA context IT0 has stopped, error code: evt_descriptor_read

This works around the problem by always leaving 0x10 padding bytes at
the end of descriptor buffer pages, which should be harmless to do
unconditionally for controllers in case others have the same behavior.

Signed-off-by: Hector Martin <[email protected]>
Reviewed-by: Clemens Ladisch <[email protected]>
Signed-off-by: Stefan Richter <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/firewire/ohci.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -1130,7 +1130,13 @@ static int context_add_buffer(struct con
return -ENOMEM;

offset = (void *)&desc->buffer - (void *)desc;
- desc->buffer_size = PAGE_SIZE - offset;
+ /*
+ * Some controllers, like JMicron ones, always issue 0x20-byte DMA reads
+ * for descriptors, even 0x10-byte ones. This can cause page faults when
+ * an IOMMU is in use and the oversized read crosses a page boundary.
+ * Work around this by always leaving at least 0x10 bytes of padding.
+ */
+ desc->buffer_size = PAGE_SIZE - offset - 0x10;
desc->buffer_bus = bus_addr + offset;
desc->used = 0;




2018-05-28 10:15:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 023/268] tracing/hrtimer: Fix tracing bugs by taking all clock bases and modes into account

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

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

From: Anna-Maria Gleixner <[email protected]>

[ Upstream commit 91633eed73a3ac37aaece5c8c1f93a18bae616a9 ]

So far only CLOCK_MONOTONIC and CLOCK_REALTIME were taken into account as
well as HRTIMER_MODE_ABS/REL in the hrtimer_init tracepoint. The query for
detecting the ABS or REL timer modes is not valid anymore, it got broken
by the introduction of HRTIMER_MODE_PINNED.

HRTIMER_MODE_PINNED is not evaluated in the hrtimer_init() call, but for the
sake of completeness print all given modes.

Signed-off-by: Anna-Maria Gleixner <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: John Stultz <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/trace/events/timer.h | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)

--- a/include/trace/events/timer.h
+++ b/include/trace/events/timer.h
@@ -125,6 +125,20 @@ DEFINE_EVENT(timer_class, timer_cancel,
TP_ARGS(timer)
);

+#define decode_clockid(type) \
+ __print_symbolic(type, \
+ { CLOCK_REALTIME, "CLOCK_REALTIME" }, \
+ { CLOCK_MONOTONIC, "CLOCK_MONOTONIC" }, \
+ { CLOCK_BOOTTIME, "CLOCK_BOOTTIME" }, \
+ { CLOCK_TAI, "CLOCK_TAI" })
+
+#define decode_hrtimer_mode(mode) \
+ __print_symbolic(mode, \
+ { HRTIMER_MODE_ABS, "ABS" }, \
+ { HRTIMER_MODE_REL, "REL" }, \
+ { HRTIMER_MODE_ABS_PINNED, "ABS|PINNED" }, \
+ { HRTIMER_MODE_REL_PINNED, "REL|PINNED" })
+
/**
* hrtimer_init - called when the hrtimer is initialized
* @hrtimer: pointer to struct hrtimer
@@ -151,10 +165,8 @@ TRACE_EVENT(hrtimer_init,
),

TP_printk("hrtimer=%p clockid=%s mode=%s", __entry->hrtimer,
- __entry->clockid == CLOCK_REALTIME ?
- "CLOCK_REALTIME" : "CLOCK_MONOTONIC",
- __entry->mode == HRTIMER_MODE_ABS ?
- "HRTIMER_MODE_ABS" : "HRTIMER_MODE_REL")
+ decode_clockid(__entry->clockid),
+ decode_hrtimer_mode(__entry->mode))
);

/**



2018-05-28 10:15:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 025/268] tools lib traceevent: Simplify pointer print logic and fix %pF

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

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

From: "Steven Rostedt (VMware)" <[email protected]>

[ Upstream commit 38d70b7ca1769f26c0b79f3c08ff2cc949712b59 ]

When processing %pX in pretty_print(), simplify the logic slightly by
incrementing the ptr to the format string if isalnum(ptr[1]) is true.
This follows the logic a bit more closely to what is in the kernel.

Also, this fixes a small bug where %pF was not giving the offset of the
function.

Signed-off-by: Steven Rostedt <[email protected]>
Acked-by: Namhyung Kim <[email protected]>
Cc: Andrew Morton <[email protected]>
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/lib/traceevent/event-parse.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)

--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -4905,21 +4905,22 @@ static void pretty_print(struct trace_se
else
ls = 2;

- if (*(ptr+1) == 'F' || *(ptr+1) == 'f' ||
- *(ptr+1) == 'S' || *(ptr+1) == 's') {
+ if (isalnum(ptr[1]))
ptr++;
+
+ if (*ptr == 'F' || *ptr == 'f' ||
+ *ptr == 'S' || *ptr == 's') {
show_func = *ptr;
- } else if (*(ptr+1) == 'M' || *(ptr+1) == 'm') {
- print_mac_arg(s, *(ptr+1), data, size, event, arg);
- ptr++;
+ } else if (*ptr == 'M' || *ptr == 'm') {
+ print_mac_arg(s, *ptr, data, size, event, arg);
arg = arg->next;
break;
- } else if (*(ptr+1) == 'I' || *(ptr+1) == 'i') {
+ } else if (*ptr == 'I' || *ptr == 'i') {
int n;

- n = print_ip_arg(s, ptr+1, data, size, event, arg);
+ n = print_ip_arg(s, ptr, data, size, event, arg);
if (n > 0) {
- ptr += n;
+ ptr += n - 1;
arg = arg->next;
break;
}



2018-05-28 10:15:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 031/268] kconfig: Dont leak main menus during parsing

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

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

From: Ulf Magnusson <[email protected]>

[ Upstream commit 0724a7c32a54e3e50d28e19e30c59014f61d4e2c ]

If a 'mainmenu' entry appeared in the Kconfig files, two things would
leak:

- The 'struct property' allocated for the default "Linux Kernel
Configuration" prompt.

- The string for the T_WORD/T_WORD_QUOTE prompt after the
T_MAINMENU token, allocated on the heap in zconf.l.

To fix it, introduce a new 'no_mainmenu_stmt' nonterminal that matches
if there's no 'mainmenu' and adds the default prompt. That means the
prompt only gets allocated once regardless of whether there's a
'mainmenu' statement or not, and managing it becomes simple.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

LEAK SUMMARY:
definitely lost: 344,568 bytes in 14,352 blocks
...

Summary after the fix:

LEAK SUMMARY:
definitely lost: 344,440 bytes in 14,350 blocks
...

Signed-off-by: Ulf Magnusson <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
scripts/kconfig/zconf.y | 33 ++++++++++++++++++++++++---------
1 file changed, 24 insertions(+), 9 deletions(-)

--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -107,7 +107,27 @@ static struct menu *current_menu, *curre
%%
input: nl start | start;

-start: mainmenu_stmt stmt_list | stmt_list;
+start: mainmenu_stmt stmt_list | no_mainmenu_stmt stmt_list;
+
+/* mainmenu entry */
+
+mainmenu_stmt: T_MAINMENU prompt nl
+{
+ menu_add_prompt(P_MENU, $2, NULL);
+};
+
+/* Default main menu, if there's no mainmenu entry */
+
+no_mainmenu_stmt: /* empty */
+{
+ /*
+ * Hack: Keep the main menu title on the heap so we can safely free it
+ * later regardless of whether it comes from the 'prompt' in
+ * mainmenu_stmt or here
+ */
+ menu_add_prompt(P_MENU, strdup("Linux Kernel Configuration"), NULL);
+};
+

stmt_list:
/* empty */
@@ -344,13 +364,6 @@ if_block:
| if_block choice_stmt
;

-/* mainmenu entry */
-
-mainmenu_stmt: T_MAINMENU prompt nl
-{
- menu_add_prompt(P_MENU, $2, NULL);
-};
-
/* menu entry */

menu: T_MENU prompt T_EOL
@@ -495,6 +508,7 @@ word_opt: /* empty */ { $$ = NULL; }

void conf_parse(const char *name)
{
+ const char *tmp;
struct symbol *sym;
int i;

@@ -502,7 +516,6 @@ void conf_parse(const char *name)

sym_init();
_menu_init();
- rootmenu.prompt = menu_add_prompt(P_MENU, "Linux Kernel Configuration", NULL);

if (getenv("ZCONF_DEBUG"))
zconfdebug = 1;
@@ -512,8 +525,10 @@ void conf_parse(const char *name)
if (!modules_sym)
modules_sym = sym_find( "n" );

+ tmp = rootmenu.prompt->text;
rootmenu.prompt->text = _(rootmenu.prompt->text);
rootmenu.prompt->text = sym_expand_string_value(rootmenu.prompt->text);
+ free((char*)tmp);

menu_finalize(&rootmenu);
for_all_symbols(i, sym) {



2018-05-28 10:15:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 033/268] kconfig: Fix expr_free() E_NOT leak

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

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

From: Ulf Magnusson <[email protected]>

[ Upstream commit 5b1374b3b3c2fc4f63a398adfa446fb8eff791a4 ]

Only the E_NOT operand and not the E_NOT node itself was freed, due to
accidentally returning too early in expr_free(). Outline of leak:

switch (e->type) {
...
case E_NOT:
expr_free(e->left.expr);
return;
...
}
*Never reached, 'e' leaked*
free(e);

Fix by changing the 'return' to a 'break'.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

LEAK SUMMARY:
definitely lost: 44,448 bytes in 1,852 blocks
...

Summary after the fix:

LEAK SUMMARY:
definitely lost: 1,608 bytes in 67 blocks
...

Signed-off-by: Ulf Magnusson <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
scripts/kconfig/expr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/scripts/kconfig/expr.c
+++ b/scripts/kconfig/expr.c
@@ -113,7 +113,7 @@ void expr_free(struct expr *e)
break;
case E_NOT:
expr_free(e->left.expr);
- return;
+ break;
case E_EQUAL:
case E_GEQ:
case E_GTH:



2018-05-28 10:15:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 035/268] ipmi/powernv: Fix error return code in ipmi_powernv_probe()

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

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

From: Wei Yongjun <[email protected]>

[ Upstream commit e749d328b0b450aa78d562fa26a0cd8872325dd9 ]

Fix to return a negative error code from the request_irq() error
handling case instead of 0, as done elsewhere in this function.

Fixes: dce143c3381c ("ipmi/powernv: Convert to irq event interface")
Signed-off-by: Wei Yongjun <[email protected]>
Reviewed-by: Alexey Kardashevskiy <[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_powernv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/char/ipmi/ipmi_powernv.c
+++ b/drivers/char/ipmi/ipmi_powernv.c
@@ -251,8 +251,9 @@ static int ipmi_powernv_probe(struct pla
ipmi->irq = opal_event_request(prop);
}

- if (request_irq(ipmi->irq, ipmi_opal_event, IRQ_TYPE_LEVEL_HIGH,
- "opal-ipmi", ipmi)) {
+ rc = request_irq(ipmi->irq, ipmi_opal_event, IRQ_TYPE_LEVEL_HIGH,
+ "opal-ipmi", ipmi);
+ if (rc) {
dev_warn(dev, "Unable to request irq\n");
goto err_dispose;
}



2018-05-28 10:16:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 006/268] ALSA: timer: Fix pause event notification

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

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

From: Ben Hutchings <[email protected]>

commit 3ae180972564846e6d794e3615e1ab0a1e6c4ef9 upstream.

Commit f65e0d299807 ("ALSA: timer: Call notifier in the same spinlock")
combined the start/continue and stop/pause functions, and in doing so
changed the event code for the pause case to SNDRV_TIMER_EVENT_CONTINUE.
Change it back to SNDRV_TIMER_EVENT_PAUSE.

Fixes: f65e0d299807 ("ALSA: timer: Call notifier in the same spinlock")
Signed-off-by: Ben Hutchings <[email protected]>
Cc: [email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/core/timer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/sound/core/timer.c
+++ b/sound/core/timer.c
@@ -548,7 +548,7 @@ static int snd_timer_stop1(struct snd_ti
}
timeri->flags &= ~(SNDRV_TIMER_IFLG_RUNNING | SNDRV_TIMER_IFLG_START);
snd_timer_notify1(timeri, stop ? SNDRV_TIMER_EVENT_STOP :
- SNDRV_TIMER_EVENT_CONTINUE);
+ SNDRV_TIMER_EVENT_PAUSE);
unlock:
spin_unlock_irqrestore(&timer->lock, flags);
return result;
@@ -570,7 +570,7 @@ static int snd_timer_stop_slave(struct s
list_del_init(&timeri->ack_list);
list_del_init(&timeri->active_list);
snd_timer_notify1(timeri, stop ? SNDRV_TIMER_EVENT_STOP :
- SNDRV_TIMER_EVENT_CONTINUE);
+ SNDRV_TIMER_EVENT_PAUSE);
spin_unlock(&timeri->timer->lock);
}
spin_unlock_irqrestore(&slave_active_lock, flags);



2018-05-28 10:16:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 053/268] IB/ipoib: Fix for potential no-carrier state

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

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

From: Alex Estrin <[email protected]>

[ Upstream commit 1029361084d18cc270f64dfd39529fafa10cfe01 ]

On reboot SM can program port pkey table before ipoib registered its
event handler, which could result in missing pkey event and leave root
interface with initial pkey value from index 0.

Since OPA port starts with invalid pkey in index 0, root interface will
fail to initialize and stay down with no-carrier flag.

For IB ipoib interface may end up with pkey different from value
opensm put in pkey table idx 0, resulting in connectivity issues
(different mcast groups, for example).

Close the window by calling event handler after registration
to make sure ipoib pkey is in sync with port pkey table.

Reviewed-by: Mike Marciniszyn <[email protected]>
Reviewed-by: Ira Weiny <[email protected]>
Signed-off-by: Alex Estrin <[email protected]>
Signed-off-by: Dennis Dalessandro <[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 | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1953,6 +1953,9 @@ static struct net_device *ipoib_add_port
goto event_failed;
}

+ /* call event handler to ensure pkey in sync */
+ queue_work(ipoib_workqueue, &priv->flush_heavy);
+
result = register_netdev(priv->dev);
if (result) {
printk(KERN_WARNING "%s: couldn't register ipoib port %d; error %d\n",



2018-05-28 10:17:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 012/268] ipc/shm: fix shmat() nil address after round-down when remapping

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

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

From: Davidlohr Bueso <[email protected]>

commit 8f89c007b6dec16a1793cb88de88fcc02117bbbc upstream.

shmat()'s SHM_REMAP option forbids passing a nil address for; this is in
fact the very first thing we check for. Andrea reported that for
SHM_RND|SHM_REMAP cases we can end up bypassing the initial addr check,
but we need to check again if the address was rounded down to nil. As
of this patch, such cases will return -EINVAL.

Link: http://lkml.kernel.org/r/20180503204934.kk63josdu6u53fbd@linux-n805
Signed-off-by: Davidlohr Bueso <[email protected]>
Reported-by: Andrea Arcangeli <[email protected]>
Cc: Joe Lawrence <[email protected]>
Cc: Manfred Spraul <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
ipc/shm.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -1113,9 +1113,17 @@ long do_shmat(int shmid, char __user *sh
goto out;
else if ((addr = (ulong)shmaddr)) {
if (addr & (shmlba - 1)) {
- if (shmflg & SHM_RND)
+ if (shmflg & SHM_RND) {
addr &= ~(shmlba - 1); /* round down */
- else
+
+ /*
+ * Ensure that the round-down is non-nil
+ * when remapping. This can happen for
+ * cases when addr < shmlba.
+ */
+ if (!addr && (shmflg & SHM_REMAP))
+ goto out;
+ } else
#ifndef __ARCH_FORCE_SHMLBA
if (addr & ~PAGE_MASK)
#endif



2018-05-28 10:17:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 062/268] arm64: spinlock: Fix theoretical trylock() A-B-A with LSE atomics

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

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

From: Will Deacon <[email protected]>

[ Upstream commit 202fb4ef81e3ec765c23bd1e6746a5c25b797d0e ]

If the spinlock "next" ticket wraps around between the initial LDR
and the cmpxchg in the LSE version of spin_trylock, then we can erroneously
think that we have successfuly acquired the lock because we only check
whether the next ticket return by the cmpxchg is equal to the owner ticket
in our updated lock word.

This patch fixes the issue by performing a full 32-bit check of the lock
word when trying to determine whether or not the CASA instruction updated
memory.

Reported-by: Catalin Marinas <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Catalin Marinas <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/include/asm/spinlock.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm64/include/asm/spinlock.h
+++ b/arch/arm64/include/asm/spinlock.h
@@ -94,8 +94,8 @@ static inline int arch_spin_trylock(arch
" cbnz %w1, 1f\n"
" add %w1, %w0, %3\n"
" casa %w0, %w1, %2\n"
- " and %w1, %w1, #0xffff\n"
- " eor %w1, %w1, %w0, lsr #16\n"
+ " sub %w1, %w1, %3\n"
+ " eor %w1, %w1, %w0\n"
"1:")
: "=&r" (lockval), "=&r" (tmp), "+Q" (*lock)
: "I" (1 << TICKET_SHIFT)



2018-05-28 10:17:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 064/268] cifs: silence compiler warnings showing up with gcc-8.0.0

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

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

From: Arnd Bergmann <[email protected]>

[ Upstream commit ade7db991b47ab3016a414468164f4966bd08202 ]

This bug was fixed before, but came up again with the latest
compiler in another function:

fs/cifs/cifssmb.c: In function 'CIFSSMBSetEA':
fs/cifs/cifssmb.c:6362:3: error: 'strncpy' offset 8 is out of the bounds [0, 4] [-Werror=array-bounds]
strncpy(parm_data->list[0].name, ea_name, name_len);

Let's apply the same fix that was used for the other instances.

Fixes: b2a3ad9ca502 ("cifs: silence compiler warnings showing up with gcc-4.7.0")
Signed-off-by: Arnd Bergmann <[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/cifssmb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -6421,9 +6421,7 @@ SetEARetry:
pSMB->InformationLevel =
cpu_to_le16(SMB_SET_FILE_EA);

- parm_data =
- (struct fealist *) (((char *) &pSMB->hdr.Protocol) +
- offset);
+ parm_data = (void *)pSMB + offsetof(struct smb_hdr, Protocol) + offset;
pSMB->ParameterOffset = cpu_to_le16(param_offset);
pSMB->DataOffset = cpu_to_le16(offset);
pSMB->SetupCount = 1;



2018-05-28 10:18:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 077/268] ARC: Fix malformed ARC_EMUL_UNALIGNED default

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

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

From: Ulf Magnusson <[email protected]>

[ Upstream commit 827cc2fa024dd6517d62de7a44c7b42f32af371b ]

'default N' should be 'default n', though they happen to have the same
effect here, due to undefined symbols (N in this case) evaluating to n
in a tristate sense.

Remove the default from ARC_EMUL_UNALIGNED instead of changing it. bool
and tristate symbols implicitly default to n.

Discovered with the
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ulfalizer_Kconfiglib_blob_master_examples_list-5Fundefined.py&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=c14YS-cH-kdhTOW89KozFhBtBJgs1zXscZojEZQ0THs&m=WxxD8ozR7QQUVzNCBksiznaisBGO_crN7PBOvAoju8s&s=1LmxsNqxwT-7wcInVpZ6Z1J27duZKSoyKxHIJclXU_M&e=
script.

Signed-off-by: Ulf Magnusson <[email protected]>
Signed-off-by: Vineet Gupta <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arc/Kconfig | 1 -
1 file changed, 1 deletion(-)

--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -479,7 +479,6 @@ config ARC_CURR_IN_REG

config ARC_EMUL_UNALIGNED
bool "Emulate unaligned memory access (userspace only)"
- default N
select SYSCTL_ARCH_UNALIGN_NO_WARN
select SYSCTL_ARCH_UNALIGN_ALLOW
depends on ISA_ARCOMPACT



2018-05-28 10:18:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 092/268] drm/exynos: g2d: Delete an error message for a failed memory allocation in two functions

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

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

From: Markus Elfring <[email protected]>

[ Upstream commit 6f0a60298bbbea43ab5e3955913ab19c153076f3 ]

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -270,7 +270,6 @@ static int g2d_init_cmdlist(struct g2d_d

node = kcalloc(G2D_CMDLIST_NUM, sizeof(*node), GFP_KERNEL);
if (!node) {
- dev_err(dev, "failed to allocate memory\n");
ret = -ENOMEM;
goto err;
}
@@ -1254,10 +1253,9 @@ int exynos_g2d_exec_ioctl(struct drm_dev
return -EFAULT;

runqueue_node = kmem_cache_alloc(g2d->runqueue_slab, GFP_KERNEL);
- if (!runqueue_node) {
- dev_err(dev, "failed to allocate memory\n");
+ if (!runqueue_node)
return -ENOMEM;
- }
+
run_cmdlist = &runqueue_node->run_cmdlist;
event_list = &runqueue_node->event_list;
INIT_LIST_HEAD(run_cmdlist);



2018-05-28 10:18:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 047/268] ocfs2/acl: use ip_xattr_sem to protect getting extended attribute

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

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

From: piaojun <[email protected]>

[ Upstream commit 16c8d569f5704a84164f30ff01b29879f3438065 ]

The race between *set_acl and *get_acl will cause getting incomplete
xattr data as below:

processA processB

ocfs2_set_acl
ocfs2_xattr_set
__ocfs2_xattr_set_handle

ocfs2_get_acl_nolock
ocfs2_xattr_get_nolock:

processB may get incomplete xattr data if processA hasn't set_acl done.

So we should use 'ip_xattr_sem' to protect getting extended attribute in
ocfs2_get_acl_nolock(), as other processes could be changing it
concurrently.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Jun Piao <[email protected]>
Reviewed-by: Alex Chen <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Joel Becker <[email protected]>
Cc: Junxiao Bi <[email protected]>
Cc: Joseph Qi <[email protected]>
Cc: Changwei Ge <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ocfs2/acl.c | 6 ++++++
fs/ocfs2/xattr.c | 2 ++
2 files changed, 8 insertions(+)

--- a/fs/ocfs2/acl.c
+++ b/fs/ocfs2/acl.c
@@ -314,7 +314,9 @@ struct posix_acl *ocfs2_iop_get_acl(stru
return ERR_PTR(ret);
}

+ down_read(&OCFS2_I(inode)->ip_xattr_sem);
acl = ocfs2_get_acl_nolock(inode, type, di_bh);
+ up_read(&OCFS2_I(inode)->ip_xattr_sem);

ocfs2_inode_unlock(inode, 0);
brelse(di_bh);
@@ -333,7 +335,9 @@ int ocfs2_acl_chmod(struct inode *inode,
if (!(osb->s_mount_opt & OCFS2_MOUNT_POSIX_ACL))
return 0;

+ down_read(&OCFS2_I(inode)->ip_xattr_sem);
acl = ocfs2_get_acl_nolock(inode, ACL_TYPE_ACCESS, bh);
+ up_read(&OCFS2_I(inode)->ip_xattr_sem);
if (IS_ERR(acl) || !acl)
return PTR_ERR(acl);
ret = __posix_acl_chmod(&acl, GFP_KERNEL, inode->i_mode);
@@ -364,8 +368,10 @@ int ocfs2_init_acl(handle_t *handle,

if (!S_ISLNK(inode->i_mode)) {
if (osb->s_mount_opt & OCFS2_MOUNT_POSIX_ACL) {
+ down_read(&OCFS2_I(dir)->ip_xattr_sem);
acl = ocfs2_get_acl_nolock(dir, ACL_TYPE_DEFAULT,
dir_bh);
+ up_read(&OCFS2_I(dir)->ip_xattr_sem);
if (IS_ERR(acl))
return PTR_ERR(acl);
}
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -639,9 +639,11 @@ int ocfs2_calc_xattr_init(struct inode *
si->value_len);

if (osb->s_mount_opt & OCFS2_MOUNT_POSIX_ACL) {
+ down_read(&OCFS2_I(dir)->ip_xattr_sem);
acl_len = ocfs2_xattr_get_nolock(dir, dir_bh,
OCFS2_XATTR_INDEX_POSIX_ACL_DEFAULT,
"", NULL, 0);
+ up_read(&OCFS2_I(dir)->ip_xattr_sem);
if (acl_len > 0) {
a_size = ocfs2_xattr_entry_real_size(0, acl_len);
if (S_ISDIR(mode))



2018-05-28 10:18:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 068/268] bcache: return attach error when no cache set exist

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

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

From: Tang Junhui <[email protected]>

[ Upstream commit 7f4fc93d4713394ee8f1cd44c238e046e11b4f15 ]

I attach a back-end device to a cache set, and the cache set is not
registered yet, this back-end device did not attach successfully, and no
error returned:
[root]# echo 87859280-fec6-4bcc-20df7ca8f86b > /sys/block/sde/bcache/attach
[root]#

In sysfs_attach(), the return value "v" is initialized to "size" in
the beginning, and if no cache set exist in bch_cache_sets, the "v" value
would not change any more, and return to sysfs, sysfs regard it as success
since the "size" is a positive number.

This patch fixes this issue by assigning "v" with "-ENOENT" in the
initialization.

Signed-off-by: Tang Junhui <[email protected]>
Reviewed-by: Michael Lyle <[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/md/bcache/sysfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -191,7 +191,7 @@ STORE(__cached_dev)
{
struct cached_dev *dc = container_of(kobj, struct cached_dev,
disk.kobj);
- ssize_t v = size;
+ ssize_t v;
struct cache_set *c;
struct kobj_uevent_env *env;

@@ -268,6 +268,7 @@ STORE(__cached_dev)
if (bch_parse_uuid(buf, set_uuid) < 16)
return -EINVAL;

+ v = -ENOENT;
list_for_each_entry(c, &bch_cache_sets, list) {
v = bch_cached_dev_attach(dc, c, set_uuid);
if (!v)
@@ -275,7 +276,7 @@ STORE(__cached_dev)
}

pr_err("Can't attach %s: cache set not found", buf);
- size = v;
+ return v;
}

if (attr == &sysfs_detach && dc->disk.c)



2018-05-28 10:18:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 094/268] locking/xchg/alpha: Add unconditional memory barrier to cmpxchg()

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

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

From: Andrea Parri <[email protected]>

[ Upstream commit cb13b424e986aed68d74cbaec3449ea23c50e167 ]

Continuing along with the fight against smp_read_barrier_depends() [1]
(or rather, against its improper use), add an unconditional barrier to
cmpxchg. This guarantees that dependency ordering is preserved when a
dependency is headed by an unsuccessful cmpxchg. As it turns out, the
change could enable further simplification of LKMM as proposed in [2].

[1] https://marc.info/?l=linux-kernel&m=150884953419377&w=2
https://marc.info/?l=linux-kernel&m=150884946319353&w=2
https://marc.info/?l=linux-kernel&m=151215810824468&w=2
https://marc.info/?l=linux-kernel&m=151215816324484&w=2

[2] https://marc.info/?l=linux-kernel&m=151881978314872&w=2

Signed-off-by: Andrea Parri <[email protected]>
Acked-by: Peter Zijlstra <[email protected]>
Acked-by: Paul E. McKenney <[email protected]>
Cc: Alan Stern <[email protected]>
Cc: Ivan Kokshaysky <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Matt Turner <[email protected]>
Cc: Richard Henderson <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/alpha/include/asm/xchg.h | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)

--- a/arch/alpha/include/asm/xchg.h
+++ b/arch/alpha/include/asm/xchg.h
@@ -127,10 +127,9 @@ ____xchg(, volatile void *ptr, unsigned
* store NEW in MEM. Return the initial value in MEM. Success is
* indicated by comparing RETURN with OLD.
*
- * The memory barrier should be placed in SMP only when we actually
- * make the change. If we don't change anything (so if the returned
- * prev is equal to old) then we aren't acquiring anything new and
- * we don't need any memory barrier as far I can tell.
+ * The memory barrier is placed in SMP unconditionally, in order to
+ * guarantee that dependency ordering is preserved when a dependency
+ * is headed by an unsuccessful operation.
*/

static inline unsigned long
@@ -149,8 +148,8 @@ ____cmpxchg(_u8, volatile char *m, unsig
" or %1,%2,%2\n"
" stq_c %2,0(%4)\n"
" beq %2,3f\n"
- __ASM__MB
"2:\n"
+ __ASM__MB
".subsection 2\n"
"3: br 1b\n"
".previous"
@@ -176,8 +175,8 @@ ____cmpxchg(_u16, volatile short *m, uns
" or %1,%2,%2\n"
" stq_c %2,0(%4)\n"
" beq %2,3f\n"
- __ASM__MB
"2:\n"
+ __ASM__MB
".subsection 2\n"
"3: br 1b\n"
".previous"
@@ -199,8 +198,8 @@ ____cmpxchg(_u32, volatile int *m, int o
" mov %4,%1\n"
" stl_c %1,%2\n"
" beq %1,3f\n"
- __ASM__MB
"2:\n"
+ __ASM__MB
".subsection 2\n"
"3: br 1b\n"
".previous"
@@ -222,8 +221,8 @@ ____cmpxchg(_u64, volatile long *m, unsi
" mov %4,%1\n"
" stq_c %1,%2\n"
" beq %1,3f\n"
- __ASM__MB
"2:\n"
+ __ASM__MB
".subsection 2\n"
"3: br 1b\n"
".previous"



2018-05-28 10:18:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 078/268] usb: gadget: f_uac2: fix bFirstInterface in composite gadget

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

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

From: John Keeping <[email protected]>

[ Upstream commit 8813a59ed892305b5ac1b5b901740b1ad4b5fefa ]

If there are multiple functions associated with a configuration, then
the UAC2 interfaces may not start at zero. Set the correct first
interface number in the association descriptor so that the audio
interfaces are enumerated correctly in this case.

Reviewed-by: Krzysztof Opasiak <[email protected]>
Signed-off-by: John Keeping <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/function/f_uac2.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/usb/gadget/function/f_uac2.c
+++ b/drivers/usb/gadget/function/f_uac2.c
@@ -1052,6 +1052,8 @@ afunc_bind(struct usb_configuration *cfg
dev_err(dev, "%s:%d Error!\n", __func__, __LINE__);
return ret;
}
+ iad_desc.bFirstInterface = ret;
+
std_ac_if_desc.bInterfaceNumber = ret;
agdev->ac_intf = ret;
agdev->ac_alt = 0;



2018-05-28 10:18:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 073/268] scsi: bnx2fc: Fix check in SCSI completion handler for timed out request

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

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

From: Chad Dupuis <[email protected]>

[ Upstream commit ecf7ff49945f5741fa1da112f994939f942031d3 ]

When a request times out we set the io_req flag BNX2FC_FLAG_IO_COMPL so
that if a subsequent completion comes in on that task ID we will ignore
it. The issue is that in the check for this flag there is a missing
return so we will continue to process a request which may have already
been returned to the ownership of the SCSI layer. This can cause
unpredictable results.

Solution is to add in the missing return.

[mkp: typo plus title shortening]

Signed-off-by: Chad Dupuis <[email protected]>
Reviewed-by: Laurence Oberman <[email protected]>
Tested-by: Laurence Oberman <[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/bnx2fc/bnx2fc_io.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/scsi/bnx2fc/bnx2fc_io.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_io.c
@@ -1858,6 +1858,7 @@ void bnx2fc_process_scsi_cmd_compl(struc
/* we will not receive ABTS response for this IO */
BNX2FC_IO_DBG(io_req, "Timer context finished processing "
"this scsi cmd\n");
+ return;
}

/* Cancel the timeout_work, as we received IO completion */



2018-05-28 10:19:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 104/268] x86/topology: Update the cpu cores field in /proc/cpuinfo correctly across CPU hotplug operations

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

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

From: Samuel Neves <[email protected]>

[ Upstream commit 4596749339e06dc7a424fc08a15eded850ed78b7 ]

Without this fix, /proc/cpuinfo will display an incorrect amount
of CPU cores, after bringing them offline and online again, as
exemplified below:

$ cat /proc/cpuinfo | grep cores
cpu cores : 4
cpu cores : 8
cpu cores : 8
cpu cores : 20
cpu cores : 4
cpu cores : 3
cpu cores : 2
cpu cores : 2

This patch fixes this by always zeroing the booted_cores variable
upon turning off a logical CPU.

Tested-by: Dou Liyang <[email protected]>
Signed-off-by: Samuel Neves <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/smpboot.c | 1 +
1 file changed, 1 insertion(+)

--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1344,6 +1344,7 @@ static void remove_siblinginfo(int cpu)
cpumask_clear(topology_core_cpumask(cpu));
c->phys_proc_id = 0;
c->cpu_core_id = 0;
+ c->booted_cores = 0;
cpumask_clear_cpu(cpu, cpu_sibling_setup_mask);
}




2018-05-28 10:19:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 107/268] batman-adv: fix packet checksum in receive path

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

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

From: Matthias Schiffer <[email protected]>

[ Upstream commit abd6360591d3f8259f41c34e31ac4826dfe621b8 ]

eth_type_trans() internally calls skb_pull(), which does not adjust the
skb checksum; skb_postpull_rcsum() is necessary to avoid log spam of the
form "bat0: hw csum failure" when packets with CHECKSUM_COMPLETE are
received.

Note that in usual setups, packets don't reach batman-adv with
CHECKSUM_COMPLETE (I assume NICs bail out of checksumming when they see
batadv's ethtype?), which is why the log messages do not occur on every
system using batman-adv. I could reproduce this issue by stacking
batman-adv on top of a VXLAN interface.

Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol")
Tested-by: Maximilian Wilhelm <[email protected]>
Signed-off-by: Matthias Schiffer <[email protected]>
Signed-off-by: Sven Eckelmann <[email protected]>
Signed-off-by: Simon Wunderlich <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/batman-adv/soft-interface.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)

--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -430,13 +430,7 @@ void batadv_interface_rx(struct net_devi

/* skb->dev & skb->pkt_type are set here */
skb->protocol = eth_type_trans(skb, soft_iface);
-
- /* should not be necessary anymore as we use skb_pull_rcsum()
- * TODO: please verify this and remove this TODO
- * -- Dec 21st 2009, Simon Wunderlich
- */
-
- /* skb->ip_summed = CHECKSUM_UNNECESSARY; */
+ skb_postpull_rcsum(skb, eth_hdr(skb), ETH_HLEN);

batadv_inc_counter(bat_priv, BATADV_CNT_RX);
batadv_add_counter(bat_priv, BATADV_CNT_RX_BYTES,



2018-05-28 10:19:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 120/268] Btrfs: send, fix issuing write op when processing hole in no data mode

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

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

From: Filipe Manana <[email protected]>

[ Upstream commit d4dfc0f4d39475ccbbac947880b5464a74c30b99 ]

When doing an incremental send of a filesystem with the no-holes feature
enabled, we end up issuing a write operation when using the no data mode
send flag, instead of issuing an update extent operation. Fix this by
issuing the update extent operation instead.

Trivial reproducer:

$ mkfs.btrfs -f -O no-holes /dev/sdc
$ mkfs.btrfs -f /dev/sdd
$ mount /dev/sdc /mnt/sdc
$ mount /dev/sdd /mnt/sdd

$ xfs_io -f -c "pwrite -S 0xab 0 32K" /mnt/sdc/foobar
$ btrfs subvolume snapshot -r /mnt/sdc /mnt/sdc/snap1

$ xfs_io -c "fpunch 8K 8K" /mnt/sdc/foobar
$ btrfs subvolume snapshot -r /mnt/sdc /mnt/sdc/snap2

$ btrfs send /mnt/sdc/snap1 | btrfs receive /mnt/sdd
$ btrfs send --no-data -p /mnt/sdc/snap1 /mnt/sdc/snap2 \
| btrfs receive -vv /mnt/sdd

Before this change the output of the second receive command is:

receiving snapshot snap2 uuid=f6922049-8c22-e544-9ff9-fc6755918447...
utimes
write foobar, offset 8192, len 8192
utimes foobar
BTRFS_IOC_SET_RECEIVED_SUBVOL uuid=f6922049-8c22-e544-9ff9-...

After this change it is:

receiving snapshot snap2 uuid=564d36a3-ebc8-7343-aec9-bf6fda278e64...
utimes
update_extent foobar: offset=8192, len=8192
utimes foobar
BTRFS_IOC_SET_RECEIVED_SUBVOL uuid=564d36a3-ebc8-7343-aec9-bf6fda278e64...

Signed-off-by: Filipe Manana <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/send.c | 3 +++
1 file changed, 3 insertions(+)

--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -4674,6 +4674,9 @@ static int send_hole(struct send_ctx *sc
u64 len;
int ret = 0;

+ if (sctx->flags & BTRFS_SEND_FLAG_NO_FILE_DATA)
+ return send_update_extent(sctx, offset, end - offset);
+
p = fs_path_alloc();
if (!p)
return -ENOMEM;



2018-05-28 10:20:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 121/268] selftests/powerpc: Skip the subpage_prot tests if the syscall is unavailable

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

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

From: Michael Ellerman <[email protected]>

[ Upstream commit cd4a6f3ab4d80cb919d15897eb3cbc85c2009d4b ]

The subpage_prot syscall is only functional when the system is using
the Hash MMU. Since commit 5b2b80714796 ("powerpc/mm: Invalidate
subpage_prot() system call on radix platforms") it returns ENOENT when
the Radix MMU is active. Currently this just makes the test fail.

Additionally the syscall is not available if the kernel is built with
4K pages, or if CONFIG_PPC_SUBPAGE_PROT=n, in which case it returns
ENOSYS because the syscall is missing entirely.

So check explicitly for ENOENT and ENOSYS and skip if we see either of
those.

Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/testing/selftests/powerpc/mm/subpage_prot.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)

--- a/tools/testing/selftests/powerpc/mm/subpage_prot.c
+++ b/tools/testing/selftests/powerpc/mm/subpage_prot.c
@@ -135,6 +135,16 @@ static int run_test(void *addr, unsigned
return 0;
}

+static int syscall_available(void)
+{
+ int rc;
+
+ errno = 0;
+ rc = syscall(__NR_subpage_prot, 0, 0, 0);
+
+ return rc == 0 || (errno != ENOENT && errno != ENOSYS);
+}
+
int test_anon(void)
{
unsigned long align;
@@ -145,6 +155,8 @@ int test_anon(void)
void *mallocblock;
unsigned long mallocsize;

+ SKIP_IF(!syscall_available());
+
if (getpagesize() != 0x10000) {
fprintf(stderr, "Kernel page size must be 64K!\n");
return 1;
@@ -180,6 +192,8 @@ int test_file(void)
off_t filesize;
int fd;

+ SKIP_IF(!syscall_available());
+
fd = open(file_name, O_RDWR);
if (fd == -1) {
perror("failed to open file");



2018-05-28 10:20:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 084/268] scsi: qla4xxx: skip error recovery in case of register disconnect.

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

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

From: Manish Rangankar <[email protected]>

[ Upstream commit 1bc5ad3a6acdcf56f83272f2de1cd2389ea9e9e2 ]

A system crashes when continuously removing/re-adding the storage
controller.

Signed-off-by: Manish Rangankar <[email protected]>
Reviewed-by: Ewan D. Milne <[email protected]>
Reviewed-by: Tomas Henzl <[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/qla4xxx/ql4_def.h | 2 +
drivers/scsi/qla4xxx/ql4_os.c | 46 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+)

--- a/drivers/scsi/qla4xxx/ql4_def.h
+++ b/drivers/scsi/qla4xxx/ql4_def.h
@@ -168,6 +168,8 @@
#define DEV_DB_NON_PERSISTENT 0
#define DEV_DB_PERSISTENT 1

+#define QL4_ISP_REG_DISCONNECT 0xffffffffU
+
#define COPY_ISID(dst_isid, src_isid) { \
int i, j; \
for (i = 0, j = ISID_SIZE - 1; i < ISID_SIZE;) \
--- a/drivers/scsi/qla4xxx/ql4_os.c
+++ b/drivers/scsi/qla4xxx/ql4_os.c
@@ -262,6 +262,24 @@ static struct iscsi_transport qla4xxx_is

static struct scsi_transport_template *qla4xxx_scsi_transport;

+static int qla4xxx_isp_check_reg(struct scsi_qla_host *ha)
+{
+ u32 reg_val = 0;
+ int rval = QLA_SUCCESS;
+
+ if (is_qla8022(ha))
+ reg_val = readl(&ha->qla4_82xx_reg->host_status);
+ else if (is_qla8032(ha) || is_qla8042(ha))
+ reg_val = qla4_8xxx_rd_direct(ha, QLA8XXX_PEG_ALIVE_COUNTER);
+ else
+ reg_val = readw(&ha->reg->ctrl_status);
+
+ if (reg_val == QL4_ISP_REG_DISCONNECT)
+ rval = QLA_ERROR;
+
+ return rval;
+}
+
static int qla4xxx_send_ping(struct Scsi_Host *shost, uint32_t iface_num,
uint32_t iface_type, uint32_t payload_size,
uint32_t pid, struct sockaddr *dst_addr)
@@ -9196,10 +9214,17 @@ static int qla4xxx_eh_abort(struct scsi_
struct srb *srb = NULL;
int ret = SUCCESS;
int wait = 0;
+ int rval;

ql4_printk(KERN_INFO, ha, "scsi%ld:%d:%llu: Abort command issued cmd=%p, cdb=0x%x\n",
ha->host_no, id, lun, cmd, cmd->cmnd[0]);

+ rval = qla4xxx_isp_check_reg(ha);
+ if (rval != QLA_SUCCESS) {
+ ql4_printk(KERN_INFO, ha, "PCI/Register disconnect, exiting.\n");
+ return FAILED;
+ }
+
spin_lock_irqsave(&ha->hardware_lock, flags);
srb = (struct srb *) CMD_SP(cmd);
if (!srb) {
@@ -9251,6 +9276,7 @@ static int qla4xxx_eh_device_reset(struc
struct scsi_qla_host *ha = to_qla_host(cmd->device->host);
struct ddb_entry *ddb_entry = cmd->device->hostdata;
int ret = FAILED, stat;
+ int rval;

if (!ddb_entry)
return ret;
@@ -9270,6 +9296,12 @@ static int qla4xxx_eh_device_reset(struc
cmd, jiffies, cmd->request->timeout / HZ,
ha->dpc_flags, cmd->result, cmd->allowed));

+ rval = qla4xxx_isp_check_reg(ha);
+ if (rval != QLA_SUCCESS) {
+ ql4_printk(KERN_INFO, ha, "PCI/Register disconnect, exiting.\n");
+ return FAILED;
+ }
+
/* FIXME: wait for hba to go online */
stat = qla4xxx_reset_lun(ha, ddb_entry, cmd->device->lun);
if (stat != QLA_SUCCESS) {
@@ -9313,6 +9345,7 @@ static int qla4xxx_eh_target_reset(struc
struct scsi_qla_host *ha = to_qla_host(cmd->device->host);
struct ddb_entry *ddb_entry = cmd->device->hostdata;
int stat, ret;
+ int rval;

if (!ddb_entry)
return FAILED;
@@ -9330,6 +9363,12 @@ static int qla4xxx_eh_target_reset(struc
ha->host_no, cmd, jiffies, cmd->request->timeout / HZ,
ha->dpc_flags, cmd->result, cmd->allowed));

+ rval = qla4xxx_isp_check_reg(ha);
+ if (rval != QLA_SUCCESS) {
+ ql4_printk(KERN_INFO, ha, "PCI/Register disconnect, exiting.\n");
+ return FAILED;
+ }
+
stat = qla4xxx_reset_target(ha, ddb_entry);
if (stat != QLA_SUCCESS) {
starget_printk(KERN_INFO, scsi_target(cmd->device),
@@ -9384,9 +9423,16 @@ static int qla4xxx_eh_host_reset(struct
{
int return_status = FAILED;
struct scsi_qla_host *ha;
+ int rval;

ha = to_qla_host(cmd->device->host);

+ rval = qla4xxx_isp_check_reg(ha);
+ if (rval != QLA_SUCCESS) {
+ ql4_printk(KERN_INFO, ha, "PCI/Register disconnect, exiting.\n");
+ return FAILED;
+ }
+
if ((is_qla8032(ha) || is_qla8042(ha)) && ql4xdontresethba)
qla4_83xx_set_idc_dontreset(ha);




2018-05-28 10:21:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 144/268] mm/mempolicy.c: avoid use uninitialized preferred_node

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

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

From: Yisheng Xie <[email protected]>

[ Upstream commit 8970a63e965b43288c4f5f40efbc2bbf80de7f16 ]

Alexander reported a use of uninitialized memory in __mpol_equal(),
which is caused by incorrect use of preferred_node.

When mempolicy in mode MPOL_PREFERRED with flags MPOL_F_LOCAL, it uses
numa_node_id() instead of preferred_node, however, __mpol_equal() uses
preferred_node without checking whether it is MPOL_F_LOCAL or not.

[[email protected]: slight comment tweak]
Link: http://lkml.kernel.org/r/[email protected]
Fixes: fc36b8d3d819 ("mempolicy: use MPOL_F_LOCAL to Indicate Preferred Local Policy")
Signed-off-by: Yisheng Xie <[email protected]>
Reported-by: Alexander Potapenko <[email protected]>
Tested-by: Alexander Potapenko <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Cc: Dmitriy Vyukov <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/mempolicy.c | 3 +++
1 file changed, 3 insertions(+)

--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2142,6 +2142,9 @@ bool __mpol_equal(struct mempolicy *a, s
case MPOL_INTERLEAVE:
return !!nodes_equal(a->v.nodes, b->v.nodes);
case MPOL_PREFERRED:
+ /* a's ->flags is the same as b's */
+ if (a->flags & MPOL_F_LOCAL)
+ return true;
return a->v.preferred_node == b->v.preferred_node;
default:
BUG();



2018-05-28 10:21:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 146/268] selftests: ftrace: Add a testcase for string type with kprobe_event

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

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

From: Masami Hiramatsu <[email protected]>

[ Upstream commit 5fbdbed797b6d12d043a5121fdbc8d8b49d10e80 ]

Add a testcase for string type with kprobe event.
This tests good/bad syntax combinations and also
the traced data is correct in several way.

Link: http://lkml.kernel.org/r/152129038381.31874.9201387794548737554.stgit@devbox

Signed-off-by: Masami Hiramatsu <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc | 46 ++++++++++
1 file changed, 46 insertions(+)
create mode 100644 tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc

--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc
@@ -0,0 +1,46 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+# description: Kprobe event string type argument
+
+[ -f kprobe_events ] || exit_unsupported # this is configurable
+
+echo 0 > events/enable
+echo > kprobe_events
+
+case `uname -m` in
+x86_64)
+ ARG2=%si
+ OFFS=8
+;;
+i[3456]86)
+ ARG2=%cx
+ OFFS=4
+;;
+aarch64)
+ ARG2=%x1
+ OFFS=8
+;;
+arm*)
+ ARG2=%r1
+ OFFS=4
+;;
+*)
+ echo "Please implement other architecture here"
+ exit_untested
+esac
+
+: "Test get argument (1)"
+echo "p:testprobe create_trace_kprobe arg1=+0(+0(${ARG2})):string" > kprobe_events
+echo 1 > events/kprobes/testprobe/enable
+! echo test >> kprobe_events
+tail -n 1 trace | grep -qe "testprobe.* arg1=\"test\""
+
+echo 0 > events/kprobes/testprobe/enable
+: "Test get argument (2)"
+echo "p:testprobe create_trace_kprobe arg1=+0(+0(${ARG2})):string arg2=+0(+${OFFS}(${ARG2})):string" > kprobe_events
+echo 1 > events/kprobes/testprobe/enable
+! echo test1 test2 >> kprobe_events
+tail -n 1 trace | grep -qe "testprobe.* arg1=\"test1\" arg2=\"test2\""
+
+echo 0 > events/enable
+echo > kprobe_events



2018-05-28 10:22:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 140/268] vti4: Dont count header length twice on tunnel setup

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

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

From: Stefano Brivio <[email protected]>

[ Upstream commit dd1df24737727e119c263acf1be2a92763938297 ]

This re-introduces the effect of commit a32452366b72 ("vti4:
Don't count header length twice.") which was accidentally
reverted by merge commit f895f0cfbb77 ("Merge branch 'master' of
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec").

The commit message from Steffen Klassert said:

We currently count the size of LL_MAX_HEADER and struct iphdr
twice for vti4 devices, this leads to a wrong device mtu.
The size of LL_MAX_HEADER and struct iphdr is already counted in
ip_tunnel_bind_dev(), so don't do it again in vti_tunnel_init().

And this is still the case now: ip_tunnel_bind_dev() already
accounts for the header length of the link layer (not
necessarily LL_MAX_HEADER, if the output device is found), plus
one IP header.

For example, with a vti device on top of veth, with MTU of 1500,
the existing implementation would set the initial vti MTU to
1332, accounting once for LL_MAX_HEADER (128, included in
hard_header_len by vti) and twice for the same IP header (once
from hard_header_len, once from ip_tunnel_bind_dev()).

It should instead be 1480, because ip_tunnel_bind_dev() is able
to figure out that the output device is veth, so no additional
link layer header is attached, and will properly count one
single IP header.

The existing issue had the side effect of avoiding PMTUD for
most xfrm policies, by arbitrarily lowering the initial MTU.
However, the only way to get a consistent PMTU value is to let
the xfrm PMTU discovery do its course, and commit d6af1a31cc72
("vti: Add pmtu handling to vti_xmit.") now takes care of local
delivery cases where the application ignores local socket
notifications.

Fixes: b9959fd3b0fa ("vti: switch to new ip tunnel code")
Fixes: f895f0cfbb77 ("Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec")
Signed-off-by: Stefano Brivio <[email protected]>
Acked-by: Sabrina Dubroca <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/ip_vti.c | 1 -
1 file changed, 1 deletion(-)

--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -366,7 +366,6 @@ static int vti_tunnel_init(struct net_de
memcpy(dev->dev_addr, &iph->saddr, 4);
memcpy(dev->broadcast, &iph->daddr, 4);

- dev->hard_header_len = LL_MAX_HEADER + sizeof(struct iphdr);
dev->mtu = ETH_DATA_LEN;
dev->flags = IFF_NOARP;
dev->addr_len = 4;



2018-05-28 10:22:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 178/268] net: bgmac: Fix endian access in bgmac_dma_tx_ring_free()

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

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

From: Florian Fainelli <[email protected]>

[ Upstream commit 60d6e6f0b9e422dd01aeda39257ee0428e5e2a3f ]

bgmac_dma_tx_ring_free() assigns the ctl1 word which is a litle endian
32-bit word without using proper accessors, fix this, and because a
length cannot be negative, use unsigned int while at it.

Fixes: 9cde94506eac ("bgmac: implement scatter/gather support")
Signed-off-by: Florian Fainelli <[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/broadcom/bgmac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -531,7 +531,8 @@ static void bgmac_dma_tx_ring_free(struc
int i;

for (i = 0; i < BGMAC_TX_RING_SLOTS; i++) {
- int len = dma_desc[i].ctl1 & BGMAC_DESC_CTL1_LEN;
+ u32 ctl1 = le32_to_cpu(dma_desc[i].ctl1);
+ unsigned int len = ctl1 & BGMAC_DESC_CTL1_LEN;

slot = &ring->slots[i];
dev_kfree_skb(slot->skb);



2018-05-28 10:23:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 157/268] net: mvneta: fix enable of all initialized RXQs

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

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

From: Yelena Krivosheev <[email protected]>

[ Upstream commit e81b5e01c14add8395dfba7130f8829206bb507d ]

In mvneta_port_up() we enable relevant RX and TX port queues by write
queues bit map to an appropriate register.

q_map must be ZERO in the beginning of this process.

Signed-off-by: Yelena Krivosheev <[email protected]>
Acked-by: Thomas Petazzoni <[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/marvell/mvneta.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -818,6 +818,7 @@ static void mvneta_port_up(struct mvneta
}
mvreg_write(pp, MVNETA_TXQ_CMD, q_map);

+ q_map = 0;
/* Enable all initialized RXQs. */
mvreg_write(pp, MVNETA_RXQ_CMD, BIT(rxq_def));
}



2018-05-28 10:23:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 160/268] fs/proc/proc_sysctl.c: fix potential page fault while unregistering sysctl table

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

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

From: Danilo Krummrich <[email protected]>

[ Upstream commit a0b0d1c345d0317efe594df268feb5ccc99f651e ]

proc_sys_link_fill_cache() does not take currently unregistering sysctl
tables into account, which might result into a page fault in
sysctl_follow_link() - add a check to fix it.

This bug has been present since v3.4.

Link: http://lkml.kernel.org/r/[email protected]
Fixes: 0e47c99d7fe25 ("sysctl: Replace root_list with links between sysctl_table_sets")
Signed-off-by: Danilo Krummrich <[email protected]>
Acked-by: Kees Cook <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Cc: "Luis R . Rodriguez" <[email protected]>
Cc: "Eric W. Biederman" <[email protected]>
Cc: Alexey Dobriyan <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/proc/proc_sysctl.c | 3 +++
1 file changed, 3 insertions(+)

--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -654,7 +654,10 @@ static bool proc_sys_link_fill_cache(str
struct ctl_table *table)
{
bool ret = true;
+
head = sysctl_head_grab(head);
+ if (IS_ERR(head))
+ return false;

if (S_ISLNK(table->mode)) {
/* It is not an error if we can not follow the link ignore it */



2018-05-28 10:23:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 145/268] selftests: ftrace: Add probe event argument syntax testcase

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

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

From: Masami Hiramatsu <[email protected]>

[ Upstream commit 871bef2000968c312a4000b2f56d370dcedbc93c ]

Add a testcase for probe event argument syntax which
ensures the kprobe_events interface correctly parses
given event arguments.

Link: http://lkml.kernel.org/r/152129033679.31874.12705519603869152799.stgit@devbox

Signed-off-by: Masami Hiramatsu <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_syntax.tc | 97 ++++++++++
1 file changed, 97 insertions(+)
create mode 100644 tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_syntax.tc

--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_syntax.tc
@@ -0,0 +1,97 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+# description: Kprobe event argument syntax
+
+[ -f kprobe_events ] || exit_unsupported # this is configurable
+
+grep "x8/16/32/64" README > /dev/null || exit_unsupported # version issue
+
+echo 0 > events/enable
+echo > kprobe_events
+
+PROBEFUNC="vfs_read"
+GOODREG=
+BADREG=
+GOODSYM="_sdata"
+if ! grep -qw ${GOODSYM} /proc/kallsyms ; then
+ GOODSYM=$PROBEFUNC
+fi
+BADSYM="deaqswdefr"
+SYMADDR=0x`grep -w ${GOODSYM} /proc/kallsyms | cut -f 1 -d " "`
+GOODTYPE="x16"
+BADTYPE="y16"
+
+case `uname -m` in
+x86_64|i[3456]86)
+ GOODREG=%ax
+ BADREG=%ex
+;;
+aarch64)
+ GOODREG=%x0
+ BADREG=%ax
+;;
+arm*)
+ GOODREG=%r0
+ BADREG=%ax
+;;
+esac
+
+test_goodarg() # Good-args
+{
+ while [ "$1" ]; do
+ echo "p ${PROBEFUNC} $1" > kprobe_events
+ shift 1
+ done;
+}
+
+test_badarg() # Bad-args
+{
+ while [ "$1" ]; do
+ ! echo "p ${PROBEFUNC} $1" > kprobe_events
+ shift 1
+ done;
+}
+
+echo > kprobe_events
+
+: "Register access"
+test_goodarg ${GOODREG}
+test_badarg ${BADREG}
+
+: "Symbol access"
+test_goodarg "@${GOODSYM}" "@${SYMADDR}" "@${GOODSYM}+10" "@${GOODSYM}-10"
+test_badarg "@" "@${BADSYM}" "@${GOODSYM}*10" "@${GOODSYM}/10" \
+ "@${GOODSYM}%10" "@${GOODSYM}&10" "@${GOODSYM}|10"
+
+: "Stack access"
+test_goodarg "\$stack" "\$stack0" "\$stack1"
+test_badarg "\$stackp" "\$stack0+10" "\$stack1-10"
+
+: "Retval access"
+echo "r ${PROBEFUNC} \$retval" > kprobe_events
+! echo "p ${PROBEFUNC} \$retval" > kprobe_events
+
+: "Comm access"
+test_goodarg "\$comm"
+
+: "Indirect memory access"
+test_goodarg "+0(${GOODREG})" "-0(${GOODREG})" "+10(\$stack)" \
+ "+0(\$stack1)" "+10(@${GOODSYM}-10)" "+0(+10(+20(\$stack)))"
+test_badarg "+(${GOODREG})" "(${GOODREG}+10)" "-(${GOODREG})" "(${GOODREG})" \
+ "+10(\$comm)" "+0(${GOODREG})+10"
+
+: "Name assignment"
+test_goodarg "varname=${GOODREG}"
+test_badarg "varname=varname2=${GOODREG}"
+
+: "Type syntax"
+test_goodarg "${GOODREG}:${GOODTYPE}"
+test_badarg "${GOODREG}::${GOODTYPE}" "${GOODREG}:${BADTYPE}" \
+ "${GOODTYPE}:${GOODREG}"
+
+: "Combination check"
+
+test_goodarg "\$comm:string" "+0(\$stack):string"
+test_badarg "\$comm:x64" "\$stack:string" "${GOODREG}:string"
+
+echo > kprobe_events



2018-05-28 10:23:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 166/268] dp83640: Ensure against premature access to PHY registers after reset

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

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

From: Esben Haabendal <[email protected]>

[ Upstream commit 76327a35caabd1a932e83d6a42b967aa08584e5d ]

The datasheet specifies a 3uS pause after performing a software
reset. The default implementation of genphy_soft_reset() does not
provide this, so implement soft_reset with the needed pause.

Signed-off-by: Esben Haabendal <[email protected]>
Reviewed-by: Andrew Lunn <[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/phy/dp83640.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)

--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -1203,6 +1203,23 @@ static void dp83640_remove(struct phy_de
kfree(dp83640);
}

+static int dp83640_soft_reset(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = genphy_soft_reset(phydev);
+ if (ret < 0)
+ return ret;
+
+ /* From DP83640 datasheet: "Software driver code must wait 3 us
+ * following a software reset before allowing further serial MII
+ * operations with the DP83640."
+ */
+ udelay(10); /* Taking udelay inaccuracy into account */
+
+ return 0;
+}
+
static int dp83640_config_init(struct phy_device *phydev)
{
struct dp83640_private *dp83640 = phydev->priv;
@@ -1496,6 +1513,7 @@ static struct phy_driver dp83640_driver
.flags = PHY_HAS_INTERRUPT,
.probe = dp83640_probe,
.remove = dp83640_remove,
+ .soft_reset = dp83640_soft_reset,
.config_init = dp83640_config_init,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,



2018-05-28 10:23:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 200/268] usb: dwc3: Update DWC_usb31 GTXFIFOSIZ reg fields

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

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

From: Thinh Nguyen <[email protected]>

[ Upstream commit 0cab8d26d6e5e053b2bed3356992aaa71dc93628 ]

Update two GTXFIFOSIZ bit fields for the DWC_usb31 controller. TXFDEP
is a 15-bit value instead of 16-bit value, and bit 15 is TXFRAMNUM.

The GTXFIFOSIZ register for DWC_usb31 is as follows:
+-------+-----------+----------------------------------+
| BITS | Name | Description |
+=======+===========+==================================+
| 31:16 | TXFSTADDR | Transmit FIFOn RAM Start Address |
| 15 | TXFRAMNUM | Asynchronous/Periodic TXFIFO |
| 14:0 | TXFDEP | TXFIFO Depth |
+-------+-----------+----------------------------------+

Signed-off-by: Thinh Nguyen <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/dwc3/core.h | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -202,6 +202,8 @@
#define DWC3_GUSB3PIPECTL_TX_DEEPH(n) ((n) << 1)

/* Global TX Fifo Size Register */
+#define DWC31_GTXFIFOSIZ_TXFRAMNUM BIT(15) /* DWC_usb31 only */
+#define DWC31_GTXFIFOSIZ_TXFDEF(n) ((n) & 0x7fff) /* DWC_usb31 only */
#define DWC3_GTXFIFOSIZ_TXFDEF(n) ((n) & 0xffff)
#define DWC3_GTXFIFOSIZ_TXFSTADDR(n) ((n) & 0xffff0000)




2018-05-28 10:23:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 171/268] btrfs: Fix possible softlock on single core machines

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

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

From: Nikolay Borisov <[email protected]>

[ Upstream commit 1e1c50a929bc9e49bc3f9935b92450d9e69f8158 ]

do_chunk_alloc implements a loop checking whether there is a pending
chunk allocation and if so causes the caller do loop. Generally this
loop is executed only once, however testing with btrfs/072 on a single
core vm machines uncovered an extreme case where the system could loop
indefinitely. This is due to a missing cond_resched when loop which
doesn't give a chance to the previous chunk allocator finish its job.

The fix is to simply add the missing cond_resched.

Fixes: 6d74119f1a3e ("Btrfs: avoid taking the chunk_mutex in do_chunk_alloc")
Signed-off-by: Nikolay Borisov <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/extent-tree.c | 1 +
1 file changed, 1 insertion(+)

--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4392,6 +4392,7 @@ again:
if (wait_for_alloc) {
mutex_unlock(&fs_info->chunk_mutex);
wait_for_alloc = 0;
+ cond_resched();
goto again;
}




2018-05-28 10:23:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 207/268] i2c: mv64xxx: Apply errata delay only in standard mode

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

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

From: Gregory CLEMENT <[email protected]>

[ Upstream commit 31184d8c6ea49ea0676d100cdd7e1f102ad025b5 ]

The errata FE-8471889 description has been updated. There is still a
timing violation for repeated start. But the errata now states that it
was only the case for the Standard mode (100 kHz), in Fast mode (400 kHz)
there is no issue.

This patch limit the errata fix to the Standard mode.

It has been tesed successfully on the clearfog (Aramda 388 based board).

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-mv64xxx.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -856,12 +856,16 @@ mv64xxx_of_config(struct mv64xxx_i2c_dat
*/
if (of_device_is_compatible(np, "marvell,mv78230-i2c")) {
drv_data->offload_enabled = true;
- drv_data->errata_delay = true;
+ /* The delay is only needed in standard mode (100kHz) */
+ if (bus_freq <= 100000)
+ drv_data->errata_delay = true;
}

if (of_device_is_compatible(np, "marvell,mv78230-a0-i2c")) {
drv_data->offload_enabled = false;
- drv_data->errata_delay = true;
+ /* The delay is only needed in standard mode (100kHz) */
+ if (bus_freq <= 100000)
+ drv_data->errata_delay = true;
}

if (of_device_is_compatible(np, "allwinner,sun6i-a31-i2c"))



2018-05-28 10:24:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 209/268] xhci: zero usb device slot_id member when disabling and freeing a xhci slot

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

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

From: Mathias Nyman <[email protected]>

[ Upstream commit a400efe455f7b61ac9a801ac8d0d01f8c8d82dd5 ]

set udev->slot_id to zero when disabling and freeing the xhci slot.
Prevents usb core from calling xhci with a stale slot id.

xHC controller may be reset during resume to recover from some error.
All slots are unusable as they are disabled and freed.
xhci driver starts slot enumeration again from 1 in the order they are
enabled. In the worst case a stale udev->slot_id for one device matches
a newly enabled slot_id for a different device, causing us to
perform a action on the wrong device.

Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/xhci-mem.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -960,6 +960,8 @@ void xhci_free_virt_device(struct xhci_h
if (dev->out_ctx)
xhci_free_container_ctx(xhci, dev->out_ctx);

+ if (dev->udev && dev->udev->slot_id)
+ dev->udev->slot_id = 0;
kfree(xhci->devs[slot_id]);
xhci->devs[slot_id] = NULL;
}



2018-05-28 10:24:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 185/268] powerpc/mpic: Check if cpu_possible() in mpic_physmask()

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

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

From: Michael Ellerman <[email protected]>

[ Upstream commit 0834d627fbea00c1444075eb3e448e1974da452d ]

In mpic_physmask() we loop over all CPUs up to 32, then get the hard
SMP processor id of that CPU.

Currently that's possibly walking off the end of the paca array, but
in a future patch we will change the paca array to be an array of
pointers, and in that case we will get a NULL for missing CPUs and
oops. eg:

Unable to handle kernel paging request for data at address 0x88888888888888b8
Faulting instruction address: 0xc00000000004e380
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP .mpic_set_affinity+0x60/0x1a0
LR .irq_do_set_affinity+0x48/0x100

Fix it by checking the CPU is possible, this also fixes the code if
there are gaps in the CPU numbering which probably never happens on
mpic systems but who knows.

Debugged-by: Nicholas Piggin <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/sysdev/mpic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -626,7 +626,7 @@ static inline u32 mpic_physmask(u32 cpum
int i;
u32 mask = 0;

- for (i = 0; i < min(32, NR_CPUS); ++i, cpumask >>= 1)
+ for (i = 0; i < min(32, NR_CPUS) && cpu_possible(i); ++i, cpumask >>= 1)
mask |= (cpumask & 1) << get_hard_smp_processor_id(i);
return mask;
}



2018-05-28 10:24:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 202/268] clk: Dont show the incorrect clock phase

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

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

From: Shawn Lin <[email protected]>

[ Upstream commit 1f9c63e8de3d7b377c9d74e4a17524cfb60e6384 ]

It's found that the clock phase output from clk_summary is
wrong compared to the actual phase reading from the register.

cat /sys/kernel/debug/clk/clk_summary | grep sdio_sample
sdio_sample 0 1 0 50000000 0 -22

It exposes an issue that clk core, clk_core_get_phase, always
returns the cached core->phase which should be either updated
by calling clk_set_phase or directly from the first place the
clk was registered.

When registering the clk, the core->phase geting from ->get_phase()
may return negative value indicating error. This is quite common
since the clk's phase may be highly related to its parent chain,
but it was temporarily orphan when registered, since its parent
chains hadn't be ready at that time, so the clk drivers decide to
return error in this case. However, if no clk_set_phase is called or
maybe the ->set_phase() isn't even implemented, the core->phase would
never be updated. This is wrong, and we should try to update it when
all its parent chains are settled down, like the way of updating clock
rate for that. But it's not deserved to complicate the code now and
just update it anyway when calling clk_core_get_phase, which would be
much simple and enough.

Signed-off-by: Shawn Lin <[email protected]>
Acked-by: Jerome Brunet <[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.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1905,6 +1905,9 @@ static int clk_core_get_phase(struct clk
int ret;

clk_prepare_lock();
+ /* Always try to update cached phase if possible */
+ if (core->ops->get_phase)
+ core->phase = core->ops->get_phase(core->hw);
ret = core->phase;
clk_prepare_unlock();




2018-05-28 10:24:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 195/268] ath10k: Fix kernel panic while using worker (ath10k_sta_rc_update_wk)

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

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

From: Karthikeyan Periyasamy <[email protected]>

[ Upstream commit 8b2d93dd22615cb7f3046a5a2083a6f8bb8052ed ]

When attempt to run worker (ath10k_sta_rc_update_wk) after the station object
(ieee80211_sta) delete will trigger the kernel panic.

This problem arise in AP + Mesh configuration, Where the current node AP VAP
and neighbor node mesh VAP MAC address are same. When the current mesh node
try to establish the mesh link with neighbor node, driver peer creation for
the neighbor mesh node fails due to duplication MAC address. Already the AP
VAP created with same MAC address.

It is caused by the following scenario steps.

Steps:
1. In above condition, ath10k driver sta_state callback (ath10k_sta_state)
fails to do the state change for a station from IEEE80211_STA_NOTEXIST
to IEEE80211_STA_NONE due to peer creation fails. Sta_state callback is
called from ieee80211_add_station() to handle the new station
(neighbor mesh node) request from the wpa_supplicant.
2. Concurrently ath10k receive the sta_rc_update callback notification from
the mesh_neighbour_update() to handle the beacon frames of the above
neighbor mesh node. since its atomic callback, ath10k driver queue the
work (ath10k_sta_rc_update_wk) to handle rc update.
3. Due to driver sta_state callback fails (step 1), mac80211 free the station
object.
4. When the worker (ath10k_sta_rc_update_wk) scheduled to run, it will access
the station object which is already deleted. so it will trigger kernel
panic.

Added the peer exist check in sta_rc_update callback before queue the work.

Kernel Panic log:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0204000
[00000000] *pgd=00000000
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
CPU: 1 PID: 1833 Comm: kworker/u4:2 Not tainted 3.14.77 #1
task: dcef0000 ti: d72b6000 task.ti: d72b6000
PC is at pwq_activate_delayed_work+0x10/0x40
LR is at pwq_activate_delayed_work+0xc/0x40
pc : [<c023f988>] lr : [<c023f984>] psr: 40000193
sp : d72b7f18 ip : 0000007a fp : d72b6000
r10: 00000000 r9 : dd404414 r8 : d8c31998
r7 : d72b6038 r6 : 00000004 r5 : d4907ec8 r4 : dcee1300
r3 : ffffffe0 r2 : 00000000 r1 : 00000001 r0 : 00000000
Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5787d Table: 595bc06a DAC: 00000015
...
Process kworker/u4:2 (pid: 1833, stack limit = 0xd72b6238)
Stack: (0xd72b7f18 to 0xd72b8000)
7f00: 00000001 dcee1300
7f20: 00000001 c02410dc d8c31980 dd404400 dd404400 c0242790 d8c31980 00000089
7f40: 00000000 d93e1340 00000000 d8c31980 c0242568 00000000 00000000 00000000
7f60: 00000000 c02474dc 00000000 00000000 000000f8 d8c31980 00000000 00000000
7f80: d72b7f80 d72b7f80 00000000 00000000 d72b7f90 d72b7f90 d72b7fac d93e1340
7fa0: c0247404 00000000 00000000 c0208d20 00000000 00000000 00000000 00000000
7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<c023f988>] (pwq_activate_delayed_work) from [<c02410dc>] (pwq_dec_nr_in_flight+0x58/0xc4)
[<c02410dc>] (pwq_dec_nr_in_flight) from [<c0242790>] (worker_thread+0x228/0x360)
[<c0242790>] (worker_thread) from [<c02474dc>] (kthread+0xd8/0xec)
[<c02474dc>] (kthread) from [<c0208d20>] (ret_from_fork+0x14/0x34)
Code: e92d4038 e1a05000 ebffffbc[69210.619376] SMP: failed to stop secondary CPUs
Rebooting in 3 seconds..

Signed-off-by: Karthikeyan Periyasamy <[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/ath10k/mac.c | 10 ++++++++++
1 file changed, 10 insertions(+)

--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6311,10 +6311,20 @@ static void ath10k_sta_rc_update(struct
{
struct ath10k *ar = hw->priv;
struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+ struct ath10k_vif *arvif = (void *)vif->drv_priv;
+ struct ath10k_peer *peer;
u32 bw, smps;

spin_lock_bh(&ar->data_lock);

+ peer = ath10k_peer_find(ar, arvif->vdev_id, sta->addr);
+ if (!peer) {
+ spin_unlock_bh(&ar->data_lock);
+ ath10k_warn(ar, "mac sta rc update failed to find peer %pM on vdev %i\n",
+ sta->addr, arvif->vdev_id);
+ return;
+ }
+
ath10k_dbg(ar, ATH10K_DBG_MAC,
"mac sta rc update for %pM changed %08x bw %d nss %d smps %d\n",
sta->addr, changed, sta->bandwidth, sta->rx_nss,



2018-05-28 10:25:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 234/268] enic: enable rq before updating rq descriptors

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

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

From: Govindarajulu Varadarajan <[email protected]>

[ Upstream commit e8588e268509292550634d9a35f2723a207683b2 ]

rq should be enabled before posting the buffers to rq desc. If not hw sees
stale value and casuses DMAR errors.

Signed-off-by: Govindarajulu Varadarajan <[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/cisco/enic/enic_main.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)

--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -1726,6 +1726,8 @@ static int enic_open(struct net_device *
}

for (i = 0; i < enic->rq_count; i++) {
+ /* enable rq before updating rq desc */
+ vnic_rq_enable(&enic->rq[i]);
vnic_rq_fill(&enic->rq[i], enic_rq_alloc_buf);
/* Need at least one buffer on ring to get going */
if (vnic_rq_desc_used(&enic->rq[i]) == 0) {
@@ -1737,8 +1739,6 @@ static int enic_open(struct net_device *

for (i = 0; i < enic->wq_count; i++)
vnic_wq_enable(&enic->wq[i]);
- for (i = 0; i < enic->rq_count; i++)
- vnic_rq_enable(&enic->rq[i]);

if (!enic_is_dynamic(enic) && !enic_is_sriov_vf(enic))
enic_dev_add_station_addr(enic);
@@ -1765,8 +1765,12 @@ static int enic_open(struct net_device *
return 0;

err_out_free_rq:
- for (i = 0; i < enic->rq_count; i++)
+ for (i = 0; i < enic->rq_count; i++) {
+ err = vnic_rq_disable(&enic->rq[i]);
+ if (err)
+ return err;
vnic_rq_clean(&enic->rq[i], enic_free_rq_buf);
+ }
enic_dev_notify_unset(enic);
err_out_free_intr:
enic_unset_affinity_hint(enic);



2018-05-28 10:25:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 181/268] Btrfs: fix copy_items() return value when logging an inode

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

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

From: Filipe Manana <[email protected]>

[ Upstream commit 8434ec46c6e3232cebc25a910363b29f5c617820 ]

When logging an inode, at tree-log.c:copy_items(), if we call
btrfs_next_leaf() at the loop which checks for the need to log holes, we
need to make sure copy_items() returns the value 1 to its caller and
not 0 (on success). This is because the path the caller passed was
released and is now different from what is was before, and the caller
expects a return value of 0 to mean both success and that the path
has not changed, while a return value of 1 means both success and
signals the caller that it can not reuse the path, it has to perform
another tree search.

Even though this is a case that should not be triggered on normal
circumstances or very rare at least, its consequences can be very
unpredictable (especially when replaying a log tree).

Fixes: 16e7549f045d ("Btrfs: incompatible format change to remove hole extents")
Signed-off-by: Filipe Manana <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/tree-log.c | 1 +
1 file changed, 1 insertion(+)

--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -3835,6 +3835,7 @@ fill_holes:
ASSERT(ret == 0);
src = src_path->nodes[0];
i = 0;
+ need_find_last_extent = true;
}

btrfs_item_key_to_cpu(src, &key, i);



2018-05-28 10:25:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 225/268] x86/devicetree: Initialize device tree before using it

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

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

From: Ivan Gorinov <[email protected]>

[ Upstream commit 628df9dc5ad886b0a9b33c75a7b09710eb859ca1 ]

Commit 08d53aa58cb1 added CRC32 calculation in early_init_dt_verify() and
checking in late initcall of_fdt_raw_init(), making early_init_dt_verify()
mandatory.

The required call to early_init_dt_verify() was not added to the
x86-specific implementation, causing failure to create the sysfs entry in
of_fdt_raw_init().

Fixes: 08d53aa58cb1 ("of/fdt: export fdt blob as /sys/firmware/fdt")
Signed-off-by: Ivan Gorinov <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Rob Herring <[email protected]>
Link: https://lkml.kernel.org/r/c8c7e941efc63b5d25ebf9b6350b0f3df38f6098.1520450752.git.ivan.gorinov@intel.com
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/devicetree.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -11,6 +11,7 @@
#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/of_irq.h>
+#include <linux/libfdt.h>
#include <linux/slab.h>
#include <linux/pci.h>
#include <linux/of_pci.h>
@@ -276,14 +277,15 @@ static void __init x86_flattree_get_conf

map_len = max(PAGE_SIZE - (initial_dtb & ~PAGE_MASK), (u64)128);

- initial_boot_params = dt = early_memremap(initial_dtb, map_len);
- size = of_get_flat_dt_size();
+ dt = early_memremap(initial_dtb, map_len);
+ size = fdt_totalsize(dt);
if (map_len < size) {
early_memunmap(dt, map_len);
- initial_boot_params = dt = early_memremap(initial_dtb, size);
+ dt = early_memremap(initial_dtb, size);
map_len = size;
}

+ early_init_dt_verify(dt);
unflatten_and_copy_device_tree();
early_memunmap(dt, map_len);
}



2018-05-28 10:26:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 215/268] usb: gadget: ffs: Execute copy_to_user() with USER_DS set

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

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

From: Lars-Peter Clausen <[email protected]>

[ Upstream commit 4058ebf33cb0be88ca516f968eda24ab7b6b93e4 ]

When using a AIO read() operation on the function FS gadget driver a URB is
submitted asynchronously and on URB completion the received data is copied
to the userspace buffer associated with the read operation.

This is done from a kernel worker thread invoking copy_to_user() (through
copy_to_iter()). And while the user space process memory is made available
to the kernel thread using use_mm(), some architecture require in addition
to this that the operation runs with USER_DS set. Otherwise the userspace
memory access will fail.

For example on ARM64 with Privileged Access Never (PAN) and User Access
Override (UAO) enabled the following crash occurs.

Internal error: Accessing user space memory with fs=KERNEL_DS: 9600004f [#1] SMP
Modules linked in:
CPU: 2 PID: 1636 Comm: kworker/2:1 Not tainted 4.9.0-04081-g8ab2dfb-dirty #487
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
Workqueue: events ffs_user_copy_worker
task: ffffffc87afc8080 task.stack: ffffffc87a00c000
PC is at __arch_copy_to_user+0x190/0x220
LR is at copy_to_iter+0x78/0x3c8
[...]
[<ffffff800847b790>] __arch_copy_to_user+0x190/0x220
[<ffffff80086f25d8>] ffs_user_copy_worker+0x70/0x130
[<ffffff80080b8c64>] process_one_work+0x1dc/0x460
[<ffffff80080b8f38>] worker_thread+0x50/0x4b0
[<ffffff80080bf5a0>] kthread+0xd8/0xf0
[<ffffff8008083680>] ret_from_fork+0x10/0x50

Address this by placing a set_fs(USER_DS) before of the copy operation
and revert it again once the copy operation has finished.

This patch is analogous to commit d7ffde35e31a ("vhost: use USER_DS in
vhost_worker thread") which addresses the same underlying issue.

Signed-off-by: Lars-Peter Clausen <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/function/f_fs.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -649,11 +649,15 @@ static void ffs_user_copy_worker(struct
bool kiocb_has_eventfd = io_data->kiocb->ki_flags & IOCB_EVENTFD;

if (io_data->read && ret > 0) {
+ mm_segment_t oldfs = get_fs();
+
+ set_fs(USER_DS);
use_mm(io_data->mm);
ret = copy_to_iter(io_data->buf, ret, &io_data->data);
if (ret != io_data->req->actual && iov_iter_count(&io_data->data))
ret = -EFAULT;
unuse_mm(io_data->mm);
+ set_fs(oldfs);
}

io_data->kiocb->ki_complete(io_data->kiocb, ret, ret);



2018-05-28 10:26:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 236/268] staging: rtl8192u: return -ENOMEM on failed allocation of priv->oldaddr

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

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

From: Colin Ian King <[email protected]>

[ Upstream commit e1a7418529e33bc4efc346324557251a16a3e79b ]

Currently the allocation of priv->oldaddr is not null checked which will
lead to subsequent errors when accessing priv->oldaddr. Fix this with
a null pointer check and a return of -ENOMEM on allocation failure.

Detected with Coccinelle:
drivers/staging/rtl8192u/r8192U_core.c:1708:2-15: alloc with no test,
possible model on line 1723

Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging")
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/rtl8192u/r8192U_core.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1749,6 +1749,8 @@ static short rtl8192_usb_initendpoints(s

priv->rx_urb[16] = usb_alloc_urb(0, GFP_KERNEL);
priv->oldaddr = kmalloc(16, GFP_KERNEL);
+ if (!priv->oldaddr)
+ return -ENOMEM;
oldaddr = priv->oldaddr;
align = ((long)oldaddr) & 3;
if (align) {



2018-05-28 10:26:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 261/268] scsi: lpfc: Fix issue_lip if link is disabled

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

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

From: James Smart <[email protected]>

[ Upstream commit 2289e9598dde9705400559ca2606fb8c145c34f0 ]

The driver ignored checks on whether the link should be kept
administratively down after a link bounce. Correct the checks.

Signed-off-by: Dick Kennedy <[email protected]>
Signed-off-by: James Smart <[email protected]>
Reviewed-by: Hannes Reinecke <[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/lpfc/lpfc_attr.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -634,7 +634,12 @@ lpfc_issue_lip(struct Scsi_Host *shost)
LPFC_MBOXQ_t *pmboxq;
int mbxstatus = MBXERR_ERROR;

+ /*
+ * If the link is offline, disabled or BLOCK_MGMT_IO
+ * it doesn't make any sense to allow issue_lip
+ */
if ((vport->fc_flag & FC_OFFLINE_MODE) ||
+ (phba->hba_flag & LINK_DISABLED) ||
(phba->sli.sli_flag & LPFC_BLOCK_MGMT_IO))
return -EPERM;




2018-05-28 10:26:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 240/268] serial: mxs-auart: Fix out-of-bounds access through serial port index

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

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

From: Geert Uytterhoeven <[email protected]>

[ Upstream commit dd345a31bfdec350d2593e6de5964e55c7f19c76 ]

The auart_port[] array is indexed using a value derived from the
"serialN" alias in DT, or from platform data, which may lead to an
out-of-bounds access.

Fix this by adding a range check.

Fixes: 1ea6607d4cdc9179 ("serial: mxs-auart: Allow device tree probing")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/mxs-auart.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -1274,6 +1274,10 @@ static int mxs_auart_probe(struct platfo
s->port.line = pdev->id < 0 ? 0 : pdev->id;
else if (ret < 0)
return ret;
+ if (s->port.line >= ARRAY_SIZE(auart_port)) {
+ dev_err(&pdev->dev, "serial%d out of range\n", s->port.line);
+ return -EINVAL;
+ }

if (of_id) {
pdev->id_entry = of_id->data;



2018-05-28 10:26:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 265/268] ASoC: samsung: i2s: Ensure the RCLK rate is properly determined

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

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

From: Sylwester Nawrocki <[email protected]>

[ Upstream commit 647d04f8e07afc7c3b7a42b3ee01a8b28db29631 ]

If the RCLK mux clock configuration is specified in DT and no set_sysclk()
callback is used in the sound card driver the sclk_srcrate field will remain
set to 0, leading to an incorrect PSR divider setting.
To fix this the frequency value is retrieved from the CLK_I2S_RCLK_SRC clock,
so the actual RCLK mux selection is taken into account.

Signed-off-by: Sylwester Nawrocki <[email protected]>
Acked-by: Krzysztof Kozlowski <[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/samsung/i2s.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)

--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -640,8 +640,12 @@ static int i2s_set_fmt(struct snd_soc_da
tmp |= mod_slave;
break;
case SND_SOC_DAIFMT_CBS_CFS:
- /* Set default source clock in Master mode */
- if (i2s->rclk_srcrate == 0)
+ /*
+ * Set default source clock in Master mode, only when the
+ * CLK_I2S_RCLK_SRC clock is not exposed so we ensure any
+ * clock configuration assigned in DT is not overwritten.
+ */
+ if (i2s->rclk_srcrate == 0 && i2s->clk_data.clks == NULL)
i2s_set_sysclk(dai, SAMSUNG_I2S_RCLKSRC_0,
0, SND_SOC_CLOCK_IN);
break;
@@ -856,6 +860,11 @@ static int config_setup(struct i2s_dai *
return 0;

if (!(i2s->quirks & QUIRK_NO_MUXPSR)) {
+ struct clk *rclksrc = i2s->clk_table[CLK_I2S_RCLK_SRC];
+
+ if (i2s->rclk_srcrate == 0 && rclksrc && !IS_ERR(rclksrc))
+ i2s->rclk_srcrate = clk_get_rate(rclksrc);
+
psr = i2s->rclk_srcrate / i2s->frmclk / rfs;
writel(((psr - 1) << 8) | PSR_PSREN, i2s->addr + I2SPSR);
dev_dbg(&i2s->pdev->dev,



2018-05-28 10:26:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 256/268] x86/apic: Set up through-local-APIC mode on the boot CPU if noapic specified

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

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

From: Baoquan He <[email protected]>

[ Upstream commit bee3204ec3c49f6f53add9c3962c9012a5c036fa ]

Currently the kdump kernel becomes very slow if 'noapic' is specified.
Normal kernel doesn't have this bug.

Kernel parameter 'noapic' is used to disable IO-APIC in system for
testing or special purpose. Here the root cause is that in kdump
kernel LAPIC is disabled since commit:

522e664644 ("x86/apic: Disable I/O APIC before shutdown of the local APIC")

In this case we need set up through-local-APIC on boot CPU in
setup_local_APIC().

In normal kernel the legacy irq mode is enabled by the BIOS. If
it is virtual wire mode, the local-APIC has been enabled and set as
through-local-APIC.

Though we fixed the regression introduced by commit 522e664644,
to further improve robustness set up the through-local-APIC mode
explicitly, do not rely on the default boot IRQ mode.

Signed-off-by: Baoquan He <[email protected]>
Reviewed-by: Eric W. Biederman <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
[ Rewrote the changelog. ]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/apic/apic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1368,7 +1368,7 @@ void setup_local_APIC(void)
* TODO: set up through-local-APIC from through-I/O-APIC? --macro
*/
value = apic_read(APIC_LVT0) & APIC_LVT_MASKED;
- if (!cpu && (pic_mode || !value)) {
+ if (!cpu && (pic_mode || !value || skip_ioapic_setup)) {
value = APIC_DM_EXTINT;
apic_printk(APIC_VERBOSE, "enabled ExtINT on CPU#%d\n", cpu);
} else {



2018-05-28 10:27:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 219/268] hwmon: (pmbus/max8688) Accept negative page register values

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

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

From: Guenter Roeck <[email protected]>

[ Upstream commit a46f8cd696624ef757be0311eb28f119c36778e8 ]

A negative page register value means that no page needs to be
selected. This is used by status register evaluations and needs
to be accepted.

Fixes: da8e48ab483e1 ("hwmon: (pmbus) Always call _pmbus_read_byte in core driver")
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hwmon/pmbus/max8688.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/hwmon/pmbus/max8688.c
+++ b/drivers/hwmon/pmbus/max8688.c
@@ -45,7 +45,7 @@ static int max8688_read_word_data(struct
{
int ret;

- if (page)
+ if (page > 0)
return -ENXIO;

switch (reg) {



2018-05-28 11:24:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 017/268] do d_instantiate/unlock_new_inode combinations safely

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

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

From: Al Viro <[email protected]>

commit 1e2e547a93a00ebc21582c06ca3c6cfea2a309ee upstream.

For anything NFS-exported we do _not_ want to unlock new inode
before it has grown an alias; original set of fixes got the
ordering right, but missed the nasty complication in case of
lockdep being enabled - unlock_new_inode() does
lockdep_annotate_inode_mutex_key(inode)
which can only be done before anyone gets a chance to touch
->i_mutex. Unfortunately, flipping the order and doing
unlock_new_inode() before d_instantiate() opens a window when
mkdir can race with open-by-fhandle on a guessed fhandle, leading
to multiple aliases for a directory inode and all the breakage
that follows from that.

Correct solution: a new primitive (d_instantiate_new())
combining these two in the right order - lockdep annotate, then
d_instantiate(), then the rest of unlock_new_inode(). All
combinations of d_instantiate() with unlock_new_inode() should
be converted to that.

Cc: [email protected] # 2.6.29 and later
Tested-by: Mike Marshall <[email protected]>
Reviewed-by: Andreas Dilger <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/btrfs/inode.c | 16 ++++------------
fs/dcache.c | 22 ++++++++++++++++++++++
fs/ecryptfs/inode.c | 3 +--
fs/ext2/namei.c | 6 ++----
fs/ext4/namei.c | 6 ++----
fs/f2fs/namei.c | 12 ++++--------
fs/jffs2/dir.c | 12 ++++--------
fs/jfs/namei.c | 12 ++++--------
fs/nilfs2/namei.c | 6 ++----
fs/reiserfs/namei.c | 12 ++++--------
fs/udf/namei.c | 6 ++----
fs/ufs/namei.c | 6 ++----
include/linux/dcache.h | 1 +
13 files changed, 54 insertions(+), 66 deletions(-)

--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -6413,8 +6413,7 @@ static int btrfs_mknod(struct inode *dir
goto out_unlock_inode;
} else {
btrfs_update_inode(trans, root, inode);
- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
}

out_unlock:
@@ -6489,8 +6488,7 @@ static int btrfs_create(struct inode *di
goto out_unlock_inode;

BTRFS_I(inode)->io_tree.ops = &btrfs_extent_io_ops;
- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);

out_unlock:
btrfs_end_transaction(trans, root);
@@ -6633,12 +6631,7 @@ static int btrfs_mkdir(struct inode *dir
if (err)
goto out_fail_inode;

- d_instantiate(dentry, inode);
- /*
- * mkdir is special. We're unlocking after we call d_instantiate
- * to avoid a race with nfsd calling d_instantiate.
- */
- unlock_new_inode(inode);
+ d_instantiate_new(dentry, inode);
drop_on_err = 0;

out_fail:
@@ -9789,8 +9782,7 @@ static int btrfs_symlink(struct inode *d
goto out_unlock_inode;
}

- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);

out_unlock:
btrfs_end_transaction(trans, root);
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1897,6 +1897,28 @@ struct dentry *d_instantiate_unique(stru

EXPORT_SYMBOL(d_instantiate_unique);

+/*
+ * This should be equivalent to d_instantiate() + unlock_new_inode(),
+ * with lockdep-related part of unlock_new_inode() done before
+ * anything else. Use that instead of open-coding d_instantiate()/
+ * unlock_new_inode() combinations.
+ */
+void d_instantiate_new(struct dentry *entry, struct inode *inode)
+{
+ BUG_ON(!hlist_unhashed(&entry->d_u.d_alias));
+ BUG_ON(!inode);
+ lockdep_annotate_inode_mutex_key(inode);
+ security_d_instantiate(entry, inode);
+ spin_lock(&inode->i_lock);
+ __d_instantiate(entry, inode);
+ WARN_ON(!(inode->i_state & I_NEW));
+ inode->i_state &= ~I_NEW;
+ smp_mb();
+ wake_up_bit(&inode->i_state, __I_NEW);
+ spin_unlock(&inode->i_lock);
+}
+EXPORT_SYMBOL(d_instantiate_new);
+
/**
* d_instantiate_no_diralias - instantiate a non-aliased dentry
* @entry: dentry to complete
--- a/fs/ecryptfs/inode.c
+++ b/fs/ecryptfs/inode.c
@@ -287,8 +287,7 @@ ecryptfs_create(struct inode *directory_
iput(ecryptfs_inode);
goto out;
}
- unlock_new_inode(ecryptfs_inode);
- d_instantiate(ecryptfs_dentry, ecryptfs_inode);
+ d_instantiate_new(ecryptfs_dentry, ecryptfs_inode);
out:
return rc;
}
--- a/fs/ext2/namei.c
+++ b/fs/ext2/namei.c
@@ -40,8 +40,7 @@ static inline int ext2_add_nondir(struct
{
int err = ext2_add_link(dentry, inode);
if (!err) {
- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
return 0;
}
inode_dec_link_count(inode);
@@ -267,8 +266,7 @@ static int ext2_mkdir(struct inode * dir
if (err)
goto out_fail;

- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
out:
return err;

--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -2429,8 +2429,7 @@ static int ext4_add_nondir(handle_t *han
int err = ext4_add_entry(handle, dentry, inode);
if (!err) {
ext4_mark_inode_dirty(handle, inode);
- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
return 0;
}
drop_nlink(inode);
@@ -2669,8 +2668,7 @@ out_clear_inode:
err = ext4_mark_inode_dirty(handle, dir);
if (err)
goto out_clear_inode;
- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
if (IS_DIRSYNC(dir))
ext4_handle_sync(handle);

--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -150,8 +150,7 @@ static int f2fs_create(struct inode *dir

alloc_nid_done(sbi, ino);

- d_instantiate(dentry, inode);
- unlock_new_inode(inode);
+ d_instantiate_new(dentry, inode);

if (IS_DIRSYNC(dir))
f2fs_sync_fs(sbi->sb, 1);
@@ -399,8 +398,7 @@ static int f2fs_symlink(struct inode *di
err = page_symlink(inode, p_str, p_len);

err_out:
- d_instantiate(dentry, inode);
- unlock_new_inode(inode);
+ d_instantiate_new(dentry, inode);

/*
* Let's flush symlink data in order to avoid broken symlink as much as
@@ -454,8 +452,7 @@ static int f2fs_mkdir(struct inode *dir,

alloc_nid_done(sbi, inode->i_ino);

- d_instantiate(dentry, inode);
- unlock_new_inode(inode);
+ d_instantiate_new(dentry, inode);

if (IS_DIRSYNC(dir))
f2fs_sync_fs(sbi->sb, 1);
@@ -499,8 +496,7 @@ static int f2fs_mknod(struct inode *dir,

alloc_nid_done(sbi, inode->i_ino);

- d_instantiate(dentry, inode);
- unlock_new_inode(inode);
+ d_instantiate_new(dentry, inode);

if (IS_DIRSYNC(dir))
f2fs_sync_fs(sbi->sb, 1);
--- a/fs/jffs2/dir.c
+++ b/fs/jffs2/dir.c
@@ -207,8 +207,7 @@ static int jffs2_create(struct inode *di
__func__, inode->i_ino, inode->i_mode, inode->i_nlink,
f->inocache->pino_nlink, inode->i_mapping->nrpages);

- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
return 0;

fail:
@@ -428,8 +427,7 @@ static int jffs2_symlink (struct inode *
mutex_unlock(&dir_f->sem);
jffs2_complete_reservation(c);

- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
return 0;

fail:
@@ -573,8 +571,7 @@ static int jffs2_mkdir (struct inode *di
mutex_unlock(&dir_f->sem);
jffs2_complete_reservation(c);

- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
return 0;

fail:
@@ -745,8 +742,7 @@ static int jffs2_mknod (struct inode *di
mutex_unlock(&dir_f->sem);
jffs2_complete_reservation(c);

- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
return 0;

fail:
--- a/fs/jfs/namei.c
+++ b/fs/jfs/namei.c
@@ -178,8 +178,7 @@ static int jfs_create(struct inode *dip,
unlock_new_inode(ip);
iput(ip);
} else {
- unlock_new_inode(ip);
- d_instantiate(dentry, ip);
+ d_instantiate_new(dentry, ip);
}

out2:
@@ -313,8 +312,7 @@ static int jfs_mkdir(struct inode *dip,
unlock_new_inode(ip);
iput(ip);
} else {
- unlock_new_inode(ip);
- d_instantiate(dentry, ip);
+ d_instantiate_new(dentry, ip);
}

out2:
@@ -1058,8 +1056,7 @@ static int jfs_symlink(struct inode *dip
unlock_new_inode(ip);
iput(ip);
} else {
- unlock_new_inode(ip);
- d_instantiate(dentry, ip);
+ d_instantiate_new(dentry, ip);
}

out2:
@@ -1443,8 +1440,7 @@ static int jfs_mknod(struct inode *dir,
unlock_new_inode(ip);
iput(ip);
} else {
- unlock_new_inode(ip);
- d_instantiate(dentry, ip);
+ d_instantiate_new(dentry, ip);
}

out1:
--- a/fs/nilfs2/namei.c
+++ b/fs/nilfs2/namei.c
@@ -50,8 +50,7 @@ static inline int nilfs_add_nondir(struc
{
int err = nilfs_add_link(dentry, inode);
if (!err) {
- d_instantiate(dentry, inode);
- unlock_new_inode(inode);
+ d_instantiate_new(dentry, inode);
return 0;
}
inode_dec_link_count(inode);
@@ -246,8 +245,7 @@ static int nilfs_mkdir(struct inode *dir
goto out_fail;

nilfs_mark_inode_dirty(inode);
- d_instantiate(dentry, inode);
- unlock_new_inode(inode);
+ d_instantiate_new(dentry, inode);
out:
if (!err)
err = nilfs_transaction_commit(dir->i_sb);
--- a/fs/reiserfs/namei.c
+++ b/fs/reiserfs/namei.c
@@ -687,8 +687,7 @@ static int reiserfs_create(struct inode
reiserfs_update_inode_transaction(inode);
reiserfs_update_inode_transaction(dir);

- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
retval = journal_end(&th);

out_failed:
@@ -771,8 +770,7 @@ static int reiserfs_mknod(struct inode *
goto out_failed;
}

- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
retval = journal_end(&th);

out_failed:
@@ -871,8 +869,7 @@ static int reiserfs_mkdir(struct inode *
/* the above add_entry did not update dir's stat data */
reiserfs_update_sd(&th, dir);

- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
retval = journal_end(&th);
out_failed:
reiserfs_write_unlock(dir->i_sb);
@@ -1186,8 +1183,7 @@ static int reiserfs_symlink(struct inode
goto out_failed;
}

- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
retval = journal_end(&th);
out_failed:
reiserfs_write_unlock(parent_dir->i_sb);
--- a/fs/udf/namei.c
+++ b/fs/udf/namei.c
@@ -611,8 +611,7 @@ static int udf_add_nondir(struct dentry
if (fibh.sbh != fibh.ebh)
brelse(fibh.ebh);
brelse(fibh.sbh);
- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);

return 0;
}
@@ -722,8 +721,7 @@ static int udf_mkdir(struct inode *dir,
inc_nlink(dir);
dir->i_ctime = dir->i_mtime = current_fs_time(dir->i_sb);
mark_inode_dirty(dir);
- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
if (fibh.sbh != fibh.ebh)
brelse(fibh.ebh);
brelse(fibh.sbh);
--- a/fs/ufs/namei.c
+++ b/fs/ufs/namei.c
@@ -38,8 +38,7 @@ static inline int ufs_add_nondir(struct
{
int err = ufs_add_link(dentry, inode);
if (!err) {
- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
return 0;
}
inode_dec_link_count(inode);
@@ -191,8 +190,7 @@ static int ufs_mkdir(struct inode * dir,
if (err)
goto out_fail;

- unlock_new_inode(inode);
- d_instantiate(dentry, inode);
+ d_instantiate_new(dentry, inode);
return 0;

out_fail:
--- a/include/linux/dcache.h
+++ b/include/linux/dcache.h
@@ -236,6 +236,7 @@ extern seqlock_t rename_lock;
* These are the low-level FS interfaces to the dcache..
*/
extern void d_instantiate(struct dentry *, struct inode *);
+extern void d_instantiate_new(struct dentry *, struct inode *);
extern struct dentry * d_instantiate_unique(struct dentry *, struct inode *);
extern int d_instantiate_no_diralias(struct dentry *, struct inode *);
extern void __d_drop(struct dentry *dentry);



2018-05-28 11:25:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 005/268] aio: fix io_destroy(2) vs. lookup_ioctx() race

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

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

From: Al Viro <[email protected]>

commit baf10564fbb66ea222cae66fbff11c444590ffd9 upstream.

kill_ioctx() used to have an explicit RCU delay between removing the
reference from ->ioctx_table and percpu_ref_kill() dropping the refcount.
At some point that delay had been removed, on the theory that
percpu_ref_kill() itself contained an RCU delay. Unfortunately, that was
the wrong kind of RCU delay and it didn't care about rcu_read_lock() used
by lookup_ioctx(). As the result, we could get ctx freed right under
lookup_ioctx(). Tejun has fixed that in a6d7cff472e ("fs/aio: Add explicit
RCU grace period when freeing kioctx"); however, that fix is not enough.

Suppose io_destroy() from one thread races with e.g. io_setup() from another;
CPU1 removes the reference from current->mm->ioctx_table[...] just as CPU2
has picked it (under rcu_read_lock()). Then CPU1 proceeds to drop the
refcount, getting it to 0 and triggering a call of free_ioctx_users(),
which proceeds to drop the secondary refcount and once that reaches zero
calls free_ioctx_reqs(). That does
INIT_RCU_WORK(&ctx->free_rwork, free_ioctx);
queue_rcu_work(system_wq, &ctx->free_rwork);
and schedules freeing the whole thing after RCU delay.

In the meanwhile CPU2 has gotten around to percpu_ref_get(), bumping the
refcount from 0 to 1 and returned the reference to io_setup().

Tejun's fix (that queue_rcu_work() in there) guarantees that ctx won't get
freed until after percpu_ref_get(). Sure, we'd increment the counter before
ctx can be freed. Now we are out of rcu_read_lock() and there's nothing to
stop freeing of the whole thing. Unfortunately, CPU2 assumes that since it
has grabbed the reference, ctx is *NOT* going away until it gets around to
dropping that reference.

The fix is obvious - use percpu_ref_tryget_live() and treat failure as miss.
It's not costlier than what we currently do in normal case, it's safe to
call since freeing *is* delayed and it closes the race window - either
lookup_ioctx() comes before percpu_ref_kill() (in which case ctx->users
won't reach 0 until the caller of lookup_ioctx() drops it) or lookup_ioctx()
fails, ctx->users is unaffected and caller of lookup_ioctx() doesn't see
the object in question at all.

Cc: [email protected]
Fixes: a6d7cff472e "fs/aio: Add explicit RCU grace period when freeing kioctx"
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/aio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1066,8 +1066,8 @@ static struct kioctx *lookup_ioctx(unsig

ctx = rcu_dereference(table->table[id]);
if (ctx && ctx->user_id == ctx_id) {
- percpu_ref_get(&ctx->users);
- ret = ctx;
+ if (percpu_ref_tryget_live(&ctx->users))
+ ret = ctx;
}
out:
rcu_read_unlock();



2018-05-28 11:25:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 090/268] md raid10: fix NULL deference in handle_write_completed()

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

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

From: Yufen Yu <[email protected]>

[ Upstream commit 01a69cab01c184d3786af09e9339311123d63d22 ]

In the case of 'recover', an r10bio with R10BIO_WriteError &
R10BIO_IsRecover will be progressed by handle_write_completed().
This function traverses all r10bio->devs[copies].
If devs[m].repl_bio != NULL, it thinks conf->mirrors[dev].replacement
is also not NULL. However, this is not always true.

When there is an rdev of raid10 has replacement, then each r10bio
->devs[m].repl_bio != NULL in conf->r10buf_pool. However, in 'recover',
even if corresponded replacement is NULL, it doesn't clear r10bio
->devs[m].repl_bio, resulting in replacement NULL deference.

This bug was introduced when replacement support for raid10 was
added in Linux 3.3.

As NeilBrown suggested:
Elsewhere the determination of "is this device part of the
resync/recovery" is made by resting bio->bi_end_io.
If this is end_sync_write, then we tried to write here.
If it is NULL, then we didn't try to write.

Fixes: 9ad1aefc8ae8 ("md/raid10: Handle replacement devices during resync.")
Cc: stable (V3.3+)
Suggested-by: NeilBrown <[email protected]>
Signed-off-by: Yufen Yu <[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 | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -2630,7 +2630,8 @@ static void handle_write_completed(struc
for (m = 0; m < conf->copies; m++) {
int dev = r10_bio->devs[m].devnum;
rdev = conf->mirrors[dev].rdev;
- if (r10_bio->devs[m].bio == NULL)
+ if (r10_bio->devs[m].bio == NULL ||
+ r10_bio->devs[m].bio->bi_end_io == NULL)
continue;
if (!r10_bio->devs[m].bio->bi_error) {
rdev_clear_badblocks(
@@ -2645,7 +2646,8 @@ static void handle_write_completed(struc
md_error(conf->mddev, rdev);
}
rdev = conf->mirrors[dev].replacement;
- if (r10_bio->devs[m].repl_bio == NULL)
+ if (r10_bio->devs[m].repl_bio == NULL ||
+ r10_bio->devs[m].repl_bio->bi_end_io == NULL)
continue;

if (!r10_bio->devs[m].repl_bio->bi_error) {



2018-05-28 14:59:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 250/268] clk: samsung: exynos5250: Fix PLL rates

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

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

From: Andrzej Hajda <[email protected]>

[ Upstream commit 2ac051eeabaa411ef89ae7cd5bb8e60cb41ad780 ]

Rates declared in PLL rate tables should match exactly rates calculated
from PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate
will return 393216003. If we now attempt to set rate of a PLL's child divider
clock to 393216000/2 its rate will be 131072001, rather than 196608000.
That is, the divider will be set to 3 instead of 2, because 393216003/2 is
greater than 196608000.

To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.

Signed-off-by: Andrzej Hajda <[email protected]>
Acked-by: Chanwoo Choi <[email protected]>
Acked-by: Tomasz Figa <[email protected]>
Signed-off-by: Sylwester Nawrocki <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/clk/samsung/clk-exynos5250.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -711,13 +711,13 @@ static struct samsung_pll_rate_table epl
/* sorted in descending order */
/* PLL_36XX_RATE(rate, m, p, s, k) */
PLL_36XX_RATE(192000000, 64, 2, 2, 0),
- PLL_36XX_RATE(180633600, 90, 3, 2, 20762),
+ PLL_36XX_RATE(180633605, 90, 3, 2, 20762),
PLL_36XX_RATE(180000000, 90, 3, 2, 0),
PLL_36XX_RATE(73728000, 98, 2, 4, 19923),
- PLL_36XX_RATE(67737600, 90, 2, 4, 20762),
+ PLL_36XX_RATE(67737602, 90, 2, 4, 20762),
PLL_36XX_RATE(49152000, 98, 3, 4, 19923),
- PLL_36XX_RATE(45158400, 90, 3, 4, 20762),
- PLL_36XX_RATE(32768000, 131, 3, 5, 4719),
+ PLL_36XX_RATE(45158401, 90, 3, 4, 20762),
+ PLL_36XX_RATE(32768001, 131, 3, 5, 4719),
{ },
};




2018-05-28 14:59:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 258/268] perf report: Fix memory corruption in --branch-history mode --branch-history

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

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

From: Jiri Olsa <[email protected]>

[ Upstream commit e3ebaa465136ecfedf9c6f4671df02bf625f8125 ]

Jin Yao reported memory corrupton in perf report with
branch info used for stack trace:

> Following command lines will cause perf crash.

> perf record -j call -g -a <application>
> perf report --branch-history
>
> *** Error in `perf': double free or corruption (!prev): 0x00000000104aa040 ***
> ======= Backtrace: =========
> /lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7f6b37254725]
> /lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7f6b3725cf4a]
> /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f6b37260abc]
> perf[0x51b914]
> perf(hist_entry_iter__add+0x1e5)[0x51f305]
> perf[0x43cf01]
> perf[0x4fa3bf]
> perf[0x4fa923]
> perf[0x4fd396]
> perf[0x4f9614]
> perf(perf_session__process_events+0x89e)[0x4fc38e]
> perf(cmd_report+0x15d2)[0x43f202]
> perf[0x4a059f]
> perf(main+0x631)[0x427b71]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f6b371fd830]
> perf(_start+0x29)[0x427d89]

For the cumulative output, we allocate the he_cache array based on the
--max-stack option value and populate it with data from 'callchain_cursor'.

The --max-stack option value does not ensure now the limit for number of
callchain_cursor nodes, so the cumulative iter code will allocate smaller array
than it's actually needed and cause above corruption.

I think the --max-stack limit does not apply here anyway, because we add
callchain data as normal hist entries, while the --max-stack control the limit
of single entry callchain depth.

Using the callchain_cursor.nr as he_cache array count to fix this. Also
removing struct hist_entry_iter::max_stack, because there's no longer any use
for it.

We need more fixes to ensure that the branch stack code follows properly the
logic of --max-stack, which is not the case at the moment.

Original-patch-by: Jin Yao <[email protected]>
Signed-off-by: Jiri Olsa <[email protected]>
Reported-by: Jin Yao <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Kan Liang <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Link: http://lkml.kernel.org/r/20180216123619.GA9945@krava
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/util/hist.c | 4 +---
tools/perf/util/hist.h | 1 -
2 files changed, 1 insertion(+), 4 deletions(-)

--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -720,7 +720,7 @@ iter_prepare_cumulative_entry(struct his
* cumulated only one time to prevent entries more than 100%
* overhead.
*/
- he_cache = malloc(sizeof(*he_cache) * (iter->max_stack + 1));
+ he_cache = malloc(sizeof(*he_cache) * (callchain_cursor.nr + 1));
if (he_cache == NULL)
return -ENOMEM;

@@ -881,8 +881,6 @@ int hist_entry_iter__add(struct hist_ent
if (err)
return err;

- iter->max_stack = max_stack_depth;
-
err = iter->ops->prepare_entry(iter, al);
if (err)
goto out;
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -91,7 +91,6 @@ struct hist_entry_iter {
int curr;

bool hide_unresolved;
- int max_stack;

struct perf_evsel *evsel;
struct perf_sample *sample;



2018-05-28 14:59:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 254/268] MIPS: Octeon: Fix logging messages with spurious periods after newlines

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

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

From: Joe Perches <[email protected]>

[ Upstream commit db6775ca6e0353d2618ca7d5e210fc36ad43bbd4 ]

Using a period after a newline causes bad output.

Fixes: 64b139f97c01 ("MIPS: OCTEON: irq: add CIB and other fixes")
Signed-off-by: Joe Perches <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/17886/
Signed-off-by: James Hogan <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/mips/cavium-octeon/octeon-irq.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

--- a/arch/mips/cavium-octeon/octeon-irq.c
+++ b/arch/mips/cavium-octeon/octeon-irq.c
@@ -2240,7 +2240,7 @@ static int __init octeon_irq_init_cib(st

parent_irq = irq_of_parse_and_map(ciu_node, 0);
if (!parent_irq) {
- pr_err("ERROR: Couldn't acquire parent_irq for %s\n.",
+ pr_err("ERROR: Couldn't acquire parent_irq for %s\n",
ciu_node->name);
return -EINVAL;
}
@@ -2252,7 +2252,7 @@ static int __init octeon_irq_init_cib(st

addr = of_get_address(ciu_node, 0, NULL, NULL);
if (!addr) {
- pr_err("ERROR: Couldn't acquire reg(0) %s\n.", ciu_node->name);
+ pr_err("ERROR: Couldn't acquire reg(0) %s\n", ciu_node->name);
return -EINVAL;
}
host_data->raw_reg = (u64)phys_to_virt(
@@ -2260,7 +2260,7 @@ static int __init octeon_irq_init_cib(st

addr = of_get_address(ciu_node, 1, NULL, NULL);
if (!addr) {
- pr_err("ERROR: Couldn't acquire reg(1) %s\n.", ciu_node->name);
+ pr_err("ERROR: Couldn't acquire reg(1) %s\n", ciu_node->name);
return -EINVAL;
}
host_data->en_reg = (u64)phys_to_virt(
@@ -2268,7 +2268,7 @@ static int __init octeon_irq_init_cib(st

r = of_property_read_u32(ciu_node, "cavium,max-bits", &val);
if (r) {
- pr_err("ERROR: Couldn't read cavium,max-bits from %s\n.",
+ pr_err("ERROR: Couldn't read cavium,max-bits from %s\n",
ciu_node->name);
return r;
}
@@ -2278,7 +2278,7 @@ static int __init octeon_irq_init_cib(st
&octeon_irq_domain_cib_ops,
host_data);
if (!cib_domain) {
- pr_err("ERROR: Couldn't irq_domain_add_linear()\n.");
+ pr_err("ERROR: Couldn't irq_domain_add_linear()\n");
return -ENOMEM;
}




2018-05-28 14:59:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 267/268] kdb: make "mdr" command repeat

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

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

From: Randy Dunlap <[email protected]>

[ Upstream commit 1e0ce03bf142454f38a5fc050bf4fd698d2d36d8 ]

The "mdr" command should repeat (continue) when only Enter/Return
is pressed, so make it do so.

Signed-off-by: Randy Dunlap <[email protected]>
Cc: Daniel Thompson <[email protected]>
Cc: Jason Wessel <[email protected]>
Cc: [email protected]
Signed-off-by: Jason Wessel <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/debug/kdb/kdb_main.c | 27 +++++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)

--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -1564,6 +1564,7 @@ static int kdb_md(int argc, const char *
int symbolic = 0;
int valid = 0;
int phys = 0;
+ int raw = 0;

kdbgetintenv("MDCOUNT", &mdcount);
kdbgetintenv("RADIX", &radix);
@@ -1573,9 +1574,10 @@ static int kdb_md(int argc, const char *
repeat = mdcount * 16 / bytesperword;

if (strcmp(argv[0], "mdr") == 0) {
- if (argc != 2)
+ if (argc == 2 || (argc == 0 && last_addr != 0))
+ valid = raw = 1;
+ else
return KDB_ARGCOUNT;
- valid = 1;
} else if (isdigit(argv[0][2])) {
bytesperword = (int)(argv[0][2] - '0');
if (bytesperword == 0) {
@@ -1611,7 +1613,10 @@ static int kdb_md(int argc, const char *
radix = last_radix;
bytesperword = last_bytesperword;
repeat = last_repeat;
- mdcount = ((repeat * bytesperword) + 15) / 16;
+ if (raw)
+ mdcount = repeat;
+ else
+ mdcount = ((repeat * bytesperword) + 15) / 16;
}

if (argc) {
@@ -1628,7 +1633,10 @@ static int kdb_md(int argc, const char *
diag = kdbgetularg(argv[nextarg], &val);
if (!diag) {
mdcount = (int) val;
- repeat = mdcount * 16 / bytesperword;
+ if (raw)
+ repeat = mdcount;
+ else
+ repeat = mdcount * 16 / bytesperword;
}
}
if (argc >= nextarg+1) {
@@ -1638,8 +1646,15 @@ static int kdb_md(int argc, const char *
}
}

- if (strcmp(argv[0], "mdr") == 0)
- return kdb_mdr(addr, mdcount);
+ if (strcmp(argv[0], "mdr") == 0) {
+ int ret;
+ last_addr = addr;
+ ret = kdb_mdr(addr, mdcount);
+ last_addr += mdcount;
+ last_repeat = mdcount;
+ last_bytesperword = bytesperword; // to make REPEAT happy
+ return ret;
+ }

switch (radix) {
case 10:



2018-05-28 15:00:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 264/268] regulator: of: Add a missing of_node_put() in an error handling path of of_regulator_match()

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

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

From: Christophe JAILLET <[email protected]>

[ Upstream commit 30966861a7a2051457be8c49466887d78cc47e97 ]

If an unlikely failure in 'of_get_regulator_init_data()' occurs, we must
release the reference on the current 'child' node before returning.

Signed-off-by: Christophe JAILLET <[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/of_regulator.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -274,6 +274,7 @@ int of_regulator_match(struct device *de
dev_err(dev,
"failed to parse DT for regulator %s\n",
child->name);
+ of_node_put(child);
return -EINVAL;
}
match->of_node = of_node_get(child);



2018-05-28 15:00:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 260/268] netlabel: If PF_INET6, check sk_buff ip header version

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

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

From: Richard Haines <[email protected]>

[ Upstream commit 213d7f94775322ba44e0bbb55ec6946e9de88cea ]

When resolving a fallback label, check the sk_buff version as it
is possible (e.g. SCTP) to have family = PF_INET6 while
receiving ip_hdr(skb)->version = 4.

Signed-off-by: Richard Haines <[email protected]>
Acked-by: Paul Moore <[email protected]>
Signed-off-by: Paul Moore <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/netlabel/netlabel_unlabeled.c | 10 ++++++++++
1 file changed, 10 insertions(+)

--- a/net/netlabel/netlabel_unlabeled.c
+++ b/net/netlabel/netlabel_unlabeled.c
@@ -1469,6 +1469,16 @@ int netlbl_unlabel_getattr(const struct
iface = rcu_dereference(netlbl_unlhsh_def);
if (iface == NULL || !iface->valid)
goto unlabel_getattr_nolabel;
+
+#if IS_ENABLED(CONFIG_IPV6)
+ /* When resolving a fallback label, check the sk_buff version as
+ * it is possible (e.g. SCTP) to have family = PF_INET6 while
+ * receiving ip_hdr(skb)->version = 4.
+ */
+ if (family == PF_INET6 && ip_hdr(skb)->version == 4)
+ family = PF_INET;
+#endif /* IPv6 */
+
switch (family) {
case PF_INET: {
struct iphdr *hdr4;



2018-05-28 15:01:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 253/268] audit: return on memory error to avoid null pointer dereference

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

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

From: Richard Guy Briggs <[email protected]>

[ Upstream commit 23138ead270045f1b3e912e667967b6094244999 ]

If there is a memory allocation error when trying to change an audit
kernel feature value, the ignored allocation error will trigger a NULL
pointer dereference oops on subsequent use of that pointer. Return
instead.

Passes audit-testsuite.
See: https://github.com/linux-audit/audit-kernel/issues/76

Signed-off-by: Richard Guy Briggs <[email protected]>
[PM: not necessary (other funcs check for NULL), but a good practice]
Signed-off-by: Paul Moore <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/audit.c | 2 ++
1 file changed, 2 insertions(+)

--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -744,6 +744,8 @@ static void audit_log_feature_change(int
return;

ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_FEATURE_CHANGE);
+ if (!ab)
+ return;
audit_log_task_info(ab, current);
audit_log_format(ab, " feature=%s old=%u new=%u old_lock=%u new_lock=%u res=%d",
audit_feature_names[which], !!old_feature, !!new_feature,



2018-05-28 15:02:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 252/268] crypto: sunxi-ss - Add MODULE_ALIAS to sun4i-ss

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

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

From: Peter Robinson <[email protected]>

[ Upstream commit 7c73cf4cc2ac16465f5102437dc0a12d66671bd6 ]

The MODULE_ALIAS is required to enable the sun4i-ss driver to load
automatically when built at a module. Tested on a Cubietruck.

Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
Signed-off-by: Peter Robinson <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -422,6 +422,7 @@ static struct platform_driver sun4i_ss_d

module_platform_driver(sun4i_ss_driver);

+MODULE_ALIAS("platform:sun4i-ss");
MODULE_DESCRIPTION("Allwinner Security System cryptographic accelerator");
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Corentin LABBE <[email protected]>");



2018-05-28 15:02:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 259/268] selftests/net: fixes psock_fanout eBPF test case

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

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

From: Prashant Bhole <[email protected]>

[ Upstream commit ddd0010392d9cbcb95b53d11b7cafc67b373ab56 ]

eBPF test fails due to verifier failure because log_buf is too small.
Fixed by increasing log_buf size

Signed-off-by: Prashant Bhole <[email protected]>
Acked-by: Willem de Bruijn <[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]>
---
tools/testing/selftests/net/psock_fanout.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/tools/testing/selftests/net/psock_fanout.c
+++ b/tools/testing/selftests/net/psock_fanout.c
@@ -97,6 +97,8 @@ static int sock_fanout_open(uint16_t typ

static void sock_fanout_set_ebpf(int fd)
{
+ static char log_buf[65536];
+
const int len_off = __builtin_offsetof(struct __sk_buff, len);
struct bpf_insn prog[] = {
{ BPF_ALU64 | BPF_MOV | BPF_X, 6, 1, 0, 0 },
@@ -109,7 +111,6 @@ static void sock_fanout_set_ebpf(int fd)
{ BPF_ALU | BPF_MOV | BPF_K, 0, 0, 0, 0 },
{ BPF_JMP | BPF_EXIT, 0, 0, 0, 0 }
};
- char log_buf[512];
union bpf_attr attr;
int pfd;




2018-05-28 15:02:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 257/268] perf tests: Use arch__compare_symbol_names to compare symbols

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

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

From: Jiri Olsa <[email protected]>

[ Upstream commit ab6e9a99345131cd8e54268d1d0dc04a33f7ed11 ]

The symbol search called by machine__find_kernel_symbol_by_name is using
internally arch__compare_symbol_names function to compare 2 symbol
names, because different archs have different ways of comparing symbols.
Mostly for skipping '.' prefixes and similar.

In test 1 when we try to find matching symbols in kallsyms and vmlinux,
by address and by symbol name. When either is found we compare the pair
symbol names by simple strcmp, which is not good enough for reasons
explained in previous paragraph.

On powerpc this can cause lockup, because even thought we found the
pair, the compared names are different and don't match simple strcmp.
Following code path is executed, that leads to lockup:

- we find the pair in kallsyms by sym->start
next_pair:
- we compare the names and it fails
- we find the pair by sym->name
- the pair addresses match so we call goto next_pair
because we assume the names match in this case

Signed-off-by: Jiri Olsa <[email protected]>
Tested-by: Naveen N. Rao <[email protected]>
Acked-by: Naveen N. Rao <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: David Ahern <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Fixes: 031b84c407c3 ("perf probe ppc: Enable matching against dot symbols automatically")
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/vmlinux-kallsyms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/perf/tests/vmlinux-kallsyms.c
+++ b/tools/perf/tests/vmlinux-kallsyms.c
@@ -126,7 +126,7 @@ int test__vmlinux_matches_kallsyms(void)

if (pair && UM(pair->start) == mem_start) {
next_pair:
- if (strcmp(sym->name, pair->name) == 0) {
+ if (arch__compare_symbol_names(sym->name, pair->name) == 0) {
/*
* kallsyms don't have the symbol end, so we
* set that by using the next symbol start - 1,



2018-05-28 15:03:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 268/268] s390/ftrace: use expoline for indirect branches

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

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

From: Martin Schwidefsky <[email protected]>

commit 23a4d7fd34856da8218c4cfc23dba7a6ec0a423a upstream.

The return from the ftrace_stub, _mcount, ftrace_caller and
return_to_handler functions is done with "br %r14" and "br %r1".
These are indirect branches as well and need to use execute
trampolines for CONFIG_EXPOLINE=y.

The ftrace_caller function is a special case as it returns to the
start of a function and may only use %r0 and %r1. For a pre z10
machine the standard execute trampoline uses a LARL + EX to do
this, but this requires *two* registers in the range %r1..%r15.
To get around this the 'br %r1' located in the lowcore is used,
then the EX instruction does not need an address register.
But the lowcore trick may only be used for pre z14 machines,
with noexec=on the mapping for the first page may not contain
instructions. The solution for that is an ALTERNATIVE in the
expoline THUNK generated by 'GEN_BR_THUNK %r1' to switch to
EXRL, this relies on the fact that a machine that supports
noexec=on has EXRL as well.

Cc: [email protected] # 4.16
Fixes: f19fbd5ed6 ("s390: introduce execute-trampolines for branches")
Signed-off-by: Martin Schwidefsky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/s390/include/asm/nospec-insn.h | 13 +++++++++++++
arch/s390/kernel/asm-offsets.c | 1 +
arch/s390/kernel/mcount.S | 14 +++++++++-----
3 files changed, 23 insertions(+), 5 deletions(-)

--- a/arch/s390/include/asm/nospec-insn.h
+++ b/arch/s390/include/asm/nospec-insn.h
@@ -2,10 +2,15 @@
#ifndef _ASM_S390_NOSPEC_ASM_H
#define _ASM_S390_NOSPEC_ASM_H

+#include <asm/alternative-asm.h>
+#include <asm/asm-offsets.h>
+
#ifdef __ASSEMBLY__

#ifdef CONFIG_EXPOLINE

+_LC_BR_R1 = __LC_BR_R1
+
/*
* The expoline macros are used to create thunks in the same format
* as gcc generates them. The 'comdat' section flag makes sure that
@@ -101,13 +106,21 @@
.endm

.macro __THUNK_EX_BR reg,ruse
+ # Be very careful when adding instructions to this macro!
+ # The ALTERNATIVE replacement code has a .+10 which targets
+ # the "br \reg" after the code has been patched.
#ifdef CONFIG_HAVE_MARCH_Z10_FEATURES
exrl 0,555f
j .
#else
+ .ifc \reg,%r1
+ ALTERNATIVE "ex %r0,_LC_BR_R1", ".insn ril,0xc60000000000,0,.+10", 35
+ j .
+ .else
larl \ruse,555f
ex 0,0(\ruse)
j .
+ .endif
#endif
555: br \reg
.endm
--- a/arch/s390/kernel/asm-offsets.c
+++ b/arch/s390/kernel/asm-offsets.c
@@ -170,6 +170,7 @@ int main(void)
OFFSET(__LC_MACHINE_FLAGS, _lowcore, machine_flags);
OFFSET(__LC_GMAP, _lowcore, gmap);
OFFSET(__LC_PASTE, _lowcore, paste);
+ OFFSET(__LC_BR_R1, _lowcore, br_r1_trampoline);
/* software defined ABI-relevant lowcore locations 0xe00 - 0xe20 */
OFFSET(__LC_DUMP_REIPL, _lowcore, ipib);
/* hardware defined lowcore locations 0x1000 - 0x18ff */
--- a/arch/s390/kernel/mcount.S
+++ b/arch/s390/kernel/mcount.S
@@ -8,12 +8,16 @@
#include <linux/linkage.h>
#include <asm/asm-offsets.h>
#include <asm/ftrace.h>
+#include <asm/nospec-insn.h>
#include <asm/ptrace.h>

+ GEN_BR_THUNK %r1
+ GEN_BR_THUNK %r14
+
.section .kprobes.text, "ax"

ENTRY(ftrace_stub)
- br %r14
+ BR_EX %r14

#define STACK_FRAME_SIZE (STACK_FRAME_OVERHEAD + __PT_SIZE)
#define STACK_PTREGS (STACK_FRAME_OVERHEAD)
@@ -21,7 +25,7 @@ ENTRY(ftrace_stub)
#define STACK_PTREGS_PSW (STACK_PTREGS + __PT_PSW)

ENTRY(_mcount)
- br %r14
+ BR_EX %r14

ENTRY(ftrace_caller)
.globl ftrace_regs_caller
@@ -49,7 +53,7 @@ ENTRY(ftrace_caller)
#endif
lgr %r3,%r14
la %r5,STACK_PTREGS(%r15)
- basr %r14,%r1
+ BASR_EX %r14,%r1
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
# The j instruction gets runtime patched to a nop instruction.
# See ftrace_enable_ftrace_graph_caller.
@@ -64,7 +68,7 @@ ftrace_graph_caller_end:
#endif
lg %r1,(STACK_PTREGS_PSW+8)(%r15)
lmg %r2,%r15,(STACK_PTREGS_GPRS+2*8)(%r15)
- br %r1
+ BR_EX %r1

#ifdef CONFIG_FUNCTION_GRAPH_TRACER

@@ -77,6 +81,6 @@ ENTRY(return_to_handler)
aghi %r15,STACK_FRAME_OVERHEAD
lgr %r14,%r2
lmg %r2,%r5,32(%r15)
- br %r14
+ BR_EX %r14

#endif



2018-05-28 15:03:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 266/268] Bluetooth: btusb: Add device ID for RTL8822BE

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

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

From: Larry Finger <[email protected]>

[ Upstream commit fed03fe7e55b7dc16077f672bd9d7bbe92b3a691 ]

The Asus Z370-I contains a Realtek RTL8822BE device with an associated
BT chip using a USB ID of 0b05:185c. This device is added to the driver.

Signed-off-by: Hon Weng Chong <[email protected]>
Signed-off-by: Larry Finger <[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/btusb.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -346,6 +346,9 @@ static const struct usb_device_id blackl
{ USB_DEVICE(0x13d3, 0x3461), .driver_info = BTUSB_REALTEK },
{ USB_DEVICE(0x13d3, 0x3462), .driver_info = BTUSB_REALTEK },

+ /* Additional Realtek 8822BE Bluetooth devices */
+ { USB_DEVICE(0x0b05, 0x185c), .driver_info = BTUSB_REALTEK },
+
/* Silicon Wave based devices */
{ USB_DEVICE(0x0c10, 0x0000), .driver_info = BTUSB_SWAVE },




2018-05-28 15:03:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 263/268] scsi: lpfc: Fix frequency of Release WQE CQEs

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

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

From: James Smart <[email protected]>

[ Upstream commit 04673e38f56b30cd39b1fa0f386137d818b17781 ]

The driver controls when the hardware sends completions that communicate
consumption of elements from the WQ. This is done by setting a WQEC bit
on a WQE.

The current driver sets it on every Nth WQE posting. However, the driver
isn't clearing the bit if the WQE is reused. Thus, if the queue depth
isn't evenly divisible by N, with enough time, it can be set on every
element, creating a lot of overhead and risking CQ full conditions.

Correct by clearing the bit when not setting it on an Nth element.

Signed-off-by: Dick Kennedy <[email protected]>
Signed-off-by: James Smart <[email protected]>
Reviewed-by: Hannes Reinecke <[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/lpfc/lpfc_sli.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -115,6 +115,8 @@ lpfc_sli4_wq_put(struct lpfc_queue *q, u
/* set consumption flag every once in a while */
if (!((q->host_index + 1) % q->entry_repost))
bf_set(wqe_wqec, &wqe->generic.wqe_com, 1);
+ else
+ bf_set(wqe_wqec, &wqe->generic.wqe_com, 0);
if (q->phba->sli3_options & LPFC_SLI4_PHWQ_ENABLED)
bf_set(wqe_wqid, &wqe->generic.wqe_com, q->queue_id);
lpfc_sli_pcimem_bcopy(wqe, temp_wqe, q->entry_size);



2018-05-28 15:03:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 262/268] scsi: lpfc: Fix soft lockup in lpfc worker thread during LIP testing

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

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

From: James Smart <[email protected]>

[ Upstream commit 161df4f09987ae2e9f0f97f0b38eee298b4a39ff ]

During link bounce testing in a point-to-point topology, the host may
enter a soft lockup on the lpfc_worker thread:

Call Trace:
lpfc_work_done+0x1f3/0x1390 [lpfc]
lpfc_do_work+0x16f/0x180 [lpfc]
kthread+0xc7/0xe0
ret_from_fork+0x3f/0x70

The driver was simultaneously setting a combination of flags that caused
lpfc_do_work()to effectively spin between slow path work and new event
data, causing the lockup.

Ensure in the typical wq completions, that new event data flags are set
if the slow path flag is running. The slow path will eventually
reschedule the wq handling.

Signed-off-by: Dick Kennedy <[email protected]>
Signed-off-by: James Smart <[email protected]>
Reviewed-by: Hannes Reinecke <[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/lpfc/lpfc_hbadisc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/scsi/lpfc/lpfc_hbadisc.c
+++ b/drivers/scsi/lpfc/lpfc_hbadisc.c
@@ -691,8 +691,9 @@ lpfc_work_done(struct lpfc_hba *phba)
(phba->hba_flag & HBA_SP_QUEUE_EVT)) {
if (pring->flag & LPFC_STOP_IOCB_EVENT) {
pring->flag |= LPFC_DEFERRED_RING_EVENT;
- /* Set the lpfc data pending flag */
- set_bit(LPFC_DATA_READY, &phba->data_flags);
+ /* Preserve legacy behavior. */
+ if (!(phba->hba_flag & HBA_SP_QUEUE_EVT))
+ set_bit(LPFC_DATA_READY, &phba->data_flags);
} else {
if (phba->link_state >= LPFC_LINK_UP) {
pring->flag &= ~LPFC_DEFERRED_RING_EVENT;



2018-05-28 15:04:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 251/268] clk: samsung: exynos3250: Fix PLL rates

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

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

From: Andrzej Hajda <[email protected]>

[ Upstream commit a8321e7887410a2b2e80ab89d1ef7b30562658ea ]

Rates declared in PLL rate tables should match exactly rates calculated
from PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate
will return 393216003. If we now attempt to set rate of a PLL's child divider
clock to 393216000/2 its rate will be 131072001, rather than 196608000.
That is, the divider will be set to 3 instead of 2, because 393216003/2 is
greater than 196608000.

To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.

In this patch an erroneous P value for 74176002 output frequency is also
corrected.

Signed-off-by: Andrzej Hajda <[email protected]>
Acked-by: Chanwoo Choi <[email protected]>
Acked-by: Tomasz Figa <[email protected]>
Signed-off-by: Sylwester Nawrocki <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/clk/samsung/clk-exynos3250.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -683,7 +683,7 @@ static struct samsung_pll_rate_table exy
PLL_36XX_RATE(144000000, 96, 2, 3, 0),
PLL_36XX_RATE( 96000000, 128, 2, 4, 0),
PLL_36XX_RATE( 84000000, 112, 2, 4, 0),
- PLL_36XX_RATE( 80000004, 106, 2, 4, 43691),
+ PLL_36XX_RATE( 80000003, 106, 2, 4, 43691),
PLL_36XX_RATE( 73728000, 98, 2, 4, 19923),
PLL_36XX_RATE( 67737598, 270, 3, 5, 62285),
PLL_36XX_RATE( 65535999, 174, 2, 5, 49982),
@@ -719,7 +719,7 @@ static struct samsung_pll_rate_table exy
PLL_36XX_RATE(148352005, 98, 2, 3, 59070),
PLL_36XX_RATE(108000000, 144, 2, 4, 0),
PLL_36XX_RATE( 74250000, 99, 2, 4, 0),
- PLL_36XX_RATE( 74176002, 98, 3, 4, 59070),
+ PLL_36XX_RATE( 74176002, 98, 2, 4, 59070),
PLL_36XX_RATE( 54054000, 216, 3, 5, 14156),
PLL_36XX_RATE( 54000000, 144, 2, 5, 0),
{ /* sentinel */ }



2018-05-28 15:04:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 223/268] usb: gadget: udc: change comparison to bitshift when dealing with a mask

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

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

From: Wolfram Sang <[email protected]>

[ Upstream commit ac87e560f7c0f91b62012e9a159c0681a373b922 ]

Due to a typo, the mask was destroyed by a comparison instead of a bit
shift.

Reported-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/udc/goku_udc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/gadget/udc/goku_udc.h
+++ b/drivers/usb/gadget/udc/goku_udc.h
@@ -28,7 +28,7 @@ struct goku_udc_regs {
# define INT_EP1DATASET 0x00040
# define INT_EP2DATASET 0x00080
# define INT_EP3DATASET 0x00100
-#define INT_EPnNAK(n) (0x00100 < (n)) /* 0 < n < 4 */
+#define INT_EPnNAK(n) (0x00100 << (n)) /* 0 < n < 4 */
# define INT_EP1NAK 0x00200
# define INT_EP2NAK 0x00400
# define INT_EP3NAK 0x00800



2018-05-28 15:04:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 221/268] cdrom: do not call check_disk_change() inside cdrom_open()

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

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

From: Maurizio Lombardi <[email protected]>

[ Upstream commit 2bbea6e117357d17842114c65e9a9cf2d13ae8a3 ]

when mounting an ISO filesystem sometimes (very rarely)
the system hangs because of a race condition between two tasks.

PID: 6766 TASK: ffff88007b2a6dd0 CPU: 0 COMMAND: "mount"
#0 [ffff880078447ae0] __schedule at ffffffff8168d605
#1 [ffff880078447b48] schedule_preempt_disabled at ffffffff8168ed49
#2 [ffff880078447b58] __mutex_lock_slowpath at ffffffff8168c995
#3 [ffff880078447bb8] mutex_lock at ffffffff8168bdef
#4 [ffff880078447bd0] sr_block_ioctl at ffffffffa00b6818 [sr_mod]
#5 [ffff880078447c10] blkdev_ioctl at ffffffff812fea50
#6 [ffff880078447c70] ioctl_by_bdev at ffffffff8123a8b3
#7 [ffff880078447c90] isofs_fill_super at ffffffffa04fb1e1 [isofs]
#8 [ffff880078447da8] mount_bdev at ffffffff81202570
#9 [ffff880078447e18] isofs_mount at ffffffffa04f9828 [isofs]
#10 [ffff880078447e28] mount_fs at ffffffff81202d09
#11 [ffff880078447e70] vfs_kern_mount at ffffffff8121ea8f
#12 [ffff880078447ea8] do_mount at ffffffff81220fee
#13 [ffff880078447f28] sys_mount at ffffffff812218d6
#14 [ffff880078447f80] system_call_fastpath at ffffffff81698c49
RIP: 00007fd9ea914e9a RSP: 00007ffd5d9bf648 RFLAGS: 00010246
RAX: 00000000000000a5 RBX: ffffffff81698c49 RCX: 0000000000000010
RDX: 00007fd9ec2bc210 RSI: 00007fd9ec2bc290 RDI: 00007fd9ec2bcf30
RBP: 0000000000000000 R8: 0000000000000000 R9: 0000000000000010
R10: 00000000c0ed0001 R11: 0000000000000206 R12: 00007fd9ec2bc040
R13: 00007fd9eb6b2380 R14: 00007fd9ec2bc210 R15: 00007fd9ec2bcf30
ORIG_RAX: 00000000000000a5 CS: 0033 SS: 002b

This task was trying to mount the cdrom. It allocated and configured a
super_block struct and owned the write-lock for the super_block->s_umount
rwsem. While exclusively owning the s_umount lock, it called
sr_block_ioctl and waited to acquire the global sr_mutex lock.

PID: 6785 TASK: ffff880078720fb0 CPU: 0 COMMAND: "systemd-udevd"
#0 [ffff880078417898] __schedule at ffffffff8168d605
#1 [ffff880078417900] schedule at ffffffff8168dc59
#2 [ffff880078417910] rwsem_down_read_failed at ffffffff8168f605
#3 [ffff880078417980] call_rwsem_down_read_failed at ffffffff81328838
#4 [ffff8800784179d0] down_read at ffffffff8168cde0
#5 [ffff8800784179e8] get_super at ffffffff81201cc7
#6 [ffff880078417a10] __invalidate_device at ffffffff8123a8de
#7 [ffff880078417a40] flush_disk at ffffffff8123a94b
#8 [ffff880078417a88] check_disk_change at ffffffff8123ab50
#9 [ffff880078417ab0] cdrom_open at ffffffffa00a29e1 [cdrom]
#10 [ffff880078417b68] sr_block_open at ffffffffa00b6f9b [sr_mod]
#11 [ffff880078417b98] __blkdev_get at ffffffff8123ba86
#12 [ffff880078417bf0] blkdev_get at ffffffff8123bd65
#13 [ffff880078417c78] blkdev_open at ffffffff8123bf9b
#14 [ffff880078417c90] do_dentry_open at ffffffff811fc7f7
#15 [ffff880078417cd8] vfs_open at ffffffff811fc9cf
#16 [ffff880078417d00] do_last at ffffffff8120d53d
#17 [ffff880078417db0] path_openat at ffffffff8120e6b2
#18 [ffff880078417e48] do_filp_open at ffffffff8121082b
#19 [ffff880078417f18] do_sys_open at ffffffff811fdd33
#20 [ffff880078417f70] sys_open at ffffffff811fde4e
#21 [ffff880078417f80] system_call_fastpath at ffffffff81698c49
RIP: 00007f29438b0c20 RSP: 00007ffc76624b78 RFLAGS: 00010246
RAX: 0000000000000002 RBX: ffffffff81698c49 RCX: 0000000000000000
RDX: 00007f2944a5fa70 RSI: 00000000000a0800 RDI: 00007f2944a5fa70
RBP: 00007f2944a5f540 R8: 0000000000000000 R9: 0000000000000020
R10: 00007f2943614c40 R11: 0000000000000246 R12: ffffffff811fde4e
R13: ffff880078417f78 R14: 000000000000000c R15: 00007f2944a4b010
ORIG_RAX: 0000000000000002 CS: 0033 SS: 002b

This task tried to open the cdrom device, the sr_block_open function
acquired the global sr_mutex lock. The call to check_disk_change()
then saw an event flag indicating a possible media change and tried
to flush any cached data for the device.
As part of the flush, it tried to acquire the super_block->s_umount
lock associated with the cdrom device.
This was the same super_block as created and locked by the previous task.

The first task acquires the s_umount lock and then the sr_mutex_lock;
the second task acquires the sr_mutex_lock and then the s_umount lock.

This patch fixes the issue by moving check_disk_change() out of
cdrom_open() and let the caller take care of it.

Signed-off-by: Maurizio Lombardi <[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/paride/pcd.c | 2 ++
drivers/cdrom/cdrom.c | 3 ---
drivers/cdrom/gdrom.c | 3 +++
drivers/ide/ide-cd.c | 2 ++
drivers/scsi/sr.c | 2 ++
5 files changed, 9 insertions(+), 3 deletions(-)

--- a/drivers/block/paride/pcd.c
+++ b/drivers/block/paride/pcd.c
@@ -230,6 +230,8 @@ static int pcd_block_open(struct block_d
struct pcd_unit *cd = bdev->bd_disk->private_data;
int ret;

+ check_disk_change(bdev);
+
mutex_lock(&pcd_mutex);
ret = cdrom_open(&cd->info, bdev, mode);
mutex_unlock(&pcd_mutex);
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -1154,9 +1154,6 @@ int cdrom_open(struct cdrom_device_info

cd_dbg(CD_OPEN, "entering cdrom_open\n");

- /* open is event synchronization point, check events first */
- check_disk_change(bdev);
-
/* if this was a O_NONBLOCK open and we should honor the flags,
* do a quick open without drive/disc integrity checks. */
cdi->use_count++;
--- a/drivers/cdrom/gdrom.c
+++ b/drivers/cdrom/gdrom.c
@@ -497,6 +497,9 @@ static struct cdrom_device_ops gdrom_ops
static int gdrom_bdops_open(struct block_device *bdev, fmode_t mode)
{
int ret;
+
+ check_disk_change(bdev);
+
mutex_lock(&gdrom_mutex);
ret = cdrom_open(gd.cd_info, bdev, mode);
mutex_unlock(&gdrom_mutex);
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -1593,6 +1593,8 @@ static int idecd_open(struct block_devic
struct cdrom_info *info;
int rc = -ENXIO;

+ check_disk_change(bdev);
+
mutex_lock(&ide_cd_mutex);
info = ide_cd_get(bdev->bd_disk);
if (!info)
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -522,6 +522,8 @@ static int sr_block_open(struct block_de
struct scsi_cd *cd;
int ret = -ENXIO;

+ check_disk_change(bdev);
+
mutex_lock(&sr_mutex);
cd = scsi_cd_get(bdev->bd_disk);
if (cd) {



2018-05-28 15:05:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 220/268] hwmon: (pmbus/adm1275) Accept negative page register values

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

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

From: Guenter Roeck <[email protected]>

[ Upstream commit ecb29abd4cb0670c616fb563a078f25d777ce530 ]

A negative page register value means that no page needs to be
selected. This is used by status register read operations and needs
to be accepted. The failure to do so so results in missed status
and limit registers.

Fixes: da8e48ab483e1 ("hwmon: (pmbus) Always call _pmbus_read_byte in core driver")
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hwmon/pmbus/adm1275.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/hwmon/pmbus/adm1275.c
+++ b/drivers/hwmon/pmbus/adm1275.c
@@ -141,7 +141,7 @@ static int adm1275_read_word_data(struct
const struct adm1275_data *data = to_adm1275_data(info);
int ret = 0;

- if (page)
+ if (page > 0)
return -ENXIO;

switch (reg) {
@@ -218,7 +218,7 @@ static int adm1275_write_word_data(struc
const struct adm1275_data *data = to_adm1275_data(info);
int ret;

- if (page)
+ if (page > 0)
return -ENXIO;

switch (reg) {



2018-05-28 15:05:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 222/268] gfs2: Fix fallocate chunk size

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

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

From: Andreas Gruenbacher <[email protected]>

[ Upstream commit 174d1232ebc84fcde8f5889d1171c9c7e74a10a7 ]

The chunk size of allocations in __gfs2_fallocate is calculated
incorrectly. The size can collapse, causing __gfs2_fallocate to
allocate one block at a time, which is very inefficient. This needs
fixing in two places:

In gfs2_quota_lock_check, always set ap->allowed to UINT_MAX to indicate
that there is no quota limit. This fixes callers that rely on
ap->allowed to be set even when quotas are off.

In __gfs2_fallocate, reset max_blks to UINT_MAX in each iteration of the
loop to make sure that allocation limits from one resource group won't
spill over into another resource group.

Signed-off-by: Andreas Gruenbacher <[email protected]>
Signed-off-by: Bob Peterson <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/gfs2/file.c | 5 +++--
fs/gfs2/quota.h | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)

--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -806,7 +806,7 @@ static long __gfs2_fallocate(struct file
struct gfs2_inode *ip = GFS2_I(inode);
struct gfs2_alloc_parms ap = { .aflags = 0, };
unsigned int data_blocks = 0, ind_blocks = 0, rblocks;
- loff_t bytes, max_bytes, max_blks = UINT_MAX;
+ loff_t bytes, max_bytes, max_blks;
int error;
const loff_t pos = offset;
const loff_t count = len;
@@ -858,7 +858,8 @@ static long __gfs2_fallocate(struct file
return error;
/* ap.allowed tells us how many blocks quota will allow
* us to write. Check if this reduces max_blks */
- if (ap.allowed && ap.allowed < max_blks)
+ max_blks = UINT_MAX;
+ if (ap.allowed)
max_blks = ap.allowed;

error = gfs2_inplace_reserve(ip, &ap);
--- a/fs/gfs2/quota.h
+++ b/fs/gfs2/quota.h
@@ -43,6 +43,8 @@ static inline int gfs2_quota_lock_check(
{
struct gfs2_sbd *sdp = GFS2_SB(&ip->i_inode);
int ret;
+
+ ap->allowed = UINT_MAX; /* Assume we are permitted a whole lot */
if (sdp->sd_args.ar_quota == GFS2_QUOTA_OFF)
return 0;
ret = gfs2_quota_lock(ip, NO_UID_QUOTA_CHANGE, NO_GID_QUOTA_CHANGE);



2018-05-28 15:05:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 247/268] clk: samsung: s3c2410: Fix PLL rates

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

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

From: Andrzej Hajda <[email protected]>

[ Upstream commit 179db533c08431f509a3823077549773d519358b ]

Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate
will return 393216003. If we now attempt to set rate of a PLL's child divider
clock to 393216000/2 its rate will be 131072001, rather than 196608000.
That is, the divider will be set to 3 instead of 2, because 393216003/2 is
greater than 196608000.

To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.

Signed-off-by: Andrzej Hajda <[email protected]>
Acked-by: Tomasz Figa <[email protected]>
Acked-by: Chanwoo Choi <[email protected]>
Signed-off-by: Sylwester Nawrocki <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/clk/samsung/clk-s3c2410.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

--- a/drivers/clk/samsung/clk-s3c2410.c
+++ b/drivers/clk/samsung/clk-s3c2410.c
@@ -168,7 +168,7 @@ static struct samsung_pll_rate_table pll
PLL_35XX_RATE(226000000, 105, 1, 1),
PLL_35XX_RATE(210000000, 132, 2, 1),
/* 2410 common */
- PLL_35XX_RATE(203000000, 161, 3, 1),
+ PLL_35XX_RATE(202800000, 161, 3, 1),
PLL_35XX_RATE(192000000, 88, 1, 1),
PLL_35XX_RATE(186000000, 85, 1, 1),
PLL_35XX_RATE(180000000, 82, 1, 1),
@@ -178,18 +178,18 @@ static struct samsung_pll_rate_table pll
PLL_35XX_RATE(147000000, 90, 2, 1),
PLL_35XX_RATE(135000000, 82, 2, 1),
PLL_35XX_RATE(124000000, 116, 1, 2),
- PLL_35XX_RATE(118000000, 150, 2, 2),
+ PLL_35XX_RATE(118500000, 150, 2, 2),
PLL_35XX_RATE(113000000, 105, 1, 2),
- PLL_35XX_RATE(101000000, 127, 2, 2),
+ PLL_35XX_RATE(101250000, 127, 2, 2),
PLL_35XX_RATE(90000000, 112, 2, 2),
- PLL_35XX_RATE(85000000, 105, 2, 2),
+ PLL_35XX_RATE(84750000, 105, 2, 2),
PLL_35XX_RATE(79000000, 71, 1, 2),
- PLL_35XX_RATE(68000000, 82, 2, 2),
- PLL_35XX_RATE(56000000, 142, 2, 3),
+ PLL_35XX_RATE(67500000, 82, 2, 2),
+ PLL_35XX_RATE(56250000, 142, 2, 3),
PLL_35XX_RATE(48000000, 120, 2, 3),
- PLL_35XX_RATE(51000000, 161, 3, 3),
+ PLL_35XX_RATE(50700000, 161, 3, 3),
PLL_35XX_RATE(45000000, 82, 1, 3),
- PLL_35XX_RATE(34000000, 82, 2, 3),
+ PLL_35XX_RATE(33750000, 82, 2, 3),
{ /* sentinel */ },
};




2018-05-28 15:06:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 249/268] clk: samsung: exynos5433: Fix PLL rates

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

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

From: Andrzej Hajda <[email protected]>

[ Upstream commit ab0447845cffc0fd752df2ccd6b4e34006000ce4 ]

Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate
will return 393216003. If we now attempt to set rate of a PLL's child divider
clock to 393216000/2 its rate will be 131072001, rather than 196608000.
That is, the divider will be set to 3 instead of 2, because 393216003/2 is
greater than 196608000.

To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.

Signed-off-by: Andrzej Hajda <[email protected]>
Acked-by: Tomasz Figa <[email protected]>
Acked-by: Chanwoo Choi <[email protected]>
Signed-off-by: Sylwester Nawrocki <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/clk/samsung/clk-exynos5433.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -747,7 +747,7 @@ static struct samsung_pll_rate_table exy
PLL_35XX_RATE(800000000U, 400, 6, 1),
PLL_35XX_RATE(733000000U, 733, 12, 1),
PLL_35XX_RATE(700000000U, 175, 3, 1),
- PLL_35XX_RATE(667000000U, 222, 4, 1),
+ PLL_35XX_RATE(666000000U, 222, 4, 1),
PLL_35XX_RATE(633000000U, 211, 4, 1),
PLL_35XX_RATE(600000000U, 500, 5, 2),
PLL_35XX_RATE(552000000U, 460, 5, 2),
@@ -773,12 +773,12 @@ static struct samsung_pll_rate_table exy
/* AUD_PLL */
static struct samsung_pll_rate_table exynos5443_aud_pll_rates[] = {
PLL_36XX_RATE(400000000U, 200, 3, 2, 0),
- PLL_36XX_RATE(393216000U, 197, 3, 2, -25690),
+ PLL_36XX_RATE(393216003U, 197, 3, 2, -25690),
PLL_36XX_RATE(384000000U, 128, 2, 2, 0),
- PLL_36XX_RATE(368640000U, 246, 4, 2, -15729),
- PLL_36XX_RATE(361507200U, 181, 3, 2, -16148),
- PLL_36XX_RATE(338688000U, 113, 2, 2, -6816),
- PLL_36XX_RATE(294912000U, 98, 1, 3, 19923),
+ PLL_36XX_RATE(368639991U, 246, 4, 2, -15729),
+ PLL_36XX_RATE(361507202U, 181, 3, 2, -16148),
+ PLL_36XX_RATE(338687988U, 113, 2, 2, -6816),
+ PLL_36XX_RATE(294912002U, 98, 1, 3, 19923),
PLL_36XX_RATE(288000000U, 96, 1, 3, 0),
PLL_36XX_RATE(252000000U, 84, 1, 3, 0),
{ /* sentinel */ }



2018-05-28 15:06:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 248/268] clk: samsung: exynos5260: Fix PLL rates

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

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

From: Andrzej Hajda <[email protected]>

[ Upstream commit cdb68fbd4e7962be742c4f29475220c5bf28d8a5 ]

Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a 393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is 393216003, after setting PLL's clk rate to 393216000 clk_get_rate
will return 393216003. If we now attempt to set rate of a PLL's child divider
clock to 393216000/2 its rate will be 131072001, rather than 196608000.
That is, the divider will be set to 3 instead of 2, because 393216003/2 is
greater than 196608000.

To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.

Signed-off-by: Andrzej Hajda <[email protected]>
Acked-by: Tomasz Figa <[email protected]>
Acked-by: Chanwoo Choi <[email protected]>
Signed-off-by: Sylwester Nawrocki <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/clk/samsung/clk-exynos5260.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/clk/samsung/clk-exynos5260.c
+++ b/drivers/clk/samsung/clk-exynos5260.c
@@ -65,7 +65,7 @@ static struct samsung_pll_rate_table pll
PLL_36XX_RATE(480000000, 160, 2, 2, 0),
PLL_36XX_RATE(432000000, 144, 2, 2, 0),
PLL_36XX_RATE(400000000, 200, 3, 2, 0),
- PLL_36XX_RATE(394073130, 459, 7, 2, 49282),
+ PLL_36XX_RATE(394073128, 459, 7, 2, 49282),
PLL_36XX_RATE(333000000, 111, 2, 2, 0),
PLL_36XX_RATE(300000000, 100, 2, 2, 0),
PLL_36XX_RATE(266000000, 266, 3, 3, 0),



2018-05-28 15:06:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 246/268] media: cx25821: prevent out-of-bounds read on array card

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

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

From: Colin Ian King <[email protected]>

[ Upstream commit 67300abdbe9f1717532aaf4e037222762716d0f6 ]

Currently an out of range dev->nr is detected by just reporting the
issue and later on an out-of-bounds read on array card occurs because
of this. Fix this by checking the upper range of dev->nr with the size
of array card (removes the hard coded size), move this check earlier
and also exit with the error -ENOSYS to avoid the later out-of-bounds
array read.

Detected by CoverityScan, CID#711191 ("Out-of-bounds-read")

Fixes: commit 02b20b0b4cde ("V4L/DVB (12730): Add conexant cx25821 driver")

Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
[[email protected]: %ld -> %zd]
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/cx25821/cx25821-core.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/media/pci/cx25821/cx25821-core.c
+++ b/drivers/media/pci/cx25821/cx25821-core.c
@@ -871,6 +871,10 @@ static int cx25821_dev_setup(struct cx25
dev->nr = ++cx25821_devcount;
sprintf(dev->name, "cx25821[%d]", dev->nr);

+ if (dev->nr >= ARRAY_SIZE(card)) {
+ CX25821_INFO("dev->nr >= %zd", ARRAY_SIZE(card));
+ return -ENODEV;
+ }
if (dev->pci->device != 0x8210) {
pr_info("%s(): Exiting. Incorrect Hardware device = 0x%02x\n",
__func__, dev->pci->device);
@@ -886,9 +890,6 @@ static int cx25821_dev_setup(struct cx25
dev->channels[i].sram_channels = &cx25821_sram_channels[i];
}

- if (dev->nr > 1)
- CX25821_INFO("dev->nr > 1!");
-
/* board config */
dev->board = 1; /* card[dev->nr]; */
dev->_max_num_decoders = MAX_DECODERS;



2018-05-28 15:06:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 224/268] usb: gadget: composite: fix incorrect handling of OS desc requests

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

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

From: Chris Dickens <[email protected]>

[ Upstream commit 5d6ae4f0da8a64a185074dabb1b2f8c148efa741 ]

When handling an OS descriptor request, one of the first operations is
to zero out the request buffer using the wLength from the setup packet.
There is no bounds checking, so a wLength > 4096 would clobber memory
adjacent to the request buffer. Fix this by taking the min of wLength
and the request buffer length prior to the memset. While at it, define
the buffer length in a header file so that magic numbers don't appear
throughout the code.

When returning data to the host, the data length should be the min of
the wLength and the valid data we have to return. Currently we are
returning wLength, thus requests for a wLength greater than the amount
of data in the OS descriptor buffer would return invalid (albeit zero'd)
data following the valid descriptor data. Fix this by counting the
number of bytes when constructing the data and using this when
determining the length of the request.

Signed-off-by: Chris Dickens <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/composite.c | 40 +++++++++++++++++++---------------------
include/linux/usb/composite.h | 3 +++
2 files changed, 22 insertions(+), 21 deletions(-)

--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1328,7 +1328,7 @@ static int count_ext_compat(struct usb_c
return res;
}

-static void fill_ext_compat(struct usb_configuration *c, u8 *buf)
+static int fill_ext_compat(struct usb_configuration *c, u8 *buf)
{
int i, count;

@@ -1355,10 +1355,12 @@ static void fill_ext_compat(struct usb_c
buf += 23;
}
count += 24;
- if (count >= 4096)
- return;
+ if (count + 24 >= USB_COMP_EP0_OS_DESC_BUFSIZ)
+ return count;
}
}
+
+ return count;
}

static int count_ext_prop(struct usb_configuration *c, int interface)
@@ -1403,25 +1405,20 @@ static int fill_ext_prop(struct usb_conf
struct usb_os_desc *d;
struct usb_os_desc_ext_prop *ext_prop;
int j, count, n, ret;
- u8 *start = buf;

f = c->interface[interface];
+ count = 10; /* header length */
for (j = 0; j < f->os_desc_n; ++j) {
if (interface != f->os_desc_table[j].if_id)
continue;
d = f->os_desc_table[j].os_desc;
if (d)
list_for_each_entry(ext_prop, &d->ext_prop, entry) {
- /* 4kB minus header length */
- n = buf - start;
- if (n >= 4086)
- return 0;
-
- count = ext_prop->data_len +
+ n = ext_prop->data_len +
ext_prop->name_len + 14;
- if (count > 4086 - n)
- return -EINVAL;
- usb_ext_prop_put_size(buf, count);
+ if (count + n >= USB_COMP_EP0_OS_DESC_BUFSIZ)
+ return count;
+ usb_ext_prop_put_size(buf, n);
usb_ext_prop_put_type(buf, ext_prop->type);
ret = usb_ext_prop_put_name(buf, ext_prop->name,
ext_prop->name_len);
@@ -1447,11 +1444,12 @@ static int fill_ext_prop(struct usb_conf
default:
return -EINVAL;
}
- buf += count;
+ buf += n;
+ count += n;
}
}

- return 0;
+ return count;
}

/*
@@ -1720,6 +1718,7 @@ unknown:
req->complete = composite_setup_complete;
buf = req->buf;
os_desc_cfg = cdev->os_desc_config;
+ w_length = min_t(u16, w_length, USB_COMP_EP0_OS_DESC_BUFSIZ);
memset(buf, 0, w_length);
buf[5] = 0x01;
switch (ctrl->bRequestType & USB_RECIP_MASK) {
@@ -1743,8 +1742,8 @@ unknown:
count += 16; /* header */
put_unaligned_le32(count, buf);
buf += 16;
- fill_ext_compat(os_desc_cfg, buf);
- value = w_length;
+ value = fill_ext_compat(os_desc_cfg, buf);
+ value = min_t(u16, w_length, value);
}
break;
case USB_RECIP_INTERFACE:
@@ -1773,8 +1772,7 @@ unknown:
interface, buf);
if (value < 0)
return value;
-
- value = w_length;
+ value = min_t(u16, w_length, value);
}
break;
}
@@ -2038,8 +2036,8 @@ int composite_os_desc_req_prepare(struct
goto end;
}

- /* OS feature descriptor length <= 4kB */
- cdev->os_desc_req->buf = kmalloc(4096, GFP_KERNEL);
+ cdev->os_desc_req->buf = kmalloc(USB_COMP_EP0_OS_DESC_BUFSIZ,
+ GFP_KERNEL);
if (!cdev->os_desc_req->buf) {
ret = PTR_ERR(cdev->os_desc_req->buf);
kfree(cdev->os_desc_req);
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -53,6 +53,9 @@
/* big enough to hold our biggest descriptor */
#define USB_COMP_EP0_BUFSIZ 1024

+/* OS feature descriptor length <= 4kB */
+#define USB_COMP_EP0_OS_DESC_BUFSIZ 4096
+
#define USB_MS_TO_HS_INTERVAL(x) (ilog2((x * 1000 / 125)) + 1)
struct usb_configuration;




2018-05-28 15:06:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 243/268] serial: arc_uart: Fix out-of-bounds access through DT alias

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

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

From: Geert Uytterhoeven <[email protected]>

[ Upstream commit f9f5786987e81d166c60833edcb7d1836aa16944 ]

The arc_uart_ports[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.

Fix this by adding a range check.

Note that the array size is defined by a Kconfig symbol
(CONFIG_SERIAL_ARC_NR_PORTS), so this can even be triggered using a
legitimate DTB.

Fixes: ea28fd56fcde69af ("serial/arc-uart: switch to devicetree based probing")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/arc_uart.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/tty/serial/arc_uart.c
+++ b/drivers/tty/serial/arc_uart.c
@@ -597,6 +597,11 @@ static int arc_serial_probe(struct platf
if (dev_id < 0)
dev_id = 0;

+ if (dev_id >= ARRAY_SIZE(arc_uart_ports)) {
+ dev_err(&pdev->dev, "serial%d out of range\n", dev_id);
+ return -EINVAL;
+ }
+
uart = &arc_uart_ports[dev_id];
port = &uart->port;




2018-05-28 15:06:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 242/268] serial: fsl_lpuart: Fix out-of-bounds access through DT alias

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

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

From: Geert Uytterhoeven <[email protected]>

[ Upstream commit ffab87fdecc655cc676f8be8dd1a2c5e22bd6d47 ]

The lpuart_ports[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.

Fix this by adding a range check.

Fixes: c9e2e946fb0ba5d2 ("tty: serial: add Freescale lpuart driver support")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/fsl_lpuart.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -1818,6 +1818,10 @@ static int lpuart_probe(struct platform_
dev_err(&pdev->dev, "failed to get alias id, errno %d\n", ret);
return ret;
}
+ if (ret >= ARRAY_SIZE(lpuart_ports)) {
+ dev_err(&pdev->dev, "serial%d out of range\n", ret);
+ return -EINVAL;
+ }
sport->port.line = ret;
sport->lpuart32 = of_device_is_compatible(np, "fsl,ls1021a-lpuart");




2018-05-28 15:06:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 218/268] perf/core: Fix perf_output_read_group()

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

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

From: Peter Zijlstra <[email protected]>

[ Upstream commit 9e5b127d6f33468143d90c8a45ca12410e4c3fa7 ]

Mark reported his arm64 perf fuzzer runs sometimes splat like:

armv8pmu_read_counter+0x1e8/0x2d8
armpmu_event_update+0x8c/0x188
armpmu_read+0xc/0x18
perf_output_read+0x550/0x11e8
perf_event_read_event+0x1d0/0x248
perf_event_exit_task+0x468/0xbb8
do_exit+0x690/0x1310
do_group_exit+0xd0/0x2b0
get_signal+0x2e8/0x17a8
do_signal+0x144/0x4f8
do_notify_resume+0x148/0x1e8
work_pending+0x8/0x14

which asserts that we only call pmu::read() on ACTIVE events.

The above callchain does:

perf_event_exit_task()
perf_event_exit_task_context()
task_ctx_sched_out() // INACTIVE
perf_event_exit_event()
perf_event_set_state(EXIT) // EXIT
sync_child_event()
perf_event_read_event()
perf_output_read()
perf_output_read_group()
leader->pmu->read()

Which results in doing a pmu::read() on an !ACTIVE event.

I _think_ this is 'new' since we added attr.inherit_stat, which added
the perf_event_read_event() to the exit path, without that
perf_event_read_output() would only trigger from samples and for
@event to trigger a sample, it's leader _must_ be ACTIVE too.

Still, adding this check makes it consistent with the @sub case for
the siblings.

Reported-and-Tested-by: Mark Rutland <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Cc: [email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/events/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5299,7 +5299,8 @@ static void perf_output_read_group(struc
if (read_format & PERF_FORMAT_TOTAL_TIME_RUNNING)
values[n++] = running;

- if (leader != event)
+ if ((leader != event) &&
+ (leader->state == PERF_EVENT_STATE_ACTIVE))
leader->pmu->read(leader);

values[n++] = perf_event_count(leader);



2018-05-28 15:07:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 244/268] PCI: Add function 1 DMA alias quirk for Marvell 88SE9220

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

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

From: Thomas Vincent-Cross <[email protected]>

[ Upstream commit 832e4e1f76b8a84991e9db56fdcef1ebce839b8b ]

Add Marvell 88SE9220 DMA quirk as found and tested on bug 42679.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679
Signed-off-by: Thomas Vincent-Cross <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pci/quirks.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3628,6 +3628,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_M
/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c46 */
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x91a0,
quirk_dma_func1_alias);
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c127 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9220,
+ quirk_dma_func1_alias);
/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c49 */
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9230,
quirk_dma_func1_alias);



2018-05-28 15:07:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 239/268] serial: samsung: Fix out-of-bounds access through serial port index

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

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

From: Geert Uytterhoeven <[email protected]>

[ Upstream commit 49ee23b71877831ac087d6083f6f397dc19c9664 ]

The s3c24xx_serial_ports[] array is indexed using a value derived from
the "serialN" alias in DT, or from an incrementing probe index, which
may lead to an out-of-bounds access.

Fix this by adding a range check.

Note that the array size is defined by a Kconfig symbol
(CONFIG_SERIAL_SAMSUNG_UARTS), so this can even be triggered using
a legitimate DTB or legitimate board code.

Fixes: 13a9f6c64fdc55eb ("serial: samsung: Consider DT alias when probing ports")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/samsung.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1807,6 +1807,10 @@ static int s3c24xx_serial_probe(struct p

dbg("s3c24xx_serial_probe(%p) %d\n", pdev, index);

+ if (index >= ARRAY_SIZE(s3c24xx_serial_ports)) {
+ dev_err(&pdev->dev, "serial%d out of range\n", index);
+ return -EINVAL;
+ }
ourport = &s3c24xx_serial_ports[index];

ourport->drv_data = s3c24xx_get_driver_data(pdev);



2018-05-28 15:07:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 238/268] serial: xuartps: Fix out-of-bounds access through DT alias

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

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

From: Geert Uytterhoeven <[email protected]>

[ Upstream commit e7d75e18d0fc3f7193b65282b651f980c778d935 ]

The cdns_uart_port[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.

Fix this by adding a range check.

Fixes: 928e9263492069ee ("tty: xuartps: Initialize ports according to aliases")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Michal Simek <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/xilinx_uartps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1026,7 +1026,7 @@ static struct uart_port *cdns_uart_get_p
struct uart_port *port;

/* Try the given port id if failed use default method */
- if (cdns_uart_port[id].mapbase != 0) {
+ if (id < CDNS_UART_NR_PORTS && cdns_uart_port[id].mapbase != 0) {
/* Find the next unused port */
for (id = 0; id < CDNS_UART_NR_PORTS; id++)
if (cdns_uart_port[id].mapbase == 0)



2018-05-28 15:08:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 237/268] rtc: tx4939: avoid unintended sign extension on a 24 bit shift

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

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

From: Colin Ian King <[email protected]>

[ Upstream commit 347876ad47b9923ce26e686173bbf46581802ffa ]

The shifting of buf[5] by 24 bits to the left will be promoted to
a 32 bit signed int and then sign-extended to an unsigned long. If
the top bit of buf[5] is set then all then all the upper bits sec
end up as also being set because of the sign-extension. Fix this by
casting buf[5] to an unsigned long before the shift.

Detected by CoverityScan, CID#1465292 ("Unintended sign extension")

Fixes: 0e1492330cd2 ("rtc: add rtc-tx4939 driver")
Signed-off-by: Colin Ian King <[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-tx4939.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/rtc/rtc-tx4939.c
+++ b/drivers/rtc/rtc-tx4939.c
@@ -86,7 +86,8 @@ static int tx4939_rtc_read_time(struct d
for (i = 2; i < 6; i++)
buf[i] = __raw_readl(&rtcreg->dat);
spin_unlock_irq(&pdata->lock);
- sec = (buf[5] << 24) | (buf[4] << 16) | (buf[3] << 8) | buf[2];
+ sec = ((unsigned long)buf[5] << 24) | (buf[4] << 16) |
+ (buf[3] << 8) | buf[2];
rtc_time_to_tm(sec, tm);
return rtc_valid_tm(tm);
}
@@ -147,7 +148,8 @@ static int tx4939_rtc_read_alarm(struct
alrm->enabled = (ctl & TX4939_RTCCTL_ALME) ? 1 : 0;
alrm->pending = (ctl & TX4939_RTCCTL_ALMD) ? 1 : 0;
spin_unlock_irq(&pdata->lock);
- sec = (buf[5] << 24) | (buf[4] << 16) | (buf[3] << 8) | buf[2];
+ sec = ((unsigned long)buf[5] << 24) | (buf[4] << 16) |
+ (buf[3] << 8) | buf[2];
rtc_time_to_tm(sec, &alrm->time);
return rtc_valid_tm(&alrm->time);
}



2018-05-28 15:08:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 235/268] hwrng: stm32 - add reset during probe

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

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

From: "[email protected]" <[email protected]>

[ Upstream commit 326ed382256475aa4b8b7eae8a2f60689fd25e78 ]

Avoid issue when probing the RNG without
reset if bad status has been detected previously

Signed-off-by: Lionel Debieve <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/hw_random/stm32-rng.c | 9 +++++++++
1 file changed, 9 insertions(+)

--- a/drivers/char/hw_random/stm32-rng.c
+++ b/drivers/char/hw_random/stm32-rng.c
@@ -21,6 +21,7 @@
#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/pm_runtime.h>
+#include <linux/reset.h>
#include <linux/slab.h>

#define RNG_CR 0x00
@@ -46,6 +47,7 @@ struct stm32_rng_private {
struct hwrng rng;
void __iomem *base;
struct clk *clk;
+ struct reset_control *rst;
};

static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
@@ -140,6 +142,13 @@ static int stm32_rng_probe(struct platfo
if (IS_ERR(priv->clk))
return PTR_ERR(priv->clk);

+ priv->rst = devm_reset_control_get(&ofdev->dev, NULL);
+ if (!IS_ERR(priv->rst)) {
+ reset_control_assert(priv->rst);
+ udelay(2);
+ reset_control_deassert(priv->rst);
+ }
+
dev_set_drvdata(dev, priv);

priv->rng.name = dev_driver_string(dev),



2018-05-28 15:08:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 217/268] ASoC: topology: create TLV data for dapm widgets

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

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

From: Ranjani Sridharan <[email protected]>

[ Upstream commit bde8b3887add8368ecf0ca71117baf2fd56a6fc9 ]

This patch adds the change required to create the TLV data
for dapm widget kcontrols from topology. This also fixes the following
TLV read error shown in amixer while showing the card control contents.
"amixer: Control hw:1 element TLV read error: No such device or address"

Signed-off-by: Ranjani Sridharan <[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/soc-topology.c | 3 +++
1 file changed, 3 insertions(+)

--- a/sound/soc/soc-topology.c
+++ b/sound/soc/soc-topology.c
@@ -1188,6 +1188,9 @@ static struct snd_kcontrol_new *soc_tplg
kfree(sm);
continue;
}
+
+ /* create any TLV data */
+ soc_tplg_create_tlv(tplg, &kc[i], &mc->hdr);
}
return kc;




2018-05-28 15:09:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 228/268] media: cx23885: Override 888 ImpactVCBe crystal frequency

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

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

From: Brad Love <[email protected]>

[ Upstream commit 779c79d4b833ec646b0aed878da38edb45bbe156 ]

Hauppauge produced a revision of ImpactVCBe using an 888,
with a 25MHz crystal, instead of using the default third
overtone 50Mhz crystal. This overrides that frequency so
that the cx25840 is properly configured. Without the proper
crystal setup the cx25840 cannot load the firmware or
decode video.

Signed-off-by: Brad Love <[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/cx23885/cx23885-core.c | 10 ++++++++++
1 file changed, 10 insertions(+)

--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -872,6 +872,16 @@ static int cx23885_dev_setup(struct cx23
if (cx23885_boards[dev->board].clk_freq > 0)
dev->clk_freq = cx23885_boards[dev->board].clk_freq;

+ if (dev->board == CX23885_BOARD_HAUPPAUGE_IMPACTVCBE &&
+ dev->pci->subsystem_device == 0x7137) {
+ /* Hauppauge ImpactVCBe device ID 0x7137 is populated
+ * with an 888, and a 25Mhz crystal, instead of the
+ * usual third overtone 50Mhz. The default clock rate must
+ * be overridden so the cx25840 is properly configured
+ */
+ dev->clk_freq = 25000000;
+ }
+
dev->pci_bus = dev->pci->bus->number;
dev->pci_slot = PCI_SLOT(dev->pci->devfn);
cx23885_irq_add(dev, 0x001f00);



2018-05-28 15:09:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 229/268] media: cx23885: Set subdev host data to clk_freq pointer

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

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

From: Brad Love <[email protected]>

[ Upstream commit 5ceade1d97fc6687e050c44c257382c192f56276 ]

Currently clk_freq is ignored entirely, because the cx235840 driver
configures the xtal at the chip defaults. This is an issue if a
board is produced with a non-default frequency crystal. If clk_freq
is not zero the cx25840 will attempt to use the setting provided,
or fall back to defaults otherwise.

Signed-off-by: Brad Love <[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/cx23885/cx23885-cards.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -2124,6 +2124,10 @@ void cx23885_card_setup(struct cx23885_d
&dev->i2c_bus[2].i2c_adap,
"cx25840", 0x88 >> 1, NULL);
if (dev->sd_cx25840) {
+ /* set host data for clk_freq configuration */
+ v4l2_set_subdev_hostdata(dev->sd_cx25840,
+ &dev->clk_freq);
+
dev->sd_cx25840->grp_id = CX23885_HW_AV_CORE;
v4l2_subdev_call(dev->sd_cx25840, core, load_fw);
}



2018-05-28 15:09:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 231/268] dmaengine: pl330: fix a race condition in case of threaded irqs

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

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

From: Qi Hou <[email protected]>

[ Upstream commit a3ca831249ca8c4c226e4ceafee04e280152e59d ]

When booting up with "threadirqs" in command line, all irq handlers of the DMA
controller pl330 will be threaded forcedly. These threads will race for the same
list, pl330->req_done.

Before the callback, the spinlock was released. And after it, the spinlock was
taken. This opened an race window where another threaded irq handler could steal
the spinlock and be permitted to delete entries of the list, pl330->req_done.

If the later deleted an entry that was still referred to by the former, there would
be a kernel panic when the former was scheduled and tried to get the next sibling
of the deleted entry.

The scenario could be depicted as below:

Thread: T1 pl330->req_done Thread: T2
| | |
| -A-B-C-D- |
Locked | |
| | Waiting
Del A | |
| -B-C-D- |
Unlocked | |
| | Locked
Waiting | |
| | Del B
| | |
| -C-D- Unlocked
Waiting | |
|
Locked
|
get C via B
\
- Kernel panic

The kernel panic looked like as below:

Unable to handle kernel paging request at virtual address dead000000000108
pgd = ffffff8008c9e000
[dead000000000108] *pgd=000000027fffe003, *pud=000000027fffe003, *pmd=0000000000000000
Internal error: Oops: 96000044 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 85 Comm: irq/59-66330000 Not tainted 4.8.24-WR9.0.0.12_standard #2
Hardware name: Broadcom NS2 SVK (DT)
task: ffffffc1f5cc3c00 task.stack: ffffffc1f5ce0000
PC is at pl330_irq_handler+0x27c/0x390
LR is at pl330_irq_handler+0x2a8/0x390
pc : [<ffffff80084cb694>] lr : [<ffffff80084cb6c0>] pstate: 800001c5
sp : ffffffc1f5ce3d00
x29: ffffffc1f5ce3d00 x28: 0000000000000140
x27: ffffffc1f5c530b0 x26: dead000000000100
x25: dead000000000200 x24: 0000000000418958
x23: 0000000000000001 x22: ffffffc1f5ccd668
x21: ffffffc1f5ccd590 x20: ffffffc1f5ccd418
x19: dead000000000060 x18: 0000000000000001
x17: 0000000000000007 x16: 0000000000000001
x15: ffffffffffffffff x14: ffffffffffffffff
x13: ffffffffffffffff x12: 0000000000000000
x11: 0000000000000001 x10: 0000000000000840
x9 : ffffffc1f5ce0000 x8 : ffffffc1f5cc3338
x7 : ffffff8008ce2020 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000001
x3 : dead000000000200 x2 : dead000000000100
x1 : 0000000000000140 x0 : ffffffc1f5ccd590

Process irq/59-66330000 (pid: 85, stack limit = 0xffffffc1f5ce0020)
Stack: (0xffffffc1f5ce3d00 to 0xffffffc1f5ce4000)
3d00: ffffffc1f5ce3d80 ffffff80080f09d0 ffffffc1f5ca0c00 ffffffc1f6f7c600
3d20: ffffffc1f5ce0000 ffffffc1f6f7c600 ffffffc1f5ca0c00 ffffff80080f0998
3d40: ffffffc1f5ce0000 ffffff80080f0000 0000000000000000 0000000000000000
3d60: ffffff8008ce202c ffffff8008ce2020 ffffffc1f5ccd668 ffffffc1f5c530b0
3d80: ffffffc1f5ce3db0 ffffff80080f0d70 ffffffc1f5ca0c40 0000000000000001
3da0: ffffffc1f5ce0000 ffffff80080f0cfc ffffffc1f5ce3e20 ffffff80080bf4f8
3dc0: ffffffc1f5ca0c80 ffffff8008bf3798 ffffff8008955528 ffffffc1f5ca0c00
3de0: ffffff80080f0c30 0000000000000000 0000000000000000 0000000000000000
3e00: 0000000000000000 0000000000000000 0000000000000000 ffffff80080f0b68
3e20: 0000000000000000 ffffff8008083690 ffffff80080bf420 ffffffc1f5ca0c80
3e40: 0000000000000000 0000000000000000 0000000000000000 ffffff80080cb648
3e60: ffffff8008b1c780 0000000000000000 0000000000000000 ffffffc1f5ca0c00
3e80: ffffffc100000000 ffffff8000000000 ffffffc1f5ce3e90 ffffffc1f5ce3e90
3ea0: 0000000000000000 ffffff8000000000 ffffffc1f5ce3eb0 ffffffc1f5ce3eb0
3ec0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3ee0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3f20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3f80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3fa0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3fc0: 0000000000000000 0000000000000005 0000000000000000 0000000000000000
3fe0: 0000000000000000 0000000000000000 0000000275ce3ff0 0000000275ce3ff8
Call trace:
Exception stack(0xffffffc1f5ce3b30 to 0xffffffc1f5ce3c60)
3b20: dead000000000060 0000008000000000
3b40: ffffffc1f5ce3d00 ffffff80084cb694 0000000000000008 0000000000000e88
3b60: ffffffc1f5ce3bb0 ffffff80080dac68 ffffffc1f5ce3b90 ffffff8008826fe4
3b80: 00000000000001c0 00000000000001c0 ffffffc1f5ce3bb0 ffffff800848dfcc
3ba0: 0000000000020000 ffffff8008b15ae4 ffffffc1f5ce3c00 ffffff800808f000
3bc0: 0000000000000010 ffffff80088377f0 ffffffc1f5ccd590 0000000000000140
3be0: dead000000000100 dead000000000200 0000000000000001 0000000000000000
3c00: 0000000000000000 ffffff8008ce2020 ffffffc1f5cc3338 ffffffc1f5ce0000
3c20: 0000000000000840 0000000000000001 0000000000000000 ffffffffffffffff
3c40: ffffffffffffffff ffffffffffffffff 0000000000000001 0000000000000007
[<ffffff80084cb694>] pl330_irq_handler+0x27c/0x390
[<ffffff80080f09d0>] irq_forced_thread_fn+0x38/0x88
[<ffffff80080f0d70>] irq_thread+0x140/0x200
[<ffffff80080bf4f8>] kthread+0xd8/0xf0
[<ffffff8008083690>] ret_from_fork+0x10/0x40
Code: f2a00838 f9405763 aa1c03e1 aa1503e0 (f9000443)
---[ end trace f50005726d31199c ]---
Kernel panic - not syncing: Fatal exception in interrupt
SMP: stopping secondary CPUs
SMP: failed to stop secondary CPUs 0-1
Kernel Offset: disabled
Memory Limit: none
---[ end Kernel panic - not syncing: Fatal exception in interrupt

To fix this, re-start with the list-head after dropping the lock then
re-takeing it.

Reviewed-by: Frank Mori Hess <[email protected]>
Tested-by: Frank Mori Hess <[email protected]>
Signed-off-by: Qi Hou <[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/pl330.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1533,7 +1533,7 @@ static void pl330_dotask(unsigned long d
/* Returns 1 if state was updated, 0 otherwise */
static int pl330_update(struct pl330_dmac *pl330)
{
- struct dma_pl330_desc *descdone, *tmp;
+ struct dma_pl330_desc *descdone;
unsigned long flags;
void __iomem *regs;
u32 val;
@@ -1611,7 +1611,9 @@ static int pl330_update(struct pl330_dma
}

/* Now that we are in no hurry, do the callbacks */
- list_for_each_entry_safe(descdone, tmp, &pl330->req_done, rqd) {
+ while (!list_empty(&pl330->req_done)) {
+ descdone = list_first_entry(&pl330->req_done,
+ struct dma_pl330_desc, rqd);
list_del(&descdone->rqd);
spin_unlock_irqrestore(&pl330->lock, flags);
dma_pl330_rqcb(descdone, PL330_ERR_NONE);



2018-05-28 15:10:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 232/268] media: em28xx: USB bulk packet size fix

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

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

From: Brad Love <[email protected]>

[ Upstream commit c7c7e8d7803406daa21e96d00c357de8b77b6764 ]

Hauppauge em28xx bulk devices exhibit continuity errors and corrupted
packets, when run in VMWare virtual machines. Unknown if other
manufacturers bulk models exhibit the same issue. KVM/Qemu is unaffected.

According to documentation the maximum packet multiplier for em28xx in bulk
transfer mode is 256 * 188 bytes. This changes the size of bulk transfers
to maximum supported value and have a bonus beneficial alignment.

Before:

After:

This sets up USB to expect just as many bytes as the em28xx is set to emit.

Successful usage under load afterwards natively and in both VMWare
and KVM/Qemu virtual machines.

Signed-off-by: Brad Love <[email protected]>
Reviewed-by: Michael Ira Krufky <[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/usb/em28xx/em28xx.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -187,7 +187,7 @@
USB 2.0 spec says bulk packet size is always 512 bytes
*/
#define EM28XX_BULK_PACKET_MULTIPLIER 384
-#define EM28XX_DVB_BULK_PACKET_MULTIPLIER 384
+#define EM28XX_DVB_BULK_PACKET_MULTIPLIER 94

#define EM28XX_INTERLACED_DEFAULT 1




2018-05-28 15:10:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 230/268] media: s3c-camif: fix out-of-bounds array access

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

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

From: Arnd Bergmann <[email protected]>

[ Upstream commit a398e043637a4819a0e96467bfecaabf3224dd62 ]

While experimenting with older compiler versions, I ran
into a warning that no longer shows up on gcc-4.8 or newer:

drivers/media/platform/s3c-camif/camif-capture.c: In function '__camif_subdev_try_format':
drivers/media/platform/s3c-camif/camif-capture.c:1265:25: error: array subscript is below array bounds

This is an off-by-one bug, leading to an access before the start of the
array, while newer compilers silently assume this undefined behavior
cannot happen and leave the loop at index 0 if no other entry matches.

As Sylvester explains, we actually need to ensure that the
value is within the range, so this reworks the loop to be
easier to parse correctly, and an additional check to fall
back on the first format value for any unexpected input.

I found an existing gcc bug for it and added a reduced version
of the function there.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69249#c3
Fixes: babde1c243b2 ("[media] V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface")

Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Acked-by: Sakari Ailus <[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/s3c-camif/camif-capture.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/media/platform/s3c-camif/camif-capture.c
+++ b/drivers/media/platform/s3c-camif/camif-capture.c
@@ -1268,16 +1268,17 @@ static void __camif_subdev_try_format(st
{
const struct s3c_camif_variant *variant = camif->variant;
const struct vp_pix_limits *pix_lim;
- int i = ARRAY_SIZE(camif_mbus_formats);
+ unsigned int i;

/* FIXME: constraints against codec or preview path ? */
pix_lim = &variant->vp_pix_limits[VP_CODEC];

- while (i-- >= 0)
+ for (i = 0; i < ARRAY_SIZE(camif_mbus_formats); i++)
if (camif_mbus_formats[i] == mf->code)
break;

- mf->code = camif_mbus_formats[i];
+ if (i == ARRAY_SIZE(camif_mbus_formats))
+ mf->code = camif_mbus_formats[0];

if (pad == CAMIF_SD_PAD_SINK) {
v4l_bound_align_image(&mf->width, 8, CAMIF_MAX_PIX_WIDTH,



2018-05-28 15:10:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 233/268] clk: rockchip: Prevent calculating mmc phase if clock rate is zero

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

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

From: Shawn Lin <[email protected]>

[ Upstream commit 4bf59902b50012b1dddeeaa23b217d9c4956cdda ]

The MMC sample and drv clock for rockchip platforms are derived from
the bus clock output to the MMC/SDIO card. So it should never happens
that the clk rate is zero given it should inherits the clock rate from
its parent. If something goes wrong and makes the clock rate to be zero,
the calculation would be wrong but may still make the mmc tuning process
work luckily. However it makes people harder to debug when the following
data transfer is unstable.

Signed-off-by: Shawn Lin <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/clk/rockchip/clk-mmc-phase.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)

--- a/drivers/clk/rockchip/clk-mmc-phase.c
+++ b/drivers/clk/rockchip/clk-mmc-phase.c
@@ -60,6 +60,12 @@ static int rockchip_mmc_get_phase(struct
u16 degrees;
u32 delay_num = 0;

+ /* See the comment for rockchip_mmc_set_phase below */
+ if (!rate) {
+ pr_err("%s: invalid clk rate\n", __func__);
+ return -EINVAL;
+ }
+
raw_value = readl(mmc_clock->reg) >> (mmc_clock->shift);

degrees = (raw_value & ROCKCHIP_MMC_DEGREE_MASK) * 90;
@@ -86,6 +92,23 @@ static int rockchip_mmc_set_phase(struct
u32 raw_value;
u32 delay;

+ /*
+ * The below calculation is based on the output clock from
+ * MMC host to the card, which expects the phase clock inherits
+ * the clock rate from its parent, namely the output clock
+ * provider of MMC host. However, things may go wrong if
+ * (1) It is orphan.
+ * (2) It is assigned to the wrong parent.
+ *
+ * This check help debug the case (1), which seems to be the
+ * most likely problem we often face and which makes it difficult
+ * for people to debug unstable mmc tuning results.
+ */
+ if (!rate) {
+ pr_err("%s: invalid clk rate\n", __func__);
+ return -EINVAL;
+ }
+
nineties = degrees / 90;
remainder = (degrees % 90);




2018-05-28 15:10:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 226/268] x86/devicetree: Fix device IRQ settings in DT

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

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

From: Ivan Gorinov <[email protected]>

[ Upstream commit 0a5169add90e43ab45ab1ba34223b8583fcaf675 ]

IRQ parameters for the SoC devices connected directly to I/O APIC lines
(without PCI IRQ routing) may be specified in the Device Tree.

Called from DT IRQ parser, irq_create_fwspec_mapping() calls
irq_domain_alloc_irqs() with a pointer to irq_fwspec structure as @arg.

But x86-specific DT IRQ allocation code casts @arg to of_phandle_args
structure pointer and crashes trying to read the IRQ parameters. The
function was not converted when the mapping descriptor was changed to
irq_fwspec in the generic irqdomain code.

Fixes: 11e4438ee330 ("irqdomain: Introduce a firmware-specific IRQ specifier structure")
Signed-off-by: Ivan Gorinov <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Rob Herring <[email protected]>
Link: https://lkml.kernel.org/r/a234dee27ea60ce76141872da0d6bdb378b2a9ee.1520450752.git.ivan.gorinov@intel.com
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/devicetree.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)

--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -200,19 +200,22 @@ static struct of_ioapic_type of_ioapic_t
static int dt_irqdomain_alloc(struct irq_domain *domain, unsigned int virq,
unsigned int nr_irqs, void *arg)
{
- struct of_phandle_args *irq_data = (void *)arg;
+ struct irq_fwspec *fwspec = (struct irq_fwspec *)arg;
struct of_ioapic_type *it;
struct irq_alloc_info tmp;
+ int type_index;

- if (WARN_ON(irq_data->args_count < 2))
+ if (WARN_ON(fwspec->param_count < 2))
return -EINVAL;
- if (irq_data->args[1] >= ARRAY_SIZE(of_ioapic_type))
+
+ type_index = fwspec->param[1];
+ if (type_index >= ARRAY_SIZE(of_ioapic_type))
return -EINVAL;

- it = &of_ioapic_type[irq_data->args[1]];
+ it = &of_ioapic_type[type_index];
ioapic_set_alloc_attr(&tmp, NUMA_NO_NODE, it->trigger, it->polarity);
tmp.ioapic_id = mpc_ioapic_id(mp_irqdomain_ioapic_idx(domain));
- tmp.ioapic_pin = irq_data->args[0];
+ tmp.ioapic_pin = fwspec->param[0];

return mp_irqdomain_alloc(domain, virq, nr_irqs, &tmp);
}



2018-05-28 15:10:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 227/268] ALSA: vmaster: Propagate slave error

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

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

From: Takashi Iwai <[email protected]>

[ Upstream commit 2e2c177ca84aff092c3c96714b0f6a12900f3946 ]

In slave_update() of vmaster code ignores the error from the slave
get() callback and copies the values. It's not only about the missing
error code but also that this may potentially lead to a leak of
uninitialized variables when the slave get() don't clear them.

This patch fixes slave_update() not to copy the potentially
uninitialized values when an error is returned from the slave get()
callback, and to propagate the error value properly.

Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/core/vmaster.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/sound/core/vmaster.c
+++ b/sound/core/vmaster.c
@@ -68,10 +68,13 @@ static int slave_update(struct link_slav
return -ENOMEM;
uctl->id = slave->slave.id;
err = slave->slave.get(&slave->slave, uctl);
+ if (err < 0)
+ goto error;
for (ch = 0; ch < slave->info.count; ch++)
slave->vals[ch] = uctl->value.integer.value[ch];
+ error:
kfree(uctl);
- return 0;
+ return err < 0 ? err : 0;
}

/* get the slave ctl info and save the initial values */



2018-05-28 15:11:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 188/268] hwmon: (nct6775) Fix writing pwmX_mode

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

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

From: Guenter Roeck <[email protected]>

[ Upstream commit 415eb2a1aaa4881cf85bd86c683356fdd8094a23 ]

pwmX_mode is defined in the ABI as 0=DC mode, 1=pwm mode. The chip
register bit is set to 1 for DC mode. This got mixed up, and writing
1 into pwmX_mode resulted in DC mode enabled. Fix it up by using
the ABI definition throughout the driver for consistency.

Fixes: 77eb5b3703d99 ("hwmon: (nct6775) Add support for pwm, pwm_mode, ... ")
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hwmon/nct6775.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

--- a/drivers/hwmon/nct6775.c
+++ b/drivers/hwmon/nct6775.c
@@ -1390,7 +1390,7 @@ static void nct6775_update_pwm(struct de
duty_is_dc = data->REG_PWM_MODE[i] &&
(nct6775_read_value(data, data->REG_PWM_MODE[i])
& data->PWM_MODE_MASK[i]);
- data->pwm_mode[i] = duty_is_dc;
+ data->pwm_mode[i] = !duty_is_dc;

fanmodecfg = nct6775_read_value(data, data->REG_FAN_MODE[i]);
for (j = 0; j < ARRAY_SIZE(data->REG_PWM); j++) {
@@ -2267,7 +2267,7 @@ show_pwm_mode(struct device *dev, struct
struct nct6775_data *data = nct6775_update_device(dev);
struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);

- return sprintf(buf, "%d\n", !data->pwm_mode[sattr->index]);
+ return sprintf(buf, "%d\n", data->pwm_mode[sattr->index]);
}

static ssize_t
@@ -2288,9 +2288,9 @@ store_pwm_mode(struct device *dev, struc
if (val > 1)
return -EINVAL;

- /* Setting DC mode is not supported for all chips/channels */
+ /* Setting DC mode (0) is not supported for all chips/channels */
if (data->REG_PWM_MODE[nr] == 0) {
- if (val)
+ if (!val)
return -EINVAL;
return count;
}
@@ -2299,7 +2299,7 @@ store_pwm_mode(struct device *dev, struc
data->pwm_mode[nr] = val;
reg = nct6775_read_value(data, data->REG_PWM_MODE[nr]);
reg &= ~data->PWM_MODE_MASK[nr];
- if (val)
+ if (!val)
reg |= data->PWM_MODE_MASK[nr];
nct6775_write_value(data, data->REG_PWM_MODE[nr], reg);
mutex_unlock(&data->update_lock);



2018-05-28 15:12:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 190/268] powerpc/perf: Prevent kernel address leak to userspace via BHRB buffer

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

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

From: Madhavan Srinivasan <[email protected]>

[ Upstream commit bb19af816025d495376bd76bf6fbcf4244f9a06d ]

The current Branch History Rolling Buffer (BHRB) code does not check
for any privilege levels before updating the data from BHRB. This
could leak kernel addresses to userspace even when profiling only with
userspace privileges. Add proper checks to prevent it.

Acked-by: Balbir Singh <[email protected]>
Signed-off-by: Madhavan Srinivasan <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/perf/core-book3s.c | 10 ++++++++++
1 file changed, 10 insertions(+)

--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -448,6 +448,16 @@ static void power_pmu_bhrb_read(struct c
/* invalid entry */
continue;

+ /*
+ * BHRB rolling buffer could very much contain the kernel
+ * addresses at this point. Check the privileges before
+ * exporting it to userspace (avoid exposure of regions
+ * where we could have speculative execution)
+ */
+ if (perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN) &&
+ is_kernel_addr(addr))
+ continue;
+
/* Branches are read most recent first (ie. mfbhrb 0 is
* the most recent branch).
* There are two types of valid entries:



2018-05-28 15:12:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 187/268] parisc/pci: Switch LBA PCI bus from Hard Fail to Soft Fail mode

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

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

From: Helge Deller <[email protected]>

[ Upstream commit b845f66f78bf42a4ce98e5cfe0e94fab41dd0742 ]

Carlo Pisani noticed that his C3600 workstation behaved unstable during heavy
I/O on the PCI bus with a VIA VT6421 IDE/SATA PCI card.

To avoid such instability, this patch switches the LBA PCI bus from Hard Fail
mode into Soft Fail mode. In this mode the bus will return -1UL for timed out
MMIO transactions, which is exactly how the x86 (and most other architectures)
PCI busses behave.

This patch is based on a proposal by Grant Grundler and Kyle McMartin 10
years ago:
https://www.spinics.net/lists/linux-parisc/msg01027.html

Cc: Carlo Pisani <[email protected]>
Cc: Kyle McMartin <[email protected]>
Reviewed-by: Grant Grundler <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/parisc/lba_pci.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)

--- a/drivers/parisc/lba_pci.c
+++ b/drivers/parisc/lba_pci.c
@@ -1365,9 +1365,27 @@ lba_hw_init(struct lba_device *d)
WRITE_REG32(stat, d->hba.base_addr + LBA_ERROR_CONFIG);
}

- /* Set HF mode as the default (vs. -1 mode). */
+
+ /*
+ * Hard Fail vs. Soft Fail on PCI "Master Abort".
+ *
+ * "Master Abort" means the MMIO transaction timed out - usually due to
+ * the device not responding to an MMIO read. We would like HF to be
+ * enabled to find driver problems, though it means the system will
+ * crash with a HPMC.
+ *
+ * In SoftFail mode "~0L" is returned as a result of a timeout on the
+ * pci bus. This is like how PCI busses on x86 and most other
+ * architectures behave. In order to increase compatibility with
+ * existing (x86) PCI hardware and existing Linux drivers we enable
+ * Soft Faul mode on PA-RISC now too.
+ */
stat = READ_REG32(d->hba.base_addr + LBA_STAT_CTL);
+#if defined(ENABLE_HARDFAIL)
WRITE_REG32(stat | HF_ENABLE, d->hba.base_addr + LBA_STAT_CTL);
+#else
+ WRITE_REG32(stat & ~HF_ENABLE, d->hba.base_addr + LBA_STAT_CTL);
+#endif

/*
** Writing a zero to STAT_CTL.rf (bit 0) will clear reset signal



2018-05-28 15:12:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 189/268] rtc: hctosys: Ensure system time doesnt overflow time_t

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

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

From: Alexandre Belloni <[email protected]>

[ Upstream commit b3a5ac42ab18b7d1a8f2f072ca0ee76a3b754a43 ]

On 32bit platforms, time_t is still a signed 32bit long. If it is
overflowed, userspace and the kernel cant agree on the current system time.
This causes multiple issues, in particular with systemd:
https://github.com/systemd/systemd/issues/1143

A good workaround is to simply avoid using hctosys which is something I
greatly encourage as the time is better set by userspace.

However, many distribution enable it and use systemd which is rendering the
system unusable in case the RTC holds a date after 2038 (and more so after
2106). Many drivers have workaround for this case and they should be
eliminated so there is only one place left to fix when userspace is able to
cope with dates after the 31bit overflow.

Acked-by: Arnd Bergmann <[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/hctosys.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/rtc/hctosys.c
+++ b/drivers/rtc/hctosys.c
@@ -49,6 +49,11 @@ static int __init rtc_hctosys(void)

tv64.tv_sec = rtc_tm_to_time64(&tm);

+#if BITS_PER_LONG == 32
+ if (tv64.tv_sec > INT_MAX)
+ goto err_read;
+#endif
+
err = do_settimeofday64(&tv64);

dev_info(rtc->dev.parent,



2018-05-28 15:12:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 214/268] usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS

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

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

From: Lars-Peter Clausen <[email protected]>

[ Upstream commit 946ef68ad4e45aa048a5fb41ce8823ed29da866a ]

Some UDC drivers (like the DWC3) expect that the response to a setup()
request is queued from within the setup function itself so that it is
available as soon as setup() has completed.

Upon receiving a setup request the function fs driver creates an event that
is made available to userspace. And only once userspace has acknowledged
that event the response to the setup request is queued.

So it violates the requirement of those UDC drivers and random failures can
be observed. This is basically a race condition and if userspace is able to
read the event and queue the response fast enough all is good. But if it is
not, for example because other processes are currently scheduled to run,
the USB host that sent the setup request will observe an error.

To avoid this the gadget framework provides the USB_GADGET_DELAYED_STATUS
return code. If a setup() callback returns this value the UDC driver is
aware that response is not yet available and can uses the appropriate
methods to handle this case.

Since in the case of function fs the response will never be available when
the setup() function returns make sure that this status code is used.

This fixed random occasional failures that were previously observed on a
DWC3 based system under high system load.

Signed-off-by: Lars-Peter Clausen <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/function/f_fs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -3033,7 +3033,7 @@ static int ffs_func_setup(struct usb_fun
__ffs_event_add(ffs, FUNCTIONFS_SETUP);
spin_unlock_irqrestore(&ffs->ev.waitq.lock, flags);

- return 0;
+ return USB_GADGET_DELAYED_STATUS;
}

static void ffs_func_suspend(struct usb_function *f)



2018-05-28 15:12:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 186/268] m68k: set dma and coherent masks for platform FEC ethernets

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

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

From: Greg Ungerer <[email protected]>

[ Upstream commit f61e64310b75733d782e930d1fb404b84699eed6 ]

As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") the Freescale FEC driver is issuing the following
warning on driver initialization on ColdFire systems:

WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
Stack from 41833dd8:
41833dd8 40259c53 40025534 40279e26 00000003 00000000 4004e514 41827000
400255de 40244e42 00000204 40159e20 00000009 00000000 00000000 4024531d
40159e20 40244e42 00000204 00000000 00000000 00000000 00000007 00000000
00000000 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
7fffffff 418273f2 41867028 4003c9a2 4180ac6c 00000004 41833f8c 4013e71c
40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 00000000
Call Trace:
[<40025534>] 0x40025534
[<4004e514>] 0x4004e514
[<400255de>] 0x400255de
[<40159e20>] 0x40159e20
[<40159e20>] 0x40159e20

It is not fatal, the driver and the system continue to function normally.

As per the warning the coherent_dma_mask is not set on this device.
There is nothing special about the DMA memory coherency on this hardware
so we can just set the mask to 32bits in the platform data for the FEC
ethernet devices.

Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/m68k/coldfire/device.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

--- a/arch/m68k/coldfire/device.c
+++ b/arch/m68k/coldfire/device.c
@@ -135,7 +135,11 @@ static struct platform_device mcf_fec0 =
.id = 0,
.num_resources = ARRAY_SIZE(mcf_fec0_resources),
.resource = mcf_fec0_resources,
- .dev.platform_data = FEC_PDATA,
+ .dev = {
+ .dma_mask = &mcf_fec0.dev.coherent_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = FEC_PDATA,
+ }
};

#ifdef MCFFEC_BASE1
@@ -167,7 +171,11 @@ static struct platform_device mcf_fec1 =
.id = 1,
.num_resources = ARRAY_SIZE(mcf_fec1_resources),
.resource = mcf_fec1_resources,
- .dev.platform_data = FEC_PDATA,
+ .dev = {
+ .dma_mask = &mcf_fec1.dev.coherent_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = FEC_PDATA,
+ }
};
#endif /* MCFFEC_BASE1 */
#endif /* CONFIG_FEC */



2018-05-28 15:13:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 212/268] ipmi_ssif: Fix kernel panic at msg_done_handler

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

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

From: Kamlakant Patel <[email protected]>

[ Upstream commit f002612b9d86613bc6fde0a444e0095225f6053e ]

This happens when BMC doesn't return any data and the code is trying
to print the value of data[2].

Getting following crash:
[ 484.728410] Unable to handle kernel NULL pointer dereference at virtual address 00000002
[ 484.736496] pgd = ffff0000094a2000
[ 484.739885] [00000002] *pgd=00000047fcffe003, *pud=00000047fcffd003, *pmd=0000000000000000
[ 484.748158] Internal error: Oops: 96000005 [#1] SMP
[...]
[ 485.101451] Call trace:
[...]
[ 485.188473] [<ffff000000a46e68>] msg_done_handler+0x668/0x700 [ipmi_ssif]
[ 485.195249] [<ffff000000a456b8>] ipmi_ssif_thread+0x110/0x128 [ipmi_ssif]
[ 485.202038] [<ffff0000080f1430>] kthread+0x108/0x138
[ 485.206994] [<ffff0000080838e0>] ret_from_fork+0x10/0x30
[ 485.212294] Code: aa1903e1 aa1803e0 b900227f 95fef6a5 (39400aa3)

Adding a check to validate the data len before printing data[2] to fix this issue.

Signed-off-by: Kamlakant Patel <[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_ssif.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/char/ipmi/ipmi_ssif.c
+++ b/drivers/char/ipmi/ipmi_ssif.c
@@ -757,7 +757,7 @@ static void msg_done_handler(struct ssif
ssif_info->ssif_state = SSIF_NORMAL;
ipmi_ssif_unlock_cond(ssif_info, flags);
pr_warn(PFX "Error getting flags: %d %d, %x\n",
- result, len, data[2]);
+ result, len, (len >= 3) ? data[2] : 0);
} else if (data[0] != (IPMI_NETFN_APP_REQUEST | 1) << 2
|| data[1] != IPMI_GET_MSG_FLAGS_CMD) {
/*
@@ -779,7 +779,7 @@ static void msg_done_handler(struct ssif
if ((result < 0) || (len < 3) || (data[2] != 0)) {
/* Error clearing flags */
pr_warn(PFX "Error clearing flags: %d %d, %x\n",
- result, len, data[2]);
+ result, len, (len >= 3) ? data[2] : 0);
} else if (data[0] != (IPMI_NETFN_APP_REQUEST | 1) << 2
|| data[1] != IPMI_CLEAR_MSG_FLAGS_CMD) {
pr_warn(PFX "Invalid response clearing flags: %x %x\n",



2018-05-28 15:13:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 213/268] usb: dwc2: Fix interval type issue

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

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

From: Grigor Tovmasyan <[email protected]>

[ Upstream commit 12814a3f8f9b247531d7863170cc82b3fe4218fd ]

The maximum value that unsigned char can hold is 255, meanwhile
the maximum value of interval is 2^(bIntervalMax-1)=2^15.

Signed-off-by: Grigor Tovmasyan <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/dwc2/core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -187,7 +187,7 @@ struct dwc2_hsotg_ep {
unsigned char dir_in;
unsigned char index;
unsigned char mc;
- unsigned char interval;
+ u16 interval;

unsigned int halted:1;
unsigned int periodic:1;



2018-05-28 15:13:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 184/268] ACPI: acpi_pad: Fix memory leak in power saving threads

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

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

From: Lenny Szubowicz <[email protected]>

[ Upstream commit 8b29d29abc484d638213dd79a18a95ae7e5bb402 ]

Fix once per second (round_robin_time) memory leak of about 1 KB in
each acpi_pad kernel idling thread that is activated.

Found by testing with kmemleak.

Signed-off-by: Lenny Szubowicz <[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/acpi_pad.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -108,6 +108,7 @@ static void round_robin_cpu(unsigned int
cpumask_andnot(tmp, cpu_online_mask, pad_busy_cpus);
if (cpumask_empty(tmp)) {
mutex_unlock(&round_robin_lock);
+ free_cpumask_var(tmp);
return;
}
for_each_cpu(cpu, tmp) {
@@ -125,6 +126,8 @@ static void round_robin_cpu(unsigned int
mutex_unlock(&round_robin_lock);

set_cpus_allowed_ptr(current, cpumask_of(preferred_cpu));
+
+ free_cpumask_var(tmp);
}

static void exit_round_robin(unsigned int tsk_index)



2018-05-28 15:14:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 211/268] PCI: Restore config space on runtime resume despite being unbound

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

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

From: "Rafael J. Wysocki" <[email protected]>

[ Upstream commit 5775b843a619b3c93f946e2b55a208d9f0f48b59 ]

We leave PCI devices not bound to a driver in D0 during runtime suspend.
But they may have a parent which is bound and can be transitioned to
D3cold at runtime. Once the parent goes to D3cold, the unbound child
may go to D3cold as well. When the child goes to D3cold, its internal
state, including configuration of BARs, MSI, ASPM, MPS, etc., is lost.

One example are recent hybrid graphics laptops which cut power to the
discrete GPU when the root port above it goes to ACPI power state D3.
Users may provoke this by unbinding the GPU driver and allowing runtime
PM on the GPU via sysfs: The PM core will then treat the GPU as
"suspended", which in turn allows the root port to runtime suspend,
causing the power resources listed in its _PR3 object to be powered off.
The GPU's BARs will be uninitialized when a driver later probes it.

Another example are hybrid graphics laptops where the GPU itself (rather
than the root port) is capable of runtime suspending to D3cold. If the
GPU's integrated HDA controller is not bound and the GPU's driver
decides to runtime suspend to D3cold, the HDA controller's BARs will be
uninitialized when a driver later probes it.

Fix by saving and restoring config space over a runtime suspend cycle
even if the device is not bound.

Acked-by: Bjorn Helgaas <[email protected]>
Tested-by: Peter Wu <[email protected]> # Nvidia Optimus
Tested-by: Lukas Wunner <[email protected]> # MacBook Pro
Signed-off-by: Rafael J. Wysocki <[email protected]>
[lukas: add commit message, bikeshed code comments for clarity]
Signed-off-by: Lukas Wunner <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/92fb6e6ae2730915eb733c08e2f76c6a313e3860.1520068884.git.lukas@wunner.de
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pci/pci-driver.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)

--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1140,11 +1140,14 @@ static int pci_pm_runtime_suspend(struct
int error;

/*
- * If pci_dev->driver is not set (unbound), the device should
- * always remain in D0 regardless of the runtime PM status
+ * If pci_dev->driver is not set (unbound), we leave the device in D0,
+ * but it may go to D3cold when the bridge above it runtime suspends.
+ * Save its config space in case that happens.
*/
- if (!pci_dev->driver)
+ if (!pci_dev->driver) {
+ pci_save_state(pci_dev);
return 0;
+ }

if (!pm || !pm->runtime_suspend)
return -ENOSYS;
@@ -1195,16 +1198,18 @@ static int pci_pm_runtime_resume(struct
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;

/*
- * If pci_dev->driver is not set (unbound), the device should
- * always remain in D0 regardless of the runtime PM status
+ * Restoring config space is necessary even if the device is not bound
+ * to a driver because although we left it in D0, it may have gone to
+ * D3cold when the bridge above it runtime suspended.
*/
+ pci_restore_standard_config(pci_dev);
+
if (!pci_dev->driver)
return 0;

if (!pm || !pm->runtime_resume)
return -ENOSYS;

- pci_restore_standard_config(pci_dev);
pci_fixup_device(pci_fixup_resume_early, pci_dev);
__pci_enable_wake(pci_dev, PCI_D0, true, false);
pci_fixup_device(pci_fixup_resume, pci_dev);



2018-05-28 15:14:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 206/268] ACPICA: acpi: acpica: fix acpi operand cache leak in nseval.c

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

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

From: Seunghun Han <[email protected]>

[ Upstream commit 97f3c0a4b0579b646b6b10ae5a3d59f0441cc12c ]

I found an ACPI cache leak in ACPI early termination and boot continuing case.

When early termination occurs due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.

Boot log of ACPI operand cache leak is as follows:
>[ 0.464168] ACPI: Added _OSI(Module Device)
>[ 0.467022] ACPI: Added _OSI(Processor Device)
>[ 0.469376] ACPI: Added _OSI(3.0 _SCP Extensions)
>[ 0.471647] ACPI: Added _OSI(Processor Aggregator Device)
>[ 0.477997] ACPI Error: Null stack entry at ffff880215c0aad8 (20170303/exresop-174)
>[ 0.482706] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [opcode_name unavailable] (20170303/dswexec-461)
>[ 0.487503] ACPI Error: Method parse/execution failed [\DBG] (Node ffff88021710ab40), AE_AML_INTERNAL (20170303/psparse-543)
>[ 0.492136] ACPI Error: Method parse/execution failed [\_SB._INI] (Node ffff88021710a618), AE_AML_INTERNAL (20170303/psparse-543)
>[ 0.497683] ACPI: Interpreter enabled
>[ 0.499385] ACPI: (supports S0)
>[ 0.501151] ACPI: Using IOAPIC for interrupt routing
>[ 0.503342] ACPI Error: Null stack entry at ffff880215c0aad8 (20170303/exresop-174)
>[ 0.506522] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [opcode_name unavailable] (20170303/dswexec-461)
>[ 0.510463] ACPI Error: Method parse/execution failed [\DBG] (Node ffff88021710ab40), AE_AML_INTERNAL (20170303/psparse-543)
>[ 0.514477] ACPI Error: Method parse/execution failed [\_PIC] (Node ffff88021710ab18), AE_AML_INTERNAL (20170303/psparse-543)
>[ 0.518867] ACPI Exception: AE_AML_INTERNAL, Evaluating _PIC (20170303/bus-991)
>[ 0.522384] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[ 0.524597] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
>[ 0.526795] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006
>[ 0.529668] Call Trace:
>[ 0.530811] ? dump_stack+0x5c/0x81
>[ 0.532240] ? kmem_cache_destroy+0x1aa/0x1c0
>[ 0.533905] ? acpi_os_delete_cache+0xa/0x10
>[ 0.535497] ? acpi_ut_delete_caches+0x3f/0x7b
>[ 0.537237] ? acpi_terminate+0xa/0x14
>[ 0.538701] ? acpi_init+0x2af/0x34f
>[ 0.540008] ? acpi_sleep_proc_init+0x27/0x27
>[ 0.541593] ? do_one_initcall+0x4e/0x1a0
>[ 0.543008] ? kernel_init_freeable+0x19e/0x21f
>[ 0.546202] ? rest_init+0x80/0x80
>[ 0.547513] ? kernel_init+0xa/0x100
>[ 0.548817] ? ret_from_fork+0x25/0x30
>[ 0.550587] vgaarb: loaded
>[ 0.551716] EDAC MC: Ver: 3.0.0
>[ 0.553744] PCI: Probing PCI hardware
>[ 0.555038] PCI host bridge to bus 0000:00
> ... Continue to boot and log is omitted ...

I analyzed this memory leak in detail and found acpi_ns_evaluate() function
only removes Info->return_object in AE_CTRL_RETURN_VALUE case. But, when errors
occur, the status value is not AE_CTRL_RETURN_VALUE, and Info->return_object is
also not null. Therefore, this causes acpi operand memory leak.

This cache leak causes a security threat because an old kernel (<= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.

I made a patch to fix ACPI operand cache leak.

Signed-off-by: Seunghun Han <[email protected]>
Signed-off-by: Erik Schmauss <[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/acpica/nseval.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/drivers/acpi/acpica/nseval.c
+++ b/drivers/acpi/acpica/nseval.c
@@ -308,6 +308,14 @@ acpi_status acpi_ns_evaluate(struct acpi
/* Map AE_CTRL_RETURN_VALUE to AE_OK, we are done with it */

status = AE_OK;
+ } else if (ACPI_FAILURE(status)) {
+
+ /* If return_object exists, delete it */
+
+ if (info->return_object) {
+ acpi_ut_remove_reference(info->return_object);
+ info->return_object = NULL;
+ }
}

ACPI_DEBUG_PRINT((ACPI_DB_NAMES,



2018-05-28 15:14:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 205/268] ACPICA: Events: add a return on failure from acpi_hw_register_read

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

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

From: Erik Schmauss <[email protected]>

[ Upstream commit b4c0de312613ca676db5bd7e696a44b56795612a ]

This ensures that acpi_ev_fixed_event_detect() does not use fixed_status
and and fixed_enable as uninitialized variables.

Signed-off-by: Erik Schmauss <[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/acpica/evevent.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/acpi/acpica/evevent.c
+++ b/drivers/acpi/acpica/evevent.c
@@ -204,6 +204,7 @@ u32 acpi_ev_fixed_event_detect(void)
u32 fixed_status;
u32 fixed_enable;
u32 i;
+ acpi_status status;

ACPI_FUNCTION_NAME(ev_fixed_event_detect);

@@ -211,8 +212,12 @@ u32 acpi_ev_fixed_event_detect(void)
* Read the fixed feature status and enable registers, as all the cases
* depend on their values. Ignore errors here.
*/
- (void)acpi_hw_register_read(ACPI_REGISTER_PM1_STATUS, &fixed_status);
- (void)acpi_hw_register_read(ACPI_REGISTER_PM1_ENABLE, &fixed_enable);
+ status = acpi_hw_register_read(ACPI_REGISTER_PM1_STATUS, &fixed_status);
+ status |=
+ acpi_hw_register_read(ACPI_REGISTER_PM1_ENABLE, &fixed_enable);
+ if (ACPI_FAILURE(status)) {
+ return (int_status);
+ }

ACPI_DEBUG_PRINT((ACPI_DB_INTERRUPTS,
"Fixed Event Block: Enable %08X Status %08X\n",



2018-05-28 15:14:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 210/268] MIPS: ath79: Fix AR724X_PLL_REG_PCIE_CONFIG offset

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

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

From: Mathias Kresin <[email protected]>

[ Upstream commit 05454c1bde91fb013c0431801001da82947e6b5a ]

According to the QCA u-boot source the "PCIE Phase Lock Loop
Configuration (PCIE_PLL_CONFIG)" register is for all SoCs except the
QCA955X and QCA956X at offset 0x10.

Since the PCIE PLL config register is only defined for the AR724x fix
only this value. The value is wrong since the day it was added and isn't
used by any driver yet.

Signed-off-by: Mathias Kresin <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/16048/
Signed-off-by: James Hogan <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/mips/include/asm/mach-ath79/ar71xx_regs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
+++ b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
@@ -167,7 +167,7 @@
#define AR71XX_AHB_DIV_MASK 0x7

#define AR724X_PLL_REG_CPU_CONFIG 0x00
-#define AR724X_PLL_REG_PCIE_CONFIG 0x18
+#define AR724X_PLL_REG_PCIE_CONFIG 0x10

#define AR724X_PLL_FB_SHIFT 0
#define AR724X_PLL_FB_MASK 0x3ff



2018-05-28 15:15:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 201/268] cpufreq: cppc_cpufreq: Fix cppc_cpufreq_init() failure path

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

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

From: Chunyu Hu <[email protected]>

[ Upstream commit 55b55abc17f238c61921360e61dde90dd9a326d1 ]

Kmemleak reported the below leak. When cppc_cpufreq_init went into
failure path, the cpu mask is not freed. After fix, this report is
gone. And to avaoid potential NULL pointer reference, check the cpu
value first.

unreferenced object 0xffff800fd5ea4880 (size 128):
comm "swapper/0", pid 1, jiffies 4294939510 (age 668.680s)
hex dump (first 32 bytes):
00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 .... ...........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffff0000082c4ae4>] __kmalloc_node+0x278/0x634
[<ffff0000088f4a74>] alloc_cpumask_var_node+0x28/0x60
[<ffff0000088f4af0>] zalloc_cpumask_var+0x14/0x1c
[<ffff000008d20254>] cppc_cpufreq_init+0xd0/0x19c
[<ffff000008083828>] do_one_initcall+0xec/0x15c
[<ffff000008cd1018>] kernel_init_freeable+0x1f4/0x2a4
[<ffff0000089099b0>] kernel_init+0x18/0x10c
[<ffff000008084d50>] ret_from_fork+0x10/0x18
[<ffffffffffffffff>] 0xffffffffffffffff

Signed-off-by: Chunyu Hu <[email protected]>
Acked-by: Viresh Kumar <[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/cpufreq/cppc_cpufreq.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/cpufreq/cppc_cpufreq.c
+++ b/drivers/cpufreq/cppc_cpufreq.c
@@ -176,8 +176,13 @@ static int __init cppc_cpufreq_init(void
return ret;

out:
- for_each_possible_cpu(i)
- kfree(all_cpu_data[i]);
+ for_each_possible_cpu(i) {
+ cpu = all_cpu_data[i];
+ if (!cpu)
+ break;
+ free_cpumask_var(cpu->shared_cpu_map);
+ kfree(cpu);
+ }

kfree(all_cpu_data);
return -ENODEV;



2018-05-28 15:15:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 204/268] bcache: quit dc->writeback_thread when BCACHE_DEV_DETACHING is set

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

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

From: Coly Li <[email protected]>

[ Upstream commit fadd94e05c02afec7b70b0b14915624f1782f578 ]

In patch "bcache: fix cached_dev->count usage for bch_cache_set_error()",
cached_dev_get() is called when creating dc->writeback_thread, and
cached_dev_put() is called when exiting dc->writeback_thread. This
modification works well unless people detach the bcache device manually by
'echo 1 > /sys/block/bcache<N>/bcache/detach'
Because this sysfs interface only calls bch_cached_dev_detach() which wakes
up dc->writeback_thread but does not stop it. The reason is, before patch
"bcache: fix cached_dev->count usage for bch_cache_set_error()", inside
bch_writeback_thread(), if cache is not dirty after writeback,
cached_dev_put() will be called here. And in cached_dev_make_request() when
a new write request makes cache from clean to dirty, cached_dev_get() will
be called there. Since we don't operate dc->count in these locations,
refcount d->count cannot be dropped after cache becomes clean, and
cached_dev_detach_finish() won't be called to detach bcache device.

This patch fixes the issue by checking whether BCACHE_DEV_DETACHING is
set inside bch_writeback_thread(). If this bit is set and cache is clean
(no existing writeback_keys), break the while-loop, call cached_dev_put()
and quit the writeback thread.

Please note if cache is still dirty, even BCACHE_DEV_DETACHING is set the
writeback thread should continue to perform writeback, this is the original
design of manually detach.

It is safe to do the following check without locking, let me explain why,
+ if (!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags) &&
+ (!atomic_read(&dc->has_dirty) || !dc->writeback_running)) {

If the kenrel thread does not sleep and continue to run due to conditions
are not updated in time on the running CPU core, it just consumes more CPU
cycles and has no hurt. This should-sleep-but-run is safe here. We just
focus on the should-run-but-sleep condition, which means the writeback
thread goes to sleep in mistake while it should continue to run.
1, First of all, no matter the writeback thread is hung or not,
kthread_stop() from cached_dev_detach_finish() will wake up it and
terminate by making kthread_should_stop() return true. And in normal
run time, bit on index BCACHE_DEV_DETACHING is always cleared, the
condition
!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags)
is always true and can be ignored as constant value.
2, If one of the following conditions is true, the writeback thread should
go to sleep,
"!atomic_read(&dc->has_dirty)" or "!dc->writeback_running)"
each of them independently controls the writeback thread should sleep or
not, let's analyse them one by one.
2.1 condition "!atomic_read(&dc->has_dirty)"
If dc->has_dirty is set from 0 to 1 on another CPU core, bcache will
call bch_writeback_queue() immediately or call bch_writeback_add() which
indirectly calls bch_writeback_queue() too. In bch_writeback_queue(),
wake_up_process(dc->writeback_thread) is called. It sets writeback
thread's task state to TASK_RUNNING and following an implicit memory
barrier, then tries to wake up the writeback thread.
In writeback thread, its task state is set to TASK_INTERRUPTIBLE before
doing the condition check. If other CPU core sets the TASK_RUNNING state
after writeback thread setting TASK_INTERRUPTIBLE, the writeback thread
will be scheduled to run very soon because its state is not
TASK_INTERRUPTIBLE. If other CPU core sets the TASK_RUNNING state before
writeback thread setting TASK_INTERRUPTIBLE, the implict memory barrier
of wake_up_process() will make sure modification of dc->has_dirty on
other CPU core is updated and observed on the CPU core of writeback
thread. Therefore the condition check will correctly be false, and
continue writeback code without sleeping.
2.2 condition "!dc->writeback_running)"
dc->writeback_running can be changed via sysfs file, every time it is
modified, a following bch_writeback_queue() is alwasy called. So the
change is always observed on the CPU core of writeback thread. If
dc->writeback_running is changed from 0 to 1 on other CPU core, this
condition check will observe the modification and allow writeback
thread to continue to run without sleeping.
Now we can see, even without a locking protection, multiple conditions
check is safe here, no deadlock or process hang up will happen.

I compose a separte patch because that patch "bcache: fix cached_dev->count
usage for bch_cache_set_error()" already gets a "Reviewed-by:" from Hannes
Reinecke. Also this fix is not trivial and good for a separate patch.

Signed-off-by: Coly Li <[email protected]>
Reviewed-by: Michael Lyle <[email protected]>
Cc: Hannes Reinecke <[email protected]>
Cc: Huijun Tang <[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/md/bcache/writeback.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)

--- a/drivers/md/bcache/writeback.c
+++ b/drivers/md/bcache/writeback.c
@@ -426,9 +426,15 @@ static int bch_writeback_thread(void *ar
while (!kthread_should_stop()) {
down_write(&dc->writeback_lock);
set_current_state(TASK_INTERRUPTIBLE);
- if (!atomic_read(&dc->has_dirty) ||
- (!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags) &&
- !dc->writeback_running)) {
+ /*
+ * If the bache device is detaching, skip here and continue
+ * to perform writeback. Otherwise, if no dirty data on cache,
+ * or there is dirty data on cache but writeback is disabled,
+ * the writeback thread should sleep here and wait for others
+ * to wake up it.
+ */
+ if (!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags) &&
+ (!atomic_read(&dc->has_dirty) || !dc->writeback_running)) {
up_write(&dc->writeback_lock);

if (kthread_should_stop()) {
@@ -450,6 +456,14 @@ static int bch_writeback_thread(void *ar
cached_dev_put(dc);
SET_BDEV_STATE(&dc->sb, BDEV_STATE_CLEAN);
bch_write_bdev_super(dc, NULL);
+ /*
+ * If bcache device is detaching via sysfs interface,
+ * writeback thread should stop after there is no dirty
+ * data on cache. BCACHE_DEV_DETACHING flag is set in
+ * bch_cached_dev_detach().
+ */
+ if (test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags))
+ break;
}

up_write(&dc->writeback_lock);



2018-05-28 15:15:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 203/268] zorro: Set up z->dev.dma_mask for the DMA API

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

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

From: Michael Schmitz <[email protected]>

[ Upstream commit 55496d3fe2acd1a365c43cbd613a20ecd4d74395 ]

The generic DMA API uses dev->dma_mask to check the DMA addressable
memory bitmask, and warns if no mask is set or even allocated.

Set z->dev.dma_coherent_mask on Zorro bus scan, and make z->dev.dma_mask
to point to z->dev.dma_coherent_mask so device drivers that need DMA have
everything set up to avoid warnings from dma_alloc_coherent(). Drivers can
still use dma_set_mask_and_coherent() to explicitly set their DMA bit mask.

Signed-off-by: Michael Schmitz <[email protected]>
[geert: Handle Zorro II with 24-bit address space]
Acked-by: Christoph Hellwig <[email protected]>
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/zorro/zorro.c | 12 ++++++++++++
1 file changed, 12 insertions(+)

--- a/drivers/zorro/zorro.c
+++ b/drivers/zorro/zorro.c
@@ -16,6 +16,7 @@
#include <linux/bitops.h>
#include <linux/string.h>
#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
#include <linux/slab.h>

#include <asm/byteorder.h>
@@ -185,6 +186,17 @@ static int __init amiga_zorro_probe(stru
z->dev.parent = &bus->dev;
z->dev.bus = &zorro_bus_type;
z->dev.id = i;
+ switch (z->rom.er_Type & ERT_TYPEMASK) {
+ case ERT_ZORROIII:
+ z->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ break;
+
+ case ERT_ZORROII:
+ default:
+ z->dev.coherent_dma_mask = DMA_BIT_MASK(24);
+ break;
+ }
+ z->dev.dma_mask = &z->dev.coherent_dma_mask;
}

/* ... then register them */



2018-05-28 15:15:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 198/268] virtio-net: Fix operstate for virtio when no VIRTIO_NET_F_STATUS

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

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

From: Jay Vosburgh <[email protected]>

[ Upstream commit bda7fab54828bbef2164bb23c0f6b1a7d05cc718 ]

The operstate update logic will leave an interface in the
default UNKNOWN operstate if the interface carrier state never changes
from the default carrier up state set at creation. This includes the
case of an explicit call to netif_carrier_on, as the carrier on to on
transition has no effect on operstate.

This affects virtio-net for the case that the virtio peer does
not support VIRTIO_NET_F_STATUS (the feature that provides carrier state
updates). Without this feature, the virtio specification states that
"the link should be assumed active," so, logically, the operstate should
be UP instead of UNKNOWN. This has impact on user space applications
that use the operstate to make availability decisions for the interface.

Resolve this by changing the virtio probe logic slightly to call
netif_carrier_off for both the "with" and "without" VIRTIO_NET_F_STATUS
cases, and then the existing call to netif_carrier_on for the "without"
case will cause an operstate transition.

Cc: "Michael S. Tsirkin" <[email protected]>
Cc: Jason Wang <[email protected]>
Cc: Ben Hutchings <[email protected]>
Signed-off-by: Jay Vosburgh <[email protected]>
Acked-by: Michael S. Tsirkin <[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/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1912,8 +1912,8 @@ static int virtnet_probe(struct virtio_d

/* Assume link up if device can't report link status,
otherwise get link status from config. */
+ netif_carrier_off(dev);
if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
- netif_carrier_off(dev);
schedule_work(&vi->config_work);
} else {
vi->status = VIRTIO_NET_S_LINK_UP;



2018-05-28 15:16:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 183/268] xen/acpi: off by one in read_acpi_id()

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

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

From: Dan Carpenter <[email protected]>

[ Upstream commit c37a3c94775855567b90f91775b9691e10bd2806 ]

If acpi_id is == nr_acpi_bits, then we access one element beyond the end
of the acpi_psd[] array or we set one bit beyond the end of the bit map
when we do __set_bit(acpi_id, acpi_id_present);

Fixes: 59a568029181 ("xen/acpi-processor: C and P-state driver that uploads said data to hypervisor.")
Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: Joao Martins <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Signed-off-by: Boris Ostrovsky <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/xen/xen-acpi-processor.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/xen/xen-acpi-processor.c
+++ b/drivers/xen/xen-acpi-processor.c
@@ -362,9 +362,9 @@ read_acpi_id(acpi_handle handle, u32 lvl
}
/* There are more ACPI Processor objects than in x2APIC or MADT.
* This can happen with incorrect ACPI SSDT declerations. */
- if (acpi_id > nr_acpi_bits) {
- pr_debug("We only have %u, trying to set %u\n",
- nr_acpi_bits, acpi_id);
+ if (acpi_id >= nr_acpi_bits) {
+ pr_debug("max acpi id %u, trying to set %u\n",
+ nr_acpi_bits - 1, acpi_id);
return AE_OK;
}
/* OK, There is a ACPI Processor object */



2018-05-28 15:16:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 199/268] arm: dts: socfpga: fix GIC PPI warning

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

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

From: Philipp Puschmann <[email protected]>

[ Upstream commit 6d97d5aba08b26108f95dc9fb7bbe4d9436c769c ]

Fixes the warning "GIC: PPI13 is secure or misconfigured" by
changing the interrupt type from level_low to edge_raising

Signed-off-by: Philipp Puschmann <[email protected]>
Signed-off-by: Dinh Nguyen <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/boot/dts/socfpga.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -738,7 +738,7 @@
timer@fffec600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0xfffec600 0x100>;
- interrupts = <1 13 0xf04>;
+ interrupts = <1 13 0xf01>;
clocks = <&mpu_periph_clk>;
};




2018-05-28 15:17:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 196/268] ima: Fix Kconfig to select TPM 2.0 CRB interface

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

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

From: Jiandi An <[email protected]>

[ Upstream commit fac37c628fd5d68fd7298d9b57ae8601ee1b4723 ]

TPM_CRB driver provides TPM CRB 2.0 support. If it is built as a
module, the TPM chip is registered after IMA init. tpm_pcr_read() in
IMA fails and displays the following message even though eventually
there is a TPM chip on the system.

ima: No TPM chip found, activating TPM-bypass! (rc=-19)

Fix IMA Kconfig to select TPM_CRB so TPM_CRB driver is built in the kernel
and initializes before IMA.

Signed-off-by: Jiandi An <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
security/integrity/ima/Kconfig | 1 +
1 file changed, 1 insertion(+)

--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -10,6 +10,7 @@ config IMA
select CRYPTO_HASH_INFO
select TCG_TPM if HAS_IOMEM && !UML
select TCG_TIS if TCG_TPM && X86
+ select TCG_CRB if TCG_TPM && ACPI
select TCG_IBMVTPM if TCG_TPM && PPC_PSERIES
help
The Trusted Computing Group(TCG) runtime Integrity



2018-05-28 15:17:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 197/268] ima: Fallback to the builtin hash algorithm

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

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

From: Petr Vorel <[email protected]>

[ Upstream commit ab60368ab6a452466885ef4edf0cefd089465132 ]

IMA requires having it's hash algorithm be compiled-in due to it's
early use. The default IMA algorithm is protected by Kconfig to be
compiled-in.

The ima_hash kernel parameter allows to choose the hash algorithm. When
the specified algorithm is not available or available as a module, IMA
initialization fails, which leads to a kernel panic (mknodat syscall calls
ima_post_path_mknod()). Therefore as fallback we force IMA to use
the default builtin Kconfig hash algorithm.

Fixed crash:

$ grep CONFIG_CRYPTO_MD4 .config
CONFIG_CRYPTO_MD4=m

[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.14-2.3-default root=UUID=74ae8202-9ca7-4e39-813b-22287ec52f7a video=1024x768-16 plymouth.ignore-serial-consoles console=ttyS0 console=tty resume=/dev/disk/by-path/pci-0000:00:07.0-part3 splash=silent showopts ima_hash=md4
...
[ 1.545190] ima: Can not allocate md4 (reason: -2)
...
[ 2.610120] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 2.611903] IP: ima_match_policy+0x23/0x390
[ 2.612967] PGD 0 P4D 0
[ 2.613080] Oops: 0000 [#1] SMP
[ 2.613080] Modules linked in: autofs4
[ 2.613080] Supported: Yes
[ 2.613080] CPU: 0 PID: 1 Comm: systemd Not tainted 4.12.14-2.3-default #1
[ 2.613080] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
[ 2.613080] task: ffff88003e2d0040 task.stack: ffffc90000190000
[ 2.613080] RIP: 0010:ima_match_policy+0x23/0x390
[ 2.613080] RSP: 0018:ffffc90000193e88 EFLAGS: 00010296
[ 2.613080] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000004
[ 2.613080] RDX: 0000000000000010 RSI: 0000000000000001 RDI: ffff880037071728
[ 2.613080] RBP: 0000000000008000 R08: 0000000000000000 R09: 0000000000000000
[ 2.613080] R10: 0000000000000008 R11: 61c8864680b583eb R12: 00005580ff10086f
[ 2.613080] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000008000
[ 2.613080] FS: 00007f5c1da08940(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[ 2.613080] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2.613080] CR2: 0000000000000000 CR3: 0000000037002000 CR4: 00000000003406f0
[ 2.613080] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2.613080] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 2.613080] Call Trace:
[ 2.613080] ? shmem_mknod+0xbf/0xd0
[ 2.613080] ima_post_path_mknod+0x1c/0x40
[ 2.613080] SyS_mknod+0x210/0x220
[ 2.613080] entry_SYSCALL_64_fastpath+0x1a/0xa5
[ 2.613080] RIP: 0033:0x7f5c1bfde570
[ 2.613080] RSP: 002b:00007ffde1c90dc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000085
[ 2.613080] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5c1bfde570
[ 2.613080] RDX: 0000000000000000 RSI: 0000000000008000 RDI: 00005580ff10086f
[ 2.613080] RBP: 00007ffde1c91040 R08: 00005580ff10086f R09: 0000000000000000
[ 2.613080] R10: 0000000000104000 R11: 0000000000000246 R12: 00005580ffb99660
[ 2.613080] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000002
[ 2.613080] Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 57 41 56 44 8d 14 09 41 55 41 54 55 53 44 89 d3 09 cb 48 83 ec 38 48 8b 05 c5 03 29 01 <4c> 8b 20 4c 39 e0 0f 84 d7 01 00 00 4c 89 44 24 08 89 54 24 20
[ 2.613080] RIP: ima_match_policy+0x23/0x390 RSP: ffffc90000193e88
[ 2.613080] CR2: 0000000000000000
[ 2.613080] ---[ end trace 9a9f0a8a73079f6a ]---
[ 2.673052] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[ 2.673052]
[ 2.675337] Kernel Offset: disabled
[ 2.676405] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009

Signed-off-by: Petr Vorel <[email protected]>
Signed-off-by: Mimi Zohar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
security/integrity/ima/ima_crypto.c | 2 ++
security/integrity/ima/ima_main.c | 13 +++++++++++++
2 files changed, 15 insertions(+)

--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -78,6 +78,8 @@ int __init ima_init_crypto(void)
hash_algo_name[ima_hash_algo], rc);
return rc;
}
+ pr_info("Allocated hash algorithm: %s\n",
+ hash_algo_name[ima_hash_algo]);
return 0;
}

--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -16,6 +16,9 @@
* implements the IMA hooks: ima_bprm_check, ima_file_mmap,
* and ima_file_check.
*/
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/module.h>
#include <linux/file.h>
#include <linux/binfmts.h>
@@ -353,6 +356,16 @@ static int __init init_ima(void)

hash_setup(CONFIG_IMA_DEFAULT_HASH);
error = ima_init();
+
+ if (error && strcmp(hash_algo_name[ima_hash_algo],
+ CONFIG_IMA_DEFAULT_HASH) != 0) {
+ pr_info("Allocating %s failed, going to use default hash algorithm %s\n",
+ hash_algo_name[ima_hash_algo], CONFIG_IMA_DEFAULT_HASH);
+ hash_setup_done = 0;
+ hash_setup(CONFIG_IMA_DEFAULT_HASH);
+ error = ima_init();
+ }
+
if (!error) {
ima_initialized = 1;
ima_update_policy_flag();



2018-05-28 15:17:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 194/268] net/mlx5: Protect from command bit overflow

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

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

From: Leon Romanovsky <[email protected]>

[ Upstream commit 957f6ba8adc7be401a74ccff427e4cfd88d3bfcb ]

The system with CONFIG_UBSAN enabled on produces the following error
during driver initialization. The reason to it that max_reg_cmds can be
larger enough to cause to "1 << max_reg_cmds" overflow the unsigned long.

================================================================================
UBSAN: Undefined behaviour in drivers/net/ethernet/mellanox/mlx5/core/cmd.c:1805:42
signed integer overflow:
-2147483648 - 1 cannot be represented in type 'int'
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-00032-g06cda2358d9b-dirty #724
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
Call Trace:
dump_stack+0xe9/0x18f
? dma_virt_alloc+0x81/0x81
ubsan_epilogue+0xe/0x4e
handle_overflow+0x187/0x20c
mlx5_cmd_init+0x73a/0x12b0
mlx5_load_one+0x1c3d/0x1d30
init_one+0xd02/0xf10
pci_device_probe+0x26c/0x3b0
driver_probe_device+0x622/0xb40
__driver_attach+0x175/0x1b0
bus_for_each_dev+0xef/0x190
bus_add_driver+0x2db/0x490
driver_register+0x16b/0x1e0
__pci_register_driver+0x177/0x1b0
init+0x6d/0x92
do_one_initcall+0x15b/0x270
kernel_init_freeable+0x2d8/0x3d0
kernel_init+0x14/0x190
ret_from_fork+0x24/0x30
================================================================================

Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
@@ -1623,7 +1623,7 @@ int mlx5_cmd_init(struct mlx5_core_dev *

cmd->checksum_disabled = 1;
cmd->max_reg_cmds = (1 << cmd->log_sz) - 1;
- cmd->bitmask = (1 << cmd->max_reg_cmds) - 1;
+ cmd->bitmask = (1UL << cmd->max_reg_cmds) - 1;

cmd->cmdif_rev = ioread32be(&dev->iseg->cmdif_rev_fw_sub) >> 16;
if (cmd->cmdif_rev > CMD_IF_REV) {



2018-05-28 15:17:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 193/268] selftests: Print the test were running to /dev/kmsg

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

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

From: Michael Ellerman <[email protected]>

[ Upstream commit 88893cf787d3062c631cc20b875068eb11756e03 ]

Some tests cause the kernel to print things to the kernel log
buffer (ie. printk), in particular oops and warnings etc. However when
running all the tests in succession it's not always obvious which
test(s) caused the kernel to print something.

We can narrow it down by printing which test directory we're running
in to /dev/kmsg, if it's writable.

Example output:

[ 170.149149] kselftest: Running tests in powerpc
[ 305.300132] kworker/dying (71) used greatest stack depth: 7776 bytes
left
[ 808.915456] kselftest: Running tests in pstore

Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/testing/selftests/Makefile | 1 +
1 file changed, 1 insertion(+)

--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -90,6 +90,7 @@ ifdef INSTALL_PATH
for TARGET in $(TARGETS); do \
echo "echo ; echo Running tests in $$TARGET" >> $(ALL_SCRIPT); \
echo "echo ========================================" >> $(ALL_SCRIPT); \
+ echo "[ -w /dev/kmsg ] && echo \"kselftest: Running tests in $$TARGET\" >> /dev/kmsg" >> $(ALL_SCRIPT); \
echo "cd $$TARGET" >> $(ALL_SCRIPT); \
make -s --no-print-directory -C $$TARGET emit_tests >> $(ALL_SCRIPT); \
echo "cd \$$ROOT" >> $(ALL_SCRIPT); \



2018-05-28 15:17:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 182/268] btrfs: fix lockdep splat in btrfs_alloc_subvolume_writers

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

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

From: Jeff Mahoney <[email protected]>

[ Upstream commit 8a5a916d9a35e13576d79cc16e24611821b13e34 ]

While running btrfs/011, I hit the following lockdep splat.

This is the important bit:
pcpu_alloc+0x1ac/0x5e0
__percpu_counter_init+0x4e/0xb0
btrfs_init_fs_root+0x99/0x1c0 [btrfs]
btrfs_get_fs_root.part.54+0x5b/0x150 [btrfs]
resolve_indirect_refs+0x130/0x830 [btrfs]
find_parent_nodes+0x69e/0xff0 [btrfs]
btrfs_find_all_roots_safe+0xa0/0x110 [btrfs]
btrfs_find_all_roots+0x50/0x70 [btrfs]
btrfs_qgroup_prepare_account_extents+0x53/0x90 [btrfs]
btrfs_commit_transaction+0x3ce/0x9b0 [btrfs]

The percpu_counter_init call in btrfs_alloc_subvolume_writers
uses GFP_KERNEL, which we can't do during transaction commit.

This switches it to GFP_NOFS.

========================================================
WARNING: possible irq lock inversion dependency detected
4.12.14-kvmsmall #8 Tainted: G W
--------------------------------------------------------
kswapd0/50 just changed the state of lock:
(&delayed_node->mutex){+.+.-.}, at: [<ffffffffc06994fa>] __btrfs_release_delayed_node+0x3a/0x1f0 [btrfs]
but this lock took another, RECLAIM_FS-unsafe lock in the past:
(pcpu_alloc_mutex){+.+.+.}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
Chain exists of:
&delayed_node->mutex --> &found->groups_sem --> pcpu_alloc_mutex

Possible interrupt unsafe locking scenario:

CPU0 CPU1
---- ----
lock(pcpu_alloc_mutex);
local_irq_disable();
lock(&delayed_node->mutex);
lock(&found->groups_sem);
<Interrupt>
lock(&delayed_node->mutex);

*** DEADLOCK ***

2 locks held by kswapd0/50:
#0: (shrinker_rwsem){++++..}, at: [<ffffffff811dc11f>] shrink_slab+0x7f/0x5b0
#1: (&type->s_umount_key#30){+++++.}, at: [<ffffffff8126dec6>] trylock_super+0x16/0x50

the shortest dependencies between 2nd lock and 1st lock:
-> (pcpu_alloc_mutex){+.+.+.} ops: 4904 {
HARDIRQ-ON-W at:
__mutex_lock+0x4e/0x8c0
pcpu_alloc+0x1ac/0x5e0
alloc_kmem_cache_cpus.isra.70+0x25/0xa0
__do_tune_cpucache+0x2c/0x220
do_tune_cpucache+0x26/0xc0
enable_cpucache+0x6d/0xf0
kmem_cache_init_late+0x42/0x75
start_kernel+0x343/0x4cb
x86_64_start_kernel+0x127/0x134
secondary_startup_64+0xa5/0xb0
SOFTIRQ-ON-W at:
__mutex_lock+0x4e/0x8c0
pcpu_alloc+0x1ac/0x5e0
alloc_kmem_cache_cpus.isra.70+0x25/0xa0
__do_tune_cpucache+0x2c/0x220
do_tune_cpucache+0x26/0xc0
enable_cpucache+0x6d/0xf0
kmem_cache_init_late+0x42/0x75
start_kernel+0x343/0x4cb
x86_64_start_kernel+0x127/0x134
secondary_startup_64+0xa5/0xb0
RECLAIM_FS-ON-W at:
__kmalloc+0x47/0x310
pcpu_extend_area_map+0x2b/0xc0
pcpu_alloc+0x3ec/0x5e0
alloc_kmem_cache_cpus.isra.70+0x25/0xa0
__do_tune_cpucache+0x2c/0x220
do_tune_cpucache+0x26/0xc0
enable_cpucache+0x6d/0xf0
__kmem_cache_create+0x1bf/0x390
create_cache+0xba/0x1b0
kmem_cache_create+0x1f8/0x2b0
ksm_init+0x6f/0x19d
do_one_initcall+0x50/0x1b0
kernel_init_freeable+0x201/0x289
kernel_init+0xa/0x100
ret_from_fork+0x3a/0x50
INITIAL USE at:
__mutex_lock+0x4e/0x8c0
pcpu_alloc+0x1ac/0x5e0
alloc_kmem_cache_cpus.isra.70+0x25/0xa0
setup_cpu_cache+0x2f/0x1f0
__kmem_cache_create+0x1bf/0x390
create_boot_cache+0x8b/0xb1
kmem_cache_init+0xa1/0x19e
start_kernel+0x270/0x4cb
x86_64_start_kernel+0x127/0x134
secondary_startup_64+0xa5/0xb0
}
... key at: [<ffffffff821d8e70>] pcpu_alloc_mutex+0x70/0xa0
... acquired at:
pcpu_alloc+0x1ac/0x5e0
__percpu_counter_init+0x4e/0xb0
btrfs_init_fs_root+0x99/0x1c0 [btrfs]
btrfs_get_fs_root.part.54+0x5b/0x150 [btrfs]
resolve_indirect_refs+0x130/0x830 [btrfs]
find_parent_nodes+0x69e/0xff0 [btrfs]
btrfs_find_all_roots_safe+0xa0/0x110 [btrfs]
btrfs_find_all_roots+0x50/0x70 [btrfs]
btrfs_qgroup_prepare_account_extents+0x53/0x90 [btrfs]
btrfs_commit_transaction+0x3ce/0x9b0 [btrfs]
transaction_kthread+0x176/0x1b0 [btrfs]
kthread+0x102/0x140
ret_from_fork+0x3a/0x50

-> (&fs_info->commit_root_sem){++++..} ops: 1566382 {
HARDIRQ-ON-W at:
down_write+0x3e/0xa0
cache_block_group+0x287/0x420 [btrfs]
find_free_extent+0x106c/0x12d0 [btrfs]
btrfs_reserve_extent+0xd8/0x170 [btrfs]
cow_file_range.isra.66+0x133/0x470 [btrfs]
run_delalloc_range+0x121/0x410 [btrfs]
writepage_delalloc.isra.50+0xfe/0x180 [btrfs]
__extent_writepage+0x19a/0x360 [btrfs]
extent_write_cache_pages.constprop.56+0x249/0x3e0 [btrfs]
extent_writepages+0x4d/0x60 [btrfs]
do_writepages+0x1a/0x70
__filemap_fdatawrite_range+0xa7/0xe0
btrfs_rename+0x5ee/0xdb0 [btrfs]
vfs_rename+0x52a/0x7e0
SyS_rename+0x351/0x3b0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
HARDIRQ-ON-R at:
down_read+0x35/0x90
caching_thread+0x57/0x560 [btrfs]
normal_work_helper+0x1c0/0x5e0 [btrfs]
process_one_work+0x1e0/0x5c0
worker_thread+0x44/0x390
kthread+0x102/0x140
ret_from_fork+0x3a/0x50
SOFTIRQ-ON-W at:
down_write+0x3e/0xa0
cache_block_group+0x287/0x420 [btrfs]
find_free_extent+0x106c/0x12d0 [btrfs]
btrfs_reserve_extent+0xd8/0x170 [btrfs]
cow_file_range.isra.66+0x133/0x470 [btrfs]
run_delalloc_range+0x121/0x410 [btrfs]
writepage_delalloc.isra.50+0xfe/0x180 [btrfs]
__extent_writepage+0x19a/0x360 [btrfs]
extent_write_cache_pages.constprop.56+0x249/0x3e0 [btrfs]
extent_writepages+0x4d/0x60 [btrfs]
do_writepages+0x1a/0x70
__filemap_fdatawrite_range+0xa7/0xe0
btrfs_rename+0x5ee/0xdb0 [btrfs]
vfs_rename+0x52a/0x7e0
SyS_rename+0x351/0x3b0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
SOFTIRQ-ON-R at:
down_read+0x35/0x90
caching_thread+0x57/0x560 [btrfs]
normal_work_helper+0x1c0/0x5e0 [btrfs]
process_one_work+0x1e0/0x5c0
worker_thread+0x44/0x390
kthread+0x102/0x140
ret_from_fork+0x3a/0x50
INITIAL USE at:
down_write+0x3e/0xa0
cache_block_group+0x287/0x420 [btrfs]
find_free_extent+0x106c/0x12d0 [btrfs]
btrfs_reserve_extent+0xd8/0x170 [btrfs]
cow_file_range.isra.66+0x133/0x470 [btrfs]
run_delalloc_range+0x121/0x410 [btrfs]
writepage_delalloc.isra.50+0xfe/0x180 [btrfs]
__extent_writepage+0x19a/0x360 [btrfs]
extent_write_cache_pages.constprop.56+0x249/0x3e0 [btrfs]
extent_writepages+0x4d/0x60 [btrfs]
do_writepages+0x1a/0x70
__filemap_fdatawrite_range+0xa7/0xe0
btrfs_rename+0x5ee/0xdb0 [btrfs]
vfs_rename+0x52a/0x7e0
SyS_rename+0x351/0x3b0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
}
... key at: [<ffffffffc0729578>] __key.61970+0x0/0xfffffffffff9aa88 [btrfs]
... acquired at:
cache_block_group+0x287/0x420 [btrfs]
find_free_extent+0x106c/0x12d0 [btrfs]
btrfs_reserve_extent+0xd8/0x170 [btrfs]
btrfs_alloc_tree_block+0x12f/0x4c0 [btrfs]
btrfs_create_tree+0xbb/0x2a0 [btrfs]
btrfs_create_uuid_tree+0x37/0x140 [btrfs]
open_ctree+0x23c0/0x2660 [btrfs]
btrfs_mount+0xd36/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
btrfs_mount+0x18c/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
do_mount+0x1c1/0xcc0
SyS_mount+0x7e/0xd0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7

-> (&found->groups_sem){++++..} ops: 2134587 {
HARDIRQ-ON-W at:
down_write+0x3e/0xa0
__link_block_group+0x34/0x130 [btrfs]
btrfs_read_block_groups+0x33d/0x7b0 [btrfs]
open_ctree+0x2054/0x2660 [btrfs]
btrfs_mount+0xd36/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
btrfs_mount+0x18c/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
do_mount+0x1c1/0xcc0
SyS_mount+0x7e/0xd0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
HARDIRQ-ON-R at:
down_read+0x35/0x90
btrfs_calc_num_tolerated_disk_barrier_failures+0x113/0x1f0 [btrfs]
open_ctree+0x207b/0x2660 [btrfs]
btrfs_mount+0xd36/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
btrfs_mount+0x18c/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
do_mount+0x1c1/0xcc0
SyS_mount+0x7e/0xd0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
SOFTIRQ-ON-W at:
down_write+0x3e/0xa0
__link_block_group+0x34/0x130 [btrfs]
btrfs_read_block_groups+0x33d/0x7b0 [btrfs]
open_ctree+0x2054/0x2660 [btrfs]
btrfs_mount+0xd36/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
btrfs_mount+0x18c/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
do_mount+0x1c1/0xcc0
SyS_mount+0x7e/0xd0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
SOFTIRQ-ON-R at:
down_read+0x35/0x90
btrfs_calc_num_tolerated_disk_barrier_failures+0x113/0x1f0 [btrfs]
open_ctree+0x207b/0x2660 [btrfs]
btrfs_mount+0xd36/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
btrfs_mount+0x18c/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
do_mount+0x1c1/0xcc0
SyS_mount+0x7e/0xd0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
INITIAL USE at:
down_write+0x3e/0xa0
__link_block_group+0x34/0x130 [btrfs]
btrfs_read_block_groups+0x33d/0x7b0 [btrfs]
open_ctree+0x2054/0x2660 [btrfs]
btrfs_mount+0xd36/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
btrfs_mount+0x18c/0xf90 [btrfs]
mount_fs+0x3a/0x160
vfs_kern_mount+0x66/0x150
do_mount+0x1c1/0xcc0
SyS_mount+0x7e/0xd0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
}
... key at: [<ffffffffc0729488>] __key.59101+0x0/0xfffffffffff9ab78 [btrfs]
... acquired at:
find_free_extent+0xcb4/0x12d0 [btrfs]
btrfs_reserve_extent+0xd8/0x170 [btrfs]
btrfs_alloc_tree_block+0x12f/0x4c0 [btrfs]
__btrfs_cow_block+0x110/0x5b0 [btrfs]
btrfs_cow_block+0xd7/0x290 [btrfs]
btrfs_search_slot+0x1f6/0x960 [btrfs]
btrfs_lookup_inode+0x2a/0x90 [btrfs]
__btrfs_update_delayed_inode+0x65/0x210 [btrfs]
btrfs_commit_inode_delayed_inode+0x121/0x130 [btrfs]
btrfs_evict_inode+0x3fe/0x6a0 [btrfs]
evict+0xc4/0x190
__dentry_kill+0xbf/0x170
dput+0x2ae/0x2f0
SyS_rename+0x2a6/0x3b0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7

-> (&delayed_node->mutex){+.+.-.} ops: 5580204 {
HARDIRQ-ON-W at:
__mutex_lock+0x4e/0x8c0
btrfs_delayed_update_inode+0x46/0x6e0 [btrfs]
btrfs_update_inode+0x83/0x110 [btrfs]
btrfs_dirty_inode+0x62/0xe0 [btrfs]
touch_atime+0x8c/0xb0
do_generic_file_read+0x818/0xb10
__vfs_read+0xdc/0x150
vfs_read+0x8a/0x130
SyS_read+0x45/0xa0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
SOFTIRQ-ON-W at:
__mutex_lock+0x4e/0x8c0
btrfs_delayed_update_inode+0x46/0x6e0 [btrfs]
btrfs_update_inode+0x83/0x110 [btrfs]
btrfs_dirty_inode+0x62/0xe0 [btrfs]
touch_atime+0x8c/0xb0
do_generic_file_read+0x818/0xb10
__vfs_read+0xdc/0x150
vfs_read+0x8a/0x130
SyS_read+0x45/0xa0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
IN-RECLAIM_FS-W at:
__mutex_lock+0x4e/0x8c0
__btrfs_release_delayed_node+0x3a/0x1f0 [btrfs]
btrfs_evict_inode+0x22c/0x6a0 [btrfs]
evict+0xc4/0x190
dispose_list+0x35/0x50
prune_icache_sb+0x42/0x50
super_cache_scan+0x139/0x190
shrink_slab+0x262/0x5b0
shrink_node+0x2eb/0x2f0
kswapd+0x2eb/0x890
kthread+0x102/0x140
ret_from_fork+0x3a/0x50
INITIAL USE at:
__mutex_lock+0x4e/0x8c0
btrfs_delayed_update_inode+0x46/0x6e0 [btrfs]
btrfs_update_inode+0x83/0x110 [btrfs]
btrfs_dirty_inode+0x62/0xe0 [btrfs]
touch_atime+0x8c/0xb0
do_generic_file_read+0x818/0xb10
__vfs_read+0xdc/0x150
vfs_read+0x8a/0x130
SyS_read+0x45/0xa0
do_syscall_64+0x79/0x1e0
entry_SYSCALL_64_after_hwframe+0x42/0xb7
}
... key at: [<ffffffffc072d488>] __key.56935+0x0/0xfffffffffff96b78 [btrfs]
... acquired at:
__lock_acquire+0x264/0x11c0
lock_acquire+0xbd/0x1e0
__mutex_lock+0x4e/0x8c0
__btrfs_release_delayed_node+0x3a/0x1f0 [btrfs]
btrfs_evict_inode+0x22c/0x6a0 [btrfs]
evict+0xc4/0x190
dispose_list+0x35/0x50
prune_icache_sb+0x42/0x50
super_cache_scan+0x139/0x190
shrink_slab+0x262/0x5b0
shrink_node+0x2eb/0x2f0
kswapd+0x2eb/0x890
kthread+0x102/0x140
ret_from_fork+0x3a/0x50

stack backtrace:
CPU: 1 PID: 50 Comm: kswapd0 Tainted: G W 4.12.14-kvmsmall #8 SLE15 (unreleased)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
Call Trace:
dump_stack+0x78/0xb7
print_irq_inversion_bug.part.38+0x19f/0x1aa
check_usage_forwards+0x102/0x120
? ret_from_fork+0x3a/0x50
? check_usage_backwards+0x110/0x110
mark_lock+0x16c/0x270
__lock_acquire+0x264/0x11c0
? pagevec_lookup_entries+0x1a/0x30
? truncate_inode_pages_range+0x2b3/0x7f0
lock_acquire+0xbd/0x1e0
? __btrfs_release_delayed_node+0x3a/0x1f0 [btrfs]
__mutex_lock+0x4e/0x8c0
? __btrfs_release_delayed_node+0x3a/0x1f0 [btrfs]
? __btrfs_release_delayed_node+0x3a/0x1f0 [btrfs]
? btrfs_evict_inode+0x1f6/0x6a0 [btrfs]
__btrfs_release_delayed_node+0x3a/0x1f0 [btrfs]
btrfs_evict_inode+0x22c/0x6a0 [btrfs]
evict+0xc4/0x190
dispose_list+0x35/0x50
prune_icache_sb+0x42/0x50
super_cache_scan+0x139/0x190
shrink_slab+0x262/0x5b0
shrink_node+0x2eb/0x2f0
kswapd+0x2eb/0x890
kthread+0x102/0x140
? mem_cgroup_shrink_node+0x2c0/0x2c0
? kthread_create_on_node+0x40/0x40
ret_from_fork+0x3a/0x50

Signed-off-by: Jeff Mahoney <[email protected]>
Reviewed-by: Liu Bo <[email protected]>
Signed-off-by: David Sterba <[email protected]>

Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/disk-io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1196,7 +1196,7 @@ static struct btrfs_subvolume_writers *b
if (!writers)
return ERR_PTR(-ENOMEM);

- ret = percpu_counter_init(&writers->counter, 0, GFP_KERNEL);
+ ret = percpu_counter_init(&writers->counter, 0, GFP_NOFS);
if (ret < 0) {
kfree(writers);
return ERR_PTR(ret);



2018-05-28 15:17:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 192/268] tools/thermal: tmon: fix for segfault

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

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

From: Frank Asseg <[email protected]>

[ Upstream commit 6c59f64b7ecf2bccbe73931d7d573d66ed13b537 ]

Fixes a segfault occurring when e.g. <TAB> is pressed multiple times in the
ncurses tmon application. The segfault is caused by incrementing
cur_thermal_record in the main function without checking if it's value reached
NR_THERMAL_RECORD immediately. Since the boundary check only occurred in
update_thermal_data a race condition existed, which lead to an attempted read
beyond the last element of the trec array.

The fix was implemented by moving the cur_thermal_record incrementation to the
update_thermal_data function using a temporary variable on which the boundary
condition is checked before updating cur_thread_record, so that the variable is
never incremented beyond the trec array's boundary.

It seems the segfault does not occur on every machine: On a HP EliteBook G4 the
segfault happens, while it does not happen on a Thinkpad T540p.

Signed-off-by: Frank Asseg <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/thermal/tmon/sysfs.c | 12 +++++++-----
tools/thermal/tmon/tmon.c | 1 -
2 files changed, 7 insertions(+), 6 deletions(-)

--- a/tools/thermal/tmon/sysfs.c
+++ b/tools/thermal/tmon/sysfs.c
@@ -486,6 +486,7 @@ int zone_instance_to_index(int zone_inst
int update_thermal_data()
{
int i;
+ int next_thermal_record = cur_thermal_record + 1;
char tz_name[256];
static unsigned long samples;

@@ -495,9 +496,9 @@ int update_thermal_data()
}

/* circular buffer for keeping historic data */
- if (cur_thermal_record >= NR_THERMAL_RECORDS)
- cur_thermal_record = 0;
- gettimeofday(&trec[cur_thermal_record].tv, NULL);
+ if (next_thermal_record >= NR_THERMAL_RECORDS)
+ next_thermal_record = 0;
+ gettimeofday(&trec[next_thermal_record].tv, NULL);
if (tmon_log) {
fprintf(tmon_log, "%lu ", ++samples);
fprintf(tmon_log, "%3.1f ", p_param.t_target);
@@ -507,11 +508,12 @@ int update_thermal_data()
snprintf(tz_name, 256, "%s/%s%d", THERMAL_SYSFS, TZONE,
ptdata.tzi[i].instance);
sysfs_get_ulong(tz_name, "temp",
- &trec[cur_thermal_record].temp[i]);
+ &trec[next_thermal_record].temp[i]);
if (tmon_log)
fprintf(tmon_log, "%lu ",
- trec[cur_thermal_record].temp[i]/1000);
+ trec[next_thermal_record].temp[i] / 1000);
}
+ cur_thermal_record = next_thermal_record;
for (i = 0; i < ptdata.nr_cooling_dev; i++) {
char cdev_name[256];
unsigned long val;
--- a/tools/thermal/tmon/tmon.c
+++ b/tools/thermal/tmon/tmon.c
@@ -336,7 +336,6 @@ int main(int argc, char **argv)
show_data_w();
show_cooling_device();
}
- cur_thermal_record++;
time_elapsed += ticktime;
controller_handler(trec[0].temp[target_tz_index] / 1000,
&yk);



2018-05-28 15:18:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 191/268] powerpc/perf: Fix kernel address leak via sampling registers

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

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

From: Michael Ellerman <[email protected]>

[ Upstream commit e1ebd0e5b9d0a10ba65e63a3514b6da8c6a5a819 ]

Current code in power_pmu_disable() does not clear the sampling
registers like Sampling Instruction Address Register (SIAR) and
Sampling Data Address Register (SDAR) after disabling the PMU. Since
these are userspace readable and could contain kernel addresses, add
code to explicitly clear the content of these registers.

Also add a "context synchronizing instruction" to enforce no further
updates to these registers as suggested by Power ISA v3.0B. From
section 9.4, on page 1108:

"If an mtspr instruction is executed that changes the value of a
Performance Monitor register other than SIAR, SDAR, and SIER, the
change is not guaranteed to have taken effect until after a
subsequent context synchronizing instruction has been executed (see
Chapter 11. "Synchronization Requirements for Context Alterations"
on page 1133)."

Signed-off-by: Madhavan Srinivasan <[email protected]>
[mpe: Massage change log and add ISA reference]
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/perf/core-book3s.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)

--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1198,6 +1198,7 @@ static void power_pmu_disable(struct pmu
*/
write_mmcr0(cpuhw, val);
mb();
+ isync();

/*
* Disable instruction sampling if it was enabled
@@ -1206,12 +1207,26 @@ static void power_pmu_disable(struct pmu
mtspr(SPRN_MMCRA,
cpuhw->mmcr[2] & ~MMCRA_SAMPLE_ENABLE);
mb();
+ isync();
}

cpuhw->disabled = 1;
cpuhw->n_added = 0;

ebb_switch_out(mmcr0);
+
+#ifdef CONFIG_PPC64
+ /*
+ * These are readable by userspace, may contain kernel
+ * addresses and are not switched by context switch, so clear
+ * them now to avoid leaking anything to userspace in general
+ * including to another process.
+ */
+ if (ppmu->flags & PPMU_ARCH_207S) {
+ mtspr(SPRN_SDAR, 0);
+ mtspr(SPRN_SIAR, 0);
+ }
+#endif
}

local_irq_restore(flags);



2018-05-28 15:18:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 151/268] net: qmi_wwan: add BroadMobi BM806U 2020:2033

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

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

From: Pawel Dembicki <[email protected]>

[ Upstream commit 743989254ea9f132517806d8893ca9b6cf9dc86b ]

BroadMobi BM806U is an Qualcomm MDM9225 based 3G/4G modem.
Tested hardware BM806U is mounted on D-Link DWR-921-C3 router.
The USB id is added to qmi_wwan.c to allow QMI communication with
the BM806U.

Tested on 4.14 kernel and OpenWRT.

Signed-off-by: Pawel Dembicki <[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/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -713,6 +713,7 @@ static const struct usb_device_id produc
{QMI_FIXED_INTF(0x19d2, 0x2002, 4)}, /* ZTE (Vodafone) K3765-Z */
{QMI_FIXED_INTF(0x2001, 0x7e19, 4)}, /* D-Link DWM-221 B1 */
{QMI_FIXED_INTF(0x2001, 0x7e35, 4)}, /* D-Link DWM-222 */
+ {QMI_FIXED_INTF(0x2020, 0x2033, 4)}, /* BroadMobi BM806U */
{QMI_FIXED_INTF(0x0f3d, 0x68a2, 8)}, /* Sierra Wireless MC7700 */
{QMI_FIXED_INTF(0x114f, 0x68a2, 8)}, /* Sierra Wireless MC7750 */
{QMI_FIXED_INTF(0x1199, 0x68a2, 8)}, /* Sierra Wireless MC7710 in QMI mode */



2018-05-28 15:18:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 154/268] llc: properly handle dev_queue_xmit() return value

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

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

From: Cong Wang <[email protected]>

[ Upstream commit b85ab56c3f81c5a24b5a5213374f549df06430da ]

llc_conn_send_pdu() pushes the skb into write queue and
calls llc_conn_send_pdus() to flush them out. However, the
status of dev_queue_xmit() is not returned to caller,
in this case, llc_conn_state_process().

llc_conn_state_process() needs hold the skb no matter
success or failure, because it still uses it after that,
therefore we should hold skb before dev_queue_xmit() when
that skb is the one being processed by llc_conn_state_process().

For other callers, they can just pass NULL and ignore
the return value as they are.

Reported-by: Noam Rathaus <[email protected]>
Signed-off-by: Cong Wang <[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]>
---
include/net/llc_conn.h | 2 +-
net/llc/llc_c_ac.c | 15 +++++++++------
net/llc/llc_conn.c | 32 +++++++++++++++++++++++---------
3 files changed, 33 insertions(+), 16 deletions(-)

--- a/include/net/llc_conn.h
+++ b/include/net/llc_conn.h
@@ -104,7 +104,7 @@ void llc_sk_reset(struct sock *sk);

/* Access to a connection */
int llc_conn_state_process(struct sock *sk, struct sk_buff *skb);
-void llc_conn_send_pdu(struct sock *sk, struct sk_buff *skb);
+int llc_conn_send_pdu(struct sock *sk, struct sk_buff *skb);
void llc_conn_rtn_pdu(struct sock *sk, struct sk_buff *skb);
void llc_conn_resend_i_pdu_as_cmd(struct sock *sk, u8 nr, u8 first_p_bit);
void llc_conn_resend_i_pdu_as_rsp(struct sock *sk, u8 nr, u8 first_f_bit);
--- a/net/llc/llc_c_ac.c
+++ b/net/llc/llc_c_ac.c
@@ -389,7 +389,7 @@ static int llc_conn_ac_send_i_cmd_p_set_
llc_pdu_init_as_i_cmd(skb, 0, llc->vS, llc->vR);
rc = llc_mac_hdr_init(skb, llc->dev->dev_addr, llc->daddr.mac);
if (likely(!rc)) {
- llc_conn_send_pdu(sk, skb);
+ rc = llc_conn_send_pdu(sk, skb);
llc_conn_ac_inc_vs_by_1(sk, skb);
}
return rc;
@@ -916,7 +916,7 @@ static int llc_conn_ac_send_i_rsp_f_set_
llc_pdu_init_as_i_cmd(skb, llc->ack_pf, llc->vS, llc->vR);
rc = llc_mac_hdr_init(skb, llc->dev->dev_addr, llc->daddr.mac);
if (likely(!rc)) {
- llc_conn_send_pdu(sk, skb);
+ rc = llc_conn_send_pdu(sk, skb);
llc_conn_ac_inc_vs_by_1(sk, skb);
}
return rc;
@@ -935,14 +935,17 @@ static int llc_conn_ac_send_i_rsp_f_set_
int llc_conn_ac_send_i_as_ack(struct sock *sk, struct sk_buff *skb)
{
struct llc_sock *llc = llc_sk(sk);
+ int ret;

if (llc->ack_must_be_send) {
- llc_conn_ac_send_i_rsp_f_set_ackpf(sk, skb);
+ ret = llc_conn_ac_send_i_rsp_f_set_ackpf(sk, skb);
llc->ack_must_be_send = 0 ;
llc->ack_pf = 0;
- } else
- llc_conn_ac_send_i_cmd_p_set_0(sk, skb);
- return 0;
+ } else {
+ ret = llc_conn_ac_send_i_cmd_p_set_0(sk, skb);
+ }
+
+ return ret;
}

/**
--- a/net/llc/llc_conn.c
+++ b/net/llc/llc_conn.c
@@ -30,7 +30,7 @@
#endif

static int llc_find_offset(int state, int ev_type);
-static void llc_conn_send_pdus(struct sock *sk);
+static int llc_conn_send_pdus(struct sock *sk, struct sk_buff *skb);
static int llc_conn_service(struct sock *sk, struct sk_buff *skb);
static int llc_exec_conn_trans_actions(struct sock *sk,
struct llc_conn_state_trans *trans,
@@ -193,11 +193,11 @@ out_skb_put:
return rc;
}

-void llc_conn_send_pdu(struct sock *sk, struct sk_buff *skb)
+int llc_conn_send_pdu(struct sock *sk, struct sk_buff *skb)
{
/* queue PDU to send to MAC layer */
skb_queue_tail(&sk->sk_write_queue, skb);
- llc_conn_send_pdus(sk);
+ return llc_conn_send_pdus(sk, skb);
}

/**
@@ -255,7 +255,7 @@ void llc_conn_resend_i_pdu_as_cmd(struct
if (howmany_resend > 0)
llc->vS = (llc->vS + 1) % LLC_2_SEQ_NBR_MODULO;
/* any PDUs to re-send are queued up; start sending to MAC */
- llc_conn_send_pdus(sk);
+ llc_conn_send_pdus(sk, NULL);
out:;
}

@@ -296,7 +296,7 @@ void llc_conn_resend_i_pdu_as_rsp(struct
if (howmany_resend > 0)
llc->vS = (llc->vS + 1) % LLC_2_SEQ_NBR_MODULO;
/* any PDUs to re-send are queued up; start sending to MAC */
- llc_conn_send_pdus(sk);
+ llc_conn_send_pdus(sk, NULL);
out:;
}

@@ -340,12 +340,16 @@ out:
/**
* llc_conn_send_pdus - Sends queued PDUs
* @sk: active connection
+ * @hold_skb: the skb held by caller, or NULL if does not care
*
- * Sends queued pdus to MAC layer for transmission.
+ * Sends queued pdus to MAC layer for transmission. When @hold_skb is
+ * NULL, always return 0. Otherwise, return 0 if @hold_skb is sent
+ * successfully, or 1 for failure.
*/
-static void llc_conn_send_pdus(struct sock *sk)
+static int llc_conn_send_pdus(struct sock *sk, struct sk_buff *hold_skb)
{
struct sk_buff *skb;
+ int ret = 0;

while ((skb = skb_dequeue(&sk->sk_write_queue)) != NULL) {
struct llc_pdu_sn *pdu = llc_pdu_sn_hdr(skb);
@@ -357,10 +361,20 @@ static void llc_conn_send_pdus(struct so
skb_queue_tail(&llc_sk(sk)->pdu_unack_q, skb);
if (!skb2)
break;
- skb = skb2;
+ dev_queue_xmit(skb2);
+ } else {
+ bool is_target = skb == hold_skb;
+ int rc;
+
+ if (is_target)
+ skb_get(skb);
+ rc = dev_queue_xmit(skb);
+ if (is_target)
+ ret = rc;
}
- dev_queue_xmit(skb);
}
+
+ return ret;
}

/**



2018-05-28 15:18:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 153/268] net-usb: add qmi_wwan if on lte modem wistron neweb d18q1

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

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

From: Giuseppe Lippolis <[email protected]>

[ Upstream commit d4c4bc11353f3bea6754f7d21e3612c9f32d1d64 ]

This modem is embedded on dlink dwr-921 router.
The oem configuration states:

T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1435 ProdID=0918 Rev= 2.32
S: Manufacturer=Android
S: Product=Android
S: SerialNumber=0123456789ABCDEF
C:* #Ifs= 7 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=84(I) Atr=03(Int.) MxPS= 64 Ivl=32ms
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E: Ad=86(I) Atr=03(Int.) MxPS= 64 Ivl=32ms
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E: Ad=88(I) Atr=03(Int.) MxPS= 64 Ivl=32ms
E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=32ms
E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=125us

Tested on openwrt distribution

Signed-off-by: Giuseppe Lippolis <[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/usb/qmi_wwan.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -637,6 +637,9 @@ static const struct usb_device_id produc
{QMI_FIXED_INTF(0x0846, 0x68a2, 8)},
{QMI_FIXED_INTF(0x12d1, 0x140c, 1)}, /* Huawei E173 */
{QMI_FIXED_INTF(0x12d1, 0x14ac, 1)}, /* Huawei E1820 */
+ {QMI_FIXED_INTF(0x1435, 0xd181, 3)}, /* Wistron NeWeb D18Q1 */
+ {QMI_FIXED_INTF(0x1435, 0xd181, 4)}, /* Wistron NeWeb D18Q1 */
+ {QMI_FIXED_INTF(0x1435, 0xd181, 5)}, /* Wistron NeWeb D18Q1 */
{QMI_FIXED_INTF(0x16d8, 0x6003, 0)}, /* CMOTech 6003 */
{QMI_FIXED_INTF(0x16d8, 0x6007, 0)}, /* CMOTech CHE-628S */
{QMI_FIXED_INTF(0x16d8, 0x6008, 0)}, /* CMOTech CMU-301 */



2018-05-28 15:19:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 152/268] net/usb/qmi_wwan.c: Add USB id for lt4120 modem

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

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

From: Torsten Hilbrich <[email protected]>

[ Upstream commit f3d801baf118c9d452ee7c278df16880c892e669 ]

This is needed to support the modem found in HP EliteBook 820 G3.

Signed-off-by: Torsten Hilbrich <[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/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -763,6 +763,7 @@ static const struct usb_device_id produc
{QMI_FIXED_INTF(0x413c, 0x81a9, 8)}, /* Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81b1, 8)}, /* Dell Wireless 5809e Gobi(TM) 4G LTE Mobile Broadband Card */
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)}, /* HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module */
+ {QMI_FIXED_INTF(0x03f0, 0x9d1d, 1)}, /* HP lt4120 Snapdragon X5 LTE */
{QMI_FIXED_INTF(0x22de, 0x9061, 3)}, /* WeTelecom WPD-600N */
{QMI_FIXED_INTF(0x1e0e, 0x9001, 5)}, /* SIMCom 7230E */




2018-05-28 15:19:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 150/268] ARM: 8748/1: mm: Define vdso_start, vdso_end as array

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

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

From: Jinbum Park <[email protected]>

[ Upstream commit 73b9160d0dfe44dfdaffd6465dc1224c38a4a73c ]

Define vdso_start, vdso_end as array to avoid compile-time analysis error
for the case of built with CONFIG_FORTIFY_SOURCE.

and, since vdso_start, vdso_end are used in vdso.c only,
move extern-declaration from vdso.h to vdso.c.

If kernel is built with CONFIG_FORTIFY_SOURCE,
compile-time error happens at this code.
- if (memcmp(&vdso_start, "177ELF", 4))

The size of "&vdso_start" is recognized as 1 byte, but n is 4,
So that compile-time error is reported.

Acked-by: Kees Cook <[email protected]>
Signed-off-by: Jinbum Park <[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/include/asm/vdso.h | 2 --
arch/arm/kernel/vdso.c | 12 +++++++-----
2 files changed, 7 insertions(+), 7 deletions(-)

--- a/arch/arm/include/asm/vdso.h
+++ b/arch/arm/include/asm/vdso.h
@@ -11,8 +11,6 @@ struct mm_struct;

void arm_install_vdso(struct mm_struct *mm, unsigned long addr);

-extern char vdso_start, vdso_end;
-
extern unsigned int vdso_total_pages;

#else /* CONFIG_VDSO */
--- a/arch/arm/kernel/vdso.c
+++ b/arch/arm/kernel/vdso.c
@@ -38,6 +38,8 @@

static struct page **vdso_text_pagelist;

+extern char vdso_start[], vdso_end[];
+
/* Total number of pages needed for the data and text portions of the VDSO. */
unsigned int vdso_total_pages __read_mostly;

@@ -178,13 +180,13 @@ static int __init vdso_init(void)
unsigned int text_pages;
int i;

- if (memcmp(&vdso_start, "\177ELF", 4)) {
+ if (memcmp(vdso_start, "\177ELF", 4)) {
pr_err("VDSO is not a valid ELF object!\n");
return -ENOEXEC;
}

- text_pages = (&vdso_end - &vdso_start) >> PAGE_SHIFT;
- pr_debug("vdso: %i text pages at base %p\n", text_pages, &vdso_start);
+ text_pages = (vdso_end - vdso_start) >> PAGE_SHIFT;
+ pr_debug("vdso: %i text pages at base %p\n", text_pages, vdso_start);

/* Allocate the VDSO text pagelist */
vdso_text_pagelist = kcalloc(text_pages, sizeof(struct page *),
@@ -199,7 +201,7 @@ static int __init vdso_init(void)
for (i = 0; i < text_pages; i++) {
struct page *page;

- page = virt_to_page(&vdso_start + i * PAGE_SIZE);
+ page = virt_to_page(vdso_start + i * PAGE_SIZE);
vdso_text_pagelist[i] = page;
}

@@ -210,7 +212,7 @@ static int __init vdso_init(void)

cntvct_ok = cntvct_functional();

- patch_vdso(&vdso_start);
+ patch_vdso(vdso_start);

return 0;
}



2018-05-28 15:19:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 177/268] rtc: snvs: Fix usage of snvs_rtc_enable

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

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

From: Bryan O'Donoghue <[email protected]>

[ Upstream commit 1485991c024603b2fb4ae77beb7a0d741128a48e ]

commit 179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver") introduces
the SNVS RTC driver with a function snvs_rtc_enable().

snvs_rtc_enable() can return an error on the enable path however this
driver does not currently trap that failure on the probe() path and
consequently if enabling the RTC fails we encounter a later error spinning
forever in rtc_write_sync_lp().

[ 36.093481] [<c010d630>] (__irq_svc) from [<c0c2e9ec>] (_raw_spin_unlock_irqrestore+0x34/0x44)
[ 36.102122] [<c0c2e9ec>] (_raw_spin_unlock_irqrestore) from [<c072e32c>] (regmap_read+0x4c/0x5c)
[ 36.110938] [<c072e32c>] (regmap_read) from [<c085d0f4>] (rtc_write_sync_lp+0x6c/0x98)
[ 36.118881] [<c085d0f4>] (rtc_write_sync_lp) from [<c085d160>] (snvs_rtc_alarm_irq_enable+0x40/0x4c)
[ 36.128041] [<c085d160>] (snvs_rtc_alarm_irq_enable) from [<c08567b4>] (rtc_timer_do_work+0xd8/0x1a8)
[ 36.137291] [<c08567b4>] (rtc_timer_do_work) from [<c01441b8>] (process_one_work+0x28c/0x76c)
[ 36.145840] [<c01441b8>] (process_one_work) from [<c01446cc>] (worker_thread+0x34/0x58c)
[ 36.153961] [<c01446cc>] (worker_thread) from [<c014aee4>] (kthread+0x138/0x150)
[ 36.161388] [<c014aee4>] (kthread) from [<c0107e14>] (ret_from_fork+0x14/0x20)
[ 36.168635] rcu_sched kthread starved for 2602 jiffies! g496 c495 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
[ 36.178564] rcu_sched R running task 0 8 2 0x00000000
[ 36.185664] [<c0c288b0>] (__schedule) from [<c0c29134>] (schedule+0x3c/0xa0)
[ 36.192739] [<c0c29134>] (schedule) from [<c0c2db80>] (schedule_timeout+0x78/0x4e0)
[ 36.200422] [<c0c2db80>] (schedule_timeout) from [<c01a7ab0>] (rcu_gp_kthread+0x648/0x1864)
[ 36.208800] [<c01a7ab0>] (rcu_gp_kthread) from [<c014aee4>] (kthread+0x138/0x150)
[ 36.216309] [<c014aee4>] (kthread) from [<c0107e14>] (ret_from_fork+0x14/0x20)

This patch fixes by parsing the result of rtc_write_sync_lp() and
propagating both in the probe and elsewhere. If the RTC doesn't start we
don't proceed loading the driver and don't get into this loop mess later
on.

Fixes: 179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver")
Signed-off-by: Bryan O'Donoghue <[email protected]>
Acked-by: Shawn Guo <[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-snvs.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)

--- a/drivers/rtc/rtc-snvs.c
+++ b/drivers/rtc/rtc-snvs.c
@@ -132,20 +132,23 @@ static int snvs_rtc_set_time(struct devi
{
struct snvs_rtc_data *data = dev_get_drvdata(dev);
unsigned long time;
+ int ret;

rtc_tm_to_time(tm, &time);

/* Disable RTC first */
- snvs_rtc_enable(data, false);
+ ret = snvs_rtc_enable(data, false);
+ if (ret)
+ return ret;

/* Write 32-bit time to 47-bit timer, leaving 15 LSBs blank */
regmap_write(data->regmap, data->offset + SNVS_LPSRTCLR, time << CNTR_TO_SECS_SH);
regmap_write(data->regmap, data->offset + SNVS_LPSRTCMR, time >> (32 - CNTR_TO_SECS_SH));

/* Enable RTC again */
- snvs_rtc_enable(data, true);
+ ret = snvs_rtc_enable(data, true);

- return 0;
+ return ret;
}

static int snvs_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
@@ -287,7 +290,11 @@ static int snvs_rtc_probe(struct platfor
regmap_write(data->regmap, data->offset + SNVS_LPSR, 0xffffffff);

/* Enable RTC */
- snvs_rtc_enable(data, true);
+ ret = snvs_rtc_enable(data, true);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to enable rtc %d\n", ret);
+ goto error_rtc_device_register;
+ }

device_init_wakeup(&pdev->dev, true);




2018-05-28 15:19:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 180/268] btrfs: tests/qgroup: Fix wrong tree backref level

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

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

From: Qu Wenruo <[email protected]>

[ Upstream commit 3c0efdf03b2d127f0e40e30db4e7aa0429b1b79a ]

The extent tree of the test fs is like the following:

BTRFS info (device (null)): leaf 16327509003777336587 total ptrs 1 free space 3919
item 0 key (4096 168 4096) itemoff 3944 itemsize 51
extent refs 1 gen 1 flags 2
tree block key (68719476736 0 0) level 1
^^^^^^^
ref#0: tree block backref root 5

And it's using an empty tree for fs tree, so there is no way that its
level can be 1.

For REAL (created by mkfs) fs tree backref with no skinny metadata, the
result should look like:

item 3 key (30408704 EXTENT_ITEM 4096) itemoff 3845 itemsize 51
refs 1 gen 4 flags TREE_BLOCK
tree block key (256 INODE_ITEM 0) level 0
^^^^^^^
tree block backref root 5

Fix the level to 0, so it won't break later tree level checker.

Fixes: faa2dbf004e8 ("Btrfs: add sanity tests for new qgroup accounting code")
Signed-off-by: Qu Wenruo <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/tests/qgroup-tests.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/btrfs/tests/qgroup-tests.c
+++ b/fs/btrfs/tests/qgroup-tests.c
@@ -70,7 +70,7 @@ static int insert_normal_tree_ref(struct
btrfs_set_extent_generation(leaf, item, 1);
btrfs_set_extent_flags(leaf, item, BTRFS_EXTENT_FLAG_TREE_BLOCK);
block_info = (struct btrfs_tree_block_info *)(item + 1);
- btrfs_set_tree_block_level(leaf, block_info, 1);
+ btrfs_set_tree_block_level(leaf, block_info, 0);
iref = (struct btrfs_extent_inline_ref *)(block_info + 1);
if (parent > 0) {
btrfs_set_extent_inline_ref_type(leaf, iref,



2018-05-28 15:20:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 179/268] Bluetooth: btusb: Add USB ID 7392:a611 for Edimax EW-7611ULB

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

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

From: Vicente Bergas <[email protected]>

[ Upstream commit a41e0796396eeceff673af4a38feaee149c6ff86 ]

This WiFi/Bluetooth USB dongle uses a Realtek chipset, so, use btrtl for it.

Product information:
https://wikidevi.com/wiki/Edimax_EW-7611ULB

>From /sys/kernel/debug/usb/devices
T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=7392 ProdID=a611 Rev= 2.00
S: Manufacturer=Realtek
S: Product=Edimax Wi-Fi N150 Bluetooth4.0 USB Adapter
S: SerialNumber=00e04c000001
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 6 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtl8723bu
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=500us
E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Tested-by: Vicente Bergas <[email protected]>
Signed-off-by: Vicente Bergas <[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/btusb.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -336,6 +336,9 @@ static const struct usb_device_id blackl
{ USB_DEVICE(0x13d3, 0x3459), .driver_info = BTUSB_REALTEK },
{ USB_DEVICE(0x13d3, 0x3494), .driver_info = BTUSB_REALTEK },

+ /* Additional Realtek 8723BU Bluetooth devices */
+ { USB_DEVICE(0x7392, 0xa611), .driver_info = BTUSB_REALTEK },
+
/* Additional Realtek 8821AE Bluetooth devices */
{ USB_DEVICE(0x0b05, 0x17dc), .driver_info = BTUSB_REALTEK },
{ USB_DEVICE(0x13d3, 0x3414), .driver_info = BTUSB_REALTEK },



2018-05-28 15:20:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 173/268] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

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

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

From: Davidlohr Bueso <[email protected]>

[ Upstream commit d29a20645d5e929aa7e8616f28e5d8e1c49263ec ]

While running rt-tests' pi_stress program I got the following splat:

rq->clock_update_flags < RQCF_ACT_SKIP
WARNING: CPU: 27 PID: 0 at kernel/sched/sched.h:960 assert_clock_updated.isra.38.part.39+0x13/0x20

[...]

<IRQ>
enqueue_top_rt_rq+0xf4/0x150
? cpufreq_dbs_governor_start+0x170/0x170
sched_rt_rq_enqueue+0x65/0x80
sched_rt_period_timer+0x156/0x360
? sched_rt_rq_enqueue+0x80/0x80
__hrtimer_run_queues+0xfa/0x260
hrtimer_interrupt+0xcb/0x220
smp_apic_timer_interrupt+0x62/0x120
apic_timer_interrupt+0xf/0x20
</IRQ>

[...]

do_idle+0x183/0x1e0
cpu_startup_entry+0x5f/0x70
start_secondary+0x192/0x1d0
secondary_startup_64+0xa5/0xb0

We can get rid of it be the "traditional" means of adding an
update_rq_clock() call after acquiring the rq->lock in
do_sched_rt_period_timer().

The case for the RT task throttling (which this workload also hits)
can be ignored in that the skip_update call is actually bogus and
quite the contrary (the request bits are removed/reverted).

By setting RQCF_UPDATED we really don't care if the skip is happening
or not and will therefore make the assert_clock_updated() check happy.

Signed-off-by: Davidlohr Bueso <[email protected]>
Reviewed-by: Matt Fleming <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Mike Galbraith <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/sched/rt.c | 2 ++
1 file changed, 2 insertions(+)

--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -822,6 +822,8 @@ static int do_sched_rt_period_timer(stru
struct rq *rq = rq_of_rt_rq(rt_rq);

raw_spin_lock(&rq->lock);
+ update_rq_clock(rq);
+
if (rt_rq->rt_time) {
u64 runtime;




2018-05-28 15:20:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 172/268] ocfs2/dlm: dont handle migrate lockres if already in shutdown

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

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

From: Jun Piao <[email protected]>

[ Upstream commit bb34f24c7d2c98d0c81838a7700e6068325b17a0 ]

We should not handle migrate lockres if we are already in
'DLM_CTXT_IN_SHUTDOWN', as that will cause lockres remains after leaving
dlm domain. At last other nodes will get stuck into infinite loop when
requsting lock from us.

The problem is caused by concurrency umount between nodes. Before
receiveing N1's DLM_BEGIN_EXIT_DOMAIN_MSG, N2 has picked up N1 as the
migrate target. So N2 will continue sending lockres to N1 even though
N1 has left domain.

N1 N2 (owner)
touch file

access the file,
and get pr lock

begin leave domain and
pick up N1 as new owner

begin leave domain and
migrate all lockres done

begin migrate lockres to N1

end leave domain, but
the lockres left
unexpectedly, because
migrate task has passed

[[email protected]: v3]
Link: http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Jun Piao <[email protected]>
Reviewed-by: Yiwen Jiang <[email protected]>
Reviewed-by: Joseph Qi <[email protected]>
Reviewed-by: Changwei Ge <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Joel Becker <[email protected]>
Cc: Junxiao Bi <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ocfs2/dlm/dlmdomain.c | 14 --------------
fs/ocfs2/dlm/dlmdomain.h | 25 ++++++++++++++++++++++++-
fs/ocfs2/dlm/dlmrecovery.c | 9 +++++++++
3 files changed, 33 insertions(+), 15 deletions(-)

--- a/fs/ocfs2/dlm/dlmdomain.c
+++ b/fs/ocfs2/dlm/dlmdomain.c
@@ -674,20 +674,6 @@ static void dlm_leave_domain(struct dlm_
spin_unlock(&dlm->spinlock);
}

-int dlm_shutting_down(struct dlm_ctxt *dlm)
-{
- int ret = 0;
-
- spin_lock(&dlm_domain_lock);
-
- if (dlm->dlm_state == DLM_CTXT_IN_SHUTDOWN)
- ret = 1;
-
- spin_unlock(&dlm_domain_lock);
-
- return ret;
-}
-
void dlm_unregister_domain(struct dlm_ctxt *dlm)
{
int leave = 0;
--- a/fs/ocfs2/dlm/dlmdomain.h
+++ b/fs/ocfs2/dlm/dlmdomain.h
@@ -28,7 +28,30 @@
extern spinlock_t dlm_domain_lock;
extern struct list_head dlm_domains;

-int dlm_shutting_down(struct dlm_ctxt *dlm);
+static inline int dlm_joined(struct dlm_ctxt *dlm)
+{
+ int ret = 0;
+
+ spin_lock(&dlm_domain_lock);
+ if (dlm->dlm_state == DLM_CTXT_JOINED)
+ ret = 1;
+ spin_unlock(&dlm_domain_lock);
+
+ return ret;
+}
+
+static inline int dlm_shutting_down(struct dlm_ctxt *dlm)
+{
+ int ret = 0;
+
+ spin_lock(&dlm_domain_lock);
+ if (dlm->dlm_state == DLM_CTXT_IN_SHUTDOWN)
+ ret = 1;
+ spin_unlock(&dlm_domain_lock);
+
+ return ret;
+}
+
void dlm_fire_domain_eviction_callbacks(struct dlm_ctxt *dlm,
int node_num);

--- a/fs/ocfs2/dlm/dlmrecovery.c
+++ b/fs/ocfs2/dlm/dlmrecovery.c
@@ -1377,6 +1377,15 @@ int dlm_mig_lockres_handler(struct o2net
if (!dlm_grab(dlm))
return -EINVAL;

+ if (!dlm_joined(dlm)) {
+ mlog(ML_ERROR, "Domain %s not joined! "
+ "lockres %.*s, master %u\n",
+ dlm->name, mres->lockname_len,
+ mres->lockname, mres->master);
+ dlm_put(dlm);
+ return -EINVAL;
+ }
+
BUG_ON(!(mres->flags & (DLM_MRES_RECOVERY|DLM_MRES_MIGRATION)));

real_master = mres->master;



2018-05-28 15:20:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 170/268] Btrfs: fix NULL pointer dereference in log_dir_items

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

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

From: Liu Bo <[email protected]>

[ Upstream commit 80c0b4210a963e31529e15bf90519708ec947596 ]

0, 1 and <0 can be returned by btrfs_next_leaf(), and when <0 is
returned, path->nodes[0] could be NULL, log_dir_items lacks such a
check for <0 and we may run into a null pointer dereference panic.

Fixes: e02119d5a7b4 ("Btrfs: Add a write ahead tree log to optimize synchronous operations")
Reviewed-by: Nikolay Borisov <[email protected]>
Signed-off-by: Liu Bo <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/tree-log.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -3380,8 +3380,11 @@ static noinline int log_dir_items(struct
* from this directory and from this transaction
*/
ret = btrfs_next_leaf(root, path);
- if (ret == 1) {
- last_offset = (u64)-1;
+ if (ret) {
+ if (ret == 1)
+ last_offset = (u64)-1;
+ else
+ err = ret;
goto done;
}
btrfs_item_key_to_cpu(path->nodes[0], &tmp, path->slots[0]);



2018-05-28 15:21:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 165/268] scsi: aacraid: Insure command thread is not recursively stopped

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

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

From: Dave Carroll <[email protected]>

[ Upstream commit 1c6b41fb92936fa5facea464d5d7cbf855966d04 ]

If a recursive IOP_RESET is invoked, usually due to the eh_thread
handling errors after the first reset, be sure we flag that the command
thread has been stopped to avoid an Oops of the form;

[ 336.620256] CPU: 28 PID: 1193 Comm: scsi_eh_0 Kdump: loaded Not tainted 4.14.0-49.el7a.ppc64le #1
[ 336.620297] task: c000003fd630b800 task.stack: c000003fd61a4000
[ 336.620326] NIP: c000000000176794 LR: c00000000013038c CTR: c00000000024bc10
[ 336.620361] REGS: c000003fd61a7720 TRAP: 0300 Not tainted (4.14.0-49.el7a.ppc64le)
[ 336.620395] MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 22084022 XER: 20040000
[ 336.620435] CFAR: c000000000130388 DAR: 0000000000000000 DSISR: 40000000 SOFTE: 1
[ 336.620435] GPR00: c00000000013038c c000003fd61a79a0 c0000000014c7e00 0000000000000000
[ 336.620435] GPR04: 000000000000000c 000000000000000c 9000000000009033 0000000000000477
[ 336.620435] GPR08: 0000000000000477 0000000000000000 0000000000000000 c008000010f7d940
[ 336.620435] GPR12: c00000000024bc10 c000000007a33400 c0000000001708a8 c000003fe3b881d8
[ 336.620435] GPR16: c000003fe3b88060 c000003fd61a7d10 fffffffffffff000 000000000000001e
[ 336.620435] GPR20: 0000000000000001 c000000000ebf1a0 0000000000000001 c000003fe3b88000
[ 336.620435] GPR24: 0000000000000003 0000000000000002 c000003fe3b88840 c000003fe3b887e8
[ 336.620435] GPR28: c000003fe3b88000 c000003fc8181788 0000000000000000 c000003fc8181700
[ 336.620750] NIP [c000000000176794] exit_creds+0x34/0x160
[ 336.620775] LR [c00000000013038c] __put_task_struct+0x8c/0x1f0
[ 336.620804] Call Trace:
[ 336.620817] [c000003fd61a79a0] [c000003fe3b88000] 0xc000003fe3b88000 (unreliable)
[ 336.620853] [c000003fd61a79d0] [c00000000013038c] __put_task_struct+0x8c/0x1f0
[ 336.620889] [c000003fd61a7a00] [c000000000171418] kthread_stop+0x1e8/0x1f0
[ 336.620922] [c000003fd61a7a40] [c008000010f7448c] aac_reset_adapter+0x14c/0x8d0 [aacraid]
[ 336.620959] [c000003fd61a7b00] [c008000010f60174] aac_eh_host_reset+0x84/0x100 [aacraid]
[ 336.621010] [c000003fd61a7b30] [c000000000864f24] scsi_try_host_reset+0x74/0x180
[ 336.621046] [c000003fd61a7bb0] [c000000000867ac0] scsi_eh_ready_devs+0xc00/0x14d0
[ 336.625165] [c000003fd61a7ca0] [c0000000008699e0] scsi_error_handler+0x550/0x730
[ 336.632101] [c000003fd61a7dc0] [c000000000170a08] kthread+0x168/0x1b0
[ 336.639031] [c000003fd61a7e30] [c00000000000b528] ret_from_kernel_thread+0x5c/0xb4
[ 336.645971] Instruction dump:
[ 336.648743] 384216a0 7c0802a6 fbe1fff8 f8010010 f821ffd1 7c7f1b78 60000000 60000000
[ 336.657056] 39400000 e87f0838 f95f0838 7c0004ac <7d401828> 314affff 7d40192d 40c2fff4
[ 336.663997] -[ end trace 4640cf8d4945ad95 ]-

So flag when the thread is stopped by setting the thread pointer to NULL.

Signed-off-by: Dave Carroll <[email protected]>
Reviewed-by: Raghava Aditya Renukunta <[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/aacraid/commsup.c | 4 +++-
drivers/scsi/aacraid/linit.c | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/scsi/aacraid/commsup.c
+++ b/drivers/scsi/aacraid/commsup.c
@@ -1321,9 +1321,10 @@ static int _aac_reset_adapter(struct aac
host = aac->scsi_host_ptr;
scsi_block_requests(host);
aac_adapter_disable_int(aac);
- if (aac->thread->pid != current->pid) {
+ if (aac->thread && aac->thread->pid != current->pid) {
spin_unlock_irq(host->host_lock);
kthread_stop(aac->thread);
+ aac->thread = NULL;
jafo = 1;
}

@@ -1392,6 +1393,7 @@ static int _aac_reset_adapter(struct aac
aac->name);
if (IS_ERR(aac->thread)) {
retval = PTR_ERR(aac->thread);
+ aac->thread = NULL;
goto out;
}
}
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -1085,6 +1085,7 @@ static void __aac_shutdown(struct aac_de
up(&fib->event_wait);
}
kthread_stop(aac->thread);
+ aac->thread = NULL;
}
aac_send_shutdown(aac);
aac_adapter_disable_int(aac);



2018-05-28 15:21:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 175/268] fscache: Fix hanging wait on page discarded by writeback

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

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

From: David Howells <[email protected]>

[ Upstream commit 2c98425720233ae3e135add0c7e869b32913502f ]

If the fscache asynchronous write operation elects to discard a page that's
pending storage to the cache because the page would be over the store limit
then it needs to wake the page as someone may be waiting on completion of
the write.

The problem is that the store limit may be updated by a different
asynchronous operation - and so may miss the write - and that the store
limit may not even get updated until later by the netfs.

Fix the kernel hang by making fscache_write_op() mark as written any pages
that are over the limit.

Signed-off-by: David Howells <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/fscache/page.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)

--- a/fs/fscache/page.c
+++ b/fs/fscache/page.c
@@ -776,6 +776,7 @@ static void fscache_write_op(struct fsca

_enter("{OP%x,%d}", op->op.debug_id, atomic_read(&op->op.usage));

+again:
spin_lock(&object->lock);
cookie = object->cookie;

@@ -816,10 +817,6 @@ static void fscache_write_op(struct fsca
goto superseded;
page = results[0];
_debug("gang %d [%lx]", n, page->index);
- if (page->index >= op->store_limit) {
- fscache_stat(&fscache_n_store_pages_over_limit);
- goto superseded;
- }

radix_tree_tag_set(&cookie->stores, page->index,
FSCACHE_COOKIE_STORING_TAG);
@@ -829,6 +826,9 @@ static void fscache_write_op(struct fsca
spin_unlock(&cookie->stores_lock);
spin_unlock(&object->lock);

+ if (page->index >= op->store_limit)
+ goto discard_page;
+
fscache_stat(&fscache_n_store_pages);
fscache_stat(&fscache_n_cop_write_page);
ret = object->cache->ops->write_page(op, page);
@@ -844,6 +844,11 @@ static void fscache_write_op(struct fsca
_leave("");
return;

+discard_page:
+ fscache_stat(&fscache_n_store_pages_over_limit);
+ fscache_end_page_write(object, page);
+ goto again;
+
superseded:
/* this writer is going away and there aren't any more things to
* write */



2018-05-28 15:21:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 164/268] cpufreq: CPPC: Initialize shared perf capabilities of CPUs

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

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

From: Shunyong Yang <[email protected]>

[ Upstream commit 8913315e9459b146e5888ab5138e10daa061b885 ]

When multiple CPUs are related in one cpufreq policy, the first online
CPU will be chosen by default to handle cpufreq operations. Let's take
cpu0 and cpu1 as an example.

When cpu0 is offline, policy->cpu will be shifted to cpu1. cpu1's perf
capabilities should be initialized. Otherwise, perf capabilities are 0s
and speed change can not take effect.

This patch copies perf capabilities of the first online CPU to other
shared CPUs when policy shared type is CPUFREQ_SHARED_TYPE_ANY.

Acked-by: Viresh Kumar <[email protected]>
Signed-off-by: Shunyong Yang <[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/cpufreq/cppc_cpufreq.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)

--- a/drivers/cpufreq/cppc_cpufreq.c
+++ b/drivers/cpufreq/cppc_cpufreq.c
@@ -100,9 +100,19 @@ static int cppc_cpufreq_cpu_init(struct
policy->cpuinfo.max_freq = policy->max;
policy->shared_type = cpu->shared_type;

- if (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
+ if (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) {
+ int i;
+
cpumask_copy(policy->cpus, cpu->shared_cpu_map);
- else if (policy->shared_type == CPUFREQ_SHARED_TYPE_ALL) {
+
+ for_each_cpu(i, policy->cpus) {
+ if (unlikely(i == policy->cpu))
+ continue;
+
+ memcpy(&all_cpu_data[i]->perf_caps, &cpu->perf_caps,
+ sizeof(cpu->perf_caps));
+ }
+ } else if (policy->shared_type == CPUFREQ_SHARED_TYPE_ALL) {
/* Support only SW_ANY for now. */
pr_debug("Unsupported CPU co-ord type\n");
return -EFAULT;



2018-05-28 15:21:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 168/268] mm: fix races between address_space dereference and free in page_evicatable

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

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

From: Huang Ying <[email protected]>

[ Upstream commit e92bb4dd9673945179b1fc738c9817dd91bfb629 ]

When page_mapping() is called and the mapping is dereferenced in
page_evicatable() through shrink_active_list(), it is possible for the
inode to be truncated and the embedded address space to be freed at the
same time. This may lead to the following race.

CPU1 CPU2

truncate(inode) shrink_active_list()
... page_evictable(page)
truncate_inode_page(mapping, page);
delete_from_page_cache(page)
spin_lock_irqsave(&mapping->tree_lock, flags);
__delete_from_page_cache(page, NULL)
page_cache_tree_delete(..)
... mapping = page_mapping(page);
page->mapping = NULL;
...
spin_unlock_irqrestore(&mapping->tree_lock, flags);
page_cache_free_page(mapping, page)
put_page(page)
if (put_page_testzero(page)) -> false
- inode now has no pages and can be freed including embedded address_space

mapping_unevictable(mapping)
test_bit(AS_UNEVICTABLE, &mapping->flags);
- we've dereferenced mapping which is potentially already free.

Similar race exists between swap cache freeing and page_evicatable()
too.

The address_space in inode and swap cache will be freed after a RCU
grace period. So the races are fixed via enclosing the page_mapping()
and address_space usage in rcu_read_lock/unlock(). Some comments are
added in code to make it clear what is protected by the RCU read lock.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: "Huang, Ying" <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Minchan Kim <[email protected]>
Cc: "Huang, Ying" <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/vmscan.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3841,7 +3841,13 @@ int zone_reclaim(struct zone *zone, gfp_
*/
int page_evictable(struct page *page)
{
- return !mapping_unevictable(page_mapping(page)) && !PageMlocked(page);
+ int ret;
+
+ /* Prevent address_space of inode and swap cache from being freed */
+ rcu_read_lock();
+ ret = !mapping_unevictable(page_mapping(page)) && !PageMlocked(page);
+ rcu_read_unlock();
+ return ret;
}

#ifdef CONFIG_SHMEM



2018-05-28 15:21:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 167/268] mm/ksm: fix interaction with THP

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

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

From: Claudio Imbrenda <[email protected]>

[ Upstream commit 77da2ba0648a4fd52e5ff97b8b2b8dd312aec4b0 ]

This patch fixes a corner case for KSM. When two pages belong or
belonged to the same transparent hugepage, and they should be merged,
KSM fails to split the page, and therefore no merging happens.

This bug can be reproduced by:
* making sure ksm is running (in case disabling ksmtuned)
* enabling transparent hugepages
* allocating a THP-aligned 1-THP-sized buffer
e.g. on amd64: posix_memalign(&p, 1<<21, 1<<21)
* filling it with the same values
e.g. memset(p, 42, 1<<21)
* performing madvise to make it mergeable
e.g. madvise(p, 1<<21, MADV_MERGEABLE)
* waiting for KSM to perform a few scans

The expected outcome is that the all the pages get merged (1 shared and
the rest sharing); the actual outcome is that no pages get merged (1
unshared and the rest volatile)

The reason of this behaviour is that we increase the reference count
once for both pages we want to merge, but if they belong to the same
hugepage (or compound page), the reference counter used in both cases is
the one of the head of the compound page. This means that
split_huge_page will find a value of the reference counter too high and
will fail.

This patch solves this problem by testing if the two pages to merge
belong to the same hugepage when attempting to merge them. If so, the
hugepage is split safely. This means that the hugepage is not split if
not necessary.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Claudio Imbrenda <[email protected]>
Co-authored-by: Gerald Schaefer <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Cc: Andrea Arcangeli <[email protected]>
Cc: Minchan Kim <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Christian Borntraeger <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/ksm.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)

--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1494,8 +1494,22 @@ static void cmp_and_merge_page(struct pa
tree_rmap_item =
unstable_tree_search_insert(rmap_item, page, &tree_page);
if (tree_rmap_item) {
+ bool split;
+
kpage = try_to_merge_two_pages(rmap_item, page,
tree_rmap_item, tree_page);
+ /*
+ * If both pages we tried to merge belong to the same compound
+ * page, then we actually ended up increasing the reference
+ * count of the same compound page twice, and split_huge_page
+ * failed.
+ * Here we set a flag if that happened, and we use it later to
+ * try split_huge_page again. Since we call put_page right
+ * afterwards, the reference count will be correct and
+ * split_huge_page should succeed.
+ */
+ split = PageTransCompound(page)
+ && compound_head(page) == compound_head(tree_page);
put_page(tree_page);
if (kpage) {
/*
@@ -1520,6 +1534,20 @@ static void cmp_and_merge_page(struct pa
break_cow(tree_rmap_item);
break_cow(rmap_item);
}
+ } else if (split) {
+ /*
+ * We are here if we tried to merge two pages and
+ * failed because they both belonged to the same
+ * compound page. We will split the page now, but no
+ * merging will take place.
+ * We do not want to add the cost of a full lock; if
+ * the page is locked, it is better to skip it and
+ * perhaps try again later.
+ */
+ if (!trylock_page(page))
+ return;
+ split_huge_page(page);
+ unlock_page(page);
}
}
}



2018-05-28 15:21:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 147/268] selftests: ftrace: Add a testcase for probepoint

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

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

From: Masami Hiramatsu <[email protected]>

[ Upstream commit dfa453bc90eca0febff33c8d292a656e53702158 ]

Add a testcase for probe point definition. This tests
symbol, address and symbol+offset syntax. The offset
must be positive and smaller than UINT_MAX.

Link: http://lkml.kernel.org/r/152129043097.31874.14273580606301767394.stgit@devbox

Signed-off-by: Masami Hiramatsu <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/testing/selftests/ftrace/test.d/kprobe/probepoint.tc | 43 +++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 tools/testing/selftests/ftrace/test.d/kprobe/probepoint.tc

--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/probepoint.tc
@@ -0,0 +1,43 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+# description: Kprobe events - probe points
+
+[ -f kprobe_events ] || exit_unsupported # this is configurable
+
+TARGET_FUNC=create_trace_kprobe
+
+dec_addr() { # hexaddr
+ printf "%d" "0x"`echo $1 | tail -c 8`
+}
+
+set_offs() { # prev target next
+ A1=`dec_addr $1`
+ A2=`dec_addr $2`
+ A3=`dec_addr $3`
+ TARGET="0x$2" # an address
+ PREV=`expr $A1 - $A2` # offset to previous symbol
+ NEXT=+`expr $A3 - $A2` # offset to next symbol
+ OVERFLOW=+`printf "0x%x" ${PREV}` # overflow offset to previous symbol
+}
+
+# We have to decode symbol addresses to get correct offsets.
+# If the offset is not an instruction boundary, it cause -EILSEQ.
+set_offs `grep -A1 -B1 ${TARGET_FUNC} /proc/kallsyms | cut -f 1 -d " " | xargs`
+
+UINT_TEST=no
+# printf "%x" -1 returns (unsigned long)-1.
+if [ `printf "%x" -1 | wc -c` != 9 ]; then
+ UINT_TEST=yes
+fi
+
+echo 0 > events/enable
+echo > kprobe_events
+echo "p:testprobe ${TARGET_FUNC}" > kprobe_events
+echo "p:testprobe ${TARGET}" > kprobe_events
+echo "p:testprobe ${TARGET_FUNC}${NEXT}" > kprobe_events
+! echo "p:testprobe ${TARGET_FUNC}${PREV}" > kprobe_events
+if [ "${UINT_TEST}" = yes ]; then
+! echo "p:testprobe ${TARGET_FUNC}${OVERFLOW}" > kprobe_events
+fi
+echo > kprobe_events
+clear_trace



2018-05-28 15:22:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 169/268] Btrfs: bail out on error during replay_dir_deletes

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

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

From: Liu Bo <[email protected]>

[ Upstream commit b98def7ca6e152ee55e36863dddf6f41f12d1dc6 ]

If errors were returned by btrfs_next_leaf(), replay_dir_deletes needs
to bail out, otherwise @ret would be forced to be 0 after 'break;' and
the caller won't be aware of it.

Fixes: e02119d5a7b4 ("Btrfs: Add a write ahead tree log to optimize synchronous operations")
Reviewed-by: Nikolay Borisov <[email protected]>
Signed-off-by: Liu Bo <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/tree-log.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -2223,8 +2223,10 @@ again:
nritems = btrfs_header_nritems(path->nodes[0]);
if (path->slots[0] >= nritems) {
ret = btrfs_next_leaf(root, path);
- if (ret)
+ if (ret == 1)
break;
+ else if (ret < 0)
+ goto out;
}
btrfs_item_key_to_cpu(path->nodes[0], &found_key,
path->slots[0]);



2018-05-28 15:22:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 161/268] swap: divide-by-zero when zero length swap file on ssd

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

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

From: Tom Abraham <[email protected]>

[ Upstream commit a06ad633a37c64a0cd4c229fc605cee8725d376e ]

Calling swapon() on a zero length swap file on SSD can lead to a
divide-by-zero.

Although creating such files isn't possible with mkswap and they woud be
considered invalid, it would be better for the swapon code to be more
robust and handle this condition gracefully (return -EINVAL).
Especially since the fix is small and straightforward.

To help with wear leveling on SSD, the swapon syscall calculates a
random position in the swap file using modulo p->highest_bit, which is
set to maxpages - 1 in read_swap_header.

If the swap file is zero length, read_swap_header sets maxpages=1 and
last_page=0, resulting in p->highest_bit=0 and we divide-by-zero when we
modulo p->highest_bit in swapon syscall.

This can be prevented by having read_swap_header return zero if
last_page is zero.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Abraham <[email protected]>
Reported-by: <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Cc: Randy Dunlap <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/swapfile.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -2258,6 +2258,10 @@ static unsigned long read_swap_header(st
maxpages = swp_offset(pte_to_swp_entry(
swp_entry_to_pte(swp_entry(0, ~0UL)))) + 1;
last_page = swap_header->info.last_page;
+ if (!last_page) {
+ pr_warn("Empty swap-file\n");
+ return 0;
+ }
if (last_page > maxpages) {
pr_warn("Truncating oversized swap area, only using %luk out of %luk\n",
maxpages << (PAGE_SHIFT - 10),



2018-05-28 15:22:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 163/268] Force log to disk before reading the AGF during a fstrim

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

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

From: Carlos Maiolino <[email protected]>

[ Upstream commit 8c81dd46ef3c416b3b95e3020fb90dbd44e6140b ]

Forcing the log to disk after reading the agf is wrong, we might be
calling xfs_log_force with XFS_LOG_SYNC with a metadata lock held.

This can cause a deadlock when racing a fstrim with a filesystem
shutdown.

The deadlock has been identified due a miscalculation bug in device-mapper
dm-thin, which returns lack of space to its users earlier than the device itself
really runs out of space, changing the device-mapper volume into an error state.

The problem happened while filling the filesystem with a single file,
triggering the bug in device-mapper, consequently causing an IO error
and shutting down the filesystem.

If such file is removed, and fstrim executed before the XFS finishes the
shut down process, the fstrim process will end up holding the buffer
lock, and going to sleep on the cil wait queue.

At this point, the shut down process will try to wake up all the threads
waiting on the cil wait queue, but for this, it will try to hold the
same buffer log already held my the fstrim, locking up the filesystem.

Signed-off-by: Carlos Maiolino <[email protected]>
Reviewed-by: Darrick J. Wong <[email protected]>
Signed-off-by: Darrick J. Wong <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/xfs/xfs_discard.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)

--- a/fs/xfs/xfs_discard.c
+++ b/fs/xfs/xfs_discard.c
@@ -50,19 +50,19 @@ xfs_trim_extents(

pag = xfs_perag_get(mp, agno);

- error = xfs_alloc_read_agf(mp, NULL, agno, 0, &agbp);
- if (error || !agbp)
- goto out_put_perag;
-
- cur = xfs_allocbt_init_cursor(mp, NULL, agbp, agno, XFS_BTNUM_CNT);
-
/*
* Force out the log. This means any transactions that might have freed
- * space before we took the AGF buffer lock are now on disk, and the
+ * space before we take the AGF buffer lock are now on disk, and the
* volatile disk cache is flushed.
*/
xfs_log_force(mp, XFS_LOG_SYNC);

+ error = xfs_alloc_read_agf(mp, NULL, agno, 0, &agbp);
+ if (error || !agbp)
+ goto out_put_perag;
+
+ cur = xfs_allocbt_init_cursor(mp, NULL, agbp, agno, XFS_BTNUM_CNT);
+
/*
* Look up the longest btree in the AGF and start with it.
*/



2018-05-28 15:23:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 158/268] sh: fix debug trap failure to process signals before return to user

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

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

From: Rich Felker <[email protected]>

[ Upstream commit 96a598996f6ac518ac79839ecbb17c91af91f4f7 ]

When responding to a debug trap (breakpoint) in userspace, the
kernel's trap handler raised SIGTRAP but returned from the trap via a
code path that ignored pending signals, resulting in an infinite loop
re-executing the trapping instruction.

Signed-off-by: Rich Felker <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/sh/kernel/entry-common.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/sh/kernel/entry-common.S
+++ b/arch/sh/kernel/entry-common.S
@@ -255,7 +255,7 @@ debug_trap:
mov.l @r8, r8
jsr @r8
nop
- bra __restore_all
+ bra ret_from_exception
nop
CFI_ENDPROC




2018-05-28 15:23:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 159/268] x86/pgtable: Dont set huge PUD/PMD on non-leaf entries

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

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

From: Joerg Roedel <[email protected]>

[ Upstream commit e3e288121408c3abeed5af60b87b95c847143845 ]

The pmd_set_huge() and pud_set_huge() functions are used from
the generic ioremap() code to establish large mappings where this
is possible.

But the generic ioremap() code does not check whether the
PMD/PUD entries are already populated with a non-leaf entry,
so that any page-table pages these entries point to will be
lost.

Further, on x86-32 with SHARED_KERNEL_PMD=0, this causes a
BUG_ON() in vmalloc_sync_one() when PMD entries are synced
from swapper_pg_dir to the current page-table. This happens
because the PMD entry from swapper_pg_dir was promoted to a
huge-page entry while the current PGD still contains the
non-leaf entry. Because both entries are present and point
to a different page, the BUG_ON() triggers.

This was actually triggered with pti-x32 enabled in a KVM
virtual machine by the graphics driver.

A real and better fix for that would be to improve the
page-table handling in the generic ioremap() code. But that is
out-of-scope for this patch-set and left for later work.

Reported-by: David H. Gutteridge <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Cc: Andrea Arcangeli <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Boris Ostrovsky <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: David Laight <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: Eduardo Valentin <[email protected]>
Cc: Greg KH <[email protected]>
Cc: Jiri Kosina <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Cc: Juergen Gross <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Pavel Machek <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Waiman Long <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/mm/pgtable.c | 9 +++++++++
1 file changed, 9 insertions(+)

--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -1,5 +1,6 @@
#include <linux/mm.h>
#include <linux/gfp.h>
+#include <linux/hugetlb.h>
#include <asm/pgalloc.h>
#include <asm/pgtable.h>
#include <asm/tlb.h>
@@ -600,6 +601,10 @@ int pud_set_huge(pud_t *pud, phys_addr_t
(mtrr != MTRR_TYPE_WRBACK))
return 0;

+ /* Bail out if we are we on a populated non-leaf entry: */
+ if (pud_present(*pud) && !pud_huge(*pud))
+ return 0;
+
prot = pgprot_4k_2_large(prot);

set_pte((pte_t *)pud, pfn_pte(
@@ -628,6 +633,10 @@ int pmd_set_huge(pmd_t *pmd, phys_addr_t
return 0;
}

+ /* Bail out if we are we on a populated non-leaf entry: */
+ if (pmd_present(*pmd) && !pmd_huge(*pmd))
+ return 0;
+
prot = pgprot_4k_2_large(prot);

set_pte((pte_t *)pmd, pfn_pte(



2018-05-28 15:23:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 162/268] sr: get/drop reference to device in revalidate and check_events

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

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

From: Jens Axboe <[email protected]>

[ Upstream commit 2d097c50212e137e7b53ffe3b37561153eeba87d ]

We can't just use scsi_cd() to get the scsi_cd structure, we have
to grab a live reference to the device. For both callbacks, we're
not inside an open where we already hold a reference to the device.

This fixes device removal/addition under concurrent device access,
which otherwise could result in the below oops.

NULL pointer dereference at 0000000000000010
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in:
sr 12:0:0:0: [sr2] scsi-1 drive
scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl
sr 12:0:0:0: Attached scsi CD-ROM sr2
sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc
sr 12:0:0:0: Attached scsi generic sg7 type 5
igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif]
CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ #650
Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016
RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod]
RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292
RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66
RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000
RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000
R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d
R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000
FS: 00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
? __invalidate_device+0x48/0x60
check_disk_change+0x4c/0x60
sr_block_open+0x16/0xd0 [sr_mod]
__blkdev_get+0xb9/0x450
? iget5_locked+0x1c0/0x1e0
blkdev_get+0x11e/0x320
? bdget+0x11d/0x150
? _raw_spin_unlock+0xa/0x20
? bd_acquire+0xc0/0xc0
do_dentry_open+0x1b0/0x320
? inode_permission+0x24/0xc0
path_openat+0x4e6/0x1420
? cpumask_any_but+0x1f/0x40
? flush_tlb_mm_range+0xa0/0x120
do_filp_open+0x8c/0xf0
? __seccomp_filter+0x28/0x230
? _raw_spin_unlock+0xa/0x20
? __handle_mm_fault+0x7d6/0x9b0
? list_lru_add+0xa8/0xc0
? _raw_spin_unlock+0xa/0x20
? __alloc_fd+0xaf/0x160
? do_sys_open+0x1a6/0x230
do_sys_open+0x1a6/0x230
do_syscall_64+0x5a/0x100
entry_SYSCALL_64_after_hwframe+0x3d/0xa2

Reviewed-by: Lee Duncan <[email protected]>
Reviewed-by: Jan Kara <[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/scsi/sr.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)

--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -582,18 +582,28 @@ out:
static unsigned int sr_block_check_events(struct gendisk *disk,
unsigned int clearing)
{
- struct scsi_cd *cd = scsi_cd(disk);
+ unsigned int ret = 0;
+ struct scsi_cd *cd;

- if (atomic_read(&cd->device->disk_events_disable_depth))
+ cd = scsi_cd_get(disk);
+ if (!cd)
return 0;

- return cdrom_check_events(&cd->cdi, clearing);
+ if (!atomic_read(&cd->device->disk_events_disable_depth))
+ ret = cdrom_check_events(&cd->cdi, clearing);
+
+ scsi_cd_put(cd);
+ return ret;
}

static int sr_block_revalidate_disk(struct gendisk *disk)
{
- struct scsi_cd *cd = scsi_cd(disk);
struct scsi_sense_hdr sshdr;
+ struct scsi_cd *cd;
+
+ cd = scsi_cd_get(disk);
+ if (!cd)
+ return -ENXIO;

/* if the unit is not ready, nothing more to do */
if (scsi_test_unit_ready(cd->device, SR_TIMEOUT, MAX_RETRIES, &sshdr))
@@ -602,6 +612,7 @@ static int sr_block_revalidate_disk(stru
sr_cd_check(&cd->cdi);
get_sectorsize(cd);
out:
+ scsi_cd_put(cd);
return 0;
}




2018-05-28 15:24:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 156/268] net: Fix untag for vlan packets without ethernet header

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

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

From: Toshiaki Makita <[email protected]>

[ Upstream commit ae4745730cf8e693d354ccd4dbaf59ea440c09a9 ]

In some situation vlan packets do not have ethernet headers. One example
is packets from tun devices. Users can specify vlan protocol in tun_pi
field instead of IP protocol, and skb_vlan_untag() attempts to untag such
packets.

skb_vlan_untag() (more precisely, skb_reorder_vlan_header() called by it)
however did not expect packets without ethernet headers, so in such a case
size argument for memmove() underflowed and triggered crash.

====
BUG: unable to handle kernel paging request at ffff8801cccb8000
IP: __memmove+0x24/0x1a0 arch/x86/lib/memmove_64.S:43
PGD 9cee067 P4D 9cee067 PUD 1d9401063 PMD 1cccb7063 PTE 2810100028101
Oops: 000b [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 17663 Comm: syz-executor2 Not tainted 4.16.0-rc7+ #368
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:__memmove+0x24/0x1a0 arch/x86/lib/memmove_64.S:43
RSP: 0018:ffff8801cc046e28 EFLAGS: 00010287
RAX: ffff8801ccc244c4 RBX: fffffffffffffffe RCX: fffffffffff6c4c2
RDX: fffffffffffffffe RSI: ffff8801cccb7ffc RDI: ffff8801cccb8000
RBP: ffff8801cc046e48 R08: ffff8801ccc244be R09: ffffed0039984899
R10: 0000000000000001 R11: ffffed0039984898 R12: ffff8801ccc244c4
R13: ffff8801ccc244c0 R14: ffff8801d96b7c06 R15: ffff8801d96b7b40
FS: 00007febd562d700(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff8801cccb8000 CR3: 00000001ccb2f006 CR4: 00000000001606e0
DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Call Trace:
memmove include/linux/string.h:360 [inline]
skb_reorder_vlan_header net/core/skbuff.c:5031 [inline]
skb_vlan_untag+0x470/0xc40 net/core/skbuff.c:5061
__netif_receive_skb_core+0x119c/0x3460 net/core/dev.c:4460
__netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4627
netif_receive_skb_internal+0x10b/0x670 net/core/dev.c:4701
netif_receive_skb+0xae/0x390 net/core/dev.c:4725
tun_rx_batched.isra.50+0x5ee/0x870 drivers/net/tun.c:1555
tun_get_user+0x299e/0x3c20 drivers/net/tun.c:1962
tun_chr_write_iter+0xb9/0x160 drivers/net/tun.c:1990
call_write_iter include/linux/fs.h:1782 [inline]
new_sync_write fs/read_write.c:469 [inline]
__vfs_write+0x684/0x970 fs/read_write.c:482
vfs_write+0x189/0x510 fs/read_write.c:544
SYSC_write fs/read_write.c:589 [inline]
SyS_write+0xef/0x220 fs/read_write.c:581
do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x454879
RSP: 002b:00007febd562cc68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007febd562d6d4 RCX: 0000000000454879
RDX: 0000000000000157 RSI: 0000000020000180 RDI: 0000000000000014
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000006b0 R14: 00000000006fc120 R15: 0000000000000000
Code: 90 90 90 90 90 90 90 48 89 f8 48 83 fa 20 0f 82 03 01 00 00 48 39 fe 7d 0f 49 89 f0 49 01 d0 49 39 f8 0f 8f 9f 00 00 00 48 89 d1 <f3> a4 c3 48 81 fa a8 02 00 00 72 05 40 38 fe 74 3b 48 83 ea 20
RIP: __memmove+0x24/0x1a0 arch/x86/lib/memmove_64.S:43 RSP: ffff8801cc046e28
CR2: ffff8801cccb8000
====

We don't need to copy headers for packets which do not have preceding
headers of vlan headers, so skip memmove() in that case.

Fixes: 4bbb3e0e8239 ("net: Fix vlan untag for bridge and vlan_dev with reorder_hdr off")
Reported-by: Eric Dumazet <[email protected]>
Signed-off-by: Toshiaki Makita <[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/core/skbuff.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4303,8 +4303,10 @@ static struct sk_buff *skb_reorder_vlan_
}

mac_len = skb->data - skb_mac_header(skb);
- memmove(skb_mac_header(skb) + VLAN_HLEN, skb_mac_header(skb),
- mac_len - VLAN_HLEN - ETH_TLEN);
+ if (likely(mac_len > VLAN_HLEN + ETH_TLEN)) {
+ memmove(skb_mac_header(skb) + VLAN_HLEN, skb_mac_header(skb),
+ mac_len - VLAN_HLEN - ETH_TLEN);
+ }
skb->mac_header += VLAN_HLEN;
return skb;
}



2018-05-28 15:24:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 116/268] sit: fix IFLA_MTU ignored on NEWLINK

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

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

From: Xin Long <[email protected]>

[ Upstream commit 2b3957c34b6d7f03544b12ebbf875eee430745db ]

Commit 128bb975dc3c ("ip6_gre: init dev->mtu and dev->hard_header_len
correctly") fixed IFLA_MTU ignored on NEWLINK for ip6_gre. The same
mtu fix is also needed for sit.

Note that dev->hard_header_len setting for sit works fine, no need to
fix it. sit is actually ipv4 tunnel, it can't call ip6_tnl_change_mtu
to set mtu.

Reported-by: Jianlin Shi <[email protected]>
Signed-off-by: Xin Long <[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/sit.c | 7 +++++++
1 file changed, 7 insertions(+)

--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1574,6 +1574,13 @@ static int ipip6_newlink(struct net *src
if (err < 0)
return err;

+ if (tb[IFLA_MTU]) {
+ u32 mtu = nla_get_u32(tb[IFLA_MTU]);
+
+ if (mtu >= IPV6_MIN_MTU && mtu <= 0xFFF8 - dev->hard_header_len)
+ dev->mtu = mtu;
+ }
+
#ifdef CONFIG_IPV6_SIT_6RD
if (ipip6_netlink_6rd_parms(data, &ip6rd))
err = ipip6_tunnel_update_6rd(nt, &ip6rd);



2018-05-28 15:24:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 155/268] mm/kmemleak.c: wait for scan completion before disabling free

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

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

From: Vinayak Menon <[email protected]>

[ Upstream commit 914b6dfff790544d9b77dfd1723adb3745ec9700 ]

A crash is observed when kmemleak_scan accesses the object->pointer,
likely due to the following race.

TASK A TASK B TASK C
kmemleak_write
(with "scan" and
NOT "scan=on")
kmemleak_scan()
create_object
kmem_cache_alloc fails
kmemleak_disable
kmemleak_do_cleanup
kmemleak_free_enabled = 0
kfree
kmemleak_free bails out
(kmemleak_free_enabled is 0)
slub frees object->pointer
update_checksum
crash - object->pointer
freed (DEBUG_PAGEALLOC)

kmemleak_do_cleanup waits for the scan thread to complete, but not for
direct call to kmemleak_scan via kmemleak_write. So add a wait for
kmemleak_scan completion before disabling kmemleak_free, and while at it
fix the comment on stop_scan_thread.

[[email protected]: fix stop_scan_thread comment]
Link: http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Vinayak Menon <[email protected]>
Reviewed-by: Catalin Marinas <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/kmemleak.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)

--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1524,8 +1524,7 @@ static void start_scan_thread(void)
}

/*
- * Stop the automatic memory scanning thread. This function must be called
- * with the scan_mutex held.
+ * Stop the automatic memory scanning thread.
*/
static void stop_scan_thread(void)
{
@@ -1788,12 +1787,15 @@ static void kmemleak_do_cleanup(struct w
{
stop_scan_thread();

+ mutex_lock(&scan_mutex);
/*
- * Once the scan thread has stopped, it is safe to no longer track
- * object freeing. Ordering of the scan thread stopping and the memory
- * accesses below is guaranteed by the kthread_stop() function.
+ * Once it is made sure that kmemleak_scan has stopped, it is safe to no
+ * longer track object freeing. Ordering of the scan thread stopping and
+ * the memory accesses below is guaranteed by the kthread_stop()
+ * function.
*/
kmemleak_free_enabled = 0;
+ mutex_unlock(&scan_mutex);

if (!kmemleak_found_leaks)
__kmemleak_do_cleanup();



2018-05-28 15:24:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 117/268] gianfar: Fix Rx byte accounting for ndev stats

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

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

From: Claudiu Manoil <[email protected]>

[ Upstream commit 590399ddf9561f2ed0839311c8ae1be21597ba68 ]

Don't include in the Rx bytecount of the packet sent up the stack:
the FCB (frame control block), and the padding bytes inserted by
the controller into the frame payload, nor the FCS. All these are
being pulled out of the skb by gfar_process_frame().
This issue is old, likely from the driver's beginnings, however
it was amplified by recent:
commit d903ec77118c ("gianfar: simplify FCS handling and fix memory leak")
which basically added the FCS to the Rx bytecount, and so brought
this to my attention.

Signed-off-by: Claudiu Manoil <[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/freescale/gianfar.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -3053,9 +3053,6 @@ static void gfar_process_frame(struct ne
if (ndev->features & NETIF_F_RXCSUM)
gfar_rx_checksum(skb, fcb);

- /* Tell the skb what kind of packet this is */
- skb->protocol = eth_type_trans(skb, ndev);
-
/* There's need to check for NETIF_F_HW_VLAN_CTAG_RX here.
* Even if vlan rx accel is disabled, on some chips
* RXFCB_VLN is pseudo randomly set.
@@ -3126,13 +3123,15 @@ int gfar_clean_rx_ring(struct gfar_priv_
continue;
}

+ gfar_process_frame(ndev, skb);
+
/* Increment the number of packets */
total_pkts++;
total_bytes += skb->len;

skb_record_rx_queue(skb, rx_queue->qindex);

- gfar_process_frame(ndev, skb);
+ skb->protocol = eth_type_trans(skb, ndev);

/* Send the packet up the stack */
napi_gro_receive(&rx_queue->grp->napi_rx, skb);



2018-05-28 15:24:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 110/268] nvme-pci: Fix nvme queue cleanup if IRQ setup fails

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

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

From: Jianchao Wang <[email protected]>

[ Upstream commit f25a2dfc20e3a3ed8fe6618c331799dd7bd01190 ]

This patch fixes nvme queue cleanup if requesting an IRQ handler for
the queue's vector fails. It does this by resetting the cq_vector to
the uninitialized value of -1 so it is ignored for a controller reset.

Signed-off-by: Jianchao Wang <[email protected]>
[changelog updates, removed misc whitespace changes]
Signed-off-by: Keith Busch <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/nvme/host/pci.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1583,7 +1583,7 @@ static int nvme_create_queue(struct nvme
nvmeq->cq_vector = qid - 1;
result = adapter_alloc_cq(dev, qid, nvmeq);
if (result < 0)
- return result;
+ goto release_vector;

result = adapter_alloc_sq(dev, qid, nvmeq);
if (result < 0)
@@ -1597,9 +1597,12 @@ static int nvme_create_queue(struct nvme
return result;

release_sq:
+ dev->online_queues--;
adapter_delete_sq(dev, qid);
release_cq:
adapter_delete_cq(dev, qid);
+ release_vector:
+ nvmeq->cq_vector = -1;
return result;
}




2018-05-28 15:25:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 115/268] bcache: fix kcrashes with fio in RAID5 backend dev

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

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

From: Tang Junhui <[email protected]>

[ Upstream commit 60eb34ec5526e264c2bbaea4f7512d714d791caf ]

Kernel crashed when run fio in a RAID5 backend bcache device, the call
trace is bellow:
[ 440.012034] kernel BUG at block/blk-ioc.c:146!
[ 440.012696] invalid opcode: 0000 [#1] SMP NOPTI
[ 440.026537] CPU: 2 PID: 2205 Comm: md127_raid5 Not tainted 4.15.0 #8
[ 440.027441] Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 07/16
/2015
[ 440.028615] RIP: 0010:put_io_context+0x8b/0x90
[ 440.029246] RSP: 0018:ffffa8c882b43af8 EFLAGS: 00010246
[ 440.029990] RAX: 0000000000000000 RBX: ffffa8c88294fca0 RCX: 0000000000
0f4240
[ 440.031006] RDX: 0000000000000004 RSI: 0000000000000286 RDI: ffffa8c882
94fca0
[ 440.032030] RBP: ffffa8c882b43b10 R08: 0000000000000003 R09: ffff949cb8
0c1700
[ 440.033206] R10: 0000000000000104 R11: 000000000000b71c R12: 00000000000
01000
[ 440.034222] R13: 0000000000000000 R14: ffff949cad84db70 R15: ffff949cb11
bd1e0
[ 440.035239] FS: 0000000000000000(0000) GS:ffff949cba280000(0000) knlGS:
0000000000000000
[ 440.060190] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 440.084967] CR2: 00007ff0493ef000 CR3: 00000002f1e0a002 CR4: 00000000001
606e0
[ 440.110498] Call Trace:
[ 440.135443] bio_disassociate_task+0x1b/0x60
[ 440.160355] bio_free+0x1b/0x60
[ 440.184666] bio_put+0x23/0x30
[ 440.208272] search_free+0x23/0x40 [bcache]
[ 440.231448] cached_dev_write_complete+0x31/0x70 [bcache]
[ 440.254468] closure_put+0xb6/0xd0 [bcache]
[ 440.277087] request_endio+0x30/0x40 [bcache]
[ 440.298703] bio_endio+0xa1/0x120
[ 440.319644] handle_stripe+0x418/0x2270 [raid456]
[ 440.340614] ? load_balance+0x17b/0x9c0
[ 440.360506] handle_active_stripes.isra.58+0x387/0x5a0 [raid456]
[ 440.380675] ? __release_stripe+0x15/0x20 [raid456]
[ 440.400132] raid5d+0x3ed/0x5d0 [raid456]
[ 440.419193] ? schedule+0x36/0x80
[ 440.437932] ? schedule_timeout+0x1d2/0x2f0
[ 440.456136] md_thread+0x122/0x150
[ 440.473687] ? wait_woken+0x80/0x80
[ 440.491411] kthread+0x102/0x140
[ 440.508636] ? find_pers+0x70/0x70
[ 440.524927] ? kthread_associate_blkcg+0xa0/0xa0
[ 440.541791] ret_from_fork+0x35/0x40
[ 440.558020] Code: c2 48 00 5b 41 5c 41 5d 5d c3 48 89 c6 4c 89 e7 e8 bb c2
48 00 48 8b 3d bc 36 4b 01 48 89 de e8 7c f7 e0 ff 5b 41 5c 41 5d 5d c3 <0f> 0b
0f 1f 00 0f 1f 44 00 00 55 48 8d 47 b8 48 89 e5 41 57 41
[ 440.610020] RIP: put_io_context+0x8b/0x90 RSP: ffffa8c882b43af8
[ 440.628575] ---[ end trace a1fd79d85643a73e ]--

All the crash issue happened when a bypass IO coming, in such scenario
s->iop.bio is pointed to the s->orig_bio. In search_free(), it finishes the
s->orig_bio by calling bio_complete(), and after that, s->iop.bio became
invalid, then kernel would crash when calling bio_put(). Maybe its upper
layer's faulty, since bio should not be freed before we calling bio_put(),
but we'd better calling bio_put() first before calling bio_complete() to
notify upper layer ending this bio.

This patch moves bio_complete() under bio_put() to avoid kernel crash.

[mlyle: fixed commit subject for character limits]

Reported-by: Matthias Ferdinand <[email protected]>
Tested-by: Matthias Ferdinand <[email protected]>
Signed-off-by: Tang Junhui <[email protected]>
Reviewed-by: Michael Lyle <[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/md/bcache/request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -633,11 +633,11 @@ static void do_bio_hook(struct search *s
static void search_free(struct closure *cl)
{
struct search *s = container_of(cl, struct search, cl);
- bio_complete(s);

if (s->iop.bio)
bio_put(s->iop.bio);

+ bio_complete(s);
closure_debug_destroy(cl);
mempool_free(s, s->d->c->search);
}



2018-05-28 15:25:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 118/268] net/tcp/illinois: replace broken algorithm reference link

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

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

From: Joey Pabalinas <[email protected]>

[ Upstream commit ecc832758a654e375924ebf06a4ac971acb5ce60 ]

The link to the pdf containing the algorithm description is now a
dead link; it seems http://www.ifp.illinois.edu/~srikant/ has been
moved to https://sites.google.com/a/illinois.edu/srikant/ and none of
the original papers can be found there...

I have replaced it with the only working copy I was able to find.

n.b. there is also a copy available at:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.296.6350&rep=rep1&type=pdf

However, this seems to only be a *cached* version, so I am unsure
exactly how reliable that link can be expected to remain over time
and have decided against using that one.

Signed-off-by: Joey Pabalinas <[email protected]>

net/ipv4/tcp_illinois.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

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_illinois.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ipv4/tcp_illinois.c
+++ b/net/ipv4/tcp_illinois.c
@@ -6,7 +6,7 @@
* The algorithm is described in:
* "TCP-Illinois: A Loss and Delay-Based Congestion Control Algorithm
* for High-Speed Networks"
- * http://www.ifp.illinois.edu/~srikant/Papers/liubassri06perf.pdf
+ * http://tamerbasar.csl.illinois.edu/LiuBasarSrikantPerfEvalArtJun2008.pdf
*
* Implemented from description in paper and ns-2 simulation.
* Copyright (C) 2007 Stephen Hemminger <[email protected]>



2018-05-28 15:26:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 143/268] RDMA/ucma: Correct option size check using optlen

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

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

From: Chien Tin Tung <[email protected]>

[ Upstream commit 5f3e3b85cc0a5eae1c46d72e47d3de7bf208d9e2 ]

The option size check is using optval instead of optlen
causing the set option call to fail. Use the correct
field, optlen, for size check.

Fixes: 6a21dfc0d0db ("RDMA/ucma: Limit possible option size")
Signed-off-by: Chien Tin Tung <[email protected]>
Signed-off-by: Shiraz Saleem <[email protected]>
Reviewed-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/ucma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -1295,7 +1295,7 @@ static ssize_t ucma_set_option(struct uc
if (IS_ERR(ctx))
return PTR_ERR(ctx);

- if (unlikely(cmd.optval > KMALLOC_MAX_SIZE))
+ if (unlikely(cmd.optlen > KMALLOC_MAX_SIZE))
return -EINVAL;

optval = memdup_user((void __user *) (unsigned long) cmd.optval,



2018-05-28 15:26:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 114/268] dmaengine: rcar-dmac: fix max_chunk_size for R-Car Gen3

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

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

From: Yoshihiro Shimoda <[email protected]>

[ Upstream commit d716d9b702bb759dd6fb50804f10a174bd156d71 ]

According to R-Car Gen3 Rev.0.80 manual, the DMATCR can be set to
16,777,215 as maximum. So, this patch fixes the max_chunk_size for
safety on all of SoCs. Otherwise, a system may hang if the DMATCR
is set to 0 on R-Car Gen3.

Signed-off-by: Yoshihiro Shimoda <[email protected]>
Reviewed-by: Simon Horman <[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/sh/rcar-dmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -851,7 +851,7 @@ rcar_dmac_chan_prep_sg(struct rcar_dmac_

rcar_dmac_chan_configure_desc(chan, desc);

- max_chunk_size = (RCAR_DMATCR_MASK + 1) << desc->xfer_shift;
+ max_chunk_size = RCAR_DMATCR_MASK << desc->xfer_shift;

/*
* Allocate and fill the transfer chunk descriptors. We own the only



2018-05-28 15:26:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 142/268] perf/cgroup: Fix child event counting bug

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

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

From: Song Liu <[email protected]>

[ Upstream commit c917e0f259908e75bd2a65877e25f9d90c22c848 ]

When a perf_event is attached to parent cgroup, it should count events
for all children cgroups:

parent_group <---- perf_event
\
- child_group <---- process(es)

However, in our tests, we found this perf_event cannot report reliable
results. Here is an example case:

# create cgroups
mkdir -p /sys/fs/cgroup/p/c
# start perf for parent group
perf stat -e instructions -G "p"

# on another console, run test process in child cgroup:
stressapptest -s 2 -M 1000 & echo $! > /sys/fs/cgroup/p/c/cgroup.procs

# after the test process is done, stop perf in the first console shows

<not counted> instructions p

The instruction should not be "not counted" as the process runs in the
child cgroup.

We found this is because perf_event->cgrp and cpuctx->cgrp are not
identical, thus perf_event->cgrp are not updated properly.

This patch fixes this by updating perf_cgroup properly for ancestor
cgroup(s).

Reported-by: Ephraim Park <[email protected]>
Signed-off-by: Song Liu <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/events/core.c | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)

--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -419,9 +419,15 @@ static inline void __update_cgrp_time(st

static inline void update_cgrp_time_from_cpuctx(struct perf_cpu_context *cpuctx)
{
- struct perf_cgroup *cgrp_out = cpuctx->cgrp;
- if (cgrp_out)
- __update_cgrp_time(cgrp_out);
+ struct perf_cgroup *cgrp = cpuctx->cgrp;
+ struct cgroup_subsys_state *css;
+
+ if (cgrp) {
+ for (css = &cgrp->css; css; css = css->parent) {
+ cgrp = container_of(css, struct perf_cgroup, css);
+ __update_cgrp_time(cgrp);
+ }
+ }
}

static inline void update_cgrp_time_from_event(struct perf_event *event)
@@ -449,6 +455,7 @@ perf_cgroup_set_timestamp(struct task_st
{
struct perf_cgroup *cgrp;
struct perf_cgroup_info *info;
+ struct cgroup_subsys_state *css;

/*
* ctx->lock held by caller
@@ -459,8 +466,12 @@ perf_cgroup_set_timestamp(struct task_st
return;

cgrp = perf_cgroup_from_task(task, ctx);
- info = this_cpu_ptr(cgrp->info);
- info->timestamp = ctx->timestamp;
+
+ for (css = &cgrp->css; css; css = css->parent) {
+ cgrp = container_of(css, struct perf_cgroup, css);
+ info = this_cpu_ptr(cgrp->info);
+ info->timestamp = ctx->timestamp;
+ }
}

#define PERF_CGROUP_SWOUT 0x1 /* cgroup switch out every event */



2018-05-28 15:26:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 139/268] batman-adv: fix header size check in batadv_dbg_arp()

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

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

From: Matthias Schiffer <[email protected]>

[ Upstream commit 6f27d2c2a8c236d296201c19abb8533ec20d212b ]

Checking for 0 is insufficient: when an SKB without a batadv header, but
with a VLAN header is received, hdr_size will be 4, making the following
code interpret the Ethernet header as a batadv header.

Fixes: be1db4f6615b ("batman-adv: make the Distributed ARP Table vlan aware")
Signed-off-by: Matthias Schiffer <[email protected]>
Signed-off-by: Sven Eckelmann <[email protected]>
Signed-off-by: Simon Wunderlich <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/batman-adv/distributed-arp-table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -374,7 +374,7 @@ static void batadv_dbg_arp(struct batadv
batadv_arp_hw_src(skb, hdr_size), &ip_src,
batadv_arp_hw_dst(skb, hdr_size), &ip_dst);

- if (hdr_size == 0)
+ if (hdr_size < sizeof(struct batadv_unicast_packet))
return;

unicast_4addr_packet = (struct batadv_unicast_4addr_packet *)skb->data;



2018-05-28 15:27:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 137/268] microblaze: switch to NO_BOOTMEM

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

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

From: Rob Herring <[email protected]>

[ Upstream commit 101646a24a2f9cdb61d7732459fbf068a7bbb542 ]

Microblaze doesn't set CONFIG_NO_BOOTMEM and so memblock_virt_alloc()
doesn't work for CONFIG_HAVE_MEMBLOCK && !CONFIG_NO_BOOTMEM.

Similar change was already done by others architectures
"ARM: mm: Remove bootmem code and switch to NO_BOOTMEM"
(sha1: 84f452b1e8fc73ac0e31254c66e3e2260ce5263d)
or
"openrisc: Consolidate setup to use memblock instead of bootmem"
(sha1: 266c7fad157265bb54d17db1c9545f2aaa488643)
or
"parisc: Drop bootmem and switch to memblock"
(sha1: 4fe9e1d957e45ad8eba9885ee860a0e93d13a7c7)
or
"powerpc: Remove bootmem allocator"
(sha1: 10239733ee8617bac3f1c1769af43a88ed979324)
or
"s390/mm: Convert bootmem to memblock"
(sha1: 50be634507284eea38df78154d22615d21200b42)
or
"sparc64: Convert over to NO_BOOTMEM."
(sha1: 625d693e9784f988371e69c2b41a2172c0be6c11)
or
"xtensa: drop sysmem and switch to memblock"
(sha1: 0e46c1115f5816949220d62dd3ff04aa68e7ac6b)

Issue was introduced by:
"of/fdt: use memblock_virt_alloc for early alloc"
(sha1: 0fa1c579349fdd90173381712ad78aa99c09d38b)

Signed-off-by: Rob Herring <[email protected]>
Tested-by: Alvaro Gamez Machado <[email protected]>
Tested-by: Michal Simek <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/microblaze/Kconfig | 1
arch/microblaze/mm/init.c | 56 ++++------------------------------------------
2 files changed, 7 insertions(+), 50 deletions(-)

--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -24,6 +24,7 @@ config MICROBLAZE
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_TRACER
+ select NO_BOOTMEM
select HAVE_MEMBLOCK
select HAVE_MEMBLOCK_NODE_MAP
select HAVE_OPROFILE
--- a/arch/microblaze/mm/init.c
+++ b/arch/microblaze/mm/init.c
@@ -32,9 +32,6 @@ int mem_init_done;
#ifndef CONFIG_MMU
unsigned int __page_offset;
EXPORT_SYMBOL(__page_offset);
-
-#else
-static int init_bootmem_done;
#endif /* CONFIG_MMU */

char *klimit = _end;
@@ -117,7 +114,6 @@ static void __init paging_init(void)

void __init setup_memory(void)
{
- unsigned long map_size;
struct memblock_region *reg;

#ifndef CONFIG_MMU
@@ -174,17 +170,6 @@ void __init setup_memory(void)
pr_info("%s: max_low_pfn: %#lx\n", __func__, max_low_pfn);
pr_info("%s: max_pfn: %#lx\n", __func__, max_pfn);

- /*
- * Find an area to use for the bootmem bitmap.
- * We look for the first area which is at least
- * 128kB in length (128kB is enough for a bitmap
- * for 4GB of memory, using 4kB pages), plus 1 page
- * (in case the address isn't page-aligned).
- */
- map_size = init_bootmem_node(NODE_DATA(0),
- PFN_UP(TOPHYS((u32)klimit)), min_low_pfn, max_low_pfn);
- memblock_reserve(PFN_UP(TOPHYS((u32)klimit)) << PAGE_SHIFT, map_size);
-
/* Add active regions with valid PFNs */
for_each_memblock(memory, reg) {
unsigned long start_pfn, end_pfn;
@@ -196,32 +181,9 @@ void __init setup_memory(void)
&memblock.memory, 0);
}

- /* free bootmem is whole main memory */
- free_bootmem_with_active_regions(0, max_low_pfn);
-
- /* reserve allocate blocks */
- for_each_memblock(reserved, reg) {
- unsigned long top = reg->base + reg->size - 1;
-
- pr_debug("reserved - 0x%08x-0x%08x, %lx, %lx\n",
- (u32) reg->base, (u32) reg->size, top,
- memory_start + lowmem_size - 1);
-
- if (top <= (memory_start + lowmem_size - 1)) {
- reserve_bootmem(reg->base, reg->size, BOOTMEM_DEFAULT);
- } else if (reg->base < (memory_start + lowmem_size - 1)) {
- unsigned long trunc_size = memory_start + lowmem_size -
- reg->base;
- reserve_bootmem(reg->base, trunc_size, BOOTMEM_DEFAULT);
- }
- }
-
/* XXX need to clip this if using highmem? */
sparse_memory_present_with_active_regions(0);

-#ifdef CONFIG_MMU
- init_bootmem_done = 1;
-#endif
paging_init();
}

@@ -398,18 +360,12 @@ asmlinkage void __init mmu_init(void)
/* This is only called until mem_init is done. */
void __init *early_get_page(void)
{
- void *p;
- if (init_bootmem_done) {
- p = alloc_bootmem_pages(PAGE_SIZE);
- } else {
- /*
- * Mem start + kernel_tlb -> here is limit
- * because of mem mapping from head.S
- */
- p = __va(memblock_alloc_base(PAGE_SIZE, PAGE_SIZE,
- memory_start + kernel_tlb));
- }
- return p;
+ /*
+ * Mem start + kernel_tlb -> here is limit
+ * because of mem mapping from head.S
+ */
+ return __va(memblock_alloc_base(PAGE_SIZE, PAGE_SIZE,
+ memory_start + kernel_tlb));
}

#endif /* CONFIG_MMU */



2018-05-28 15:28:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 113/268] virtio-gpu: fix ioctl and expose the fixed status to userspace.

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

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

From: Dave Airlie <[email protected]>

[ Upstream commit 9a191b114906457c4b2494c474f58ae4142d4e67 ]

This exposes to mesa that it can use the fixed ioctl for querying
later cap sets, cap set 1 is forever frozen in time.

Signed-off-by: Dave Airlie <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Gerd Hoffmann <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 17 +++++++++++------
include/uapi/drm/virtgpu_drm.h | 1 +
2 files changed, 12 insertions(+), 6 deletions(-)

--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -208,6 +208,9 @@ static int virtio_gpu_getparam_ioctl(str
case VIRTGPU_PARAM_3D_FEATURES:
value = vgdev->has_virgl_3d == true ? 1 : 0;
break;
+ case VIRTGPU_PARAM_CAPSET_QUERY_FIX:
+ value = 1;
+ break;
default:
return -EINVAL;
}
@@ -483,7 +486,7 @@ static int virtio_gpu_get_caps_ioctl(str
{
struct virtio_gpu_device *vgdev = dev->dev_private;
struct drm_virtgpu_get_caps *args = data;
- int size;
+ unsigned size, host_caps_size;
int i;
int found_valid = -1;
int ret;
@@ -492,6 +495,10 @@ static int virtio_gpu_get_caps_ioctl(str
if (vgdev->num_capsets == 0)
return -ENOSYS;

+ /* don't allow userspace to pass 0 */
+ if (args->size == 0)
+ return -EINVAL;
+
spin_lock(&vgdev->display_info_lock);
for (i = 0; i < vgdev->num_capsets; i++) {
if (vgdev->capsets[i].id == args->cap_set_id) {
@@ -507,11 +514,9 @@ static int virtio_gpu_get_caps_ioctl(str
return -EINVAL;
}

- size = vgdev->capsets[found_valid].max_size;
- if (args->size > size) {
- spin_unlock(&vgdev->display_info_lock);
- return -EINVAL;
- }
+ host_caps_size = vgdev->capsets[found_valid].max_size;
+ /* only copy to user the minimum of the host caps size or the guest caps size */
+ size = min(args->size, host_caps_size);

list_for_each_entry(cache_ent, &vgdev->cap_cache, head) {
if (cache_ent->id == args->cap_set_id &&
--- a/include/uapi/drm/virtgpu_drm.h
+++ b/include/uapi/drm/virtgpu_drm.h
@@ -60,6 +60,7 @@ struct drm_virtgpu_execbuffer {
};

#define VIRTGPU_PARAM_3D_FEATURES 1 /* do we have 3D features in the hw */
+#define VIRTGPU_PARAM_CAPSET_QUERY_FIX 2 /* do we have the capset fix */

struct drm_virtgpu_getparam {
uint64_t param;



2018-05-28 15:28:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 136/268] sunvnet: does not support GSO for sctp

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

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

From: Cathy Zhou <[email protected]>

[ Upstream commit cf55612a945039476abfd73e39064b2e721c3272 ]

The NETIF_F_GSO_SOFTWARE implies support for GSO on SCTP, but the
sunvnet driver does not support GSO for sctp. Here we remove the
NETIF_F_GSO_SOFTWARE feature flag and only report NETIF_F_ALL_TSO
instead.

Signed-off-by: Cathy Zhou <[email protected]>
Signed-off-by: Shannon Nelson <[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/sun/sunvnet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/sun/sunvnet.c
+++ b/drivers/net/ethernet/sun/sunvnet.c
@@ -1787,7 +1787,7 @@ static struct vnet *vnet_new(const u64 *
dev->ethtool_ops = &vnet_ethtool_ops;
dev->watchdog_timeo = VNET_TX_TIMEOUT;

- dev->hw_features = NETIF_F_TSO | NETIF_F_GSO | NETIF_F_GSO_SOFTWARE |
+ dev->hw_features = NETIF_F_TSO | NETIF_F_GSO | NETIF_F_ALL_TSO |
NETIF_F_HW_CSUM | NETIF_F_SG;
dev->features = dev->hw_features;




2018-05-28 15:28:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 135/268] ipv4: lock mtu in fnhe when received PMTU < net.ipv4.route.min_pmtu

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

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

From: Sabrina Dubroca <[email protected]>

[ Upstream commit d52e5a7e7ca49457dd31fc8b42fb7c0d58a31221 ]

Prior to the rework of PMTU information storage in commit
2c8cec5c10bc ("ipv4: Cache learned PMTU information in inetpeer."),
when a PMTU event advertising a PMTU smaller than
net.ipv4.route.min_pmtu was received, we would disable setting the DF
flag on packets by locking the MTU metric, and set the PMTU to
net.ipv4.route.min_pmtu.

Since then, we don't disable DF, and set PMTU to
net.ipv4.route.min_pmtu, so the intermediate router that has this link
with a small MTU will have to drop the packets.

This patch reestablishes pre-2.6.39 behavior by splitting
rtable->rt_pmtu into a bitfield with rt_mtu_locked and rt_pmtu.
rt_mtu_locked indicates that we shouldn't set the DF bit on that path,
and is checked in ip_dont_fragment().

One possible workaround is to set net.ipv4.route.min_pmtu to a value low
enough to accommodate the lowest MTU encountered.

Fixes: 2c8cec5c10bc ("ipv4: Cache learned PMTU information in inetpeer.")
Signed-off-by: Sabrina Dubroca <[email protected]>
Reviewed-by: Stefano Brivio <[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]>
---
include/net/ip.h | 11 +++++++++--
include/net/ip_fib.h | 1 +
include/net/route.h | 3 ++-
net/ipv4/route.c | 26 +++++++++++++++++++-------
net/ipv4/xfrm4_policy.c | 1 +
5 files changed, 32 insertions(+), 10 deletions(-)

--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -279,6 +279,13 @@ int ip_decrease_ttl(struct iphdr *iph)
return --iph->ttl;
}

+static inline int ip_mtu_locked(const struct dst_entry *dst)
+{
+ const struct rtable *rt = (const struct rtable *)dst;
+
+ return rt->rt_mtu_locked || dst_metric_locked(dst, RTAX_MTU);
+}
+
static inline
int ip_dont_fragment(const struct sock *sk, const struct dst_entry *dst)
{
@@ -286,7 +293,7 @@ int ip_dont_fragment(const struct sock *

return pmtudisc == IP_PMTUDISC_DO ||
(pmtudisc == IP_PMTUDISC_WANT &&
- !(dst_metric_locked(dst, RTAX_MTU)));
+ !ip_mtu_locked(dst));
}

static inline bool ip_sk_accept_pmtu(const struct sock *sk)
@@ -312,7 +319,7 @@ static inline unsigned int ip_dst_mtu_ma
struct net *net = dev_net(dst->dev);

if (net->ipv4.sysctl_ip_fwd_use_pmtu ||
- dst_metric_locked(dst, RTAX_MTU) ||
+ ip_mtu_locked(dst) ||
!forwarding)
return dst_mtu(dst);

--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -56,6 +56,7 @@ struct fib_nh_exception {
int fnhe_genid;
__be32 fnhe_daddr;
u32 fnhe_pmtu;
+ bool fnhe_mtu_locked;
__be32 fnhe_gw;
unsigned long fnhe_expires;
struct rtable __rcu *fnhe_rth_input;
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -64,7 +64,8 @@ struct rtable {
__be32 rt_gateway;

/* Miscellaneous cached information */
- u32 rt_pmtu;
+ u32 rt_mtu_locked:1,
+ rt_pmtu:31;

u32 rt_table_id;

--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -612,6 +612,7 @@ static inline u32 fnhe_hashfun(__be32 da
static void fill_route_from_fnhe(struct rtable *rt, struct fib_nh_exception *fnhe)
{
rt->rt_pmtu = fnhe->fnhe_pmtu;
+ rt->rt_mtu_locked = fnhe->fnhe_mtu_locked;
rt->dst.expires = fnhe->fnhe_expires;

if (fnhe->fnhe_gw) {
@@ -622,7 +623,7 @@ static void fill_route_from_fnhe(struct
}

static void update_or_create_fnhe(struct fib_nh *nh, __be32 daddr, __be32 gw,
- u32 pmtu, unsigned long expires)
+ u32 pmtu, bool lock, unsigned long expires)
{
struct fnhe_hash_bucket *hash;
struct fib_nh_exception *fnhe;
@@ -659,8 +660,10 @@ static void update_or_create_fnhe(struct
fnhe->fnhe_genid = genid;
if (gw)
fnhe->fnhe_gw = gw;
- if (pmtu)
+ if (pmtu) {
fnhe->fnhe_pmtu = pmtu;
+ fnhe->fnhe_mtu_locked = lock;
+ }
fnhe->fnhe_expires = max(1UL, expires);
/* Update all cached dsts too */
rt = rcu_dereference(fnhe->fnhe_rth_input);
@@ -684,6 +687,7 @@ static void update_or_create_fnhe(struct
fnhe->fnhe_daddr = daddr;
fnhe->fnhe_gw = gw;
fnhe->fnhe_pmtu = pmtu;
+ fnhe->fnhe_mtu_locked = lock;
fnhe->fnhe_expires = expires;

/* Exception created; mark the cached routes for the nexthop
@@ -765,7 +769,8 @@ static void __ip_do_redirect(struct rtab
struct fib_nh *nh = &FIB_RES_NH(res);

update_or_create_fnhe(nh, fl4->daddr, new_gw,
- 0, jiffies + ip_rt_gc_timeout);
+ 0, false,
+ jiffies + ip_rt_gc_timeout);
}
if (kill_route)
rt->dst.obsolete = DST_OBSOLETE_KILL;
@@ -977,15 +982,18 @@ static void __ip_rt_update_pmtu(struct r
{
struct dst_entry *dst = &rt->dst;
struct fib_result res;
+ bool lock = false;

- if (dst_metric_locked(dst, RTAX_MTU))
+ if (ip_mtu_locked(dst))
return;

if (ipv4_mtu(dst) < mtu)
return;

- if (mtu < ip_rt_min_pmtu)
+ if (mtu < ip_rt_min_pmtu) {
+ lock = true;
mtu = ip_rt_min_pmtu;
+ }

if (rt->rt_pmtu == mtu &&
time_before(jiffies, dst->expires - ip_rt_mtu_expires / 2))
@@ -995,7 +1003,7 @@ static void __ip_rt_update_pmtu(struct r
if (fib_lookup(dev_net(dst->dev), fl4, &res, 0) == 0) {
struct fib_nh *nh = &FIB_RES_NH(res);

- update_or_create_fnhe(nh, fl4->daddr, 0, mtu,
+ update_or_create_fnhe(nh, fl4->daddr, 0, mtu, lock,
jiffies + ip_rt_mtu_expires);
}
rcu_read_unlock();
@@ -1250,7 +1258,7 @@ static unsigned int ipv4_mtu(const struc

mtu = READ_ONCE(dst->dev->mtu);

- if (unlikely(dst_metric_locked(dst, RTAX_MTU))) {
+ if (unlikely(ip_mtu_locked(dst))) {
if (rt->rt_uses_gateway && mtu > 576)
mtu = 576;
}
@@ -1473,6 +1481,7 @@ static struct rtable *rt_dst_alloc(struc
rt->rt_is_input = 0;
rt->rt_iif = 0;
rt->rt_pmtu = 0;
+ rt->rt_mtu_locked = 0;
rt->rt_gateway = 0;
rt->rt_uses_gateway = 0;
rt->rt_table_id = 0;
@@ -2393,6 +2402,7 @@ struct dst_entry *ipv4_blackhole_route(s
rt->rt_is_input = ort->rt_is_input;
rt->rt_iif = ort->rt_iif;
rt->rt_pmtu = ort->rt_pmtu;
+ rt->rt_mtu_locked = ort->rt_mtu_locked;

rt->rt_genid = rt_genid_ipv4(net);
rt->rt_flags = ort->rt_flags;
@@ -2495,6 +2505,8 @@ static int rt_fill_info(struct net *net,
memcpy(metrics, dst_metrics_ptr(&rt->dst), sizeof(metrics));
if (rt->rt_pmtu && expires)
metrics[RTAX_MTU - 1] = rt->rt_pmtu;
+ if (rt->rt_mtu_locked && expires)
+ metrics[RTAX_LOCK - 1] |= BIT(RTAX_MTU);
if (rtnetlink_put_metrics(skb, metrics) < 0)
goto nla_put_failure;

--- a/net/ipv4/xfrm4_policy.c
+++ b/net/ipv4/xfrm4_policy.c
@@ -97,6 +97,7 @@ static int xfrm4_fill_dst(struct xfrm_ds
xdst->u.rt.rt_gateway = rt->rt_gateway;
xdst->u.rt.rt_uses_gateway = rt->rt_uses_gateway;
xdst->u.rt.rt_pmtu = rt->rt_pmtu;
+ xdst->u.rt.rt_mtu_locked = rt->rt_mtu_locked;
xdst->u.rt.rt_table_id = rt->rt_table_id;
INIT_LIST_HEAD(&xdst->u.rt.rt_uncached);




2018-05-28 15:28:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 134/268] workqueue: use put_device() instead of kfree()

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

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

From: Arvind Yadav <[email protected]>

[ Upstream commit 537f4146c53c95aac977852b371bafb9c6755ee1 ]

Never directly free @dev after calling device_register(), even
if it returned an error! Always use put_device() to give up the
reference initialized in this function instead.

Signed-off-by: Arvind Yadav <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/workqueue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -5199,7 +5199,7 @@ int workqueue_sysfs_register(struct work

ret = device_register(&wq_dev->dev);
if (ret) {
- kfree(wq_dev);
+ put_device(&wq_dev->dev);
wq->wq_dev = NULL;
return ret;
}



2018-05-28 15:28:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 141/268] vti4: Dont override MTU passed on link creation via IFLA_MTU

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

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

From: Stefano Brivio <[email protected]>

[ Upstream commit 03080e5ec72740c1a62e6730f2a5f3f114f11b19 ]

Don't hardcode a MTU value on vti tunnel initialization,
ip_tunnel_newlink() is able to deal with this already. See also
commit ffc2b6ee4174 ("ip_gre: fix IFLA_MTU ignored on NEWLINK").

Fixes: 1181412c1a67 ("net/ipv4: VTI support new module for ip_vti.")
Signed-off-by: Stefano Brivio <[email protected]>
Acked-by: Sabrina Dubroca <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/ip_vti.c | 1 -
1 file changed, 1 deletion(-)

--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -366,7 +366,6 @@ static int vti_tunnel_init(struct net_de
memcpy(dev->dev_addr, &iph->saddr, 4);
memcpy(dev->broadcast, &iph->daddr, 4);

- dev->mtu = ETH_DATA_LEN;
dev->flags = IFF_NOARP;
dev->addr_len = 4;
dev->features |= NETIF_F_LLTX;



2018-05-28 15:28:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 132/268] netfilter: ebtables: fix erroneous reject of last rule

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

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

From: Florian Westphal <[email protected]>

[ Upstream commit 932909d9b28d27e807ff8eecb68c7748f6701628 ]

The last rule in the blob has next_entry offset that is same as total size.
This made "ebtables32 -A OUTPUT -d de:ad:be:ef:01:02" fail on 64 bit kernel.

Fixes: b71812168571fa ("netfilter: ebtables: CONFIG_COMPAT: don't trust userland offsets")
Signed-off-by: Florian Westphal <[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/bridge/netfilter/ebtables.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -2088,8 +2088,12 @@ static int size_entry_mwt(struct ebt_ent
* offsets are relative to beginning of struct ebt_entry (i.e., 0).
*/
for (i = 0; i < 4 ; ++i) {
- if (offsets[i] >= *total)
+ if (offsets[i] > *total)
return -EINVAL;
+
+ if (i < 3 && offsets[i] == *total)
+ return -EINVAL;
+
if (i == 0)
continue;
if (offsets[i-1] > offsets[i])



2018-05-28 15:29:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 133/268] bnxt_en: Check valid VNIC ID in bnxt_hwrm_vnic_set_tpa().

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

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

From: Michael Chan <[email protected]>

[ Upstream commit 3c4fe80b32c685bdc02b280814d0cfe80d441c72 ]

During initialization, if we encounter errors, there is a code path that
calls bnxt_hwrm_vnic_set_tpa() with invalid VNIC ID. This may cause a
warning in firmware logs.

Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Michael Chan <[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/broadcom/bnxt/bnxt.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -2925,6 +2925,9 @@ static int bnxt_hwrm_vnic_set_tpa(struct
struct bnxt_vnic_info *vnic = &bp->vnic_info[vnic_id];
struct hwrm_vnic_tpa_cfg_input req = {0};

+ if (vnic->fw_vnic_id == INVALID_HW_RING_ID)
+ return 0;
+
bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_VNIC_TPA_CFG, -1, -1);

if (tpa_flags) {



2018-05-28 15:29:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 138/268] net: Fix vlan untag for bridge and vlan_dev with reorder_hdr off

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

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

From: Toshiaki Makita <[email protected]>

[ Upstream commit 4bbb3e0e8239f9079bf1fe20b3c0cb598714ae61 ]

When we have a bridge with vlan_filtering on and a vlan device on top of
it, packets would be corrupted in skb_vlan_untag() called from
br_dev_xmit().

The problem sits in skb_reorder_vlan_header() used in skb_vlan_untag(),
which makes use of skb->mac_len. In this function mac_len is meant for
handling rx path with vlan devices with reorder_header disabled, but in
tx path mac_len is typically 0 and cannot be used, which is the problem
in this case.

The current code even does not properly handle rx path (skb_vlan_untag()
called from __netif_receive_skb_core()) with reorder_header off actually.

In rx path single tag case, it works as follows:

- Before skb_reorder_vlan_header()

mac_header data
v v
+-------------------+-------------+------+----
| ETH | VLAN | ETH |
| ADDRS | TPID | TCI | TYPE |
+-------------------+-------------+------+----
<-------- mac_len --------->
<------------->
to be removed

- After skb_reorder_vlan_header()

mac_header data
v v
+-------------------+------+----
| ETH | ETH |
| ADDRS | TYPE |
+-------------------+------+----
<-------- mac_len --------->

This is ok, but in rx double tag case, it corrupts packets:

- Before skb_reorder_vlan_header()

mac_header data
v v
+-------------------+-------------+-------------+------+----
| ETH | VLAN | VLAN | ETH |
| ADDRS | TPID | TCI | TPID | TCI | TYPE |
+-------------------+-------------+-------------+------+----
<--------------- mac_len ---------------->
<------------->
should be removed
<--------------------------->
actually will be removed

- After skb_reorder_vlan_header()

mac_header data
v v
+-------------------+------+----
| ETH | ETH |
| ADDRS | TYPE |
+-------------------+------+----
<--------------- mac_len ---------------->

So, two of vlan tags are both removed while only inner one should be
removed and mac_header (and mac_len) is broken.

skb_vlan_untag() is meant for removing the vlan header at (skb->data - 2),
so use skb->data and skb->mac_header to calculate the right offset.

Reported-by: Brandon Carpenter <[email protected]>
Fixes: a6e18ff11170 ("vlan: Fix untag operations of stacked vlans with REORDER_HEADER off")
Signed-off-by: Toshiaki Makita <[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]>
---
include/uapi/linux/if_ether.h | 1 +
net/core/skbuff.c | 7 +++++--
2 files changed, 6 insertions(+), 2 deletions(-)

--- a/include/uapi/linux/if_ether.h
+++ b/include/uapi/linux/if_ether.h
@@ -29,6 +29,7 @@
*/

#define ETH_ALEN 6 /* Octets in one ethernet addr */
+#define ETH_TLEN 2 /* Octets in ethernet type field */
#define ETH_HLEN 14 /* Total octets in header. */
#define ETH_ZLEN 60 /* Min. octets in frame sans FCS */
#define ETH_DATA_LEN 1500 /* Max. octets in payload */
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4295,13 +4295,16 @@ EXPORT_SYMBOL_GPL(skb_gso_transport_segl

static struct sk_buff *skb_reorder_vlan_header(struct sk_buff *skb)
{
+ int mac_len;
+
if (skb_cow(skb, skb_headroom(skb)) < 0) {
kfree_skb(skb);
return NULL;
}

- memmove(skb->data - ETH_HLEN, skb->data - skb->mac_len - VLAN_HLEN,
- 2 * ETH_ALEN);
+ mac_len = skb->data - skb_mac_header(skb);
+ memmove(skb_mac_header(skb) + VLAN_HLEN, skb_mac_header(skb),
+ mac_len - VLAN_HLEN - ETH_TLEN);
skb->mac_header += VLAN_HLEN;
return skb;
}



2018-05-28 15:29:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 130/268] xen: xenbus: use put_device() instead of kfree()

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

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

From: Arvind Yadav <[email protected]>

[ Upstream commit 351b2bccede1cb673ec7957b35ea997ea24c8884 ]

Never directly free @dev after calling device_register(), even
if it returned an error! Always use put_device() to give up the
reference initialized.

Signed-off-by: Arvind Yadav <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/xen/xenbus/xenbus_probe.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -470,8 +470,11 @@ int xenbus_probe_node(struct xen_bus_typ

/* Register with generic device framework. */
err = device_register(&xendev->dev);
- if (err)
+ if (err) {
+ put_device(&xendev->dev);
+ xendev = NULL;
goto fail;
+ }

return 0;
fail:



2018-05-28 15:29:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 131/268] USB: OHCI: Fix NULL dereference in HCDs using HCD_LOCAL_MEM

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

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

From: Fredrik Noring <[email protected]>

[ Upstream commit d6c931ea32dc08ac2665bb5f009f9c40ad1bbdb3 ]

Scatter-gather needs to be disabled when using dma_declare_coherent_memory
and HCD_LOCAL_MEM. Andrea Righi made the equivalent fix for EHCI drivers
in commit 4307a28eb01284 "USB: EHCI: fix NULL pointer dererence in HCDs
that use HCD_LOCAL_MEM".

The following NULL pointer WARN_ON_ONCE triggered with OHCI drivers:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 49 at drivers/usb/core/hcd.c:1379 hcd_alloc_coherent+0x4c/0xc8
Modules linked in:
CPU: 0 PID: 49 Comm: usb-storage Not tainted 4.15.0+ #1014
Stack : 00000000 00000000 805a78d2 0000003a 81f5c2cc 8053d367 804d77fc 00000031
805a3a08 00000563 81ee9400 805a0000 00000000 10058c00 81f61b10 805c0000
00000000 00000000 805a0000 00d9038e 00000004 803ee818 00000006 312e3420
805c0000 00000000 00000073 81f61958 00000000 00000000 802eb380 804fd538
00000009 00000563 81ee9400 805a0000 00000002 80056148 00000000 805a0000
...
Call Trace:
[<578af360>] show_stack+0x74/0x104
[<2f3702c6>] __warn+0x118/0x120
[<ae93fc9e>] warn_slowpath_null+0x44/0x58
[<a891a517>] hcd_alloc_coherent+0x4c/0xc8
[<3578fa36>] usb_hcd_map_urb_for_dma+0x4d8/0x534
[<110bc94c>] usb_hcd_submit_urb+0x82c/0x834
[<02eb5baf>] usb_sg_wait+0x14c/0x1a0
[<ccd09e85>] usb_stor_bulk_transfer_sglist.part.1+0xac/0x124
[<87a5c34c>] usb_stor_bulk_srb+0x40/0x60
[<ff1792ac>] usb_stor_Bulk_transport+0x160/0x37c
[<b9e2709c>] usb_stor_invoke_transport+0x3c/0x500
[<004754f4>] usb_stor_control_thread+0x258/0x28c
[<22edf42e>] kthread+0x134/0x13c
[<a419ffd0>] ret_from_kernel_thread+0x14/0x1c
---[ end trace bcdb825805eefdcc ]---

Signed-off-by: Fredrik Noring <[email protected]>
Acked-by: Alan Stern <[email protected]>


Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/ohci-hcd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -444,7 +444,8 @@ static int ohci_init (struct ohci_hcd *o
struct usb_hcd *hcd = ohci_to_hcd(ohci);

/* Accept arbitrarily long scatter-gather lists */
- hcd->self.sg_tablesize = ~0;
+ if (!(hcd->driver->flags & HCD_LOCAL_MEM))
+ hcd->self.sg_tablesize = ~0;

if (distrust_firmware)
ohci->flags |= OHCI_QUIRK_HUB_POWER;



2018-05-28 15:29:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 112/268] r8152: fix tx packets accounting

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

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

From: Eric Dumazet <[email protected]>

[ Upstream commit 4c27bf3c5b7434ccb9ab962301da661c26b467a4 ]

r8152 driver handles TSO packets (limited to ~16KB) quite well,
but pretends each TSO logical packet is a single packet on the wire.

There is also some error since headers are accounted once, but
error rate is small enough that we do not care.

Signed-off-by: Eric Dumazet <[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/usb/r8152.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1610,7 +1610,7 @@ static int r8152_tx_agg_fill(struct r815

tx_data += len;
agg->skb_len += len;
- agg->skb_num++;
+ agg->skb_num += skb_shinfo(skb)->gso_segs ?: 1;

dev_kfree_skb_any(skb);




2018-05-28 15:30:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 128/268] scsi: sd: Keep disk read-only when re-reading partition

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

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

From: Jeremy Cline <[email protected]>

[ Upstream commit 20bd1d026aacc5399464f8328f305985c493cde3 ]

If the read-only flag is true on a SCSI disk, re-reading the partition
table sets the flag back to false.

To observe this bug, you can run:

1. blockdev --setro /dev/sda
2. blockdev --rereadpt /dev/sda
3. blockdev --getro /dev/sda

This commit reads the disk's old state and combines it with the device
disk-reported state rather than unconditionally marking it as RW.

Reported-by: Li Ning <[email protected]>
Signed-off-by: Jeremy Cline <[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/sd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2395,6 +2395,7 @@ sd_read_write_protect_flag(struct scsi_d
int res;
struct scsi_device *sdp = sdkp->device;
struct scsi_mode_data data;
+ int disk_ro = get_disk_ro(sdkp->disk);
int old_wp = sdkp->write_prot;

set_disk_ro(sdkp->disk, 0);
@@ -2435,7 +2436,7 @@ sd_read_write_protect_flag(struct scsi_d
"Test WP failed, assume Write Enabled\n");
} else {
sdkp->write_prot = ((data.device_specific & 0x80) != 0);
- set_disk_ro(sdkp->disk, sdkp->write_prot);
+ set_disk_ro(sdkp->disk, sdkp->write_prot || disk_ro);
if (sdkp->first_scan || old_wp != sdkp->write_prot) {
sd_printk(KERN_NOTICE, sdkp, "Write Protect is %s\n",
sdkp->write_prot ? "on" : "off");



2018-05-28 15:30:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 129/268] fbdev: Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in sbusfb_ioctl_helper().

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

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

From: Peter Malone <[email protected]>

[ Upstream commit 250c6c49e3b68756b14983c076183568636e2bde ]

Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in
sbusfb_ioctl_helper().

'index' is defined as an int in sbusfb_ioctl_helper().
We retrieve this from the user:
if (get_user(index, &c->index) ||
__get_user(count, &c->count) ||
__get_user(ured, &c->red) ||
__get_user(ugreen, &c->green) ||
__get_user(ublue, &c->blue))
return -EFAULT;

and then we use 'index' in the following way:
red = cmap->red[index + i] >> 8;
green = cmap->green[index + i] >> 8;
blue = cmap->blue[index + i] >> 8;

This is a classic information leak vulnerability. 'index' should be
an unsigned int, given its usage above.

This patch is straight-forward; it changes 'index' to unsigned int
in two switch-cases: FBIOGETCMAP_SPARC && FBIOPUTCMAP_SPARC.

This patch fixes CVE-2018-6412.

Signed-off-by: Peter Malone <[email protected]>
Acked-by: Mathieu Malaterre <[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/sbuslib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/video/fbdev/sbuslib.c
+++ b/drivers/video/fbdev/sbuslib.c
@@ -121,7 +121,7 @@ int sbusfb_ioctl_helper(unsigned long cm
unsigned char __user *ured;
unsigned char __user *ugreen;
unsigned char __user *ublue;
- int index, count, i;
+ unsigned int index, count, i;

if (get_user(index, &c->index) ||
__get_user(count, &c->count) ||
@@ -160,7 +160,7 @@ int sbusfb_ioctl_helper(unsigned long cm
unsigned char __user *ugreen;
unsigned char __user *ublue;
struct fb_cmap *cmap = &info->cmap;
- int index, count, i;
+ unsigned int index, count, i;
u8 red, green, blue;

if (get_user(index, &c->index) ||



2018-05-28 15:30:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 124/268] e1000e: Fix check_for_link return value with autoneg off

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

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

From: Benjamin Poirier <[email protected]>

[ Upstream commit 4e7dc08e57c95673d2edaba8983c3de4dd1f65f5 ]

When autoneg is off, the .check_for_link callback functions clear the
get_link_status flag and systematically return a "pseudo-error". This means
that the link is not detected as up until the next execution of the
e1000_watchdog_task() 2 seconds later.

Fixes: 19110cfbb34d ("e1000e: Separate signaling for link check/link up")
Signed-off-by: Benjamin Poirier <[email protected]>
Acked-by: Sasha Neftin <[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/ich8lan.c | 2 +-
drivers/net/ethernet/intel/e1000e/mac.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -1574,7 +1574,7 @@ static s32 e1000_check_for_copper_link_i
* we have already determined whether we have link or not.
*/
if (!mac->autoneg)
- return -E1000_ERR_CONFIG;
+ return 1;

/* Auto-Neg is enabled. Auto Speed Detection takes care
* of MAC speed/duplex configuration. So we only need to
--- a/drivers/net/ethernet/intel/e1000e/mac.c
+++ b/drivers/net/ethernet/intel/e1000e/mac.c
@@ -450,7 +450,7 @@ s32 e1000e_check_for_copper_link(struct
* we have already determined whether we have link or not.
*/
if (!mac->autoneg)
- return -E1000_ERR_CONFIG;
+ return 1;

/* Auto-Neg is enabled. Auto Speed Detection takes care
* of MAC speed/duplex configuration. So we only need to



2018-05-28 15:30:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 125/268] e1000e: allocate ring descriptors with dma_zalloc_coherent

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

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

From: Pierre-Yves Kerbrat <[email protected]>

[ Upstream commit aea3fca005fb45f80869f2e8d56fd4e64c1d1fdb ]

Descriptor rings were not initialized at zero when allocated
When area contained garbage data, it caused skb_over_panic in
e1000_clean_rx_irq (if data had E1000_RXD_STAT_DD bit set)

This patch makes use of dma_zalloc_coherent to make sure the
ring is memset at 0 to prevent the area from containing garbage.

Following is the signature of the panic:
[email protected]: skbuff: skb_over_panic: text:80407b20 len:64010 put:64010 head:ab46d800 data:ab46d842 tail:0xab47d24c end:0xab46df40 dev:eth0
[email protected]: BUG: failure at net/core/skbuff.c:105/skb_panic()!
[email protected]: Kernel panic - not syncing: BUG!
[email protected]:
[email protected]: Process swapper/0 (pid: 0, threadinfo=81728000, task=8173cc00 ,cpu: 0)
[email protected]: SP = <815a1c0c>
[email protected]: Stack: 00000001
[email protected]: b2d89800 815e33ac
[email protected]: ea73c040 00000001
[email protected]: 60040003 0000fa0a
[email protected]: 00000002
[email protected]:
[email protected]: 804540c0 815a1c70
[email protected]: b2744000 602ac070
[email protected]: 815a1c44 b2d89800
[email protected]: 8173cc00 815a1c08
[email protected]:
[email protected]: 00000006
[email protected]: 815a1b50 00000000
[email protected]: 80079434 00000001
[email protected]: ab46df40 b2744000
[email protected]: b2d89800
[email protected]:
[email protected]: 0000fa0a 8045745c
[email protected]: 815a1c88 0000fa0a
[email protected]: 80407b20 b2789f80
[email protected]: 00000005 80407b20
[email protected]:
[email protected]:
[email protected]: Call Trace:
[email protected]: [<804540bc>] skb_panic+0xa4/0xa8
[email protected]: [<80079430>] console_unlock+0x2f8/0x6d0
[email protected]: [<80457458>] skb_put+0xa0/0xc0
[email protected]: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
[email protected]: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
[email protected]: [<804079c8>] e1000_clean_rx_irq+0x188/0x3e8
[email protected]: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
[email protected]: [<80468b48>] __dev_kfree_skb_any+0x88/0xa8
[email protected]: [<804101ac>] e1000e_poll+0x94/0x288
[email protected]: [<8046e9d4>] net_rx_action+0x19c/0x4e8
[email protected]: ...
[email protected]: Maximum depth to print reached. Use kstack=<maximum_depth_to_print> To specify a custom value (where 0 means to display the full backtrace)
[email protected]: ---[ end Kernel panic - not syncing: BUG!

Signed-off-by: Pierre-Yves Kerbrat <[email protected]>
Signed-off-by: Marius Gligor <[email protected]>
Tested-by: Aaron Brown <[email protected]>
Reviewed-by: Alexander Duyck <[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 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -2330,8 +2330,8 @@ static int e1000_alloc_ring_dma(struct e
{
struct pci_dev *pdev = adapter->pdev;

- ring->desc = dma_alloc_coherent(&pdev->dev, ring->size, &ring->dma,
- GFP_KERNEL);
+ ring->desc = dma_zalloc_coherent(&pdev->dev, ring->size, &ring->dma,
+ GFP_KERNEL);
if (!ring->desc)
return -ENOMEM;




2018-05-28 15:31:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 127/268] scsi: mpt3sas: Do not mark fw_event workqueue as WQ_MEM_RECLAIM

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

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

From: Hannes Reinecke <[email protected]>

[ Upstream commit 864449eea7c600596e305ffdc4a6a846414b222c ]

The firmware event workqueue should not be marked as WQ_MEM_RECLAIM
as it's doesn't need to make forward progress under memory pressure.
In the current state it will result in a deadlock if the device had been
forcefully removed.

Cc: Sreekanth Reddy <[email protected]>
Cc: Suganath Prabu Subramani <[email protected]>
Acked-by: Sreekanth Reddy <[email protected]>
Signed-off-by: Hannes Reinecke <[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/mpt3sas/mpt3sas_scsih.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -8637,7 +8637,7 @@ _scsih_probe(struct pci_dev *pdev, const
snprintf(ioc->firmware_event_name, sizeof(ioc->firmware_event_name),
"fw_event_%s%d", ioc->driver_name, ioc->id);
ioc->firmware_event_thread = alloc_ordered_workqueue(
- ioc->firmware_event_name, WQ_MEM_RECLAIM);
+ ioc->firmware_event_name, 0);
if (!ioc->firmware_event_thread) {
pr_err(MPT3SAS_FMT "failure at %s:%d/%s()!\n",
ioc->name, __FILE__, __LINE__, __func__);



2018-05-28 15:31:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 126/268] usb: musb: call pm_runtime_{get,put}_sync before reading vbus registers

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

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

From: Merlijn Wajer <[email protected]>

[ Upstream commit df6b074dbe248d8c43a82131e8fd429e401841a5 ]

Without pm_runtime_{get,put}_sync calls in place, reading
vbus status via /sys causes the following error:

Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0ab060
pgd = b333e822
[fa0ab060] *pgd=48011452(bad)

[<c05261b0>] (musb_default_readb) from [<c0525bd0>] (musb_vbus_show+0x58/0xe4)
[<c0525bd0>] (musb_vbus_show) from [<c04c0148>] (dev_attr_show+0x20/0x44)
[<c04c0148>] (dev_attr_show) from [<c0259f74>] (sysfs_kf_seq_show+0x80/0xdc)
[<c0259f74>] (sysfs_kf_seq_show) from [<c0210bac>] (seq_read+0x250/0x448)
[<c0210bac>] (seq_read) from [<c01edb40>] (__vfs_read+0x1c/0x118)
[<c01edb40>] (__vfs_read) from [<c01edccc>] (vfs_read+0x90/0x144)
[<c01edccc>] (vfs_read) from [<c01ee1d0>] (SyS_read+0x3c/0x74)
[<c01ee1d0>] (SyS_read) from [<c0106fe0>] (ret_fast_syscall+0x0/0x54)

Solution was suggested by Tony Lindgren <[email protected]>.

Signed-off-by: Merlijn Wajer <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Bin Liu <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/musb/musb_core.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1775,6 +1775,7 @@ musb_vbus_show(struct device *dev, struc
int vbus;
u8 devctl;

+ pm_runtime_get_sync(dev);
spin_lock_irqsave(&musb->lock, flags);
val = musb->a_wait_bcon;
vbus = musb_platform_get_vbus_status(musb);
@@ -1788,6 +1789,7 @@ musb_vbus_show(struct device *dev, struc
vbus = 0;
}
spin_unlock_irqrestore(&musb->lock, flags);
+ pm_runtime_put_sync(dev);

return sprintf(buf, "Vbus %s, timeout %lu msec\n",
vbus ? "on" : "off", val);



2018-05-28 15:31:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 123/268] watchdog: f71808e_wdt: Fix magic close handling

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

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

From: Igor Pylypiv <[email protected]>

[ Upstream commit 7bd3e7b743956afbec30fb525bc3c5e22e3d475c ]

Watchdog close is "expected" when any byte is 'V' not just the last one.
Writing "V" to the device fails because the last byte is the end of string.

$ echo V > /dev/watchdog
f71808e_wdt: Unexpected close, not stopping watchdog!

Signed-off-by: Igor Pylypiv <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Wim Van Sebroeck <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/watchdog/f71808e_wdt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/watchdog/f71808e_wdt.c
+++ b/drivers/watchdog/f71808e_wdt.c
@@ -520,7 +520,8 @@ static ssize_t watchdog_write(struct fil
char c;
if (get_user(c, buf + i))
return -EFAULT;
- expect_close = (c == 'V');
+ if (c == 'V')
+ expect_close = true;
}

/* Properly order writes across fork()ed processes */



2018-05-28 15:31:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 111/268] clocksource/drivers/fsl_ftm_timer: Fix error return checking

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

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

From: Colin Ian King <[email protected]>

[ Upstream commit f287eb9013ccf199cbfa4eabd80c36fedfc15a73 ]

The error checks on freq for a negative error return always fails because
freq is unsigned and can never be negative. Fix this by making freq a
signed long.

Detected with Coccinelle:
drivers/clocksource/fsl_ftm_timer.c:287:5-9: WARNING: Unsigned expression
compared with zero: freq <= 0
drivers/clocksource/fsl_ftm_timer.c:291:5-9: WARNING: Unsigned expression
compared with zero: freq <= 0

Fixes: 2529c3a33079 ("clocksource: Add Freescale FlexTimer Module (FTM) timer support")
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/clocksource/fsl_ftm_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/clocksource/fsl_ftm_timer.c
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -281,7 +281,7 @@ static int __init __ftm_clk_init(struct

static unsigned long __init ftm_clk_init(struct device_node *np)
{
- unsigned long freq;
+ long freq;

freq = __ftm_clk_init(np, "ftm-evt-counter-en", "ftm-evt");
if (freq <= 0)



2018-05-28 15:31:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 122/268] KVM: PPC: Book3S HV: Fix VRMA initialization with 2MB or 1GB memory backing

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

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

From: Paul Mackerras <[email protected]>

[ Upstream commit debd574f4195e205ba505b25e19b2b797f4bcd94 ]

The current code for initializing the VRMA (virtual real memory area)
for HPT guests requires the page size of the backing memory to be one
of 4kB, 64kB or 16MB. With a radix host we have the possibility that
the backing memory page size can be 2MB or 1GB. In these cases, if the
guest switches to HPT mode, KVM will not initialize the VRMA and the
guest will fail to run.

In fact it is not necessary that the VRMA page size is the same as the
backing memory page size; any VRMA page size less than or equal to the
backing memory page size is acceptable. Therefore we now choose the
largest page size out of the set {4k, 64k, 16M} which is not larger
than the backing memory page size.

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_hv.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)

--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -3002,15 +3002,17 @@ static int kvmppc_hv_setup_htab_rma(stru
goto up_out;

psize = vma_kernel_pagesize(vma);
- porder = __ilog2(psize);

up_read(&current->mm->mmap_sem);

/* We can handle 4k, 64k or 16M pages in the VRMA */
- err = -EINVAL;
- if (!(psize == 0x1000 || psize == 0x10000 ||
- psize == 0x1000000))
- goto out_srcu;
+ if (psize >= 0x1000000)
+ psize = 0x1000000;
+ else if (psize >= 0x10000)
+ psize = 0x10000;
+ else
+ psize = 0x1000;
+ porder = __ilog2(psize);

/* Update VRMASD field in the LPCR */
senc = slb_pgsize_encoding(psize);



2018-05-28 15:32:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 076/268] scsi: qla2xxx: Avoid triggering undefined behavior in qla2x00_mbx_completion()

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

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

From: Bart Van Assche <[email protected]>

[ Upstream commit c02189e12ce3bf3808cb880569d3b10249f50bd9 ]

A left shift must shift less than the bit width of the left argument.
Avoid triggering undefined behavior if ha->mbx_count == 32.

This patch avoids that UBSAN reports the following complaint:

UBSAN: Undefined behaviour in drivers/scsi/qla2xxx/qla_isr.c:275:14
shift exponent 32 is too large for 32-bit type 'int'
Call Trace:
dump_stack+0x4e/0x6c
ubsan_epilogue+0xd/0x3b
__ubsan_handle_shift_out_of_bounds+0x112/0x14c
qla2x00_mbx_completion+0x1c5/0x25d [qla2xxx]
qla2300_intr_handler+0x1ea/0x3bb [qla2xxx]
qla2x00_mailbox_command+0x77b/0x139a [qla2xxx]
qla2x00_mbx_reg_test+0x83/0x114 [qla2xxx]
qla2x00_chip_diag+0x354/0x45f [qla2xxx]
qla2x00_initialize_adapter+0x2c2/0xa4e [qla2xxx]
qla2x00_probe_one+0x1681/0x392e [qla2xxx]
pci_device_probe+0x10b/0x1f1
driver_probe_device+0x21f/0x3a4
__driver_attach+0xa9/0xe1
bus_for_each_dev+0x6e/0xb5
driver_attach+0x22/0x3c
bus_add_driver+0x1d1/0x2ae
driver_register+0x78/0x130
__pci_register_driver+0x75/0xa8
qla2x00_module_init+0x21b/0x267 [qla2xxx]
do_one_initcall+0x5a/0x1e2
do_init_module+0x9d/0x285
load_module+0x20db/0x38e3
SYSC_finit_module+0xa8/0xbc
SyS_finit_module+0x9/0xb
do_syscall_64+0x77/0x271
entry_SYSCALL64_slow_path+0x25/0x25

Reported-by: Meelis Roos <[email protected]>
Signed-off-by: Bart Van Assche <[email protected]>
Cc: Himanshu Madhani <[email protected]>
Reviewed-by: Laurence Oberman <[email protected]>
Acked-by: Himanshu Madhani <[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/qla2xxx/qla_isr.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -268,7 +268,8 @@ qla2x00_mbx_completion(scsi_qla_host_t *
struct device_reg_2xxx __iomem *reg = &ha->iobase->isp;

/* Read all mbox registers? */
- mboxes = (1 << ha->mbx_count) - 1;
+ WARN_ON_ONCE(ha->mbx_count > 32);
+ mboxes = (1ULL << ha->mbx_count) - 1;
if (!ha->mcp)
ql_dbg(ql_dbg_async, vha, 0x5001, "MBX pointer ERROR.\n");
else
@@ -2495,7 +2496,8 @@ qla24xx_mbx_completion(scsi_qla_host_t *
struct device_reg_24xx __iomem *reg = &ha->iobase->isp24;

/* Read all mbox registers? */
- mboxes = (1 << ha->mbx_count) - 1;
+ WARN_ON_ONCE(ha->mbx_count > 32);
+ mboxes = (1ULL << ha->mbx_count) - 1;
if (!ha->mcp)
ql_dbg(ql_dbg_async, vha, 0x504e, "MBX pointer ERROR.\n");
else



2018-05-28 15:32:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 085/268] ARM: OMAP2+: timer: fix a kmemleak caused in omap_get_timer_dt

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

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

From: Qi Hou <[email protected]>

[ Upstream commit db35340c536f1af0108ec9a0b2126a05d358d14a ]

When more than one GP timers are used as kernel system timers and the
corresponding nodes in device-tree are marked with the same "disabled"
property, then the "attr" field of the property will be initialized
more than once as the property being added to sys file system via
__of_add_property_sysfs().

In __of_add_property_sysfs(), the "name" field of pp->attr.attr is set
directly to the return value of safe_name(), without taking care of
whether it's already a valid pointer to a memory block. If it is, its
old value will always be overwritten by the new one and the memory block
allocated before will a "ghost", then a kmemleak happened.

That the same "disabled" property being added to different nodes of device
tree would cause that kind of kmemleak overhead, at least once.

To fix it, allocate the property dynamically, and delete static one.

Signed-off-by: Qi Hou <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/mach-omap2/timer.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)

--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -136,12 +136,6 @@ static struct clock_event_device clockev
.tick_resume = omap2_gp_timer_shutdown,
};

-static struct property device_disabled = {
- .name = "status",
- .length = sizeof("disabled"),
- .value = "disabled",
-};
-
static const struct of_device_id omap_timer_match[] __initconst = {
{ .compatible = "ti,omap2420-timer", },
{ .compatible = "ti,omap3430-timer", },
@@ -183,8 +177,17 @@ static struct device_node * __init omap_
of_get_property(np, "ti,timer-secure", NULL)))
continue;

- if (!of_device_is_compatible(np, "ti,omap-counter32k"))
- of_add_property(np, &device_disabled);
+ if (!of_device_is_compatible(np, "ti,omap-counter32k")) {
+ struct property *prop;
+
+ prop = kzalloc(sizeof(*prop), GFP_KERNEL);
+ if (!prop)
+ return NULL;
+ prop->name = "status";
+ prop->value = "disabled";
+ prop->length = strlen(prop->value);
+ of_add_property(np, prop);
+ }
return np;
}




2018-05-28 15:32:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 082/268] scsi: storvsc: Increase cmd_per_lun for higher speed devices

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

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

From: "Michael Kelley (EOSG)" <[email protected]>

[ Upstream commit cabe92a55e3a12005a4ac4d3954c9a174b0efe2a ]

Increase cmd_per_lun to allow more I/Os in progress per device,
particularly for NVMe's. The Hyper-V host side can handle the higher
count with no issues.

Signed-off-by: Michael Kelley <[email protected]>
Reviewed-by: K. Y. Srinivasan <[email protected]>
Acked-by: K. Y. Srinivasan <[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/storvsc_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1538,7 +1538,7 @@ static struct scsi_host_template scsi_dr
.eh_timed_out = storvsc_eh_timed_out,
.slave_alloc = storvsc_device_alloc,
.slave_configure = storvsc_device_configure,
- .cmd_per_lun = 255,
+ .cmd_per_lun = 2048,
.this_id = -1,
.use_clustering = ENABLE_CLUSTERING,
/* Make sure we dont get a sg segment crosses a page boundary */



2018-05-28 15:32:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 083/268] scsi: aacraid: fix shutdown crash when init fails

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

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

From: Meelis Roos <[email protected]>

[ Upstream commit 00c20cdc79259c6c5bf978b21af96c2d3edb646d ]

When aacraid init fails with "AAC0: adapter self-test failed.", shutdown
leads to UBSAN warning and then oops:

[154316.118423] ================================================================================
[154316.118508] UBSAN: Undefined behaviour in drivers/scsi/scsi_lib.c:2328:27
[154316.118566] member access within null pointer of type 'struct Scsi_Host'
[154316.118631] CPU: 2 PID: 14530 Comm: reboot Tainted: G W 4.15.0-dirty #89
[154316.118701] Hardware name: Hewlett Packard HP NetServer/HP System Board, BIOS 4.06.46 PW 06/25/2003
[154316.118774] Call Trace:
[154316.118848] dump_stack+0x48/0x65
[154316.118916] ubsan_epilogue+0xe/0x40
[154316.118976] __ubsan_handle_type_mismatch+0xfb/0x180
[154316.119043] scsi_block_requests+0x20/0x30
[154316.119135] aac_shutdown+0x18/0x40 [aacraid]
[154316.119196] pci_device_shutdown+0x33/0x50
[154316.119269] device_shutdown+0x18a/0x390
[...]
[154316.123435] BUG: unable to handle kernel NULL pointer dereference at 000000f4
[154316.123515] IP: scsi_block_requests+0xa/0x30

This is because aac_shutdown() does

struct Scsi_Host *shost = pci_get_drvdata(dev);
scsi_block_requests(shost);

and that assumes shost has been assigned with pci_set_drvdata().

However, pci_set_drvdata(pdev, shost) is done in aac_probe_one() far
after bailing out with error from calling the init function
((*aac_drivers[index].init)(aac)), and when the init function fails, no
error is returned from aac_probe_one() so PCI layer assumes there is
driver attached, and tries to shut it down later.

Fix it by returning error from aac_probe_one() when card-specific init
function fails.

This fixes reboot on my HP NetRAID-4M with dead battery.

Signed-off-by: Meelis Roos <[email protected]>
Reviewed-by: Dave Carroll <[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/aacraid/linit.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -1189,8 +1189,10 @@ static int aac_probe_one(struct pci_dev
* Map in the registers from the adapter.
*/
aac->base_size = AAC_MIN_FOOTPRINT_SIZE;
- if ((*aac_drivers[index].init)(aac))
+ if ((*aac_drivers[index].init)(aac)) {
+ error = -ENODEV;
goto out_unmap;
+ }

if (aac->sync_mode) {
if (aac_sync_mode)



2018-05-28 15:34:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 080/268] usb: dwc2: Fix dwc2_hsotg_core_init_disconnected()

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

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

From: Vardan Mikayelyan <[email protected]>

[ Upstream commit 755d739534f998d92e348fba8ffb0478416576e7 ]

We should call dwc2_hsotg_enqueue_setup() after properly
setting lx_state. Because it may cause error-out from
dwc2_hsotg_enqueue_setup() due to wrong value in lx_state.

Issue can be reproduced by loading driver while connected
A-Connector (start in A-HOST mode) then disconnect A-Connector
to switch to B-DEVICE.

Acked-by: John Youn <[email protected]>
Signed-off-by: Vardan Mikayelyan <[email protected]>
Signed-off-by: Grigor Tovmasyan <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/dwc2/gadget.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2424,12 +2424,6 @@ void dwc2_hsotg_core_init_disconnected(s
dwc2_writel(dwc2_hsotg_ep0_mps(hsotg->eps_out[0]->ep.maxpacket) |
DXEPCTL_USBACTEP, hsotg->regs + DIEPCTL0);

- dwc2_hsotg_enqueue_setup(hsotg);
-
- dev_dbg(hsotg->dev, "EP0: DIEPCTL0=0x%08x, DOEPCTL0=0x%08x\n",
- dwc2_readl(hsotg->regs + DIEPCTL0),
- dwc2_readl(hsotg->regs + DOEPCTL0));
-
/* clear global NAKs */
val = DCTL_CGOUTNAK | DCTL_CGNPINNAK;
if (!is_usb_reset)
@@ -2440,6 +2434,12 @@ void dwc2_hsotg_core_init_disconnected(s
mdelay(3);

hsotg->lx_state = DWC2_L0;
+
+ dwc2_hsotg_enqueue_setup(hsotg);
+
+ dev_dbg(hsotg->dev, "EP0: DIEPCTL0=0x%08x, DOEPCTL0=0x%08x\n",
+ dwc2_readl(hsotg->regs + DIEPCTL0),
+ dwc2_readl(hsotg->regs + DOEPCTL0));
}

static void dwc2_hsotg_core_disconnect(struct dwc2_hsotg *hsotg)



2018-05-28 15:34:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 108/268] batman-adv: invalidate checksum on fragment reassembly

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

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

From: Matthias Schiffer <[email protected]>

[ Upstream commit 3bf2a09da956b43ecfaa630a2ef9a477f991a46a ]

A more sophisticated implementation could try to combine fragment checksums
when all fragments have CHECKSUM_COMPLETE and are split at even offsets.
For now, we just set ip_summed to CHECKSUM_NONE to avoid "hw csum failure"
warnings in the kernel log when fragmented frames are received. In
consequence, skb_pull_rcsum() can be replaced with skb_pull().

Note that in usual setups, packets don't reach batman-adv with
CHECKSUM_COMPLETE (I assume NICs bail out of checksumming when they see
batadv's ethtype?), which is why the log messages do not occur on every
system using batman-adv. I could reproduce this issue by stacking
batman-adv on top of a VXLAN interface.

Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge")
Tested-by: Maximilian Wilhelm <[email protected]>
Signed-off-by: Matthias Schiffer <[email protected]>
Signed-off-by: Sven Eckelmann <[email protected]>
Signed-off-by: Simon Wunderlich <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/batman-adv/fragmentation.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/net/batman-adv/fragmentation.c
+++ b/net/batman-adv/fragmentation.c
@@ -278,7 +278,8 @@ batadv_frag_merge_packets(struct hlist_h
/* Move the existing MAC header to just before the payload. (Override
* the fragment header.)
*/
- skb_pull_rcsum(skb_out, hdr_size);
+ skb_pull(skb_out, hdr_size);
+ skb_out->ip_summed = CHECKSUM_NONE;
memmove(skb_out->data - ETH_HLEN, skb_mac_header(skb_out), ETH_HLEN);
skb_set_mac_header(skb_out, -ETH_HLEN);
skb_reset_network_header(skb_out);



2018-05-28 15:35:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 109/268] netfilter: ebtables: convert BUG_ONs to WARN_ONs

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

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

From: Florian Westphal <[email protected]>

[ Upstream commit fc6a5d0601c5ac1d02f283a46f60b87b2033e5ca ]

All of these conditions are not fatal and should have
been WARN_ONs from the get-go.

Convert them to WARN_ONs and bail out.

Signed-off-by: Florian Westphal <[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/bridge/netfilter/ebtables.c | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)

--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -1614,7 +1614,8 @@ static int compat_match_to_user(struct e
int off = ebt_compat_match_offset(match, m->match_size);
compat_uint_t msize = m->match_size - off;

- BUG_ON(off >= m->match_size);
+ if (WARN_ON(off >= m->match_size))
+ return -EINVAL;

if (copy_to_user(cm->u.name, match->name,
strlen(match->name) + 1) || put_user(msize, &cm->match_size))
@@ -1641,7 +1642,8 @@ static int compat_target_to_user(struct
int off = xt_compat_target_offset(target);
compat_uint_t tsize = t->target_size - off;

- BUG_ON(off >= t->target_size);
+ if (WARN_ON(off >= t->target_size))
+ return -EINVAL;

if (copy_to_user(cm->u.name, target->name,
strlen(target->name) + 1) || put_user(tsize, &cm->match_size))
@@ -1869,7 +1871,8 @@ static int ebt_buf_add(struct ebt_entrie
if (state->buf_kern_start == NULL)
goto count_only;

- BUG_ON(state->buf_kern_offset + sz > state->buf_kern_len);
+ if (WARN_ON(state->buf_kern_offset + sz > state->buf_kern_len))
+ return -EINVAL;

memcpy(state->buf_kern_start + state->buf_kern_offset, data, sz);

@@ -1882,7 +1885,8 @@ static int ebt_buf_add_pad(struct ebt_en
{
char *b = state->buf_kern_start;

- BUG_ON(b && state->buf_kern_offset > state->buf_kern_len);
+ if (WARN_ON(b && state->buf_kern_offset > state->buf_kern_len))
+ return -EINVAL;

if (b != NULL && sz > 0)
memset(b + state->buf_kern_offset, 0, sz);
@@ -1959,8 +1963,10 @@ static int compat_mtw_from_user(struct c
pad = XT_ALIGN(size_kern) - size_kern;

if (pad > 0 && dst) {
- BUG_ON(state->buf_kern_len <= pad);
- BUG_ON(state->buf_kern_offset - (match_size + off) + size_kern > state->buf_kern_len - pad);
+ if (WARN_ON(state->buf_kern_len <= pad))
+ return -EINVAL;
+ if (WARN_ON(state->buf_kern_offset - (match_size + off) + size_kern > state->buf_kern_len - pad))
+ return -EINVAL;
memset(dst + size_kern, 0, pad);
}
return off + match_size;
@@ -2011,7 +2017,8 @@ static int ebt_size_mwt(struct compat_eb
if (ret < 0)
return ret;

- BUG_ON(ret < match32->match_size);
+ if (WARN_ON(ret < match32->match_size))
+ return -EINVAL;
growth += ret - match32->match_size;
growth += ebt_compat_entry_padsize();

@@ -2121,7 +2128,8 @@ static int size_entry_mwt(struct ebt_ent

startoff = state->buf_user_offset - startoff;

- BUG_ON(*total < startoff);
+ if (WARN_ON(*total < startoff))
+ return -EINVAL;
*total -= startoff;
return 0;
}
@@ -2249,7 +2257,8 @@ static int compat_do_replace(struct net
state.buf_kern_len = size64;

ret = compat_copy_entries(entries_tmp, tmp.entries_size, &state);
- BUG_ON(ret < 0); /* parses same data again */
+ if (WARN_ON(ret < 0))
+ goto out_unlock;

vfree(entries_tmp);
tmp.entries_size = size64;



2018-05-28 15:35:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 106/268] md/raid1: fix NULL pointer dereference

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

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

From: Yufen Yu <[email protected]>

[ Upstream commit 3de59bb9d551428cbdc76a9ea57883f82e350b4d ]

In handle_write_finished(), if r1_bio->bios[m] != NULL, it thinks
the corresponding conf->mirrors[m].rdev is also not NULL. But, it
is not always true.

Even if some io hold replacement rdev(i.e. rdev->nr_pending.count > 0),
raid1_remove_disk() can also set the rdev as NULL. That means,
bios[m] != NULL, but mirrors[m].rdev is NULL, resulting in NULL
pointer dereference in handle_write_finished and sync_request_write.

This patch can fix BUGs as follows:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000140
IP: [<ffffffff815bbbbd>] raid1d+0x2bd/0xfc0
PGD 12ab52067 PUD 12f587067 PMD 0
Oops: 0000 [#1] SMP
CPU: 1 PID: 2008 Comm: md3_raid1 Not tainted 4.1.44+ #130
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014
Call Trace:
? schedule+0x37/0x90
? prepare_to_wait_event+0x83/0xf0
md_thread+0x144/0x150
? wake_atomic_t_function+0x70/0x70
? md_start_sync+0xf0/0xf0
kthread+0xd8/0xf0
? kthread_worker_fn+0x160/0x160
ret_from_fork+0x42/0x70
? kthread_worker_fn+0x160/0x160

BUG: unable to handle kernel NULL pointer dereference at 00000000000000b8
IP: sync_request_write+0x9e/0x980
PGD 800000007c518067 P4D 800000007c518067 PUD 8002b067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 24 PID: 2549 Comm: md3_raid1 Not tainted 4.15.0+ #118
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014
Call Trace:
? sched_clock+0x5/0x10
? sched_clock_cpu+0xc/0xb0
? flush_pending_writes+0x3a/0xd0
? pick_next_task_fair+0x4d5/0x5f0
? __switch_to+0xa2/0x430
raid1d+0x65a/0x870
? find_pers+0x70/0x70
? find_pers+0x70/0x70
? md_thread+0x11c/0x160
md_thread+0x11c/0x160
? finish_wait+0x80/0x80
kthread+0x111/0x130
? kthread_create_worker_on_cpu+0x70/0x70
? do_syscall_64+0x6f/0x190
? SyS_exit_group+0x10/0x10
ret_from_fork+0x35/0x40

Reviewed-by: NeilBrown <[email protected]>
Signed-off-by: Yufen Yu <[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/raid1.c | 11 +++++++++++
1 file changed, 11 insertions(+)

--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -1686,6 +1686,17 @@ static int raid1_remove_disk(struct mdde
struct md_rdev *repl =
conf->mirrors[conf->raid_disks + number].rdev;
freeze_array(conf, 0);
+ if (atomic_read(&repl->nr_pending)) {
+ /* It means that some queued IO of retry_list
+ * hold repl. Thus, we cannot set replacement
+ * as NULL, avoiding rdev NULL pointer
+ * dereference in sync_request_write and
+ * handle_write_finished.
+ */
+ err = -EBUSY;
+ unfreeze_array(conf);
+ goto abort;
+ }
clear_bit(Replacement, &repl->flags);
p->rdev = repl;
conf->mirrors[conf->raid_disks + number].rdev = NULL;



2018-05-28 15:35:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 103/268] locking/xchg/alpha: Fix xchg() and cmpxchg() memory ordering bugs

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

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

From: Andrea Parri <[email protected]>

[ Upstream commit 472e8c55cf6622d1c112dc2bc777f68bbd4189db ]

Successful RMW operations are supposed to be fully ordered, but
Alpha's xchg() and cmpxchg() do not meet this requirement.

Will Deacon noticed the bug:

> So MP using xchg:
>
> WRITE_ONCE(x, 1)
> xchg(y, 1)
>
> smp_load_acquire(y) == 1
> READ_ONCE(x) == 0
>
> would be allowed.

... which thus violates the above requirement.

Fix it by adding a leading smp_mb() to the xchg() and cmpxchg() implementations.

Reported-by: Will Deacon <[email protected]>
Signed-off-by: Andrea Parri <[email protected]>
Acked-by: Paul E. McKenney <[email protected]>
Cc: Alan Stern <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Ivan Kokshaysky <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Matt Turner <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Richard Henderson <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/alpha/include/asm/xchg.h | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)

--- a/arch/alpha/include/asm/xchg.h
+++ b/arch/alpha/include/asm/xchg.h
@@ -11,6 +11,10 @@
* Atomic exchange.
* Since it can be used to implement critical sections
* it must clobber "memory" (also for interrupts in UP).
+ *
+ * The leading and the trailing memory barriers guarantee that these
+ * operations are fully ordered.
+ *
*/

static inline unsigned long
@@ -18,6 +22,7 @@ ____xchg(_u8, volatile char *m, unsigned
{
unsigned long ret, tmp, addr64;

+ smp_mb();
__asm__ __volatile__(
" andnot %4,7,%3\n"
" insbl %1,%4,%1\n"
@@ -42,6 +47,7 @@ ____xchg(_u16, volatile short *m, unsign
{
unsigned long ret, tmp, addr64;

+ smp_mb();
__asm__ __volatile__(
" andnot %4,7,%3\n"
" inswl %1,%4,%1\n"
@@ -66,6 +72,7 @@ ____xchg(_u32, volatile int *m, unsigned
{
unsigned long dummy;

+ smp_mb();
__asm__ __volatile__(
"1: ldl_l %0,%4\n"
" bis $31,%3,%1\n"
@@ -86,6 +93,7 @@ ____xchg(_u64, volatile long *m, unsigne
{
unsigned long dummy;

+ smp_mb();
__asm__ __volatile__(
"1: ldq_l %0,%4\n"
" bis $31,%3,%1\n"
@@ -127,9 +135,12 @@ ____xchg(, volatile void *ptr, unsigned
* store NEW in MEM. Return the initial value in MEM. Success is
* indicated by comparing RETURN with OLD.
*
- * The memory barrier is placed in SMP unconditionally, in order to
- * guarantee that dependency ordering is preserved when a dependency
- * is headed by an unsuccessful operation.
+ * The leading and the trailing memory barriers guarantee that these
+ * operations are fully ordered.
+ *
+ * The trailing memory barrier is placed in SMP unconditionally, in
+ * order to guarantee that dependency ordering is preserved when a
+ * dependency is headed by an unsuccessful operation.
*/

static inline unsigned long
@@ -137,6 +148,7 @@ ____cmpxchg(_u8, volatile char *m, unsig
{
unsigned long prev, tmp, cmp, addr64;

+ smp_mb();
__asm__ __volatile__(
" andnot %5,7,%4\n"
" insbl %1,%5,%1\n"
@@ -164,6 +176,7 @@ ____cmpxchg(_u16, volatile short *m, uns
{
unsigned long prev, tmp, cmp, addr64;

+ smp_mb();
__asm__ __volatile__(
" andnot %5,7,%4\n"
" inswl %1,%5,%1\n"
@@ -191,6 +204,7 @@ ____cmpxchg(_u32, volatile int *m, int o
{
unsigned long prev, cmp;

+ smp_mb();
__asm__ __volatile__(
"1: ldl_l %0,%5\n"
" cmpeq %0,%3,%1\n"
@@ -214,6 +228,7 @@ ____cmpxchg(_u64, volatile long *m, unsi
{
unsigned long prev, cmp;

+ smp_mb();
__asm__ __volatile__(
"1: ldq_l %0,%5\n"
" cmpeq %0,%3,%1\n"



2018-05-28 15:35:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 079/268] usb: gadget: fsl_udc_core: fix ep valid checks

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

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

From: Stefan Agner <[email protected]>

[ Upstream commit 20c63f4089cceab803438c383631963e34c4d8e5 ]

Clang reports the following warning:
drivers/usb/gadget/udc/fsl_udc_core.c:1312:10: warning: address of array
'ep->name' will always evaluate to 'true' [-Wpointer-bool-conversion]
if (ep->name)
~~ ~~~~^~~~

It seems that the authors intention was to check if the ep has been
configured through struct_ep_setup. Check whether struct usb_ep name
pointer has been set instead.

Signed-off-by: Stefan Agner <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/udc/fsl_udc_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -1310,7 +1310,7 @@ static void udc_reset_ep_queue(struct fs
{
struct fsl_ep *ep = get_ep_by_pipe(udc, pipe);

- if (ep->name)
+ if (ep->ep.name)
nuke(ep, -ESHUTDOWN);
}

@@ -1698,7 +1698,7 @@ static void dtd_complete_irq(struct fsl_
curr_ep = get_ep_by_pipe(udc, i);

/* If the ep is configured */
- if (curr_ep->name == NULL) {
+ if (!curr_ep->ep.name) {
WARNING("Invalid EP?");
continue;
}



2018-05-28 15:36:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 105/268] media: dmxdev: fix error code for invalid ioctls

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

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

From: Mauro Carvalho Chehab <[email protected]>

[ Upstream commit a145f64c6107d3aa5a7cec9f8977d04ac2a896c9 ]

Returning -EINVAL when an ioctl is not implemented is a very
bad idea, as it is hard to distinguish from other error
contitions that an ioctl could lead. Replace it by its
right error code: -ENOTTY.

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/dmxdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/dvb-core/dmxdev.c
+++ b/drivers/media/dvb-core/dmxdev.c
@@ -1071,7 +1071,7 @@ static int dvb_demux_do_ioctl(struct fil
break;

default:
- ret = -EINVAL;
+ ret = -ENOTTY;
break;
}
mutex_unlock(&dmxdev->mutex);



2018-05-28 15:36:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 102/268] regulatory: add NUL to request alpha2

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

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

From: Johannes Berg <[email protected]>

[ Upstream commit 657308f73e674e86b60509a430a46e569bf02846 ]

Similar to the ancient commit a5fe8e7695dc ("regulatory: add NUL
to alpha2"), add another byte to alpha2 in the request struct so
that when we use nla_put_string(), we don't overrun anything.

Fixes: 73d54c9e74c4 ("cfg80211: add regulatory netlink multicast group")
Reported-by: Kees Cook <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/net/regulatory.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/net/regulatory.h
+++ b/include/net/regulatory.h
@@ -78,7 +78,7 @@ struct regulatory_request {
int wiphy_idx;
enum nl80211_reg_initiator initiator;
enum nl80211_user_reg_hint_type user_reg_hint_type;
- char alpha2[2];
+ char alpha2[3];
enum nl80211_dfs_regions dfs_region;
bool intersect;
bool processed;



2018-05-28 15:37:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 101/268] smsc75xx: fix smsc75xx_set_features()

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

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

From: Eric Dumazet <[email protected]>

[ Upstream commit 88e80c62671ceecdbb77c902731ec95a4bfa62f9 ]

If an attempt is made to disable RX checksums, USB adapter is changed
but netdev->features is not, because smsc75xx_set_features() returns a
non zero value.

This throws errors from netdev_rx_csum_fault() :
<devname>: hw csum failure

Signed-off-by: Eric Dumazet <[email protected]>
Cc: Steve Glendinning <[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/usb/smsc75xx.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -945,10 +945,11 @@ static int smsc75xx_set_features(struct
/* it's racing here! */

ret = smsc75xx_write_reg(dev, RFE_CTL, pdata->rfe_ctl);
- if (ret < 0)
+ if (ret < 0) {
netdev_warn(dev->net, "Error writing RFE_CTL\n");
-
- return ret;
+ return ret;
+ }
+ return 0;
}

static int smsc75xx_wait_ready(struct usbnet *dev, int in_pm)



2018-05-28 15:37:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 099/268] s390/cio: clear timer when terminating driver I/O

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

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

From: Sebastian Ott <[email protected]>

[ Upstream commit 410d5e13e7638bc146321671e223d56495fbf3c7 ]

When we terminate driver I/O (because we need to stop using a certain
channel path) we also need to ensure that a timer (which may have been
set up using ccw_device_start_timeout) is cleared.

Signed-off-by: Sebastian Ott <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/s390/cio/device_fsm.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/s390/cio/device_fsm.c
+++ b/drivers/s390/cio/device_fsm.c
@@ -923,6 +923,7 @@ void ccw_device_kill_io(struct ccw_devic
{
int ret;

+ ccw_device_set_timeout(cdev, 0);
cdev->private->iretry = 255;
cdev->private->async_kill_io_rc = -EIO;
ret = ccw_device_cancel_halt_clear(cdev);



2018-05-28 15:38:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 098/268] s390/cio: fix return code after missing interrupt

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

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

From: Sebastian Ott <[email protected]>

[ Upstream commit 770b55c995d171f026a9efb85e71e3b1ea47b93d ]

When a timeout occurs for users of ccw_device_start_timeout
we will stop the IO and call the drivers int handler with
the irb pointer set to ERR_PTR(-ETIMEDOUT). Sometimes
however we'd set the irb pointer to ERR_PTR(-EIO) which is
not intended. Just set the correct value in all codepaths.

Reported-by: Julian Wiedmann <[email protected]>
Signed-off-by: Sebastian Ott <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/s390/cio/device_fsm.c | 6 ++++--
drivers/s390/cio/io_sch.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/s390/cio/device_fsm.c
+++ b/drivers/s390/cio/device_fsm.c
@@ -822,6 +822,7 @@ ccw_device_online_timeout(struct ccw_dev

ccw_device_set_timeout(cdev, 0);
cdev->private->iretry = 255;
+ cdev->private->async_kill_io_rc = -ETIMEDOUT;
ret = ccw_device_cancel_halt_clear(cdev);
if (ret == -EBUSY) {
ccw_device_set_timeout(cdev, 3*HZ);
@@ -898,7 +899,7 @@ ccw_device_killing_irq(struct ccw_device
/* OK, i/o is dead now. Call interrupt handler. */
if (cdev->handler)
cdev->handler(cdev, cdev->private->intparm,
- ERR_PTR(-EIO));
+ ERR_PTR(cdev->private->async_kill_io_rc));
}

static void
@@ -915,7 +916,7 @@ ccw_device_killing_timeout(struct ccw_de
ccw_device_online_verify(cdev, 0);
if (cdev->handler)
cdev->handler(cdev, cdev->private->intparm,
- ERR_PTR(-EIO));
+ ERR_PTR(cdev->private->async_kill_io_rc));
}

void ccw_device_kill_io(struct ccw_device *cdev)
@@ -923,6 +924,7 @@ void ccw_device_kill_io(struct ccw_devic
int ret;

cdev->private->iretry = 255;
+ cdev->private->async_kill_io_rc = -EIO;
ret = ccw_device_cancel_halt_clear(cdev);
if (ret == -EBUSY) {
ccw_device_set_timeout(cdev, 3*HZ);
--- a/drivers/s390/cio/io_sch.h
+++ b/drivers/s390/cio/io_sch.h
@@ -155,6 +155,7 @@ struct ccw_device_private {
unsigned long intparm; /* user interruption parameter */
struct qdio_irq *qdio_data;
struct irb irb; /* device status */
+ int async_kill_io_rc;
struct senseid senseid; /* SenseID info */
struct pgid pgid[8]; /* path group IDs per chpid*/
struct ccw1 iccws[2]; /* ccws for SNID/SID/SPGID commands */



2018-05-28 15:38:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 097/268] powerpc/bpf/jit: Fix 32-bit JIT for seccomp_data access

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

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

From: Mark Lord <[email protected]>

[ Upstream commit 083b20907185b076f21c265b30fe5b5f24c03d8c ]

I am using SECCOMP to filter syscalls on a ppc32 platform, and noticed
that the JIT compiler was failing on the BPF even though the
interpreter was working fine.

The issue was that the compiler was missing one of the instructions
used by SECCOMP, so here is a patch to enable JIT for that
instruction.

Fixes: eb84bab0fb38 ("ppc: Kconfig: Enable BPF JIT on ppc32")
Signed-off-by: Mark Lord <[email protected]>
Acked-by: Naveen N. Rao <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/net/bpf_jit_comp.c | 3 +++
1 file changed, 3 insertions(+)

--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -329,6 +329,9 @@ static int bpf_jit_build_body(struct bpf
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff, len));
break;
+ case BPF_LDX | BPF_W | BPF_ABS: /* A = *((u32 *)(seccomp_data + K)); */
+ PPC_LWZ_OFFS(r_A, r_skb, K);
+ break;
case BPF_LDX | BPF_W | BPF_LEN: /* X = skb->len; */
PPC_LWZ_OFFS(r_X, r_skb, offsetof(struct sk_buff, len));
break;



2018-05-28 15:39:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 100/268] ARM: OMAP: Fix dmtimer init for omap1

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

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

From: Tony Lindgren <[email protected]>

[ Upstream commit ba6887836178d43b3665b9da075c2c5dfe1d207c ]

We need to enable PM runtime on omap1 also as otherwise we
will get errors:

omap_timer omap_timer.1: omap_dm_timer_probe: pm_runtime_get_sync failed!
omap_timer: probe of omap_timer.1 failed with error -13
...

We are checking for OMAP_TIMER_NEEDS_RESET flag elsewhere so this is
safe to do.

Cc: Aaro Koskinen <[email protected]>
Cc: Keerthy <[email protected]>
Cc: Ladislav Michl <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/plat-omap/dmtimer.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)

--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -854,11 +854,8 @@ static int omap_dm_timer_probe(struct pl
timer->irq = irq->start;
timer->pdev = pdev;

- /* Skip pm_runtime_enable for OMAP1 */
- if (!(timer->capability & OMAP_TIMER_NEEDS_RESET)) {
- pm_runtime_enable(dev);
- pm_runtime_irq_safe(dev);
- }
+ pm_runtime_enable(dev);
+ pm_runtime_irq_safe(dev);

if (!timer->reserved) {
ret = pm_runtime_get_sync(dev);



2018-05-28 15:39:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 095/268] md: raid5: avoid string overflow warning

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

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

From: Arnd Bergmann <[email protected]>

[ Upstream commit 53b8d89ddbdbb0e4625a46d2cdbb6f106c52f801 ]

gcc warns about a possible overflow of the kmem_cache string, when adding
four characters to a string of the same length:

drivers/md/raid5.c: In function 'setup_conf':
drivers/md/raid5.c:2207:34: error: '-alt' directive writing 4 bytes into a region of size between 1 and 32 [-Werror=format-overflow=]
sprintf(conf->cache_name[1], "%s-alt", conf->cache_name[0]);
^~~~
drivers/md/raid5.c:2207:2: note: 'sprintf' output between 5 and 36 bytes into a destination of size 32
sprintf(conf->cache_name[1], "%s-alt", conf->cache_name[0]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If I'm counting correctly, we need 11 characters for the fixed part
of the string and 18 characters for a 64-bit pointer (when no gendisk
is used), so that leaves three characters for conf->level, which should
always be sufficient.

This makes the code use snprintf() with the correct length, to
make the code more robust against changes, and to get the compiler
to shut up.

In commit f4be6b43f1ac ("md/raid5: ensure we create a unique name for
kmem_cache when mddev has no gendisk") from 2010, Neil said that
the pointer could be removed "shortly" once devices without gendisk
are disallowed. I have no idea if that happened, but if it did, that
should probably be changed as well.

Signed-off-by: Arnd Bergmann <[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/raid5.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2028,15 +2028,16 @@ static int grow_one_stripe(struct r5conf
static int grow_stripes(struct r5conf *conf, int num)
{
struct kmem_cache *sc;
+ size_t namelen = sizeof(conf->cache_name[0]);
int devs = max(conf->raid_disks, conf->previous_raid_disks);

if (conf->mddev->gendisk)
- sprintf(conf->cache_name[0],
+ snprintf(conf->cache_name[0], namelen,
"raid%d-%s", conf->level, mdname(conf->mddev));
else
- sprintf(conf->cache_name[0],
+ snprintf(conf->cache_name[0], namelen,
"raid%d-%p", conf->level, conf->mddev);
- sprintf(conf->cache_name[1], "%s-alt", conf->cache_name[0]);
+ snprintf(conf->cache_name[1], namelen, "%.27s-alt", conf->cache_name[0]);

conf->active_name = 0;
sc = kmem_cache_create(conf->cache_name[conf->active_name],



2018-05-28 15:39:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 088/268] NFC: llcp: Limit size of SDP URI

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

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

From: Kees Cook <[email protected]>

[ Upstream commit fe9c842695e26d8116b61b80bfb905356f07834b ]

The tlv_len is u8, so we need to limit the size of the SDP URI. Enforce
this both in the NLA policy and in the code that performs the allocation
and copy, to avoid writing past the end of the allocated buffer.

Fixes: d9b8d8e19b073 ("NFC: llcp: Service Name Lookup netlink interface")
Signed-off-by: Kees Cook <[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/nfc/llcp_commands.c | 4 ++++
net/nfc/netlink.c | 3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)

--- a/net/nfc/llcp_commands.c
+++ b/net/nfc/llcp_commands.c
@@ -149,6 +149,10 @@ struct nfc_llcp_sdp_tlv *nfc_llcp_build_

pr_debug("uri: %s, len: %zu\n", uri, uri_len);

+ /* sdreq->tlv_len is u8, takes uri_len, + 3 for header, + 1 for NULL */
+ if (WARN_ON_ONCE(uri_len > U8_MAX - 4))
+ return NULL;
+
sdreq = kzalloc(sizeof(struct nfc_llcp_sdp_tlv), GFP_KERNEL);
if (sdreq == NULL)
return NULL;
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -68,7 +68,8 @@ static const struct nla_policy nfc_genl_
};

static const struct nla_policy nfc_sdp_genl_policy[NFC_SDP_ATTR_MAX + 1] = {
- [NFC_SDP_ATTR_URI] = { .type = NLA_STRING },
+ [NFC_SDP_ATTR_URI] = { .type = NLA_STRING,
+ .len = U8_MAX - 4 },
[NFC_SDP_ATTR_SAP] = { .type = NLA_U8 },
};




2018-05-28 15:39:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 096/268] kernel/relay.c: limit kmalloc size to KMALLOC_MAX_SIZE

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

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

From: David Rientjes <[email protected]>

[ Upstream commit 88913bd8ea2a75d7e460a4bed5f75e1c32660d7e ]

chan->n_subbufs is set by the user and relay_create_buf() does a kmalloc()
of chan->n_subbufs * sizeof(size_t *).

kmalloc_slab() will generate a warning when this fails if
chan->subbufs * sizeof(size_t *) > KMALLOC_MAX_SIZE.

Limit chan->n_subbufs to the maximum allowed kmalloc() size.

Link: http://lkml.kernel.org/r/[email protected]
Fixes: f6302f1bcd75 ("relay: prevent integer overflow in relay_open()")
Signed-off-by: David Rientjes <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Cc: Jens Axboe <[email protected]>
Cc: Dave Jiang <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Dan Carpenter <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/relay.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -163,7 +163,7 @@ static struct rchan_buf *relay_create_bu
{
struct rchan_buf *buf;

- if (chan->n_subbufs > UINT_MAX / sizeof(size_t *))
+ if (chan->n_subbufs > KMALLOC_MAX_SIZE / sizeof(size_t *))
return NULL;

buf = kzalloc(sizeof(struct rchan_buf), GFP_KERNEL);



2018-05-28 15:39:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 093/268] usb: musb: fix enumeration after resume

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

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

From: Andreas Kemnade <[email protected]>

[ Upstream commit 17539f2f4f0b7fa906b508765c8ada07a1e45f52 ]

On dm3730 there are enumeration problems after resume.
Investigation led to the cause that the MUSB_POWER_SOFTCONN
bit is not set. If it was set before suspend (because it
was enabled via musb_pullup()), it is set in
musb_restore_context() so the pullup is enabled. But then
musb_start() is called which overwrites MUSB_POWER and
therefore disables MUSB_POWER_SOFTCONN, so no pullup is
enabled and the device is not enumerated.

So let's do a subset of what musb_start() does
in the same way as musb_suspend() does it. Platform-specific
stuff it still called as there might be some phy-related stuff
which needs to be enabled.
Also interrupts are enabled, as it was the original idea
of calling musb_start() in musb_resume() according to
Commit 6fc6f4b87cb3 ("usb: musb: Disable interrupts on suspend,
enable them on resume")

Signed-off-by: Andreas Kemnade <[email protected]>
Tested-by: Tony Lindgren <[email protected]>
Signed-off-by: Bin Liu <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/musb/musb_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2522,7 +2522,8 @@ static int musb_resume(struct device *de
pm_runtime_set_active(dev);
pm_runtime_enable(dev);

- musb_start(musb);
+ musb_enable_interrupts(musb);
+ musb_platform_enable(musb);

return 0;
}



2018-05-28 15:40:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 089/268] mac80211: round IEEE80211_TX_STATUS_HEADROOM up to multiple of 4

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

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

From: Felix Fietkau <[email protected]>

[ Upstream commit 651b9920d7a694ffb1f885aef2bbb068a25d9d66 ]

This ensures that mac80211 allocated management frames are properly
aligned, which makes copying them more efficient.
For instance, mt76 uses iowrite32_copy to copy beacon frames to beacon
template memory on the chip.
Misaligned 32-bit accesses cause CPU exceptions on MIPS and should be
avoided.

Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/net/mac80211.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -3898,7 +3898,7 @@ static inline int ieee80211_sta_ps_trans
* The TX headroom reserved by mac80211 for its own tx_status functions.
* This is enough for the radiotap header.
*/
-#define IEEE80211_TX_STATUS_HEADROOM 14
+#define IEEE80211_TX_STATUS_HEADROOM ALIGN(14, 4)

/**
* ieee80211_sta_set_buffered - inform mac80211 about driver-buffered frames



2018-05-28 15:40:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 091/268] drm/exynos: fix comparison to bitshift when dealing with a mask

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

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

From: Wolfram Sang <[email protected]>

[ Upstream commit 1293b6191010672c0c9dacae8f71c6f3e4d70cbe ]

Due to a typo, the mask was destroyed by a comparison instead of a bit
shift.

Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/exynos/regs-fimc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/exynos/regs-fimc.h
+++ b/drivers/gpu/drm/exynos/regs-fimc.h
@@ -569,7 +569,7 @@
#define EXYNOS_CIIMGEFF_FIN_EMBOSSING (4 << 26)
#define EXYNOS_CIIMGEFF_FIN_SILHOUETTE (5 << 26)
#define EXYNOS_CIIMGEFF_FIN_MASK (7 << 26)
-#define EXYNOS_CIIMGEFF_PAT_CBCR_MASK ((0xff < 13) | (0xff < 0))
+#define EXYNOS_CIIMGEFF_PAT_CBCR_MASK ((0xff << 13) | (0xff << 0))

/* Real input DMA size register */
#define EXYNOS_CIREAL_ISIZE_AUTOLOAD_ENABLE (1 << 31)



2018-05-28 15:41:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 050/268] mm/mempolicy: add nodes_empty check in SYSC_migrate_pages

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

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

From: Yisheng Xie <[email protected]>

[ Upstream commit 0486a38bcc4749808edbc848f1bcf232042770fc ]

As in manpage of migrate_pages, the errno should be set to EINVAL when
none of the node IDs specified by new_nodes are on-line and allowed by
the process's current cpuset context, or none of the specified nodes
contain memory. However, when test by following case:

new_nodes = 0;
old_nodes = 0xf;
ret = migrate_pages(pid, old_nodes, new_nodes, MAX);

The ret will be 0 and no errno is set. As the new_nodes is empty, we
should expect EINVAL as documented.

To fix the case like above, this patch check whether target nodes AND
current task_nodes is empty, and then check whether AND
node_states[N_MEMORY] is empty.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Yisheng Xie <[email protected]>
Acked-by: Vlastimil Babka <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Chris Salls <[email protected]>
Cc: Christopher Lameter <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Naoya Horiguchi <[email protected]>
Cc: Tan Xiaojun <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/mempolicy.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)

--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1410,10 +1410,14 @@ SYSCALL_DEFINE4(migrate_pages, pid_t, pi
goto out_put;
}

- if (!nodes_subset(*new, node_states[N_MEMORY])) {
- err = -EINVAL;
+ task_nodes = cpuset_mems_allowed(current);
+ nodes_and(*new, *new, task_nodes);
+ if (nodes_empty(*new))
+ goto out_put;
+
+ nodes_and(*new, *new, node_states[N_MEMORY]);
+ if (nodes_empty(*new))
goto out_put;
- }

err = security_task_movememory(task);
if (err)



2018-05-28 15:41:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 086/268] ARM: OMAP3: Fix prm wake interrupt for resume

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

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

From: Tony Lindgren <[email protected]>

[ Upstream commit d3be6d2a08bd26580562d9714d3d97ea9ba22c73 ]

For platform_suspend_ops, the finish call is too late to re-enable wake
irqs and we need re-enable wake irqs on wake call instead.

Otherwise noirq resume for devices has already happened. And then
dev_pm_disarm_wake_irq() has already disabled the dedicated wake irqs
when the interrupt triggers and the wake irq is never handled.

For devices that are already in PM runtime suspended state when we
enter suspend this means that a possible wake irq will never trigger.

And this can lead into a situation where a device has a pending padconf
wake irq, and the device will stay unresponsive to any further wake
irqs.

This issue can be easily reproduced by setting serial console log level
to zero, letting the serial console idle, and suspend the system from
an ssh terminal. Then try to wake up the system by typing to the serial
console.

Note that this affects only omap3 PRM interrupt as that's currently
the only omap variant that does anything in omap_pm_wake().

In general, for the wake irqs to work, the interrupt must have either
IRQF_NO_SUSPEND or IRQF_EARLY_RESUME set for it to trigger before
dev_pm_disarm_wake_irq() disables the wake irqs.

Reported-by: Grygorii Strashko <[email protected]>
Cc: Tero Kristo <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/mach-omap2/pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -231,7 +231,7 @@ static void omap_pm_end(void)
cpu_idle_poll_ctrl(false);
}

-static void omap_pm_finish(void)
+static void omap_pm_wake(void)
{
if (cpu_is_omap34xx())
omap_prcm_irq_complete();
@@ -241,7 +241,7 @@ static const struct platform_suspend_ops
.begin = omap_pm_begin,
.end = omap_pm_end,
.enter = omap_pm_enter,
- .finish = omap_pm_finish,
+ .wake = omap_pm_wake,
.valid = suspend_valid_only_mem,
};




2018-05-28 15:41:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 087/268] ARM: OMAP1: clock: Fix debugfs_create_*() usage

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

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

From: Geert Uytterhoeven <[email protected]>

[ Upstream commit 8cbbf1745dcde7ba7e423dc70619d223de90fd43 ]

When exposing data access through debugfs, the correct
debugfs_create_*() functions must be used, depending on data type.

Remove all casts from data pointers passed to debugfs_create_*()
functions, as such casts prevent the compiler from flagging bugs.

Correct all wrong usage:
- clk.rate is unsigned long, not u32,
- clk.flags is u8, not u32, which exposed the successive
clk.rate_offset and clk.src_offset fields.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Acked-by: Aaro Koskinen <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/mach-omap1/clock.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -1031,17 +1031,17 @@ static int clk_debugfs_register_one(stru
return -ENOMEM;
c->dent = d;

- d = debugfs_create_u8("usecount", S_IRUGO, c->dent, (u8 *)&c->usecount);
+ d = debugfs_create_u8("usecount", S_IRUGO, c->dent, &c->usecount);
if (!d) {
err = -ENOMEM;
goto err_out;
}
- d = debugfs_create_u32("rate", S_IRUGO, c->dent, (u32 *)&c->rate);
+ d = debugfs_create_ulong("rate", S_IRUGO, c->dent, &c->rate);
if (!d) {
err = -ENOMEM;
goto err_out;
}
- d = debugfs_create_x32("flags", S_IRUGO, c->dent, (u32 *)&c->flags);
+ d = debugfs_create_x8("flags", S_IRUGO, c->dent, &c->flags);
if (!d) {
err = -ENOMEM;
goto err_out;



2018-05-28 15:41:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 048/268] ocfs2: return error when we attempt to access a dirty bh in jbd2

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

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

From: piaojun <[email protected]>

[ Upstream commit d984187e3a1ad7d12447a7ab2c43ce3717a2b5b3 ]

We should not reuse the dirty bh in jbd2 directly due to the following
situation:

1. When removing extent rec, we will dirty the bhs of extent rec and
truncate log at the same time, and hand them over to jbd2.

2. The bhs are submitted to jbd2 area successfully.

3. The write-back thread of device help flush the bhs to disk but
encounter write error due to abnormal storage link.

4. After a while the storage link become normal. Truncate log flush
worker triggered by the next space reclaiming found the dirty bh of
truncate log and clear its 'BH_Write_EIO' and then set it uptodate in
__ocfs2_journal_access():

ocfs2_truncate_log_worker
ocfs2_flush_truncate_log
__ocfs2_flush_truncate_log
ocfs2_replay_truncate_records
ocfs2_journal_access_di
__ocfs2_journal_access // here we clear io_error and set 'tl_bh' uptodata.

5. Then jbd2 will flush the bh of truncate log to disk, but the bh of
extent rec is still in error state, and unfortunately nobody will
take care of it.

6. At last the space of extent rec was not reduced, but truncate log
flush worker have given it back to globalalloc. That will cause
duplicate cluster problem which could be identified by fsck.ocfs2.

Sadly we can hardly revert this but set fs read-only in case of ruining
atomicity and consistency of space reclaim.

Link: http://lkml.kernel.org/r/[email protected]
Fixes: acf8fdbe6afb ("ocfs2: do not BUG if buffer not uptodate in __ocfs2_journal_access")
Signed-off-by: Jun Piao <[email protected]>
Reviewed-by: Yiwen Jiang <[email protected]>
Reviewed-by: Changwei Ge <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Joel Becker <[email protected]>
Cc: Junxiao Bi <[email protected]>
Cc: Joseph Qi <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ocfs2/journal.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)

--- a/fs/ocfs2/journal.c
+++ b/fs/ocfs2/journal.c
@@ -666,23 +666,24 @@ static int __ocfs2_journal_access(handle
/* we can safely remove this assertion after testing. */
if (!buffer_uptodate(bh)) {
mlog(ML_ERROR, "giving me a buffer that's not uptodate!\n");
- mlog(ML_ERROR, "b_blocknr=%llu\n",
- (unsigned long long)bh->b_blocknr);
+ mlog(ML_ERROR, "b_blocknr=%llu, b_state=0x%lx\n",
+ (unsigned long long)bh->b_blocknr, bh->b_state);

lock_buffer(bh);
/*
- * A previous attempt to write this buffer head failed.
- * Nothing we can do but to retry the write and hope for
- * the best.
+ * A previous transaction with a couple of buffer heads fail
+ * to checkpoint, so all the bhs are marked as BH_Write_EIO.
+ * For current transaction, the bh is just among those error
+ * bhs which previous transaction handle. We can't just clear
+ * its BH_Write_EIO and reuse directly, since other bhs are
+ * not written to disk yet and that will cause metadata
+ * inconsistency. So we should set fs read-only to avoid
+ * further damage.
*/
if (buffer_write_io_error(bh) && !buffer_uptodate(bh)) {
- clear_buffer_write_io_error(bh);
- set_buffer_uptodate(bh);
- }
-
- if (!buffer_uptodate(bh)) {
unlock_buffer(bh);
- return -EIO;
+ return ocfs2_error(osb->sb, "A previous attempt to "
+ "write this buffer head failed\n");
}
unlock_buffer(bh);
}



2018-05-28 15:41:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 041/268] jffs2: Fix use-after-free bug in jffs2_iget()s error handling path

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

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

From: Jake Daryll Obina <[email protected]>

[ Upstream commit 5bdd0c6f89fba430e18d636493398389dadc3b17 ]

If jffs2_iget() fails for a newly-allocated inode, jffs2_do_clear_inode()
can get called twice in the error handling path, the first call in
jffs2_iget() itself and the second through iget_failed(). This can result
to a use-after-free error in the second jffs2_do_clear_inode() call, such
as shown by the oops below wherein the second jffs2_do_clear_inode() call
was trying to free node fragments that were already freed in the first
jffs2_do_clear_inode() call.

[ 78.178860] jffs2: error: (1904) jffs2_do_read_inode_internal: CRC failed for read_inode of inode 24 at physical location 0x1fc00c
[ 78.178914] Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b7b
[ 78.185871] pgd = ffffffc03a567000
[ 78.188794] [6b6b6b6b6b6b6b7b] *pgd=0000000000000000, *pud=0000000000000000
[ 78.194968] Internal error: Oops: 96000004 [#1] PREEMPT SMP
...
[ 78.513147] PC is at rb_first_postorder+0xc/0x28
[ 78.516503] LR is at jffs2_kill_fragtree+0x28/0x90 [jffs2]
[ 78.520672] pc : [<ffffff8008323d28>] lr : [<ffffff8000eb1cc8>] pstate: 60000105
[ 78.526757] sp : ffffff800cea38f0
[ 78.528753] x29: ffffff800cea38f0 x28: ffffffc01f3f8e80
[ 78.532754] x27: 0000000000000000 x26: ffffff800cea3c70
[ 78.536756] x25: 00000000dc67c8ae x24: ffffffc033d6945d
[ 78.540759] x23: ffffffc036811740 x22: ffffff800891a5b8
[ 78.544760] x21: 0000000000000000 x20: 0000000000000000
[ 78.548762] x19: ffffffc037d48910 x18: ffffff800891a588
[ 78.552764] x17: 0000000000000800 x16: 0000000000000c00
[ 78.556766] x15: 0000000000000010 x14: 6f2065646f6e695f
[ 78.560767] x13: 6461657220726f66 x12: 2064656c69616620
[ 78.564769] x11: 435243203a6c616e x10: 7265746e695f6564
[ 78.568771] x9 : 6f6e695f64616572 x8 : ffffffc037974038
[ 78.572774] x7 : bbbbbbbbbbbbbbbb x6 : 0000000000000008
[ 78.576775] x5 : 002f91d85bd44a2f x4 : 0000000000000000
[ 78.580777] x3 : 0000000000000000 x2 : 000000403755e000
[ 78.584779] x1 : 6b6b6b6b6b6b6b6b x0 : 6b6b6b6b6b6b6b6b
...
[ 79.038551] [<ffffff8008323d28>] rb_first_postorder+0xc/0x28
[ 79.042962] [<ffffff8000eb5578>] jffs2_do_clear_inode+0x88/0x100 [jffs2]
[ 79.048395] [<ffffff8000eb9ddc>] jffs2_evict_inode+0x3c/0x48 [jffs2]
[ 79.053443] [<ffffff8008201ca8>] evict+0xb0/0x168
[ 79.056835] [<ffffff8008202650>] iput+0x1c0/0x200
[ 79.060228] [<ffffff800820408c>] iget_failed+0x30/0x3c
[ 79.064097] [<ffffff8000eba0c0>] jffs2_iget+0x2d8/0x360 [jffs2]
[ 79.068740] [<ffffff8000eb0a60>] jffs2_lookup+0xe8/0x130 [jffs2]
[ 79.073434] [<ffffff80081f1a28>] lookup_slow+0x118/0x190
[ 79.077435] [<ffffff80081f4708>] walk_component+0xfc/0x28c
[ 79.081610] [<ffffff80081f4dd0>] path_lookupat+0x84/0x108
[ 79.085699] [<ffffff80081f5578>] filename_lookup+0x88/0x100
[ 79.089960] [<ffffff80081f572c>] user_path_at_empty+0x58/0x6c
[ 79.094396] [<ffffff80081ebe14>] vfs_statx+0xa4/0x114
[ 79.098138] [<ffffff80081ec44c>] SyS_newfstatat+0x58/0x98
[ 79.102227] [<ffffff800808354c>] __sys_trace_return+0x0/0x4
[ 79.106489] Code: d65f03c0 f9400001 b40000e1 aa0103e0 (f9400821)

The jffs2_do_clear_inode() call in jffs2_iget() is unnecessary since
iget_failed() will eventually call jffs2_do_clear_inode() if needed, so
just remove it.

Fixes: 5451f79f5f81 ("iget: stop JFFS2 from using iget() and read_inode()")
Reviewed-by: Richard Weinberger <[email protected]>
Signed-off-by: Jake Daryll Obina <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/jffs2/fs.c | 1 -
1 file changed, 1 deletion(-)

--- a/fs/jffs2/fs.c
+++ b/fs/jffs2/fs.c
@@ -361,7 +361,6 @@ error_io:
ret = -EIO;
error:
mutex_unlock(&f->sem);
- jffs2_do_clear_inode(c, f);
iget_failed(inode);
return ERR_PTR(ret);
}



2018-05-28 15:42:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 046/268] ocfs2: return -EROFS to mount.ocfs2 if inode block is invalid

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

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

From: piaojun <[email protected]>

[ Upstream commit 025bcbde3634b2c9b316f227fed13ad6ad6817fb ]

If metadata is corrupted such as 'invalid inode block', we will get
failed by calling 'mount()' and then set filesystem readonly as below:

ocfs2_mount
ocfs2_initialize_super
ocfs2_init_global_system_inodes
ocfs2_iget
ocfs2_read_locked_inode
ocfs2_validate_inode_block
ocfs2_error
ocfs2_handle_error
ocfs2_set_ro_flag(osb, 0); // set readonly

In this situation we need return -EROFS to 'mount.ocfs2', so that user
can fix it by fsck. And then mount again. In addition, 'mount.ocfs2'
should be updated correspondingly as it only return 1 for all errno.
And I will post a patch for 'mount.ocfs2' too.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Jun Piao <[email protected]>
Reviewed-by: Alex Chen <[email protected]>
Reviewed-by: Joseph Qi <[email protected]>
Reviewed-by: Changwei Ge <[email protected]>
Reviewed-by: Gang He <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Joel Becker <[email protected]>
Cc: Junxiao Bi <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ocfs2/super.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

--- a/fs/ocfs2/super.c
+++ b/fs/ocfs2/super.c
@@ -477,9 +477,8 @@ static int ocfs2_init_global_system_inod
new = ocfs2_get_system_file_inode(osb, i, osb->slot_num);
if (!new) {
ocfs2_release_system_inodes(osb);
- status = -EINVAL;
+ status = ocfs2_is_soft_readonly(osb) ? -EROFS : -EINVAL;
mlog_errno(status);
- /* FIXME: Should ERROR_RO_FS */
mlog(ML_ERROR, "Unable to load system inode %d, "
"possibly corrupt fs?", i);
goto bail;
@@ -508,7 +507,7 @@ static int ocfs2_init_local_system_inode
new = ocfs2_get_system_file_inode(osb, i, osb->slot_num);
if (!new) {
ocfs2_release_system_inodes(osb);
- status = -EINVAL;
+ status = ocfs2_is_soft_readonly(osb) ? -EROFS : -EINVAL;
mlog(ML_ERROR, "status=%d, sysfile=%d, slot=%d\n",
status, i, osb->slot_num);
goto bail;



2018-05-28 15:42:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 075/268] scsi: mptfusion: Add bounds check in mptctl_hp_targetinfo()

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

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

From: Dan Carpenter <[email protected]>

[ Upstream commit a7043e9529f3c367cc4d82997e00be034cbe57ca ]

My static checker complains about an out of bounds read:

drivers/message/fusion/mptctl.c:2786 mptctl_hp_targetinfo()
error: buffer overflow 'hd->sel_timeout' 255 <= u32max.

It's true that we probably should have a bounds check here.

Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: Johannes Thumshirn <[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/message/fusion/mptctl.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/message/fusion/mptctl.c
+++ b/drivers/message/fusion/mptctl.c
@@ -2698,6 +2698,8 @@ mptctl_hp_targetinfo(unsigned long arg)
__FILE__, __LINE__, iocnum);
return -ENODEV;
}
+ if (karg.hdr.id >= MPT_MAX_FC_DEVICES)
+ return -EINVAL;
dctlprintk(ioc, printk(MYIOC_s_DEBUG_FMT "mptctl_hp_targetinfo called.\n",
ioc->name));




2018-05-28 15:42:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 045/268] ntb_transport: Fix bug with max_mw_size parameter

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

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

From: Logan Gunthorpe <[email protected]>

[ Upstream commit cbd27448faff4843ac4b66cc71445a10623ff48d ]

When using the max_mw_size parameter of ntb_transport to limit the size of
the Memory windows, communication cannot be established and the queues
freeze.

This is because the mw_size that's reported to the peer is correctly
limited but the size used locally is not. So the MW is initialized
with a buffer smaller than the window but the TX side is using the
full window. This means the TX side will be writing to a region of the
window that points nowhere.

This is easily fixed by applying the same limit to tx_size in
ntb_transport_init_queue().

Fixes: e26a5843f7f5 ("NTB: Split ntb_hw_intel and ntb_transport drivers")
Signed-off-by: Logan Gunthorpe <[email protected]>
Acked-by: Allen Hubbe <[email protected]>
Cc: Dave Jiang <[email protected]>
Signed-off-by: Jon Mason <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/ntb/ntb_transport.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -955,6 +955,9 @@ static int ntb_transport_init_queue(stru
mw_base = nt->mw_vec[mw_num].phys_addr;
mw_size = nt->mw_vec[mw_num].phys_size;

+ if (max_mw_size && mw_size > max_mw_size)
+ mw_size = max_mw_size;
+
tx_size = (unsigned int)mw_size / num_qps_mw;
qp_offset = tx_size * (qp_num / mw_count);




2018-05-28 15:43:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 049/268] mm/mempolicy: fix the check of nodemask from user

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

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

From: Yisheng Xie <[email protected]>

[ Upstream commit 56521e7a02b7b84a5e72691a1fb15570e6055545 ]

As Xiaojun reported the ltp of migrate_pages01 will fail on arm64 system
which has 4 nodes[0...3], all have memory and CONFIG_NODES_SHIFT=2:

migrate_pages01 0 TINFO : test_invalid_nodes
migrate_pages01 14 TFAIL : migrate_pages_common.c:45: unexpected failure - returned value = 0, expected: -1
migrate_pages01 15 TFAIL : migrate_pages_common.c:55: call succeeded unexpectedly

In this case the test_invalid_nodes of migrate_pages01 will call:
SYSC_migrate_pages as:

migrate_pages(0, , {0x0000000000000001}, 64, , {0x0000000000000010}, 64) = 0

The new nodes specifies one or more node IDs that are greater than the
maximum supported node ID, however, the errno is not set to EINVAL as
expected.

As man pages of set_mempolicy[1], mbind[2], and migrate_pages[3]
mentioned, when nodemask specifies one or more node IDs that are greater
than the maximum supported node ID, the errno should set to EINVAL.
However, get_nodes only check whether the part of bits
[BITS_PER_LONG*BITS_TO_LONGS(MAX_NUMNODES), maxnode) is zero or not, and
remain [MAX_NUMNODES, BITS_PER_LONG*BITS_TO_LONGS(MAX_NUMNODES)
unchecked.

This patch is to check the bits of [MAX_NUMNODES, maxnode) in get_nodes
to let migrate_pages set the errno to EINVAL when nodemask specifies one
or more node IDs that are greater than the maximum supported node ID,
which follows the manpage's guide.

[1] http://man7.org/linux/man-pages/man2/set_mempolicy.2.html
[2] http://man7.org/linux/man-pages/man2/mbind.2.html
[3] http://man7.org/linux/man-pages/man2/migrate_pages.2.html

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Yisheng Xie <[email protected]>
Reported-by: Tan Xiaojun <[email protected]>
Acked-by: Vlastimil Babka <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Chris Salls <[email protected]>
Cc: Christopher Lameter <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Naoya Horiguchi <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/mempolicy.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)

--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1232,6 +1232,7 @@ static int get_nodes(nodemask_t *nodes,
unsigned long maxnode)
{
unsigned long k;
+ unsigned long t;
unsigned long nlongs;
unsigned long endmask;

@@ -1248,13 +1249,19 @@ static int get_nodes(nodemask_t *nodes,
else
endmask = (1UL << (maxnode % BITS_PER_LONG)) - 1;

- /* When the user specified more nodes than supported just check
- if the non supported part is all zero. */
+ /*
+ * When the user specified more nodes than supported just check
+ * if the non supported part is all zero.
+ *
+ * If maxnode have more longs than MAX_NUMNODES, check
+ * the bits in that area first. And then go through to
+ * check the rest bits which equal or bigger than MAX_NUMNODES.
+ * Otherwise, just check bits [MAX_NUMNODES, maxnode).
+ */
if (nlongs > BITS_TO_LONGS(MAX_NUMNODES)) {
if (nlongs > PAGE_SIZE/sizeof(long))
return -EINVAL;
for (k = BITS_TO_LONGS(MAX_NUMNODES); k < nlongs; k++) {
- unsigned long t;
if (get_user(t, nmask + k))
return -EFAULT;
if (k == nlongs - 1) {
@@ -1267,6 +1274,16 @@ static int get_nodes(nodemask_t *nodes,
endmask = ~0UL;
}

+ if (maxnode > MAX_NUMNODES && MAX_NUMNODES % BITS_PER_LONG != 0) {
+ unsigned long valid_mask = endmask;
+
+ valid_mask &= ~((1UL << (MAX_NUMNODES % BITS_PER_LONG)) - 1);
+ if (get_user(t, nmask + nlongs - 1))
+ return -EFAULT;
+ if (t & valid_mask)
+ return -EINVAL;
+ }
+
if (copy_from_user(nodes_addr(*nodes), nmask, nlongs*sizeof(unsigned long)))
return -EFAULT;
nodes_addr(*nodes)[nlongs-1] &= endmask;



2018-05-28 15:44:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 074/268] scsi: sym53c8xx_2: iterator underflow in sym_getsync()

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

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

From: Dan Carpenter <[email protected]>

[ Upstream commit e6f791d95313c85f3dd4a26141e28e50ae9aa0ae ]

We wanted to exit the loop with "div" set to zero, but instead, if we
don't hit the break then "div" is -1 when we finish the loop. It leads
to an array underflow a few lines later.

Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Acked-by: Matthew Wilcox <[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/sym53c8xx_2/sym_hipd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/scsi/sym53c8xx_2/sym_hipd.c
+++ b/drivers/scsi/sym53c8xx_2/sym_hipd.c
@@ -536,7 +536,7 @@ sym_getsync(struct sym_hcb *np, u_char d
* Look for the greatest clock divisor that allows an
* input speed faster than the period.
*/
- while (div-- > 0)
+ while (--div > 0)
if (kpc >= (div_10M[div] << 2)) break;

/*



2018-05-28 15:44:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 044/268] RDMA/mlx5: Avoid memory leak in case of XRCD dealloc failure

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

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

From: Leon Romanovsky <[email protected]>

[ Upstream commit b081808a66345ba725b77ecd8d759bee874cd937 ]

Failure in XRCD FW deallocation command leaves memory leaked and
returns error to the user which he can't do anything about it.

This patch changes behavior to always free memory and always return
success to the user.

Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
Reviewed-by: Majd Dibbiny <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Reviewed-by: Yuval Shaia <[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/mlx5/qp.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)

--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -3161,12 +3161,9 @@ int mlx5_ib_dealloc_xrcd(struct ib_xrcd
int err;

err = mlx5_core_xrcd_dealloc(dev->mdev, xrcdn);
- if (err) {
+ if (err)
mlx5_ib_warn(dev, "failed to dealloc xrcdn 0x%x\n", xrcdn);
- return err;
- }

kfree(xrcd);
-
return 0;
}



2018-05-28 15:44:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 072/268] scsi: ufs: Enable quirk to ignore sending WRITE_SAME command

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

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

From: Sujit Reddy Thumma <[email protected]>

[ Upstream commit 84af7e8b895088d89f246d6b0f82717fafdebf61 ]

WRITE_SAME command is not supported by UFS. Enable a quirk for the upper
level drivers to not send WRITE SAME command.

[mkp: botched patch, applied by hand]

Signed-off-by: Sujit Reddy Thumma <[email protected]>
Signed-off-by: Subhash Jadavani <[email protected]>
Signed-off-by: Asutosh Das <[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/ufs/ufshcd.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2923,6 +2923,8 @@ static int ufshcd_slave_alloc(struct scs
/* REPORT SUPPORTED OPERATION CODES is not supported */
sdev->no_report_opcodes = 1;

+ /* WRITE_SAME command is not supported */
+ sdev->no_write_same = 1;

ufshcd_set_queue_depth(sdev);




2018-05-28 15:45:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 071/268] irqchip/gic-v3: Change pr_debug message to pr_devel

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

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

From: Mark Salter <[email protected]>

[ Upstream commit b6dd4d83dc2f78cebc9a7e6e7e4bc2be4d29b94d ]

The pr_debug() in gic-v3 gic_send_sgi() can trigger a circular locking
warning:

GICv3: CPU10: ICC_SGI1R_EL1 5000400
======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #1 Tainted: G W
------------------------------------------------------
dynamic_debug01/1873 is trying to acquire lock:
((console_sem).lock){-...}, at: [<0000000099c891ec>] down_trylock+0x20/0x4c

but task is already holding lock:
(&rq->lock){-.-.}, at: [<00000000842e1587>] __task_rq_lock+0x54/0xdc

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&rq->lock){-.-.}:
__lock_acquire+0x3b4/0x6e0
lock_acquire+0xf4/0x2a8
_raw_spin_lock+0x4c/0x60
task_fork_fair+0x3c/0x148
sched_fork+0x10c/0x214
copy_process.isra.32.part.33+0x4e8/0x14f0
_do_fork+0xe8/0x78c
kernel_thread+0x48/0x54
rest_init+0x34/0x2a4
start_kernel+0x45c/0x488

-> #1 (&p->pi_lock){-.-.}:
__lock_acquire+0x3b4/0x6e0
lock_acquire+0xf4/0x2a8
_raw_spin_lock_irqsave+0x58/0x70
try_to_wake_up+0x48/0x600
wake_up_process+0x28/0x34
__up.isra.0+0x60/0x6c
up+0x60/0x68
__up_console_sem+0x4c/0x7c
console_unlock+0x328/0x634
vprintk_emit+0x25c/0x390
dev_vprintk_emit+0xc4/0x1fc
dev_printk_emit+0x88/0xa8
__dev_printk+0x58/0x9c
_dev_info+0x84/0xa8
usb_new_device+0x100/0x474
hub_port_connect+0x280/0x92c
hub_event+0x740/0xa84
process_one_work+0x240/0x70c
worker_thread+0x60/0x400
kthread+0x110/0x13c
ret_from_fork+0x10/0x18

-> #0 ((console_sem).lock){-...}:
validate_chain.isra.34+0x6e4/0xa20
__lock_acquire+0x3b4/0x6e0
lock_acquire+0xf4/0x2a8
_raw_spin_lock_irqsave+0x58/0x70
down_trylock+0x20/0x4c
__down_trylock_console_sem+0x3c/0x9c
console_trylock+0x20/0xb0
vprintk_emit+0x254/0x390
vprintk_default+0x58/0x90
vprintk_func+0xbc/0x164
printk+0x80/0xa0
__dynamic_pr_debug+0x84/0xac
gic_raise_softirq+0x184/0x18c
smp_cross_call+0xac/0x218
smp_send_reschedule+0x3c/0x48
resched_curr+0x60/0x9c
check_preempt_curr+0x70/0xdc
wake_up_new_task+0x310/0x470
_do_fork+0x188/0x78c
SyS_clone+0x44/0x50
__sys_trace_return+0x0/0x4

other info that might help us debug this:

Chain exists of:
(console_sem).lock --> &p->pi_lock --> &rq->lock

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
lock(&rq->lock);
lock(&p->pi_lock);
lock(&rq->lock);
lock((console_sem).lock);

*** DEADLOCK ***

2 locks held by dynamic_debug01/1873:
#0: (&p->pi_lock){-.-.}, at: [<000000001366df53>] wake_up_new_task+0x40/0x470
#1: (&rq->lock){-.-.}, at: [<00000000842e1587>] __task_rq_lock+0x54/0xdc

stack backtrace:
CPU: 10 PID: 1873 Comm: dynamic_debug01 Tainted: G W 4.15.0+ #1
Hardware name: GIGABYTE R120-T34-00/MT30-GS2-00, BIOS T48 10/02/2017
Call trace:
dump_backtrace+0x0/0x188
show_stack+0x24/0x2c
dump_stack+0xa4/0xe0
print_circular_bug.isra.31+0x29c/0x2b8
check_prev_add.constprop.39+0x6c8/0x6dc
validate_chain.isra.34+0x6e4/0xa20
__lock_acquire+0x3b4/0x6e0
lock_acquire+0xf4/0x2a8
_raw_spin_lock_irqsave+0x58/0x70
down_trylock+0x20/0x4c
__down_trylock_console_sem+0x3c/0x9c
console_trylock+0x20/0xb0
vprintk_emit+0x254/0x390
vprintk_default+0x58/0x90
vprintk_func+0xbc/0x164
printk+0x80/0xa0
__dynamic_pr_debug+0x84/0xac
gic_raise_softirq+0x184/0x18c
smp_cross_call+0xac/0x218
smp_send_reschedule+0x3c/0x48
resched_curr+0x60/0x9c
check_preempt_curr+0x70/0xdc
wake_up_new_task+0x310/0x470
_do_fork+0x188/0x78c
SyS_clone+0x44/0x50
__sys_trace_return+0x0/0x4
GICv3: CPU0: ICC_SGI1R_EL1 12000

This could be fixed with printk_deferred() but that might lessen its
usefulness for debugging. So change it to pr_devel to keep it out of
production kernels. Developers working on gic-v3 can enable it as
needed in their kernels.

Signed-off-by: Mark Salter <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/irqchip/irq-gic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -589,7 +589,7 @@ static void gic_send_sgi(u64 cluster_id,
MPIDR_TO_SGI_AFFINITY(cluster_id, 1) |
tlist << ICC_SGI1R_TARGET_LIST_SHIFT);

- pr_debug("CPU%d: ICC_SGI1R_EL1 %llx\n", smp_processor_id(), val);
+ pr_devel("CPU%d: ICC_SGI1R_EL1 %llx\n", smp_processor_id(), val);
gic_write_sgi1r(val);
}




2018-05-28 15:45:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 067/268] bcache: fix for data collapse after re-attaching an attached device

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

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

From: Tang Junhui <[email protected]>

[ Upstream commit 73ac105be390c1de42a2f21643c9778a5e002930 ]

back-end device sdm has already attached a cache_set with ID
f67ebe1f-f8bc-4d73-bfe5-9dc88607f119, then try to attach with
another cache set, and it returns with an error:
[root]# cd /sys/block/sdm/bcache
[root]# echo 5ccd0a63-148e-48b8-afa2-aca9cbd6279f > attach
-bash: echo: write error: Invalid argument

After that, execute a command to modify the label of bcache
device:
[root]# echo data_disk1 > label

Then we reboot the system, when the system power on, the back-end
device can not attach to cache_set, a messages show in the log:
Feb 5 12:05:52 ceph152 kernel: [922385.508498] bcache:
bch_cached_dev_attach() couldn't find uuid for sdm in set

In sysfs_attach(), dc->sb.set_uuid was assigned to the value
which input through sysfs, no matter whether it is success
or not in bch_cached_dev_attach(). For example, If the back-end
device has already attached to an cache set, bch_cached_dev_attach()
would fail, but dc->sb.set_uuid was changed. Then modify the
label of bcache device, it will call bch_write_bdev_super(),
which would write the dc->sb.set_uuid to the super block, so we
record a wrong cache set ID in the super block, after the system
reboot, the cache set couldn't find the uuid of the back-end
device, so the bcache device couldn't exist and use any more.

In this patch, we don't assigned cache set ID to dc->sb.set_uuid
in sysfs_attach() directly, but input it into bch_cached_dev_attach(),
and assigned dc->sb.set_uuid to the cache set ID after the back-end
device attached to the cache set successful.

Signed-off-by: Tang Junhui <[email protected]>
Reviewed-by: Michael Lyle <[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/md/bcache/bcache.h | 2 +-
drivers/md/bcache/super.c | 10 ++++++----
drivers/md/bcache/sysfs.c | 6 ++++--
3 files changed, 11 insertions(+), 7 deletions(-)

--- a/drivers/md/bcache/bcache.h
+++ b/drivers/md/bcache/bcache.h
@@ -904,7 +904,7 @@ void bcache_write_super(struct cache_set

int bch_flash_dev_create(struct cache_set *c, uint64_t size);

-int bch_cached_dev_attach(struct cached_dev *, struct cache_set *);
+int bch_cached_dev_attach(struct cached_dev *, struct cache_set *, uint8_t *);
void bch_cached_dev_detach(struct cached_dev *);
void bch_cached_dev_run(struct cached_dev *);
void bcache_device_stop(struct bcache_device *);
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -936,7 +936,8 @@ void bch_cached_dev_detach(struct cached
cached_dev_put(dc);
}

-int bch_cached_dev_attach(struct cached_dev *dc, struct cache_set *c)
+int bch_cached_dev_attach(struct cached_dev *dc, struct cache_set *c,
+ uint8_t *set_uuid)
{
uint32_t rtime = cpu_to_le32(get_seconds());
struct uuid_entry *u;
@@ -945,7 +946,8 @@ int bch_cached_dev_attach(struct cached_

bdevname(dc->bdev, buf);

- if (memcmp(dc->sb.set_uuid, c->sb.set_uuid, 16))
+ if ((set_uuid && memcmp(set_uuid, c->sb.set_uuid, 16)) ||
+ (!set_uuid && memcmp(dc->sb.set_uuid, c->sb.set_uuid, 16)))
return -ENOENT;

if (dc->disk.c) {
@@ -1189,7 +1191,7 @@ static void register_bdev(struct cache_s

list_add(&dc->list, &uncached_devices);
list_for_each_entry(c, &bch_cache_sets, list)
- bch_cached_dev_attach(dc, c);
+ bch_cached_dev_attach(dc, c, NULL);

if (BDEV_STATE(&dc->sb) == BDEV_STATE_NONE ||
BDEV_STATE(&dc->sb) == BDEV_STATE_STALE)
@@ -1711,7 +1713,7 @@ static void run_cache_set(struct cache_s
bcache_write_super(c);

list_for_each_entry_safe(dc, t, &uncached_devices, list)
- bch_cached_dev_attach(dc, c);
+ bch_cached_dev_attach(dc, c, NULL);

flash_devs_run(c);

--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -263,11 +263,13 @@ STORE(__cached_dev)
}

if (attr == &sysfs_attach) {
- if (bch_parse_uuid(buf, dc->sb.set_uuid) < 16)
+ uint8_t set_uuid[16];
+
+ if (bch_parse_uuid(buf, set_uuid) < 16)
return -EINVAL;

list_for_each_entry(c, &bch_cache_sets, list) {
- v = bch_cached_dev_attach(dc, c);
+ v = bch_cached_dev_attach(dc, c, set_uuid);
if (!v)
return size;
}



2018-05-28 15:45:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 070/268] locking/qspinlock: Ensure node->count is updated before initialising node

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

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

From: Will Deacon <[email protected]>

[ Upstream commit 11dc13224c975efcec96647a4768a6f1bb7a19a8 ]

When queuing on the qspinlock, the count field for the current CPU's head
node is incremented. This needn't be atomic because locking in e.g. IRQ
context is balanced and so an IRQ will return with node->count as it
found it.

However, the compiler could in theory reorder the initialisation of
node[idx] before the increment of the head node->count, causing an
IRQ to overwrite the initialised node and potentially corrupt the lock
state.

Avoid the potential for this harmful compiler reordering by placing a
barrier() between the increment of the head node->count and the subsequent
node initialisation.

Signed-off-by: Will Deacon <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/locking/qspinlock.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -423,6 +423,14 @@ queue:
tail = encode_tail(smp_processor_id(), idx);

node += idx;
+
+ /*
+ * Ensure that we increment the head node->count before initialising
+ * the actual node. If the compiler is kind enough to reorder these
+ * stores, then an IRQ could overwrite our assignments.
+ */
+ barrier();
+
node->locked = 0;
node->next = NULL;
pv_init_node(node);



2018-05-28 15:46:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 065/268] bcache: properly set task state in bch_writeback_thread()

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

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

From: Coly Li <[email protected]>

[ Upstream commit 99361bbf26337186f02561109c17a4c4b1a7536a ]

Kernel thread routine bch_writeback_thread() has the following code block,

447 down_write(&dc->writeback_lock);
448~450 if (check conditions) {
451 up_write(&dc->writeback_lock);
452 set_current_state(TASK_INTERRUPTIBLE);
453
454 if (kthread_should_stop())
455 return 0;
456
457 schedule();
458 continue;
459 }

If condition check is true, its task state is set to TASK_INTERRUPTIBLE
and call schedule() to wait for others to wake up it.

There are 2 issues in current code,
1, Task state is set to TASK_INTERRUPTIBLE after the condition checks, if
another process changes the condition and call wake_up_process(dc->
writeback_thread), then at line 452 task state is set back to
TASK_INTERRUPTIBLE, the writeback kernel thread will lose a chance to be
waken up.
2, At line 454 if kthread_should_stop() is true, writeback kernel thread
will return to kernel/kthread.c:kthread() with TASK_INTERRUPTIBLE and
call do_exit(). It is not good to enter do_exit() with task state
TASK_INTERRUPTIBLE, in following code path might_sleep() is called and a
warning message is reported by __might_sleep(): "WARNING: do not call
blocking ops when !TASK_RUNNING; state=1 set at [xxxx]".

For the first issue, task state should be set before condition checks.
Ineed because dc->writeback_lock is required when modifying all the
conditions, calling set_current_state() inside code block where dc->
writeback_lock is hold is safe. But this is quite implicit, so I still move
set_current_state() before all the condition checks.

For the second issue, frankley speaking it does not hurt when kernel thread
exits with TASK_INTERRUPTIBLE state, but this warning message scares users,
makes them feel there might be something risky with bcache and hurt their
data. Setting task state to TASK_RUNNING before returning fixes this
problem.

In alloc.c:allocator_wait(), there is also a similar issue, and is also
fixed in this patch.

Changelog:
v3: merge two similar fixes into one patch
v2: fix the race issue in v1 patch.
v1: initial buggy fix.

Signed-off-by: Coly Li <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Michael Lyle <[email protected]>
Cc: Michael Lyle <[email protected]>
Cc: Junhui Tang <[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/md/bcache/alloc.c | 4 +++-
drivers/md/bcache/writeback.c | 7 +++++--
2 files changed, 8 insertions(+), 3 deletions(-)

--- a/drivers/md/bcache/alloc.c
+++ b/drivers/md/bcache/alloc.c
@@ -285,8 +285,10 @@ do { \
break; \
\
mutex_unlock(&(ca)->set->bucket_lock); \
- if (kthread_should_stop()) \
+ if (kthread_should_stop()) { \
+ set_current_state(TASK_RUNNING); \
return 0; \
+ } \
\
try_to_freeze(); \
schedule(); \
--- a/drivers/md/bcache/writeback.c
+++ b/drivers/md/bcache/writeback.c
@@ -425,19 +425,22 @@ static int bch_writeback_thread(void *ar

while (!kthread_should_stop()) {
down_write(&dc->writeback_lock);
+ set_current_state(TASK_INTERRUPTIBLE);
if (!atomic_read(&dc->has_dirty) ||
(!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags) &&
!dc->writeback_running)) {
up_write(&dc->writeback_lock);
- set_current_state(TASK_INTERRUPTIBLE);

- if (kthread_should_stop())
+ if (kthread_should_stop()) {
+ set_current_state(TASK_RUNNING);
return 0;
+ }

try_to_freeze();
schedule();
continue;
}
+ set_current_state(TASK_RUNNING);

searched_full_index = refill_dirty(dc);




2018-05-28 15:46:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 069/268] tools/libbpf: handle issues with bpf ELF objects containing .eh_frames

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

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

From: Jesper Dangaard Brouer <[email protected]>

[ Upstream commit e3d91b0ca523d53158f435a3e13df7f0cb360ea2 ]

V3: More generic skipping of relo-section (suggested by Daniel)

If clang >= 4.0.1 is missing the option '-target bpf', it will cause
llc/llvm to create two ELF sections for "Exception Frames", with
section names '.eh_frame' and '.rel.eh_frame'.

The BPF ELF loader library libbpf fails when loading files with these
sections. The other in-kernel BPF ELF loader in samples/bpf/bpf_load.c,
handle this gracefully. And iproute2 loader also seems to work with these
"eh" sections.

The issue in libbpf is caused by bpf_object__elf_collect() skipping
some sections, and later when performing relocation it will be
pointing to a skipped section, as these sections cannot be found by
bpf_object__find_prog_by_idx() in bpf_object__collect_reloc().

This is a general issue that also occurs for other sections, like
debug sections which are also skipped and can have relo section.

As suggested by Daniel. To avoid keeping state about all skipped
sections, instead perform a direct qlookup in the ELF object. Lookup
the section that the relo-section points to and check if it contains
executable machine instructions (denoted by the sh_flags
SHF_EXECINSTR). Use this check to also skip irrelevant relo-sections.

Note, for samples/bpf/ the '-target bpf' parameter to clang cannot be used
due to incompatibility with asm embedded headers, that some of the samples
include. This is explained in more details by Yonghong Song in bpf_devel_QA.

Signed-off-by: Jesper Dangaard Brouer <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/lib/bpf/libbpf.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)

--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -487,6 +487,24 @@ bpf_object__init_maps(struct bpf_object
return 0;
}

+static bool section_have_execinstr(struct bpf_object *obj, int idx)
+{
+ Elf_Scn *scn;
+ GElf_Shdr sh;
+
+ scn = elf_getscn(obj->efile.elf, idx);
+ if (!scn)
+ return false;
+
+ if (gelf_getshdr(scn, &sh) != &sh)
+ return false;
+
+ if (sh.sh_flags & SHF_EXECINSTR)
+ return true;
+
+ return false;
+}
+
static int bpf_object__elf_collect(struct bpf_object *obj)
{
Elf *elf = obj->efile.elf;
@@ -567,6 +585,14 @@ static int bpf_object__elf_collect(struc
} else if (sh.sh_type == SHT_REL) {
void *reloc = obj->efile.reloc;
int nr_reloc = obj->efile.nr_reloc + 1;
+ int sec = sh.sh_info; /* points to other section */
+
+ /* Only do relo for section with exec instructions */
+ if (!section_have_execinstr(obj, sec)) {
+ pr_debug("skip relo %s(%d) for section(%d)\n",
+ name, idx, sec);
+ continue;
+ }

reloc = realloc(reloc,
sizeof(*obj->efile.reloc) * nr_reloc);



2018-05-28 15:47:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 043/268] powerpc/numa: Ensure nodes initialized for hotplug

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

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

From: Michael Bringmann <[email protected]>

[ Upstream commit ea05ba7c559c8e5a5946c3a94a2a266e9a6680a6 ]

This patch fixes some problems encountered at runtime with
configurations that support memory-less nodes, or that hot-add CPUs
into nodes that are memoryless during system execution after boot. The
problems of interest include:

* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node.

* Nodes which have no resources assigned at boot, but which may still
be referenced subsequently by affinity or associativity attributes,
are kept in the list of 'possible' nodes for powerpc. Hot-add of
memory or CPUs to the system can reference these nodes and bring
them online instead of redirecting the references to one of the set
of nodes known to have memory at boot.

Note that this software operates under the context of CPU hotplug. We
are not doing memory hotplug in this code, but rather updating the
kernel's CPU topology (i.e. arch_update_cpu_topology /
numa_update_cpu_topology). We are initializing a node that may be used
by CPUs or memory before it can be referenced as invalid by a CPU
hotplug operation. CPU hotplug operations are protected by a range of
APIs including cpu_maps_update_begin/cpu_maps_update_done,
cpus_read/write_lock / cpus_read/write_unlock, device locks, and more.
Memory hotplug operations, including try_online_node, are protected by
mem_hotplug_begin/mem_hotplug_done, device locks, and more. In the
case of CPUs being hot-added to a previously memoryless node, the
try_online_node operation occurs wholly within the CPU locks with no
overlap. Using HMC hot-add/hot-remove operations, we have been able to
add and remove CPUs to any possible node without failures. HMC
operations involve a degree self-serialization, though.

Signed-off-by: Michael Bringmann <[email protected]>
Reviewed-by: Nathan Fontenot <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/mm/numa.c | 47 +++++++++++++++++++++++++++++++++++++----------
1 file changed, 37 insertions(+), 10 deletions(-)

--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -551,7 +551,7 @@ static int numa_setup_cpu(unsigned long
nid = of_node_to_nid_single(cpu);

out_present:
- if (nid < 0 || !node_online(nid))
+ if (nid < 0 || !node_possible(nid))
nid = first_online_node;

map_cpu_to_node(lcpu, nid);
@@ -969,10 +969,8 @@ static void __init find_possible_nodes(v
goto out;

for (i = 0; i < numnodes; i++) {
- if (!node_possible(i)) {
- setup_node_data(i, 0, 0);
+ if (!node_possible(i))
node_set(i, node_possible_map);
- }
}

out:
@@ -1335,6 +1333,40 @@ static long vphn_get_associativity(unsig
return rc;
}

+static inline int find_and_online_cpu_nid(int cpu)
+{
+ __be32 associativity[VPHN_ASSOC_BUFSIZE] = {0};
+ int new_nid;
+
+ /* Use associativity from first thread for all siblings */
+ vphn_get_associativity(cpu, associativity);
+ new_nid = associativity_to_nid(associativity);
+ if (new_nid < 0 || !node_possible(new_nid))
+ new_nid = first_online_node;
+
+ if (NODE_DATA(new_nid) == NULL) {
+#ifdef CONFIG_MEMORY_HOTPLUG
+ /*
+ * Need to ensure that NODE_DATA is initialized for a node from
+ * available memory (see memblock_alloc_try_nid). If unable to
+ * init the node, then default to nearest node that has memory
+ * installed.
+ */
+ if (try_online_node(new_nid))
+ new_nid = first_online_node;
+#else
+ /*
+ * Default to using the nearest node that has memory installed.
+ * Otherwise, it would be necessary to patch the kernel MM code
+ * to deal with more memoryless-node error conditions.
+ */
+ new_nid = first_online_node;
+#endif
+ }
+
+ return new_nid;
+}
+
/*
* Update the CPU maps and sysfs entries for a single CPU when its NUMA
* characteristics change. This function doesn't perform any locking and is
@@ -1400,7 +1432,6 @@ int arch_update_cpu_topology(void)
{
unsigned int cpu, sibling, changed = 0;
struct topology_update_data *updates, *ud;
- __be32 associativity[VPHN_ASSOC_BUFSIZE] = {0};
cpumask_t updated_cpus;
struct device *dev;
int weight, new_nid, i = 0;
@@ -1435,11 +1466,7 @@ int arch_update_cpu_topology(void)
continue;
}

- /* Use associativity from first thread for all siblings */
- vphn_get_associativity(cpu, associativity);
- new_nid = associativity_to_nid(associativity);
- if (new_nid < 0 || !node_online(new_nid))
- new_nid = first_online_node;
+ new_nid = find_and_online_cpu_nid(cpu);

if (new_nid == numa_cpu_lookup_table[cpu]) {
cpumask_andnot(&cpu_associativity_changes_mask,



2018-05-28 15:47:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 061/268] RDS: IB: Fix null pointer issue

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

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

From: Guanglei Li <[email protected]>

[ Upstream commit 2c0aa08631b86a4678dbc93b9caa5248014b4458 ]

Scenario:
1. Port down and do fail over
2. Ap do rds_bind syscall

PID: 47039 TASK: ffff89887e2fe640 CPU: 47 COMMAND: "kworker/u:6"
#0 [ffff898e35f159f0] machine_kexec at ffffffff8103abf9
#1 [ffff898e35f15a60] crash_kexec at ffffffff810b96e3
#2 [ffff898e35f15b30] oops_end at ffffffff8150f518
#3 [ffff898e35f15b60] no_context at ffffffff8104854c
#4 [ffff898e35f15ba0] __bad_area_nosemaphore at ffffffff81048675
#5 [ffff898e35f15bf0] bad_area_nosemaphore at ffffffff810487d3
#6 [ffff898e35f15c00] do_page_fault at ffffffff815120b8
#7 [ffff898e35f15d10] page_fault at ffffffff8150ea95
[exception RIP: unknown or invalid address]
RIP: 0000000000000000 RSP: ffff898e35f15dc8 RFLAGS: 00010282
RAX: 00000000fffffffe RBX: ffff889b77f6fc00 RCX:ffffffff81c99d88
RDX: 0000000000000000 RSI: ffff896019ee08e8 RDI:ffff889b77f6fc00
RBP: ffff898e35f15df0 R8: ffff896019ee08c8 R9:0000000000000000
R10: 0000000000000400 R11: 0000000000000000 R12:ffff896019ee08c0
R13: ffff889b77f6fe68 R14: ffffffff81c99d80 R15: ffffffffa022a1e0
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#8 [ffff898e35f15dc8] cma_ndev_work_handler at ffffffffa022a228 [rdma_cm]
#9 [ffff898e35f15df8] process_one_work at ffffffff8108a7c6
#10 [ffff898e35f15e58] worker_thread at ffffffff8108bda0
#11 [ffff898e35f15ee8] kthread at ffffffff81090fe6

PID: 45659 TASK: ffff880d313d2500 CPU: 31 COMMAND: "oracle_45659_ap"
#0 [ffff881024ccfc98] __schedule at ffffffff8150bac4
#1 [ffff881024ccfd40] schedule at ffffffff8150c2cf
#2 [ffff881024ccfd50] __mutex_lock_slowpath at ffffffff8150cee7
#3 [ffff881024ccfdc0] mutex_lock at ffffffff8150cdeb
#4 [ffff881024ccfde0] rdma_destroy_id at ffffffffa022a027 [rdma_cm]
#5 [ffff881024ccfe10] rds_ib_laddr_check at ffffffffa0357857 [rds_rdma]
#6 [ffff881024ccfe50] rds_trans_get_preferred at ffffffffa0324c2a [rds]
#7 [ffff881024ccfe80] rds_bind at ffffffffa031d690 [rds]
#8 [ffff881024ccfeb0] sys_bind at ffffffff8142a670

PID: 45659 PID: 47039
rds_ib_laddr_check
/* create id_priv with a null event_handler */
rdma_create_id
rdma_bind_addr
cma_acquire_dev
/* add id_priv to cma_dev->id_list */
cma_attach_to_dev
cma_ndev_work_handler
/* event_hanlder is null */
id_priv->id.event_handler

Signed-off-by: Guanglei Li <[email protected]>
Signed-off-by: Honglei Wang <[email protected]>
Reviewed-by: Junxiao Bi <[email protected]>
Reviewed-by: Yanjun Zhu <[email protected]>
Reviewed-by: Leon Romanovsky <[email protected]>
Acked-by: Santosh Shilimkar <[email protected]>
Acked-by: Doug Ledford <[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/rds/ib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/net/rds/ib.c
+++ b/net/rds/ib.c
@@ -336,7 +336,8 @@ static int rds_ib_laddr_check(struct net
/* Create a CMA ID and try to bind it. This catches both
* IB and iWARP capable NICs.
*/
- cm_id = rdma_create_id(&init_net, NULL, NULL, RDMA_PS_TCP, IB_QPT_RC);
+ cm_id = rdma_create_id(&init_net, rds_rdma_cm_event_handler,
+ NULL, RDMA_PS_TCP, IB_QPT_RC);
if (IS_ERR(cm_id))
return PTR_ERR(cm_id);




2018-05-28 15:47:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 056/268] ACPI: processor_perflib: Do not send _PPC change notification if not ready

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

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

From: Chen Yu <[email protected]>

[ Upstream commit ba1edb9a5125a617d612f98eead14b9b84e75c3a ]

The following warning was triggered after resumed from S3 -
if all the nonboot CPUs were put offline before suspend:

[ 1840.329515] unchecked MSR access error: RDMSR from 0x771 at rIP: 0xffffffff86061e3a (native_read_msr+0xa/0x30)
[ 1840.329516] Call Trace:
[ 1840.329521] __rdmsr_on_cpu+0x33/0x50
[ 1840.329525] generic_exec_single+0x81/0xb0
[ 1840.329527] smp_call_function_single+0xd2/0x100
[ 1840.329530] ? acpi_ds_result_pop+0xdd/0xf2
[ 1840.329532] ? acpi_ds_create_operand+0x215/0x23c
[ 1840.329534] rdmsrl_on_cpu+0x57/0x80
[ 1840.329536] ? cpumask_next+0x1b/0x20
[ 1840.329538] ? rdmsrl_on_cpu+0x57/0x80
[ 1840.329541] intel_pstate_update_perf_limits+0xf3/0x220
[ 1840.329544] ? notifier_call_chain+0x4a/0x70
[ 1840.329546] intel_pstate_set_policy+0x4e/0x150
[ 1840.329548] cpufreq_set_policy+0xcd/0x2f0
[ 1840.329550] cpufreq_update_policy+0xb2/0x130
[ 1840.329552] ? cpufreq_update_policy+0x130/0x130
[ 1840.329556] acpi_processor_ppc_has_changed+0x65/0x80
[ 1840.329558] acpi_processor_notify+0x80/0x100
[ 1840.329561] acpi_ev_notify_dispatch+0x44/0x5c
[ 1840.329563] acpi_os_execute_deferred+0x14/0x20
[ 1840.329565] process_one_work+0x193/0x3c0
[ 1840.329567] worker_thread+0x35/0x3b0
[ 1840.329569] kthread+0x125/0x140
[ 1840.329571] ? process_one_work+0x3c0/0x3c0
[ 1840.329572] ? kthread_park+0x60/0x60
[ 1840.329575] ? do_syscall_64+0x67/0x180
[ 1840.329577] ret_from_fork+0x25/0x30
[ 1840.329585] unchecked MSR access error: WRMSR to 0x774 (tried to write 0x0000000000000000) at rIP: 0xffffffff86061f78 (native_write_msr+0x8/0x30)
[ 1840.329586] Call Trace:
[ 1840.329587] __wrmsr_on_cpu+0x37/0x40
[ 1840.329589] generic_exec_single+0x81/0xb0
[ 1840.329592] smp_call_function_single+0xd2/0x100
[ 1840.329594] ? acpi_ds_create_operand+0x215/0x23c
[ 1840.329595] ? cpumask_next+0x1b/0x20
[ 1840.329597] wrmsrl_on_cpu+0x57/0x70
[ 1840.329598] ? rdmsrl_on_cpu+0x57/0x80
[ 1840.329599] ? wrmsrl_on_cpu+0x57/0x70
[ 1840.329602] intel_pstate_hwp_set+0xd3/0x150
[ 1840.329604] intel_pstate_set_policy+0x119/0x150
[ 1840.329606] cpufreq_set_policy+0xcd/0x2f0
[ 1840.329607] cpufreq_update_policy+0xb2/0x130
[ 1840.329610] ? cpufreq_update_policy+0x130/0x130
[ 1840.329613] acpi_processor_ppc_has_changed+0x65/0x80
[ 1840.329615] acpi_processor_notify+0x80/0x100
[ 1840.329617] acpi_ev_notify_dispatch+0x44/0x5c
[ 1840.329619] acpi_os_execute_deferred+0x14/0x20
[ 1840.329620] process_one_work+0x193/0x3c0
[ 1840.329622] worker_thread+0x35/0x3b0
[ 1840.329624] kthread+0x125/0x140
[ 1840.329625] ? process_one_work+0x3c0/0x3c0
[ 1840.329626] ? kthread_park+0x60/0x60
[ 1840.329628] ? do_syscall_64+0x67/0x180
[ 1840.329631] ret_from_fork+0x25/0x30

This is because if there's only one online CPU, the MSR_PM_ENABLE
(package wide)can not be enabled after resumed, due to
intel_pstate_hwp_enable() will only be invoked on AP's online
process after resumed - if there's no AP online, the HWP remains
disabled after resumed (BIOS has disabled it in S3). Then if
there comes a _PPC change notification which touches HWP register
during this stage, the warning is triggered.

Since we don't call acpi_processor_register_performance() when
HWP is enabled, the pr->performance will be NULL. When this is
NULL we don't need to do _PPC change notification.

Reported-by: Doug Smythies <[email protected]>
Suggested-by: Srinivas Pandruvada <[email protected]>
Signed-off-by: Yu Chen <[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/processor_perflib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -161,7 +161,7 @@ int acpi_processor_ppc_has_changed(struc
{
int ret;

- if (ignore_ppc) {
+ if (ignore_ppc || !pr->performance) {
/*
* Only when it is notification event, the _OST object
* will be evaluated. Otherwise it is skipped.



2018-05-28 15:47:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 059/268] xen-netfront: Fix race between device setup and open

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

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

From: Ross Lagerwall <[email protected]>

[ Upstream commit f599c64fdf7d9c108e8717fb04bc41c680120da4 ]

When a netfront device is set up it registers a netdev fairly early on,
before it has set up the queues and is actually usable. A userspace tool
like NetworkManager will immediately try to open it and access its state
as soon as it appears. The bug can be reproduced by hotplugging VIFs
until the VM runs out of grant refs. It registers the netdev but fails
to set up any queues (since there are no more grant refs). In the
meantime, NetworkManager opens the device and the kernel crashes trying
to access the queues (of which there are none).

Fix this in two ways:
* For initial setup, register the netdev much later, after the queues
are setup. This avoids the race entirely.
* During a suspend/resume cycle, the frontend reconnects to the backend
and the queues are recreated. It is possible (though highly unlikely) to
race with something opening the device and accessing the queues after
they have been destroyed but before they have been recreated. Extend the
region covered by the rtnl semaphore to protect against this race. There
is a possibility that we fail to recreate the queues so check for this
in the open function.

Signed-off-by: Ross Lagerwall <[email protected]>
Reviewed-by: Boris Ostrovsky <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/xen-netfront.c | 46 +++++++++++++++++++++++----------------------
1 file changed, 24 insertions(+), 22 deletions(-)

--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -342,6 +342,9 @@ static int xennet_open(struct net_device
unsigned int i = 0;
struct netfront_queue *queue = NULL;

+ if (!np->queues)
+ return -ENODEV;
+
for (i = 0; i < num_queues; ++i) {
queue = &np->queues[i];
napi_enable(&queue->napi);
@@ -1363,18 +1366,8 @@ static int netfront_probe(struct xenbus_
#ifdef CONFIG_SYSFS
info->netdev->sysfs_groups[0] = &xennet_dev_group;
#endif
- err = register_netdev(info->netdev);
- if (err) {
- pr_warn("%s: register_netdev err=%d\n", __func__, err);
- goto fail;
- }

return 0;
-
- fail:
- xennet_free_netdev(netdev);
- dev_set_drvdata(&dev->dev, NULL);
- return err;
}

static void xennet_end_access(int ref, void *page)
@@ -1743,8 +1736,6 @@ static void xennet_destroy_queues(struct
{
unsigned int i;

- rtnl_lock();
-
for (i = 0; i < info->netdev->real_num_tx_queues; i++) {
struct netfront_queue *queue = &info->queues[i];

@@ -1753,8 +1744,6 @@ static void xennet_destroy_queues(struct
netif_napi_del(&queue->napi);
}

- rtnl_unlock();
-
kfree(info->queues);
info->queues = NULL;
}
@@ -1770,8 +1759,6 @@ static int xennet_create_queues(struct n
if (!info->queues)
return -ENOMEM;

- rtnl_lock();
-
for (i = 0; i < *num_queues; i++) {
struct netfront_queue *queue = &info->queues[i];

@@ -1780,7 +1767,7 @@ static int xennet_create_queues(struct n

ret = xennet_init_queue(queue);
if (ret < 0) {
- dev_warn(&info->netdev->dev,
+ dev_warn(&info->xbdev->dev,
"only created %d queues\n", i);
*num_queues = i;
break;
@@ -1794,10 +1781,8 @@ static int xennet_create_queues(struct n

netif_set_real_num_tx_queues(info->netdev, *num_queues);

- rtnl_unlock();
-
if (*num_queues == 0) {
- dev_err(&info->netdev->dev, "no queues\n");
+ dev_err(&info->xbdev->dev, "no queues\n");
return -EINVAL;
}
return 0;
@@ -1839,6 +1824,7 @@ static int talk_to_netback(struct xenbus
goto out;
}

+ rtnl_lock();
if (info->queues)
xennet_destroy_queues(info);

@@ -1849,6 +1835,7 @@ static int talk_to_netback(struct xenbus
info->queues = NULL;
goto out;
}
+ rtnl_unlock();

/* Create shared ring, alloc event channel -- for each queue */
for (i = 0; i < num_queues; ++i) {
@@ -1945,8 +1932,10 @@ abort_transaction_no_dev_fatal:
xenbus_transaction_end(xbt, 1);
destroy_ring:
xennet_disconnect_backend(info);
+ rtnl_lock();
xennet_destroy_queues(info);
out:
+ rtnl_unlock();
device_unregister(&dev->dev);
return err;
}
@@ -1982,6 +1971,15 @@ static int xennet_connect(struct net_dev
netdev_update_features(dev);
rtnl_unlock();

+ if (dev->reg_state == NETREG_UNINITIALIZED) {
+ err = register_netdev(dev);
+ if (err) {
+ pr_warn("%s: register_netdev err=%d\n", __func__, err);
+ device_unregister(&np->xbdev->dev);
+ return err;
+ }
+ }
+
/*
* All public and private state should now be sane. Get
* ready to start sending and receiving packets and give the driver
@@ -2172,10 +2170,14 @@ static int xennet_remove(struct xenbus_d

xennet_disconnect_backend(info);

- unregister_netdev(info->netdev);
+ if (info->netdev->reg_state == NETREG_REGISTERED)
+ unregister_netdev(info->netdev);

- if (info->queues)
+ if (info->queues) {
+ rtnl_lock();
xennet_destroy_queues(info);
+ rtnl_unlock();
+ }
xennet_free_netdev(info->netdev);

return 0;



2018-05-28 15:48:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 063/268] proc: fix /proc/*/map_files lookup

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

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

From: Alexey Dobriyan <[email protected]>

[ Upstream commit ac7f1061c2c11bb8936b1b6a94cdb48de732f7a4 ]

Current code does:

if (sscanf(dentry->d_name.name, "%lx-%lx", start, end) != 2)

However sscanf() is broken garbage.

It silently accepts whitespace between format specifiers
(did you know that?).

It silently accepts valid strings which result in integer overflow.

Do not use sscanf() for any even remotely reliable parsing code.

OK
# readlink '/proc/1/map_files/55a23af39000-55a23b05b000'
/lib/systemd/systemd

broken
# readlink '/proc/1/map_files/ 55a23af39000-55a23b05b000'
/lib/systemd/systemd

broken
# readlink '/proc/1/map_files/55a23af39000-55a23b05b000 '
/lib/systemd/systemd

very broken
# readlink '/proc/1/map_files/1000000000000000055a23af39000-55a23b05b000'
/lib/systemd/systemd

Andrei said:

: This patch breaks criu. It was a bug in criu. And this bug is on a minor
: path, which works when memfd_create() isn't available. It is a reason why
: I ask to not backport this patch to stable kernels.
:
: In CRIU this bug can be triggered, only if this patch will be backported
: to a kernel which version is lower than v3.16.

Link: http://lkml.kernel.org/r/20171120212706.GA14325@avx2
Signed-off-by: Alexey Dobriyan <[email protected]>
Cc: Pavel Emelyanov <[email protected]>
Cc: Andrei Vagin <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/proc/base.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)

--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -94,6 +94,8 @@
#include "internal.h"
#include "fd.h"

+#include "../../lib/kstrtox.h"
+
/* NOTE:
* Implementing inode permission operations in /proc is almost
* certainly an error. Permission checks need to happen during
@@ -1836,8 +1838,33 @@ end_instantiate:
static int dname_to_vma_addr(struct dentry *dentry,
unsigned long *start, unsigned long *end)
{
- if (sscanf(dentry->d_name.name, "%lx-%lx", start, end) != 2)
+ const char *str = dentry->d_name.name;
+ unsigned long long sval, eval;
+ unsigned int len;
+
+ len = _parse_integer(str, 16, &sval);
+ if (len & KSTRTOX_OVERFLOW)
+ return -EINVAL;
+ if (sval != (unsigned long)sval)
return -EINVAL;
+ str += len;
+
+ if (*str != '-')
+ return -EINVAL;
+ str++;
+
+ len = _parse_integer(str, 16, &eval);
+ if (len & KSTRTOX_OVERFLOW)
+ return -EINVAL;
+ if (eval != (unsigned long)eval)
+ return -EINVAL;
+ str += len;
+
+ if (*str != '\0')
+ return -EINVAL;
+
+ *start = sval;
+ *end = eval;

return 0;
}



2018-05-28 15:48:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 057/268] bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y

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

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

From: Yonghong Song <[email protected]>

[ Upstream commit 09584b406742413ac4c8d7e030374d4daa045b69 ]

With CONFIG_BPF_JIT_ALWAYS_ON is defined in the config file,
tools/testing/selftests/bpf/test_kmod.sh failed like below:
[root@localhost bpf]# ./test_kmod.sh
sysctl: setting key "net.core.bpf_jit_enable": Invalid argument
[ JIT enabled:0 hardened:0 ]
[ 132.175681] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
[ 132.458834] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
[ JIT enabled:1 hardened:0 ]
[ 133.456025] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
[ 133.730935] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
[ JIT enabled:1 hardened:1 ]
[ 134.769730] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
[ 135.050864] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
[ JIT enabled:1 hardened:2 ]
[ 136.442882] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
[ 136.821810] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
[root@localhost bpf]#

The test_kmod.sh load/remove test_bpf.ko multiple times with different
settings for sysctl net.core.bpf_jit_{enable,harden}. The failed test #297
of test_bpf.ko is designed such that JIT always fails.

Commit 290af86629b2 (bpf: introduce BPF_JIT_ALWAYS_ON config)
introduced the following tightening logic:
...
if (!bpf_prog_is_dev_bound(fp->aux)) {
fp = bpf_int_jit_compile(fp);
#ifdef CONFIG_BPF_JIT_ALWAYS_ON
if (!fp->jited) {
*err = -ENOTSUPP;
return fp;
}
#endif
...
With this logic, Test #297 always gets return value -ENOTSUPP
when CONFIG_BPF_JIT_ALWAYS_ON is defined, causing the test failure.

This patch fixed the failure by marking Test #297 as expected failure
when CONFIG_BPF_JIT_ALWAYS_ON is defined.

Fixes: 290af86629b2 (bpf: introduce BPF_JIT_ALWAYS_ON config)
Signed-off-by: Yonghong Song <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
lib/test_bpf.c | 31 ++++++++++++++++++++++++++-----
1 file changed, 26 insertions(+), 5 deletions(-)

--- a/lib/test_bpf.c
+++ b/lib/test_bpf.c
@@ -83,6 +83,7 @@ struct bpf_test {
__u32 result;
} test[MAX_SUBTESTS];
int (*fill_helper)(struct bpf_test *self);
+ int expected_errcode; /* used when FLAG_EXPECTED_FAIL is set in the aux */
__u8 frag_data[MAX_DATA];
};

@@ -1780,7 +1781,9 @@ static struct bpf_test tests[] = {
},
CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
{ },
- { }
+ { },
+ .fill_helper = NULL,
+ .expected_errcode = -EINVAL,
},
{
"check: div_k_0",
@@ -1790,7 +1793,9 @@ static struct bpf_test tests[] = {
},
CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
{ },
- { }
+ { },
+ .fill_helper = NULL,
+ .expected_errcode = -EINVAL,
},
{
"check: unknown insn",
@@ -1801,7 +1806,9 @@ static struct bpf_test tests[] = {
},
CLASSIC | FLAG_EXPECTED_FAIL,
{ },
- { }
+ { },
+ .fill_helper = NULL,
+ .expected_errcode = -EINVAL,
},
{
"check: out of range spill/fill",
@@ -1811,7 +1818,9 @@ static struct bpf_test tests[] = {
},
CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
{ },
- { }
+ { },
+ .fill_helper = NULL,
+ .expected_errcode = -EINVAL,
},
{
"JUMPS + HOLES",
@@ -1903,6 +1912,8 @@ static struct bpf_test tests[] = {
CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
{ },
{ },
+ .fill_helper = NULL,
+ .expected_errcode = -EINVAL,
},
{
"check: LDX + RET X",
@@ -1913,6 +1924,8 @@ static struct bpf_test tests[] = {
CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
{ },
{ },
+ .fill_helper = NULL,
+ .expected_errcode = -EINVAL,
},
{ /* Mainly checking JIT here. */
"M[]: alt STX + LDX",
@@ -2087,6 +2100,8 @@ static struct bpf_test tests[] = {
CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
{ },
{ },
+ .fill_helper = NULL,
+ .expected_errcode = -EINVAL,
},
{ /* Passes checker but fails during runtime. */
"LD [SKF_AD_OFF-1]",
@@ -4462,6 +4477,7 @@ static struct bpf_test tests[] = {
{ },
{ },
.fill_helper = bpf_fill_maxinsns4,
+ .expected_errcode = -EINVAL,
},
{ /* Mainly checking JIT here. */
"BPF_MAXINSNS: Very long jump",
@@ -4517,10 +4533,15 @@ static struct bpf_test tests[] = {
{
"BPF_MAXINSNS: Jump, gap, jump, ...",
{ },
+#ifdef CONFIG_BPF_JIT_ALWAYS_ON
+ CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
+#else
CLASSIC | FLAG_NO_DATA,
+#endif
{ },
{ { 0, 0xababcbac } },
.fill_helper = bpf_fill_maxinsns11,
+ .expected_errcode = -ENOTSUPP,
},
{
"BPF_MAXINSNS: ld_abs+get_processor_id",
@@ -5290,7 +5311,7 @@ static struct bpf_prog *generate_filter(

*err = bpf_prog_create(&fp, &fprog);
if (tests[which].aux & FLAG_EXPECTED_FAIL) {
- if (*err == -EINVAL) {
+ if (*err == tests[which].expected_errcode) {
pr_cont("PASS\n");
/* Verifier rejected filter as expected. */
*err = 0;



2018-05-28 15:48:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 058/268] MIPS: TXx9: use IS_BUILTIN() for CONFIG_LEDS_CLASS

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

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

From: Matt Redfearn <[email protected]>

[ Upstream commit 0cde5b44a30f1daaef1c34e08191239dc63271c4 ]

When commit b27311e1cace ("MIPS: TXx9: Add RBTX4939 board support")
added board support for the RBTX4939, it added a call to
led_classdev_register even if the LED class is built as a module.
Built-in arch code cannot call module code directly like this. Commit
b33b44073734 ("MIPS: TXX9: use IS_ENABLED() macro") subsequently
changed the inclusion of this code to a single check that
CONFIG_LEDS_CLASS is either builtin or a module, but the same issue
remains.

This leads to MIPS allmodconfig builds failing when CONFIG_MACH_TX49XX=y
is set:

arch/mips/txx9/rbtx4939/setup.o: In function `rbtx4939_led_probe':
setup.c:(.init.text+0xc0): undefined reference to `of_led_classdev_register'
make: *** [Makefile:999: vmlinux] Error 1

Fix this by using the IS_BUILTIN() macro instead.

Fixes: b27311e1cace ("MIPS: TXx9: Add RBTX4939 board support")
Signed-off-by: Matt Redfearn <[email protected]>
Reviewed-by: James Hogan <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/18544/
Signed-off-by: James Hogan <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/mips/txx9/rbtx4939/setup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/mips/txx9/rbtx4939/setup.c
+++ b/arch/mips/txx9/rbtx4939/setup.c
@@ -186,7 +186,7 @@ static void __init rbtx4939_update_ioc_p

#define RBTX4939_MAX_7SEGLEDS 8

-#if IS_ENABLED(CONFIG_LEDS_CLASS)
+#if IS_BUILTIN(CONFIG_LEDS_CLASS)
static u8 led_val[RBTX4939_MAX_7SEGLEDS];
struct rbtx4939_led_data {
struct led_classdev cdev;
@@ -261,7 +261,7 @@ static inline void rbtx4939_led_setup(vo

static void __rbtx4939_7segled_putc(unsigned int pos, unsigned char val)
{
-#if IS_ENABLED(CONFIG_LEDS_CLASS)
+#if IS_BUILTIN(CONFIG_LEDS_CLASS)
unsigned long flags;
local_irq_save(flags);
/* bit7: reserved for LED class */



2018-05-28 15:49:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 054/268] x86/power: Fix swsusp_arch_resume prototype

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

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

From: Arnd Bergmann <[email protected]>

[ Upstream commit 328008a72d38b5bde6491e463405c34a81a65d3e ]

The declaration for swsusp_arch_resume marks it as 'asmlinkage', but the
definition in x86-32 does not, and it fails to include the header with the
declaration. This leads to a warning when building with
link-time-optimizations:

kernel/power/power.h:108:23: error: type of 'swsusp_arch_resume' does not match original declaration [-Werror=lto-type-mismatch]
extern asmlinkage int swsusp_arch_resume(void);
^
arch/x86/power/hibernate_32.c:148:0: note: 'swsusp_arch_resume' was previously declared here
int swsusp_arch_resume(void)

This moves the declaration into a globally visible header file and fixes up
both x86 definitions to match it.

Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Nicolas Pitre <[email protected]>
Cc: [email protected]
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Pavel Machek <[email protected]>
Cc: Bart Van Assche <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/power/hibernate_32.c | 2 +-
arch/x86/power/hibernate_64.c | 2 +-
include/linux/suspend.h | 2 ++
kernel/power/power.h | 3 ---
4 files changed, 4 insertions(+), 5 deletions(-)

--- a/arch/x86/power/hibernate_32.c
+++ b/arch/x86/power/hibernate_32.c
@@ -142,7 +142,7 @@ static inline void resume_init_first_lev
#endif
}

-int swsusp_arch_resume(void)
+asmlinkage int swsusp_arch_resume(void)
{
int error;

--- a/arch/x86/power/hibernate_64.c
+++ b/arch/x86/power/hibernate_64.c
@@ -78,7 +78,7 @@ static int set_up_temporary_mappings(voi
return 0;
}

-int swsusp_arch_resume(void)
+asmlinkage int swsusp_arch_resume(void)
{
int error;

--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -377,6 +377,8 @@ extern int swsusp_page_is_forbidden(stru
extern void swsusp_set_page_free(struct page *);
extern void swsusp_unset_page_free(struct page *);
extern unsigned long get_safe_page(gfp_t gfp_mask);
+extern asmlinkage int swsusp_arch_suspend(void);
+extern asmlinkage int swsusp_arch_resume(void);

extern void hibernation_set_ops(const struct platform_hibernation_ops *ops);
extern int hibernate(void);
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -85,9 +85,6 @@ extern int in_suspend;
extern dev_t swsusp_resume_device;
extern sector_t swsusp_resume_block;

-extern asmlinkage int swsusp_arch_suspend(void);
-extern asmlinkage int swsusp_arch_resume(void);
-
extern int create_basic_memory_bitmaps(void);
extern void free_basic_memory_bitmaps(void);
extern int hibernate_preallocate_memory(void);



2018-05-28 15:49:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 055/268] firmware: dmi_scan: Fix handling of empty DMI strings

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

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

From: Jean Delvare <[email protected]>

[ Upstream commit a7770ae194569e96a93c48aceb304edded9cc648 ]

The handling of empty DMI strings looks quite broken to me:
* Strings from 1 to 7 spaces are not considered empty.
* True empty DMI strings (string index set to 0) are not considered
empty, and result in allocating a 0-char string.
* Strings with invalid index also result in allocating a 0-char
string.
* Strings starting with 8 spaces are all considered empty, even if
non-space characters follow (sounds like a weird thing to do, but
I have actually seen occurrences of this in DMI tables before.)
* Strings which are considered empty are reported as 8 spaces,
instead of being actually empty.

Some of these issues are the result of an off-by-one error in memcmp,
the rest is incorrect by design.

So let's get it square: missing strings and strings made of only
spaces, regardless of their length, should be treated as empty and
no memory should be allocated for them. All other strings are
non-empty and should be allocated.

Signed-off-by: Jean Delvare <[email protected]>
Fixes: 79da4721117f ("x86: fix DMI out of memory problems")
Cc: Parag Warudkar <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/firmware/dmi_scan.c | 22 +++++++++-------------
1 file changed, 9 insertions(+), 13 deletions(-)

--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -18,7 +18,7 @@ EXPORT_SYMBOL_GPL(dmi_kobj);
* of and an antecedent to, SMBIOS, which stands for System
* Management BIOS. See further: http://www.dmtf.org/standards
*/
-static const char dmi_empty_string[] = " ";
+static const char dmi_empty_string[] = "";

static u32 dmi_ver __initdata;
static u32 dmi_len;
@@ -44,25 +44,21 @@ static int dmi_memdev_nr;
static const char * __init dmi_string_nosave(const struct dmi_header *dm, u8 s)
{
const u8 *bp = ((u8 *) dm) + dm->length;
+ const u8 *nsp;

if (s) {
- s--;
- while (s > 0 && *bp) {
+ while (--s > 0 && *bp)
bp += strlen(bp) + 1;
- s--;
- }

- if (*bp != 0) {
- size_t len = strlen(bp)+1;
- size_t cmp_len = len > 8 ? 8 : len;
-
- if (!memcmp(bp, dmi_empty_string, cmp_len))
- return dmi_empty_string;
+ /* Strings containing only spaces are considered empty */
+ nsp = bp;
+ while (*nsp == ' ')
+ nsp++;
+ if (*nsp != '\0')
return bp;
- }
}

- return "";
+ return dmi_empty_string;
}

static const char * __init dmi_string(const struct dmi_header *dm, u8 s)



2018-05-28 15:49:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 060/268] xen/grant-table: Use put_page instead of free_page

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

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

From: Ross Lagerwall <[email protected]>

[ Upstream commit 3ac7292a25db1c607a50752055a18aba32ac2176 ]

The page given to gnttab_end_foreign_access() to free could be a
compound page so use put_page() instead of free_page() since it can
handle both compound and single pages correctly.

This bug was discovered when migrating a Xen VM with several VIFs and
CONFIG_DEBUG_VM enabled. It hits a BUG usually after fewer than 10
iterations. All netfront devices disconnect from the backend during a
suspend/resume and this will call gnttab_end_foreign_access() if a
netfront queue has an outstanding skb. The mismatch between calling
get_page() and free_page() on a compound page causes a reference
counting error which is detected when DEBUG_VM is enabled.

Signed-off-by: Ross Lagerwall <[email protected]>
Reviewed-by: Boris Ostrovsky <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/xen/grant-table.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -328,7 +328,7 @@ static void gnttab_handle_deferred(unsig
if (entry->page) {
pr_debug("freeing g.e. %#x (pfn %#lx)\n",
entry->ref, page_to_pfn(entry->page));
- __free_page(entry->page);
+ put_page(entry->page);
} else
pr_info("freeing g.e. %#x\n", entry->ref);
kfree(entry);
@@ -384,7 +384,7 @@ void gnttab_end_foreign_access(grant_ref
if (gnttab_end_foreign_access_ref(ref, readonly)) {
put_free_entry(ref);
if (page != 0)
- free_page(page);
+ put_page(virt_to_page(page));
} else
gnttab_add_deferred(ref, readonly,
page ? virt_to_page(page) : NULL);



2018-05-28 15:50:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 052/268] mm: pin address_space before dereferencing it while isolating an LRU page

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

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

From: Mel Gorman <[email protected]>

[ Upstream commit 69d763fc6d3aee787a3e8c8c35092b4f4960fa5d ]

Minchan Kim asked the following question -- what locks protects
address_space destroying when race happens between inode trauncation and
__isolate_lru_page? Jan Kara clarified by describing the race as follows

CPU1 CPU2

truncate(inode) __isolate_lru_page()
...
truncate_inode_page(mapping, page);
delete_from_page_cache(page)
spin_lock_irqsave(&mapping->tree_lock, flags);
__delete_from_page_cache(page, NULL)
page_cache_tree_delete(..)
... mapping = page_mapping(page);
page->mapping = NULL;
...
spin_unlock_irqrestore(&mapping->tree_lock, flags);
page_cache_free_page(mapping, page)
put_page(page)
if (put_page_testzero(page)) -> false
- inode now has no pages and can be freed including embedded address_space

if (mapping && !mapping->a_ops->migratepage)
- we've dereferenced mapping which is potentially already free.

The race is theoretically possible but unlikely. Before the
delete_from_page_cache, truncate_cleanup_page is called so the page is
likely to be !PageDirty or PageWriteback which gets skipped by the only
caller that checks the mappping in __isolate_lru_page. Even if the race
occurs, a substantial amount of work has to happen during a tiny window
with no preemption but it could potentially be done using a virtual
machine to artifically slow one CPU or halt it during the critical
window.

This patch should eliminate the race with truncation by try-locking the
page before derefencing mapping and aborting if the lock was not
acquired. There was a suggestion from Huang Ying to use RCU as a
side-effect to prevent mapping being freed. However, I do not like the
solution as it's an unconventional means of preserving a mapping and
it's not a context where rcu_read_lock is obviously protecting rcu data.

Link: http://lkml.kernel.org/r/[email protected]
Fixes: c82449352854 ("mm: compaction: make isolate_lru_page() filter-aware again")
Signed-off-by: Mel Gorman <[email protected]>
Acked-by: Minchan Kim <[email protected]>
Cc: "Huang, Ying" <[email protected]>
Cc: Jan Kara <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/vmscan.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)

--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1312,6 +1312,7 @@ int __isolate_lru_page(struct page *page

if (PageDirty(page)) {
struct address_space *mapping;
+ bool migrate_dirty;

/* ISOLATE_CLEAN means only clean pages */
if (mode & ISOLATE_CLEAN)
@@ -1320,10 +1321,19 @@ int __isolate_lru_page(struct page *page
/*
* Only pages without mappings or that have a
* ->migratepage callback are possible to migrate
- * without blocking
+ * without blocking. However, we can be racing with
+ * truncation so it's necessary to lock the page
+ * to stabilise the mapping as truncation holds
+ * the page lock until after the page is removed
+ * from the page cache.
*/
+ if (!trylock_page(page))
+ return ret;
+
mapping = page_mapping(page);
- if (mapping && !mapping->a_ops->migratepage)
+ migrate_dirty = mapping && mapping->a_ops->migratepage;
+ unlock_page(page);
+ if (!migrate_dirty)
return ret;
}
}



2018-05-28 15:50:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 051/268] asm-generic: provide generic_pmdp_establish()

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

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

From: "Kirill A. Shutemov" <[email protected]>

[ Upstream commit c58f0bb77ed8bf93dfdde762b01cb67eebbdfc29 ]

Patch series "Do not lose dirty bit on THP pages", v4.

Vlastimil noted that pmdp_invalidate() is not atomic and we can lose
dirty and access bits if CPU sets them after pmdp dereference, but
before set_pmd_at().

The bug can lead to data loss, but the race window is tiny and I haven't
seen any reports that suggested that it happens in reality. So I don't
think it worth sending it to stable.

Unfortunately, there's no way to address the issue in a generic way. We
need to fix all architectures that support THP one-by-one.

All architectures that have THP supported have to provide atomic
pmdp_invalidate() that returns previous value.

If generic implementation of pmdp_invalidate() is used, architecture
needs to provide atomic pmdp_estabish().

pmdp_estabish() is not used out-side generic implementation of
pmdp_invalidate() so far, but I think this can change in the future.

This patch (of 12):

This is an implementation of pmdp_establish() that is only suitable for
an architecture that doesn't have hardware dirty/accessed bits. In this
case we can't race with CPU which sets these bits and non-atomic
approach is fine.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Kirill A. Shutemov <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: Andrea Arcangeli <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Aneesh Kumar K.V <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: David Daney <[email protected]>
Cc: David Miller <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Martin Schwidefsky <[email protected]>
Cc: Nitin Gupta <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vineet Gupta <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/asm-generic/pgtable.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)

--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -237,6 +237,21 @@ extern void pgtable_trans_huge_deposit(s
extern pgtable_t pgtable_trans_huge_withdraw(struct mm_struct *mm, pmd_t *pmdp);
#endif

+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+/*
+ * This is an implementation of pmdp_establish() that is only suitable for an
+ * architecture that doesn't have hardware dirty/accessed bits. In this case we
+ * can't race with CPU which sets these bits and non-atomic aproach is fine.
+ */
+static inline pmd_t generic_pmdp_establish(struct vm_area_struct *vma,
+ unsigned long address, pmd_t *pmdp, pmd_t pmd)
+{
+ pmd_t old_pmd = *pmdp;
+ set_pmd_at(vma->vm_mm, address, pmdp, pmd);
+ return old_pmd;
+}
+#endif
+
#ifndef __HAVE_ARCH_PMDP_INVALIDATE
extern void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
pmd_t *pmdp);



2018-05-28 15:51:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 015/268] kernel/signal.c: avoid undefined behaviour in kill_something_info

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

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

From: zhongjiang <[email protected]>

commit 4ea77014af0d6205b05503d1c7aac6eace11d473 upstream.

When running kill(72057458746458112, 0) in userspace I hit the following
issue.

UBSAN: Undefined behaviour in kernel/signal.c:1462:11
negation of -2147483648 cannot be represented in type 'int':
CPU: 226 PID: 9849 Comm: test Tainted: G B ---- ------- 3.10.0-327.53.58.70.x86_64_ubsan+ #116
Hardware name: Huawei Technologies Co., Ltd. RH8100 V3/BC61PBIA, BIOS BLHSV028 11/11/2014
Call Trace:
dump_stack+0x19/0x1b
ubsan_epilogue+0xd/0x50
__ubsan_handle_negate_overflow+0x109/0x14e
SYSC_kill+0x43e/0x4d0
SyS_kill+0xe/0x10
system_call_fastpath+0x16/0x1b

Add code to avoid the UBSAN detection.

[[email protected]: tweak comment]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: zhongjiang <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: Xishi Qiu <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/signal.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1392,6 +1392,10 @@ static int kill_something_info(int sig,
return ret;
}

+ /* -INT_MIN is undefined. Exclude this case to avoid a UBSAN warning */
+ if (pid == INT_MIN)
+ return -ESRCH;
+
read_lock(&tasklist_lock);
if (pid != -1) {
ret = __kill_pgrp_info(sig, info,



2018-05-28 15:51:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 042/268] powerpc/numa: Use ibm,max-associativity-domains to discover possible nodes

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

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

From: Michael Bringmann <[email protected]>

[ Upstream commit a346137e9142b039fd13af2e59696e3d40c487ef ]

On powerpc systems which allow 'hot-add' of CPU or memory resources,
it may occur that the new resources are to be inserted into nodes that
were not used for these resources at bootup. In the kernel, any node
that is used must be defined and initialized. These empty nodes may
occur when,

* Dedicated vs. shared resources. Shared resources require information
such as the VPHN hcall for CPU assignment to nodes. Associativity
decisions made based on dedicated resource rules, such as
associativity properties in the device tree, may vary from decisions
made using the values returned by the VPHN hcall.

* memoryless nodes at boot. Nodes need to be defined as 'possible' at
boot for operation with other code modules. Previously, the powerpc
code would limit the set of possible nodes to those which have
memory assigned at boot, and were thus online. Subsequent add/remove
of CPUs or memory would only work with this subset of possible
nodes.

* memoryless nodes with CPUs at boot. Due to the previous restriction
on nodes, nodes that had CPUs but no memory were being collapsed
into other nodes that did have memory at boot. In practice this
meant that the node assignment presented by the runtime kernel
differed from the affinity and associativity attributes presented by
the device tree or VPHN hcalls. Nodes that might be known to the
pHyp were not 'possible' in the runtime kernel because they did not
have memory at boot.

This patch ensures that sufficient nodes are defined to support
configuration requirements after boot, as well as at boot. This patch
set fixes a couple of problems.

* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node. * Nodes which have no
resources assigned at boot, but which may still be referenced
subsequently by affinity or associativity attributes, are kept in
the list of 'possible' nodes for powerpc. Hot-add of memory or CPUs
to the system can reference these nodes and bring them online
instead of redirecting to one of the set of nodes that were known to
have memory at boot.

This patch extracts the value of the lowest domain level (number of
allocable resources) from the device tree property
"ibm,max-associativity-domains" to use as the maximum number of nodes
to setup as possibly available in the system. This new setting will
override the instruction:

nodes_and(node_possible_map, node_possible_map, node_online_map);

presently seen in the function arch/powerpc/mm/numa.c:initmem_init().

If the "ibm,max-associativity-domains" property is not present at
boot, no operation will be performed to define or enable additional
nodes, or enable the above 'nodes_and()'.

Signed-off-by: Michael Bringmann <[email protected]>
Reviewed-by: Nathan Fontenot <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/mm/numa.c | 37 ++++++++++++++++++++++++++++++++++---
1 file changed, 34 insertions(+), 3 deletions(-)

--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -951,6 +951,34 @@ static void __init setup_node_data(int n
NODE_DATA(nid)->node_spanned_pages = spanned_pages;
}

+static void __init find_possible_nodes(void)
+{
+ struct device_node *rtas;
+ u32 numnodes, i;
+
+ if (min_common_depth <= 0)
+ return;
+
+ rtas = of_find_node_by_path("/rtas");
+ if (!rtas)
+ return;
+
+ if (of_property_read_u32_index(rtas,
+ "ibm,max-associativity-domains",
+ min_common_depth, &numnodes))
+ goto out;
+
+ for (i = 0; i < numnodes; i++) {
+ if (!node_possible(i)) {
+ setup_node_data(i, 0, 0);
+ node_set(i, node_possible_map);
+ }
+ }
+
+out:
+ of_node_put(rtas);
+}
+
void __init initmem_init(void)
{
int nid, cpu;
@@ -966,12 +994,15 @@ void __init initmem_init(void)
memblock_dump_all();

/*
- * Reduce the possible NUMA nodes to the online NUMA nodes,
- * since we do not support node hotplug. This ensures that we
- * lower the maximum NUMA node ID to what is actually present.
+ * Modify the set of possible NUMA nodes to reflect information
+ * available about the set of online nodes, and the set of nodes
+ * that we expect to make use of for this platform's affinity
+ * calculations.
*/
nodes_and(node_possible_map, node_possible_map, node_online_map);

+ find_possible_nodes();
+
for_each_online_node(nid) {
unsigned long start_pfn, end_pfn;




2018-05-28 15:52:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 014/268] kernel/sys.c: fix potential Spectre v1 issue

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

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

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

commit 23d6aef74da86a33fa6bb75f79565e0a16ee97c2 upstream.

`resource' can be controlled by user-space, hence leading to a potential
exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

kernel/sys.c:1474 __do_compat_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap)
kernel/sys.c:1455 __do_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap)

Fix this by sanitizing *resource* before using it to index
current->signal->rlim

Notice that given that speculation windows are large, the policy is to
kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/sys.c | 3 +++
1 file changed, 3 insertions(+)

--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -53,6 +53,8 @@
#include <linux/uidgid.h>
#include <linux/cred.h>

+#include <linux/nospec.h>
+
#include <linux/kmsg_dump.h>
/* Move somewhere else to avoid recompiling? */
#include <generated/utsrelease.h>
@@ -1311,6 +1313,7 @@ SYSCALL_DEFINE2(old_getrlimit, unsigned
if (resource >= RLIM_NLIMITS)
return -EINVAL;

+ resource = array_index_nospec(resource, RLIM_NLIMITS);
task_lock(current->group_leader);
x = current->signal->rlim[resource];
task_unlock(current->group_leader);



2018-05-28 15:52:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 010/268] xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent

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

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

From: Joe Jin <[email protected]>

commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.

When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
but Dom Heap is increased by the same size. Tracing raidconfig we found
that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
to apply memory. If the memory allocated by Dom0 is not in the DMA area,
it will exchange memory with Xen to meet the requiment. Later drivers
call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent()
the check condition (dev_addr + size - 1 <= dma_mask) is always false,
it prevents calling xen_destroy_contiguous_region() to return the memory
to the Xen DMA heap.

This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing
coherent alloc/dealloc check before swizzling the MFNs.".

Signed-off-by: Joe Jin <[email protected]>
Tested-by: John Sobecki <[email protected]>
Reviewed-by: Rzeszutek Wilk <[email protected]>
Cc: [email protected]
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -359,7 +359,7 @@ xen_swiotlb_free_coherent(struct device
* physical address */
phys = xen_bus_to_phys(dev_addr);

- if (((dev_addr + size - 1 > dma_mask)) ||
+ if (((dev_addr + size - 1 <= dma_mask)) ||
range_straddles_page_boundary(phys, size))
xen_destroy_contiguous_region(phys, order);




2018-05-28 15:52:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 013/268] kasan: fix memory hotplug during boot

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

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

From: David Hildenbrand <[email protected]>

commit 3f1959721558a976aaf9c2024d5bc884e6411bf7 upstream.

Using module_init() is wrong. E.g. ACPI adds and onlines memory before
our memory notifier gets registered.

This makes sure that ACPI memory detected during boot up will not result
in a kernel crash.

Easily reproducible with QEMU, just specify a DIMM when starting up.

Link: http://lkml.kernel.org/r/[email protected]
Fixes: 786a8959912e ("kasan: disable memory hotplug")
Signed-off-by: David Hildenbrand <[email protected]>
Acked-by: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/kasan/kasan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -548,5 +548,5 @@ static int __init kasan_memhotplug_init(
return 0;
}

-module_init(kasan_memhotplug_init);
+core_initcall(kasan_memhotplug_init);
#endif



2018-05-28 15:53:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 011/268] Revert "ipc/shm: Fix shmat mmap nil-page protection"

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

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

From: Davidlohr Bueso <[email protected]>

commit a73ab244f0dad8fffb3291b905f73e2d3eaa7c00 upstream.

Patch series "ipc/shm: shmat() fixes around nil-page".

These patches fix two issues reported[1] a while back by Joe and Andrea
around how shmat(2) behaves with nil-page.

The first reverts a commit that it was incorrectly thought that mapping
nil-page (address=0) was a no no with MAP_FIXED. This is not the case,
with the exception of SHM_REMAP; which is address in the second patch.

I chose two patches because it is easier to backport and it explicitly
reverts bogus behaviour. Both patches ought to be in -stable and ltp
testcases need updated (the added testcase around the cve can be
modified to just test for SHM_RND|SHM_REMAP).

[1] lkml.kernel.org/r/20180430172152.nfa564pvgpk3ut7p@linux-n805

This patch (of 2):

Commit 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection")
worked on the idea that we should not be mapping as root addr=0 and
MAP_FIXED. However, it was reported that this scenario is in fact
valid, thus making the patch both bogus and breaks userspace as well.

For example X11's libint10.so relies on shmat(1, SHM_RND) for lowmem
initialization[1].

[1] https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/int10/linux.c#n347
Link: http://lkml.kernel.org/r/[email protected]
Fixes: 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection")
Signed-off-by: Davidlohr Bueso <[email protected]>
Reported-by: Joe Lawrence <[email protected]>
Reported-by: Andrea Arcangeli <[email protected]>
Cc: Manfred Spraul <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
ipc/shm.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)

--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -1113,13 +1113,8 @@ long do_shmat(int shmid, char __user *sh
goto out;
else if ((addr = (ulong)shmaddr)) {
if (addr & (shmlba - 1)) {
- /*
- * Round down to the nearest multiple of shmlba.
- * For sane do_mmap_pgoff() parameters, avoid
- * round downs that trigger nil-page and MAP_FIXED.
- */
- if ((shmflg & SHM_RND) && addr >= shmlba)
- addr &= ~(shmlba - 1);
+ if (shmflg & SHM_RND)
+ addr &= ~(shmlba - 1); /* round down */
else
#ifndef __ARCH_FORCE_SHMLBA
if (addr & ~PAGE_MASK)



2018-05-28 15:53:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 038/268] Btrfs: fix scrub to repair raid6 corruption

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

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

From: Liu Bo <[email protected]>

[ Upstream commit 762221f095e3932669093466aaf4b85ed9ad2ac1 ]

The raid6 corruption is that,
suppose that all disks can be read without problems and if the content
that was read out doesn't match its checksum, currently for raid6
btrfs at most retries twice,

- the 1st retry is to rebuild with all other stripes, it'll eventually
be a raid5 xor rebuild,
- if the 1st fails, the 2nd retry will deliberately fail parity p so
that it will do raid6 style rebuild,

however, the chances are that another non-parity stripe content also
has something corrupted, so that the above retries are not able to
return correct content.

We've fixed normal reads to rebuild raid6 correctly with more retries
in Patch "Btrfs: make raid6 rebuild retry more"[1], this is to fix
scrub to do the exactly same rebuild process.

[1]: https://patchwork.kernel.org/patch/10091755/

Signed-off-by: Liu Bo <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/raid56.c | 18 ++++++++++++++----
fs/btrfs/volumes.c | 9 ++++++++-
2 files changed, 22 insertions(+), 5 deletions(-)

--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -2160,11 +2160,21 @@ int raid56_parity_recover(struct btrfs_r
}

/*
- * reconstruct from the q stripe if they are
- * asking for mirror 3
+ * Loop retry:
+ * for 'mirror == 2', reconstruct from all other stripes.
+ * for 'mirror_num > 2', select a stripe to fail on every retry.
*/
- if (mirror_num == 3)
- rbio->failb = rbio->real_stripes - 2;
+ if (mirror_num > 2) {
+ /*
+ * 'mirror == 3' is to fail the p stripe and
+ * reconstruct from the q stripe. 'mirror > 3' is to
+ * fail a data stripe and reconstruct from p+q stripe.
+ */
+ rbio->failb = rbio->real_stripes - (mirror_num - 1);
+ ASSERT(rbio->failb > 0);
+ if (rbio->failb <= rbio->faila)
+ rbio->failb--;
+ }

ret = lock_stripe_add(rbio);

--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -5056,7 +5056,14 @@ int btrfs_num_copies(struct btrfs_fs_inf
else if (map->type & BTRFS_BLOCK_GROUP_RAID5)
ret = 2;
else if (map->type & BTRFS_BLOCK_GROUP_RAID6)
- ret = 3;
+ /*
+ * There could be two corrupted data stripes, we need
+ * to loop retry in order to rebuild the correct data.
+ *
+ * Fail a stripe at a time on every retry except the
+ * stripe under reconstruction.
+ */
+ ret = map->num_stripes;
else
ret = 1;
free_extent_map(em);



2018-05-28 15:53:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 040/268] HID: roccat: prevent an out of bounds read in kovaplus_profile_activated()

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

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

From: Dan Carpenter <[email protected]>

[ Upstream commit 7ad81482cad67cbe1ec808490d1ddfc420c42008 ]

We get the "new_profile_index" value from the mouse device when we're
handling raw events. Smatch taints it as untrusted data and complains
that we need a bounds check. This seems like a reasonable warning
otherwise there is a small read beyond the end of the array.

Fixes: 0e70f97f257e ("HID: roccat: Add support for Kova[+] mouse")
Signed-off-by: Dan Carpenter <[email protected]>
Acked-by: Silvan Jegen <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hid/hid-roccat-kovaplus.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/hid/hid-roccat-kovaplus.c
+++ b/drivers/hid/hid-roccat-kovaplus.c
@@ -37,6 +37,8 @@ static uint kovaplus_convert_event_cpi(u
static void kovaplus_profile_activated(struct kovaplus_device *kovaplus,
uint new_profile_index)
{
+ if (new_profile_index >= ARRAY_SIZE(kovaplus->profile_settings))
+ return;
kovaplus->actual_profile = new_profile_index;
kovaplus->actual_cpi = kovaplus->profile_settings[new_profile_index].cpi_startup_level;
kovaplus->actual_x_sensitivity = kovaplus->profile_settings[new_profile_index].sensitivity_x;



2018-05-28 16:01:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 009/268] libata: blacklist Micron 500IT SSD with MU01 firmware

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

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

From: Sudip Mukherjee <[email protected]>

commit 136d769e0b3475d71350aa3648a116a6ee7a8f6c upstream.

While whitelisting Micron M500DC drives, the tweaked blacklist entry
enabled queued TRIM from M500IT variants also. But these do not support
queued TRIM. And while using those SSDs with the latest kernel we have
seen errors and even the partition table getting corrupted.

Some part from the dmesg:
[ 6.727384] ata1.00: ATA-9: Micron_M500IT_MTFDDAK060MBD, MU01, max UDMA/133
[ 6.727390] ata1.00: 117231408 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[ 6.741026] ata1.00: supports DRM functions and may not be fully accessible
[ 6.759887] ata1.00: configured for UDMA/133
[ 6.762256] scsi 0:0:0:0: Direct-Access ATA Micron_M500IT_MT MU01 PQ: 0 ANSI: 5

and then for the error:
[ 120.860334] ata1.00: exception Emask 0x1 SAct 0x7ffc0007 SErr 0x0 action 0x6 frozen
[ 120.860338] ata1.00: irq_stat 0x40000008
[ 120.860342] ata1.00: failed command: SEND FPDMA QUEUED
[ 120.860351] ata1.00: cmd 64/01:00:00:00:00/00:00:00:00:00/a0 tag 0 ncq dma 512 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x5 (timeout)
[ 120.860353] ata1.00: status: { DRDY }
[ 120.860543] ata1: hard resetting link
[ 121.166128] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 121.166376] ata1.00: supports DRM functions and may not be fully accessible
[ 121.186238] ata1.00: supports DRM functions and may not be fully accessible
[ 121.204445] ata1.00: configured for UDMA/133
[ 121.204454] ata1.00: device reported invalid CHS sector 0
[ 121.204541] sd 0:0:0:0: [sda] tag#18 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[ 121.204546] sd 0:0:0:0: [sda] tag#18 Sense Key : 0x5 [current]
[ 121.204550] sd 0:0:0:0: [sda] tag#18 ASC=0x21 ASCQ=0x4
[ 121.204555] sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x93 93 08 00 00 00 00 00 04 28 80 00 00 00 30 00 00
[ 121.204559] print_req_error: I/O error, dev sda, sector 272512

After few reboots with these errors, and the SSD is corrupted.
After blacklisting it, the errors are not seen and the SSD does not get
corrupted any more.

Fixes: 243918be6393 ("libata: Do not blacklist Micron M500DC")
Cc: Martin K. Petersen <[email protected]>
Cc: [email protected]
Signed-off-by: Sudip Mukherjee <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/ata/libata-core.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4251,6 +4251,8 @@ static const struct ata_blacklist_entry
{ "SanDisk SD7UB3Q*G1001", NULL, ATA_HORKAGE_NOLPM, },

/* devices that don't properly handle queued TRIM commands */
+ { "Micron_M500IT_*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |
+ ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |



2018-05-28 16:01:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 039/268] scsi: fas216: fix sense buffer initialization

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

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

From: Arnd Bergmann <[email protected]>

[ Upstream commit 96d5eaa9bb74d299508d811d865c2c41b38b0301 ]

While testing with the ARM specific memset() macro removed, I ran into a
compiler warning that shows an old bug:

drivers/scsi/arm/fas216.c: In function 'fas216_rq_sns_done':
drivers/scsi/arm/fas216.c:2014:40: error: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to provide an explicit length? [-Werror=sizeof-pointer-memaccess]

It turns out that the definition of the scsi_cmd structure changed back
in linux-2.6.25, so now we clear only four bytes (sizeof(pointer))
instead of 96 (SCSI_SENSE_BUFFERSIZE). I did not check whether we
actually need to initialize the buffer here, but it's clear that if we
do it, we should use the correct size.

Fixes: de25deb18016 ("[SCSI] use dynamically allocated sense buffer")
Signed-off-by: Arnd Bergmann <[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/arm/fas216.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/scsi/arm/fas216.c
+++ b/drivers/scsi/arm/fas216.c
@@ -2009,7 +2009,7 @@ static void fas216_rq_sns_done(FAS216_In
* have valid data in the sense buffer that could
* confuse the higher levels.
*/
- memset(SCpnt->sense_buffer, 0, sizeof(SCpnt->sense_buffer));
+ memset(SCpnt->sense_buffer, 0, SCSI_SENSE_BUFFERSIZE);
//printk("scsi%d.%c: sense buffer: ", info->host->host_no, '0' + SCpnt->device->id);
//{ int i; for (i = 0; i < 32; i++) printk("%02x ", SCpnt->sense_buffer[i]); printk("\n"); }
/*



2018-05-28 16:02:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 036/268] Btrfs: set plug for fsync

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

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

From: Liu Bo <[email protected]>

[ Upstream commit 343e4fc1c60971b0734de26dbbd475d433950982 ]

Setting plug can merge adjacent IOs before dispatching IOs to the disk
driver.

Without plug, it'd not be a problem for single disk usecases, but for
multiple disks using raid profile, a large IO can be split to several
IOs of stripe length, and plug can be helpful to bring them together
for each disk so that we can save several disk access.

Moreover, fsync issues synchronous writes, so plug can really take
effect.

Signed-off-by: Liu Bo <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/file.c | 9 +++++++++
1 file changed, 9 insertions(+)

--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1861,10 +1861,19 @@ int btrfs_release_file(struct inode *ino
static int start_ordered_ops(struct inode *inode, loff_t start, loff_t end)
{
int ret;
+ struct blk_plug plug;

+ /*
+ * This is only called in fsync, which would do synchronous writes, so
+ * a plug can merge adjacent IOs as much as possible. Esp. in case of
+ * multiple disks using raid profile, a large IO can be split to
+ * several segments of stripe length (currently 64K).
+ */
+ blk_start_plug(&plug);
atomic_inc(&BTRFS_I(inode)->sync_writers);
ret = btrfs_fdatawrite_range(inode, start, end);
atomic_dec(&BTRFS_I(inode)->sync_writers);
+ blk_finish_plug(&plug);

return ret;
}



2018-05-28 16:02:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 034/268] mac80211_hwsim: fix possible memory leak in hwsim_new_radio_nl()

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

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

From: "weiyongjun (A)" <[email protected]>

[ Upstream commit 0ddcff49b672239dda94d70d0fcf50317a9f4b51 ]

'hwname' is malloced in hwsim_new_radio_nl() and should be freed
before leaving from the error handling cases, otherwise it will cause
memory leak.

Fixes: ff4dd73dd2b4 ("mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length")
Signed-off-by: Wei Yongjun <[email protected]>
Reviewed-by: Ben Hutchings <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/mac80211_hwsim.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2925,8 +2925,10 @@ static int hwsim_new_radio_nl(struct sk_
if (info->attrs[HWSIM_ATTR_REG_CUSTOM_REG]) {
u32 idx = nla_get_u32(info->attrs[HWSIM_ATTR_REG_CUSTOM_REG]);

- if (idx >= ARRAY_SIZE(hwsim_world_regdom_custom))
+ if (idx >= ARRAY_SIZE(hwsim_world_regdom_custom)) {
+ kfree(hwname);
return -EINVAL;
+ }
param.regd = hwsim_world_regdom_custom[idx];
}




2018-05-28 16:03:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 032/268] kconfig: Fix automatic menu creation mem leak

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

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

From: Ulf Magnusson <[email protected]>

[ Upstream commit ae7440ef0c8013d68c00dad6900e7cce5311bb1c ]

expr_trans_compare() always allocates and returns a new expression,
giving the following leak outline:

...
*Allocate*
basedep = expr_trans_compare(basedep, E_UNEQUAL, &symbol_no);
...
for (menu = parent->next; menu; menu = menu->next) {
...
*Copy*
dep2 = expr_copy(basedep);
...
*Free copy*
expr_free(dep2);
}
*basedep lost!*

Fix by freeing 'basedep' after the loop.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

LEAK SUMMARY:
definitely lost: 344,376 bytes in 14,349 blocks
...

Summary after the fix:

LEAK SUMMARY:
definitely lost: 44,448 bytes in 1,852 blocks
...

Signed-off-by: Ulf Magnusson <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
scripts/kconfig/menu.c | 1 +
1 file changed, 1 insertion(+)

--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -364,6 +364,7 @@ void menu_finalize(struct menu *parent)
menu->parent = parent;
last_menu = menu;
}
+ expr_free(basedep);
if (last_menu) {
parent->list = parent->next;
parent->next = last_menu->next;



2018-05-28 16:03:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 037/268] btrfs: Fix out of bounds access in btrfs_search_slot

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

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

From: Nikolay Borisov <[email protected]>

[ Upstream commit 9ea2c7c9da13c9073e371c046cbbc45481ecb459 ]

When modifying a tree where the root is at BTRFS_MAX_LEVEL - 1 then
the level variable is going to be 7 (this is the max height of the
tree). On the other hand btrfs_cow_block is always called with
"level + 1" as an index into the nodes and slots arrays. This leads to
an out of bounds access. Admittdely this will be benign since an OOB
access of the nodes array will likely read the 0th element from the
slots array, which in this case is going to be 0 (since we start CoW at
the top of the tree). The OOB access into the slots array in turn will
read the 0th and 1st values of the locks array, which would both be 0
at the time. However, this benign behavior relies on the fact that the
path being passed hasn't been initialised, if it has already been used to
query a btree then it could potentially have populated the nodes/slots arrays.

Fix it by explicitly checking if we are at level 7 (the maximum allowed
index in nodes/slots arrays) and explicitly call the CoW routine with
NULL for parent's node/slot.

Signed-off-by: Nikolay Borisov <[email protected]>
Fixes-coverity-id: 711515
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/ctree.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)

--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -2769,6 +2769,8 @@ again:
* contention with the cow code
*/
if (cow) {
+ bool last_level = (level == (BTRFS_MAX_LEVEL - 1));
+
/*
* if we don't really need to cow this block
* then we don't want to set the path blocking,
@@ -2793,9 +2795,13 @@ again:
}

btrfs_set_path_blocking(p);
- err = btrfs_cow_block(trans, root, b,
- p->nodes[level + 1],
- p->slots[level + 1], &b);
+ if (last_level)
+ err = btrfs_cow_block(trans, root, b, NULL, 0,
+ &b);
+ else
+ err = btrfs_cow_block(trans, root, b,
+ p->nodes[level + 1],
+ p->slots[level + 1], &b);
if (err) {
ret = err;
goto done;



2018-05-28 16:03:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 028/268] dm thin: fix documentation relative to low water mark threshold

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

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

From: mulhern <[email protected]>

[ Upstream commit 9b28a1102efc75d81298198166ead87d643a29ce ]

Fixes:
1. The use of "exceeds" when the opposite of exceeds, falls below,
was meant.
2. Properly speaking, a table can not exceed a threshold.

It emphasizes the important point, which is that it is the userspace
daemon's responsibility to check for low free space when a device
is resumed, since it won't get a special event indicating low free
space in that situation.

Signed-off-by: mulhern <[email protected]>
Signed-off-by: Mike Snitzer <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Documentation/device-mapper/thin-provisioning.txt | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

--- a/Documentation/device-mapper/thin-provisioning.txt
+++ b/Documentation/device-mapper/thin-provisioning.txt
@@ -112,9 +112,11 @@ $low_water_mark is expressed in blocks o
free space on the data device drops below this level then a dm event
will be triggered which a userspace daemon should catch allowing it to
extend the pool device. Only one such event will be sent.
-Resuming a device with a new table itself triggers an event so the
-userspace daemon can use this to detect a situation where a new table
-already exceeds the threshold.
+
+No special event is triggered if a just resumed device's free space is below
+the low water mark. However, resuming a device always triggers an
+event; a userspace daemon should verify that free space exceeds the low
+water mark when handling this event.

A low water mark for the metadata device is maintained in the kernel and
will trigger a dm event if free space on the metadata device drops below



2018-05-28 16:04:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 020/268] ALSA: hda - Use IS_REACHABLE() for dependency on input

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

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

From: Takashi Iwai <[email protected]>

[ Upstream commit c469652bb5e8fb715db7d152f46d33b3740c9b87 ]

The commit ffcd28d88e4f ("ALSA: hda - Select INPUT for Realtek
HD-audio codec") introduced the reverse-selection of CONFIG_INPUT for
Realtek codec in order to avoid the mess with dependency between
built-in and modules. Later on, we obtained IS_REACHABLE() macro
exactly for this kind of problems, and now we can remove th INPUT
selection in Kconfig and put IS_REACHABLE(INPUT) to the appropriate
places in the code, so that the driver doesn't need to select other
subsystem forcibly.

Fixes: ffcd28d88e4f ("ALSA: hda - Select INPUT for Realtek HD-audio codec")
Reported-by: Randy Dunlap <[email protected]>
Acked-by: Randy Dunlap <[email protected]> # and build-tested
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/Kconfig | 1 -
sound/pci/hda/patch_realtek.c | 5 +++++
2 files changed, 5 insertions(+), 1 deletion(-)

--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -84,7 +84,6 @@ config SND_HDA_PATCH_LOADER
config SND_HDA_CODEC_REALTEK
tristate "Build Realtek HD-audio codec support"
select SND_HDA_GENERIC
- select INPUT
help
Say Y or M here to include Realtek HD-audio codec support in
snd-hda-intel driver, such as ALC880.
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -3495,6 +3495,7 @@ static void alc280_fixup_hp_gpio4(struct
}
}

+#if IS_REACHABLE(INPUT)
static void gpio2_mic_hotkey_event(struct hda_codec *codec,
struct hda_jack_callback *event)
{
@@ -3627,6 +3628,10 @@ static void alc233_fixup_lenovo_line2_mi
spec->kb_dev = NULL;
}
}
+#else /* INPUT */
+#define alc280_fixup_hp_gpio2_mic_hotkey NULL
+#define alc233_fixup_lenovo_line2_mic_hotkey NULL
+#endif /* INPUT */

static void alc269_fixup_hp_line1_mic1_led(struct hda_codec *codec,
const struct hda_fixup *fix, int action)



2018-05-28 16:04:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 027/268] tools lib traceevent: Fix get_field_str() for dynamic strings

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

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

From: "Steven Rostedt (VMware)" <[email protected]>

[ Upstream commit d777f8de99b05d399c0e4e51cdce016f26bd971b ]

If a field is a dynamic string, get_field_str() returned just the
offset/size value and not the string. Have it parse the offset/size
correctly to return the actual string. Otherwise filtering fails when
trying to filter fields that are dynamic strings.

Reported-by: Gopanapalli Pradeep <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
Acked-by: Namhyung Kim <[email protected]>
Cc: Andrew Morton <[email protected]>
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/lib/traceevent/parse-filter.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

--- a/tools/lib/traceevent/parse-filter.c
+++ b/tools/lib/traceevent/parse-filter.c
@@ -1867,17 +1867,25 @@ static const char *get_field_str(struct
struct pevent *pevent;
unsigned long long addr;
const char *val = NULL;
+ unsigned int size;
char hex[64];

/* If the field is not a string convert it */
if (arg->str.field->flags & FIELD_IS_STRING) {
val = record->data + arg->str.field->offset;
+ size = arg->str.field->size;
+
+ if (arg->str.field->flags & FIELD_IS_DYNAMIC) {
+ addr = *(unsigned int *)val;
+ val = record->data + (addr & 0xffff);
+ size = addr >> 16;
+ }

/*
* We need to copy the data since we can't be sure the field
* is null terminated.
*/
- if (*(val + arg->str.field->size - 1)) {
+ if (*(val + size - 1)) {
/* copy it */
memcpy(arg->str.buffer, val, arg->str.field->size);
/* the buffer is already NULL terminated */



2018-05-28 16:04:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 029/268] nfs: Do not convert nfs_idmap_cache_timeout to jiffies

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

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

From: Jan Chochol <[email protected]>

[ Upstream commit cbebc6ef4fc830f4040d4140bf53484812d5d5d9 ]

Since commit 57e62324e469 ("NFS: Store the legacy idmapper result in the
keyring") nfs_idmap_cache_timeout changed units from jiffies to seconds.
Unfortunately sysctl interface was not updated accordingly.

As a effect updating /proc/sys/fs/nfs/idmap_cache_timeout with some
value will incorrectly multiply this value by HZ.
Also reading /proc/sys/fs/nfs/idmap_cache_timeout will show real value
divided by HZ.

Fixes: 57e62324e469 ("NFS: Store the legacy idmapper result in the keyring")
Signed-off-by: Jan Chochol <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfs/nfs4sysctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/nfs/nfs4sysctl.c
+++ b/fs/nfs/nfs4sysctl.c
@@ -31,7 +31,7 @@ static struct ctl_table nfs4_cb_sysctls[
.data = &nfs_idmap_cache_timeout,
.maxlen = sizeof(int),
.mode = 0644,
- .proc_handler = proc_dointvec_jiffies,
+ .proc_handler = proc_dointvec,
},
{ }
};



2018-05-28 16:04:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 026/268] perf callchain: Fix attr.sample_max_stack setting

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

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

From: Arnaldo Carvalho de Melo <[email protected]>

[ Upstream commit 249d98e567e25dd03e015e2d31e1b7b9648f34df ]

When setting the "dwarf" unwinder for a specific event and not
specifying the max-stack, the attr.sample_max_stack ended up using an
uninitialized callchain_param.max_stack, fix it by using designated
initializers for that callchain_param variable, zeroing all non
explicitely initialized struct members.

Here is what happened:

# perf trace -vv --no-syscalls --max-stack 4 -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
callchain: type DWARF
callchain: stack dump size 8192
perf_event_attr:
type 2
size 112
config 0x730
{ sample_period, sample_freq } 1
sample_type IP|TID|TIME|ADDR|CALLCHAIN|CPU|PERIOD|RAW|REGS_USER|STACK_USER|DATA_SRC
exclude_callchain_user 1
{ wakeup_events, wakeup_watermark } 1
sample_regs_user 0xff0fff
sample_stack_user 8192
sample_max_stack 50656
sys_perf_event_open failed, error -75
Value too large for defined data type
# perf trace -vv --no-syscalls --max-stack 4 -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
callchain: type DWARF
callchain: stack dump size 8192
perf_event_attr:
type 2
size 112
config 0x730
sample_type IP|TID|TIME|ADDR|CALLCHAIN|CPU|PERIOD|RAW|REGS_USER|STACK_USER|DATA_SRC
exclude_callchain_user 1
sample_regs_user 0xff0fff
sample_stack_user 8192
sample_max_stack 30448
sys_perf_event_open failed, error -75
Value too large for defined data type
#

Now the attr.sample_max_stack is set to zero and the above works as
expected:

# perf trace --no-syscalls --max-stack 4 -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.072 ms

--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.072/0.072/0.072/0.000 ms
0.000 probe_libc:inet_pton:(7feb7a998350))
__inet_pton (inlined)
gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
__GI_getaddrinfo (inlined)
[0xffffaa39b6108f3f] (/usr/bin/ping)
#

Cc: Adrian Hunter <[email protected]>
Cc: David Ahern <[email protected]>
Cc: Hendrick Brueckner <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Thomas Richter <[email protected]>
Cc: Wang Nan <[email protected]>
Link: https://lkml.kernel.org/n/[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/util/evsel.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -624,13 +624,13 @@ static void apply_config_terms(struct pe
struct perf_evsel_config_term *term;
struct list_head *config_terms = &evsel->config_terms;
struct perf_event_attr *attr = &evsel->attr;
- struct callchain_param param;
+ /* callgraph default */
+ struct callchain_param param = {
+ .record_mode = callchain_param.record_mode,
+ };
u32 dump_size = 0;
char *callgraph_buf = NULL;

- /* callgraph default */
- param.record_mode = callchain_param.record_mode;
-
list_for_each_entry(term, config_terms, list) {
switch (term->type) {
case PERF_EVSEL__CONFIG_TERM_PERIOD:



2018-05-28 16:04:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 008/268] libata: Blacklist some Sandisk SSDs for NCQ

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

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

From: Tejun Heo <[email protected]>

commit 322579dcc865b94b47345ad1b6002ad167f85405 upstream.

Sandisk SSDs SD7SN6S256G and SD8SN8U256G are regularly locking up
regularly under sustained moderate load with NCQ enabled. Blacklist
for now.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Dave Jones <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/ata/libata-core.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4187,6 +4187,10 @@ static const struct ata_blacklist_entry
/* https://bugzilla.kernel.org/show_bug.cgi?id=15573 */
{ "C300-CTFDDAC128MAG", "0001", ATA_HORKAGE_NONCQ, },

+ /* Some Sandisk SSDs lock up hard with NCQ enabled. Reported on
+ SD7SN6S256G and SD8SN8U256G */
+ { "SanDisk SD[78]SN*G", NULL, ATA_HORKAGE_NONCQ, },
+
/* devices which puke on READ_NATIVE_MAX */
{ "HDS724040KLSA80", "KFAOA20N", ATA_HORKAGE_BROKEN_HPA, },
{ "WDC WD3200JD-00KLB0", "WD-WCAMR1130137", ATA_HORKAGE_BROKEN_HPA },



2018-05-28 16:05:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 021/268] ASoC: au1x: Fix timeout tests in au1xac97c_ac97_read()

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

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

From: Dan Carpenter <[email protected]>

[ Upstream commit 123af9043e93cb6f235207d260d50f832cdb5439 ]

The loop timeout doesn't work because it's a post op and ends with "tmo"
set to -1. I changed it from a post-op to a pre-op and I changed the
initial the starting value from 5 to 6 so we still iterate 5 times. I
left the other as it was because it's a large number.

Fixes: b3c70c9ea62a ("ASoC: Alchemy AC97C/I2SC audio support")
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/au1x/ac97c.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/sound/soc/au1x/ac97c.c
+++ b/sound/soc/au1x/ac97c.c
@@ -91,8 +91,8 @@ static unsigned short au1xac97c_ac97_rea
do {
mutex_lock(&ctx->lock);

- tmo = 5;
- while ((RD(ctx, AC97_STATUS) & STAT_CP) && tmo--)
+ tmo = 6;
+ while ((RD(ctx, AC97_STATUS) & STAT_CP) && --tmo)
udelay(21); /* wait an ac97 frame time */
if (!tmo) {
pr_debug("ac97rd timeout #1\n");
@@ -105,7 +105,7 @@ static unsigned short au1xac97c_ac97_rea
* poll, Forrest, poll...
*/
tmo = 0x10000;
- while ((RD(ctx, AC97_STATUS) & STAT_CP) && tmo--)
+ while ((RD(ctx, AC97_STATUS) & STAT_CP) && --tmo)
asm volatile ("nop");
data = RD(ctx, AC97_CMDRESP);




2018-05-28 16:06:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 024/268] PCI: Add function 1 DMA alias quirk for Marvell 9128

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

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

From: Alex Williamson <[email protected]>

[ Upstream commit aa008206634363ef800fbd5f0262016c9ff81dea ]

The Marvell 9128 is the original device generating bug 42679, from which
many other Marvell DMA alias quirks have been sourced, but we didn't have
positive confirmation of the fix on 9128 until now.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679
Link: https://www.spinics.net/lists/kvm/msg161459.html
Reported-by: Binarus <[email protected]>
Tested-by: Binarus <[email protected]>
Signed-off-by: Alex Williamson <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pci/quirks.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3614,6 +3614,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_M
quirk_dma_func1_alias);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9123,
quirk_dma_func1_alias);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9128,
+ quirk_dma_func1_alias);
/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c14 */
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9130,
quirk_dma_func1_alias);



2018-05-28 16:07:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 019/268] NFSv4: always set NFS_LOCK_LOST when a lock is lost.

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

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

From: NeilBrown <[email protected]>

[ Upstream commit dce2630c7da73b0634686bca557cc8945cc450c8 ]

There are 2 comments in the NFSv4 code which suggest that
SIGLOST should possibly be sent to a process. In these
cases a lock has been lost.
The current practice is to set NFS_LOCK_LOST so that
read/write returns EIO when a lock is lost.
So change these comments to code when sets NFS_LOCK_LOST.

One case is when lock recovery after apparent server restart
fails with NFS4ERR_DENIED, NFS4ERR_RECLAIM_BAD, or
NFS4ERRO_RECLAIM_CONFLICT. The other case is when a lock
attempt as part of lease recovery fails with NFS4ERR_DENIED.

In an ideal world, these should not happen. However I have
a packet trace showing an NFSv4.1 session getting
NFS4ERR_BADSESSION after an extended network parition. The
NFSv4.1 client treats this like server reboot until/unless
it get NFS4ERR_NO_GRACE, in which case it switches over to
"nograce" recovery mode. In this network trace, the client
attempts to recover a lock and the server (incorrectly)
reports NFS4ERR_DENIED rather than NFS4ERR_NO_GRACE. This
leads to the ineffective comment and the client then
continues to write using the OPEN stateid.

Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfs/nfs4proc.c | 12 ++++++++----
fs/nfs/nfs4state.c | 5 ++++-
2 files changed, 12 insertions(+), 5 deletions(-)

--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -1780,7 +1780,7 @@ static int nfs4_open_reclaim(struct nfs4
return ret;
}

-static int nfs4_handle_delegation_recall_error(struct nfs_server *server, struct nfs4_state *state, const nfs4_stateid *stateid, int err)
+static int nfs4_handle_delegation_recall_error(struct nfs_server *server, struct nfs4_state *state, const nfs4_stateid *stateid, struct file_lock *fl, int err)
{
switch (err) {
default:
@@ -1827,7 +1827,11 @@ static int nfs4_handle_delegation_recall
return -EAGAIN;
case -ENOMEM:
case -NFS4ERR_DENIED:
- /* kill_proc(fl->fl_pid, SIGLOST, 1); */
+ if (fl) {
+ struct nfs4_lock_state *lsp = fl->fl_u.nfs4_fl.owner;
+ if (lsp)
+ set_bit(NFS_LOCK_LOST, &lsp->ls_flags);
+ }
return 0;
}
return err;
@@ -1863,7 +1867,7 @@ int nfs4_open_delegation_recall(struct n
err = nfs4_open_recover_helper(opendata, FMODE_READ);
}
nfs4_opendata_put(opendata);
- return nfs4_handle_delegation_recall_error(server, state, stateid, err);
+ return nfs4_handle_delegation_recall_error(server, state, stateid, NULL, err);
}

static void nfs4_open_confirm_prepare(struct rpc_task *task, void *calldata)
@@ -6157,7 +6161,7 @@ int nfs4_lock_delegation_recall(struct f
if (err != 0)
return err;
err = _nfs4_do_setlk(state, F_SETLK, fl, NFS_LOCK_NEW);
- return nfs4_handle_delegation_recall_error(server, state, stateid, err);
+ return nfs4_handle_delegation_recall_error(server, state, stateid, fl, err);
}

struct nfs_release_lockowner_data {
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -1386,6 +1386,7 @@ static int nfs4_reclaim_locks(struct nfs
struct inode *inode = state->inode;
struct nfs_inode *nfsi = NFS_I(inode);
struct file_lock *fl;
+ struct nfs4_lock_state *lsp;
int status = 0;
struct file_lock_context *flctx = inode->i_flctx;
struct list_head *list;
@@ -1426,7 +1427,9 @@ restart:
case -NFS4ERR_DENIED:
case -NFS4ERR_RECLAIM_BAD:
case -NFS4ERR_RECLAIM_CONFLICT:
- /* kill_proc(fl->fl_pid, SIGLOST, 1); */
+ lsp = fl->fl_u.nfs4_fl.owner;
+ if (lsp)
+ set_bit(NFS_LOCK_LOST, &lsp->ls_flags);
status = 0;
}
spin_lock(&flctx->flc_lock);



2018-05-28 16:07:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 007/268] mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register

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

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

From: Corneliu Doban <[email protected]>

commit 5f651b870485ee60f5abbbd85195a6852978894a upstream.

When the host controller accepts only 32bit writes, the value of the
16bit TRANSFER_MODE register, that has the same 32bit address as the
16bit COMMAND register, needs to be saved and it will be written
in a 32bit write together with the command as this will trigger the
host to send the command on the SD interface.
When sending the tuning command, TRANSFER_MODE is written and then
sdhci_set_transfer_mode reads it back to clear AUTO_CMD12 bit and
write it again resulting in wrong value to be written because the
initial write value was saved in a shadow and the read-back returned
a wrong value, from the register.
Fix sdhci_iproc_readw to return the saved value of TRANSFER_MODE
when a saved value exist.
Same fix for read of BLOCK_SIZE and BLOCK_COUNT registers, that are
saved for a different reason, although a scenario that will cause the
mentioned problem on this registers is not probable.

Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver")
Signed-off-by: Corneliu Doban <[email protected]>
Signed-off-by: Scott Branden <[email protected]>
Cc: [email protected] # v4.1+
Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/mmc/host/sdhci-iproc.c | 30 +++++++++++++++++++++++++-----
1 file changed, 25 insertions(+), 5 deletions(-)

--- a/drivers/mmc/host/sdhci-iproc.c
+++ b/drivers/mmc/host/sdhci-iproc.c
@@ -32,6 +32,8 @@ struct sdhci_iproc_host {
const struct sdhci_iproc_data *data;
u32 shadow_cmd;
u32 shadow_blk;
+ bool is_cmd_shadowed;
+ bool is_blk_shadowed;
};

#define REG_OFFSET_IN_BITS(reg) ((reg) << 3 & 0x18)
@@ -47,8 +49,22 @@ static inline u32 sdhci_iproc_readl(stru

static u16 sdhci_iproc_readw(struct sdhci_host *host, int reg)
{
- u32 val = sdhci_iproc_readl(host, (reg & ~3));
- u16 word = val >> REG_OFFSET_IN_BITS(reg) & 0xffff;
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_iproc_host *iproc_host = sdhci_pltfm_priv(pltfm_host);
+ u32 val;
+ u16 word;
+
+ if ((reg == SDHCI_TRANSFER_MODE) && iproc_host->is_cmd_shadowed) {
+ /* Get the saved transfer mode */
+ val = iproc_host->shadow_cmd;
+ } else if ((reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) &&
+ iproc_host->is_blk_shadowed) {
+ /* Get the saved block info */
+ val = iproc_host->shadow_blk;
+ } else {
+ val = sdhci_iproc_readl(host, (reg & ~3));
+ }
+ word = val >> REG_OFFSET_IN_BITS(reg) & 0xffff;
return word;
}

@@ -104,13 +120,15 @@ static void sdhci_iproc_writew(struct sd

if (reg == SDHCI_COMMAND) {
/* Write the block now as we are issuing a command */
- if (iproc_host->shadow_blk != 0) {
+ if (iproc_host->is_blk_shadowed) {
sdhci_iproc_writel(host, iproc_host->shadow_blk,
SDHCI_BLOCK_SIZE);
- iproc_host->shadow_blk = 0;
+ iproc_host->is_blk_shadowed = false;
}
oldval = iproc_host->shadow_cmd;
- } else if (reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) {
+ iproc_host->is_cmd_shadowed = false;
+ } else if ((reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) &&
+ iproc_host->is_blk_shadowed) {
/* Block size and count are stored in shadow reg */
oldval = iproc_host->shadow_blk;
} else {
@@ -122,9 +140,11 @@ static void sdhci_iproc_writew(struct sd
if (reg == SDHCI_TRANSFER_MODE) {
/* Save the transfer mode until the command is issued */
iproc_host->shadow_cmd = newval;
+ iproc_host->is_cmd_shadowed = true;
} else if (reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) {
/* Save the block info until the command is issued */
iproc_host->shadow_blk = newval;
+ iproc_host->is_blk_shadowed = true;
} else {
/* Command or other regular 32-bit write */
sdhci_iproc_writel(host, newval, reg & ~3);



2018-05-28 16:07:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 003/268] KVM: Fix spelling mistake: "cop_unsuable" -> "cop_unusable"

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

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

From: Colin Ian King <[email protected]>

commit ba3696e94d9d590d9a7e55f68e81c25dba515191 upstream.

Trivial fix to spelling mistake in debugfs_entries text.

Fixes: 669e846e6c4e ("KVM/MIPS32: MIPS arch specific APIs for KVM")
Signed-off-by: Colin Ian King <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: <[email protected]> # 3.10+
Signed-off-by: James Hogan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/mips/kvm/mips.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -40,7 +40,7 @@ struct kvm_stats_debugfs_item debugfs_en
{ "cache", VCPU_STAT(cache_exits), KVM_STAT_VCPU },
{ "signal", VCPU_STAT(signal_exits), KVM_STAT_VCPU },
{ "interrupt", VCPU_STAT(int_exits), KVM_STAT_VCPU },
- { "cop_unsuable", VCPU_STAT(cop_unusable_exits), KVM_STAT_VCPU },
+ { "cop_unusable", VCPU_STAT(cop_unusable_exits), KVM_STAT_VCPU },
{ "tlbmod", VCPU_STAT(tlbmod_exits), KVM_STAT_VCPU },
{ "tlbmiss_ld", VCPU_STAT(tlbmiss_ld_exits), KVM_STAT_VCPU },
{ "tlbmiss_st", VCPU_STAT(tlbmiss_st_exits), KVM_STAT_VCPU },



2018-05-28 16:08:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 002/268] MIPS: Fix ptrace(2) PTRACE_PEEKUSR and PTRACE_POKEUSR accesses to o32 FGRs

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

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

From: Maciej W. Rozycki <[email protected]>

commit 9a3a92ccfe3620743d4ae57c987dc8e9c5f88996 upstream.

Check the TIF_32BIT_FPREGS task setting of the tracee rather than the
tracer in determining the layout of floating-point general registers in
the floating-point context, correcting access to odd-numbered registers
for o32 tracees where the setting disagrees between the two processes.

Fixes: 597ce1723e0f ("MIPS: Support for 64-bit FP with O32 binaries")
Signed-off-by: Maciej W. Rozycki <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: [email protected]
Cc: <[email protected]> # 3.14+
Signed-off-by: James Hogan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/mips/kernel/ptrace.c | 4 ++--
arch/mips/kernel/ptrace32.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)

--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -830,7 +830,7 @@ long arch_ptrace(struct task_struct *chi
fregs = get_fpu_regs(child);

#ifdef CONFIG_32BIT
- if (test_thread_flag(TIF_32BIT_FPREGS)) {
+ if (test_tsk_thread_flag(child, TIF_32BIT_FPREGS)) {
/*
* The odd registers are actually the high
* order bits of the values stored in the even
@@ -919,7 +919,7 @@ long arch_ptrace(struct task_struct *chi

init_fp_ctx(child);
#ifdef CONFIG_32BIT
- if (test_thread_flag(TIF_32BIT_FPREGS)) {
+ if (test_tsk_thread_flag(child, TIF_32BIT_FPREGS)) {
/*
* The odd registers are actually the high
* order bits of the values stored in the even
--- a/arch/mips/kernel/ptrace32.c
+++ b/arch/mips/kernel/ptrace32.c
@@ -97,7 +97,7 @@ long compat_arch_ptrace(struct task_stru
break;
}
fregs = get_fpu_regs(child);
- if (test_thread_flag(TIF_32BIT_FPREGS)) {
+ if (test_tsk_thread_flag(child, TIF_32BIT_FPREGS)) {
/*
* The odd registers are actually the high
* order bits of the values stored in the even
@@ -203,7 +203,7 @@ long compat_arch_ptrace(struct task_stru
sizeof(child->thread.fpu));
child->thread.fpu.fcr31 = 0;
}
- if (test_thread_flag(TIF_32BIT_FPREGS)) {
+ if (test_tsk_thread_flag(child, TIF_32BIT_FPREGS)) {
/*
* The odd registers are actually the high
* order bits of the values stored in the even



2018-05-28 16:08:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 016/268] xfs: remove racy hasattr check from attr ops

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

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

From: Brian Foster <[email protected]>

commit 5a93790d4e2df73e30c965ec6e49be82fc3ccfce upstream.

xfs_attr_[get|remove]() have unlocked attribute fork checks to optimize
away a lock cycle in cases where the fork does not exist or is otherwise
empty. This check is not safe, however, because an attribute fork short
form to extent format conversion includes a transient state that causes
the xfs_inode_hasattr() check to fail. Specifically,
xfs_attr_shortform_to_leaf() creates an empty extent format attribute
fork and then adds the existing shortform attributes to it.

This means that lookup of an existing xattr can spuriously return
-ENOATTR when racing against a setxattr that causes the associated
format conversion. This was originally reproduced by an untar on a
particularly configured glusterfs volume, but can also be reproduced on
demand with properly crafted xattr requests.

The format conversion occurs under the exclusive ilock. xfs_attr_get()
and xfs_attr_remove() already have the proper locking and checks further
down in the functions to handle this situation correctly. Drop the
unlocked checks to avoid the spurious failure and rely on the existing
logic.

Signed-off-by: Brian Foster <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Darrick J. Wong <[email protected]>
Signed-off-by: Darrick J. Wong <[email protected]>
Cc: Daniel Sangorrin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/xfs/libxfs/xfs_attr.c | 6 ------
1 file changed, 6 deletions(-)

--- a/fs/xfs/libxfs/xfs_attr.c
+++ b/fs/xfs/libxfs/xfs_attr.c
@@ -130,9 +130,6 @@ xfs_attr_get(
if (XFS_FORCED_SHUTDOWN(ip->i_mount))
return -EIO;

- if (!xfs_inode_hasattr(ip))
- return -ENOATTR;
-
error = xfs_attr_args_init(&args, ip, name, flags);
if (error)
return error;
@@ -417,9 +414,6 @@ xfs_attr_remove(
if (XFS_FORCED_SHUTDOWN(dp->i_mount))
return -EIO;

- if (!xfs_inode_hasattr(dp))
- return -ENOATTR;
-
error = xfs_attr_args_init(&args, dp, name, flags);
if (error)
return error;



2018-05-28 16:09:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 001/268] MIPS: ptrace: Expose FIR register through FP regset

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

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

From: Maciej W. Rozycki <[email protected]>

commit 71e909c0cdad28a1df1fa14442929e68615dee45 upstream.

Correct commit 7aeb753b5353 ("MIPS: Implement task_user_regset_view.")
and expose the FIR register using the unused 4 bytes at the end of the
NT_PRFPREG regset. Without that register included clients cannot use
the PTRACE_GETREGSET request to retrieve the complete FPU register set
and have to resort to one of the older interfaces, either PTRACE_PEEKUSR
or PTRACE_GETFPREGS, to retrieve the missing piece of data. Also the
register is irreversibly missing from core dumps.

This register is architecturally hardwired and read-only so the write
path does not matter. Ignore data supplied on writes then.

Fixes: 7aeb753b5353 ("MIPS: Implement task_user_regset_view.")
Signed-off-by: James Hogan <[email protected]>
Signed-off-by: Maciej W. Rozycki <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: [email protected]
Cc: <[email protected]> # 3.13+
Patchwork: https://patchwork.linux-mips.org/patch/19273/
Signed-off-by: James Hogan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/mips/kernel/ptrace.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)

--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -483,7 +483,7 @@ static int fpr_get_msa(struct task_struc
/*
* Copy the floating-point context to the supplied NT_PRFPREG buffer.
* Choose the appropriate helper for general registers, and then copy
- * the FCSR register separately.
+ * the FCSR and FIR registers separately.
*/
static int fpr_get(struct task_struct *target,
const struct user_regset *regset,
@@ -491,6 +491,7 @@ static int fpr_get(struct task_struct *t
void *kbuf, void __user *ubuf)
{
const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t);
+ const int fir_pos = fcr31_pos + sizeof(u32);
int err;

if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))
@@ -503,6 +504,12 @@ static int fpr_get(struct task_struct *t
err = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
&target->thread.fpu.fcr31,
fcr31_pos, fcr31_pos + sizeof(u32));
+ if (err)
+ return err;
+
+ err = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &boot_cpu_data.fpu_id,
+ fir_pos, fir_pos + sizeof(u32));

return err;
}
@@ -551,7 +558,8 @@ static int fpr_set_msa(struct task_struc
/*
* Copy the supplied NT_PRFPREG buffer to the floating-point context.
* Choose the appropriate helper for general registers, and then copy
- * the FCSR register separately.
+ * the FCSR register separately. Ignore the incoming FIR register
+ * contents though, as the register is read-only.
*
* We optimize for the case where `count % sizeof(elf_fpreg_t) == 0',
* which is supposed to have been guaranteed by the kernel before
@@ -565,6 +573,7 @@ static int fpr_set(struct task_struct *t
const void *kbuf, const void __user *ubuf)
{
const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t);
+ const int fir_pos = fcr31_pos + sizeof(u32);
u32 fcr31;
int err;

@@ -592,6 +601,11 @@ static int fpr_set(struct task_struct *t
ptrace_setfcr31(target, fcr31);
}

+ if (count > 0)
+ err = user_regset_copyin_ignore(&pos, &count, &kbuf, &ubuf,
+ fir_pos,
+ fir_pos + sizeof(u32));
+
return err;
}




2018-05-28 16:24:52

by Nathan Chancellor

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/268] 4.4.134-stable review

On Mon, May 28, 2018 at 11:59:34AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.134 release.
> There are 268 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 Wed May 30 10:00:40 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.134-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 with -Werror, and installed onto my Pixel 2 XL and
OnePlus 5.

No initial issues noticed in general usage or dmesg.

Thanks!
Nathan

2018-05-29 03:57:17

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/268] 4.4.134-stable review

On 05/28/2018 02:59 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.134 release.
> There are 268 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 Wed May 30 10:00:40 UTC 2018.
> Anything received after that time might be too late.
>
Build results:
total: 146 pass: 146 fail: 0
Qemu test results:
total: 127 pass: 127 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

2018-05-29 06:14:15

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/268] 4.4.134-stable review

On 28 May 2018 at 15:29, Greg Kroah-Hartman <[email protected]> wrote:
> This is the start of the stable review cycle for the 4.4.134 release.
> There are 268 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 Wed May 30 10:00:40 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.134-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.

NOTE:
The failed LTP test case "cve-2017-5669" is a waiver here.

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

kernel: 4.4.134-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: 186b201a52cb29a2970391841c16a97833fe7119
git describe: v4.4.133-269-g186b201a52cb
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.133-269-g186b201a52cb

No regressions (compared to build v4.4.133-270-gc7a377784d68)

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

Environments
--------------
- juno-r2 - arm64
- qemu_arm
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

Hikey test results,
Summary
------------------------------------------------------------------------

kernel: 4.4.134-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.134-rc1-hikey-20180528-206
git commit: c4a9948ea47675e12c3f2a5ff009b2d0cb6c7517
git describe: 4.4.134-rc1-hikey-20180528-206
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.134-rc1-hikey-20180528-206

No regressions (compared to build 4.4.134-rc1-hikey-20180528-205)

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

Environments
--------------
- hi6220-hikey - arm64
- qemu_arm64

Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests

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

2018-05-29 19:52:45

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/268] 4.4.134-stable review

On 05/28/2018 03:59 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.134 release.
> There are 268 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 Wed May 30 10:00:40 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.134-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-05-31 02:38:00

by Daniel Sangorrin

[permalink] [raw]
Subject: RE: [PATCH 4.4 011/268] Revert "ipc/shm: Fix shmat mmap nil-page protection"

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Davidlohr Bueso <[email protected]>
>
> commit a73ab244f0dad8fffb3291b905f73e2d3eaa7c00 upstream.
>
> Patch series "ipc/shm: shmat() fixes around nil-page".

Sorry for being a bit late (the pace is really fast here).

I have found a regression from 4.4.133-rc1 to 4.4.134-rc1 using Fuego LTP wrapper.

4.4.134-rc1
tst_test.c:982: INFO: Timeout per run is 0h 05m 00s
cve-2017-5669.c:62: INFO: Attempting to attach shared memory to null page
cve-2017-5669.c:74: INFO: Mapped shared memory to (nil)
cve-2017-5669.c:78: FAIL: We have mapped a VM address within the first 64Kb
cve-2017-5669.c:84: INFO: Touching shared memory to see if anything strange happens

4.4.133-rc1:
tst_test.c:982: INFO: Timeout per run is 0h 05m 00s
cve-2017-5669.c:62: INFO: Attempting to attach shared memory to null page
cve-2017-5669.c:67: PASS: shmat returned EINVAL

The culprits should be one or both of the two last commits to ipc/shm (one of them a revert).

- ipc/shm: fix shmat() nil address after round-down when remapping
- Revert "ipc/shm: Fix shmat mmap nil-page protection"

I need to investigate the concrete reason, but for now I just wanted to report it.

Thanks,
Daniel









>
> These patches fix two issues reported[1] a while back by Joe and Andrea
> around how shmat(2) behaves with nil-page.
>
> The first reverts a commit that it was incorrectly thought that mapping
> nil-page (address=0) was a no no with MAP_FIXED. This is not the case,
> with the exception of SHM_REMAP; which is address in the second patch.
>
> I chose two patches because it is easier to backport and it explicitly
> reverts bogus behaviour. Both patches ought to be in -stable and ltp
> testcases need updated (the added testcase around the cve can be
> modified to just test for SHM_RND|SHM_REMAP).
>
> [1] lkml.kernel.org/r/20180430172152.nfa564pvgpk3ut7p@linux-n805
>
> This patch (of 2):
>
> Commit 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection")
> worked on the idea that we should not be mapping as root addr=0 and
> MAP_FIXED. However, it was reported that this scenario is in fact
> valid, thus making the patch both bogus and breaks userspace as well.
>
> For example X11's libint10.so relies on shmat(1, SHM_RND) for lowmem
> initialization[1].
>
> [1]
> https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/int1
> 0/linux.c#n347
> Link: http://lkml.kernel.org/r/[email protected]
> Fixes: 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection")
> Signed-off-by: Davidlohr Bueso <[email protected]>
> Reported-by: Joe Lawrence <[email protected]>
> Reported-by: Andrea Arcangeli <[email protected]>
> Cc: Manfred Spraul <[email protected]>
> Cc: <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> Signed-off-by: Linus Torvalds <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> ---
> ipc/shm.c | 9 ++-------
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> --- a/ipc/shm.c
> +++ b/ipc/shm.c
> @@ -1113,13 +1113,8 @@ long do_shmat(int shmid, char __user *sh
> goto out;
> else if ((addr = (ulong)shmaddr)) {
> if (addr & (shmlba - 1)) {
> - /*
> - * Round down to the nearest multiple of shmlba.
> - * For sane do_mmap_pgoff() parameters, avoid
> - * round downs that trigger nil-page and MAP_FIXED.
> - */
> - if ((shmflg & SHM_RND) && addr >= shmlba)
> - addr &= ~(shmlba - 1);
> + if (shmflg & SHM_RND)
> + addr &= ~(shmlba - 1); /* round down */
> else
> #ifndef __ARCH_FORCE_SHMLBA
> if (addr & ~PAGE_MASK)
>
>




2018-05-31 06:35:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 011/268] Revert "ipc/shm: Fix shmat mmap nil-page protection"

On Thu, May 31, 2018 at 11:36:46AM +0900, Daniel Sangorrin wrote:
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Davidlohr Bueso <[email protected]>
> >
> > commit a73ab244f0dad8fffb3291b905f73e2d3eaa7c00 upstream.
> >
> > Patch series "ipc/shm: shmat() fixes around nil-page".
>
> Sorry for being a bit late (the pace is really fast here).
>
> I have found a regression from 4.4.133-rc1 to 4.4.134-rc1 using Fuego LTP wrapper.
>
> 4.4.134-rc1
> tst_test.c:982: INFO: Timeout per run is 0h 05m 00s
> cve-2017-5669.c:62: INFO: Attempting to attach shared memory to null page
> cve-2017-5669.c:74: INFO: Mapped shared memory to (nil)
> cve-2017-5669.c:78: FAIL: We have mapped a VM address within the first 64Kb
> cve-2017-5669.c:84: INFO: Touching shared memory to see if anything strange happens
>
> 4.4.133-rc1:
> tst_test.c:982: INFO: Timeout per run is 0h 05m 00s
> cve-2017-5669.c:62: INFO: Attempting to attach shared memory to null page
> cve-2017-5669.c:67: PASS: shmat returned EINVAL
>
> The culprits should be one or both of the two last commits to ipc/shm (one of them a revert).
>
> - ipc/shm: fix shmat() nil address after round-down when remapping
> - Revert "ipc/shm: Fix shmat mmap nil-page protection"
>
> I need to investigate the concrete reason, but for now I just wanted to report it.

Thanks for letting us know, but this was reported already. See the
emails on lkml with the subject:
Subject: Re: [PATCH 4.16 000/272] 4.16.13-stable review
from Davidlohr Bueso
Message-ID: <20180528213039.yy2madue67njkmw5@linux-n805>

where he discusses that the LTP test is incorrect and that the kernel
change is correct and that LTP is going to be fixed because of this.

thanks,

greg k-h

2018-05-31 07:38:30

by Daniel Sangorrin

[permalink] [raw]
Subject: RE: [PATCH 4.4 011/268] Revert "ipc/shm: Fix shmat mmap nil-page protection"

> -----Original Message-----
> From: 'Greg Kroah-Hartman' [mailto:[email protected]]
..
> Thanks for letting us know, but this was reported already. See the
> emails on lkml with the subject:
> Subject: Re: [PATCH 4.16 000/272] 4.16.13-stable review
> from Davidlohr Bueso
> Message-ID: <20180528213039.yy2madue67njkmw5@linux-n805>
>
> where he discusses that the LTP test is incorrect and that the kernel
> change is correct and that LTP is going to be fixed because of this.

OK, thank you for the information!

Regards,
Daniel



2018-05-31 15:57:02

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.4 011/268] Revert "ipc/shm: Fix shmat mmap nil-page protection"

On 31 May 2018 at 13:06, Daniel Sangorrin
<[email protected]> wrote:
>> -----Original Message-----
>> From: 'Greg Kroah-Hartman' [mailto:[email protected]]
> ..
>> Thanks for letting us know, but this was reported already. See the
>> emails on lkml with the subject:
>> Subject: Re: [PATCH 4.16 000/272] 4.16.13-stable review
>> from Davidlohr Bueso
>> Message-ID: <20180528213039.yy2madue67njkmw5@linux-n805>
>>
>> where he discusses that the LTP test is incorrect and that the kernel
>> change is correct and that LTP is going to be fixed because of this.

My two cents,
If you are referring to cve-2017-5669.c
LTP test case is been fixed few hours ago by Rafael Tinoco,

- shm_addr = shmat(shm_id, ((void *)1), SHM_RND);
+ shm_addr = shmat(shm_id, ((void *)1), SHM_RND | SHM_REMAP);

LTP patch pull request and it is been merged.
https://github.com/linux-test-project/ltp/pull/324

>
> OK, thank you for the information!
>

- Naresh

> Regards,
> Daniel
>
>

2018-06-04 00:38:28

by Daniel Sangorrin

[permalink] [raw]
Subject: RE: [PATCH 4.4 011/268] Revert "ipc/shm: Fix shmat mmap nil-page protection"

> -----Original Message-----
> From: Naresh Kamboju [mailto:[email protected]]
> Sent: Friday, June 1, 2018 12:55 AM
> To: Daniel Sangorrin <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>; open list
> <[email protected]>; linux- stable <[email protected]>;
> Davidlohr Bueso <[email protected]>; Joe Lawrence <[email protected]>;
> Andrea Arcangeli <[email protected]>; Manfred Spraul
> <[email protected]>; Andrew Morton <[email protected]>;
> Linus Torvalds <[email protected]>
> Subject: Re: [PATCH 4.4 011/268] Revert "ipc/shm: Fix shmat mmap nil-page
> protection"
>
> On 31 May 2018 at 13:06, Daniel Sangorrin
> <[email protected]> wrote:
> >> -----Original Message-----
> >> From: 'Greg Kroah-Hartman' [mailto:[email protected]]
> > ..
> >> Thanks for letting us know, but this was reported already. See the
> >> emails on lkml with the subject:
> >> Subject: Re: [PATCH 4.16 000/272] 4.16.13-stable review
> >> from Davidlohr Bueso
> >> Message-ID: <20180528213039.yy2madue67njkmw5@linux-n805>
> >>
> >> where he discusses that the LTP test is incorrect and that the kernel
> >> change is correct and that LTP is going to be fixed because of this.
>
> My two cents,
> If you are referring to cve-2017-5669.c
> LTP test case is been fixed few hours ago by Rafael Tinoco,
>
> - shm_addr = shmat(shm_id, ((void *)1), SHM_RND);
> + shm_addr = shmat(shm_id, ((void *)1), SHM_RND | SHM_REMAP);
>
> LTP patch pull request and it is been merged.
> https://github.com/linux-test-project/ltp/pull/324

Thanks a lot Naresh.
I confirmed that the latest LTP cve-2017-5669 now PASSes.

Thanks,
Daniel





2018-06-07 20:29:37

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 010/268] xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent

On Mon, 2018-05-28 at 11:59 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Joe Jin <[email protected]>
>
> commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.
>
> When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
> but Dom Heap is increased by the same size. Tracing raidconfig we found
> that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
> to apply memory. If the memory allocated by Dom0 is not in the DMA area,
> it will exchange memory with Xen to meet the requiment. Later drivers
> call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent()
> the check condition (dev_addr + size - 1 <= dma_mask) is always false,

I think this was meant to say (dev_addr + size - 1 > dma_mask), i.e.
the condition that is replaced by this commit. If that's always false,
the new condition (the logical inverse) must always be true.

[...]
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -359,7 +359,7 @@ xen_swiotlb_free_coherent(struct device
>    * physical address */
>   phys = xen_bus_to_phys(dev_addr);
>  
> - if (((dev_addr + size - 1 > dma_mask)) ||
> + if (((dev_addr + size - 1 <= dma_mask)) ||
>       range_straddles_page_boundary(phys, size))
>   xen_destroy_contiguous_region(phys, order);
>  

So now we will always call xen_destroy_contiguous_region(), whether or
not xen_create_contiguous_region() was called during allocation. Is
that really the intent? If so, the entire condition could be removed
to make this clear.

Alternately, if the commit message is correct, the condition could be
simplified to range_straddles_page_boundary(...).

But I'm not at all convinced that either of these is correct. It seems
like you need to either find a way of distinguishing between memory
allocated with or without the use of xen_create_contiguous_region(), or
to use it unconditionally.

Ben.

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

2018-06-07 21:00:49

by Joe Jin

[permalink] [raw]
Subject: Re: [PATCH 4.4 010/268] xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent

On 6/7/18 1:28 PM, Ben Hutchings wrote:
> On Mon, 2018-05-28 at 11:59 +0200, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch.  If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: Joe Jin <[email protected]>
>>
>> commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.
>>
>> When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
>> but Dom Heap is increased by the same size. Tracing raidconfig we found
>> that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
>> to apply memory. If the memory allocated by Dom0 is not in the DMA area,
>> it will exchange memory with Xen to meet the requiment. Later drivers
>> call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent()
>> the check condition (dev_addr + size - 1 <= dma_mask) is always false,
>
> I think this was meant to say (dev_addr + size - 1 > dma_mask), i.e.

Hi Ben,

Yes you are right, sorry I made the mistake, thanks for catch it.
Is there any way to fix description from git repo?

Regards,
Joe

> the condition that is replaced by this commit. If that's always false,
> the new condition (the logical inverse) must always be true.
>
> [...]
>> --- a/drivers/xen/swiotlb-xen.c
>> +++ b/drivers/xen/swiotlb-xen.c
>> @@ -359,7 +359,7 @@ xen_swiotlb_free_coherent(struct device
>>    * physical address */
>>   phys = xen_bus_to_phys(dev_addr);
>>  
>> - if (((dev_addr + size - 1 > dma_mask)) ||
>> + if (((dev_addr + size - 1 <= dma_mask)) ||
>>       range_straddles_page_boundary(phys, size))
>>   xen_destroy_contiguous_region(phys, order);
>>  
>
> So now we will always call xen_destroy_contiguous_region(), whether or
> not xen_create_contiguous_region() was called during allocation. Is
> that really the intent? If so, the entire condition could be removed
> to make this clear.
>
> Alternately, if the commit message is correct, the condition could be
> simplified to range_straddles_page_boundary(...).
>
> But I'm not at all convinced that either of these is correct. It seems
> like you need to either find a way of distinguishing between memory
> allocated with or without the use of xen_create_contiguous_region(), or
> to use it unconditionally.
>
> Ben.
>


--
Oracle <http://www.oracle.com>
Joe Jin | IT Director
ORACLE | Production Engineering and Operations
600 Oracle Parkway Redwood City, CA US 94065

2018-06-08 12:25:04

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 010/268] xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent

On Thu, 2018-06-07 at 13:59 -0700, Joe Jin wrote:
> On 6/7/18 1:28 PM, Ben Hutchings wrote:
> > On Mon, 2018-05-28 at 11:59 +0200, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Joe Jin <[email protected]>
> > >
> > > commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.
> > >
> > > When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
> > > but Dom Heap is increased by the same size. Tracing raidconfig we found
> > > that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
> > > to apply memory. If the memory allocated by Dom0 is not in the DMA area,
> > > it will exchange memory with Xen to meet the requiment. Later drivers
> > > call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent()
> > > the check condition (dev_addr + size - 1 <= dma_mask) is always false,
> >
> > I think this was meant to say (dev_addr + size - 1 > dma_mask), i.e.
>
> Hi Ben,
>
> Yes you are right, sorry I made the mistake, thanks for catch it.
> Is there any way to fix description from git repo?

No there isn't, but that wasn't my main point. Please address the rest
of my message.

Ben.

> Regards,
> Joe
>
> > the condition that is replaced by this commit.  If that's always false,
> > the new condition (the logical inverse) must always be true.
> >
> > [...]
> > > --- a/drivers/xen/swiotlb-xen.c
> > > +++ b/drivers/xen/swiotlb-xen.c
> > > @@ -359,7 +359,7 @@ xen_swiotlb_free_coherent(struct device
> > >    * physical address */
> > >   phys = xen_bus_to_phys(dev_addr);
> > >  
> > > - if (((dev_addr + size - 1 > dma_mask)) ||
> > > + if (((dev_addr + size - 1 <= dma_mask)) ||
> > >       range_straddles_page_boundary(phys, size))
> > >   xen_destroy_contiguous_region(phys, order);
> > >  
> >
> > So now we will always call xen_destroy_contiguous_region(), whether or
> > not xen_create_contiguous_region() was called during allocation.  Is
> > that really the intent?  If so, the entire condition could be removed
> > to make this clear.
> >
> > Alternately, if the commit message is correct, the condition could be
> > simplified to range_straddles_page_boundary(...).
> >
> > But I'm not at all convinced that either of these is correct.  It seems
> > like you need to either find a way of distinguishing between memory
> > allocated with or without the use of xen_create_contiguous_region(), or
> > to use it unconditionally.
> >
> > Ben.
> >
>
>
--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

2018-06-08 13:20:00

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 017/268] do d_instantiate/unlock_new_inode combinations safely

On Mon, 2018-05-28 at 11:59 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Al Viro <[email protected]>
>
> commit 1e2e547a93a00ebc21582c06ca3c6cfea2a309ee upstream.
>
> For anything NFS-exported we do _not_ want to unlock new inode
> before it has grown an alias; original set of fixes got the
> ordering right, but missed the nasty complication in case of
> lockdep being enabled - unlock_new_inode() does
> lockdep_annotate_inode_mutex_key(inode)
> which can only be done before anyone gets a chance to touch
> ->i_mutex.  Unfortunately, flipping the order and doing
> unlock_new_inode() before d_instantiate() opens a window when
> mkdir can race with open-by-fhandle on a guessed fhandle, leading
> to multiple aliases for a directory inode and all the breakage
> that follows from that.
>
> Correct solution: a new primitive (d_instantiate_new())
> combining these two in the right order - lockdep annotate, then
> d_instantiate(), then the rest of unlock_new_inode().  All
> combinations of d_instantiate() with unlock_new_inode() should
> be converted to that.
[...]

I think you missed xfs, which has a wrapper around unlock_new_inode()
called xfs_finish_inode_setup(). It looks like xfs_generic_create()
and xfs_vn_symlink() still need this conversion.

Ben.

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

2018-06-08 18:43:40

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 038/268] Btrfs: fix scrub to repair raid6 corruption

On Mon, 2018-05-28 at 12:00 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Liu Bo <[email protected]>
>
> [ Upstream commit 762221f095e3932669093466aaf4b85ed9ad2ac1 ]

The diff here is actually from commit 8810f7517a3b ("Btrfs: make raid6
rebuild retry more", mentioned in this commit message). (Sasha, please
try to work out why commit messages and descriptions are getting mixed
up in your auto-selections.)

Maybe stable branches should get the real commit 762221f095e3 as well?

Ben.

> The raid6 corruption is that,
> suppose that all disks can be read without problems and if the content
> that was read out doesn't match its checksum, currently for raid6
> btrfs at most retries twice,
>
> - the 1st retry is to rebuild with all other stripes, it'll eventually
>   be a raid5 xor rebuild,
> - if the 1st fails, the 2nd retry will deliberately fail parity p so
>   that it will do raid6 style rebuild,
>
> however, the chances are that another non-parity stripe content also
> has something corrupted, so that the above retries are not able to
> return correct content.
>
> We've fixed normal reads to rebuild raid6 correctly with more retries
> in Patch "Btrfs: make raid6 rebuild retry more"[1], this is to fix
> scrub to do the exactly same rebuild process.
>
> [1]: https://patchwork.kernel.org/patch/10091755/
>
> Signed-off-by: Liu Bo <[email protected]>
> Signed-off-by: David Sterba <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
>  fs/btrfs/raid56.c  |   18 ++++++++++++++----
>  fs/btrfs/volumes.c |    9 ++++++++-
>  2 files changed, 22 insertions(+), 5 deletions(-)
>
> --- a/fs/btrfs/raid56.c
> +++ b/fs/btrfs/raid56.c
> @@ -2160,11 +2160,21 @@ int raid56_parity_recover(struct btrfs_r
>   }
>  
>   /*
> -  * reconstruct from the q stripe if they are
> -  * asking for mirror 3
> +  * Loop retry:
> +  * for 'mirror == 2', reconstruct from all other stripes.
> +  * for 'mirror_num > 2', select a stripe to fail on every retry.
>    */
> - if (mirror_num == 3)
> - rbio->failb = rbio->real_stripes - 2;
> + if (mirror_num > 2) {
> + /*
> +  * 'mirror == 3' is to fail the p stripe and
> +  * reconstruct from the q stripe.  'mirror > 3' is to
> +  * fail a data stripe and reconstruct from p+q stripe.
> +  */
> + rbio->failb = rbio->real_stripes - (mirror_num - 1);
> + ASSERT(rbio->failb > 0);
> + if (rbio->failb <= rbio->faila)
> + rbio->failb--;
> + }
>  
>   ret = lock_stripe_add(rbio);
>  
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -5056,7 +5056,14 @@ int btrfs_num_copies(struct btrfs_fs_inf
>   else if (map->type & BTRFS_BLOCK_GROUP_RAID5)
>   ret = 2;
>   else if (map->type & BTRFS_BLOCK_GROUP_RAID6)
> - ret = 3;
> + /*
> +  * There could be two corrupted data stripes, we need
> +  * to loop retry in order to rebuild the correct data.
> +  *
> +  * Fail a stripe at a time on every retry except the
> +  * stripe under reconstruction.
> +  */
> + ret = map->num_stripes;
>   else
>   ret = 1;
>   free_extent_map(em);

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

2018-06-11 12:56:10

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 051/268] asm-generic: provide generic_pmdp_establish()

On Mon, 2018-05-28 at 12:00 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: "Kirill A. Shutemov" <[email protected]>
>
> [ Upstream commit c58f0bb77ed8bf93dfdde762b01cb67eebbdfc29 ]
>
> Patch series "Do not lose dirty bit on THP pages", v4.
>
> Vlastimil noted that pmdp_invalidate() is not atomic and we can lose
> dirty and access bits if CPU sets them after pmdp dereference, but
> before set_pmd_at().
>
> The bug can lead to data loss, but the race window is tiny and I haven't
> seen any reports that suggested that it happens in reality.  So I don't
> think it worth sending it to stable.
[...]
> This patch (of 12):
>
> This is an implementation of pmdp_establish() that is only suitable for
> an architecture that doesn't have hardware dirty/accessed bits.  In this
> case we can't race with CPU which sets these bits and non-atomic
> approach is fine.
[...]

There's no point in applying just this patch, since it adds a new
function that nothing will call.

I tend to think that since this is fixing a potential data loss, the
whole series should be backported. But the commit message here says it
shouldn't.

Ben.

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

2018-06-11 14:31:29

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 059/268] xen-netfront: Fix race between device setup and open

On Mon, 2018-05-28 at 12:00 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Ross Lagerwall <[email protected]>
>
> [ Upstream commit f599c64fdf7d9c108e8717fb04bc41c680120da4 ]
[...]
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
[...]
> @@ -1839,6 +1824,7 @@ static int talk_to_netback(struct xenbus
>   goto out;

This "goto out" is outside the locked section...

>   }
>  
> + rtnl_lock();
>   if (info->queues)
>   xennet_destroy_queues(info);
>  
> @@ -1849,6 +1835,7 @@ static int talk_to_netback(struct xenbus
>   info->queues = NULL;
>   goto out;
>   }
> + rtnl_unlock();
>  
>   /* Create shared ring, alloc event channel -- for each queue */
>   for (i = 0; i < num_queues; ++i) {
> @@ -1945,8 +1932,10 @@ abort_transaction_no_dev_fatal:
>   xenbus_transaction_end(xbt, 1);
>   destroy_ring:
>   xennet_disconnect_backend(info);
> + rtnl_lock();
>   xennet_destroy_queues(info);
>   out:
> + rtnl_unlock();

...so this will be an unmatched unlock.

You need to add another label below the rtnl_unlock().

Ben.

>   device_unregister(&dev->dev);
>   return err;
>  }
[...]

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

2018-06-12 18:49:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 051/268] asm-generic: provide generic_pmdp_establish()

On Mon, Jun 11, 2018 at 01:55:17PM +0100, Ben Hutchings wrote:
> On Mon, 2018-05-28 at 12:00 +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: "Kirill A. Shutemov" <[email protected]>
> >
> > [ Upstream commit c58f0bb77ed8bf93dfdde762b01cb67eebbdfc29 ]
> >
> > Patch series "Do not lose dirty bit on THP pages", v4.
> >
> > Vlastimil noted that pmdp_invalidate() is not atomic and we can lose
> > dirty and access bits if CPU sets them after pmdp dereference, but
> > before set_pmd_at().
> >
> > The bug can lead to data loss, but the race window is tiny and I haven't
> > seen any reports that suggested that it happens in reality.??So I don't
> > think it worth sending it to stable.
> [...]
> > This patch (of 12):
> >
> > This is an implementation of pmdp_establish() that is only suitable for
> > an architecture that doesn't have hardware dirty/accessed bits.??In this
> > case we can't race with CPU which sets these bits and non-atomic
> > approach is fine.
> [...]
>
> There's no point in applying just this patch, since it adds a new
> function that nothing will call.
>
> I tend to think that since this is fixing a potential data loss, the
> whole series should be backported. But the commit message here says it
> shouldn't.

Hm, I thought there was some reason for this patch, as I thought it came
up before. Sasha do you remember? Should I just revert it?

thanks,

greg k-h

2018-06-13 16:16:52

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 110/268] nvme-pci: Fix nvme queue cleanup if IRQ setup fails

On Mon, 2018-05-28 at 12:01 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Jianchao Wang <[email protected]>
>
> [ Upstream commit f25a2dfc20e3a3ed8fe6618c331799dd7bd01190 ]
>
> This patch fixes nvme queue cleanup if requesting an IRQ handler for
> the queue's vector fails. It does this by resetting the cq_vector to
> the uninitialized value of -1 so it is ignored for a controller reset.
>
> Signed-off-by: Jianchao Wang <[email protected]>
> [changelog updates, removed misc whitespace changes]
> Signed-off-by: Keith Busch <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
>  drivers/nvme/host/pci.c |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -1583,7 +1583,7 @@ static int nvme_create_queue(struct nvme
>   nvmeq->cq_vector = qid - 1;
>   result = adapter_alloc_cq(dev, qid, nvmeq);
>   if (result < 0)
> - return result;
> + goto release_vector;
>  
>   result = adapter_alloc_sq(dev, qid, nvmeq);
>   if (result < 0)
> @@ -1597,9 +1597,12 @@ static int nvme_create_queue(struct nvme
>   return result;
>  
>   release_sq:
> + dev->online_queues--;

This addition looks wrong. dev->online_queues is incremented by
nvme_init_queue(), but this function only calls that at a point where
it is sure to succeed. So why would a failure path need to decrement
it?

Ben.

>   adapter_delete_sq(dev, qid);
>   release_cq:
>   adapter_delete_cq(dev, qid);
> + release_vector:
> + nvmeq->cq_vector = -1;
>   return result;
>  }
>  
>
>
>
--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

2018-06-13 16:27:58

by Keith Busch

[permalink] [raw]
Subject: Re: [PATCH 4.4 110/268] nvme-pci: Fix nvme queue cleanup if IRQ setup fails

On Wed, Jun 13, 2018 at 05:14:34PM +0100, Ben Hutchings wrote:
> On Mon, 2018-05-28 at 12:01 +0200, Greg Kroah-Hartman wrote:
> > ? result = adapter_alloc_sq(dev, qid, nvmeq);
> > ? if (result < 0)
> > @@ -1597,9 +1597,12 @@ static int nvme_create_queue(struct nvme
> > ? return result;
> > ?
> > ? release_sq:
> > + dev->online_queues--;
>
> This addition looks wrong. dev->online_queues is incremented by
> nvme_init_queue(), but this function only calls that at a point where
> it is sure to succeed. So why would a failure path need to decrement
> it?

Thank you very much the catching that. This particular patch is indeed
not correct without the following:

161b8be2bd6ab ("nvme-pci: initialize queue memory before interrupts")

2018-06-13 16:38:54

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 110/268] nvme-pci: Fix nvme queue cleanup if IRQ setup fails

On Wed, 2018-06-13 at 10:30 -0600, Keith Busch wrote:
> On Wed, Jun 13, 2018 at 05:14:34PM +0100, Ben Hutchings wrote:
> > On Mon, 2018-05-28 at 12:01 +0200, Greg Kroah-Hartman wrote:
> > >   result = adapter_alloc_sq(dev, qid, nvmeq);
> > >   if (result < 0)
> > > @@ -1597,9 +1597,12 @@ static int nvme_create_queue(struct nvme
> > >   return result;
> > >  
> > >   release_sq:
> > > + dev->online_queues--;
> >
> > This addition looks wrong.  dev->online_queues is incremented by
> > nvme_init_queue(), but this function only calls that at a point where
> > it is sure to succeed.  So why would a failure path need to decrement
> > it?
>
> Thank you very much the catching that. This particular patch is indeed
> not correct without the following:
>
>   161b8be2bd6ab ("nvme-pci: initialize queue memory before interrupts")

Oh, now I see. Do you think that commit is suitable for stable
branches?

Ben.

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

2018-06-13 16:55:22

by Keith Busch

[permalink] [raw]
Subject: Re: [PATCH 4.4 110/268] nvme-pci: Fix nvme queue cleanup if IRQ setup fails

On Wed, Jun 13, 2018 at 05:37:35PM +0100, Ben Hutchings wrote:
> On Wed, 2018-06-13 at 10:30 -0600, Keith Busch wrote:
> > Thank you very much the catching that. This particular patch is indeed
> > not correct without the following:
> >
> > ? 161b8be2bd6ab ("nvme-pci: initialize queue memory before interrupts")
>
> Oh, now I see. Do you think that commit is suitable for stable
> branches?

Yes, we can safely include that commit 4.4-stable. The scenario it fixes
isn't very common in 4.4, but it could happen with quirky hardware or
legacy interrupts.

2018-06-13 17:14:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 110/268] nvme-pci: Fix nvme queue cleanup if IRQ setup fails

On Wed, Jun 13, 2018 at 10:56:32AM -0600, Keith Busch wrote:
> On Wed, Jun 13, 2018 at 05:37:35PM +0100, Ben Hutchings wrote:
> > On Wed, 2018-06-13 at 10:30 -0600, Keith Busch wrote:
> > > Thank you very much the catching that. This particular patch is indeed
> > > not correct without the following:
> > >
> > > ? 161b8be2bd6ab ("nvme-pci: initialize queue memory before interrupts")
> >
> > Oh, now I see. Do you think that commit is suitable for stable
> > branches?
>
> Yes, we can safely include that commit 4.4-stable. The scenario it fixes
> isn't very common in 4.4, but it could happen with quirky hardware or
> legacy interrupts.

It does not apply to 4.4.y right now, but it does apply to 4.9.y, so
I've added it there. If it needs to get to 4.4.y, can someone do a
backport?

thanks,

greg k-h

2018-06-13 21:27:16

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 128/268] scsi: sd: Keep disk read-only when re-reading partition

On Mon, 2018-05-28 at 12:01 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Jeremy Cline <[email protected]>
>
> [ Upstream commit 20bd1d026aacc5399464f8328f305985c493cde3 ]
>
> If the read-only flag is true on a SCSI disk, re-reading the partition
> table sets the flag back to false.
>
> To observe this bug, you can run:
>
> 1. blockdev --setro /dev/sda
> 2. blockdev --rereadpt /dev/sda
> 3. blockdev --getro /dev/sda
>
> This commit reads the disk's old state and combines it with the device
> disk-reported state rather than unconditionally marking it as RW.

It seems to me that this change is likely to cause a regression: if a
SCSI device switches from read-only to read-write state then a
subsequent rescan won't automatically change the block device to read-
write state. The administrator will have to use the blockdev command
too.

Even if this change in behaviour is acceptable, this commit does not
implement it consistently. The function starts by clearing the ro flag
and this commit only changes one of the three exit paths to preserve
it. (The log message about Write Protect status also reports the
underlying SCSI device flag and not the combined ro flag, but maybe
that was intentional.)

I think this commit should be reverted, both in stable and upstream. A
proper fix would involve splitting the ro flag into two flags—one
controlled by user-space and one read from the device—with the
effective read-only status being the logical-or of those two.

Ben.

> Reported-by: Li Ning <[email protected]>
> Signed-off-by: Jeremy Cline <[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/sd.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -2395,6 +2395,7 @@ sd_read_write_protect_flag(struct scsi_d
>   int res;
>   struct scsi_device *sdp = sdkp->device;
>   struct scsi_mode_data data;
> + int disk_ro = get_disk_ro(sdkp->disk);
>   int old_wp = sdkp->write_prot;
>  
>   set_disk_ro(sdkp->disk, 0);
> @@ -2435,7 +2436,7 @@ sd_read_write_protect_flag(struct scsi_d
>     "Test WP failed, assume Write Enabled\n");
>   } else {
>   sdkp->write_prot = ((data.device_specific & 0x80) != 0);
> - set_disk_ro(sdkp->disk, sdkp->write_prot);
> + set_disk_ro(sdkp->disk, sdkp->write_prot || disk_ro);
>   if (sdkp->first_scan || old_wp != sdkp->write_prot) {
>   sd_printk(KERN_NOTICE, sdkp, "Write Protect is %s\n",
>    sdkp->write_prot ? "on" : "off");

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

2018-06-14 08:20:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 038/268] Btrfs: fix scrub to repair raid6 corruption

On Fri, Jun 08, 2018 at 07:42:47PM +0100, Ben Hutchings wrote:
> On Mon, 2018-05-28 at 12:00 +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Liu Bo <[email protected]>
> >
> > [ Upstream commit 762221f095e3932669093466aaf4b85ed9ad2ac1 ]
>
> The diff here is actually from commit 8810f7517a3b ("Btrfs: make raid6
> rebuild retry more", mentioned in this commit message). (Sasha, please
> try to work out why commit messages and descriptions are getting mixed
> up in your auto-selections.)
>
> Maybe stable branches should get the real commit 762221f095e3 as well?

Ugh, not good. Sasha, can you fix this up and send me patches for it,
separate from your pull requests?

thanks,

greg k-h

2018-06-14 18:51:40

by Jeremy Cline

[permalink] [raw]
Subject: Re: [PATCH 4.4 128/268] scsi: sd: Keep disk read-only when re-reading partition

Hi Ben,

On 06/13/2018 05:25 PM, Ben Hutchings wrote:
> On Mon, 2018-05-28 at 12:01 +0200, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch.  If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: Jeremy Cline <[email protected]>
>>
>> [ Upstream commit 20bd1d026aacc5399464f8328f305985c493cde3 ]
>>
>> If the read-only flag is true on a SCSI disk, re-reading the partition
>> table sets the flag back to false.
>>
>> To observe this bug, you can run:
>>
>> 1. blockdev --setro /dev/sda
>> 2. blockdev --rereadpt /dev/sda
>> 3. blockdev --getro /dev/sda
>>
>> This commit reads the disk's old state and combines it with the device
>> disk-reported state rather than unconditionally marking it as RW.
>
> It seems to me that this change is likely to cause a regression: if a
> SCSI device switches from read-only to read-write state then a
> subsequent rescan won't automatically change the block device to read-
> write state. The administrator will have to use the blockdev command
> too.
>
> Even if this change in behaviour is acceptable, this commit does not
> implement it consistently. The function starts by clearing the ro flag
> and this commit only changes one of the three exit paths to preserve
> it. (The log message about Write Protect status also reports the
> underlying SCSI device flag and not the combined ro flag, but maybe
> that was intentional.)

Yes, it looks like I messed this up.

>
> I think this commit should be reverted, both in stable and upstream. A
> proper fix would involve splitting the ro flag into two flags—one
> controlled by user-space and one read from the device—with the
> effective read-only status being the logical-or of those two.

This seems sensible to me, for whatever that's worth. I'm new to the
kernel so I'm not certain I'll produce a reasonable patch, but I'm
willing to give it a shot.

So the change would be something like:

1. Add a flag to the gendisk struct to indicate if the device is
read-only. The driver sets this.

2. In hd_struct struct's policy flag is one that indicates the
user-space setting and this gets set by BLKROSET ioctl/set_disk_ro.

3. The effective read-only status reported by the BLKROGET ioctl and
bdev_read_only is the logical-or of the hd_struct policy flag and the
gendisk device flag.

Maybe that doesn't make sense at all, though. Thoughts?


Thanks,
Jeremy

2018-06-14 21:57:00

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 173/268] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

On Mon, 2018-05-28 at 12:02 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Davidlohr Bueso <[email protected]>
>
> [ Upstream commit d29a20645d5e929aa7e8616f28e5d8e1c49263ec ]
>
> While running rt-tests' pi_stress program I got the following splat:
>
>   rq->clock_update_flags < RQCF_ACT_SKIP
>   WARNING: CPU: 27 PID: 0 at kernel/sched/sched.h:960 assert_clock_updated.isra.38.part.39+0x13/0x20
>
>   [...]
>
>   <IRQ>
>   enqueue_top_rt_rq+0xf4/0x150
>   ? cpufreq_dbs_governor_start+0x170/0x170
>   sched_rt_rq_enqueue+0x65/0x80
>   sched_rt_period_timer+0x156/0x360
>   ? sched_rt_rq_enqueue+0x80/0x80
>   __hrtimer_run_queues+0xfa/0x260
>   hrtimer_interrupt+0xcb/0x220
>   smp_apic_timer_interrupt+0x62/0x120
>   apic_timer_interrupt+0xf/0x20
>   </IRQ>
>
>   [...]
>
>   do_idle+0x183/0x1e0
>   cpu_startup_entry+0x5f/0x70
>   start_secondary+0x192/0x1d0
>   secondary_startup_64+0xa5/0xb0
>
> We can get rid of it be the "traditional" means of adding an
> update_rq_clock() call after acquiring the rq->lock in
> do_sched_rt_period_timer().
>
> The case for the RT task throttling (which this workload also hits)
> can be ignored in that the skip_update call is actually bogus and
> quite the contrary (the request bits are removed/reverted).
>
> By setting RQCF_UPDATED we really don't care if the skip is happening
> or not and will therefore make the assert_clock_updated() check happy.

There is no such flag or assertion in 4.4 or 4.9, so does this change
still make sense there?

Ben.

> Signed-off-by: Davidlohr Bueso <[email protected]>
> Reviewed-by: Matt Fleming <[email protected]>
> Acked-by: Peter Zijlstra (Intel) <[email protected]>
> Cc: Linus Torvalds <[email protected]>
> Cc: Mike Galbraith <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Link: http://lkml.kernel.org/r/[email protected]
> Signed-off-by: Ingo Molnar <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
>  kernel/sched/rt.c |    2 ++
>  1 file changed, 2 insertions(+)
>
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -822,6 +822,8 @@ static int do_sched_rt_period_timer(stru
>   struct rq *rq = rq_of_rt_rq(rt_rq);
>  
>   raw_spin_lock(&rq->lock);
> + update_rq_clock(rq);
> +
>   if (rt_rq->rt_time) {
>   u64 runtime;
>  
>
>
>
--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

2018-06-14 22:33:18

by Steven Rostedt

[permalink] [raw]
Subject: Re: [PATCH 4.4 173/268] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

On Thu, 14 Jun 2018 22:55:56 +0100
Ben Hutchings <[email protected]> wrote:

> On Mon, 2018-05-28 at 12:02 +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Davidlohr Bueso <[email protected]>
> >
> > [ Upstream commit d29a20645d5e929aa7e8616f28e5d8e1c49263ec ]
> >
> > While running rt-tests' pi_stress program I got the following splat:
> >
> >   rq->clock_update_flags < RQCF_ACT_SKIP
> >   WARNING: CPU: 27 PID: 0 at kernel/sched/sched.h:960 assert_clock_updated.isra.38.part.39+0x13/0x20
> >
> >   [...]
> >
> >   <IRQ>
> >   enqueue_top_rt_rq+0xf4/0x150
> >   ? cpufreq_dbs_governor_start+0x170/0x170
> >   sched_rt_rq_enqueue+0x65/0x80
> >   sched_rt_period_timer+0x156/0x360
> >   ? sched_rt_rq_enqueue+0x80/0x80
> >   __hrtimer_run_queues+0xfa/0x260
> >   hrtimer_interrupt+0xcb/0x220
> >   smp_apic_timer_interrupt+0x62/0x120
> >   apic_timer_interrupt+0xf/0x20
> >   </IRQ>
> >
> >   [...]
> >
> >   do_idle+0x183/0x1e0
> >   cpu_startup_entry+0x5f/0x70
> >   start_secondary+0x192/0x1d0
> >   secondary_startup_64+0xa5/0xb0
> >
> > We can get rid of it be the "traditional" means of adding an
> > update_rq_clock() call after acquiring the rq->lock in
> > do_sched_rt_period_timer().
> >
> > The case for the RT task throttling (which this workload also hits)
> > can be ignored in that the skip_update call is actually bogus and
> > quite the contrary (the request bits are removed/reverted).
> >
> > By setting RQCF_UPDATED we really don't care if the skip is happening
> > or not and will therefore make the assert_clock_updated() check happy.
>
> There is no such flag or assertion in 4.4 or 4.9, so does this change
> still make sense there?

I believe the assert was added to catch bugs like this.

Although the change log is a bit ambiguous in if it is fixing an actual
miss update, or if it is just quieting a false positive.

Davidlohr?

-- Steve


>
> Ben.
>
> > Signed-off-by: Davidlohr Bueso <[email protected]>
> > Reviewed-by: Matt Fleming <[email protected]>
> > Acked-by: Peter Zijlstra (Intel) <[email protected]>
> > Cc: Linus Torvalds <[email protected]>
> > Cc: Mike Galbraith <[email protected]>
> > Cc: Thomas Gleixner <[email protected]>
> > Cc: [email protected]
> > Cc: [email protected]
> > Cc: [email protected]
> > Link: http://lkml.kernel.org/r/[email protected]
> > Signed-off-by: Ingo Molnar <[email protected]>
> > Signed-off-by: Sasha Levin <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> >  kernel/sched/rt.c |    2 ++
> >  1 file changed, 2 insertions(+)
> >
> > --- a/kernel/sched/rt.c
> > +++ b/kernel/sched/rt.c
> > @@ -822,6 +822,8 @@ static int do_sched_rt_period_timer(stru
> >   struct rq *rq = rq_of_rt_rq(rt_rq);
> >  
> >   raw_spin_lock(&rq->lock);
> > + update_rq_clock(rq);
> > +
> >   if (rt_rq->rt_time) {
> >   u64 runtime;
> >  
> >
> >
> >


2018-06-14 23:02:17

by Sasha Levin

[permalink] [raw]
Subject: Re: [PATCH 4.4 038/268] Btrfs: fix scrub to repair raid6 corruption

On Thu, Jun 14, 2018 at 10:18:58AM +0200, Greg Kroah-Hartman wrote:
>On Fri, Jun 08, 2018 at 07:42:47PM +0100, Ben Hutchings wrote:
>> On Mon, 2018-05-28 at 12:00 +0200, Greg Kroah-Hartman wrote:
>> > 4.4-stable review patch.??If anyone has any objections, please let me know.
>> >
>> > ------------------
>> >
>> > From: Liu Bo <[email protected]>
>> >
>> > [ Upstream commit 762221f095e3932669093466aaf4b85ed9ad2ac1 ]
>>
>> The diff here is actually from commit 8810f7517a3b ("Btrfs: make raid6
>> rebuild retry more", mentioned in this commit message). (Sasha, please
>> try to work out why commit messages and descriptions are getting mixed
>> up in your auto-selections.)
>>
>> Maybe stable branches should get the real commit 762221f095e3 as well?
>
>Ugh, not good. Sasha, can you fix this up and send me patches for it,
>separate from your pull requests?

Crap, I see what's wrong. I'll send fixes later tonight.

2018-06-15 01:42:41

by Martin K. Petersen

[permalink] [raw]
Subject: Re: [PATCH 4.4 128/268] scsi: sd: Keep disk read-only when re-reading partition


Hi Ben,

> (The log message about Write Protect status also reports the
> underlying SCSI device flag and not the combined ro flag, but maybe
> that was intentional.)

I'd prefer for the printk in question to reflect the device-reported
state, not the state of the block device.

> I think this commit should be reverted, both in stable and upstream.
> A proper fix would involve splitting the ro flag into two flags—one
> controlled by user-space and one read from the device—with the
> effective read-only status being the logical-or of those two.

I don't have a problem with distinguishing between current state and an
override flag in the block layer. However, I think an incremental patch
to fix that up is fine. SCSI devices don't typically switch write
protection state on a whim.

--
Martin K. Petersen Oracle Linux Engineering

2018-06-17 16:28:22

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 181/268] Btrfs: fix copy_items() return value when logging an inode

On Mon, 2018-05-28 at 12:02 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Filipe Manana <[email protected]>
>
> [ Upstream commit 8434ec46c6e3232cebc25a910363b29f5c617820 ]

Should stable branches also get a backport of commit
4ee3fad34a9cc2cf33303dfbd0cf554248651c86? It looks like 4.4 and 4.9
would need a minor change (inode->root to BTRFS_I(inode)->root) but I
don't know whether that's really sufficient.

Ben.

> When logging an inode, at tree-log.c:copy_items(), if we call
> btrfs_next_leaf() at the loop which checks for the need to log holes, we
> need to make sure copy_items() returns the value 1 to its caller and
> not 0 (on success). This is because the path the caller passed was
> released and is now different from what is was before, and the caller
> expects a return value of 0 to mean both success and that the path
> has not changed, while a return value of 1 means both success and
> signals the caller that it can not reuse the path, it has to perform
> another tree search.
>
> Even though this is a case that should not be triggered on normal
> circumstances or very rare at least, its consequences can be very
> unpredictable (especially when replaying a log tree).
>
> Fixes: 16e7549f045d ("Btrfs: incompatible format change to remove hole extents")
> Signed-off-by: Filipe Manana <[email protected]>
> Signed-off-by: David Sterba <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
>  fs/btrfs/tree-log.c |    1 +
>  1 file changed, 1 insertion(+)
>
> --- a/fs/btrfs/tree-log.c
> +++ b/fs/btrfs/tree-log.c
> @@ -3835,6 +3835,7 @@ fill_holes:
>   ASSERT(ret == 0);
>   src = src_path->nodes[0];
>   i = 0;
> + need_find_last_extent = true;
>   }
>  
>   btrfs_item_key_to_cpu(src, &key, i);

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

2018-06-17 16:52:13

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 188/268] hwmon: (nct6775) Fix writing pwmX_mode

On Mon, 2018-05-28 at 12:02 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Guenter Roeck <[email protected]>
>
> [ Upstream commit 415eb2a1aaa4881cf85bd86c683356fdd8094a23 ]
>
> pwmX_mode is defined in the ABI as 0=DC mode, 1=pwm mode. The chip
> register bit is set to 1 for DC mode. This got mixed up, and writing
> 1 into pwmX_mode resulted in DC mode enabled. Fix it up by using
> the ABI definition throughout the driver for consistency.
>
> Fixes: 77eb5b3703d99 ("hwmon: (nct6775) Add support for pwm, pwm_mode, ... ")
> Signed-off-by: Guenter Roeck <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
[...]

The code changes look fine but the comment on the declaration of
nct6775_data::pwm_mode is now incorrect.

Ben.

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

2018-06-17 22:13:41

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 229/268] media: cx23885: Set subdev host data to clk_freq pointer

On Mon, 2018-05-28 at 12:03 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Brad Love <[email protected]>
>
> [ Upstream commit 5ceade1d97fc6687e050c44c257382c192f56276 ]
>
> Currently clk_freq is ignored entirely, because the cx235840 driver
> configures the xtal at the chip defaults. This is an issue if a
> board is produced with a non-default frequency crystal. If clk_freq
> is not zero the cx25840 will attempt to use the setting provided,
> or fall back to defaults otherwise.

This depends on (at least):

commit 3ee9bc12342cf546313d300808ff47d7dbb8e7db
Author: Brad Love <[email protected]>
Date: Tue Mar 6 14:15:34 2018 -0500

media: cx25840: Use subdev host data for PLL override

Ben.

> Signed-off-by: Brad Love <[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/cx23885/cx23885-cards.c |    4 ++++
>  1 file changed, 4 insertions(+)
>
> --- a/drivers/media/pci/cx23885/cx23885-cards.c
> +++ b/drivers/media/pci/cx23885/cx23885-cards.c
> @@ -2124,6 +2124,10 @@ void cx23885_card_setup(struct cx23885_d
>   &dev->i2c_bus[2].i2c_adap,
>   "cx25840", 0x88 >> 1, NULL);
>   if (dev->sd_cx25840) {
> + /* set host data for clk_freq configuration */
> + v4l2_set_subdev_hostdata(dev->sd_cx25840,
> + &dev->clk_freq);
> +
>   dev->sd_cx25840->grp_id = CX23885_HW_AV_CORE;
>   v4l2_subdev_call(dev->sd_cx25840, core, load_fw);
>   }

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

2018-06-17 23:07:03

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 234/268] enic: enable rq before updating rq descriptors

On Mon, 2018-05-28 at 12:03 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Govindarajulu Varadarajan <[email protected]>
>
> [ Upstream commit e8588e268509292550634d9a35f2723a207683b2 ]
[...]
> --- a/drivers/net/ethernet/cisco/enic/enic_main.c
> +++ b/drivers/net/ethernet/cisco/enic/enic_main.c
[...]
> @@ -1765,8 +1765,12 @@ static int enic_open(struct net_device *
> >   return 0;
>  
>  err_out_free_rq:
> - for (i = 0; i < enic->rq_count; i++)
> + for (i = 0; i < enic->rq_count; i++) {
> + err = vnic_rq_disable(&enic->rq[i]);
> + if (err)
> + return err;

This added code is wrong: it overwrites the error code that was
previously in err. If vnic_rq_disable() succeeds, enic_open() will
wrongly return 0. If vnic_rq_disable() fails, I still don't think it
makes sense to skip the remaining cleanup actins.

Ben.

>   vnic_rq_clean(&enic->rq[i], enic_free_rq_buf);
> + }
>   enic_dev_notify_unset(enic);
>  err_out_free_intr:
>   enic_unset_affinity_hint(enic);
>
>
>
--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

2018-06-17 23:45:09

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 246/268] media: cx25821: prevent out-of-bounds read on array card

On Mon, 2018-05-28 at 12:03 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Colin Ian King <[email protected]>
>
> [ Upstream commit 67300abdbe9f1717532aaf4e037222762716d0f6 ]
>
> Currently an out of range dev->nr is detected by just reporting the
> issue and later on an out-of-bounds read on array card occurs because
> of this. Fix this by checking the upper range of dev->nr with the size
> of array card (removes the hard coded size), move this check earlier
> and also exit with the error -ENOSYS to avoid the later out-of-bounds
> array read.

I don't think this is a correct fix.

The card[] array and module parameter appear to be completely
redundant. Instead of arbitrarily limiting the number of cards that
the driver can bind to, we should remove them.

Ben.

> Detected by CoverityScan, CID#711191 ("Out-of-bounds-read")
>
> Fixes: commit 02b20b0b4cde ("V4L/DVB (12730): Add conexant cx25821 driver")
>
> Signed-off-by: Colin Ian King <[email protected]>
> Signed-off-by: Hans Verkuil <[email protected]>
> [[email protected]: %ld -> %zd]
> 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/cx25821/cx25821-core.c |    7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> --- a/drivers/media/pci/cx25821/cx25821-core.c
> +++ b/drivers/media/pci/cx25821/cx25821-core.c
> @@ -871,6 +871,10 @@ static int cx25821_dev_setup(struct cx25
>   dev->nr = ++cx25821_devcount;
>   sprintf(dev->name, "cx25821[%d]", dev->nr);
>  
> + if (dev->nr >= ARRAY_SIZE(card)) {
> + CX25821_INFO("dev->nr >= %zd", ARRAY_SIZE(card));
> + return -ENODEV;
> + }
>   if (dev->pci->device != 0x8210) {
>   pr_info("%s(): Exiting. Incorrect Hardware device = 0x%02x\n",
>   __func__, dev->pci->device);
> @@ -886,9 +890,6 @@ static int cx25821_dev_setup(struct cx25
>   dev->channels[i].sram_channels = &cx25821_sram_channels[i];
>   }
>  
> - if (dev->nr > 1)
> - CX25821_INFO("dev->nr > 1!");
> -
>   /* board config */
>   dev->board = 1; /* card[dev->nr]; */
>   dev->_max_num_decoders = MAX_DECODERS;

--
Ben Hutchings, Software Developer   Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

Subject: Re: [PATCH 4.4 234/268] enic: enable rq before updating rq descriptors

On Mon, 2018-06-18 at 00:06 +0100, Ben Hutchings wrote:
> On Mon, 2018-05-28 at 12:03 +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Govindarajulu Varadarajan <[email protected]>
> >
> > [ Upstream commit e8588e268509292550634d9a35f2723a207683b2 ]
>
> [...]
> > --- a/drivers/net/ethernet/cisco/enic/enic_main.c
> > +++ b/drivers/net/ethernet/cisco/enic/enic_main.c
>
> [...]
> > @@ -1765,8 +1765,12 @@ static int enic_open(struct net_device *
> > > return 0;
> >
> >
> > err_out_free_rq:
> > - for (i = 0; i < enic->rq_count; i++)
> > + for (i = 0; i < enic->rq_count; i++) {
> > + err = vnic_rq_disable(&enic->rq[i]);
> > + if (err)
> > + return err;
>
> This added code is wrong: it overwrites the error code that was
> previously in err. If vnic_rq_disable() succeeds, enic_open() will
> wrongly return 0. If vnic_rq_disable() fails, I still don't think it
> makes sense to skip the remaining cleanup actins.

Good catch. Fixing it.

2018-06-19 14:36:03

by Davidlohr Bueso

[permalink] [raw]
Subject: Re: [PATCH 4.4 173/268] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

On Thu, 14 Jun 2018, Steven Rostedt wrote:
>
>Although the change log is a bit ambiguous in if it is fixing an actual
>miss update, or if it is just quieting a false positive.
>
>Davidlohr?

It fixes an update, not a false positive.

Thanks,
Davidlohr

2018-06-19 17:24:07

by Ben Hutchings

[permalink] [raw]
Subject: [PATCH 4.4] nvme-pci: initialize queue memory before interrupts

From: Keith Busch <[email protected]>

commit 161b8be2bd6abad250d4b3f674bdd5480f15beeb upstream.

A spurious interrupt before the nvme driver has initialized the completion
queue may inadvertently cause the driver to believe it has a completion
to process. This may result in a NULL dereference since the nvmeq's tags
are not set at this point.

The patch initializes the host's CQ memory so that a spurious interrupt
isn't mistaken for a real completion.

Signed-off-by: Keith Busch <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
[bwh: Backported to 4.4: adjust context]
Signed-off-by: Jens Axboe <[email protected]>
---
drivers/nvme/host/pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index e86fcc9e9852..01f47b68b6e7 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1589,11 +1589,11 @@ static int nvme_create_queue(struct nvme_queue *nvmeq, int qid)
if (result < 0)
goto release_cq;

+ nvme_init_queue(nvmeq, qid);
result = queue_request_irq(dev, nvmeq, nvmeq->irqname);
if (result < 0)
goto release_sq;

- nvme_init_queue(nvmeq, qid);
return result;

release_sq:
@@ -1797,6 +1797,7 @@ static int nvme_configure_admin_queue(struct nvme_dev *dev)
goto free_nvmeq;

nvmeq->cq_vector = 0;
+ nvme_init_queue(nvmeq, 0);
result = queue_request_irq(dev, nvmeq, nvmeq->irqname);
if (result) {
nvmeq->cq_vector = -1;
@@ -3165,7 +3166,6 @@ static void nvme_probe_work(struct work_struct *work)
goto disable;
}

- nvme_init_queue(dev->queues[0], 0);
result = nvme_alloc_admin_tags(dev);
if (result)
goto disable;
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom


2018-06-21 13:08:47

by Ross Lagerwall

[permalink] [raw]
Subject: Re: [PATCH 4.4 059/268] xen-netfront: Fix race between device setup and open

On 06/11/2018 03:29 PM, Ben Hutchings wrote:
> On Mon, 2018-05-28 at 12:00 +0200, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch.  If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: Ross Lagerwall <[email protected]>
>>
>> [ Upstream commit f599c64fdf7d9c108e8717fb04bc41c680120da4 ]
> [...]
>> --- a/drivers/net/xen-netfront.c
>> +++ b/drivers/net/xen-netfront.c
> [...]
>> @@ -1839,6 +1824,7 @@ static int talk_to_netback(struct xenbus
>>   goto out;
>
> This "goto out" is outside the locked section...
>
>>   }
>>
>> + rtnl_lock();
>>   if (info->queues)
>>   xennet_destroy_queues(info);
>>
>> @@ -1849,6 +1835,7 @@ static int talk_to_netback(struct xenbus
>>   info->queues = NULL;
>>   goto out;
>>   }
>> + rtnl_unlock();
>>
>>   /* Create shared ring, alloc event channel -- for each queue */
>>   for (i = 0; i < num_queues; ++i) {
>> @@ -1945,8 +1932,10 @@ abort_transaction_no_dev_fatal:
>>   xenbus_transaction_end(xbt, 1);
>>   destroy_ring:
>>   xennet_disconnect_backend(info);
>> + rtnl_lock();
>>   xennet_destroy_queues(info);
>>   out:
>> + rtnl_unlock();
>
> ...so this will be an unmatched unlock.
>
> You need to add another label below the rtnl_unlock().
>

Thanks for spotting this. I've sent patches to the list to fix this and
another issue with the original patch.

Regards,
--
Ross Lagerwall

2018-07-05 16:57:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4] nvme-pci: initialize queue memory before interrupts

On Tue, Jun 19, 2018 at 06:23:06PM +0100, Ben Hutchings wrote:
> From: Keith Busch <[email protected]>
>
> commit 161b8be2bd6abad250d4b3f674bdd5480f15beeb upstream.
>
> A spurious interrupt before the nvme driver has initialized the completion
> queue may inadvertently cause the driver to believe it has a completion
> to process. This may result in a NULL dereference since the nvmeq's tags
> are not set at this point.
>
> The patch initializes the host's CQ memory so that a spurious interrupt
> isn't mistaken for a real completion.
>
> Signed-off-by: Keith Busch <[email protected]>
> Reviewed-by: Johannes Thumshirn <[email protected]>
> Signed-off-by: Christoph Hellwig <[email protected]>
> [bwh: Backported to 4.4: adjust context]
> Signed-off-by: Jens Axboe <[email protected]>
> ---
> drivers/nvme/host/pci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)

Now applied, thanks.

greg k-h

2018-07-10 14:13:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 229/268] media: cx23885: Set subdev host data to clk_freq pointer

On Sun, Jun 17, 2018 at 11:12:17PM +0100, Ben Hutchings wrote:
> On Mon, 2018-05-28 at 12:03 +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Brad Love <[email protected]>
> >
> > [ Upstream commit 5ceade1d97fc6687e050c44c257382c192f56276 ]
> >
> > Currently clk_freq is ignored entirely, because the cx235840 driver
> > configures the xtal at the chip defaults. This is an issue if a
> > board is produced with a non-default frequency crystal. If clk_freq
> > is not zero the cx25840 will attempt to use the setting provided,
> > or fall back to defaults otherwise.
>
> This depends on (at least):
>
> commit 3ee9bc12342cf546313d300808ff47d7dbb8e7db
> Author: Brad Love <[email protected]>
> Date: Tue Mar 6 14:15:34 2018 -0500
>
> media: cx25840: Use subdev host data for PLL override
>
> Ben.

Good catch, now queued up.

greg k-h