1. 22 Apr, 2017 11 commits
    • Steven Rostedt (VMware)'s avatar
      ftrace: Fix removing of second function probe · 1f9b31fd
      Steven Rostedt (VMware) authored
      commit 82cc4fc2 upstream.
      
      When two function probes are added to set_ftrace_filter, and then one of
      them is removed, the update to the function locations is not performed, and
      the record keeping of the function states are corrupted, and causes an
      ftrace_bug() to occur.
      
      This is easily reproducable by adding two probes, removing one, and then
      adding it back again.
      
       # cd /sys/kernel/debug/tracing
       # echo schedule:traceoff > set_ftrace_filter
       # echo do_IRQ:traceoff > set_ftrace_filter
       # echo \!do_IRQ:traceoff > /debug/tracing/set_ftrace_filter
       # echo do_IRQ:traceoff > set_ftrace_filter
      
      Causes:
       ------------[ cut here ]------------
       WARNING: CPU: 2 PID: 1098 at kernel/trace/ftrace.c:2369 ftrace_get_addr_curr+0x143/0x220
       Modules linked in: [...]
       CPU: 2 PID: 1098 Comm: bash Not tainted 4.10.0-test+ #405
       Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
       Call Trace:
        dump_stack+0x68/0x9f
        __warn+0x111/0x130
        ? trace_irq_work_interrupt+0xa0/0xa0
        warn_slowpath_null+0x1d/0x20
        ftrace_get_addr_curr+0x143/0x220
        ? __fentry__+0x10/0x10
        ftrace_replace_code+0xe3/0x4f0
        ? ftrace_int3_handler+0x90/0x90
        ? printk+0x99/0xb5
        ? 0xffffffff81000000
        ftrace_modify_all_code+0x97/0x110
        arch_ftrace_update_code+0x10/0x20
        ftrace_run_update_code+0x1c/0x60
        ftrace_run_modify_code.isra.48.constprop.62+0x8e/0xd0
        register_ftrace_function_probe+0x4b6/0x590
        ? ftrace_startup+0x310/0x310
        ? debug_lockdep_rcu_enabled.part.4+0x1a/0x30
        ? update_stack_state+0x88/0x110
        ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320
        ? preempt_count_sub+0x18/0xd0
        ? mutex_lock_nested+0x104/0x800
        ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320
        ? __unwind_start+0x1c0/0x1c0
        ? _mutex_lock_nest_lock+0x800/0x800
        ftrace_trace_probe_callback.isra.3+0xc0/0x130
        ? func_set_flag+0xe0/0xe0
        ? __lock_acquire+0x642/0x1790
        ? __might_fault+0x1e/0x20
        ? trace_get_user+0x398/0x470
        ? strcmp+0x35/0x60
        ftrace_trace_onoff_callback+0x48/0x70
        ftrace_regex_write.isra.43.part.44+0x251/0x320
        ? match_records+0x420/0x420
        ftrace_filter_write+0x2b/0x30
        __vfs_write+0xd7/0x330
        ? do_loop_readv_writev+0x120/0x120
        ? locks_remove_posix+0x90/0x2f0
        ? do_lock_file_wait+0x160/0x160
        ? __lock_is_held+0x93/0x100
        ? rcu_read_lock_sched_held+0x5c/0xb0
        ? preempt_count_sub+0x18/0xd0
        ? __sb_start_write+0x10a/0x230
        ? vfs_write+0x222/0x240
        vfs_write+0xef/0x240
        SyS_write+0xab/0x130
        ? SyS_read+0x130/0x130
        ? trace_hardirqs_on_caller+0x182/0x280
        ? trace_hardirqs_on_thunk+0x1a/0x1c
        entry_SYSCALL_64_fastpath+0x18/0xad
       RIP: 0033:0x7fe61c157c30
       RSP: 002b:00007ffe87890258 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
       RAX: ffffffffffffffda RBX: ffffffff8114a410 RCX: 00007fe61c157c30
       RDX: 0000000000000010 RSI: 000055814798f5e0 RDI: 0000000000000001
       RBP: ffff8800c9027f98 R08: 00007fe61c422740 R09: 00007fe61ca53700
       R10: 0000000000000073 R11: 0000000000000246 R12: 0000558147a36400
       R13: 00007ffe8788f160 R14: 0000000000000024 R15: 00007ffe8788f15c
        ? trace_hardirqs_off_caller+0xc0/0x110
       ---[ end trace 99fa09b3d9869c2c ]---
       Bad trampoline accounting at: ffffffff81cc3b00 (do_IRQ+0x0/0x150)
      
      Fixes: 59df055f ("ftrace: trace different functions with a different tracer")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f9b31fd
    • Juergen Gross's avatar
      xen, fbfront: fix connecting to backend · de584f83
      Juergen Gross authored
      commit 9121b15b upstream.
      
      Connecting to the backend isn't working reliably in xen-fbfront: in
      case XenbusStateInitWait of the backend has been missed the backend
      transition to XenbusStateConnected will trigger the connected state
      only without doing the actions required when the backend has
      connected.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de584f83
    • Martin K. Petersen's avatar
      scsi: sd: Fix capacity calculation with 32-bit sector_t · 1038f1f4
      Martin K. Petersen authored
      commit 7c856152 upstream.
      
      We previously made sure that the reported disk capacity was less than
      0xffffffff blocks when the kernel was not compiled with large sector_t
      support (CONFIG_LBDAF). However, this check assumed that the capacity
      was reported in units of 512 bytes.
      
      Add a sanity check function to ensure that we only enable disks if the
      entire reported capacity can be expressed in terms of sector_t.
      Reported-by: default avatarSteve Magnani <steve.magnani@digidescorp.com>
      Cc: Bart Van Assche <Bart.VanAssche@sandisk.com>
      Reviewed-by: default avatarBart Van Assche <Bart.VanAssche@sandisk.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1038f1f4
    • Martin K. Petersen's avatar
      scsi: sr: Sanity check returned mode data · 167d5feb
      Martin K. Petersen authored
      commit a00a7862 upstream.
      
      Kefeng Wang discovered that old versions of the QEMU CD driver would
      return mangled mode data causing us to walk off the end of the buffer in
      an attempt to parse it. Sanity check the returned mode sense data.
      Reported-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Tested-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      167d5feb
    • Nicholas Bellinger's avatar
      iscsi-target: Drop work-around for legacy GlobalSAN initiator · e204051d
      Nicholas Bellinger authored
      commit 1c99de98 upstream.
      
      Once upon a time back in 2009, a work-around was added to support
      the GlobalSAN iSCSI initiator v3.3 for MacOSX, which during login
      did not propose nor respond to MaxBurstLength, FirstBurstLength,
      DefaultTime2Wait and DefaultTime2Retain keys.
      
      The work-around in iscsi_check_proposer_for_optional_reply()
      allowed the missing keys to be proposed, but did not require
      waiting for a response before moving to full feature phase
      operation.  This allowed GlobalSAN v3.3 to work out-of-the
      box, and for many years we didn't run into login interopt
      issues with any other initiators..
      
      Until recently, when Martin tried a QLogic 57840S iSCSI Offload
      HBA on Windows 2016 which completed login, but subsequently
      failed with:
      
          Got unknown iSCSI OpCode: 0x43
      
      The issue was QLogic MSFT side did not propose DefaultTime2Wait +
      DefaultTime2Retain, so LIO proposes them itself, and immediately
      transitions to full feature phase because of the GlobalSAN hack.
      However, the QLogic MSFT side still attempts to respond to
      DefaultTime2Retain + DefaultTime2Wait, even though LIO has set
      ISCSI_FLAG_LOGIN_NEXT_STAGE3 + ISCSI_FLAG_LOGIN_TRANSIT
      in last login response.
      
      So while the QLogic MSFT side should have been proposing these
      two keys to start, it was doing the correct thing per RFC-3720
      attempting to respond to proposed keys before transitioning to
      full feature phase.
      
      All that said, recent versions of GlobalSAN iSCSI (v5.3.0.541)
      does correctly propose the four keys during login, making the
      original work-around moot.
      
      So in order to allow QLogic MSFT to run unmodified as-is, go
      ahead and drop this long standing work-around.
      Reported-by: default avatarMartin Svec <martin.svec@zoner.cz>
      Cc: Martin Svec <martin.svec@zoner.cz>
      Cc: Himanshu Madhani <Himanshu.Madhani@cavium.com>
      Cc: Arun Easi <arun.easi@cavium.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e204051d
    • Nicholas Bellinger's avatar
      iscsi-target: Fix TMR reference leak during session shutdown · 808430c4
      Nicholas Bellinger authored
      commit efb2ea77 upstream.
      
      This patch fixes a iscsi-target specific TMR reference leak
      during session shutdown, that could occur when a TMR was
      quiesced before the hand-off back to iscsi-target code
      via transport_cmd_check_stop_to_fabric().
      
      The reference leak happens because iscsit_free_cmd() was
      incorrectly skipping the final target_put_sess_cmd() for
      TMRs when transport_generic_free_cmd() returned zero because
      the se_cmd->cmd_kref did not reach zero, due to the missing
      se_cmd assignment in original code.
      
      The result was iscsi_cmd and it's associated se_cmd memory
      would be freed once se_sess->sess_cmd_map where released,
      but the associated se_tmr_req was leaked and remained part
      of se_device->dev_tmr_list.
      
      This bug would manfiest itself as kernel paging request
      OOPsen in core_tmr_lun_reset(), when a left-over se_tmr_req
      attempted to dereference it's se_cmd pointer that had
      already been released during normal session shutdown.
      
      To address this bug, go ahead and treat ISCSI_OP_SCSI_CMD
      and ISCSI_OP_SCSI_TMFUNC the same when there is an extra
      se_cmd->cmd_kref to drop in iscsit_free_cmd(), and use
      op_scsi to signal __iscsit_free_cmd() when the former
      needs to clear any further iscsi related I/O state.
      Reported-by: default avatarRob Millner <rlm@daterainc.com>
      Cc: Rob Millner <rlm@daterainc.com>
      Reported-by: default avatarChu Yuan Lin <cyl@datera.io>
      Cc: Chu Yuan Lin <cyl@datera.io>
      Tested-by: default avatarChu Yuan Lin <cyl@datera.io>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      808430c4
    • Mathias Krause's avatar
      x86/vdso: Ensure vdso32_enabled gets set to valid values only · ced7ce3d
      Mathias Krause authored
      commit c06989da upstream.
      
      vdso_enabled can be set to arbitrary integer values via the kernel command
      line 'vdso32=' parameter or via 'sysctl abi.vsyscall32'.
      
      load_vdso32() only maps VDSO if vdso_enabled == 1, but ARCH_DLINFO_IA32
      merily checks for vdso_enabled != 0. As a consequence the AT_SYSINFO_EHDR
      auxiliary vector for the VDSO_ENTRY is emitted with a NULL pointer which
      causes a segfault when the application tries to use the VDSO.
      
      Restrict the valid arguments on the command line and the sysctl to 0 and 1.
      
      Fixes: b0b49f26 ("x86, vdso: Remove compat vdso support")
      Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
      Acked-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Roland McGrath <roland@redhat.com>
      Link: http://lkml.kernel.org/r/1491424561-7187-1-git-send-email-minipli@googlemail.com
      Link: http://lkml.kernel.org/r/20170410151723.518412863@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ced7ce3d
    • Thomas Gleixner's avatar
      x86/vdso: Plug race between mapping and ELF header setup · 3255c1b5
      Thomas Gleixner authored
      commit 6fdc6dd9 upstream.
      
      The vsyscall32 sysctl can racy against a concurrent fork when it switches
      from disabled to enabled:
      
          arch_setup_additional_pages()
      	if (vdso32_enabled)
                 --> No mapping
                                              sysctl.vsysscall32()
                                                --> vdso32_enabled = true
          create_elf_tables()
            ARCH_DLINFO_IA32
              if (vdso32_enabled) {
                 --> Add VDSO entry with NULL pointer
      
      Make ARCH_DLINFO_IA32 check whether the VDSO mapping has been set up for
      the newly forked process or not.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Mathias Krause <minipli@googlemail.com>
      Link: http://lkml.kernel.org/r/20170410151723.602367196@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3255c1b5
    • Peter Zijlstra's avatar
      perf/x86: Avoid exposing wrong/stale data in intel_pmu_lbr_read_32() · f9e23df4
      Peter Zijlstra authored
      commit f2200ac3 upstream.
      
      When the perf_branch_entry::{in_tx,abort,cycles} fields were added,
      intel_pmu_lbr_read_32() wasn't updated to initialize them.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Fixes: 135c5612 ("perf/x86/intel: Support Haswell/v4 LBR format")
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9e23df4
    • Cameron Gutman's avatar
    • Germano Percossi's avatar
      CIFS: store results of cifs_reopen_file to avoid infinite wait · ca57d3ae
      Germano Percossi authored
      commit 1fa839b4 upstream.
      
      This fixes Continuous Availability when errors during
      file reopen are encountered.
      
      cifs_user_readv and cifs_user_writev would wait for ever if
      results of cifs_reopen_file are not stored and for later inspection.
      
      In fact, results are checked and, in case of errors, a chain
      of function calls leading to reads and writes to be scheduled in
      a separate thread is skipped.
      These threads will wake up the corresponding waiters once reads
      and writes are done.
      
      However, given the return value is not stored, when rc is checked
      for errors a previous one (always zero) is inspected instead.
      This leads to pending reads/writes added to the list, making
      cifs_user_readv and cifs_user_writev wait for ever.
      Signed-off-by: default avatarGermano Percossi <germano.percossi@citrix.com>
      Reviewed-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ca57d3ae
  2. 18 Apr, 2017 29 commits