From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A5AE23002DF; Sun, 29 Mar 2026 15:49:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774799397; cv=none; b=C+0oW6cmblFViZRousiihFktxFOKW5Ezxa1p7/CXJZAwKD9qGzPhOB63BIoD5sE4wvZ0KVJyI8uxhjeZLUWXs+cX5+ueWF2Qps251V9ClWHnUsy7r8gAcJprK8o8wvIbGxjhN29B/EOy/Nwn26x+IYVHamc0qro5HMC863j0X6c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774799397; c=relaxed/simple; bh=iE1Cap7oN+cp6nkIZohrvPTbgBqghi/30U/wEpUeb2Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aIYMnSiINxV3AAUpTUXesEkhijnkM6Umlyc5eXv+gI5tj91yDAS2DRUcxV4hpo7zDR0vS8ULLst8YPEXgSRqc/AAPAMZYvaaRreH8wUU9AchPcG5RuSpDwvl90jd5jfx79ThebjyS8uijoiEVGq33eRXcVM/DgYqGkP8vFaipwc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rccDmTva; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rccDmTva" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A23B5C116C6; Sun, 29 Mar 2026 15:49:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774799397; bh=iE1Cap7oN+cp6nkIZohrvPTbgBqghi/30U/wEpUeb2Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rccDmTvaNBFtG9O+4KtDSMXF6lJD4aeHtHbnhdOu9vkiC7eSwr9SvG/jFYNbZNc6g JN+OX3Hr2QjdpnVuQvJb1sP2J341QhyVxuUZSXP7gH5k+LpF2yNH32nZCmSzQaZ4c2 fwDx+1W9h5Rlffzx2ysJkKIAvndzh54p+HfJguh/edCJFyTxzeTUWob8Hbpcb7CLSu fDz7G7LvlieYNbfcQslHnSSsG3DmcNdDYBzNcr2IT5cBrFv650AtxtAfZAJsFMJepO e5S0oYofBVoqC4N7U/lHOE9maIIgdhrzT0uM+XZBWBF3Hb6MSIXMeh4nuGohvpUoHr w3FkpWiHDbqkQ== From: SeongJae Park To: SeongJae Park Cc: Andrew Morton , "Liam R. Howlett" , "# 6 . 0 . x" , David Hildenbrand , Jonathan Corbet , Lorenzo Stoakes , Michal Hocko , Mike Rapoport , Shuah Khan , Suren Baghdasaryan , Vlastimil Babka , damon@lists.linux.dev, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: (sashiko review) [PATCH 2/2] Docs/admin-guide/mm/damon/lru_sort: warn commit_inputs vs param updates race Date: Sun, 29 Mar 2026 08:49:54 -0700 Message-ID: <20260329154955.47813-1-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260329153052.46657-3-sj@kernel.org> References: Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Forwarding Sashiko review for doing discussions via mails. # review url: https://sashiko.dev/#/patchset/20260329153052.46657-3-sj@kernel.org # start of sashiko.dev inline review commit 7f5e14b7be3b4aea36d62a6c529ef25dde22e973 Author: SeongJae Park Docs/admin-guide/mm/damon/lru_sort: warn commit_inputs vs param updates race This commit updates the DAMON LRU_SORT documentation to warn users against modifying module parameters while the kdamond thread is processing a commit_inputs request. It states that violating this rule can cause races and undefined behavior in the kernel. Link: https://lore.kernel.org/20260319161620.189392-2-objecting@objecting.org > diff --git a/Documentation/admin-guide/mm/damon/lru_sort.rst b/Documentation/admin-guide/mm/damon/lru_sort.rst > index a7dea7c75a9b..14cc6b2db897 100644 > --- a/Documentation/admin-guide/mm/damon/lru_sort.rst > +++ b/Documentation/admin-guide/mm/damon/lru_sort.rst > @@ -79,6 +79,10 @@ of parametrs except ``enabled`` again. Once the re-reading is done, this > parameter is set as ``N``. If invalid parameters are found while the > re-reading, DAMON_LRU_SORT will be disabled. > > +Once ``Y`` is written to this parameter, the user must not write to any > +parameters until reading ``commit_inputs`` again returns ``N``. If users > +violate this rule, the kernel may exhibit undefined behavior. Is it safe to rely on userspace following documentation to prevent kernel data races? The kernel is generally expected to be robust against concurrent or unexpected userspace inputs. Does addressing a data race with a documentation warning leave the kernel vulnerable to crashes or instability if a user ignores this rule? Could this underlying race condition be resolved with proper synchronization, such as locks or mutexes, rather than documenting the undefined behavior? # end of sashiko.dev inline review # review url: https://sashiko.dev/#/patchset/20260329153052.46657-3-sj@kernel.org # # hkml [1] generated a draft of this mail. It can be regenerated # using below command: # # hkml patch sashiko_dev --for_forwarding \ # 20260329153052.46657-3-sj@kernel.org # # [1] https://github.com/sjp38/hackermail Sent using hkml (https://github.com/sjp38/hackermail)