unpushed 4-month-old mods?

unpushed 4-month-old mods?

[Eric Sandeen]

At least these three mods which I did back in September to get Fedora 8
/ 2.6.23 into shape on 4k stacks, and a bugfix, are still not pushed to
kernel.org, and are missing in 2.6.24...

Is there any reason for the holdup?  Makes me wonder what else isn't
pushed...

-------------

Refactor xfs_mountfs

Refactoring xfs_mountfs() to call sub-functions for logical
chunks can help save a bit of stack, and can make it easier to
read this long function.

The mount path is one of the longest common callchains, easily
getting to within a few bytes of the end of a 4k stack when
over lvm, quotas are enabled, and quotacheck must be done.

With this change on top of the other stack-related changes
I've sent, I can get xfs to survive a normal xfsqa run on
4k stacks over lvm.

Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Merge of xfs-linux-melb:xfs-kern:29834a by kenmcd.

  Refactor xfs_mountfs

and:

optimize XFS_IS_REALTIME_INODE w/o realtime config

Use XFS_IS_REALTIME_INODE in more places, and #define it to
0 if CONFIG_XFS_RT is off.  This should be safe because mount
checks in xfs_rtmount_init:

# define xfs_rtmount_init(m)    (((mp)->m_sb.sb_rblocks == 0)? 0 : (ENOSYS))

so if we get mounted w/o CONFIG_XFS_RT, no realtime inodes should
be encountered after that.

Defining XFS_IS_REALTIME_INODE to 0 saves a bit of stack space,
presumeably gcc can optimize around the various "if (0)" type
checks:

xfs_alloc_file_space    -8
xfs_bmap_adjacent       -16
xfs_bmapi               -8
xfs_bmap_rtalloc        -16
xfs_bunmapi             -28
xfs_free_file_space     -64
xfs_imap                +8  <-- ?  hmm.
xfs_iomap_write_direct  -12
xfs_qm_dqusage_adjust   -4
xfs_qm_vop_chown_reserve -4

Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Merge of xfs-linux-melb:xfs-kern:30014a by kenmcd.

  Use XFS_IS_REALTIME_INODE() rather than open coding the check.

fix 32-bit compat ioctls for GETXFLAGS, SETXFLAGS, GETVERSION

XFS_IOC_GETVERSION, XFS_IOC_GETXFLAGS and XFS_IOC_SETXFLAGS all
take a "long" which changes size between 32 and 64 bit platforms.

So, the ioctl cmds that come in from a 32-bit app aren't as expected,
for example on GETXFLAGS,

        unknown cmd fd(3) cmd(80046601){t:'f';sz:4}

due to the size mismatch.

So, use instead the 32-bit version of the commands for compat ioctls,
and other than that it doesn't take any more manipulation.

Also, for both native and compat versions, just define them to
the values as defined in fs.h

Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Merge of xfs-linux-melb:xfs-kern:29849a by kenmcd.

  fix 32-bit compat ioctls for GETXFLAGS, SETXFLAGS, GETVERSION

Re: unpushed 4-month-old mods?

[David Chinner]

On Sun, Feb 03, 2008 at 10:30:43PM -0600, Eric Sandeen wrote:
> At least these three mods which I did back in September to get Fedora 8
> / 2.6.23 into shape on 4k stacks, and a bugfix, are still not pushed to
> kernel.org, and are missing in 2.6.24...
> 
> Is there any reason for the holdup?  Makes me wonder what else isn't
> pushed...

The holdup is that we drew a line in the sand for the 2.6.24 before
2.6.23 was released. We did this because of the massive amount of invasive
change we already had queued up for 2.6.24.  All those mods that got
held up will be pushed into 2.6.25 release.

Given the problems with the readdir changes (which still isn't 100% right
given we've had at least one bug report of a crash in the readdir code
post 2.6.24 release), we couldn't have handled much more change in that
release.....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: unpushed 4-month-old mods?

[Eric Sandeen]

David Chinner wrote:
> On Sun, Feb 03, 2008 at 10:30:43PM -0600, Eric Sandeen wrote:
>> At least these three mods which I did back in September to get Fedora 8
>> / 2.6.23 into shape on 4k stacks, and a bugfix, are still not pushed to
>> kernel.org, and are missing in 2.6.24...
>>
>> Is there any reason for the holdup?  Makes me wonder what else isn't
>> pushed...
> 
> The holdup is that we drew a line in the sand for the 2.6.24 before
> 2.6.23 was released. We did this because of the massive amount of invasive
> change we already had queued up for 2.6.24.  All those mods that got
> held up will be pushed into 2.6.25 release.
> 
> Given the problems with the readdir changes (which still isn't 100% right
> given we've had at least one bug report of a crash in the readdir code
> post 2.6.24 release), we couldn't have handled much more change in that
> release.....

Ok, as long as you guys know what's up :)

I just spent the evening sorting out why Fedora 9 was blowing up on
install, when Fedora 8 was working so well... :(

-Eric

Re: unpushed 4-month-old mods?

[Christoph Hellwig]

On Mon, Feb 04, 2008 at 03:46:11PM +1100, David Chinner wrote:
> On Sun, Feb 03, 2008 at 10:30:43PM -0600, Eric Sandeen wrote:
> > At least these three mods which I did back in September to get Fedora 8
> > / 2.6.23 into shape on 4k stacks, and a bugfix, are still not pushed to
> > kernel.org, and are missing in 2.6.24...
> > 
> > Is there any reason for the holdup?  Makes me wonder what else isn't
> > pushed...
> 
> The holdup is that we drew a line in the sand for the 2.6.24 before
> 2.6.23 was released. We did this because of the massive amount of invasive
> change we already had queued up for 2.6.24.  All those mods that got
> held up will be pushed into 2.6.25 release.

For which it's getting about time.  The merge window started about with
LCA, so by the tradition 2 weeks rule it'll close by the end of the
week..