Next 2.6.17-stable review cycle will be starting in about 24 hours

Next 2.6.17-stable review cycle will be starting in about 24 hours

[Greg KH]

This is a heads up that the next 2.6.17-stable review cycle will be
starting in about 24 hours.  I've caught up on all pending -stable
patches that I know about and placed them in our queue, which can be
browsed online at:
	http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=tree;f=queue-2.6.17

If anyone sees that this queue is missing something that they feel
should get into the next 2.6.17-stable release, please let us know at
stable@kernel.org within the next 24 hours or so.

thanks,

greg k-h

Re: Next 2.6.17-stable review cycle will be starting in about 24 hours

[Marcel Holtmann]

Hi Greg,

> This is a heads up that the next 2.6.17-stable review cycle will be
> starting in about 24 hours.  I've caught up on all pending -stable
> patches that I know about and placed them in our queue, which can be
> browsed online at:
> 	http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=tree;f=queue-2.6.17
> 
> If anyone sees that this queue is missing something that they feel
> should get into the next 2.6.17-stable release, please let us know at
> stable@kernel.org within the next 24 hours or so.

instead of ext3-avoid-triggering-ext3_error-on-bad-nfs-file-handle.patch
it makes more sense to include the revised patches from Neil:

http://comments.gmane.org/gmane.linux.kernel/430323

It seems that these are not merged upstream, but my understanding was
that they were the best way to fix this. For RHEL4 we are going with
these two patches. 

Linus, any reason why they are not merged yet?

Regards

Marcel

Re: [stable] Next 2.6.17-stable review cycle will be starting in about 24 hours

[Greg KH]

On Thu, Aug 03, 2006 at 06:47:32PM +0200, Marcel Holtmann wrote:
> Hi Greg,
> 
> > This is a heads up that the next 2.6.17-stable review cycle will be
> > starting in about 24 hours.  I've caught up on all pending -stable
> > patches that I know about and placed them in our queue, which can be
> > browsed online at:
> > 	http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=tree;f=queue-2.6.17
> > 
> > If anyone sees that this queue is missing something that they feel
> > should get into the next 2.6.17-stable release, please let us know at
> > stable@kernel.org within the next 24 hours or so.
> 
> instead of ext3-avoid-triggering-ext3_error-on-bad-nfs-file-handle.patch
> it makes more sense to include the revised patches from Neil:
> 
> http://comments.gmane.org/gmane.linux.kernel/430323
> 
> It seems that these are not merged upstream, but my understanding was
> that they were the best way to fix this. For RHEL4 we are going with
> these two patches. 

Hm, I just went with what Neil sent me for inclusion.  Neil, do you want
me to change the patches you sent us?

thanks,

greg k-h

Re: [stable] Next 2.6.17-stable review cycle will be starting in about 24 hours

[Neil Brown]

On Thursday August 3, greg@kroah.com wrote:
> On Thu, Aug 03, 2006 at 06:47:32PM +0200, Marcel Holtmann wrote:
> > Hi Greg,
> > 
> > > This is a heads up that the next 2.6.17-stable review cycle will be
> > > starting in about 24 hours.  I've caught up on all pending -stable
> > > patches that I know about and placed them in our queue, which can be
> > > browsed online at:
> > > 	http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=tree;f=queue-2.6.17
> > > 
> > > If anyone sees that this queue is missing something that they feel
> > > should get into the next 2.6.17-stable release, please let us know at
> > > stable@kernel.org within the next 24 hours or so.
> > 
> > instead of ext3-avoid-triggering-ext3_error-on-bad-nfs-file-handle.patch
> > it makes more sense to include the revised patches from Neil:
> > 
> > http://comments.gmane.org/gmane.linux.kernel/430323
> > 
> > It seems that these are not merged upstream, but my understanding was
> > that they were the best way to fix this. For RHEL4 we are going with
> > these two patches. 
> 
> Hm, I just went with what Neil sent me for inclusion.  Neil, do you want
> me to change the patches you sent us?

I think the patch you have is adequate for ext3.  It closes the
important hole.  I think the extra patch for ext3 in the gmane link
above is not entirely necessary so I wouldn't push it for stable.
That doesn't make it a wrong choice for RHEL4 though.

The ext2 patch, on the other hand, should probably go in to stable.

I include it below so you don't have to scrape it off the web page...

NeilBrown

---------------------------------
Have ext2 reject file handles with bad inode numbers early.

This prevents bad inode numbers from triggering errors in
ext2_get_inode.


