user/sven/linux.git/drivers/ata, branch v3.18.31

Adding Intel Lewisburg device IDs for SATA

2016-03-08T02:29:57Z

[ Upstream commit f5bdd66c705484b4bc77eb914be15c1b7881fae7 ] This patch complements the list of device IDs previously added for lewisburg sata. Signed-off-by: Alexandra Yates Signed-off-by: Tejun Heo Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin

ahci: Order SATA device IDs for codename Lewisburg

2016-03-08T02:29:48Z

[ Upstream commit 4d92f0099a06ef0e36c7673f7c090f1a448b2d1b ] 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: Sasha Levin

libata: fix HDIO_GET_32BIT ioctl

2016-03-08T02:13:02Z

[ Upstream commit 287e6611ab1eac76c2c5ebf6e345e04c80ca9c61 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin

ahci: Intel DNV device IDs SATA

2016-03-04T15:18:40Z

[ Upstream commit 342decff2b846b46fa61eb5ee40986fab79a9a32 ] Adding Intel codename DNV platform device IDs for SATA. Signed-off-by: Alexandra Yates Signed-off-by: Tejun Heo Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin

libata: fix sff host state machine locking while polling

2016-03-02T20:18:54Z

[ Upstream commit 8eee1d3ed5b6fc8e14389567c9a6f53f82bb7224 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin

libata: disable forced PORTS_IMPL for >= AHCI 1.3

2016-02-27T23:28:28Z

[ Upstream commit 566d1827df2ef0cbe921d3d6946ac3007b1a6938 ] 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 Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin

Add factory recertified Crucial M500s to blacklist

2015-09-22T19:20:20Z

[ Upstream commit 7a7184b01aa9deb86df661c6f7cbcf69a95b728c ] The Crucial M500 is known to have issues with queued TRIM commands, the factory recertified SSDs use a different model number naming convention which causes them to get ignored by the blacklist. The new naming convention boils down to: s/Crucial_/FC/ Signed-off-by: Guillermo A. Amaral Signed-off-by: Tejun Heo Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin

libata: Do not blacklist M510DC

2015-08-27T17:26:12Z

[ Upstream commit 9051bd393cf25e76dfb45409792719a854661500 ] A new Micron drive was just announced, once again recycling the first part of the model string. Add an underscore to the M510/M550 pattern to avoid picking up the new DC drive. Signed-off-by: Martin K. Petersen Cc: Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin

libata: force disable trim for SuperSSpeed S238

2015-08-27T17:26:12Z

[ Upstream commit cda57b1b05cf7b8b99ab4b732bea0b05b6c015cc ] This device loses blocks, often the partition table area, on trim. Disable TRIM. http://pcengines.ch/msata16a.htm Signed-off-by: Arne Fitzenreiter Signed-off-by: Tejun Heo Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin

libata: add ATA_HORKAGE_NOTRIM

2015-08-27T17:26:11Z

[ Upstream commit 71d126fd28de2d4d9b7b2088dbccd7ca62fad6e0 ] Some devices lose data on TRIM whether queued or not. This patch adds a horkage to disable TRIM. tj: Collapsed unnecessary if() nesting. Signed-off-by: Arne Fitzenreiter Signed-off-by: Tejun Heo Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin