Re: [BUG] IB/hfi1: might sleep under spinlock in hfi1_ioctl()

2015-11-10 Thread ira.weiny
On Fri, Oct 30, 2015 at 07:58:18PM -0400, ira. weiny wrote: > On Sat, Oct 31, 2015 at 12:32:29AM +0300, Alexey Khoroshilov wrote: > > Hello, > > > > hfi1_ioctl() contains many calls to might sleep functions with > > dd->hfi1_snoop.snoop_lock spinlock held (for example, access_ok, > >

Re: [BUG] IB/hfi1: might sleep under spinlock in hfi1_ioctl()

2015-11-10 Thread ira.weiny
On Fri, Oct 30, 2015 at 07:58:18PM -0400, ira. weiny wrote: > On Sat, Oct 31, 2015 at 12:32:29AM +0300, Alexey Khoroshilov wrote: > > Hello, > > > > hfi1_ioctl() contains many calls to might sleep functions with > > dd->hfi1_snoop.snoop_lock spinlock held (for example, access_ok, > >

Re: [BUG] IB/hfi1: might sleep under spinlock in hfi1_ioctl()

2015-10-30 Thread ira.weiny
On Sat, Oct 31, 2015 at 12:32:29AM +0300, Alexey Khoroshilov wrote: > Hello, > > hfi1_ioctl() contains many calls to might sleep functions with > dd->hfi1_snoop.snoop_lock spinlock held (for example, access_ok, > copy_from_user, kzalloc(GFP_KERNEL), etc.). > > Should dd->hfi1_snoop.snoop_lock be

[BUG] IB/hfi1: might sleep under spinlock in hfi1_ioctl()

2015-10-30 Thread Alexey Khoroshilov
Hello, hfi1_ioctl() contains many calls to might sleep functions with dd->hfi1_snoop.snoop_lock spinlock held (for example, access_ok, copy_from_user, kzalloc(GFP_KERNEL), etc.). Should dd->hfi1_snoop.snoop_lock be acquired just before updating state? Found by Linux Driver Verification project

Re: [BUG] IB/hfi1: might sleep under spinlock in hfi1_ioctl()

2015-10-30 Thread ira.weiny
On Sat, Oct 31, 2015 at 12:32:29AM +0300, Alexey Khoroshilov wrote: > Hello, > > hfi1_ioctl() contains many calls to might sleep functions with > dd->hfi1_snoop.snoop_lock spinlock held (for example, access_ok, > copy_from_user, kzalloc(GFP_KERNEL), etc.). > > Should dd->hfi1_snoop.snoop_lock be

[BUG] IB/hfi1: might sleep under spinlock in hfi1_ioctl()

2015-10-30 Thread Alexey Khoroshilov
Hello, hfi1_ioctl() contains many calls to might sleep functions with dd->hfi1_snoop.snoop_lock spinlock held (for example, access_ok, copy_from_user, kzalloc(GFP_KERNEL), etc.). Should dd->hfi1_snoop.snoop_lock be acquired just before updating state? Found by Linux Driver Verification project