linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vishwanath Pai <vpai@akamai.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Igor Lubashev <ilubashe@akamai.com>,
	Josh Hunt <johunt@akamai.com>,
	Pablo Neira Ayuso <pablo@netfilter.org>,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Brian Gerst <brgerst@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Juergen Gross <jgross@suse.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Kees Cook <keescook@chromium.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: xt_hashlimig build error (was Re: [RFC 01/17] x86/asm/64: Remove the restore_c_regs_and_iret label)
Date: Thu, 7 Sep 2017 16:16:47 -0400	[thread overview]
Message-ID: <6667f710-68f3-b97e-b0eb-d9879476831e@akamai.com> (raw)
In-Reply-To: <CA+55aFxvD1R0xg8ZEjNyHtvhBZchWBJTU=FQNiY6Mv8E4TqZ=Q@mail.gmail.com>

On 09/07/2017 02:43 PM, Linus Torvalds wrote:
> Note: that patch has *exactly* the issue I was talking about above.
> 
> Doing that
> 
>     if (user > 0xFFFFFFFFULL)
>         return 0;
> 
> is different from the old code, which used to result in a zero in the
> divide, and then
> 
>     r = (r - 1) << 4;
> 
> would cause it to return a large value.
> 
> So the patch in question doesn't just fix the build error, it
> completely changes the semantics of the function too.
> 
> I *think* the new behavior is likely what you want, but these kinds of
> things should be _described_.
> 
> Also, even with the patch, we have garbage:
> 
>     0xFFFFFFFFULL / (u32)user
> 
> why is that sub-expression pointlessly doing a 64-bit divide with a
> 32-bit number? The compiler is hopefully smart enough to point things
> out, but that "ULL" really is _wrong_ there, and could cause a stupid
> compiler to still do a 64-bit divide (although hopefully the simpler
> version that is 64/32).
> 
> So please clarify both the correct behavior _and_ the actual typing of
> the divide, ok?
> 
>                  Linus

The value of 'user' is sent from userspace, which is the return value of
this function:

static uint64_t bytes_to_cost(uint32_t bytes)
{
        uint32_t r = bytes >> XT_HASHLIMIT_BYTE_SHIFT;
        return UINT32_MAX / (r+1);
}

What user2rate_bytes() is trying to do is the opposite of above. The
size of 'user' is 64bit for a different reason altogether, but in this
case it is guaranteed to be always < U32_MAX. And hence using 64bit
divide is completely pointless (which I now realize).

Writing U32INT_MAX as 0xFFFFFFFFULL was a mistake on my part. I could
have avoided all of this by using built-in constants instead of trying
to define them myself. I will rewrite the function as below and send out
another patch:

static u64 user2rate_bytes(u64 user)
{
        u64 r;

        r = user ? U32_MAX / (u32) user : U32_MAX;
        r = (r - 1) << XT_HASHLIMIT_BYTE_SHIFT;
        return r;
}

-Vishwanath

  reply	other threads:[~2017-09-07 20:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-07 17:51 xt_hashlimig build error (was Re: [RFC 01/17] x86/asm/64: Remove the restore_c_regs_and_iret label) Linus Torvalds
2017-09-07 18:25 ` Vishwanath Pai
2017-09-07 18:43   ` Linus Torvalds
2017-09-07 20:16     ` Vishwanath Pai [this message]
2017-09-07 20:41       ` Lubashev, Igor
2017-09-07 20:45       ` Linus Torvalds
2017-09-07 21:21         ` Vishwanath Pai

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=6667f710-68f3-b97e-b0eb-d9879476831e@akamai.com \
    --to=vpai@akamai.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=arnd@arndb.de \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=davem@davemloft.net \
    --cc=ilubashe@akamai.com \
    --cc=jgross@suse.com \
    --cc=johunt@akamai.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=pablo@netfilter.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /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).