All of lore.kernel.org
 help / color / mirror / Atom feed
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.

>> ...


  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.