public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [GIT PULL] xfs: updates for 4.7-rc1
@ 2016-05-26  6:13 Dave Chinner
  2016-05-26 17:19 ` Linus Torvalds
  0 siblings, 1 reply; 5+ messages in thread
From: Dave Chinner @ 2016-05-26  6:13 UTC (permalink / raw)
  To: torvalds; +Cc: akpm, linux-kernel

Hi Linus,

Can you please pull the XFS update from the tag below? It's a pretty
average collection of fixes, cleanups and improvements in this
request, details are in the tag below. A couple of the branches were
only pushed out last week (yes, I know this is generally considered
bad form) but I had been testing them for a couple of weeks prior
and had planned to push them out before the window opened.  However,
an unplanned high speed impact with a concrete wall a couple of days
before the merge window opened forced me to change my plans a
little, hence the late commit dates on the changes.

I've let them soak in linux-next for a week, and I did a merge with
your tree this morning and a bunch of xfstests runs over the past 8
hours without any problems, so everything looks ok from my side.
Just yell if this is not OK and I'll drop those branches for this
merge and resend the pull request....

-Dave.

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:

  Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git for-next

for you to fetch changes up to 555b67e4e729ca544bb4028ab12e532c68b70ddb:

  Merge branch 'xfs-4.7-inode-reclaim' into for-next (2016-05-20 10:34:00 +1000)

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

xfs: update for 4.7-rc1

Changes in this update:
o fixes for mount line parsing, sparse warnings, read-only compat
  feature remount behaviour
o allow fast path symlink lookups for inline symlinks.
o attribute listing cleanups
o writeback goes direct to bios rather than indirecting through
  bufferheads
o transaction allocation cleanup
o optimised kmem_realloc
o added configurable error handling for metadata write errors,
  changed default error handling behaviour from "retry forever" to
  "retry until unmount then fail"
o fixed several inode cluster writeback lookup vs reclaim race
  conditions
o fixed inode cluster writeback checking wrong inode after lookup
o fixed bugs where struct xfs_inode freeing wasn't actually RCU safe
o cleaned up inode reclaim tagging

----------------------------------------------------------------
Alex Lyakas (1):
      xfs: optimise xfs_iext_destroy

Brian Foster (1):
      xfs: buffer ->bi_end_io function requires irq-safe lock

Carlos Maiolino (8):
      xfs: Add caller function output to xfs_log_force tracepoint
      xfs: configurable error behavior via sysfs
      xfs: introduce metadata IO error class
      xfs: add configurable error support to metadata buffers
      xfs: introduce table-based init for error behaviors
      xfs: add configuration of error failure speed
      xfs: add configuration handlers for specific errors
      xfs: add "fail at unmount" error handling configuration

Christoph Hellwig (9):
      xfs: factor out a helper to initialize a local format inode fork
      xfs: set up inode operation vectors later
      xfs: use ->readlink to implement the readlink_by_handle ioctl
      xfs: optimize inline symlinks
      xfs: optimize bio handling in the buffer writeback path
      xfs: better xfs_trans_alloc interface
      xfs: remove transaction types
      xfs: improve kmem_realloc
      xfs: fix warning in xfs_finish_page_writeback for non-debug builds

Dave Chinner (20):
      xfs: Don't wrap growfs AGFL indexes
      xfs: build bios directly in xfs_add_to_ioend
      xfs: don't release bios on completion immediately
      xfs: remove xfs_fs_evict_inode()
      xfs: xfs_iflush_cluster fails to abort on error
      xfs: fix inode validity check in xfs_iflush_cluster
      xfs: skip stale inodes in xfs_iflush_cluster
      xfs: xfs_inode_free() isn't RCU safe
      xfs: mark reclaimed inodes invalid earlier
      xfs: xfs_iflush_cluster has range issues
      xfs: rename variables in xfs_iflush_cluster for clarity
      xfs: simplify inode reclaim tagging interfaces
      xfs: move reclaim tagging functions
      Merge branch 'xfs-4.7-writeback-bio' into for-next
      Merge branch 'xfs-4.7-trans-type-cleanup' into for-next
      Merge branch 'xfs-4.7-optimise-inline-symlinks' into for-next
      Merge branch 'xfs-4.7-cleanup-attr-listent' into for-next
      Merge branch 'xfs-4.7-misc-fixes' into for-next
      Merge branch 'xfs-4.7-error-cfg' into for-next
      Merge branch 'xfs-4.7-inode-reclaim' into for-next

Eric Sandeen (5):
      xfs: disallow rw remount on fs with unknown ro-compat features
      xfs: only return -errno or success from attr ->put_listent
      xfs: don't pass value into attr ->put_listent
      xfs: remove put_value from attr ->put_listent context
      xfs: collapse cases in xfs_attr3_leaf_list_int

Eryu Guan (2):
      xfs: add missing break in xfs_parseargs()
      xfs: mute some sparse warnings

 fs/namei.c                     |    1 -
 fs/xfs/kmem.c                  |   26 +--
 fs/xfs/kmem.h                  |    2 +-
 fs/xfs/libxfs/xfs_attr.c       |   58 ++-----
 fs/xfs/libxfs/xfs_bmap.c       |   22 +--
 fs/xfs/libxfs/xfs_dir2_sf.c    |    9 +-
 fs/xfs/libxfs/xfs_inode_fork.c |   99 +++++++----
 fs/xfs/libxfs/xfs_inode_fork.h |    1 +
 fs/xfs/libxfs/xfs_log_format.h |    5 +
 fs/xfs/libxfs/xfs_sb.c         |    8 +-
 fs/xfs/libxfs/xfs_shared.h     |  102 +-----------
 fs/xfs/xfs_aops.c              |  353 ++++++++++++++++++++--------------------
 fs/xfs/xfs_aops.h              |   15 +-
 fs/xfs/xfs_attr.h              |    4 +-
 fs/xfs/xfs_attr_inactive.c     |   16 +-
 fs/xfs/xfs_attr_list.c         |   85 +++-------
 fs/xfs/xfs_bmap_util.c         |   45 ++---
 fs/xfs/xfs_buf.c               |   12 +-
 fs/xfs/xfs_buf.h               |   20 +++
 fs/xfs/xfs_buf_item.c          |  121 +++++++++-----
 fs/xfs/xfs_dquot.c             |    9 +-
 fs/xfs/xfs_file.c              |    8 +-
 fs/xfs/xfs_fsops.c             |   14 +-
 fs/xfs/xfs_icache.c            |  290 ++++++++++++++++++---------------
 fs/xfs/xfs_inode.c             |  167 ++++++++++---------
 fs/xfs/xfs_inode.h             |    5 +-
 fs/xfs/xfs_inode_item.c        |    6 +-
 fs/xfs/xfs_ioctl.c             |   31 +---
 fs/xfs/xfs_iomap.c             |   53 ++----
 fs/xfs/xfs_iops.c              |  117 ++++++++-----
 fs/xfs/xfs_log.c               |   62 +------
 fs/xfs/xfs_log.h               |    3 +-
 fs/xfs/xfs_log_cil.c           |    1 -
 fs/xfs/xfs_log_priv.h          |    1 -
 fs/xfs/xfs_log_recover.c       |   12 +-
 fs/xfs/xfs_mount.c             |   23 ++-
 fs/xfs/xfs_mount.h             |   34 ++++
 fs/xfs/xfs_pnfs.c              |    7 +-
 fs/xfs/xfs_qm.c                |    9 +-
 fs/xfs/xfs_qm_syscalls.c       |   26 +--
 fs/xfs/xfs_rtalloc.c           |   21 +--
 fs/xfs/xfs_super.c             |   65 +++-----
 fs/xfs/xfs_symlink.c           |   37 ++---
 fs/xfs/xfs_sysfs.c             |  291 ++++++++++++++++++++++++++++++++-
 fs/xfs/xfs_sysfs.h             |    3 +
 fs/xfs/xfs_trace.h             |   16 +-
 fs/xfs/xfs_trans.c             |   88 +++++-----
 fs/xfs/xfs_trans.h             |    8 +-
 fs/xfs/xfs_xattr.c             |   17 +-
 49 files changed, 1293 insertions(+), 1135 deletions(-)
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [GIT PULL] xfs: updates for 4.7-rc1
  2016-05-26  6:13 [GIT PULL] xfs: updates for 4.7-rc1 Dave Chinner
@ 2016-05-26 17:19 ` Linus Torvalds
  2016-05-27  0:13   ` Dave Chinner
  0 siblings, 1 reply; 5+ messages in thread
From: Linus Torvalds @ 2016-05-26 17:19 UTC (permalink / raw)
  To: Dave Chinner; +Cc: Andrew Morton, Linux Kernel Mailing List

On Wed, May 25, 2016 at 11:13 PM, Dave Chinner <david@fromorbit.com> wrote:
>
> Just yell if this is not OK and I'll drop those branches for this
> merge and resend the pull request....

i'm ok with the late branches, it's not like xfs has been a problem spot.

However:

> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git for-next

Your pull request mentions the 'for-next' branch, but I think you
*meant* to send me the "xfs-for-linus-4.7-rc1" tag which points to the
same commit and has your summary in it.

Please try to make sure your pull requests actually contain what you
intend for them to do,

               Linus

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [GIT PULL] xfs: updates for 4.7-rc1
  2016-05-26 17:19 ` Linus Torvalds
