1. 08 Nov, 2016 15 commits
  2. 28 Oct, 2016 25 commits
    • Paul E. McKenney's avatar
      compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release() · afe98b3b
      Paul E. McKenney authored
      commit 536fa402 upstream.
      
      CPUs without single-byte and double-byte loads and stores place some
      "interesting" requirements on concurrent code.  For example (adapted
      from Peter Hurley's test code), suppose we have the following structure:
      
      	struct foo {
      		spinlock_t lock1;
      		spinlock_t lock2;
      		char a; /* Protected by lock1. */
      		char b; /* Protected by lock2. */
      	};
      	struct foo *foop;
      
      Of course, it is common (and good) practice to place data protected
      by different locks in separate cache lines.  However, if the locks are
      rarely acquired (for example, only in rare error cases), and there are
      a great many instances of the data structure, then memory footprint can
      trump false-sharing concerns, so that it can be better to place them in
      the same cache cache line as above.
      
      But if the CPU does not support single-byte loads and stores, a store
      to foop->a will do a non-atomic read-modify-write operation on foop->b,
      which will come as a nasty surprise to someone holding foop->lock2.  So we
      now require CPUs to support single-byte and double-byte loads and stores.
      Therefore, this commit adjusts the definition of __native_word() to allow
      these sizes to be used by smp_load_acquire() and smp_store_release().
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      afe98b3b
    • Guenter Roeck's avatar
      metag: Only define atomic_dec_if_positive conditionally · e4dfd365
      Guenter Roeck authored
      commit 35d04077 upstream.
      
      The definition of atomic_dec_if_positive() assumes that
      atomic_sub_if_positive() exists, which is only the case if
      metag specific atomics are used. This results in the following
      build error when trying to build metag1_defconfig.
      
      kernel/ucount.c: In function 'dec_ucount':
      kernel/ucount.c:211: error:
      	implicit declaration of function 'atomic_sub_if_positive'
      
      Moving the definition of atomic_dec_if_positive() into the metag
      conditional code fixes the problem.
      
      Fixes: 6006c0d8 ("metag: Atomics, locks and bitops")
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      e4dfd365
    • Ming Lei's avatar
      scsi: Fix use-after-free · 04b46ca8
      Ming Lei authored
      commit bcd8f2e9 upstream.
      
      This patch fixes one use-after-free report[1] by KASAN.
      
      In __scsi_scan_target(), when a type 31 device is probed,
      SCSI_SCAN_TARGET_PRESENT is returned and the target will be scanned
      again.
      
      Inside the following scsi_report_lun_scan(), one new scsi_device
      instance is allocated, and scsi_probe_and_add_lun() is called again to
      probe the target and still see type 31 device, finally
      __scsi_remove_device() is called to remove & free the device at the end
      of scsi_probe_and_add_lun(), so cause use-after-free in
      scsi_report_lun_scan().
      
      And the following SCSI log can be observed:
      
      	scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
      	scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
      	scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
      	scsi 0:0:2:0: scsi scan: Sending REPORT LUNS to (try 0)
      	scsi 0:0:2:0: scsi scan: REPORT LUNS successful (try 0) result 0x0
      	scsi 0:0:2:0: scsi scan: REPORT LUN scan
      	scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
      	scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
      	scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
      	BUG: KASAN: use-after-free in __scsi_scan_target+0xbf8/0xe40 at addr ffff88007b44a104
      
      This patch fixes the issue by moving the putting reference at
      the end of scsi_report_lun_scan().
      
      [1] KASAN report
      ==================================================================
      [    3.274597] PM: Adding info for serio:serio1
      [    3.275127] BUG: KASAN: use-after-free in __scsi_scan_target+0xd87/0xdf0 at addr ffff880254d8c304
      [    3.275653] Read of size 4 by task kworker/u10:0/27
      [    3.275903] CPU: 3 PID: 27 Comm: kworker/u10:0 Not tainted 4.8.0 #2121
      [    3.276258] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      [    3.276797] Workqueue: events_unbound async_run_entry_fn
      [    3.277083]  ffff880254d8c380 ffff880259a37870 ffffffff94bbc6c1 ffff880078402d80
      [    3.277532]  ffff880254d8bb80 ffff880259a37898 ffffffff9459fec1 ffff880259a37930
      [    3.277989]  ffff880254d8bb80 ffff880078402d80 ffff880259a37920 ffffffff945a0165
      [    3.278436] Call Trace:
      [    3.278528]  [<ffffffff94bbc6c1>] dump_stack+0x65/0x84
      [    3.278797]  [<ffffffff9459fec1>] kasan_object_err+0x21/0x70
      [    3.279063] device: 'psaux': device_add
      [    3.279616]  [<ffffffff945a0165>] kasan_report_error+0x205/0x500
      [    3.279651] PM: Adding info for No Bus:psaux
      [    3.280202]  [<ffffffff944ecd22>] ? kfree_const+0x22/0x30
      [    3.280486]  [<ffffffff94bc2dc9>] ? kobject_release+0x119/0x370
      [    3.280805]  [<ffffffff945a0543>] __asan_report_load4_noabort+0x43/0x50
      [    3.281170]  [<ffffffff9507e1f7>] ? __scsi_scan_target+0xd87/0xdf0
      [    3.281506]  [<ffffffff9507e1f7>] __scsi_scan_target+0xd87/0xdf0
      [    3.281848]  [<ffffffff9507d470>] ? scsi_add_device+0x30/0x30
      [    3.282156]  [<ffffffff94f7f660>] ? pm_runtime_autosuspend_expiration+0x60/0x60
      [    3.282570]  [<ffffffff956ddb07>] ? _raw_spin_lock+0x17/0x40
      [    3.282880]  [<ffffffff9507e505>] scsi_scan_channel+0x105/0x160
      [    3.283200]  [<ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
      [    3.283563]  [<ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
      [    3.283882]  [<ffffffff9507efc1>] do_scan_async+0x41/0x450
      [    3.284173]  [<ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
      [    3.284492]  [<ffffffff941a8954>] ? pwq_dec_nr_in_flight+0x124/0x2a0
      [    3.284876]  [<ffffffff941d1770>] ? preempt_count_add+0x130/0x160
      [    3.285207]  [<ffffffff941a9a84>] process_one_work+0x544/0x12d0
      [    3.285526]  [<ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
      [    3.285844]  [<ffffffff941aa810>] ? process_one_work+0x12d0/0x12d0
      [    3.286182]  [<ffffffff941bb365>] kthread+0x1c5/0x260
      [    3.286443]  [<ffffffff940855cd>] ? __switch_to+0x88d/0x1430
      [    3.286745]  [<ffffffff941bb1a0>] ? kthread_worker_fn+0x5a0/0x5a0
      [    3.287085]  [<ffffffff956dde9f>] ret_from_fork+0x1f/0x40
      [    3.287368]  [<ffffffff941bb1a0>] ? kthread_worker_fn+0x5a0/0x5a0
      [    3.287697] Object at ffff880254d8bb80, in cache kmalloc-2048 size: 2048
      [    3.288064] Allocated:
      [    3.288147] PID = 27
      [    3.288218]  [<ffffffff940b27ab>] save_stack_trace+0x2b/0x50
      [    3.288531]  [<ffffffff9459f246>] save_stack+0x46/0xd0
      [    3.288806]  [<ffffffff9459f4bd>] kasan_kmalloc+0xad/0xe0
      [    3.289098]  [<ffffffff9459c07e>] __kmalloc+0x13e/0x250
      [    3.289378]  [<ffffffff95078e5a>] scsi_alloc_sdev+0xea/0xcf0
      [    3.289701]  [<ffffffff9507de76>] __scsi_scan_target+0xa06/0xdf0
      [    3.290034]  [<ffffffff9507e505>] scsi_scan_channel+0x105/0x160
      [    3.290362]  [<ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
      [    3.290724]  [<ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
      [    3.291055]  [<ffffffff9507efc1>] do_scan_async+0x41/0x450
      [    3.291354]  [<ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
      [    3.291695]  [<ffffffff941a9a84>] process_one_work+0x544/0x12d0
      [    3.292022]  [<ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
      [    3.292325]  [<ffffffff941bb365>] kthread+0x1c5/0x260
      [    3.292594]  [<ffffffff956dde9f>] ret_from_fork+0x1f/0x40
      [    3.292886] Freed:
      [    3.292945] PID = 27
      [    3.293016]  [<ffffffff940b27ab>] save_stack_trace+0x2b/0x50
      [    3.293327]  [<ffffffff9459f246>] save_stack+0x46/0xd0
      [    3.293600]  [<ffffffff9459fa61>] kasan_slab_free+0x71/0xb0
      [    3.293916]  [<ffffffff9459bac2>] kfree+0xa2/0x1f0
      [    3.294168]  [<ffffffff9508158a>] scsi_device_dev_release_usercontext+0x50a/0x730
      [    3.294598]  [<ffffffff941ace9a>] execute_in_process_context+0xda/0x130
      [    3.294974]  [<ffffffff9508107c>] scsi_device_dev_release+0x1c/0x20
      [    3.295322]  [<ffffffff94f566f6>] device_release+0x76/0x1e0
      [    3.295626]  [<ffffffff94bc2db7>] kobject_release+0x107/0x370
      [    3.295942]  [<ffffffff94bc29ce>] kobject_put+0x4e/0xa0
      [    3.296222]  [<ffffffff94f56e17>] put_device+0x17/0x20
      [    3.296497]  [<ffffffff9505201c>] scsi_device_put+0x7c/0xa0
      [    3.296801]  [<ffffffff9507e1bc>] __scsi_scan_target+0xd4c/0xdf0
      [    3.297132]  [<ffffffff9507e505>] scsi_scan_channel+0x105/0x160
      [    3.297458]  [<ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
      [    3.297829]  [<ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
      [    3.298156]  [<ffffffff9507efc1>] do_scan_async+0x41/0x450
      [    3.298453]  [<ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
      [    3.298777]  [<ffffffff941a9a84>] process_one_work+0x544/0x12d0
      [    3.299105]  [<ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
      [    3.299408]  [<ffffffff941bb365>] kthread+0x1c5/0x260
      [    3.299676]  [<ffffffff956dde9f>] ret_from_fork+0x1f/0x40
      [    3.299967] Memory state around the buggy address:
      [    3.300209]  ffff880254d8c200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [    3.300608]  ffff880254d8c280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [    3.300986] >ffff880254d8c300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [    3.301408]                    ^
      [    3.301550]  ffff880254d8c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [    3.301987]  ffff880254d8c400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [    3.302396]
      ==================================================================
      
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      04b46ca8
    • Trond Myklebust's avatar
      NFSv4: Open state recovery must account for file permission changes · b160dbbd
      Trond Myklebust authored
      commit 304020fe upstream.
      
      If the file permissions change on the server, then we may not be able to
      recover open state. If so, we need to ensure that we mark the file
      descriptor appropriately.
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Tested-by: default avatarOleg Drokin <green@linuxhacker.ru>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b160dbbd
    • Dmitry Torokhov's avatar
      Input: elantech - add Fujitsu Lifebook E556 to force crc_enabled · 689c691b
      Dmitry Torokhov authored
      commit 62837b3c upstream.
      
      Another Lifebook machine that needs the same quirk as other similar
      models to make the driver working.
      
      Also let's reorder elantech_dmi_force_crc_enabled list so LIfebook enries
      are in alphabetical order.
      Reported-by: default avatarWilliam Linna <william.linna@gmail.com>
      Tested-by: default avatarWilliam Linna <william.linna@gmail.com>
      Reviewed-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      689c691b
    • Matti Kurkela's avatar
      Input: elantech - force needed quirks on Fujitsu H760 · 2ace5a25
      Matti Kurkela authored
      commit f9a703a5 upstream.
      
      Just like Fujitsu CELSIUS H730, the H760 also has an Elantech touchpad with
      the same quirks. Without this patch, the touchpad is useless out-of-the-box
      as the mouse pointer won't move.
      
      This patch makes the driver aware of both the crc_enabled=1 requirement and
      the middle button, making the touchpad fully functional out-of-the-box.
      Signed-off-by: default avatarMatti Kurkela <Matti.Kurkela@iki.fi>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2ace5a25
    • Marcin Nowakowski's avatar
      MIPS: ptrace: Fix regs_return_value for kernel context · 75393dbe
      Marcin Nowakowski authored
      commit 74f1077b upstream.
      
      Currently regs_return_value always negates reg[2] if it determines
      the syscall has failed, but when called in kernel context this check is
      invalid and may result in returning a wrong value.
      
      This fixes errors reported by CONFIG_KPROBES_SANITY_TEST
      
      Fixes: d7e7528b ("Audit: push audit success and retcode into arch ptrace.h")
      Signed-off-by: default avatarMarcin Nowakowski <marcin.nowakowski@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14381/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      75393dbe
    • Mauro Carvalho Chehab's avatar
      cx231xx: fix GPIOs for Pixelview SBTVD hybrid · 9802f2db
      Mauro Carvalho Chehab authored
      commit 24b923f0 upstream.
      
      This device uses GPIOs: 28 to switch between analog and
      digital modes: on digital mode, it should be set to 1.
      
      The code that sets it on analog mode is OK, but it misses
      the logic that sets it on digital mode.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      9802f2db
    • Mauro Carvalho Chehab's avatar
      cx231xx: don't return error on success · 38cbcc78
      Mauro Carvalho Chehab authored
      commit 1871d718 upstream.
      
      The cx231xx_set_agc_analog_digital_mux_select() callers
      expect it to return 0 or an error. Returning a positive value
      makes the first attempt to switch between analog/digital to fail.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      38cbcc78
    • Mauro Carvalho Chehab's avatar
      mb86a20s: fix demod settings · e258efb3
      Mauro Carvalho Chehab authored
      commit 505a0ea7 upstream.
      
      With the current settings, only one channel locks properly.
      That's likely because, when this driver was written, Brazil
      were still using experimental transmissions.
      
      Change it to reproduce the settings used by the newer drivers.
      That makes it lock on other channels.
      
      Tested with both PixelView SBTVD Hybrid (cx231xx-based) and
      C3Tech Digital Duo HDTV/SDTV (em28xx-based) devices.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      e258efb3
    • Mauro Carvalho Chehab's avatar
      mb86a20s: fix the locking logic · d49f16e7
      Mauro Carvalho Chehab authored
      commit dafb65fb upstream.
      
      On this frontend, it takes a while to start output normal
      TS data. That only happens on state S9. On S8, the TS output
      is enabled, but it is not reliable enough.
      
      However, the zigzag loop is too fast to let it sync.
      
      As, on practical tests, the zigzag software loop doesn't
      seem to be helping, but just slowing down the tuning, let's
      switch to hardware algorithm, as the tuners used on such
      devices are capable of work with frequency drifts without
      any help from software.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d49f16e7
    • Max Staudt's avatar
      fbdev/efifb: Fix 16 color palette entry calculation · e559b035
      Max Staudt authored
      commit d50b3f43 upstream.
      
      When using efifb with a 16-bit (5:6:5) visual, fbcon's text is rendered
      in the wrong colors - e.g. text gray (#aaaaaa) is rendered as green
      (#50bc50) and neighboring pixels have slightly different values
      (such as #50bc78).
      
      The reason is that fbcon loads its 16 color palette through
      efifb_setcolreg(), which in turn calculates a 32-bit value to write
      into memory for each palette index.
      Until now, this code could only handle 8-bit visuals and didn't mask
      overlapping values when ORing them.
      
      With this patch, fbcon displays the correct colors when a qemu VM is
      booted in 16-bit mode (in GRUB: "set gfxpayload=800x600x16").
      
      Fixes: 7c83172b ("x86_64 EFI boot support: EFI frame buffer driver")  # v2.6.24+
      Signed-off-by: default avatarMax Staudt <mstaudt@suse.de>
      Acked-By: default avatarPeter Jones <pjones@redhat.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      e559b035
    • Dan Carpenter's avatar
      scsi: zfcp: spin_lock_irqsave() is not nestable · 919b4765
      Dan Carpenter authored
      commit e7cb08e8 upstream.
      
      We accidentally overwrite the original saved value of "flags" so that we
      can't re-enable IRQs at the end of the function.  Presumably this
      function is mostly called with IRQs disabled or it would be obvious in
      testing.
      
      Fixes: aceeffbb ("zfcp: trace full payload of all SAN records (req,resp,iels)")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      919b4765
    • Steffen Maier's avatar
      zfcp: trace full payload of all SAN records (req,resp,iels) · 6f5790ba
      Steffen Maier authored
      commit aceeffbb upstream.
      
      This was lost with commit 2c55b750
      ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
      but is necessary for problem determination, e.g. to see the
      currently active zone set during automatic port scan.
      
      For the large GPN_FT response (4 pages), save space by not dumping
      any empty residual entries.
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 2c55b750 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
      Reviewed-by: default avatarAlexey Ishchuk <aishchuk@linux.vnet.ibm.com>
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      6f5790ba
    • Steffen Maier's avatar
      zfcp: fix payload trace length for SAN request&response · 9e70e9ee
      Steffen Maier authored
      commit 94db3725 upstream.
      
      commit 2c55b750
      ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
      started to add FC_CT_HDR_LEN which made zfcp dump random data
      out of bounds for RSPN GS responses because u.rspn.rsp
      is the largest and last field in the union of struct zfcp_fc_req.
      Other request/response types only happened to stay within bounds
      due to the padding of the union or
      due to the trace capping of u.gspn.rsp to ZFCP_DBF_SAN_MAX_PAYLOAD.
      
      Timestamp      : ...
      Area           : SAN
      Subarea        : 00
      Level          : 1
      Exception      : -
      CPU id         : ..
      Caller         : ...
      Record id      : 2
      Tag            : fsscth2
      Request id     : 0x...
      Destination ID : 0x00fffffc
      Payload short  : 01000000 fc020000 80020000 00000000
                       xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx <===
                       00000000 00000000 00000000 00000000
      Payload length : 32                                  <===
      
      struct zfcp_fc_req {
          [0] struct zfcp_fsf_ct_els ct_els;
         [56] struct scatterlist sg_req;
         [96] struct scatterlist sg_rsp;
              union {
                  struct {req; rsp;} adisc;    SIZE: 28+28=   56
                  struct {req; rsp;} gid_pn;   SIZE: 24+20=   44
                  struct {rspsg; req;} gpn_ft; SIZE: 40*4+20=180
                  struct {req; rsp;} gspn;     SIZE: 20+273= 293
                  struct {req; rsp;} rspn;     SIZE: 277+16= 293
        [136] } u;
      }
      SIZE: 432
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 2c55b750 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
      Reviewed-by: default avatarAlexey Ishchuk <aishchuk@linux.vnet.ibm.com>
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      9e70e9ee
    • Steffen Maier's avatar
      zfcp: fix D_ID field with actual value on tracing SAN responses · ac00aa89
      Steffen Maier authored
      commit 771bf035 upstream.
      
      With commit 2c55b750
      ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
      we lost the N_Port-ID where an ELS response comes from.
      With commit 7c7dc196
      ("[SCSI] zfcp: Simplify handling of ct and els requests")
      we lost the N_Port-ID where a CT response comes from.
      It's especially useful if the request SAN trace record
      with D_ID was already lost due to trace buffer wrap.
      
      GS uses an open WKA port handle and ELS just a D_ID, and
      only for ELS we could get D_ID from QTCB bottom via zfcp_fsf_req.
      To cover both cases, add a new field to zfcp_fsf_ct_els
      and fill it in on request to use in SAN response trace.
      Strictly speaking the D_ID on SAN response is the FC frame's S_ID.
      We don't need a field for the other end which is always us.
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 2c55b750 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
      Fixes: 7c7dc196 ("[SCSI] zfcp: Simplify handling of ct and els requests")
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      ac00aa89
    • Steffen Maier's avatar
      zfcp: restore tracing of handle for port and LUN with HBA records · 95772bc4
      Steffen Maier authored
      commit 7c964ffe upstream.
      
      This information was lost with
      commit a54ca0f6
      ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
      but is required to debug e.g. invalid handle situations.
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: a54ca0f6 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      95772bc4
    • Steffen Maier's avatar
      zfcp: trace on request for open and close of WKA port · d0426362
      Steffen Maier authored
      commit d27a7cb9 upstream.
      
      Since commit a54ca0f6
      ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
      HBA records no longer contain WWPN, D_ID, or LUN
      to reduce duplicate information which is already in REC records.
      In contrast to "regular" target ports, we don't use recovery to open
      WKA ports such as directory/nameserver, so we don't get REC records.
      Therefore, introduce pseudo REC running records without any
      actual recovery action but including D_ID of WKA port on open/close.
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: a54ca0f6 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d0426362
    • Steffen Maier's avatar
      zfcp: restore: Dont use 0 to indicate invalid LUN in rec trace · 2a6fc747
      Steffen Maier authored
      commit 0102a30a upstream.
      
      bring back
      commit d21e9daa
      ("[SCSI] zfcp: Dont use 0 to indicate invalid LUN in rec trace")
      which was lost with
      commit ae0904f6
      ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.")
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: ae0904f6 ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.")
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2a6fc747
    • Steffen Maier's avatar
      zfcp: retain trace level for SCSI and HBA FSF response records · 9a71e7e6
      Steffen Maier authored
      commit 35f040df 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 250a1352
      ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.")
      commit a54ca0f6
      ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
      
      Now we can distinguish written records again for offline level filtering.
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 250a1352 ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.")
      Fixes: a54ca0f6 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      9a71e7e6
    • Steffen Maier's avatar
      zfcp: close window with unblocked rport during rport gone · 3498aa77
      Steffen Maier authored
      commit 4eeaa4f3 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: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 5767620c ("[SCSI] zfcp: Do not unblock rport from REOPEN_PORT_FORCED")
      Fixes: a2fa0aed ("[SCSI] zfcp: Block FC transport rports early on errors")
      Fixes: 5f852be9 ("[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI")
      Fixes: 338151e0 ("[SCSI] zfcp: make use of fc_remote_port_delete when target port is unavailable")
      Fixes: 3859f6a2 ("[PATCH] zfcp: add rports to enable scsi_add_device to work again")
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      3498aa77
    • Steffen Maier's avatar
      zfcp: fix ELS/GS request&response length for hardware data router · f2d495a3
      Steffen Maier authored
      commit 70369f8e upstream.
      
      In the hardware data router case, introduced with kernel 3.2
      commit 86a9668a ("[SCSI] zfcp: support for hardware data router")
      the ELS/GS request&response length needs to be initialized
      as in the chained SBAL case.
      
      Otherwise, the FCP channel rejects ELS requests with
      FSF_REQUEST_SIZE_TOO_LARGE.
      
      Such ELS requests can be issued by user space through BSG / HBA API,
      or zfcp itself uses ADISC ELS for remote port link test on RSCN.
      The latter can cause a short path outage due to
      unnecessary remote target port recovery because the always
      failing ADISC cannot detect extremely short path interruptions
      beyond the local FCP channel.
      
      Below example is decoded with zfcpdbf from s390-tools:
      
      Timestamp      : ...
      Area           : SAN
      Subarea        : 00
      Level          : 1
      Exception      : -
      CPU id         : ..
      Caller         : zfcp_dbf_san_req+0408
      Record id      : 1
      Tag            : fssels1
      Request id     : 0x<reqid>
      Destination ID : 0x00<target d_id>
      Payload info   : 52000000 00000000 <our wwpn       >           [ADISC]
                       <our wwnn       > 00<s_id> 00000000
                       00000000 00000000 00000000 00000000
      
      Timestamp      : ...
      Area           : HBA
      Subarea        : 00
      Level          : 1
      Exception      : -
      CPU id         : ..
      Caller         : zfcp_dbf_hba_fsf_res+0740
      Record id      : 1
      Tag            : fs_ferr
      Request id     : 0x<reqid>
      Request status : 0x00000010
      FSF cmnd       : 0x0000000b               [FSF_QTCB_SEND_ELS]
      FSF sequence no: 0x...
      FSF issued     : ...
      FSF stat       : 0x00000061		  [FSF_REQUEST_SIZE_TOO_LARGE]
      FSF stat qual  : 00000000 00000000 00000000 00000000
      Prot stat      : 0x00000100
      Prot stat qual : 00000000 00000000 00000000 00000000
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 86a9668a ("[SCSI] zfcp: support for hardware data router")
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      f2d495a3
    • Steffen Maier's avatar
      zfcp: fix fc_host port_type with NPIV · 36dc83b5
      Steffen Maier authored
      commit bd77befa 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 0282985d
      ("[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: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 0282985d ("[SCSI] zfcp: Report fc_host_port_type as NPIV")
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      36dc83b5
    • Laurent Dufour's avatar
      powerpc/pseries: Fix stack corruption in htpe code · 429074e8
      Laurent Dufour authored
      commit 05af40e8 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: 1a527286 ("powerpc: Optimize hugepage invalidate")
      Signed-off-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Acked-by: default avatarBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      429074e8
    • Paul Mackerras's avatar
      powerpc/64: Fix incorrect return value from __copy_tofrom_user · 61bc5e39
      Paul Mackerras authored
      commit 1a34439e upstream.
      
      Debugging a data corruption issue with virtio-net/vhost-net led to
      the observation that __copy_tofrom_user was occasionally returning
      a value 16 larger than it should.  Since the return value from
      __copy_tofrom_user is the number of bytes not copied, this means
      that __copy_tofrom_user can occasionally return a value larger
      than the number of bytes it was asked to copy.  In turn this can
      cause higher-level copy functions such as copy_page_to_iter_iovec
      to corrupt memory by copying data into the wrong memory locations.
      
      It turns out that the failing case involves a fault on the store
      at label 79, and at that point the first unmodified byte of the
      destination is at R3 + 16.  Consequently the exception handler
      for that store needs to add 16 to R3 before using it to work out
      how many bytes were not copied, but in this one case it was not
      adding the offset to R3.  To fix it, this moves the label 179 to
      the point where we add 16 to R3.  I have checked manually all the
      exception handlers for the loads and stores in this code and the
      rest of them are correct (it would be excellent to have an
      automated test of all the exception cases).
      
      This bug has been present since this code was initially
      committed in May 2002 to Linux version 2.5.20.
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      61bc5e39