- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] nbd: add sanity check for first_minor
by Yang Yingliang 02 Nov '21

02 Nov '21

From: Yu Kuai <yukuai3(a)huawei.com> hulk inclusion category: bugfix bugzilla: 182920, https://gitee.com/openeuler/kernel/issues/I4GLNX CVE: NA --------------------------- When user pass 0x100000 as index, nbd will end up create sysfs dir "/sys/block/43:0": nbd_dev_add disk->first_minor = index << part_shift -> default part_shift is 5, 0x100000 << 5 = 0x2000000 device_add_disk blk_alloc_devt MKDEV(disk->major, disk->first_minor + part->partno) -> (0x2b << 20) | (0x2000000) = 0x2b00000 register_disk device_add device_create_sys_dev_entry format_dev_t MAJOR(devt) -> 0x2b00000 >> 20 = 0x2b MINOR(devt) -> 0x2b00000 & 0xfffff = 0 sysfs_create_link -> /sys/block/43:0 If nbd created device with index 0 aready, then sysfs will compalin about dumplicated creation. On the other hand, the similar dumplicated creation will happen if "index << part_shift" over flow to a value that is less than MINORMASK. Thus fix the problem by adding sanity check for first_minor. Fixes: b0d9111a2d53 ("nbd: use an idr to keep track of nbd devices") Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> Reviewed-by: Jason Yan <yanaijie(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/block/nbd.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index 2a3794801704a..33a52be762d24 100644 --- a/drivers/block/nbd.c +++ b/drivers/block/nbd.c @@ -1755,7 +1755,18 @@ static int nbd_dev_add(int index) refcount_set(&nbd->refs, 1); INIT_LIST_HEAD(&nbd->list); disk->major = NBD_MAJOR; + + /* + * Too big index can cause duplicate creation of sysfs files/links, + * because MKDEV() expect that the max first minor is MINORMASK, or + * index << part_shift can overflow. + */ disk->first_minor = index << part_shift; + if (disk->first_minor < index || disk->first_minor > MINORMASK) { + err = -EINVAL; + goto out_free_tags; + } + disk->fops = &nbd_fops; disk->private_data = nbd; sprintf(disk->disk_name, "nbd%d", index); -- 2.25.1

1 0

[PATCH openEuler-1.0-LTS] perf: hisi: Fix compile error if defined MODULE
by Yang Yingliang 02 Nov '21

02 Nov '21

From: Lijun Fang <fanglijun3(a)huawei.com> ascend inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4D4WR CVE: NA --------------------------- Fix compile error if defined MODULE. Signed-off-by: Lijun Fang <fanglijun3(a)huawei.com> Reviewed-by: Cheng Jian <cj.chengjian(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/perf/hisilicon/hisi_uncore_lpddrc_pmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/perf/hisilicon/hisi_uncore_lpddrc_pmu.c b/drivers/perf/hisilicon/hisi_uncore_lpddrc_pmu.c index 8f8b211788e0f..ca395252ccc3d 100644 --- a/drivers/perf/hisilicon/hisi_uncore_lpddrc_pmu.c +++ b/drivers/perf/hisilicon/hisi_uncore_lpddrc_pmu.c @@ -241,7 +241,7 @@ static int hisi_lpddrc_pmu_init_irq(struct hisi_pmu *lpddrc_pmu, static const struct of_device_id lpddrc_of_match[] = { { .compatible = "hisilicon,lpddrc-pmu", }, {}, -} +}; MODULE_DEVICE_TABLE(of, lpddrc_of_match); static int hisi_lpddrc_pmu_init_data(struct platform_device *pdev, -- 2.25.1

1 0

[PATCH openEuler-1.0-LTS] nfc: nci: fix the UAF of rf_conn_info object
by Yang Yingliang 02 Nov '21

02 Nov '21

From: Lin Ma <linma(a)zju.edu.cn> mainline inclusion from mainline-v5.15-rc6 commit 1b1499a817c90fd1ce9453a2c98d2a01cca0e775 category: bugfix bugzilla: NA CVE: CVE-2021-3760 ------------------------------------------------- The nci_core_conn_close_rsp_packet() function will release the conn_info with given conn_id. However, it needs to set the rf_conn_info to NULL to prevent other routines like nci_rf_intf_activated_ntf_packet() to trigger the UAF. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)canonical.com> Signed-off-by: Lin Ma <linma(a)zju.edu.cn> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)canonical.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- net/nfc/nci/rsp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/nfc/nci/rsp.c b/net/nfc/nci/rsp.c index e3bbf1937d0e9..7681f89dc312b 100644 --- a/net/nfc/nci/rsp.c +++ b/net/nfc/nci/rsp.c @@ -289,6 +289,8 @@ static void nci_core_conn_close_rsp_packet(struct nci_dev *ndev, ndev->cur_conn_id); if (conn_info) { list_del(&conn_info->list); + if (conn_info == ndev->rf_conn_info) + ndev->rf_conn_info = NULL; devm_kfree(&ndev->nfc_dev->dev, conn_info); } } -- 2.25.1

1 0

[PATCH openEuler-1.0-LTS 1/4] ipv4: use siphash instead of Jenkins in fnhe_hashfun()
by Yang Yingliang 02 Nov '21

02 Nov '21

From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v5.14 commit 6457378fe796815c973f631a1904e147d6ee33b1 category: bugfix bugzilla: NA CVE: CVE-2021-20322 ------------------------------------------------- A group of security researchers brought to our attention the weakness of hash function used in fnhe_hashfun(). Lets use siphash instead of Jenkins Hash, to considerably reduce security risks. Also remove the inline keyword, this really is distracting. Fixes: d546c621542d ("ipv4: harden fnhe_hashfun()") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reported-by: Keyu Man <kman001(a)ucr.edu> Cc: Willy Tarreau <w(a)1wt.eu> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Xu Jia <xujia39(a)huawei.com> Reviewed-by: Yue Haibing <yuehaibing(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- net/ipv4/route.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 958df3427c34f..dd43e798194ab 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -614,14 +614,14 @@ static struct fib_nh_exception *fnhe_oldest(struct fnhe_hash_bucket *hash) return oldest; } -static inline u32 fnhe_hashfun(__be32 daddr) +static u32 fnhe_hashfun(__be32 daddr) { - static u32 fnhe_hashrnd __read_mostly; - u32 hval; + static siphash_key_t fnhe_hash_key __read_mostly; + u64 hval; - net_get_random_once(&fnhe_hashrnd, sizeof(fnhe_hashrnd)); - hval = jhash_1word((__force u32) daddr, fnhe_hashrnd); - return hash_32(hval, FNHE_HASH_SHIFT); + net_get_random_once(&fnhe_hash_key, sizeof(fnhe_hash_key)); + hval = siphash_1u32((__force u32) daddr, &fnhe_hash_key); + return hash_64(hval, FNHE_HASH_SHIFT); } static void fill_route_from_fnhe(struct rtable *rt, struct fib_nh_exception *fnhe) -- 2.25.1