@ 2016-05-27  0:13   ` Dave Chinner
  2016-05-27  2:05     ` Linus Torvalds
  0 siblings, 1 reply; 5+ messages in thread
From: Dave Chinner @ 2016-05-27  0:13 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Andrew Morton, Linux Kernel Mailing List

On Thu, May 26, 2016 at 10:19:13AM -0700, Linus Torvalds wrote:
> On Wed, May 25, 2016 at 11:13 PM, Dave Chinner <david@fromorbit.com> wrote:
> >
> > Just yell if this is not OK and I'll drop those branches for this
> > merge and resend the pull request....
> 
> i'm ok with the late branches, it's not like xfs has been a problem spot.

Still, I'll try to avoid them because it reduces testing time.

> However:
> 
> > are available in the git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git for-next
> 
> Your pull request mentions the 'for-next' branch, but I think you
> *meant* to send me the "xfs-for-linus-4.7-rc1" tag which points to the
> same commit and has your summary in it.

<sigh>

Mea culpa. I ran this command after creating the tag:

$ git request-pull v4.6 git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git tags/xfs-for-linus-4.7-rc1 > ~/tmp/t.txt

And I didn't check the output closely enough. I forgot to push the
tag to the upstream repo before running request-pull.

Git often makes it very easy to make mistakes whilst simultaneously
making it hard to notice you've made a mistake. :(

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [GIT PULL] xfs: updates for 4.7-rc1
  2016-05-27  0:13   ` Dave Chinner
@ 2016-05-27  2:05     ` Linus Torvalds
  2016-05-30  5:23       ` Dave Chinner
  0 siblings, 1 reply; 5+ messages in thread
From: Linus Torvalds @ 2016-05-27  2:05 UTC (permalink / raw)
  To: Dave Chinner; +Cc: Andrew Morton, Linux Kernel Mailing List

On Thu, May 26, 2016 at 5:13 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Thu, May 26, 2016 at 10:19:13AM -0700, Linus Torvalds wrote:
>>
>> i'm ok with the late branches, it's not like xfs has been a problem spot.
>
> Still, I'll try to avoid them because it reduces testing time.

Oh, 100% agreed. I'm just saying that you get a pass because you've
historically been very reliable.

>> Your pull request mentions the 'for-next' branch, but I think you
>> *meant* to send me the "xfs-for-linus-4.7-rc1" tag which points to the
>> same commit and has your summary in it.
>
> <sigh>
>
> Mea culpa. I ran this command after creating the tag:
>
> $ git request-pull v4.6 git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git tags/xfs-for-linus-4.7-rc1 > ~/tmp/t.txt
>
> And I didn't check the output closely enough. I forgot to push the
> tag to the upstream repo before running request-pull.
>
> Git often makes it very easy to make mistakes whilst simultaneously
> making it hard to notice you've made a mistake. :(

Actually, that one got fixed in git quite some time ago.

You probably have a fairly old version of git, which had the "helpful"
logic to pick another remote location if it couldn't find the exact
one you had specified, but it could find another one that matched in
content

It was a misguided attempt at automatically just "doing the right
thing" and being easier to use, but yes, it means that it does
something subtly different from what you ask for if you haven't pushed
out the remote you talked about yet.

Bu that was all fixed about two years ago, and I think made v2.0.

Do you perhaps happen to run something like debian-stable or similar
that never upgrades major versions, so you're still at git-1.x?

Building your own git is trivial, and a "make install" will just
install in your ~/bin directory so you don't even have to uninstall
the system one (assuming you have your own ~/bin before /usr/bin in
the path, of course).

               Linus

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [GIT PULL] xfs: updates for 4.7-rc1
  2016-05-27  2:05     ` Linus Torvalds
