Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: fix up Git commit hook paths

...

Gerrit needs to automatically identify updates to existing patches and update the existing change instead of creating a new one for each patch submitted. This preserves the history of patch comments, and allows comparing old and new versions of a patch for more efficient inspections. For this to work properly the changes you create locally need to have a unique commit id in them. The same Change-Id: line should be used for all versions of a patch.

Please make sure the Change-Id: line and Signed-off-by: lines are at the bottom of the comment. This is required by the fs/lustre-release project and other projects in order for the patch to be approved. If your comments are missing either of these lines the patch will be automatically be rejected at submission time.

The Change-Id: field is inserted automatically into the commit message by installing the buildcontrib/git-hooks/commit-msg hook into each Git repository's .git/hooks/ directory. The buildcontrib/git-hooks/prepare-commit-msg script should be installed as well. From the top-level Lustre tree checkout:

No Format
ln -sf ../../buildcontrib/git-hooks/commit-msg .git/hooks/
ln -sf ../../contrib/buildgit-hooks/prepare-commit-msg .git/hooks/

At git commit time this will run the build/prepare-commit-msg script from the currently Lustre tree to check the code changes for style errors using buildcontrib/checkpatch.pl, and add comments at the end of the commit message with any warnings or errors. After the commit message has been saved, the build/commit-msg script will verify that the commit message format matches the format specified above, and insert the CommitChange-Id: field into the commit message, if one isn't already present.

...

Lustre-commit: and Lustre-change: are used to reference the original version of a patch that is being ported to another branch.

Patches pushed to the upstream kernel should include Intel-bug-id: to reference the JIRA URL for the LU ticket, in the form https://jira.hpdd.intel.com/browse/LU-nnnn. Patches should also include the Reviewed-on: permalink URL for the Gerrit patch, in the form https://review.whamcloud.com/nnnnn. The upstream maintainers do not want to have commit hashes for non-kernel commits, so upstream patches should not include the Lustre-commit: tag.

Patches ported from the upstream kernel, the patch should keep the original commit summary line, with slight modification to conform to Lustre standards: include the JIRA LU ticket number, and replace "staging" and other pathnames in the summary with a subsystem. The Linux-commit: tag is used to hold the upstream kernel commit hash.  The original author should be kept as the author of the patch using the git --author option, as well as the original Signed-off-by: tag(s).

...

No Format
LU-477 ldiskfs: allocate s_group_desc/s_group_info by vmalloc()

Add the patch to the RHEL6 ldiskfs patch series.

Large kmalloc() for sbi->s_group_desc and sbi->s_group_info can fail
for large filesystems (typically over 16TB), which will cause the
"not enough memory" error while mounting.  This patch makes allocation
fall back to vmalloc() if the kmalloc() failed, as what was done for
sbi->s_flex_groups.

To avoid colliding with an valid on-disk inode number, EXT4_BAD_INO
is used as the number of the buddy cache inode.

The patch also incorporates the following upstream kernel fix:

  Linux-commit: 32a9bb57d7c1fd04ae0f72b8f671501f000a0e9f
  ext4: fix missing iput() of root inode for some mount error paths
  https://bugzilla.kernel.org/show_bug.cgi?id=26752

Signed-off-by: Yu Jian <yujian@whamcloud.com>
Change-Id: I3950425835ea7f2968ceb2edbc622e3ff3ed8545

...

For patches backported from master to a Lustre maintenance branch (e.g. b2_5) there are some conventions to follow so that the changes/fixes can more easily be tracked across branches. The best method for porting a patch from one branch to another is to use git cherry-pick {commit_hash} on the branch where you want the patch to land.  This will apply the whole patch (as best as is able, and show conflicts where needed), copy the commit message, preserve the original patch author.  With luck, there will not be any patch conflicts and no further work is needed.  If necessary, the patch conflicts need to be resolved before committing the patch.  For the commit message:

  • the entire commit message, including the summary line, should be copied from the source change
  • the Signed-off-by: line of the original author should also be kept
  • the person who commits the ported change should add a Signed-off-by: line with their name and email following the original one
  • the original Change-Id: line can be kept (newer Gerrit versions can handle the same Change-Id: line on different branches
  • the original Reviewed-by: lines can be kept, and Gerrit will automatically add them as reviewers to the new patch
  • the Tested-by: Maloo and Tested-by: Jenkins lines should be removed from the new commit message, though any Tested-by: lines from real people can be kept
  • the "Reviewed-on: http://review.whamcloud.com/nnnnn" line should be changed to "Lustre-change: http://review.whamcloud.com/nnnnn" (please use the "canonicalpermalink" gerrit Gerrit URL as shown)
  • the "cherry picked from commit abcdef1234567890" line should be changed to  "Lustre-commit: abcdef1234567890"
  • any non-trivial changes to the original patch should be described after the original Signed-off-by: and Lustre-commit: lines before your own Signed-off-by: line
  • if two or more patches are being combined into a single patch (normally only in case when there are bugs in the original patch that were fixed in later commits) the full commit message from each patch should be kept, along with the Signed-off-by: and Lustre-commit: and Lustre-change: lines of each commit

...

No Format
lustre/llite: simplify dentry revalidate
    
Lustre client dentry validation is protected by LDLM lock, so
any time a dentry is found, it's valid and no need to revalidate
from MDS, and even it does, there is race that it may be
invalidated after revalidation is finished.
    
Signed-off-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-on: http://review.whamcloud.com/7475
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3544
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

...