On Sat, 2015-11-21 at 14:01 +0100, Nikolay Aleksandrov wrote: > From: Nikolay Aleksandrov <niko...@cumulusnetworks.com> > > It's not necessary to panic upon allocation failure, returning an error > at that point is okay because user-space won't be able to use any of the > ops since they didn't get registered and the default table is null. > > Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> > --- > net/ipv4/ipmr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c > index a006d96d6cd9..2c7fa584a274 100644 > --- a/net/ipv4/ipmr.c > +++ b/net/ipv4/ipmr.c > @@ -2675,7 +2675,7 @@ int __init ip_mr_init(void) > > mrt_cachep = kmem_cache_create("ip_mrt_cache", > sizeof(struct mfc_cache), > - 0, SLAB_HWCACHE_ALIGN | SLAB_PANIC, > + 0, SLAB_HWCACHE_ALIGN, > NULL); > if (!mrt_cachep) > return -ENOMEM;
This runs at boot time. I very much prefer a panic instead of having to deal with a host with a probable bug in mm layer at this point. For IPv6, it is a different matter as it might be a module, thus ip6_mr_init() does not use SLAB_PANIC -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html