On Mon, Jun 23, 2014 at 08:44:40 +0100,
Al Viro wrote:
blkdev_read_iter() wants to cap the iov_iter by the amount of
data remaining to the end of device. That's what iov_iter_truncate()
is for (trim iter->count if it's above the given limit). So far,
so good, but the argument of
On Mon, Jun 23, 2014 at 08:44:40 +0100,
Al Viro v...@zeniv.linux.org.uk wrote:
blkdev_read_iter() wants to cap the iov_iter by the amount of
data remaining to the end of device. That's what iov_iter_truncate()
is for (trim iter-count if it's above the given limit). So far,
so good, but the
Al,
just checking - did you expect me to take this from the email, or are
you preparing a pull request?
Linus
On Mon, Jun 23, 2014 at 12:44 AM, Al Viro wrote:
>
> OK, here it is, hopefully with sufficient comments:
--
To unsubscribe from this list: send the line "unsubscribe
Al,
just checking - did you expect me to take this from the email, or are
you preparing a pull request?
Linus
On Mon, Jun 23, 2014 at 12:44 AM, Al Viro v...@zeniv.linux.org.uk wrote:
OK, here it is, hopefully with sufficient comments:
--
To unsubscribe from this list: send the
On Mon, 23 Jun 2014 11:43:02 -0400
"Theodore Ts'o" wrote:
> On Mon, Jun 23, 2014 at 08:44:40AM +0100, Al Viro wrote:
> >
> > OK, here it is, hopefully with sufficient comments:
>
> The comments look really good. I assume you'll get this to
> Linus in time for 3.16-rc3?
Fixes the 32GB 'can't
On Mon, 23 Jun 2014 11:43:02 -0400
Theodore Ts'o ty...@mit.edu wrote:
On Mon, Jun 23, 2014 at 08:44:40AM +0100, Al Viro wrote:
OK, here it is, hopefully with sufficient comments:
The comments look really good. I assume you'll get this to
Linus in time for 3.16-rc3?
Fixes the 32GB
On Mon, Jun 23, 2014 at 08:44:40AM +0100, Al Viro wrote:
>
> OK, here it is, hopefully with sufficient comments:
The comments look really good. I assume you'll get this to
Linus in time for 3.16-rc3?
Many thanks!!
- Ted
--
To unsubscribe from this list:
On Sun, Jun 22, 2014 at 07:50:07AM -0400, Theodore Ts'o wrote:
> On Sun, Jun 22, 2014 at 02:00:32AM +0100, Al Viro wrote:
> >
> > PS: I agree that it's worth careful commenting, obviously, but
> > before sending it to Linus (*with* comments) I want to get a
> > confirmation that this one-liner
On Mon, Jun 23, 2014 at 08:44:40AM +0100, Al Viro wrote:
OK, here it is, hopefully with sufficient comments:
The comments look really good. I assume you'll get this to
Linus in time for 3.16-rc3?
Many thanks!!
- Ted
--
To unsubscribe from this list:
On Sun, Jun 22, 2014 at 07:50:07AM -0400, Theodore Ts'o wrote:
On Sun, Jun 22, 2014 at 02:00:32AM +0100, Al Viro wrote:
PS: I agree that it's worth careful commenting, obviously, but
before sending it to Linus (*with* comments) I want to get a
confirmation that this one-liner actually
On Sun, Jun 22, 2014 at 02:00:32AM +0100, Al Viro wrote:
>
> PS: I agree that it's worth careful commenting, obviously, but
> before sending it to Linus (*with* comments) I want to get a
> confirmation that this one-liner actually fixes what Ted is seeing.
> I have reproduced it here, and that
On Sun, Jun 22, 2014 at 02:00:32AM +0100, Al Viro wrote:
PS: I agree that it's worth careful commenting, obviously, but
before sending it to Linus (*with* comments) I want to get a
confirmation that this one-liner actually fixes what Ted is seeing.
I have reproduced it here, and that change
On Sun, Jun 22, 2014 at 01:53:52AM +0100, Al Viro wrote:
> On Sat, Jun 21, 2014 at 05:32:44PM -0700, James Bottomley wrote:
> > > No, we are not. Look:
> > > * comparison promotes both operands to u64 here, so its result is
> > > accurate, no matter how large count is. They are compared as
On Sun, 2014-06-22 at 01:53 +0100, Al Viro wrote:
> On Sat, Jun 21, 2014 at 05:32:44PM -0700, James Bottomley wrote:
> > > No, we are not. Look:
> > > * comparison promotes both operands to u64 here, so its result is
> > > accurate, no matter how large count is. They are compared as natural
>
On Sat, Jun 21, 2014 at 05:32:44PM -0700, James Bottomley wrote:
> > No, we are not. Look:
> > * comparison promotes both operands to u64 here, so its result is
> > accurate, no matter how large count is. They are compared as natural
> > numbers.
>
> True ... figured this out 10 seconds
On Sun, 2014-06-22 at 01:26 +0100, Al Viro wrote:
> On Sat, Jun 21, 2014 at 05:03:20PM -0700, James Bottomley wrote:
>
> > > Anyway, does the following alone fix the problem you are seeing?
> > >
> > > diff --git a/include/linux/uio.h b/include/linux/uio.h
> > > index ddfdb53..dbb02d4 100644
> >
On Sat, Jun 21, 2014 at 05:03:20PM -0700, James Bottomley wrote:
> > Anyway, does the following alone fix the problem you are seeing?
> >
> > diff --git a/include/linux/uio.h b/include/linux/uio.h
> > index ddfdb53..dbb02d4 100644
> > --- a/include/linux/uio.h
> > +++ b/include/linux/uio.h
> >
On Sun, 2014-06-22 at 00:49 +0100, Al Viro wrote:
> On Sat, Jun 21, 2014 at 07:09:22PM -0400, Theodore Ts'o wrote:
> > On Sat, Jun 21, 2014 at 06:53:07AM +0100, Al Viro wrote:
> > >
> > > ed include/linux/uio.h < > > /iov_iter_truncate/s/size_t/u64/
> > > w
> > > q
> > > EOF
> > >
> > > Could
On Sat, Jun 21, 2014 at 07:09:22PM -0400, Theodore Ts'o wrote:
> On Sat, Jun 21, 2014 at 06:53:07AM +0100, Al Viro wrote:
> >
> > ed include/linux/uio.h < > /iov_iter_truncate/s/size_t/u64/
> > w
> > q
> > EOF
> >
> > Could you check if that fixes the sucker?
>
> The following patch (attached
On Sat, Jun 21, 2014 at 06:53:07AM +0100, Al Viro wrote:
>
> ed include/linux/uio.h < /iov_iter_truncate/s/size_t/u64/
> w
> q
> EOF
>
> Could you check if that fixes the sucker?
The following patch (attached at the end) appears to fix the problem,
but looking at uio.h, I'm completely confused
On Sat, Jun 21, 2014 at 06:53:07AM +0100, Al Viro wrote:
ed include/linux/uio.h EOF
/iov_iter_truncate/s/size_t/u64/
w
q
EOF
Could you check if that fixes the sucker?
The following patch (attached at the end) appears to fix the problem,
but looking at uio.h, I'm completely confused
On Sat, Jun 21, 2014 at 07:09:22PM -0400, Theodore Ts'o wrote:
On Sat, Jun 21, 2014 at 06:53:07AM +0100, Al Viro wrote:
ed include/linux/uio.h EOF
/iov_iter_truncate/s/size_t/u64/
w
q
EOF
Could you check if that fixes the sucker?
The following patch (attached at the end)
On Sun, 2014-06-22 at 00:49 +0100, Al Viro wrote:
On Sat, Jun 21, 2014 at 07:09:22PM -0400, Theodore Ts'o wrote:
On Sat, Jun 21, 2014 at 06:53:07AM +0100, Al Viro wrote:
ed include/linux/uio.h EOF
/iov_iter_truncate/s/size_t/u64/
w
q
EOF
Could you check if that fixes
On Sat, Jun 21, 2014 at 05:03:20PM -0700, James Bottomley wrote:
Anyway, does the following alone fix the problem you are seeing?
diff --git a/include/linux/uio.h b/include/linux/uio.h
index ddfdb53..dbb02d4 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -94,7 +94,7
On Sun, 2014-06-22 at 01:26 +0100, Al Viro wrote:
On Sat, Jun 21, 2014 at 05:03:20PM -0700, James Bottomley wrote:
Anyway, does the following alone fix the problem you are seeing?
diff --git a/include/linux/uio.h b/include/linux/uio.h
index ddfdb53..dbb02d4 100644
---
On Sat, Jun 21, 2014 at 05:32:44PM -0700, James Bottomley wrote:
No, we are not. Look:
* comparison promotes both operands to u64 here, so its result is
accurate, no matter how large count is. They are compared as natural
numbers.
True ... figured this out 10 seconds after sending
On Sun, 2014-06-22 at 01:53 +0100, Al Viro wrote:
On Sat, Jun 21, 2014 at 05:32:44PM -0700, James Bottomley wrote:
No, we are not. Look:
* comparison promotes both operands to u64 here, so its result is
accurate, no matter how large count is. They are compared as natural
numbers.
On Sun, Jun 22, 2014 at 01:53:52AM +0100, Al Viro wrote:
On Sat, Jun 21, 2014 at 05:32:44PM -0700, James Bottomley wrote:
No, we are not. Look:
* comparison promotes both operands to u64 here, so its result is
accurate, no matter how large count is. They are compared as natural
On Fri, Jun 20, 2014 at 11:51:44PM -0400, Theodore Ts'o wrote:
> On Fri, Jun 20, 2014 at 08:38:20AM +1000, Dave Chinner wrote:
> >
> > Short reads are more likely a bug in all the iovec iterator stuff
> > that got merged in from the vfs tree. ISTR a 32 bit-only bug in that
> > stuff go past in to
On Fri, Jun 20, 2014 at 08:38:20AM +1000, Dave Chinner wrote:
>
> Short reads are more likely a bug in all the iovec iterator stuff
> that got merged in from the vfs tree. ISTR a 32 bit-only bug in that
> stuff go past in to do with not being able to partition a 32GB block
> dev on a 32 bit
On Fri, Jun 20, 2014 at 08:38:20AM +1000, Dave Chinner wrote:
Short reads are more likely a bug in all the iovec iterator stuff
that got merged in from the vfs tree. ISTR a 32 bit-only bug in that
stuff go past in to do with not being able to partition a 32GB block
dev on a 32 bit system due
On Fri, Jun 20, 2014 at 11:51:44PM -0400, Theodore Ts'o wrote:
On Fri, Jun 20, 2014 at 08:38:20AM +1000, Dave Chinner wrote:
Short reads are more likely a bug in all the iovec iterator stuff
that got merged in from the vfs tree. ISTR a 32 bit-only bug in that
stuff go past in to do with
32 matches
Mail list logo
