linux-stable.git/drivers/ata, branch v3.2.83

ata: sata_dwc_460ex: remove incorrect locking

2016-08-22T21:37:10+00:00

commit 55e610cdd28c0ad3dce0652030c0296d549673f3 upstream.

This lock is already taken in ata_scsi_queuecmd() a few levels up the
call stack so attempting to take it here is an error.  Moreover, it is
pointless in the first place since it only protects a single, atomic
assignment.

Enabling lock debugging gives the following output:

=============================================
[ INFO: possible recursive locking detected ]
4.4.0-rc5+ #189 Not tainted
---------------------------------------------
kworker/u2:3/37 is trying to acquire lock:
 (&(&host->lock)->rlock){-.-...}, at: [<90283294>] sata_dwc_exec_command_by_tag.constprop.14+0x44/0x8c

but task is already holding lock:
 (&(&host->lock)->rlock){-.-...}, at: [<902761ac>] ata_scsi_queuecmd+0x2c/0x330

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&host->lock)->rlock);
  lock(&(&host->lock)->rlock);

 *** DEADLOCK ***
 May be due to missing lock nesting notation

4 locks held by kworker/u2:3/37:
 #0:  ("events_unbound"){.+.+.+}, at: [<9003a0a4>] process_one_work+0x12c/0x430
 #1:  ((&entry->work)){+.+.+.}, at: [<9003a0a4>] process_one_work+0x12c/0x430
 #2:  (&bdev->bd_mutex){+.+.+.}, at: [<9011fd54>] __blkdev_get+0x50/0x380
 #3:  (&(&host->lock)->rlock){-.-...}, at: [<902761ac>] ata_scsi_queuecmd+0x2c/0x330

stack backtrace:
CPU: 0 PID: 37 Comm: kworker/u2:3 Not tainted 4.4.0-rc5+ #189
Workqueue: events_unbound async_run_entry_fn
Stack : 90b38e30 00000021 00000003 9b2a6040 00000000 9005f3f0 904fc8dc 00000025
        906b96e4 00000000 90528648 9b3336c4 904fc8dc 9009bf18 00000002 00000004
        00000000 00000000 9b3336c4 9b3336e4 904fc8dc 9003d074 00000000 90500000
        9005e738 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        6e657665 755f7374 756f626e 0000646e 00000000 00000000 9b00ca00 9b025000
          ...
Call Trace:
[<90009d6c>] show_stack+0x88/0xa4
[<90057744>] __lock_acquire+0x1ce8/0x2154
[<900583e4>] lock_acquire+0x64/0x8c
[<9045ff10>] _raw_spin_lock_irqsave+0x54/0x78
[<90283294>] sata_dwc_exec_command_by_tag.constprop.14+0x44/0x8c
[<90283484>] sata_dwc_qc_issue+0x1a8/0x24c
[<9026b39c>] ata_qc_issue+0x1f0/0x410
[<90273c6c>] ata_scsi_translate+0xb4/0x200
[<90276234>] ata_scsi_queuecmd+0xb4/0x330
[<9025800c>] scsi_dispatch_cmd+0xd0/0x128
[<90259934>] scsi_request_fn+0x58c/0x638
[<901a3e50>] __blk_run_queue+0x40/0x5c
[<901a83d4>] blk_queue_bio+0x27c/0x28c
[<901a5914>] generic_make_request+0xf0/0x188
[<901a5a54>] submit_bio+0xa8/0x194
[<9011adcc>] submit_bh_wbc.isra.23+0x15c/0x17c
[<9011c908>] block_read_full_page+0x3e4/0x428
[<9009e2e0>] do_read_cache_page+0xac/0x210
[<9009fd90>] read_cache_page+0x18/0x24
[<901bbd18>] read_dev_sector+0x38/0xb0
[<901bd174>] msdos_partition+0xb4/0x5c0
[<901bcb8c>] check_partition+0x140/0x274
[<901bba60>] rescan_partitions+0xa0/0x2b0
[<9011ff68>] __blkdev_get+0x264/0x380
[<901201ac>] blkdev_get+0x128/0x36c
[<901b9378>] add_disk+0x3c0/0x4bc
[<90268268>] sd_probe_async+0x100/0x224
[<90043a44>] async_run_entry_fn+0x50/0x124
[<9003a11c>] process_one_work+0x1a4/0x430
[<9003a4f4>] worker_thread+0x14c/0x4fc
[<900408f4>] kthread+0xd0/0xe8
[<90004338>] ret_from_kernel_thread+0x14/0x1c

Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex")
Tested-by: Christian Lamparter 
Signed-off-by: Mans Rullgard 
Signed-off-by: Tejun Heo 
Signed-off-by: Ben Hutchings

