* [GIT PULL] xfs: updates for 3.18-rc1
@ 2014-10-13 1:37 Dave Chinner
2014-10-13 9:48 ` Linus Torvalds
0 siblings, 1 reply; 3+ messages in thread
From: Dave Chinner @ 2014-10-13 1:37 UTC (permalink / raw)
To: torvalds; +Cc: akpm, linux-kernel, xfs
Hi Linus,
Can you please pull the current XFS updates from the tree below?
The changes outlined in the tag description include everything that
is not in your tree, but I has a question about that because there
are commits in the branch that are already in your tree.
i.e. I have generated this pull-req from the base tree I've been working
on (3.17-rc2) but there have already been commits merged into a more
recent upstream tree (3.17-rc4) in this tree. When I generate the
pull request from the underlying 3.17-rc2 branch, it includes all
those commits, both in the summary and the diffstat. If I base the
pull request off 3.17, the base commit is the last one that was
merged into your tree, and the diffstat and commit list reflect
that.
So my question is this: Which tree should I generate the pull
request from? I flipped a coin an generated this one from 3.17-rc2,
but if you'd prefer to see just the commits/diffstat that aren't in
your tree, let me know and I'll do it differently next time....
-Dave.
The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef:
Linux 3.17-rc2 (2014-08-25 15:36:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs tags/xfs-for-linus-3.18-rc1
for you to fetch changes up to 6889e783cd68b79f8330ad4d10a2571c67c3f7df:
Merge branch 'xfs-misc-fixes-for-3.18-3' into for-next (2014-10-13 10:22:45 +1100)
----------------------------------------------------------------
xfs: update for 3.18-rc1
This update contains:
o various cleanups
o log recovery debug hooks
o seek hole/data implementation merge
o extent shift rework to fix collapse range bugs
o various sparse warning fixes
o log recovery transaction processing rework to fix use after free bugs
o metadata buffer IO infrastructuer rework to ensure all buffers under IO have
valid reference counts
o various fixes for ondisk flags, writeback and zero range corner cases
----------------------------------------------------------------
Brian Foster (13):
xfs: don't log inode unless extent shift makes extent modifications
xfs: trim eofblocks before collapse range
xfs: mark all internal workqueues as freezable
xfs: add debug sysfs attribute set
xfs: export log_recovery_delay to delay mount time log recovery
xfs: track collapse via file offset rather than extent index
xfs: refactor shift-by-merge into xfs_bmse_merge() helper
xfs: refactor single extent shift into xfs_bmse_shift_one() helper
xfs: writeback and inval. file range to be shifted by collapse
xfs: only writeback and truncate pages for the freed range
xfs: check for inode size overflow in xfs_new_eof()
xfs: restore buffer_head unwritten bit on ioend cancel
xfs: flush the range before zero range conversion
Chris Mason (1):
xfs: don't zero partial page cache pages during O_DIRECT writes
Christoph Hellwig (1):
xfs: simplify xfs_zero_remaining_bytes
Dave Chinner (39):
xfs: don't dirty buffers beyond EOF
xfs: don't zero partial page cache pages during O_DIRECT writes
xfs: use ranged writeback and invalidation for direct IO
xfs: xfs_file_collapse_range is delalloc challenged
Merge branch 'xfs-misc-fixes-for-3.18-1' into for-next
xfs: ensure WB_SYNC_ALL writeback handles partial pages correctly
Merge branch 'xfs-shift-extents-rework' into for-next
xfs: xlog_cil_force_lsn doesn't always wait correctly
xfs: xfs_buf_write_fail_rl_state can be static
xfs: xfs_swap_extent_flush can be static
xfs: flush entire last page of old EOF on truncate up
Merge branch 'xfs-misc-fixes-for-3.18-2' into for-next
xfs: refactor xlog_recover_process_data()
xfs: recovery of XLOG_UNMOUNT_TRANS leaks memory
xfs: fix double free in xlog_recover_commit_trans
xfs: reorganise transaction recovery item code
xfs: refactor recovery transaction start handling
Merge branch 'xfs-trans-recover-cleanup' into for-next
xfs: fix use of agi_newino in finobt lookup
xfs: xfs_qm_dquot_isolate needs locking annotations for sparse
xfs: xfs_kset should be static
xfs: annotate user variables passed as void
Merge branch 'xfs-sparse-fixes' into for-next
xfs: force the log before shutting down
xfs: Don't use xfs_buf_iowait in the delwri buffer code
xfs: synchronous buffer IO needs a reference
xfs: xfs_buf_ioend and xfs_buf_iodone_work duplicate functionality
xfs: rework xfs_buf_bio_endio error handling
xfs: kill xfs_bdstrat_cb
xfs: xfs_bioerror can die.
xfs: kill xfs_bioerror_relse
xfs: introduce xfs_buf_submit[_wait]
xfs: check xfs_buf_read_uncached returns correctly
Merge branch 'xfs-buf-iosubmit' into for-next
xfs: compat_xfs_bstat does not have forkoff
xfs: kill time.h
xfs: project id inheritance is a directory only flag
xfs: only set extent size hint when asked
Merge branch 'xfs-misc-fixes-for-3.18-3' into for-next
Eric Sandeen (13):
xfs: add a few more verifier tests
xfs: combine xfs_seek_hole & xfs_seek_data
xfs: lseek: the "whence" argument is called "whence"
xfs: deduplicate xlog_do_recovery_pass()
xfs: check resblks before calling xfs_dir_canenter
xfs: combine xfs_dir_canenter into xfs_dir_createname
xfs: combine xfs_rtmodify_summary and xfs_rtget_summary
xfs: remove rbpp check from xfs_rtmodify_summary_int
xfs: don't ASSERT on corrupt ftype
xfs: don't send null bp to xfs_trans_brelse()
xfs: fix crc field handling in xfs_sb_to/from_disk
xfs: check for null dquot in xfs_quota_calc_throttle()
xfs: fix agno increment in xfs_inumbers() loop
Fabian Frederick (1):
xfs: remove second xfs_quota.h inclusion in xfs_icache.c
Fengguang Wu (1):
xfs: xfs_rtget_summary can be static
Mark Tinguely (1):
xfs: xfs_iflush_done checks the wrong log item callback
fs/xfs/kmem.c | 1 -
fs/xfs/libxfs/xfs_alloc.c | 4 +
fs/xfs/libxfs/xfs_bmap.c | 371 ++++++++++++++--------
fs/xfs/libxfs/xfs_bmap.h | 7 +-
fs/xfs/libxfs/xfs_da_btree.c | 3 +-
fs/xfs/libxfs/xfs_da_format.c | 1 -
fs/xfs/libxfs/xfs_dir2.c | 67 +---
fs/xfs/libxfs/xfs_dir2.h | 2 +-
fs/xfs/libxfs/xfs_ialloc.c | 7 +-
fs/xfs/libxfs/xfs_rtbitmap.c | 49 ++-
fs/xfs/libxfs/xfs_sb.c | 7 +
fs/xfs/time.h | 36 ---
fs/xfs/xfs_aops.c | 84 ++++-
fs/xfs/xfs_bmap_util.c | 120 +++----
fs/xfs/xfs_buf.c | 355 ++++++++++-----------
fs/xfs/xfs_buf.h | 15 +-
fs/xfs/xfs_buf_item.c | 10 +-
fs/xfs/xfs_file.c | 205 +++++-------
fs/xfs/xfs_fsops.c | 11 +-
fs/xfs/xfs_globals.c | 4 +
fs/xfs/xfs_icache.c | 1 -
fs/xfs/xfs_inode.c | 34 +-
fs/xfs/xfs_inode.h | 2 +-
fs/xfs/xfs_inode_item.c | 2 +-
fs/xfs/xfs_ioctl.c | 28 +-
fs/xfs/xfs_ioctl32.c | 2 +
fs/xfs/xfs_ioctl32.h | 3 +-
fs/xfs/xfs_iomap.c | 4 +-
fs/xfs/xfs_iops.c | 30 ++
fs/xfs/xfs_itable.c | 3 +-
fs/xfs/xfs_linux.h | 6 +-
fs/xfs/xfs_log.c | 59 ++--
fs/xfs/xfs_log_cil.c | 47 ++-
fs/xfs/xfs_log_recover.c | 689 +++++++++++++++++++++--------------------
fs/xfs/xfs_mount.c | 58 ++--
fs/xfs/xfs_mru_cache.c | 3 +-
fs/xfs/xfs_qm.c | 1 +
fs/xfs/xfs_rtalloc.c | 85 +----
fs/xfs/xfs_rtalloc.h | 4 +
fs/xfs/xfs_super.c | 39 ++-
fs/xfs/xfs_symlink.c | 8 +-
fs/xfs/xfs_sysctl.h | 5 +
fs/xfs/xfs_sysfs.c | 74 +++++
fs/xfs/xfs_sysfs.h | 1 +
fs/xfs/xfs_trace.h | 3 +-
fs/xfs/xfs_trans_buf.c | 16 +-
fs/xfs/xfs_trans_inode.c | 2 +-
47 files changed, 1399 insertions(+), 1169 deletions(-)
delete mode 100644 fs/xfs/time.h
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [GIT PULL] xfs: updates for 3.18-rc1
2014-10-13 1:37 [GIT PULL] xfs: updates for 3.18-rc1 Dave Chinner
@ 2014-10-13 9:48 ` Linus Torvalds
2014-10-13 21:55 ` Dave Chinner
0 siblings, 1 reply; 3+ messages in thread
From: Linus Torvalds @ 2014-10-13 9:48 UTC (permalink / raw)
To: Dave Chinner; +Cc: Andrew Morton, Linux Kernel Mailing List, xfs
On Sun, Oct 12, 2014 at 9:37 PM, Dave Chinner <david@fromorbit.com> wrote:
>
> i.e. I have generated this pull-req from the base tree I've been working
> on (3.17-rc2) but there have already been commits merged into a more
> recent upstream tree (3.17-rc4) in this tree. When I generate the
> pull request from the underlying 3.17-rc2 branch, it includes all
> those commits, both in the summary and the diffstat. If I base the
> pull request off 3.17, the base commit is the last one that was
> merged into your tree, and the diffstat and commit list reflect
> that.
That's fine, and works for me too. This is normal and expected for
stuff that has gotten into my tree other ways (ie bugfixes that were
cherrypicked to be backported from development trees etc). I'm used
to it, and while I hope people minimize it (not only because of
multiple commits showing up with the same patch, but because it can
easily cause stupid merge conflicts because the development tree then
made further changes on top of the same patch), it's also very much
considered "normal development".
That said, when there are actual *common* commits as in your case (as
opposed to cherrypicked commits that generate duplicate commits with
the same patch), I would generally suggest you just let "git
merge-base" figure it all out from my latest tree. That way it takes
into account the stuff that you sent earlier on its own.
But this is not a big deal.
> So my question is this: Which tree should I generate the pull
> request from? I flipped a coin an generated this one from 3.17-rc2,
> but if you'd prefer to see just the commits/diffstat that aren't in
> your tree, let me know and I'll do it differently next time....
Normally, I'd suggest the easiest way to handle things is to have a
"linus" branch that tracks my upstream, and then just generate the
pull request off that. Git will figure out the latest merge base and
just do the right thing, and you don't need to really think about
where you forked things off, and which parts you have already sent to
me.
As mentioned, even then the diffstat doesn't always end up being
exactly right, because the history with partially merged branches, and
with potential cherry-picked commits. So I am not surprised or upset
if the diffstat doesn't always match, it happens quite commonly. I go
on a rant when that i sdue to bad development practices, but I don't
see anything like that in your tree.
Some people avoid this by actually generating a test-merge (to warn me
about upcoming conflicts etc), and then generate the diffstat from
that test merge instead of just using the plain "git diff" in the
git-pull-request helper scripts. Whatever works. This is not a huge
deal, exactly because it's "normal development" (unlike the
back-merges issue).
And in this case, it looks like you don't even have cherry-picks, but
just shared common branches, some of which you sent earlier. It looks
like the diffstat if you just use my current tree as the other point
of the git merge-base is correct, although I haven't actually done the
merge itself yet (still waiting for the build for the previous merge
to finish).
Linus
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [GIT PULL] xfs: updates for 3.18-rc1
2014-10-13 9:48 ` Linus Torvalds
@ 2014-10-13 21:55 ` Dave Chinner
0 siblings, 0 replies; 3+ messages in thread
From: Dave Chinner @ 2014-10-13 21:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Linux Kernel Mailing List, xfs
On Mon, Oct 13, 2014 at 05:48:18AM -0400, Linus Torvalds wrote:
> On Sun, Oct 12, 2014 at 9:37 PM, Dave Chinner <david@fromorbit.com> wrote:
> >
> > i.e. I have generated this pull-req from the base tree I've been working
> > on (3.17-rc2) but there have already been commits merged into a more
> > recent upstream tree (3.17-rc4) in this tree. When I generate the
> > pull request from the underlying 3.17-rc2 branch, it includes all
> > those commits, both in the summary and the diffstat. If I base the
> > pull request off 3.17, the base commit is the last one that was
> > merged into your tree, and the diffstat and commit list reflect
> > that.
>
> That's fine, and works for me too. This is normal and expected for
> stuff that has gotten into my tree other ways (ie bugfixes that were
> cherrypicked to be backported from development trees etc). I'm used
> to it, and while I hope people minimize it (not only because of
> multiple commits showing up with the same patch, but because it can
> easily cause stupid merge conflicts because the development tree then
> made further changes on top of the same patch), it's also very much
> considered "normal development".
>
> That said, when there are actual *common* commits as in your case (as
> opposed to cherrypicked commits that generate duplicate commits with
> the same patch), I would generally suggest you just let "git
> merge-base" figure it all out from my latest tree. That way it takes
> into account the stuff that you sent earlier on its own.
Ok, that seems easy enough to check. I wasn't aware of git
merge-base, so thanks for letting me know about it.
> But this is not a big deal.
>
> > So my question is this: Which tree should I generate the pull
> > request from? I flipped a coin an generated this one from 3.17-rc2,
> > but if you'd prefer to see just the commits/diffstat that aren't in
> > your tree, let me know and I'll do it differently next time....
>
> Normally, I'd suggest the easiest way to handle things is to have a
> "linus" branch that tracks my upstream, and then just generate the
> pull request off that. Git will figure out the latest merge base and
> just do the right thing, and you don't need to really think about
> where you forked things off, and which parts you have already sent to
> me.
OK, that's exactly what I would have done if the coin flip landed
the other way. I'll use that method in future.
> As mentioned, even then the diffstat doesn't always end up being
> exactly right, because the history with partially merged branches, and
> with potential cherry-picked commits. So I am not surprised or upset
> if the diffstat doesn't always match, it happens quite commonly. I go
> on a rant when that i sdue to bad development practices, but I don't
> see anything like that in your tree.
That's good to know - I'm trying to keep the topic branches as
stable as possible so you can see when they were first pushed into
the tree, if/when fixes are appended to them and the dependencies
between them so bisects won't break. If you do see something wrong
or dodgy, just yell. ;)
> Some people avoid this by actually generating a test-merge (to warn me
> about upcoming conflicts etc), and then generate the diffstat from
> that test merge instead of just using the plain "git diff" in the
> git-pull-request helper scripts. Whatever works. This is not a huge
> deal, exactly because it's "normal development" (unlike the
> back-merges issue).
*nod*
Definitely "normal development" - I do that "test merge" as part of
my day-to-day workflow. My test tree (i.e. what I point overnight
xfstests runs at) is your TOT + the current XFS for-next + any patch
sets I'm reviewing, testing and/or developing....
Thanks for the info, Linus.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-10-13 21:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-13 1:37 [GIT PULL] xfs: updates for 3.18-rc1 Dave Chinner
2014-10-13 9:48 ` Linus Torvalds
2014-10-13 21:55 ` Dave Chinner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).