[GIT PULL] ext4 bugfixes for 3.2-rc5

[GIT PULL] ext4 bugfixes for 3.2-rc5

[Theodore Ts'o]

Hi Linus,

There is a signed tag tytso-for-linus-20111214 covering these patches,
which fix a potential hang, crash (on big endian), and data corruption
bugs which show up when using fsx and/or Hugh's kernel compile/mm
torture test.

Please pull,

						- Ted

The following changes since commit dc47ce90c3a822cd7c9e9339fe4d5f61dcb26b50:

  Linux 3.2-rc5 (2011-12-09 15:09:32 -0800)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev

Andrea Arcangeli (1):
      ext4: avoid hangs in ext4_da_should_update_i_disksize()

Paul Mackerras (1):
      ext4: Fix crash due to getting bogus eh_depth value on big-endian systems

Theodore Ts'o (2):
      ext4: fix ext4_end_io_dio() racing against fsync()
      ext4: display the correct mount option in /proc/mounts for [no]init_itable

Yongqiang Yang (4):
      ext4: avoid potential hang in mpage_submit_io() when blocksize < pagesize
      ext4: correctly handle pages w/o buffers in ext4_discard_partial_buffers()
      ext4: remove a wrong BUG_ON in ext4_ext_convert_to_initialized
      ext4: handle EOF correctly in ext4_bio_write_page()

 fs/ext4/extents.c |    3 +-
 fs/ext4/inode.c   |   54 +++++++++-------------------------------------------
 fs/ext4/page-io.c |   12 +++++++++++
 fs/ext4/super.c   |   17 +++++++--------
 4 files changed, 31 insertions(+), 55 deletions(-)

Re: [GIT PULL] ext4 bugfixes for 3.2-rc5

[Linus Torvalds]

On Wed, Dec 14, 2011 at 11:20 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>
> There is a signed tag tytso-for-linus-20111214 covering these patches,
> which fix a potential hang, crash (on big endian), and data corruption
> bugs which show up when using fsx and/or Hugh's kernel compile/mm
> torture test.

Ok, since I build my own git versions, I have one that can pull signed
tags and automatically verifies them and saves the signed tag
information as part of the commit object.

Which is all fine, but your tag-names are just ugly. I could edit the
end result (another advantage of the new git version - it starts the
editor automatically), but I decided to not do so, and instead use
this as a "teaching moment" for everybody.

Everybody: you can now create a signed tag, and just point me at it.
You don't even have to have a separate branch for me to pull any more,
just the signed tag is fine.

So it would actually be nicer if you used temporary tag names the way
you use temporary branch names when  you ask me to pull. The tag
*content* will be saved from now on (unless I screw up while traveling
or something and pull with a machine that has an older git version),
so there's very little advantage in then saving the tags separately by
having ugly tag-names with long lifetimes.

I pushed out, so you can see this in action in the current git tree by doing

 [torvalds@i5 linux]$ git show --abbrev-commit 2240a7bb479c

to see the normal commit message. And then to see the actual
saved-away signed tag information, do

  [torvalds@i5 linux]$ git cat-file commit 2240a7bb479c

which should all work with old versions of git too - it's just the
merger that needs a new version of git. It's easy to parse: it's the
standard "git tag" format, except it is indented by a space to show
that it's part of the header (and then the first empty line is what
ends the commit object headers). So you can basically do something
like

   git cat-file commit 2240a7bb479c |
        awk '/^mergetag /,/^$/ { print }' |
        sed 's/^mergetag//' |
        sed 's/^ //'

to re-create the tag object, and then you can verify it (the part
*before* the "-----BEGIN PGP SIGNATURE-----" line should match the
signature inside the PGP signature - trivial format).

It got verified when I pulled it (the gpg verification output shows up
as part of the comments in the commit message editing thing), but
using the above you can now verify it after-the-fact too, without
having access to your original tag object - since the data is embedded
in the git merge commit.

Hmm?

                              Linus

Re: [GIT PULL] ext4 bugfixes for 3.2-rc5