libahci: save port map for forced port map

2016-06-15T20:28:11+00:00

commit 2fd0f46cb1b82587c7ae4a616d69057fb9bd0af7 upstream.

In usecases where force_port_map is used saved_port_map is never set,
resulting in not programming the PORTS_IMPL register as part of initial
config. This patch fixes this by setting it to port_map even in case
where force_port_map is used, making it more inline with other parts of
the code.

Fixes: 566d1827df2e ("libata: disable forced PORTS_IMPL for >= AHCI 1.3")
Signed-off-by: Srinivas Kandagatla 
Acked-by: Tejun Heo 
Reviewed-by: Andy Gross 
Signed-off-by: Tejun Heo 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

Adding Intel Lewisburg device IDs for SATA

2016-04-01T00:54:34+00:00

commit f5bdd66c705484b4bc77eb914be15c1b7881fae7 upstream.

This patch complements the list of device IDs previously
added for lewisburg sata.

Signed-off-by: Alexandra Yates 
Signed-off-by: Tejun Heo 
Signed-off-by: Ben Hutchings

libata: fix HDIO_GET_32BIT ioctl

2016-04-01T00:54:32+00:00

commit 287e6611ab1eac76c2c5ebf6e345e04c80ca9c61 upstream.

As reported by Soohoon Lee, the HDIO_GET_32BIT ioctl does not
work correctly in compat mode with libata.

I have investigated the issue further and found multiple problems
that all appeared with the same commit that originally introduced
HDIO_GET_32BIT handling in libata back in linux-2.6.8 and presumably
also linux-2.4, as the code uses "copy_to_user(arg, &val, 1)" to copy
a 'long' variable containing either 0 or 1 to user space.

The problems with this are:

* On big-endian machines, this will always write a zero because it
  stores the wrong byte into user space.

* In compat mode, the upper three bytes of the variable are updated
  by the compat_hdio_ioctl() function, but they now contain
  uninitialized stack data.

* The hdparm tool calling this ioctl uses a 'static long' variable
  to store the result. This means at least the upper bytes are
  initialized to zero, but calling another ioctl like HDIO_GET_MULTCOUNT
  would fill them with data that remains stale when the low byte
  is overwritten. Fortunately libata doesn't implement any of the
  affected ioctl commands, so this would only happen when we query
  both an IDE and an ATA device in the same command such as
  "hdparm -N -c /dev/hda /dev/sda"

* The libata code for unknown reasons started using ATA_IOC_GET_IO32
  and ATA_IOC_SET_IO32 as aliases for HDIO_GET_32BIT and HDIO_SET_32BIT,
  while the ioctl commands that were added later use the normal
  HDIO_* names. This is harmless but rather confusing.

This addresses all four issues by changing the code to use put_user()
on an 'unsigned long' variable in HDIO_GET_32BIT, like the IDE subsystem
does, and by clarifying the names of the ioctl commands.

Signed-off-by: Arnd Bergmann 
Reported-by: Soohoon Lee 
Tested-by: Soohoon Lee 
Signed-off-by: Tejun Heo 
Signed-off-by: Ben Hutchings

ahci: Intel DNV device IDs SATA

2016-02-27T14:28:48+00:00

commit 342decff2b846b46fa61eb5ee40986fab79a9a32 upstream.

Adding Intel codename DNV platform device IDs for SATA.

Signed-off-by: Alexandra Yates 
Signed-off-by: Tejun Heo 
Signed-off-by: Ben Hutchings

libata: fix sff host state machine locking while polling

2016-02-27T14:28:46+00:00

commit 8eee1d3ed5b6fc8e14389567c9a6f53f82bb7224 upstream.

The bulk of ATA host state machine is implemented by
ata_sff_hsm_move().  The function is called from either the interrupt
handler or, if polling, a work item.  Unlike from the interrupt path,
the polling path calls the function without holding the host lock and
ata_sff_hsm_move() selectively grabs the lock.

