A brief summary of linux kernel source git operations

Keywords: Linux git vim

An old colleague wanted to quickly check the different versions of the kernel source and asked me if there was any way, of course. Most people who play linux should know that kernel/git/stable/linux.git - Linux kernel stable tree You can find and download the linux kernel source. However, there are many original versions of the kernel source code. If you want to view the kernel update log changelog and source code between multiple kernel versions, you can't always use the kernel/git/stable/linux.git - Linux kernel stable tree Click to view each kernel source? Too inefficient!

For example, it is now suspected that there is a bug in the 3.10.107 kernel file system layer. The 3.10.108 kernel solves the bug, and there are more than N related source C files. It is not sure which file to modify solves the bug. In fact, if you are familiar with git operation, you can get all the update logs changelog from 3.10.107 to 3.10.108 kernels, and find changelog by specific module or keyword, which greatly reduces the scope of search.

Again, you can use Git   Cheout naming quickly switches the source code from 3.10.107 to the specified 3.10.108 without having to download the new 3.10.108 source code, which makes it easy to view multiple versions of the kernel source code. There are other git commands, which are good for reading the kernel source code when you are familiar with them. This article summarizes them.

First git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Download the latest Linux kernel source. Slow downloads are normal and I have to wait. Fortunately, the download speed may reach the M/s level (I've encountered one). Once downloaded, enter the Linux directory and execute ctags  – R establishes the source-code function relationship, which allows you to view the kernel source code with vim, while supporting function jumps.

Execute git first   branch  – a Command to view all local and remote branches of the kernel source code

git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/linux-2.6.11.y
  remotes/origin/linux-2.6.12.y
  remotes/origin/linux-2.6.13.y
  remotes/origin/linux-2.6.14.y
  remotes/origin/linux-2.6.15.y
  ..........
  remotes/origin/linux-3.18.y
  remotes/origin/linux-3.19.y
  remotes/origin/linux-3.2.y
  .........
  remotes/origin/linux-5.9.y
  remotes/origin/linux-rolling-lts
  remotes/origin/linux-rolling-stable
  remotes/origin/master

Print out each kernel version branch

Execute git   checkout linux-3.5.y switches the kernel source to linux-3.5.y. Other kernel versions can also switch in this way, and ctags-R can quickly view different versions of the kernel source instead of downloading each kernel version separately.

[root@localhost linux]# git checkout linux-3.5.y
M       include/uapi/linux/netfilter/xt_CONNMARK.h
M       include/uapi/linux/netfilter/xt_DSCP.h
M       include/uapi/linux/netfilter/xt_MARK.h
M       include/uapi/linux/netfilter/xt_RATEEST.h
M       include/uapi/linux/netfilter/xt_TCPMSS.h
M       include/uapi/linux/netfilter_ipv4/ipt_ECN.h
M       include/uapi/linux/netfilter_ipv4/ipt_TTL.h
M       include/uapi/linux/netfilter_ipv6/ip6t_HL.h
M       net/netfilter/xt_DSCP.c
M       net/netfilter/xt_HL.c
M       net/netfilter/xt_RATEEST.c
M       net/netfilter/xt_TCPMSS.c
M       tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+pombonce.litmus
Switched to branch 'linux-3.5.y'

This is the large version of the kernel. What should I do to get the small version of the kernel? Execute git   tag command

[root@localhost linux]# git tag
v2.6.11
v2.6.11-tree
........
v3.10.28
v3.10.29
.....
v4.2.5
v4.2.6
.....
v5.8.7
v5.8.8
v5.8.9

Of course, git can also be executed   checkout   v3.10.28 switches the kernel source to the specified smaller version of the kernel.

Execute git   status prints the current kernel version. Sometimes git is executed   Log   - 1 When printing the last update log, you can also print the current kernel version, git   Log  - 2 Print the last two update logs.

[root@localhost linux]# git status
# On branch linux-3.5.y
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   include/uapi/linux/netfilter/xt_CONNMARK.h
#       modified:   include/uapi/linux/netfilter/xt_DSCP.h
#       modified:   include/uapi/linux/netfilter/xt_MARK.h
#       modified:   include/uapi/linux/netfilter/xt_RATEEST.h
#       modified:   include/uapi/linux/netfilter/xt_TCPMSS.h
#       modified:   include/uapi/linux/netfilter_ipv4/ipt_ECN.h
#       modified:   include/uapi/linux/netfilter_ipv4/ipt_TTL.h
#       modified:   include/uapi/linux/netfilter_ipv6/ip6t_HL.h
#       modified:   net/netfilter/xt_DSCP.c
#       modified:   net/netfilter/xt_HL.c
#       modified:   net/netfilter/xt_RATEEST.c
#       modified:   net/netfilter/xt_TCPMSS.c
#       modified:   tools/memory-model/litmus-
.............

Executing git log-p block/blk-core.c to view the modification log of a single file can also achieve a similar effect with git blame block/blk-core.c

[root@localhost linux]# git log -p block/blk-core.c
commit 3b629f8d6dc04d3af94429c18fe17239d6fbe2c3
Merge: c547d89 3d5b3fb
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Aug 30 19:30:30 2021 -0700

    Merge tag 'io_uring-bio-cache.5-2021-08-30' of git://git.kernel.dk/linux-block
    
    Pull support for struct bio recycling from Jens Axboe:
     "This adds bio recycling support for polled IO, allowing quick reuse of
      a bio for high IOPS scenarios via a percpu bio_set list.
    
      It's good for almost a 10% improvement in performance, bumping our
      per-core IO limit from ~3.2M IOPS to ~3.5M IOPS"
    
    * tag 'io_uring-bio-cache.5-2021-08-30' of git://git.kernel.dk/linux-block:
      bio: improve kerneldoc documentation for bio_alloc_kiocb()
      block: provide bio_clear_hipri() helper
      block: use the percpu bio cache in __blkdev_direct_IO
      io_uring: enable use of bio alloc cache
      block: clear BIO_PERCPU_CACHE flag if polling isn't supported
      bio: add allocation cache abstraction
      fs: add kiocb alloc cache flag
      bio: optimize initialization of a bio

commit 679369114e55f422dc593d0628cfde1d04ae59b3
Merge: 8596e58 1d1cf15
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Aug 30 18:52:11 2021 -0700

    Merge tag 'for-5.15/block-2021-08-30' of git://git.kernel.dk/linux-block
    
    Pull block updates from Jens Axboe:
     "Nothing major in here - lots of good cleanups and tech debt handling,
      which is also evident in the diffstats. In particular:
    
       - Add disk sequence numbers (Matteo)
..................

Important information such as commit id, author, time, modification log will be printed. You can also execute git log --oneline --graph block/blk-mq.c to view all the brief update logs for the file, which is useful when looking for bug s.

If we want to see all the modification logs between the two kernel versions of linux-3.5.y and linux-3.6.y, execute the git log   remotes/origin/linux-3.5.y..remotes/origin/linux-3.6.y command

[root@localhost linux]# git log  remotes/origin/linux-3.5.y..remotes/origin/linux-3.6.y        
commit b2824f4e0990716407b0c0e7acee75bb6353febf
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Dec 17 09:27:45 2012 -0800

    Linux 3.6.11

commit 8647f31166b23f82f8ba33b3bf563e9f2bbd8956
Author: Tommi Rantala <tt.rantala@gmail.com>
Date:   Thu Nov 22 03:23:16 2012 +0000

    sctp: fix -ENOMEM result with invalid user space pointer in sendto() syscall
..............................

If the linux-3.5.y kernel has an ext4 file system bug, the linux-3.6.y kernel solves it. This command is useful when you want to see which updates to the linux-3.5.y kernel solved the bug. Because you can find clues in the commit log. But git   Log   remotes/origin/linux-3.5.y..remotes/origin/linux-3.6.y Prints too much information and is it too cluttered to view only the brief information for each update? Yes, use the git log --oneline remotes/origin/linux-3.5.y..remotes/origin/linux-3.6.y command

[root@localhost linux]# git log --oneline remotes/origin/linux-3.5.y..remotes/origin/linux-3.6.y
b2824f4 Linux 3.6.11
8647f31 sctp: fix -ENOMEM result with invalid user space pointer in sendto() syscall
11b435b sctp: fix memory leak in sctp_datamsg_from_user() when copy from user space fails
c60fcb1 bonding: fix race condition in bonding_store_slaves_active
6ba4bca bonding: Bonding driver does not consider the gso_max_size/gso_max_segs setting of slave devices.
be59563 net: cdc_ncm: add Huawei devices
8e63550 usb/ipheth: Add iPhone 5 support
973e442 inet_diag: validate port comparison byte code to prevent unsafe reads
38a5e42 inet_diag: avoid unsafe and nonsensical prefix matches in inet_diag_bc_run()
2d9f468 inet_diag: validate byte code to prevent oops in inet_diag_bc_run()
72c4553 inet_diag: fix oops for IPv4 AF_INET6 TCP SYN-RECV state
f410b53 ipv4: ip_check_defrag must not modify skb before unsharing
67e2485 ipv4: avoid passing NULL to inet_putpeer() in icmpv4_xrlim_allow()
1322cf6 ipv4: do not cache looped multicasts
0541e18 irda: sir_dev: Fix copy/paste typo
.......................

You can see that the--oneline parameter has been added. This allows you to print only the commit id and the brief update log for each row. git views the kernel log more often than not--oneline prints to filter out interference. Because the kernel bug is related to the ext4 file system, grep ext4 can also search for keywords, which can greatly reduce the interference information as follows:

[root@localhost linux]# git log --oneline remotes/origin/linux-3.5.y..remotes/origin/linux-3.6.y  | grep ext4
5770e9e ext4: remove erroneous ext4_superblock_csum_set() in update_backups()
19dfc17 ext4: fix metadata checksum calculation for the superblock
dab43b7 ext4: fix unjournaled inode bitmap modification
b1f9e72 ext4: Avoid underflow in ext4_trim_fs()
462f4e6 ext4: Checksum the block bitmap properly with bigalloc enabled
e28b27b ext4: race-condition protection for ext4_convert_unwritten_extents_endio
92b7722 ext4: fix mtime update in nodelalloc mode
34414b2 ext4: fix fdatasync() for files with only i_size changes
12ebdf0 ext4: always set i_op in ext4_mknod()
22a5672 ext4: online defrag is not supported for journaled files
ba57d9e ext4: move_extent code cleanup
2fdb112 ext4: fix crash when accessing /proc/mounts concurrently
1638f1f ext4: fix potential deadlock in ext4_nonda_switch()

Assuming that the first line "5770e9e ext4: remove erroneous ext4_superblock_csum_set() in update_backups()" is determined to most likely resolve the bug in this ext4 file system of the linux-3.5.y kernel, how can I view the details of this update? Execute git log   commit id, as follows:

[root@localhost linux]# git log 5770e9e
commit 5770e9ed8a5b8ae7204e6cfe52565f10395091e4
Author: Tao Ma <boyu.mt@taobao.com>
Date:   Thu Sep 20 11:35:38 2012 -0400

    ext4: remove erroneous ext4_superblock_csum_set() in update_backups()
    
    commit bef53b01faeb791e27605cba1a71ba21364cb23e upstream.
    
    The update_backups() function is used to backup all the metadata
    blocks, so we should not take it for granted that 'data' is pointed to
    a super block and use ext4_superblock_csum_set to calculate the
    checksum there.  In case where the data is a group descriptor block,
    it will corrupt the last group descriptor, and then e2fsck will
    complain about it it.
    
    As all the metadata checksums should already be OK when we do the
    backup, remove the wrong ext4_superblock_csum_set and it should be
    just fine.
    
    Reported-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Tao Ma <boyu.mt@taobao.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5433889db1b04159054a9e6357f90c77970cf4ed
Author: Manuel Lauss <manuel.lauss@gmail.com>
Date:   Thu Nov 22 11:58:22 2012 +0100

    MPI: Fix compilation on MIPS with GCC 4.4 and newer
    
    commit a3cea9894157c20a5b1ec08b7e0b5f2019740c10 upstream.
    
    Since 4.4 GCC on MIPS no longer recognizes the "h" constraint,
    leading to t

You can see the next two submissions before and after this update, 5770e9ed8a5b8ae7204e6cfe52565f10395091e4 is the complete commit   Id, 5433889db1b04159054a9e6357f90c77970cf4ed is the previous commit id, then execute the following command: git diff 5433889db1b04159054a9e6357f90c77970cf4ed 5770e9ed8a5ae7204e6cfe52565f10395091e4

[root@localhost linux]# git diff 5433889db1b04159054a9e6357f90c77970cf4ed 5770e9ed8a5b8ae7204e6cfe52565f10395091e4
diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c
index 101b41c..82e1fde3 100644
--- a/fs/ext4/resize.c
+++ b/fs/ext4/resize.c
@@ -979,8 +979,6 @@ static void update_backups(struct super_block *sb,
                goto exit_err;
        }
 
-       ext4_superblock_csum_set(sb);
-
        while ((group = ext4_list_backups(sb, &three, &five, &seven)) < last) {
                struct buffer_head *bh;

Two commit IDS before and after git diff allow you to view the details of the subsequent change, which is the commit id   Detailed record of modification of 5770e9ed8a5b8ae7204e6cfe52565f10395091e4.

Other commonly used git commands, Git   pull gets the latest source version remotely and merges it locally. If you only want to see what the latest source version has changed? You can use the git fetch command. There are other commands:

  1. Git log--author=*** or git log--commitor=***//View only the update logs for a specific author
  2. Git log--since=1.days or git log--since=1.weeks//view update logs for the last day/week
  3. git pull //update the kernel source to the latest
  4. Git checout-b dev//switch to dev branch
  5. git push origin dev//Update source to dev branch
  6. git checkout master//Switch to master branch

git can also be replaced most of the time with tig, which is an interactive mode. That's all for now, so there's a chance to add it later.

Posted by kristianblom on Tue, 19 Oct 2021 09:12:41 -0700