Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp7584557ybc; Thu, 28 Nov 2019 20:52:53 -0800 (PST) X-Google-Smtp-Source: APXvYqw62zxW85zWJwxAPxJFaxN9QoiH+w23MyXicWODDqLL01FGPRvaYO3pslZg3KnKMFUZtusw X-Received: by 2002:a17:906:7750:: with SMTP id o16mr58487608ejn.224.1575003173223; Thu, 28 Nov 2019 20:52:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575003173; cv=none; d=google.com; s=arc-20160816; b=Fc+IA6CIcUN7edKyHUSM+VYkpDyNBq+MitCyeh/5nOgNvc/lWemOhJmXbdeObPn8bK BCSmHM4plqxCF8hhpzOY7q38AVilvMu7tYicH/HeO+16Z9wcpYOG1SBCzMYuiR/YkL+C f8V/RohjzMxAQmZWNxp+llXvVBYS18rqtnZjT+vos6CenmpNR2SmOUaBF16mj2omVZCA ckM+lizI0SVuBndiSzu1roIZOg2ifG5r/AR1/WXkqBlxG/VxLf/BO8/ZrETneGhojO/5 QlnJc2B38Kkrml6XYzR2xhJ6i11K2nT63xoj7YDF657pGGGn+kgyR9SzuFKoo32HpbMh aMwg== 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=rqdB82PDk1aPHvXPJTP+tArND0SNQYY7vjCHcANExmk=; b=XUDwc1qlSmsRAy5tdY5tFNUTNyKccrbTzePQm/dcmkbu4OgoGpEAxrK6p8Gp4+x+3w A2B+8w4zx/6CK3XkXF4xRMTtGH6vyXrkoxukcOf4vmFk+m8TGnCAqtufWnfw74TiMuA6 wdlkKHRvODM/C8cvHPCqnFLtMyYzy05dEJybugKNK5R1Hcv2y4CJHyk1u7hksd/kuXXx hlRW5eaWvz1tso6yIWQbNPTUTO7HVfFyOsImMiU0IBhr3Hh6m94fYBo9qWQJyzhcCyzR mZ9IGB/LXPYMFKomjQU6VDh0xrS0TOy+h/1UNQlrd9ieugjDkyXwKfveTE9SoP7uJ9nK agSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=GA2KjSGL; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g6si14822545edf.256.2019.11.28.20.52.05; Thu, 28 Nov 2019 20:52:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-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=@gmail.com header.s=20161025 header.b=GA2KjSGL; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726934AbfK2En3 (ORCPT + 99 others); Thu, 28 Nov 2019 23:43:29 -0500 Received: from mail-ed1-f65.google.com ([209.85.208.65]:39888 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726876AbfK2En2 (ORCPT ); Thu, 28 Nov 2019 23:43:28 -0500 Received: by mail-ed1-f65.google.com with SMTP id n26so24643237edw.6 for ; Thu, 28 Nov 2019 20:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rqdB82PDk1aPHvXPJTP+tArND0SNQYY7vjCHcANExmk=; b=GA2KjSGLO9Da0WDcfWerQwQqaQsE3iXpK4OIevCpk8576eviSF7MK9RcQNiuXxMTnH 2bJHLTGJdwTnRQcJYJsc0TaVk60SJbTd+MnFaeJ8ng/Mz+N+IryiB0HOGD8MFnk2UeIU GVIvdcdJOcLHC+Zu5CaWi5HD4b6XLN4HgcMxLOgmfVyQQzh2ZcuJieZlIbJhsQ1JNkwd 3mrEiY8XdNsYqmdrlpOAUOcko8BCLtl2xBl1+l3/fmaj0gCjS56g9d6Oe7Vn8qSHyieD 1+nKpuSiBJ0WwDZEYKmC1njl4fW5CuYXB2y5HGWtxlsfbaw7c5J3/jO7o6Bfa96Mt1oe g82Q== 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=rqdB82PDk1aPHvXPJTP+tArND0SNQYY7vjCHcANExmk=; b=PYq0LefWiizBt1p0KGquuNVMDCEtWc/mvRZiwX39ZQYWP22bsDGCgx/Uo/26+e8JIG t1kTdZzQ2UHJ7iuIJ9Pff5DWZsGyavRuKelV5w2ssID6/ihk7tJ8c+5TpeOrNs05AQ5L Zd9kabEItVFpnDjFVToy5Mi1ZmFn4iJQWivJJUtQE3j9OQiN4iZnGVqBaxGwY/hzRjOn Imgvms23GXq3mNFTkrfjGEWarG7jVdwndSmguVWfo2EFf/m9GasV8J1aSQgcJVTyZNG7 +CScOunlkeaeqQd4dN47+MFYSpmsel9NlPCMCn/65LSHD6gBXT5bmyNO+iPVD8lKVnP6 ThOA== X-Gm-Message-State: APjAAAWY3UUzgGeFyOsiOTikhpvlcV6BBwLhuc68bfCiDqZeqBYpz4Fa FqAZ6oexw1h196FKPz9FfcbCdLUo4KbRU75nceUwytzi X-Received: by 2002:aa7:dc0c:: with SMTP id b12mr42145403edu.186.1575002605600; Thu, 28 Nov 2019 20:43:25 -0800 (PST) MIME-Version: 1.0 References: <20191128231947.GH22921@mit.edu> In-Reply-To: <20191128231947.GH22921@mit.edu> From: Meng Xu Date: Thu, 28 Nov 2019 23:43:14 -0500 Message-ID: Subject: Re: potential data race on ext_inode_hdr(inode)->eh_depth, ext_inode_hdr(inode)->eh_max between a creat and unlink syscall To: "Theodore Y. Ts'o" Cc: linux-ext4@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hi Ted, First, thank you for checking this out. I hook every memory access in the kernel so I know that the [READ] and [WRITE] are accessing to the exact same memory address. Plus, this access cannot be from two malloc-ed inode because we replaced kfree with a quarantine scheme like KASan so they two inodes will have to have two different addresses. This is what confused me too. In addition, just in case it may make a difference, there is an fsync happening on another thread too. The three threads are like: [Setup] mkdir("foo", 511) = 0; open("foo", 65536, 511) = 3; creat("bar", 511) = 4; symlink("foo", "sym_foo") = 0; open("sym_foo", 65536, 511) = 5; dup2(5, 195) = 195; [Thread 0: fsync(195)] [Thread 1: creat("bar", 438)] [Thread 2: unlink("sym_foo")] Or in orders observed at runtime: Enter fsync(195); Enter unlink("sym_foo"); Enter creat("bar", 438); Exit unlink("sym_foo"); Exit creat("bar", 438); Exit fsync(195); I can provide more information (eg, other function calls on the trace or memory access logs), if that would help in checking this case. And I am sorry for wasting your time if this case does not make sense. Best regards, Meng On Thu, Nov 28, 2019 at 6:19 PM Theodore Y. Ts'o wrote: > > On Thu, Nov 28, 2019 at 12:03:04PM -0500, Meng Xu wrote: > > I notice a potential data race on ext_inode_hdr(inode)->eh_depth, > > ext_inode_hdr(inode)->eh_max between a create and unlink syscall. > > Following is the trace: > > > > [Setup] > > mkdir("foo", 511) = 0; > > open("foo", 65536, 511) = 3; > > create("bar", 511) = 4; > > symlink("foo", "sym_foo") = 0; > > open("sym_foo", 65536, 511) = 5; > > > > [Thread 1] > > create("bar", 438); > > > > __do_sys_creat > > ksys_open > > do_filp_open > > path_openat > > do_last > > handle_truncate > > do_truncate > > notify_change > > ext4_setattr > > ext4_truncate > > ext4_ext_truncate > > ext4_ext _remove_space > > [WRITE, 2 bytes] ext_inode_hdr(inode)->eh_depth = 0; > > [WRITE, 2 bytes] ext_inode_hdr(inode)->eh_max > > = cpu_to_le16(ext4_ext_space_root(inode, 0)); > > > > [Thread 2] > > unlink("sym_foo"); > > > > __do_sys_unlink > > do_unlinkat > > iput > > iput_final > > evict > > ext4_evict_inode > > ext4_orphan_del > > ext4_mark_iloc_dirty > > ext4_do_update_inode > > [READ, 4 bytes] raw_inode->i_block[block] = ei->i_data[block]; > > > > > > I could observe that the order between the READ and WRITE is not > > deterministic and I was curious what will happen if the READ takes > > place in the middle of the two WRITES? Does it cause any damages or > > violations? > > This makes no sense. The inodes corresponding to "sym_foo" and "bar" > are completely differenth. So why would there be a data race? > > How are you concluding that that there is, in fact, a data race? > > - Ted