LVS
lvs-devel
Google
 
Web LinuxVirtualServer.org

Re: activeconns * weight overflowing 32-bit int

To: Simon Kirby <sim@xxxxxxxxxx>
Subject: Re: activeconns * weight overflowing 32-bit int
Cc: lvs-devel@xxxxxxxxxxxxxxx, Changli Gao <xiaosuo@xxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Thu, 23 May 2013 23:44:22 +0300 (EEST)
        Hello,

On Thu, 23 May 2013, Simon Kirby wrote:

> Hello!
> 
> Yes, see: http://0x.ca/sim/ref/3.9-ipvs/
> 
> The case of just (__u64) on i386 looks not very good, but making the
> weight also unsigned (__u32) seems to improve things. I set up a test

        Hm, only sizeof(long int) should differ between
32-bit and 64-bit platforms, atomic_t is always int, int
is returned from atomic_read and int is always 4 bytes.

> harness (ipvs.c) and disassembled i386 and amd64 compiler outputs for
> both. The only reason I haven't submitted it yet is that I haven't yet
> confirmed that it fixes our problem in production, though it did seem to
> work in testing. Will follow-up shortly.

        Last time I also checked the assembler output from x86-32
and it looked good. I used 'make net/netfilter/ipvs/ip_vs_wlc.s'
to generate asm output, note the 's' extension.

        May be problem in your ipvs.c file comes from the
fact that __u64 is unsigned long long for 32-bit platforms.
I changed the code to use 'unsigned long' as follows:

#if 0
typedef unsigned long long __u64;
#else
typedef unsigned long __u64;
#endif

        and the x86-32 platform works correctly.
x86-64 works for both cases: 'unsigned long long' and
'unsigned long' but x86-32 generates many mul operations
for the 'unsigned long long' case which is not used in
the kernel. That is why I didn't noticed such problem.

        So, I think we should be safe by adding
(__u64) without any (__u32), next days I'll check again
the asm output. May be (__u32) before weight ensures
32x32 multiply but it should not be needed.

Regards

--
Julian Anastasov <ja@xxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

<Prev in Thread] Current Thread [Next in Thread>