Messages in this thread | | | Subject | Re: [ 026/180] eCryptfs: Improve statfs reporting | From | Ben Hutchings <> | Date | Wed, 03 Oct 2012 16:13:49 +0100 |
| |
On Tue, 2012-10-02 at 06:24 -0600, Tim Gardner wrote: > On 10/01/2012 11:46 PM, Tyler Hicks wrote: > > On 2012-10-02 00:52:23, Willy Tarreau wrote: > >> 2.6.32-longterm review patch. If anyone has any objections, > >> please let me know. > > > > Hi - Please drop this patch. It incorrectly calculates f_namelen > > and I haven't had a chance to fix it yet. When I get a fix ready, > > I'll forward the corrected patch to stable@v.k.o. Thanks! > > > > Tyler > > > >> > >> ------------------ > >> > >> From: Tyler Hicks <tyhicks@canonical.com> > >> > >> commit 4a26620df451ad46151ad21d711ed43e963c004e upstream. [...] > Tyler - this is the same patch that we're carrying in every kernel > from Lucid to Quantal, right ? Colin has verified test cases for this, > so I'm curious what you think is wrong. Something unique to 2.6.32 ? > > https://bugs.launchpad.net/ecryptfs/+bug/885744/comments/5 > https://bugs.launchpad.net/ecryptfs/+bug/885744/comments/9
As I said in <1344208574.13142.59.camel@deadeye.wl.decadent.org.uk>, pathconf(_PC_NAME_MAX) needs to report an upper bound on the maximum name length, not a lower bound, so that readdir_r() can be used safely.
Ben.
-- Ben Hutchings For every complex problem there is a solution that is simple, neat, and wrong. [unhandled content-type:application/pgp-signature] | |