linux-kernel - Re: in-kernel rpc.statd

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:	Mon, 4 Sep 2006 08:52:15 +1000
From:	Neil Brown <neilb@...e.de>
To:	Bernd Eckenfels <ecki@...a.inka.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: in-kernel rpc.statd

On Sunday September 3, ecki@...a.inka.de wrote:
> In article <Pine.LNX.4.61.0609032255010.6844@...hk01.tjqt.qr> you wrote:
> > Hm. I do not have a rpc.statd userspace program nor kernel daemon (running 
> > on 2.6.17-vanilla). Yet everything is working. Is there a specific need for 
> > statd?
> 
> It is more or less an uptime notification protocol for NFS locks. I think
> NFS clients can recover from a reboot without the help of the statd in most
> situations.

No.

If a client has a lock and the server reboots, then the client loses
the lock and must recovery it during the grace period (first 45
seconds while the server is running again).
Without statd it doesn't know to do this, and it certainly doesn't
know when to do it.  So there is a chance that the server will give
the lock to some other client. Bad.

On the flip side, when a client reboots, the server is left holding
the lock and will not drop it until it discovers that the client has
rebooted, and this can only be discovered via statd.  So without statd
you end up with locks that can only be removed by the sysadmin (or a
server reboot).
In early days when lockd/statd implementations (not necessarily linux)
were even more clunky than they are today, stale locks were not
particularly uncommon.

NeilBrown

-- 
VGER BF report: H 0.018873
-
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/