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.
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
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
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
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,
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
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
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
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
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!
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
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
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!
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)
>>
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
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
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
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
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
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
20 matches
Mail list logo