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:	Thu, 26 Mar 2009 15:40:52 -0400
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	Richard A Nelson <cowboy@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, linux-nfs@...r.kernel.org,
	openafs-devel@...nafs.org
Subject: Re: NFS/AFS/Selinux issues with 2.26.29

On Wed, 2009-03-25 at 17:42 -0700, Richard A Nelson wrote:
> Trond Myklebust wrote:
> > On Wed, 2009-03-25 at 15:09 -0700, Richard A Nelson wrote:
> >> 1) 2.6.29 NFS clients can no longer lock files:
> ...
> > 
> > Given that you are claiming to be seeing selinux problems on
> > 2.6.29-based servers, 
> 
> Yeah, I fixed the SeLinux issues by disabling it at boot
> 
> > could you therefore please check again after
> > downgrading the server kernel?
> 
> I dropped the server to:
> # uname -a
> Linux el-ghor 2.6.28.8 #19 SMP Sun Mar 22 18:41:28 UTC 2009 x86_64 GNU/Linux
> 
> And still see same lockfile error.
> 
> However, a typo showed that locking is indeed working fine - for everything
> except one directory tree (/root/Mail) ... re-mounting and even rebooting one
> of the failing clients didn't help.
> 
> mounts are nfs3,sec=sys,posix,... and the server filesystem is ext3 w/acls
> rpc.statd is active on all systems, and there is no firewall in the way
> 
> So now the server and one client have been rebooted, and the client can
> lock files anywhere but the directory tree for /root/Mail
> sm-notify -f (from the client) didn't help
> 
> Somewhere, there is persistant state that is keeping two out of three
> local systems from creating locks and it all started after upgrading the
> kernel ... colour me dazed and confused, but trying to continue ;)
> 
> /me goes in search of lock display tools (cat /proc/locks isn't yet enough for me)

Have you used wireshark to inspect what is going down the wire when this
exclusive create attempt fails? That would help in narrowing down
whether it is the client or the server that is being problematic.

Cheers
  Trond

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