Signed-off-by: Neil Brown <neilb@suse.de>

### Diffstat output
 ./fs/ext2/super.c |   41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff .prev/fs/ext2/super.c ./fs/ext2/super.c
--- .prev/fs/ext2/super.c	2006-07-28 10:37:57.000000000 +1000
+++ ./fs/ext2/super.c	2006-07-28 11:43:09.000000000 +1000
@@ -251,6 +251,46 @@ static struct super_operations ext2_sops
 #endif
 };
 
+static struct dentry *ext2_get_dentry(struct super_block *sb, void *vobjp)
+{
+	__u32 *objp = vobjp;
+	unsigned long ino = objp[0];
+	__u32 generation = objp[1];
+	struct inode *inode;
+	struct dentry *result;
+
+	if (ino != EXT2_ROOT_INO && ino < EXT2_FIRST_INO(sb))
+		return ERR_PTR(-ESTALE);
+	if (ino > le32_to_cpu(EXT2_SB(sb)->s_es->s_inodes_count))
+		return ERR_PTR(-ESTALE);
+
+	/* iget isn't really right if the inode is currently unallocated!!
+	 * ext2_read_inode currently does appropriate checks, but
+	 * it might be "neater" to call ext2_get_inode first and check
+	 * if the inode is valid.....
+	 */
+	inode = iget(sb, ino);
+	if (inode == NULL)
+		return ERR_PTR(-ENOMEM);
+	if (is_bad_inode(inode)
+	    || (generation && inode->i_generation != generation)
+		) {
+		/* we didn't find the right inode.. */
+		iput(inode);
+		return ERR_PTR(-ESTALE);
+	}
+	/* now to find a dentry.
+	 * If possible, get a well-connected one
+	 */
+	result = d_alloc_anon(inode);
+	if (!result) {
+		iput(inode);
+		return ERR_PTR(-ENOMEM);
+	}
+	return result;
+}
+
+
 /* Yes, most of these are left as NULL!!
  * A NULL value implies the default, which works with ext2-like file
  * systems, but can be improved upon.
@@ -258,6 +298,7 @@ static struct super_operations ext2_sops
  */
 static struct export_operations ext2_export_ops = {
 	.get_parent = ext2_get_parent,
+	.get_dentry = ext2_get_dentry,
 };
 
 static unsigned long get_sb_block(void **data)

Re: [stable] Next 2.6.17-stable review cycle will be starting in about 24 hours

[Greg KH]

On Fri, Aug 04, 2006 at 10:53:40AM +1000, Neil Brown wrote:
> The ext2 patch, on the other hand, should probably go in to stable.
> 
> I include it below so you don't have to scrape it off the web page...

Thanks, I've queued this up for the next -stable release.

greg k-h

Re: [stable] Next 2.6.17-stable review cycle will be starting in about 24 hours

[Marcel Holtmann]

Hi Neil,

> > > > This is a heads up that the next 2.6.17-stable review cycle will be
> > > > starting in about 24 hours.  I've caught up on all pending -stable
> > > > patches that I know about and placed them in our queue, which can be
> > > > browsed online at:
> > > > 	http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=tree;f=queue-2.6.17
> > > > 
> > > > If anyone sees that this queue is missing something that they feel
> > > > should get into the next 2.6.17-stable release, please let us know at
> > > > stable@kernel.org within the next 24 hours or so.
> > > 
> > > instead of ext3-avoid-triggering-ext3_error-on-bad-nfs-file-handle.patch
> > > it makes more sense to include the revised patches from Neil:
> > > 
> > > http://comments.gmane.org/gmane.linux.kernel/430323
> > > 
> > > It seems that these are not merged upstream, but my understanding was
> > > that they were the best way to fix this. For RHEL4 we are going with
> > > these two patches. 
> > 
> > Hm, I just went with what Neil sent me for inclusion.  Neil, do you want
> > me to change the patches you sent us?
> 
> I think the patch you have is adequate for ext3.  It closes the
> important hole.  I think the extra patch for ext3 in the gmane link
> above is not entirely necessary so I wouldn't push it for stable.
> That doesn't make it a wrong choice for RHEL4 though.
> 
> The ext2 patch, on the other hand, should probably go in to stable.

this actually looks unclean to me. I thought the code duplication in
ext2 and ext3 was the price that you have to pay to avoid any layering
violation. I personally would like to see the upstream patch go into
-stable. However we don't have this upstream at the moment. So what
would you consider sending to Linus?

Regards

Marcel