《一个令人惊叹的Linux内核补丁》

《分享以原始patch开始深究Linux内核》

《宋宝华：为什么Linux内核常常用unsigned long来代替指针》

《LKML Archive on lore.kernel.org》

一个令人惊叹的Linux内核补丁

分享以原始patch开始深究Linux内核

一个令人惊叹的Linux内核补丁

我们都知道linux内核中的代码非常精妙，但是有些代码由于历史原因，一个函数为了兼容处理各种情况，到最后可能变得非常糟糕，到处都是goto 和if，看的想跳楼(宋老师口头禅^_^)

如果在系统中读一个文件时会调用

generic_file_buffered_read

这个函数的功能是把磁盘中的数据读到page之后，或者直接获取cache中的page,然后调用copy_page_to_iter把page拷贝到用户层的buffer中。

一天寂静的下午，得空，打开电脑，准备仔细研究一下这个函数，发现这个函数的注释上面就写明了：

 * This is really ugly. But the goto's actually try to clarify some* of the logic when it comes to error handling etc.

仔细看了一下代码，果然ugly的不像话，到处都是跳转和判断，令人眩晕，而且整个函数达到300行左右(原谅我看了注释才斗胆这样讲:-) )，发现要是把这个函数看下去，今天一整天的心情都不会好了(当时看的是Linux5.10的代码)

ssize_t generic_file_buffered_read(struct kiocb *iocb,struct iov_iter *iter, ssize_t written)
{find_page:if (fatal_signal_pending(current)) {error = -EINTR;goto out;}error = wait_on_page_locked_killable(page);if (unlikely(error))goto readpage_error;if (PageUptodate(page))goto page_ok;if (inode->i_blkbits == PAGE_SHIFT ||!mapping->a_ops->is_partially_uptodate)goto page_not_up_to_date;/* pipes can't handle partially uptodate pages */if (unlikely(iov_iter_is_pipe(iter)))goto page_not_up_to_date;if (!trylock_page(page))goto page_not_up_to_date;/* Did it get truncated before we got the lock? */if (!page->mapping)goto page_not_up_to_date_locked;if (!mapping->a_ops->is_partially_uptodate(page,offset, iter->count))goto page_not_up_to_date_locked;unlock_page(page);}

于是就想内核社区这么多牛人，他们整天盯着这些代码，肯定很多人早已经注意到了，于是想去看看有没有人提交patch重构这个函数：

./scripts/get_maintainer.pl   mm/filemap.c
linux-kernel@vger.kernel.org (open list)

然后我就在下面网址中搜索generic_file_buffered_read，果然在10月25号(我看代码那天在11月1号前后),就有人发了相关patch:

https://lore.kernel.org/lkml/

然后迫不及待查看patch，并把整个patch 下载下来：

这里推荐一个工具，使用b4工具

https://git.kernel.org/pub/scm/utils/b4/b4.git

可以直接从

https://lore.kernel.org

获取原始格式的patch,便于自己git am之后测试。

# b4 am https://lore.kernel.org/lkml/20201025212949.602194-1-kent.overstreet@gmail.com
v2_20201025_kent_overstreet_generic_file_buffered_read_improvements.cover
v2_20201025_kent_overstreet_generic_file_buffered_read_improvements.mbx

然后直接 git am ,非常方便，这样就打上了lore.kernel.org上提交的patch.

git am v2_20201025_kent_overstreet_generic_file_buffered_read_improvements.mbx
提示：在git am之前，可以提前git apply --check 一下

# gitlogdate -3
fc5608fc9917    2020-10-25      Kent Overstreet fs: generic_file_buffered_read() now uses find_get_pages_contig
3bcadc3306be    2020-10-25      Kent Overstreet fs: Break generic_file_buffered_read up into multiple functions
3650b228f83a    2020-10-25      Linus Torvalds  Linux 5.10-rc1alias gitlogdate='git log --pretty=format:"%h%x09%ad%x09%an%x09%s" --date=short'

打了这个patch之后，generic_file_buffered_read变成了这个样子：

ssize_t generic_file_buffered_read(struct kiocb *iocb,struct iov_iter *iter, ssize_t written)
{
..
pg_nr = generic_file_buffered_read_get_pages(iocb, iter,pages, nr_pages);...
for (i = 0; i < pg_nr; i++) {copied = copy_page_to_iter(pages[i], offset, bytes, iter);}

而且 generic_file_buffered_read_get_pages 也非常之清晰：

static int generic_file_buffered_read_get_pages(struct kiocb *iocb,struct iov_iter *iter,struct page **pages,unsigned int nr)nr_got = find_get_pages_contig(mapping, index, nr, pages);if (nr_got)goto got_pages;if (iocb->ki_flags & IOCB_NOIO)return -EAGAIN;page_cache_sync_readahead(mapping, ra, filp, index, last_index - index);nr_got = find_get_pages_contig(mapping, index, nr, pages);if (nr_got)goto got_pages;
...
}

