amd64/88249: getdents syscall fails for devfs on amd64 linuxalator

[John Baldwin]

On Monday 07 November 2005 05:19 pm, Devon O'Dell wrote:
> On Mon, Nov 07, 2005 at 04:32:49PM -0500, John Baldwin wrote:
> > On Monday 07 November 2005 03:00 pm, Devon O'Dell wrote:
> > >  The long discussion ended up implying several things:
> > >
> > >  d) The issue probably isn't limited to linuxulator, but to any
> > >     filesystem that uses cookies and exports devfs. Thus, panics (or
> > >     hangs) will probably occur for devfs being exported over AFS or
> > > NFS.
> >
> > Well, it shouldn't panic, that's for sure.
>
> It currently does in linuxulator; I'm only assuming it'd do so as well when
> trying to export the devfs over another cookie-enabled filesystem, just
> from how devfs works when you give it cookies (i.e. not at all).

My point there is that some sort of fix should be committed certainly.  panics 
bad. :)

> > >  The attached patch does two things:
> > >
> > >  a) If we are provided with cookie information in devfs, we currently
> > >     do not support this. This means we cannot export devfs over network
> > >     mounts, which I don't view as a problem (but would be a cool
> > >     feature).
> >
> > Actually, it would be a worse than useless feature when you consider
> > dynamic major number allocation (so that /dev/cuad0 on one machine might
> > map to /dev/acd0 on another machine) not to mention the fact that on
> > FreeBSD, at least, we don't have specfs anymore, so you can't look
> > devices up by just major/minor, but it has to be by their name through an
> > instance of devfs. So, only non-FreeBSD clients could even use the
> > exported char devs, and FreeBSD char devs are less than useless on
> > non-FreeBSD operating systems.
>
> Ah, ok. I was thinking in a Plan 9-ish sense: being able to export devices
> to another system and give the remote system the ability to control those
> devices, but I guess I was misinterpreting how that'd work.

Yeah, I think that would be a substantially more complex task, but I could be 
wrong I suppose.  phk@ would really be best able to address this.  The only 
way it could work is if the client OS knows to forward requests to exported 
devices via NFS to the server, in which case I think you'd end up with all 
sorts of weird edge cases (but that's beside the point).  The issues above 
have to do with when the client OS decides to interpret the block devices 
natively via specfs rather than forwarding them across via NFS.  Given that 
this might require changes in various clients of arbitrary OSs I'm not sure 
if it is worth persuing.

> Do you think that the attached patch is the correct behavior? I have
> another patch that begins work on some of the architectural changes, but it
> allows devfs to make use of cookies. I suppose this would imply that you
> could then export devfs, but it wouldn't ever work due to the points you
> describe above. Any ideas on how to get around or disallow this behavior
> altogether?

I haven't really gone and read enough vfs code to give the specific patch a 
competent review.

> From the standpoint of how the linuxulator works with the cookies (also
> apparently not very well at all), would it be better to do:
>
> a) Make linux_file.c:getdents_common() be a wrapper around our own
>    dirent syscall, or
>
> b) Update linux_file.c: getdents_common() to look more like our syscall?
>
> It seems to me that it should be possible to do point a; indeed, I don't
> understand why most of the linux file syscall translation code
> re-implements a lot of the code (almost verbatim) that we have in other
> syscalls, when it appears that we could just wrap them.

a) would certainly be preferable.  As for why there's a lot of duplicated 
code, it seems that the initial work on compat ABIs used the cut 'n' paste 
'n' hack method to implement emulated syscalls rather than wrappers and the 
use of wrappers is actually a relatively recent change.  Thus, there's still 
a lot of room for more cleanup via more widespread use of wrappers.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org