Why?
This is a preparation patch set that will make it easier for us to apply
subsequent patches that will remove the sentinel element (last empty element)
in the ctl_table arrays.
In itself, it does not remove any sentinels but it is needed to bring all the
advantages of the removal to fruition which is to help reduce the overall build
time size of the kernel and run time memory bloat by about ~64 bytes per
sentinel. Without this patch set we would have to put everything into one big
commit making the review process that much longer and harder for everyone.
Since it is so related to the removal of the sentinel element, its worth while
to give a bit of context on this:
* Good summary from Luis about why we want to remove the sentinels.
https://lore.kernel.org/all/[email protected]/
* This is a patch set that replaces register_sysctl_table with register_sysctl
https://lore.kernel.org/all/[email protected]/
* Patch set to deprecate register_sysctl_paths()
https://lore.kernel.org/all/[email protected]/
* Here there is an explicit expectation for the removal of the sentinel element.
https://lore.kernel.org/all/[email protected]
* The "ARRAY_SIZE" approach was mentioned (proposed?) in this thread
https://lore.kernel.org/all/[email protected]
What?
These commits set things up so we can start removing the sentinel elements.
They modify sysctl and net_sysctl internals so that registering a ctl_table
that contains a sentinel gives the same result as passing a table_size
calculated from the ctl_table array without a sentinel. We accomplish this by
introducing a table_size argument in the same place where procname is checked
for NULL. The idea is for it to keep stopping when it hits ->procname == NULL,
while the sentinel is still present. And when the sentinel is removed, it will
stop on the table_size (thx to [email protected] for the discussion
that led to this). This allows us to remove sentinels from one (or several)
files at a time.
These commits are part of a bigger set containing the removal of ctl_table sentinel
(https://github.com/Joelgranados/linux/tree/tag/sysctl_remove_empty_elem_V2).
The idea is to make the review process easier by chunking the 65+ commits into
manageable pieces.
My idea is to send out one chunk at a time so it can be reviewed separately
from the others without the noise from parallel related sets. After this first
chunk will come 6 that remove the sentinel element from "arch/*, drivers/*,
fs/*, kernel/*, net/* and miscellaneous. And then a final one that removes the
->procname == NULL check. You can see all commits here
(https://github.com/Joelgranados/linux/tree/tag/sysctl_remove_empty_elem_V2).
Commits in this chunk:
* Preparation commits:
start : sysctl: Prefer ctl_table_header in proc_sysct
end : sysctl: Add size argument to init_header
These are preparation commits that make sure that we have the
ctl_table_header where we need the array size.
* Add size to __register_sysctl_table, __register_sysctl_init and register_sysctl
start : sysctl: Add a size arg to __register_sysctl_table
end : sysctl: Add size arg to __register_sysctl_init
Here we replace the existing register functions with macros that add the
ARRAY_SIZE automatically. Unfortunately these macros cannot be used for the
register calls that pass a pointer; in this situation we add register
functions with an table_size argument (thx to [email protected] for bringing
this to my attention)
* Add size to register_net_sysctl
start : sysctl: Add size to register_net_sysctl function
end : sysctl: SIZE_MAX->ARRAY_SIZE in register_net_sysctl
register_net_sysctl is an indirection function to the sysctl registrations
and needed a several commits to add table_size to all its callers. We
temporarily use SIZE_MAX to avoid compiler warnings while we change to
register_net_sysctl to register_net_sysctl_sz; we remove it with the
penultimate patch of this set. Finally, we make sure to adjust the calculated
size every time there is a check for unprivileged users.
* Add size as additional stopping criteria
commit : sysctl: Use ctl_table_size as stopping criteria for list macro
We add table_size check in the main macro within proc_sysctl.c. This commit
allows the removal of the sentinel element by chunks.
Testing:
* Ran sysctl selftests (./tools/testing/selftests/sysctl/sysctl.sh)
* Successfully ran this through 0-day
Size saving estimates:
A consequence of eventually removing all the sentinels (64 bytes per sentinel)
is the bytes we save. These are *not* numbers that we will get after this patch
set; these are the numbers that we will get after removing all the sentinels. I
included them here because they are relevant and to get an idea of just how
much memory we are talking about.
* bloat-o-meter:
The "yesall" configuration results save 9158 bytes (you can see the output here
https://lore.kernel.org/all/[email protected]/.
The "tiny" configuration + CONFIG_SYSCTL save 1215 bytes (you can see the
output here [2])
* memory usage:
As we no longer need the sentinel element within proc_sysctl.c, we save some
bytes in main memory as well. In my testing kernel I measured a difference of
6720 bytes. I include the way to measure this in [1]
Comments/feedback greatly appreciated
V2:
* Dropped moving mpls_table up the af_mpls.c file. We don't need it any longer
as it is not really used before its current location.
* Added/Clarified the why in several commit messages that were missing it.
* Clarified the why in the cover letter to be "to make it easier to apply
subsequent patches that will remove the sentinels"
* Added documentation for table_size
* Added suggested by tags (Greg and Jani) to relevant commits
Best
Joel
[1]
To measure the in memory savings apply this patch on top of
https://github.com/Joelgranados/linux/tree/tag/sysctl_remove_empty_elem_V1
"
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index 5f413bfd6271..9aa8374c0ef1 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -975,6 +975,7 @@ static struct ctl_dir *new_dir(struct ctl_table_set *set,
table[0].procname = new_name;
table[0].mode = S_IFDIR|S_IRUGO|S_IXUGO;
init_header(&new->header, set->dir.header.root, set, node, table, 1);
+ printk("%ld sysctl saved mem kzalloc \n", sizeof(struct ctl_table));
return new;
}
@@ -1202,6 +1203,7 @@ static struct ctl_table_header *new_links(struct ctl_dir *dir, struct ctl_table_
head->ctl_table_size);
links->nreg = head->ctl_table_size;
+ printk("%ld sysctl saved mem kzalloc \n", sizeof(struct ctl_table));
return links;
}
"
and then run the following bash script in the kernel:
accum=0
for n in $(dmesg | grep kzalloc | awk '{print $3}') ; do
echo $n
accum=$(calc "$accum + $n")
done
echo $accum
[2]
bloat-o-meter with "tiny" config:
add/remove: 0/2 grow/shrink: 33/24 up/down: 470/-1685 (-1215)
Function old new delta
insert_header 831 966 +135
__register_sysctl_table 971 1092 +121
get_links 177 226 +49
put_links 167 186 +19
erase_header 55 66 +11
sysctl_init_bases 59 69 +10
setup_sysctl_set 65 73 +8
utsname_sysctl_init 26 31 +5
sld_mitigate_sysctl_init 33 38 +5
setup_userns_sysctls 158 163 +5
sched_rt_sysctl_init 33 38 +5
sched_fair_sysctl_init 33 38 +5
sched_dl_sysctl_init 33 38 +5
random_sysctls_init 33 38 +5
page_writeback_init 122 127 +5
oom_init 73 78 +5
kernel_panic_sysctls_init 33 38 +5
kernel_exit_sysctls_init 33 38 +5
init_umh_sysctls 33 38 +5
init_signal_sysctls 33 38 +5
init_pipe_fs 94 99 +5
init_fs_sysctls 33 38 +5
init_fs_stat_sysctls 33 38 +5
init_fs_namespace_sysctls 33 38 +5
init_fs_namei_sysctls 33 38 +5
init_fs_inode_sysctls 33 38 +5
init_fs_exec_sysctls 33 38 +5
init_fs_dcache_sysctls 33 38 +5
register_sysctl 22 25 +3
__register_sysctl_init 9 12 +3
user_namespace_sysctl_init 149 151 +2
sched_core_sysctl_init 38 40 +2
register_sysctl_mount_point 13 15 +2
vm_table 1344 1280 -64
vm_page_writeback_sysctls 512 448 -64
vm_oom_kill_table 256 192 -64
uts_kern_table 448 384 -64
usermodehelper_table 192 128 -64
user_table 576 512 -64
sld_sysctls 128 64 -64
signal_debug_table 128 64 -64
sched_rt_sysctls 256 192 -64
sched_fair_sysctls 128 64 -64
sched_dl_sysctls 192 128 -64
sched_core_sysctls 64 - -64
root_table 128 64 -64
random_table 448 384 -64
namei_sysctls 320 256 -64
kern_table 1792 1728 -64
kern_panic_table 128 64 -64
kern_exit_table 128 64 -64
inodes_sysctls 192 128 -64
fs_stat_sysctls 256 192 -64
fs_shared_sysctls 192 128 -64
fs_pipe_sysctls 256 192 -64
fs_namespace_sysctls 128 64 -64
fs_exec_sysctls 128 64 -64
fs_dcache_sysctls 128 64 -64
init_header 85 - -85
Total: Before=1877669, After=1876454, chg -0.06%
base: fdf0eaf11452
Joel Granados (14):
sysctl: Prefer ctl_table_header in proc_sysctl
sysctl: Use ctl_table_header in list_for_each_table_entry
sysctl: Add ctl_table_size to ctl_table_header
sysctl: Add size argument to init_header
sysctl: Add a size arg to __register_sysctl_table
sysctl: Add size to register_sysctl
sysctl: Add size arg to __register_sysctl_init
sysctl: Add size to register_net_sysctl function
ax.25: Update to register_net_sysctl_sz
netfilter: Update to register_net_sysctl_sz
networking: Update to register_net_sysctl_sz
vrf: Update to register_net_sysctl_sz
sysctl: SIZE_MAX->ARRAY_SIZE in register_net_sysctl
sysctl: Use ctl_table_size as stopping criteria for list macro
arch/arm64/kernel/armv8_deprecated.c | 2 +-
arch/s390/appldata/appldata_base.c | 2 +-
drivers/net/vrf.c | 3 +-
fs/proc/proc_sysctl.c | 90 +++++++++++++------------
include/linux/sysctl.h | 31 +++++++--
include/net/ipv6.h | 2 +
include/net/net_namespace.h | 10 +--
ipc/ipc_sysctl.c | 4 +-
ipc/mq_sysctl.c | 4 +-
kernel/ucount.c | 5 +-
net/ax25/sysctl_net_ax25.c | 3 +-
net/bridge/br_netfilter_hooks.c | 3 +-
net/core/neighbour.c | 8 ++-
net/core/sysctl_net_core.c | 3 +-
net/ieee802154/6lowpan/reassembly.c | 8 ++-
net/ipv4/devinet.c | 3 +-
net/ipv4/ip_fragment.c | 3 +-
net/ipv4/route.c | 8 ++-
net/ipv4/sysctl_net_ipv4.c | 3 +-
net/ipv4/xfrm4_policy.c | 3 +-
net/ipv6/addrconf.c | 3 +-
net/ipv6/icmp.c | 5 ++
net/ipv6/netfilter/nf_conntrack_reasm.c | 3 +-
net/ipv6/reassembly.c | 3 +-
net/ipv6/route.c | 13 ++--
net/ipv6/sysctl_net_ipv6.c | 16 +++--
net/ipv6/xfrm6_policy.c | 3 +-
net/mpls/af_mpls.c | 6 +-
net/mptcp/ctrl.c | 3 +-
net/netfilter/ipvs/ip_vs_ctl.c | 8 ++-
net/netfilter/ipvs/ip_vs_lblc.c | 10 ++-
net/netfilter/ipvs/ip_vs_lblcr.c | 10 ++-
net/netfilter/nf_conntrack_standalone.c | 4 +-
net/netfilter/nf_log.c | 7 +-
net/rds/tcp.c | 3 +-
net/sctp/sysctl.c | 4 +-
net/smc/smc_sysctl.c | 3 +-
net/sysctl_net.c | 26 ++++---
net/unix/sysctl_net_unix.c | 3 +-
net/xfrm/xfrm_sysctl.c | 8 ++-
40 files changed, 222 insertions(+), 117 deletions(-)
--
2.30.2
This commit adds size to the register_net_sysctl indirection function to
facilitate the removal of the sentinel elements (last empty markers)
from the ctl_table arrays. Though we don't actually remove any sentinels
in this commit, register_net_sysctl* now has the capability of
forwarding table_size for when that happens.
We create a new function register_net_sysctl_sz with an extra size
argument. A macro replaces the existing register_net_sysctl. The size in
the macro is SIZE_MAX instead of ARRAY_SIZE to avoid compilation errors
while we systematically migrate to register_net_sysctl_sz. Will change
to ARRAY_SIZE in subsequent commits.
Care is taken to add table_size to the stopping criteria in such a way
that when we remove the empty sentinel element, it will continue
stopping in the last element of the ctl_table array.
Signed-off-by: Joel Granados <[email protected]>
Suggested-by: Greg Kroah-Hartman <[email protected]>
---
include/net/net_namespace.h | 10 ++++++----
net/sysctl_net.c | 22 +++++++++++++---------
2 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 78beaa765c73..e4e5fe75a281 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -469,15 +469,17 @@ void unregister_pernet_device(struct pernet_operations *);
struct ctl_table;
+#define register_net_sysctl(net, path, table) \
+ register_net_sysctl_sz(net, path, table, SIZE_MAX)
#ifdef CONFIG_SYSCTL
int net_sysctl_init(void);
-struct ctl_table_header *register_net_sysctl(struct net *net, const char *path,
- struct ctl_table *table);
+struct ctl_table_header *register_net_sysctl_sz(struct net *net, const char *path,
+ struct ctl_table *table, size_t table_size);
void unregister_net_sysctl_table(struct ctl_table_header *header);
#else
static inline int net_sysctl_init(void) { return 0; }
-static inline struct ctl_table_header *register_net_sysctl(struct net *net,
- const char *path, struct ctl_table *table)
+static inline struct ctl_table_header *register_net_sysctl_sz(struct net *net,
+ const char *path, struct ctl_table *table, size_t table_size)
{
return NULL;
}
diff --git a/net/sysctl_net.c b/net/sysctl_net.c
index d9cbbb51b143..051ed5f6fc93 100644
--- a/net/sysctl_net.c
+++ b/net/sysctl_net.c
@@ -122,12 +122,13 @@ __init int net_sysctl_init(void)
* allocated.
*/
static void ensure_safe_net_sysctl(struct net *net, const char *path,
- struct ctl_table *table)
+ struct ctl_table *table, size_t table_size)
{
struct ctl_table *ent;
pr_debug("Registering net sysctl (net %p): %s\n", net, path);
- for (ent = table; ent->procname; ent++) {
+ ent = table;
+ for (size_t i = 0; i < table_size && ent->procname; ent++, i++) {
unsigned long addr;
const char *where;
@@ -160,21 +161,24 @@ static void ensure_safe_net_sysctl(struct net *net, const char *path,
}
}
-struct ctl_table_header *register_net_sysctl(struct net *net,
- const char *path, struct ctl_table *table)
+struct ctl_table_header *register_net_sysctl_sz(struct net *net,
+ const char *path,
+ struct ctl_table *table,
+ size_t table_size)
{
- int count = 0;
+ int count;
struct ctl_table *entry;
if (!net_eq(net, &init_net))
- ensure_safe_net_sysctl(net, path, table);
+ ensure_safe_net_sysctl(net, path, table, table_size);
- for (entry = table; entry->procname; entry++)
- count++;
+ entry = table;
+ for (count = 0 ; count < table_size && entry->procname; entry++, count++)
+ ;
return __register_sysctl_table(&net->sysctls, path, table, count);
}
-EXPORT_SYMBOL_GPL(register_net_sysctl);
+EXPORT_SYMBOL_GPL(register_net_sysctl_sz);
void unregister_net_sysctl_table(struct ctl_table_header *header)
{
--
2.30.2
> Joel Granados (14):
> sysctl: Prefer ctl_table_header in proc_sysctl
> sysctl: Use ctl_table_header in list_for_each_table_entry
> sysctl: Add ctl_table_size to ctl_table_header
> sysctl: Add size argument to init_header
> sysctl: Add a size arg to __register_sysctl_table
> sysctl: Add size to register_sysctl
> sysctl: Add size arg to __register_sysctl_init
This is looking great thanks, I've taken the first 7 patches above
to sysctl-next to get more exposure / testing and since we're already
on rc4.
Since the below patches involve more networking I'll wait to get
more feedback from networking folks before merging them.
> sysctl: Add size to register_net_sysctl function
> ax.25: Update to register_net_sysctl_sz
> netfilter: Update to register_net_sysctl_sz
> networking: Update to register_net_sysctl_sz
> vrf: Update to register_net_sysctl_sz
> sysctl: SIZE_MAX->ARRAY_SIZE in register_net_sysctl
> sysctl: Use ctl_table_size as stopping criteria for list macro
Luis
On Mon, Jul 31, 2023 at 09:17:14AM +0200, Joel Granados wrote:
> Why?
It would be easier to read if the what went before the why.
> This is a preparation patch set that will make it easier for us to apply
> subsequent patches that will remove the sentinel element (last empty element)
> in the ctl_table arrays.
>
> In itself, it does not remove any sentinels but it is needed to bring all the
> advantages of the removal to fruition which is to help reduce the overall build
> time size of the kernel and run time memory bloat by about ~64 bytes per
> sentinel.
s/sentinel/declared ctl array
Because the you're suggesting we want to remove the sentinel but we
want to help the patch reviewer know that a sentil is required per
declared ctl array.
You can also mention here briefly that this helps ensure that future moves of
sysctl arrays out from kernel/sysctl.c to their own subsystem won't
penalize in enlarging the kernel build size or run time memory consumption.
Thanks for spinning this up again!
Luis
On Mon, Jul 31, 2023 at 02:36:50PM -0700, Luis Chamberlain wrote:
> > Joel Granados (14):
> > sysctl: Prefer ctl_table_header in proc_sysctl
> > sysctl: Use ctl_table_header in list_for_each_table_entry
> > sysctl: Add ctl_table_size to ctl_table_header
> > sysctl: Add size argument to init_header
> > sysctl: Add a size arg to __register_sysctl_table
> > sysctl: Add size to register_sysctl
> > sysctl: Add size arg to __register_sysctl_init
>
> This is looking great thanks, I've taken the first 7 patches above
> to sysctl-next to get more exposure / testing and since we're already
> on rc4.
Thx for the feedback.
>
> Since the below patches involve more networking I'll wait to get
> more feedback from networking folks before merging them.
Just FYI, these are all networking except for the last one. That one is
actually just in sysctl and will set everything up for removing the
sentinels.
>
> > sysctl: Add size to register_net_sysctl function
> > ax.25: Update to register_net_sysctl_sz
> > netfilter: Update to register_net_sysctl_sz
> > networking: Update to register_net_sysctl_sz
> > vrf: Update to register_net_sysctl_sz
> > sysctl: SIZE_MAX->ARRAY_SIZE in register_net_sysctl
> > sysctl: Use ctl_table_size as stopping criteria for list macro
>
> Luis
--
Joel Granados
On Mon, Jul 31, 2023 at 01:50:40PM -0700, Luis Chamberlain wrote:
> On Mon, Jul 31, 2023 at 09:17:14AM +0200, Joel Granados wrote:
> > Why?
>
> It would be easier to read if the what went before the why.
haha. I totally misunderstood you in
lore.kernel.org/all/[email protected] I thought
you meant to put the why first. I'll switch it back to having the what
first for V3
>
> > This is a preparation patch set that will make it easier for us to apply
> > subsequent patches that will remove the sentinel element (last empty element)
> > in the ctl_table arrays.
> >
> > In itself, it does not remove any sentinels but it is needed to bring all the
> > advantages of the removal to fruition which is to help reduce the overall build
> > time size of the kernel and run time memory bloat by about ~64 bytes per
> > sentinel.
>
> s/sentinel/declared ctl array
>
> Because the you're suggesting we want to remove the sentinel but we
> want to help the patch reviewer know that a sentil is required per
> declared ctl array.
Ack
>
> You can also mention here briefly that this helps ensure that future moves of
> sysctl arrays out from kernel/sysctl.c to their own subsystem won't
> penalize in enlarging the kernel build size or run time memory consumption.
I worked it in
Thx for the review
>
> Thanks for spinning this up again!
>
> Luis
--
Joel Granados
On Mon, Aug 07, 2023 at 04:00:49PM -0700, Chris Maness wrote:
> When are these likely to hit the mainline release code?
linux-next tomorrow. The first 7 patches are scheduled for mainline
as they were merged + tested without any hiccups. These last few patches
I'll wait and see. If nothing blows up on linux-next perhaps I'll
include them to Linux for mainline during the next merge window.
Luis
On Mon, Jul 31, 2023 at 02:36:50PM -0700, Luis Chamberlain wrote:
> > Joel Granados (14):
> > sysctl: Prefer ctl_table_header in proc_sysctl
> > sysctl: Use ctl_table_header in list_for_each_table_entry
> > sysctl: Add ctl_table_size to ctl_table_header
> > sysctl: Add size argument to init_header
> > sysctl: Add a size arg to __register_sysctl_table
> > sysctl: Add size to register_sysctl
> > sysctl: Add size arg to __register_sysctl_init
>
> This is looking great thanks, I've taken the first 7 patches above
> to sysctl-next to get more exposure / testing and since we're already
> on rc4.
Ok I havent't heard much more feedback from networking folks, and
since this is mostly sysctl love I've taken in the rest of these
patches. Thanks to Jani Nikula for the reviews and to Greg KH for
the suggestion on simplifying things.
Let's see what busts in linux-next, and if anything does I can reset
my tree back to only the first 7 patches.
Luis
On Mon, 7 Aug 2023 14:44:11 -0700 Luis Chamberlain wrote:
> > This is looking great thanks, I've taken the first 7 patches above
> > to sysctl-next to get more exposure / testing and since we're already
> > on rc4.
>
> Ok I havent't heard much more feedback from networking folks
What did you expect to hear from us?
My only comment is to merge the internal prep changes in and then send
us the networking changes in the next release cycle.
I tried running the current mainline kernel (current Arch Linux) with
simple single MUX socket (ax0) using LinFBB. I was a happy camper as
it seemed to work fine at first, then the system just slowed to a
crawl. I am wondering if any of these patches are addressing this
behavior. No kernel panic like before, but not what I was hoping for.
I have also tried sixpack, and that explodes instantly the last time I
have checked. That goes all the way back to the v4 kernels. v2 is
fine there.
73 de Chris KQ6UP
On Mon, Aug 7, 2023 at 4:43 PM Luis Chamberlain <[email protected]> wrote:
>
> On Mon, Aug 07, 2023 at 04:00:49PM -0700, Chris Maness wrote:
> > When are these likely to hit the mainline release code?
>
> linux-next tomorrow. The first 7 patches are scheduled for mainline
> as they were merged + tested without any hiccups. These last few patches
> I'll wait and see. If nothing blows up on linux-next perhaps I'll
> include them to Linux for mainline during the next merge window.
>
> Luis
--
Thanks,
Chris Maness
>
> Are you reporting a separate regression that goes all the way back to v4 kernels?
>
I am not certain what you mean by regression.
> > v2 is fine there.
>
> What does this mean?
I have to go all the way back to kernel version 2 for the serial 6PACK
driver to work. If I try to use it in Kernel version 4, 5, or 6 the
kernel panics as soon as I attempt to connect to another station.
>
> Luis
Chris KQ6UP
--
Thanks,
Chris Maness
On Mon, Aug 07, 2023 at 07:50:44PM -0700, Chris Maness wrote:
> I tried running the current mainline kernel (current Arch Linux) with
> simple single MUX socket (ax0) using LinFBB. I was a happy camper as
> it seemed to work fine at first, then the system just slowed to a
> crawl. I am wondering if any of these patches are addressing this
> behavior.
If its a regressio no.
> No kernel panic like before, but not what I was hoping for.
> I have also tried sixpack, and that explodes instantly the last time I
> have checked. That goes all the way back to the v4 kernels.
Are you reporting a separate regression that goes all the way back to v4 kernels?
> v2 is fine there.
What does this mean?
Luis
On Mon, Aug 07, 2023 at 07:09:14PM -0700, Jakub Kicinski wrote:
> On Mon, 7 Aug 2023 14:44:11 -0700 Luis Chamberlain wrote:
> > > This is looking great thanks, I've taken the first 7 patches above
> > > to sysctl-next to get more exposure / testing and since we're already
> > > on rc4.
> >
> > Ok I havent't heard much more feedback from networking folks
>
> What did you expect to hear from us?
Just a sanity review would be nice.
> My only comment is to merge the internal prep changes in and then send
> us the networking changes in the next release cycle.
OK we can do that, I can soak them on linux-next from now so to be sure
it gets wider testing. But review on those parts would be nice.
Luis
Hey Chris
My questions inline
On Mon, Aug 07, 2023 at 07:50:44PM -0700, Chris Maness wrote:
> I tried running the current mainline kernel (current Arch Linux) with
What kernel version are we talking about exactly here? Please notice the
base that I used in the cover letter (rc2 or rc3). They should also
rebase cleanly on top of v6.5-rc5.
I'm not sure what the patches will do if you apply them to an older
kernel.
> simple single MUX socket (ax0) using LinFBB. I was a happy camper as
> it seemed to work fine at first, then the system just slowed to a
> crawl. I am wondering if any of these patches are addressing this
> behavior. No kernel panic like before, but not what I was hoping for.
So you have been experiencing kernel panics from before? What does
before mean? And can you bisect to pinpoint what commit fixed it?
> I have also tried sixpack, and that explodes instantly the last time I
> have checked. That goes all the way back to the v4 kernels. v2 is
> fine there.
You mean that 6pack is broken in all the major versions up until v2? If
this is the case, then it might be an issue that is not related to this
patchset.I see that Andreas Koensgen <[email protected]> is the
maintainer of 6pack, maybe he can chime in on the issue?
>
> 73 de Chris KQ6UP
>
> On Mon, Aug 7, 2023 at 4:43 PM Luis Chamberlain <[email protected]> wrote:
> >
> > On Mon, Aug 07, 2023 at 04:00:49PM -0700, Chris Maness wrote:
> > > When are these likely to hit the mainline release code?
> >
> > linux-next tomorrow. The first 7 patches are scheduled for mainline
> > as they were merged + tested without any hiccups. These last few patches
> > I'll wait and see. If nothing blows up on linux-next perhaps I'll
> > include them to Linux for mainline during the next merge window.
> >
> > Luis
>
>
>
> --
> Thanks,
> Chris Maness
--
Joel Granados
On Mon, Aug 07, 2023 at 08:07:24PM -0700, Chris Maness wrote:
> >
> > Are you reporting a separate regression that goes all the way back to v4 kernels?
> >
>
> I am not certain what you mean by regression.
>
> > > v2 is fine there.
> >
> > What does this mean?
>
> I have to go all the way back to kernel version 2 for the serial 6PACK
> driver to work. If I try to use it in Kernel version 4, 5, or 6 the
> kernel panics as soon as I attempt to connect to another station.
Again. Have you reached out to Andreas Koensgen
<[email protected]>? Maybe he has more info on this.
Best
>
> >
> > Luis
>
> Chris KQ6UP
>
>
> --
> Thanks,
> Chris Maness
--
Joel Granados