This is completely broken.  If an IRQ triggers while polling is in
progress, the two can easily race and end up accessing the hardware
and updating state machine state at the same time.  This can put the
state machine in an illegal state and lead to a crash like the
following.

  kernel BUG at drivers/ata/libata-sff.c:1302!
  invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
  Modules linked in:
  CPU: 1 PID: 10679 Comm: syz-executor Not tainted 4.5.0-rc1+ #300
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  task: ffff88002bd00000 ti: ffff88002e048000 task.ti: ffff88002e048000
  RIP: 0010:[]  [] ata_sff_hsm_move+0x619/0x1c60
  ...
  Call Trace:
   
   [] __ata_sff_port_intr+0x1e1/0x3a0 drivers/ata/libata-sff.c:1584
   [] ata_bmdma_port_intr+0x71/0x400 drivers/ata/libata-sff.c:2877
   [<     inline     >] __ata_sff_interrupt drivers/ata/libata-sff.c:1629
   [] ata_bmdma_interrupt+0x253/0x580 drivers/ata/libata-sff.c:2902
   [] handle_irq_event_percpu+0x108/0x7e0 kernel/irq/handle.c:157
   [] handle_irq_event+0xa7/0x140 kernel/irq/handle.c:205
   [] handle_edge_irq+0x1e3/0x8d0 kernel/irq/chip.c:623
   [<     inline     >] generic_handle_irq_desc include/linux/irqdesc.h:146
   [] handle_irq+0x10c/0x2a0 arch/x86/kernel/irq_64.c:78
   [] do_IRQ+0x7d/0x1a0 arch/x86/kernel/irq.c:240
   [] common_interrupt+0x8c/0x8c arch/x86/entry/entry_64.S:520
   
   [<     inline     >] rcu_lock_acquire include/linux/rcupdate.h:490
   [<     inline     >] rcu_read_lock include/linux/rcupdate.h:874
   [] filemap_map_pages+0x131/0xba0 mm/filemap.c:2145
   [<     inline     >] do_fault_around mm/memory.c:2943
   [<     inline     >] do_read_fault mm/memory.c:2962
   [<     inline     >] do_fault mm/memory.c:3133
   [<     inline     >] handle_pte_fault mm/memory.c:3308
   [<     inline     >] __handle_mm_fault mm/memory.c:3418
   [] handle_mm_fault+0x2516/0x49a0 mm/memory.c:3447
   [] __do_page_fault+0x376/0x960 arch/x86/mm/fault.c:1238
   [] trace_do_page_fault+0xe8/0x420 arch/x86/mm/fault.c:1331
   [] do_async_page_fault+0x14/0xd0 arch/x86/kernel/kvm.c:264
   [] async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:986

Fix it by ensuring that the polling path is holding the host lock
before entering ata_sff_hsm_move() so that all hardware accesses and
state updates are performed under the host lock.

Signed-off-by: Tejun Heo 
Reported-and-tested-by: Dmitry Vyukov 
Link: http://lkml.kernel.org/g/CACT4Y+b_JsOxJu2EZyEf+mOXORc_zid5V1-pLZSroJVxyWdSpw@mail.gmail.com
Signed-off-by: Ben Hutchings

libata: disable forced PORTS_IMPL for >= AHCI 1.3

2016-02-27T14:28:44+00:00

commit 566d1827df2ef0cbe921d3d6946ac3007b1a6938 upstream.

Some early controllers incorrectly reported zero ports in PORTS_IMPL
register and the ahci driver fabricates PORTS_IMPL from the number of
ports in those cases.  This hasn't mattered but with the new nvme
controllers there are cases where zero PORTS_IMPL is valid and should
be honored.

Disable the workaround for >= AHCI 1.3.

Signed-off-by: Tejun Heo 
Reported-by: Andy Lutomirski 
Link: http://lkml.kernel.org/g/CALCETrU7yMvXEDhjAUShoHEhDwifJGapdw--BKxsP0jmjKGmRw@mail.gmail.com
Cc: Sergei Shtylyov 
Signed-off-by: Ben Hutchings

ahci: Order SATA device IDs for codename Lewisburg

2016-01-22T21:40:11+00:00

commit 4d92f0099a06ef0e36c7673f7c090f1a448b2d1b upstream.

This change was to preserve the ascending order of device IDs.
There was an exception with the first two Lewisburg device IDs to
keep all device IDs of the same kind grouped by code name.

Signed-off-by: Alexandra Yates 
signed-off-by: Tejun Heo 
Signed-off-by: Ben Hutchings

ahci: Add Device ID for Intel Sunrise Point PCH

2016-01-22T21:40:10+00:00

commit c5967b79ecabe2baca40658d9073e28b30d7f6cf upstream.

This patch adds missing AHCI RAID SATA Device IDs for the Intel Sunrise
Point PCH.

Signed-off-by: Nanda Kishore Chinna 
Signed-off-by: Charles Rose 
Signed-off-by: Tejun Heo 
Signed-off-by: Ben Hutchings

ahci: add new Intel device IDs

2016-01-22T21:40:10+00:00

commit 56e74338a535cbcc2f2da08b1ea1a92920194364 upstream.

Adding Intel codename Lewisburg platform device IDs for SATA.

Signed-off-by: Alexandra Yates 
Signed-off-by: Tejun Heo 
Signed-off-by: Ben Hutchings