On Mon, 13 Aug 2007 08:01:34 -0400
Jeff Layton <[EMAIL PROTECTED]> wrote:
> On Sat, 11 Aug 2007 03:57:39 +0100
> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> >
> > I like the idea of checking ia_valid after return a lot. But instead of
> > going BUG() it should just do the default action, that
On Sat, 11 Aug 2007 03:57:39 +0100
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> I like the idea of checking ia_valid after return a lot. But instead of
> going BUG() it should just do the default action, that we can avoid
> touching all the filesystem and only need to change those that need
>
On Fri, Aug 10, 2007 at 04:47:52PM -0400, Jeff Layton wrote:
> attr->ia_valid after the setattr operation returns. If either ATTR_KILL_*
> bit is set then BUG(). The helper function already clears those bits
> so anything using it should automatically be ok. We'd have to fix
> up NFS and a few othe
On Tue, 07 Aug 2007 20:45:34 -0400
Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > - rename something so that unconverted filesystems will reliably fail to
> > compile?
> >
> > - leave existing filesystems alone, but add a new
> > inode_operations.setattr_jeff, which the networked filesytems ca
On Wed, 8 Aug 2007 22:05:13 +0200 (CEST)
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Aug 8 2007 09:48, Andrew Morton wrote:
> >> > On Mon, 6 Aug 2007 09:54:03 -0400
> >> > Jeff Layton <[EMAIL PROTECTED]> wrote:
> >> >
> >> > Is there any way in which we can prevent these problems? Say
> >>
On Aug 8 2007 09:48, Andrew Morton wrote:
>> > On Mon, 6 Aug 2007 09:54:03 -0400
>> > Jeff Layton <[EMAIL PROTECTED]> wrote:
>> >
>> > Is there any way in which we can prevent these problems? Say
>> >
>> > - rename something so that unconverted filesystems will reliably fail to
>> > compile?
On Wed, 8 Aug 2007 08:54:35 -0400 Jeff Layton <[EMAIL PROTECTED]> wrote:
> On Tue, 7 Aug 2007 17:15:01 -0700
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 6 Aug 2007 09:54:03 -0400
> > Jeff Layton <[EMAIL PROTECTED]> wrote:
> >
> > Is there any way in which we can prevent these proble
On Tue, 7 Aug 2007 17:15:01 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 6 Aug 2007 09:54:03 -0400
> Jeff Layton <[EMAIL PROTECTED]> wrote:
>
> > Apologies for the resend, but the original sending had the date in the
> > email header and it caused some of these to bounce...
> >
> > (
> >From a purely practical standpoint: it's a concern that all filesytems need
> patching to continue to correctly function after this change. There might
> be filesystems which you missed, and there are out-of-tree filesystems
> which won't be updated.
>
> And I think the impact upon the out-of-
On Tue, 07 Aug 2007 20:45:34 -0400
Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > - rename something so that unconverted filesystems will reliably fail to
> > compile?
> >
> > - leave existing filesystems alone, but add a new
> > inode_operations.setattr_jeff, which the networked filesytems c
On Tue, 2007-08-07 at 17:15 -0700, Andrew Morton wrote:
> Is there any way in which we can prevent these problems? Say
The problem here is that we occasionally DO need to add new flags, and
yes, they MAY be security related. The whole reason why we're now having
to change the semantics of setatt
On Mon, 6 Aug 2007 09:54:03 -0400
Jeff Layton <[EMAIL PROTECTED]> wrote:
> Apologies for the resend, but the original sending had the date in the
> email header and it caused some of these to bounce...
>
> ( Please consider trimming the Cc list if discussing some aspect of this
> that doesn't con
On Tue, 7 Aug 2007 21:49:09 +0100
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> First thanks a lot for doing this work, it's been long needed.
>
> Second please don't send out that many patches. We encourage people
> to split things into small patches when the changes are logially
> separated.
First thanks a lot for doing this work, it's been long needed.
Second please don't send out that many patches. We encourage people
to split things into small patches when the changes are logially
separated. Which these are not - it's a flag day change (which btw
is fine despite the rants soe peo
Apologies for the resend, but the original sending had the date in the
email header and it caused some of these to bounce...
( Please consider trimming the Cc list if discussing some aspect of this
that doesn't concern everyone.)
When an unprivileged process attempts to modify a file that has the
15 matches
Mail list logo
