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 iov_iter_tru
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 linu
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 p
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 act
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 cha
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 natu
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 afte
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 you
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 at
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 a
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 system
16 matches
Mail list logo
