10:22 a.m.
Hi Dave,
crash currently fails on linux-next kernel due to another radix-tree rework.
The patch attached fixes this.
BTW, is there an 'official policy' about fixing linux-next issues, as commits
can be changed/dropped on their way to the linux repo?
Thanks
Philipp
Philipp Rudo (1):
Fix for XArray/radix_tree rework on linux-next
bpf.c | 7 ++++++-
ipcs.c | 5 ++++-
task.c | 15 +++++++++++----
3 files changed, 21 insertions(+), 6 deletions(-)
--
2.16.4
10:22 a.m.
New subject: [PATCH 1/1] Fix for XArray/radix_tree rework on linux-next
Commit dd12805ed1db7 ("XArray: Remove radix tree compatibility") on
linux-next changes the definition of 'radix_tree_root' back to be a struct.
The content however differs from the original 'struct radix_tree_root'.
Thus attempts to debug current linux-next kernels fail with 'radix trees do
not exist or have changed their format'. Because the new 'struct
radix_tree_root' and 'struct xarray' have nearly the same layout the
functionality for XArrays can be reused.
Signed-off-by: Philipp Rudo <prudo(a)linux.ibm.com>
---
bpf.c | 7 ++++++-
ipcs.c | 5 ++++-
task.c | 15 +++++++++++----
3 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/bpf.c b/bpf.c
index 6eacb9a..056e286 100644
--- a/bpf.c
+++ b/bpf.c
@@ -221,7 +221,12 @@ bpf_init(struct bpf_info *bpf)
bpf->idr_type = IDR_ORIG;
do_old_idr(IDR_ORIG_INIT, 0, NULL);
} else if (STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"),
"radix_tree_root"))
- bpf->idr_type = IDR_RADIX;
+ if (MEMBER_EXISTS("radix_tree_root", "rnode"))
+ bpf->idr_type = IDR_RADIX;
+ else if (MEMBER_EXISTS("radix_tree_root", "xa_head"))
+ bpf->idr_type = IDR_XARRAY;
+ else
+ error(FATAL, "cannot determine IDR list type\n");
else if (STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"),
"xarray"))
bpf->idr_type = IDR_XARRAY;
else
diff --git a/ipcs.c b/ipcs.c
index 2553bac..3c26620 100644
--- a/ipcs.c
+++ b/ipcs.c
@@ -206,7 +206,10 @@ ipcs_init(void)
if (STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"), "xarray"))
ipcs_table.init_flags |= IDR_XARRAY;
else
- ipcs_table.init_flags |= IDR_RADIX;
+ if (MEMBER_EXISTS("radix_tree_root", "rnode"))
+ ipcs_table.init_flags |= IDR_RADIX;
+ else if (MEMBER_EXISTS("radix_tree_root", "xa_head"))
+ ipcs_table.init_flags |= IDR_XARRAY;
} else
ipcs_table.init_flags |= IDR_ORIG;
diff --git a/task.c b/task.c
index cd118e5..36a90d6 100644
--- a/task.c
+++ b/task.c
@@ -507,10 +507,17 @@ task_init(void)
OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
tt->flags |= PID_XARRAY;
} else if STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"),
"radix_tree_root") {
- tt->refresh_task_table = refresh_radix_tree_task_table;
- tt->pid_radix_tree = symbol_value("init_pid_ns") +
- OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
- tt->flags |= PID_RADIX_TREE;
+ if (MEMBER_EXISTS("radix_tree_root", "rnode")) {
+ tt->refresh_task_table = refresh_radix_tree_task_table;
+ tt->pid_radix_tree = symbol_value("init_pid_ns") +
+ OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
+ tt->flags |= PID_RADIX_TREE;
+ } else if (MEMBER_EXISTS("radix_tree_root", "xa_head")) {
+ tt->refresh_task_table = refresh_xarray_task_table;
+ tt->pid_xarray = symbol_value("init_pid_ns") +
+ OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
+ tt->flags |= PID_XARRAY;
+ }
} else
error(FATAL, "unknown pid_namespace.idr type: %s\n",
MEMBER_TYPE_NAME("idr", "idr_rt"));
--
2.16.4
2:55 p.m.
New subject: [PATCH v2] Fix for XArray/radix_tree rework on linux-next
----- Original Message -----
Commit dd12805ed1db7 ("XArray: Remove radix tree compatibility") on
linux-next changes the definition of 'radix_tree_root' back to be a struct.
The content however differs from the original 'struct radix_tree_root'.
Thus attempts to debug current linux-next kernels fail with 'radix trees do
not exist or have changed their format'. Because the new 'struct
radix_tree_root' and 'struct xarray' have nearly the same layout the
functionality for XArrays can be reused.
Hi Philipp,
The patch looks good, and doesn't break backwards-compatibility. If by chance
Matthew changes the linux-next kernel patch, this one can always be revisited.
Queued for crash-7.2.6:
https://github.com/crash-utility/crash/commit/4d551127014e3ad4014e6e8811b...
Thanks,
Dave
Signed-off-by: Philipp Rudo <prudo linux ibm com>
---
bpf.c | 7 ++++++-
filesys.c | 4 +++-
ipcs.c | 5 ++++-
kernel.c | 11 ++++++++---
task.c | 15 +++++++++++----
tools.c | 5 ++++-
6 files changed, 36 insertions(+), 11 deletions(-)
diff --git a/bpf.c b/bpf.c
index 6eacb9a..056e286 100644
--- a/bpf.c
+++ b/bpf.c
@@ -221,7 +221,12 @@ bpf_init(struct bpf_info *bpf)
bpf->idr_type = IDR_ORIG;
do_old_idr(IDR_ORIG_INIT, 0, NULL);
} else if (STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"),
"radix_tree_root"))
- bpf->idr_type = IDR_RADIX;
+ if (MEMBER_EXISTS("radix_tree_root", "rnode"))
+ bpf->idr_type = IDR_RADIX;
+ else if (MEMBER_EXISTS("radix_tree_root", "xa_head"))
+ bpf->idr_type = IDR_XARRAY;
+ else
+ error(FATAL, "cannot determine IDR list type\n");
else if (STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"),
"xarray"))
bpf->idr_type = IDR_XARRAY;
else
diff --git a/filesys.c b/filesys.c
index 9305627..6abba0b 100644
--- a/filesys.c
+++ b/filesys.c
@@ -2217,7 +2217,9 @@ dump_inode_page_cache_info(ulong inode)
xarray = root_rnode = count = 0;
if (MEMBER_EXISTS("address_space", "i_pages") &&
- STREQ(MEMBER_TYPE_NAME("address_space", "i_pages"),
"xarray"))
+ (STREQ(MEMBER_TYPE_NAME("address_space", "i_pages"),
"xarray") ||
+ (STREQ(MEMBER_TYPE_NAME("address_space", "i_pages"),
"radix_tree_root") &&
+ MEMBER_EXISTS("radix_tree_root", "xa_head"))))
xarray = i_mapping + OFFSET(address_space_page_tree);
else
root_rnode = i_mapping + OFFSET(address_space_page_tree);
diff --git a/ipcs.c b/ipcs.c
index 2553bac..3c26620 100644
--- a/ipcs.c
+++ b/ipcs.c
@@ -206,7 +206,10 @@ ipcs_init(void)
if (STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"), "xarray"))
ipcs_table.init_flags |= IDR_XARRAY;
else
- ipcs_table.init_flags |= IDR_RADIX;
+ if (MEMBER_EXISTS("radix_tree_root", "rnode"))
+ ipcs_table.init_flags |= IDR_RADIX;
+ else if (MEMBER_EXISTS("radix_tree_root", "xa_head"))
+ ipcs_table.init_flags |= IDR_XARRAY;
} else
ipcs_table.init_flags |= IDR_ORIG;
diff --git a/kernel.c b/kernel.c
index 9f5ba89..8080097 100644
--- a/kernel.c
+++ b/kernel.c
@@ -534,9 +534,14 @@ kernel_init()
if (kernel_symbol_exists("irq_desc_tree")) {
get_symbol_type("irq_desc_tree", NULL, &req);
- kt->flags2 |= STREQ(req.type_tag_name, "xarray") ?
- IRQ_DESC_TREE_XARRAY : IRQ_DESC_TREE_RADIX;
-
+ if (STREQ(req.type_tag_name, "xarray")) {
+ kt->flags2 |= IRQ_DESC_TREE_XARRAY;
+ } else {
+ if (MEMBER_EXISTS("radix_tree_root", "xa_head"))
+ kt->flags2 |= IRQ_DESC_TREE_XARRAY;
+ else
+ kt->flags2 |= IRQ_DESC_TREE_RADIX;
+ }
}
STRUCT_SIZE_INIT(irq_data, "irq_data");
if (VALID_STRUCT(irq_data)) {
diff --git a/task.c b/task.c
index cd118e5..36a90d6 100644
--- a/task.c
+++ b/task.c
@@ -507,10 +507,17 @@ task_init(void)
OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
tt->flags |= PID_XARRAY;
} else if STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"),
"radix_tree_root") {
- tt->refresh_task_table = refresh_radix_tree_task_table;
- tt->pid_radix_tree = symbol_value("init_pid_ns") +
- OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
- tt->flags |= PID_RADIX_TREE;
+ if (MEMBER_EXISTS("radix_tree_root", "rnode")) {
+ tt->refresh_task_table = refresh_radix_tree_task_table;
+ tt->pid_radix_tree = symbol_value("init_pid_ns") +
+ OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
+ tt->flags |= PID_RADIX_TREE;
+ } else if (MEMBER_EXISTS("radix_tree_root", "xa_head")) {
+ tt->refresh_task_table = refresh_xarray_task_table;
+ tt->pid_xarray = symbol_value("init_pid_ns") +
+ OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
+ tt->flags |= PID_XARRAY;
+ }
} else
error(FATAL, "unknown pid_namespace.idr type: %s\n",
MEMBER_TYPE_NAME("idr", "idr_rt"));
diff --git a/tools.c b/tools.c
index 72ec76a..43b838a 100644
--- a/tools.c
+++ b/tools.c
@@ -4241,7 +4241,10 @@ cmd_tree()
}
if (STRNEQ(optarg, "ra"))
- type_flag = RADIXTREE_REQUEST;
+ if (MEMBER_EXISTS("radix_tree_root", "xa_head"))
+ type_flag = XARRAY_REQUEST;
+ else
+ type_flag = RADIXTREE_REQUEST;
else if (STRNEQ(optarg, "rb"))
type_flag = RBTREE_REQUEST;
else if (STRNEQ(optarg, "x"))
--
2.16.4
5:07 a.m.
New subject: [PATCH v2] Fix for XArray/radix_tree rework on linux-next
Hi Dave,
On Fri, 22 Mar 2019 15:55:36 -0400 (EDT)
Dave Anderson <anderson(a)redhat.com> wrote:
----- Original Message -----
>
> Commit dd12805ed1db7 ("XArray: Remove radix tree compatibility") on
> linux-next changes the definition of 'radix_tree_root' back to be a struct.
> The content however differs from the original 'struct radix_tree_root'.
> Thus attempts to debug current linux-next kernels fail with 'radix trees do
> not exist or have changed their format'. Because the new 'struct
> radix_tree_root' and 'struct xarray' have nearly the same layout the
> functionality for XArrays can be reused.
Hi Philipp,
The patch looks good, and doesn't break backwards-compatibility. If by chance
Matthew changes the linux-next kernel patch, this one can always be revisited.
Queued for crash-7.2.6:
https://github.com/crash-utility/crash/commit/4d551127014e3ad4014e6e8811b...
Great thanks!
I'll keep an eye on the commit and send a fixup if something changes.
Thanks
Philipp
Thanks,
Dave
>
> Signed-off-by: Philipp Rudo <prudo linux ibm com>
> ---
> bpf.c | 7 ++++++-
> filesys.c | 4 +++-
> ipcs.c | 5 ++++-
> kernel.c | 11 ++++++++---
> task.c | 15 +++++++++++----
> tools.c | 5 ++++-
> 6 files changed, 36 insertions(+), 11 deletions(-)
>
> diff --git a/bpf.c b/bpf.c
> index 6eacb9a..056e286 100644
> --- a/bpf.c
> +++ b/bpf.c
> @@ -221,7 +221,12 @@ bpf_init(struct bpf_info *bpf)
> bpf->idr_type = IDR_ORIG;
> do_old_idr(IDR_ORIG_INIT, 0, NULL);
> } else if (STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"),
"radix_tree_root"))
> - bpf->idr_type = IDR_RADIX;
> + if (MEMBER_EXISTS("radix_tree_root", "rnode"))
> + bpf->idr_type = IDR_RADIX;
> + else if (MEMBER_EXISTS("radix_tree_root", "xa_head"))
> + bpf->idr_type = IDR_XARRAY;
> + else
> + error(FATAL, "cannot determine IDR list type\n");
> else if (STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"),
"xarray"))
> bpf->idr_type = IDR_XARRAY;
> else
> diff --git a/filesys.c b/filesys.c
> index 9305627..6abba0b 100644
> --- a/filesys.c
> +++ b/filesys.c
> @@ -2217,7 +2217,9 @@ dump_inode_page_cache_info(ulong inode)
>
> xarray = root_rnode = count = 0;
> if (MEMBER_EXISTS("address_space", "i_pages") &&
> - STREQ(MEMBER_TYPE_NAME("address_space", "i_pages"),
"xarray"))
> + (STREQ(MEMBER_TYPE_NAME("address_space", "i_pages"),
"xarray") ||
> + (STREQ(MEMBER_TYPE_NAME("address_space", "i_pages"),
"radix_tree_root") &&
> + MEMBER_EXISTS("radix_tree_root", "xa_head"))))
> xarray = i_mapping + OFFSET(address_space_page_tree);
> else
> root_rnode = i_mapping + OFFSET(address_space_page_tree);
> diff --git a/ipcs.c b/ipcs.c
> index 2553bac..3c26620 100644
> --- a/ipcs.c
> +++ b/ipcs.c
> @@ -206,7 +206,10 @@ ipcs_init(void)
> if (STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"),
"xarray"))
> ipcs_table.init_flags |= IDR_XARRAY;
> else
> - ipcs_table.init_flags |= IDR_RADIX;
> + if (MEMBER_EXISTS("radix_tree_root", "rnode"))
> + ipcs_table.init_flags |= IDR_RADIX;
> + else if (MEMBER_EXISTS("radix_tree_root", "xa_head"))
> + ipcs_table.init_flags |= IDR_XARRAY;
> } else
> ipcs_table.init_flags |= IDR_ORIG;
>
> diff --git a/kernel.c b/kernel.c
> index 9f5ba89..8080097 100644
> --- a/kernel.c
> +++ b/kernel.c
> @@ -534,9 +534,14 @@ kernel_init()
>
> if (kernel_symbol_exists("irq_desc_tree")) {
> get_symbol_type("irq_desc_tree", NULL, &req);
> - kt->flags2 |= STREQ(req.type_tag_name, "xarray") ?
> - IRQ_DESC_TREE_XARRAY : IRQ_DESC_TREE_RADIX;
> -
> + if (STREQ(req.type_tag_name, "xarray")) {
> + kt->flags2 |= IRQ_DESC_TREE_XARRAY;
> + } else {
> + if (MEMBER_EXISTS("radix_tree_root", "xa_head"))
> + kt->flags2 |= IRQ_DESC_TREE_XARRAY;
> + else
> + kt->flags2 |= IRQ_DESC_TREE_RADIX;
> + }
> }
> STRUCT_SIZE_INIT(irq_data, "irq_data");
> if (VALID_STRUCT(irq_data)) {
> diff --git a/task.c b/task.c
> index cd118e5..36a90d6 100644
> --- a/task.c
> +++ b/task.c
> @@ -507,10 +507,17 @@ task_init(void)
> OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
> tt->flags |= PID_XARRAY;
> } else if STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"),
"radix_tree_root") {
> - tt->refresh_task_table = refresh_radix_tree_task_table;
> - tt->pid_radix_tree = symbol_value("init_pid_ns") +
> - OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
> - tt->flags |= PID_RADIX_TREE;
> + if (MEMBER_EXISTS("radix_tree_root", "rnode")) {
> + tt->refresh_task_table = refresh_radix_tree_task_table;
> + tt->pid_radix_tree = symbol_value("init_pid_ns") +
> + OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
> + tt->flags |= PID_RADIX_TREE;
> + } else if (MEMBER_EXISTS("radix_tree_root", "xa_head")) {
> + tt->refresh_task_table = refresh_xarray_task_table;
> + tt->pid_xarray = symbol_value("init_pid_ns") +
> + OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
> + tt->flags |= PID_XARRAY;
> + }
> } else
> error(FATAL, "unknown pid_namespace.idr type: %s\n",
> MEMBER_TYPE_NAME("idr", "idr_rt"));
> diff --git a/tools.c b/tools.c
> index 72ec76a..43b838a 100644
> --- a/tools.c
> +++ b/tools.c
> @@ -4241,7 +4241,10 @@ cmd_tree()
> }
>
> if (STRNEQ(optarg, "ra"))
> - type_flag = RADIXTREE_REQUEST;
> + if (MEMBER_EXISTS("radix_tree_root", "xa_head"))
> + type_flag = XARRAY_REQUEST;
> + else
> + type_flag = RADIXTREE_REQUEST;
> else if (STRNEQ(optarg, "rb"))
> type_flag = RBTREE_REQUEST;
> else if (STRNEQ(optarg, "x"))
> --
> 2.16.4
>
10:46 a.m.
----- Original Message -----
Hi Dave,
crash currently fails on linux-next kernel due to another radix-tree rework.
The patch attached fixes this.
BTW, is there an 'official policy' about fixing linux-next issues, as commits
can be changed/dropped on their way to the linux repo?
Hi Philipp,
Not really, although since your fixes will not affect the current mechanism,
they should be safe to apply.
But I note that your changes only address the basic task initialization
sequence and the "bpf" and the "ipcs" commands. Did you also look
into the "files -p", "irq" and "tree -t -p" options?
Thanks,
Dave
PS: the
"
Thanks
Philipp
Philipp Rudo (1):
Fix for XArray/radix_tree rework on linux-next
bpf.c | 7 ++++++-
ipcs.c | 5 ++++-
task.c | 15 +++++++++++----
3 files changed, 21 insertions(+), 6 deletions(-)
--
2.16.4
9:27 a.m.
Hi Dave,
On Thu, 21 Mar 2019 11:46:33 -0400 (EDT)
Dave Anderson <anderson(a)redhat.com> wrote:
----- Original Message -----
> Hi Dave,
>
> crash currently fails on linux-next kernel due to another radix-tree rework.
> The patch attached fixes this.
>
> BTW, is there an 'official policy' about fixing linux-next issues, as
commits
> can be changed/dropped on their way to the linux repo?
Hi Philipp,
Not really, although since your fixes will not affect the current mechanism,
they should be safe to apply.
Ok. I'm mainly asking because we are building up an environment for automated
(kernel) tests on s390, including tests on linux-next. In this context we also
have a test if crash starts with a given kernel. That's why I expect more
fixes/bugs like this to come in the future.
I'm not really sure what's the best way to handle them. On one hand it would be
nice when crash could read those kernels. On the other I don't want to clutter
the code with fixes for patches that don't make it upstream. Do you have a
preferred way to handle similar bugs in the future?
But I note that your changes only address the basic task
initialization
sequence and the "bpf" and the "ipcs" commands. Did you also look
into the "files -p", "irq" and "tree -t -p" options?
You are right I missed those. "files -p" however seems to work fine with the
patch I sent. For the other two I'll prepare a v2.
Thanks
Philipp
Thanks,
Dave
PS: the
"
>
> Thanks
> Philipp
>
> Philipp Rudo (1):
> Fix for XArray/radix_tree rework on linux-next
>
> bpf.c | 7 ++++++-
> ipcs.c | 5 ++++-
> task.c | 15 +++++++++++----
> 3 files changed, 21 insertions(+), 6 deletions(-)
>
> --
> 2.16.4
>
>
9:38 a.m.
----- Original Message -----
Hi Dave,
On Thu, 21 Mar 2019 11:46:33 -0400 (EDT)
Dave Anderson <anderson(a)redhat.com> wrote:
> ----- Original Message -----
> > Hi Dave,
> >
> > crash currently fails on linux-next kernel due to another radix-tree rework.
> > The patch attached fixes this.
> >
> > BTW, is there an 'official policy' about fixing linux-next issues, as
commits
> > can be changed/dropped on their way to the linux repo?
>
> Hi Philipp,
>
> Not really, although since your fixes will not affect the current mechanism,
> they should be safe to apply.
Ok. I'm mainly asking because we are building up an environment for automated
(kernel) tests on s390, including tests on linux-next. In this context we also
have a test if crash starts with a given kernel. That's why I expect more
fixes/bugs like this to come in the future.
Excellent -- I appreciate that!
I'm not really sure what's the best way to handle them. On one hand it would be
nice when crash could read those kernels. On the other I don't want to clutter
the code with fixes for patches that don't make it upstream. Do you have a
preferred way to handle similar bugs in the future?
Recently I have been trying to be as proactive as possible, although I only go as
far as sanity-testing upstream -rc kernels as they get released (i.e. not linux-next).
On the other hand, I'm about to check in the first phase of support for ARM64 52-bit
virtual addressing, which has not yet made it into the mainstream kernel. In that
case, it's pretty certain that those changes will be accepted. And I would presume
that stuff that Matthew Wilcox has queued up for Xarray are a pretty safe bet as
well. So let's take it on a case-by-case basis.
> But I note that your changes only address the basic task initialization
> sequence and the "bpf" and the "ipcs" commands. Did you also
look
> into the "files -p", "irq" and "tree -t -p" options?
You are right I missed those. "files -p" however seems to work fine with the
patch I sent. For the other two I'll prepare a v2.
Nice -- thanks!
Dave
Thanks
Philipp
>
> Thanks,
> Dave
>
> PS: the
>
> "
> >
> > Thanks
> > Philipp
> >
> > Philipp Rudo (1):
> > Fix for XArray/radix_tree rework on linux-next
> >
> > bpf.c | 7 ++++++-
> > ipcs.c | 5 ++++-
> > task.c | 15 +++++++++++----
> > 3 files changed, 21 insertions(+), 6 deletions(-)
> >
> > --
> > 2.16.4
> >
> >
>
11 a.m.
On Fri, 22 Mar 2019 10:38:31 -0400 (EDT)
Dave Anderson <anderson(a)redhat.com> wrote:
----- Original Message -----
> Hi Dave,
>
>
> On Thu, 21 Mar 2019 11:46:33 -0400 (EDT)
> Dave Anderson <anderson(a)redhat.com> wrote:
>
> > ----- Original Message -----
> > > Hi Dave,
> > >
> > > crash currently fails on linux-next kernel due to another radix-tree
rework.
> > > The patch attached fixes this.
> > >
> > > BTW, is there an 'official policy' about fixing linux-next issues,
as commits
> > > can be changed/dropped on their way to the linux repo?
> >
> > Hi Philipp,
> >
> > Not really, although since your fixes will not affect the current mechanism,
> > they should be safe to apply.
>
> Ok. I'm mainly asking because we are building up an environment for automated
> (kernel) tests on s390, including tests on linux-next. In this context we also
> have a test if crash starts with a given kernel. That's why I expect more
> fixes/bugs like this to come in the future.
Excellent -- I appreciate that!
You're welcome.
>
> I'm not really sure what's the best way to handle them. On one hand it would
be
> nice when crash could read those kernels. On the other I don't want to clutter
> the code with fixes for patches that don't make it upstream. Do you have a
> preferred way to handle similar bugs in the future?
Recently I have been trying to be as proactive as possible, although I only go as
far as sanity-testing upstream -rc kernels as they get released (i.e. not linux-next).
On the other hand, I'm about to check in the first phase of support for ARM64 52-bit
virtual addressing, which has not yet made it into the mainstream kernel. In that
case, it's pretty certain that those changes will be accepted. And I would presume
that stuff that Matthew Wilcox has queued up for Xarray are a pretty safe bet as
well. So let's take it on a case-by-case basis.
Yeah, Matthew Wilcox are a pretty save bet. It's more patches like the one that
caused the 'MAGIC_START not found' Mikhail is working on, that bugs me.
Great. So we keep sending you the patches. Then you can decide if you feel
comfortable enough to include them or better wait till the code is accepted
upstream.
>
> > But I note that your changes only address the basic task initialization
> > sequence and the "bpf" and the "ipcs" commands. Did you
also look
> > into the "files -p", "irq" and "tree -t -p"
options?
>
> You are right I missed those. "files -p" however seems to work fine with
the
> patch I sent. For the other two I'll prepare a v2.
Nice -- thanks!
It's almost on the way. The only problem I have is that 'bpf' only prints a
blank line for linux-next but works totally fine on upstream. So I currently
don't know if there's still a problem or if there simply is no bpf program. At
least the error is gone :)
Thanks
Philipp
Dave
> Thanks
> Philipp
>
> >
> > Thanks,
> > Dave
> >
> > PS: the
> >
> > "
> > >
> > > Thanks
> > > Philipp
> > >
> > > Philipp Rudo (1):
> > > Fix for XArray/radix_tree rework on linux-next
> > >
> > > bpf.c | 7 ++++++-
> > > ipcs.c | 5 ++++-
> > > task.c | 15 +++++++++++----
> > > 3 files changed, 21 insertions(+), 6 deletions(-)
> > >
> > > --
> > > 2.16.4
> > >
> > >
> >
>
>
11:34 a.m.
----- Original Message -----
On Fri, 22 Mar 2019 10:38:31 -0400 (EDT)
Dave Anderson <anderson(a)redhat.com> wrote:
> ----- Original Message -----
> > Hi Dave,
> >
> >
> > On Thu, 21 Mar 2019 11:46:33 -0400 (EDT)
> > Dave Anderson <anderson(a)redhat.com> wrote:
> >
> > > ----- Original Message -----
> > > > Hi Dave,
> > > >
> > > > crash currently fails on linux-next kernel due to another radix-tree
> > > > rework.
> > > > The patch attached fixes this.
> > > >
> > > > BTW, is there an 'official policy' about fixing linux-next
issues, as
> > > > commits
> > > > can be changed/dropped on their way to the linux repo?
> > >
> > > Hi Philipp,
> > >
> > > Not really, although since your fixes will not affect the current
> > > mechanism,
> > > they should be safe to apply.
> >
> > Ok. I'm mainly asking because we are building up an environment for
> > automated
> > (kernel) tests on s390, including tests on linux-next. In this context we
> > also
> > have a test if crash starts with a given kernel. That's why I expect more
> > fixes/bugs like this to come in the future.
>
> Excellent -- I appreciate that!
You're welcome.
> >
> > I'm not really sure what's the best way to handle them. On one hand it
> > would be
> > nice when crash could read those kernels. On the other I don't want to
> > clutter
> > the code with fixes for patches that don't make it upstream. Do you have
> > a
> > preferred way to handle similar bugs in the future?
>
> Recently I have been trying to be as proactive as possible, although I only
> go as
> far as sanity-testing upstream -rc kernels as they get released (i.e. not
> linux-next).
> On the other hand, I'm about to check in the first phase of support for
> ARM64 52-bit
> virtual addressing, which has not yet made it into the mainstream kernel.
> In that
> case, it's pretty certain that those changes will be accepted. And I would
> presume
> that stuff that Matthew Wilcox has queued up for Xarray are a pretty safe
> bet as
> well. So let's take it on a case-by-case basis.
Yeah, Matthew Wilcox are a pretty save bet. It's more patches like the one
that
caused the 'MAGIC_START not found' Mikhail is working on, that bugs me.
Great. So we keep sending you the patches. Then you can decide if you feel
comfortable enough to include them or better wait till the code is accepted
upstream.
> >
> > > But I note that your changes only address the basic task initialization
> > > sequence and the "bpf" and the "ipcs" commands. Did
you also look
> > > into the "files -p", "irq" and "tree -t -p"
options?
> >
> > You are right I missed those. "files -p" however seems to work fine
with
> > the
> > patch I sent. For the other two I'll prepare a v2.
>
> Nice -- thanks!
It's almost on the way. The only problem I have is that 'bpf' only prints a
blank line for linux-next but works totally fine on upstream. So I currently
don't know if there's still a problem or if there simply is no bpf program.
At least the error is gone :)
That's most likely the case. If you print out the "prog_idr" or
"map_idr" structures,
their "xa_head" pointer are probably NULL.
Dave
Thanks
Philipp
>
> Dave
>
>
> > Thanks
> > Philipp
> >
> > >
> > > Thanks,
> > > Dave
> > >
> > > PS: the
> > >
> > > "
> > > >
> > > > Thanks
> > > > Philipp
> > > >
> > > > Philipp Rudo (1):
> > > > Fix for XArray/radix_tree rework on linux-next
> > > >
> > > > bpf.c | 7 ++++++-
> > > > ipcs.c | 5 ++++-
> > > > task.c | 15 +++++++++++----
> > > > 3 files changed, 21 insertions(+), 6 deletions(-)
> > > >
> > > > --
> > > > 2.16.4
> > > >
> > > >
> > >
> >
> >
>
11:48 a.m.
On Fri, 22 Mar 2019 12:34:18 -0400 (EDT)
Dave Anderson <anderson(a)redhat.com> wrote:
> It's almost on the way. The only problem I have is that
'bpf' only prints a
> blank line for linux-next but works totally fine on upstream. So I currently
> don't know if there's still a problem or if there simply is no bpf program.
> At least the error is gone :)
That's most likely the case. If you print out the "prog_idr" or
"map_idr" structures,
their "xa_head" pointer are probably NULL.
You are right. I also found some warnings in dmes not allowing BPF. Looks like
there is some problem in linux-next.
v2 is on its way.
Philipp
Dave
> Thanks
> Philipp
>
> >
> > Dave
> >
> >
> > > Thanks
> > > Philipp
> > >
> > > >
> > > > Thanks,
> > > > Dave
> > > >
> > > > PS: the
> > > >
> > > > "
> > > > >
> > > > > Thanks
> > > > > Philipp
> > > > >
> > > > > Philipp Rudo (1):
> > > > > Fix for XArray/radix_tree rework on linux-next
> > > > >
> > > > > bpf.c | 7 ++++++-
> > > > > ipcs.c | 5 ++++-
> > > > > task.c | 15 +++++++++++----
> > > > > 3 files changed, 21 insertions(+), 6 deletions(-)
> > > > >
> > > > > --
> > > > > 2.16.4
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
11:46 a.m.
New subject: [PATCH v2] Fix for XArray/radix_tree rework on linux-next
Commit dd12805ed1db7 ("XArray: Remove radix tree compatibility") on
linux-next changes the definition of 'radix_tree_root' back to be a struct.
The content however differs from the original 'struct radix_tree_root'.
Thus attempts to debug current linux-next kernels fail with 'radix trees do
not exist or have changed their format'. Because the new 'struct
radix_tree_root' and 'struct xarray' have nearly the same layout the
functionality for XArrays can be reused.
Signed-off-by: Philipp Rudo <prudo(a)linux.ibm.com>
---
bpf.c | 7 ++++++-
filesys.c | 4 +++-
ipcs.c | 5 ++++-
kernel.c | 11 ++++++++---
task.c | 15 +++++++++++----
tools.c | 5 ++++-
6 files changed, 36 insertions(+), 11 deletions(-)
diff --git a/bpf.c b/bpf.c
index 6eacb9a..056e286 100644
--- a/bpf.c
+++ b/bpf.c
@@ -221,7 +221,12 @@ bpf_init(struct bpf_info *bpf)
bpf->idr_type = IDR_ORIG;
do_old_idr(IDR_ORIG_INIT, 0, NULL);
} else if (STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"),
"radix_tree_root"))
- bpf->idr_type = IDR_RADIX;
+ if (MEMBER_EXISTS("radix_tree_root", "rnode"))
+ bpf->idr_type = IDR_RADIX;
+ else if (MEMBER_EXISTS("radix_tree_root", "xa_head"))
+ bpf->idr_type = IDR_XARRAY;
+ else
+ error(FATAL, "cannot determine IDR list type\n");
else if (STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"),
"xarray"))
bpf->idr_type = IDR_XARRAY;
else
diff --git a/filesys.c b/filesys.c
index 9305627..6abba0b 100644
--- a/filesys.c
+++ b/filesys.c
@@ -2217,7 +2217,9 @@ dump_inode_page_cache_info(ulong inode)
xarray = root_rnode = count = 0;
if (MEMBER_EXISTS("address_space", "i_pages") &&
- STREQ(MEMBER_TYPE_NAME("address_space", "i_pages"),
"xarray"))
+ (STREQ(MEMBER_TYPE_NAME("address_space", "i_pages"),
"xarray") ||
+ (STREQ(MEMBER_TYPE_NAME("address_space", "i_pages"),
"radix_tree_root") &&
+ MEMBER_EXISTS("radix_tree_root", "xa_head"))))
xarray = i_mapping + OFFSET(address_space_page_tree);
else
root_rnode = i_mapping + OFFSET(address_space_page_tree);
diff --git a/ipcs.c b/ipcs.c
index 2553bac..3c26620 100644
--- a/ipcs.c
+++ b/ipcs.c
@@ -206,7 +206,10 @@ ipcs_init(void)
if (STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"), "xarray"))
ipcs_table.init_flags |= IDR_XARRAY;
else
- ipcs_table.init_flags |= IDR_RADIX;
+ if (MEMBER_EXISTS("radix_tree_root", "rnode"))
+ ipcs_table.init_flags |= IDR_RADIX;
+ else if (MEMBER_EXISTS("radix_tree_root", "xa_head"))
+ ipcs_table.init_flags |= IDR_XARRAY;
} else
ipcs_table.init_flags |= IDR_ORIG;
diff --git a/kernel.c b/kernel.c
index 9f5ba89..8080097 100644
--- a/kernel.c
+++ b/kernel.c
@@ -534,9 +534,14 @@ kernel_init()
if (kernel_symbol_exists("irq_desc_tree")) {
get_symbol_type("irq_desc_tree", NULL, &req);
- kt->flags2 |= STREQ(req.type_tag_name, "xarray") ?
- IRQ_DESC_TREE_XARRAY : IRQ_DESC_TREE_RADIX;
-
+ if (STREQ(req.type_tag_name, "xarray")) {
+ kt->flags2 |= IRQ_DESC_TREE_XARRAY;
+ } else {
+ if (MEMBER_EXISTS("radix_tree_root", "xa_head"))
+ kt->flags2 |= IRQ_DESC_TREE_XARRAY;
+ else
+ kt->flags2 |= IRQ_DESC_TREE_RADIX;
+ }
}
STRUCT_SIZE_INIT(irq_data, "irq_data");
if (VALID_STRUCT(irq_data)) {
diff --git a/task.c b/task.c
index cd118e5..36a90d6 100644
--- a/task.c
+++ b/task.c
@@ -507,10 +507,17 @@ task_init(void)
OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
tt->flags |= PID_XARRAY;
} else if STREQ(MEMBER_TYPE_NAME("idr", "idr_rt"),
"radix_tree_root") {
- tt->refresh_task_table = refresh_radix_tree_task_table;
- tt->pid_radix_tree = symbol_value("init_pid_ns") +
- OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
- tt->flags |= PID_RADIX_TREE;
+ if (MEMBER_EXISTS("radix_tree_root", "rnode")) {
+ tt->refresh_task_table = refresh_radix_tree_task_table;
+ tt->pid_radix_tree = symbol_value("init_pid_ns") +
+ OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
+ tt->flags |= PID_RADIX_TREE;
+ } else if (MEMBER_EXISTS("radix_tree_root", "xa_head")) {
+ tt->refresh_task_table = refresh_xarray_task_table;
+ tt->pid_xarray = symbol_value("init_pid_ns") +
+ OFFSET(pid_namespace_idr) + OFFSET(idr_idr_rt);
+ tt->flags |= PID_XARRAY;
+ }
} else
error(FATAL, "unknown pid_namespace.idr type: %s\n",
MEMBER_TYPE_NAME("idr", "idr_rt"));
diff --git a/tools.c b/tools.c
index 72ec76a..43b838a 100644
--- a/tools.c
+++ b/tools.c
@@ -4241,7 +4241,10 @@ cmd_tree()
}
if (STRNEQ(optarg, "ra"))
- type_flag = RADIXTREE_REQUEST;
+ if (MEMBER_EXISTS("radix_tree_root", "xa_head"))
+ type_flag = XARRAY_REQUEST;
+ else
+ type_flag = RADIXTREE_REQUEST;
else if (STRNEQ(optarg, "rb"))
type_flag = RBTREE_REQUEST;
else if (STRNEQ(optarg, "x"))
--
2.16.4
2021
days inactive
2025
days old
devel@lists.crash-utility.osci.io
10 comments
2 participants
participants (2)
-
Dave Anderson -
Philipp Rudo