netdev - Re: STMMAC driver: NFS Problem on 2.6.37

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:	Wed, 9 Feb 2011 16:26:16 -0500
From:	Chuck Lever <chuck.lever@...cle.com>
To:	Brian Downing <bdowning@...os.net>
Cc:	deepaksi <deepak.sikri@...com>,
	Armando VISCONTI <armando.visconti@...com>,
	Trond Myklebust <Trond.Myklebust@...app.com>,
	netdev@...r.kernel.org,
	Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
	Shiraz HASHIM <shiraz.hashim@...com>,
	Viresh KUMAR <viresh.kumar@...com>,
	Peppe CAVALLARO <peppe.cavallaro@...com>,
	amitgoel <amit.goel@...com>
Subject: Re: STMMAC driver: NFS Problem on 2.6.37


On Feb 9, 2011, at 3:58 PM, Brian Downing wrote:

> On Wed, Feb 09, 2011 at 03:12:22PM -0500, Chuck Lever wrote:
>> Based on your console logs, I see that the working case uses UDP to
>> contact the server's mountd, but the failing case uses TCP.  You can
>> try explicitly specifying "proto=udp" to force the use of UDP, to test
>> this theory.
> 
> This does indeed make it work again for me, thanks!
> 
>> Meanwhile, the patch description explicitly states that the default
>> mount option settings have changed.  Does it make sense to change the
>> default behavior of NFSROOT mounts to use UDP again?  I don't see
>> another way to make this process more reliable across NIC
>> initialization.  If this is considered a regression, we can make a
>> patch for 2.6.38-rc and 2.6.37.
> 
> I only use nfsroot for development, so I don't have a terribly strong
> opinion.  I would point out though that the default u-boot parameters
> for nfsrooting a lot of boards will no longer work at this point, so if
> it's not patched to work again without specifying nfs options I think
> there should at least be a note in the documentation and possibly a
> "maybe try proto=udp?" console message on failure.
> 
> I assume it's not feasable to either wait until the chosen interface's
> link is ready before trying to mount nfsroot, or retrying TCP-based
> connections a little bit more aggressively/at all?

Our goal is to use the same mount logic for both normal user space mounts and for NFSROOT (that was the purpose of the patch series this particular patch comes from).  It's exceptionally difficult to add a special case for retrying TCP connections here, as that would change the behavior of user space mounts, which often want to fail quickly, and don't need to worry about NIC initialization.

Sounds like the right thing to do is restore the default UDP behavior.  I'll cook up a patch.

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html