From: David Miller <davem@davemloft.net> Date: 2012-07-17 16:01:42
Linus was _extremely_ generous and took in all the stuff that was
pending in the net tree just now.
Besides very serious issues, I'm not willing to consider any more bug
fixes for the 'net' tree at this time.
Only one pending known bug qualifies, and that's the CIPSO ip option
processing OOPS'er. And I'll work on that myself if Paul Moore
doesn't show a sign of life in the next day.
Thanks.
From: Rustad, Mark D <hidden> Date: 2012-07-17 17:41:55
On Jul 17, 2012, at 9:01 AM, David Miller wrote:
Linus was _extremely_ generous and took in all the stuff that was
pending in the net tree just now.
Maybe *too* generous. :-) I just updated and when I boot I get an early crash in update_netdev_tables which is in netprio_cgroup.c.
Besides very serious issues, I'm not willing to consider any more bug
fixes for the 'net' tree at this time.
I think the above issue will have to be fixed, as it completely prevents booting for any kernel that includes the netprio_cgroup option.
Only one pending known bug qualifies, and that's the CIPSO ip option
processing OOPS'er. And I'll work on that myself if Paul Moore
doesn't show a sign of life in the next day.
Thanks.
I can start taking a look at this if you like, but I see that Gao feng has two patches in the last set of patches that may be related.
To give you an idea how early the crash is, here are a few log messages leading up to it:
[ 0.003455] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[ 0.005550] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 0.007165] Mount-cache hash table entries: 256
[ 0.010289] Initializing cgroup subsys net_cls
[ 0.010947] Initializing cgroup subsys net_prio
[ 0.011039] BUG: unable to handle kernel NULL pointer dereference at 0000000000000828
[ 0.011998] IP: [<ffffffff814202c8>] update_netdev_tables+0x68/0xe0
--
Mark Rustad, LAN Access Division, Intel Corporation
From: Rustad, Mark D <hidden> Date: 2012-07-17 18:48:58
On Jul 17, 2012, at 10:41 AM, Rustad, Mark D wrote:
On Jul 17, 2012, at 9:01 AM, David Miller wrote:
quoted
Linus was _extremely_ generous and took in all the stuff that was
pending in the net tree just now.
Maybe *too* generous. :-) I just updated and when I boot I get an early crash in update_netdev_tables which is in netprio_cgroup.c.
quoted
Besides very serious issues, I'm not willing to consider any more bug
fixes for the 'net' tree at this time.
I think the above issue will have to be fixed, as it completely prevents booting for any kernel that includes the netprio_cgroup option.
quoted
Only one pending known bug qualifies, and that's the CIPSO ip option
processing OOPS'er. And I'll work on that myself if Paul Moore
doesn't show a sign of life in the next day.
Thanks.
I can start taking a look at this if you like, but I see that Gao feng has two patches in the last set of patches that may be related.
To give you an idea how early the crash is, here are a few log messages leading up to it:
[ 0.003455] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[ 0.005550] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 0.007165] Mount-cache hash table entries: 256
[ 0.010289] Initializing cgroup subsys net_cls
[ 0.010947] Initializing cgroup subsys net_prio
[ 0.011039] BUG: unable to handle kernel NULL pointer dereference at 0000000000000828
[ 0.011998] IP: [<ffffffff814202c8>] update_netdev_tables+0x68/0xe0
I found that I can avoid the crash by configuring the netprio_cgroup as a module. I don't need to have it built in, I just happened to. This finding may lower the temperature of this issue a lot from what I had been feeling.
--
Mark Rustad, LAN Access Division, Intel Corporation
From: John Fastabend <hidden> Date: 2012-07-17 19:00:19
On 7/17/2012 11:48 AM, Rustad, Mark D wrote:
On Jul 17, 2012, at 10:41 AM, Rustad, Mark D wrote:
quoted
On Jul 17, 2012, at 9:01 AM, David Miller wrote:
quoted
Linus was _extremely_ generous and took in all the stuff that was
pending in the net tree just now.
Maybe *too* generous. :-) I just updated and when I boot I get an early crash in update_netdev_tables which is in netprio_cgroup.c.
quoted
Besides very serious issues, I'm not willing to consider any more bug
fixes for the 'net' tree at this time.
I think the above issue will have to be fixed, as it completely prevents booting for any kernel that includes the netprio_cgroup option.
quoted
Only one pending known bug qualifies, and that's the CIPSO ip option
processing OOPS'er. And I'll work on that myself if Paul Moore
doesn't show a sign of life in the next day.
Thanks.
I can start taking a look at this if you like, but I see that Gao feng has two patches in the last set of patches that may be related.
To give you an idea how early the crash is, here are a few log messages leading up to it:
[ 0.003455] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[ 0.005550] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 0.007165] Mount-cache hash table entries: 256
[ 0.010289] Initializing cgroup subsys net_cls
[ 0.010947] Initializing cgroup subsys net_prio
[ 0.011039] BUG: unable to handle kernel NULL pointer dereference at 0000000000000828
[ 0.011998] IP: [<ffffffff814202c8>] update_netdev_tables+0x68/0xe0
I found that I can avoid the crash by configuring the netprio_cgroup as a module. I don't need to have it built in, I just happened to. This finding may lower the temperature of this issue a lot from what I had been feeling.
hmm looks like we access init_net here,
static void update_netdev_tables(void)
{
struct net_device *dev;
u32 max_len = atomic_read(&max_prioidx) + 1;
struct netprio_map *map;
rtnl_lock();
for_each_netdev(&init_net, dev) {
map = rtnl_dereference(dev->priomap);
if ((!map) ||
(map->priomap_len < max_len))
extend_netdev_table(dev, max_len);
}
rtnl_unlock();
}
but inet_net is initialized by pure_initcall(net_ns_init) and I
gather pure_initcall's should not have any dependencies but it
looks like we created one here with cgroup_init_early() in
start_kernel().
I'll poke around some more. Also had some off list help from
Mark.
.John
From: John Fastabend <hidden> Date: 2012-07-17 19:09:54
On 7/17/2012 12:00 PM, John Fastabend wrote:
On 7/17/2012 11:48 AM, Rustad, Mark D wrote:
quoted
On Jul 17, 2012, at 10:41 AM, Rustad, Mark D wrote:
quoted
On Jul 17, 2012, at 9:01 AM, David Miller wrote:
quoted
Linus was _extremely_ generous and took in all the stuff that was
pending in the net tree just now.
Maybe *too* generous. :-) I just updated and when I boot I get an
early crash in update_netdev_tables which is in netprio_cgroup.c.
quoted
Besides very serious issues, I'm not willing to consider any more bug
fixes for the 'net' tree at this time.
I think the above issue will have to be fixed, as it completely
prevents booting for any kernel that includes the netprio_cgroup option.
quoted
Only one pending known bug qualifies, and that's the CIPSO ip option
processing OOPS'er. And I'll work on that myself if Paul Moore
doesn't show a sign of life in the next day.
Thanks.
I can start taking a look at this if you like, but I see that Gao
feng has two patches in the last set of patches that may be related.
To give you an idea how early the crash is, here are a few log
messages leading up to it:
[ 0.003455] Dentry cache hash table entries: 262144 (order: 9,
2097152 bytes)
[ 0.005550] Inode-cache hash table entries: 131072 (order: 8,
1048576 bytes)
[ 0.007165] Mount-cache hash table entries: 256
[ 0.010289] Initializing cgroup subsys net_cls
[ 0.010947] Initializing cgroup subsys net_prio
[ 0.011039] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000828
[ 0.011998] IP: [<ffffffff814202c8>] update_netdev_tables+0x68/0xe0
I found that I can avoid the crash by configuring the netprio_cgroup
as a module. I don't need to have it built in, I just happened to.
This finding may lower the temperature of this issue a lot from what I
had been feeling.
hmm looks like we access init_net here,
static void update_netdev_tables(void)
{
struct net_device *dev;
u32 max_len = atomic_read(&max_prioidx) + 1;
struct netprio_map *map;
rtnl_lock();
for_each_netdev(&init_net, dev) {
map = rtnl_dereference(dev->priomap);
if ((!map) ||
(map->priomap_len < max_len))
extend_netdev_table(dev, max_len);
}
rtnl_unlock();
}
but inet_net is initialized by pure_initcall(net_ns_init) and I
gather pure_initcall's should not have any dependencies but it
looks like we created one here with cgroup_init_early() in
start_kernel().
I'll poke around some more. Also had some off list help from
Mark.
.John
although we don't have an early_init hook for netprio_cgroup so this
is probably not correct.
although we don't have an early_init hook for netprio_cgroup so this
is probably not correct.
The dependency is actually on net_dev_init (a subsys_initcall) rather
than a pure_initcall.
net_dev_init is what registers the netdev_net_ops, which in turn
initializes the netdev list in namespaces such as &init_net
although we don't have an early_init hook for netprio_cgroup so this
is probably not correct.
The dependency is actually on net_dev_init (a subsys_initcall) rather
than a pure_initcall.
net_dev_init is what registers the netdev_net_ops, which in turn
initializes the netdev list in namespaces such as &init_net
Ah right thanks sorry for the thrash. I guess we need to check if the
netdev list in the init_net namespace is initialized.
although we don't have an early_init hook for netprio_cgroup so this
is probably not correct.
The dependency is actually on net_dev_init (a subsys_initcall) rather
than a pure_initcall.
net_dev_init is what registers the netdev_net_ops, which in turn
initializes the netdev list in namespaces such as &init_net
Ah right thanks sorry for the thrash. I guess we need to check if the
netdev list in the init_net namespace is initialized.
It's a hack, but we could export and then test dev_boot_phase == 0,
and if that test is true then skip the init_net device walk in the
cgroup code.
But I don't like that very much.
The things this code cares about can't even be an issue until
net_dev_init() runs.
There is a comment warning not to do this in linux/init.h, but we
could change the module_init() in netprio_cgroup.c to some level which
runs after subsys_inticall(). When built as a module, linux/init.h
will translate this into module_init() which is basically the behavior
we want.
although we don't have an early_init hook for netprio_cgroup so this
is probably not correct.
The dependency is actually on net_dev_init (a subsys_initcall) rather
than a pure_initcall.
net_dev_init is what registers the netdev_net_ops, which in turn
initializes the netdev list in namespaces such as &init_net
Ah right thanks sorry for the thrash. I guess we need to check if the
netdev list in the init_net namespace is initialized.
It's a hack, but we could export and then test dev_boot_phase == 0,
and if that test is true then skip the init_net device walk in the
cgroup code.
But I don't like that very much.
The things this code cares about can't even be an issue until
net_dev_init() runs.
There is a comment warning not to do this in linux/init.h, but we
could change the module_init() in netprio_cgroup.c to some level which
runs after subsys_inticall(). When built as a module, linux/init.h
will translate this into module_init() which is basically the behavior
we want.
Perhaps the easiest way is to check net->count this should be zero
until setup_net is called.
if (!atomic_read(&init_net.count))
return ret;