HID: sensor-hub: make dyn_callback_lock IRQ-safe

dyn_callback_lock is being taken from IRQ context through hid_irq_in() ->
hid_input_report() -> sensor_hub_raw_event() -> sensor_hub_get_callback(),
therefore anyone else acquiring it needs to disable IRQs to disable deadlocks.

Reported-by: Alexander Holler <holler@ahsoftware.de>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Reported-by: Reyad Attiyat <reyad.attiyat@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: sensor-hub: introduce Kconfig dependency on IOMEM

When NO_IOMEM is enabled (e.g. score architecture), some drivers which
need HAS_IOMEM need notice about it, or it will report related warning:

  warning: (GPIO_SCH && GPIO_ICH && GPIO_VX855 && GPIO_RDC321X && IE6XX_WDT && RADIO_WL1273 && HID_SENSOR_HUB && MFD_NVEC) selects MFD_CORE which has unmet direct dependencies (HAS_IOMEM)

Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: rmi: Protect PM-only functions by #ifdef CONFIG_PM

If CONFIG_PM=n:

drivers/hid/hid-rmi.c:432: warning: ‘rmi_post_reset’ defined but not used
drivers/hid/hid-rmi.c:437: warning: ‘rmi_post_resume’ defined but not used

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
pinctrl: sunxi: Fix potential null pointer dereference

kzalloc can fail. Add a null check to avoid null pointer
dereference error while accessing the pointer later.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
scsi_error: fix invalid setting of host byte

After scsi_try_to_abort_cmd returns, the eh_abort_handler may have
already found that the command has completed in the device, causing
the host_byte to be nonzero (e.g. it could be DID_ABORT).  When
this happens, ORing DID_TIME_OUT into the host byte will corrupt
the result field and initiate an unwanted command retry.

Fix this by using set_host_byte instead, following the model of
commit 2082ebc45af9c9c648383b8cde0dc1948eadbf31.

Cc: stable@vger.kernel.org
Signed-off-by: Ulrich Obergfell <uobergfe@redhat.com>
[Fix all instances according to review comments. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
scsi_error: set DID_TIME_OUT correctly

Any callbacks in scsi_timeout_out() might return BLK_EH_RESET_TIMER,
in which case we should leave the result alone and not set
DID_TIME_OUT, as the command didn't actually timeout.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
be2iscsi: add an missing goto in error path

a jump to 'free_memory' is apparently missing

Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: Christoph Hellwig <hch@lst.de>
be2iscsi: remove potential junk pointer free

commit 0e7c60c [SCSI] be2iscsi: fix memory leak in error path
fixed an potential junk pointer free if  mgmt_get_if_info() returned an error

fix it on one more place

Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: Christoph Hellwig <hch@lst.de>
MAINTAINERS: Update LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI) maintainers Email IDs

Updating maintainers Email Ids for the entry LSILOGIC MPT FUSION DRIVERS in
MAINTAINERS file

Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@avagotech.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
pm8001: Fix potential null pointer dereference and memory leak.

The pm8001_get_phy_settings_info() function does not check
the kzalloc() return value and does not free the allocated memory.

Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Acked-by: Suresh Thiagarajan <Suresh.Thiagarajan@pmcs.com>
Acked-by: Jack Wang <xjtuwjp@gmail.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
fc: ensure scan_work isn't active when freeing fc_rport

debugfs caught this:
WARNING: at lib/debugobjects.c:260 debug_print_object+0x83/0xa0()
ODEBUG: free active (active state 0) object type: work_struct
hint: fc_scsi_scan_rport+0x0/0xd0 [scsi_transport_fc]
 CPU: 1 PID: 184 Comm: kworker/1:1 Tainted: G        W
--------------   3.10.0-123.el7.x86_64.debug #1
Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
Workqueue: fc_wq_5 fc_rport_final_delete [scsi_transport_fc]
Call Trace:
[<ffffffff8169efec>] dump_stack+0x19/0x1b
[<ffffffff8106cbd1>] warn_slowpath_common+0x61/0x80
[<ffffffff8106cc4c>] warn_slowpath_fmt+0x5c/0x80
[<ffffffff8133e003>] debug_print_object+0x83/0xa0
[<ffffffffa04e2f40>] ? fc_parse_wwn+0x100/0x100

[<ffffffff8133f23b>] debug_check_no_obj_freed+0x22b/0x270
[<ffffffffa04e127e>] ? fc_rport_dev_release+0x1e/0x30
[<ffffffff811db3e9>] kfree+0xd9/0x2d0
[<ffffffffa04e127e>] fc_rport_dev_release+0x1e/0x30
[<ffffffff81428032>] device_release+0x32/0xa0
[<ffffffff8132701e>] kobject_release+0x7e/0x1b0
[<ffffffff81326ed8>] kobject_put+0x28/0x60
[<ffffffff81428397>] put_device+0x17/0x20
[<ffffffffa04e5025>] fc_rport_final_delete+0x165/0x210
[<ffffffff810959b0>] process_one_work+0x220/0x710
[<ffffffff81095944>] ? process_one_work+0x1b4/0x710
[<ffffffff81095fbb>] worker_thread+0x11b/0x3a0
[<ffffffff81095ea0>] ? process_one_work+0x710/0x710
[<ffffffff8109e0cd>] kthread+0xed/0x100
[<ffffffff8109dfe0>] ? insert_kthread_work+0x80/0x80
[<ffffffff816b2fec>] ret_from_fork+0x7c/0xb0
[<ffffffff8109dfe0>] ? insert_kthread_work+0x80/0x80

