From: Patrick McHardy <kaber@trash.net>
To: Simon Horman <horms@verge.net.au>
Cc: Julius Volz <juliusv@google.com>,
lvs-devel@vger.kernel.org, netdev@vger.kernel.org,
davem@davemloft.net, vbusam@google.com
Subject: Re: [PATCH] IPVS: Move userspace definitions to include/linux/ip_vs.h
Date: Thu, 24 Jul 2008 13:22:34 +0200 [thread overview]
Message-ID: <488865FA.4040002@trash.net> (raw)
In-Reply-To: <20080724111434.GA30382@verge.net.au>
Simon Horman wrote:
> On Thu, Jul 24, 2008 at 12:14:49PM +0200, Julius Volz wrote:
>> Current versions of ipvsadm include "/usr/src/linux/include/net/ip_vs.h"
>> directly. This file also contains kernel-only definitions. Normally, public
>> definitions should live in include/linux, so this patch moves the
>> definitions shared with userspace to a new file, "include/linux/ip_vs.h".
>>
>> To make old ipvsadms still compile with this, the old header file includes
>> the new one.
>>
>> Thanks to Dave Miller and Horms for noting/adding the missing Kbuild entry
>> for the new header file.
>>
>> Signed-off-by: Julius Volz <juliusv@google.com>
>
> Acked-by: Simon Horman <horms@verge.net.au>
>
>> ---
>> +/* Move it to better place one day, for now keep it unique */
>> +#define NFC_IPVS_PROPERTY 0x10000
Does this have any connection to the skb flag? If so, does
it really belong in the userspace interface?
>> +struct ip_vs_service_user {
>> + /* virtual service addresses */
>> + u_int16_t protocol;
>> + __be32 addr; /* virtual ip address */
>> + __be16 port;
If you switch the above two you plug two holes in the struct.
>> + u_int32_t fwmark; /* firwall mark of service */
>> +
>> + /* virtual service options */
>> + char sched_name[IP_VS_SCHEDNAME_MAXLEN];
>> + unsigned flags; /* virtual service flags */
>> + unsigned timeout; /* persistent timeout in sec */
>> + __be32 netmask; /* persistent netmask */
>> +};
>> +
>> +
>> +struct ip_vs_dest_user {
>> + /* destination server address */
>> + __be32 addr;
>> + __be16 port;
This also leaves a hole, you should make sure its zeroed explicitly
to avoid leaking information to userspace.
>> +
>> + /* real server options */
>> + unsigned conn_flags; /* connection flags */
>> + int weight; /* destination weight */
>> +
>> + /* thresholds for active connections */
>> + u_int32_t u_threshold; /* upper threshold */
>> + u_int32_t l_threshold; /* lower threshold */
>> +};
>> +
>> +
>> +/*
>> + * IPVS statistics object (for user space)
>> + */
>> +struct ip_vs_stats_user
>> +{
>> + __u32 conns; /* connections scheduled */
>> + __u32 inpkts; /* incoming packets */
>> + __u32 outpkts; /* outgoing packets */
>> + __u64 inbytes; /* incoming bytes */
>> + __u64 outbytes; /* outgoing bytes */
Putting the u64s first would also plug a hole.
>> +
>> + __u32 cps; /* current connection rate */
>> + __u32 inpps; /* current in packet rate */
>> + __u32 outpps; /* current out packet rate */
>> + __u32 inbps; /* current in byte rate */
>> + __u32 outbps; /* current out byte rate */
>> +};
>> +
>> +
>> +/* The argument to IP_VS_SO_GET_INFO */
>> +struct ip_vs_getinfo {
>> + /* version number */
>> + unsigned int version;
>> +
>> + /* size of connection hash table */
>> + unsigned int size;
>> +
>> + /* number of virtual services */
>> + unsigned int num_services;
>> +};
>> +
>> +
>> +/* The argument to IP_VS_SO_GET_SERVICE */
>> +struct ip_vs_service_entry {
>> + /* which service: user fills in these */
>> + u_int16_t protocol;
>> + __be32 addr; /* virtual address */
>> + __be16 port;
Same as above.
>> + u_int32_t fwmark; /* firwall mark of service */
>> +
>> + /* service options */
>> + char sched_name[IP_VS_SCHEDNAME_MAXLEN];
>> + unsigned flags; /* virtual service flags */
>> + unsigned timeout; /* persistent timeout */
>> + __be32 netmask; /* persistent netmask */
>> +
>> + /* number of real servers */
>> + unsigned int num_dests;
>> +
>> + /* statistics */
>> + struct ip_vs_stats_user stats;
>> +};
>> +
>> +
>> +struct ip_vs_dest_entry {
>> + __be32 addr; /* destination address */
>> + __be16 port;
Also a hole that should be cleared.
>> + unsigned conn_flags; /* connection flags */
>> + int weight; /* destination weight */
>> +
>> + u_int32_t u_threshold; /* upper threshold */
>> + u_int32_t l_threshold; /* lower threshold */
>> +
>> + u_int32_t activeconns; /* active connections */
>> + u_int32_t inactconns; /* inactive connections */
>> + u_int32_t persistconns; /* persistent connections */
>> +
>> + /* statistics */
>> + struct ip_vs_stats_user stats;
You might also have a hole before stats since it has 8b alignment.
I'd suggest to use pahole to figure out which structs need to be
restructured.
>> ...
next prev parent reply other threads:[~2008-07-24 11:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-24 10:14 [PATCH] IPVS: Move userspace definitions to include/linux/ip_vs.h Julius Volz
2008-07-24 11:14 ` Simon Horman
2008-07-24 11:22 ` Patrick McHardy [this message]
2008-07-24 11:34 ` Julius Volz
2008-07-24 11:40 ` Patrick McHardy
2008-07-24 11:46 ` Julius Volz
2008-07-24 11:58 ` Julius Volz
2008-07-25 0:22 ` Simon Horman
2008-07-31 2:09 ` Simon Horman
2008-08-01 3:45 ` David Miller
2008-07-25 0:18 ` Simon Horman
-- strict thread matches above, loose matches on Subject: below --
2008-07-22 0:37 Simon Horman
2008-07-23 23:42 ` David Miller
2008-07-24 0:20 ` Simon Horman
2008-07-24 10:09 ` Julius Volz
2008-07-08 14:29 Julius Volz
2008-07-09 1:11 ` Simon Horman
2008-07-09 11:24 ` Julius Volz
2008-07-09 12:20 ` Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=488865FA.4040002@trash.net \
--to=kaber@trash.net \
--cc=davem@davemloft.net \
--cc=horms@verge.net.au \
--cc=juliusv@google.com \
--cc=lvs-devel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=vbusam@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).