* Re: [PATCH v2 29/32] regulator/drivers/max8976: Switch to new of thermal API
From: Mark Brown @ 2022-07-25 21:31 UTC (permalink / raw)
To: Daniel Lezcano
Cc: daniel.lezcano, rafael, rui.zhang, linux-pm, linux-kernel,
khilman, abailon, lukasz.luba, damien.lemoal, heiko,
hayashi.kunihiko, mhiramat, talel, thierry.reding, digetx,
jonathanh, anarsoul, tiny.windzz, baolin.wang7, f.fainelli,
bjorn.andersson, mcoquelin.stm32, glaroque, miquel.raynal,
shawnguo, niklas.soderlund, matthias.bgg, j-keerthy,
Liam Girdwood
In-Reply-To: <20220725212637.2818207-30-daniel.lezcano@linexp.org>
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
On Mon, Jul 25, 2022 at 11:26:34PM +0200, Daniel Lezcano wrote:
> The thermal OF code has a new API allowing to migrate the OF
> initialization to a simpler approach. The ops are no longer device
> tree specific and are the generic ones provided by the core code.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] mtd: rawnand: arasan: stop using 0 as NULL pointer
From: Vanessa Page @ 2022-07-25 21:32 UTC (permalink / raw)
To: GONG, Ruiqi
Cc: Miquel Raynal, Naga Sureshkumar Relli, Richard Weinberger,
Vignesh Raghavendra, linux-mtd@lists.infradead.org,
linux-kernel@vger.kernel.org, Wang Weiyang
In-Reply-To: <20220725112108.686347-1-gongruiqi1@huawei.com>
Stop fucking emailing me you pathetic loser
Sent from my iPhone
> On Jul 25, 2022, at 7:23 AM, GONG, Ruiqi <gongruiqi1@huawei.com> wrote:
>
> Fix the following sparse warnings:
>
> drivers/mtd/nand/raw/arasan-nand-controller.c:918:70: warning: Using plain integer as NULL pointer
> drivers/mtd/nand/raw/arasan-nand-controller.c:918:73: warning: Using plain integer as NULL pointer
>
> Signed-off-by: GONG, Ruiqi <gongruiqi1@huawei.com>
> ---
> drivers/mtd/nand/raw/arasan-nand-controller.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/arasan-nand-controller.c b/drivers/mtd/nand/raw/arasan-nand-controller.c
> index 296fb16c8dc3..ec7e6eeac55f 100644
> --- a/drivers/mtd/nand/raw/arasan-nand-controller.c
> +++ b/drivers/mtd/nand/raw/arasan-nand-controller.c
> @@ -915,7 +915,7 @@ static int anfc_check_op(struct nand_chip *chip,
> if (instr->ctx.data.len > ANFC_MAX_CHUNK_SIZE)
> return -ENOTSUPP;
>
> - if (anfc_pkt_len_config(instr->ctx.data.len, 0, 0))
> + if (anfc_pkt_len_config(instr->ctx.data.len, NULL, NULL))
> return -ENOTSUPP;
>
> break;
> --
> 2.25.1
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* + mm-gupc-fix-formating-in-check_and_migrate_movable_page.patch added to mm-unstable branch
From: Andrew Morton @ 2022-07-25 21:34 UTC (permalink / raw)
To: mm-commits, david, apopple, akpm
The patch titled
Subject: mm/gup.c: fix formatting in check_and_migrate_movable_page()
has been added to the -mm mm-unstable branch. Its filename is
mm-gupc-fix-formating-in-check_and_migrate_movable_page.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-gupc-fix-formating-in-check_and_migrate_movable_page.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Alistair Popple <apopple@nvidia.com>
Subject: mm/gup.c: fix formatting in check_and_migrate_movable_page()
Date: Thu, 21 Jul 2022 12:05:52 +1000
Commit b05a79d4377f ("mm/gup: migrate device coherent pages when pinning
instead of failing") added a badly formatted if statement. Fix it.
Link: https://lkml.kernel.org/r/20220721020552.1397598-2-apopple@nvidia.com
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Reported-by: David Hildenbrand <david@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/gup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/mm/gup.c~mm-gupc-fix-formating-in-check_and_migrate_movable_page
+++ a/mm/gup.c
@@ -1983,8 +1983,8 @@ static long check_and_migrate_movable_pa
folio_nr_pages(folio));
}
- if (!list_empty(&movable_page_list) || isolation_error_count
- || coherent_pages)
+ if (!list_empty(&movable_page_list) || isolation_error_count ||
+ coherent_pages)
goto unpin_pages;
/*
_
Patches currently in -mm which might be from apopple@nvidia.com are
mm-gupc-fix-formating-in-check_and_migrate_movable_page.patch
^ permalink raw reply
* Re: [PATCH] jffs2: correct logic when creating a hole in jffs2_write_begin
From: Vanessa Page @ 2022-07-25 21:34 UTC (permalink / raw)
To: Yifei Liu
Cc: ezk@cs.stonybrook.edu, madkar@cs.stonybrook.edu, David Woodhouse,
Richard Weinberger, Matthew Wilcox (Oracle), Kyeong Yoo,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
In-Reply-To: <MN2PR17MB337506A10F6AF87BBC514F97B8959@MN2PR17MB3375.namprd17.prod.outlook.com>
Koop😂😂😑😑😑😎😄😄😴😴👀👀💁🙈🙈🙈🙈💁👀👀😑💁😁😳😎😴😑👀😑😄🤣🤣😀😃😑😴😄🤥🤫😥😰🥵🥵😡😡🤬🤯😭😭😟😟🥳🤩🥸🥸🥸🙁😩🥺☹️😣😔😔😔😖😣😢😡🥶😰😰😥😥😶🌫️🤬🤬🤬🤯😶🌫️🥶😰😰🤫🤫😓🤯🤯🤯
Ooiggvklpoure🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤯🤯🤯🤯🤯🤯🤯🤯🤯🤫😓🤬🤯🤯🤬🤬🙁😒😍😒😒😎🥸🤩🥳😟😖🥺😩😩🤩🥳🥳😟😖😣🙁😩☹️😟😫😤😭🤬🤩🤩🥸😎🙁😩😡😵😪😧🤥🤥😯😵🤮😬🤥😓🤗🤗😶😲🤤🤐🤒🤕😵💫😵💫😵💫😵💫😵💫😵💫😵💫😵💫😵💫😵💫😵💫🤑😼😽☠️💀💀👻👻👻👹👹👺👽👽💀💀👻💀💀💀☠️☠️☠️☠️
> On Jul 25, 2022, at 1:06 AM, Vanessa Page <Vebpe@outlook.com> wrote:
>
> 🥰🥰🥰🥰🥰🥰🥰🥰🥰😍👌😍👌😍😍😍😍😍☺️☺️☺️☺️☺️💕💕😚😚😚😚🥰😚😍😍😍😚😚😍☺️☺️☺️😍💕😚🥰🥰😍☺️☺️😚🥰😍☺️😍🥰😍☺️☺️💕🥰🥰😍☺️☺️😊
>
> Sent from my iPhon✌️
>
>> On Jul 25, 2022, at 1:01 AM, Yifei Liu <yifeliu@cs.stonybrook.edu> wrote:
>>
>> Bug description and fix:
>>
>> 1. Write data to a file, say all 1s from offset 0 to 16.
>>
>> 2. Truncate the file to a smaller size, say 8 bytes.
>>
>> 3. Write new bytes (say 2s) from an offset past the original size of the
>> file, say at offset 20, for 4 bytes. This is supposed to create a "hole"
>> in the file, meaning that the bytes from offset 8 (where it was truncated
>> above) up to the new write at offset 20, should all be 0s (zeros).
>>
>> 4. flush all caches using "echo 3 > /proc/sys/vm/drop_caches" (or unmount
>> and remount) the f/s.
>>
>> 5. Check the content of the file. It is wrong. The 1s that used to be
>> between bytes 9 and 16, before the truncation, have REAPPEARED (they should
>> be 0s).
>>
>> We wrote a script and helper C program to reproduce the bug
>> (reproduce_jffs2_write_begin_issue.sh, write_file.c, and Makefile). We can
>> make them available to anyone.
>>
>> The above example is shown when writing a small file within the same first
>> page. But the bug happens for larger files, as long as steps 1, 2, and 3
>> above all happen within the same page.
>>
>> The problem was traced to the jffs2_write_begin code, where it goes into an
>> 'if' statement intended to handle writes past the current EOF (i.e., writes
>> that may create a hole). The code computes a 'pageofs' that is the floor
>> of the write position (pos), aligned to the page size boundary. In other
>> words, 'pageofs' will never be larger than 'pos'. The code then sets the
>> internal jffs2_raw_inode->isize to the size of max(current inode size,
>> pageofs) but that is wrong: the new file size should be the 'pos', which is
>> larger than both the current inode size and pageofs.
>>
>> Similarly, the code incorrectly sets the internal jffs2_raw_inode->dsize to
>> the difference between the pageofs minus current inode size; instead it
>> should be the current pos minus the current inode size. Finally,
>> inode->i_size was also set incorrectly.
>>
>> The patch below fixes this bug. The bug was discovered using a new tool
>> for finding f/s bugs using model checking, called MCFS (Model Checking File
>> Systems).
>>
>> Signed-off-by: Yifei Liu <yifeliu@cs.stonybrook.edu>
>> Signed-off-by: Erez Zadok <ezk@cs.stonybrook.edu>
>> Signed-off-by: Manish Adkar <madkar@cs.stonybrook.edu>
>> ---
>> fs/jffs2/file.c | 15 +++++++--------
>> 1 file changed, 7 insertions(+), 8 deletions(-)
>>
>> diff --git a/fs/jffs2/file.c b/fs/jffs2/file.c
>> index ba86acbe12d3..0479096b96e4 100644
>> --- a/fs/jffs2/file.c
>> +++ b/fs/jffs2/file.c
>> @@ -137,19 +137,18 @@ static int jffs2_write_begin(struct file *filp, struct address_space *mapping,
>> struct jffs2_inode_info *f = JFFS2_INODE_INFO(inode);
>> struct jffs2_sb_info *c = JFFS2_SB_INFO(inode->i_sb);
>> pgoff_t index = pos >> PAGE_SHIFT;
>> - uint32_t pageofs = index << PAGE_SHIFT;
>> int ret = 0;
>>
>> jffs2_dbg(1, "%s()\n", __func__);
>>
>> - if (pageofs > inode->i_size) {
>> - /* Make new hole frag from old EOF to new page */
>> + if (pos > inode->i_size) {
>> + /* Make new hole frag from old EOF to new position */
>> struct jffs2_raw_inode ri;
>> struct jffs2_full_dnode *fn;
>> uint32_t alloc_len;
>>
>> - jffs2_dbg(1, "Writing new hole frag 0x%x-0x%x between current EOF and new page\n",
>> - (unsigned int)inode->i_size, pageofs);
>> + jffs2_dbg(1, "Writing new hole frag 0x%x-0x%x between current EOF and new position\n",
>> + (unsigned int)inode->i_size, (uint32_t)pos);
>>
>> ret = jffs2_reserve_space(c, sizeof(ri), &alloc_len,
>> ALLOC_NORMAL, JFFS2_SUMMARY_INODE_SIZE);
>> @@ -169,10 +168,10 @@ static int jffs2_write_begin(struct file *filp, struct address_space *mapping,
>> ri.mode = cpu_to_jemode(inode->i_mode);
>> ri.uid = cpu_to_je16(i_uid_read(inode));
>> ri.gid = cpu_to_je16(i_gid_read(inode));
>> - ri.isize = cpu_to_je32(max((uint32_t)inode->i_size, pageofs));
>> + ri.isize = cpu_to_je32((uint32_t)pos);
>> ri.atime = ri.ctime = ri.mtime = cpu_to_je32(JFFS2_NOW());
>> ri.offset = cpu_to_je32(inode->i_size);
>> - ri.dsize = cpu_to_je32(pageofs - inode->i_size);
>> + ri.dsize = cpu_to_je32((uint32_t)pos - inode->i_size);
>> ri.csize = cpu_to_je32(0);
>> ri.compr = JFFS2_COMPR_ZERO;
>> ri.node_crc = cpu_to_je32(crc32(0, &ri, sizeof(ri)-8));
>> @@ -202,7 +201,7 @@ static int jffs2_write_begin(struct file *filp, struct address_space *mapping,
>> goto out_err;
>> }
>> jffs2_complete_reservation(c);
>> - inode->i_size = pageofs;
>> + inode->i_size = pos;
>> mutex_unlock(&f->sem);
>> }
>>
>> --
>> 2.25.1
>>
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [meta-ti][dunfell][PATCH] cadence-mhdp-fw: Lock firmware to j721e
From: Ryan Eatmon @ 2022-07-25 21:35 UTC (permalink / raw)
To: Praneeth Bajjuri, Denys Dmytriyenko, meta-ti
This firmware is only applicable to the j721e platform and not
all j7 devices.
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
---
recipes-bsp/cadence-mhdp-fw/cadence-mhdp-fw_git.bb | 2 +-
recipes-kernel/linux/kernel-rdepends.inc | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/recipes-bsp/cadence-mhdp-fw/cadence-mhdp-fw_git.bb b/recipes-bsp/cadence-mhdp-fw/cadence-mhdp-fw_git.bb
index 5cbbceb6..ec102761 100644
--- a/recipes-bsp/cadence-mhdp-fw/cadence-mhdp-fw_git.bb
+++ b/recipes-bsp/cadence-mhdp-fw/cadence-mhdp-fw_git.bb
@@ -10,7 +10,7 @@ PR = "${INC_PR}.0"
CLEANBROKEN = "1"
-COMPATIBLE_MACHINE = "j7"
+COMPATIBLE_MACHINE = "j7-evm|j7-hs-evm"
PACKAGE_ARCH = "${MACHINE_ARCH}"
diff --git a/recipes-kernel/linux/kernel-rdepends.inc b/recipes-kernel/linux/kernel-rdepends.inc
index 2ebf4948..2ac6eac4 100644
--- a/recipes-kernel/linux/kernel-rdepends.inc
+++ b/recipes-kernel/linux/kernel-rdepends.inc
@@ -38,7 +38,8 @@ RDEPENDS_${KERNEL_PACKAGE_NAME}-base_append_am65xx-evm = " prueth-fw-am65x-sr2 p
RDEPENDS_${KERNEL_PACKAGE_NAME}-base_append_am64xx-evm = " prueth-fw-am65x-sr2"
# Add run-time dependency for Cadence MHDP firmware to the rootfs
-RDEPENDS_${KERNEL_PACKAGE_NAME}-base_append_j7 = " cadence-mhdp-fw"
+RDEPENDS_${KERNEL_PACKAGE_NAME}-base_append_j7-evm = " cadence-mhdp-fw"
+RDEPENDS_${KERNEL_PACKAGE_NAME}-base_append_j7-hs-evm = " cadence-mhdp-fw"
# Add run-time dependency for Video Decoding firmware to the rootfs
RDEPENDS_${KERNEL_PACKAGE_NAME}-base_append_j7 = " vxd-dec-fw"
--
2.17.1
^ permalink raw reply related
* [meta-ti][dunfell][PATCH v2] j7200-hs-evm-k3r5: Move J7200 HS evm support to PG2.0
From: Ryan Eatmon @ 2022-07-25 21:35 UTC (permalink / raw)
To: Praneeth Bajjuri, Denys Dmytriyenko, meta-ti
From: Jonathan Humphreys <j-humphreys@ti.com>
With J7200 PG1.0 being deprecated, use PG2.0 sysfw when building images for j7200-hs-evm.
Also update k3-image-gen version to support this change.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
---
v2: Add in the K3_IMAGE_GEN_SRCREV change since it is required to work.
conf/machine/j7200-hs-evm-k3r5.conf | 2 +-
recipes-bsp/ti-linux-fw/ti-linux-fw.inc | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/conf/machine/j7200-hs-evm-k3r5.conf b/conf/machine/j7200-hs-evm-k3r5.conf
index 488f19ec..3f134877 100644
--- a/conf/machine/j7200-hs-evm-k3r5.conf
+++ b/conf/machine/j7200-hs-evm-k3r5.conf
@@ -4,7 +4,7 @@
require conf/machine/include/k3r5.inc
-SYSFW_SOC = "j7200"
+SYSFW_SOC = "j7200_sr2"
SYSFW_CONFIG = "evm"
SYSFW_SUFFIX = "hs"
diff --git a/recipes-bsp/ti-linux-fw/ti-linux-fw.inc b/recipes-bsp/ti-linux-fw/ti-linux-fw.inc
index d1a1f3a5..8aaf1559 100644
--- a/recipes-bsp/ti-linux-fw/ti-linux-fw.inc
+++ b/recipes-bsp/ti-linux-fw/ti-linux-fw.inc
@@ -25,7 +25,7 @@ SRCREV = "${TI_LINUX_FW_SRCREV}"
BRANCH ?= "ti-linux-firmware"
-K3_IMAGE_GEN_SRCREV ?= "f67a3696bb8d9efd052f40b6c67b742d63f6545c"
+K3_IMAGE_GEN_SRCREV ?= "85a70059fc24242ea03653a5014b98100e4da2d6"
SRCREV_imggen = "${K3_IMAGE_GEN_SRCREV}"
SRCREV_FORMAT = "imggen"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] jffs2: correct logic when creating a hole in jffs2_write_begin
From: Vanessa Page @ 2022-07-25 21:34 UTC (permalink / raw)
To: Yifei Liu
Cc: ezk@cs.stonybrook.edu, madkar@cs.stonybrook.edu, David Woodhouse,
Richard Weinberger, Matthew Wilcox (Oracle), Kyeong Yoo,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
In-Reply-To: <MN2PR17MB337506A10F6AF87BBC514F97B8959@MN2PR17MB3375.namprd17.prod.outlook.com>
Koop😂😂😑😑😑😎😄😄😴😴👀👀💁🙈🙈🙈🙈💁👀👀😑💁😁😳😎😴😑👀😑😄🤣🤣😀😃😑😴😄🤥🤫😥😰🥵🥵😡😡🤬🤯😭😭😟😟🥳🤩🥸🥸🥸🙁😩🥺☹️😣😔😔😔😖😣😢😡🥶😰😰😥😥😶🌫️🤬🤬🤬🤯😶🌫️🥶😰😰🤫🤫😓🤯🤯🤯
Ooiggvklpoure🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤯🤯🤯🤯🤯🤯🤯🤯🤯🤫😓🤬🤯🤯🤬🤬🙁😒😍😒😒😎🥸🤩🥳😟😖🥺😩😩🤩🥳🥳😟😖😣🙁😩☹️😟😫😤😭🤬🤩🤩🥸😎🙁😩😡😵😪😧🤥🤥😯😵🤮😬🤥😓🤗🤗😶😲🤤🤐🤒🤕😵💫😵💫😵💫😵💫😵💫😵💫😵💫😵💫😵💫😵💫😵💫🤑😼😽☠️💀💀👻👻👻👹👹👺👽👽💀💀👻💀💀💀☠️☠️☠️☠️
> On Jul 25, 2022, at 1:06 AM, Vanessa Page <Vebpe@outlook.com> wrote:
>
> 🥰🥰🥰🥰🥰🥰🥰🥰🥰😍👌😍👌😍😍😍😍😍☺️☺️☺️☺️☺️💕💕😚😚😚😚🥰😚😍😍😍😚😚😍☺️☺️☺️😍💕😚🥰🥰😍☺️☺️😚🥰😍☺️😍🥰😍☺️☺️💕🥰🥰😍☺️☺️😊
>
> Sent from my iPhon✌️
>
>> On Jul 25, 2022, at 1:01 AM, Yifei Liu <yifeliu@cs.stonybrook.edu> wrote:
>>
>> Bug description and fix:
>>
>> 1. Write data to a file, say all 1s from offset 0 to 16.
>>
>> 2. Truncate the file to a smaller size, say 8 bytes.
>>
>> 3. Write new bytes (say 2s) from an offset past the original size of the
>> file, say at offset 20, for 4 bytes. This is supposed to create a "hole"
>> in the file, meaning that the bytes from offset 8 (where it was truncated
>> above) up to the new write at offset 20, should all be 0s (zeros).
>>
>> 4. flush all caches using "echo 3 > /proc/sys/vm/drop_caches" (or unmount
>> and remount) the f/s.
>>
>> 5. Check the content of the file. It is wrong. The 1s that used to be
>> between bytes 9 and 16, before the truncation, have REAPPEARED (they should
>> be 0s).
>>
>> We wrote a script and helper C program to reproduce the bug
>> (reproduce_jffs2_write_begin_issue.sh, write_file.c, and Makefile). We can
>> make them available to anyone.
>>
>> The above example is shown when writing a small file within the same first
>> page. But the bug happens for larger files, as long as steps 1, 2, and 3
>> above all happen within the same page.
>>
>> The problem was traced to the jffs2_write_begin code, where it goes into an
>> 'if' statement intended to handle writes past the current EOF (i.e., writes
>> that may create a hole). The code computes a 'pageofs' that is the floor
>> of the write position (pos), aligned to the page size boundary. In other
>> words, 'pageofs' will never be larger than 'pos'. The code then sets the
>> internal jffs2_raw_inode->isize to the size of max(current inode size,
>> pageofs) but that is wrong: the new file size should be the 'pos', which is
>> larger than both the current inode size and pageofs.
>>
>> Similarly, the code incorrectly sets the internal jffs2_raw_inode->dsize to
>> the difference between the pageofs minus current inode size; instead it
>> should be the current pos minus the current inode size. Finally,
>> inode->i_size was also set incorrectly.
>>
>> The patch below fixes this bug. The bug was discovered using a new tool
>> for finding f/s bugs using model checking, called MCFS (Model Checking File
>> Systems).
>>
>> Signed-off-by: Yifei Liu <yifeliu@cs.stonybrook.edu>
>> Signed-off-by: Erez Zadok <ezk@cs.stonybrook.edu>
>> Signed-off-by: Manish Adkar <madkar@cs.stonybrook.edu>
>> ---
>> fs/jffs2/file.c | 15 +++++++--------
>> 1 file changed, 7 insertions(+), 8 deletions(-)
>>
>> diff --git a/fs/jffs2/file.c b/fs/jffs2/file.c
>> index ba86acbe12d3..0479096b96e4 100644
>> --- a/fs/jffs2/file.c
>> +++ b/fs/jffs2/file.c
>> @@ -137,19 +137,18 @@ static int jffs2_write_begin(struct file *filp, struct address_space *mapping,
>> struct jffs2_inode_info *f = JFFS2_INODE_INFO(inode);
>> struct jffs2_sb_info *c = JFFS2_SB_INFO(inode->i_sb);
>> pgoff_t index = pos >> PAGE_SHIFT;
>> - uint32_t pageofs = index << PAGE_SHIFT;
>> int ret = 0;
>>
>> jffs2_dbg(1, "%s()\n", __func__);
>>
>> - if (pageofs > inode->i_size) {
>> - /* Make new hole frag from old EOF to new page */
>> + if (pos > inode->i_size) {
>> + /* Make new hole frag from old EOF to new position */
>> struct jffs2_raw_inode ri;
>> struct jffs2_full_dnode *fn;
>> uint32_t alloc_len;
>>
>> - jffs2_dbg(1, "Writing new hole frag 0x%x-0x%x between current EOF and new page\n",
>> - (unsigned int)inode->i_size, pageofs);
>> + jffs2_dbg(1, "Writing new hole frag 0x%x-0x%x between current EOF and new position\n",
>> + (unsigned int)inode->i_size, (uint32_t)pos);
>>
>> ret = jffs2_reserve_space(c, sizeof(ri), &alloc_len,
>> ALLOC_NORMAL, JFFS2_SUMMARY_INODE_SIZE);
>> @@ -169,10 +168,10 @@ static int jffs2_write_begin(struct file *filp, struct address_space *mapping,
>> ri.mode = cpu_to_jemode(inode->i_mode);
>> ri.uid = cpu_to_je16(i_uid_read(inode));
>> ri.gid = cpu_to_je16(i_gid_read(inode));
>> - ri.isize = cpu_to_je32(max((uint32_t)inode->i_size, pageofs));
>> + ri.isize = cpu_to_je32((uint32_t)pos);
>> ri.atime = ri.ctime = ri.mtime = cpu_to_je32(JFFS2_NOW());
>> ri.offset = cpu_to_je32(inode->i_size);
>> - ri.dsize = cpu_to_je32(pageofs - inode->i_size);
>> + ri.dsize = cpu_to_je32((uint32_t)pos - inode->i_size);
>> ri.csize = cpu_to_je32(0);
>> ri.compr = JFFS2_COMPR_ZERO;
>> ri.node_crc = cpu_to_je32(crc32(0, &ri, sizeof(ri)-8));
>> @@ -202,7 +201,7 @@ static int jffs2_write_begin(struct file *filp, struct address_space *mapping,
>> goto out_err;
>> }
>> jffs2_complete_reservation(c);
>> - inode->i_size = pageofs;
>> + inode->i_size = pos;
>> mutex_unlock(&f->sem);
>> }
>>
>> --
>> 2.25.1
>>
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: Bonded multicast traffic causing packet loss when using DSA with Microchip KSZ9567 switch
From: Florian Fainelli @ 2022-07-25 21:35 UTC (permalink / raw)
To: Brian Hutchinson, netdev
Cc: andrew, Vladimir Oltean, woojung.huh, UNGLinuxDriver, j.vosburgh,
vfalico, andy, davem, kuba
In-Reply-To: <CAFZh4h-JVWt80CrQWkFji7tZJahMfOToUJQgKS5s0_=9zzpvYQ@mail.gmail.com>
On 7/25/22 08:12, Brian Hutchinson wrote:
> I'm experiencing large packet loss when using multicast with bonded
> DSA interfaces.
>
> I have the first two ports of a ksz9567 setup as individual network
> interfaces in device tree that shows up in the system as lan1 and lan2
> and I have those two interfaces bonded in an "active-backup" bond with
> the intent of having each slave interface go to redundant switches.
> I've tried connecting both interfaces to the same switch and also to
> separate switches that are then connected together. In the latter
> setup, if I disconnect the two switches I don't see the problem.
>
> The kernel bonding documentation says "active-backup" will work with
> any layer2 switch and doesn't need smart/managed switches configured
> in any particular way. I'm currently using dumb switches.
>
> I can readily reproduce the packet loss issue running iperf to
> generate multicast traffic.
>
> If I ping my board with the ksz9567 from a PC while iperf is
> generating multicast packets, I get tons of packet loss. If I run
> heavily loaded iperf tests that are not multicast I don't notice the
> packet loss problem.
>
> Here is ifconfig view of interfaces:
>
> bond1: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500 metric 1
> inet 192.168.1.6 netmask 255.255.255.0 broadcast 0.0.0.0
> inet6 fd1c:a799:6054:0:60e2:5ff:fe75:6716 prefixlen 64
> scopeid 0x0<global>
> inet6 fe80::60e2:5ff:fe75:6716 prefixlen 64 scopeid 0x20<link>
> ether 62:e2:05:75:67:16 txqueuelen 1000 (Ethernet)
> RX packets 1264782 bytes 84198600 (80.2 MiB)
> RX errors 0 dropped 40 overruns 0 frame 0
> TX packets 2466062 bytes 3705565532 (3.4 GiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>
> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1506 metric 1
> inet6 fe80::f21f:afff:fe6b:b218 prefixlen 64 scopeid 0x20<link>
> ether f0:1f:af:6b:b2:18 txqueuelen 1000 (Ethernet)
> RX packets 1264782 bytes 110759022 (105.6 MiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 2466097 bytes 3710503019 (3.4 GiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>
> lan1: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500 metric 1
> ether 62:e2:05:75:67:16 txqueuelen 1000 (Ethernet)
> RX packets 543771 bytes 37195218 (35.4 MiB)
> RX errors 0 dropped 20 overruns 0 frame 0
> TX packets 1058336 bytes 1593030865 (1.4 GiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>
> lan2: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500 metric 1
> ether 62:e2:05:75:67:16 txqueuelen 1000 (Ethernet)
> RX packets 721011 bytes 47003382 (44.8 MiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 1407726 bytes 2112534667 (1.9 GiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>
> lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 metric 1
> inet 127.0.0.1 netmask 255.0.0.0
> inet6 ::1 prefixlen 128 scopeid 0x10<host>
> loop txqueuelen 1000 (Local Loopback)
> RX packets 394 bytes 52052 (50.8 KiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 394 bytes 52052 (50.8 KiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>
> Is what I'm trying to do even valid with dumb switches or is the
> bonding documentation wrong/outdated regarding active-backup bonds not
> needing smart switches?
>
> I know there's probably not going to be anyone out there that can
> reproduce my setup to look at this problem but I'm willing to run
> whatever tests and provide all the info/feedback I can.
>
> I'm running 5.10.69 on iMX8MM with custom Linux OS based on Yocto
> Dunfell release.
>
> I know that DSA master interface eth0 is not to be accessed directly
> yet I see eth0 is getting an ipv6 address and I'm wondering if that
> could cause a scenario where networking stack could attempt to use
> eth0 directly for traffic.
This is a red herring, we cannot tell the network stack without much special casing that the DSA network device must only transport tagged traffic to/from the switch, so the IPv6 stack still happily generates a link local address for your adapter.
Any chance of getting the outputs of ethtool -S for lan1 and lan2, and eth0 so we could possibly glean something from the hardware maintained statistics?
--
Florian
^ permalink raw reply
* Re: Controlling device power management from terminal
From: Crt Mori @ 2022-07-25 21:35 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Linux Iio
In-Reply-To: <CAHp75VcrFQXW10vkLSB5Yh2D24zPzKR9FtfDU8bsSqDwD7=zjg@mail.gmail.com>
On Mon, 25 Jul 2022 at 23:27, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> On Mon, Jul 25, 2022 at 10:48 AM Crt Mori <cmo@melexis.com> wrote:
> >
> > Hi,
> > I am implementing the power saving modes for mlx90632 device driver
> > and while I have implemented routines for SET_RUNTIME_PM_OPS
> > (runtime_pm_suspend and runtime_pm_resume) I am not able to find out
> > how to trigger them from the terminal.
> >
> > It could be that my driver code for power management implementation is
> > incomplete and I need to initialize something more.
> >
> > Maybe it is helpful, but the power submodule of the device contains below files:
> >
> > $ ls -al /sys/bus/iio/devices/iio\:device0/power
> > total 0
> > drwxrwxr-x 2 root gpio 0 Apr 6 14:17 .
> > drwxrwxr-x 3 root gpio 0 Apr 6 14:17 ..
> > -rw-rw-r-- 1 root gpio 4096 Apr 6 14:17 async
> > -rw-rw-r-- 1 root gpio 4096 Apr 6 14:17 autosuspend_delay_ms
> > -rw-rw-r-- 1 root gpio 4096 Apr 6 14:18 control
> > -r--r--r-- 1 root gpio 4096 Apr 6 14:17 runtime_active_kids
> > -r--r--r-- 1 root gpio 4096 Apr 6 14:17 runtime_active_time
> > -r--r--r-- 1 root gpio 4096 Apr 6 14:17 runtime_enabled
> > -r--r--r-- 1 root gpio 4096 Apr 6 14:17 runtime_status
> > -r--r--r-- 1 root gpio 4096 Apr 6 14:17 runtime_suspended_time
> > -r--r--r-- 1 root gpio 4096 Apr 6 14:17 runtime_usage
> >
> > And control is already set to "auto" which according to documentation
> > should allow the PM.
>
> 'auto' should enable it. So, whenever the driver thinks it's a time to
> power off/on the device it will call the methods.
>
> You may hack a bit to enable autosuspend (which often is not a good
> idea for IIO sensors) and see it done automatically after some time.
So the idea is to wait? How would I enable autosuspend - by lowering
the autosusped_delay_ms? How does the driver decide that it is time to
power off/on?
Do I need something else enabled to have this done automatically?
Autosuspend is 5000 in my case which would mean 5 seconds, so I am
quite sure I waited that long and I did not see printk's from the
driver.
>
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply
* [kvm-unit-tests GIT PULL v2] x86: Fixes, cleanups, and new sub-tests
From: Sean Christopherson @ 2022-07-25 21:36 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm, Yang Weijiang, Manali Shukla, Jim Mattson
Attempt #2. Only difference is the addition of two patches[*] (effectively just
one when all is said and done) to fix the x2APIC+INIT+SIPI SVM test bug.
[*] https://lore.kernel.org/all/20220725201336.2158604-1-seanjc@google.com
The following changes since commit 7b2e41767bb8caf91972ee32e4ca85ec630584e2:
Merge branch 's390x-next-2022-07' into 'master' (2022-07-21 14:41:56 +0000)
are available in the Git repository at:
https://github.com/sean-jc/kvm-unit-tests.git tags/for_paolo
for you to fetch changes up to f7b730bcac4432f9ea239faeb963392d1854b9b0:
nVMX: Add subtest to verify VMXON succeeds/#UDs on good/bad CR0/CR4 (2022-07-25 13:20:29 -0700)
----------------------------------------------------------------
x86 fixes, cleanups, and new sub-tests:
- Bug fix for the VMX-preemption timer expiration test
- Refactor SVM tests to split out NPT tests
- Add tests for MCE banks to MSR test
- Add SMP Support for x86 UEFI tests
- x86: nVMX: Add VMXON #UD test (and exception cleanup)
- PMU cleanup and related nVMX bug fixes
----------------------------------------------------------------
Jim Mattson (1):
x86: VMX: Fix the VMX-preemption timer expiration test
Manali Shukla (5):
x86: nSVM: Extract core functionality of main() to helper run_svm_tests()
x86: Add flags to control behavior of set_mmu_range()
x86: nSVM: Build up the nested page table dynamically
x86: nSVM: Correct indentation for svm.c
x86: nSVM: Correct indentation for svm_tests.c
Sean Christopherson (23):
x86: nSVM: Move all nNPT test cases from svm_tests.c to a separate file.
x86: nSVM: Run non-NPT nSVM tests with PT_USER_MASK enabled
x86: nSVM: Add macros to create SVM's NPT tests, reduce boilerplate code
x86: msr: Take the MSR index and name separately in low level helpers
x86: msr: Add tests for MCE bank MSRs
x86: Use an explicit magic string to detect that dummy.efi passes
x86: apic: Play nice with x2APIC being enabled when getting "pre-boot" ID
x86: cstart64: Put APIC into xAPIC after loading TSS
x86: Rename ap_init() to bringup_aps()
x86: Add ap_online() to consolidate final "AP is alive!" code
x86: Use BIT() to define architectural bits
x86: Replace spaces with tables in processor.h
x86: Use "safe" terminology instead of "checking"
x86: Use "safe" helpers to implement unsafe CRs accessors
x86: Provide result of RDMSR from "safe" variant
nVMX: Check the results of VMXON/VMXOFF in feature control test
nVMX: Check result of VMXON in INIT/SIPI tests
nVMX: Wrap VMXON in ASM_TRY(), a.k.a. in exception fixup
nVMX: Simplify test_vmxon() by returning directly on failure
x86: Drop cpuid_osxsave(), just use this_cpu_has(X86_FEATURE_OSXSAVE)
nVMX: Move wrappers of this_cpu_has() to nVMX's VM-Exit test
nVMX: Rename monitor_support() to this_cpu_has_mwait(), drop #define
nVMX: Add subtest to verify VMXON succeeds/#UDs on good/bad CR0/CR4
Varad Gautam (10):
x86: Share realmode trampoline between i386 and x86_64
x86: Move ap_init() to smp.c
x86: Move load_idt() to desc.c
x86: desc: Split IDT entry setup into a generic helper
x86: Move load_gdt_tss() to desc.c
x86: efi: Provide a stack within testcase memory
x86: efi: Provide percpu storage
x86: Move 32-bit => 64-bit transition code to trampolines.S
x86: efi, smp: Transition APs from 16-bit to 32-bit mode
x86: Provide a common 64-bit AP entrypoint for EFI and non-EFI
Yang Weijiang (4):
x86: nVMX: Use report_skip() to print messages when VMX tests are skipped
x86: Use helpers to fetch supported perf capabilities
x86: Skip perf related tests when platform cannot support
x86: Check platform pmu capabilities before run lbr tests
lib/alloc_page.h | 3 +
lib/x86/apic.c | 16 +-
lib/x86/asm/setup.h | 3 +
lib/x86/desc.c | 46 +-
lib/x86/desc.h | 5 +-
lib/x86/processor.h | 455 +++++++++++--------
lib/x86/setup.c | 81 +++-
lib/x86/smp.c | 150 ++++++-
lib/x86/smp.h | 11 +
lib/x86/vm.c | 22 +-
lib/x86/vm.h | 10 +
scripts/runtime.bash | 2 +-
x86/Makefile.common | 2 +
x86/Makefile.x86_64 | 2 +
x86/access.c | 8 +-
x86/cstart.S | 48 +-
x86/cstart64.S | 127 +-----
x86/dummy.c | 8 +
x86/efi/crt0-efi-x86_64.S | 3 +
x86/efi/efistart64.S | 79 ++--
x86/la57.c | 2 +-
x86/msr.c | 113 ++++-
x86/pcid.c | 28 +-
x86/pmu.c | 116 ++---
x86/pmu_lbr.c | 35 +-
x86/rdpru.c | 4 +-
x86/svm.c | 219 ++++-----
x86/svm.h | 5 +-
x86/svm_npt.c | 380 ++++++++++++++++
x86/svm_tests.c | 3365 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------------------------------------------------------------
x86/trampolines.S | 129 ++++++
x86/unittests.cfg | 6 +
x86/vmexit.c | 12 +-
x86/vmx.c | 141 ++++--
x86/vmx.h | 31 +-
x86/vmx_tests.c | 136 +++---
x86/xsave.c | 31 +-
37 files changed, 3170 insertions(+), 2664 deletions(-)
create mode 100644 x86/svm_npt.c
create mode 100644 x86/trampolines.S
^ permalink raw reply
* Re: [PATCH v2] i2c: i2c-mux-gpmux: Add of_node_put() when breaking out of loop
From: Peter Rosin @ 2022-07-25 21:38 UTC (permalink / raw)
To: Liang He, linux-i2c
In-Reply-To: <20220722012401.1303609-1-windhl@126.com>
2022-07-22 at 03:24, Liang He wrote:
> In i2c_mux_probe(), we should call of_node_put() when breaking out
> of for_each_child_of_node() which will automatically increase and
> decrease the refcount.
>
> Fixes: ac8498f0ce53 ("i2c: i2c-mux-gpmux: new driver")
> Signed-off-by: Liang He <windhl@126.com>
Acked-by: Peter Rosin <peda@axentia.se>
Cheers,
Peter
> ---
> changelog:
>
> v2: make a correct patch pointed out by Peter
> v1: https://lore.kernel.org/all/20220721081202.1300071-1-windhl@126.com/
>
> drivers/i2c/muxes/i2c-mux-gpmux.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/i2c/muxes/i2c-mux-gpmux.c b/drivers/i2c/muxes/i2c-mux-gpmux.c
> index d3acd8d66c32..33024acaac02 100644
> --- a/drivers/i2c/muxes/i2c-mux-gpmux.c
> +++ b/drivers/i2c/muxes/i2c-mux-gpmux.c
> @@ -134,6 +134,7 @@ static int i2c_mux_probe(struct platform_device *pdev)
> return 0;
>
> err_children:
> + of_node_put(child);
> i2c_mux_del_adapters(muxc);
> err_parent:
> i2c_put_adapter(parent);
^ permalink raw reply
* Re: [iptables PATCH] iptables: xshared: Ouptut '--' in the opt field in ipv6's fake mode
From: Florian Westphal @ 2022-07-25 21:39 UTC (permalink / raw)
To: Erik Skultety; +Cc: netfilter-devel
In-Reply-To: <bb391c763171f0c5511f73e383e1b2e6a53e2014.1658322396.git.eskultet@redhat.com>
Erik Skultety <eskultet@redhat.com> wrote:
> The fact that the 'opt' table field reports spaces instead of '--' for
> IPv6 as it would have been the case with IPv4 has a bit of an
> unfortunate side effect that it completely confuses the 'jc' JSON
> formatter tool (which has an iptables formatter module).
> Consider:
> # ip6tables -L test
> Chain test (0 references)
> target prot opt source destination
> ACCEPT all a:b:c:: anywhere MAC01:02:03:04:05:06
>
> Then:
> # ip6tables -L test | jc --iptables
> [{"chain":"test",
> "rules":[
> {"target":"ACCEPT",
> "prot":"all",
> "opt":"a:b:c::",
> "source":"anywhere",
> "destination":"MAC01:02:03:04:05:06"
> }]
> }]
>
> which as you can see is wrong simply because whitespaces are considered
> as a column delimiter.
Applied. I amended the commit message to include a Link to this thread
on lore.kernel.org so in case something else breaks because of this
change.
^ permalink raw reply
* Re: [RFC v3 15/17] perf kwork: Add irq trace bpf support
From: Arnaldo Carvalho de Melo @ 2022-07-25 21:39 UTC (permalink / raw)
To: Yang Jihong
Cc: peterz, mingo, mark.rutland, alexander.shishkin, jolsa, namhyung,
pc, linux-kernel, linux-perf-users
In-Reply-To: <20220709015033.38326-16-yangjihong1@huawei.com>
Em Sat, Jul 09, 2022 at 09:50:31AM +0800, Yang Jihong escreveu:
> Implements irq trace bpf function.
>
> Test cases:
> Trace irq without filter:
>
> # perf kwork -k irq rep -b
> Starting trace, Hit <Ctrl+C> to stop and report
That is cool, works like a charm :-) Lemme go back testing the rest...
- Arnaldo
> ^C
> Kwork Name | Cpu | Total Runtime | Count | Max runtime | Max runtime start | Max runtime end |
> --------------------------------------------------------------------------------------------------------------------------------
> virtio0-requests:25 | 0000 | 31.026 ms | 285 | 1.493 ms | 110326.049963 s | 110326.051456 s |
> eth0:10 | 0002 | 7.875 ms | 96 | 1.429 ms | 110313.916835 s | 110313.918264 s |
> ata_piix:14 | 0002 | 2.510 ms | 28 | 0.396 ms | 110331.367987 s | 110331.368383 s |
> --------------------------------------------------------------------------------------------------------------------------------
>
> Trace irq with cpu filter:
>
> # perf kwork -k irq rep -b -C 0
> Starting trace, Hit <Ctrl+C> to stop and report
> ^C
> Kwork Name | Cpu | Total Runtime | Count | Max runtime | Max runtime start | Max runtime end |
> --------------------------------------------------------------------------------------------------------------------------------
> virtio0-requests:25 | 0000 | 34.288 ms | 282 | 2.061 ms | 110358.078968 s | 110358.081029 s |
> --------------------------------------------------------------------------------------------------------------------------------
>
> Trace irq with name filter:
>
> # perf kwork -k irq rep -b -n eth0
> Starting trace, Hit <Ctrl+C> to stop and report
> ^C
> Kwork Name | Cpu | Total Runtime | Count | Max runtime | Max runtime start | Max runtime end |
> --------------------------------------------------------------------------------------------------------------------------------
> eth0:10 | 0002 | 2.184 ms | 21 | 0.572 ms | 110386.541699 s | 110386.542271 s |
> --------------------------------------------------------------------------------------------------------------------------------
>
> Trace irq with summary:
>
> # perf kwork -k irq rep -b -S
> Starting trace, Hit <Ctrl+C> to stop and report
> ^C
> Kwork Name | Cpu | Total Runtime | Count | Max runtime | Max runtime start | Max runtime end |
> --------------------------------------------------------------------------------------------------------------------------------
> virtio0-requests:25 | 0000 | 42.923 ms | 285 | 1.181 ms | 110418.128867 s | 110418.130049 s |
> eth0:10 | 0002 | 2.085 ms | 20 | 0.668 ms | 110416.002935 s | 110416.003603 s |
> ata_piix:14 | 0002 | 0.970 ms | 4 | 0.656 ms | 110424.034482 s | 110424.035138 s |
> --------------------------------------------------------------------------------------------------------------------------------
> Total count : 309
> Total runtime (msec) : 45.977 (0.003% load average)
> Total time span (msec) : 17017.655
> --------------------------------------------------------------------------------------------------------------------------------
>
> Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
> ---
> tools/perf/util/bpf_kwork.c | 40 +++++-
> tools/perf/util/bpf_skel/kwork_trace.bpf.c | 150 +++++++++++++++++++++
> 2 files changed, 189 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/bpf_kwork.c b/tools/perf/util/bpf_kwork.c
> index 433bfadd3af1..08252fcda1a4 100644
> --- a/tools/perf/util/bpf_kwork.c
> +++ b/tools/perf/util/bpf_kwork.c
> @@ -62,9 +62,47 @@ void perf_kwork__trace_finish(void)
> skel->bss->enabled = 0;
> }
>
> +static int get_work_name_from_map(struct work_key *key, char **ret_name)
> +{
> + char name[MAX_KWORKNAME] = { 0 };
> + int fd = bpf_map__fd(skel->maps.perf_kwork_names);
> +
> + *ret_name = NULL;
> +
> + if (fd < 0) {
> + pr_debug("Invalid names map fd\n");
> + return 0;
> + }
> +
> + if ((bpf_map_lookup_elem(fd, key, name) == 0) && (strlen(name) != 0)) {
> + *ret_name = strdup(name);
> + if (*ret_name == NULL) {
> + pr_err("Failed to copy work name\n");
> + return -1;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void irq_load_prepare(struct perf_kwork *kwork)
> +{
> + if (kwork->report == KWORK_REPORT_RUNTIME) {
> + bpf_program__set_autoload(
> + skel->progs.report_irq_handler_entry, true);
> + bpf_program__set_autoload(
> + skel->progs.report_irq_handler_exit, true);
> + }
> +}
> +
> +static struct kwork_class_bpf kwork_irq_bpf = {
> + .load_prepare = irq_load_prepare,
> + .get_work_name = get_work_name_from_map,
> +};
> +
> static struct kwork_class_bpf *
> kwork_class_bpf_supported_list[KWORK_CLASS_MAX] = {
> - [KWORK_CLASS_IRQ] = NULL,
> + [KWORK_CLASS_IRQ] = &kwork_irq_bpf,
> [KWORK_CLASS_SOFTIRQ] = NULL,
> [KWORK_CLASS_WORKQUEUE] = NULL,
> };
> diff --git a/tools/perf/util/bpf_skel/kwork_trace.bpf.c b/tools/perf/util/bpf_skel/kwork_trace.bpf.c
> index 36112be831e3..1925407d1c16 100644
> --- a/tools/perf/util/bpf_skel/kwork_trace.bpf.c
> +++ b/tools/perf/util/bpf_skel/kwork_trace.bpf.c
> @@ -71,4 +71,154 @@ int enabled = 0;
> int has_cpu_filter = 0;
> int has_name_filter = 0;
>
> +static __always_inline int local_strncmp(const char *s1,
> + unsigned int sz, const char *s2)
> +{
> + int ret = 0;
> + unsigned int i;
> +
> + for (i = 0; i < sz; i++) {
> + ret = (unsigned char)s1[i] - (unsigned char)s2[i];
> + if (ret || !s1[i] || !s2[i])
> + break;
> + }
> +
> + return ret;
> +}
> +
> +static __always_inline int trace_event_match(struct work_key *key, char *name)
> +{
> + __u8 *cpu_val;
> + char *name_val;
> + __u32 zero = 0;
> + __u32 cpu = bpf_get_smp_processor_id();
> +
> + if (!enabled)
> + return 0;
> +
> + if (has_cpu_filter) {
> + cpu_val = bpf_map_lookup_elem(&perf_kwork_cpu_filter, &cpu);
> + if (!cpu_val)
> + return 0;
> + }
> +
> + if (has_name_filter && (name != NULL)) {
> + name_val = bpf_map_lookup_elem(&perf_kwork_name_filter, &zero);
> + if (name_val &&
> + (local_strncmp(name_val, MAX_KWORKNAME, name) != 0)) {
> + return 0;
> + }
> + }
> +
> + return 1;
> +}
> +
> +static __always_inline void do_update_time(void *map, struct work_key *key,
> + __u64 time_start, __u64 time_end)
> +{
> + struct report_data zero, *data;
> + __s64 delta = time_end - time_start;
> +
> + if (delta < 0)
> + return;
> +
> + data = bpf_map_lookup_elem(map, key);
> + if (!data) {
> + __builtin_memset(&zero, 0, sizeof(zero));
> + bpf_map_update_elem(map, key, &zero, BPF_NOEXIST);
> + data = bpf_map_lookup_elem(map, key);
> + if (!data)
> + return;
> + }
> +
> + if ((delta > data->max_time) ||
> + (data->max_time == 0)) {
> + data->max_time = delta;
> + data->max_time_start = time_start;
> + data->max_time_end = time_end;
> + }
> +
> + data->total_time += delta;
> + data->nr++;
> +}
> +
> +static __always_inline void do_update_timestart(void *map, struct work_key *key)
> +{
> + __u64 ts = bpf_ktime_get_ns();
> +
> + bpf_map_update_elem(map, key, &ts, BPF_ANY);
> +}
> +
> +static __always_inline void do_update_timeend(void *report_map, void *time_map,
> + struct work_key *key)
> +{
> + __u64 *time = bpf_map_lookup_elem(time_map, key);
> +
> + if (time) {
> + bpf_map_delete_elem(time_map, key);
> + do_update_time(report_map, key, *time, bpf_ktime_get_ns());
> + }
> +}
> +
> +static __always_inline void do_update_name(void *map,
> + struct work_key *key, char *name)
> +{
> + if (!bpf_map_lookup_elem(map, key))
> + bpf_map_update_elem(map, key, name, BPF_ANY);
> +}
> +
> +static __always_inline int update_timestart_and_name(void *time_map,
> + void *names_map,
> + struct work_key *key,
> + char *name)
> +{
> + if (!trace_event_match(key, name))
> + return 0;
> +
> + do_update_timestart(time_map, key);
> + do_update_name(names_map, key, name);
> +
> + return 0;
> +}
> +
> +static __always_inline int update_timeend(void *report_map,
> + void *time_map, struct work_key *key)
> +{
> + if (!trace_event_match(key, NULL))
> + return 0;
> +
> + do_update_timeend(report_map, time_map, key);
> +
> + return 0;
> +}
> +
> +SEC("tracepoint/irq/irq_handler_entry")
> +int report_irq_handler_entry(struct trace_event_raw_irq_handler_entry *ctx)
> +{
> + char name[MAX_KWORKNAME];
> + struct work_key key = {
> + .type = KWORK_CLASS_IRQ,
> + .cpu = bpf_get_smp_processor_id(),
> + .id = (__u64)ctx->irq,
> + };
> + void *name_addr = (void *)ctx + (ctx->__data_loc_name & 0xffff);
> +
> + bpf_probe_read_kernel_str(name, sizeof(name), name_addr);
> +
> + return update_timestart_and_name(&perf_kwork_time,
> + &perf_kwork_names, &key, name);
> +}
> +
> +SEC("tracepoint/irq/irq_handler_exit")
> +int report_irq_handler_exit(struct trace_event_raw_irq_handler_exit *ctx)
> +{
> + struct work_key key = {
> + .type = KWORK_CLASS_IRQ,
> + .cpu = bpf_get_smp_processor_id(),
> + .id = (__u64)ctx->irq,
> + };
> +
> + return update_timeend(&perf_kwork_report, &perf_kwork_time, &key);
> +}
> +
> char LICENSE[] SEC("license") = "Dual BSD/GPL";
> --
> 2.30.GIT
--
- Arnaldo
^ permalink raw reply
* Re: [PATCH net] net: dsa: fix bonding with ARP monitoring by updating trans_start manually
From: Jonathan Toppins @ 2022-07-25 21:39 UTC (permalink / raw)
To: Vladimir Oltean, Jakub Kicinski
Cc: netdev@vger.kernel.org, David S. Miller, Eric Dumazet,
Paolo Abeni, Andrew Lunn, Vivien Didelot, Florian Fainelli,
Jay Vosburgh, Veaceslav Falico, Hangbin Liu, Brian Hutchinson
In-Reply-To: <20220725203125.kaxokkhyrb4aerp5@skbuf>
On 7/25/22 16:31, Vladimir Oltean wrote:
> Hi Jakub,
>
> On Sat, Jul 16, 2022 at 04:33:38PM -0700, Jakub Kicinski wrote:
>> On Sat, 16 Jul 2022 13:30:10 +0000 Vladimir Oltean wrote:
>>> I would need some assistance from Jay or other people more familiar with
>>> bonding to do that. I'm not exactly clear which packets the bonding
>>> driver wants to check they have been transmitted in the last interval:
>>> ARP packets? any packets?
>>
>> And why - stack has queued a packet to the driver, how is that useful
>> to assess the fact that the link is up? Can bonding check instead
>> whether any queue is running? Or maybe the whole thing is just a remnant
>> of times before the centralized watchdog tx and should be dropped?
>
> Yes, indeed, why? I don't know.
>
>>> With DSA and switchdev drivers in general,
>>> they have an offloaded forwarding path as well, so expect that what you
>>> get through ndo_get_stats64 may also report packets which egressed a
>>> physical port but weren't originated by the network stack.
>>> I simply don't know what is a viable substitute for dev_trans_start()
>>> because I don't understand very well what it intends to capture.
>>
>> Looking thru the code I stumbled on the implementation of
>> dev_trans_start() - it already takes care of some upper devices.
>> Adding DSA handling there would offend my sensibilities slightly
>> less, if you want to do that. At least it's not on the fast path.
>
> How are your sensibilities feeling about this change?
>
> diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
> index cc6eabee2830..b844eb0bde7e 100644
> --- a/net/sched/sch_generic.c
> +++ b/net/sched/sch_generic.c
> @@ -427,20 +427,43 @@ void __qdisc_run(struct Qdisc *q)
>
> unsigned long dev_trans_start(struct net_device *dev)
> {
> + struct net_device *lower;
> + struct list_head *iter;
> unsigned long val, res;
> + bool have_lowers;
> unsigned int i;
>
> - if (is_vlan_dev(dev))
> - dev = vlan_dev_real_dev(dev);
> - else if (netif_is_macvlan(dev))
> - dev = macvlan_dev_real_dev(dev);
> + rcu_read_lock();
> +
> + /* Stacked network interfaces usually have NETIF_F_LLTX so
> + * netdev_start_xmit() -> txq_trans_update() fails to do anything,
> + * because they don't lock the TX queue. However, layers such as the
> + * bonding arp monitor may still use dev_trans_start() on slave
> + * interfaces such as vlan, macvlan, DSA (or potentially stacked
> + * combinations of the above). In this case, walk the adjacency lists
> + * all the way down, hoping that the lower-most device won't have
> + * NETIF_F_LLTX.
> + */
I am not sure this assumption holds for virtual devices like veth unless
the virtual interfaces are updated to modify trans_start, see
e66e257a5d83 ("veth: Add updating of trans_start")
And not all the virtual interfaces update trans_start iirc.
> + do {
> + have_lowers = false;
> +
> + netdev_for_each_lower_dev(dev, lower, iter) {
> + have_lowers = true;
> + dev = lower;
> + break;
> + }
> + } while (have_lowers);
> +
> res = READ_ONCE(netdev_get_tx_queue(dev, 0)->trans_start);
> +
> for (i = 1; i < dev->num_tx_queues; i++) {
> val = READ_ONCE(netdev_get_tx_queue(dev, i)->trans_start);
> if (val && time_after(val, res))
> res = val;
> }
>
> + rcu_read_unlock();
> +
> return res;
> }
> EXPORT_SYMBOL(dev_trans_start);
>
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: drop dependency on <asm/machdep.h> in archrandom.h
From: Andy Shevchenko @ 2022-07-25 21:39 UTC (permalink / raw)
To: Yury Norov
Cc: Linux Kernel Mailing List, Andy Shevchenko, Rasmus Villemoes,
open list:LINUX FOR POWERPC PA SEMI PWRFICIENT, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Stephen Rothwell
In-Reply-To: <Yt7CJj8r3eo05pKd@yury-laptop>
On Mon, Jul 25, 2022 at 6:19 PM Yury Norov <yury.norov@gmail.com> wrote:
> On Mon, Jul 25, 2022 at 09:28:12AM +0200, Andy Shevchenko wrote:
> > On Sun, Jul 24, 2022 at 12:19 AM Yury Norov <yury.norov@gmail.com> wrote:
...
> > > EXPORT_SYMBOL_GPL(pm_power_off);
> >
> > ^^^ (Note this and read below)
> >
> > ...
> >
> > > +EXPORT_SYMBOL(arch_get_random_seed_long);
> >
> > It can't be like this. Brief browsing of the callees shows that.
>
> Is my understanding correct that you're suggesting to make it GPL?
>
> ppc_md is exported with EXPORT_SYMBOL(), and the function is in header,
> so it's available for non-GPL code now. I don't want to change it.
The symbols your function calls are GPL. As far as I understand (not a
lawyer!) it logically one may not call GPL and pretend to be non-GPL.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: drop dependency on <asm/machdep.h> in archrandom.h
From: Andy Shevchenko @ 2022-07-25 21:39 UTC (permalink / raw)
To: Yury Norov
Cc: Stephen Rothwell, Rasmus Villemoes, Linux Kernel Mailing List,
Paul Mackerras, Andy Shevchenko,
open list:LINUX FOR POWERPC PA SEMI PWRFICIENT
In-Reply-To: <Yt7CJj8r3eo05pKd@yury-laptop>
On Mon, Jul 25, 2022 at 6:19 PM Yury Norov <yury.norov@gmail.com> wrote:
> On Mon, Jul 25, 2022 at 09:28:12AM +0200, Andy Shevchenko wrote:
> > On Sun, Jul 24, 2022 at 12:19 AM Yury Norov <yury.norov@gmail.com> wrote:
...
> > > EXPORT_SYMBOL_GPL(pm_power_off);
> >
> > ^^^ (Note this and read below)
> >
> > ...
> >
> > > +EXPORT_SYMBOL(arch_get_random_seed_long);
> >
> > It can't be like this. Brief browsing of the callees shows that.
>
> Is my understanding correct that you're suggesting to make it GPL?
>
> ppc_md is exported with EXPORT_SYMBOL(), and the function is in header,
> so it's available for non-GPL code now. I don't want to change it.
The symbols your function calls are GPL. As far as I understand (not a
lawyer!) it logically one may not call GPL and pretend to be non-GPL.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [Cluster-devel] [PATCHv2 dlm/next 1/2] fs: dlm: fix race in lowcomms
From: Alexander Aring @ 2022-07-25 21:41 UTC (permalink / raw)
To: cluster-devel.redhat.com
In-Reply-To: <20220725195322.857226-2-aahringo@redhat.com>
Hi,
On Mon, Jul 25, 2022 at 3:53 PM Alexander Aring <aahringo@redhat.com> wrote:
>
> This patch fixes a race between queue_work() in
> _dlm_lowcomms_commit_msg() and srcu_read_unlock(). The queue_work() can
> take the final reference of a dlm_msg and so msg->idx can contain
> garbage which is signaled by the following warning:
>
> [ 676.237050] ------------[ cut here ]------------
> [ 676.237052] WARNING: CPU: 0 PID: 1060 at include/linux/srcu.h:189 dlm_lowcomms_commit_msg+0x41/0x50
> [ 676.238945] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common iTCO_wdt iTCO_vendor_support qxl kvm_intel drm_ttm_helper vmw_vsock_virtio_transport kvm vmw_vsock_virtio_transport_common ttm irqbypass crc32_pclmul joydev crc32c_intel serio_raw drm_kms_helper vsock virtio_scsi virtio_console virtio_balloon snd_pcm drm syscopyarea sysfillrect sysimgblt snd_timer fb_sys_fops i2c_i801 lpc_ich snd i2c_smbus soundcore pcspkr
> [ 676.244227] CPU: 0 PID: 1060 Comm: lock_torture_wr Not tainted 5.19.0-rc3+ #1546
> [ 676.245216] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014
> [ 676.246460] RIP: 0010:dlm_lowcomms_commit_msg+0x41/0x50
> [ 676.247132] Code: fe ff ff ff 75 24 48 c7 c6 bd 0f 49 bb 48 c7 c7 38 7c 01 bd e8 00 e7 ca ff 89 de 48 c7 c7 60 78 01 bd e8 42 3d cd ff 5b 5d c3 <0f> 0b eb d8 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48
> [ 676.249253] RSP: 0018:ffffa401c18ffc68 EFLAGS: 00010282
> [ 676.249855] RAX: 0000000000000001 RBX: 00000000ffff8b76 RCX: 0000000000000006
> [ 676.250713] RDX: 0000000000000000 RSI: ffffffffbccf3a10 RDI: ffffffffbcc7b62e
> [ 676.251610] RBP: ffffa401c18ffc70 R08: 0000000000000001 R09: 0000000000000001
> [ 676.252481] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000005
> [ 676.253421] R13: ffff8b76786ec370 R14: ffff8b76786ec370 R15: ffff8b76786ec480
> [ 676.254257] FS: 0000000000000000(0000) GS:ffff8b7777800000(0000) knlGS:0000000000000000
> [ 676.255239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 676.255897] CR2: 00005590205d88b8 CR3: 000000017656c003 CR4: 0000000000770ee0
> [ 676.256734] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 676.257567] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 676.258397] PKRU: 55555554
> [ 676.258729] Call Trace:
> [ 676.259063] <TASK>
> [ 676.259354] dlm_midcomms_commit_mhandle+0xcc/0x110
> [ 676.259964] queue_bast+0x8b/0xb0
> [ 676.260423] grant_pending_locks+0x166/0x1b0
> [ 676.261007] _unlock_lock+0x75/0x90
> [ 676.261469] unlock_lock.isra.57+0x62/0xa0
> [ 676.262009] dlm_unlock+0x21e/0x330
> [ 676.262457] ? lock_torture_stats+0x80/0x80 [dlm_locktorture]
> [ 676.263183] torture_unlock+0x5a/0x90 [dlm_locktorture]
> [ 676.263815] ? preempt_count_sub+0xba/0x100
> [ 676.264361] ? complete+0x1d/0x60
> [ 676.264777] lock_torture_writer+0xb8/0x150 [dlm_locktorture]
> [ 676.265555] kthread+0x10a/0x130
> [ 676.266007] ? kthread_complete_and_exit+0x20/0x20
> [ 676.266616] ret_from_fork+0x22/0x30
> [ 676.267097] </TASK>
> [ 676.267381] irq event stamp: 9579855
> [ 676.267824] hardirqs last enabled at (9579863): [<ffffffffbb14e6f8>] __up_console_sem+0x58/0x60
> [ 676.268896] hardirqs last disabled at (9579872): [<ffffffffbb14e6dd>] __up_console_sem+0x3d/0x60
> [ 676.270008] softirqs last enabled at (9579798): [<ffffffffbc200349>] __do_softirq+0x349/0x4c7
> [ 676.271438] softirqs last disabled at (9579897): [<ffffffffbb0d54c0>] irq_exit_rcu+0xb0/0xf0
> [ 676.272796] ---[ end trace 0000000000000000 ]---
>
> I reproduced this warning with dlm_locktorture test which is currently
> not upstream. However this patch fix the issue by make a additional
> refcount between dlm_lowcomms_new_msg() and dlm_lowcomms_commit_msg().
> In case of the race the kref_put() in dlm_lowcomms_commit_msg() will be
> the final put.
>
> Signed-off-by: Alexander Aring <aahringo@redhat.com>
grml, now I forgot in this patch Cc: stable and fixes-tag. Will send v3. Sorry.
- Alex
^ permalink raw reply
* Re: [PATCHv2 dlm/next 1/2] fs: dlm: fix race in lowcomms
From: Alexander Aring @ 2022-07-25 21:41 UTC (permalink / raw)
To: David Teigland; +Cc: cluster-devel, stable
In-Reply-To: <20220725195322.857226-2-aahringo@redhat.com>
Hi,
On Mon, Jul 25, 2022 at 3:53 PM Alexander Aring <aahringo@redhat.com> wrote:
>
> This patch fixes a race between queue_work() in
> _dlm_lowcomms_commit_msg() and srcu_read_unlock(). The queue_work() can
> take the final reference of a dlm_msg and so msg->idx can contain
> garbage which is signaled by the following warning:
>
> [ 676.237050] ------------[ cut here ]------------
> [ 676.237052] WARNING: CPU: 0 PID: 1060 at include/linux/srcu.h:189 dlm_lowcomms_commit_msg+0x41/0x50
> [ 676.238945] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common iTCO_wdt iTCO_vendor_support qxl kvm_intel drm_ttm_helper vmw_vsock_virtio_transport kvm vmw_vsock_virtio_transport_common ttm irqbypass crc32_pclmul joydev crc32c_intel serio_raw drm_kms_helper vsock virtio_scsi virtio_console virtio_balloon snd_pcm drm syscopyarea sysfillrect sysimgblt snd_timer fb_sys_fops i2c_i801 lpc_ich snd i2c_smbus soundcore pcspkr
> [ 676.244227] CPU: 0 PID: 1060 Comm: lock_torture_wr Not tainted 5.19.0-rc3+ #1546
> [ 676.245216] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014
> [ 676.246460] RIP: 0010:dlm_lowcomms_commit_msg+0x41/0x50
> [ 676.247132] Code: fe ff ff ff 75 24 48 c7 c6 bd 0f 49 bb 48 c7 c7 38 7c 01 bd e8 00 e7 ca ff 89 de 48 c7 c7 60 78 01 bd e8 42 3d cd ff 5b 5d c3 <0f> 0b eb d8 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48
> [ 676.249253] RSP: 0018:ffffa401c18ffc68 EFLAGS: 00010282
> [ 676.249855] RAX: 0000000000000001 RBX: 00000000ffff8b76 RCX: 0000000000000006
> [ 676.250713] RDX: 0000000000000000 RSI: ffffffffbccf3a10 RDI: ffffffffbcc7b62e
> [ 676.251610] RBP: ffffa401c18ffc70 R08: 0000000000000001 R09: 0000000000000001
> [ 676.252481] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000005
> [ 676.253421] R13: ffff8b76786ec370 R14: ffff8b76786ec370 R15: ffff8b76786ec480
> [ 676.254257] FS: 0000000000000000(0000) GS:ffff8b7777800000(0000) knlGS:0000000000000000
> [ 676.255239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 676.255897] CR2: 00005590205d88b8 CR3: 000000017656c003 CR4: 0000000000770ee0
> [ 676.256734] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 676.257567] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 676.258397] PKRU: 55555554
> [ 676.258729] Call Trace:
> [ 676.259063] <TASK>
> [ 676.259354] dlm_midcomms_commit_mhandle+0xcc/0x110
> [ 676.259964] queue_bast+0x8b/0xb0
> [ 676.260423] grant_pending_locks+0x166/0x1b0
> [ 676.261007] _unlock_lock+0x75/0x90
> [ 676.261469] unlock_lock.isra.57+0x62/0xa0
> [ 676.262009] dlm_unlock+0x21e/0x330
> [ 676.262457] ? lock_torture_stats+0x80/0x80 [dlm_locktorture]
> [ 676.263183] torture_unlock+0x5a/0x90 [dlm_locktorture]
> [ 676.263815] ? preempt_count_sub+0xba/0x100
> [ 676.264361] ? complete+0x1d/0x60
> [ 676.264777] lock_torture_writer+0xb8/0x150 [dlm_locktorture]
> [ 676.265555] kthread+0x10a/0x130
> [ 676.266007] ? kthread_complete_and_exit+0x20/0x20
> [ 676.266616] ret_from_fork+0x22/0x30
> [ 676.267097] </TASK>
> [ 676.267381] irq event stamp: 9579855
> [ 676.267824] hardirqs last enabled at (9579863): [<ffffffffbb14e6f8>] __up_console_sem+0x58/0x60
> [ 676.268896] hardirqs last disabled at (9579872): [<ffffffffbb14e6dd>] __up_console_sem+0x3d/0x60
> [ 676.270008] softirqs last enabled at (9579798): [<ffffffffbc200349>] __do_softirq+0x349/0x4c7
> [ 676.271438] softirqs last disabled at (9579897): [<ffffffffbb0d54c0>] irq_exit_rcu+0xb0/0xf0
> [ 676.272796] ---[ end trace 0000000000000000 ]---
>
> I reproduced this warning with dlm_locktorture test which is currently
> not upstream. However this patch fix the issue by make a additional
> refcount between dlm_lowcomms_new_msg() and dlm_lowcomms_commit_msg().
> In case of the race the kref_put() in dlm_lowcomms_commit_msg() will be
> the final put.
>
> Signed-off-by: Alexander Aring <aahringo@redhat.com>
grml, now I forgot in this patch Cc: stable and fixes-tag. Will send v3. Sorry.
- Alex
^ permalink raw reply
* Re: [PATCH] kvm: x86: mmu: Drop the need_remote_flush() function
From: Sean Christopherson @ 2022-07-25 21:43 UTC (permalink / raw)
To: David Matlack; +Cc: Junaid Shahid, kvm, pbonzini
In-Reply-To: <Yt7VNt2bsdNtyqZl@google.com>
On Mon, Jul 25, 2022, David Matlack wrote:
> On Fri, Jul 22, 2022 at 07:43:16PM -0700, Junaid Shahid wrote:
> > This is only used by kvm_mmu_pte_write(), which no longer actually
> > creates the new SPTE and instead just clears the old SPTE. So we
> > just need to check if the old SPTE was shadow-present instead of
> > calling need_remote_flush(). Hence we can drop this function. It was
> > incomplete anyway as it didn't take access-tracking into account.
> >
> > This patch should not result in any functional change.
>
> Even if we don't assume anything about the new SPTE, this commit flushes
> TLBs in a superset of the current cases. So this change should
> definitely be safe.
>
> And then if we assume new SPTE is 0 (which it should be), I agree this
> should not result in any functional change.
Nit for posterity, zapped SPTEs don't necessarily have to be '0', e.g. KVM is
more than likely going to use 0x80000000_00000000 as the "zero" value for TDP MMU
SPTEs so that the SUPPRESS_VE is set for "zero"-initialized SPTEs (TDX requires
EPT Violation #VEs be enabled).
> Reviewed-by: David Matlack <dmatlack@google.com>
Reviewed-by: Sean Christopherson <seanjc@google.com>
^ permalink raw reply
* Re: [RFC v3 00/17] perf: Add perf kwork (using BPF skels)
From: Arnaldo Carvalho de Melo @ 2022-07-25 21:45 UTC (permalink / raw)
To: Yang Jihong
Cc: peterz, mingo, mark.rutland, alexander.shishkin, jolsa, namhyung,
pc, linux-kernel, linux-perf-users, Yonghong Song,
Andrii Nakryiko, Song Liu
In-Reply-To: <20220709015033.38326-1-yangjihong1@huawei.com>
Em Sat, Jul 09, 2022 at 09:50:16AM +0800, Yang Jihong escreveu:
> Sometimes, we need to analyze time properties of kernel work such as irq,
> softirq, and workqueue, including delay and running time of specific interrupts.
> Currently, these events have kernel tracepoints, but perf tool does not
> directly analyze the delay of these events
>
> The perf-kwork tool is used to trace time properties of kernel work
> (such as irq, softirq, and workqueue), including runtime, latency,
> and timehist, using the infrastructure in the perf tools to allow
> tracing extra targets
>
> We also use bpf trace to collect and filter data in kernel to solve
> problem of large perf data volume and extra file system interruptions.
Pushed out to tmp.perf/core, will continue reviewing and testing then
move to perf/core, thanks for the great work.
Its fantastic how the bpf skel infra is working well with tools/perf,
really great.
- Arnaldo
> Example usage:
>
> 1. Kwork record:
>
> # perf kwork record -- sleep 10
> [ perf record: Woken up 0 times to write data ]
> [ perf record: Captured and wrote 6.825 MB perf.data ]
>
> 2. Kwork report:
>
> # perf kwork report -S
>
> Kwork Name | Cpu | Total Runtime | Count | Max runtime | Max runtime start | Max runtime end |
> --------------------------------------------------------------------------------------------------------------------------------
> virtio0-requests:25 | 0000 | 1347.861 ms | 25049 | 1.417 ms | 121235.524083 s | 121235.525499 s |
> (s)TIMER:1 | 0005 | 151.033 ms | 2545 | 0.153 ms | 121237.454591 s | 121237.454744 s |
> (s)RCU:9 | 0005 | 117.254 ms | 2754 | 0.223 ms | 121239.461024 s | 121239.461246 s |
> (s)SCHED:7 | 0005 | 58.714 ms | 1773 | 0.075 ms | 121237.702345 s | 121237.702419 s |
> (s)RCU:9 | 0007 | 43.359 ms | 945 | 0.861 ms | 121237.702984 s | 121237.703845 s |
> (s)SCHED:7 | 0000 | 33.389 ms | 549 | 4.121 ms | 121235.521379 s | 121235.525499 s |
> (s)RCU:9 | 0002 | 21.419 ms | 484 | 0.281 ms | 121244.629001 s | 121244.629282 s |
> (w)mix_interrupt_randomness | 0000 | 21.047 ms | 391 | 1.016 ms | 121237.934008 s | 121237.935024 s |
> (s)SCHED:7 | 0007 | 19.903 ms | 570 | 0.065 ms | 121235.523360 s | 121235.523426 s |
> (s)RCU:9 | 0000 | 19.017 ms | 472 | 0.507 ms | 121244.634002 s | 121244.634510 s |
> ... <SNIP> ...
> (s)SCHED:7 | 0003 | 0.049 ms | 1 | 0.049 ms | 121240.018631 s | 121240.018680 s |
> (w)vmstat_update | 0003 | 0.046 ms | 1 | 0.046 ms | 121240.916200 s | 121240.916246 s |
> (s)RCU:9 | 0004 | 0.045 ms | 2 | 0.024 ms | 121235.522876 s | 121235.522900 s |
> (w)neigh_managed_work | 0001 | 0.044 ms | 1 | 0.044 ms | 121235.513929 s | 121235.513973 s |
> (w)vmstat_update | 0006 | 0.031 ms | 1 | 0.031 ms | 121245.673914 s | 121245.673945 s |
> (w)vmstat_update | 0004 | 0.028 ms | 1 | 0.028 ms | 121235.522743 s | 121235.522770 s |
> (w)wb_update_bandwidth_workfn | 0000 | 0.024 ms | 1 | 0.024 ms | 121244.842660 s | 121244.842683 s |
> --------------------------------------------------------------------------------------------------------------------------------
> Total count : 36071
> Total runtime (msec) : 1887.188 (0.185% load average)
> Total time span (msec) : 10185.012
> --------------------------------------------------------------------------------------------------------------------------------
>
> 3. Kwork latency:
>
> # perf kwork latency
>
> Kwork Name | Cpu | Avg delay | Count | Max delay | Max delay start | Max delay end |
> --------------------------------------------------------------------------------------------------------------------------------
> (s)TIMER:1 | 0004 | 3.903 ms | 1 | 3.903 ms | 121235.517068 s | 121235.520971 s |
> (s)RCU:9 | 0004 | 3.252 ms | 2 | 5.809 ms | 121235.517068 s | 121235.522876 s |
> (s)RCU:9 | 0001 | 3.238 ms | 2 | 5.832 ms | 121235.514494 s | 121235.520326 s |
> (w)vmstat_update | 0004 | 1.738 ms | 1 | 1.738 ms | 121235.521005 s | 121235.522743 s |
> (s)SCHED:7 | 0004 | 0.978 ms | 2 | 1.899 ms | 121235.520940 s | 121235.522840 s |
> (w)wb_update_bandwidth_workfn | 0000 | 0.834 ms | 1 | 0.834 ms | 121244.841826 s | 121244.842660 s |
> (s)RCU:9 | 0003 | 0.479 ms | 3 | 0.752 ms | 121240.027521 s | 121240.028273 s |
> (s)TIMER:1 | 0001 | 0.465 ms | 1 | 0.465 ms | 121235.513107 s | 121235.513572 s |
> (w)vmstat_update | 0000 | 0.391 ms | 5 | 1.275 ms | 121236.814938 s | 121236.816213 s |
> (w)mix_interrupt_randomness | 0002 | 0.317 ms | 5 | 0.874 ms | 121244.628034 s | 121244.628908 s |
> (w)neigh_managed_work | 0001 | 0.315 ms | 1 | 0.315 ms | 121235.513614 s | 121235.513929 s |
> ... <SNIP> ...
> (s)TIMER:1 | 0005 | 0.061 ms | 2545 | 0.506 ms | 121237.136113 s | 121237.136619 s |
> (s)SCHED:7 | 0001 | 0.052 ms | 21 | 0.437 ms | 121237.711014 s | 121237.711451 s |
> (s)SCHED:7 | 0002 | 0.045 ms | 309 | 0.145 ms | 121237.137184 s | 121237.137329 s |
> (s)SCHED:7 | 0003 | 0.045 ms | 1 | 0.045 ms | 121240.018586 s | 121240.018631 s |
> (s)SCHED:7 | 0007 | 0.044 ms | 570 | 0.173 ms | 121238.161161 s | 121238.161334 s |
> (s)BLOCK:4 | 0003 | 0.030 ms | 4 | 0.056 ms | 121240.028255 s | 121240.028311 s |
> --------------------------------------------------------------------------------------------------------------------------------
> INFO: 28.761% skipped events (27674 including 2607 raise, 25067 entry, 0 exit)
>
> 4. Kwork timehist:
>
> # perf kwork timehist
> Runtime start Runtime end Cpu Kwork name Runtime Delaytime
> (TYPE)NAME:NUM (msec) (msec)
> ----------------- ----------------- ------ ------------------------------ ---------- ----------
> 121235.513572 121235.513674 [0001] (s)TIMER:1 0.102 0.465
> 121235.513688 121235.513738 [0001] (s)SCHED:7 0.050 0.172
> 121235.513750 121235.513777 [0001] (s)RCU:9 0.027 0.643
> 121235.513929 121235.513973 [0001] (w)neigh_managed_work 0.044 0.315
> 121235.520326 121235.520386 [0001] (s)RCU:9 0.060 5.832
> 121235.520672 121235.520716 [0002] (s)SCHED:7 0.044 0.048
> 121235.520729 121235.520753 [0002] (s)RCU:9 0.024 5.651
> 121235.521213 121235.521249 [0005] (s)TIMER:1 0.036 0.064
> 121235.520166 121235.521379 [0000] (s)SCHED:7 1.213 0.056
> ... <SNIP> ...
> 121235.533256 121235.533296 [0000] virtio0-requests:25 0.040
> 121235.533322 121235.533359 [0000] (s)SCHED:7 0.037 0.095
> 121235.533018 121235.533452 [0006] (s)RCU:9 0.434 0.348
> 121235.534653 121235.534698 [0000] virtio0-requests:25 0.046
> 121235.535657 121235.535702 [0000] virtio0-requests:25 0.044
> 121235.535857 121235.535916 [0005] (s)TIMER:1 0.059 0.055
> 121235.535927 121235.535947 [0005] (s)RCU:9 0.020 0.113
> 121235.536178 121235.536196 [0006] (s)RCU:9 0.018 0.410
> 121235.537406 121235.537445 [0006] (s)SCHED:7 0.039 0.049
> 121235.537457 121235.537481 [0006] (s)RCU:9 0.024 0.334
> 121235.538199 121235.538254 [0007] (s)RCU:9 0.055 0.066
>
> 5. Kwork report use bpf:
>
> # perf kwork report -b
> Starting trace, Hit <Ctrl+C> to stop and report
> ^C
> Kwork Name | Cpu | Total Runtime | Count | Max runtime | Max runtime start | Max runtime end |
> --------------------------------------------------------------------------------------------------------------------------------
> (w)flush_to_ldisc | 0000 | 2.279 ms | 2 | 2.219 ms | 121293.080933 s | 121293.083152 s |
> (s)SCHED:7 | 0001 | 2.141 ms | 2 | 2.100 ms | 121293.082064 s | 121293.084164 s |
> (s)RCU:9 | 0003 | 2.137 ms | 3 | 2.046 ms | 121293.081348 s | 121293.083394 s |
> (s)TIMER:1 | 0007 | 1.882 ms | 12 | 0.249 ms | 121295.632211 s | 121295.632460 s |
> (w)e1000_watchdog | 0002 | 1.136 ms | 3 | 0.428 ms | 121294.496559 s | 121294.496987 s |
> (s)SCHED:7 | 0007 | 0.995 ms | 12 | 0.139 ms | 121295.632483 s | 121295.632621 s |
> (s)NET_RX:3 | 0002 | 0.727 ms | 5 | 0.391 ms | 121299.044624 s | 121299.045016 s |
> (s)TIMER:1 | 0002 | 0.696 ms | 5 | 0.164 ms | 121294.496172 s | 121294.496337 s |
> (s)SCHED:7 | 0002 | 0.427 ms | 6 | 0.077 ms | 121295.840321 s | 121295.840398 s |
> (s)SCHED:7 | 0000 | 0.366 ms | 3 | 0.156 ms | 121296.545389 s | 121296.545545 s |
> eth0:10 | 0002 | 0.353 ms | 5 | 0.122 ms | 121293.084796 s | 121293.084919 s |
> (w)flush_to_ldisc | 0000 | 0.298 ms | 1 | 0.298 ms | 121299.046236 s | 121299.046534 s |
> (w)mix_interrupt_randomness | 0002 | 0.215 ms | 4 | 0.077 ms | 121293.086747 s | 121293.086823 s |
> (s)RCU:9 | 0002 | 0.128 ms | 3 | 0.060 ms | 121293.087348 s | 121293.087409 s |
> (w)vmstat_shepherd | 0000 | 0.098 ms | 1 | 0.098 ms | 121293.083901 s | 121293.083999 s |
> (s)TIMER:1 | 0001 | 0.089 ms | 1 | 0.089 ms | 121293.085709 s | 121293.085798 s |
> (w)vmstat_update | 0003 | 0.071 ms | 1 | 0.071 ms | 121293.085227 s | 121293.085298 s |
> (w)wq_barrier_func | 0000 | 0.064 ms | 1 | 0.064 ms | 121293.083688 s | 121293.083752 s |
> (w)vmstat_update | 0000 | 0.041 ms | 1 | 0.041 ms | 121293.083829 s | 121293.083869 s |
> (s)RCU:9 | 0001 | 0.038 ms | 1 | 0.038 ms | 121293.085818 s | 121293.085856 s |
> (s)RCU:9 | 0007 | 0.035 ms | 1 | 0.035 ms | 121293.112322 s | 121293.112357 s |
> --------------------------------------------------------------------------------------------------------------------------------
>
> 6. Kwork latency use bpf:
>
> # perf kwork latency -b
> Starting trace, Hit <Ctrl+C> to stop and report
> ^C
> Kwork Name | Cpu | Avg delay | Count | Max delay | Max delay start | Max delay end |
> --------------------------------------------------------------------------------------------------------------------------------
> (w)vmstat_shepherd | 0000 | 2.044 ms | 2 | 2.764 ms | 121314.942758 s | 121314.945522 s |
> (w)flush_to_ldisc | 0000 | 1.008 ms | 1 | 1.008 ms | 121317.335508 s | 121317.336516 s |
> (w)vmstat_update | 0002 | 0.879 ms | 1 | 0.879 ms | 121317.024405 s | 121317.025284 s |
> (w)mix_interrupt_randomness | 0002 | 0.328 ms | 5 | 0.383 ms | 121308.832944 s | 121308.833327 s |
> (w)e1000_watchdog | 0002 | 0.304 ms | 5 | 0.368 ms | 121317.024305 s | 121317.024673 s |
> (s)RCU:9 | 0001 | 0.172 ms | 41 | 0.728 ms | 121308.308187 s | 121308.308915 s |
> (s)TIMER:1 | 0000 | 0.149 ms | 3 | 0.195 ms | 121317.334255 s | 121317.334449 s |
> (s)NET_RX:3 | 0001 | 0.143 ms | 40 | 1.213 ms | 121315.030992 s | 121315.032205 s |
> (s)RCU:9 | 0002 | 0.139 ms | 27 | 0.187 ms | 121315.077388 s | 121315.077576 s |
> (s)NET_RX:3 | 0002 | 0.130 ms | 7 | 0.283 ms | 121308.832917 s | 121308.833201 s |
> (s)SCHED:7 | 0007 | 0.123 ms | 34 | 0.191 ms | 121308.736240 s | 121308.736431 s |
> (s)TIMER:1 | 0007 | 0.116 ms | 18 | 0.145 ms | 121308.736168 s | 121308.736313 s |
> (s)RCU:9 | 0007 | 0.111 ms | 68 | 0.318 ms | 121308.736194 s | 121308.736512 s |
> (s)SCHED:7 | 0002 | 0.110 ms | 22 | 0.292 ms | 121308.832197 s | 121308.832489 s |
> (s)TIMER:1 | 0001 | 0.107 ms | 1 | 0.107 ms | 121314.948230 s | 121314.948337 s |
> (w)neigh_managed_work | 0001 | 0.103 ms | 1 | 0.103 ms | 121314.948381 s | 121314.948484 s |
> (s)RCU:9 | 0000 | 0.099 ms | 49 | 0.289 ms | 121308.520167 s | 121308.520456 s |
> (s)NET_RX:3 | 0007 | 0.096 ms | 40 | 1.227 ms | 121315.022994 s | 121315.024220 s |
> (s)RCU:9 | 0003 | 0.093 ms | 37 | 0.261 ms | 121314.950651 s | 121314.950913 s |
> (w)flush_to_ldisc | 0000 | 0.090 ms | 1 | 0.090 ms | 121317.336737 s | 121317.336827 s |
> (s)TIMER:1 | 0002 | 0.078 ms | 36 | 0.115 ms | 121310.880172 s | 121310.880288 s |
> (s)SCHED:7 | 0001 | 0.071 ms | 27 | 0.180 ms | 121314.953571 s | 121314.953751 s |
> (s)SCHED:7 | 0000 | 0.066 ms | 28 | 0.344 ms | 121317.334345 s | 121317.334689 s |
> (s)SCHED:7 | 0003 | 0.063 ms | 14 | 0.119 ms | 121314.978808 s | 121314.978927 s |
> --------------------------------------------------------------------------------------------------------------------------------
>
> 7. Kwork report with filter:
>
> # perf kwork report -b -n RCU
> Starting trace, Hit <Ctrl+C> to stop and report
> ^C
> Kwork Name | Cpu | Total Runtime | Count | Max runtime | Max runtime start | Max runtime end |
> --------------------------------------------------------------------------------------------------------------------------------
> (s)RCU:9 | 0006 | 2.266 ms | 3 | 2.158 ms | 121335.008290 s | 121335.010449 s |
> (s)RCU:9 | 0002 | 0.158 ms | 3 | 0.063 ms | 121335.011914 s | 121335.011977 s |
> (s)RCU:9 | 0007 | 0.082 ms | 1 | 0.082 ms | 121335.448378 s | 121335.448460 s |
> (s)RCU:9 | 0000 | 0.058 ms | 1 | 0.058 ms | 121335.011350 s | 121335.011408 s |
> --------------------------------------------------------------------------------------------------------------------------------
>
> ---
> Changes since v2:
> - Updage commit messages.
>
> Changes since v1:
> - Add options and document when actually add the functionality later.
> - Replace "cluster" with "work".
> - Add workqueue symbolizing function support.
> - Replace "frequency" with "count" in report header.
> - Add bpf trace support.
>
> Yang Jihong (17):
> perf kwork: New tool
> perf kwork: Add irq kwork record support
> perf kwork: Add softirq kwork record support
> perf kwork: Add workqueue kwork record support
> tools lib: Add list_last_entry_or_null
> perf kwork: Implement perf kwork report
> perf kwork: Add irq report support
> perf kwork: Add softirq report support
> perf kwork: Add workqueue report support
> perf kwork: Implement perf kwork latency
> perf kwork: Add softirq latency support
> perf kwork: Add workqueue latency support
> perf kwork: Implement perf kwork timehist
> perf kwork: Implement bpf trace
> perf kwork: Add irq trace bpf support
> perf kwork: Add softirq trace bpf support
> perf kwork: Add workqueue trace bpf support
>
> tools/include/linux/list.h | 11 +
> tools/perf/Build | 1 +
> tools/perf/Documentation/perf-kwork.txt | 180 ++
> tools/perf/Makefile.perf | 1 +
> tools/perf/builtin-kwork.c | 1834 ++++++++++++++++++++
> tools/perf/builtin.h | 1 +
> tools/perf/command-list.txt | 1 +
> tools/perf/perf.c | 1 +
> tools/perf/util/Build | 1 +
> tools/perf/util/bpf_kwork.c | 356 ++++
> tools/perf/util/bpf_skel/kwork_trace.bpf.c | 381 ++++
> tools/perf/util/kwork.h | 257 +++
> 12 files changed, 3025 insertions(+)
> create mode 100644 tools/perf/Documentation/perf-kwork.txt
> create mode 100644 tools/perf/builtin-kwork.c
> create mode 100644 tools/perf/util/bpf_kwork.c
> create mode 100644 tools/perf/util/bpf_skel/kwork_trace.bpf.c
> create mode 100644 tools/perf/util/kwork.h
>
> --
> 2.30.GIT
--
- Arnaldo
^ permalink raw reply
* Re: Controlling device power management from terminal
From: Andy Shevchenko @ 2022-07-25 21:45 UTC (permalink / raw)
To: Crt Mori; +Cc: Linux Iio
In-Reply-To: <CAKv63uv12XWEEVAhUBuK9Botj4mCtKWwRL-YzxywOipTAHgQFg@mail.gmail.com>
On Mon, Jul 25, 2022 at 11:36 PM Crt Mori <cmo@melexis.com> wrote:
> On Mon, 25 Jul 2022 at 23:27, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Mon, Jul 25, 2022 at 10:48 AM Crt Mori <cmo@melexis.com> wrote:
> > >
> > > Hi,
> > > I am implementing the power saving modes for mlx90632 device driver
> > > and while I have implemented routines for SET_RUNTIME_PM_OPS
> > > (runtime_pm_suspend and runtime_pm_resume) I am not able to find out
> > > how to trigger them from the terminal.
> > >
> > > It could be that my driver code for power management implementation is
> > > incomplete and I need to initialize something more.
> > >
> > > Maybe it is helpful, but the power submodule of the device contains below files:
> > >
> > > $ ls -al /sys/bus/iio/devices/iio\:device0/power
> > > total 0
> > > drwxrwxr-x 2 root gpio 0 Apr 6 14:17 .
> > > drwxrwxr-x 3 root gpio 0 Apr 6 14:17 ..
> > > -rw-rw-r-- 1 root gpio 4096 Apr 6 14:17 async
> > > -rw-rw-r-- 1 root gpio 4096 Apr 6 14:17 autosuspend_delay_ms
> > > -rw-rw-r-- 1 root gpio 4096 Apr 6 14:18 control
> > > -r--r--r-- 1 root gpio 4096 Apr 6 14:17 runtime_active_kids
> > > -r--r--r-- 1 root gpio 4096 Apr 6 14:17 runtime_active_time
> > > -r--r--r-- 1 root gpio 4096 Apr 6 14:17 runtime_enabled
> > > -r--r--r-- 1 root gpio 4096 Apr 6 14:17 runtime_status
> > > -r--r--r-- 1 root gpio 4096 Apr 6 14:17 runtime_suspended_time
> > > -r--r--r-- 1 root gpio 4096 Apr 6 14:17 runtime_usage
> > >
> > > And control is already set to "auto" which according to documentation
> > > should allow the PM.
> >
> > 'auto' should enable it. So, whenever the driver thinks it's a time to
> > power off/on the device it will call the methods.
> >
> > You may hack a bit to enable autosuspend (which often is not a good
> > idea for IIO sensors) and see it done automatically after some time.
>
> So the idea is to wait?
Yes.
> How would I enable autosuspend - by lowering
> the autosusped_delay_ms?
Yep, if you wish. The driver should enable it though.
> How does the driver decide that it is time to
> power off/on?
I'm not a driver author, it seems you , who should answer this
question (as you are about to add PM there, am I right?).
> Do I need something else enabled to have this done automatically?
> Autosuspend is 5000 in my case which would mean 5 seconds, so I am
> quite sure I waited that long and I did not see printk's from the
> driver.
Something prevents it from doing (reference counting) or simply some
initialization / enablement is forgotten. For different buses
different PM runtime rules are applied (for example, IIRC, PCI core
does it for you, while platform bus is on what driver wants basis).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* QA notification for completed autobuilder build (yocto-3.1.18.rc1)
From: Pokybuild User @ 2022-07-25 21:46 UTC (permalink / raw)
To: yocto; +Cc: qa-build-notification
A build flagged for QA (yocto-3.1.18.rc1) was completed on the autobuilder and is available at:
https://autobuilder.yocto.io/pub/releases/yocto-3.1.18.rc1
Build hash information:
bitbake: 7fc4cffebf5dcc1d050416c0b7f7d58c765c1d69
meta-agl: 6c9fa75459cf86576c47411fc239e0d7896d483c
meta-arm: 5c09684863be8e803e3e987a5ce4940721c3f39a
meta-aws: dd742bafa5eff33ac930e97dde851f41cbde85e8
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 1c1a8f769ef93d96ae488f40abbcd11946403169
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: 52cee67833d1975a5bd52e4556c4cd312425a017
meta-virtualization: a63a54df3170fed387f810f23cdc2f483ad587df
oecore: 3f40d5f095ceb099b604750db96058df00fcd49e
poky: d695bd0d3dc66f2111a25c6922f617be2d991071
This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org
^ permalink raw reply
* Re: [PATCH] zephyr-kernel-src: bump the v3 version to v3.1.0
From: Jon Mason @ 2022-07-25 21:46 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Naveen Saini, Eilís Ní Fhlannagáin, yocto,
openembedded-devel, Bartosz Golaszewski
In-Reply-To: <20220725154744.97466-1-brgl@bgdev.pl>
On Mon, Jul 25, 2022 at 05:47:44PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@huawei.com>
>
> This upgrades the 3.x series to using v3.1.0.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@huawei.com>
With this patch, I'm seeing:
WARNING: interrupt-3.1.0+gitAUTOINC+2ddd73feaf_5f86244bad-r0 do_patch: Fuzz detected:
Applying patch 0001-cmake-add-yocto-toolchain.patch
patching file cmake/compiler/gcc/target.cmake
Hunk #1 succeeded at 94 with fuzz 1 (offset 26 lines).
patching file cmake/toolchain/yocto/generic.cmake
patching file cmake/toolchain/yocto/target.cmake
The context lines in the patches can be updated with devtool:
devtool modify interrupt
devtool finish --force-patch-refresh interrupt <layer_path>
And similar errors for all the other tests. You can see them all at
https://gitlab.com/jonmason00/meta-zephyr/-/pipelines/596452936
It should be a trival rebase and everything will be happy. Aside from
this, it looks like all the tests are passing.
Thanks,
Jon
> ---
> .../zephyr-kernel/zephyr-kernel-src-2.7.2.inc | 6 +-
> .../zephyr-kernel/zephyr-kernel-src-3.0.0.inc | 70 ------------------
> .../zephyr-kernel/zephyr-kernel-src-3.1.0.inc | 72 +++++++++++++++++++
> .../zephyr-kernel/zephyr-kernel-src.inc | 4 +-
> 4 files changed, 78 insertions(+), 74 deletions(-)
> delete mode 100644 meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.0.0.inc
> create mode 100644 meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc
>
> diff --git a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.2.inc b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.2.inc
> index 7a4da21..204e770 100644
> --- a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.2.inc
> +++ b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.2.inc
> @@ -62,4 +62,8 @@ SRCREV_tfm = "c74be3890c9d975976fde1b1a3b2f5742bec34c0"
> ZEPHYR_BRANCH = "v2.7-branch"
> PV = "2.7.2+git${SRCPV}"
>
> -SRC_URI:append = " file://dtc.patch"
> +SRC_URI:append = " \
> + file://dtc.patch \
> + file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
> + git://github.com/zephyrproject-rtos/hal_cypress.git;protocol=https;nobranch=1;destsuffix=git/modules/hal/cypress;name=cypress \
> +"
> diff --git a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.0.0.inc b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.0.0.inc
> deleted file mode 100644
> index 64594a0..0000000
> --- a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.0.0.inc
> +++ /dev/null
> @@ -1,70 +0,0 @@
> -SRCREV_FORMAT = "default_cmsis"
> -
> -#
> -# Generated with:
> -#
> -# #!/usr/bin/python3
> -#
> -# import yaml
> -# import sys
> -#
> -# if __name__ == "__main__":
> -# with open(sys.argv[1], "r") as fd:
> -# data = yaml.safe_load(fd)
> -#
> -# for project in data["manifest"]["projects"]:
> -# print("SRCREV_{} = \"{}\"".format(project["name"], project["revision"]))
> -#
> -
> -SRCREV_default = "4f8d78ceeb436e82f528511998515f6fc137c6cd"
> -SRCREV_canopennode = "1052dae561497bef901f931ef75e117c9224aecd"
> -SRCREV_civetweb = "094aeb41bb93e9199d24d665ee43e9e05d6d7b1c"
> -SRCREV_cmsis = "b0612c97c1401feeb4160add6462c3627fe90fc7"
> -SRCREV_edtt = "1fc2e6f7d2a01a01074456f2ef2ccf1f3df7fac1"
> -SRCREV_fatfs = "09a9d913c61dccbb8ff92d8943b452c614ac5292"
> -SRCREV_fff = "6ce5ba26486e93d5b7696a3e23f0585932c14b16"
> -SRCREV_altera = "23c1c1dd7a0c1cc9a399509d1819375847c95b97"
> -SRCREV_atmel = "9f78f520f6cbb997e5b44fe8ab17dd5bf2448095"
> -SRCREV_cypress = "81a059f21435bc7e315bccd720da5a9b615bbb50"
> -SRCREV_espressif = "bcd7565ffa390d5774dc2fbe71a002faa9a7d082"
> -SRCREV_gigadevice = "242a7f4be7a3136606c7a65169775f7ef85ad444"
> -SRCREV_infineon = "f1fa8241f8786198ba41155413243de36ed878a5"
> -SRCREV_microchip = "870d05e6a64ea9548da6b907058b03c8c9420826"
> -SRCREV_nordic = "a42b016d7c7610489f5f8c79773fedc05ba352ee"
> -SRCREV_nuvoton = "b4d31f33238713a568e23618845702fadd67386f"
> -SRCREV_nxp = "9629f15fd80169cc9669e3fbb1260467c3aeb175"
> -SRCREV_openisa = "40d049f69c50b58ea20473bee14cf93f518bf262"
> -SRCREV_quicklogic = "b3a66fe6d04d87fd1533a5c8de51d0599fcd08d0"
> -SRCREV_rpi_pico = "191f5ba46fda49523cdaaef27583d1c875ba2c36"
> -SRCREV_silabs = "be39d4eebeddac6e18e9c0c3ba1b31ad1e82eaed"
> -SRCREV_st = "575de9d461aa6f430cf62c58a053675377e700f3"
> -SRCREV_stm32 = "300109f80730cb2477bfcc706a6602b9870336b3"
> -SRCREV_telink = "ffcfd6282aa213f1dc0848dbca6279b098f6b143"
> -SRCREV_ti = "1992a4c536554c4f409c36896eda6abdc414d277"
> -SRCREV_xtensa = "0e577021bb66e644afd067cd9f7c71ab11b62b3d"
> -SRCREV_libmetal = "f237c9d420a51cc43bc37d744e41191ad613f348"
> -SRCREV_littlefs = "33509ed9c3d369cdb9d909cd40c5eea8f64a902c"
> -SRCREV_loramac-node = "12019623bbad9eb54fe51066847a7cbd4b4eac57"
> -SRCREV_lvgl = "783c1f78c8e39751fe89d0883c8bce7336f55e94"
> -SRCREV_lz4 = "8e303c264fc21c2116dc612658003a22e933124d"
> -SRCREV_mbedtls = "3e3e58a92de76069730c63e0d524f40fea948a61"
> -SRCREV_mcuboot = "89936c338e46f43cb177a8b928cd80b90f3ace8f"
> -SRCREV_mipi-sys-t = "d9da086b11cda494d85f4d8a9829f505c2d5e380"
> -SRCREV_nanopb = "d148bd26718e4c10414f07a7eb1bd24c62e56c5d"
> -SRCREV_net-tools = "f49bd1354616fae4093bf36e5eaee43c51a55127"
> -SRCREV_nrf_hw_models = "b8cea37dbdc8fc58cc14b4e19fa850877a9da520"
> -SRCREV_open-amp = "cfd050ff38a9d028dc211690b2ec35971128e45e"
> -SRCREV_openthread = "b7aa7686d3f4e326bd25abc234b209159977c26d"
> -SRCREV_segger = "3a52ab222133193802d3c3b4d21730b9b1f1d2f6"
> -SRCREV_sof = "500d77e0ac84ac2c969e0d4b2142cca192e893bc"
> -SRCREV_tflite-micro = "9156d050927012da87079064db59d07f03b8baf6"
> -SRCREV_tinycbor = "40daca97b478989884bffb5226e9ab73ca54b8c4"
> -SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
> -SRCREV_TraceRecorderSource = "e8ca3b6a83d19b2fc4738a0d9607190436e5e452"
> -SRCREV_trusted-firmware-m = "5d32c3e64b3d589548e881eeeeb37d84944c90af"
> -SRCREV_tf-m-tests = "52814181f0fde6d1422fac204d42cde30c62e40e"
> -SRCREV_psa-arch-tests = "0aab24602cbef30f6422e7ef1066a8473073e586"
> -SRCREV_zscilib = "12bfe3f0a9fcbfe3edab7eabc9678b6c62875d34"
> -
> -ZEPHYR_BRANCH = "v3.0-branch"
> -PV = "3.0.0+git${SRCPV}"
> diff --git a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc
> new file mode 100644
> index 0000000..c3e4e57
> --- /dev/null
> +++ b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc
> @@ -0,0 +1,72 @@
> +SRCREV_FORMAT = "default_cmsis"
> +
> +#
> +# Generated with:
> +#
> +# #!/usr/bin/python3
> +#
> +# import yaml
> +# import sys
> +#
> +# if __name__ == "__main__":
> +# with open(sys.argv[1], "r") as fd:
> +# data = yaml.safe_load(fd)
> +#
> +# for project in data["manifest"]["projects"]:
> +# print("SRCREV_{} = \"{}\"".format(project["name"], project["revision"]))
> +#
> +
> +SRCREV_default = "2ddd73feafd3316af2c547c34d6969bea637d5c6"
> +SRCREV_canopennode = "53d3415c14d60f8f4bfca54bfbc5d5a667d7e724"
> +SRCREV_chre = "0edfe2c2ec656afb910cfab8ed59a5ffd59b87c8"
> +SRCREV_civetweb = "094aeb41bb93e9199d24d665ee43e9e05d6d7b1c"
> +SRCREV_cmsis = "5f86244bad4ad5a590e084f0e72ba7a1416c2edf"
> +SRCREV_edtt = "1ea61a390d2bfcf3b2ecdba8f8b0b98dfdffbd11"
> +SRCREV_fatfs = "a30531af3a95a9a3ea7d771ea8a578ebfed45514"
> +SRCREV_fff = "6ce5ba26486e93d5b7696a3e23f0585932c14b16"
> +SRCREV_altera = "0d225ddd314379b32355a00fb669eacf911e750d"
> +SRCREV_atmel = "78c5567c05b6b434dd7d98f49156319df4217bac"
> +SRCREV_espressif = "df85671c5d0405c0747c2939c8dfe808b7e4cf38"
> +SRCREV_gigadevice = "63a72ca90b7e0d7257211ddc5c79e8c0b940371b"
> +SRCREV_infineon = "4af06965f57ba1e7d170e6a97d24c33785543a8c"
> +SRCREV_microchip = "5d079f1683a00b801373bbbbf5d181d4e33b30d5"
> +SRCREV_nordic = "a85bb3676d61d1ae202088e0d3fec556056b2c9e"
> +SRCREV_nuvoton = "b4d31f33238713a568e23618845702fadd67386f"
> +SRCREV_nxp = "2302a1e94f5bc00ce59db4e249b688ad2e959f58"
> +SRCREV_openisa = "40d049f69c50b58ea20473bee14cf93f518bf262"
> +SRCREV_quicklogic = "b3a66fe6d04d87fd1533a5c8de51d0599fcd08d0"
> +SRCREV_rpi_pico = "191f5ba46fda49523cdaaef27583d1c875ba2c36"
> +SRCREV_silabs = "be39d4eebeddac6e18e9c0c3ba1b31ad1e82eaed"
> +SRCREV_st = "52a522ca4a8a9ec1e9bb5bb514e1ab6f102863fe"
> +SRCREV_stm32 = "51b373cd3455b8c2b9babbf6ff41918116a442ac"
> +SRCREV_telink = "ffcfd6282aa213f1dc0848dbca6279b098f6b143"
> +SRCREV_ti = "905a5d4134899630071f9383aadaaf266e8f8cd2"
> +SRCREV_xtensa = "0e577021bb66e644afd067cd9f7c71ab11b62b3d"
> +SRCREV_libmetal = "850a3c3fd5bc655987021dc9106d8e8cd0f7e061"
> +SRCREV_liblc3codec = "3951cf1b71ff3be086c9b9b595e473e12301337c"
> +SRCREV_littlefs = "652f2c5646e79b881e6f3099686ad3b7af9e216c"
> +SRCREV_loramac-node = "12019623bbad9eb54fe51066847a7cbd4b4eac57"
> +SRCREV_lvgl = "df717ac87a9fd80246cc8df24554475e59bda21f"
> +SRCREV_lz4 = "8e303c264fc21c2116dc612658003a22e933124d"
> +SRCREV_mbedtls = "7fed49c9b9f983ad6416986661ef637459723bcb"
> +SRCREV_mcuboot = "e58ea98aec6e5539c5f872a98059e461d0155bbb"
> +SRCREV_mipi-sys-t = "a5163c1800a5243f8b05d84c942da008df4cb666"
> +SRCREV_nanopb = "d148bd26718e4c10414f07a7eb1bd24c62e56c5d"
> +SRCREV_net-tools = "f49bd1354616fae4093bf36e5eaee43c51a55127"
> +SRCREV_nrf_hw_models = "b8cea37dbdc8fc58cc14b4e19fa850877a9da520"
> +SRCREV_open-amp = "8d53544871e1f300c478224faca6be8384ab0d04"
> +SRCREV_openthread = "e2a765599aa0379d0f72f0149a9cbafec070c12d"
> +SRCREV_segger = "3a52ab222133193802d3c3b4d21730b9b1f1d2f6"
> +SRCREV_sof = "2efc3ea41c0074c6dab5f376fafaa26f52c25c75"
> +SRCREV_tflite-micro = "9156d050927012da87079064db59d07f03b8baf6"
> +SRCREV_tinycbor = "9e1f34bc08123aaad7666d3652aaa839e8178b3b"
> +SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
> +SRCREV_TraceRecorderSource = "e8ca3b6a83d19b2fc4738a0d9607190436e5e452"
> +SRCREV_trusted-firmware-m = "7c53a6e76130a85303f83b15d868a92fdcd5f5be"
> +SRCREV_tf-m-tests = "c99a86b295c4887520da9d8402566d7f225c974e"
> +SRCREV_psa-arch-tests = "a81f9da287569f169d60026916952641b233faa8"
> +SRCREV_zcbor = "882c489a7d9fdfff31d27666914a78a9eb6976d7"
> +SRCREV_zscilib = "fc979a8dcb74169c69b02835927bff8f070d6325"
> +
> +ZEPHYR_BRANCH = "v3.1-branch"
> +PV = "3.1.0+git${SRCPV}"
> diff --git a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
> index bf9ceaf..0769017 100644
> --- a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
> +++ b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
> @@ -19,7 +19,6 @@ SRC_URI = "\
> git://github.com/zephyrproject-rtos/fatfs.git;protocol=https;nobranch=1;destsuffix=git/modules/fs/fatfs;name=fatfs \
> git://github.com/zephyrproject-rtos/hal_altera.git;protocol=https;nobranch=1;destsuffix=git/modules/hal/altera;name=altera \
> git://github.com/zephyrproject-rtos/hal_atmel.git;protocol=https;nobranch=1;destsuffix=git/modules/hal/atmel;name=atmel \
> - git://github.com/zephyrproject-rtos/hal_cypress.git;protocol=https;nobranch=1;destsuffix=git/modules/hal/cypress;name=cypress \
> git://github.com/zephyrproject-rtos/hal_espressif.git;protocol=https;nobranch=1;destsuffix=git/modules/hal/espressif;name=espressif \
> git://github.com/zephyrproject-rtos/hal_infineon.git;protocol=https;nobranch=1;destsuffix=git/modules/hal/infineon;name=infineon \
> git://github.com/zephyrproject-rtos/hal_microchip.git;protocol=https;nobranch=1;destsuffix=git/modules/hal/microchip;name=microchip \
> @@ -53,10 +52,9 @@ SRC_URI = "\
> git://github.com/zephyrproject-rtos/lz4.git;protocol=https;nobranch=1;destsuffix=git/modules/lib/lz4;name=lz4 \
> git://github.com/zephyrproject-rtos/tflite-micro.git;protocol=https;nobranch=1;destsuffix=git/modules/lib/tflite-micro;name=tflite-micro \
> file://0001-cmake-add-yocto-toolchain.patch \
> - file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
> "
> S = "${WORKDIR}/git"
>
> # Default to a stable version
> -PREFERRED_VERSION_zephyr-kernel ??= "3.0.0"
> +PREFERRED_VERSION_zephyr-kernel ??= "3.1.0"
> include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc
> --
> 2.34.1
>
>
^ permalink raw reply
* [usb:usb-testing] BUILD SUCCESS b6de1f901039cfcbd605842d454bd80c589105d8
From: kernel test robot @ 2022-07-25 21:46 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-usb
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
branch HEAD: b6de1f901039cfcbd605842d454bd80c589105d8 Merge tag 'usb-serial-5.20-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next
elapsed time: 721m
configs tested: 76
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm64 allyesconfig
arm defconfig
arm allyesconfig
powerpc randconfig-c003-20220724
i386 randconfig-c001
arm clps711x_defconfig
powerpc mpc85xx_cds_defconfig
parisc64 alldefconfig
powerpc amigaone_defconfig
arm cerfcube_defconfig
arc axs101_defconfig
arm shmobile_defconfig
m68k virt_defconfig
arm lart_defconfig
xtensa generic_kc705_defconfig
loongarch defconfig
loongarch allnoconfig
ia64 allmodconfig
csky allnoconfig
alpha allnoconfig
arc allnoconfig
riscv allnoconfig
sh allmodconfig
powerpc allnoconfig
powerpc allmodconfig
mips allyesconfig
m68k allyesconfig
i386 defconfig
i386 allyesconfig
alpha allyesconfig
arc allyesconfig
m68k allmodconfig
i386 randconfig-a001
i386 randconfig-a003
i386 randconfig-a005
x86_64 randconfig-a013
x86_64 randconfig-a011
x86_64 randconfig-a015
i386 randconfig-a016
i386 randconfig-a012
i386 randconfig-a014
x86_64 randconfig-a002
x86_64 randconfig-a006
x86_64 randconfig-a004
s390 randconfig-r044-20220724
riscv randconfig-r042-20220724
arc randconfig-r043-20220724
x86_64 rhel-8.3-kselftests
um i386_defconfig
um x86_64_defconfig
x86_64 rhel-8.3-func
x86_64 rhel-8.3-kunit
x86_64 rhel-8.3-syz
x86_64 rhel-8.3-kvm
x86_64 defconfig
x86_64 allyesconfig
x86_64 rhel-8.3
clang tested configs:
arm hackkit_defconfig
mips tb0219_defconfig
arm mvebu_v5_defconfig
mips sb1250_swarm_defconfig
x86_64 randconfig-k001
x86_64 randconfig-a005
x86_64 randconfig-a003
x86_64 randconfig-a001
i386 randconfig-a002
i386 randconfig-a006
i386 randconfig-a004
x86_64 randconfig-a012
x86_64 randconfig-a014
x86_64 randconfig-a016
i386 randconfig-a015
i386 randconfig-a013
i386 randconfig-a011
hexagon randconfig-r041-20220724
hexagon randconfig-r045-20220724
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply
* Re: Feature request: provide a persistent IDs on a commit
From: Jacob Keller @ 2022-07-25 21:47 UTC (permalink / raw)
To: Elijah Newren
Cc: Michal Suchánek, Philip Oakley, Hilco Wijbenga, Phillip Susi,
Ævar Arnfjörð Bjarmason, Stephen Finucane,
Git Users
In-Reply-To: <CABPp-BEYQOtr6EZmi4emKRKNVXS3071Ud90jiLycdGXGG+YqgQ@mail.gmail.com>
On Sat, Jul 23, 2022 at 10:23 PM Elijah Newren <newren@gmail.com> wrote:
>
> On Sat, Jul 23, 2022 at 12:44 AM Michal Suchánek <msuchanek@suse.de> wrote:
> >
> > On Fri, Jul 22, 2022 at 03:46:22PM -0700, Jacob Keller wrote:
> > > On Fri, Jul 22, 2022 at 1:42 PM Michal Suchánek <msuchanek@suse.de> wrote:
> > > >
> > > > On Fri, Jul 22, 2022 at 09:08:56PM +0100, Philip Oakley wrote:
> [...]
> > > > > Part of the rename problem is that there can be many different routes to
> > > > > the same result, and often the route used isn't the one 'specified' by
> > > > > those who wish a complicated rename process to have happened 'their
> > > > > way', plus people forget to record what they actually did. Attempting to
> > > > > capture what happened still results major gaps in the record.
> > > >
> > > > Doesn't git have rebase?
> > > >
> > > > It is not required that the rename is captured perfectly every time so
> > > > long as it can be amended later.
> > > >
> > >
> > > Rebase is typically reserved only to modify commits which are not yet
> > > "permanent". Once a commit starts being referenced by many others it
> > > becomes more and more difficult to rebase it. Any rebase effectively
> > > creates a new commit.
> > >
> > > There are multiple threads discussing renames and handling them in git
> > > in the past which are worth re-reading, including at least
> > >
> > > https://public-inbox.org/git/Pine.LNX.4.58.0504141102430.7211@ppc970.osdl.org/
> > >
> > > A fuller analysis here too:
> > > https://public-inbox.org/git/Pine.LNX.4.64.0510221251330.10477@g5.osdl.org/
> > >
> > > As mentioned above in this thread, depending on what context you are
> > > using, a change to a commit could be many to many: i.e. a commit which
> > > splits into 2, or 3 commits merging into one, or 3 commits splitting
> > > apart and then becoming 2 commits. When that happens, what "change id"
> > > do you use for each commit?
> >
> > Same as commit message and any trailers you might have - they are
> > preserved, concatenated
>
> Exactly how are they concatenated? Is that a user operation, or
> something a Git command does automatically? Which commands and which
> circumstances? If users do it, what's the UI for them to discover
> what the fields are, for them to discover whether such a thing might
> be needed or beneficial, and the UI for them to change these fields?
> This sounds like a massive UX/UI issue that I don't have a clue how to
> tackle (assuming I wanted to).
>
> > and can be regenerated.
>
> "can be". But generally won't be even when it should be, right?
>
> Committer name/email/date basically don't even exist as far as many
> Git users are concerned. They aren't shown in the default log output
> (which greatly saddens me), and even after attempting to educate users
> for well over a decade now, I still routinely find developers who are
> surprised that these things exist.
>
> Given that committer name/email/date aren't shown with --pretty=full
> but with the lame option name --pretty=fuller, I can't see why it'd
> make any sense to show Change-Ids in the log output by default.
>
> But if it's not shown -- and by default -- then it doesn't exist for
> many users. And if it doesn't exist, users aren't going to fix it
> when they need to.
>
> (Even if it were shown by default, it's not clear to me that users
> would know when to fix it, or how to fix it, or even care to fix it
> and instead view it as a pedantic requirement being foisted on them.)
>
> I think the "many-to-many issue" others have raised in this thread is
> an important, big, and thorny problem. I think it has the potential
> to be a minefield of UX and a steady stream of bug reports. And
> seeing proponents of Change-Id just dismissing the issue makes me all
> the more suspicious of the proposal in the first place.
I do think there is some value in having a sort of generic id like
change-id, but I do think we want to be careful about how exactly we
handle it.
As you say, if we hide it then users may not be aware of it, and if we
make it visible users who don't care may be annoyed. I don't think we
can fully automate it because of the nature of combining changes and
splitting changes require humans to decide which change keeps which
ID. Its not even clear when rebasing whether a split is going to
happen. A combine operation is easier to detect in rebase
(fixup/squash), but determining which id to keep is not. Would we even
want to have support for "this commit merges two and is now one, but
we keep both IDs because it really is both commits"? That gets messy
pretty fast.
Users such as gerrit already simply use the trailer with Change-id and
manage to make it work by enforcing some constraints and assuming
users will know what to do (because otherwise they fail to interact
with gerrit servers).
For cases where it helps, I think its very valuable. Being able to
track revisions of a series or a patch is super useful. Getting
external tooling like public-inbox, patchworks, etc to use this would
also be useful. But I think we would want to sort out the situation a
bit for how and when are they generated, when are they
replaced/re-generated, how this interacts with mailing etc.
Should rebase just always regenerate? that loses a lot of value. I
guess squashing could offer users a choice of which to keep? Fixup
would always keep the same one. And otherwise it becomes up to users
to know when they need to copy from an old commit or refresh an
existing commit... Thats pretty much what gerrit does these days, if a
commit doesn't have the trailer it gets added, and if it does, its up
to the user to know when to remove it or regenerate it... Since its a
commit message trailer it gets sent implicitly through the mailing
list unless removed.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.