From: Joe Perches <joe@perches.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: SF Markus Elfring <elfring@users.sourceforge.net>,
linux-raid@vger.kernel.org, Shaohua Li <shli@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] md: Combine two kmalloc() calls into one in sb_equal()
Date: Fri, 09 Dec 2016 21:57:57 +0000 [thread overview]
Message-ID: <1481320677.5946.44.camel@perches.com> (raw)
In-Reply-To: <20161209213030.GC1555@ZenIV.linux.org.uk>
On Fri, 2016-12-09 at 21:30 +0000, Al Viro wrote:
> On Fri, Dec 09, 2016 at 11:05:14AM -0800, Joe Perches wrote:
> > On Fri, 2016-12-09 at 19:30 +0100, SF Markus Elfring wrote:
> > > From: Markus Elfring <elfring@users.sourceforge.net>
> > > Date: Fri, 9 Dec 2016 19:09:13 +0100
> > >
> > > The function "kmalloc" was called in one case by the function "sb_equal"
> > > without checking immediately if it failed.
> > > This issue was detected by using the Coccinelle software.
> > >
> > > Perform the desired memory allocation (and release at the end)
> > > by a single function call instead.
> > >
> > > Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2")
> >
> > Making a change does not mean fixes.
> >
> > There's nothing particularly _wrong_ with the code as-is.
> >
> > 2 kmemdup calls might make the code more obvious.
> >
> > There's a small optimization possible in that only the
> > first MB_SB_GENERIC_CONSTANT_WORDS of the struct are
> > actually compared. Alloc and copy of both entire structs
> > is inefficient and unnecessary.
> >
> > Perhaps something like the below would be marginally
> > better/faster, but the whole thing is dubious.
> >
> > static int sb_equal(mdp_super_t *sb1, mdp_super_t *sb2)
> > {
> > int ret;
> > void *tmp1, *tmp2;
> >
> > tmp1 = kmemdup(sb1, MD_SB_GENERIC_CONSTANT_WORDS * sizeof(__u32), GFP_KERNEL);
> > tmp2 = kmemdup(sb2, MD_SB_GENERIC_CONSTANT_WORDS * sizeof(__u32), GFP_KERNEL);
> >
> > if (!tmp1 || !tmp2) {
> > ret = 0;
> > goto out;
> > }
> >
> > /*
> > * nr_disks is not constant
> > */
> > ((mdp_super_t *)tmp1)->nr_disks = 0;
> > ((mdp_super_t *)tmp2)->nr_disks = 0;
> >
> > ret = memcmp(tmp1, tmp2, MD_SB_GENERIC_CONSTANT_WORDS * sizeof(__u32)) = 0;
> >
> > out:
> > kfree(tmp1);
> > kfree(tmp2);
> > return ret;
> > }
>
> May I politely inquire if either of you has actually bothered to read the
> code and figure out what it does? This is grotesque...
>
> For really slow: we have two objects. We want to check if anything in the
> 128-byte chunks in their beginnings other than one 32bit field happens to be
> different. For that we
> * allocate two 128-byte pieces of memory
> * *copy* our objects into those
> * forcibly zero the field in question in both of those copies
> * compare the fuckers
> * free them
>
> And you two are discussing whether it's better to combine allocations of those
> copies into a single 256-byte allocation? Really?
No. May I suggest you read my suggestion?
At no point did I suggest a single allocation.
I think the single allocation is silly and just
makes the code harder to read.
> _IF_ it is a hot path,
> the obvious optimization would be to avoid copying that crap in the first
> place - simply by
> return memcmp(sb1, sb2, offsetof(mdp_super_t, nr_disks)) ||
> memcmp(&sb1->nr_disks + 1, &sb2->nr_disks + 1,
> MD_SB_GENERIC_CONSTANT_WORDS * sizeof(__u32) -
> offsetof(mdp_super_t, nr_disks) - 4);
That's all true, but Markus has enough trouble reading simple
code without trying to explain to him what offsetof does.
btw: the "- 4" should be " - sizeof(__u32)" just for consistency
with the line above it.
> If it is _not_ a hot path, why bother with it at all?
exactly.
WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: SF Markus Elfring <elfring@users.sourceforge.net>,
linux-raid@vger.kernel.org, Shaohua Li <shli@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] md: Combine two kmalloc() calls into one in sb_equal()
Date: Fri, 09 Dec 2016 13:57:57 -0800 [thread overview]
Message-ID: <1481320677.5946.44.camel@perches.com> (raw)
In-Reply-To: <20161209213030.GC1555@ZenIV.linux.org.uk>
On Fri, 2016-12-09 at 21:30 +0000, Al Viro wrote:
> On Fri, Dec 09, 2016 at 11:05:14AM -0800, Joe Perches wrote:
> > On Fri, 2016-12-09 at 19:30 +0100, SF Markus Elfring wrote:
> > > From: Markus Elfring <elfring@users.sourceforge.net>
> > > Date: Fri, 9 Dec 2016 19:09:13 +0100
> > >
> > > The function "kmalloc" was called in one case by the function "sb_equal"
> > > without checking immediately if it failed.
> > > This issue was detected by using the Coccinelle software.
> > >
> > > Perform the desired memory allocation (and release at the end)
> > > by a single function call instead.
> > >
> > > Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2")
> >
> > Making a change does not mean fixes.
> >
> > There's nothing particularly _wrong_ with the code as-is.
> >
> > 2 kmemdup calls might make the code more obvious.
> >
> > There's a small optimization possible in that only the
> > first MB_SB_GENERIC_CONSTANT_WORDS of the struct are
> > actually compared. Alloc and copy of both entire structs
> > is inefficient and unnecessary.
> >
> > Perhaps something like the below would be marginally
> > better/faster, but the whole thing is dubious.
> >
> > static int sb_equal(mdp_super_t *sb1, mdp_super_t *sb2)
> > {
> > int ret;
> > void *tmp1, *tmp2;
> >
> > tmp1 = kmemdup(sb1, MD_SB_GENERIC_CONSTANT_WORDS * sizeof(__u32), GFP_KERNEL);
> > tmp2 = kmemdup(sb2, MD_SB_GENERIC_CONSTANT_WORDS * sizeof(__u32), GFP_KERNEL);
> >
> > if (!tmp1 || !tmp2) {
> > ret = 0;
> > goto out;
> > }
> >
> > /*
> > * nr_disks is not constant
> > */
> > ((mdp_super_t *)tmp1)->nr_disks = 0;
> > ((mdp_super_t *)tmp2)->nr_disks = 0;
> >
> > ret = memcmp(tmp1, tmp2, MD_SB_GENERIC_CONSTANT_WORDS * sizeof(__u32)) == 0;
> >
> > out:
> > kfree(tmp1);
> > kfree(tmp2);
> > return ret;
> > }
>
> May I politely inquire if either of you has actually bothered to read the
> code and figure out what it does? This is grotesque...
>
> For really slow: we have two objects. We want to check if anything in the
> 128-byte chunks in their beginnings other than one 32bit field happens to be
> different. For that we
> * allocate two 128-byte pieces of memory
> * *copy* our objects into those
> * forcibly zero the field in question in both of those copies
> * compare the fuckers
> * free them
>
> And you two are discussing whether it's better to combine allocations of those
> copies into a single 256-byte allocation? Really?
No. May I suggest you read my suggestion?
At no point did I suggest a single allocation.
I think the single allocation is silly and just
makes the code harder to read.
> _IF_ it is a hot path,
> the obvious optimization would be to avoid copying that crap in the first
> place - simply by
> return memcmp(sb1, sb2, offsetof(mdp_super_t, nr_disks)) ||
> memcmp(&sb1->nr_disks + 1, &sb2->nr_disks + 1,
> MD_SB_GENERIC_CONSTANT_WORDS * sizeof(__u32) -
> offsetof(mdp_super_t, nr_disks) - 4);
That's all true, but Markus has enough trouble reading simple
code without trying to explain to him what offsetof does.
btw: the "- 4" should be " - sizeof(__u32)" just for consistency
with the line above it.
> If it is _not_ a hot path, why bother with it at all?
exactly.
next prev parent reply other threads:[~2016-12-09 21:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-09 18:30 [PATCH] md: Combine two kmalloc() calls into one in sb_equal() SF Markus Elfring
2016-12-09 18:30 ` SF Markus Elfring
2016-12-09 19:05 ` Joe Perches
2016-12-09 19:05 ` Joe Perches
2016-12-09 20:05 ` SF Markus Elfring
2016-12-09 20:05 ` SF Markus Elfring
2016-12-09 20:51 ` Joe Perches
2016-12-09 20:51 ` Joe Perches
2016-12-09 21:30 ` [PATCH] " Al Viro
2016-12-09 21:30 ` Al Viro
2016-12-09 21:57 ` Joe Perches [this message]
2016-12-09 21:57 ` Joe Perches
2016-12-09 19:09 ` Bernd Schubert
2016-12-09 19:09 ` Bernd Schubert
2016-12-09 19:54 ` SF Markus Elfring
2016-12-09 19:54 ` SF Markus Elfring
2016-12-09 21:18 ` Bernd Schubert
2016-12-09 21:18 ` Bernd Schubert
2016-12-09 21:58 ` SF Markus Elfring
2016-12-09 21:58 ` SF Markus Elfring
2016-12-09 22:04 ` Bernd Schubert
2016-12-09 22:04 ` Bernd Schubert
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=1481320677.5946.44.camel@perches.com \
--to=joe@perches.com \
--cc=elfring@users.sourceforge.net \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=shli@kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/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.