qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Amjad Alsharafi <amjadsharafi10@gmail.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, Hanna Reitz <hreitz@redhat.com>,
	"open list:vvfat" <qemu-block@nongnu.org>
Subject: Re: [PATCH v5 4/5] vvfat: Fix reading files with non-continuous clusters
Date: Fri, 19 Jul 2024 08:20:00 +0800	[thread overview]
Message-ID: <ZpmxMEj5qZDUhj_h@amjad-pc> (raw)
In-Reply-To: <ZpkyxA3s_gzQE7gW@redhat.com>

On Thu, Jul 18, 2024 at 05:20:36PM +0200, Kevin Wolf wrote:
> Am 12.06.2024 um 14:43 hat Amjad Alsharafi geschrieben:
> > When reading with `read_cluster` we get the `mapping` with
> > `find_mapping_for_cluster` and then we call `open_file` for this
> > mapping.
> > The issue appear when its the same file, but a second cluster that is
> > not immediately after it, imagine clusters `500 -> 503`, this will give
> > us 2 mappings one has the range `500..501` and another `503..504`, both
> > point to the same file, but different offsets.
> > 
> > When we don't open the file since the path is the same, we won't assign
> > `s->current_mapping` and thus accessing way out of bound of the file.
> > 
> > From our example above, after `open_file` (that didn't open anything) we
> > will get the offset into the file with
> > `s->cluster_size*(cluster_num-s->current_mapping->begin)`, which will
> > give us `0x2000 * (504-500)`, which is out of bound for this mapping and
> > will produce some issues.
> > 
> > Signed-off-by: Amjad Alsharafi <amjadsharafi10@gmail.com>
> > ---
> >  block/vvfat.c | 23 ++++++++++++++++-------
> >  1 file changed, 16 insertions(+), 7 deletions(-)
> > 
> > diff --git a/block/vvfat.c b/block/vvfat.c
> > index b63ac5d045..fc570d0610 100644
> > --- a/block/vvfat.c
> > +++ b/block/vvfat.c
> > @@ -1360,15 +1360,24 @@ static int open_file(BDRVVVFATState* s,mapping_t* mapping)
> >  {
> >      if(!mapping)
> >          return -1;
> > +    int new_path = 1;
> >      if(!s->current_mapping ||
> > -            strcmp(s->current_mapping->path,mapping->path)) {
> > -        /* open file */
> > -        int fd = qemu_open_old(mapping->path,
> > +            s->current_mapping->info.file.offset
> > +                != mapping->info.file.offset ||
> 
> I'm wondering if this couldn't just be s->current_mapping != mapping?

Actually, you are totally right. Not sure what made me go for this.

I tried also to test with only checking if the path changed, but it
fails on some tests. So the offset is important.
For that reason, checking just the mapping ptr is better since we won't
have 2 mappings with same file and offset.

I'll then use this change. Thanks

> 
> > +            (new_path = strcmp(s->current_mapping->path, mapping->path))) {
> 
> If both the path and the offset change, we still want to set new_path, I
> think. And if we didn't already have a mapping, we also need to open the
> file.
> 
> Actually, setting a variable inside the condition makes it kind of hard
> to read, so if s->current_mapping != mapping works, we can do the check
> only in the conditon below:
> 
> > +        if (new_path) {
> 
> if (!s->current_mapping ||
>     strcmp(s->current_mapping->path, mapping->path))
> 
> > +            /* open file */
> > +            int fd = qemu_open_old(mapping->path,
> >                                 O_RDONLY | O_BINARY | O_LARGEFILE);
> > -        if(fd<0)
> > -            return -1;
> > -        vvfat_close_current_file(s);
> > -        s->current_fd = fd;
> > +            if (fd < 0) {
> > +                return -1;
> > +            }
> > +            vvfat_close_current_file(s);
> > +
> > +            s->current_fd = fd;
> > +        }
> > +        assert(s->current_fd);
> >          s->current_mapping = mapping;
> >      }
> 
> Kevin
> 


  reply	other threads:[~2024-07-19  0:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-12 12:43 [PATCH v5 0/5] vvfat: Fix write bugs for large files and add iotests Amjad Alsharafi
2024-06-12 12:43 ` [PATCH v5 1/5] vvfat: Fix bug in writing to middle of file Amjad Alsharafi
2024-08-11  7:48   ` Michael Tokarev
2024-06-12 12:43 ` [PATCH v5 2/5] vvfat: Fix usage of `info.file.offset` Amjad Alsharafi
2024-07-18 15:30   ` Kevin Wolf
2024-06-12 12:43 ` [PATCH v5 3/5] vvfat: Fix wrong checks for cluster mappings invariant Amjad Alsharafi
2024-07-18 15:31   ` Kevin Wolf
2024-06-12 12:43 ` [PATCH v5 4/5] vvfat: Fix reading files with non-continuous clusters Amjad Alsharafi
2024-07-18 15:20   ` Kevin Wolf
2024-07-19  0:20     ` Amjad Alsharafi [this message]
2024-07-19  0:29       ` Amjad Alsharafi
2024-07-19  8:22         ` Kevin Wolf
2024-06-12 12:43 ` [PATCH v5 5/5] iotests: Add `vvfat` tests Amjad Alsharafi
2024-06-13 14:07   ` Amjad Alsharafi
2024-06-13 17:32     ` Kevin Wolf
2024-07-18 15:30   ` Kevin Wolf
2024-07-01 13:45 ` [PATCH v5 0/5] vvfat: Fix write bugs for large files and add iotests Amjad Alsharafi
2024-08-11  7:51 ` Michael Tokarev
2024-08-11  9:52   ` Amjad Alsharafi
2024-08-11 10:09     ` Michael Tokarev
2024-08-11 10:19       ` Amjad Alsharafi
2024-08-11 14:45         ` Michael Tokarev
2024-08-12  1:36           ` Amjad Alsharafi
2024-08-13  8:52   ` Kevin Wolf

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=ZpmxMEj5qZDUhj_h@amjad-pc \
    --to=amjadsharafi10@gmail.com \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).