Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1259805 > unrolled thread
| Started by | Alexey Khoroshilov <khoroshilov@ispras.ru> |
|---|---|
| First post | 2015-10-30 22:40 +0100 |
| Last post | 2015-11-11 07:00 +0100 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
[BUG] IB/hfi1: might sleep under spinlock in hfi1_ioctl() Alexey Khoroshilov <khoroshilov@ispras.ru> - 2015-10-30 22:40 +0100
Re: [BUG] IB/hfi1: might sleep under spinlock in hfi1_ioctl() "ira.weiny" <ira.weiny@intel.com> - 2015-10-31 01:00 +0100
Re: [BUG] IB/hfi1: might sleep under spinlock in hfi1_ioctl() "ira.weiny" <ira.weiny@intel.com> - 2015-11-11 07:00 +0100
| From | Alexey Khoroshilov <khoroshilov@ispras.ru> |
|---|---|
| Date | 2015-10-30 22:40 +0100 |
| Subject | [BUG] IB/hfi1: might sleep under spinlock in hfi1_ioctl() |
| Message-ID | <qppyW-2yK-9@gated-at.bofh.it> |
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 (linuxtesting.org). -- Alexey Khoroshilov Linux Verification Center, ISPRAS web: http://linuxtesting.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | "ira.weiny" <ira.weiny@intel.com> |
|---|---|
| Date | 2015-10-31 01:00 +0100 |
| Message-ID | <qprKq-3P7-7@gated-at.bofh.it> |
| In reply to | #1259805 |
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 acquired just before updating state? I believe you are correct. I am currently in the process of pushing fixes to the staging tree. We have a patch which fixes this queued up but it depends on at least one other patch in my queue. I will do my best to get this submitted soon. Thanks, Ira -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "ira.weiny" <ira.weiny@intel.com> |
|---|---|
| Date | 2015-11-11 07:00 +0100 |
| Message-ID | <qtwBQ-77u-7@gated-at.bofh.it> |
| In reply to | #1259864 |
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, > > copy_from_user, kzalloc(GFP_KERNEL), etc.). > > > > Should dd->hfi1_snoop.snoop_lock be acquired just before updating state? > > I believe you are correct. > > I am currently in the process of pushing fixes to the staging tree. > > We have a patch which fixes this queued up but it depends on at least one other > patch in my queue. > > I will do my best to get this submitted soon. I have just posted a series which addresses this problem as well as doing general clean up on hfi1_ioctl. The specific fix is contained in this patch. [PATCH 7/8] staging/rdma/hfi1: Reduce snoop locking scope in IOCTL handler. Thanks for the report, Ira -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web