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] [day] [month] [year] [list]
Message-Id: <1179160199.3811.88.camel@raven.themaw.net>
Date:	Tue, 15 May 2007 00:29:59 +0800
From:	Ian Kent <raven@...maw.net>
To:	Dave Hansen <hansendc@...ibm.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	haveblue@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
	Trond Myklebust <Trond.Myklebust@...app.com>
Subject: Re: Read-only bind mount patches

On Mon, 2007-05-14 at 09:01 -0700, Dave Hansen wrote:
> On Mon, 2007-05-14 at 23:55 +0800, Ian Kent wrote:
> > 
> > Anything I can do to help?
> > If so maybe we could reduce the time to posting a bit.
> 
> Probably nothing to actually speed up the development, but I'd really
> appreciate some testing once I do post them.  How about I send you an
> advance copy, or cc you on the RFC?

Sure.

My personal test environment is limited.
I can test them with the autofs Connectathon suite and do sanity
checking and the like.

In my other life I can spin a RHEL5 kernel in a private branch and get
that to customers that are complaining, hopefully they will be willing
to test this stuff and persevere with any needed debugging (ya right).
I'm happy to screen reports before passing them on and hopefully provide
you with sensible feedback. But it would be best if we could at least
get this into the mm kernel. That should get them a fair bit of
exposure.

The other question for me is I don't know yet if this will resolve the
problem that lead me to chase this. That's the problem where all NFS
client mounts to the same exported filesystem always use the mount
options of the first mount.

Are you sure I can't help with development, even just re-spinning them
against the current kernel may help (of course you would know best).
Having read the patch set in the archives I see that I'm familiar with
the code in most of the areas of the VFS they touch (but maybe not to
the depth that I would like).

Ian


-
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