linux-kernel - Re: [bisect] kernel 2.6.38 regression with root nfs mounting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 25 Mar 2011 09:26:17 -0400
From:	Chuck Lever <chuck.lever@...cle.com>
To:	Belisko Marek <marek.belisko@...il.com>
Cc:	Trond.Myklebust@...app.com, broonie@...nsource.wolfsonmicro.com,
	bdowning@...os.net, linux-nfs@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [bisect] kernel 2.6.38 regression with root nfs mounting


On Mar 25, 2011, at 3:24 AM, Belisko Marek wrote:

> On Wed, Mar 23, 2011 at 3:54 PM, Chuck Lever <chuck.lever@...cle.com> wrote:
>> 
>> On Mar 23, 2011, at 10:30 AM, Belisko Marek wrote:
>> 
>> The server is advertising NFS over UDP.  Why can't a client access your server via UDP?  What happens if you perform a normal post-boot mount of this file system via UDP?
> Strange (rootfs mounted from SD card and try to mount nfs always fail)
> 
> mount -t nfs -o udp 10.146.1.21:/home/open-nandra/rootfs /mnt
> svc: failed to register lockdv1 RPC service (errno 111).
> lockd_up: makesock failed, error=-111
> mount: mounting 10.146.1.21:/home/open-nandra/rootfs on /mnt failed:
> Connection refused
> # mount -t nfs -o tcp 10.146.1.21:/home/open-nandra/rootfs /mnt
> svc: failed to register lockdv1 RPC service (errno 111).
> mount: mounting 10.146.1.21:/home/open-nandra/rootfs on /mnt failed:
> Connection refused

The client system isn't running a portmapper that its NFS client (specifically lockd) can talk to.  That "connection refused" is due to an incorrect client configuration.  A simple workaround might be to specify the "nolock" mount option for this test.

> 
>> 
>>>>>    100227    2   udp   2049
>>>>>    100227    3   udp   2049
>>>>>    100005    1   udp  58278  mountd
>>>>>    100005    1   tcp  37178  mountd
>>>>>    100005    2   udp  58278  mountd
>>>>>    100005    2   tcp  37178  mountd
>>>>>    100005    3   udp  58278  mountd
>>>>>    100005    3   tcp  37178  mountd
>>>> 
>>>> Can you boot if you specify either the "tcp" or "proto=tcp" NFSROOT mount options?
>>> When add proto=tcp to bootargs it boot fine
>>> (....nfsroot=10.146.1.21:/home/open-nandra/rootfs,proto=tcp....).
>>>> Perhaps a network trace would be probative.  Capture on the server with "tcpdump -s0 -w /tmp/foo ip 10.146.1.199" (untested, but I think you get the idea) while the client is attempting to boot, and post.
>>> Log is attached in attachment (too big 4.8M). Correct form is: tcpdump
>>> -s0 -w /tmp/foo host 10.146.1.199
>> 
>> Received.  I should have been clear: Please capture a non-working client boot attempt.  To reduce the size of the attachment, strip the TFTP packets before sending, and please gzip the file.
> tcpdump log from wrong attemp in attachment.

According to the trace, the mount succeeds, and NFS requests are working.  However, the server's replies to READ requests are not being seen by the client.  Something on the client host or in the network is dropping them.  I see successful 16KB reads, but 32KB reads do not work.  Check your client for packet filtering (either intentional filtering, or accidental filtering due to configuration issues).

I'll revisit the mount option defaults for NFSROOT again.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/