[Ted Ts'o]

On Wed, Dec 14, 2011 at 06:50:07PM -0800, Linus Torvalds wrote:
> On Wed, Dec 14, 2011 at 11:20 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> >
> > There is a signed tag tytso-for-linus-20111214 covering these patches,
> > which fix a potential hang, crash (on big endian), and data corruption
> > bugs which show up when using fsx and/or Hugh's kernel compile/mm
> > torture test.
> 
> Ok, since I build my own git versions, I have one that can pull signed
> tags and automatically verifies them and saves the signed tag
> information as part of the commit object.

Cool!  Does it save enough that GPG signature information can be
verified later?  I'm a little fuzzy on what is covered by the
signature which gets verified when you run the command "git verify-tag
tytso-for-linus-20111214".  Better yet, does the new version of git
have a command that will automatically verify the digital signature
found in a merge commit?

And this isn't in 1.7.8 yet, right?  I'd have to build version of git
based on the next branch to play with this new signatury goodness?

      	     	  	    	      - Ted

Re: [GIT PULL] ext4 bugfixes for 3.2-rc5

[Linus Torvalds]

On Thu, Dec 15, 2011 at 11:08 AM, Ted Ts'o <tytso@mit.edu> wrote:
>
> Cool!  Does it save enough that GPG signature information can be
> verified later?

Yes, it saves the whole tag object data, and the verification really
is very simple.

Do the command line I suggested:

  git cat-file commit 2240a7bb479c |
       awk '/^mergetag /,/^$/ { print }' |
       sed 's/^mergetag//' |
       sed 's/^ //'

(ok, that can almost certainly be done smarter, but it's a
step-by-step trivial thing: the "awk" line to get everything in the
commit object header 'mergetag' line to tne end of the commit header
(empty line), followed by removing the "mergetag" part, followed by
removing the continuation space at the beginning of the line.

Now, save the end result to a file, and then split the file so that
the gpg signature part (-----BEGIN PGP SIGNATURE----- etc) is in
"file.sign", and the part before it, which in this case is

  object 5a0dc7365c240795bf190766eba7a27600be3b3e
  type commit
  tag tytso-for-linus-20111214
  tagger Theodore Ts'o <tytso@mit.edu> 1323890113 -0500

  tytso-for-linus-20111214

is in the file "file", and now you can just do

  [torvalds@i5 linux]$ gpg --verify file.sign file
  gpg: Signature made Wed 14 Dec 2011 11:15:13 AM PST using RSA key ID C11804F0
  gpg: Good signature from "Theodore Ts'o <tytso@mit.edu>"
  gpg:                 aka "Theodore Ts'o <tytso@debian.org>"
  gpg:                 aka "Theodore Ts'o <tytso@google.com>"

>                   I'm a little fuzzy on what is covered by the
> signature which gets verified when you run the command "git verify-tag
> tytso-for-linus-20111214".  Better yet, does the new version of git
> have a command that will automatically verify the digital signature
> found in a merge commit?

See above, the pgp signature logic is *really* simple: it's literally
"the pgp signature at the end covers everything up until the pgp
signature part".

And it's unambiguous even in the case of multiple lines of "-----BEGIN
PGP SIGNATURE-----" - you just need to take the last block. Whether we
do that right in the actual implementation, I have no idea, but the
thing is at least designed to allow that.

This all literally used to be a couple of lines of shell script in the
original git implementation of "git verify-tag".

You can just go to the git sources, and do

   git log -p -- git-verify-tag.sh

to see that old historic implementation, of course. Here's the very
original one:

  #!/bin/sh
  . git-sh-setup || die "Not a git archive"

  tag=$(git-rev-parse $1) || exit 1

  git-cat-file tag $tag > .tmp-vtag || exit 1
  cat .tmp-vtag | sed '/-----BEGIN PGP/Q' | gpg --verify .tmp-vtag - || exit 1
  rm -f .tmp-vtag

which gets it wrong for the case of multiple lines of "BEGIN PGP", but
whatever.

> And this isn't in 1.7.8 yet, right?  I'd have to build version of git
> based on the next branch to play with this new signatury goodness?

If you actually want to merge signed tags with the save-the-tag-info
feature, yes. It's in the current master branch of git, but not in any
released version yet.

                    Linus

Re: [GIT PULL] ext4 bugfixes for 3.2-rc5

[Linus Torvalds]

On Thu, Dec 15, 2011 at 11:08 AM, Ted Ts'o <tytso@mit.edu> wrote:
>
> Cool!  Does it save enough that GPG signature information can be
> verified later?

Yes, it saves the whole tag object data, and the verification really
is very simple.

Do the command line I suggested:

  git cat-file commit 2240a7bb479c |
       awk '/^mergetag /,/^$/ { print }' |
       sed 's/^mergetag//' |
       sed 's/^ //'

(ok, that can almost certainly be done smarter, but it's a
step-by-step trivial thing: the "awk" line to get everything in the
commit object header 'mergetag' line to tne end of the commit header
(empty line), followed by removing the "mergetag" part, followed by
removing the continuation space at the beginning of the line.

Now, save the end result to a file, and then split the file so that
the gpg signature part (-----BEGIN PGP SIGNATURE----- etc) is in
"file.sign", and the part before it, which in this case is

  object 5a0dc7365c240795bf190766eba7a27600be3b3e
  type commit
  tag tytso-for-linus-20111214
  tagger Theodore Ts'o <tytso@mit.edu> 1323890113 -0500

  tytso-for-linus-20111214

is in the file "file", and now you can just do

  [torvalds@i5 linux]$ gpg --verify file.sign file
  gpg: Signature made Wed 14 Dec 2011 11:15:13 AM PST using RSA key ID C11804F0
  gpg: Good signature from "Theodore Ts'o <tytso@mit.edu>"
  gpg:                 aka "Theodore Ts'o <tytso@debian.org>"
  gpg:                 aka "Theodore Ts'o <tytso@google.com>"

>                   I'm a little fuzzy on what is covered by the
> signature which gets verified when you run the command "git verify-tag
> tytso-for-linus-20111214".  Better yet, does the new version of git
> have a command that will automatically verify the digital signature
> found in a merge commit?

See above, the pgp signature logic is *really* simple: it's literally
"the pgp signature at the end covers everything up until the pgp
signature part".

And it's unambiguous even in the case of multiple lines of "-----BEGIN
PGP SIGNATURE-----" - you just need to take the last block. Whether we
do that right in the actual implementation, I have no idea, but the
thing is at least designed to allow that.

This all literally used to be a couple of lines of shell script in the
original git implementation of "git verify-tag".

You can just go to the git sources, and do

   git log -p -- git-verify-tag.sh

to see that old historic implementation, of course. Here's the very
original one:

  #!/bin/sh
  . git-sh-setup || die "Not a git archive"

  tag=$(git-rev-parse $1) || exit 1

  git-cat-file tag $tag > .tmp-vtag || exit 1
  cat .tmp-vtag | sed '/-----BEGIN PGP/Q' | gpg --verify .tmp-vtag - || exit 1
  rm -f .tmp-vtag

which gets it wrong for the case of multiple lines of "BEGIN PGP", but
whatever.

> And this isn't in 1.7.8 yet, right?  I'd have to build version of git
> based on the next branch to play with this new signatury goodness?

If you actually want to merge signed tags with the save-the-tag-info
feature, yes. It's in the current master branch of git, but not in any
released version yet.

                    Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] ext4 bugfixes for 3.2-rc5

[Junio C Hamano]

Ted Ts'o <tytso@mit.edu> writes:

> Cool!  Does it save enough that GPG signature information can be
> verified later?  I'm a little fuzzy on what is covered by the
> signature which gets verified when you run the command "git verify-tag
> tytso-for-linus-20111214".  Better yet, does the new version of git
> have a command that will automatically verify the digital signature
> found in a merge commit?
>
> And this isn't in 1.7.8 yet, right?  I'd have to build version of git
> based on the next branch to play with this new signatury goodness?

The 'master' branch as of this week has the topic merged.

Re: [GIT PULL] ext4 bugfixes for 3.2-rc5

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Ted Ts'o <tytso@mit.edu> writes:
> ...
>> And this isn't in 1.7.8 yet, right?  I'd have to build version of git
>> based on the next branch to play with this new signatury goodness?
>
> The 'master' branch as of this week has the topic merged.

Also please notice that the original "pull request" said:

    Hi Linus,

    There is a signed tag tytso-for-linus-20111214 covering these patches,...
    Please pull,

                                                    - Ted

    The following changes since commit dc47ce90c3a822cd7c9e9339fe4d5f61dcb26b50:

      Linux 3.2-rc5 (2011-12-09 15:09:32 -0800)

    are available in the git repository at:
      git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev

    Andrea Arcangeli (1):
          ext4: avoid hangs in ext4_da_should_update_i_disksize()
    ... shortlog output ...

that mentions where the work forked, but does _not_ mention what tip
commit of "dev" branch to expect. Updated "git request-pull" command will
have that information, and also gives the tag name you already pushed out
to your publishing repository instead of the branch name "dev" when
producing the "... available in the git repository at:" information.

Re: [GIT PULL] ext4 bugfixes for 3.2-rc5

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Wed, Dec 14, 2011 at 11:20 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>>
>> There is a signed tag tytso-for-linus-20111214 covering these patches,
>> which fix a potential hang, crash (on big endian), and data corruption
>> bugs which show up when using fsx and/or Hugh's kernel compile/mm
>> torture test.
>
> Ok, since I build my own git versions, I have one that can pull signed
> tags and automatically verifies them and saves the signed tag
> information as part of the commit object.

Just a note. The new feature was broken when the pull has conflict that
needs to be resolved and concluded with "git commit". The version of git
from 'master' as of today should have a fix, but older ones forgot to
record the mergetag in the resulting commit object.

Re: [GIT PULL] ext4 bugfixes for 3.2-rc5

[Nick Holloway]

Linus Torvalds <torvalds@linux-foundation.org> writes:
>   git cat-file commit 2240a7bb479c |
>        awk '/^mergetag /,/^$/ { print }' |
>        sed 's/^mergetag//' |
>        sed 's/^ //'
>
> (ok, that can almost certainly be done smarter,

Forfilling your prediction that it could be smarter, here is the same
in a single sed invocation:

    git cat-file commit 2240a7bb479c | 
	sed -rn '/^mergetag /,/^$/{s/^(mergetag)? //p}'

I don't expect anyone cares though...

-- 
 `O O'  | Nick.Holloway@pyrites.org.uk
// ^ \\ | http://www.pyrites.org.uk/