Re: ata: BUG in ata_sff_hsm_move

2016-02-01 Thread Dmitry Vyukov
On Fri, Jan 29, 2016 at 9:23 PM, Tejun Heo wrote: > Hello, > > On Fri, Jan 29, 2016 at 02:40:33PM +0100, Dmitry Vyukov wrote: >> It now deadlocks at this stack. It is probably not OK to call >> ata_sff_hsm_move holding the spinlock. > > Yeah, the locking is pretty messed up with the polling path.

Re: ata: BUG in ata_sff_hsm_move

2016-02-01 Thread Dmitry Vyukov
On Fri, Jan 29, 2016 at 9:23 PM, Tejun Heo wrote: > Hello, > > On Fri, Jan 29, 2016 at 02:40:33PM +0100, Dmitry Vyukov wrote: >> It now deadlocks at this stack. It is probably not OK to call >> ata_sff_hsm_move holding the spinlock. > > Yeah, the locking is pretty messed up with

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread Tejun Heo
Hello, David. On Fri, Jan 29, 2016 at 12:14:42PM -0600, David Milburn wrote: > Can ata_sff_hsm_move grab the lock and save off the task_state, > like this patch? It's not just the task_state. Everything the polling path is doing is dangerous. It's all pretty confused. Thanks. -- tejun

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread Tejun Heo
Hello, On Fri, Jan 29, 2016 at 02:40:33PM +0100, Dmitry Vyukov wrote: > It now deadlocks at this stack. It is probably not OK to call > ata_sff_hsm_move holding the spinlock. Yeah, the locking is pretty messed up with the polling path. Can you please try the following? Thanks. diff --git

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread David Milburn
Hi Tejun, Can ata_sff_hsm_move grab the lock and save off the task_state, like this patch? Thanks, David On Fri, Jan 29, 2016 at 02:40:33PM +0100, Dmitry Vyukov wrote: > On Fri, Jan 29, 2016 at 2:18 PM, Dmitry Vyukov wrote: > > On Fri, Jan 29, 2016 at 1:23 PM, Tejun Heo wrote: > >> Hello,

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread Dmitry Vyukov
On Fri, Jan 29, 2016 at 2:18 PM, Dmitry Vyukov wrote: > On Fri, Jan 29, 2016 at 1:23 PM, Tejun Heo wrote: >> Hello, Dmitry. >> >> On Fri, Jan 29, 2016 at 12:59:49PM +0100, Dmitry Vyukov wrote: >>> > Hmmm... the port interrupt handler checks for IDLE before calling into >>> > hsm_move, so the

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread Dmitry Vyukov
On Fri, Jan 29, 2016 at 1:23 PM, Tejun Heo wrote: > Hello, Dmitry. > > On Fri, Jan 29, 2016 at 12:59:49PM +0100, Dmitry Vyukov wrote: >> > Hmmm... the port interrupt handler checks for IDLE before calling into >> > hsm_move, so the only explanation would be that something is resetting >> > it to

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread Tejun Heo
Hello, Dmitry. On Fri, Jan 29, 2016 at 12:59:49PM +0100, Dmitry Vyukov wrote: > > Hmmm... the port interrupt handler checks for IDLE before calling into > > hsm_move, so the only explanation would be that something is resetting > > it to IDLE inbetween. ce7514526742 ("libata: prevent HSM state

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread Dmitry Vyukov
On Fri, Jan 29, 2016 at 12:52 PM, Tejun Heo wrote: > Hello, Dmitry. > > On Thu, Jan 28, 2016 at 12:35:43PM +0100, Dmitry Vyukov wrote: >> Hello, >> >> I episodically hit the following BUG while running syzkaller fuzzer: >> >> ata2: protocol 2 task_state 0 (dev_stat 0x41) >> [ cut here

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread Tejun Heo
Hello, Dmitry. On Thu, Jan 28, 2016 at 12:35:43PM +0100, Dmitry Vyukov wrote: > Hello, > > I episodically hit the following BUG while running syzkaller fuzzer: > > ata2: protocol 2 task_state 0 (dev_stat 0x41) > [ cut here ] > kernel BUG at drivers/ata/libata-sff.c:1302!

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread Dmitry Vyukov
On Fri, Jan 29, 2016 at 2:18 PM, Dmitry Vyukov wrote: > On Fri, Jan 29, 2016 at 1:23 PM, Tejun Heo wrote: >> Hello, Dmitry. >> >> On Fri, Jan 29, 2016 at 12:59:49PM +0100, Dmitry Vyukov wrote: >>> > Hmmm... the port interrupt handler checks for IDLE before

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread Dmitry Vyukov
On Fri, Jan 29, 2016 at 1:23 PM, Tejun Heo wrote: > Hello, Dmitry. > > On Fri, Jan 29, 2016 at 12:59:49PM +0100, Dmitry Vyukov wrote: >> > Hmmm... the port interrupt handler checks for IDLE before calling into >> > hsm_move, so the only explanation would be that something is

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread Tejun Heo
Hello, Dmitry. On Thu, Jan 28, 2016 at 12:35:43PM +0100, Dmitry Vyukov wrote: > Hello, > > I episodically hit the following BUG while running syzkaller fuzzer: > > ata2: protocol 2 task_state 0 (dev_stat 0x41) > [ cut here ] > kernel BUG at drivers/ata/libata-sff.c:1302!

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread Dmitry Vyukov
On Fri, Jan 29, 2016 at 12:52 PM, Tejun Heo wrote: > Hello, Dmitry. > > On Thu, Jan 28, 2016 at 12:35:43PM +0100, Dmitry Vyukov wrote: >> Hello, >> >> I episodically hit the following BUG while running syzkaller fuzzer: >> >> ata2: protocol 2 task_state 0 (dev_stat 0x41) >>

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread Tejun Heo
Hello, Dmitry. On Fri, Jan 29, 2016 at 12:59:49PM +0100, Dmitry Vyukov wrote: > > Hmmm... the port interrupt handler checks for IDLE before calling into > > hsm_move, so the only explanation would be that something is resetting > > it to IDLE inbetween. ce7514526742 ("libata: prevent HSM state

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread David Milburn
Hi Tejun, Can ata_sff_hsm_move grab the lock and save off the task_state, like this patch? Thanks, David On Fri, Jan 29, 2016 at 02:40:33PM +0100, Dmitry Vyukov wrote: > On Fri, Jan 29, 2016 at 2:18 PM, Dmitry Vyukov wrote: > > On Fri, Jan 29, 2016 at 1:23 PM, Tejun Heo

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread Tejun Heo
Hello, On Fri, Jan 29, 2016 at 02:40:33PM +0100, Dmitry Vyukov wrote: > It now deadlocks at this stack. It is probably not OK to call > ata_sff_hsm_move holding the spinlock. Yeah, the locking is pretty messed up with the polling path. Can you please try the following? Thanks. diff --git

Re: ata: BUG in ata_sff_hsm_move

2016-01-29 Thread Tejun Heo
Hello, David. On Fri, Jan 29, 2016 at 12:14:42PM -0600, David Milburn wrote: > Can ata_sff_hsm_move grab the lock and save off the task_state, > like this patch? It's not just the task_state. Everything the polling path is doing is dangerous. It's all pretty confused. Thanks. -- tejun

ata: BUG in ata_sff_hsm_move

2016-01-28 Thread Dmitry Vyukov
Hello, I episodically hit the following BUG while running syzkaller fuzzer: ata2: protocol 2 task_state 0 (dev_stat 0x41) [ cut here ] kernel BUG at drivers/ata/libata-sff.c:1302! invalid opcode: [#1] SMP DEBUG_PAGEALLOC KASAN Modules linked in: CPU: 1 PID: 10679

ata: BUG in ata_sff_hsm_move

2016-01-28 Thread Dmitry Vyukov
Hello, I episodically hit the following BUG while running syzkaller fuzzer: ata2: protocol 2 task_state 0 (dev_stat 0x41) [ cut here ] kernel BUG at drivers/ata/libata-sff.c:1302! invalid opcode: [#1] SMP DEBUG_PAGEALLOC KASAN Modules linked in: CPU: 1 PID: 10679