Messages in this thread | | | Date | Thu, 3 Oct 2013 19:56:30 +0100 | From | Al Viro <> | Subject | Re: pipe/cred lockdep warning |
| |
On Tue, Oct 01, 2013 at 10:57:55AM -0400, Dave Jones wrote: > I seem to recall hitting this quite a while ago. Does it look familiar ? > Either it didn't get fixed, or it's back..
> [ 2836.628506] trinity-child0/30759 is trying to acquire lock: > [ 2836.628544] (&sig->cred_guard_mutex){+.+.+.}, at: [<ffffffff81239045>] proc_pid_attr_write+0xf5/0x140 > [ 2836.628624] > but task is already holding lock: > [ 2836.628664] (&pipe->mutex/1){+.+.+.}, at: [<ffffffff811ccf66>] pipe_lock+0x26/0x30 > [ 2836.628734]
splice to /proc/<pid>/attr/<something> [cred_guard shite under pipe->mutex]
vs.
splice from XFS [pipe->mutex under exclusive iolock]
vs.
read from XFS in execve() [shared iolock under cred_guard]
Note, BTW, that splice to /proc/<pid>/attr/<something> is broken. proc_pid_attr_write() is *not* supposed to allow partial writes at all. Frankly, I'd consider adding a ->splice_write() instance that would simply return -EINVAL there...
| |