Please pull logfs tree

Please pull logfs tree

[Jörn Engel]

Hi Linus,

in principle this should be a simple pull request.  But as Stephen
noted, the logfs tree conflicts with a patch from hch and I am unsure
how best to proceed.

On Mon, 1 March 2010 16:04:45 +1100, Stephen Rothwell wrote:
> 
> I am carrying a few merge fixup patches in linux-next that I thought you
> might want a heads up about.  Hopefully, these will be fixed before you
> see them, but just in case, here they are (in no particular order).
> 
> This could also be taken as a reminder to the respective maintiners that
> they may want to do a merge of your tree before asking you to pull theirs.
> 
> [...]
> 
> 5) The vfs[9] tree modifies the write_inode method API (commit
> 716c28c0bc8bcbdd26e819f38dfc8fdfaafc0289 "pass writeback_control to
> ->write_inode") and the logfs[10] tree adds a write_inode method (commit
> 5db53f3e80dee2d9dff5e534f9e9fe1db17c9936 "[LogFS] add new flash file
> system"), so:

I see three solutions that are remotely sane.

1) pull git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs.git
and apply the patch at the bottom yourself.

2) pull git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs_for_2.6.34
A tree with the patch applied that won't work standalone but will work
after being pulled into your tree (tested locally).

3) pull git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs_for_2.6.34_alternative
A tree that merged your tree and the logfs tree, then has the patch
applied.  Works standalone but has an additional merge commit.

I would slightly prefer option 2), but you surely know better.

PS: And trees 2) and 3) haven't made it over from master.kernel.org yet.
    Not sure if I made a mistake or simply have to wait longer.

Jörn

-- 
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

>From aaaa4c850bbe2e02aca24b681180258d1671b15e Mon Sep 17 00:00:00 2001
From: Joern Engel <joern@logfs.org>
Date: Sat, 6 Mar 2010 21:25:08 +0100
Subject: [PATCH] [LogFS] Follow write_inode changes

Commit a9185b41a4f84971b930c519f0c63bd450c4810d changed the
write_inode prototype.
---
 fs/logfs/inode.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/logfs/inode.c b/fs/logfs/inode.c
index 6d08b37..33ec1ae 100644
--- a/fs/logfs/inode.c
+++ b/fs/logfs/inode.c
@@ -282,7 +282,7 @@ struct inode *logfs_read_meta_inode(struct super_block *sb, u64 ino)
 	return inode;
 }
 
-static int logfs_write_inode(struct inode *inode, int do_sync)
+static int logfs_write_inode(struct inode *inode, struct writeback_control *wbc)
 {
 	int ret;
 	long flags = WF_LOCK;
-- 
1.6.6.1

Re: Please pull logfs tree

[Linus Torvalds]

On Sat, 6 Mar 2010, Jörn Engel wrote:
> 
> 1) pull git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs.git
> and apply the patch at the bottom yourself.

Not quite - it needs to be applied while merging, rather than applied 
separately. It's a conflict, even though it's not a data-conflict, but a 
semantic one.

But that's trivial enough. "git pull --no-commit" + fixup + "git commit" 
is trivially done, now that I was fore-warned. Thanks.

> 2) pull git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs_for_2.6.34
> A tree with the patch applied that won't work standalone but will work
> after being pulled into your tree (tested locally).

No, that's horrible. Unbisectable. Not that anybody probably cares in this 
case, but it's fundamentally wrong to merge something that doesn't work 
before the merge.

> 3) pull git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs_for_2.6.34_alternative
> A tree that merged your tree and the logfs tree, then has the patch
> applied.  Works standalone but has an additional merge commit.

That's ok, but I already did the trivial merge, which actually had another 
conflict too (which showed up as a real data conflict on the Kconfig 
file).

		Linus

Re: Please pull logfs tree

[Jörn Engel]

On Sat, 6 March 2010 13:26:46 -0800, Linus Torvalds wrote:
> On Sat, 6 Mar 2010, Jörn Engel wrote:
> > 
> > 1) pull git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs.git
> > and apply the patch at the bottom yourself.
> 
> Not quite - it needs to be applied while merging, rather than applied 
> separately. It's a conflict, even though it's not a data-conflict, but a 
> semantic one.
> 
> But that's trivial enough. "git pull --no-commit" + fixup + "git commit" 
> is trivially done, now that I was fore-warned. Thanks.
> 
> > 2) pull git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs_for_2.6.34
> > A tree with the patch applied that won't work standalone but will work
> > after being pulled into your tree (tested locally).
> 
> No, that's horrible. Unbisectable. Not that anybody probably cares in this 
> case, but it's fundamentally wrong to merge something that doesn't work 
> before the merge.
> 
> > 3) pull git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs_for_2.6.34_alternative
> > A tree that merged your tree and the logfs tree, then has the patch
> > applied.  Works standalone but has an additional merge commit.
> 
> That's ok, but I already did the trivial merge, which actually had another 
> conflict too (which showed up as a real data conflict on the Kconfig 
> file).

Ok, learned something new again.  Thank you for doing the trivial merge
that would have taken me days to figure out. :)

Jörn

-- 
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth

Re: Please pull logfs tree

[Linus Torvalds]

On Sat, 6 Mar 2010, Jörn Engel wrote:
> 
> Ok, learned something new again.  Thank you for doing the trivial merge
> that would have taken me days to figure out. :)

Heh. I do those things day in and day out. That was a really easy merge. 
And I'm happy you pointed it out beforehand, so that we didn't get a 
separate commit and non-bisectable history.

			Linus

Please pull logfs tree for fixes

[Jörn Engel]

Good morning Linus!

