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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.