All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH] Rewrite and fix grub_bufio_read()
Date: Fri, 29 Apr 2016 06:50:46 +0300	[thread overview]
Message-ID: <5722DA16.6040706@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1604282129550.23497@eru.sfritsch.de>

28.04.2016 22:52, Stefan Fritsch пишет:
> On Thu, 28 Apr 2016, Andrei Borzenkov wrote:
> 
>> 28.04.2016 14:11, Stefan Fritsch пишет:
>>> We had problems downloading large (10-100 MB) gziped files via http
>>> with grub. After some debugging, I think I have found the reason in
>>> grub_bufio_read, which leads to wrong data being passed on. This patch
>>> fixes the issues for me.  I did my tests with a somewhat older
>>> snapshot, but the bufio.c file is the same.
>>>
>>
>> Please send minimal patch that fixes bug in bufio so we can actually see
>> where the bug is and apply bug fix for 2.02. It is impossible to deduce
>> from your complete rewrite and this patch is too intrusive for 2.02
>> irrespectively of considerations below.
>>
>>> Cheers,
>>> Stefan
>>>
>>> The grub_bufio_read() had some issues:
>>>
>>> * in the calculation of next_buf, it assumed that bufio->block_size is a
>>>   power of 2, which is not always the case (see code in grub_bufio_open()).
>>>
>>
>> All current callers set it to power of 2, although you are right that it
>> should verify it.
> 
> No:
> 
>   if ((size < 0) || ((unsigned) size > io->size))
>     size = ((io->size > GRUB_BUFIO_MAX_SIZE) ? GRUB_BUFIO_MAX_SIZE :
>             io->size);
> 
> ...
> 
>   bufio->block_size = size;
> 
> io->size is the file size. So at least for files < 32K (which is the size 
> that bufio is called with by the net layer), block_size is not a power of 
> 2 but the size of the file. Then next_buf typically gets a value from 0 
> to 8.
> 


Ah, OK. Not sure why we need this check in the first place. Buffer size
is unrelated to file size, so this looks more like micro-optimization of
buffer size.

Although this means that we always have the whole file in buffer anyway
and so never hit power of 2 issue.


      parent reply	other threads:[~2016-04-29  3:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-28 11:11 [PATCH] Rewrite and fix grub_bufio_read() Stefan Fritsch
2016-04-28 17:49 ` Andrei Borzenkov
2016-04-28 19:52   ` Stefan Fritsch
2016-04-28 21:30     ` gzio/http problem (was: [PATCH] Rewrite and fix grub_bufio_read()) Stefan Fritsch
2016-04-28 21:54       ` Vladimir 'phcoder' Serbinenko
2016-04-29  4:08         ` gzio/http problem Andrei Borzenkov
2016-04-29 21:00           ` Stefan Fritsch
2016-04-30  6:21             ` Andrei Borzenkov
2016-04-29  3:50     ` Andrei Borzenkov [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=5722DA16.6040706@gmail.com \
    --to=arvidjaar@gmail.com \
    --cc=grub-devel@gnu.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.