netdev - Re: Sending big Netlink messages to userspace

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f4845fc0806241118u397a17e3qbe09f5d04a7e5035@mail.gmail.com>
Date:	Tue, 24 Jun 2008 20:18:12 +0200
From:	"Julius Volz" <juliusv@...gle.com>
To:	"Patrick McHardy" <kaber@...sh.net>
Cc:	netdev@...r.kernel.org, "Vince Busam" <vbusam@...gle.com>,
	"Thomas Graf" <tgraf@...g.ch>
Subject: Re: Sending big Netlink messages to userspace

On Tue, Jun 24, 2008, Patrick McHardy wrote:
> Thats done automatically through netlink_dump_start().
> You send one skb per dump callback invocation. The final
> call returns a zero sized skb to indicate the end of the
> dump.

Thanks for the pointer, that seems like what I was looking for!

> You probably need to increase the receive buffer size in libnl.

libnl hides this from the user, but from reading the code it looks
like it now has correct a provision for increasing receive buffer size
automatically on seeing MSG_TRUNC. However, it doesn't seem to help in
my case...

> It depends on what kind of attributes you're sending. In case
> of top-level attributes you should only dump objects until
> you reach NLMSG_GOODSIZE and continue during the next dump
> callback invocation. Sending arbitary amounts of nested
> data is more tricky, or might even be impossible currently.

Then I probably have a problem because the list items I'm sending are
nested and the whole list itself is contained in a nested attribute:

IPVS_ENTRY_ATTR_SERVICE_LIST
  IPVS_ENTRY_ATTR_SERVICE
    [service attributes]
    ...
  IPVS_ENTRY_ATTR_SERVICE
    [service attributes]
    ...
  ...

Each list entry has a limited size, however, so if I get rid of the
top-level wrapper (SERVICE_LIST), I could try to see if there is
enough space left in the skb for another whole nested service entry
and continue in the next callback invocation if space runs out.

Actually, nla_nest_cancel() seems to be what I'm looking for: start
dumping service entries into the skb, call nla_nest_cancel() on a put
failure and begin with the canceled element on the next invocation.
That should work, right?

Julius

-- 
Google Switzerland GmbH
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html