lkml.org 
[lkml]   [2012]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [ 026/180] eCryptfs: Improve statfs reporting
From
Date
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]
\
 
 \ /
  Last update: 2012-10-04 07:41    [W:0.115 / U:1.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site