While writing the tests for copy_struct_from_user(), I used a construct
that Linus doesn't appear to be too fond of:
On 2019-10-04, Linus Torvalds <[email protected]> wrote:
> Hmm. That code is ugly, both before and after the fix.
>
> This just doesn't make sense for so many reasons:
>
> if ((ret |= test(umem_src == NULL, "kmalloc failed")))
>
> where the insanity comes from
>
> - why "|=" when you know that "ret" was zero before (and it had to
> be, for the test to make sense)
>
> - why do this as a single line anyway?
>
> - don't do the stupid "double parenthesis" to hide a warning. Make it
> use an actual comparison if you add a layer of parentheses.
So instead, use a bog-standard check that isn't nearly as ugly.
Fixes: 341115822f88 ("usercopy: Add parentheses around assignment in test_copy_struct_from_user")
Fixes: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
Signed-off-by: Aleksa Sarai <[email protected]>
---
lib/test_user_copy.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/lib/test_user_copy.c b/lib/test_user_copy.c
index e365ace06538..ad2372727b1b 100644
--- a/lib/test_user_copy.c
+++ b/lib/test_user_copy.c
@@ -52,13 +52,14 @@ static int test_check_nonzero_user(char *kmem, char __user *umem, size_t size)
size_t zero_end = size - zero_start;
/*
- * We conduct a series of check_nonzero_user() tests on a block of memory
- * with the following byte-pattern (trying every possible [start,end]
- * pair):
+ * We conduct a series of check_nonzero_user() tests on a block of
+ * memory with the following byte-pattern (trying every possible
+ * [start,end] pair):
*
* [ 00 ff 00 ff ... 00 00 00 00 ... ff 00 ff 00 ]
*
- * And we verify that check_nonzero_user() acts identically to memchr_inv().
+ * And we verify that check_nonzero_user() acts identically to
+ * memchr_inv().
*/
memset(kmem, 0x0, size);
@@ -93,11 +94,13 @@ static int test_copy_struct_from_user(char *kmem, char __user *umem,
size_t ksize, usize;
umem_src = kmalloc(size, GFP_KERNEL);
- if ((ret |= test(umem_src == NULL, "kmalloc failed")))
+ ret = test(umem_src == NULL, "kmalloc failed");
+ if (ret)
goto out_free;
expected = kmalloc(size, GFP_KERNEL);
- if ((ret |= test(expected == NULL, "kmalloc failed")))
+ ret = test(expected == NULL, "kmalloc failed");
+ if (ret)
goto out_free;
/* Fill umem with a fixed byte pattern. */
--
2.23.0
On Sun, Oct 06, 2019 at 10:30:28AM +1100, Aleksa Sarai wrote:
> While writing the tests for copy_struct_from_user(), I used a construct
> that Linus doesn't appear to be too fond of:
>
> On 2019-10-04, Linus Torvalds <[email protected]> wrote:
> > Hmm. That code is ugly, both before and after the fix.
> >
> > This just doesn't make sense for so many reasons:
> >
> > if ((ret |= test(umem_src == NULL, "kmalloc failed")))
> >
> > where the insanity comes from
> >
> > - why "|=" when you know that "ret" was zero before (and it had to
> > be, for the test to make sense)
> >
> > - why do this as a single line anyway?
> >
> > - don't do the stupid "double parenthesis" to hide a warning. Make it
> > use an actual comparison if you add a layer of parentheses.
>
> So instead, use a bog-standard check that isn't nearly as ugly.
>
> Fixes: 341115822f88 ("usercopy: Add parentheses around assignment in test_copy_struct_from_user")
> Fixes: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
> Signed-off-by: Aleksa Sarai <[email protected]>
I assume the comment diff is a line length/alignment thing? The commit
message does not mention it.
Regardless, thank you for providing the fix that I should have.
Reviewed-by: Nathan Chancellor <[email protected]>
On Sun, Oct 06, 2019 at 10:30:28AM +1100, Aleksa Sarai wrote:
> While writing the tests for copy_struct_from_user(), I used a construct
> that Linus doesn't appear to be too fond of:
>
> On 2019-10-04, Linus Torvalds <[email protected]> wrote:
> > Hmm. That code is ugly, both before and after the fix.
> >
> > This just doesn't make sense for so many reasons:
> >
> > if ((ret |= test(umem_src == NULL, "kmalloc failed")))
> >
> > where the insanity comes from
> >
> > - why "|=" when you know that "ret" was zero before (and it had to
> > be, for the test to make sense)
> >
> > - why do this as a single line anyway?
> >
> > - don't do the stupid "double parenthesis" to hide a warning. Make it
> > use an actual comparison if you add a layer of parentheses.
>
> So instead, use a bog-standard check that isn't nearly as ugly.
>
> Fixes: 341115822f88 ("usercopy: Add parentheses around assignment in test_copy_struct_from_user")
> Fixes: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
> Signed-off-by: Aleksa Sarai <[email protected]>
Fwiw, I think the commit message doesn't necessarily need to mention
stylistic preferences nor a specific mail. It's sufficient enough to say
that the new way makes things way more obvious. But ok. :)
I'll pick this up now.
Reviewed-by: Christian Brauner <[email protected]>
On 2019-10-06, Christian Brauner <[email protected]> wrote:
> On Sun, Oct 06, 2019 at 10:30:28AM +1100, Aleksa Sarai wrote:
> > While writing the tests for copy_struct_from_user(), I used a construct
> > that Linus doesn't appear to be too fond of:
> >
> > On 2019-10-04, Linus Torvalds <[email protected]> wrote:
> > > Hmm. That code is ugly, both before and after the fix.
> > >
> > > This just doesn't make sense for so many reasons:
> > >
> > > if ((ret |= test(umem_src == NULL, "kmalloc failed")))
> > >
> > > where the insanity comes from
> > >
> > > - why "|=" when you know that "ret" was zero before (and it had to
> > > be, for the test to make sense)
> > >
> > > - why do this as a single line anyway?
> > >
> > > - don't do the stupid "double parenthesis" to hide a warning. Make it
> > > use an actual comparison if you add a layer of parentheses.
> >
> > So instead, use a bog-standard check that isn't nearly as ugly.
> >
> > Fixes: 341115822f88 ("usercopy: Add parentheses around assignment in test_copy_struct_from_user")
> > Fixes: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
> > Signed-off-by: Aleksa Sarai <[email protected]>
>
> Fwiw, I think the commit message doesn't necessarily need to mention
> stylistic preferences nor a specific mail. It's sufficient enough to say
> that the new way makes things way more obvious. But ok. :)
>
> I'll pick this up now.
Thanks, and feel free to rewrite the commit message to whatever you'd
prefer.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>