lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121025165632.GC7857@raven>
Date:	Thu, 25 Oct 2012 17:56:32 +0100
From:	Tom Parkin <tparkin@...alix.com>
To:	netdev <netdev@...r.kernel.org>
Subject: Supporting more devices with dev_alloc_name()

Hi list,

I've recently been trying to create large-scale L2TPv3 configurations
of up to 50,000 Ethernet pseudowires.

One of the limitations I've hit has been to do with dev_alloc_name().
By default, l2tp_eth uses "l2tpeth%d" for device names, which is
expanded by dev_alloc_name() into l2tpeth1, l2tpeth2, etc.  However,
the algorithm dev_alloc_name() uses to derive the next free number for
this scheme is bounded by the number of bits in a single page.  For
kernels/platforms with a 4kB page, this limits these "autoderived"
names to 32k.

In my testing I've been able to work around this by specifying
interface names during the bringup of the l2tpeth interfaces, thereby
bypassing dev_alloc_name() altogether.  Using this approach I am able
to comfortably create 50k interfaces, even on fairly modest hardware.
But it seems a shame to have to do this; it would be much nicer if
the kernel were able to autogenerate names for more devices.

Is this something that would be worth my working on a patch for, or
would the increased code complexity be too great an overhead to
consider for such outlandish use-cases?

Thanks,
Tom
-- 
Tom Parkin
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