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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56C24C47DA2 for ; Wed, 17 Jan 2024 20:38:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C627B6B0093; Wed, 17 Jan 2024 15:38:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B93A56B008C; Wed, 17 Jan 2024 15:38:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A35756B0092; Wed, 17 Jan 2024 15:38:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8E3646B0081 for ; Wed, 17 Jan 2024 15:38:36 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3EE73C0653 for ; Wed, 17 Jan 2024 20:38:36 +0000 (UTC) X-FDA: 81689966232.22.8DAA63E Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf05.hostedemail.com (Postfix) with ESMTP id CDC1A100020 for ; Wed, 17 Jan 2024 20:38:33 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Qe4YR7qx; dmarc=none; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705523914; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8KR7LDuJuULbvbkfkcg0Pw2uzyZFXH73CrNO1+XqHr4=; b=iIf+4+iiWMqoW0xcd7TQatLE7dc1/bDGJV8ErpU2iNj7EuxtvULKWgzk957IbkifvieHdu B/XUpBdKloespYqHUjqpiVRzZmHUbAZEBqH7VsEilzcP/l+FcL6cfMlH/GFOG73xO8uVdh sYazofZ6411ltklSDw0NmLvShzk48fg= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Qe4YR7qx; dmarc=none; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705523914; a=rsa-sha256; cv=none; b=6hJiWl4F0TTbaxwfDD9KC3GaqOJLQg0ifCMtZk/G2AhjSXaulaxi2X2aQQIrVJ+nOAqiFm 7FqYRUDGuW8+EFuQDuFDf3ZqtZG/MzbdQeLRfHQW0KQZLSp8i77EEa6qFO3tm/RK6m6sW0 p7EtiY/mvg8vpzM4XYn7VM+JLnmgCSk= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=8KR7LDuJuULbvbkfkcg0Pw2uzyZFXH73CrNO1+XqHr4=; b=Qe4YR7qx2xbxXS54byCy3o9N7Z eqQ7K538mxhgX2CrPfASvUzk90bcnIG89ow+XvVsXTxly3/QmT/UqbY64V+1kuDZ12lDtFiEx1v7R FXC8tu17hbgN1oz35+I2xo/ipwgsisghxBiyKA3rrGZiz04Hi8hUGnYWHK2Qw0mbIbdEPJwx/x4yz aaW4PwPjh2JDm+wVbSDZHCN292HgMWCKrRpne/iMUQ0qtAnyv+HablXB+DyMX4k6SsxIWazC7c7ih h54bkRYJR2o8isOzjhpWrWV68bLOtwapjl6jYGXqXgN1WXd7Lvp98G5oDpv9dx46xCiZtqm546xYF zFuAtOPQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rQCgA-00000000ibD-1sZY; Wed, 17 Jan 2024 20:38:30 +0000 Date: Wed, 17 Jan 2024 20:38:30 +0000 From: Matthew Wilcox To: Gabriel Ryan Cc: Andrew Morton , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: Race in mm/readahead.c:140 file_ra_state_init / block/ioctl.c:497 blkdev_common_ioctl Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: CDC1A100020 X-Stat-Signature: 8cta9zb3pdgre79mscq7ps4kb6oun3xe X-HE-Tag: 1705523913-505121 X-HE-Meta: U2FsdGVkX19OBX0uey/8fckShdpdYvfFogWiGbOGekrNl1SCRgt/MOw0KeRghZtoSo5habRlWLPgcatoIhVW9BMdQWqIUZrj0A2Kr6HBhH7O2kLsaRPycaKvJzb2LrcVYGoWgCpg3edgrc30pBsFxnPKG6BWtF6iK3tWQArQCn+66WJj//wgy4z9PF/QK7ifhAHkVFBa5QWJm6Kdd376Wwxk4Rp+FTZ4L90Mm+Rq2UOXjNKBxZHL32iqs/rEWcp6nopgsCXBwB0OUnehh2b4AU9cqpyLk5IAO/wosTM4ReTgvVL+RgGWnyGFxh4+gck8KUMkuEO/UCAfILYEEcaAZH2jVvBfr3Pw3QUNNvGopU0fyvmU5wRnLZ9KjLU1E+2SY4BQUOZgviexfiYVyPPMMRBqawH+RxmMgilYRA7y6ujGLTCQxK/i+YgC4buDuXIor5JIiAuDN1sUeTMXzKYhiGaB4xqOHRrVui5PwvOKq9RBPqORvN1AMuLOwfYsQ0ZEbR4/Uk7hJ6j5Q9SpbPmqjUGf7z/HcCiKCa0x+y095bI2ECnmPTgUs9sL6X4JUCaPCF+u33fVs/j5v9rIPyLQSsbsXNhB4EsK6PNTwWdf4/pncg2kEquWezlYq/L7obIzq/grhLUAzj4OgYoNFoduRCUwlReD57r6TD2OXafGRP6IK1iILvEOELi9nP6CFH+TX+QuL14uVcJTyayLoSXfdmmsulCYB81QKnRE2peFmZoNrNC6uBYUuhYCT9tEiwEP1dEi40jZtaODDtgW32WfJRdGQ+WG5WbLKwNklK94zbXTfQkqMEmFFCvjUgVg+kxpVxcgmKKHluSnyISHfEgnqvg0ODWdohkZ/+VKxr823n2qNkzLJvKd7o0+T3GBWYW2QCaFrvV79nKO2YqLccNAlSvslO8u2FmwzPnl//yhUAWN8qVl+HlB1TTpXSD287yHsqnDf4QbAyupFYUP78e bf6hlcvV tVB4uDjUPf8DCCF8yHuhLFIFw+AZwbffG1c2JBWyi519NQY035gbqeUUKb4t0SGPFDzgKC1/PoaBO7mWYBOzAWayXBakGt/v8ECglRr6BLKm1B+57Cn7XWi1iSDPAn/No3QTO1X5hrYSubAeTsfLVxbnKW7ms9k2qqo300b0ZTxn6r2ExJkJzXlbGIw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Jan 17, 2024 at 03:08:47PM -0500, Gabriel Ryan wrote: > We found a race in the mm subsystem in kernel version v5.18-rc5 that What an odd kernel version to be analysing. It's simultaneously almost two years old, and yet not an actual release. You'd be better off choosing an LTS kernel as your version to analyse, something like v6.6 or v6.1. Or staying right on the bleeding edge and using something more recent like v6.7. > appears to be potentially harmful using a race testing tool we are > developing. The race occurs between: > > mm/readahead.c:140 file_ra_state_init > > ra->ra_pages = inode_to_bdi(mapping->host)->ra_pages; > > block/ioctl.c:497 blkdev_common_ioctl > > bdev->bd_disk->bdi->ra_pages = (arg * 512) / PAGE_SIZE; > > > which both set the ra->ra_pages value. It appears this race could lead > to undefined behavior, if multiple threads set ra->ra_pages to > different values simultaneously for a single file inode. Undefined behaviour from the C spec point of view, sure. But from a realistic hardware/compiler point of view, not really. These are going to be simple loads & stores. since bdi->ra_pages is an unsigned long. And if it does happen to be garbage, how much harm is really done? We'll end up with the wrong readahead value for a single open file. Performance might not be so great, but it's not like we're going to grant root access as a result. We should probably add READ_ONCE / WRITE_ONCE annotations to be certain the compiler doesn't get all clever, but that brings me to the question about why you're developing this tool. We already have tooling to annoy people with these kinds of nitpicks (KCSAN).