1. 11 Dec, 2015 2 commits
  2. 10 Dec, 2015 7 commits
    • Mark Brown's avatar
      arm64: cmpxchg: Don't incldue linux/mmdebug.h · 4a6ccf30
      Mark Brown authored
      The arm64 asm/cmpxchg.h includes linux/mmdebug.h but doesn't so far as I
      can tell actually use anything from it.  Removing the inclusion reduces
      spurious header dependency rebuilds and also avoids issues with
      recursive inclusions of headers causing build breaks due to attempts to
      use things before they are defined if linux/mmdebug.h starts pulling in
      more low level headers.
      
      Such errors have happened in -next recently, for example:
      
      In file included from include/linux/completion.h:11:0,
                       from include/linux/rcupdate.h:43,
                       from include/linux/tracepoint.h:19,
                       from include/linux/mmdebug.h:6,
                       from ./arch/arm64/include/asm/cmpxchg.h:22,
                       from ./arch/arm64/include/asm/atomic.h:41,
                       from include/linux/atomic.h:4,
                       from include/linux/spinlock.h:406,
                       from include/linux/seqlock.h:35,
                       from include/linux/time.h:5,
                       from include/uapi/linux/timex.h:56,
                       from include/linux/timex.h:56,
                       from include/linux/sched.h:19,
                       from arch/arm64/kernel/asm-offsets.c:21:
      include/linux/wait.h: In function 'wait_on_atomic_t':
      include/linux/wait.h:1218:2: error: implicit declaration of function 'atomic_read' [-Werror=implicit-function-declaration]
       if (atomic_read(val) == 0)
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      4a6ccf30
    • Mark Rutland's avatar
      arm64: mm: fold alternatives into .init · 9aa4ec15
      Mark Rutland authored
      Currently we treat the alternatives separately from other data that's
      only used during initialisation, using separate .altinstructions and
      .altinstr_replacement linker sections. These are freed for general
      allocation separately from .init*. This is problematic as:
      
      * We do not remove execute permissions, as we do for .init, leaving the
        memory executable.
      
      * We pad between them, making the kernel Image bianry up to PAGE_SIZE
        bytes larger than necessary.
      
      This patch moves the two sections into the contiguous region used for
      .init*. This saves some memory, ensures that we remove execute
      permissions, and allows us to remove some code made redundant by this
      reorganisation.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Jeremy Linton <jeremy.linton@arm.com>
      Cc: Laura Abbott <labbott@fedoraproject.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      9aa4ec15
    • Mark Rutland's avatar
      arm64: Remove redundant padding from linker script · 5b28cd9d
      Mark Rutland authored
      Currently we place an ALIGN_DEBUG_RO between text and data for the .text
      and .init sections, and depending on configuration each of these may
      result in up to SECTION_SIZE bytes worth of padding (for
      DEBUG_RODATA_ALIGN).
      
      We make no distinction between the text and data in each of these
      sections at any point when creating the initial page tables in head.S.
      We also make no distinction when modifying the tables; __map_memblock,
      fixup_executable, mark_rodata_ro, and fixup_init only work at section
      granularity. Thus this padding is unnecessary.
      
      For the spit between init text and data we impose a minimum alignment of
      16 bytes, but this is also unnecessary. The init data is output
      immediately after the padding before any symbols are defined, so this is
      not required to keep a symbol for linker a section array correctly
      associated with the data. Any objects within the section will be given
      at least their usual alignment regardless.
      
      This patch removes the redundant padding.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Jeremy Linton <jeremy.linton@arm.com>
      Cc: Laura Abbott <labbott@fedoraproject.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5b28cd9d
    • Mark Rutland's avatar
      arm64: mm: remove pointless PAGE_MASKing · e2c30ee3
      Mark Rutland authored
      As pgd_offset{,_k} shift the input address by PGDIR_SHIFT, the sub-page
      bits will always be shifted out. There is no need to apply PAGE_MASK
      before this.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Jeremy Linton <jeremy.linton@arm.com>
      Cc: Laura Abbott <labbott@fedoraproject.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      e2c30ee3
    • James Morse's avatar
      arm64: don't call C code with el0's fp register · 49003a8d
      James Morse authored
      On entry from el0, we save all the registers on the kernel stack, and
      restore them before returning. x29 remains unchanged when we call out
      to C code, which will store x29 as the frame-pointer on the stack.
      
      Instead, write 0 into x29 after entry from el0, to avoid any risk of
      tracing into user space.
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      49003a8d
    • James Morse's avatar
      arm64: when walking onto the task stack, check sp & fp are in current->stack · 1ffe199b
      James Morse authored
      When unwind_frame() reaches the bottom of the irq_stack, the last fp
      points to the original task stack. unwind_frame() uses
      IRQ_STACK_TO_TASK_STACK() to find the sp value. If either values is
      wrong, we may end up walking a corrupt stack.
      
      Check these values are sane by testing if they are both on the stack
      pointed to by current->stack.
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      1ffe199b
    • James Morse's avatar
      arm64: Add this_cpu_ptr() assembler macro for use in entry.S · aa4d5d3c
      James Morse authored
      irq_stack is a per_cpu variable, that needs to be access from entry.S.
      Use an assembler macro instead of the unreadable details.
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      aa4d5d3c
  3. 09 Dec, 2015 1 commit
    • Will Deacon's avatar
      arm64: irq: fix walking from irq stack to task stack · 7596abf2
      Will Deacon authored
      Running with CONFIG_DEBUG_SPINLOCK=y can trigger a BUG with the new IRQ
      stack code:
      
        BUG: spinlock lockup suspected on CPU#1
      
      This is due to the IRQ_STACK_TO_TASK_STACK macro incorrectly retrieving
      the task stack pointer stashed at the top of the IRQ stack.
      
      Sayeth James:
      
      | Yup, this is what is happening. Its an off-by-one due to broken
      | thinking about how the stack works. My broken thinking was:
      |
      | >   top ------------
      | >       | dummy_lr | <- irq_stack_ptr
      | >       ------------
      | >       |   x29    |
      | >       ------------
      | >       |   x19    | <- irq_stack_ptr - 0x10
      | >       ------------
      | >       |   xzr    |
      | >       ------------
      |
      | But the stack-pointer is decreased before use. So it actually looks
      | like this:
      |
      | >       ------------
      | >       |          |  <- irq_stack_ptr
      | >   top ------------
      | >       | dummy_lr |
      | >       ------------
      | >       |   x29    | <- irq_stack_ptr - 0x10
      | >       ------------
      | >       |   x19    |
      | >       ------------
      | >       |   xzr    | <- irq_stack_ptr - 0x20
      | >       ------------
      |
      | The value being used as the original stack is x29, which in all the
      | tests is sp but without the current frames data, hence there are no
      | missing frames in the output.
      |
      | Jungseok Lee picked it up with a 32bit user space because aarch32
      | can't use x29, so it remains 0 forever. The fix he posted is correct.
      
      This patch fixes the macro and adds some of this wisdom to a comment,
      so that the layout of the IRQ stack is well understood.
      
      Cc: James Morse <james.morse@arm.com>
      Reported-by: default avatarJungseok Lee <jungseoklee85@gmail.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      7596abf2
  4. 08 Dec, 2015 3 commits
  5. 07 Dec, 2015 1 commit
  6. 04 Dec, 2015 3 commits
    • Catalin Marinas's avatar
      arm64: Add trace_hardirqs_off annotation in ret_to_user · db3899a6
      Catalin Marinas authored
      When a kernel is built with CONFIG_TRACE_IRQFLAGS the following warning
      is produced when entering userspace for the first time:
      
        WARNING: at /work/Linux/linux-2.6-aarch64/kernel/locking/lockdep.c:3519
        Modules linked in:
        CPU: 1 PID: 1 Comm: systemd Not tainted 4.4.0-rc3+ #639
        Hardware name: Juno (DT)
        task: ffffffc9768a0000 ti: ffffffc9768a8000 task.ti: ffffffc9768a8000
        PC is at check_flags.part.22+0x19c/0x1a8
        LR is at check_flags.part.22+0x19c/0x1a8
        pc : [<ffffffc0000fba6c>] lr : [<ffffffc0000fba6c>] pstate: 600001c5
        sp : ffffffc9768abe10
        x29: ffffffc9768abe10 x28: ffffffc9768a8000
        x27: 0000000000000000 x26: 0000000000000001
        x25: 00000000000000a6 x24: ffffffc00064be6c
        x23: ffffffc0009f249e x22: ffffffc9768a0000
        x21: ffffffc97fea5480 x20: 00000000000001c0
        x19: ffffffc00169a000 x18: 0000005558cc7b58
        x17: 0000007fb78e3180 x16: 0000005558d2e238
        x15: ffffffffffffffff x14: 0ffffffffffffffd
        x13: 0000000000000008 x12: 0101010101010101
        x11: 7f7f7f7f7f7f7f7f x10: fefefefefefeff63
        x9 : 7f7f7f7f7f7f7f7f x8 : 6e655f7371726964
        x7 : 0000000000000001 x6 : ffffffc0001079c4
        x5 : 0000000000000000 x4 : 0000000000000001
        x3 : ffffffc001698438 x2 : 0000000000000000
        x1 : ffffffc9768a0000 x0 : 000000000000002e
        Call trace:
        [<ffffffc0000fba6c>] check_flags.part.22+0x19c/0x1a8
        [<ffffffc0000fc440>] lock_is_held+0x80/0x98
        [<ffffffc00064bafc>] __schedule+0x404/0x730
        [<ffffffc00064be6c>] schedule+0x44/0xb8
        [<ffffffc000085bb0>] ret_to_user+0x0/0x24
        possible reason: unannotated irqs-off.
        irq event stamp: 502169
        hardirqs last  enabled at (502169): [<ffffffc000085a98>] el0_irq_naked+0x1c/0x24
        hardirqs last disabled at (502167): [<ffffffc0000bb3bc>] __do_softirq+0x17c/0x298
        softirqs last  enabled at (502168): [<ffffffc0000bb43c>] __do_softirq+0x1fc/0x298
        softirqs last disabled at (502143): [<ffffffc0000bb830>] irq_exit+0xa0/0xf0
      
      This happens because we disable interrupts in ret_to_user before calling
      schedule() in work_resched. This patch adds the necessary
      trace_hardirqs_off annotation.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reported-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      db3899a6
    • Li Bin's avatar
      arm64: ftrace: fix the comments for ftrace_modify_code · 004ab584
      Li Bin authored
      There is no need to worry about module and __init text disappearing
      case, because that ftrace has a module notifier that is called when
      a module is being unloaded and before the text goes away and this
      code grabs the ftrace_lock mutex and removes the module functions
      from the ftrace list, such that it will no longer do any
      modifications to that module's text, the update to make functions
      be traced or not is done under the ftrace_lock mutex as well.
      And by now, __init section codes should not been modified
      by ftrace, because it is black listed in recordmcount.c and
      ignored by ftrace.
      Suggested-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarLi Bin <huawei.libin@huawei.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      004ab584
    • Li Bin's avatar
      arm64: ftrace: stop using kstop_machine to enable/disable tracing · 81a6a146
      Li Bin authored
      For ftrace on arm64, kstop_machine which is hugely disruptive
      to a running system is not needed to convert nops to ftrace calls
      or back, because that to be modified instrucions, that NOP, B or BL,
      are all safe instructions which called "concurrent modification
      and execution of instructions", that can be executed by one
      thread of execution as they are being modified by another thread
      of execution without requiring explicit synchronization.
      Signed-off-by: default avatarLi Bin <huawei.libin@huawei.com>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      81a6a146
  7. 03 Dec, 2015 2 commits
    • Will Deacon's avatar
      arm64: spinlock: serialise spin_unlock_wait against concurrent lockers · d86b8da0
      Will Deacon authored
      Boqun Feng reported a rather nasty ordering issue with spin_unlock_wait
      on architectures implementing spin_lock with LL/SC sequences and acquire
      semantics:
      
       | CPU 1                   CPU 2                     CPU 3
       | ==================      ====================      ==============
       |                                                   spin_unlock(&lock);
       |                         spin_lock(&lock):
       |                           r1 = *lock; // r1 == 0;
       |                         o = READ_ONCE(object); // reordered here
       | object = NULL;
       | smp_mb();
       | spin_unlock_wait(&lock);
       |                           *lock = 1;
       | smp_mb();
       | o->dead = true;
       |                         if (o) // true
       |                           BUG_ON(o->dead); // true!!
      
      The crux of the problem is that spin_unlock_wait(&lock) can return on
      CPU 1 whilst CPU 2 is in the process of taking the lock. This can be
      resolved by upgrading spin_unlock_wait to a LOCK operation, forcing it
      to serialise against a concurrent locker and giving it acquire semantics
      in the process (although it is not at all clear whether this is needed -
      different callers seem to assume different things about the barrier
      semantics and architectures are similarly disjoint in their
      implementations of the macro).
      
      This patch implements spin_unlock_wait using an LL/SC sequence with
      acquire semantics on arm64. For v8.1 systems with the LSE atomics, the
      exclusive writeback is omitted, since the spin_lock operation is
      indivisible and no intermediate state can be observed.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      d86b8da0
    • Will Deacon's avatar
      arm64: enable HAVE_IRQ_TIME_ACCOUNTING · 24da208d
      Will Deacon authored
      arm64 relies on the arm_arch_timer for sched_clock, so we can select
      HAVE_IRQ_TIME_ACCOUNTING and have the core sched-clock code enable the
      feature at runtime based on the rate.
      Reported-by: default avatarMario Smarduch <m.smarduch@samsung.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      24da208d
  8. 02 Dec, 2015 2 commits
  9. 01 Dec, 2015 3 commits
  10. 30 Nov, 2015 6 commits
  11. 29 Nov, 2015 10 commits
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending · 36511e86
      Linus Torvalds authored
      Pull SCSI target fixes from Nicholas Bellinger:
       - fix tcm-user backend driver expired cmd time processing (agrover)
       - eliminate kref_put_spinlock_irqsave() for I/O completion (bart)
       - fix iscsi login kthread failure case hung task regression (nab)
       - fix COMPARE_AND_WRITE completion use-after-free race (nab)
       - fix COMPARE_AND_WRITE with SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC non zero
         SGL offset data corruption.  (Jan + Doug)
       - fix >= v4.4-rc1 regression for tcm_qla2xxx enable configfs attribute
         (Himanshu + HCH)
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
        target/stat: print full t10_wwn.model buffer
        target: fix COMPARE_AND_WRITE non zero SGL offset data corruption
        qla2xxx: Fix regression introduced by target configFS changes
        kref: Remove kref_put_spinlock_irqsave()
        target: Invoke release_cmd() callback without holding a spinlock
        target: Fix race for SCF_COMPARE_AND_WRITE_POST checking
        iscsi-target: Fix rx_login_comp hang after login failure
        iscsi-target: return -ENOMEM instead of -1 in case of failed kmalloc()
        target/user: Do not set unused fields in tcmu_ops
        target/user: Fix time calc in expired cmd processing
      36511e86
    • Linus Torvalds's avatar
      Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux · 75a29ec1
      Linus Torvalds authored
      Pull thermal management fixes from Zhang Rui:
       "Specifics:
      
       - several fixes and cleanups on Rockchip thermal drivers.
      
       - add the missing support of RK3368 SoCs in Rockchip driver.
      
       - small fixes on of-thermal, power_allocator, rcar driver, IMX, and
         QCOM drivers, and also compilation fixes, on thermal.h, when thermal
         is not selected"
      
      * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
        imx: thermal: use CPU temperature grade info for thresholds
        thermal: fix thermal_zone_bind_cooling_device prototype
        Revert "thermal: qcom_spmi: allow compile test"
        thermal: rcar_thermal: remove redundant operation
        thermal: of-thermal: Reduce log level for message when can't fine thermal zone
        thermal: power_allocator: Use temperature reading from tz
        thermal: rockchip: Support the RK3368 SoCs in thermal driver
        thermal: rockchip: consistently use int for temperatures
        thermal: rockchip: Add the sort mode for adc value increment or decrement
        thermal: rockchip: improve the conversion function
        thermal: rockchip: trivial: fix typo in commit
        thermal: rockchip: better to compatible the driver for different SoCs
        dt-bindings: rockchip-thermal: Support the RK3368 SoCs compatible
      75a29ec1
    • David Disseldorp's avatar
      target/stat: print full t10_wwn.model buffer · 8f903539
      David Disseldorp authored
      Cut 'n paste error saw it only process sizeof(t10_wwn.vendor) characters.
      Signed-off-by: default avatarDavid Disseldorp <ddiss@suse.de>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      8f903539
    • Jan Engelhardt's avatar
      target: fix COMPARE_AND_WRITE non zero SGL offset data corruption · d94e5a61
      Jan Engelhardt authored
      target_core_sbc's compare_and_write functionality suffers from taking
      data at the wrong memory location when writing a CAW request to disk
      when a SGL offset is non-zero.
      
      This can happen with loopback and vhost-scsi fabric drivers when
      SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC is used to map existing user-space
      SGL memory into COMPARE_AND_WRITE READ/WRITE payload buffers.
      
      Given the following sample LIO subtopology,
      
      % targetcli ls /loopback/
      o- loopback ................................. [1 Target]
        o- naa.6001405ebb8df14a ....... [naa.60014059143ed2b3]
          o- luns ................................... [2 LUNs]
            o- lun0 ................ [iblock/ram0 (/dev/ram0)]
            o- lun1 ................ [iblock/ram1 (/dev/ram1)]
      % lsscsi -g
      [3:0:1:0]    disk    LIO-ORG  IBLOCK           4.0   /dev/sdc   /dev/sg3
      [3:0:1:1]    disk    LIO-ORG  IBLOCK           4.0   /dev/sdd   /dev/sg4
      
      the following bug can be observed in Linux 4.3 and 4.4~rc1:
      
      % perl -e 'print chr$_ for 0..255,reverse 0..255' >rand
      % perl -e 'print "\0" x 512' >zero
      % cat rand >/dev/sdd
      % sg_compare_and_write -i rand -D zero --lba 0 /dev/sdd
      % sg_compare_and_write -i zero -D rand --lba 0 /dev/sdd
      Miscompare reported
      % hexdump -Cn 512 /dev/sdd
      00000000  0f 0e 0d 0c 0b 0a 09 08  07 06 05 04 03 02 01 00
      00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
      *
      00000200
      
      Rather than writing all-zeroes as instructed with the -D file, it
      corrupts the data in the sector by splicing some of the original
      bytes in. The page of the first entry of cmd->t_data_sg includes the
      CDB, and sg->offset is set to a position past the CDB. I presume that
      sg->offset is also the right choice to use for subsequent sglist
      members.
      Signed-off-by: default avatarJan Engelhardt <jengelh@netitwork.de>
      Tested-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
      Cc: <stable@vger.kernel.org> # v3.12+
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      d94e5a61
    • Himanshu Madhani's avatar
      qla2xxx: Fix regression introduced by target configFS changes · 3786dc45
      Himanshu Madhani authored
      this patch fixes following regression
      
       # targetcli
       [Errno 13] Permission denied: '/sys/kernel/config/target/qla2xxx/21:00:00:0e:1e:08:c7:20/tpgt_1/enable'
      
      Fixes: 2eafd729 ("target: use per-attribute show and store methods")
      Signed-off-by: default avatarHimanshu Madhani <himanshu.madhani@qlogic.com>
      Signed-off-by: default avatarGiridhar Malavali <giridhar.malavali@qlogic.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      3786dc45
    • Bart Van Assche's avatar
      kref: Remove kref_put_spinlock_irqsave() · 3a66d7dc
      Bart Van Assche authored
      The last user is gone. Hence remove this function.
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Joern Engel <joern@logfs.org>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      3a66d7dc
    • Bart Van Assche's avatar
      target: Invoke release_cmd() callback without holding a spinlock · 9ff9d15e
      Bart Van Assche authored
      This patch fixes the following kernel warning because it avoids that
      IRQs are disabled while ft_release_cmd() is invoked (fc_seq_set_resp()
      invokes spin_unlock_bh()):
      
      WARNING: CPU: 3 PID: 117 at kernel/softirq.c:150 __local_bh_enable_ip+0xaa/0x110()
      Call Trace:
       [<ffffffff814f71eb>] dump_stack+0x4f/0x7b
       [<ffffffff8105e56a>] warn_slowpath_common+0x8a/0xc0
       [<ffffffff8105e65a>] warn_slowpath_null+0x1a/0x20
       [<ffffffff81062b2a>] __local_bh_enable_ip+0xaa/0x110
       [<ffffffff814ff229>] _raw_spin_unlock_bh+0x39/0x40
       [<ffffffffa03a7f94>] fc_seq_set_resp+0xe4/0x100 [libfc]
       [<ffffffffa02e604a>] ft_free_cmd+0x4a/0x90 [tcm_fc]
       [<ffffffffa02e6972>] ft_release_cmd+0x12/0x20 [tcm_fc]
       [<ffffffffa042bd66>] target_release_cmd_kref+0x56/0x90 [target_core_mod]
       [<ffffffffa042caf0>] target_put_sess_cmd+0xc0/0x110 [target_core_mod]
       [<ffffffffa042cb81>] transport_release_cmd+0x41/0x70 [target_core_mod]
       [<ffffffffa042d975>] transport_generic_free_cmd+0x35/0x420 [target_core_mod]
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Acked-by: default avatarJoern Engel <joern@logfs.org>
      Reviewed-by: default avatarAndy Grover <agrover@redhat.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      9ff9d15e
    • Nicholas Bellinger's avatar
      target: Fix race for SCF_COMPARE_AND_WRITE_POST checking · 057085e5
      Nicholas Bellinger authored
      This patch addresses a race + use after free where the first
      stage of COMPARE_AND_WRITE in compare_and_write_callback()
      is rescheduled after the backend sends the secondary WRITE,
      resulting in second stage compare_and_write_post() callback
      completing in target_complete_ok_work() before the first
      can return.
      
      Because current code depends on checking se_cmd->se_cmd_flags
      after return from se_cmd->transport_complete_callback(),
      this results in first stage having SCF_COMPARE_AND_WRITE_POST
      set, which incorrectly falls through into second stage CAW
      processing code, eventually triggering a NULL pointer
      dereference due to use after free.
      
      To address this bug, pass in a new *post_ret parameter into
      se_cmd->transport_complete_callback(), and depend upon this
      value instead of ->se_cmd_flags to determine when to return
      or fall through into ->queue_status() code for CAW.
      
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: <stable@vger.kernel.org> # v3.12+
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      057085e5
    • Nicholas Bellinger's avatar
      iscsi-target: Fix rx_login_comp hang after login failure · ca82c2bd
      Nicholas Bellinger authored
      This patch addresses a case where iscsi_target_do_tx_login_io()
      fails sending the last login response PDU, after the RX/TX
      threads have already been started.
      
      The case centers around iscsi_target_rx_thread() not invoking
      allow_signal(SIGINT) before the send_sig(SIGINT, ...) occurs
      from the failure path, resulting in RX thread hanging
      indefinately on iscsi_conn->rx_login_comp.
      
      Note this bug is a regression introduced by:
      
        commit e5419865
        Author: Nicholas Bellinger <nab@linux-iscsi.org>
        Date:   Wed Jul 22 23:14:19 2015 -0700
      
            iscsi-target: Fix iscsit_start_kthreads failure OOPs
      
      To address this bug, complete ->rx_login_complete for good
      measure in the failure path, and immediately return from
      RX thread context if connection state did not actually reach
      full feature phase (TARG_CONN_STATE_LOGGED_IN).
      
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: <stable@vger.kernel.org> # v3.10+
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      ca82c2bd
    • Luis de Bethencourt's avatar
      iscsi-target: return -ENOMEM instead of -1 in case of failed kmalloc() · 82a819e8
      Luis de Bethencourt authored
      Smatch complains about returning hard coded error codes, silence this
      warning.
      
      drivers/target/iscsi/iscsi_target_parameters.c:211
         iscsi_create_default_params() warn: returning -1 instead of -ENOMEM is sloppy
      Signed-off-by: default avatarLuis de Bethencourt <luisbg@osg.samsung.com>
      Reviewed-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      82a819e8