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