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 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
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
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 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
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
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
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
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 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 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
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
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
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
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
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
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 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
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
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
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
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
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
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()
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()
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(
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(
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 into the pipe mo
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 into the pipe mo
e_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 buffered write...
e_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 buffered write...
nt 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 iov_iter
> p
nt 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 iov_iter
> p
uation 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.
uation 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 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
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 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 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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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?
>
>
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?
>
>
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 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
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
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 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
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
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
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
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
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
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 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
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
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
>
>
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
>
>
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
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
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
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
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
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
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]
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]
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]
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]
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
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
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,
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,
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 =
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 =
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
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
1 - 100 of 146 matches
Mail list logo
