This very small series comes to fix the very annyoing problem of
partitions declared by parser at runtime NOT supporting nvmem cells
definition.
The current implementation is very generic. The idea is to provide an of
node if defined for everyone and not strictly limit this to nvmem stuff.
But still the actual change is done only for nvmem-cells mtd. (just to
make sure) This can totally change by removing the compatible check.
The idea here is that a user can still use these dynamic parsers
instead of declaring a fixed-partition and also declare how nvmem-cells
are defined for the partition.
This live with the assumption that dynamic partition have always the
same name and they are known. (this is the case for smem-part partition
that would require a bootloader reflash to change and for parsers like
cmdlinepart where the name is always the same.)
With this assumption, it's easy to fix this problem. Just introduce a
new partition node that will declare just these special partition.
Mtdcore then will check if these special declaration are present and
connect the dynamic partition with the OF node present in the dts. Nvmem
will automagically fin the OF node and cells will be works based on the
data provided by the parser.
The initial idea was to create a special nvmem driver with a special
compatible where a user would declare the mtd partition name and this
driver would search it and register the nvmem cells but that became
difficult really fast, mtd notifier system is problematic for this kind
of stuff. So here is the better implementation. A variant of this is
already tested on openwrt where we have devices that use cmdlinepart.
(that current variant have defined in the dts the exact copy of
cmdlinepart in the fixed-partition scheme and we patched the cmdlinepart
parser to scan this fixed-partition node (that is ignored as cmdlinepart
have priority) and connect the dynamic partition with the dts node)
I provided an example of this in the documentation commit.
In short it's needed to add to the partitions where the compatible parser
is declared, a partition with just the label declared (instead of the reg).
Then declare some nvmem-cells and it will all work at runtime.
Mtdcore will check if a node with the same label is present and assign an
OF node to the MTD.
I currently tested this on my device that have smem-part and the
gmac driver use nvmem to get the mac-address. This works correctly and
the same address is provided.
I hope we find a solutio to this problem as currently we are trying to
transition to nvmem and we found this limitation. This seems to be a
good solution that doesn't looks to be too much of an hack.n
v2:
- Simplify this. Drop dynamic-partition
- Fix problem with parser with ko
- Do not pollude mtd_get_of_node
- Fix problem with Documentation
Ansuel Smith (2):
dt-bindings: mtd: partitions: Document new partition-dynamic nodes
mtd: core: introduce of support for dynamic partitions
.../mtd/partitions/partition-dynamic.yaml | 54 +++++++++++++++++++
drivers/mtd/mtdcore.c | 45 ++++++++++++++++
2 files changed, 99 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml
--
2.34.1
Document new partition-dynamic nodes used to provide an OF node for
partition registred at runtime by parsers. This is required for nvmem
system to declare and detect nvmem-cells.
With these special partitions, only the label is required as the parser
will provide reg and offset of the mtd. NVMEM will use the data from the
parser and provide the NVMEM cells declared in the DTS, "connecting" the
dynamic partition with a static declaration of cells in them.
Signed-off-by: Ansuel Smith <[email protected]>
---
.../mtd/partitions/partition-dynamic.yaml | 54 +++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml
diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml
new file mode 100644
index 000000000000..945128e754ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/partition-dynamic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dynamic Partition
+
+description: |
+ This binding describes a single flash partition that is dynamically allocated
+ by a dedicated parser that is not a fixed-partition parser. To declare a
+ partition the label is required. This can be used to give a dynamic partition
+ an OF node so that subsystems like NVMEM can work and provide NVMEM Cells to
+ the system. An example is declaring the partition label and all the NVMEM
+ cells in it. The parser will detect the correct reg and offset and the NVMEM
+ will register the cells in it based on the data extracted by the parser.
+
+maintainers:
+ - Ansuel Smith <[email protected]>
+
+properties:
+ label:
+ description: The label / name for the partition assigned by the parser at
+ runtime. This is needed for sybsystem like NVMEM to define cells and
+ register with this OF node.
+
+required:
+ - label
+
+additionalProperties: true
+
+examples:
+ - |
+ partitions {
+ compatible = "qcom,smem-part";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ art {
+ compatible = "nvmem-cells";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ label = "0:art";
+
+ macaddr_art_0: macaddr@0 {
+ reg = <0x0 0x6>;
+ };
+
+ macaddr_art_6: macaddr@6 {
+ reg = <0x6 0x6>;
+ };
+ };
+ };
--
2.34.1
We have many parser that register mtd partitions at runtime. One example
is the cmdlinepart or the smem-part parser where the compatible is defined
in the dts and the partitions gets detected and registered by the
parser. This is problematic for the NVMEM subsystem that requires an OF node
to detect NVMEM cells.
To fix this problem, introduce an additional logic that will try to
assign an OF node to the MTD if declared.
On MTD addition, it will be checked if the MTD has an OF node and if
not declared will check if a partition with the same name / label is
declared in DTS. If an exact match is found, the partition dynamically
allocated by the parser will have a connected OF node.
The NVMEM subsystem will detect the OF node and register any NVMEM cells
declared statically in the DTS.
Signed-off-by: Ansuel Smith <[email protected]>
---
drivers/mtd/mtdcore.c | 45 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 9186268d361b..636b0a02f6cf 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -563,6 +563,50 @@ static int mtd_nvmem_add(struct mtd_info *mtd)
return 0;
}
+void mtd_check_of_node(struct mtd_info *mtd)
+{
+ struct device_node *partitions, *parent_dn, *mtd_dn = NULL;
+ struct mtd_info *parent;
+ const char *mtd_name;
+ bool found = false;
+ int plen;
+
+ /* Check if MTD already has a device node */
+ if (dev_of_node(&mtd->dev))
+ return;
+
+ /* Check if a partitions node exist */
+ parent = mtd->parent;
+ parent_dn = dev_of_node(&parent->dev);
+ if (!parent_dn)
+ return;
+
+ partitions = of_get_compatible_child(parent_dn, "partitions");
+ if (!partitions)
+ goto exit_parent;
+
+ /* Search if a partition is defined with the same name */
+ for_each_child_of_node(partitions, mtd_dn) {
+ mtd_name = of_get_property(mtd_dn, "label", &plen);
+ if (!strncmp(mtd->name, mtd_name, plen)) {
+ found = true;
+ break;
+ }
+ }
+
+ if (!found)
+ goto exit_partitions;
+
+ /* Set of_node only for nvmem */
+ if (of_device_is_compatible(mtd_dn, "nvmem-cells"))
+ mtd_set_of_node(mtd, mtd_dn);
+
+exit_partitions:
+ of_node_put(partitions);
+exit_parent:
+ of_node_put(parent_dn);
+}
+
/**
* add_mtd_device - register an MTD device
* @mtd: pointer to new MTD device info structure
@@ -668,6 +712,7 @@ int add_mtd_device(struct mtd_info *mtd)
mtd->dev.devt = MTD_DEVT(i);
dev_set_name(&mtd->dev, "mtd%d", i);
dev_set_drvdata(&mtd->dev, mtd);
+ mtd_check_of_node(mtd);
of_node_get(mtd_get_of_node(mtd));
error = device_register(&mtd->dev);
if (error)
--
2.34.1
On Sun, 20 Feb 2022 18:39:04 +0100, Ansuel Smith wrote:
> Document new partition-dynamic nodes used to provide an OF node for
> partition registred at runtime by parsers. This is required for nvmem
> system to declare and detect nvmem-cells.
>
> With these special partitions, only the label is required as the parser
> will provide reg and offset of the mtd. NVMEM will use the data from the
> parser and provide the NVMEM cells declared in the DTS, "connecting" the
> dynamic partition with a static declaration of cells in them.
>
> Signed-off-by: Ansuel Smith <[email protected]>
> ---
> .../mtd/partitions/partition-dynamic.yaml | 54 +++++++++++++++++++
> 1 file changed, 54 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.example.dt.yaml: partitions: '#address-cells', '#size-cells', 'art' do not match any of the regexes: 'pinctrl-[0-9]+'
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1595230
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
On Sun, Feb 20, 2022 at 08:36:09PM -0600, Rob Herring wrote:
> On Sun, 20 Feb 2022 18:39:04 +0100, Ansuel Smith wrote:
> > Document new partition-dynamic nodes used to provide an OF node for
> > partition registred at runtime by parsers. This is required for nvmem
> > system to declare and detect nvmem-cells.
> >
> > With these special partitions, only the label is required as the parser
> > will provide reg and offset of the mtd. NVMEM will use the data from the
> > parser and provide the NVMEM cells declared in the DTS, "connecting" the
> > dynamic partition with a static declaration of cells in them.
> >
> > Signed-off-by: Ansuel Smith <[email protected]>
> > ---
> > .../mtd/partitions/partition-dynamic.yaml | 54 +++++++++++++++++++
> > 1 file changed, 54 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml
> >
>
> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.example.dt.yaml: partitions: '#address-cells', '#size-cells', 'art' do not match any of the regexes: 'pinctrl-[0-9]+'
> From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml
>
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.ozlabs.org/patch/1595230
>
> This check can fail if there are any dependencies. The base for a patch
> series is generally the most recent rc1.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit.
>
Considering the idea of this partition-dynamic, should these warning be
ignored or the smem-part should include the ref of these new partitions?
Or should I remove the example?
(or should I add the example to smem-part instead of partition-dynamic)
--
Ansuel
On Tue, Feb 22, 2022 at 12:01:31PM -0600, Rob Herring wrote:
> On Mon, Feb 21, 2022 at 04:57:40PM +0100, Ansuel Smith wrote:
> > On Sun, Feb 20, 2022 at 08:36:09PM -0600, Rob Herring wrote:
> > > On Sun, 20 Feb 2022 18:39:04 +0100, Ansuel Smith wrote:
> > > > Document new partition-dynamic nodes used to provide an OF node for
> > > > partition registred at runtime by parsers. This is required for nvmem
> > > > system to declare and detect nvmem-cells.
> > > >
> > > > With these special partitions, only the label is required as the parser
> > > > will provide reg and offset of the mtd. NVMEM will use the data from the
> > > > parser and provide the NVMEM cells declared in the DTS, "connecting" the
> > > > dynamic partition with a static declaration of cells in them.
> > > >
> > > > Signed-off-by: Ansuel Smith <[email protected]>
> > > > ---
> > > > .../mtd/partitions/partition-dynamic.yaml | 54 +++++++++++++++++++
> > > > 1 file changed, 54 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml
> > > >
> > >
> > > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> > > on your patch (DT_CHECKER_FLAGS is new in v5.13):
> > >
> > > yamllint warnings/errors:
> > >
> > > dtschema/dtc warnings/errors:
> > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.example.dt.yaml: partitions: '#address-cells', '#size-cells', 'art' do not match any of the regexes: 'pinctrl-[0-9]+'
> > > From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml
> > >
> > > doc reference errors (make refcheckdocs):
> > >
> > > See https://patchwork.ozlabs.org/patch/1595230
> > >
> > > This check can fail if there are any dependencies. The base for a patch
> > > series is generally the most recent rc1.
> > >
> > > If you already ran 'make dt_binding_check' and didn't see the above
> > > error(s), then make sure 'yamllint' is installed and dt-schema is up to
> > > date:
> > >
> > > pip3 install dtschema --upgrade
> > >
> > > Please check and re-submit.
> > >
> >
> > Considering the idea of this partition-dynamic, should these warning be
> > ignored or the smem-part should include the ref of these new partitions?
>
> We can't have warnings.
>
> > Or should I remove the example?
>
> Doesn't that just kick the problem to actual users?
>
> > (or should I add the example to smem-part instead of partition-dynamic)
>
> That shouldn't matter I think...
>
> Rob
I mean the problem here is that smem-part doesn't accept partition
subnode... Think I should add a ref there... In theory I should be able
to keep the example...
--
Ansuel
On Tue, Feb 22, 2022 at 12:18:56PM -0600, Rob Herring wrote:
> On Sun, Feb 20, 2022 at 06:39:04PM +0100, Ansuel Smith wrote:
> > Document new partition-dynamic nodes used to provide an OF node for
> > partition registred at runtime by parsers. This is required for nvmem
> > system to declare and detect nvmem-cells.
> >
> > With these special partitions, only the label is required as the parser
> > will provide reg and offset of the mtd. NVMEM will use the data from the
> > parser and provide the NVMEM cells declared in the DTS, "connecting" the
> > dynamic partition with a static declaration of cells in them.
> >
> > Signed-off-by: Ansuel Smith <[email protected]>
> > ---
> > .../mtd/partitions/partition-dynamic.yaml | 54 +++++++++++++++++++
> > 1 file changed, 54 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml
> > new file mode 100644
> > index 000000000000..945128e754ac
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml
> > @@ -0,0 +1,54 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/mtd/partitions/partition-dynamic.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Dynamic Partition
> > +
> > +description: |
> > + This binding describes a single flash partition that is dynamically allocated
> > + by a dedicated parser that is not a fixed-partition parser. To declare a
> > + partition the label is required. This can be used to give a dynamic partition
> > + an OF node so that subsystems like NVMEM can work and provide NVMEM Cells to
>
> 'subsystems like NVMEM' is a Linux detail that shouldn't be in bindings.
>
> > + the system. An example is declaring the partition label and all the NVMEM
> > + cells in it. The parser will detect the correct reg and offset and the NVMEM
> > + will register the cells in it based on the data extracted by the parser.
> > +
> > +maintainers:
> > + - Ansuel Smith <[email protected]>
> > +
> > +properties:
> > + label:
> > + description: The label / name for the partition assigned by the parser at
> > + runtime. This is needed for sybsystem like NVMEM to define cells and
> > + register with this OF node.
>
> 'label' is generally for human consumption and should be opaque to the
> OS (or at least the kernel). Perhaps node name should be used like
> Rafał is doing for nvmem[1]. That appears to be the same problem at the
> next level down.
>
> Rob
>
> [1] https://lore.kernel.org/all/[email protected]/
Ok will add support for node name. Problem is that properties is mandatory
in Documentation and can't be None... so how should I handle this? Keep
label but set it as not required?
--
Ansuel
On Mon, Feb 21, 2022 at 04:57:40PM +0100, Ansuel Smith wrote:
> On Sun, Feb 20, 2022 at 08:36:09PM -0600, Rob Herring wrote:
> > On Sun, 20 Feb 2022 18:39:04 +0100, Ansuel Smith wrote:
> > > Document new partition-dynamic nodes used to provide an OF node for
> > > partition registred at runtime by parsers. This is required for nvmem
> > > system to declare and detect nvmem-cells.
> > >
> > > With these special partitions, only the label is required as the parser
> > > will provide reg and offset of the mtd. NVMEM will use the data from the
> > > parser and provide the NVMEM cells declared in the DTS, "connecting" the
> > > dynamic partition with a static declaration of cells in them.
> > >
> > > Signed-off-by: Ansuel Smith <[email protected]>
> > > ---
> > > .../mtd/partitions/partition-dynamic.yaml | 54 +++++++++++++++++++
> > > 1 file changed, 54 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml
> > >
> >
> > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> > on your patch (DT_CHECKER_FLAGS is new in v5.13):
> >
> > yamllint warnings/errors:
> >
> > dtschema/dtc warnings/errors:
> > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.example.dt.yaml: partitions: '#address-cells', '#size-cells', 'art' do not match any of the regexes: 'pinctrl-[0-9]+'
> > From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml
> >
> > doc reference errors (make refcheckdocs):
> >
> > See https://patchwork.ozlabs.org/patch/1595230
> >
> > This check can fail if there are any dependencies. The base for a patch
> > series is generally the most recent rc1.
> >
> > If you already ran 'make dt_binding_check' and didn't see the above
> > error(s), then make sure 'yamllint' is installed and dt-schema is up to
> > date:
> >
> > pip3 install dtschema --upgrade
> >
> > Please check and re-submit.
> >
>
> Considering the idea of this partition-dynamic, should these warning be
> ignored or the smem-part should include the ref of these new partitions?
We can't have warnings.
> Or should I remove the example?
Doesn't that just kick the problem to actual users?
> (or should I add the example to smem-part instead of partition-dynamic)
That shouldn't matter I think...
Rob
On Sun, Feb 20, 2022 at 06:39:04PM +0100, Ansuel Smith wrote:
> Document new partition-dynamic nodes used to provide an OF node for
> partition registred at runtime by parsers. This is required for nvmem
> system to declare and detect nvmem-cells.
>
> With these special partitions, only the label is required as the parser
> will provide reg and offset of the mtd. NVMEM will use the data from the
> parser and provide the NVMEM cells declared in the DTS, "connecting" the
> dynamic partition with a static declaration of cells in them.
>
> Signed-off-by: Ansuel Smith <[email protected]>
> ---
> .../mtd/partitions/partition-dynamic.yaml | 54 +++++++++++++++++++
> 1 file changed, 54 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml
>
> diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml
> new file mode 100644
> index 000000000000..945128e754ac
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/partitions/partition-dynamic.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mtd/partitions/partition-dynamic.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Dynamic Partition
> +
> +description: |
> + This binding describes a single flash partition that is dynamically allocated
> + by a dedicated parser that is not a fixed-partition parser. To declare a
> + partition the label is required. This can be used to give a dynamic partition
> + an OF node so that subsystems like NVMEM can work and provide NVMEM Cells to
'subsystems like NVMEM' is a Linux detail that shouldn't be in bindings.
> + the system. An example is declaring the partition label and all the NVMEM
> + cells in it. The parser will detect the correct reg and offset and the NVMEM
> + will register the cells in it based on the data extracted by the parser.
> +
> +maintainers:
> + - Ansuel Smith <[email protected]>
> +
> +properties:
> + label:
> + description: The label / name for the partition assigned by the parser at
> + runtime. This is needed for sybsystem like NVMEM to define cells and
> + register with this OF node.
'label' is generally for human consumption and should be opaque to the
OS (or at least the kernel). Perhaps node name should be used like
Rafał is doing for nvmem[1]. That appears to be the same problem at the
next level down.
Rob
[1] https://lore.kernel.org/all/[email protected]/
Greeting,
FYI, we noticed the following commit (built with gcc-9):
commit: 8d892a300af5d531ed5af5684706bab1146db33b ("[RFC RFT PATCH v2 2/2] mtd: core: introduce of support for dynamic partitions")
url: https://github.com/0day-ci/linux/commits/Ansuel-Smith/Add-nvmem-support-for-dynamic-partitions/20220221-014154
base: https://git.kernel.org/cgit/linux/kernel/git/mtd/linux.git mtd/next
patch link: https://lore.kernel.org/linux-mtd/[email protected]
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
If you fix the issue, kindly add following tag
Reported-by: kernel test robot <[email protected]>
[ 2.362523][ T1] BUG: kernel NULL pointer dereference, address: 000003a8
[ 2.362925][ T1] #PF: supervisor read access in kernel mode
[ 2.362925][ T1] #PF: error_code(0x0000) - not-present page
[ 2.362925][ T1] *pde = 00000000
[ 2.362925][ T1] Oops: 0000 [#1]
[ 2.362925][ T1] CPU: 0 PID: 1 Comm: swapper Not tainted 5.17.0-rc1-00042-g8d892a300af5 #1
[ 2.362925][ T1] EIP: mtd_check_of_node (include/linux/device.h:794 drivers/mtd/mtdcore.c:595)
[ 2.362925][ T1] Code: c6 53 83 ec 08 3d 08 ff ff ff 74 0d 83 b8 a8 03 00 00 00 0f 85 a0 00 00 00 8b 86 24 04 00 00 3d 08 ff ff ff 0f 84 8f 00 00 00 <8b> b8 a8 03 00 00 85 ff 0f 84 81 00 00 00 ba 2b cc 38 42 89 f8 e8
All code
========
0: c6 (bad)
1: 53 push %rbx
2: 83 ec 08 sub $0x8,%esp
5: 3d 08 ff ff ff cmp $0xffffff08,%eax
a: 74 0d je 0x19
c: 83 b8 a8 03 00 00 00 cmpl $0x0,0x3a8(%rax)
13: 0f 85 a0 00 00 00 jne 0xb9
19: 8b 86 24 04 00 00 mov 0x424(%rsi),%eax
1f: 3d 08 ff ff ff cmp $0xffffff08,%eax
24: 0f 84 8f 00 00 00 je 0xb9
2a:* 8b b8 a8 03 00 00 mov 0x3a8(%rax),%edi <-- trapping instruction
30: 85 ff test %edi,%edi
32: 0f 84 81 00 00 00 je 0xb9
38: ba 2b cc 38 42 mov $0x4238cc2b,%edx
3d: 89 f8 mov %edi,%eax
3f: e8 .byte 0xe8
Code starting with the faulting instruction
===========================================
0: 8b b8 a8 03 00 00 mov 0x3a8(%rax),%edi
6: 85 ff test %edi,%edi
8: 0f 84 81 00 00 00 je 0x8f
e: ba 2b cc 38 42 mov $0x4238cc2b,%edx
13: 89 f8 mov %edi,%eax
15: e8 .byte 0xe8
[ 2.362925][ T1] EAX: 00000000 EBX: 44e20800 ECX: 00000000 EDX: 00000000
[ 2.362925][ T1] ESI: 44e20800 EDI: 00000001 EBP: 403a5e44 ESP: 403a5e30
[ 2.362925][ T1] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010213
[ 2.362925][ T1] CR0: 80050033 CR2: 000003a8 CR3: 02d0c000 CR4: 000406d0
[ 2.362925][ T1] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 2.362925][ T1] DR6: fffe0ff0 DR7: 00000400
[ 2.362925][ T1] Call Trace:
[ 2.362925][ T1] ? add_mtd_device (include/linux/device.h:793 include/linux/mtd/mtd.h:469 drivers/mtd/mtdcore.c:731)
[ 2.362925][ T1] ? lockdep_init_map_type (kernel/locking/lockdep.c:4810)
[ 2.362925][ T1] ? debug_mutex_init (kernel/locking/mutex-debug.c:89)
[ 2.362925][ T1] ? __mutex_init (kernel/locking/mutex.c:53)
[ 2.362925][ T1] ? mtd_device_parse_register (drivers/mtd/mtdcore.c:1027)
[ 2.362925][ T1] ? mtdram_init_device (drivers/mtd/devices/mtdram.c:146)
[ 2.362925][ T1] ? init_mtdram (drivers/mtd/devices/mtdram.c:171)
[ 2.362925][ T1] ? init_pmc551 (drivers/mtd/devices/mtdram.c:153)
[ 2.362925][ T1] ? do_one_initcall (init/main.c:1300)
[ 2.362925][ T1] ? parse_args (kernel/params.c:131 kernel/params.c:188)
[ 2.362925][ T1] ? do_basic_setup (init/main.c:1372 init/main.c:1389 init/main.c:1408)
[ 2.362925][ T1] ? kernel_init_freeable (init/main.c:1615)
[ 2.362925][ T1] ? rest_init (init/main.c:1494)
[ 2.362925][ T1] ? kernel_init (init/main.c:1504)
[ 2.362925][ T1] ? ret_from_fork (arch/x86/entry/entry_32.S:772)
[ 2.362925][ T1] Modules linked in:
[ 2.362925][ T1] CR2: 00000000000003a8
[ 2.362925][ T1] ---[ end trace 0000000000000000 ]---
[ 2.362925][ T1] EIP: mtd_check_of_node (include/linux/device.h:794 drivers/mtd/mtdcore.c:595)
[ 2.362925][ T1] Code: c6 53 83 ec 08 3d 08 ff ff ff 74 0d 83 b8 a8 03 00 00 00 0f 85 a0 00 00 00 8b 86 24 04 00 00 3d 08 ff ff ff 0f 84 8f 00 00 00 <8b> b8 a8 03 00 00 85 ff 0f 84 81 00 00 00 ba 2b cc 38 42 89 f8 e8
All code
========
0: c6 (bad)
1: 53 push %rbx
2: 83 ec 08 sub $0x8,%esp
5: 3d 08 ff ff ff cmp $0xffffff08,%eax
a: 74 0d je 0x19
c: 83 b8 a8 03 00 00 00 cmpl $0x0,0x3a8(%rax)
13: 0f 85 a0 00 00 00 jne 0xb9
19: 8b 86 24 04 00 00 mov 0x424(%rsi),%eax
1f: 3d 08 ff ff ff cmp $0xffffff08,%eax
24: 0f 84 8f 00 00 00 je 0xb9
2a:* 8b b8 a8 03 00 00 mov 0x3a8(%rax),%edi <-- trapping instruction
30: 85 ff test %edi,%edi
32: 0f 84 81 00 00 00 je 0xb9
38: ba 2b cc 38 42 mov $0x4238cc2b,%edx
3d: 89 f8 mov %edi,%eax
3f: e8 .byte 0xe8
Code starting with the faulting instruction
===========================================
0: 8b b8 a8 03 00 00 mov 0x3a8(%rax),%edi
6: 85 ff test %edi,%edi
8: 0f 84 81 00 00 00 je 0x8f
e: ba 2b cc 38 42 mov $0x4238cc2b,%edx
13: 89 f8 mov %edi,%eax
15: e8 .byte 0xe8
To reproduce:
# build kernel
cd linux
cp config-5.17.0-rc1-00042-g8d892a300af5 .config
make HOSTCC=gcc-9 CC=gcc-9 ARCH=i386 olddefconfig prepare modules_prepare bzImage modules
make HOSTCC=gcc-9 CC=gcc-9 ARCH=i386 INSTALL_MOD_PATH=<mod-install-dir> modules_install
cd <mod-install-dir>
find lib/ | cpio -o -H newc --quiet | gzip > modules.cgz
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> -m modules.cgz job-script # job-script is attached in this email
# if come across any failure that blocks the test,
# please remove ~/.lkp and /lkp dir to run from a clean state.
---
0DAY/LKP+ Test Infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/[email protected] Intel Corporation
Thanks,
Oliver Sang