1 3

[PATCH openEuler-1.0-LTS] README: README optimize
by Yang Yingliang 01 Nov '21

01 Nov '21

From: Laibin Qiu <qiulaibin(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4FS3G?from=project-issue CVE: NA --------------------------- There are some language problems in the README file, and MarkDown fromat syntax is not effective, and it needs to be adjusted. Signed-off-by: suqin <suqin2(a)huawei.com> Signed-off-by: Laibin Qiu <qiulaibin(a)huawei.com> Reviewed-by: Cheng Jian <cj.chengjian(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- README | 291 ++++++++++++++++++++++++++++++--------------------------- 1 file changed, 155 insertions(+), 136 deletions(-) diff --git a/README b/README index 46c9ea3522c1c..21b2e09d62db2 100644 --- a/README +++ b/README @@ -1,174 +1,188 @@ -Contributions to openEuler kernel project -========================================= +# How to Contribute +------- -Sign CLA --------- +- [How to Contribute](#How to Contribute) -Before submitting any Contributions to openEuler, you have to sign CLA. + \- [Sign the CLA](#Sign the CLA) -See: - https://openeuler.org/zh/cla.html - https://openeuler.org/en/cla.html + \- [Steps of submitting patches](#Steps of submitting patches) -Steps of submitting patches ---------------------------- + \- [Use the unified patch format](#Use the unified patch format) -1. Compile and test your patches successfully. -2. Generate patches - Your patches should be based on top of latest openEuler branch, and should - use git-format-patch to generate patches, and if it's a patchset, it's - better to use --cover-letter option to describe what the patchset does. + \- [Define the patch format](#Define the patch format) - Using scripts/checkpatch.pl to make sure there's no coding style issue. + \- [Examples](#Examples) - And make sure your patch follow unified openEuler patch format describe - below. + \- [Email client - Thunderbird settings](#Email client - Thunderbird settings) -3. Send patch to openEuler mailing list - Use this command to send patches to openEuler mailing list: +- [Linux kernel](#Linux kernel) - git send-email *.patch -to="kernel(a)openeuler.org" --suppress-cc=all +### Sign the CLA - *NOTE*: that you must add --suppress-cc=all if you use git send-email, - otherwise the email will be cced to the people in upstream community and mailing - lists. +------- - *See*: How to send patches using git-send-email - https://git-scm.com/docs/git-send-email +Before making any contributions to openEuler, sign the CLA first. -4. Mark "v1, v2, v3 ..." in your patch subject if you have multiple versions - to send out. +Address: [https://openeuler.org/en/cla.html](https://openeuler.org/en/cla.html) - Use --subject-prefix="PATCH v2" option to add v2 tag for patchset. - git format-patch --subject-prefix="PATCH v2" -1 +### Steps of submitting patches +------- - Subject examples: - Subject: [PATCH v2 01/27] fork: fix some -Wmissing-prototypes warnings - Subject: [PATCH v3] ext2: improve scalability of bitmap searching +**Step 1** Compile and test your patches. -5. Upstream your kernel patch to kernel community is strongly recommended. - openEuler will sync up with kernel master timely. +**Step 2** Generate patches. -6. Sign your work - the Developer’s Certificate of Origin - As the same of upstream kernel community, you also need to sign your patch. +Your patches should be generated based on the latest openEuler branch using git-format-patch. If your patches are in a patchset, it is better to use the **--cover-letter** option to describe what the patchset does. - See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html +Use **scripts/checkpatch.pl** to ensure that no coding style issue exists. - The sign-off is a simple line at the end of the explanation for the patch, - which certifies that you wrote it or otherwise have the right to pass it - on as an open-source patch. The rules are pretty simple: if you can certify - the below: +In addition, ensure that your patches comply with the unified openEuler patch format described below. - Developer’s Certificate of Origin 1.1 - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +**Step 3** Send your patches to the openEuler mailing list. - By making a contribution to this project, I certify that: +To do so, run the following command: - (a) The contribution was created in whole or in part by me and I have - the right to submit it under the open source license indicated in - the file; or + `git send-email *.patch -to="kernel(a)openeuler.org" --suppress-cc=all` - (b The contribution is based upon previous work that, to the best of - my knowledge, is covered under an appropriate open source license - and I have the right under that license to submit that work with - modifications, whether created in whole or in part by me, under - the same open source license (unless I am permitted to submit under - a different license), as indicated in the file; or +*NOTE*: Add **--suppress-cc=all** if you use git-send-email; otherwise, the email will be copied to all people in the upstream community and mailing lists. - (c) The contribution was provided directly to me by some other person - who certified (a), (b) or (c) and I have not modified it. +For details about how to send patches using git-send-email, see [https://git-scm.com/docs/git-send-email](https://git-scm.com/docs/git-send-…. - (d) I understand and agree that this project and the contribution are - public and that a record of the contribution (including all personal - information I submit with it, including my sign-off) is maintained - indefinitely and may be redistributed consistent with this project - or the open source license(s) involved. +**Step 4** Mark "v1, v2, v3 ..." in your patch subject if you have multiple versions to send out. - then you just add a line saying: +Use the **--subject-prefix="PATCH v2"** option to add the v2 tag to the patchset. - Signed-off-by: Random J Developer <random(a)developer.example.org> + `git format-patch --subject-prefix="PATCH v2" -1` - using your real name (sorry, no pseudonyms or anonymous contributions.) +Subject examples: -Use unified patch format ------------------------- + Subject: [PATCH v2 01/27] fork: fix some -Wmissing-prototypes warnings + + Subject: [PATCH v3] ext2: improve scalability of bitmap searching + +**Step 5** Upstream your kernel patches to the kernel community (recommended). openEuler will synchronize with the kernel master in a timely manner. + +**Step 6** Sign your work - the Developer’s Certificate of Origin. + + Similar to the upstream kernel community, you also need to sign your patch. + + For details, see [https://www.kernel.org/doc/html/latest/process/submitting-patches.html](htt…. + + The sign-off is a simple line at the end of the explanation of the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open source patch. The rules are pretty simple. You can certify as below: + + Developer’s Certificate of Origin 1.1 + + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + By making a contribution to this project, I certify that: + + (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; + + (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; + + (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. + + (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. + +Then you add a line saying: + +Signed-off-by: Random J Developer <random(a)developer.example.org> + +Use your real name (sorry, no pseudonyms or anonymous contributions). + +### Use the unified patch format +------- Reasons: -1. long term maintainability - openEuler will merge massive patches. If all patches are merged by casual - changelog format without a unified format, the git log will be messy, and - then it's hard to figure out the original patch. +1. Long term maintainability + + openEuler will merge massive patches. If all patches are merged by casual + + changelog formats without a unified format, the git logs will be messy, and + + then it is hard to figure out the original patches. + +2. Kernel upgrade -2. kernel upgrade - We definitely will upgrade our openEuler kernel in someday, using strict - patch management will alleviate the pain to migrate patches during big upgrade. + We definitely will upgrade our openEuler kernel in someday, so strict patch management -3. easy for script parsing - Keyword highlighting is necessary for script parsing. + will alleviate the pain to migrate patches during big upgrades. -Patch format definition ------------------------ +3. Easy for script parsing + + Keyword highlighting is necessary for script parsing. + +### Define the patch format +------- + +[M] stands for "mandatory". + +[O] stands for "option". -[M] stands for "mandatory" -[O] stands for "option" $category can be: bug preparation, bugfix, perf, feature, doc, other... -If category is feature, then we also need to add feature name like below: - category: feature - feature: YYY (the feature name) +If category is feature, we need to add a feature name as below: -If the patch is related to CVE or bugzilla, then we need add the corresponding -tag like below (In general, it should include at least one of the following): - CVE: $cve-id - bugzilla: $bug-id +```cpp +category: feature +feature: YYY (the feature name) +``` -Additional changelog should include at least one of the flollwing: - 1) Why we should apply this patch - 2) What real problem in product does this patch resolved - 3) How could we reproduce this bug or how to test - 4) Other useful information for help to understand this patch or problem +If the patch is related to CVE or bugzilla, we need to add the corresponding tag as below (In general, it should include at least one of the following): -The detail information is very useful for porting patch to another kenrel branch. +```cpp +CVE: $cve-id +bugzilla: $bug-id +``` -Example for mainline patch: +Additional changelog should include at least one of the following: - mainline inclusion [M] - from $mainline-version [M] - commit $id [M] - category: $category [M] - bugzilla: $bug-id [O] - CVE: $cve-id [O] +1. Why we should apply this patch - additional changelog [O] +2. What real problems in the product does this patch resolved + +3. How could we reproduce this bug or how to test + +4. Other useful information for help to understand this patch or problem + +The detailed information is very useful for migrating a patch to another kernel branch. + +Example for mainline patch: - -------------------------------- +```cpp +mainline inclusion [M] +from $mainline-version [M] +commit $id [M] +category: $category [M] +bugzilla: $bug-id [O] +CVE: $cve-id [O] - original changelog +additional changelog [O] - Signed-off-by: $yourname <$yourname(a)huawei.com> [M] +-------------------------------- - ($mainline-version could be mainline-3.5, mainline-3.6, etc...) +original changelog +Signed-off-by: $yourname <$yourname(a)huawei.com> [M] +($mainline-version could be mainline-3.5, mainline-3.6, etc...) +``` -Examples --------- +### Examples +------- +```cpp mainline inclusion from mainline-4.10 commit 0becc0ae5b42828785b589f686725ff5bc3b9b25 category: bugfix bugzilla: 3004 -CVE: NA - -The patch fixes a BUG_ON in the product: injecting single bit ECC error -to memory before system boot use hardware inject tools, which cause a -large amount of CMCI during system booting . +CVE: N/A -[ 1.146580] mce: [Hardware Error]: Machine check events logged -[ 1.152908] ------------[ cut here ]------------ -[ 1.157751] kernel BUG at kernel/timer.c:951! -[ 1.162321] invalid opcode: 0000 [#1] SMP -... +The patch fixes a BUG_ON in the product: Injecting a single bit ECC error to the memory before system boot using hardware inject tools will cause a large amount of CMCI during system booting . +[ 1.146580] mce: [Hardware Error]: Machine check events logged +[ 1.152908] ------------[ cut here ]------------ +[ 1.157751] kernel BUG at kernel/timer.c:951! +[ 1.162321] invalid opcode: 0000 [#1] SMP ------------------------------------------------- @@ -177,33 +191,38 @@ original changelog <original S-O-B> Signed-off-by: Zhang San <zhangsan(a)huawei.com> Tested-by: Li Si <lisi(a)huawei.com> +``` + +### Email client - Thunderbird settings +------- + +If you are a new developer in the kernel community, it is highly recommended that you use the Thunderbird mail client. + +1. Thunderbird Installation + + Obtain the English version of Thunderbird from [http://www.mozilla.org/]( http://www.mozilla.org/) and install it on your system. + + Download URL: https://www.thunderbird.net/en-US/thunderbird/all/ + +2. Settings + + 2.1 Use the plain text format instead of the HTML format. + + Choose **Options > Account Settings > Composition & Addressing**, and do **NOT** select Compose message in HTML format. -Email Client - Thunderbird Settings ------------------------------------ + 2.2 Editor settings -If you are newly developer in the kernel community, it is highly recommended -to use thunderbird mail client. + **Tools > Options> Advanced > Config editor** -1. Thunderbird Installation - Get English version Thunderbird from http://www.mozilla.org/ and install - it on your system。 + \- To bring up the Thunderbird's registry editor, set **mailnews.send_plaintext_flowed** to **false**. - Download url: https://www.thunderbird.net/en-US/thunderbird/all/ + \- Disable HTML Format: Set **mail.identity.id1.compose_html** to **false**. -2. Settings - 2.1 Use plain text format instead of HTML format - Options -> Account Settings -> Composition & Addressing, do *NOT* select - "Compose message in HTML format". + \- Enable UTF-8: Set **prefs.converted-to-utf8** to **true**. - 2.2 Editor Settings - Tools->Options->Advanced->Config editor. + \- View messages in UTF-8: Set **mailnews.view_default_charset** to **UTF-8**. - - To bring up the thunderbird's registry editor, and set: - "mailnews.send_plaintext_flowed" to "false". - - Disable HTML Format: Set "mail.identity.id1.compose_html" to "false". - - Enable UTF8: Set "prefs.converted-to-utf8" to "true". - - View message in UTF-8: Set "mailnews.view_default_charset" to "UTF-8". - - Set mailnews.wraplength to 9999 for avoiding auto-wrap + \- Set **mailnews.wraplength** to **9999** to avoid auto-wrap. Linux kernel ============ -- 2.25.1

1 0

[PATCH OLK-5.10] Net:NIC:SPNIC:Fix compile error when O= is specififed
by Yanling Song 01 Nov '21

01 Nov '21

Ramaxel inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4CBDP CVE: NA Signed-off-by: Yanling Song <songyl(a)ramaxel.com> --- drivers/net/ethernet/ramaxel/spnic/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/ramaxel/spnic/Makefile b/drivers/net/ethernet/ramaxel/spnic/Makefile index f86ccff374f6..207e1d9c431a 100644 --- a/drivers/net/ethernet/ramaxel/spnic/Makefile +++ b/drivers/net/ethernet/ramaxel/spnic/Makefile @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only obj-$(CONFIG_SPNIC) += spnic.o -subdir-ccflags-y += -I$(src)/hw +subdir-ccflags-y += -I$(srctree)/$(src)/hw spnic-objs := hw/sphw_common.o \ hw/sphw_hwif.o \ -- 2.27.0

2 1

[PATCH OLK-5.10] SCSI:SPFC: fix compile error when O= is specified
by Yanling Song 01 Nov '21

01 Nov '21

Ramaxel inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4DBD7 CVE: NA Signed-off-by: Yanling Song <songyl(a)ramaxel.com> --- drivers/scsi/spfc/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/spfc/Makefile b/drivers/scsi/spfc/Makefile index 02fe0213e048..205eadc35318 100644 --- a/drivers/scsi/spfc/Makefile +++ b/drivers/scsi/spfc/Makefile @@ -1,9 +1,9 @@ # SPDX-License-Identifier: GPL-2.0-only obj-$(CONFIG_SPFC) += spfc.o -subdir-ccflags-y += -I$(src)/../../net/ethernet/ramaxel/spnic/hw -subdir-ccflags-y += -I$(src)/hw -subdir-ccflags-y += -I$(src)/common +subdir-ccflags-y += -I$(srctree)/$(src)/../../net/ethernet/ramaxel/spnic/hw +subdir-ccflags-y += -I$(srctree)/$(src)/hw +subdir-ccflags-y += -I$(srctree)/$(src)/common spfc-objs := common/unf_init.o \ common/unf_event.o \ -- 2.27.0

2 1

[PATCH openEuler-1.0-LTS V4] README: README optimize
by Laibin Qiu 01 Nov '21

01 Nov '21

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4FS3G?from=project-issue CVE: NA --------------------------- There are some language problems in the README file, and MarkDown fromat syntax is not effective, and it needs to be adjusted. Signed-off-by: suqin <suqin2(a)huawei.com> Signed-off-by: Laibin Qiu <qiulaibin(a)huawei.com> Reviewed-by: Cheng Jian <cj.chengjian(a)huawei.com> --- README | 291 ++++++++++++++++++++++++++++++--------------------------- 1 file changed, 155 insertions(+), 136 deletions(-) diff --git a/README b/README index 46c9ea352..21b2e09d6 100644 --- a/README +++ b/README @@ -1,174 +1,188 @@ -Contributions to openEuler kernel project -========================================= +# How to Contribute +------- -Sign CLA --------- +- [How to Contribute](#How to Contribute) -Before submitting any Contributions to openEuler, you have to sign CLA. + \- [Sign the CLA](#Sign the CLA) -See: - https://openeuler.org/zh/cla.html - https://openeuler.org/en/cla.html + \- [Steps of submitting patches](#Steps of submitting patches) -Steps of submitting patches ---------------------------- + \- [Use the unified patch format](#Use the unified patch format) -1. Compile and test your patches successfully. -2. Generate patches - Your patches should be based on top of latest openEuler branch, and should - use git-format-patch to generate patches, and if it's a patchset, it's - better to use --cover-letter option to describe what the patchset does. + \- [Define the patch format](#Define the patch format) - Using scripts/checkpatch.pl to make sure there's no coding style issue. + \- [Examples](#Examples) - And make sure your patch follow unified openEuler patch format describe - below. + \- [Email client - Thunderbird settings](#Email client - Thunderbird settings) -3. Send patch to openEuler mailing list - Use this command to send patches to openEuler mailing list: +- [Linux kernel](#Linux kernel) - git send-email *.patch -to="kernel(a)openeuler.org" --suppress-cc=all +### Sign the CLA - *NOTE*: that you must add --suppress-cc=all if you use git send-email, - otherwise the email will be cced to the people in upstream community and mailing - lists. +------- - *See*: How to send patches using git-send-email - https://git-scm.com/docs/git-send-email +Before making any contributions to openEuler, sign the CLA first. -4. Mark "v1, v2, v3 ..." in your patch subject if you have multiple versions - to send out. +Address: [https://openeuler.org/en/cla.html](https://openeuler.org/en/cla.html) - Use --subject-prefix="PATCH v2" option to add v2 tag for patchset. - git format-patch --subject-prefix="PATCH v2" -1 +### Steps of submitting patches +------- - Subject examples: - Subject: [PATCH v2 01/27] fork: fix some -Wmissing-prototypes warnings - Subject: [PATCH v3] ext2: improve scalability of bitmap searching +**Step 1** Compile and test your patches. -5. Upstream your kernel patch to kernel community is strongly recommended. - openEuler will sync up with kernel master timely. +**Step 2** Generate patches. -6. Sign your work - the Developer’s Certificate of Origin - As the same of upstream kernel community, you also need to sign your patch. +Your patches should be generated based on the latest openEuler branch using git-format-patch. If your patches are in a patchset, it is better to use the **--cover-letter** option to describe what the patchset does. - See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html +Use **scripts/checkpatch.pl** to ensure that no coding style issue exists. - The sign-off is a simple line at the end of the explanation for the patch, - which certifies that you wrote it or otherwise have the right to pass it - on as an open-source patch. The rules are pretty simple: if you can certify - the below: +In addition, ensure that your patches comply with the unified openEuler patch format described below. - Developer’s Certificate of Origin 1.1 - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +**Step 3** Send your patches to the openEuler mailing list. - By making a contribution to this project, I certify that: +To do so, run the following command: - (a) The contribution was created in whole or in part by me and I have - the right to submit it under the open source license indicated in - the file; or + `git send-email *.patch -to="kernel(a)openeuler.org" --suppress-cc=all` - (b The contribution is based upon previous work that, to the best of - my knowledge, is covered under an appropriate open source license - and I have the right under that license to submit that work with - modifications, whether created in whole or in part by me, under - the same open source license (unless I am permitted to submit under - a different license), as indicated in the file; or +*NOTE*: Add **--suppress-cc=all** if you use git-send-email; otherwise, the email will be copied to all people in the upstream community and mailing lists. - (c) The contribution was provided directly to me by some other person - who certified (a), (b) or (c) and I have not modified it. +For details about how to send patches using git-send-email, see [https://git-scm.com/docs/git-send-email](https://git-scm.com/docs/git-send-…. - (d) I understand and agree that this project and the contribution are - public and that a record of the contribution (including all personal - information I submit with it, including my sign-off) is maintained - indefinitely and may be redistributed consistent with this project - or the open source license(s) involved. +**Step 4** Mark "v1, v2, v3 ..." in your patch subject if you have multiple versions to send out. - then you just add a line saying: +Use the **--subject-prefix="PATCH v2"** option to add the v2 tag to the patchset. - Signed-off-by: Random J Developer <random(a)developer.example.org> + `git format-patch --subject-prefix="PATCH v2" -1` - using your real name (sorry, no pseudonyms or anonymous contributions.) +Subject examples: -Use unified patch format ------------------------- + Subject: [PATCH v2 01/27] fork: fix some -Wmissing-prototypes warnings + + Subject: [PATCH v3] ext2: improve scalability of bitmap searching + +**Step 5** Upstream your kernel patches to the kernel community (recommended). openEuler will synchronize with the kernel master in a timely manner. + +**Step 6** Sign your work - the Developer’s Certificate of Origin. + + Similar to the upstream kernel community, you also need to sign your patch. + + For details, see [https://www.kernel.org/doc/html/latest/process/submitting-patches.html](htt…. + + The sign-off is a simple line at the end of the explanation of the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open source patch. The rules are pretty simple. You can certify as below: + + Developer’s Certificate of Origin 1.1 + + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + By making a contribution to this project, I certify that: + + (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; + + (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; + + (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. + + (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. + +Then you add a line saying: + +Signed-off-by: Random J Developer <random(a)developer.example.org> + +Use your real name (sorry, no pseudonyms or anonymous contributions). + +### Use the unified patch format +------- Reasons: -1. long term maintainability - openEuler will merge massive patches. If all patches are merged by casual - changelog format without a unified format, the git log will be messy, and - then it's hard to figure out the original patch. +1. Long term maintainability + + openEuler will merge massive patches. If all patches are merged by casual + + changelog formats without a unified format, the git logs will be messy, and + + then it is hard to figure out the original patches. + +2. Kernel upgrade -2. kernel upgrade - We definitely will upgrade our openEuler kernel in someday, using strict - patch management will alleviate the pain to migrate patches during big upgrade. + We definitely will upgrade our openEuler kernel in someday, so strict patch management -3. easy for script parsing - Keyword highlighting is necessary for script parsing. + will alleviate the pain to migrate patches during big upgrades. -Patch format definition ------------------------ +3. Easy for script parsing + + Keyword highlighting is necessary for script parsing. + +### Define the patch format +------- + +[M] stands for "mandatory". + +[O] stands for "option". -[M] stands for "mandatory" -[O] stands for "option" $category can be: bug preparation, bugfix, perf, feature, doc, other... -If category is feature, then we also need to add feature name like below: - category: feature - feature: YYY (the feature name) +If category is feature, we need to add a feature name as below: -If the patch is related to CVE or bugzilla, then we need add the corresponding -tag like below (In general, it should include at least one of the following): - CVE: $cve-id - bugzilla: $bug-id +```cpp +category: feature +feature: YYY (the feature name) +``` -Additional changelog should include at least one of the flollwing: - 1) Why we should apply this patch - 2) What real problem in product does this patch resolved - 3) How could we reproduce this bug or how to test - 4) Other useful information for help to understand this patch or problem +If the patch is related to CVE or bugzilla, we need to add the corresponding tag as below (In general, it should include at least one of the following): -The detail information is very useful for porting patch to another kenrel branch. +```cpp +CVE: $cve-id +bugzilla: $bug-id +``` -Example for mainline patch: +Additional changelog should include at least one of the following: - mainline inclusion [M] - from $mainline-version [M] - commit $id [M] - category: $category [M] - bugzilla: $bug-id [O] - CVE: $cve-id [O] +1. Why we should apply this patch - additional changelog [O] +2. What real problems in the product does this patch resolved + +3. How could we reproduce this bug or how to test + +4. Other useful information for help to understand this patch or problem + +The detailed information is very useful for migrating a patch to another kernel branch. + +Example for mainline patch: - -------------------------------- +```cpp +mainline inclusion [M] +from $mainline-version [M] +commit $id [M] +category: $category [M] +bugzilla: $bug-id [O] +CVE: $cve-id [O] - original changelog +additional changelog [O] - Signed-off-by: $yourname <$yourname(a)huawei.com> [M] +-------------------------------- - ($mainline-version could be mainline-3.5, mainline-3.6, etc...) +original changelog +Signed-off-by: $yourname <$yourname(a)huawei.com> [M] +($mainline-version could be mainline-3.5, mainline-3.6, etc...) +``` -Examples --------- +### Examples +------- +```cpp mainline inclusion from mainline-4.10 commit 0becc0ae5b42828785b589f686725ff5bc3b9b25 category: bugfix bugzilla: 3004 -CVE: NA - -The patch fixes a BUG_ON in the product: injecting single bit ECC error -to memory before system boot use hardware inject tools, which cause a -large amount of CMCI during system booting . +CVE: N/A -[ 1.146580] mce: [Hardware Error]: Machine check events logged -[ 1.152908] ------------[ cut here ]------------ -[ 1.157751] kernel BUG at kernel/timer.c:951! -[ 1.162321] invalid opcode: 0000 [#1] SMP -... +The patch fixes a BUG_ON in the product: Injecting a single bit ECC error to the memory before system boot using hardware inject tools will cause a large amount of CMCI during system booting . +[ 1.146580] mce: [Hardware Error]: Machine check events logged +[ 1.152908] ------------[ cut here ]------------ +[ 1.157751] kernel BUG at kernel/timer.c:951! +[ 1.162321] invalid opcode: 0000 [#1] SMP ------------------------------------------------- @@ -177,33 +191,38 @@ original changelog <original S-O-B> Signed-off-by: Zhang San <zhangsan(a)huawei.com> Tested-by: Li Si <lisi(a)huawei.com> +``` + +### Email client - Thunderbird settings +------- + +If you are a new developer in the kernel community, it is highly recommended that you use the Thunderbird mail client. + +1. Thunderbird Installation + + Obtain the English version of Thunderbird from [http://www.mozilla.org/]( http://www.mozilla.org/) and install it on your system. + + Download URL: https://www.thunderbird.net/en-US/thunderbird/all/ + +2. Settings + + 2.1 Use the plain text format instead of the HTML format. + + Choose **Options > Account Settings > Composition & Addressing**, and do **NOT** select Compose message in HTML format. -Email Client - Thunderbird Settings ------------------------------------ + 2.2 Editor settings -If you are newly developer in the kernel community, it is highly recommended -to use thunderbird mail client. + **Tools > Options> Advanced > Config editor** -1. Thunderbird Installation - Get English version Thunderbird from http://www.mozilla.org/ and install - it on your system。 + \- To bring up the Thunderbird's registry editor, set **mailnews.send_plaintext_flowed** to **false**. - Download url: https://www.thunderbird.net/en-US/thunderbird/all/ + \- Disable HTML Format: Set **mail.identity.id1.compose_html** to **false**. -2. Settings - 2.1 Use plain text format instead of HTML format - Options -> Account Settings -> Composition & Addressing, do *NOT* select - "Compose message in HTML format". + \- Enable UTF-8: Set **prefs.converted-to-utf8** to **true**. - 2.2 Editor Settings - Tools->Options->Advanced->Config editor. + \- View messages in UTF-8: Set **mailnews.view_default_charset** to **UTF-8**. - - To bring up the thunderbird's registry editor, and set: - "mailnews.send_plaintext_flowed" to "false". - - Disable HTML Format: Set "mail.identity.id1.compose_html" to "false". - - Enable UTF8: Set "prefs.converted-to-utf8" to "true". - - View message in UTF-8: Set "mailnews.view_default_charset" to "UTF-8". - - Set mailnews.wraplength to 9999 for avoiding auto-wrap + \- Set **mailnews.wraplength** to **9999** to avoid auto-wrap. Linux kernel ============ -- 2.22.0

1 0

[PATCH openEuler-1.0-LTS] PM: hibernate: Get block device exclusively in swsusp_check()
by Yang Yingliang 01 Nov '21

01 Nov '21

From: Ye Bin <yebin10(a)huawei.com> mainline inclusion from mainline-v5.16 commit 39fbef4b0f77f9c89c8f014749ca533643a37c9f category: bugfix bugzilla: 182871 CVE: NA ----------------------------------------------- The following kernel crash can be triggered: [ 89.266592] ------------[ cut here ]------------ [ 89.267427] kernel BUG at fs/buffer.c:3020! [ 89.268264] invalid opcode: 0000 [#1] SMP KASAN PTI [ 89.269116] CPU: 7 PID: 1750 Comm: kmmpd-loop0 Not tainted 5.10.0-862.14.0.6.x86_64-08610-gc932cda3cef4-dirty #20 [ 89.273169] RIP: 0010:submit_bh_wbc.isra.0+0x538/0x6d0 [ 89.277157] RSP: 0018:ffff888105ddfd08 EFLAGS: 00010246 [ 89.278093] RAX: 0000000000000005 RBX: ffff888124231498 RCX: ffffffffb2772612 [ 89.279332] RDX: 1ffff11024846293 RSI: 0000000000000008 RDI: ffff888124231498 [ 89.280591] RBP: ffff8881248cc000 R08: 0000000000000001 R09: ffffed1024846294 [ 89.281851] R10: ffff88812423149f R11: ffffed1024846293 R12: 0000000000003800 [ 89.283095] R13: 0000000000000001 R14: 0000000000000000 R15: ffff8881161f7000 [ 89.284342] FS: 0000000000000000(0000) GS:ffff88839b5c0000(0000) knlGS:0000000000000000 [ 89.285711] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 89.286701] CR2: 00007f166ebc01a0 CR3: 0000000435c0e000 CR4: 00000000000006e0 [ 89.287919] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 89.289138] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 89.290368] Call Trace: [ 89.290842] write_mmp_block+0x2ca/0x510 [ 89.292218] kmmpd+0x433/0x9a0 [ 89.294902] kthread+0x2dd/0x3e0 [ 89.296268] ret_from_fork+0x22/0x30 [ 89.296906] Modules linked in: by running the following commands: 1. mkfs.ext4 -O mmp /dev/sda -b 1024 2. mount /dev/sda /home/test 3. echo "/dev/sda" > /sys/power/resume That happens because swsusp_check() calls set_blocksize() on the target partition which confuses the file system: Thread1 Thread2 mount /dev/sda /home/test get s_mmp_bh --> has mapped flag start kmmpd thread echo "/dev/sda" > /sys/power/resume resume_store software_resume swsusp_check set_blocksize truncate_inode_pages_range truncate_cleanup_page block_invalidatepage discard_buffer --> clean mapped flag write_mmp_block submit_bh submit_bh_wbc BUG_ON(!buffer_mapped(bh)) To address this issue, modify swsusp_check() to open the target block device with exclusive access. Signed-off-by: Ye Bin <yebin10(a)huawei.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Ye Bin <yebin10(a)huawei.com> Reviewed-by: Jason Yan <yanaijie(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- kernel/power/swap.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/power/swap.c b/kernel/power/swap.c index d7f6c1a288d33..4fde37fce4ea4 100644 --- a/kernel/power/swap.c +++ b/kernel/power/swap.c @@ -1512,9 +1512,10 @@ int swsusp_read(unsigned int *flags_p) int swsusp_check(void) { int error; + void *holder; hib_resume_bdev = blkdev_get_by_dev(swsusp_resume_device, - FMODE_READ, NULL); + FMODE_READ | FMODE_EXCL, &holder); if (!IS_ERR(hib_resume_bdev)) { set_blocksize(hib_resume_bdev, PAGE_SIZE); clear_page(swsusp_header); @@ -1536,7 +1537,7 @@ int swsusp_check(void) put: if (error) - blkdev_put(hib_resume_bdev, FMODE_READ); + blkdev_put(hib_resume_bdev, FMODE_READ | FMODE_EXCL); else pr_debug("Image signature found, resuming\n"); } else { -- 2.25.1

1 0

[PATCH openEuler-1.0-LTS V3] README: README optimize
by Laibin Qiu 01 Nov '21

01 Nov '21

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4FS3G?from=project-issue CVE: NA --------------------------- There are some language problems in the README file, and MarkDown fromat syntax is not effective, and it needs to be adjusted. Signed-off-by: suqin <suqin2(a)huawei.com> Signed-off-by: Laibin Qiu <qiulaibin(a)huawei.com> Reviewed-by: Cheng Jian <cj.chengjian(a)huawei.com> --- README | 311 +++++++++++++++++++++++++++++---------------------------- 1 file changed, 161 insertions(+), 150 deletions(-) diff --git a/README b/README index 46c9ea352..3374c4726 100644 --- a/README +++ b/README @@ -1,174 +1,188 @@ -Contributions to openEuler kernel project -========================================= +# How to Contribute +------- -Sign CLA --------- +- [How to Contribute](#How to Contribute) -Before submitting any Contributions to openEuler, you have to sign CLA. + \- [Sign the CLA](#Sign the CLA) -See: - https://openeuler.org/zh/cla.html - https://openeuler.org/en/cla.html + \- [Steps of submitting patches](#Steps of submitting patches) -Steps of submitting patches ---------------------------- + \- [Use the unified patch format](#Use the unified patch format) -1. Compile and test your patches successfully. -2. Generate patches - Your patches should be based on top of latest openEuler branch, and should - use git-format-patch to generate patches, and if it's a patchset, it's - better to use --cover-letter option to describe what the patchset does. + \- [Define the patch format](#Define the patch format) - Using scripts/checkpatch.pl to make sure there's no coding style issue. + \- [Examples](#Examples) - And make sure your patch follow unified openEuler patch format describe - below. + \- [Email client - Thunderbird settings](#Email client - Thunderbird settings) -3. Send patch to openEuler mailing list - Use this command to send patches to openEuler mailing list: +- [Linux kernel](#Linux kernel) - git send-email *.patch -to="kernel(a)openeuler.org" --suppress-cc=all +### Sign the CLA - *NOTE*: that you must add --suppress-cc=all if you use git send-email, - otherwise the email will be cced to the people in upstream community and mailing - lists. +------- - *See*: How to send patches using git-send-email - https://git-scm.com/docs/git-send-email +Before making any contributions to openEuler, sign the CLA first. -4. Mark "v1, v2, v3 ..." in your patch subject if you have multiple versions - to send out. +Address: [https://openeuler.org/en/cla.html](https://openeuler.org/en/cla.html) - Use --subject-prefix="PATCH v2" option to add v2 tag for patchset. - git format-patch --subject-prefix="PATCH v2" -1 +### Steps of submitting patches +------- - Subject examples: - Subject: [PATCH v2 01/27] fork: fix some -Wmissing-prototypes warnings - Subject: [PATCH v3] ext2: improve scalability of bitmap searching +**Step 1** Compile and test your patches. -5. Upstream your kernel patch to kernel community is strongly recommended. - openEuler will sync up with kernel master timely. +**Step 2** Generate patches. -6. Sign your work - the Developer’s Certificate of Origin - As the same of upstream kernel community, you also need to sign your patch. +Your patches should be generated based on the latest openEuler branch using git-format-patch. If your patches are in a patchset, it is better to use the **--cover-letter** option to describe what the patchset does. - See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html +Use **scripts/checkpatch.pl** to ensure that no coding style issue exists. - The sign-off is a simple line at the end of the explanation for the patch, - which certifies that you wrote it or otherwise have the right to pass it - on as an open-source patch. The rules are pretty simple: if you can certify - the below: +In addition, ensure that your patches comply with the unified openEuler patch format described below. - Developer’s Certificate of Origin 1.1 - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +**Step 3** Send your patches to the openEuler mailing list. - By making a contribution to this project, I certify that: +To do so, run the following command: - (a) The contribution was created in whole or in part by me and I have - the right to submit it under the open source license indicated in - the file; or + `git send-email *.patch -to="kernel(a)openeuler.org" --suppress-cc=all` - (b The contribution is based upon previous work that, to the best of - my knowledge, is covered under an appropriate open source license - and I have the right under that license to submit that work with - modifications, whether created in whole or in part by me, under - the same open source license (unless I am permitted to submit under - a different license), as indicated in the file; or +*NOTE*: Add **--suppress-cc=all** if you use git-send-email; otherwise, the email will be copied to all people in the upstream community and mailing lists. - (c) The contribution was provided directly to me by some other person - who certified (a), (b) or (c) and I have not modified it. +For details about how to send patches using git-send-email, see [https://git-scm.com/docs/git-send-email](https://git-scm.com/docs/git-send-…. - (d) I understand and agree that this project and the contribution are - public and that a record of the contribution (including all personal - information I submit with it, including my sign-off) is maintained - indefinitely and may be redistributed consistent with this project - or the open source license(s) involved. +**Step 4** Mark "v1, v2, v3 ..." in your patch subject if you have multiple versions to send out. - then you just add a line saying: +Use the **--subject-prefix="PATCH v2"** option to add the v2 tag to the patchset. - Signed-off-by: Random J Developer <random(a)developer.example.org> + `git format-patch --subject-prefix="PATCH v2" -1` - using your real name (sorry, no pseudonyms or anonymous contributions.) +Subject examples: -Use unified patch format ------------------------- + Subject: [PATCH v2 01/27] fork: fix some -Wmissing-prototypes warnings + + Subject: [PATCH v3] ext2: improve scalability of bitmap searching + +**Step 5** Upstream your kernel patches to the kernel community (recommended). openEuler will synchronize with the kernel master in a timely manner. + +**Step 6** Sign your work - the Developer’s Certificate of Origin. + + Similar to the upstream kernel community, you also need to sign your patch. + + For details, see [https://www.kernel.org/doc/html/latest/process/submitting-patches.html](htt…. + + The sign-off is a simple line at the end of the explanation of the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open source patch. The rules are pretty simple. You can certify as below: + + Developer’s Certificate of Origin 1.1 + + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + By making a contribution to this project, I certify that: + + (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; + + (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; + + (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. + + (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. + +Then you add a line saying: + +Signed-off-by: Random J Developer <random(a)developer.example.org> + +Use your real name (sorry, no pseudonyms or anonymous contributions). + +### Use the unified patch format +------- Reasons: -1. long term maintainability - openEuler will merge massive patches. If all patches are merged by casual - changelog format without a unified format, the git log will be messy, and - then it's hard to figure out the original patch. +1. Long term maintainability + + openEuler will merge massive patches. If all patches are merged by casual + + changelog formats without a unified format, the git logs will be messy, and + + then it is hard to figure out the original patches. + +2. Kernel upgrade -2. kernel upgrade - We definitely will upgrade our openEuler kernel in someday, using strict - patch management will alleviate the pain to migrate patches during big upgrade. + We definitely will upgrade our openEuler kernel in someday, so strict patch management -3. easy for script parsing - Keyword highlighting is necessary for script parsing. + will alleviate the pain to migrate patches during big upgrades. -Patch format definition ------------------------ +3. Easy for script parsing + + Keyword highlighting is necessary for script parsing. + +### Define the patch format +------- + +[M] stands for "mandatory". + +[O] stands for "option". -[M] stands for "mandatory" -[O] stands for "option" $category can be: bug preparation, bugfix, perf, feature, doc, other... -If category is feature, then we also need to add feature name like below: - category: feature - feature: YYY (the feature name) +If category is feature, we need to add a feature name as below: -If the patch is related to CVE or bugzilla, then we need add the corresponding -tag like below (In general, it should include at least one of the following): - CVE: $cve-id - bugzilla: $bug-id +```cpp +category: feature +feature: YYY (the feature name) +``` -Additional changelog should include at least one of the flollwing: - 1) Why we should apply this patch - 2) What real problem in product does this patch resolved - 3) How could we reproduce this bug or how to test - 4) Other useful information for help to understand this patch or problem +If the patch is related to CVE or bugzilla, we need to add the corresponding tag as below (In general, it should include at least one of the following): -The detail information is very useful for porting patch to another kenrel branch. +```cpp +CVE: $cve-id +bugzilla: $bug-id +``` -Example for mainline patch: +Additional changelog should include at least one of the following: - mainline inclusion [M] - from $mainline-version [M] - commit $id [M] - category: $category [M] - bugzilla: $bug-id [O] - CVE: $cve-id [O] +1. Why we should apply this patch - additional changelog [O] +2. What real problems in the product does this patch resolved + +3. How could we reproduce this bug or how to test + +4. Other useful information for help to understand this patch or problem + +The detailed information is very useful for migrating a patch to another kernel branch. + +Example for mainline patch: - -------------------------------- +```cpp +mainline inclusion [M] +from $mainline-version [M] +commit $id [M] +category: $category [M] +bugzilla: $bug-id [O] +CVE: $cve-id [O] - original changelog +additional changelog [O] - Signed-off-by: $yourname <$yourname(a)huawei.com> [M] +-------------------------------- - ($mainline-version could be mainline-3.5, mainline-3.6, etc...) +original changelog +Signed-off-by: $yourname <$yourname(a)huawei.com> [M] +($mainline-version could be mainline-3.5, mainline-3.6, etc...) +``` -Examples --------- +### Examples +------- +```cpp mainline inclusion from mainline-4.10 commit 0becc0ae5b42828785b589f686725ff5bc3b9b25 category: bugfix bugzilla: 3004 -CVE: NA - -The patch fixes a BUG_ON in the product: injecting single bit ECC error -to memory before system boot use hardware inject tools, which cause a -large amount of CMCI during system booting . +CVE: N/A -[ 1.146580] mce: [Hardware Error]: Machine check events logged -[ 1.152908] ------------[ cut here ]------------ -[ 1.157751] kernel BUG at kernel/timer.c:951! -[ 1.162321] invalid opcode: 0000 [#1] SMP -... +The patch fixes a BUG_ON in the product: Injecting a single bit ECC error to the memory before system boot using hardware inject tools will cause a large amount of CMCI during system booting . +[ 1.146580] mce: [Hardware Error]: Machine check events logged +[ 1.152908] ------------[ cut here ]------------ +[ 1.157751] kernel BUG at kernel/timer.c:951! +[ 1.162321] invalid opcode: 0000 [#1] SMP ------------------------------------------------- @@ -177,50 +191,47 @@ original changelog <original S-O-B> Signed-off-by: Zhang San <zhangsan(a)huawei.com> Tested-by: Li Si <lisi(a)huawei.com> +``` + +### Email client - Thunderbird settings +------- + +If you are a new developer in the kernel community, it is highly recommended that you use the Thunderbird mail client. + +1. Thunderbird Installation + + Obtain the English version of Thunderbird from [http://www.mozilla.org/]( http://www.mozilla.org/) and install it on your system. + + Download URL: https://www.thunderbird.net/en-US/thunderbird/all/ + +2. Settings + + 2.1 Use the plain text format instead of the HTML format. + + Choose **Options > Account Settings > Composition & Addressing**, and do **NOT** select Compose message in HTML format. -Email Client - Thunderbird Settings ------------------------------------ + 2.2 Editor settings -If you are newly developer in the kernel community, it is highly recommended -to use thunderbird mail client. + **Tools > Options> Advanced > Config editor** -1. Thunderbird Installation - Get English version Thunderbird from http://www.mozilla.org/ and install - it on your system。 + \- To bring up the Thunderbird's registry editor, set **mailnews.send_plaintext_flowed** to **false**. - Download url: https://www.thunderbird.net/en-US/thunderbird/all/ + \- Disable HTML Format: Set **mail.identity.id1.compose_html** to **false**. -2. Settings - 2.1 Use plain text format instead of HTML format - Options -> Account Settings -> Composition & Addressing, do *NOT* select - "Compose message in HTML format". + \- Enable UTF-8: Set **prefs.converted-to-utf8** to **true**. - 2.2 Editor Settings - Tools->Options->Advanced->Config editor. + \- View messages in UTF-8: Set **mailnews.view_default_charset** to **UTF-8**. - - To bring up the thunderbird's registry editor, and set: - "mailnews.send_plaintext_flowed" to "false". - - Disable HTML Format: Set "mail.identity.id1.compose_html" to "false". - - Enable UTF8: Set "prefs.converted-to-utf8" to "true". - - View message in UTF-8: Set "mailnews.view_default_charset" to "UTF-8". - - Set mailnews.wraplength to 9999 for avoiding auto-wrap + \- Set **mailnews.wraplength** to **9999** to avoid auto-wrap. -Linux kernel -============ +# Linux kernel +------- -There are several guides for kernel developers and users. These guides can -be rendered in a number of formats, like HTML and PDF. Please read -Documentation/admin-guide/README.rst first. +There are several guides for kernel developers and users, which can be rendered in a number of formats, like HTML and PDF. You can read **Documentation/admin-guide/README.rst** first. -In order to build the documentation, use ``make htmldocs`` or -``make pdfdocs``. The formatted documentation can also be read online at: +In order to build the documentation, use **make htmldocs** or **make pdfdocs**. The formatted documentation can also be read online at: https://www.kernel.org/doc/html/latest/ - https://www.kernel.org/doc/html/latest/ +There are various text files in the Documentation/ subdirectory, several of which use the Restructured Text markup notation. See Documentation/00-INDEX for a list of what is contained in each file. -There are various text files in the Documentation/ subdirectory, -several of them using the Restructured Text markup notation. -See Documentation/00-INDEX for a list of what is contained in each file. +Read the **Documentation/process/changes.rst** file, as it contains the requirements for building and running the kernel, and information about the problems that may be caused by upgrading your kernel. -Please read the Documentation/process/changes.rst file, as it contains the -requirements for building and running the kernel, and information about -the problems which may result by upgrading your kernel. -- 2.22.0

1 0

2025

2024

2023

2022

2021

2020

2019

Kernel