Re: 2.6.23-rc8-mm1
On Tue, Sep 25, 2007 at 10:26:37AM -0700, Randy Dunlap wrote: > On Tue, 25 Sep 2007 01:46:25 -0700 Andrew Morton wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm1/ > > > > - Various fixes against 2.6.23-rc7-mm1. > > > > > > git-unionfs.patch > > in unionfs debug.c: > > #if BITS_PER_LONG == 32 > #define POISONED_PTR ((void*) 0x5a5a5a5a) > #elif BITS_PER_LONG == 64 > #define POISONED_PTR ((void*) 0x5a5a5a5a5a5a5a5a) > #else > #error Unknown BITS_PER_LONG value > #endif /* BITS_PER_LONG != known */ > > > We try to keep all poison values in include/linux/poison.h so that > when digging around for them, it's easier to locate the one in > question. Right. I didn't want to introduce this kind of ifdef, the 0x5a pattern is also the same as POISON_INUSE. I guess, using the 32-bit poison value should be good enough anyway. > Also, on x86_64, the 64-bit version wants a L or UL suffix: > > fs/unionfs/debug.c:96:30: warning: constant 0x5a5a5a5a5a5a5a5a is so big it > is long > fs/unionfs/debug.c:264:30: warning: constant 0x5a5a5a5a5a5a5a5a is so big it > is long Strange...I didn't get the warning when I compile tested; but it's valid. Josef 'Jeff' Sipek. -- Research, n.: Consider Columbus: He didn't know where he was going. When he got there he didn't know where he was. When he got back he didn't know where he had been. And he did it all on someone else's money. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-mm1
On Tue, Sep 25, 2007 at 10:26:37AM -0700, Randy Dunlap wrote: On Tue, 25 Sep 2007 01:46:25 -0700 Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm1/ - Various fixes against 2.6.23-rc7-mm1. git-unionfs.patch in unionfs debug.c: #if BITS_PER_LONG == 32 #define POISONED_PTR ((void*) 0x5a5a5a5a) #elif BITS_PER_LONG == 64 #define POISONED_PTR ((void*) 0x5a5a5a5a5a5a5a5a) #else #error Unknown BITS_PER_LONG value #endif /* BITS_PER_LONG != known */ We try to keep all poison values in include/linux/poison.h so that when digging around for them, it's easier to locate the one in question. Right. I didn't want to introduce this kind of ifdef, the 0x5a pattern is also the same as POISON_INUSE. I guess, using the 32-bit poison value should be good enough anyway. Also, on x86_64, the 64-bit version wants a L or UL suffix: fs/unionfs/debug.c:96:30: warning: constant 0x5a5a5a5a5a5a5a5a is so big it is long fs/unionfs/debug.c:264:30: warning: constant 0x5a5a5a5a5a5a5a5a is so big it is long Strange...I didn't get the warning when I compile tested; but it's valid. Josef 'Jeff' Sipek. -- Research, n.: Consider Columbus: He didn't know where he was going. When he got there he didn't know where he was. When he got back he didn't know where he had been. And he did it all on someone else's money. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] fs: define file_fsync() even for CONFIG_BLOCK=n
On Wed, Sep 12, 2007 at 10:30:20AM +0100, Christoph Hellwig wrote: > On Wed, Sep 12, 2007 at 11:06:10AM +0900, Paul Mundt wrote: > > There's nothing that is problematic for file_fsync() with CONFIG_BLOCK=n, > > and it's built in unconditionally anyways, so move the prototype out to > > reflect that. Without this, the unionfs build bails out. > > Unionfs should stop using it instead. We did stop. Josef 'Jeff' Sipek. -- NT is to UNIX what a doughnut is to a particle accelerator. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] fs: define file_fsync() even for CONFIG_BLOCK=n
On Wed, Sep 12, 2007 at 10:30:20AM +0100, Christoph Hellwig wrote: On Wed, Sep 12, 2007 at 11:06:10AM +0900, Paul Mundt wrote: There's nothing that is problematic for file_fsync() with CONFIG_BLOCK=n, and it's built in unconditionally anyways, so move the prototype out to reflect that. Without this, the unionfs build bails out. Unionfs should stop using it instead. We did stop. Josef 'Jeff' Sipek. -- NT is to UNIX what a doughnut is to a particle accelerator. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Increase lockdep MAX_LOCK_DEPTH
On Fri, Aug 31, 2007 at 05:09:21PM +0200, Peter Zijlstra wrote: > On Sat, 2007-09-01 at 01:05 +1000, David Chinner wrote: > > > > Trouble is, we'd like to have a sane upper bound on the amount of held > > > locks at any one time, obviously this is just wanting, because a lot of > > > lock chains also depend on the number of online cpus... > > > > Sure - this is an obvious case where it is valid to take >30 locks at > > once in a single thread. In fact, worst case here we are taking twice this > > number of locks - we actually take 2 per inode (ilock and flock) so a > > full 32 inode cluster free would take >60 locks in the middle of this > > function and we should be busting this depth couter limit all the > > time. > > I think this started because jeffpc couldn't boot without XFS busting > lockdep :-) It booted, but if I tried to build the kernel it would make lockdep blowup - not very useful when you have your own code you'd like lockdep to check :) Josef 'Jeff' Sipek. -- I'm somewhere between geek and normal. - Linus Torvalds - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Increase lockdep MAX_LOCK_DEPTH
On Fri, Aug 31, 2007 at 05:09:21PM +0200, Peter Zijlstra wrote: On Sat, 2007-09-01 at 01:05 +1000, David Chinner wrote: Trouble is, we'd like to have a sane upper bound on the amount of held locks at any one time, obviously this is just wanting, because a lot of lock chains also depend on the number of online cpus... Sure - this is an obvious case where it is valid to take 30 locks at once in a single thread. In fact, worst case here we are taking twice this number of locks - we actually take 2 per inode (ilock and flock) so a full 32 inode cluster free would take 60 locks in the middle of this function and we should be busting this depth couter limit all the time. I think this started because jeffpc couldn't boot without XFS busting lockdep :-) It booted, but if I tried to build the kernel it would make lockdep blowup - not very useful when you have your own code you'd like lockdep to check :) Josef 'Jeff' Sipek. -- I'm somewhere between geek and normal. - Linus Torvalds - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] add killattr inode operation to allow filesystems to interpret ATTR_KILL_S*ID bits
On Tue, Aug 28, 2007 at 08:11:14PM +0100, Christoph Hellwig wrote: > > Sorry for not replying to the previsious revisions, but I've been out > for on vacation. > > I can't say I like this version. Now we've got callouts at two rather close > levels which is not very nice from the interface POV. > > Maybe preference is for the first scheme where we simply move interpreation > of the ATTR_KILL_SUID/ATTR_KILL_SGID into the setattr routine and provide > a nice helper for the normal filesystem to use. > > If people are really concerned about adding two lines of code to the > handfull of setattr operation there's a variant of this scheme that can > avoid it: It's not about adding 2 lines of code - it's about adding the requirement for the fs to call a function. > - notify_change is modified to not clear the ATTR_KILL_SUID/ATTR_KILL_SGID >but update ia_mode and the ia_valid flag to include ATTR_MODE. > - disk filesystems stay unchanged and never look at >ATTR_KILL_SUID/ATTR_KILL_SGID, but nfs can check for it and ignore >the ATTR_MODE flags and ia_valid in this case and do the right thing >on the server side. Sounds reasonable. Josef 'Jeff' Sipek. -- I abhor a system designed for the "user", if that word is a coded pejorative meaning "stupid and unsophisticated." - Ken Thompson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] add killattr inode operation to allow filesystems to interpret ATTR_KILL_S*ID bits
On Tue, Aug 28, 2007 at 08:11:14PM +0100, Christoph Hellwig wrote: Sorry for not replying to the previsious revisions, but I've been out for on vacation. I can't say I like this version. Now we've got callouts at two rather close levels which is not very nice from the interface POV. Maybe preference is for the first scheme where we simply move interpreation of the ATTR_KILL_SUID/ATTR_KILL_SGID into the setattr routine and provide a nice helper for the normal filesystem to use. If people are really concerned about adding two lines of code to the handfull of setattr operation there's a variant of this scheme that can avoid it: It's not about adding 2 lines of code - it's about adding the requirement for the fs to call a function. - notify_change is modified to not clear the ATTR_KILL_SUID/ATTR_KILL_SGID but update ia_mode and the ia_valid flag to include ATTR_MODE. - disk filesystems stay unchanged and never look at ATTR_KILL_SUID/ATTR_KILL_SGID, but nfs can check for it and ignore the ATTR_MODE flags and ia_valid in this case and do the right thing on the server side. Sounds reasonable. Josef 'Jeff' Sipek. -- I abhor a system designed for the user, if that word is a coded pejorative meaning stupid and unsophisticated. - Ken Thompson - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: errno codes intertwined
On Fri, Aug 24, 2007 at 06:24:48PM +0200, Jan Engelhardt wrote: ... > If a file does not have the requested attribute, the syscall will > produce ENODATA. On x86_64, that is mapped to the value 61. Back on the > sparc side, 61 is mapped to ECONNREFUSED, and that gives odd errors > when ls tries to query xattrs: I'd think that passing the raw error code is a bad idea, and that you probably want to have your own set of codes that you use in the trasport and map value to/from the host's errno values. > the values are exactly swapped (mips is another oddball not portrayed > here). Since these header files propagate into /usr/include, this > affects userspace programs too. Yep, and it kind of sucks. > So I'm just asking: can I rely on the same errno across Linuxes? I wouldn't - Linux on different different architectures seems to have different errno codes. > And should the errno values be fixed up? It would break userspace :-/ Josef 'Jeff' Sipek. -- *NOTE: This message is ROT-13 encrypted twice for extra protection* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: false positive in checkpatch.pl (complex macro values)
On Fri, Aug 24, 2007 at 09:24:17AM -0400, Mike Frysinger wrote:
...
> $ grep AUREON_DEVICE_DESC ./sound/pci/ice1712/aureon.h -A 5
> #define AUREON_DEVICE_DESC"{Terratec,Aureon 5.1 Sky},"\
>"{Terratec,Aureon 7.1 Space},"\
>"{Terratec,Aureon 7.1 Universe}," \
> "{AudioTrak,Prodigy 7.1}," \
> "{AudioTrak,Prodigy 7.1 LT},"\
> "{AudioTrak,Prodigy 7.1 XT},"
This is a different thing. This is a long string, not a list of elements.
IMO, this one shouldn't have given a warning regardless of whether or not
the original case is valid.
Josef 'Jeff' Sipek.
--
If I have trouble installing Linux, something is wrong. Very wrong.
- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: false positive in checkpatch.pl (complex macro values)
On Fri, Aug 24, 2007 at 09:24:17AM -0400, Mike Frysinger wrote:
...
$ grep AUREON_DEVICE_DESC ./sound/pci/ice1712/aureon.h -A 5
#define AUREON_DEVICE_DESC{Terratec,Aureon 5.1 Sky},\
{Terratec,Aureon 7.1 Space},\
{Terratec,Aureon 7.1 Universe}, \
{AudioTrak,Prodigy 7.1}, \
{AudioTrak,Prodigy 7.1 LT},\
{AudioTrak,Prodigy 7.1 XT},
This is a different thing. This is a long string, not a list of elements.
IMO, this one shouldn't have given a warning regardless of whether or not
the original case is valid.
Josef 'Jeff' Sipek.
--
If I have trouble installing Linux, something is wrong. Very wrong.
- Linus Torvalds
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: errno codes intertwined
On Fri, Aug 24, 2007 at 06:24:48PM +0200, Jan Engelhardt wrote: ... If a file does not have the requested attribute, the syscall will produce ENODATA. On x86_64, that is mapped to the value 61. Back on the sparc side, 61 is mapped to ECONNREFUSED, and that gives odd errors when ls tries to query xattrs: I'd think that passing the raw error code is a bad idea, and that you probably want to have your own set of codes that you use in the trasport and map value to/from the host's errno values. the values are exactly swapped (mips is another oddball not portrayed here). Since these header files propagate into /usr/include, this affects userspace programs too. Yep, and it kind of sucks. So I'm just asking: can I rely on the same errno across Linuxes? I wouldn't - Linux on different different architectures seems to have different errno codes. And should the errno values be fixed up? It would break userspace :-/ Josef 'Jeff' Sipek. -- *NOTE: This message is ROT-13 encrypted twice for extra protection* - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/23] lib: percpu_counter_init error handling
On Sat, Aug 18, 2007 at 10:09:34AM +0200, Peter Zijlstra wrote:
> On Fri, 2007-08-17 at 11:56 -0400, Josef Sipek wrote:
> > On Thu, Aug 16, 2007 at 09:45:34AM +0200, Peter Zijlstra wrote:
Sorry...this mail got lost in the flood of email after a procmail rule
stopped working...
> The actual value of err is irrelevant, it is not used after this not
> zero check.
>
> But how about this:
> ---
> Subject: lib: percpu_counter_init error handling
>
> alloc_percpu can fail, propagate that error.
>
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> ---
> fs/ext2/super.c| 15 ---
> fs/ext3/super.c| 21 +++--
> fs/ext4/super.c| 21 +++--
> include/linux/percpu_counter.h |5 +++--
> lib/percpu_counter.c |8 +++-
> 5 files changed, 52 insertions(+), 18 deletions(-)
>
> Index: linux-2.6/fs/ext2/super.c
> ===
> --- linux-2.6.orig/fs/ext2/super.c
> +++ linux-2.6/fs/ext2/super.c
> @@ -725,6 +725,7 @@ static int ext2_fill_super(struct super_
> int db_count;
> int i, j;
> __le32 features;
> + int err;
>
> sbi = kzalloc(sizeof(*sbi), GFP_KERNEL);
> if (!sbi)
> @@ -996,12 +997,20 @@ static int ext2_fill_super(struct super_
> sbi->s_rsv_window_head.rsv_goal_size = 0;
> ext2_rsv_window_add(sb, >s_rsv_window_head);
>
> - percpu_counter_init(>s_freeblocks_counter,
> + err = percpu_counter_init(>s_freeblocks_counter,
> ext2_count_free_blocks(sb));
> - percpu_counter_init(>s_freeinodes_counter,
> + if (!err) {
> + err = percpu_counter_init(>s_freeinodes_counter,
> ext2_count_free_inodes(sb));
> - percpu_counter_init(>s_dirs_counter,
> + }
> + if (!err) {
> + err = percpu_counter_init(>s_dirs_counter,
> ext2_count_dirs(sb));
> + }
> + if (err) {
> + printk(KERN_ERR "EXT2-fs: insufficient memory\n");
> + goto failed_mount3;
> + }
> /*
>* set up enough so that it can read an inode
>*/
I find this more readable as I don't have to try to figure out what the
bitops are doing :)
Jeff.
--
Mankind invented the atomic bomb, but no mouse would ever construct a
mousetrap.
- Albert Einstein
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/23] lib: percpu_counter_init error handling
On Sat, Aug 18, 2007 at 10:09:34AM +0200, Peter Zijlstra wrote:
On Fri, 2007-08-17 at 11:56 -0400, Josef Sipek wrote:
On Thu, Aug 16, 2007 at 09:45:34AM +0200, Peter Zijlstra wrote:
Sorry...this mail got lost in the flood of email after a procmail rule
stopped working...
The actual value of err is irrelevant, it is not used after this not
zero check.
But how about this:
---
Subject: lib: percpu_counter_init error handling
alloc_percpu can fail, propagate that error.
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
---
fs/ext2/super.c| 15 ---
fs/ext3/super.c| 21 +++--
fs/ext4/super.c| 21 +++--
include/linux/percpu_counter.h |5 +++--
lib/percpu_counter.c |8 +++-
5 files changed, 52 insertions(+), 18 deletions(-)
Index: linux-2.6/fs/ext2/super.c
===
--- linux-2.6.orig/fs/ext2/super.c
+++ linux-2.6/fs/ext2/super.c
@@ -725,6 +725,7 @@ static int ext2_fill_super(struct super_
int db_count;
int i, j;
__le32 features;
+ int err;
sbi = kzalloc(sizeof(*sbi), GFP_KERNEL);
if (!sbi)
@@ -996,12 +997,20 @@ static int ext2_fill_super(struct super_
sbi-s_rsv_window_head.rsv_goal_size = 0;
ext2_rsv_window_add(sb, sbi-s_rsv_window_head);
- percpu_counter_init(sbi-s_freeblocks_counter,
+ err = percpu_counter_init(sbi-s_freeblocks_counter,
ext2_count_free_blocks(sb));
- percpu_counter_init(sbi-s_freeinodes_counter,
+ if (!err) {
+ err = percpu_counter_init(sbi-s_freeinodes_counter,
ext2_count_free_inodes(sb));
- percpu_counter_init(sbi-s_dirs_counter,
+ }
+ if (!err) {
+ err = percpu_counter_init(sbi-s_dirs_counter,
ext2_count_dirs(sb));
+ }
+ if (err) {
+ printk(KERN_ERR EXT2-fs: insufficient memory\n);
+ goto failed_mount3;
+ }
/*
* set up enough so that it can read an inode
*/
I find this more readable as I don't have to try to figure out what the
bitops are doing :)
Jeff.
--
Mankind invented the atomic bomb, but no mouse would ever construct a
mousetrap.
- Albert Einstein
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Fix mainline filesystems to handle ATTR_KILL_ bits correctly
On Tue, Aug 21, 2007 at 07:35:51AM -0400, Jeff Layton wrote:
> On Tue, 21 Aug 2007 15:35:08 +1000
> Timothy Shimmin <[EMAIL PROTECTED]> wrote:
>
> > Jeff Layton wrote:
> > > This should fix all of the filesystems in the mainline kernels to handle
> > > ATTR_KILL_SUID and ATTR_KILL_SGID correctly. For most of them, this is
> > > just a matter of making sure that they call generic_attrkill early in
> > > the setattr inode op.
> > >
> > > Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
> > > ---
> > > fs/xfs/linux-2.6/xfs_iops.c |5 -
> > > --- a/fs/xfs/linux-2.6/xfs_iops.c
> > > +++ b/fs/xfs/linux-2.6/xfs_iops.c
> > > @@ -651,12 +651,15 @@ xfs_vn_setattr(
> > > struct iattr*attr)
> > > {
> > > struct inode*inode = dentry->d_inode;
> > > - unsigned intia_valid = attr->ia_valid;
> > > + unsigned intia_valid;
> > > bhv_vnode_t *vp = vn_from_inode(inode);
> > > bhv_vattr_t vattr = { 0 };
> > > int flags = 0;
> > > int error;
> > >
> > > + generic_attrkill(inode->i_mode, attr);
> > > + ia_valid = attr->ia_valid;
> > > +
> > > if (ia_valid & ATTR_UID) {
> > > vattr.va_mask |= XFS_AT_UID;
> > > vattr.va_uid = attr->ia_uid;
> >
> > Looks reasonable to me for XFS.
> > Acked-by: Tim Shimmin <[EMAIL PROTECTED]>
> >
> > So before, this clearing would happen directly in notify_change()
> > and now this won't happen until notify_change() calls i_op->setattr
> > which for a particular fs it can call generic_attrkill() to do it.
> > So I guess for the cases where i_op->setattr is called outside of
> > via notify_change, we don't normally have ATTR_KILL_SUID/SGID
> > set so that nothing will happen there?
>
> Right. If neither ATTR_KILL bit is set then generic_attrkill is a
> noop.
>
> > I guess just wondering the effect with having the code on all
> > setattr's. (I'm not familiar with the code path)
> >
>
> These bits are referenced in very few places in the current kernel
> tree -- mostly in the VFS layer. The *only* place I see that they
> actually get interpreted into a mode change is in notify_change. So
> places that call setattr ops w/o going through notify_change are
> not likely to have those bits set.
>
> But hypothetically, if a fs did set ATTR_KILL_* and call setattr
> directly, then the setattr would now include a mode change that
> clears setuid or setgid bits where it may not have before.
It almost sounds like an argument for a new inode op (NULL would use
generic_attr_kill).
Josef 'Jeff' Sipek.
--
A CRAY is the only computer that runs an endless loop in just 4 hours...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Fix mainline filesystems to handle ATTR_KILL_ bits correctly
On Tue, Aug 21, 2007 at 07:35:51AM -0400, Jeff Layton wrote:
On Tue, 21 Aug 2007 15:35:08 +1000
Timothy Shimmin [EMAIL PROTECTED] wrote:
Jeff Layton wrote:
This should fix all of the filesystems in the mainline kernels to handle
ATTR_KILL_SUID and ATTR_KILL_SGID correctly. For most of them, this is
just a matter of making sure that they call generic_attrkill early in
the setattr inode op.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
---
fs/xfs/linux-2.6/xfs_iops.c |5 -
--- a/fs/xfs/linux-2.6/xfs_iops.c
+++ b/fs/xfs/linux-2.6/xfs_iops.c
@@ -651,12 +651,15 @@ xfs_vn_setattr(
struct iattr*attr)
{
struct inode*inode = dentry-d_inode;
- unsigned intia_valid = attr-ia_valid;
+ unsigned intia_valid;
bhv_vnode_t *vp = vn_from_inode(inode);
bhv_vattr_t vattr = { 0 };
int flags = 0;
int error;
+ generic_attrkill(inode-i_mode, attr);
+ ia_valid = attr-ia_valid;
+
if (ia_valid ATTR_UID) {
vattr.va_mask |= XFS_AT_UID;
vattr.va_uid = attr-ia_uid;
Looks reasonable to me for XFS.
Acked-by: Tim Shimmin [EMAIL PROTECTED]
So before, this clearing would happen directly in notify_change()
and now this won't happen until notify_change() calls i_op-setattr
which for a particular fs it can call generic_attrkill() to do it.
So I guess for the cases where i_op-setattr is called outside of
via notify_change, we don't normally have ATTR_KILL_SUID/SGID
set so that nothing will happen there?
Right. If neither ATTR_KILL bit is set then generic_attrkill is a
noop.
I guess just wondering the effect with having the code on all
setattr's. (I'm not familiar with the code path)
These bits are referenced in very few places in the current kernel
tree -- mostly in the VFS layer. The *only* place I see that they
actually get interpreted into a mode change is in notify_change. So
places that call setattr ops w/o going through notify_change are
not likely to have those bits set.
But hypothetically, if a fs did set ATTR_KILL_* and call setattr
directly, then the setattr would now include a mode change that
clears setuid or setgid bits where it may not have before.
It almost sounds like an argument for a new inode op (NULL would use
generic_attr_kill).
Josef 'Jeff' Sipek.
--
A CRAY is the only computer that runs an endless loop in just 4 hours...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Git tree for old kernels
On Mon, Aug 20, 2007 at 01:40:52PM -0400, Nicolas Pitre wrote: > On Mon, 20 Aug 2007, Josef Sipek wrote: > > > On Sun, Aug 19, 2007 at 03:24:56PM -0400, Nicolas Pitre wrote: > > > On Sun, 22 Jul 2007, Jon Smirl wrote: > > > > > > > Continuing on with kernel archeology for embedded systems, any > > > > interest in making a git tree with all of the kernel versions from the > > > > beginning up to the start of the current git tree? > > > > > > I just put the archive I've gathered so far in a Git tree on kernel.org: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/nico/archive.git > > > > > > It is also available through gitweb from: > > > > > > http://git.kernel.org/?p=linux/kernel/git/nico/archive.git > > > > I don't mean to nit-pick but, would it be possible to have the timestamps > > for the commits closer to the release dates? > > Well, the author timestamp already is, based on the date of the > announcement message used for the commit log, including the timezone. > If you find errors in those please tell me. Ah ok. Too bad gitweb displays the commit times => throws off some of the sorting too. /me prods gitweb people > The commit timestamp, however, is the time when _I_ created the > repository, hence it should not be that interesting. Too bad that's the date you see all over the place :( Jeff. -- NT is to UNIX what a doughnut is to a particle accelerator. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Git tree for old kernels
On Sun, Aug 19, 2007 at 03:24:56PM -0400, Nicolas Pitre wrote: > On Sun, 22 Jul 2007, Jon Smirl wrote: > > > Continuing on with kernel archeology for embedded systems, any > > interest in making a git tree with all of the kernel versions from the > > beginning up to the start of the current git tree? > > I just put the archive I've gathered so far in a Git tree on kernel.org: > > git://git.kernel.org/pub/scm/linux/kernel/git/nico/archive.git > > It is also available through gitweb from: > > http://git.kernel.org/?p=linux/kernel/git/nico/archive.git I don't mean to nit-pick but, would it be possible to have the timestamps for the commits closer to the release dates? I must say, impressive work. Thanks! Josef 'Jeff' Sipek. -- Computer Science is no more about computers than astronomy is about telescopes. - Edsger Dijkstra - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Git tree for old kernels
On Sun, Aug 19, 2007 at 03:24:56PM -0400, Nicolas Pitre wrote: On Sun, 22 Jul 2007, Jon Smirl wrote: Continuing on with kernel archeology for embedded systems, any interest in making a git tree with all of the kernel versions from the beginning up to the start of the current git tree? I just put the archive I've gathered so far in a Git tree on kernel.org: git://git.kernel.org/pub/scm/linux/kernel/git/nico/archive.git It is also available through gitweb from: http://git.kernel.org/?p=linux/kernel/git/nico/archive.git I don't mean to nit-pick but, would it be possible to have the timestamps for the commits closer to the release dates? I must say, impressive work. Thanks! Josef 'Jeff' Sipek. -- Computer Science is no more about computers than astronomy is about telescopes. - Edsger Dijkstra - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Git tree for old kernels
On Mon, Aug 20, 2007 at 01:40:52PM -0400, Nicolas Pitre wrote: On Mon, 20 Aug 2007, Josef Sipek wrote: On Sun, Aug 19, 2007 at 03:24:56PM -0400, Nicolas Pitre wrote: On Sun, 22 Jul 2007, Jon Smirl wrote: Continuing on with kernel archeology for embedded systems, any interest in making a git tree with all of the kernel versions from the beginning up to the start of the current git tree? I just put the archive I've gathered so far in a Git tree on kernel.org: git://git.kernel.org/pub/scm/linux/kernel/git/nico/archive.git It is also available through gitweb from: http://git.kernel.org/?p=linux/kernel/git/nico/archive.git I don't mean to nit-pick but, would it be possible to have the timestamps for the commits closer to the release dates? Well, the author timestamp already is, based on the date of the announcement message used for the commit log, including the timezone. If you find errors in those please tell me. Ah ok. Too bad gitweb displays the commit times = throws off some of the sorting too. /me prods gitweb people The commit timestamp, however, is the time when _I_ created the repository, hence it should not be that interesting. Too bad that's the date you see all over the place :( Jeff. -- NT is to UNIX what a doughnut is to a particle accelerator. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 17/23] mm: count reclaimable pages per BDI
On Thu, Aug 16, 2007 at 09:45:42AM +0200, Peter Zijlstra wrote:
...
> Index: linux-2.6/include/linux/backing-dev.h
> ===
> --- linux-2.6.orig/include/linux/backing-dev.h
> +++ linux-2.6/include/linux/backing-dev.h
> @@ -27,6 +27,7 @@ enum bdi_state {
> typedef int (congested_fn)(void *, int);
>
> enum bdi_stat_item {
> + BDI_RECLAIMABLE,
> NR_BDI_STAT_ITEMS
> };
Ok, I see. Ignore my comment on 16/xx :)
Jeff.
--
Keyboard not found!
Press F1 to enter Setup
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 16/23] mm: scalable bdi statistics counters.
On Thu, Aug 16, 2007 at 09:45:41AM +0200, Peter Zijlstra wrote:
...
> Index: linux-2.6/include/linux/backing-dev.h
> ===
> --- linux-2.6.orig/include/linux/backing-dev.h
> +++ linux-2.6/include/linux/backing-dev.h
...
> @@ -24,6 +26,12 @@ enum bdi_state {
>
> typedef int (congested_fn)(void *, int);
>
> +enum bdi_stat_item {
> + NR_BDI_STAT_ITEMS
> +};
enum numbering starts at 0, so NR_BDI_STAT_ITEMS == 0
> +
> +#define BDI_STAT_BATCH (8*(1+ilog2(nr_cpu_ids)))
> +
> struct backing_dev_info {
> unsigned long ra_pages; /* max readahead in PAGE_CACHE_SIZE units */
> unsigned long state;/* Always use atomic bitops on this */
> @@ -32,15 +40,86 @@ struct backing_dev_info {
> void *congested_data; /* Pointer to aux data for congested func */
> void (*unplug_io_fn)(struct backing_dev_info *, struct page *);
> void *unplug_io_data;
> +
> + struct percpu_counter bdi_stat[NR_BDI_STAT_ITEMS];
So, this is a 0-element array.
> };
>
> -static inline int bdi_init(struct backing_dev_info *bdi)
> +int bdi_init(struct backing_dev_info *bdi);
> +void bdi_destroy(struct backing_dev_info *bdi);
> +
> +static inline void __add_bdi_stat(struct backing_dev_info *bdi,
> + enum bdi_stat_item item, s64 amount)
> {
> - return 0;
> + __percpu_counter_add(>bdi_stat[item], amount, BDI_STAT_BATCH);
Boom!
> }
Josef 'Jeff' Sipek.
--
You measure democracy by the freedom it gives its dissidents, not the
freedom it gives its assimilated conformists.
- Abbie Hoffman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/23] mm: bdi init hooks
On Thu, Aug 16, 2007 at 09:45:36AM +0200, Peter Zijlstra wrote:
> provide BDI constructor/destructor hooks
...
> Index: linux-2.6/drivers/block/rd.c
> ===
> --- linux-2.6.orig/drivers/block/rd.c
> +++ linux-2.6/drivers/block/rd.c
...
> @@ -419,7 +422,19 @@ static void __exit rd_cleanup(void)
> static int __init rd_init(void)
> {
> int i;
> - int err = -ENOMEM;
> + int err;
> +
> + err = bdi_init(_backing_dev_info);
> + if (err)
> + goto out2;
> +
> + err = bdi_init(_file_backing_dev_info);
> + if (err) {
> + bdi_destroy(_backing_dev_info);
> + goto out2;
How about this...
if (err)
goto out3;
> + }
> +
> + err = -ENOMEM;
>
> if (rd_blocksize > PAGE_SIZE || rd_blocksize < 512 ||
> (rd_blocksize & (rd_blocksize-1))) {
> @@ -473,6 +488,9 @@ out:
> put_disk(rd_disks[i]);
> blk_cleanup_queue(rd_queue[i]);
> }
> + bdi_destroy(_backing_dev_info);
> + bdi_destroy(_file_backing_dev_info);
bdi_destroy(_file_backing_dev_info);
out3:
bdi_destroy(_backing_dev_info);
Sure you might want to switch from numbered labels to something a bit more
descriptive.
> +out2:
> return err;
> }
>
Josef 'Jeff' Sipek.
--
The box said "Windows XP or better required". So I installed Linux.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/23] lib: percpu_counter_init error handling
On Thu, Aug 16, 2007 at 09:45:34AM +0200, Peter Zijlstra wrote:
> alloc_percpu can fail, propagate that error.
>
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> ---
> fs/ext2/super.c| 11 ---
> fs/ext3/super.c| 11 ---
> fs/ext4/super.c| 11 ---
> include/linux/percpu_counter.h |5 +++--
> lib/percpu_counter.c |8 +++-
> 5 files changed, 34 insertions(+), 12 deletions(-)
>
> Index: linux-2.6/fs/ext2/super.c
> ===
> --- linux-2.6.orig/fs/ext2/super.c
> +++ linux-2.6/fs/ext2/super.c
> @@ -725,6 +725,7 @@ static int ext2_fill_super(struct super_
> int db_count;
> int i, j;
> __le32 features;
> + int err;
>
> sbi = kzalloc(sizeof(*sbi), GFP_KERNEL);
> if (!sbi)
> @@ -996,12 +997,16 @@ static int ext2_fill_super(struct super_
> sbi->s_rsv_window_head.rsv_goal_size = 0;
> ext2_rsv_window_add(sb, >s_rsv_window_head);
>
> - percpu_counter_init(>s_freeblocks_counter,
> + err = percpu_counter_init(>s_freeblocks_counter,
> ext2_count_free_blocks(sb));
> - percpu_counter_init(>s_freeinodes_counter,
> + err |= percpu_counter_init(>s_freeinodes_counter,
> ext2_count_free_inodes(sb));
> - percpu_counter_init(>s_dirs_counter,
> + err |= percpu_counter_init(>s_dirs_counter,
> ext2_count_dirs(sb));
> + if (err) {
> + printk(KERN_ERR "EXT2-fs: insufficient memory\n");
> + goto failed_mount3;
> + }
Can percpu_counter_init fail with only one error code? If not, the error
code potentially used in future at failed_mount3 could be nonsensical
because of the bitwise or-ing.
> Index: linux-2.6/lib/percpu_counter.c
> ===
> --- linux-2.6.orig/lib/percpu_counter.c
> +++ linux-2.6/lib/percpu_counter.c
> @@ -68,21 +68,27 @@ s64 __percpu_counter_sum(struct percpu_c
> }
> EXPORT_SYMBOL(__percpu_counter_sum);
>
> -void percpu_counter_init(struct percpu_counter *fbc, s64 amount)
> +int percpu_counter_init(struct percpu_counter *fbc, s64 amount)
> {
> spin_lock_init(>lock);
> fbc->count = amount;
> fbc->counters = alloc_percpu(s32);
> + if (!fbc->counters)
> + return -ENOMEM;
> #ifdef CONFIG_HOTPLUG_CPU
> mutex_lock(_counters_lock);
> list_add(>list, _counters);
> mutex_unlock(_counters_lock);
> #endif
> + return 0;
> }
I guess this answers my question. But I'd still be weary because a trivial
change here could produce very strange error codes in ext2/3/4.
Josef 'Jeff' Sipek.
--
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/23] lib: percpu_counter_add
On Thu, Aug 16, 2007 at 09:45:27AM +0200, Peter Zijlstra wrote: ... > Index: linux-2.6/fs/ext2/balloc.c > === > --- linux-2.6.orig/fs/ext2/balloc.c > +++ linux-2.6/fs/ext2/balloc.c > @@ -163,7 +163,7 @@ static int reserve_blocks(struct super_b > return 0; > } > > - percpu_counter_mod(>s_freeblocks_counter, -count); > + percpu_counter_add(>s_freeblocks_counter, -count); Out of curiosity, I noticed similar thing being done in the vm code, what is preferred: foobar_add(, -num); or foobar_sub(, num); ? Josef 'Jeff' Sipek. -- Research, n.: Consider Columbus: He didn't know where he was going. When he got there he didn't know where he was. When he got back he didn't know where he had been. And he did it all on someone else's money. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/23] lib: percpu_counter_add
On Thu, Aug 16, 2007 at 09:45:27AM +0200, Peter Zijlstra wrote: ... Index: linux-2.6/fs/ext2/balloc.c === --- linux-2.6.orig/fs/ext2/balloc.c +++ linux-2.6/fs/ext2/balloc.c @@ -163,7 +163,7 @@ static int reserve_blocks(struct super_b return 0; } - percpu_counter_mod(sbi-s_freeblocks_counter, -count); + percpu_counter_add(sbi-s_freeblocks_counter, -count); Out of curiosity, I noticed similar thing being done in the vm code, what is preferred: foobar_add(counter, -num); or foobar_sub(counter, num); ? Josef 'Jeff' Sipek. -- Research, n.: Consider Columbus: He didn't know where he was going. When he got there he didn't know where he was. When he got back he didn't know where he had been. And he did it all on someone else's money. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/23] mm: bdi init hooks
On Thu, Aug 16, 2007 at 09:45:36AM +0200, Peter Zijlstra wrote:
provide BDI constructor/destructor hooks
...
Index: linux-2.6/drivers/block/rd.c
===
--- linux-2.6.orig/drivers/block/rd.c
+++ linux-2.6/drivers/block/rd.c
...
@@ -419,7 +422,19 @@ static void __exit rd_cleanup(void)
static int __init rd_init(void)
{
int i;
- int err = -ENOMEM;
+ int err;
+
+ err = bdi_init(rd_backing_dev_info);
+ if (err)
+ goto out2;
+
+ err = bdi_init(rd_file_backing_dev_info);
+ if (err) {
+ bdi_destroy(rd_backing_dev_info);
+ goto out2;
How about this...
if (err)
goto out3;
+ }
+
+ err = -ENOMEM;
if (rd_blocksize PAGE_SIZE || rd_blocksize 512 ||
(rd_blocksize (rd_blocksize-1))) {
@@ -473,6 +488,9 @@ out:
put_disk(rd_disks[i]);
blk_cleanup_queue(rd_queue[i]);
}
+ bdi_destroy(rd_backing_dev_info);
+ bdi_destroy(rd_file_backing_dev_info);
bdi_destroy(rd_file_backing_dev_info);
out3:
bdi_destroy(rd_backing_dev_info);
Sure you might want to switch from numbered labels to something a bit more
descriptive.
+out2:
return err;
}
Josef 'Jeff' Sipek.
--
The box said Windows XP or better required. So I installed Linux.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 17/23] mm: count reclaimable pages per BDI
On Thu, Aug 16, 2007 at 09:45:42AM +0200, Peter Zijlstra wrote:
...
Index: linux-2.6/include/linux/backing-dev.h
===
--- linux-2.6.orig/include/linux/backing-dev.h
+++ linux-2.6/include/linux/backing-dev.h
@@ -27,6 +27,7 @@ enum bdi_state {
typedef int (congested_fn)(void *, int);
enum bdi_stat_item {
+ BDI_RECLAIMABLE,
NR_BDI_STAT_ITEMS
};
Ok, I see. Ignore my comment on 16/xx :)
Jeff.
--
Keyboard not found!
Press F1 to enter Setup
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/23] lib: percpu_counter_init error handling
On Thu, Aug 16, 2007 at 09:45:34AM +0200, Peter Zijlstra wrote:
alloc_percpu can fail, propagate that error.
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
---
fs/ext2/super.c| 11 ---
fs/ext3/super.c| 11 ---
fs/ext4/super.c| 11 ---
include/linux/percpu_counter.h |5 +++--
lib/percpu_counter.c |8 +++-
5 files changed, 34 insertions(+), 12 deletions(-)
Index: linux-2.6/fs/ext2/super.c
===
--- linux-2.6.orig/fs/ext2/super.c
+++ linux-2.6/fs/ext2/super.c
@@ -725,6 +725,7 @@ static int ext2_fill_super(struct super_
int db_count;
int i, j;
__le32 features;
+ int err;
sbi = kzalloc(sizeof(*sbi), GFP_KERNEL);
if (!sbi)
@@ -996,12 +997,16 @@ static int ext2_fill_super(struct super_
sbi-s_rsv_window_head.rsv_goal_size = 0;
ext2_rsv_window_add(sb, sbi-s_rsv_window_head);
- percpu_counter_init(sbi-s_freeblocks_counter,
+ err = percpu_counter_init(sbi-s_freeblocks_counter,
ext2_count_free_blocks(sb));
- percpu_counter_init(sbi-s_freeinodes_counter,
+ err |= percpu_counter_init(sbi-s_freeinodes_counter,
ext2_count_free_inodes(sb));
- percpu_counter_init(sbi-s_dirs_counter,
+ err |= percpu_counter_init(sbi-s_dirs_counter,
ext2_count_dirs(sb));
+ if (err) {
+ printk(KERN_ERR EXT2-fs: insufficient memory\n);
+ goto failed_mount3;
+ }
Can percpu_counter_init fail with only one error code? If not, the error
code potentially used in future at failed_mount3 could be nonsensical
because of the bitwise or-ing.
Index: linux-2.6/lib/percpu_counter.c
===
--- linux-2.6.orig/lib/percpu_counter.c
+++ linux-2.6/lib/percpu_counter.c
@@ -68,21 +68,27 @@ s64 __percpu_counter_sum(struct percpu_c
}
EXPORT_SYMBOL(__percpu_counter_sum);
-void percpu_counter_init(struct percpu_counter *fbc, s64 amount)
+int percpu_counter_init(struct percpu_counter *fbc, s64 amount)
{
spin_lock_init(fbc-lock);
fbc-count = amount;
fbc-counters = alloc_percpu(s32);
+ if (!fbc-counters)
+ return -ENOMEM;
#ifdef CONFIG_HOTPLUG_CPU
mutex_lock(percpu_counters_lock);
list_add(fbc-list, percpu_counters);
mutex_unlock(percpu_counters_lock);
#endif
+ return 0;
}
I guess this answers my question. But I'd still be weary because a trivial
change here could produce very strange error codes in ext2/3/4.
Josef 'Jeff' Sipek.
--
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 16/23] mm: scalable bdi statistics counters.
On Thu, Aug 16, 2007 at 09:45:41AM +0200, Peter Zijlstra wrote:
...
Index: linux-2.6/include/linux/backing-dev.h
===
--- linux-2.6.orig/include/linux/backing-dev.h
+++ linux-2.6/include/linux/backing-dev.h
...
@@ -24,6 +26,12 @@ enum bdi_state {
typedef int (congested_fn)(void *, int);
+enum bdi_stat_item {
+ NR_BDI_STAT_ITEMS
+};
enum numbering starts at 0, so NR_BDI_STAT_ITEMS == 0
+
+#define BDI_STAT_BATCH (8*(1+ilog2(nr_cpu_ids)))
+
struct backing_dev_info {
unsigned long ra_pages; /* max readahead in PAGE_CACHE_SIZE units */
unsigned long state;/* Always use atomic bitops on this */
@@ -32,15 +40,86 @@ struct backing_dev_info {
void *congested_data; /* Pointer to aux data for congested func */
void (*unplug_io_fn)(struct backing_dev_info *, struct page *);
void *unplug_io_data;
+
+ struct percpu_counter bdi_stat[NR_BDI_STAT_ITEMS];
So, this is a 0-element array.
};
-static inline int bdi_init(struct backing_dev_info *bdi)
+int bdi_init(struct backing_dev_info *bdi);
+void bdi_destroy(struct backing_dev_info *bdi);
+
+static inline void __add_bdi_stat(struct backing_dev_info *bdi,
+ enum bdi_stat_item item, s64 amount)
{
- return 0;
+ __percpu_counter_add(bdi-bdi_stat[item], amount, BDI_STAT_BATCH);
Boom!
}
Josef 'Jeff' Sipek.
--
You measure democracy by the freedom it gives its dissidents, not the
freedom it gives its assimilated conformists.
- Abbie Hoffman
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 04/10] Temporary struct vfs_lookup in file_permission
On Wed, Aug 08, 2007 at 07:16:26PM +0200, Andreas Gruenbacher wrote:
> Create a temporary struct vfs_lookup in file_permission() instead of
> passing a NULL value.
>
> Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
>
> ---
> fs/namei.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -292,14 +292,15 @@ int vfs_permission(struct vfs_lookup *lo
> *
> * Used to check for read/write/execute permissions on an already opened
> * file.
> - *
> - * Note:
> - * Do not use this function in new code. All access checks should
> - * be done using vfs_permission().
Should this comment be removed?
> */
> int file_permission(struct file *file, int mask)
> {
> - return permission(file->f_path.dentry->d_inode, mask, NULL);
> + struct vfs_lookup lookup;
> +
> + lookup.path = file->f_path;
> + lookup.flags = 0;
I tend to find this little bit cleaner:
struct vfs_lookup lookup = {
.path = file->f_path,
.flags = 0,
};
> +
> + return permission(file->f_path.dentry->d_inode, mask, );
> }
>
> /*
--
Humans were created by water to transport it upward.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 04/10] Temporary struct vfs_lookup in file_permission
On Wed, Aug 08, 2007 at 07:16:26PM +0200, Andreas Gruenbacher wrote:
Create a temporary struct vfs_lookup in file_permission() instead of
passing a NULL value.
Signed-off-by: Andreas Gruenbacher [EMAIL PROTECTED]
---
fs/namei.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -292,14 +292,15 @@ int vfs_permission(struct vfs_lookup *lo
*
* Used to check for read/write/execute permissions on an already opened
* file.
- *
- * Note:
- * Do not use this function in new code. All access checks should
- * be done using vfs_permission().
Should this comment be removed?
*/
int file_permission(struct file *file, int mask)
{
- return permission(file-f_path.dentry-d_inode, mask, NULL);
+ struct vfs_lookup lookup;
+
+ lookup.path = file-f_path;
+ lookup.flags = 0;
I tend to find this little bit cleaner:
struct vfs_lookup lookup = {
.path = file-f_path,
.flags = 0,
};
+
+ return permission(file-f_path.dentry-d_inode, mask, lookup);
}
/*
--
Humans were created by water to transport it upward.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Guilt v0.27
Guilt v0.27 is available for download (once it mirrors out on kernel.org). Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like functionality and interface to git. Tarballs: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/ Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git Alright, I'm trying to get back to the 2-week release schedule, so here's v0.27! There has been a number of changes in those two weeks, Out of the 20 commits, about half of them are bug fixes of all sorts - mostly preventive (does anyone actually use whitespace in their branch names?). The major changes include some performance speedups. Little bit thought (there's more to come!) went into making guilt-push faster, 0.27 is about 8% faster than 0.26 on push. The other major thing is the infrastructure (which turned out to be really simple) for hooks. Currently, only one hook is supported (guilt-delete) but that'll change sooner or later. And the last major change under the hood: guilt now checks and expects git 1.5. Other new features: guilt-series -e to edit the series file by hand guilt-header -e to edit a patch's header guilt-refresh --diffstat to include a diffstat in the patch file As always, patches, and other feedback is welcome. Josef "Jeff" Sipek. Changes since v0.26: Dmitry Monakhov (2): Fix guilt-import patch naming Add series editor support Eric Lesh (4): Handles slashes in branch names Makefile: don't install *~ files guilt-rebase: Make fast-forward work guilt-header: Add -e option for editing Josef 'Jeff' Sipek (14): refresh: Added --diffstat option init: Be careful with whitespace in branch names guilt: check git version and bail if version is not supported guilt: Create infrastructure for guilt hooks delete: Added delete-patch hook pop: Check if no patches are applied guilt: Do not scan entire patch file when not necessary guilt: git-apply --index can be used to update the index guilt: Remove unnecessary reading of the status file push_patch: propagate return code to caller rebase: warn the user that rebase is experimental Documentation: document series -e option header: rewrite option parsing and patch searching Guilt v0.27 Michael Halcrow (1): import-commit: Retry with a different patch name if necessary - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 12/26] ext2 white-out support
On Wed, Aug 01, 2007 at 02:10:31PM -0500, Dave Kleikamp wrote:
> On Wed, 2007-08-01 at 14:44 -0400, Josef Sipek wrote:
> > Alright not the greatest of examples, there is something to be said about
> > symmetry, so...let me try again :)
> >
> > /a/
> > /b/bar (whiteout for bar)
> > /c/foo/qwerty
> >
> > Now, let's mount a union of {a,b,c}, and we'll see:
> >
> > $ find /u
> > /u
> > /u/foo
> > /u/foo/qwerty
> > $ mv /u/foo /u/bar
> >
> > Now what? How do you rename? Do you rename in the same branch (assuming it
> > is rw)?
>
> Er, no. According to Documentation/filesystems/union-mounts.txt, "only
> the topmost layer of the mount stack can be altered".
This brings up an very interesting (but painful) question...which makes more
sense? Allowing the modifications in only the top-most branch, or any branch
(given the user allows it at mount-time)?
This is really question to the community at large, not just you, Dave :)
> > 1) "cp -r" the entire subtree being renamed to highest-priority branch, and
> > rename there (you might have to recreate a series of directories to have a
> > place to "cp" to...so you got "cp -r" _AND_ "mkdir -p"-like code in the VFS!
> > 1/2 a :) )
>
> I think this is the only alternative, given the design.
Right. Doing something like this at the filesystem level (as we do in
unionfs) seems less painful - filesystems are places full of all sorts of
nefarious activities to begin with. Having it in the VFS seems...even
uglier.
Josef 'Jeff' Sipek.
--
*NOTE: This message is ROT-13 encrypted twice for extra protection*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 12/26] ext2 white-out support
On Wed, Aug 01, 2007 at 10:23:29AM -0500, Dave Kleikamp wrote:
> On Tue, 2007-07-31 at 13:11 -0400, Josef Sipek wrote:
> > On Tue, Jul 31, 2007 at 07:00:12PM +0200, Jan Blunck wrote:
> > > On Tue, Jul 31, Josef Sipek wrote:
> > >
> > > > On Mon, Jul 30, 2007 at 06:13:35PM +0200, Jan Blunck wrote:
> > > > > Introduce white-out support to ext2.
> > > >
> > > > I think storing whiteouts on the branches is wrong. It creates all sort
> > > > of
> > > > nasty cases when people actually try to use unioning. Imagine a (no-so
> > > > unlikely) scenario where you have 2 unions, and they share a branch. If
> > > > you
> > > > create a whiteout in one union on that shared branch, the whiteout
> > > > magically
> > > > affects the other union as well! Whiteouts are a union-level construct,
> > > > and
> > > > therefore storing them at the branch level is wrong.
> > >
> > > So you think that just because you mounted the filesystem somewhere else
> > > it
> > > should look different? This is what sharing is all about. If you share a
> > > filesystem you also share the removal of objects.
> >
> > The removal happens at the union level, not the branch level. Say you have:
> >
> > /a/
> > /b/foo
> > /c/foo
> >
> > And you mount /u1 as a union of {a,b}, and /u2 as union of {a,c}.
>
> Who does this? I'm assuming that a is the "top" layer. Aren't union
> mounts typically about sharing lower layers and having a separate rw
> layer for each union mount?
Alright not the greatest of examples, there is something to be said about
symmetry, so...let me try again :)
/a/
/b/bar (whiteout for bar)
/c/foo/qwerty
Now, let's mount a union of {a,b,c}, and we'll see:
$ find /u
/u
/u/foo
/u/foo/qwerty
$ mv /u/foo /u/bar
Now what? How do you rename? Do you rename in the same branch (assuming it
is rw)? If you do, you'll get:
$ find /u
/u
Oops! There's a whiteout in /b that hides the directory in /c -- rename(2)
shouldn't make directory subtrees disappear.
There are two ways to solve this:
1) "cp -r" the entire subtree being renamed to highest-priority branch, and
rename there (you might have to recreate a series of directories to have a
place to "cp" to...so you got "cp -r" _AND_ "mkdir -p"-like code in the VFS!
1/2 a :) )
2) Don't store whiteouts within branches. This makes it really easy to
rename and remove the whiteout.
Sure, you could try to rename in-place and remove the whiteout, but what if
you have:
/a/
/b/bar (whiteout)
/c/bar/blah
/d/foo/qwerty
$ mv /u/foo /u/bar
You can't just remove the whiteout, because that'd uncover the whited-out
directory bar in /c.
Josef 'Jeff' Sipek.
--
Bad pun of the week: The formula 1 control computer suffered from a race
condition
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 12/26] ext2 white-out support
On Wed, Aug 01, 2007 at 07:58:49PM +0200, Jan Engelhardt wrote: > > On Jul 31 2007 12:36, Josef Sipek wrote: > >[2] http://www.filesystems.org/unionfs-odf.txt > > >Instead, the new ODF code stores whiteouts as hardlinks to a special > >(regular) zero-length file in odf (/odf/whiteout), and it stores opaqueness > >information for directories in the inode GID bits in an ODF file system > >(e.g., ext2, XFS, etc.) on the local machine. This avoids the name-space > >pollution and avoids races with network file systems, while minimizing inode > >consummation in /odf. > > Inode GID bits - are you reducing my 32 bits of gid_t to 31 bits? > That does not work out either. No. The ODF code just uses the GID bits to store extra info. The GID is _NOT_ used to store the GID of the file. The GID of the file is still coming from the branches. Josef 'Jeff' Sipek. -- I abhor a system designed for the "user", if that word is a coded pejorative meaning "stupid and unsophisticated." - Ken Thompson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unionfs compile error ( Re: 2.6.23-rc1-mm2 )
On Wed, Aug 01, 2007 at 10:22:07AM -0700, Andrew Morton wrote: > On Wed, 01 Aug 2007 12:33:18 +0200 Gabriel C <[EMAIL PROTECTED]> wrote: > > > > > > > fs/unionfs/file.c:147: error: 'file_fsync' undeclared here (not in a > > function) > > make[2]: *** [fs/unionfs/file.o] Error 1 > > make[1]: *** [fs/unionfs] Error 2 > > make: *** [fs] Error 2 > > make: *** Waiting for unfinished jobs > > > > ... > > > > Config can be found there -> http://194.231.229.228/MM/config-auto-3 > > > > This, I assume: > > --- a/fs/unionfs/file.c~git-unionfs-fix-2 > +++ a/fs/unionfs/file.c > @@ -17,6 +17,7 @@ > */ > > #include "union.h" > +#include > > /*** > * File Operations * > _ > > (and no, sorry, I will not be complicit in that > single-header-file-which-includes-the-whole-world junk). Ouch. I had a fix for this, and it managed to get lost in the pile of patches. I'll fix it up and push fix to kernel.org. Jeff. -- I abhor a system designed for the "user", if that word is a coded pejorative meaning "stupid and unsophisticated." - Ken Thompson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 12/26] ext2 white-out support
On Wed, Aug 01, 2007 at 12:00:42PM +0200, Hans-Peter Jansen wrote: > Am Dienstag, 31. Juli 2007 19:00 schrieb Jan Blunck: > > On Tue, Jul 31, Josef Sipek wrote: > > > On Mon, Jul 30, 2007 at 06:13:35PM +0200, Jan Blunck wrote: > > > > Introduce white-out support to ext2. > > > > > > I think storing whiteouts on the branches is wrong. It creates all sort > > > of nasty cases when people actually try to use unioning. Imagine a > > > (no-so unlikely) scenario where you have 2 unions, and they share a > > > branch. If you create a whiteout in one union on that shared branch, > > > the whiteout magically affects the other union as well! Whiteouts are a > > > union-level construct, and therefore storing them at the branch level > > > is wrong. > > > > So you think that just because you mounted the filesystem somewhere else > > it should look different? This is what sharing is all about. If you share > > a filesystem you also share the removal of objects. > > No. At least I don't. > > Usage case: I heavily depend on using union mounts in diskless nfs setups, > since it drops the amount of administration of many systems _near_ one. It > boils down on installing the distribution of your choice in a directory, > union mount it ro, overlayed with a node private one (doing this in initrd > on the client for several reasons), You're not sharing the rw layer so it's a different scenario, and will not have the problem I'm talking about. See my other post [1] for exact scenario where storing whiteouts on a branch would cause problems. > add a little boot and automatic setup > machinery and be done. Since all changes are persistant, any system can be > set up individually, and still mostly only one tree is needed to keep up to > date.. Being in production in an office environment since two years without > major hassle (*). Unionfs is used by many people in this way. Josef 'Jeff' Sipek. [1] http://lkml.org/lkml/2007/7/31/365 -- Intellectuals solve problems; geniuses prevent them - Albert Einstein - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 12/26] ext2 white-out support
On Wed, Aug 01, 2007 at 12:00:42PM +0200, Hans-Peter Jansen wrote: Am Dienstag, 31. Juli 2007 19:00 schrieb Jan Blunck: On Tue, Jul 31, Josef Sipek wrote: On Mon, Jul 30, 2007 at 06:13:35PM +0200, Jan Blunck wrote: Introduce white-out support to ext2. I think storing whiteouts on the branches is wrong. It creates all sort of nasty cases when people actually try to use unioning. Imagine a (no-so unlikely) scenario where you have 2 unions, and they share a branch. If you create a whiteout in one union on that shared branch, the whiteout magically affects the other union as well! Whiteouts are a union-level construct, and therefore storing them at the branch level is wrong. So you think that just because you mounted the filesystem somewhere else it should look different? This is what sharing is all about. If you share a filesystem you also share the removal of objects. No. At least I don't. Usage case: I heavily depend on using union mounts in diskless nfs setups, since it drops the amount of administration of many systems _near_ one. It boils down on installing the distribution of your choice in a directory, union mount it ro, overlayed with a node private one (doing this in initrd on the client for several reasons), You're not sharing the rw layer so it's a different scenario, and will not have the problem I'm talking about. See my other post [1] for exact scenario where storing whiteouts on a branch would cause problems. add a little boot and automatic setup machinery and be done. Since all changes are persistant, any system can be set up individually, and still mostly only one tree is needed to keep up to date.. Being in production in an office environment since two years without major hassle (*). Unionfs is used by many people in this way. Josef 'Jeff' Sipek. [1] http://lkml.org/lkml/2007/7/31/365 -- Intellectuals solve problems; geniuses prevent them - Albert Einstein - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unionfs compile error ( Re: 2.6.23-rc1-mm2 )
On Wed, Aug 01, 2007 at 10:22:07AM -0700, Andrew Morton wrote: On Wed, 01 Aug 2007 12:33:18 +0200 Gabriel C [EMAIL PROTECTED] wrote: fs/unionfs/file.c:147: error: 'file_fsync' undeclared here (not in a function) make[2]: *** [fs/unionfs/file.o] Error 1 make[1]: *** [fs/unionfs] Error 2 make: *** [fs] Error 2 make: *** Waiting for unfinished jobs ... Config can be found there - http://194.231.229.228/MM/config-auto-3 This, I assume: --- a/fs/unionfs/file.c~git-unionfs-fix-2 +++ a/fs/unionfs/file.c @@ -17,6 +17,7 @@ */ #include union.h +#include linux/buffer_head.h /*** * File Operations * _ (and no, sorry, I will not be complicit in that single-header-file-which-includes-the-whole-world junk). Ouch. I had a fix for this, and it managed to get lost in the pile of patches. I'll fix it up and push fix to kernel.org. Jeff. -- I abhor a system designed for the user, if that word is a coded pejorative meaning stupid and unsophisticated. - Ken Thompson - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 12/26] ext2 white-out support
On Wed, Aug 01, 2007 at 07:58:49PM +0200, Jan Engelhardt wrote: On Jul 31 2007 12:36, Josef Sipek wrote: [2] http://www.filesystems.org/unionfs-odf.txt Instead, the new ODF code stores whiteouts as hardlinks to a special (regular) zero-length file in odf (/odf/whiteout), and it stores opaqueness information for directories in the inode GID bits in an ODF file system (e.g., ext2, XFS, etc.) on the local machine. This avoids the name-space pollution and avoids races with network file systems, while minimizing inode consummation in /odf. Inode GID bits - are you reducing my 32 bits of gid_t to 31 bits? That does not work out either. No. The ODF code just uses the GID bits to store extra info. The GID is _NOT_ used to store the GID of the file. The GID of the file is still coming from the branches. Josef 'Jeff' Sipek. -- I abhor a system designed for the user, if that word is a coded pejorative meaning stupid and unsophisticated. - Ken Thompson - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 12/26] ext2 white-out support
On Wed, Aug 01, 2007 at 10:23:29AM -0500, Dave Kleikamp wrote:
On Tue, 2007-07-31 at 13:11 -0400, Josef Sipek wrote:
On Tue, Jul 31, 2007 at 07:00:12PM +0200, Jan Blunck wrote:
On Tue, Jul 31, Josef Sipek wrote:
On Mon, Jul 30, 2007 at 06:13:35PM +0200, Jan Blunck wrote:
Introduce white-out support to ext2.
I think storing whiteouts on the branches is wrong. It creates all sort
of
nasty cases when people actually try to use unioning. Imagine a (no-so
unlikely) scenario where you have 2 unions, and they share a branch. If
you
create a whiteout in one union on that shared branch, the whiteout
magically
affects the other union as well! Whiteouts are a union-level construct,
and
therefore storing them at the branch level is wrong.
So you think that just because you mounted the filesystem somewhere else
it
should look different? This is what sharing is all about. If you share a
filesystem you also share the removal of objects.
The removal happens at the union level, not the branch level. Say you have:
/a/
/b/foo
/c/foo
And you mount /u1 as a union of {a,b}, and /u2 as union of {a,c}.
Who does this? I'm assuming that a is the top layer. Aren't union
mounts typically about sharing lower layers and having a separate rw
layer for each union mount?
Alright not the greatest of examples, there is something to be said about
symmetry, so...let me try again :)
/a/
/b/bar (whiteout for bar)
/c/foo/qwerty
Now, let's mount a union of {a,b,c}, and we'll see:
$ find /u
/u
/u/foo
/u/foo/qwerty
$ mv /u/foo /u/bar
Now what? How do you rename? Do you rename in the same branch (assuming it
is rw)? If you do, you'll get:
$ find /u
/u
Oops! There's a whiteout in /b that hides the directory in /c -- rename(2)
shouldn't make directory subtrees disappear.
There are two ways to solve this:
1) cp -r the entire subtree being renamed to highest-priority branch, and
rename there (you might have to recreate a series of directories to have a
place to cp to...so you got cp -r _AND_ mkdir -p-like code in the VFS!
1/2 a :) )
2) Don't store whiteouts within branches. This makes it really easy to
rename and remove the whiteout.
Sure, you could try to rename in-place and remove the whiteout, but what if
you have:
/a/
/b/bar (whiteout)
/c/bar/blah
/d/foo/qwerty
$ mv /u/foo /u/bar
You can't just remove the whiteout, because that'd uncover the whited-out
directory bar in /c.
Josef 'Jeff' Sipek.
--
Bad pun of the week: The formula 1 control computer suffered from a race
condition
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Guilt v0.27
Guilt v0.27 is available for download (once it mirrors out on kernel.org). Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like functionality and interface to git. Tarballs: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/ Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git Alright, I'm trying to get back to the 2-week release schedule, so here's v0.27! There has been a number of changes in those two weeks, Out of the 20 commits, about half of them are bug fixes of all sorts - mostly preventive (does anyone actually use whitespace in their branch names?). The major changes include some performance speedups. Little bit thought (there's more to come!) went into making guilt-push faster, 0.27 is about 8% faster than 0.26 on push. The other major thing is the infrastructure (which turned out to be really simple) for hooks. Currently, only one hook is supported (guilt-delete) but that'll change sooner or later. And the last major change under the hood: guilt now checks and expects git 1.5. Other new features: guilt-series -e to edit the series file by hand guilt-header -e to edit a patch's header guilt-refresh --diffstat to include a diffstat in the patch file As always, patches, and other feedback is welcome. Josef Jeff Sipek. Changes since v0.26: Dmitry Monakhov (2): Fix guilt-import patch naming Add series editor support Eric Lesh (4): Handles slashes in branch names Makefile: don't install *~ files guilt-rebase: Make fast-forward work guilt-header: Add -e option for editing Josef 'Jeff' Sipek (14): refresh: Added --diffstat option init: Be careful with whitespace in branch names guilt: check git version and bail if version is not supported guilt: Create infrastructure for guilt hooks delete: Added delete-patch hook pop: Check if no patches are applied guilt: Do not scan entire patch file when not necessary guilt: git-apply --index can be used to update the index guilt: Remove unnecessary reading of the status file push_patch: propagate return code to caller rebase: warn the user that rebase is experimental Documentation: document series -e option header: rewrite option parsing and patch searching Guilt v0.27 Michael Halcrow (1): import-commit: Retry with a different patch name if necessary - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 12/26] ext2 white-out support
On Wed, Aug 01, 2007 at 02:10:31PM -0500, Dave Kleikamp wrote:
On Wed, 2007-08-01 at 14:44 -0400, Josef Sipek wrote:
Alright not the greatest of examples, there is something to be said about
symmetry, so...let me try again :)
/a/
/b/bar (whiteout for bar)
/c/foo/qwerty
Now, let's mount a union of {a,b,c}, and we'll see:
$ find /u
/u
/u/foo
/u/foo/qwerty
$ mv /u/foo /u/bar
Now what? How do you rename? Do you rename in the same branch (assuming it
is rw)?
Er, no. According to Documentation/filesystems/union-mounts.txt, only
the topmost layer of the mount stack can be altered.
This brings up an very interesting (but painful) question...which makes more
sense? Allowing the modifications in only the top-most branch, or any branch
(given the user allows it at mount-time)?
This is really question to the community at large, not just you, Dave :)
1) cp -r the entire subtree being renamed to highest-priority branch, and
rename there (you might have to recreate a series of directories to have a
place to cp to...so you got cp -r _AND_ mkdir -p-like code in the VFS!
1/2 a :) )
I think this is the only alternative, given the design.
Right. Doing something like this at the filesystem level (as we do in
unionfs) seems less painful - filesystems are places full of all sorts of
nefarious activities to begin with. Having it in the VFS seems...even
uglier.
Josef 'Jeff' Sipek.
--
*NOTE: This message is ROT-13 encrypted twice for extra protection*
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 12/26] ext2 white-out support
On Tue, Jul 31, 2007 at 06:03:06PM +0100, Mark Williamson wrote: > > Really the only sane way of keeping track of whiteouts seems some external > > store. We did an experiment with Unionfs, and moving the whiteout handling > > to effectively a "library" that did all the dirty work cleaned up the code > > considerably [2,3]. > > What about keeping track of whiteouts in a special file (or files) in the top > level filesystem of the union? For instance, having a /.whiteouts file at > the root of the top FS in the stack, instead of storing union-specific data > in the flags / inode numbers of the lower levels. What is needed is a "filesystem" that has all the directory bits only. For ODF, we opted to "abuse" existing filesystems to see if it actually helped Unionfs, and I think it did help. Really, now what we (unionfs) need is a cleanup of the ODF code, with a bit better defined interface. ... > This might avoid requiring a store external to the stack of filesystems and I > believe it would solve the problem with shared branches and arbitrary > stacking that you described? We generally did a loopback mount on a file. Very similar to your idea. > I guess a rather similar effect could be had by somehow storing loopback > mountable ODF filesystems in the top layer of a union somewhere (e.g. with > the default path /.odf) and allowing the user to specify an alternate > location at mount time if necessary. So maybe these approaches are quite > similar after all... Very :) We forced the user to mount the fs in the odf loopback manually, but there's no reason why we couldn't do an in-kernel mount on unionfs mount time. Josef 'Jeff' Sipek. -- Once you have their hardware. Never give it back. (The First Rule of Hardware Acquisition) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 12/26] ext2 white-out support
On Tue, Jul 31, 2007 at 07:00:12PM +0200, Jan Blunck wrote:
> On Tue, Jul 31, Josef Sipek wrote:
>
> > On Mon, Jul 30, 2007 at 06:13:35PM +0200, Jan Blunck wrote:
> > > Introduce white-out support to ext2.
> >
> > I think storing whiteouts on the branches is wrong. It creates all sort of
> > nasty cases when people actually try to use unioning. Imagine a (no-so
> > unlikely) scenario where you have 2 unions, and they share a branch. If you
> > create a whiteout in one union on that shared branch, the whiteout magically
> > affects the other union as well! Whiteouts are a union-level construct, and
> > therefore storing them at the branch level is wrong.
>
> So you think that just because you mounted the filesystem somewhere else it
> should look different? This is what sharing is all about. If you share a
> filesystem you also share the removal of objects.
The removal happens at the union level, not the branch level. Say you have:
/a/
/b/foo
/c/foo
And you mount /u1 as a union of {a,b}, and /u2 as union of {a,c}.
$ find /u*
/u1
/u1/foo
/u2
/u2/foo
$ rm /u1/foo # this creates whiteout for "foo" in /a
$ find /u*
/u1
/u2
Is that what you'd expect as a user? I don't think so.
...
> > Really the only sane way of keeping track of whiteouts seems some external
> > store. We did an experiment with Unionfs, and moving the whiteout handling
> > to effectively a "library" that did all the dirty work cleaned up the code
> > considerably [2,3].
>
> Haven't checked if you could use ODF for a generic store for filesystems that
> couldn't support whiteouts. This might be an interesting idea.
Yes, since the ODF is completely separate, you can use _any_ filesystem and
regardless of whether or not they support whiteouts.
Josef 'Jeff' Sipek.
--
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 12/26] ext2 white-out support
On Mon, Jul 30, 2007 at 06:13:35PM +0200, Jan Blunck wrote: > Introduce white-out support to ext2. I think storing whiteouts on the branches is wrong. It creates all sort of nasty cases when people actually try to use unioning. Imagine a (no-so unlikely) scenario where you have 2 unions, and they share a branch. If you create a whiteout in one union on that shared branch, the whiteout magically affects the other union as well! Whiteouts are a union-level construct, and therefore storing them at the branch level is wrong. If you store whiteouts on the branches, you'll probably want readdir to not include them. That's relatively cheap if you have a whiteout bit in the inode, but I don't think filesystems should be forced to use up rather prescious inode bits for whiteouts/opaqueness [1]. Really the only sane way of keeping track of whiteouts seems some external store. We did an experiment with Unionfs, and moving the whiteout handling to effectively a "library" that did all the dirty work cleaned up the code considerably [2,3]. > Known Bugs: > - Needs a reserved inode number for white-outs > - S_OPAQUE isn't persistently stored Out of curiosity, how do you keep track of opaqueness while the fs is mounted? Josef 'Jeff' Sipek. [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg02904.html [2] http://www.filesystems.org/unionfs-odf.txt [3] http://download.filesystems.org/unionfs/unionfs-2.0-odf/linux-2.6.20-rc6-odf1.diff.gz -- UNIX is user-friendly ... it's just selective about who it's friends are - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 12/26] ext2 white-out support
On Mon, Jul 30, 2007 at 06:13:35PM +0200, Jan Blunck wrote: Introduce white-out support to ext2. I think storing whiteouts on the branches is wrong. It creates all sort of nasty cases when people actually try to use unioning. Imagine a (no-so unlikely) scenario where you have 2 unions, and they share a branch. If you create a whiteout in one union on that shared branch, the whiteout magically affects the other union as well! Whiteouts are a union-level construct, and therefore storing them at the branch level is wrong. If you store whiteouts on the branches, you'll probably want readdir to not include them. That's relatively cheap if you have a whiteout bit in the inode, but I don't think filesystems should be forced to use up rather prescious inode bits for whiteouts/opaqueness [1]. Really the only sane way of keeping track of whiteouts seems some external store. We did an experiment with Unionfs, and moving the whiteout handling to effectively a library that did all the dirty work cleaned up the code considerably [2,3]. Known Bugs: - Needs a reserved inode number for white-outs - S_OPAQUE isn't persistently stored Out of curiosity, how do you keep track of opaqueness while the fs is mounted? Josef 'Jeff' Sipek. [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg02904.html [2] http://www.filesystems.org/unionfs-odf.txt [3] http://download.filesystems.org/unionfs/unionfs-2.0-odf/linux-2.6.20-rc6-odf1.diff.gz -- UNIX is user-friendly ... it's just selective about who it's friends are - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 12/26] ext2 white-out support
On Tue, Jul 31, 2007 at 07:00:12PM +0200, Jan Blunck wrote:
On Tue, Jul 31, Josef Sipek wrote:
On Mon, Jul 30, 2007 at 06:13:35PM +0200, Jan Blunck wrote:
Introduce white-out support to ext2.
I think storing whiteouts on the branches is wrong. It creates all sort of
nasty cases when people actually try to use unioning. Imagine a (no-so
unlikely) scenario where you have 2 unions, and they share a branch. If you
create a whiteout in one union on that shared branch, the whiteout magically
affects the other union as well! Whiteouts are a union-level construct, and
therefore storing them at the branch level is wrong.
So you think that just because you mounted the filesystem somewhere else it
should look different? This is what sharing is all about. If you share a
filesystem you also share the removal of objects.
The removal happens at the union level, not the branch level. Say you have:
/a/
/b/foo
/c/foo
And you mount /u1 as a union of {a,b}, and /u2 as union of {a,c}.
$ find /u*
/u1
/u1/foo
/u2
/u2/foo
$ rm /u1/foo # this creates whiteout for foo in /a
$ find /u*
/u1
/u2
Is that what you'd expect as a user? I don't think so.
...
Really the only sane way of keeping track of whiteouts seems some external
store. We did an experiment with Unionfs, and moving the whiteout handling
to effectively a library that did all the dirty work cleaned up the code
considerably [2,3].
Haven't checked if you could use ODF for a generic store for filesystems that
couldn't support whiteouts. This might be an interesting idea.
Yes, since the ODF is completely separate, you can use _any_ filesystem and
regardless of whether or not they support whiteouts.
Josef 'Jeff' Sipek.
--
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 12/26] ext2 white-out support
On Tue, Jul 31, 2007 at 06:03:06PM +0100, Mark Williamson wrote: Really the only sane way of keeping track of whiteouts seems some external store. We did an experiment with Unionfs, and moving the whiteout handling to effectively a library that did all the dirty work cleaned up the code considerably [2,3]. What about keeping track of whiteouts in a special file (or files) in the top level filesystem of the union? For instance, having a /.whiteouts file at the root of the top FS in the stack, instead of storing union-specific data in the flags / inode numbers of the lower levels. What is needed is a filesystem that has all the directory bits only. For ODF, we opted to abuse existing filesystems to see if it actually helped Unionfs, and I think it did help. Really, now what we (unionfs) need is a cleanup of the ODF code, with a bit better defined interface. ... This might avoid requiring a store external to the stack of filesystems and I believe it would solve the problem with shared branches and arbitrary stacking that you described? We generally did a loopback mount on a file. Very similar to your idea. I guess a rather similar effect could be had by somehow storing loopback mountable ODF filesystems in the top layer of a union somewhere (e.g. with the default path /.odf) and allowing the user to specify an alternate location at mount time if necessary. So maybe these approaches are quite similar after all... Very :) We forced the user to mount the fs in the odf loopback manually, but there's no reason why we couldn't do an in-kernel mount on unionfs mount time. Josef 'Jeff' Sipek. -- Once you have their hardware. Never give it back. (The First Rule of Hardware Acquisition) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] eCryptfs: Fix Tag 1 parsing code
On Thu, Jul 19, 2007 at 04:28:01PM -0500, Michael Halcrow wrote:
> Fix up the Tag 1 parsing code to handle size limits and boundaries
> more explicitly. Initialize the new auth_tok's flags.
...
> - if (unlikely((*packet_size) + 3 > max_packet_size)) {
> - ecryptfs_printk(KERN_ERR, "Packet size exceeds max\n");
> + if (unlikely(max_packet_size < 12)) {
> + printk(KERN_ERR "Invalid max packet size; must be >=12\n");
Hardcoded 12?
Josef 'Jeff' Sipek.
--
Humans were created by water to transport it upward.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] eCryptfs: Fix Tag 1 parsing code
On Thu, Jul 19, 2007 at 04:28:01PM -0500, Michael Halcrow wrote:
Fix up the Tag 1 parsing code to handle size limits and boundaries
more explicitly. Initialize the new auth_tok's flags.
...
- if (unlikely((*packet_size) + 3 max_packet_size)) {
- ecryptfs_printk(KERN_ERR, Packet size exceeds max\n);
+ if (unlikely(max_packet_size 12)) {
+ printk(KERN_ERR Invalid max packet size; must be =12\n);
Hardcoded 12?
Josef 'Jeff' Sipek.
--
Humans were created by water to transport it upward.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: XFS -git changes and Linux-VServer patch porting
On Wed, Jul 18, 2007 at 03:49:07PM +0200, Radoslaw Szkodzinski wrote: > Linux-VServer patch adds 2 new flags: barrier and iunlink. > With recent changes in -git (filestreams), XFS now lacks di_flags bits > to add these. > iunlink flag adds Copy-on-Write semantics to hard links, while barrier > flag signifies a filesystem barrier no virtual context can pass. > > I'd like to know how to possibly resolve this problem w/o negatively > impacting performance (especially of iunlink) or changing on-disc > format in an incompatible way, as well as being more future-proof. A while back, I mentioned that it would be nice to have a whiteout inode flag (I've since changed my mind) but the answer I got from Dave Chinner, et. al., was to use xattrs. Josef 'Jeff' Sipek. -- If I have trouble installing Linux, something is wrong. Very wrong. - Linus Torvalds - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS -git changes and Linux-VServer patch porting
On Wed, Jul 18, 2007 at 03:49:07PM +0200, Radoslaw Szkodzinski wrote: Linux-VServer patch adds 2 new flags: barrier and iunlink. With recent changes in -git (filestreams), XFS now lacks di_flags bits to add these. iunlink flag adds Copy-on-Write semantics to hard links, while barrier flag signifies a filesystem barrier no virtual context can pass. I'd like to know how to possibly resolve this problem w/o negatively impacting performance (especially of iunlink) or changing on-disc format in an incompatible way, as well as being more future-proof. A while back, I mentioned that it would be nice to have a whiteout inode flag (I've since changed my mind) but the answer I got from Dave Chinner, et. al., was to use xattrs. Josef 'Jeff' Sipek. -- If I have trouble installing Linux, something is wrong. Very wrong. - Linus Torvalds - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/17] lib: percpu_count_sum_signed()
On Tue, Jul 17, 2007 at 12:32:43PM -0400, Josef Sipek wrote:
> On Thu, Jun 14, 2007 at 11:58:22PM +0200, Peter Zijlstra wrote:
> > Provide an accurate version of percpu_counter_read.
> >
> > Should we go and replace the current use of percpu_counter_sum()
> > with percpu_counter_sum_positive(), and call this new primitive
> > percpu_counter_sum() instead?
> >
> > Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> > ---
> > include/linux/percpu_counter.h | 18 +-
> > lib/percpu_counter.c |6 +++---
> > 2 files changed, 20 insertions(+), 4 deletions(-)
> >
> > Index: linux-2.6/include/linux/percpu_counter.h
> > ===
> > --- linux-2.6.orig/include/linux/percpu_counter.h 2007-05-23
> > 20:37:54.0 +0200
> > +++ linux-2.6/include/linux/percpu_counter.h2007-05-23
> > 20:38:09.0 +0200
> > @@ -35,7 +35,18 @@ void percpu_counter_destroy(struct percp
> > void percpu_counter_set(struct percpu_counter *fbc, s64 amount);
> > void __percpu_counter_mod(struct percpu_counter *fbc, s32 amount, s32
> > batch);
> > void __percpu_counter_mod64(struct percpu_counter *fbc, s64 amount, s32
> > batch);
> > -s64 percpu_counter_sum(struct percpu_counter *fbc);
> > +s64 __percpu_counter_sum(struct percpu_counter *fbc);
> > +
> > +static inline s64 percpu_counter_sum(struct percpu_counter *fbc)
> > +{
> > + s64 ret = __percpu_counter_sum(fbc);
> > + return ret < 0 ? 0 : ret;
>
> max(0, ret) maybe?
>
> Josef 'Jeff' Sipek.
Ok, replying to email that's more than a month old may not be the best idea
:)
Josef 'Jeff' Sipek.
--
We have joy, we have fun, we have Linux on a Sun...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/17] lib: percpu_counter_init_irq
On Thu, Jun 14, 2007 at 11:58:23PM +0200, Peter Zijlstra wrote:
> provide a way to init percpu_counters that are supposed to be used from irq
> safe contexts.
>
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> ---
> include/linux/percpu_counter.h |4
> lib/percpu_counter.c |8
> 2 files changed, 12 insertions(+)
>
> Index: linux-2.6/include/linux/percpu_counter.h
> ===
> --- linux-2.6.orig/include/linux/percpu_counter.h
> +++ linux-2.6/include/linux/percpu_counter.h
> @@ -31,6 +31,8 @@ struct percpu_counter {
> #endif
>
> void percpu_counter_init(struct percpu_counter *fbc, s64 amount);
> +void percpu_counter_init_irq(struct percpu_counter *fbc, s64 amount);
> +
> void percpu_counter_destroy(struct percpu_counter *fbc);
> void percpu_counter_set(struct percpu_counter *fbc, s64 amount);
> void __percpu_counter_mod(struct percpu_counter *fbc, s32 amount, s32 batch);
> @@ -89,6 +91,8 @@ static inline void percpu_counter_init(s
> fbc->count = amount;
> }
>
> +#define percpu_counter_init_irq percpu_counter_init
Huh? I'm confused. You have prototypes for both, and now a #define?
Josef 'Jeff' Sipek.
--
Hegh QaQ law'
quvHa'ghach QaQ puS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/17] lib: percpu_count_sum_signed()
On Thu, Jun 14, 2007 at 11:58:22PM +0200, Peter Zijlstra wrote:
> Provide an accurate version of percpu_counter_read.
>
> Should we go and replace the current use of percpu_counter_sum()
> with percpu_counter_sum_positive(), and call this new primitive
> percpu_counter_sum() instead?
>
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> ---
> include/linux/percpu_counter.h | 18 +-
> lib/percpu_counter.c |6 +++---
> 2 files changed, 20 insertions(+), 4 deletions(-)
>
> Index: linux-2.6/include/linux/percpu_counter.h
> ===
> --- linux-2.6.orig/include/linux/percpu_counter.h 2007-05-23
> 20:37:54.0 +0200
> +++ linux-2.6/include/linux/percpu_counter.h 2007-05-23 20:38:09.0
> +0200
> @@ -35,7 +35,18 @@ void percpu_counter_destroy(struct percp
> void percpu_counter_set(struct percpu_counter *fbc, s64 amount);
> void __percpu_counter_mod(struct percpu_counter *fbc, s32 amount, s32 batch);
> void __percpu_counter_mod64(struct percpu_counter *fbc, s64 amount, s32
> batch);
> -s64 percpu_counter_sum(struct percpu_counter *fbc);
> +s64 __percpu_counter_sum(struct percpu_counter *fbc);
> +
> +static inline s64 percpu_counter_sum(struct percpu_counter *fbc)
> +{
> + s64 ret = __percpu_counter_sum(fbc);
> + return ret < 0 ? 0 : ret;
max(0, ret) maybe?
Josef 'Jeff' Sipek.
--
Real Programmers consider "what you see is what you get" to be just as bad a
concept in Text Editors as it is in women. No, the Real Programmer wants a
"you asked for it, you got it" text editor -- complicated, cryptic,
powerful, unforgiving, dangerous.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Guilt v0.26
Guilt v0.26 is available for download (once it mirrors out on kernel.org). Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like functionality and interface to git. Tarballs: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/ Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git Although there was a v0.26-rc1 release, I never announced it so the following summary includes all the changes since v0.25. Unfortunately, it took two months to get this release out. I promise to get back to the 2-3 week release cycle. The major change since v0.25 (contributed by Pierre Habouzit) is that Guilt no longer depends on bash. Other than that, there have been a number of bug fixes, as well several new commands and options: branch Branch the repository & patch series diffOutput a diff against the top-most applied patch fold -k Keep patch file graph Generate dot(1) patch dependecy graph new -f Force new patch creation refresh --git Detect renames & copies series -g Start gitk on the applied patches Additionally, Guilt now knows how to: Grab Cc: lines from the patch descriptions for patchbomb Strip 'Subject: ' from the first line of patch description All in all, quite a number of changes, so it is possible that I forgot to mention something. For more details, check the change list below, or the git repository near you :) As always, patches, and other feedback is welcome. Josef "Jeff" Sipek. Changes since v0.25: Josef 'Jeff' Sipek (20): graph: generate a dot(1) dependency graph of patches graph: Remove graph cache after command terminates new: Added new option, -f to force new patch creation refresh: Added --git option to generate more git friendly diff new: current working dir should not be displayed export: Create subdirectories before copying the patch files series: Added -g option to start gitk refresh: Reintroduce the --git option that got accidentally dropped guilt: added -V/--version option to display only the version number fold: Added -k option to keep patch file Guilt v0.26-rc1 guilt: Strip "^Subject: " from first line of patch message Docs/Requirements: sh is now required instead of bash branch: new command to create a new branch with duplicated patches directory Docs: A begining of a Features file graph: Fixed graph generation patchbomb: Grab additional Cc info from '^Cc:' lines in patch desc patchbomb: Remove leftover debug code diff: Create a diff against the top-most applied patch Guilt v0.26 Pierre Habouzit (8): Add a guilt-export(1) command to export a guilt series to quilt. guilt(1): Obvious bashisms fixed. guilt(1): simplifications... guilt(1): reimplement push_patch, using a subshell to avoid locals. Remove bashisms - easy commands guilt-status(1): Remove bashisms. Remove last bashisms from remaining commands. Regression test suite needs bash, that's OK. Theodore Ts'o (1): Fix guilt to work correctly even if the refs are packed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Guilt v0.26
Guilt v0.26 is available for download (once it mirrors out on kernel.org). Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like functionality and interface to git. Tarballs: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/ Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git Although there was a v0.26-rc1 release, I never announced it so the following summary includes all the changes since v0.25. Unfortunately, it took two months to get this release out. I promise to get back to the 2-3 week release cycle. The major change since v0.25 (contributed by Pierre Habouzit) is that Guilt no longer depends on bash. Other than that, there have been a number of bug fixes, as well several new commands and options: branch Branch the repository patch series diffOutput a diff against the top-most applied patch fold -k Keep patch file graph Generate dot(1) patch dependecy graph new -f Force new patch creation refresh --git Detect renames copies series -g Start gitk on the applied patches Additionally, Guilt now knows how to: Grab Cc: lines from the patch descriptions for patchbomb Strip 'Subject: ' from the first line of patch description All in all, quite a number of changes, so it is possible that I forgot to mention something. For more details, check the change list below, or the git repository near you :) As always, patches, and other feedback is welcome. Josef Jeff Sipek. Changes since v0.25: Josef 'Jeff' Sipek (20): graph: generate a dot(1) dependency graph of patches graph: Remove graph cache after command terminates new: Added new option, -f to force new patch creation refresh: Added --git option to generate more git friendly diff new: current working dir should not be displayed export: Create subdirectories before copying the patch files series: Added -g option to start gitk refresh: Reintroduce the --git option that got accidentally dropped guilt: added -V/--version option to display only the version number fold: Added -k option to keep patch file Guilt v0.26-rc1 guilt: Strip ^Subject: from first line of patch message Docs/Requirements: sh is now required instead of bash branch: new command to create a new branch with duplicated patches directory Docs: A begining of a Features file graph: Fixed graph generation patchbomb: Grab additional Cc info from '^Cc:' lines in patch desc patchbomb: Remove leftover debug code diff: Create a diff against the top-most applied patch Guilt v0.26 Pierre Habouzit (8): Add a guilt-export(1) command to export a guilt series to quilt. guilt(1): Obvious bashisms fixed. guilt(1): simplifications... guilt(1): reimplement push_patch, using a subshell to avoid locals. Remove bashisms - easy commands guilt-status(1): Remove bashisms. Remove last bashisms from remaining commands. Regression test suite needs bash, that's OK. Theodore Ts'o (1): Fix guilt to work correctly even if the refs are packed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/17] lib: percpu_count_sum_signed()
On Thu, Jun 14, 2007 at 11:58:22PM +0200, Peter Zijlstra wrote:
Provide an accurate version of percpu_counter_read.
Should we go and replace the current use of percpu_counter_sum()
with percpu_counter_sum_positive(), and call this new primitive
percpu_counter_sum() instead?
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
---
include/linux/percpu_counter.h | 18 +-
lib/percpu_counter.c |6 +++---
2 files changed, 20 insertions(+), 4 deletions(-)
Index: linux-2.6/include/linux/percpu_counter.h
===
--- linux-2.6.orig/include/linux/percpu_counter.h 2007-05-23
20:37:54.0 +0200
+++ linux-2.6/include/linux/percpu_counter.h 2007-05-23 20:38:09.0
+0200
@@ -35,7 +35,18 @@ void percpu_counter_destroy(struct percp
void percpu_counter_set(struct percpu_counter *fbc, s64 amount);
void __percpu_counter_mod(struct percpu_counter *fbc, s32 amount, s32 batch);
void __percpu_counter_mod64(struct percpu_counter *fbc, s64 amount, s32
batch);
-s64 percpu_counter_sum(struct percpu_counter *fbc);
+s64 __percpu_counter_sum(struct percpu_counter *fbc);
+
+static inline s64 percpu_counter_sum(struct percpu_counter *fbc)
+{
+ s64 ret = __percpu_counter_sum(fbc);
+ return ret 0 ? 0 : ret;
max(0, ret) maybe?
Josef 'Jeff' Sipek.
--
Real Programmers consider what you see is what you get to be just as bad a
concept in Text Editors as it is in women. No, the Real Programmer wants a
you asked for it, you got it text editor -- complicated, cryptic,
powerful, unforgiving, dangerous.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/17] lib: percpu_counter_init_irq
On Thu, Jun 14, 2007 at 11:58:23PM +0200, Peter Zijlstra wrote:
provide a way to init percpu_counters that are supposed to be used from irq
safe contexts.
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
---
include/linux/percpu_counter.h |4
lib/percpu_counter.c |8
2 files changed, 12 insertions(+)
Index: linux-2.6/include/linux/percpu_counter.h
===
--- linux-2.6.orig/include/linux/percpu_counter.h
+++ linux-2.6/include/linux/percpu_counter.h
@@ -31,6 +31,8 @@ struct percpu_counter {
#endif
void percpu_counter_init(struct percpu_counter *fbc, s64 amount);
+void percpu_counter_init_irq(struct percpu_counter *fbc, s64 amount);
+
void percpu_counter_destroy(struct percpu_counter *fbc);
void percpu_counter_set(struct percpu_counter *fbc, s64 amount);
void __percpu_counter_mod(struct percpu_counter *fbc, s32 amount, s32 batch);
@@ -89,6 +91,8 @@ static inline void percpu_counter_init(s
fbc-count = amount;
}
+#define percpu_counter_init_irq percpu_counter_init
Huh? I'm confused. You have prototypes for both, and now a #define?
Josef 'Jeff' Sipek.
--
Hegh QaQ law'
quvHa'ghach QaQ puS
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/17] lib: percpu_count_sum_signed()
On Tue, Jul 17, 2007 at 12:32:43PM -0400, Josef Sipek wrote:
On Thu, Jun 14, 2007 at 11:58:22PM +0200, Peter Zijlstra wrote:
Provide an accurate version of percpu_counter_read.
Should we go and replace the current use of percpu_counter_sum()
with percpu_counter_sum_positive(), and call this new primitive
percpu_counter_sum() instead?
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
---
include/linux/percpu_counter.h | 18 +-
lib/percpu_counter.c |6 +++---
2 files changed, 20 insertions(+), 4 deletions(-)
Index: linux-2.6/include/linux/percpu_counter.h
===
--- linux-2.6.orig/include/linux/percpu_counter.h 2007-05-23
20:37:54.0 +0200
+++ linux-2.6/include/linux/percpu_counter.h2007-05-23
20:38:09.0 +0200
@@ -35,7 +35,18 @@ void percpu_counter_destroy(struct percp
void percpu_counter_set(struct percpu_counter *fbc, s64 amount);
void __percpu_counter_mod(struct percpu_counter *fbc, s32 amount, s32
batch);
void __percpu_counter_mod64(struct percpu_counter *fbc, s64 amount, s32
batch);
-s64 percpu_counter_sum(struct percpu_counter *fbc);
+s64 __percpu_counter_sum(struct percpu_counter *fbc);
+
+static inline s64 percpu_counter_sum(struct percpu_counter *fbc)
+{
+ s64 ret = __percpu_counter_sum(fbc);
+ return ret 0 ? 0 : ret;
max(0, ret) maybe?
Josef 'Jeff' Sipek.
Ok, replying to email that's more than a month old may not be the best idea
:)
Josef 'Jeff' Sipek.
--
We have joy, we have fun, we have Linux on a Sun...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] unionfs: make functions static
On Mon, Jul 02, 2007 at 04:27:59AM +0200, Adrian Bunk wrote: > On Sun, Jul 01, 2007 at 09:42:49PM -0400, Josef Sipek wrote: > > On Sun, Jul 01, 2007 at 10:23:30PM +0200, Adrian Bunk wrote: > > > This patch makes some needlessly global functions static. > > > > > ... > > > --- linux-2.6.22-rc6-mm1/fs/unionfs/lookup.c.old 2007-07-01 > > > 00:05:02.0 +0200 > > > +++ linux-2.6.22-rc6-mm1/fs/unionfs/lookup.c 2007-07-01 > > > 00:06:05.0 +0200 > > > @@ -18,6 +18,8 @@ > > > > > > #include "union.h" > > > > > > +static int realloc_dentry_private_data(struct dentry *dentry); > > > + > > > /* is the filename valid == !(whiteout for a file or opaque dir marker) > > > */ > > > > I forget who said it, but someone wasn't very happy with prototypes like > > that in .c files. What's the prefered way - are they ok for static symbols? > > It might have even been me who said this - but about global functions. > > For global functions, prototypes in header files allow gcc to check > whether the prototype matches the actual function. With a prototype > in the C file of the caller that's not possible, and if they are > different it can result in nasty runtime errors. > > For static functions that's not an issue since gcc sees both the > prototype and the actual function. Ok, fair enough. Applied & pushed to korg tree. Thanks. Josef "Jeff" Sipek. -- Once you have their hardware. Never give it back. (The First Rule of Hardware Acquisition) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] unionfs: make functions static
On Mon, Jul 02, 2007 at 04:27:59AM +0200, Adrian Bunk wrote: On Sun, Jul 01, 2007 at 09:42:49PM -0400, Josef Sipek wrote: On Sun, Jul 01, 2007 at 10:23:30PM +0200, Adrian Bunk wrote: This patch makes some needlessly global functions static. ... --- linux-2.6.22-rc6-mm1/fs/unionfs/lookup.c.old 2007-07-01 00:05:02.0 +0200 +++ linux-2.6.22-rc6-mm1/fs/unionfs/lookup.c 2007-07-01 00:06:05.0 +0200 @@ -18,6 +18,8 @@ #include union.h +static int realloc_dentry_private_data(struct dentry *dentry); + /* is the filename valid == !(whiteout for a file or opaque dir marker) */ I forget who said it, but someone wasn't very happy with prototypes like that in .c files. What's the prefered way - are they ok for static symbols? It might have even been me who said this - but about global functions. For global functions, prototypes in header files allow gcc to check whether the prototype matches the actual function. With a prototype in the C file of the caller that's not possible, and if they are different it can result in nasty runtime errors. For static functions that's not an issue since gcc sees both the prototype and the actual function. Ok, fair enough. Applied pushed to korg tree. Thanks. Josef Jeff Sipek. -- Once you have their hardware. Never give it back. (The First Rule of Hardware Acquisition) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] unionfs: make functions static
On Sun, Jul 01, 2007 at 10:23:30PM +0200, Adrian Bunk wrote: > This patch makes some needlessly global functions static. > ... > --- linux-2.6.22-rc6-mm1/fs/unionfs/lookup.c.old 2007-07-01 > 00:05:02.0 +0200 > +++ linux-2.6.22-rc6-mm1/fs/unionfs/lookup.c 2007-07-01 00:06:05.0 > +0200 > @@ -18,6 +18,8 @@ > > #include "union.h" > > +static int realloc_dentry_private_data(struct dentry *dentry); > + > /* is the filename valid == !(whiteout for a file or opaque dir marker) */ I forget who said it, but someone wasn't very happy with prototypes like that in .c files. What's the prefered way - are they ok for static symbols? Josef "Jeff" Sipek. -- We have joy, we have fun, we have Linux on a Sun... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] unionfs: make functions static
On Sun, Jul 01, 2007 at 10:23:30PM +0200, Adrian Bunk wrote: This patch makes some needlessly global functions static. ... --- linux-2.6.22-rc6-mm1/fs/unionfs/lookup.c.old 2007-07-01 00:05:02.0 +0200 +++ linux-2.6.22-rc6-mm1/fs/unionfs/lookup.c 2007-07-01 00:06:05.0 +0200 @@ -18,6 +18,8 @@ #include union.h +static int realloc_dentry_private_data(struct dentry *dentry); + /* is the filename valid == !(whiteout for a file or opaque dir marker) */ I forget who said it, but someone wasn't very happy with prototypes like that in .c files. What's the prefered way - are they ok for static symbols? Josef Jeff Sipek. -- We have joy, we have fun, we have Linux on a Sun... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/4] Mount changes to support union mount.
On Wed, Jun 20, 2007 at 02:23:30PM +0530, Bharata B Rao wrote:
> (replying from a different ID as you didn't copy me on reply)
>
> On 6/20/07, Jan Blunck <[EMAIL PROTECTED]> wrote:
> >On Wed, 20 Jun 2007 11:22:41 +0530, Bharata B Rao wrote:
> >
> >> +/*
> >> + * When propagating mount events to peer group, this is called under
> >> + * vfsmount_lock. Hence using GFP_ATOMIC for kmalloc here.
> >> + * TODO: Can we use a separate kmem cache for union_mount ?
> >> + */
> >> +struct union_mount *alloc_union_mount(struct vfsmount *src_mnt,
> >> + struct dentry *src_dentry, struct vfsmount *dst_mnt,
> >> + struct dentry *dst_dentry)
> >> +{
> >> + struct union_mount *u;
> >> + u = kmalloc(sizeof(struct union_mount), GFP_ATOMIC);
> >> + if (!u)
> >> + return u;
> >> + u->dst_mnt = mntget(dst_mnt);
> >> + u->dst_dentry = dget(dst_dentry);
> >> + u->src_mnt = src_mnt;
> >> + u->src_dentry = dget(src_dentry);
> >> + INIT_LIST_HEAD(>hash);
> >> + INIT_LIST_HEAD(>list);
> >> + return u;
> >> +}
> >
> >Hmm, you pin the dentries in memory until umount. This isn't good. Besides
> >that this doesn't work with file systems that do invalidate their
> >dentries. The file system must have a chance to replace the dentry in the
> >union structure.
>
> Yes, both top level and next level dentries are pinned until umount of
> the upper layer. I was thinking if we could prune these from
> prune_dcache(). What do you think ?
>
> Ok, I haven't thought about filesystem invalidating the dentries. Yet
> to understand the dentry invalidation, but would filesystem invalidate
> an inuse dentry ?
NFS, and quite possibly other network/cluster filesystems can encounter all
sort of odd conditions where the dentry might change, no?
Josef "Jeff" Sipek.
--
Hegh QaQ law'
quvHa'ghach QaQ puS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/4] Union mount documentation.
On Thu, Jun 21, 2007 at 10:55:45AM +0530, Bharata B Rao wrote: ... > Talking about copyup and whiteout at VFS layer, we have already > demonstrated what complexity it takes to have these within VFS. Please > take a look at the copyup and whiteout patches in our previous > releases at: > > http://lkml.org/lkml/2007/4/17/150 > http://lkml.org/lkml/2007/5/14/69 > > Or may be wait till I clean all those up to work with the new union > new stack infrastructure which I have posted here. Really, the problem for both, union mounts and unionfs, is that the concept of unioning spans the two layers. You have the unification part - which is very VFS-level concept, but at the same time, you got whiteouts, copyup, (semi-?)persistent inode numbers, and a bunch of other details that just don't belong in the VFS at all. Josef "Jeff" Sipek. -- Evolution, n.: A hypothetical process whereby infinitely improbable events occur with alarming frequency, order arises from chaos, and no one is given credit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/4] Union mount documentation.
On Thu, Jun 21, 2007 at 10:55:45AM +0530, Bharata B Rao wrote: ... Talking about copyup and whiteout at VFS layer, we have already demonstrated what complexity it takes to have these within VFS. Please take a look at the copyup and whiteout patches in our previous releases at: http://lkml.org/lkml/2007/4/17/150 http://lkml.org/lkml/2007/5/14/69 Or may be wait till I clean all those up to work with the new union new stack infrastructure which I have posted here. Really, the problem for both, union mounts and unionfs, is that the concept of unioning spans the two layers. You have the unification part - which is very VFS-level concept, but at the same time, you got whiteouts, copyup, (semi-?)persistent inode numbers, and a bunch of other details that just don't belong in the VFS at all. Josef Jeff Sipek. -- Evolution, n.: A hypothetical process whereby infinitely improbable events occur with alarming frequency, order arises from chaos, and no one is given credit. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/4] Mount changes to support union mount.
On Wed, Jun 20, 2007 at 02:23:30PM +0530, Bharata B Rao wrote:
(replying from a different ID as you didn't copy me on reply)
On 6/20/07, Jan Blunck [EMAIL PROTECTED] wrote:
On Wed, 20 Jun 2007 11:22:41 +0530, Bharata B Rao wrote:
+/*
+ * When propagating mount events to peer group, this is called under
+ * vfsmount_lock. Hence using GFP_ATOMIC for kmalloc here.
+ * TODO: Can we use a separate kmem cache for union_mount ?
+ */
+struct union_mount *alloc_union_mount(struct vfsmount *src_mnt,
+ struct dentry *src_dentry, struct vfsmount *dst_mnt,
+ struct dentry *dst_dentry)
+{
+ struct union_mount *u;
+ u = kmalloc(sizeof(struct union_mount), GFP_ATOMIC);
+ if (!u)
+ return u;
+ u-dst_mnt = mntget(dst_mnt);
+ u-dst_dentry = dget(dst_dentry);
+ u-src_mnt = src_mnt;
+ u-src_dentry = dget(src_dentry);
+ INIT_LIST_HEAD(u-hash);
+ INIT_LIST_HEAD(u-list);
+ return u;
+}
Hmm, you pin the dentries in memory until umount. This isn't good. Besides
that this doesn't work with file systems that do invalidate their
dentries. The file system must have a chance to replace the dentry in the
union structure.
Yes, both top level and next level dentries are pinned until umount of
the upper layer. I was thinking if we could prune these from
prune_dcache(). What do you think ?
Ok, I haven't thought about filesystem invalidating the dentries. Yet
to understand the dentry invalidation, but would filesystem invalidate
an inuse dentry ?
NFS, and quite possibly other network/cluster filesystems can encounter all
sort of odd conditions where the dentry might change, no?
Josef Jeff Sipek.
--
Hegh QaQ law'
quvHa'ghach QaQ puS
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Guilt v0.25
Guilt v0.25 is available for download (once it mirrors out on kernel.org). Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like functionality and interface to git. Tarballs: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/ Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git Really the only major changes are the new commands: import and rebase. guilt-import allows one to import a patch into the Guilt series easily guilt-rebase is very similar to git-rebase - it detects patches that were pushed upstream. NOTE: This command is still not perfect, so use it with caution. As always, patches, and other feedback is welcome. Josef "Jeff" Sipek. Changes since v0.24: Josef 'Jeff' Sipek (13): Docs: Fixed two small typos import: import a patch command import: Added -P to specify a name of the patch file within guilt new: Add an empty line after the message/signed-off-by guilt: be more careful when parsing hash ranges patchbomb: Added --in-reply-to argument rebase: Rebase pushed patches against an upstream branch docs: Skeleton of the rebase docs rebase: removed some leftover bits from git-cherry rebase: comment out patch instead of removing it rebase: created a helper function to pop all patches Fixed $PAGER detection logic Guilt v0.25 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Guilt v0.25
Guilt v0.25 is available for download (once it mirrors out on kernel.org). Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like functionality and interface to git. Tarballs: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/ Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git Really the only major changes are the new commands: import and rebase. guilt-import allows one to import a patch into the Guilt series easily guilt-rebase is very similar to git-rebase - it detects patches that were pushed upstream. NOTE: This command is still not perfect, so use it with caution. As always, patches, and other feedback is welcome. Josef Jeff Sipek. Changes since v0.24: Josef 'Jeff' Sipek (13): Docs: Fixed two small typos import: import a patch command import: Added -P to specify a name of the patch file within guilt new: Add an empty line after the message/signed-off-by guilt: be more careful when parsing hash ranges patchbomb: Added --in-reply-to argument rebase: Rebase pushed patches against an upstream branch docs: Skeleton of the rebase docs rebase: removed some leftover bits from git-cherry rebase: comment out patch instead of removing it rebase: created a helper function to pop all patches Fixed $PAGER detection logic Guilt v0.25 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22 -mm merge plans
On Mon, Apr 30, 2007 at 04:20:07PM -0700, Andrew Morton wrote: ... > git-unionfs.patch > > Does this have a future? Yes! There are many active users who use our unioning functionality. Namespace unification consists of several major parts: 1) Duplicate elimination: This can be handled in the VFS. However, it would clutter up the VFS code with a lot of wrappers around key VFS functions to select the appropriate dentry/inode/etc. object from the underlying branch. (You also need to provide efficient and sane readdir/seekdir semantics which we do with our "On Disk Format" support.) 2) Copyup: Having a unified namespace by itself isn't enough. You also need copy-on-write functionality when the source file is on a read-only branch. This makes unioning much more useful and is one of the main attractions to unionfs users. 3) Whiteouts: Whiteouts are a key unioning construct. As it was pointed out at OLS 2006, they are a properly of the union and _NOT_ a branch. Therefore, they should not be stored persistently on a branch but rather in some "external" storage. 4) You also need unique and *persistent* inode numbers for network f/s exports and other unix tools. 5) You need to provide dynamic branch management functionality: adding, removing, and changing the mode of branches in an existing union. We have considerable experience in unioning file systems for years now; we are currently working on the third generation of the code. All of the above features, and more, are USED by users, and are NEEDED by users. We believe the right approach is the one we've taken, and is the least intrusive: a standalone (stackable) file system that doesn't clutter the VFS, with some small and gradual changes to the VFS to support stacking. As you may have noticed, we have been successfully submitting VFS patches to make the VFS more stacking friendly (not just to Unionfs, but also to eCryptfs which has been in since 2.6.19). The older Union mounts, alas, try to put all that functionality into the VFS. We recognize that some people think that union mounts at the VFS level is the "elegant" approach, but we hope people will listen to us and learn from our experience: unioning may seem simple in principle, but it is difficult in practice. (See http://unionfs.fileystems.org/ for a lot more info.) So we don't think that is a viable long term approach to have all of the unioning functionality in the VFS for two main reasons: (1) If you want users to use a VFS-level unioning functionality ala union-mounts, then you're going to have to implement *all* of the features we have implemented; the VFS clutter and complexity that will result will be very considerable, and we just don't think that it'd happen. (2) Some may suggest to have a lightweight union mounts that only offers a subset of the functionality that's suitable for placing in the VFS. In that case, most unionfs users simply won't use it. You'd need union mounts to provide ALL of the functionality that we have TODAY, if you want users to it. As far as we can see the remaining stumbling block right now is cache coherency between the layers. Whether you provide unioning as a stackable f/s or shoved into the VFS, coherency will have to be addressed. In our upcoming paper and talk at OLS'07, we plan to bring up and discuss several ideas we've explored already on how to resolve this incoherency. Our ideas range from complex graph-based pointer management between objects of all sorts, to simple timestamp-based VFS hooks. (We've been experimenting with several approaches and so far we're leaning toward the simple timestamp based on, again in the interest of keeping the VFS changes simple. We hope to have more results to report by OLS time.) Josef "Jeff" Sipek, on behalf of the Unionfs team. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21-mm1] remove unionfs reference to SLAB_CTOR_VERIFY
On Mon, May 07, 2007 at 11:22:32AM -0400, Lee Schermerhorn wrote: > With unionfs included as a module, 2.6.21-mm1 build broke with: > > fs/unionfs/super.c: In function ‘init_once’: > fs/unionfs/super.c:822: error: ‘SLAB_CTOR_VERIFY’ undeclared (first use in > this function) > fs/unionfs/super.c:822: error: (Each undeclared identifier is reported only > oncefs/unionfs/super.c:822: error: for each function it appears in.) > > Looks like it missed the removal of SLAB_CTOR_VERIFY. This fix (by Adrian Bunk) is already in the unionfs git tree. Thanks anyway. Josef "Jeff" Sipek. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21-mm1] remove unionfs reference to SLAB_CTOR_VERIFY
On Mon, May 07, 2007 at 11:22:32AM -0400, Lee Schermerhorn wrote: With unionfs included as a module, 2.6.21-mm1 build broke with: fs/unionfs/super.c: In function ‘init_once’: fs/unionfs/super.c:822: error: ‘SLAB_CTOR_VERIFY’ undeclared (first use in this function) fs/unionfs/super.c:822: error: (Each undeclared identifier is reported only oncefs/unionfs/super.c:822: error: for each function it appears in.) Looks like it missed the removal of SLAB_CTOR_VERIFY. This fix (by Adrian Bunk) is already in the unionfs git tree. Thanks anyway. Josef Jeff Sipek. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22 -mm merge plans
On Mon, Apr 30, 2007 at 04:20:07PM -0700, Andrew Morton wrote: ... git-unionfs.patch Does this have a future? Yes! There are many active users who use our unioning functionality. Namespace unification consists of several major parts: 1) Duplicate elimination: This can be handled in the VFS. However, it would clutter up the VFS code with a lot of wrappers around key VFS functions to select the appropriate dentry/inode/etc. object from the underlying branch. (You also need to provide efficient and sane readdir/seekdir semantics which we do with our On Disk Format support.) 2) Copyup: Having a unified namespace by itself isn't enough. You also need copy-on-write functionality when the source file is on a read-only branch. This makes unioning much more useful and is one of the main attractions to unionfs users. 3) Whiteouts: Whiteouts are a key unioning construct. As it was pointed out at OLS 2006, they are a properly of the union and _NOT_ a branch. Therefore, they should not be stored persistently on a branch but rather in some external storage. 4) You also need unique and *persistent* inode numbers for network f/s exports and other unix tools. 5) You need to provide dynamic branch management functionality: adding, removing, and changing the mode of branches in an existing union. We have considerable experience in unioning file systems for years now; we are currently working on the third generation of the code. All of the above features, and more, are USED by users, and are NEEDED by users. We believe the right approach is the one we've taken, and is the least intrusive: a standalone (stackable) file system that doesn't clutter the VFS, with some small and gradual changes to the VFS to support stacking. As you may have noticed, we have been successfully submitting VFS patches to make the VFS more stacking friendly (not just to Unionfs, but also to eCryptfs which has been in since 2.6.19). The older Union mounts, alas, try to put all that functionality into the VFS. We recognize that some people think that union mounts at the VFS level is the elegant approach, but we hope people will listen to us and learn from our experience: unioning may seem simple in principle, but it is difficult in practice. (See http://unionfs.fileystems.org/ for a lot more info.) So we don't think that is a viable long term approach to have all of the unioning functionality in the VFS for two main reasons: (1) If you want users to use a VFS-level unioning functionality ala union-mounts, then you're going to have to implement *all* of the features we have implemented; the VFS clutter and complexity that will result will be very considerable, and we just don't think that it'd happen. (2) Some may suggest to have a lightweight union mounts that only offers a subset of the functionality that's suitable for placing in the VFS. In that case, most unionfs users simply won't use it. You'd need union mounts to provide ALL of the functionality that we have TODAY, if you want users to it. As far as we can see the remaining stumbling block right now is cache coherency between the layers. Whether you provide unioning as a stackable f/s or shoved into the VFS, coherency will have to be addressed. In our upcoming paper and talk at OLS'07, we plan to bring up and discuss several ideas we've explored already on how to resolve this incoherency. Our ideas range from complex graph-based pointer management between objects of all sorts, to simple timestamp-based VFS hooks. (We've been experimenting with several approaches and so far we're leaning toward the simple timestamp based on, again in the interest of keeping the VFS changes simple. We hope to have more results to report by OLS time.) Josef Jeff Sipek, on behalf of the Unionfs team. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] fs: Fix indentation in do_path_lookup
On Sun, May 06, 2007 at 12:11:24PM +0100, Christoph Hellwig wrote:
> On Sat, May 05, 2007 at 06:59:39PM -0400, Josef 'Jeff' Sipek wrote:
> > Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
> > ---
> > fs/namei.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/fs/namei.c b/fs/namei.c
> > index 0262594..600a4e7 100644
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -1159,7 +1159,7 @@ out:
> > if (likely(retval == 0)) {
> > if (unlikely(!audit_dummy_context() && nd && nd->dentry &&
> > nd->dentry->d_inode))
> > - audit_inode(name, nd->dentry->d_inode);
> > + audit_inode(name, nd->dentry->d_inode);
> > }
...
> nd is guaranteed to be zero.
Should that say non-zero?
Josef "Jeff" Sipek.
--
Humans were created by water to transport it upward.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] fs: Fix indentation in do_path_lookup
On Sun, May 06, 2007 at 12:11:24PM +0100, Christoph Hellwig wrote:
On Sat, May 05, 2007 at 06:59:39PM -0400, Josef 'Jeff' Sipek wrote:
Signed-off-by: Josef 'Jeff' Sipek [EMAIL PROTECTED]
---
fs/namei.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 0262594..600a4e7 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1159,7 +1159,7 @@ out:
if (likely(retval == 0)) {
if (unlikely(!audit_dummy_context() nd nd-dentry
nd-dentry-d_inode))
- audit_inode(name, nd-dentry-d_inode);
+ audit_inode(name, nd-dentry-d_inode);
}
...
nd is guaranteed to be zero.
Should that say non-zero?
Josef Jeff Sipek.
--
Humans were created by water to transport it upward.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix unionfs compilation
On Sat, May 05, 2007 at 07:00:12PM +0200, Adrian Bunk wrote: > On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote: > >... > > Changes since 2.6.21-rc7-mm2: > >... > > git-unionfs.patch > >... > > git trees > >... > > <-- snip --> > > ... > CC fs/unionfs/super.o > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c: In function > ‘init_once’: > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error: > ‘SLAB_CTOR_VERIFY’ undeclared (first use in this function) > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error: > (Each undeclared identifier is reported only once > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error: > for each function it appears in.) > make[3]: *** [fs/unionfs/super.o] Error 1 > > <-- snip --> > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Applied. Thanks. Josef "Jeff" Sipek. -- *NOTE: This message is ROT-13 encrypted twice for extra protection* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix unionfs compilation
On Sat, May 05, 2007 at 10:19:42PM +0300, Pekka Enberg wrote: > On 5/5/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > >Bah, that was hidden from my allmodconfig because CONFIG_UNIONFS is > >inexplicably > >dependent upon CONFIG_SLAB. > > > >How come? > > I think Adrian added it before we introduced krealloc() to fix uniofs > from poking slab internals. I believe the (commented out) patch in -mm series file fixes things: unionfs-fix-slab-abuses-with-krealloc.patch It probably got commented out when unionfs got temporarily dropped from -mm. Josef "Jeff" Sipek. -- Keyboard not found! Press F1 to enter Setup - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix unionfs compilation
On Sat, May 05, 2007 at 11:57:18AM -0700, Andrew Morton wrote:
> On Sat, 5 May 2007 19:00:12 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
> > >...
> > > Changes since 2.6.21-rc7-mm2:
> > >...
> > > git-unionfs.patch
> > >...
> > > git trees
> > >...
> >
> > <-- snip -->
> >
> > ...
> > CC fs/unionfs/super.o
> > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c: In
> > function ‘init_once’:
> > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
> > ‘SLAB_CTOR_VERIFY’ undeclared (first use in this function)
> > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
> > (Each undeclared identifier is reported only once
> > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
> > for each function it appears in.)
> > make[3]: *** [fs/unionfs/super.o] Error 1
> >
> > <-- snip -->
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> >
> > ---
> > --- linux-2.6.21-mm1/fs/unionfs/super.c.old 2007-05-05 18:45:25.0
> > +0200
> > +++ linux-2.6.21-mm1/fs/unionfs/super.c 2007-05-05 18:46:03.0
> > +0200
> > @@ -819,8 +819,7 @@
> > {
> > struct unionfs_inode_info *i = v;
> >
> > - if ((flags & (SLAB_CTOR_VERIFY | SLAB_CTOR_CONSTRUCTOR)) ==
> > - SLAB_CTOR_CONSTRUCTOR)
> > + if (flags & SLAB_CTOR_CONSTRUCTOR)
> > inode_init_once(>vfs_inode);
> > }
>
> Bah, that was hidden from my allmodconfig because CONFIG_UNIONFS is
> inexplicably
> dependent upon CONFIG_SLAB.
>
> How come?
As it was discussed a while back on the mailing lists, Unionfs is trying to
be smart and tries to do reallocation on its own. The way it does it makes
it depend on some internals of the SLAB allocator. There have been some
patches out there for a realloc function (by Pekka Enberg, IIRC), but as far
as I can tell, they haven't been merged in.
Josef "Jeff" Sipek.
--
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like
that.
- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix unionfs compilation
On Sat, May 05, 2007 at 11:57:18AM -0700, Andrew Morton wrote:
On Sat, 5 May 2007 19:00:12 +0200 Adrian Bunk [EMAIL PROTECTED] wrote:
On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
...
Changes since 2.6.21-rc7-mm2:
...
git-unionfs.patch
...
git trees
...
-- snip --
...
CC fs/unionfs/super.o
/home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c: In
function ‘init_once’:
/home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
‘SLAB_CTOR_VERIFY’ undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
(Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
for each function it appears in.)
make[3]: *** [fs/unionfs/super.o] Error 1
-- snip --
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- linux-2.6.21-mm1/fs/unionfs/super.c.old 2007-05-05 18:45:25.0
+0200
+++ linux-2.6.21-mm1/fs/unionfs/super.c 2007-05-05 18:46:03.0
+0200
@@ -819,8 +819,7 @@
{
struct unionfs_inode_info *i = v;
- if ((flags (SLAB_CTOR_VERIFY | SLAB_CTOR_CONSTRUCTOR)) ==
- SLAB_CTOR_CONSTRUCTOR)
+ if (flags SLAB_CTOR_CONSTRUCTOR)
inode_init_once(i-vfs_inode);
}
Bah, that was hidden from my allmodconfig because CONFIG_UNIONFS is
inexplicably
dependent upon CONFIG_SLAB.
How come?
As it was discussed a while back on the mailing lists, Unionfs is trying to
be smart and tries to do reallocation on its own. The way it does it makes
it depend on some internals of the SLAB allocator. There have been some
patches out there for a realloc function (by Pekka Enberg, IIRC), but as far
as I can tell, they haven't been merged in.
Josef Jeff Sipek.
--
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like
that.
- Linus Torvalds
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix unionfs compilation
On Sat, May 05, 2007 at 10:19:42PM +0300, Pekka Enberg wrote: On 5/5/07, Andrew Morton [EMAIL PROTECTED] wrote: Bah, that was hidden from my allmodconfig because CONFIG_UNIONFS is inexplicably dependent upon CONFIG_SLAB. How come? I think Adrian added it before we introduced krealloc() to fix uniofs from poking slab internals. I believe the (commented out) patch in -mm series file fixes things: unionfs-fix-slab-abuses-with-krealloc.patch It probably got commented out when unionfs got temporarily dropped from -mm. Josef Jeff Sipek. -- Keyboard not found! Press F1 to enter Setup - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix unionfs compilation
On Sat, May 05, 2007 at 07:00:12PM +0200, Adrian Bunk wrote: On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote: ... Changes since 2.6.21-rc7-mm2: ... git-unionfs.patch ... git trees ... -- snip -- ... CC fs/unionfs/super.o /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c: In function ‘init_once’: /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error: ‘SLAB_CTOR_VERIFY’ undeclared (first use in this function) /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error: (Each undeclared identifier is reported only once /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error: for each function it appears in.) make[3]: *** [fs/unionfs/super.o] Error 1 -- snip -- Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Applied. Thanks. Josef Jeff Sipek. -- *NOTE: This message is ROT-13 encrypted twice for extra protection* - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] fs: add 4th case to do_path_lookup
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
diff --git a/fs/namei.c b/fs/namei.c
index 2995fba..1516a9b 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1125,6 +1125,10 @@ static int fastcall do_path_lookup(int dfd, const char
*name,
nd->mnt = mntget(fs->rootmnt);
nd->dentry = dget(fs->root);
read_unlock(>lock);
+ } else if (flags & LOOKUP_ONE) {
+ /* nd->mnt and nd->dentry already set, just grab references */
+ mntget(nd->mnt);
+ dget(nd->dentry);
} else if (dfd == AT_FDCWD) {
read_lock(>lock);
nd->mnt = mntget(fs->pwdmnt);
diff --git a/include/linux/namei.h b/include/linux/namei.h
index 92b422b..aa89d97 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -48,6 +48,7 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
* - internal "there are more path compnents" flag
* - locked when lookup done with dcache_lock held
* - dentry cache is untrusted; force a real lookup
+ * - lookup path from given dentry/vfsmount pair
*/
#define LOOKUP_FOLLOW 1
#define LOOKUP_DIRECTORY2
@@ -55,6 +56,7 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
#define LOOKUP_PARENT 16
#define LOOKUP_NOALT 32
#define LOOKUP_REVAL 64
+#define LOOKUP_ONE128
/*
* Intent data
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] [RFC] New mode for path_lookup (V1)
Stackable file systems frequently need to lookup paths or path components
starting from an arbitrary point in the namespace (identified by a dentry
and a vfsmount). Currently, such file systems use lookup_one_len, which is
frowned upon [1] as it does not pass the lookup intent along; not passing a
lookup intent, for example, can trigger BUG_ON's when stacking on top of
NFSv4.
The following patch introduces a new mode to path_lookup to allow lookup to
start from an arbitrary point in the namespace. This approach has been
suggested by Christoph Hellwig at the Linux Storage & Filesystem workshop in
February of this year.
One indicates that the lookup should be relative to a dentry-vfsmnt pair by
using the LOOKUP_ONE flag. For example, the following snippet of code,
looks up "pathcomponent" in a directory pointed to by
parent_{dentry,vfsmnt}:
nd.dentry = parent_dentry;
nd.mnt = parent_vfsmnt;
err = path_lookup("pathcomponent", LOOKUP_ONE, );
if (!err) {
/* exits */
...
/* once done, release the references */
path_release();
} else if (err == -ENOENT) {
/* doesn't exits */
} else {
/* other error */
}
VFS functions such as lookup_create can be used on the nameidata structure
to pass the create intent to the file system.
Currently, there is no easy way to pass the LOOKUP_OPEN intent. The proper
way would be to call open_namei.
We'd like to get comments about what's necessary to make stackable file
systems do lookups right - this includes potential changes to open_namei.
Josef 'Jeff' Sipek.
[1] http://marc.info/?l=linux-kernel=117343337823760=2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Guilt v0.24
Sorry for the delayed announcement... Guilt v0.24 is available for download. Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like functionality and interface to git. Tarballs: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/ Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git The major changes are in status and fork commands. guilt-status now accepts a number of flags to display only certain subset of changed files (e.g., only newly added files). guilt-fork is now smarter about the naming of patches - following quilt's lead. Additionally, Brandon Philips, went a head, and create a Debian package for Guilt. So, if you are a Debian Unstable user, you can Guilt through apt. As always, patches, and other feedback is welcome. Josef "Jeff" Sipek. Changes since v0.23: Eric Lesh (4): guilt-fork: Rename patches sequentially (ala quilt) guilt-fork: Use first argument (if given) as name of new patch Documentation/guilt-fork: document argument to choose name of new patch guilt: Add -h option to show man pages Josef 'Jeff' Sipek (7): status: Major cleanup of status Docs: Document all options for status status: Added -n to hide status prefix from ouput status: change into the top of the repo before checking for changes Docs: Fixed up description of series -v pop: Added -f to force popping of the patch Guilt v0.24 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Guilt v0.24
Sorry for the delayed announcement... Guilt v0.24 is available for download. Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like functionality and interface to git. Tarballs: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/ Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git The major changes are in status and fork commands. guilt-status now accepts a number of flags to display only certain subset of changed files (e.g., only newly added files). guilt-fork is now smarter about the naming of patches - following quilt's lead. Additionally, Brandon Philips, went a head, and create a Debian package for Guilt. So, if you are a Debian Unstable user, you can Guilt through apt. As always, patches, and other feedback is welcome. Josef Jeff Sipek. Changes since v0.23: Eric Lesh (4): guilt-fork: Rename patches sequentially (ala quilt) guilt-fork: Use first argument (if given) as name of new patch Documentation/guilt-fork: document argument to choose name of new patch guilt: Add -h option to show man pages Josef 'Jeff' Sipek (7): status: Major cleanup of status Docs: Document all options for status status: Added -n to hide status prefix from ouput status: change into the top of the repo before checking for changes Docs: Fixed up description of series -v pop: Added -f to force popping of the patch Guilt v0.24 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] [RFC] New mode for path_lookup (V1)
Stackable file systems frequently need to lookup paths or path components
starting from an arbitrary point in the namespace (identified by a dentry
and a vfsmount). Currently, such file systems use lookup_one_len, which is
frowned upon [1] as it does not pass the lookup intent along; not passing a
lookup intent, for example, can trigger BUG_ON's when stacking on top of
NFSv4.
The following patch introduces a new mode to path_lookup to allow lookup to
start from an arbitrary point in the namespace. This approach has been
suggested by Christoph Hellwig at the Linux Storage Filesystem workshop in
February of this year.
One indicates that the lookup should be relative to a dentry-vfsmnt pair by
using the LOOKUP_ONE flag. For example, the following snippet of code,
looks up pathcomponent in a directory pointed to by
parent_{dentry,vfsmnt}:
nd.dentry = parent_dentry;
nd.mnt = parent_vfsmnt;
err = path_lookup(pathcomponent, LOOKUP_ONE, nd);
if (!err) {
/* exits */
...
/* once done, release the references */
path_release(nd);
} else if (err == -ENOENT) {
/* doesn't exits */
} else {
/* other error */
}
VFS functions such as lookup_create can be used on the nameidata structure
to pass the create intent to the file system.
Currently, there is no easy way to pass the LOOKUP_OPEN intent. The proper
way would be to call open_namei.
We'd like to get comments about what's necessary to make stackable file
systems do lookups right - this includes potential changes to open_namei.
Josef 'Jeff' Sipek.
[1] http://marc.info/?l=linux-kernelm=117343337823760w=2
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] fs: add 4th case to do_path_lookup
Signed-off-by: Josef 'Jeff' Sipek [EMAIL PROTECTED]
diff --git a/fs/namei.c b/fs/namei.c
index 2995fba..1516a9b 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1125,6 +1125,10 @@ static int fastcall do_path_lookup(int dfd, const char
*name,
nd-mnt = mntget(fs-rootmnt);
nd-dentry = dget(fs-root);
read_unlock(fs-lock);
+ } else if (flags LOOKUP_ONE) {
+ /* nd-mnt and nd-dentry already set, just grab references */
+ mntget(nd-mnt);
+ dget(nd-dentry);
} else if (dfd == AT_FDCWD) {
read_lock(fs-lock);
nd-mnt = mntget(fs-pwdmnt);
diff --git a/include/linux/namei.h b/include/linux/namei.h
index 92b422b..aa89d97 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -48,6 +48,7 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
* - internal there are more path compnents flag
* - locked when lookup done with dcache_lock held
* - dentry cache is untrusted; force a real lookup
+ * - lookup path from given dentry/vfsmount pair
*/
#define LOOKUP_FOLLOW 1
#define LOOKUP_DIRECTORY2
@@ -55,6 +56,7 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
#define LOOKUP_PARENT 16
#define LOOKUP_NOALT 32
#define LOOKUP_REVAL 64
+#define LOOKUP_ONE128
/*
* Intent data
*/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL -mm] Unionfs branch management code
On Tue, Apr 10, 2007 at 01:22:52PM -0400, Shaya Potter wrote: > Andrew Morton wrote: > >On Mon, 9 Apr 2007 10:53:51 -0400 "Josef 'Jeff' Sipek" > ><[EMAIL PROTECTED]> wrote: > > > >>The following patches introduce new branch-management code into Unionfs as > >>well as fix a number of stability issues and resource leaks. > > > >I have a mental note that unionfs is in the "stuck" state, due to general > >agreement that we should implement this functionality at the VFS level, one > >reason for which is unionfs's upper-vs-lower coherency problems. > > How can a union file system with a decent set of useful semantics be > fully implemented at the VFS layer in a "clean" manner? Unioning is quite odd. It uses concepts, some of which do indeed belong in the VFS (like actual merging of the lower directories), but others that most definitely do not (like whiteouts). > For instance, a major use of unionfs is live CDs, namely unionfs w/ a > read-only and read-write layer. Unionfs enables files to be copied up > from the read-only layer to the read-write layer. > > Does one really want to implement "copyup" in the VFS? I don't think that copyup is the problem, but whiteouts...oh boy. Whiteouts/some kind of persistent storage is most definitely a filesystem construct, and it does not belong in the VFS. Josef "Jeff" Sipek. -- If I have trouble installing Linux, something is wrong. Very wrong. - Linus Torvalds - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL -mm] Unionfs branch management code
On Tue, Apr 10, 2007 at 01:22:52PM -0400, Shaya Potter wrote: Andrew Morton wrote: On Mon, 9 Apr 2007 10:53:51 -0400 Josef 'Jeff' Sipek [EMAIL PROTECTED] wrote: The following patches introduce new branch-management code into Unionfs as well as fix a number of stability issues and resource leaks. I have a mental note that unionfs is in the stuck state, due to general agreement that we should implement this functionality at the VFS level, one reason for which is unionfs's upper-vs-lower coherency problems. How can a union file system with a decent set of useful semantics be fully implemented at the VFS layer in a clean manner? Unioning is quite odd. It uses concepts, some of which do indeed belong in the VFS (like actual merging of the lower directories), but others that most definitely do not (like whiteouts). For instance, a major use of unionfs is live CDs, namely unionfs w/ a read-only and read-write layer. Unionfs enables files to be copied up from the read-only layer to the read-write layer. Does one really want to implement copyup in the VFS? I don't think that copyup is the problem, but whiteouts...oh boy. Whiteouts/some kind of persistent storage is most definitely a filesystem construct, and it does not belong in the VFS. Josef Jeff Sipek. -- If I have trouble installing Linux, something is wrong. Very wrong. - Linus Torvalds - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL -mm] Unionfs branch management code
On Mon, Apr 09, 2007 at 10:49:48AM -0700, Andrew Morton wrote:
> On Mon, 9 Apr 2007 10:53:51 -0400 "Josef 'Jeff' Sipek" <[EMAIL PROTECTED]>
> wrote:
>
> > The following patches introduce new branch-management code into Unionfs as
> > well as fix a number of stability issues and resource leaks.
First, a quick note...Unionfs used to have branch management code, but the
code was so crufty that we decided to spare the eyes (and brains) of kernel
developers at large by ripping it out. This series of patches just
reintroduces the functionality in a sane way. With that said...
> I have a mental note that unionfs is in the "stuck" state, due to general
> agreement that we should implement this functionality at the VFS level, one
> reason for which is unionfs's upper-vs-lower coherency problems.
Right. The upper-vs-lower coherency problem is indeed a problem, but it is
not a _Unionfs_ problem, but rather a _stackable filesystems_ problem
(eCrypfs suffers from the same issue people are just less likely to trip
over it as no one in their right mind modifies encrypted data by hand). If
we hope to have Linux do stacking (which, I think makes sense), we need to
make few changes to the kernel to allow stackable filesystems to work
better, and safer. We're working on an OLS paper which discusses some of
these ideas (some of which we got at LSF back in February) - for example, do
we want to have strong or weak cache coherency? (When the lower pages
change, do we want to have the VM enforce coherency, or can we use more of
an NFS-like coherency model - checking {a,c,m}time.)
Josef "Jeff" Sipek.
--
Intellectuals solve problems; geniuses prevent them
- Albert Einstein
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL -mm] Unionfs branch management code
On Mon, Apr 09, 2007 at 10:49:48AM -0700, Andrew Morton wrote:
On Mon, 9 Apr 2007 10:53:51 -0400 Josef 'Jeff' Sipek [EMAIL PROTECTED]
wrote:
The following patches introduce new branch-management code into Unionfs as
well as fix a number of stability issues and resource leaks.
First, a quick note...Unionfs used to have branch management code, but the
code was so crufty that we decided to spare the eyes (and brains) of kernel
developers at large by ripping it out. This series of patches just
reintroduces the functionality in a sane way. With that said...
I have a mental note that unionfs is in the stuck state, due to general
agreement that we should implement this functionality at the VFS level, one
reason for which is unionfs's upper-vs-lower coherency problems.
Right. The upper-vs-lower coherency problem is indeed a problem, but it is
not a _Unionfs_ problem, but rather a _stackable filesystems_ problem
(eCrypfs suffers from the same issue people are just less likely to trip
over it as no one in their right mind modifies encrypted data by hand). If
we hope to have Linux do stacking (which, I think makes sense), we need to
make few changes to the kernel to allow stackable filesystems to work
better, and safer. We're working on an OLS paper which discusses some of
these ideas (some of which we got at LSF back in February) - for example, do
we want to have strong or weak cache coherency? (When the lower pages
change, do we want to have the VM enforce coherency, or can we use more of
an NFS-like coherency model - checking {a,c,m}time.)
Josef Jeff Sipek.
--
Intellectuals solve problems; geniuses prevent them
- Albert Einstein
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Guilt v0.23
Guilt v0.23 is available for download (once it mirrors out on kernel.org). Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like functionality and interface to git. Tarballs: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/ Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git There are two brand new commands: fork and fold. A few minor bugs related to really unusual patch names (containing commas) were fixed. And finally, each command has a manual page! As always, patches, and other feedback is welcome. Josef "Jeff" Sipek. Changes since v0.22: Brandon Philips (2): Get usage information from the USAGE variable Remaining guilt documentation Josef 'Jeff' Sipek (14): Docs: Ignore generated usage-*.txt files Docs: Consistified the man pages Docs: Reimplemented cmd-list generation script in sh Docs: Added import-commit manpage Docs: Fixed up patchbomb documentation Docs: Include version Guilt version number in page footer Remove pop_patch as there are no real users fold: fold a patch into the topmost patch delete: use series_remove_patch instead of opencoding the logic fold: fixed patch backup creation Docs: guilt-fold manpage new: escape new patch name properly when changing the series file fork: fork the topmost applied patch Guilt v0.23 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Guilt v0.23
Guilt v0.23 is available for download (once it mirrors out on kernel.org). Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like functionality and interface to git. Tarballs: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/ Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git There are two brand new commands: fork and fold. A few minor bugs related to really unusual patch names (containing commas) were fixed. And finally, each command has a manual page! As always, patches, and other feedback is welcome. Josef Jeff Sipek. Changes since v0.22: Brandon Philips (2): Get usage information from the USAGE variable Remaining guilt documentation Josef 'Jeff' Sipek (14): Docs: Ignore generated usage-*.txt files Docs: Consistified the man pages Docs: Reimplemented cmd-list generation script in sh Docs: Added import-commit manpage Docs: Fixed up patchbomb documentation Docs: Include version Guilt version number in page footer Remove pop_patch as there are no real users fold: fold a patch into the topmost patch delete: use series_remove_patch instead of opencoding the logic fold: fixed patch backup creation Docs: guilt-fold manpage new: escape new patch name properly when changing the series file fork: fork the topmost applied patch Guilt v0.23 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Guilt v0.22
Guilt v0.22 is available for download (once it mirrors out on kernel.org).
Guilt (Git Quilt) is a series of bash scripts which add a Mercurial
queues-like functionality and interface to git.
Tarballs:
http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/
Git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git
The changes to Guilt could be divided into three categories:
1) Documentation: Quite a bit of documentation was added.
2) Bugfixes:
- guilt-patchbomb did not actually do the right action based on user's
answer to the question about removal of the temporary patch directory.
- Many places in the code used variables in an unsafe way - a whitespace
in a path could have caused very bad things to happen.
- Guilt 0.21 did not allow the user to be in a subdirectory and run
guilt commands.
- guilt-files did not recurse into subdirectories.
3) Features: Autotagging:
Automatically creates unannotated tags for top, bottom, and base of the
stack
On every push or pop operation (refresh is a pop followed by a push),
update the stack top (${branch}_top), stack bottom (${branch}_bottom),
and stack base (${branch}_base) tags.
Top:Topmost applied patch/commit
Bottom: Bottommost applied patch/commit
Base: Commit on top of which the bottom most patch is applied
Having these three tags, one can easily get the log/diff/other information
only for commits that are (or are not!) part of the patch stack.
Autotagging can be disabled by setting guilt.autotag=0 in your git
config file.
Additionally, guilt-init now accepts a new parameter '-n' to
automatically set guilt.autotag=0 in the current repository.
As always, patches, and other feedback is welcome.
Josef "Jeff" Sipek.
Changes since v0.21:
Josef 'Jeff' Sipek (19):
Inform git-sh-setup that we can work from within a subdirectory
Docs: guilt-new manpage
files: Recurse into subdirectories when using git-diff-tree
Docs: guilt-files manpage
Docs: Formatting fixes
Docs: prev, refresh, top, and unapplied manpages
new: Make sure the requested patchname would not create unnecessary
problems
Quote variables as frequently as possible to prevent whitespace problems
Remove find_git_dir as git-sh-setup already provides such functionality
Makefile's clean target should be .PHONY as well
Docs: Fix links/references between pages
Docs: Mention the fact that guilt can be used to develop guilt
Docs: Fix command examples in new & next manpage
Docs: Remove stray reference
Automatically create unannotated tags for top, bottom, and base of the
stack
Autotag: Read guilt.autotag config var and tag commits only if this
feature is enabled
Docs: Added install-html makefile rule to Documentation/Makefile
Makefile: Replace hard-coded script list with a wildcard
Guilt v0.22
Nur Hussein (3):
Guilt: Fixed guilt-patchbomb temporary mbox deletion bug
Guilt: Added an uninstall target
Guilt: Makefile tab fix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Guilt v0.22
Guilt v0.22 is available for download (once it mirrors out on kernel.org).
Guilt (Git Quilt) is a series of bash scripts which add a Mercurial
queues-like functionality and interface to git.
Tarballs:
http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/
Git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git
The changes to Guilt could be divided into three categories:
1) Documentation: Quite a bit of documentation was added.
2) Bugfixes:
- guilt-patchbomb did not actually do the right action based on user's
answer to the question about removal of the temporary patch directory.
- Many places in the code used variables in an unsafe way - a whitespace
in a path could have caused very bad things to happen.
- Guilt 0.21 did not allow the user to be in a subdirectory and run
guilt commands.
- guilt-files did not recurse into subdirectories.
3) Features: Autotagging:
Automatically creates unannotated tags for top, bottom, and base of the
stack
On every push or pop operation (refresh is a pop followed by a push),
update the stack top (${branch}_top), stack bottom (${branch}_bottom),
and stack base (${branch}_base) tags.
Top:Topmost applied patch/commit
Bottom: Bottommost applied patch/commit
Base: Commit on top of which the bottom most patch is applied
Having these three tags, one can easily get the log/diff/other information
only for commits that are (or are not!) part of the patch stack.
Autotagging can be disabled by setting guilt.autotag=0 in your git
config file.
Additionally, guilt-init now accepts a new parameter '-n' to
automatically set guilt.autotag=0 in the current repository.
As always, patches, and other feedback is welcome.
Josef Jeff Sipek.
Changes since v0.21:
Josef 'Jeff' Sipek (19):
Inform git-sh-setup that we can work from within a subdirectory
Docs: guilt-new manpage
files: Recurse into subdirectories when using git-diff-tree
Docs: guilt-files manpage
Docs: Formatting fixes
Docs: prev, refresh, top, and unapplied manpages
new: Make sure the requested patchname would not create unnecessary
problems
Quote variables as frequently as possible to prevent whitespace problems
Remove find_git_dir as git-sh-setup already provides such functionality
Makefile's clean target should be .PHONY as well
Docs: Fix links/references between pages
Docs: Mention the fact that guilt can be used to develop guilt
Docs: Fix command examples in new next manpage
Docs: Remove stray reference
Automatically create unannotated tags for top, bottom, and base of the
stack
Autotag: Read guilt.autotag config var and tag commits only if this
feature is enabled
Docs: Added install-html makefile rule to Documentation/Makefile
Makefile: Replace hard-coded script list with a wildcard
Guilt v0.22
Nur Hussein (3):
Guilt: Fixed guilt-patchbomb temporary mbox deletion bug
Guilt: Added an uninstall target
Guilt: Makefile tab fix
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] eCryptfs: convert lookup_one_len() to lookup_one_len_nd()
On Fri, Mar 09, 2007 at 09:40:00AM +, Christoph Hellwig wrote: > On Sat, Feb 17, 2007 at 03:56:55AM -0500, Josef 'Jeff' Sipek wrote: > > From: Michael Halcrow <[EMAIL PROTECTED]> > > > > Call the new lookup_one_len_nd() rather than lookup_one_len(). This fixes > > an > > oops when stacked on NFS. > > > > Note that there are still some issues with eCryptfs on NFS having to do with > > directory deletion (I'm not getting an oops, just an -EBUSY). > > Biug NACK here. This is just working around the broken lookup intents > code. lookup_one_len still is a hack for some network filesystems that > unfortunately grew a few too many users. I'm working on the 4-th case to do_path_lookup. The only problem left, is the negative dentries. do_path_lookup returns -ENOENT. Which would means that we need either a wrapper that returns the negative dentry instead of > Implementing this might be a good idea anyway to clean up the mess > do_path_lookup is currently. Clean up? There are 4 (including the new case) "setup" cases, and then the actual lookup happens. You'll need the crazy if conditions unless the mening of the arguments changes. Josef "Jeff" Sipek. -- UNIX is user-friendly ... it's just selective about who it's friends are - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] eCryptfs: convert lookup_one_len() to lookup_one_len_nd()
On Fri, Mar 09, 2007 at 09:40:00AM +, Christoph Hellwig wrote: On Sat, Feb 17, 2007 at 03:56:55AM -0500, Josef 'Jeff' Sipek wrote: From: Michael Halcrow [EMAIL PROTECTED] Call the new lookup_one_len_nd() rather than lookup_one_len(). This fixes an oops when stacked on NFS. Note that there are still some issues with eCryptfs on NFS having to do with directory deletion (I'm not getting an oops, just an -EBUSY). Biug NACK here. This is just working around the broken lookup intents code. lookup_one_len still is a hack for some network filesystems that unfortunately grew a few too many users. I'm working on the 4-th case to do_path_lookup. The only problem left, is the negative dentries. do_path_lookup returns -ENOENT. Which would means that we need either a wrapper that returns the negative dentry instead of Implementing this might be a good idea anyway to clean up the mess do_path_lookup is currently. Clean up? There are 4 (including the new case) setup cases, and then the actual lookup happens. You'll need the crazy if conditions unless the mening of the arguments changes. Josef Jeff Sipek. -- UNIX is user-friendly ... it's just selective about who it's friends are - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
