is NFS mounting borked in bb-1.1.1?

Kumar Gala galak at kernel.crashing.org
Wed Mar 29 23:16:00 PST 2006


On Mar 29, 2006, at 7:03 PM, Rob Landley wrote:

> On Wednesday 29 March 2006 2:32 pm, Kumar Gala wrote:
>
>>>> # mount /local
>>>> mount: Mounting  on /local failed: Invalid argument
>>>
>>> Huh.  Parsing the above, it looks like it should do a:
>>>
>>>   mount -t nfs -o defaults,nolock kgala_lnx:/local /local
>>>
>>> Does that work?
>>
>> Yes that works.
>
> Ok, so singlemount() and mount_it_now() are ok, and the problem's in
> mount_main().

correct.

>>>> We should probably only match on mtcur->mnt_dir if mtcur->type ==
>>>> "nfs"
>>>
>>> Even if you didn't say noauto?
>>
>> Well, I'd assume we would still do the MOUNT_NOAUTO | MOUNT_SWAP
>> testing.
>
> mount -a should match everything that doesn't have "noauto" set, I  
> mean...

mount -a works properly.

>>>> , however I dont see how we would actual call singlemount() even
>>>> if we matched the mtcur.
>>>
>>> mntgetent_r() populates a structure from fstab.  We keep two
>>> structures: the
>>> current one we're looking at and the last one we found.  That's the
>>> swapping
>>> mtcur and mtnext part, they both point to mtpair.  At the start of
>>> the loop,
>>> mtnext is pointed at whichever one mtcur doesn't point to.  When we
>>> load an
>>> mtcur we want to keep, we point mtcur at mtnext so the next load  
>>> will
>>> overwrite the other one.
>>>
>>> When we hit the end of the list we look at the last match (which is
>>> in mtnext,
>>> the one we _didn't_ load.)
>>>
>>> I was calling mtnext "mtother" for a while, but it was
>>> approximately as
>>> confusing either way.  mtswap, perhaps?
>>
>> But we dont do anything with mtnext which is my confusion.  I believe
>> what's happening in my case is we iterate over all entries in /etc/
>> fstab dont find a match and fall through to the end of the file rc=1
>> so I get the "Mounting ... failed" error.
>
> Yeah, that could be the case.  The check for
> strcmp(argv[optind],mtcur->mnt_dir) should be triggering, though,  
> which means
> that mtcur should be toggled to the other slot, and the data we  
> read earlier
> should be waiting for us in mtnext when we hit the end of the loop.
>
> I take it this is not happening...

Actually I think this is working properly (maybe)

>> The only way we mount anything is if optind == argc.  In my case
>> optind = 1 and argc = 2.  Thus no mater what matching occurs we
>> aren't going to mount anything.
>
> No, when we hit the end of the list, getmntent_r() should return 0,  
> which goes
> through into the test with the comment "Were we looking for something
> specific?", which is for optind != argc, and then makes use of  
> mtnext...

Ok, now I think I understand the issue.  While the pointer swapping  
between mtcur and mtnext works, these data structures contain  
pointers that point into bb_common_bufsiz1.  One find a match, swap  
mtcur & mtnext.  Once we call getmntent_r we end up changing  
bb_common_bufsiz1 which means whatever mtnext points out is now bogus.

So when we swap mtnext/mtcur we also need to swap bb_common_bufsiz1  
to another buffer.  Is there another standard buffer we can use?

- kumar




More information about the busybox mailing list