看完generic_file_buffered_read()之后，整个下午的心情都好多了。

ps: 这个补丁很快就被各种review, 并被相关maintainer收进自己仓库。

获取更多使用patch研究linux内核的方法，可以参考：

分享以原始patch开始深究Linux内核

发现很多人都有一个困扰，对linux内核了解到一定程度，比如看过ULK,写过几年linux驱动，甚至在linux系统上工作过很多年的人，想对linux内核源码进行更深入的研究，感觉就是使不上劲，很难前进,苦恼的不行不行的。

我上一家公司的Linux内核部门主管(Linux内核中某一个子系统的maintainer)说过,patch是逻辑单位，文件是物理单位. 我一直深表认同。

我自己深究linux内核中任何子系统时(包括deadline调度、slub内存分配、ext2文件系统，以及最近一年多对kvm的几千个patch进行逐行分析)，都是按照当时maintainer对此子系统提交的第一个版本开始,还原当时的历史场景，找到功能引入Linux内核的出发点，然后逐步叠加patch分析，发现这样不仅研究得来的知识更加精准,也非常有深度。

所以我想以slub为例，从搭建slub第一个版本(Linux2.6.11)编译运行环境开始，怎样使用git查找第一个引入功能的patch,并从邮件列表中找到当时的提交者，也是现在slub 的maintainer Christoph Lameter当时提交代码时的邮件记录,并分享一点git合并大小补丁的方法。

然后以这位maintainer 出品的这副图为主线，从patch源码角度完全解剖slub的精髓,之后便可以自行更加深入研究。

如何跟踪发现Linux内核补丁（patch）相关推荐

【华为云技术分享】Linux内核补丁源码分析(1)
在上一期中,我们介绍了Linux内核编程环境,在这一期中,我们将通过实例来介绍如何分析Linux内核的补丁. 一.Linux内核补丁在"Linux内核发展史"中,我们简要介绍了L ...
哪里下载linux内核补丁,给大家科普一下linux内核补丁，顺便说一下华为的事
最近一个新闻说华为给linux内核提交了一个补丁(业内人叫patch),这个补丁有漏洞. 我先说给linux提交patch,基本上你在芯片厂商做嵌入式或者内核移植工作,都会给linux内核提交patc ...
第十期-Linux内核补丁源码分析（2）
作者:罗宇哲,中国科学院软件研究所智能软件研究中心在上一期中,我们通过CAKE系统的实例介绍了一种对Linux内核补丁的初步分析方法,这一期我们将继续通过CAKE系统的例子介绍一种对补丁文件源码的分 ...
linux内核启动分析三,Linux内核分析实验三：跟踪分析Linux内核的启动过程
贺邦 + 原创作品转载请注明出处 + <Linux内核分析>MOOC课程 http://mooc.study.163.com/course/USTC-1000029000 一. 实验过程 ...
linux补丁怎么下载工具,Linux内核补丁批量自动下载工具
Linux kernel官网cgit工具不支持按变更代码进行补丁搜索,想到个办法就是把补丁都抓下来,这样可以在本地搜索.花了2个小时写了个小工具,话不多说,直接看效果: E:\docs\TOOLS\p ...
跟踪分析Linux内核5.0系统调用处理过程
跟踪分析Linux内核5.0系统调用处理过程学号384 原创作业转载请注明出处+中国科学技术大学孟宁老师的Linux操作系统分析 https://github.com/mengning/linuxk ...
龙芯2k1000 linux内核,2017年的龙芯2K1000 已获得新的Linux内核补丁
虽然已被更先进的龙芯3 号所取代,但国产MIPS64芯片制造商Loongson在2017年发布的2K1000芯片,还是于近日获得了最新的Linux内核补丁.据悉,2K1000是龙芯打造的双核40nmM ...
Linux内核补丁降级,linux内核生成补丁和打补丁的方法
linux内核源码较多,在修改完内核并发布新内核的时候,一般采用补丁的方式进行发布,而不是整个内核打包发布的. 采用补丁的方式发布有很多好处,1.首先体积很小,通常内核修改很小,生成补丁可能不到1k的 ...
linux内核补丁安装和编译安装
一.简介内核,是一个操作系统的核心.它负责管理系统的进程.内存.设备驱动程序.文件和网络系统,决定着系统的性能和稳定性.Linux作为一个自由软件,在广大爱好者的支持下,内核版本不断更新.新的内核修 ...

如何跟踪发现Linux内核补丁（patch）

一个令人惊叹的Linux内核补丁

分享以原始patch开始深究Linux内核

如何跟踪发现Linux内核补丁（patch）相关推荐

最新文章

热门文章