@ 2016-05-30  5:23       ` Dave Chinner
  0 siblings, 0 replies; 5+ messages in thread
From: Dave Chinner @ 2016-05-30  5:23 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Andrew Morton, Linux Kernel Mailing List

On Thu, May 26, 2016 at 07:05:11PM -0700, Linus Torvalds wrote:
> On Thu, May 26, 2016 at 5:13 PM, Dave Chinner <david@fromorbit.com> wrote:
> > On Thu, May 26, 2016 at 10:19:13AM -0700, Linus Torvalds wrote:
> >>
> >> i'm ok with the late branches, it's not like xfs has been a problem spot.
> >
> > Still, I'll try to avoid them because it reduces testing time.
> 
> Oh, 100% agreed. I'm just saying that you get a pass because you've
> historically been very reliable.
> 
> >> Your pull request mentions the 'for-next' branch, but I think you
> >> *meant* to send me the "xfs-for-linus-4.7-rc1" tag which points to the
> >> same commit and has your summary in it.
> >
> > <sigh>
> >
> > Mea culpa. I ran this command after creating the tag:
> >
> > $ git request-pull v4.6 git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git tags/xfs-for-linus-4.7-rc1 > ~/tmp/t.txt
> >
> > And I didn't check the output closely enough. I forgot to push the
> > tag to the upstream repo before running request-pull.
> >
> > Git often makes it very easy to make mistakes whilst simultaneously
> > making it hard to notice you've made a mistake. :(
> 
> Actually, that one got fixed in git quite some time ago.
> 
> You probably have a fairly old version of git, which had the "helpful"
> logic to pick another remote location if it couldn't find the exact
> one you had specified, but it could find another one that matched in
> content

Ah, unlike my workstation which is running 2.8.3, the server I host
my all my internal network services (including staging trees) is
running....

> Do you perhaps happen to run something like debian-stable or similar
> that never upgrades major versions, so you're still at git-1.x?

... debian stable.

Given the only thing I do manually in those staging trees is tag
commits, push branches to kernel.org, and run "git request-pull" I
hadn't noticed that I was still on an old git.

> Building your own git is trivial, and a "make install" will just
> install in your ~/bin directory so you don't even have to
> uninstall the system one (assuming you have your own ~/bin before
> /usr/bin in the path, of course).

*nod*

But it's far easier just to do 'apt-get install git/testing'
and have 2.8.1 installed 15s later.... :P

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-05-30  5:23 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-05-26  6:13 [GIT PULL] xfs: updates for 4.7-rc1 Dave Chinner
2016-05-26 17:19 ` Linus Torvalds
2016-05-27  0:13   ` Dave Chinner
2016-05-27  2:05     ` Linus Torvalds
2016-05-30  5:23       ` Dave Chinner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox