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

[Devon O'Dell]

On Mon, Nov 07, 2005 at 05:49:47PM -0500, John Baldwin wrote:
> 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. :)

Understood :)
 
> > > >  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.

OK. I wasn't sure what all would be involved in doing such a thing. Again,
in Plan 9, it's a non-issue. You import the devices from a remote location
and you can do standard file operations. I guess this might be a much more
long-term project and I probably won't be able to address this immediately,
but it would indeed be a fun thing to see -- if it's worth the work at
all.

> > 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.

Ok. Hopefully someone who knows more about it can take a closer look then.
I know I discussed this with scottl@, but I'm not sure what the plans are
with regard to committing it (he said he would, but I don't know how busy
he is with his cool amr work) in what timeframe. Doesn't really matter
much, but I think it should get a competent review, considering that I'm
a VFS newbie (and relatively new with kernel stuff as well, anyway).
 
> > 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.

Alright. I will make a point of trying to make more of the code use
wrappers around our syscalls, at least for the VFS stuff (since I'm
already working around that area anyway).

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

Thanks for the input!

--Devon