Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1516119 > unrolled thread
| Started by | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| First post | 2016-11-07 14:10 +0100 |
| Last post | 2016-11-10 20:00 +0100 |
| Articles | 20 on this page of 22 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH 3.12 00/72] 3.12.67-stable review Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:10 +0100
[PATCH 3.12 01/72] i40e: avoid NULL pointer dereference and recursive errors on early PCI error Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:30 +0100
[PATCH 3.12 03/72] scsi: ibmvfc: Fix I/O hang when port is not mapped Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:30 +0100
[PATCH 3.12 19/72] powerpc/pseries: Fix stack corruption in htpe code Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:30 +0100
[PATCH 3.12 10/72] regulator: tps65910: Work around silicon erratum SWCZ010 Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:30 +0100
[PATCH 3.12 15/72] dm: mark request_queue dead before destroying the DM device Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:30 +0100
[PATCH 3.12 16/72] powerpc/vdso64: Use double word compare on pointers Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:30 +0100
[PATCH 3.12 22/72] zfcp: close window with unblocked rport during rport gone Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:30 +0100
[PATCH 3.12 09/72] gpio: mpc8xxx: Correct irq handler function Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:30 +0100
[PATCH 3.12 23/72] zfcp: retain trace level for SCSI and HBA FSF response records Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:30 +0100
[PATCH 3.12 07/72] pstore: Fix buffer overflow while write offset equal to buffer size Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:30 +0100
[PATCH 3.12 06/72] cfq: fix starvation of asynchronous writes Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:30 +0100
[PATCH 3.12 08/72] ipc: remove use of seq_printf return value Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:30 +0100
[PATCH 3.12 17/72] powerpc/powernv: Use CPU-endian PEST in pnv_pci_dump_p7ioc_diag_data() Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:30 +0100
[PATCH 3.12 20/72] zfcp: fix fc_host port_type with NPIV Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:30 +0100
[PATCH 3.12 62/72] powerpc/eeh: Null check uses of eeh_pe_bus_get Jiri Slaby <jslaby@suse.cz> - 2016-11-07 14:40 +0100
Re: [PATCH 3.12 00/72] 3.12.67-stable review Guenter Roeck <linux@roeck-us.net> - 2016-11-07 18:20 +0100
Re: [PATCH 3.12 00/72] 3.12.67-stable review Jiri Slaby <jslaby@suse.cz> - 2016-11-08 16:50 +0100
Re: [PATCH 3.12 00/72] 3.12.67-stable review Guenter Roeck <linux@roeck-us.net> - 2016-11-09 05:20 +0100
Re: [PATCH 3.12 00/72] 3.12.67-stable review Jiri Slaby <jslaby@suse.cz> - 2016-11-10 20:00 +0100
Re: [PATCH 3.12 00/72] 3.12.67-stable review Shuah Khan <shuah.kh@samsung.com> - 2016-11-07 19:40 +0100
Re: [PATCH 3.12 00/72] 3.12.67-stable review Jiri Slaby <jslaby@suse.cz> - 2016-11-10 20:00 +0100
Page 1 of 2 [1] 2 Next page →
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:10 +0100 |
| Subject | [PATCH 3.12 00/72] 3.12.67-stable review |
| Message-ID | <sARQu-3wK-63@gated-at.bofh.it> |
This is the start of the stable review cycle for the 3.12.67 release.
There are 72 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 Nov 9 14:03:48 CET 2016.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.67-rc1.xz
and the diffstat can be found below.
thanks,
js
===============
Al Viro (1):
arc: don't leak bits of kernel stack into coredump
Alex Deucher (3):
drm/radeon: narrow asic_init for virtualization
drm/radeon/si/dpm: fix phase shedding setup
drm/radeon: change vblank_time's calculation method to reduce
computational error.
Andrew Bresticker (1):
pstore/ram: Use memcpy_fromio() to save old buffer
Anton Blanchard (1):
powerpc/vdso64: Use double word compare on pointers
Arnaldo Carvalho de Melo (1):
perf symbols: Fixup symbol sizes before picking best ones
Bart Van Assche (1):
dm: mark request_queue dead before destroying the DM device
Brian King (1):
scsi: ibmvfc: Fix I/O hang when port is not mapped
Daeho Jeong (1):
ext4: reinforce check of i_dtime when clearing high fields of uid and
gid
Dan Carpenter (2):
scsi: zfcp: spin_lock_irqsave() is not nestable
scsi: arcmsr: Buffer overflow in arcmsr_iop_message_xfer()
Daniel Glöckner (1):
mmc: block: don't use CMD23 with very old MMC cards
Dave Gerlach (1):
hwrng: omap - Only fail if pm_runtime_get_sync returns < 0
Dmitry Torokhov (1):
Input: elantech - add Fujitsu Lifebook E556 to force crc_enabled
Furquan Shaikh (1):
pstore/ram: Use memcpy_toio instead of memcpy
Gavin Shan (1):
powerpc/powernv: Use CPU-endian PEST in pnv_pci_dump_p7ioc_diag_data()
Gerald Schaefer (1):
mm/hugetlb: fix memory offline with hugepage size > memory block size
Glauber Costa (1):
cfq: fix starvation of asynchronous writes
Guenter Roeck (1):
metag: Only define atomic_dec_if_positive conditionally
Guilherme G Piccoli (1):
i40e: avoid NULL pointer dereference and recursive errors on early PCI
error
Jack Morgenstein (1):
net/mlx4_core: Allow resetting VF admin mac to zero
Jan Kara (1):
isofs: Do not return EACCES for unknown filesystems
Jan Remmet (1):
regulator: tps65910: Work around silicon erratum SWCZ010
Jan Viktorin (1):
uio: fix dmem_region_start computation
Jesse Gross (1):
tunnels: Remove encapsulation offloads on decap.
Jiri Slaby (2):
mmc: core: Annotate cmd_hdr as __le32
Revert "fix minor infoleak in get_user_ex()"
Joe Perches (1):
ipc: remove use of seq_printf return value
Laurent Dufour (1):
powerpc/pseries: Fix stack corruption in htpe code
Liu Gang (1):
gpio: mpc8xxx: Correct irq handler function
Liu ShuoX (1):
pstore: Fix buffer overflow while write offset equal to buffer size
Manfred Spraul (1):
ipc/sem.c: fix complex_count vs. simple op race
Marcin Nowakowski (1):
MIPS: ptrace: Fix regs_return_value for kernel context
Matti Kurkela (1):
Input: elantech - force needed quirks on Fujitsu H760
Mauro Carvalho Chehab (4):
mb86a20s: fix the locking logic
mb86a20s: fix demod settings
cx231xx: don't return error on success
cx231xx: fix GPIOs for Pixelview SBTVD hybrid
Max Staudt (1):
fbdev/efifb: Fix 16 color palette entry calculation
Mike Galbraith (1):
reiserfs: Unlock superblock before calling reiserfs_quota_on_mount()
Ming Lei (1):
scsi: Fix use-after-free
Oleg Nesterov (1):
fs/super.c: fix race between freeze_super() and thaw_super()
Ondrej Mosnáček (1):
crypto: gcm - Fix IV buffer size in crypto_gcm_setkey
Pan Xinhui (1):
powerpc/nvram: Fix an incorrect partition merge
Paul E. McKenney (1):
compiler: Allow 1- and 2-byte smp_load_acquire() and
smp_store_release()
Paul Mackerras (1):
powerpc/64: Fix incorrect return value from __copy_tofrom_user
Pravin B Shelar (1):
introduce NETIF_F_GSO_ENCAP_ALL helper mask
Richard Weinberger (1):
ubifs: Fix xattr_names length in exit paths
Ross Lagerwall (1):
cifs: Limit the overall credit acquired
Ross Zwisler (1):
ext4: allow DAX writeback for hole punch
Russell Currey (1):
powerpc/eeh: Null check uses of eeh_pe_bus_get
Sebastian Andrzej Siewior (1):
pstore/core: drop cmpxchg based updates
Sebastian Frias (1):
genirq/generic_chip: Add irq_unmap callback
Steffen Maier (10):
zfcp: fix fc_host port_type with NPIV
zfcp: fix ELS/GS request&response length for hardware data router
zfcp: close window with unblocked rport during rport gone
zfcp: retain trace level for SCSI and HBA FSF response records
zfcp: restore: Dont use 0 to indicate invalid LUN in rec trace
zfcp: trace on request for open and close of WKA port
zfcp: restore tracing of handle for port and LUN with HBA records
zfcp: fix D_ID field with actual value on tracing SAN responses
zfcp: fix payload trace length for SAN request&response
zfcp: trace full payload of all SAN records (req,resp,iels)
Steve French (5):
Clarify locking of cifs file and tcon structures and make more
granular
Display number of credits available
Set previous session id correctly on SMB3 reconnect
SMB3: GUIDs should be constructed as random but valid uuids
Do not send SMB3 SET_INFO request if nothing is changing
Trond Myklebust (1):
NFSv4: Open state recovery must account for file permission changes
Vladimir Zapolskiy (1):
i2c: core: fix NULL pointer dereference under race condition
Yonglong Wu (1):
usb: hub: change CLEAR_FEATURE to SET_FEATURE
arch/arc/kernel/signal.c | 9 +-
arch/metag/include/asm/atomic.h | 3 +-
arch/mips/include/asm/ptrace.h | 2 +-
arch/powerpc/kernel/eeh_driver.c | 8 ++
arch/powerpc/kernel/nvram_64.c | 6 +-
arch/powerpc/kernel/vdso64/datapage.S | 2 +-
arch/powerpc/kernel/vdso64/gettimeofday.S | 2 +-
arch/powerpc/lib/copyuser_64.S | 2 +-
arch/powerpc/platforms/powernv/eeh-ioda.c | 5 +
arch/powerpc/platforms/powernv/pci.c | 4 +-
arch/powerpc/platforms/pseries/lpar.c | 4 +-
arch/x86/include/asm/uaccess.h | 6 +-
block/cfq-iosched.c | 13 +-
crypto/gcm.c | 2 +-
drivers/char/hw_random/omap-rng.c | 4 +-
drivers/gpio/gpio-mpc8xxx.c | 2 +-
drivers/gpu/drm/radeon/r600_dpm.c | 15 +--
drivers/gpu/drm/radeon/radeon_device.c | 5 +-
drivers/gpu/drm/radeon/si_dpm.c | 2 +-
drivers/gpu/drm/radeon/sislands_smc.h | 1 +
drivers/i2c/i2c-core.c | 2 +-
drivers/input/mouse/elantech.c | 25 +++-
drivers/md/dm.c | 5 +
drivers/media/dvb-frontends/mb86a20s.c | 104 ++++++++--------
drivers/media/usb/cx231xx/cx231xx-avcore.c | 5 +-
drivers/media/usb/cx231xx/cx231xx-cards.c | 2 +-
drivers/media/usb/cx231xx/cx231xx-core.c | 3 +-
drivers/mmc/card/block.c | 5 +-
drivers/mmc/card/queue.h | 2 +-
drivers/net/ethernet/intel/i40e/i40e_main.c | 6 +
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
drivers/regulator/tps65910-regulator.c | 6 +
drivers/s390/scsi/zfcp_dbf.c | 162 ++++++++++++++++++++++---
drivers/s390/scsi/zfcp_dbf.h | 14 ++-
drivers/s390/scsi/zfcp_erp.c | 12 +-
drivers/s390/scsi/zfcp_ext.h | 8 +-
drivers/s390/scsi/zfcp_fsf.c | 22 +++-
drivers/s390/scsi/zfcp_fsf.h | 4 +-
drivers/s390/scsi/zfcp_scsi.c | 8 +-
drivers/scsi/arcmsr/arcmsr_hba.c | 8 +-
drivers/scsi/ibmvscsi/ibmvfc.c | 1 -
drivers/scsi/scsi_scan.c | 2 +-
drivers/uio/uio_dmem_genirq.c | 2 +-
drivers/usb/core/hub.c | 2 +-
drivers/video/efifb.c | 6 +-
fs/cifs/cifs_debug.c | 1 +
fs/cifs/cifsfs.c | 3 +-
fs/cifs/cifsglob.h | 30 ++---
fs/cifs/cifssmb.c | 4 +-
fs/cifs/connect.c | 2 +-
fs/cifs/file.c | 66 +++++-----
fs/cifs/misc.c | 15 +--
fs/cifs/readdir.c | 6 +-
fs/cifs/smb2glob.h | 10 ++
fs/cifs/smb2inode.c | 6 +
fs/cifs/smb2misc.c | 16 +--
fs/cifs/smb2ops.c | 2 +-
fs/cifs/smb2pdu.c | 21 +++-
fs/cifs/smb2pdu.h | 2 +-
fs/ext4/inode.c | 12 +-
fs/isofs/inode.c | 8 +-
fs/nfs/nfs4state.c | 3 +
fs/pstore/ram_core.c | 51 +-------
fs/reiserfs/super.c | 12 +-
fs/super.c | 6 +-
fs/ubifs/xattr.c | 2 +
include/linux/compiler.h | 2 +-
include/linux/netdev_features.h | 4 +
include/linux/sem.h | 1 +
include/net/ip_tunnels.h | 16 +++
ipc/msg.c | 34 +++---
ipc/sem.c | 156 ++++++++++++++----------
ipc/shm.c | 42 ++++---
ipc/util.c | 6 +-
kernel/irq/generic-chip.c | 20 +++
mm/hugetlb.c | 13 +-
net/ipv4/ip_tunnel_core.c | 3 +-
net/ipv6/sit.c | 5 +-
tools/perf/util/symbol-elf.c | 2 +-
tools/perf/util/symbol.c | 2 +-
80 files changed, 714 insertions(+), 385 deletions(-)
--
2.10.2
[toc] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:30 +0100 |
| Subject | [PATCH 3.12 01/72] i40e: avoid NULL pointer dereference and recursive errors on early PCI error |
| Message-ID | <sARQt-3wK-3@gated-at.bofh.it> |
| In reply to | #1516119 |
From: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit edfc23ee3e0ebbb6713d7574ab1b00abff178f6c upstream.
Although rare, it's possible to hit PCI error early on device
probe, meaning possibly some structs are not entirely initialized,
and some might even be completely uninitialized, leading to NULL
pointer dereference.
The i40e driver currently presents a "bad" behavior if device hits
such early PCI error: firstly, the struct i40e_pf might not be
attached to pci_dev yet, leading to a NULL pointer dereference on
access to pf->state.
Even checking if the struct is NULL and avoiding the access in that
case isn't enough, since the driver cannot recover from PCI error
that early; in our experiments we saw multiple failures on kernel
log, like:
[549.664] i40e 0007:01:00.1: Initial pf_reset failed: -15
[549.664] i40e: probe of 0007:01:00.1 failed with error -15
[...]
[871.644] i40e 0007:01:00.1: The driver for the device stopped because the
device firmware failed to init. Try updating your NVM image.
[871.644] i40e: probe of 0007:01:00.1 failed with error -32
[...]
[872.516] i40e 0007:01:00.0: ARQ: Unknown event 0x0000 ignored
Between the first probe failure (error -15) and the second (error -32)
another PCI error happened due to the first bad probe. Also, driver
started to flood console with those ARQ event messages.
This patch will prevent these issues by allowing error recovery
mechanism to remove the failed device from the system instead of
trying to recover from early PCI errors during device probe.
Signed-off-by: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
Acked-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 221aa4795017..1c7c3048117b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -7265,6 +7265,12 @@ static pci_ers_result_t i40e_pci_error_detected(struct pci_dev *pdev,
dev_info(&pdev->dev, "%s: error %d\n", __func__, error);
+ if (!pf) {
+ dev_info(&pdev->dev,
+ "Cannot recover - error happened during device probe\n");
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
/* shutdown all operations */
i40e_pf_quiesce_all_vsi(pf);
--
2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:30 +0100 |
| Subject | [PATCH 3.12 03/72] scsi: ibmvfc: Fix I/O hang when port is not mapped |
| Message-ID | <sAS9Q-3GK-21@gated-at.bofh.it> |
| In reply to | #1516169 |
From: Brian King <brking@linux.vnet.ibm.com> 3.12-stable review patch. If anyone has any objections, please let me know. =============== commit 07d0e9a847401ffd2f09bd450d41644cd090e81d upstream. If a VFC port gets unmapped in the VIOS, it may not respond with a CRQ init complete following H_REG_CRQ. If this occurs, we can end up having called scsi_block_requests and not a resulting unblock until the init complete happens, which may never occur, and we end up hanging I/O requests. This patch ensures the host action stay set to IBMVFC_HOST_ACTION_TGT_DEL so we move all rports into devloss state and unblock unless we receive an init complete. Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> --- drivers/scsi/ibmvscsi/ibmvfc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c index 23f5ba5e6472..26d31b7e7331 100644 --- a/drivers/scsi/ibmvscsi/ibmvfc.c +++ b/drivers/scsi/ibmvscsi/ibmvfc.c @@ -717,7 +717,6 @@ static int ibmvfc_reset_crq(struct ibmvfc_host *vhost) spin_lock_irqsave(vhost->host->host_lock, flags); vhost->state = IBMVFC_NO_CRQ; vhost->logged_in = 0; - ibmvfc_set_host_action(vhost, IBMVFC_HOST_ACTION_NONE); /* Clean out the queue */ memset(crq->msgs, 0, PAGE_SIZE); -- 2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:30 +0100 |
| Subject | [PATCH 3.12 19/72] powerpc/pseries: Fix stack corruption in htpe code |
| Message-ID | <sAS9Q-3GK-15@gated-at.bofh.it> |
| In reply to | #1516169 |
From: Laurent Dufour <ldufour@linux.vnet.ibm.com>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit 05af40e885955065aee8bb7425058eb3e1adca08 upstream.
This commit fixes a stack corruption in the pseries specific code dealing
with the huge pages.
In __pSeries_lpar_hugepage_invalidate() the buffer used to pass arguments
to the hypervisor is not large enough. This leads to a stack corruption
where a previously saved register could be corrupted leading to unexpected
result in the caller, like the following panic:
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: virtio_balloon ip_tables x_tables autofs4
virtio_blk 8139too virtio_pci virtio_ring 8139cp virtio
CPU: 11 PID: 1916 Comm: mmstress Not tainted 4.8.0 #76
task: c000000005394880 task.stack: c000000005570000
NIP: c00000000027bf6c LR: c00000000027bf64 CTR: 0000000000000000
REGS: c000000005573820 TRAP: 0300 Not tainted (4.8.0)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 84822884 XER: 20000000
CFAR: c00000000010a924 DAR: 420000000014e5e0 DSISR: 40000000 SOFTE: 1
GPR00: c00000000027bf64 c000000005573aa0 c000000000e02800 c000000004447964
GPR04: c00000000404de18 c000000004d38810 00000000042100f5 00000000f5002104
GPR08: e0000000f5002104 0000000000000001 042100f5000000e0 00000000042100f5
GPR12: 0000000000002200 c00000000fe02c00 c00000000404de18 0000000000000000
GPR16: c1ffffffffffe7ff 00003fff62000000 420000000014e5e0 00003fff63000000
GPR20: 0008000000000000 c0000000f7014800 0405e600000000e0 0000000000010000
GPR24: c000000004d38810 c000000004447c10 c00000000404de18 c000000004447964
GPR28: c000000005573b10 c000000004d38810 00003fff62000000 420000000014e5e0
NIP [c00000000027bf6c] zap_huge_pmd+0x4c/0x470
LR [c00000000027bf64] zap_huge_pmd+0x44/0x470
Call Trace:
[c000000005573aa0] [c00000000027bf64] zap_huge_pmd+0x44/0x470 (unreliable)
[c000000005573af0] [c00000000022bbd8] unmap_page_range+0xcf8/0xed0
[c000000005573c30] [c00000000022c2d4] unmap_vmas+0x84/0x120
[c000000005573c80] [c000000000235448] unmap_region+0xd8/0x1b0
[c000000005573d80] [c0000000002378f0] do_munmap+0x2d0/0x4c0
[c000000005573df0] [c000000000237be4] SyS_munmap+0x64/0xb0
[c000000005573e30] [c000000000009560] system_call+0x38/0x108
Instruction dump:
fbe1fff8 fb81ffe0 7c7f1b78 7ca32b78 7cbd2b78 f8010010 7c9a2378 f821ffb1
7cde3378 4bfffea9 7c7b1b79 41820298 <e87f0000> 48000130 7fa5eb78 7fc4f378
Most of the time, the bug is surfacing in a caller up in the stack from
__pSeries_lpar_hugepage_invalidate() which is quite confusing.
This bug is pending since v3.11 but was hidden if a caller of the
caller of __pSeries_lpar_hugepage_invalidate() has pushed the corruped
register (r18 in this case) in the stack and is not using it until
restoring it. GCC 6.2.0 seems to raise it more frequently.
This commit also change the definition of the parameter buffer in
pSeries_lpar_flush_hash_range() to rely on the global define
PLPAR_HCALL9_BUFSIZE (no functional change here).
Fixes: 1a5272866f87 ("powerpc: Optimize hugepage invalidate")
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
arch/powerpc/platforms/pseries/lpar.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index 691a479f7d97..73f2c2f35f6d 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -373,7 +373,7 @@ static void __pSeries_lpar_hugepage_invalidate(unsigned long *slot,
unsigned long *vpn, int count,
int psize, int ssize)
{
- unsigned long param[8];
+ unsigned long param[PLPAR_HCALL9_BUFSIZE];
int i = 0, pix = 0, rc;
unsigned long flags = 0;
int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
@@ -490,7 +490,7 @@ static void pSeries_lpar_flush_hash_range(unsigned long number, int local)
unsigned long flags = 0;
struct ppc64_tlb_batch *batch = &__get_cpu_var(ppc64_tlb_batch);
int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
- unsigned long param[9];
+ unsigned long param[PLPAR_HCALL9_BUFSIZE];
unsigned long hash, index, shift, hidx, slot;
real_pte_t pte;
int psize, ssize;
--
2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:30 +0100 |
| Subject | [PATCH 3.12 10/72] regulator: tps65910: Work around silicon erratum SWCZ010 |
| Message-ID | <sAS9Q-3GK-13@gated-at.bofh.it> |
| In reply to | #1516169 |
From: Jan Remmet <j.remmet@phytec.de> 3.12-stable review patch. If anyone has any objections, please let me know. =============== commit 8f9165c981fed187bb483de84caf9adf835aefda upstream. http://www.ti.com/lit/pdf/SWCZ010: DCDC o/p voltage can go higher than programmed value Impact: VDDI, VDD2, and VIO output programmed voltage level can go higher than expected or crash, when coming out of PFM to PWM mode or using DVFS. Description: When DCDC CLK SYNC bits are 11/01: * VIO 3-MHz oscillator is the source clock of the digital core and input clock of VDD1 and VDD2 * Turn-on of VDD1 and VDD2 HSD PFETis synchronized or at a constant phase shift * Current pulled though VCC1+VCC2 is Iload(VDD1) + Iload(VDD2) * The 3 HSD PFET will be turned-on at the same time, causing the highest possible switching noise on the application. This noise level depends on the layout, the VBAT level, and the load current. The noise level increases with improper layout. When DCDC CLK SYNC bits are 00: * VIO 3-MHz oscillator is the source clock of digital core * VDD1 and VDD2 are running on their own 3-MHz oscillator * Current pulled though VCC1+VCC2 average of Iload(VDD1) + Iload(VDD2) * The switching noise of the 3 SMPS will be randomly spread over time, causing lower overall switching noise. Workaround: Set DCDCCTRL_REG[1:0]= 00. Signed-off-by: Jan Remmet <j.remmet@phytec.de> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz> --- drivers/regulator/tps65910-regulator.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/regulator/tps65910-regulator.c b/drivers/regulator/tps65910-regulator.c index 45c16447744b..1ed4145164d6 100644 --- a/drivers/regulator/tps65910-regulator.c +++ b/drivers/regulator/tps65910-regulator.c @@ -1080,6 +1080,12 @@ static int tps65910_probe(struct platform_device *pdev) pmic->num_regulators = ARRAY_SIZE(tps65910_regs); pmic->ext_sleep_control = tps65910_ext_sleep_control; info = tps65910_regs; + /* Work around silicon erratum SWCZ010: output programmed + * voltage level can go higher than expected or crash + * Workaround: use no synchronization of DCDC clocks + */ + tps65910_reg_clear_bits(pmic->mfd, TPS65910_DCDCCTRL, + DCDCCTRL_DCDCCKSYNC_MASK); break; case TPS65911: pmic->get_ctrl_reg = &tps65911_get_ctrl_register; -- 2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:30 +0100 |
| Subject | [PATCH 3.12 15/72] dm: mark request_queue dead before destroying the DM device |
| Message-ID | <sAS9Q-3GK-25@gated-at.bofh.it> |
| In reply to | #1516169 |
From: Bart Van Assche <bart.vanassche@sandisk.com>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit 3b785fbcf81c3533772c52b717f77293099498d3 upstream.
This avoids that new requests are queued while __dm_destroy() is in
progress.
[js] use md->queue instead of non-present helper
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
drivers/md/dm.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 78ab0a131cf1..8c82835a4749 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -2428,6 +2428,7 @@ EXPORT_SYMBOL_GPL(dm_device_name);
static void __dm_destroy(struct mapped_device *md, bool wait)
{
+ struct request_queue *q = md->queue;
struct dm_table *map;
int srcu_idx;
@@ -2438,6 +2439,10 @@ static void __dm_destroy(struct mapped_device *md, bool wait)
set_bit(DMF_FREEING, &md->flags);
spin_unlock(&_minor_lock);
+ spin_lock_irq(q->queue_lock);
+ queue_flag_set(QUEUE_FLAG_DYING, q);
+ spin_unlock_irq(q->queue_lock);
+
/*
* Take suspend_lock so that presuspend and postsuspend methods
* do not race with internal suspend.
--
2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:30 +0100 |
| Subject | [PATCH 3.12 16/72] powerpc/vdso64: Use double word compare on pointers |
| Message-ID | <sAS9Q-3GK-35@gated-at.bofh.it> |
| In reply to | #1516169 |
From: Anton Blanchard <anton@samba.org>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit 5045ea37377ce8cca6890d32b127ad6770e6dce5 upstream.
__kernel_get_syscall_map() and __kernel_clock_getres() use cmpli to
check if the passed in pointer is non zero. cmpli maps to a 32 bit
compare on binutils, so we ignore the top 32 bits.
A simple test case can be created by passing in a bogus pointer with
the bottom 32 bits clear. Using a clk_id that is handled by the VDSO,
then one that is handled by the kernel shows the problem:
printf("%d\n", clock_getres(CLOCK_REALTIME, (void *)0x100000000));
printf("%d\n", clock_getres(CLOCK_BOOTTIME, (void *)0x100000000));
And we get:
0
-1
The bigger issue is if we pass a valid pointer with the bottom 32 bits
clear, in this case we will return success but won't write any data
to the pointer.
I stumbled across this issue because the LLVM integrated assembler
doesn't accept cmpli with 3 arguments. Fix this by converting them to
cmpldi.
Fixes: a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel")
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
arch/powerpc/kernel/vdso64/datapage.S | 2 +-
arch/powerpc/kernel/vdso64/gettimeofday.S | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/vdso64/datapage.S b/arch/powerpc/kernel/vdso64/datapage.S
index 79796de11737..3263ee23170d 100644
--- a/arch/powerpc/kernel/vdso64/datapage.S
+++ b/arch/powerpc/kernel/vdso64/datapage.S
@@ -57,7 +57,7 @@ V_FUNCTION_BEGIN(__kernel_get_syscall_map)
bl V_LOCAL_FUNC(__get_datapage)
mtlr r12
addi r3,r3,CFG_SYSCALL_MAP64
- cmpli cr0,r4,0
+ cmpldi cr0,r4,0
crclr cr0*4+so
beqlr
li r0,__NR_syscalls
diff --git a/arch/powerpc/kernel/vdso64/gettimeofday.S b/arch/powerpc/kernel/vdso64/gettimeofday.S
index a76b4af37ef2..382021324883 100644
--- a/arch/powerpc/kernel/vdso64/gettimeofday.S
+++ b/arch/powerpc/kernel/vdso64/gettimeofday.S
@@ -145,7 +145,7 @@ V_FUNCTION_BEGIN(__kernel_clock_getres)
bne cr0,99f
li r3,0
- cmpli cr0,r4,0
+ cmpldi cr0,r4,0
crclr cr0*4+so
beqlr
lis r5,CLOCK_REALTIME_RES@h
--
2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:30 +0100 |
| Subject | [PATCH 3.12 22/72] zfcp: close window with unblocked rport during rport gone |
| Message-ID | <sAS9Q-3GK-33@gated-at.bofh.it> |
| In reply to | #1516169 |
From: Steffen Maier <maier@linux.vnet.ibm.com>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit 4eeaa4f3f1d6c47b69f70e222297a4df4743363e upstream.
On a successful end of reopen port forced,
zfcp_erp_strategy_followup_success() re-uses the port erp_action
and the subsequent zfcp_erp_action_cleanup() now
sees ZFCP_ERP_SUCCEEDED with
erp_action->action==ZFCP_ERP_ACTION_REOPEN_PORT
instead of ZFCP_ERP_ACTION_REOPEN_PORT_FORCED
but must not perform zfcp_scsi_schedule_rport_register().
We can detect this because the fresh port reopen erp_action
is in its very first step ZFCP_ERP_STEP_UNINITIALIZED.
Otherwise this opens a time window with unblocked rport
(until the followup port reopen recovery would block it again).
If a scsi_cmnd timeout occurs during this time window
fc_timed_out() cannot work as desired and such command
would indeed time out and trigger scsi_eh. This prevents
a clean and timely path failover.
This should not happen if the path issue can be recovered
on FC transport layer such as path issues involving RSCNs.
Also, unnecessary and repeated DID_IMM_RETRY for pending and
undesired new requests occur because internally zfcp still
has its zfcp_port blocked.
As follow-on errors with scsi_eh, it can cause,
in the worst case, permanently lost paths due to one of:
sd <scsidev>: [<scsidisk>] Medium access timeout failure. Offlining disk!
sd <scsidev>: Device offlined - not ready after error recovery
For fix validation and to aid future debugging with other recoveries
we now also trace (un)blocking of rports.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: 5767620c383a ("[SCSI] zfcp: Do not unblock rport from REOPEN_PORT_FORCED")
Fixes: a2fa0aede07c ("[SCSI] zfcp: Block FC transport rports early on errors")
Fixes: 5f852be9e11d ("[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI")
Fixes: 338151e06608 ("[SCSI] zfcp: make use of fc_remote_port_delete when target port is unavailable")
Fixes: 3859f6a248cb ("[PATCH] zfcp: add rports to enable scsi_add_device to work again")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
drivers/s390/scsi/zfcp_dbf.h | 7 ++++++-
drivers/s390/scsi/zfcp_erp.c | 12 +++++++++---
drivers/s390/scsi/zfcp_scsi.c | 8 +++++++-
3 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/s390/scsi/zfcp_dbf.h b/drivers/s390/scsi/zfcp_dbf.h
index 3ac7a4b30dd9..b5afa3d01e93 100644
--- a/drivers/s390/scsi/zfcp_dbf.h
+++ b/drivers/s390/scsi/zfcp_dbf.h
@@ -2,7 +2,7 @@
* zfcp device driver
* debug feature declarations
*
- * Copyright IBM Corp. 2008, 2010
+ * Copyright IBM Corp. 2008, 2015
*/
#ifndef ZFCP_DBF_H
@@ -17,6 +17,11 @@
#define ZFCP_DBF_INVALID_LUN 0xFFFFFFFFFFFFFFFFull
+enum zfcp_dbf_pseudo_erp_act_type {
+ ZFCP_PSEUDO_ERP_ACTION_RPORT_ADD = 0xff,
+ ZFCP_PSEUDO_ERP_ACTION_RPORT_DEL = 0xfe,
+};
+
/**
* struct zfcp_dbf_rec_trigger - trace record for triggered recovery action
* @ready: number of ready recovery actions
diff --git a/drivers/s390/scsi/zfcp_erp.c b/drivers/s390/scsi/zfcp_erp.c
index c82fe65c4128..ac86ff90c897 100644
--- a/drivers/s390/scsi/zfcp_erp.c
+++ b/drivers/s390/scsi/zfcp_erp.c
@@ -3,7 +3,7 @@
*
* Error Recovery Procedures (ERP).
*
- * Copyright IBM Corp. 2002, 2010
+ * Copyright IBM Corp. 2002, 2015
*/
#define KMSG_COMPONENT "zfcp"
@@ -1224,8 +1224,14 @@ static void zfcp_erp_action_cleanup(struct zfcp_erp_action *act, int result)
break;
case ZFCP_ERP_ACTION_REOPEN_PORT:
- if (result == ZFCP_ERP_SUCCEEDED)
- zfcp_scsi_schedule_rport_register(port);
+ /* This switch case might also happen after a forced reopen
+ * was successfully done and thus overwritten with a new
+ * non-forced reopen at `ersfs_2'. In this case, we must not
+ * do the clean-up of the non-forced version.
+ */
+ if (act->step != ZFCP_ERP_STEP_UNINITIALIZED)
+ if (result == ZFCP_ERP_SUCCEEDED)
+ zfcp_scsi_schedule_rport_register(port);
/* fall through */
case ZFCP_ERP_ACTION_REOPEN_PORT_FORCED:
put_device(&port->dev);
diff --git a/drivers/s390/scsi/zfcp_scsi.c b/drivers/s390/scsi/zfcp_scsi.c
index 7b353647cb90..38ee0df633a3 100644
--- a/drivers/s390/scsi/zfcp_scsi.c
+++ b/drivers/s390/scsi/zfcp_scsi.c
@@ -3,7 +3,7 @@
*
* Interface to Linux SCSI midlayer.
*
- * Copyright IBM Corp. 2002, 2013
+ * Copyright IBM Corp. 2002, 2015
*/
#define KMSG_COMPONENT "zfcp"
@@ -577,6 +577,9 @@ static void zfcp_scsi_rport_register(struct zfcp_port *port)
ids.port_id = port->d_id;
ids.roles = FC_RPORT_ROLE_FCP_TARGET;
+ zfcp_dbf_rec_trig("scpaddy", port->adapter, port, NULL,
+ ZFCP_PSEUDO_ERP_ACTION_RPORT_ADD,
+ ZFCP_PSEUDO_ERP_ACTION_RPORT_ADD);
rport = fc_remote_port_add(port->adapter->scsi_host, 0, &ids);
if (!rport) {
dev_err(&port->adapter->ccw_device->dev,
@@ -598,6 +601,9 @@ static void zfcp_scsi_rport_block(struct zfcp_port *port)
struct fc_rport *rport = port->rport;
if (rport) {
+ zfcp_dbf_rec_trig("scpdely", port->adapter, port, NULL,
+ ZFCP_PSEUDO_ERP_ACTION_RPORT_DEL,
+ ZFCP_PSEUDO_ERP_ACTION_RPORT_DEL);
fc_remote_port_delete(rport);
port->rport = NULL;
}
--
2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:30 +0100 |
| Subject | [PATCH 3.12 09/72] gpio: mpc8xxx: Correct irq handler function |
| Message-ID | <sAS9Q-3GK-39@gated-at.bofh.it> |
| In reply to | #1516169 |
From: Liu Gang <Gang.Liu@nxp.com> 3.12-stable review patch. If anyone has any objections, please let me know. =============== commit d71cf15b865bdd45925f7b094d169aaabd705145 upstream. From the beginning of the gpio-mpc8xxx.c, the "handle_level_irq" has being used to handle GPIO interrupts in the PowerPC/Layerscape platforms. But actually, almost all PowerPC/Layerscape platforms assert an interrupt request upon either a high-to-low change or any change on the state of the signal. So the "handle_level_irq" is not reasonable for PowerPC/Layerscape GPIO interrupt, it should be "handle_edge_irq". Otherwise the system may lost some interrupts from the PIN's state changes. Signed-off-by: Liu Gang <Gang.Liu@nxp.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz> --- drivers/gpio/gpio-mpc8xxx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c index 2aa3ca215bd6..d5376aa1c5e1 100644 --- a/drivers/gpio/gpio-mpc8xxx.c +++ b/drivers/gpio/gpio-mpc8xxx.c @@ -295,7 +295,7 @@ static int mpc8xxx_gpio_irq_map(struct irq_domain *h, unsigned int virq, mpc8xxx_irq_chip.irq_set_type = mpc8xxx_gc->of_dev_id_data; irq_set_chip_data(virq, h->host_data); - irq_set_chip_and_handler(virq, &mpc8xxx_irq_chip, handle_level_irq); + irq_set_chip_and_handler(virq, &mpc8xxx_irq_chip, handle_edge_irq); return 0; } -- 2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:30 +0100 |
| Subject | [PATCH 3.12 23/72] zfcp: retain trace level for SCSI and HBA FSF response records |
| Message-ID | <sAS9Q-3GK-37@gated-at.bofh.it> |
| In reply to | #1516169 |
From: Steffen Maier <maier@linux.vnet.ibm.com>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit 35f040df97fa0e94c7851c054ec71533c88b4b81 upstream.
While retaining the actual filtering according to trace level,
the following commits started to write such filtered records
with a hardcoded record level of 1 instead of the actual record level:
commit 250a1352b95e1db3216e5c5d4f4365bea5122f4a
("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.")
commit a54ca0f62f953898b05549391ac2a8a4dad6482b
("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
Now we can distinguish written records again for offline level filtering.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: 250a1352b95e ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.")
Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
drivers/s390/scsi/zfcp_dbf.c | 11 ++++++-----
drivers/s390/scsi/zfcp_dbf.h | 4 ++--
drivers/s390/scsi/zfcp_ext.h | 7 ++++---
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
index 132a905b6bdb..bbd1ed552d7d 100644
--- a/drivers/s390/scsi/zfcp_dbf.c
+++ b/drivers/s390/scsi/zfcp_dbf.c
@@ -3,7 +3,7 @@
*
* Debug traces for zfcp.
*
- * Copyright IBM Corp. 2002, 2013
+ * Copyright IBM Corp. 2002, 2015
*/
#define KMSG_COMPONENT "zfcp"
@@ -65,7 +65,7 @@ void zfcp_dbf_pl_write(struct zfcp_dbf *dbf, void *data, u16 length, char *area,
* @tag: tag indicating which kind of unsolicited status has been received
* @req: request for which a response was received
*/
-void zfcp_dbf_hba_fsf_res(char *tag, struct zfcp_fsf_req *req)
+void zfcp_dbf_hba_fsf_res(char *tag, int level, struct zfcp_fsf_req *req)
{
struct zfcp_dbf *dbf = req->adapter->dbf;
struct fsf_qtcb_prefix *q_pref = &req->qtcb->prefix;
@@ -97,7 +97,7 @@ void zfcp_dbf_hba_fsf_res(char *tag, struct zfcp_fsf_req *req)
rec->pl_len, "fsf_res", req->req_id);
}
- debug_event(dbf->hba, 1, rec, sizeof(*rec));
+ debug_event(dbf->hba, level, rec, sizeof(*rec));
spin_unlock_irqrestore(&dbf->hba_lock, flags);
}
@@ -399,7 +399,8 @@ void zfcp_dbf_san_in_els(char *tag, struct zfcp_fsf_req *fsf)
* @sc: pointer to struct scsi_cmnd
* @fsf: pointer to struct zfcp_fsf_req
*/
-void zfcp_dbf_scsi(char *tag, struct scsi_cmnd *sc, struct zfcp_fsf_req *fsf)
+void zfcp_dbf_scsi(char *tag, int level, struct scsi_cmnd *sc,
+ struct zfcp_fsf_req *fsf)
{
struct zfcp_adapter *adapter =
(struct zfcp_adapter *) sc->device->host->hostdata[0];
@@ -441,7 +442,7 @@ void zfcp_dbf_scsi(char *tag, struct scsi_cmnd *sc, struct zfcp_fsf_req *fsf)
}
}
- debug_event(dbf->scsi, 1, rec, sizeof(*rec));
+ debug_event(dbf->scsi, level, rec, sizeof(*rec));
spin_unlock_irqrestore(&dbf->scsi_lock, flags);
}
diff --git a/drivers/s390/scsi/zfcp_dbf.h b/drivers/s390/scsi/zfcp_dbf.h
index b5afa3d01e93..97f46e6964d4 100644
--- a/drivers/s390/scsi/zfcp_dbf.h
+++ b/drivers/s390/scsi/zfcp_dbf.h
@@ -284,7 +284,7 @@ static inline
void zfcp_dbf_hba_fsf_resp(char *tag, int level, struct zfcp_fsf_req *req)
{
if (level <= req->adapter->dbf->hba->level)
- zfcp_dbf_hba_fsf_res(tag, req);
+ zfcp_dbf_hba_fsf_res(tag, level, req);
}
/**
@@ -323,7 +323,7 @@ void _zfcp_dbf_scsi(char *tag, int level, struct scsi_cmnd *scmd,
scmd->device->host->hostdata[0];
if (level <= adapter->dbf->scsi->level)
- zfcp_dbf_scsi(tag, scmd, req);
+ zfcp_dbf_scsi(tag, level, scmd, req);
}
/**
diff --git a/drivers/s390/scsi/zfcp_ext.h b/drivers/s390/scsi/zfcp_ext.h
index a9c570a09b85..673f85103d72 100644
--- a/drivers/s390/scsi/zfcp_ext.h
+++ b/drivers/s390/scsi/zfcp_ext.h
@@ -3,7 +3,7 @@
*
* External function declarations.
*
- * Copyright IBM Corp. 2002, 2010
+ * Copyright IBM Corp. 2002, 2015
*/
#ifndef ZFCP_EXT_H
@@ -36,7 +36,7 @@ extern void zfcp_dbf_rec_trig(char *, struct zfcp_adapter *,
struct zfcp_port *, struct scsi_device *, u8, u8);
extern void zfcp_dbf_rec_run(char *, struct zfcp_erp_action *);
extern void zfcp_dbf_hba_fsf_uss(char *, struct zfcp_fsf_req *);
-extern void zfcp_dbf_hba_fsf_res(char *, struct zfcp_fsf_req *);
+extern void zfcp_dbf_hba_fsf_res(char *, int, struct zfcp_fsf_req *);
extern void zfcp_dbf_hba_bit_err(char *, struct zfcp_fsf_req *);
extern void zfcp_dbf_hba_berr(struct zfcp_dbf *, struct zfcp_fsf_req *);
extern void zfcp_dbf_hba_def_err(struct zfcp_adapter *, u64, u16, void **);
@@ -44,7 +44,8 @@ extern void zfcp_dbf_hba_basic(char *, struct zfcp_adapter *);
extern void zfcp_dbf_san_req(char *, struct zfcp_fsf_req *, u32);
extern void zfcp_dbf_san_res(char *, struct zfcp_fsf_req *);
extern void zfcp_dbf_san_in_els(char *, struct zfcp_fsf_req *);
-extern void zfcp_dbf_scsi(char *, struct scsi_cmnd *, struct zfcp_fsf_req *);
+extern void zfcp_dbf_scsi(char *, int, struct scsi_cmnd *,
+ struct zfcp_fsf_req *);
/* zfcp_erp.c */
extern void zfcp_erp_set_adapter_status(struct zfcp_adapter *, u32);
--
2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:30 +0100 |
| Subject | [PATCH 3.12 07/72] pstore: Fix buffer overflow while write offset equal to buffer size |
| Message-ID | <sAS9Q-3GK-41@gated-at.bofh.it> |
| In reply to | #1516169 |
From: Liu ShuoX <shuox.liu@intel.com>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit 017321cf390045dd4c4afc4a232995ea50bcf66d upstream.
In case new offset is equal to prz->buffer_size, it won't wrap at this
time and will return old(overflow) value next time.
Signed-off-by: Liu ShuoX <shuox.liu@intel.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
fs/pstore/ram_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index bda61a759b68..0b367ef7a7d6 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -54,7 +54,7 @@ static size_t buffer_start_add_atomic(struct persistent_ram_zone *prz, size_t a)
do {
old = atomic_read(&prz->buffer->start);
new = old + a;
- while (unlikely(new > prz->buffer_size))
+ while (unlikely(new >= prz->buffer_size))
new -= prz->buffer_size;
} while (atomic_cmpxchg(&prz->buffer->start, old, new) != old);
@@ -91,7 +91,7 @@ static size_t buffer_start_add_locked(struct persistent_ram_zone *prz, size_t a)
old = atomic_read(&prz->buffer->start);
new = old + a;
- while (unlikely(new > prz->buffer_size))
+ while (unlikely(new >= prz->buffer_size))
new -= prz->buffer_size;
atomic_set(&prz->buffer->start, new);
--
2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:30 +0100 |
| Subject | [PATCH 3.12 06/72] cfq: fix starvation of asynchronous writes |
| Message-ID | <sAS9R-3GK-49@gated-at.bofh.it> |
| In reply to | #1516169 |
From: Glauber Costa <glauber@scylladb.com>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit 3932a86b4b9d1f0b049d64d4591ce58ad18b44ec upstream.
While debugging timeouts happening in my application workload (ScyllaDB), I have
observed calls to open() taking a long time, ranging everywhere from 2 seconds -
the first ones that are enough to time out my application - to more than 30
seconds.
The problem seems to happen because XFS may block on pending metadata updates
under certain circumnstances, and that's confirmed with the following backtrace
taken by the offcputime tool (iovisor/bcc):
ffffffffb90c57b1 finish_task_switch
ffffffffb97dffb5 schedule
ffffffffb97e310c schedule_timeout
ffffffffb97e1f12 __down
ffffffffb90ea821 down
ffffffffc046a9dc xfs_buf_lock
ffffffffc046abfb _xfs_buf_find
ffffffffc046ae4a xfs_buf_get_map
ffffffffc046babd xfs_buf_read_map
ffffffffc0499931 xfs_trans_read_buf_map
ffffffffc044a561 xfs_da_read_buf
ffffffffc0451390 xfs_dir3_leaf_read.constprop.16
ffffffffc0452b90 xfs_dir2_leaf_lookup_int
ffffffffc0452e0f xfs_dir2_leaf_lookup
ffffffffc044d9d3 xfs_dir_lookup
ffffffffc047d1d9 xfs_lookup
ffffffffc0479e53 xfs_vn_lookup
ffffffffb925347a path_openat
ffffffffb9254a71 do_filp_open
ffffffffb9242a94 do_sys_open
ffffffffb9242b9e sys_open
ffffffffb97e42b2 entry_SYSCALL_64_fastpath
00007fb0698162ed [unknown]
Inspecting my run with blktrace, I can see that the xfsaild kthread exhibit very
high "Dispatch wait" times, on the dozens of seconds range and consistent with
the open() times I have saw in that run.
Still from the blktrace output, we can after searching a bit, identify the
request that wasn't dispatched:
8,0 11 152 81.092472813 804 A WM 141698288 + 8 <- (8,1) 141696240
8,0 11 153 81.092472889 804 Q WM 141698288 + 8 [xfsaild/sda1]
8,0 11 154 81.092473207 804 G WM 141698288 + 8 [xfsaild/sda1]
8,0 11 206 81.092496118 804 I WM 141698288 + 8 ( 22911) [xfsaild/sda1]
<==== 'I' means Inserted (into the IO scheduler) ===================================>
8,0 0 289372 96.718761435 0 D WM 141698288 + 8 (15626265317) [swapper/0]
<==== Only 15s later the CFQ scheduler dispatches the request ======================>
As we can see above, in this particular example CFQ took 15 seconds to dispatch
this request. Going back to the full trace, we can see that the xfsaild queue
had plenty of opportunity to run, and it was selected as the active queue many
times. It would just always be preempted by something else (example):
8,0 1 0 81.117912979 0 m N cfq1618SN / insert_request
8,0 1 0 81.117913419 0 m N cfq1618SN / add_to_rr
8,0 1 0 81.117914044 0 m N cfq1618SN / preempt
8,0 1 0 81.117914398 0 m N cfq767A / slice expired t=1
8,0 1 0 81.117914755 0 m N cfq767A / resid=40
8,0 1 0 81.117915340 0 m N / served: vt=1948520448 min_vt=1948520448
8,0 1 0 81.117915858 0 m N cfq767A / sl_used=1 disp=0 charge=0 iops=1 sect=0
where cfq767 is the xfsaild queue and cfq1618 corresponds to one of the ScyllaDB
IO dispatchers.
The requests preempting the xfsaild queue are synchronous requests. That's a
characteristic of ScyllaDB workloads, as we only ever issue O_DIRECT requests.
While it can be argued that preempting ASYNC requests in favor of SYNC is part
of the CFQ logic, I don't believe that doing so for 15+ seconds is anyone's
goal.
Moreover, unless I am misunderstanding something, that breaks the expectation
set by the "fifo_expire_async" tunable, which in my system is set to the
default.
Looking at the code, it seems to me that the issue is that after we make
an async queue active, there is no guarantee that it will execute any request.
When the queue itself tests if it cfq_may_dispatch() it can bail if it sees SYNC
requests in flight. An incoming request from another queue can also preempt it
in such situation before we have the chance to execute anything (as seen in the
trace above).
This patch sets the must_dispatch flag if we notice that we have requests
that are already fifo_expired. This flag is always cleared after
cfq_dispatch_request() returns from cfq_dispatch_requests(), so it won't pin
the queue for subsequent requests (unless they are themselves expired)
Care is taken during preempt to still allow rt requests to preempt us
regardless.
Testing my workload with this patch applied produces much better results.
From the application side I see no timeouts, and the open() latency histogram
generated by systemtap looks much better, with the worst outlier at 131ms:
Latency histogram of xfs_buf_lock acquisition (microseconds):
value |-------------------------------------------------- count
0 | 11
1 |@@@@ 161
2 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1966
4 |@ 54
8 | 36
16 | 7
32 | 0
64 | 0
~
1024 | 0
2048 | 0
4096 | 1
8192 | 1
16384 | 2
32768 | 0
65536 | 0
131072 | 1
262144 | 0
524288 | 0
Signed-off-by: Glauber Costa <glauber@scylladb.com>
CC: Jens Axboe <axboe@kernel.dk>
CC: linux-block@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Glauber Costa <glauber@scylladb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
block/cfq-iosched.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index b19c9f391761..cf3c8dc4acce 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -2812,7 +2812,6 @@ static struct request *cfq_check_fifo(struct cfq_queue *cfqq)
if (time_before(jiffies, rq_fifo_time(rq)))
rq = NULL;
- cfq_log_cfqq(cfqq->cfqd, cfqq, "fifo=%p", rq);
return rq;
}
@@ -3186,6 +3185,9 @@ static bool cfq_may_dispatch(struct cfq_data *cfqd, struct cfq_queue *cfqq)
{
unsigned int max_dispatch;
+ if (cfq_cfqq_must_dispatch(cfqq))
+ return true;
+
/*
* Drain async requests before we start sync IO
*/
@@ -3277,15 +3279,20 @@ static bool cfq_dispatch_request(struct cfq_data *cfqd, struct cfq_queue *cfqq)
BUG_ON(RB_EMPTY_ROOT(&cfqq->sort_list));
+ rq = cfq_check_fifo(cfqq);
+ if (rq)
+ cfq_mark_cfqq_must_dispatch(cfqq);
+
if (!cfq_may_dispatch(cfqd, cfqq))
return false;
/*
* follow expired path, else get first next available
*/
- rq = cfq_check_fifo(cfqq);
if (!rq)
rq = cfqq->next_rq;
+ else
+ cfq_log_cfqq(cfqq->cfqd, cfqq, "fifo=%p", rq);
/*
* insert request into driver dispatch list
@@ -3794,7 +3801,7 @@ cfq_should_preempt(struct cfq_data *cfqd, struct cfq_queue *new_cfqq,
* if the new request is sync, but the currently running queue is
* not, let the sync request have priority.
*/
- if (rq_is_sync(rq) && !cfq_cfqq_sync(cfqq))
+ if (rq_is_sync(rq) && !cfq_cfqq_sync(cfqq) && !cfq_cfqq_must_dispatch(cfqq))
return true;
if (new_cfqq->cfqg != cfqq->cfqg)
--
2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:30 +0100 |
| Subject | [PATCH 3.12 08/72] ipc: remove use of seq_printf return value |
| Message-ID | <sAS9R-3GK-57@gated-at.bofh.it> |
| In reply to | #1516169 |
From: Joe Perches <joe@perches.com>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit 7f032d6ef6154868a2a5d5f6b2c3f8587292196c upstream.
The seq_printf return value, because it's frequently misused,
will eventually be converted to void.
See: commit 1f33c41c03da ("seq_file: Rename seq_overflow() to
seq_has_overflowed() and make public")
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
ipc/msg.c | 34 ++++++++++++++++++----------------
ipc/sem.c | 26 ++++++++++++++------------
ipc/shm.c | 42 ++++++++++++++++++++++--------------------
ipc/util.c | 6 ++++--
4 files changed, 58 insertions(+), 50 deletions(-)
diff --git a/ipc/msg.c b/ipc/msg.c
index f8c22afff450..b92acb6a138c 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -1046,21 +1046,23 @@ static int sysvipc_msg_proc_show(struct seq_file *s, void *it)
struct user_namespace *user_ns = seq_user_ns(s);
struct msg_queue *msq = it;
- return seq_printf(s,
- "%10d %10d %4o %10lu %10lu %5u %5u %5u %5u %5u %5u %10lu %10lu %10lu\n",
- msq->q_perm.key,
- msq->q_perm.id,
- msq->q_perm.mode,
- msq->q_cbytes,
- msq->q_qnum,
- msq->q_lspid,
- msq->q_lrpid,
- from_kuid_munged(user_ns, msq->q_perm.uid),
- from_kgid_munged(user_ns, msq->q_perm.gid),
- from_kuid_munged(user_ns, msq->q_perm.cuid),
- from_kgid_munged(user_ns, msq->q_perm.cgid),
- msq->q_stime,
- msq->q_rtime,
- msq->q_ctime);
+ seq_printf(s,
+ "%10d %10d %4o %10lu %10lu %5u %5u %5u %5u %5u %5u %10lu %10lu %10lu\n",
+ msq->q_perm.key,
+ msq->q_perm.id,
+ msq->q_perm.mode,
+ msq->q_cbytes,
+ msq->q_qnum,
+ msq->q_lspid,
+ msq->q_lrpid,
+ from_kuid_munged(user_ns, msq->q_perm.uid),
+ from_kgid_munged(user_ns, msq->q_perm.gid),
+ from_kuid_munged(user_ns, msq->q_perm.cuid),
+ from_kgid_munged(user_ns, msq->q_perm.cgid),
+ msq->q_stime,
+ msq->q_rtime,
+ msq->q_ctime);
+
+ return 0;
}
#endif
diff --git a/ipc/sem.c b/ipc/sem.c
index 7fb486739cbb..9e963c28a214 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -2174,17 +2174,19 @@ static int sysvipc_sem_proc_show(struct seq_file *s, void *it)
sem_otime = get_semotime(sma);
- return seq_printf(s,
- "%10d %10d %4o %10u %5u %5u %5u %5u %10lu %10lu\n",
- sma->sem_perm.key,
- sma->sem_perm.id,
- sma->sem_perm.mode,
- sma->sem_nsems,
- from_kuid_munged(user_ns, sma->sem_perm.uid),
- from_kgid_munged(user_ns, sma->sem_perm.gid),
- from_kuid_munged(user_ns, sma->sem_perm.cuid),
- from_kgid_munged(user_ns, sma->sem_perm.cgid),
- sem_otime,
- sma->sem_ctime);
+ seq_printf(s,
+ "%10d %10d %4o %10u %5u %5u %5u %5u %10lu %10lu\n",
+ sma->sem_perm.key,
+ sma->sem_perm.id,
+ sma->sem_perm.mode,
+ sma->sem_nsems,
+ from_kuid_munged(user_ns, sma->sem_perm.uid),
+ from_kgid_munged(user_ns, sma->sem_perm.gid),
+ from_kuid_munged(user_ns, sma->sem_perm.cuid),
+ from_kgid_munged(user_ns, sma->sem_perm.cgid),
+ sem_otime,
+ sma->sem_ctime);
+
+ return 0;
}
#endif
diff --git a/ipc/shm.c b/ipc/shm.c
index 02f7125c8a0f..4066519acc64 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -1340,25 +1340,27 @@ static int sysvipc_shm_proc_show(struct seq_file *s, void *it)
#define SIZE_SPEC "%21lu"
#endif
- return seq_printf(s,
- "%10d %10d %4o " SIZE_SPEC " %5u %5u "
- "%5lu %5u %5u %5u %5u %10lu %10lu %10lu "
- SIZE_SPEC " " SIZE_SPEC "\n",
- shp->shm_perm.key,
- shp->shm_perm.id,
- shp->shm_perm.mode,
- shp->shm_segsz,
- shp->shm_cprid,
- shp->shm_lprid,
- shp->shm_nattch,
- from_kuid_munged(user_ns, shp->shm_perm.uid),
- from_kgid_munged(user_ns, shp->shm_perm.gid),
- from_kuid_munged(user_ns, shp->shm_perm.cuid),
- from_kgid_munged(user_ns, shp->shm_perm.cgid),
- shp->shm_atim,
- shp->shm_dtim,
- shp->shm_ctim,
- rss * PAGE_SIZE,
- swp * PAGE_SIZE);
+ seq_printf(s,
+ "%10d %10d %4o " SIZE_SPEC " %5u %5u "
+ "%5lu %5u %5u %5u %5u %10lu %10lu %10lu "
+ SIZE_SPEC " " SIZE_SPEC "\n",
+ shp->shm_perm.key,
+ shp->shm_perm.id,
+ shp->shm_perm.mode,
+ shp->shm_segsz,
+ shp->shm_cprid,
+ shp->shm_lprid,
+ shp->shm_nattch,
+ from_kuid_munged(user_ns, shp->shm_perm.uid),
+ from_kgid_munged(user_ns, shp->shm_perm.gid),
+ from_kuid_munged(user_ns, shp->shm_perm.cuid),
+ from_kgid_munged(user_ns, shp->shm_perm.cgid),
+ shp->shm_atim,
+ shp->shm_dtim,
+ shp->shm_ctim,
+ rss * PAGE_SIZE,
+ swp * PAGE_SIZE);
+
+ return 0;
}
#endif
diff --git a/ipc/util.c b/ipc/util.c
index 735342570a87..cc106890784b 100644
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -904,8 +904,10 @@ static int sysvipc_proc_show(struct seq_file *s, void *it)
struct ipc_proc_iter *iter = s->private;
struct ipc_proc_iface *iface = iter->iface;
- if (it == SEQ_START_TOKEN)
- return seq_puts(s, iface->header);
+ if (it == SEQ_START_TOKEN) {
+ seq_puts(s, iface->header);
+ return 0;
+ }
return iface->show(s, it);
}
--
2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:30 +0100 |
| Subject | [PATCH 3.12 17/72] powerpc/powernv: Use CPU-endian PEST in pnv_pci_dump_p7ioc_diag_data() |
| Message-ID | <sAS9R-3GK-51@gated-at.bofh.it> |
| In reply to | #1516169 |
From: Gavin Shan <gwshan@linux.vnet.ibm.com>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit 5adaf8629b193f185ca5a1665b9e777a0579f518 upstream.
This fixes the warnings reported from sparse:
pci.c:312:33: warning: restricted __be64 degrades to integer
pci.c:313:33: warning: restricted __be64 degrades to integer
Fixes: cee72d5bb489 ("powerpc/powernv: Display diag data on p7ioc EEH errors")
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
arch/powerpc/platforms/powernv/pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
index 52746b3caf08..ec78cdb13288 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -179,8 +179,8 @@ static void pnv_pci_dump_p7ioc_diag_data(struct pnv_phb *phb)
pr_info(" dma1ErrorLog1 = 0x%016llx\n", data->dma1ErrorLog1);
for (i = 0; i < OPAL_P7IOC_NUM_PEST_REGS; i++) {
- if ((data->pestA[i] >> 63) == 0 &&
- (data->pestB[i] >> 63) == 0)
+ if ((be64_to_cpu(data->pestA[i]) >> 63) == 0 &&
+ (be64_to_cpu(data->pestB[i]) >> 63) == 0)
continue;
pr_info(" PE[%3d] PESTA = 0x%016llx\n", i, data->pestA[i]);
pr_info(" PESTB = 0x%016llx\n", data->pestB[i]);
--
2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:30 +0100 |
| Subject | [PATCH 3.12 20/72] zfcp: fix fc_host port_type with NPIV |
| Message-ID | <sAS9R-3GK-59@gated-at.bofh.it> |
| In reply to | #1516169 |
From: Steffen Maier <maier@linux.vnet.ibm.com>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit bd77befa5bcff8c51613de271913639edf85fbc2 upstream.
For an NPIV-enabled FCP device, zfcp can erroneously show
"NPort (fabric via point-to-point)" instead of "NPIV VPORT"
for the port_type sysfs attribute of the corresponding
fc_host.
s390-tools that can be affected are dbginfo.sh and ziomon.
zfcp_fsf_exchange_config_evaluate() ignores
fsf_qtcb_bottom_config.connection_features indicating NPIV
and only sets fc_host_port_type to FC_PORTTYPE_NPORT if
fsf_qtcb_bottom_config.fc_topology is FSF_TOPO_FABRIC.
Only the independent zfcp_fsf_exchange_port_evaluate()
evaluates connection_features to overwrite fc_host_port_type
to FC_PORTTYPE_NPIV in case of NPIV.
Code was introduced with upstream kernel 2.6.30
commit 0282985da5923fa6365adcc1a1586ae0c13c1617
("[SCSI] zfcp: Report fc_host_port_type as NPIV").
This works during FCP device recovery (such as set online)
because it performs FSF_QTCB_EXCHANGE_CONFIG_DATA followed by
FSF_QTCB_EXCHANGE_PORT_DATA in sequence.
However, the zfcp-specific scsi host sysfs attributes
"requests", "megabytes", or "seconds_active" trigger only
zfcp_fsf_exchange_config_evaluate() resetting fc_host
port_type to FC_PORTTYPE_NPORT despite NPIV.
The zfcp-specific scsi host sysfs attribute "utilization"
triggers only zfcp_fsf_exchange_port_evaluate() correcting
the fc_host port_type again in case of NPIV.
Evaluate fsf_qtcb_bottom_config.connection_features
in zfcp_fsf_exchange_config_evaluate() where it belongs to.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: 0282985da592 ("[SCSI] zfcp: Report fc_host_port_type as NPIV")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
drivers/s390/scsi/zfcp_fsf.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/s390/scsi/zfcp_fsf.c b/drivers/s390/scsi/zfcp_fsf.c
index 0fe8d5d95119..08d488f47097 100644
--- a/drivers/s390/scsi/zfcp_fsf.c
+++ b/drivers/s390/scsi/zfcp_fsf.c
@@ -3,7 +3,7 @@
*
* Implementation of FSF commands.
*
- * Copyright IBM Corp. 2002, 2013
+ * Copyright IBM Corp. 2002, 2015
*/
#define KMSG_COMPONENT "zfcp"
@@ -508,7 +508,10 @@ static int zfcp_fsf_exchange_config_evaluate(struct zfcp_fsf_req *req)
fc_host_port_type(shost) = FC_PORTTYPE_PTP;
break;
case FSF_TOPO_FABRIC:
- fc_host_port_type(shost) = FC_PORTTYPE_NPORT;
+ if (bottom->connection_features & FSF_FEATURE_NPIV_MODE)
+ fc_host_port_type(shost) = FC_PORTTYPE_NPIV;
+ else
+ fc_host_port_type(shost) = FC_PORTTYPE_NPORT;
break;
case FSF_TOPO_AL:
fc_host_port_type(shost) = FC_PORTTYPE_NLPORT;
@@ -613,7 +616,6 @@ static void zfcp_fsf_exchange_port_evaluate(struct zfcp_fsf_req *req)
if (adapter->connection_features & FSF_FEATURE_NPIV_MODE) {
fc_host_permanent_port_name(shost) = bottom->wwpn;
- fc_host_port_type(shost) = FC_PORTTYPE_NPIV;
} else
fc_host_permanent_port_name(shost) = fc_host_port_name(shost);
fc_host_maxframe_size(shost) = bottom->maximum_frame_size;
--
2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-07 14:40 +0100 |
| Subject | [PATCH 3.12 62/72] powerpc/eeh: Null check uses of eeh_pe_bus_get |
| Message-ID | <sASjv-3Kx-5@gated-at.bofh.it> |
| In reply to | #1516119 |
From: Russell Currey <ruscur@russell.cc>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit 04fec21c06e35b169a83e75a84a015ab4606bf5e upstream.
eeh_pe_bus_get() can return NULL if a PCI bus isn't found for a given PE.
Some callers don't check this, and can cause a null pointer dereference
under certain circumstances.
Fix this by checking NULL everywhere eeh_pe_bus_get() is called.
Fixes: 8a6b1bc70dbb ("powerpc/eeh: EEH core to handle special event")
Signed-off-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
arch/powerpc/kernel/eeh_driver.c | 8 ++++++++
arch/powerpc/platforms/powernv/eeh-ioda.c | 5 +++++
2 files changed, 13 insertions(+)
diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index d3a132c9127c..33d998fda24e 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -697,6 +697,14 @@ static void eeh_handle_special_event(void)
/* Notify all devices to be down */
bus = eeh_pe_bus_get(phb_pe);
+ if (!bus) {
+ pr_err("%s: Cannot find PCI bus for "
+ "PHB#%d-PE#%x\n",
+ __func__,
+ pe->phb->global_number,
+ pe->addr);
+ break;
+ }
eeh_pe_dev_traverse(pe,
eeh_report_failure, NULL);
pcibios_remove_pci_devices(bus);
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
index b91083370bc6..605a2f07618e 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -493,6 +493,11 @@ static int ioda_eeh_reset(struct eeh_pe *pe, int option)
ret = ioda_eeh_phb_reset(hose, option);
} else {
bus = eeh_pe_bus_get(pe);
+ if (!bus) {
+ pr_err("%s: Cannot find PCI bus for PHB#%d-PE#%x\n",
+ __func__, pe->phb->global_number, pe->addr);
+ return -EIO;
+ }
if (pci_is_root_bus(bus) ||
pci_is_root_bus(bus->parent))
ret = ioda_eeh_root_reset(hose, option);
--
2.10.2
[toc] | [prev] | [next] | [standalone]
| From | Guenter Roeck <linux@roeck-us.net> |
|---|---|
| Date | 2016-11-07 18:20 +0100 |
| Message-ID | <sAVKq-6d8-9@gated-at.bofh.it> |
| In reply to | #1516119 |
On 11/07/2016 05:04 AM, Jiri Slaby wrote:
> This is the start of the stable review cycle for the 3.12.67 release.
> There are 72 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 Nov 9 14:03:48 CET 2016.
> Anything received after that time might be too late.
>
Build results:
total: 128 pass: 127 fail: 1
Failed builds:
um:defconfig
Qemu test results:
total: 85 pass: 85 fail: 0
Details are available at http://kerneltests.org/builders.
Build error log for um:defconfig:
ipc/sem.c: In function 'complexmode_tryleave':
ipc/sem.c:317:2: error: implicit declaration of function 'smp_store_release'
ipc/sem.c: In function 'sem_lock':
ipc/sem.c:370:3: error: implicit declaration of function 'smp_load_acquire'
Culprit is commit a198951bf258 ("ipc/sem.c: fix complex_count vs. simple op race"),
and reverting it fixes the problem. Copying the patch author for feedback.
Guenter
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-08 16:50 +0100 |
| Message-ID | <sBgOR-2Jy-17@gated-at.bofh.it> |
| In reply to | #1516349 |
On 11/07/2016, 06:16 PM, Guenter Roeck wrote:
> On 11/07/2016 05:04 AM, Jiri Slaby wrote:
>> This is the start of the stable review cycle for the 3.12.67 release.
>> There are 72 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 Nov 9 14:03:48 CET 2016.
>> Anything received after that time might be too late.
>>
>
> Build results:
> total: 128 pass: 127 fail: 1
> Failed builds:
> um:defconfig
>
> Qemu test results:
> total: 85 pass: 85 fail: 0
>
> Details are available at http://kerneltests.org/builders.
>
> Build error log for um:defconfig:
>
> ipc/sem.c: In function 'complexmode_tryleave':
> ipc/sem.c:317:2: error: implicit declaration of function
> 'smp_store_release'
> ipc/sem.c: In function 'sem_lock':
> ipc/sem.c:370:3: error: implicit declaration of function 'smp_load_acquire'
>
> Culprit is commit a198951bf258 ("ipc/sem.c: fix complex_count vs. simple
> op race"),
> and reverting it fixes the problem. Copying the patch author for feedback.
Oh, thanks!
I backported this to fix the problem:
commit 577f183acc88645eae116326cc2203dc88ea730c
Author: Michael S. Tsirkin <mst@redhat.com>
Date: Mon Dec 21 09:22:18 2015 +0200
x86/um: reuse asm-generic/barrier.h
Everything should be fine now, let's see the results :).
thanks,
--
js
suse labs
[toc] | [prev] | [next] | [standalone]
| From | Guenter Roeck <linux@roeck-us.net> |
|---|---|
| Date | 2016-11-09 05:20 +0100 |
| Message-ID | <sBswF-2nS-3@gated-at.bofh.it> |
| In reply to | #1517302 |
On 11/08/2016 07:40 AM, Jiri Slaby wrote:
> On 11/07/2016, 06:16 PM, Guenter Roeck wrote:
>> On 11/07/2016 05:04 AM, Jiri Slaby wrote:
>>> This is the start of the stable review cycle for the 3.12.67 release.
>>> There are 72 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 Nov 9 14:03:48 CET 2016.
>>> Anything received after that time might be too late.
>>>
>>
>> Build results:
>> total: 128 pass: 127 fail: 1
>> Failed builds:
>> um:defconfig
>>
>> Qemu test results:
>> total: 85 pass: 85 fail: 0
>>
>> Details are available at http://kerneltests.org/builders.
>>
>> Build error log for um:defconfig:
>>
>> ipc/sem.c: In function 'complexmode_tryleave':
>> ipc/sem.c:317:2: error: implicit declaration of function
>> 'smp_store_release'
>> ipc/sem.c: In function 'sem_lock':
>> ipc/sem.c:370:3: error: implicit declaration of function 'smp_load_acquire'
>>
>> Culprit is commit a198951bf258 ("ipc/sem.c: fix complex_count vs. simple
>> op race"),
>> and reverting it fixes the problem. Copying the patch author for feedback.
>
> Oh, thanks!
>
> I backported this to fix the problem:
> commit 577f183acc88645eae116326cc2203dc88ea730c
> Author: Michael S. Tsirkin <mst@redhat.com>
> Date: Mon Dec 21 09:22:18 2015 +0200
>
> x86/um: reuse asm-generic/barrier.h
>
> Everything should be fine now, let's see the results :).
>
Yes, all ok now.
Guenter
[toc] | [prev] | [next] | [standalone]
| From | Jiri Slaby <jslaby@suse.cz> |
|---|---|
| Date | 2016-11-10 20:00 +0100 |
| Message-ID | <sC2JQ-1Fi-15@gated-at.bofh.it> |
| In reply to | #1517755 |
On 11/09/2016, 05:14 AM, Guenter Roeck wrote:
> On 11/08/2016 07:40 AM, Jiri Slaby wrote:
>> On 11/07/2016, 06:16 PM, Guenter Roeck wrote:
>>> On 11/07/2016 05:04 AM, Jiri Slaby wrote:
>>>> This is the start of the stable review cycle for the 3.12.67 release.
>>>> There are 72 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 Nov 9 14:03:48 CET 2016.
>>>> Anything received after that time might be too late.
>>>>
>>>
>>> Build results:
>>> total: 128 pass: 127 fail: 1
>>> Failed builds:
>>> um:defconfig
>>>
>>> Qemu test results:
>>> total: 85 pass: 85 fail: 0
>>>
>>> Details are available at http://kerneltests.org/builders.
>>>
>>> Build error log for um:defconfig:
>>>
>>> ipc/sem.c: In function 'complexmode_tryleave':
>>> ipc/sem.c:317:2: error: implicit declaration of function
>>> 'smp_store_release'
>>> ipc/sem.c: In function 'sem_lock':
>>> ipc/sem.c:370:3: error: implicit declaration of function
>>> 'smp_load_acquire'
>>>
>>> Culprit is commit a198951bf258 ("ipc/sem.c: fix complex_count vs. simple
>>> op race"),
>>> and reverting it fixes the problem. Copying the patch author for
>>> feedback.
>>
>> Oh, thanks!
>>
>> I backported this to fix the problem:
>> commit 577f183acc88645eae116326cc2203dc88ea730c
>> Author: Michael S. Tsirkin <mst@redhat.com>
>> Date: Mon Dec 21 09:22:18 2015 +0200
>>
>> x86/um: reuse asm-generic/barrier.h
>>
>> Everything should be fine now, let's see the results :).
>>
>
> Yes, all ok now.
Ok, thanks for confirming!
--
js
suse labs
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | linux.kernel
csiph-web