Jan Beulich
2011-May-26 09:47 UTC
[Xen-devel] [PATCH] linux-2.6.18/blkback: don''t fail empty barrier requests
The sector number on empty barrier requests may (will?) be
uninitialized (neither bio_init() nor rq_init() set the respective
fields), which allows for exceeding the actual (virtual) disk''s size.
Inspired by Konrad''s "When writting barriers set the sector number
to
zero...", but instead of zapping the sector number (which is wrong for
non-empty ones) just ignore the sector number when the sector count is
zero.
While at it also add overflow checking to the math in vbd_translate().
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
--- a/drivers/xen/blkback/vbd.c
+++ b/drivers/xen/blkback/vbd.c
@@ -108,8 +108,14 @@ int vbd_translate(struct phys_req *req,
if ((operation != READ) && vbd->readonly)
goto out;
- if (unlikely((req->sector_number + req->nr_sects) > vbd_sz(vbd)))
- goto out;
+ if (likely(req->nr_sects)) {
+ blkif_sector_t end = req->sector_number + req->nr_sects;
+
+ if (unlikely(end < req->sector_number))
+ goto out;
+ if (unlikely(end > vbd_sz(vbd)))
+ goto out;
+ }
req->dev = vbd->pdevice;
req->bdev = vbd->bdev;
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-May-26 12:41 UTC
Re: [Xen-devel] [PATCH] linux-2.6.18/blkback: don''t fail empty barrier requests
On Thu, May 26, 2011 at 10:47:58AM +0100, Jan Beulich wrote:> The sector number on empty barrier requests may (will?) be > uninitialized (neither bio_init() nor rq_init() set the respective > fields), which allows for exceeding the actual (virtual) disk''s size. > > Inspired by Konrad''s "When writting barriers set the sector number to > zero...", but instead of zapping the sector number (which is wrong for > non-empty ones) just ignore the sector number when the sector count is > zero. > > While at it also add overflow checking to the math in vbd_translate(). > > Signed-off-by: Jan Beulich <jbeulich@novell.com> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>Acked-by.> > --- a/drivers/xen/blkback/vbd.c > +++ b/drivers/xen/blkback/vbd.c > @@ -108,8 +108,14 @@ int vbd_translate(struct phys_req *req, > if ((operation != READ) && vbd->readonly) > goto out; > > - if (unlikely((req->sector_number + req->nr_sects) > vbd_sz(vbd))) > - goto out; > + if (likely(req->nr_sects)) { > + blkif_sector_t end = req->sector_number + req->nr_sects; > + > + if (unlikely(end < req->sector_number)) > + goto out; > + if (unlikely(end > vbd_sz(vbd))) > + goto out; > + } > > req->dev = vbd->pdevice; > req->bdev = vbd->bdev; > > >> Subject: xen/blkback: don''t fail empty barrier requests > > The sector number on empty barrier requests may (will?) be > uninitialized (neither bio_init() nor rq_init() set the respective > fields), which allows for exceeding the actual (virtual) disk''s size. > > Inspired by Konrad''s "When writting barriers set the sector number to > zero...", but instead of zapping the sector number (which is wrong for > non-empty ones) just ignore the sector number when the sector count is > zero. > > While at it also add overflow checking to the math in vbd_translate(). > > Signed-off-by: Jan Beulich <jbeulich@novell.com> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > > --- a/drivers/xen/blkback/vbd.c > +++ b/drivers/xen/blkback/vbd.c > @@ -108,8 +108,14 @@ int vbd_translate(struct phys_req *req, > if ((operation != READ) && vbd->readonly) > goto out; > > - if (unlikely((req->sector_number + req->nr_sects) > vbd_sz(vbd))) > - goto out; > + if (likely(req->nr_sects)) { > + blkif_sector_t end = req->sector_number + req->nr_sects; > + > + if (unlikely(end < req->sector_number)) > + goto out; > + if (unlikely(end > vbd_sz(vbd))) > + goto out; > + } > > req->dev = vbd->pdevice; > req->bdev = vbd->bdev;> _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel