linux-kernel - Re: [PATCH] [RFC] seqcount: Add lockdep functionality to seqcount/seqlock structures

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: <20130910084340.GL26785@twins.programming.kicks-ass.net>
Date:	Tue, 10 Sep 2013 10:43:40 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	John Stultz <john.stultz@...aro.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] [RFC] seqcount: Add lockdep functionality to
 seqcount/seqlock structures

On Mon, Sep 09, 2013 at 09:42:46PM -0700, John Stultz wrote:
> Currently seqlocks and seqcounts don't support lockdep.
> 
> After running across a seqcount related deadlock in the timekeeping
> code, I used a less-refined and more focused varient of this patch
> to narrow down the cause of the issue.
> 
> This is a first-pass attempt to properly enable lockdep functionality
> on seqlocks and seqcounts.
> 
> Due to seqlocks/seqcounts having slightly different possible semantics
> then standard locks (ie: reader->reader and reader->writer recursion is
> fine, but writer->reader is not), this implementation is probably not
> as exact as I'd like (currently using a hack by only spot checking
> readers), and may be overly strict in some cases.
> 
> I've handled one cases where there were nested seqlock writers, and
> there may be more edge cases, as while I've gotten it to run cleanly,
> depending on config its reporting issues that I'm not sure if they are
> flaws in the implementation or actual bugs. But I wanted to send this
> out for some initial thoughts as until today I hadn't looked at much
> of the lockdep infrastructure. So I'm sure there are improvements
> that could be made.
> 
> Comments and feedback would be appreciated!

> --- a/arch/x86/vdso/vclock_gettime.c
> +++ b/arch/x86/vdso/vclock_gettime.c
> @@ -178,13 +178,15 @@ notrace static int __always_inline do_realtime(struct timespec *ts)
>  
>  	ts->tv_nsec = 0;
>  	do {
> -		seq = read_seqcount_begin(&gtod->seq);
> +		seq = __read_seqcount_begin(&gtod->seq);
> +		smp_rmb();
>  		mode = gtod->clock.vclock_mode;
>  		ts->tv_sec = gtod->wall_time_sec;
>  		ns = gtod->wall_time_snsec;
>  		ns += vgetsns(&mode);
>  		ns >>= gtod->clock.shift;
> -	} while (unlikely(read_seqcount_retry(&gtod->seq, seq)));
> +		smp_rmb();
> +	} while (unlikely(__read_seqcount_retry(&gtod->seq, seq)));
>  
>  	timespec_add_ns(ts, ns);
>  	return mode;


You didn't mention the VDSO 'fun' in you Changelog!
--
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/