Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp356431imu; Tue, 8 Jan 2019 21:55:56 -0800 (PST) X-Google-Smtp-Source: ALg8bN4lTagViQutJv/O4idRgsvQyGPZNxfY3DMjnYF689JIbETp3GWamTe5OJIv6Bz6A1C1PGBU X-Received: by 2002:a63:5c22:: with SMTP id q34mr4155440pgb.417.1547013356000; Tue, 08 Jan 2019 21:55:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547013355; cv=none; d=google.com; s=arc-20160816; b=k1J8NILgaRavJrvmkobMSvPme73NHdNiehWCkH8Oio0ZE+2ucXd91+RHViykTKGvuG vhmIwnw5aM/3hx3Ip0mXYtgsmQ3ZKNFF/YbMIrvGg9XEgHEwsJZhHgoChtTEtJwQwqff xiNkVSjJKiLqyBSUjuZ7GxC4kfCAnxWw9ZozivJpJUuA4q/WpNsMYqIl+B5Qt4339v12 TRqV10G/L5N5kjsf3O487FpFlenK+tNGRFTL3bU399vWH03fLNXoq7PfFshbHliTbyJ0 WKC5EHsuKyFWTE0v2w1sjQM+6Z6y8IUsH12efOUDhJVxX0qe8YW7ZcSm6v3H5MPfCwiS hWFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=/WVHyTuBrX2Rn5yLapMfjo88L7PXGhBB2wQv9lPJLEU=; b=CDkA4kNfjANjnWlLe03vjzwIj8c7Pv5B8E5+o0FbIcKYW4TIVE7QYoWkRINKXU2Yuw TbnTXZSclsUYUdvEjdC5sYKo3kBLFe8KGWfk+z8sDDgR/WFzEaUTQ7B5lPMUVq0t8ql+ XJ4J9j+SKux2kvAo4KjPmdPe3Yb3FVsRd0q0WZCXjtrG4aSaxZfaQZLaDtk0pxbjztyj 6UisAmeoJduJiVYxJ+HTV8PnHKza9byKLHkR90DIuf5uQwqxmI6nDdzBiQ50Jt9J5L6g p4rWVEE0OvD2qrcZzALMwJcZ0gS2NJOGrxwef/Xj9ZL+gsIMJF/iLV8/tCn+B1oOlP1b lTUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="SuY/z/BO"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 92si6717951pli.220.2019.01.08.21.55.39; Tue, 08 Jan 2019 21:55:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="SuY/z/BO"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729414AbfAIFfu (ORCPT + 99 others); Wed, 9 Jan 2019 00:35:50 -0500 Received: from mail-io1-f43.google.com ([209.85.166.43]:41014 "EHLO mail-io1-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727387AbfAIFfu (ORCPT ); Wed, 9 Jan 2019 00:35:50 -0500 Received: by mail-io1-f43.google.com with SMTP id s22so5083765ioc.8 for ; Tue, 08 Jan 2019 21:35:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/WVHyTuBrX2Rn5yLapMfjo88L7PXGhBB2wQv9lPJLEU=; b=SuY/z/BO2DWvTXym37KH8V9PADURSCmY0mMUoO4f4xmcl63689UWrvJQ8FEUKeg36K 5NkjRCJpQ4cPfmLojdIX2Y4EZm6oxnxmWU9+GkywRKdI0CTf99R7QiYUskkq48piUr9F zZY7l3CUrt+5sB2Rd0G7v60aLi5gw4k6bXcaxbRKA8eFyNF2IaPuGAXocXxfD8eDaMZZ gmWQvsVlhxo0rEfjFPSImwOEBMQZRcYrSMYMN6raJSNmJpeIvwTBdQle/KF5ASBlhBK7 ak0xGRuwPG9va+VCZLdPp4wHAJB8WGKe89ndM+FluFic2ZYPWD05ViviZIvmL+t7TRdO j4KA== 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=/WVHyTuBrX2Rn5yLapMfjo88L7PXGhBB2wQv9lPJLEU=; b=ijtTNDnan6aed+zwm0hMtpX3NWGS3txEb6tJJY78d168AGr6hWJ3OgIwAaC2nnLRCc Ci2pWuGbaQTWQFrYOC7I2rRbY+iGECKSoMhuz5JsbVRie1OQHTMsdUiup7MfJIJ0BWM/ lc1bxYGmMJV6x9rn84NShGNk2NRWu5yR7xux6FigAuMmhjhbIynedkJN2Gx4YmIVHbxW 8dh6cDycWcf02W3Rzr3yC1UVpxMWUEKWaX4J4CKIDFridAYFyJS2O3tkXDsZxT9r2dwt GVKHrQlyieonWsKo005KyP+JQA2Xq/eF6Y9HVQls4M/tXCeeGy0JsT7qdhxgqg/0k1tW Cv/A== X-Gm-Message-State: AJcUukcwicwmfBZuIV7Vt/v1Q3UVXWeaiTol+qNzk/ZMCzcqeuUJZd+g /PnAEJbIKsa73ebkidYM8hMbESGX93miecy82CmXsA== X-Received: by 2002:a5d:9456:: with SMTP id x22mr2509083ior.282.1547012149087; Tue, 08 Jan 2019 21:35:49 -0800 (PST) MIME-Version: 1.0 References: <20190109000214.GA5907@andrea> In-Reply-To: From: Dmitry Vyukov Date: Wed, 9 Jan 2019 06:35:37 +0100 Message-ID: Subject: Re: seqcount usage in xt_replace_table() To: Anatol Pomozov Cc: Andrea Parri , Florian Westphal , Paul McKenney , LKML , Andrey Konovalov Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 9, 2019 at 1:36 AM Anatol Pomozov wrote: > > Hello > > On Tue, Jan 8, 2019 at 4:02 PM Andrea Parri > wrote: > > > > Hi Anatol, > > > > On Tue, Jan 08, 2019 at 11:33:39AM -0800, Anatol Pomozov wrote: > > > Hello folks, > > > > > > A bit of context what I am doing. I am trying to port KTSAN (Kernel > > > Thread Sanitizer) tool to v4.20. That tool tracks shared data usage > > > and makes sure it is accessed in a thread-safe manner. > > > > Interesting! FYI, some LKMM's maintainers (Paul included) had and > > continued to have some "fun" discussing topics related to "thread- > > safe memory accesses": I'm sure that they'll be very interested in > > such work of yours and eager to discuss your results. > > Thread Sanitizer is a great tool to find thread-safety issues with > user-space code. The tool been developed by a team of smart people > from Google [1]. > > KTSAN is an attempt to bring the same ideas to Linux kernel [2]. A > bunch of work been done there but the project is still at > proof-of-concept point. > > I am not a part of Google's dynamic tools team. But I've decided to > pick something to do during the New Year holidays so started porting > KTSAN from v4.2 to v4.20. The work is "almost completed" but I need to > fix a few crashes [3]. > > [1] https://github.com/google/sanitizers > [2] https://github.com/google/ktsan/wiki > [3] https://github.com/anatol/linux/tree/ktsan_4.20 For completeness, at the time we also had to add read_seqcount_cancel() function to dynamically mark all seqcount read regions. It can be used here too, start read region and immediately end it. Less clear than raw_read_seqcount_nocritical(), but also less API surface. /** * read_seqcount_cancel - cancel a seq-read critical section * @s: pointer to seqcount_t * * This is a no-op except for ktsan, it needs to know scopes of seq-read * critical sections. The sections are denoted either by begin->retry or * by begin->cancel. */ static inline void read_seqcount_cancel(const seqcount_t *s) { ktsan_seqcount_end(s); } https://github.com/google/ktsan/blob/tsan/include/linux/seqlock.h#L235-L246