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 9FFC233ADA4 for ; Fri, 10 Apr 2026 07:54:08 +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=1775807648; cv=none; b=b0B4huGu5IwLu3ztrIxUK8nfbdivQHfvbQDlY/TmJ4ScMvp4bz/sJz/pLNXuLW55KbNwB2lPWxHYmvIz4O6BlsSzDdOr8blQQGUG1X2k5MlajUmSjqo60WRbbO8ngkSVQFQ+8Kh2VY2gwhJ3HzGxgR0+RCy3Lovf0akSiLfslCI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775807648; c=relaxed/simple; bh=lyEPxIQgdgDhkm5+q3i8AVYjElyUkUFGJlpM1WnOCMU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CfvjScmo2r5D7rNrBfaDE+xqpGp5no2+KUnu+VRxIBgT8q9WLSOVFTvyvGSyFWQmbn6zrC1o0I5DD47BRe9BVve1fYhoCeENQDDYoQvmfEmtrSQiPIqnKI9jGiXJSg0wqXcxLGZw20opRQ7yZYQMXLtg4ZFWI8bsxxrEDlQS+k0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=b+LCs10/; 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="b+LCs10/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DAA59C19421; Fri, 10 Apr 2026 07:54:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775807648; bh=lyEPxIQgdgDhkm5+q3i8AVYjElyUkUFGJlpM1WnOCMU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=b+LCs10/aPOGuTAHAFIjBy+ergqO1WXDb4Z95VST4uXqo9yfBxjMZrzf7X4WeGxyi Epv7B4UjQ7Wl+BGTD9GjFeyIhgaboDcQD5maYfnZ2GYW9/xmskm9ZCXuk68+ckW/ea Bj0JuCh5dmInlXg53wKTAssBk5HLM6Am2bBTvnoDkG9wGZInmn5xRkmG0YY0QM2VrJ icIaQqA6zbovqI1/VkXnwkKm2V9fFe0xSPLaolLey4dcACEeGDAfFZSwdtbkGLvKE6 kVCD/mtKoKBN01IUXR08XneQB2LBtuyTSEgRkr+ZK6CKKxS1+P/HT49dbC1sREBGUz ZXYzexxdS4B/w== Date: Fri, 10 Apr 2026 10:53:57 +0300 From: Mike Rapoport To: "David Hildenbrand (Arm)" Cc: Michael Neuling , =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= , "Vishal Moola (Oracle)" , Albert Ou , Aleksa Paunovic , Aleksandar Rikalo , Alexandre Ghiti , Andrew Jones , Andrew Morton , Arnd Bergmann , Djordje Todorovic , Guo Ren , Junhui Liu , Kevin Brodsky , Lorenzo Stoakes , Nam Cao , Oleg Nesterov , Oscar Salvador , Palmer Dabbelt , Paul Walmsley , Qinglin Pan , Raj Vishwanathan4 , linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH 3/5] riscv: mm: Fix NULL pointer dereference in __set_memory Message-ID: References: <20260409091143.1348853-1-mikey@neuling.org> <20260409091143.1348853-4-mikey@neuling.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Apr 10, 2026 at 09:42:26AM +0200, David Hildenbrand (Arm) wrote: > On 4/10/26 08:23, Michael Neuling wrote: > >>> area = find_vm_area((void *)start); > >>> + if (!area) { > >>> + ret = -EINVAL; > >>> + goto unlock; > >>> + } > >>> page_start = (start - (unsigned long)area->addr) >> PAGE_SHIFT; > >>> > >>> for (i = page_start; i < page_start + numpages; ++i) { > >> > >> Which caller would end up calling __set_memory() in such a way? > > > > It wouldn't. You're right on this and the other two. Sorry for the noise. > > Slopped-by: Cursor:claude-4.6-opus-high-thinking > > :) It's a general tendency of LLMs to generate overly defensive code and raise concerns about theoretical issues. Maybe it's worth taking into account when writing prompts specific to kernel development. > Patch #1 seems reasonable (although non-critical); not sure about patch > #2, leaving both to Risc-V people! > > -- > Cheers, > > David -- Sincerely yours, Mike.