All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andries E. Brouwer" <Andries.Brouwer@cwi.nl>
To: "Cox, Alan" <alan.cox@intel.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"aeb@cwi.nl" <Andries.Brouwer@cwi.nl>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Cannot partition 32GB disk on a 32bit machine (correct version of the patch this time)
Date: Thu, 19 Jun 2014 23:12:11 +0200	[thread overview]
Message-ID: <20140619211211.GA30404@jp> (raw)
In-Reply-To: <1403170400.10778.38.camel@acox1-desk.ger.corp.intel.com>

On Thu, Jun 19, 2014 at 09:33:26AM +0000, Cox, Alan wrote:
> On Thu, 2014-06-19 at 10:30 +0100, Alan Cox wrote:
> > The block code has 32bit cleanness problems with the iterator. This
> > prevents things like partitioning a 32GB volume on a 32bit system.
> > 
> > I hit this with a volume of exactly 32GB in size (easy to duplicate with
> > virtual machines). Tracing at step by step through the kernel I found
> > the problem lines in blkdev_read_iter which truncates the size value
> > into a 32bit value when setting up the iterator.
> 
> This is a simple initial "fix" that clips the problem cases so get
> behaviour that is at least sane and trivially backportable.
> 
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> ---
>  fs/block_dev.c |    3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/block_dev.c b/fs/block_dev.c
> index 6d72746..bef2414 100644
> --- a/fs/block_dev.c
> +++ b/fs/block_dev.c
> @@ -1603,6 +1603,9 @@ static ssize_t blkdev_read_iter(struct kiocb
> *iocb, struct iov_iter *to)
>  
>  	size -= pos;
>  	iov_iter_truncate(to, size);
> +	/* Fix up for 32bit boxes for now */
> +	if (to->count < size)
> +	        to->count = 0xFFFFFFFF;
>  	return generic_file_read_iter(iocb, to);
>  }


It is ages ago that I last looked at such things.
Certainly I have partitioned 160GB+ disks on 32-bit machines, years ago,
so maybe the problem is due to recent bitrot, e.g. the use of a size_t
instead of a loff_t somewhere.

Fetched linux-3.15.1 and linux-3.16-rc1 tar balls.
The diff shows

-static ssize_t blkdev_aio_read(struct kiocb *iocb, const struct iovec *iov,
-                        unsigned long nr_segs, loff_t pos)
+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;
-       if (size < iocb->ki_nbytes)
-               nr_segs = iov_shorten((struct iovec *)iov, nr_segs, size);
-       return generic_file_aio_read(iocb, iov, nr_segs, pos);
+       iov_iter_truncate(to, size);
+       return generic_file_read_iter(iocb, to);
 }

that a test of size was deleted.

In older kernels the test was

        if (size < INT_MAX)
                nr_segs = iov_shorten((struct iovec *)iov, nr_segs, size);

which more clearly shows that this is because the last arg of iov_shorten()
is a size_t. In later source this is called iov_iter_truncate,

static inline void iov_iter_truncate(struct iov_iter *i, size_t count)

still with a size_t as lat arg, so probably the test is still needed.

Andries

      parent reply	other threads:[~2014-06-19 21:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-19  9:30 Cannot partition 32GB disk on a 32bit machine Alan Cox
2014-06-19  9:33 ` Cannot partition 32GB disk on a 32bit machine (correct version of the patch this time) Cox, Alan
2014-06-19  9:33   ` Cox, Alan
2014-06-19 18:43   ` James Bottomley
2014-06-19 18:43     ` James Bottomley
2014-06-19 20:51     ` Andrew Morton
2014-06-19 21:12     ` Paul Bolle
2014-06-19 23:04     ` Alan Cox
2014-06-19 23:44       ` James Bottomley
2014-06-19 21:12   ` Andries E. Brouwer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140619211211.GA30404@jp \
    --to=andries.brouwer@cwi.nl \
    --cc=akpm@linux-foundation.org \
    --cc=alan.cox@intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.