I have a dozen fixes for you.  Some solve error path bugs, some are
necessary for the SSD that I never wanted to buy but finally did anyway
and the rest solve rather nasty bugs.

Al still has one error path problem I haven't dealt with yet.

 dev_bdev.c  |    9 +++++++--
 dir.c       |    4 ++--
 journal.c   |    7 +++++++
 logfs.h     |    1 +
 readwrite.c |   13 ++++++++++++-
 segment.c   |   54 +++++++++++++++++++++++++++++++-----------------------
 super.c     |   15 +++++++--------
 7 files changed, 67 insertions(+), 36 deletions(-)

git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs.git

Jörn

-- 
Joern's library part 11:
http://www.unicom.com/pw/reply-to-harmful.html

Re: Please pull logfs tree for fixes

[Linus Torvalds]

On Mon, 17 May 2010, Jörn Engel wrote:
> 
> If such a situation reappears in the future, would you rather have the
> fixes and mindlessly revert them in case of any trouble or wait until
> the respective maintainer reappers?

Hmm. I think I'm happier this way. If there is something really critical 
for 2.6.34, you can always send it to stable.

		Linus

Please pull logfs tree for fixes

[Jörn Engel]

Linus,

this should have made it into 2.6.34 - except that I was on vacation
last week and decided not to send a pull request right before hanging
out the "gone fishing" sign.  Whether that was a wise decision, I'm no
longer so sure.

If such a situation reappears in the future, would you rather have the
fixes and mindlessly revert them in case of any trouble or wait until
the respective maintainer reappers?

Jörn

-- 
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


The following changes since commit 79dba2eaa771c3173957eccfd288e0e0d12e4d3f:
  Linus Torvalds (1):
        Merge branch 'for-linus' of git://git.kernel.org/.../jbarnes/pci-2.6

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs.git master

Dan Carpenter (2):
      logfs: testing the wrong variable
      logfs: handle errors from get_mtd_device()

Joern Engel (10):
      LogFS: Fix typo in b6349ac8
      logfs: Return -EINVAL if filesystem image doesn't match
      logfs: fix logfs_seek_hole()
      logfs: Close i_ino reuse race
      logfs: survive logfs_buf_recover read errors
      logfs: commit reservations under space pressure
      logfs: fix compile failure
      logfs: fix sync
      logfs: remove unused variable
      logfs: handle powerfail on NAND flash

Prasad Joshi (1):
      logfs: initialize li->li_refcount

 fs/logfs/dev_bdev.c  |    6 ++++++
 fs/logfs/dev_mtd.c   |   26 +++++++++++++++++++++++++-
 fs/logfs/file.c      |   16 ++++++++++++----
 fs/logfs/gc.c        |   49 +++++++++++++++++++++----------------------------
 fs/logfs/inode.c     |    6 +++---
 fs/logfs/journal.c   |    7 +++----
 fs/logfs/logfs.h     |   13 ++++++++-----
 fs/logfs/readwrite.c |   19 +++++++++++++++----
 fs/logfs/segment.c   |    7 +++++--
 fs/logfs/super.c     |    8 ++++++--
 10 files changed, 104 insertions(+), 53 deletions(-)

Re: Please pull logfs tree for fixes

[Jörn Engel]

On Wed, 21 April 2010 07:09:22 -0700, Daniel Walker wrote:
> On Wed, 2010-04-21 at 14:19 +0200, Jörn Engel wrote:
> > Another set of fixes.  Two of them are security relevant.  But given
> > that an attacker needs mount access and few people have logfs compiled
> > in, that's unlikely to be a huge issue.
> > 
> >  gc.c        |    8 ++++++
> >  journal.c   |   29 ++++++++++++++---------
> >  logfs.h     |   15 ++++++++++--
> >  readwrite.c |   75 +++++++++++++++++++++++++++++++++---------------------------
> >  segment.c   |    8 ------
> >  super.c     |   11 +++++++-
> >  6 files changed, 91 insertions(+), 55 deletions(-)
> 
> Where is the url for your tree? There's a git command,

Doh!

git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs.git

> "git request-pull"
> 
> It spits out a form email with url , and all the needed info.

Nice.  Guess I'll use that from now on.  Thanks!

Jörn

-- 
"Translations are and will always be problematic. They inflict violence
upon two languages." (translation from German)

Re: Please pull logfs tree for fixes

[Daniel Walker]

On Wed, 2010-04-21 at 14:19 +0200, Jörn Engel wrote:
> Another set of fixes.  Two of them are security relevant.  But given
> that an attacker needs mount access and few people have logfs compiled
> in, that's unlikely to be a huge issue.
> 
>  gc.c        |    8 ++++++
>  journal.c   |   29 ++++++++++++++---------
>  logfs.h     |   15 ++++++++++--
>  readwrite.c |   75 +++++++++++++++++++++++++++++++++---------------------------
>  segment.c   |    8 ------
>  super.c     |   11 +++++++-
>  6 files changed, 91 insertions(+), 55 deletions(-)

Where is the url for your tree? There's a git command,

"git request-pull"

It spits out a form email with url , and all the needed info.

Daniel

Please pull logfs tree for fixes

[Jörn Engel]

Another set of fixes.  Two of them are security relevant.  But given
that an attacker needs mount access and few people have logfs compiled
in, that's unlikely to be a huge issue.

 gc.c        |    8 ++++++
 journal.c   |   29 ++++++++++++++---------
 logfs.h     |   15 ++++++++++--
 readwrite.c |   75 +++++++++++++++++++++++++++++++++---------------------------
 segment.c   |    8 ------
 super.c     |   11 +++++++-
 6 files changed, 91 insertions(+), 55 deletions(-)

Jörn

-- 
More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including
blind stupidity.
-- W. A. Wulf