Re: __might_sleep in uio_read()?
From: Andy Grover
Date: Thu Sep 03 2015 - 16:12:34 EST
On 09/03/2015 12:12 PM, Greg KH wrote:
On Thu, Sep 03, 2015 at 11:47:34AM -0700, Andy Grover wrote:
On 09/03/2015 05:26 AM, Michal Hocko wrote:
On Wed 02-09-15 15:45:10, Andy Grover wrote:
Hi Hans and Greg,
Is this an issue with uio? I swear it didn't used to throw this warning...
Thanks -- Andy
[ 5174.883261] ------------[ cut here ]------------
[ 5174.883617] WARNING: CPU: 0 PID: 1532 at
/home/agrover/git/kernel/kernel/sched/core.c:7389 __might_sleep+0x7d/0x90()
[ 5174.884407] do not call blocking ops when !TASK_RUNNING; state=1 set at
[<ffffffffa02a5821>] uio_read+0x91/0x170 [uio]
The warning says that the driver is calling copy_to_user with
TASK_INTERRUPTIBLE which is wrong in general because this context can
sleep and a schedule would destroy the state. It doesn't matter here
because the code would break out from the loop regardless of the
copy_to_user return value.
I assume that TASK_INTERRUPTIBLE is necessary before the event_count
check to prevent from wake up races. If that is the case then you can
simply do:
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 3257d4220d01..7d8959e3833b 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -524,6 +524,7 @@ static ssize_t uio_read(struct file *filep, char __user *buf,
event_count = atomic_read(&idev->event);
if (event_count != listener->event_count) {
+ __set_current_state(TASK_RUNNING);
if (copy_to_user(buf, &event_count, count))
retval = -EFAULT;
else {
This certainly makes the warning go away. If this looks good to everyone
else can we get this change in?
What changed to require this? Why is this suddenly showing up now?
I'm working on drivers/target/target_core_user.c, a SCSI userspace
passthrough that was added in 3.18, aka TCMU, which uses uio.
The checks for !TASK_RUNNING were added in 3.19 (8eb23b9f3 and 00845eb96)
...and I'm just getting back to TCMU development after a bit, so maybe
I'm the first one to call uio_read since those checks were added in 3.19?
-- Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/