[B.A.T.M.A.N.] [RFC] batman-adv: add generic netlink query API to replace debugfs files

Linus L├╝ssing linus.luessing at c0d3.blue
Fri Aug 7 18:16:22 CEST 2015

Hi Matthias,

here at the Wireless BattleMesh we finally had the chance to get
some initial discussions on your patch going. For the start a few
comprehension questions came up:

On Wed, Jun 24, 2015 at 08:34:28PM +0200, Matthias Schiffer wrote:
> * As batman-adv uses single_open, the whole content of the originators/
>   transglobal files must fit into a single buffer; in large batman-adv
>   networks this often fails (as an order-5 allocation or even more would be
>   necessary)
> * When originators or transglobal aren't just used for debugging, they are
>   first converted to text, and then parsed again in userspace by tools like
>   alfred/batadv-vis. Sending MAC address lists from the kernel to userspace
>   as text makes the buffer size issue even worse.

These two points can be addressed through debugfs too, for
instance using sequential debugfs writes, right? (In fact IIRC you
had started with that approach until you got the feedback from
Gregk, right?)

Can you elaborate a little more on the "order-5 allocation"?
What amount of free RAM did the machines have where we observed
Out-of-Memory kernel panics upon debugfs access? Can you give some
numbers / calculations why we ended up with several Megabytes
memory allocations on debugfs access?

The debugfs race conditions Gregk and you talked about are on
adding/removing debugfs files, right? Are there any known race
conditions on simple reads/writes in the abscene of removing
debugfs files?

Since you've had a look at both the netlink and sequential debugfs
approach already, can you give some estimation about the
complexity or rough number of lines of code to change for the
sequential debugfs approach?

One thought that popped up here was, whether it'd make sense to
first "fix" the debugfs approach to the extent possible with a
couple of lines instead of 800+ lines to get rid of the issues
we frequently observe. And then merge a complete fix but bigger
patchset implementing netlink support with a more thorough review
and discussions on what we'd need for its API now and upcoming

Cheers, Linus

More information about the B.A.T.M.A.N mailing list