linux-kernel - Re: [PATCH] fs/gfs2/glock.c: Deinline do

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1824612152.49246801.1460143078420.JavaMail.zimbra@redhat.com>
Date:	Fri, 8 Apr 2016 15:17:58 -0400 (EDT)
From:	Bob Peterson <rpeterso@...hat.com>
To:	Denys Vlasenko <dvlasenk@...hat.com>
Cc:	Steven Whitehouse <swhiteho@...hat.com>, cluster-devel@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fs/gfs2/glock.c: Deinline do_error, save 1856 bytes

----- Original Message -----
> This function compiles to 522 bytes of machine code.
> 
> Error paths are not very time critical.
> 
> Signed-off-by: Denys Vlasenko <dvlasenk@...hat.com>
> CC: Steven Whitehouse <swhiteho@...hat.com>
> CC: Bob Peterson <rpeterso@...hat.com>
> CC: cluster-devel@...hat.com
> CC: linux-kernel@...r.kernel.org
> ---
>  fs/gfs2/glock.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
> index 6539131..c3d5172 100644
> --- a/fs/gfs2/glock.c
> +++ b/fs/gfs2/glock.c
> @@ -218,7 +218,7 @@ static void gfs2_holder_wake(struct gfs2_holder *gh)
>   *
>   */
>  
> -static inline void do_error(struct gfs2_glock *gl, const int ret)
> +static void do_error(struct gfs2_glock *gl, const int ret)
>  {
>  	struct gfs2_holder *gh, *tmp;
>  
> --
> 2.1.0
> 
> 

Hi Denys,

The name is misleading. Function do_error() isn't really an error path.
Its job is to "fail" all the holders for a glock that are doing a "try" lock
in cases where trying the lock has been determined to have failed.

Is there a reason why you want to trade memory for speed? Are you
optimizing for memory on an embedded device or something?
I guess I have no fundamental problem in adding this patch, but perhaps
Steve or someone can offer a second opinion before I do.

Regards,

Bob Peterson
Red Hat File Systems