we don't need {len = PTR_ERR(pathname)} when IS_ERR(pathname) is false,
it's better to move it into if(IS_ERR(pathname)){}.
Signed-off-by: Kaitao Cheng <[email protected]>
---
fs/proc/base.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index d86c0afc8a85..9509e0d42610 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1753,9 +1753,10 @@ static int do_proc_readlink(struct path *path, char __user *buffer, int buflen)
return -ENOMEM;
pathname = d_path(path, tmp, PAGE_SIZE);
- len = PTR_ERR(pathname);
- if (IS_ERR(pathname))
+ if (IS_ERR(pathname)) {
+ len = PTR_ERR(pathname);
goto out;
+ }
len = tmp + PAGE_SIZE - 1 - pathname;
if (len > buflen)
--
2.20.1
Kaitao Cheng <[email protected]> writes:
> we don't need {len = PTR_ERR(pathname)} when IS_ERR(pathname) is false,
> it's better to move it into if(IS_ERR(pathname)){}.
Please look at the generated code.
I believe you will find that your change will generate worse assembly.
Eric
> Signed-off-by: Kaitao Cheng <[email protected]>
> ---
> fs/proc/base.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index d86c0afc8a85..9509e0d42610 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1753,9 +1753,10 @@ static int do_proc_readlink(struct path *path, char __user *buffer, int buflen)
> return -ENOMEM;
>
> pathname = d_path(path, tmp, PAGE_SIZE);
> - len = PTR_ERR(pathname);
> - if (IS_ERR(pathname))
> + if (IS_ERR(pathname)) {
> + len = PTR_ERR(pathname);
> goto out;
> + }
> len = tmp + PAGE_SIZE - 1 - pathname;
>
> if (len > buflen)
On Wed, May 27, 2020 at 09:41:53AM -0500, Eric W. Biederman wrote:
> Kaitao Cheng <[email protected]> writes:
>
> > we don't need {len = PTR_ERR(pathname)} when IS_ERR(pathname) is false,
> > it's better to move it into if(IS_ERR(pathname)){}.
>
> Please look at the generated code.
>
> I believe you will find that your change will generate worse assembly.
I think patch is good.
Super duper CPUs which speculate thousands instructions forward won't
care but more embedded ones do. Or in other words 1 unnecessary instruction
on common path is more important for slow CPUs than for fast CPUs.
This style separates common path from error path more cleanly.
And finally "len" here is local, so the issue barely deserves mention
but if target is in memory code like this happens:
static struct socket *sockfd_lookup_light(int fd, int *err, int *fput_needed)
{
struct fd f = fdget(fd);
struct socket *sock;
*err = -EBADF;
if (f.file) {
// unconditionally write to *err as well.
sock = sock_from_file(f.file, err);
if (likely(sock)) {
*fput_needed = f.flags;
return sock;
}
fdput(f);
}
return NULL;
}
so current style promotes more memory dirtying than necessary.
There is another place like this in sk_buff.c (search for ENOBUFS).
> > pathname = d_path(path, tmp, PAGE_SIZE);
> > - len = PTR_ERR(pathname);
> > - if (IS_ERR(pathname))
> > + if (IS_ERR(pathname)) {
> > + len = PTR_ERR(pathname);
> > goto out;
> > + }
Alexey Dobriyan <[email protected]> writes:
> On Wed, May 27, 2020 at 09:41:53AM -0500, Eric W. Biederman wrote:
>> Kaitao Cheng <[email protected]> writes:
>>
>> > we don't need {len = PTR_ERR(pathname)} when IS_ERR(pathname) is false,
>> > it's better to move it into if(IS_ERR(pathname)){}.
>>
>> Please look at the generated code.
>>
>> I believe you will find that your change will generate worse assembly.
>
> I think patch is good.
>
> Super duper CPUs which speculate thousands instructions forward won't
> care but more embedded ones do. Or in other words 1 unnecessary instruction
> on common path is more important for slow CPUs than for fast CPUs.
No. This adds an entire extra basic block, with an extra jump.
A good compiler should not even generate an extra instruction for this
case. A good compiler will just let len and pathname share the same
register.
So I think this will hurt your slow cpu case two as it winds up just
plain being more assembly code, which stress the size of the slow cpus
caches.
I do admit a good compiler should be able to hoist the assignment above
the branch (as we have today) it gets tricky to tell if hoisting the
assignment is safe.
> This style separates common path from error path more cleanly.
Very arguable.
[snip a completely different case]
Yes larger cases can have different solutions.
Eric