On Tue, Sep 12, 2017 at 04:02:14PM +1000, Dave Chinner wrote:
> > Note that one of the bugs there applies to normal read() as well - if you
> > are reading from a hole in file into an array with a read-only page in
> > the middle, you want a short read.
>
> And there's another WTF? moment.
>
On Mon, Sep 11, 2017 at 09:07:13PM +0100, Al Viro wrote:
> On Mon, Sep 11, 2017 at 04:44:40PM +1000, Dave Chinner wrote:
>
> > > iov_iter_get_pages() for pipe-backed destination does page allocation
> > > and inserts freshly allocated pages into pipe.
> >
> > Oh, it's hidden more layers down than
On Mon, Sep 11, 2017 at 09:07:13PM +0100, Al Viro wrote:
> Strictly speaking that behaviour doesn't violate POSIX. It is, however,
> atrocious from the QoI standpoint, and for no good reason whatsoever.
> It's quite easy to do better, and doing so would've eliminated the problems
> in pipe-backed
On Mon, Sep 11, 2017 at 04:44:40PM +1000, Dave Chinner wrote:
> > iov_iter_get_pages() for pipe-backed destination does page allocation
> > and inserts freshly allocated pages into pipe.
>
> Oh, it's hidden more layers down than the code implied I needed to
> look.
>
> i.e. there's no obvious cl
On Mon, Sep 11, 2017 at 05:07:57AM -0700, Christoph Hellwig wrote:
> On Mon, Sep 11, 2017 at 12:07:23AM +0100, Al Viro wrote:
> > BTW, another problem I see there is that iomap_dio_actor() should *NOT*
> > assume that do-while loop in there will always manage to shove 'length'
> > bytes out in case
On Mon, Sep 11, 2017 at 12:07:23AM +0100, Al Viro wrote:
> BTW, another problem I see there is that iomap_dio_actor() should *NOT*
> assume that do-while loop in there will always manage to shove 'length'
> bytes out in case of success. That is simply not true for pipe-backed
> destination. And I
On Mon, Sep 11, 2017 at 04:32:22AM +0100, Al Viro wrote:
> On Mon, Sep 11, 2017 at 10:31:13AM +1000, Dave Chinner wrote:
>
> > splice does not go down the direct IO path, so iomap_dio_actor()
> > should never be handled a pipe as the destination for the IO data.
> > Indeed, splice read has to supp
On Mon, Sep 11, 2017 at 10:31:13AM +1000, Dave Chinner wrote:
> splice does not go down the direct IO path, so iomap_dio_actor()
> should never be handled a pipe as the destination for the IO data.
> Indeed, splice read has to supply the pages to be put into the pipe,
> which the DIO path does not
On Mon, Sep 11, 2017 at 12:07:23AM +0100, Al Viro wrote:
> On Mon, Sep 11, 2017 at 08:08:14AM +1000, Dave Chinner wrote:
> > On Sun, Sep 10, 2017 at 10:19:07PM +0100, Al Viro wrote:
> > > On Mon, Sep 11, 2017 at 07:11:10AM +1000, Dave Chinner wrote:
> > > > On Sun, Sep 10, 2017 at 03:57:21AM +0100,
On Mon, Sep 11, 2017 at 12:07:23AM +0100, Al Viro wrote:
> BTW, another problem I see there is that iomap_dio_actor() should *NOT*
> assume that do-while loop in there will always manage to shove 'length'
> bytes out in case of success. That is simply not true for pipe-backed
> destination. And
On Mon, Sep 11, 2017 at 08:08:14AM +1000, Dave Chinner wrote:
> On Sun, Sep 10, 2017 at 10:19:07PM +0100, Al Viro wrote:
> > On Mon, Sep 11, 2017 at 07:11:10AM +1000, Dave Chinner wrote:
> > > On Sun, Sep 10, 2017 at 03:57:21AM +0100, Al Viro wrote:
> > > > On Sat, Sep 09, 2017 at 09:07:56PM -0400,
On Sun, Sep 10, 2017 at 10:19:07PM +0100, Al Viro wrote:
> On Mon, Sep 11, 2017 at 07:11:10AM +1000, Dave Chinner wrote:
> > On Sun, Sep 10, 2017 at 03:57:21AM +0100, Al Viro wrote:
> > > On Sat, Sep 09, 2017 at 09:07:56PM -0400, Dave Jones wrote:
> > >
> > > > With this in place, I'm still seeing
On Mon, Sep 11, 2017 at 07:11:10AM +1000, Dave Chinner wrote:
> On Sun, Sep 10, 2017 at 03:57:21AM +0100, Al Viro wrote:
> > On Sat, Sep 09, 2017 at 09:07:56PM -0400, Dave Jones wrote:
> >
> > > With this in place, I'm still seeing -EBUSY from
> > > invalidate_inode_pages2_range
> > > which doesn
On Sun, Sep 10, 2017 at 03:57:21AM +0100, Al Viro wrote:
> On Sat, Sep 09, 2017 at 09:07:56PM -0400, Dave Jones wrote:
>
> > With this in place, I'm still seeing -EBUSY from
> > invalidate_inode_pages2_range
> > which doesn't end well...
>
> Different issue, and I'm not sure why that WARN_ON() i
ent issue, and I'm not sure why that WARN_ON() is there in the
> > > > first place. Note that in a similar situation
> generic_file_direct_write()
> > > > simply buggers off and lets the caller do buffered write...
> > > >
> > > > i
Note that in a similar situation
> > generic_file_direct_write()
> > > simply buggers off and lets the caller do buffered write...
> > >
> > > iov_iter_pipe() warning is a sign of ->read_iter() on pipe-backed
> > iov_iter
> > > putting i
_inode_pages2_range
> > > which doesn't end well...
> >
> > Different issue, and I'm not sure why that WARN_ON() is there in the
> > first place. Note that in a similar situation generic_file_direct_write()
> > simply buggers off and lets the caller do bu
fferent issue, and I'm not sure why that WARN_ON() is there in the
> first place. Note that in a similar situation generic_file_direct_write()
> simply buggers off and lets the caller do buffered write...
>
> iov_iter_pipe() warning is a sign of ->read_iter() on pipe-backed i
n a similar situation generic_file_direct_write()
simply buggers off and lets the caller do buffered write...
iov_iter_pipe() warning is a sign of ->read_iter() on pipe-backed iov_iter
putting into the pipe more than it claims to have done.
On Fri, Sep 08, 2017 at 02:04:41AM +0100, Al Viro wrote:
> There's at least one suspicious place in iomap_dio_actor() -
> if (!(dio->flags & IOMAP_DIO_WRITE)) {
> iov_iter_zero(length, dio->submit.iter);
> dio->size += length;
>
On Thu, Sep 07, 2017 at 09:46:17AM +1000, Dave Chinner wrote:
> On Wed, Sep 06, 2017 at 04:03:37PM -0400, Dave Jones wrote:
> > On Mon, Aug 28, 2017 at 09:25:42PM -0700, Darrick J. Wong wrote:
> > > On Mon, Aug 28, 2017 at 04:31:30PM -0400, Dave Jones wrote:
> > > > I'm still trying to narrow dow
On Wed, Sep 06, 2017 at 11:48:35PM -0400, Dave Jones wrote:
> > That doesn't seem like an XFS problem - it indicates the pipe we are
> > filling in generic_file_splice_read() is not being emptied by
> > whatever we are splicing the file data to
>
> The puzzling part is this runs for a day
On Thu, Sep 07, 2017 at 09:46:17AM +1000, Dave Chinner wrote:
> On Wed, Sep 06, 2017 at 04:03:37PM -0400, Dave Jones wrote:
> > On Mon, Aug 28, 2017 at 09:25:42PM -0700, Darrick J. Wong wrote:
> > > On Mon, Aug 28, 2017 at 04:31:30PM -0400, Dave Jones wrote:
> > > > I'm still trying to narrow
On Wed, Sep 06, 2017 at 04:03:37PM -0400, Dave Jones wrote:
> On Mon, Aug 28, 2017 at 09:25:42PM -0700, Darrick J. Wong wrote:
> > On Mon, Aug 28, 2017 at 04:31:30PM -0400, Dave Jones wrote:
> > > I'm still trying to narrow down an exact reproducer, but it seems having
> > > trinity do a combina
On Mon, Aug 28, 2017 at 09:25:42PM -0700, Darrick J. Wong wrote:
> On Mon, Aug 28, 2017 at 04:31:30PM -0400, Dave Jones wrote:
> > On Mon, Aug 07, 2017 at 04:18:18PM -0400, Dave Jones wrote:
> > > On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote:
> > > > On Fri, Apr 28, 2017 at 12:50:
On Wed, Aug 30, 2017 at 10:13:43AM -0700, Darrick J. Wong wrote:
> > I reverted the debug patches mentioned above, and ran trinity for a while
> > again,
> > and got this which smells really suspiciously related
> >
> > WARNING: CPU: 1 PID: 10380 at fs/iomap.c:993 iomap_dio_rw+0x825/0x840
On Wed, Aug 30, 2017 at 01:05:23PM -0400, Dave Jones wrote:
> On Mon, Aug 28, 2017 at 09:25:42PM -0700, Darrick J. Wong wrote:
> > On Mon, Aug 28, 2017 at 04:31:30PM -0400, Dave Jones wrote:
> > > On Mon, Aug 07, 2017 at 04:18:18PM -0400, Dave Jones wrote:
> > > > On Fri, Apr 28, 2017 at 06:20:
On Mon, Aug 28, 2017 at 09:25:42PM -0700, Darrick J. Wong wrote:
> On Mon, Aug 28, 2017 at 04:31:30PM -0400, Dave Jones wrote:
> > On Mon, Aug 07, 2017 at 04:18:18PM -0400, Dave Jones wrote:
> > > On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote:
> > > > On Fri, Apr 28, 2017 at 12:50:
On Mon, Aug 28, 2017 at 04:31:30PM -0400, Dave Jones wrote:
> On Mon, Aug 07, 2017 at 04:18:18PM -0400, Dave Jones wrote:
> > On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote:
> > > On Fri, Apr 28, 2017 at 12:50:24PM -0400, Dave Jones wrote:
> > > > currently running v4.11-rc8-75-gf8324
On Mon, Aug 07, 2017 at 04:18:18PM -0400, Dave Jones wrote:
> On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote:
> > On Fri, Apr 28, 2017 at 12:50:24PM -0400, Dave Jones wrote:
> > > currently running v4.11-rc8-75-gf83246089ca0
> > >
> > > sunrpc bit is for the other unrelated probl
On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote:
> On Fri, Apr 28, 2017 at 12:50:24PM -0400, Dave Jones wrote:
> > currently running v4.11-rc8-75-gf83246089ca0
> >
> > sunrpc bit is for the other unrelated problem I'm chasing.
> >
> > note also, I saw the backtrace without the fs/sp
On Sat, Apr 29, 2017 at 11:51:40AM -0400, Dave Jones wrote:
> > > > Gyah... It's a bloody dumb braino in iov_iter_revert() for
> pipe-backed
> > > > ones. Sorry, the oneliner below should fix it.
> > >
> > > 5 hrs in, looking good so far.
> >
> > Mind your Tested-by on the fix?
>
> S
On Sat, Apr 29, 2017 at 03:47:36AM +0100, Al Viro wrote:
> On Fri, Apr 28, 2017 at 09:58:47PM -0400, Dave Jones wrote:
> > On Fri, Apr 28, 2017 at 07:25:12PM +0100, Al Viro wrote:
> > > On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote:
> > > > On Fri, Apr 28, 2017 at 12:50:24PM -0400,
On Fri, Apr 28, 2017 at 09:58:47PM -0400, Dave Jones wrote:
> On Fri, Apr 28, 2017 at 07:25:12PM +0100, Al Viro wrote:
> > On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote:
> > > On Fri, Apr 28, 2017 at 12:50:24PM -0400, Dave Jones wrote:
> > > > currently running v4.11-rc8-75-gf83246089c
On Fri, Apr 28, 2017 at 07:25:12PM +0100, Al Viro wrote:
> On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote:
> > On Fri, Apr 28, 2017 at 12:50:24PM -0400, Dave Jones wrote:
> > > currently running v4.11-rc8-75-gf83246089ca0
> > >
> > > sunrpc bit is for the other unrelated problem I'm
On Fri, Apr 28, 2017 at 06:20:25PM +0100, Al Viro wrote:
> On Fri, Apr 28, 2017 at 12:50:24PM -0400, Dave Jones wrote:
> > currently running v4.11-rc8-75-gf83246089ca0
> >
> > sunrpc bit is for the other unrelated problem I'm chasing.
> >
> > note also, I saw the backtrace without the fs/splice.c
On Fri, Apr 28, 2017 at 12:50:24PM -0400, Dave Jones wrote:
> currently running v4.11-rc8-75-gf83246089ca0
>
> sunrpc bit is for the other unrelated problem I'm chasing.
>
> note also, I saw the backtrace without the fs/splice.c changes.
Interesting... Could you add this and see if that
On Fri, Apr 28, 2017 at 05:43:13PM +0100, Al Viro wrote:
> On Fri, Apr 28, 2017 at 11:29:55AM -0400, Dave Jones wrote:
> > On Fri, Apr 21, 2017 at 06:54:30PM +0100, Al Viro wrote:
> > > On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote:
> > >
> > > > Well it's been running an hour
On Fri, Apr 28, 2017 at 11:29:55AM -0400, Dave Jones wrote:
> On Fri, Apr 21, 2017 at 06:54:30PM +0100, Al Viro wrote:
> > On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote:
> >
> > > Well it's been running an hour without incident, which looks promising.
> > > I'll leave it run, but
On Fri, Apr 21, 2017 at 06:54:30PM +0100, Al Viro wrote:
> On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote:
>
> > Well it's been running an hour without incident, which looks promising.
> > I'll leave it run, but I'd say you're on the right track given how quick
> > it reproduced s
On Thu, Apr 27, 2017 at 12:34:44PM -0400, Dave Jones wrote:
> [977286.117268] RPC request reserved 116 but used 268
> [1918138.126285] RPC request reserved 200 but used 268
> [232.483077] RPC request reserved 200 but used 268
> [2327800.909007] RPC request reserved 200 but used 268
>
> relate
On Thu, Apr 27, 2017 at 12:19:18AM -0400, Dave Jones wrote:
> On Fri, Apr 21, 2017 at 06:54:30PM +0100, Al Viro wrote:
> > On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote:
> >
> > > Well it's been running an hour without incident, which looks promising.
> > > I'll leave it run,
On Fri, Apr 21, 2017 at 06:54:30PM +0100, Al Viro wrote:
> On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote:
>
> > Well it's been running an hour without incident, which looks promising.
> > I'll leave it run, but I'd say you're on the right track given how quick
> > it reproduced s
On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote:
> Well it's been running an hour without incident, which looks promising.
> I'll leave it run, but I'd say you're on the right track given how quick
> it reproduced so far.
Could you try this and see if it works? What happens is that un
On Wed, Apr 12, 2017 at 06:07:23PM +0100, Al Viro wrote:
> On Wed, Apr 12, 2017 at 12:27:09PM -0400, Dave Jones wrote:
>
> > [ 1010.317696] asked to read 2097152, claims to have read 7025
> > [ 1010.329471] actual size of data in pipe 65536
> > [ 1010.341162] [0:4096
> > [ 1010.353232] ,1:4
On Wed, Apr 12, 2017 at 12:27:09PM -0400, Dave Jones wrote:
> [ 1010.317696] asked to read 2097152, claims to have read 7025
> [ 1010.329471] actual size of data in pipe 65536
> [ 1010.341162] [0:4096
> [ 1010.353232] ,1:4096
> [ 1010.364402] ,2:4096
> [ 1010.375608] ,3:4096
> [ 1010.386346] ,4:4
On Wed, Apr 12, 2017 at 04:26:00PM +0100, Al Viro wrote:
> On Wed, Apr 12, 2017 at 10:35:19AM -0400, Dave Jones wrote:
>
> > [ 4140.040002] asked to read 8, claims to have read 4
> > [ 4140.051634] actual size of data in pipe 8
> > [ 4140.063234] [0:8
>
> > [ 4140.342955] ---[ end trace d
On Wed, Apr 12, 2017 at 10:35:19AM -0400, Dave Jones wrote:
> [ 4140.040002] asked to read 8, claims to have read 4
> [ 4140.051634] actual size of data in pipe 8
> [ 4140.063234] [0:8
> [ 4140.342955] ---[ end trace d074a8823fe244d4 ]---
> [ 4140.353868] in->f_op = a02dc980, ->splice_wr
On Wed, Apr 12, 2017 at 03:58:42AM +0100, Al Viro wrote:
> On Tue, Apr 11, 2017 at 10:29:11PM -0400, Dave Jones wrote:
> > On Wed, Apr 12, 2017 at 02:15:32AM +0100, Al Viro wrote:
> > > On Tue, Apr 11, 2017 at 08:58:53PM -0400, Dave Jones wrote:
> > > > [ 462.696557] in->f_op = a02df
On Tue, Apr 11, 2017 at 10:29:11PM -0400, Dave Jones wrote:
> On Wed, Apr 12, 2017 at 02:15:32AM +0100, Al Viro wrote:
> > On Tue, Apr 11, 2017 at 08:58:53PM -0400, Dave Jones wrote:
> > > [ 462.696557] in->f_op = a02df980, ->splice_write =
> 812b2b20
> > > $ grep a02df
On Wed, Apr 12, 2017 at 02:15:32AM +0100, Al Viro wrote:
> On Tue, Apr 11, 2017 at 08:58:53PM -0400, Dave Jones wrote:
> > [ 462.696557] in->f_op = a02df980, ->splice_write =
> > 812b2b20
> > $ grep a02df980 /proc/kallsyms
> > a02df980 r nfs4_file_operations
On Tue, Apr 11, 2017 at 08:58:53PM -0400, Dave Jones wrote:
> [ 462.696557] in->f_op = a02df980, ->splice_write = 812b2b20
> $ grep a02df980 /proc/kallsyms
> a02df980 r nfs4_file_operations [nfsv4]
> $ grep 812b2b20 /proc/kallsyms
> 812b2b20
On Wed, Apr 12, 2017 at 01:17:46AM +0100, Al Viro wrote:
> On Tue, Apr 11, 2017 at 08:06:07PM -0400, Dave Jones wrote:
> > On Wed, Apr 12, 2017 at 12:56:41AM +0100, Al Viro wrote:
> > > On Wed, Apr 12, 2017 at 12:51:58AM +0100, Al Viro wrote:
> > > > On Tue, Apr 11, 2017 at 07:45:58PM -0400,
On Tue, Apr 11, 2017 at 08:06:07PM -0400, Dave Jones wrote:
> On Wed, Apr 12, 2017 at 12:56:41AM +0100, Al Viro wrote:
> > On Wed, Apr 12, 2017 at 12:51:58AM +0100, Al Viro wrote:
> > > On Tue, Apr 11, 2017 at 07:45:58PM -0400, Dave Jones wrote:
> > > > > if (file->f_op->splice_write == gen
On Wed, Apr 12, 2017 at 12:56:41AM +0100, Al Viro wrote:
> On Wed, Apr 12, 2017 at 12:51:58AM +0100, Al Viro wrote:
> > On Tue, Apr 11, 2017 at 07:45:58PM -0400, Dave Jones wrote:
> > > > if (file->f_op->splice_write == generic_splice_sendpage) {
> > > > struct socket *soc
On Wed, Apr 12, 2017 at 12:51:58AM +0100, Al Viro wrote:
> On Tue, Apr 11, 2017 at 07:45:58PM -0400, Dave Jones wrote:
> > > if (file->f_op->splice_write == generic_splice_sendpage) {
> > > struct socket *sock = file->private_data;
> > > printk(KERN_ERR "socket [%d, %p]\n", so
On Tue, Apr 11, 2017 at 07:45:58PM -0400, Dave Jones wrote:
> >if (file->f_op->splice_write == generic_splice_sendpage) {
> >struct socket *sock = file->private_data;
> >printk(KERN_ERR "socket [%d, %p]\n", sock->type, sock->ops);
> >}
> >printk(KERN_ERR "in
On Tue, Apr 11, 2017 at 07:34:37PM -0400, Dave Jones wrote:
> On Wed, Apr 12, 2017 at 12:28:42AM +0100, Al Viro wrote:
> > On Tue, Apr 11, 2017 at 06:25:02PM -0400, Dave Jones wrote:
> >
> > > 812b3130 T generic_splice_sendpage
> > >
> > > This one spat out all by itself.
> >
> >
On Wed, Apr 12, 2017 at 12:28:42AM +0100, Al Viro wrote:
> On Tue, Apr 11, 2017 at 06:25:02PM -0400, Dave Jones wrote:
>
> > 812b3130 T generic_splice_sendpage
> >
> > This one spat out all by itself.
>
> No need to print ->f_op for that one - can be only socket_file_ops. Now,
>
On Wed, Apr 12, 2017 at 12:28:42AM +0100, Al Viro wrote:
> On Tue, Apr 11, 2017 at 06:25:02PM -0400, Dave Jones wrote:
>
> > 812b3130 T generic_splice_sendpage
> >
> > This one spat out all by itself.
>
> No need to print ->f_op for that one - can be only socket_file_ops. Now,
>
On Tue, Apr 11, 2017 at 06:25:02PM -0400, Dave Jones wrote:
> 812b3130 T generic_splice_sendpage
>
> This one spat out all by itself.
No need to print ->f_op for that one - can be only socket_file_ops. Now,
the address family of that socket would be interesting...
How about adding to t
On Tue, Apr 11, 2017 at 10:12:16PM +0100, Al Viro wrote:
> On Tue, Apr 11, 2017 at 04:53:36PM -0400, Dave Jones wrote:
> > > if (WARN_ON(pipe->nrbufs)) {
> > > printk(KERN_ERR "->splice_write = %p",
> > > sd->u.file->f_o
On Tue, Apr 11, 2017 at 04:53:36PM -0400, Dave Jones wrote:
> >if (WARN_ON(pipe->nrbufs)) {
> >printk(KERN_ERR "->splice_write = %p",
> >sd->u.file->f_op->splice_write);
> >}
> >}
>
> Ah, missed adding this 2nd WARN_O
On Tue, Apr 11, 2017 at 04:28:39AM +0100, Al Viro wrote:
> On Mon, Apr 10, 2017 at 11:05:32PM -0400, Dave Jones wrote:
> > On Tue, Apr 11, 2017 at 01:22:15AM +0100, Al Viro wrote:
> >
> > > * in do_splice_to(): WARN_ON(pipe->nrbufs == pipe->buffers)
> >
> > Hit this one.
>
> But
On Mon, Apr 10, 2017 at 11:05:32PM -0400, Dave Jones wrote:
> On Tue, Apr 11, 2017 at 01:22:15AM +0100, Al Viro wrote:
>
> >* in do_splice_to(): WARN_ON(pipe->nrbufs == pipe->buffers)
>
> Hit this one.
But not WARN_ON(pipe->nrbufs) in its caller *or* WARN_ON(!pipe->buffers)
in do_splice_to(
On Tue, Apr 11, 2017 at 01:22:15AM +0100, Al Viro wrote:
> * in do_splice_to(): WARN_ON(pipe->nrbufs == pipe->buffers)
Hit this one.
> * in generic_file_splice_read(): WARN_ON(pipe->nrbufs == pipe->buffers)
followed by this one.
Then the usual iov_iter trace.
Dave
On Mon, Apr 10, 2017 at 07:48:30PM -0400, Dave Jones wrote:
> >if (WARN_ON(pipe->nr_bufs))
> >printk(KERN_ERR "->splice_write = %p",
> >sd->u.file->f_op->splice_write);
> > and see which function it is?
>
> s/nr_bufs/nrbufs/ aside, I tried this, and it didn'
On Mon, Apr 10, 2017 at 08:57:11PM +0100, Al Viro wrote:
> On Mon, Apr 10, 2017 at 03:42:06PM -0400, Dave Jones wrote:
> > > Do you have a reliable reproducer?
> >
> > Not reliable, but I'll see if I can find some time to narrow it down
> > this week. I've been working on better logging of
On Mon, Apr 10, 2017 at 03:42:06PM -0400, Dave Jones wrote:
> > Do you have a reliable reproducer?
>
> Not reliable, but I'll see if I can find some time to narrow it down
> this week. I've been working on better logging of "wtf just happened"
> the last few weeks, so it should get easier once I
On Mon, Apr 10, 2017 at 08:28:00PM +0100, Al Viro wrote:
> On Tue, Mar 21, 2017 at 04:59:01PM -0400, Dave Jones wrote:
> > WARNING: CPU: 0 PID: 9290 at lib/iov_iter.c:836 iov_iter_pipe+0x71/0x80
> > CPU: 0 PID: 9290 Comm: trinity-c7 Not tainted 4.11.0-rc3-think+ #3
> > Call Trace:
> > dump_s
On Tue, Mar 21, 2017 at 04:59:01PM -0400, Dave Jones wrote:
> WARNING: CPU: 0 PID: 9290 at lib/iov_iter.c:836 iov_iter_pipe+0x71/0x80
> CPU: 0 PID: 9290 Comm: trinity-c7 Not tainted 4.11.0-rc3-think+ #3
> Call Trace:
> dump_stack+0x68/0x93
> __warn+0xcb/0xf0
> warn_slowpath_null+0x1d/0x20
> io
On Tue, Mar 21, 2017 at 04:59:01PM -0400, Dave Jones wrote:
> WARNING: CPU: 0 PID: 9290 at lib/iov_iter.c:836 iov_iter_pipe+0x71/0x80
> CPU: 0 PID: 9290 Comm: trinity-c7 Not tainted 4.11.0-rc3-think+ #3
> Call Trace:
> dump_stack+0x68/0x93
> __warn+0xcb/0xf0
> warn_slowpath_null+0x1d/0x20
WARNING: CPU: 0 PID: 9290 at lib/iov_iter.c:836 iov_iter_pipe+0x71/0x80
CPU: 0 PID: 9290 Comm: trinity-c7 Not tainted 4.11.0-rc3-think+ #3
Call Trace:
dump_stack+0x68/0x93
__warn+0xcb/0xf0
warn_slowpath_null+0x1d/0x20
iov_iter_pipe+0x71/0x80
generic_file_splice_read+0x37/0x140
do_splice_to+0
73 matches
Mail list logo
