Re: [regression] fix 32-bit breakage in block device read(2) (was Re: 32-bit bug in iovec iterator changes)
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_truncate() is size_t, so on 32bit boxen (in case of a large device) we end up with that upper limit truncated down to 32 bits *before* comparing it with iter->count. This seems to fix a problem I had (https://bugzilla.kernel.org/show_bug.cgi?id=78711) with a partition device (/dev/sda3) being zero size on 3.16 kernels. However I am having some other issues with 3.16 on i686 and the amount of testing was the raid array using /dev/sda3 appeared to start (which it hadn't previously), but the system hung before finishing the boot process. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [regression] fix 32-bit breakage in block device read(2) (was Re: 32-bit bug in iovec iterator changes)
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 linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [regression] fix 32-bit breakage in block device read(2) (was Re: 32-bit bug in iovec iterator changes)
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 partition' bug I reported too. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [regression] fix 32-bit breakage in block device read(2) (was Re: 32-bit bug in iovec iterator changes)
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: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[regression] fix 32-bit breakage in block device read(2) (was Re: 32-bit bug in iovec iterator changes)
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 fixes what Ted is seeing.
> > I have reproduced it here, and that change makes the breakage go
> > away in my testing, but I'd like to make sure that we are seeing the
> > same thing. Ted?
>
> Hep, that fixes things. Thanks for explaining what was going on!
OK, here it is, hopefully with sufficient comments:
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_truncate() is size_t, so on
32bit boxen (in case of a large device) we end up with that upper
limit truncated down to 32 bits *before* comparing it with iter->count.
Easily fixed by making iov_iter_truncate() take 64bit argument -
it does the right thing after such change (we only reach the
assignment in there when the current value of iter->count is greater
than the limit, i.e. for anything that would get truncated we don't
reach the assignment at all) and that argument is not the new
value of iter->count - it's an upper limit for such.
The overhead of passing u64 is not an issue - the thing is inlined,
so callers passing size_t won't pay any penalty.
Reported-by: Theodore Tso
Tested-by: Theodore Tso
Signed-off-by: Al Viro
---
diff --git a/include/linux/uio.h b/include/linux/uio.h
index ddfdb53..17ae7e3 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -94,8 +94,20 @@ static inline size_t iov_iter_count(struct iov_iter *i)
return i->count;
}
-static inline void iov_iter_truncate(struct iov_iter *i, size_t count)
+/*
+ * Cap the iov_iter by given limit; note that the second argument is
+ * *not* the new size - it's upper limit for such. Passing it a value
+ * greater than the amount of data in iov_iter is fine - it'll just do
+ * nothing in that case.
+ */
+static inline void iov_iter_truncate(struct iov_iter *i, u64 count)
{
+ /*
+* count doesn't have to fit in size_t - comparison extends both
+* operands to u64 here and any value that would be truncated by
+* conversion in assignement is by definition greater than all
+* values of size_t, including old i->count.
+*/
if (i->count > count)
i->count = count;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32-bit bug in iovec iterator changes
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 makes the breakage go > away in my testing, but I'd like to make sure that we are seeing the > same thing. Ted? Hep, that fixes things. Thanks for explaining what was going on! - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32-bit bug in iovec iterator changes
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
> > > numbers.
> >
> > True ... figured this out 10 seconds after sending the email.
> >
> > > * assignment converts count to size_t, which *would* truncate for
> > > values that are greater than the maximal value representable by size_t.
> > > But in that case it's by definition greater than i->count, so we do not
> > > reach that assignment at all.
> >
> > OK, so what I still don't get is why isn't the compiler warning when we
> > truncate a u64 to a u32? We should get that warning in your new code,
> > and we should have got that warning in fs/block_dev.c where it would
> > have pinpointed the actual problem.
>
> In which universe?
>
> extern void f(unsigned int);
>
> void g(unsigned long x)
> {
> f(x);
> }
>
> is perfectly valid C, with no warnings in sight. f(1UL << 32) might
> give one, but not this...
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
makes the breakage go away in my testing, but I'd like to make sure that we are
seeing the same thing. Ted?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32-bit bug in iovec iterator changes
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.
> >
> > True ... figured this out 10 seconds after sending the email.
> >
> > > * assignment converts count to size_t, which *would* truncate for
> > > values that are greater than the maximal value representable by size_t.
> > > But in that case it's by definition greater than i->count, so we do not
> > > reach that assignment at all.
> >
> > OK, so what I still don't get is why isn't the compiler warning when we
> > truncate a u64 to a u32? We should get that warning in your new code,
> > and we should have got that warning in fs/block_dev.c where it would
> > have pinpointed the actual problem.
>
> In which universe?
>
> extern void f(unsigned int);
>
> void g(unsigned long x)
> {
> f(x);
> }
In the one where the code is compiled with -Wconversion ... I'm just
surprised, I thought we had this enabled.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32-bit bug in iovec iterator changes
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 the email.
>
> > * assignment converts count to size_t, which *would* truncate for
> > values that are greater than the maximal value representable by size_t.
> > But in that case it's by definition greater than i->count, so we do not
> > reach that assignment at all.
>
> OK, so what I still don't get is why isn't the compiler warning when we
> truncate a u64 to a u32? We should get that warning in your new code,
> and we should have got that warning in fs/block_dev.c where it would
> have pinpointed the actual problem.
In which universe?
extern void f(unsigned int);
void g(unsigned long x)
{
f(x);
}
is perfectly valid C, with no warnings in sight. f(1UL << 32) might
give one, but not this...
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32-bit bug in iovec iterator changes
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
> > > --- a/include/linux/uio.h
> > > +++ b/include/linux/uio.h
> > > @@ -94,7 +94,7 @@ static inline size_t iov_iter_count(struct iov_iter *i)
> > > return i->count;
> > > }
> > >
> > > -static inline void iov_iter_truncate(struct iov_iter *i, size_t count)
> > > +static inline void iov_iter_truncate(struct iov_iter *i, u64 count)
> > > {
> > > if (i->count > count)
> > > i->count = count;
> >
> > Al, how can that work? i->count is size_t, which is 32 bit, so we're
> > going to get truncation errors.
>
> 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 the email.
> * assignment converts count to size_t, which *would* truncate for
> values that are greater than the maximal value representable by size_t.
> But in that case it's by definition greater than i->count, so we do not
> reach that assignment at all.
OK, so what I still don't get is why isn't the compiler warning when we
truncate a u64 to a u32? We should get that warning in your new code,
and we should have got that warning in fs/block_dev.c where it would
have pinpointed the actual problem.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32-bit bug in iovec iterator changes
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 @@ static inline size_t iov_iter_count(struct iov_iter *i)
> > return i->count;
> > }
> >
> > -static inline void iov_iter_truncate(struct iov_iter *i, size_t count)
> > +static inline void iov_iter_truncate(struct iov_iter *i, u64 count)
> > {
> > if (i->count > count)
> > i->count = count;
>
> Al, how can that work? i->count is size_t, which is 32 bit, so we're
> going to get truncation errors.
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.
* assignment converts count to size_t, which *would* truncate for
values that are greater than the maximal value representable by size_t.
But in that case it's by definition greater than i->count, so we do not
reach that assignment at all.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32-bit bug in iovec iterator changes
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 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 about *why* it fixes the
> > problem. In particular, iov_iter_iovec() makes no sense to me at all,
> > and I don't understand how the calculation of iov_len makes any sense:
> >
> > .iov_len = min(iter->count,
> >iter->iov->iov_len - iter->iov_offset),
>
> Eh? We have iov[0].iov_base..iov[0].iov_base+iov[0].iov_len - 1 for
> area covered by the first iovec. First iov_offset bytes have already
> been consumed. And at most count bytes matter. So yes, this iov_len
> will give you equivalent first iovec.
>
> Said that, iov_iter_iovec() will die shortly - it's a rudiment of older
> code, with almost no users left. But yes, it is correct.
>
> > It also looks like uio.h is mostly about offsets to memory pointers,
> > and so why this would make a difference when the issue is the block
> > device offset goes above 2**30?
>
> It is, and your patch is a huge overkill.
>
> > There must be deep magic going on here, and so I don't know if your
> > s/size_t/u64/g substitation also extends to the various functions that
> > have size_t in them:
>
> No, it does not. It's specifically about iov_iter_truncate(); moreover,
> it matters to only one caller of that sucker. Namely,
>
> static ssize_t blkdev_read_iter(struct kiocb *iocb, struct iov_iter *to)
> {
> struct file *file = iocb->ki_filp;
> struct inode *bd_inode = file->f_mapping->host;
> loff_t size = i_size_read(bd_inode);
> loff_t pos = iocb->ki_pos;
>
> if (pos >= size)
> return 0;
>
> size -= pos;
> iov_iter_truncate(to, size);
> return generic_file_read_iter(iocb, to);
> }
>
> What happens here is capping to->count, to guarantee that we won't even look
> at anything past the end of block device. Alternative fix would be to
> have
> if (pos >= size)
> return 0;
> if (to->size + pos > size) {
> /* note that size - pos fits into size_t in this case,
>* so it's OK to pass it to iov_iter_truncate().
>*/
> iov_iter_truncate(to, size - pos);
> }
> return generic_file_read_iter(iocb, to);
> in there. Other callers are passing it size_t values already, so we don't
> need similar checks there.
>
> Or we can make iov_iter_truncate() take an arbitrary u64 argument, seeing that
> it's inlined anyway. IMO it's more robust that way...
>
> 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 @@ static inline size_t iov_iter_count(struct iov_iter *i)
> return i->count;
> }
>
> -static inline void iov_iter_truncate(struct iov_iter *i, size_t count)
> +static inline void iov_iter_truncate(struct iov_iter *i, u64 count)
> {
> if (i->count > count)
> i->count = count;
Al, how can that work? i->count is size_t, which is 32 bit, so we're
going to get truncation errors. I could see this possibly working if
count in struct iov_iter becomes u64 (which is going to have a lot of
knock on consequences, but it seems to me that at least kvec.iov_len and
iov_iter.iov_offset have to become u64 as well.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32-bit bug in iovec iterator changes
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 the end) appears to fix the problem,
> but looking at uio.h, I'm completely confused about *why* it fixes the
> problem. In particular, iov_iter_iovec() makes no sense to me at all,
> and I don't understand how the calculation of iov_len makes any sense:
>
> .iov_len = min(iter->count,
> iter->iov->iov_len - iter->iov_offset),
Eh? We have iov[0].iov_base..iov[0].iov_base+iov[0].iov_len - 1 for
area covered by the first iovec. First iov_offset bytes have already
been consumed. And at most count bytes matter. So yes, this iov_len
will give you equivalent first iovec.
Said that, iov_iter_iovec() will die shortly - it's a rudiment of older
code, with almost no users left. But yes, it is correct.
> It also looks like uio.h is mostly about offsets to memory pointers,
> and so why this would make a difference when the issue is the block
> device offset goes above 2**30?
It is, and your patch is a huge overkill.
> There must be deep magic going on here, and so I don't know if your
> s/size_t/u64/g substitation also extends to the various functions that
> have size_t in them:
No, it does not. It's specifically about iov_iter_truncate(); moreover,
it matters to only one caller of that sucker. Namely,
static ssize_t blkdev_read_iter(struct kiocb *iocb, struct iov_iter *to)
{
struct file *file = iocb->ki_filp;
struct inode *bd_inode = file->f_mapping->host;
loff_t size = i_size_read(bd_inode);
loff_t pos = iocb->ki_pos;
if (pos >= size)
return 0;
size -= pos;
iov_iter_truncate(to, size);
return generic_file_read_iter(iocb, to);
}
What happens here is capping to->count, to guarantee that we won't even look
at anything past the end of block device. Alternative fix would be to
have
if (pos >= size)
return 0;
if (to->size + pos > size) {
/* note that size - pos fits into size_t in this case,
* so it's OK to pass it to iov_iter_truncate().
*/
iov_iter_truncate(to, size - pos);
}
return generic_file_read_iter(iocb, to);
in there. Other callers are passing it size_t values already, so we don't
need similar checks there.
Or we can make iov_iter_truncate() take an arbitrary u64 argument, seeing that
it's inlined anyway. IMO it's more robust that way...
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 @@ static inline size_t iov_iter_count(struct iov_iter *i)
return i->count;
}
-static inline void iov_iter_truncate(struct iov_iter *i, size_t count)
+static inline void iov_iter_truncate(struct iov_iter *i, u64 count)
{
if (i->count > count)
i->count = count;
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32-bit bug in iovec iterator changes
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 about *why* it fixes the
problem. In particular, iov_iter_iovec() makes no sense to me at all,
and I don't understand how the calculation of iov_len makes any sense:
.iov_len = min(iter->count,
iter->iov->iov_len - iter->iov_offset),
It also looks like uio.h is mostly about offsets to memory pointers,
and so why this would make a difference when the issue is the block
device offset goes above 2**30?
There must be deep magic going on here, and so I don't know if your
s/size_t/u64/g substitation also extends to the various functions that
have size_t in them:
unsigned long iov_shorten(struct iovec *iov, unsigned long nr_segs, size_t to);
size_t iov_iter_copy_from_user_atomic(struct page *page,
struct iov_iter *i, unsigned long offset, size_t bytes);
void iov_iter_advance(struct iov_iter *i, size_t bytes);
int iov_iter_fault_in_readable(struct iov_iter *i, size_t bytes);
size_t iov_iter_single_seg_count(const struct iov_iter *i);
size_t copy_page_to_iter(struct page *page, size_t offset, size_t bytes,
struct iov_iter *i);
size_t copy_page_from_iter(struct page *page, size_t offset, size_t bytes,
struct iov_iter *i);
unsigned long iov_iter_alignment(const struct iov_iter *i);
void iov_iter_init(struct iov_iter *i, int direction, const struct iovec *iov,
unsigned long nr_segs, size_t count);
ssize_t iov_iter_get_pages(struct iov_iter *i, struct page **pages,
size_t maxsize, size_t *start);
ssize_t iov_iter_get_pages_alloc(struct iov_iter *i, struct page ***pages,
size_t maxsize, size_t *start);
Anyway, this patch does appear to make the problem go away, but given
that I don't understand what is going on here, please take it with a
huge grain of salt. And might I suggest some comments to perhaps give
some context to someone who is trying to understand
include/linux/uio.h?
Thanks!!
- Ted
diff --git a/include/linux/uio.h b/include/linux/uio.h
index e2231e4..bea7b7d 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -16,7 +16,7 @@ struct page;
struct kvec {
void *iov_base; /* and that should *never* hold a userland pointer */
- size_t iov_len;
+ u64 iov_len;
};
enum {
@@ -27,8 +27,8 @@ enum {
struct iov_iter {
int type;
- size_t iov_offset;
- size_t count;
+ u64 iov_offset;
+ u64 count;
union {
const struct iovec *iov;
const struct bio_vec *bvec;
@@ -41,12 +41,12 @@ struct iov_iter {
*
* NOTE that it is not safe to use this function until all the iovec's
* segment lengths have been validated. Because the individual lengths can
- * overflow a size_t when added together.
+ * overflow a u64 when added together.
*/
-static inline size_t iov_length(const struct iovec *iov, unsigned long nr_segs)
+static inline u64 iov_length(const struct iovec *iov, unsigned long nr_segs)
{
unsigned long seg;
- size_t ret = 0;
+ u64 ret = 0;
for (seg = 0; seg < nr_segs; seg++)
ret += iov[seg].iov_len;
@@ -89,12 +89,12 @@ ssize_t iov_iter_get_pages_alloc(struct iov_iter *i, struct
page ***pages,
size_t maxsize, size_t *start);
int iov_iter_npages(const struct iov_iter *i, int maxpages);
-static inline size_t iov_iter_count(struct iov_iter *i)
+static inline u64 iov_iter_count(struct iov_iter *i)
{
return i->count;
}
-static inline void iov_iter_truncate(struct iov_iter *i, size_t count)
+static inline void iov_iter_truncate(struct iov_iter *i, u64 count)
{
if (i->count > count)
i->count = count;
@@ -104,7 +104,7 @@ static inline void iov_iter_truncate(struct iov_iter *i,
size_t count)
* reexpand a previously truncated iterator; count must be no more than how
much
* we had shrunk it.
*/
-static inline void iov_iter_reexpand(struct iov_iter *i, size_t count)
+static inline void iov_iter_reexpand(struct iov_iter *i, u64 count)
{
i->count = count;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32-bit bug in iovec iterator changes
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 not being able to partition a 32GB block > > dev on a 32 bit system due to a 32 bit size_t overflow somewhere > > Dave Chinner called it. > > Al, I'm seeing a regression which shows up using a 32-bit x86 kernel. > The symptoms of the bug is when run under KVM, with a 5 GB /dev/vdc > virtual block device, a read at offset 2 ** 30 fails with a short > read: > > # dd if=/dev/vdc of=/dev/null bs=4k skip=262144 count=1 > 0+0 records in > 0+0 records out > 0 bytes (0 B) copied, 0.0164144 s, 0.0 kB/s Argh... ed include/linux/uio.h
