linux-kernel - Re: [RFC] Move kfree outside pde_unload

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]

Date:	Wed, 22 Aug 2012 01:03:52 +0300
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	Nathan Zimmer <nzimmer@....com>
Cc:	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [RFC] Move kfree outside pde_unload_lock

On Tue, Aug 21, 2012 at 03:54:54PM -0500, Nathan Zimmer wrote:
> I am currently tracking a hotlock reported by a customer on a large, 512 cores,
> system, I am currently running 3.6.0 rc1 but the issue looks like it has been
> this way for a very long time.
> The offending lock is proc_dir_entry->pde_unload_lock.  
> 
> In proc_reg_release we are doing a kfree under the spinlock which is ok but it
> means we are holding the lock longer then required. Scaling improved when I 
> moved kfree out.

It's OK to move it out.
Acked-by: Alexey Dobriyan <adobriyan@...il.com>

> Also shouldn't the comment on pde_unload_lock also note that pde_openers and 
> pde_unload_completion are both used under the lock?

Yeah, why not.

> --- a/fs/proc/inode.c
> +++ b/fs/proc/inode.c
> @@ -403,9 +403,11 @@ static int proc_reg_release(struct inode *inode, struct file *file)
>  	release = pde->proc_fops->release;
>  	if (pdeo) {
>  		list_del(&pdeo->lh);
> -		kfree(pdeo);
>  	}
>  	spin_unlock(&pde->pde_unload_lock);
> +	if (pdeo) {
> +		kfree(pdeo);
> +	}
>  
>  	if (release)
>  		rv = release(inode, file);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/