User Tools

Site Tools


civilinfrastructureplatform:cipkernelmaintenance

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
civilinfrastructureplatform:cipkernelmaintenance [2017/12/13 18:06]
bwhct [Find the patches] Fix link to netdev list info
civilinfrastructureplatform:cipkernelmaintenance [2017/12/13 18:24]
bwhct [Read the code] Fix formatting of code
Line 105: Line 105:
    * If the author is Linus, be aware that he often makes security fixes without describing the security implications.    * If the author is Linus, be aware that he often makes security fixes without describing the security implications.
  
-Look for a //Fixes:// tag in the commit message, identifying which commit introduced (or only partly fixed) the bug that's being fixed:+Look for a ''​Fixes:'' ​tag in the commit message, identifying which commit introduced (or only partly fixed) the bug that's being fixed:
    * If it's not present, look to see if the free-form text identifies which commit introduced it.    * If it's not present, look to see if the free-form text identifies which commit introduced it.
    * Is that commit actually present in the stable branch? Don't forget that it might have been backported as part of another stable update. ​ If not, this probably doesn'​t belong in the stable branch.    * Is that commit actually present in the stable branch? Don't forget that it might have been backported as part of another stable update. ​ If not, this probably doesn'​t belong in the stable branch.
-   * Find the first release containing a commit: ​<​code>​ git describe --contains --match '​v*'​ *hash* </​code>​ +   * Find the first release containing a commit:
-   * Check whether a stable branch contains a backported commit: <​code>​ git log --pretty=oneline --grep=`*hash* ​ `v`*version*`..stable/​linux-`*version*`.y </​code>​+
  
-The //git-check-in-stable// script from [[https://​anonscm.debian.org/​cgit/​kernel/​kernel-team.git/​|kernel-team.git]] provides a shortcut (and slightly nicer output format) for the second command.+> ''​%%git describe --contains --match '​v*'​ %%**//hash//​**''​ 
 + 
 +   * Check whether a stable branch contains a backported commit: 
 + 
 +> ''​%%git log --pretty=oneline ​--grep=%%**//​hash//​**%% v%%**//​version//​**..stable/linux-**//​version//​**.y''​ 
 + 
 +The ''​git-check-in-stable'' ​script from [[https://​anonscm.debian.org/​cgit/​kernel/​kernel-team.git/​|Debian kernel/kernel-team.git]] provides a shortcut (and slightly nicer output format) for the second command.
  
 ==== Read the code ==== ==== Read the code ====
Line 120: Line 125:
       * Ignore white-space changes - they shouldn'​t be combined with fixes, but at least they won't do any harm).       * Ignore white-space changes - they shouldn'​t be combined with fixes, but at least they won't do any harm).
    * If a file contains multiple similar blocks of code, is the right one being patched?    * If a file contains multiple similar blocks of code, is the right one being patched?
-   * If the patch changes a function to acquire and then release a lock or other resource, are there any additional paths through the function where the resource can leak?  For example, there might be an extra //return// statement in the stable branch, compared to the upstream version. +   * If the patch changes a function to acquire and then release a lock or other resource, are there any additional paths through the function where the resource can leak?  For example, there might be an extra ''​return'' ​statement in the stable branch, compared to the upstream version. 
-   * If the patch adds a //return////goto//, or //break// statement, again check for leaks.+   * If the patch adds a ''​return''​''​goto''​, or ''​break'' ​statement, again check for leaks.
    * Sometimes the upstream commit will have been modified (backported) to create the stable patch, because it depended on new or changed APIs, or because a function that needed to be fixed has been merged or split up in some way.  If it has been backported, do the modifications make sense? ​ If someone other than the original author backported it, they should have added an explanation in the new commit message.    * Sometimes the upstream commit will have been modified (backported) to create the stable patch, because it depended on new or changed APIs, or because a function that needed to be fixed has been merged or split up in some way.  If it has been backported, do the modifications make sense? ​ If someone other than the original author backported it, they should have added an explanation in the new commit message.
    * If the patch changes the type or semantics of a function, all its callers probably need to be updated. ​ In the stable branch, there might be additional callers compared to upstream. Have any of them been missed?    * If the patch changes the type or semantics of a function, all its callers probably need to be updated. ​ In the stable branch, there might be additional callers compared to upstream. Have any of them been missed?
civilinfrastructureplatform/cipkernelmaintenance.txt · Last modified: 2023/09/28 06:49 by jki-siemens