linux-kernel - Re: [PATCH 13/14] staging: lustre: llog: limit file size of plain logs

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:   Fri, 24 Feb 2017 17:59:10 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     James Simmons <jsimmons@...radead.org>
Cc:     devel@...verdev.osuosl.org,
        Andreas Dilger <andreas.dilger@...el.com>,
        Oleg Drokin <oleg.drokin@...el.com>,
        Alex Zhuravlev <alexey.zhuravlev@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Lustre Development List <lustre-devel@...ts.lustre.org>
Subject: Re: [PATCH 13/14] staging: lustre: llog: limit file size of plain
 logs

On Sat, Feb 18, 2017 at 04:47:14PM -0500, James Simmons wrote:
> From: Alex Zhuravlev <alexey.zhuravlev@...el.com>
> 
> on small filesystems plain log can grow dramatically. especially
> given large record sizes produced by DNE and extended chunksize.
> I saw >50% of space consumed by a single llog file which was still
> in use. this leads to test failures (sanityn, etc).
> the patch introduces additional limit on plain llog size, which
> is calculated as <free space>/64 (128MB at most) at llog creation
> time.
> 
> Signed-off-by: Alex Zhuravlev <alexey.zhuravlev@...el.com>
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6838
> Reviewed-on: https://review.whamcloud.com/18028
> Reviewed-by: Andreas Dilger <andreas.dilger@...el.com>
> Reviewed-by: wangdi <di.wang@...el.com>
> Reviewed-by: Mike Pershin <mike.pershin@...el.com>
> Reviewed-by: Oleg Drokin <oleg.drokin@...el.com>
> Signed-off-by: James Simmons <jsimmons@...radead.org>
> ---
>  drivers/staging/lustre/lustre/obdclass/llog.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/staging/lustre/lustre/obdclass/llog.c b/drivers/staging/lustre/lustre/obdclass/llog.c
> index 83c5b62..320ff6b 100644
> --- a/drivers/staging/lustre/lustre/obdclass/llog.c
> +++ b/drivers/staging/lustre/lustre/obdclass/llog.c
> @@ -319,10 +319,26 @@ static int llog_process_thread(void *arg)
>  				 * the case and re-read the current chunk
>  				 * otherwise.
>  				 */
> +				int records;
> +
>  				if (index > loghandle->lgh_last_idx) {
>  					rc = 0;
>  					goto out;
>  				}
> +				/* <2 records means no more records
> +				 * if the last record we processed was
> +				 * the final one, then the underlying
> +				 * object might have been destroyed yet.
> +				 * we better don't access that..
> +				 */
> +				mutex_lock(&loghandle->lgh_hdr_mutex);
> +				records = loghandle->lgh_hdr->llh_count;
> +				mutex_unlock(&loghandle->lgh_hdr_mutex);
> +				if (records <= 1) {
> +					rc = 0;
> +					goto out;
> +				}


So you now use the lock, in only one place, when reading a single value?
That makes no sense, it's obviously wrong, or not needed.

Please fix up these two patches...

thanks,

greg k-h