Seems to be because the scan_work work_struct might be active when the housing
fc_rport struct gets freed.  Ensure that we cancel it prior to freeing the rport

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Vasu Dev <vasu.dev@intel.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
bnx2fc: do not scan uninitialized lists in case of error.

In case of of error, the bnx2fc_cmd_mgr_alloc() function will call
the bnx2fc_cmd_mgr_free() to perform the cleanup.
The problem is that in one case the latter may try to scan
some not-yet initialized lists, resulting in a kernel panic.

This patch prevents this from happening by freeing the lists
before calling bnx2fc_cmd_mgr_free().

Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Acked-by: Eddie Wai <eddie.wai@broadcom.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
bnx2fc: Improve stats update mechanism

Recently had this warning reported:

[  290.489047] Call Trace:
[  290.489053]  [<ffffffff8169efec>] dump_stack+0x19/0x1b
[  290.489055]  [<ffffffff810ac7a9>] __might_sleep+0x179/0x230
[  290.489057]  [<ffffffff816a4ad5>] mutex_lock_nested+0x55/0x520
[  290.489061]  [<ffffffffa01b9905>] ? bnx2fc_l2_rcv_thread+0xc5/0x4c0 [bnx2fc]
[  290.489065]  [<ffffffffa0174c1a>] fc_vport_id_lookup+0x3a/0xa0 [libfc]
[  290.489068]  [<ffffffffa01b9a6c>] bnx2fc_l2_rcv_thread+0x22c/0x4c0 [bnx2fc]
[  290.489070]  [<ffffffffa01b9840>] ? bnx2fc_vport_destroy+0x110/0x110 [bnx2fc]
[  290.489073]  [<ffffffff8109e0cd>] kthread+0xed/0x100
[  290.489075]  [<ffffffff8109dfe0>] ? insert_kthread_work+0x80/0x80
[  290.489077]  [<ffffffff816b2fec>] ret_from_fork+0x7c/0xb0
[  290.489078]  [<ffffffff8109dfe0>] ? insert_kthread_work+0x80/0x80

Its due to the fact that we call a potentially sleeping function from the bnx2fc
rcv path with preemption disabled (via the get_cpu call embedded in the per-cpu
variable stats lookup in bnx2fc_l2_rcv_thread.

Easy enough fix, we can just move the stats collection later in the function
where we are sure we won't preempt or sleep.  This also allows us to not have to
enable pre-emption when doing a per-cpu lookup, since we're certain not to get
rescheduled.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by:  Eddie Wai <eddie.wai@broadcom.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
qla2xxx: Fix sparse warning in qla_target.c.

Signed-off-by: Quinn Tran <quinn.tran@qlogic.com>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
ibmvscsi: Abort init sequence during error recovery

If a CRQ reset is triggered for some reason while in the middle
of performing VSCSI adapter initialization, we don't want to
call the done function for the initialization MAD commands as
this will only result in two threads attempting initialization
at the same time, resulting in failures.

Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Acked-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Christoph Hellwig <hch@lst.de>
ibmvscsi: Add memory barriers for send / receive

Add a memory barrier prior to sending a new command to the VIOS
to ensure the VIOS does not receive stale data in the command buffer.
Also add a memory barrier when processing the CRQ for completed commands.

Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Acked-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Christoph Hellwig <hch@lst.de>
virtio-scsi: avoid cancelling uninitialized work items

Calling the workqueue interface on uninitialized work items isn't a
good idea even if they're zeroed. It's not failing catastrophically only
through happy accidents.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Christoph Hellwig <hch@lst.de>
virtio-scsi: fix various bad behavior on aborted requests

Even though the virtio-scsi spec guarantees that all requests related
to the TMF will have been completed by the time the TMF itself completes,
the request queue's callback might not have run yet.  This causes requests
to be completed more than once, and as a result triggers a variety of
BUGs or oopses.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Venkatesh Srinivas <venkateshs@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Christoph Hellwig <hch@lst.de>
MAINTAINERS: Update Eduardo Valentin's email address

Eduardo TI address is bouncing, but it looks like he's still
contributing via his Gmail address.

Cc: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
of: Check for phys_addr_t overflows in early_init_dt_add_memory_arch

The common early_init_dt_add_memory_arch takes the base and size
of a memory region as u64 types. The function never checks if
the base and size can actually fit in a phys_addr_t which may
be smaller than 64-bits. This may result in incorrect memory
being passed to memblock_add if the memory falls outside the
range of phys_addr_t. Add range checks for the base and size if
phys_addr_t is smaller than u64.

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Grant Likely <grant.likely@linaro.org>