From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1GCaHo-0004RO-PX for user-mode-linux-devel@lists.sourceforge.net; Mon, 14 Aug 2006 04:07:12 -0700 Received: from nf-out-0910.google.com ([64.233.182.186]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1GCaHm-0008Ks-Lw for user-mode-linux-devel@lists.sourceforge.net; Mon, 14 Aug 2006 04:07:12 -0700 Received: by nf-out-0910.google.com with SMTP id a27so27428nfc for ; Mon, 14 Aug 2006 04:07:08 -0700 (PDT) Message-ID: <39134b110608140407n718d0cf5rfed71f8295ea43e0@mail.gmail.com> Date: Mon, 14 Aug 2006 19:07:08 +0800 From: "wang lianwei" In-Reply-To: <200608122022.42389.blaisorblade@yahoo.it> MIME-Version: 1.0 References: <39134b110608100842p5acdf798o807b48801ea9a706@mail.gmail.com> <200608122022.42389.blaisorblade@yahoo.it> Subject: Re: [uml-devel] UML hostfs bugs List-Id: The user-mode Linux development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1325291242==" Sender: user-mode-linux-devel-bounces@lists.sourceforge.net Errors-To: user-mode-linux-devel-bounces@lists.sourceforge.net To: Blaisorblade Cc: user-mode-linux-devel@lists.sourceforge.net --===============1325291242== Content-Type: multipart/alternative; boundary="----=_Part_166800_23667354.1155553628045" ------=_Part_166800_23667354.1155553628045 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Answers: 1. I test it on ext3 filesystem. 2. You are right. Sometimes the pos telldir returned is not the next entry offset. just as your point out: position 0 -> readdir "." -> you call telldir -> it _again_ says you're at 0. 3. I also try to resolve it by remove the seekdir(only use the sequence readdir call), It is also worked. --- linux-2.6.x/fs/hostfs/hostfs_kern.c 2006-04-12 15:12:51.000000000 +0800 +++ linux-2.6.10-src/fs/hostfs/hostfs_kern.c 2006-08-14 18:25: 13.772237744 +0800 @@ -338,6 +338,7 @@ kfree(name); if(dir == NULL) return(-error); next = file->f_pos; + seekdir(dir,next); while((name = read_dir(dir, &next, &ino, &len)) != NULL){ error = (*filldir)(ent, name, len, file->f_pos, ino, DT_UNKNOWN); --- linux-2.6.x/fs/hostfs/hostfs_user.c 2006-04-12 15:12:52.000000000 +0800 +++ linux-2.6.10-src/fs/hostfs/hostfs_user.c 2006-08-14 18:36: 24.276305632 +0800 @@ -122,7 +122,6 @@ DIR *dir = stream; struct dirent *ent; - seekdir(dir, *pos); ent = readdir(dir); if(ent == NULL) return(NULL); *len_out = strlen(ent->d_name); 2006/8/13, Blaisorblade : > > On Thursday 10 August 2006 17:42, wang lianwei wrote: > > Hi all, > > > > There is a bug with UML kernel, some host directory can not be read, for > > > example "ls /mnt/host/usr/lib", this command is dead until you press > > CTRL+c. I test it with Redhat Enterprise Linux 4. > > Yes, this has been reported various times but difficult to reproduce, so > we're > very happy somebody diagnosed it, and I'd be interested in understanding > it > better. > > On which filesystem (ext3, reiserfs, what else) lays /usr/lib on the host? > > This is because the UML read host directory through opendir, seekdir, > > readdir and telldir. When get the dir stream offset through telldir, it > > always return 0 on some directory, for example".", > > Can you elaborate on this? (And if possible post some details, like a > strace) > > What I've understood is: > > position 0 -> you read "." -> you call telldir -> it _again_ says you're > at 0? > > I can maybe understand why it could happen. I'd be more interested in > checking > if a simple sequence of readdir() calls (without seekdir()) would work > (probably write a standalone test program, it will be easier to use and > debug) and why read_dir needs to do seekdir (I think it's done to handle > calls to seekdir by the underlying process, but there should be different > ways to do it). > > > I don't know why? But > > we can fix it as follows although the next dir entry offset is not > exact: > > > Modify the fs/hostfs/hostfs_user.c file, update the read_dir function, > > > > char *read_dir(void *stream, unsigned long long *pos, > > unsigned long long *ino_out, int *len_out) > > { > > DIR *dir = stream; > > struct dirent *ent; > > unsigned long long oldpos; > > > > oldpos = *pos; > > > > seekdir(dir, *pos); > > ent = readdir(dir); > > if(ent == NULL) > > { > > return(NULL); > > } > > *len_out = strlen(ent->d_name); > > *ino_out = ent->d_ino; > > *pos = telldir(dir); > > > > /* Fix the telldir return 0 error */ > > if (*pos == 0) > > *pos = oldpos + *len_out; > > > > return(ent->d_name); > > } > > > > although the next offset is not exact, but the readdir can get the next > > entry correct. > > This probably depends heavily on the underlying filesystem... > > > Can anyone give a better solution? > > I can't yet, but maybe with your help we'll be able. > -- > Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". > Paolo Giarrusso, aka Blaisorblade > http://www.user-mode-linux.org/~blaisorblade > Chiacchiera con i tuoi amici in tempo reale! > http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com > > ------=_Part_166800_23667354.1155553628045 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Answers:
 
1. I test it on ext3 filesystem.

2. You are right. Sometimes the pos telldir returned is not the next entry offset. just as your point out:
      position 0 -> readdir "." -> you call telldir -> it _again_ says you're at 0. 
 
3. I also try to resolve it by remove the seekdir(only use the sequence readdir call), It is also worked.
 
--- linux-2.6.x/fs/hostfs/hostfs_kern.c 2006-04-12 15:12:51.000000000 +0800
+++ linux-2.6.10-src/fs/hostfs/hostfs_kern.c      2006-08-14 18:25:13.772237744 +0800
@@ -338,6 +338,7 @@
        kfree(name);
        if(dir == NULL) return(-error);
        next = file->f_pos;
+       seekdir(dir,next);
        while((name = read_dir(dir, &next, &ino, &len)) != NULL){
                error = (*filldir)(ent, name, len, file->f_pos,
                                   ino, DT_UNKNOWN);
 

--- linux-2.6.x/fs/hostfs/hostfs_user.c 2006-04-12 15:12:52.000000000 +0800
+++ linux-2.6.10-src/fs/hostfs/hostfs_user.c      2006-08-14 18:36:24.276305632 +0800
@@ -122,7 +122,6 @@
        DIR *dir = stream;
        struct dirent *ent;

-       seekdir(dir, *pos);
        ent = readdir(dir);
        if(ent == NULL) return(NULL);
        *len_out = strlen(ent->d_name);


 
 
 
2006/8/13, Blaisorblade <blaisorblade@yahoo.it>:
On Thursday 10 August 2006 17:42, wang lianwei wrote:
> Hi all,
>
> There is a bug with UML kernel, some host directory can not be read, for
> example "ls /mnt/host/usr/lib", this command is dead until you press
> CTRL+c. I test it with Redhat Enterprise Linux 4.

Yes, this has been reported various times but difficult to reproduce, so we're
very happy somebody diagnosed it, and I'd be interested in understanding it
better.

On which filesystem (ext3, reiserfs, what else) lays /usr/lib on the host?
> This is because the UML read host directory through opendir, seekdir,
> readdir and telldir. When get the dir stream offset through telldir, it
> always return 0 on some directory, for example".",

Can you elaborate on this? (And if possible post some details, like a strace)

What I've understood is:

position 0 -> you read "." -> you call telldir -> it _again_ says you're at 0?

I can maybe understand why it could happen. I'd be more interested in checking
if a simple sequence of readdir() calls (without seekdir()) would work
(probably write a standalone test program, it will be easier to use and
debug) and why read_dir needs to do seekdir (I think it's done to handle
calls to seekdir by the underlying process, but there should be different
ways to do it).

> I don't know why? But
> we can fix it as follows although the next dir entry offset is not exact:

> Modify the fs/hostfs/hostfs_user.c file, update the read_dir function,
>
> char *read_dir(void *stream, unsigned long long *pos,
>                unsigned long long *ino_out, int *len_out)
> {
>         DIR *dir = stream;
>         struct dirent *ent;
>         unsigned long long oldpos;
>
>         oldpos = *pos;
>
>         seekdir(dir, *pos);
>         ent = readdir(dir);
>         if(ent == NULL)
>         {
>                 return(NULL);
>         }
>         *len_out = strlen(ent->d_name);
>         *ino_out = ent->d_ino;
>         *pos = telldir(dir);
>
>         /* Fix the telldir return 0 error */
>         if (*pos == 0)
>                 *pos = oldpos + *len_out;
>
>         return(ent->d_name);
> }
>
> although the next offset is not exact, but the readdir can get the next
> entry correct.

This probably depends heavily on the underlying filesystem...

> Can anyone give a better solution?

I can't yet, but maybe with your help we'll be able.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com


------=_Part_166800_23667354.1155553628045-- --===============1325291242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 --===============1325291242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel --===============1325291242==--