From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82B0EC35657 for ; Fri, 21 Feb 2020 18:02:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5330820722 for ; Fri, 21 Feb 2020 18:02:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="xQjdrHTy" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729484AbgBUSCh (ORCPT ); Fri, 21 Feb 2020 13:02:37 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:37605 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727699AbgBUSCh (ORCPT ); Fri, 21 Feb 2020 13:02:37 -0500 Received: by mail-oi1-f193.google.com with SMTP id q84so2437429oic.4 for ; Fri, 21 Feb 2020 10:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YwDEdueNqiLiTZn2fh4bRMDgxjPniW53g8xmvHACU8Q=; b=xQjdrHTyiXy4turHzDZawU33aP36M8C7jfcRPKkpZOWK4V8Zng8Z6f+ZgYj7VxJaFK 5Spfrxkvpfi24B5ZMNSQ4zijH9oXUi0TjkRHlZy4p+o+GHFj7sQp91f/yhA706x1ZWMy QI/h2BnyyFjtA2nPfmhrZidKwkesQDhIpNPE5Rq3JTzmWpzItKvuV7pFIm/r2ZDha7co 9f+SB7uplc1s7HwIkY6KPwsRdjrP3Q9n9R9o/2r5hb5l4YFol9quvryDblWiKQ2ERHY6 wHqrdXaOo/w+WgWBTejcc8efA2jIXWb8INL/HXIVLxDLOM7zPH3L/wwe9r8ECi41E5HS TBCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YwDEdueNqiLiTZn2fh4bRMDgxjPniW53g8xmvHACU8Q=; b=c/GcDbH+m3WmdCo67Y5O1v6htS+5zs4j8Z22VqkCukL0Nn+chGBJ8pZw+2D2t9h4/V RFIzCrKyBaRzokZF5SeF4DWL910Ce2oJkktjOQZjiTQcie5UTcqXUb1VFyyrZPcDEFru 2NjHlgF+LnqZJELa0y67OVqSQ1Z/0kPfENBf6ibJGYlllXjeY6NKLirXwaitBRKQu6K5 /A7ZwQloKz7bDuDlfHlQMFLRxi4F6BbbHqKBNThb63+poTkGV70hSvRvUdrdPgW4B16+ mHwnm6yFRR3MZ/ufdEIWnSaUbSPFsYqK3npaE5EMUUiSuSL+C3ypeg9fuBKZacclI7SF Gaog== X-Gm-Message-State: APjAAAWD/1bRkrqjsXhcYOULbFMB7NCZIsWOsSvqDMvQwwow+KLc/E8u OTfNmF1KHeZ4qJ432rfdkuekNPswuaX4+bBLbFjJag== X-Google-Smtp-Source: APXvYqyEtv2oGXx37l0a2b85lAJA3ombqXpMi4TeaNhtI8rq6+iJk+G5kX12275qe2nvDThK6H9LGH1udU668SSz7Zo= X-Received: by 2002:aca:c551:: with SMTP id v78mr3003192oif.161.1582308156744; Fri, 21 Feb 2020 10:02:36 -0800 (PST) MIME-Version: 1.0 References: <158204549488.3299825.3783690177353088425.stgit@warthog.procyon.org.uk> <158204559631.3299825.5358385352169781990.stgit@warthog.procyon.org.uk> <1808070.1582287889@warthog.procyon.org.uk> <2113718.1582304782@warthog.procyon.org.uk> In-Reply-To: From: John Stultz Date: Fri, 21 Feb 2020 10:02:25 -0800 Message-ID: Subject: Re: seq_lock and lockdep_is_held() assertions To: Jann Horn Cc: David Howells , Peter Zijlstra , Ingo Molnar , Will Deacon , Al Viro , raven@themaw.net, Miklos Szeredi , Christian Brauner , Linux API , linux-fsdevel , kernel list Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, Feb 21, 2020 at 9:36 AM Jann Horn wrote: > > adding some locking folks to the thread... > > On Fri, Feb 21, 2020 at 6:06 PM David Howells wrote: > > Jann Horn wrote: > > > On Fri, Feb 21, 2020 at 1:24 PM David Howells wrote: > > > > What's the best way to write a lockdep assertion? > > > > > > > > BUG_ON(!lockdep_is_held(lock)); > > > > > > lockdep_assert_held(lock) is the normal way, I think - that will > > > WARN() if lockdep is enabled and the lock is not held. > > > > Okay. But what's the best way with a seqlock_t? It has two dep maps in it. > > Do I just ignore the one attached to the spinlock? > > Uuuh... very good question. Looking at how the seqlock_t helpers use > the dep map of the seqlock, I don't think lockdep asserts work for > asserting that you're in the read side of a seqlock? > > read_seqbegin_or_lock() -> read_seqbegin() -> read_seqcount_begin() -> > seqcount_lockdep_reader_access() does seqcount_acquire_read() (which > maps to lock_acquire_shared_recursive()), but immediately following > that calls seqcount_release() (which maps to lock_release())? > > So I think lockdep won't consider you to be holding any locks after > read_seqbegin_or_lock() if the lock wasn't taken? Yea. It's a bit foggy now, but the main concern at the time was wanting to catch seqlock readers that happened under a writer which was a common cause of deadlocks between the timekeeping core and stuff like printks (or anything we called out that might try to read the time). I think it was because writers can properly interrupt readers, we couldn't hold the depmap across the read critical section? That's why we just take and release the depmap, since that will still catch any reads made while holding the write, which would deadlock. But take that with a grain of salt, as its been awhile. thanks -john