From owner-freebsd-hackers@freebsd.org Mon Aug 12 10:49:05 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9D29BAE052; Mon, 12 Aug 2019 10:49:05 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 466Xds3YjXz48sJ; Mon, 12 Aug 2019 10:49:05 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-ot1-x341.google.com with SMTP id c34so17030902otb.7; Mon, 12 Aug 2019 03:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uBM1FAzsK84kstKTP657BIwgAzqQ8ZqZnFgsxMyzFW4=; b=SIf8MRxtg0Q50ipF5GtSIQg+27xLQ/x+F9MjasDTBMLfJGGszwMWFxo9jU7EYYPwN/ kKwzcmp1hCaxuzy589i0c5BhFfXY3HLf+1tmwjGk5Y7mVXNkGDHYj73bG+UNSYhrdsaq 1uMDaQrP4pPm4sXB/YcUu23TTfP77kOfODOyhFoPMQX8zoReY9aXzYKzOrWKrT7bDrR3 IPBBLzYaeTQ0+4iO3Q/YAW2euw4zBKemwExDneVp4ab65Xi/jgpPFMc/7PSyyM/Wukf3 Ja2z/2r38mNphELxID2L7VSHORhdOtvn/6EerTHpwFxZyG3o8m5Xv3EA7aP6hyAUoIY8 1dtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uBM1FAzsK84kstKTP657BIwgAzqQ8ZqZnFgsxMyzFW4=; b=Lx1sRjmWsU9/rb5PvHS3KdAetqSScLHa7YuVaCdIi7iMmESCB1hyzcedhLhrZ1PXPb 3wcrGe+bA0O65oI0D0VTNzYd7hJjXFky8vzocccHeBIWrCVHv4QWtj6qUVJJLsvSM2MW b35ys4oBISyH816HB7M53dwrsUbPxOhRb8F/CljLtM45bJlRHWN0vnqRMapidiNOqrJQ GQC21qjaCn+KaX7iYTw0q1Ae6zIiiO8LlMV0FyNCh6D5Z9G9Xg38AexNn1PPltdTZLJd xoy3Ii4/4WnxJ8hazlttHSx7gN+f0+NEhcLUgFJbrSqDb5/ZV6MwZlZImF2zfbIcoH1M P8+A== X-Gm-Message-State: APjAAAVp41iej1C4a4FegtV8NXiSXFZzEt2PNIxMOZTl/0Xw8x19c5Gf RvcGBaUX9g9FImyU7613ds0Egdd6AmGY2RBFDqffgA== X-Google-Smtp-Source: APXvYqw3sinxQGx9jkWCp74zJlcxGZgJCOpf1y7dBMzRZBP3nn/mNfNgR6krOKOttXxsxVmS8g/7fgs/CgKRVBgalYE= X-Received: by 2002:aca:b788:: with SMTP id h130mr15046815oif.85.1565606944173; Mon, 12 Aug 2019 03:49:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:2516:0:0:0:0:0 with HTTP; Mon, 12 Aug 2019 03:49:03 -0700 (PDT) In-Reply-To: <94110a73-3c55-e87e-96ae-475014e45596@FreeBSD.org> References: <94110a73-3c55-e87e-96ae-475014e45596@FreeBSD.org> From: Mateusz Guzik Date: Mon, 12 Aug 2019 12:49:03 +0200 Message-ID: Subject: Re: userret: assert td_lk_slocks == 0 To: Andriy Gapon Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 466Xds3YjXz48sJ X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.984,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 10:49:05 -0000 On 8/12/19, Andriy Gapon wrote: > > I am trying to debug a leak of a shared vnode lock and I noticed that > there is no check for td_lk_slocks in userret. There are checks for > td_rw_rlocks and td_sx_slocks. I wonder if there is any valid scenario > where a thread is allowed to retain a shared lock manager lock across > system calls. > These counters are not for debugging purposes. They are part of poor man's starvation prevention for writers. If the target lock is taken for reading and someone wants to take it for writing, a bit will be set to denote this fact and prevent more readers from showing up. However, this can lead to deadlocks so if someone already has a read lock on something, they can bypass the bit and grab the extra read lock anyway. No locks are allowed to leak back to userspace and witness should already handles checking this for readers as well. -- Mateusz Guzik