[OE-core] [PATCH] runqemu-export-rootfs: don't change RPC ports

[Mark Hatle]

On 5/31/17 11:07 AM, Cody P Schafer wrote:
>> There's a patch that we've had for years to allow alternate RPC ports
>> to work with userspace NFS and co-exist with existing NFS servers.
> 
> Ah, I see (I should have checked that sooner). "NFS: allow nfs root
> mount to use alternate rpc ports". I can likely just pull that into my
> kernel and have things work fine without changes to
> runqemu-export-rootfs.
> 
>> This would have an impact on that functionality, so if we do need to
>> change those ports, the existing ones should be maintained with some
>> sort of option to change the nfsroot line.
> 
> Yep, that makes sense.
> 
> That said: it isn't completely clear to me that a seperate rpc program
> number (aka RPC port) is needed to avoid conflicts between 2 nfs
> instances in this case:
> 
>  - we don't have unfsd register with rpcbind (-p option), so the rpc
> program numbers won't conflict there.
>  - using nfsroot implicitly adds the 'nolock' option, so there isn't a
> conflict there
>  - I did my tests with the nfs kernel server running. There wasn't an
> immdiate issue observed with mounting and accessing both a kernel
> provided export & a unfsd provided export (using
> runqemu-export-rootfs) at the same time.
> 
> Still, I'm not too familiar with all of the ins and outs of nfs. Is
> there somewhere I've overlooked where the program numbers could
> conflict?
> 

Non-root user can't create privileged ports.

Multiple nfs-servers and/or developers on the same machine could end up with
port conflicts, so we need to make sure the ports can 'change'.

Of course running this on a machine that has a traditional NFS server will also
cause a conflict.   The various rpmbind and other options may reduce the
likelihood of a conflict -- but they can still occur.  It's better to use unique
port information on a per-use basis to avoid any potential conflicts or
privileged port requirements.

--Mark