From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) (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 BD717231A30 for ; Wed, 24 Dec 2025 01:43:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766540598; cv=none; b=Nsn8gk2RFwkUSMU5gJ6prQxwfy6li9l6mkNkx9RhKSrcOrB9X0DZpA412VO1JQ/vfTYs7zxYDCbvmSvcUupT0ohTCZlPhFznZgVGKU5RyAeFLB9X3D7PiyhkwqXFskR5pFRDlaKyvtq4zENHZNXDP/tG8j7W2S1oFuweifbmJp4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766540598; c=relaxed/simple; bh=sMjyhWDsGrcYIzXCWgKymt1XO7YFhgpkp98IlWXA62M=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ZYpsamTIC5QOEc7j9DmxjZwdb9Xz7XQl9PMdYAFrs55qw+gav2MFIjFgcpZqqyZSrA4vvhgKRpoB7BAnotpkRFgJG7vPLZ+jXmm/3eY2Vnu7lv6/xoHFz/GpPeT69RptjZJS/F3vyWQMx0IsUP5SsemRGd2pJMo8BTjxjBIT1fo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=IXR2DRNP; arc=none smtp.client-ip=115.124.30.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="IXR2DRNP" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1766540587; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=RTBbu/2wTfEwRaeB/LIZ7XgTg0+gpS5cMbulWwscrZA=; b=IXR2DRNPm9SVH6g6/AJnXkUr51jz5nafe70tWqo/xP1GzSsUC1WTEgkvQ2dyGFlMWTtwiPbDr4Gchy37wqo+fI14WLDXjrMXam4jXaDAeTupcxqeWwHeYqEDsfVZURMjfYe2G3dn0osVsHQbv74tvn4DyOGOYGFXfXbQHwzW2FY= Received: from 30.74.144.133(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WvZJ6O2_1766540585 cluster:ay36) by smtp.aliyun-inc.com; Wed, 24 Dec 2025 09:43:05 +0800 Message-ID: <9bbc1962-5f6f-4e3c-a672-d80565aa5157@linux.alibaba.com> Date: Wed, 24 Dec 2025 09:43:04 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [syzbot] [mm?] KMSAN: uninit-value in swap_writeout To: Barry Song <21cnbao@gmail.com>, pfalcato@suse.de Cc: akpm@linux-foundation.org, bhe@redhat.com, chrisl@kernel.org, hughd@google.com, kasong@tencent.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, nphamcs@gmail.com, shikemeng@huaweicloud.com, syzbot+178fff6149127421c2cc@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com References: <7ng6tntadu62ls32r54aetyevgbghta4oufyzxtq5ym6bprjai@hc2ozb2mbcyb> <20251224001617.45293-1-21cnbao@gmail.com> From: Baolin Wang In-Reply-To: <20251224001617.45293-1-21cnbao@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2025/12/24 08:16, Barry Song wrote: > On Wed, Dec 24, 2025 at 12:43 PM Pedro Falcato wrote: >> >> On Wed, Dec 24, 2025 at 11:46:44AM +1300, Barry Song wrote: >>>> >>>> Uninit was created at: >>>>  __alloc_frozen_pages_noprof+0x421/0xab0 mm/page_alloc.c:5233 >>>>  alloc_pages_mpol+0x328/0x860 mm/mempolicy.c:2486 >>>>  folio_alloc_mpol_noprof+0x56/0x1d0 mm/mempolicy.c:2505 >>>>  shmem_alloc_folio mm/shmem.c:1890 [inline] >>>>  shmem_alloc_and_add_folio+0xc56/0x1bd0 mm/shmem.c:1932 >>>>  shmem_get_folio_gfp+0xad3/0x1fc0 mm/shmem.c:2556 >>>>  shmem_get_folio mm/shmem.c:2662 [inline] >>>>  shmem_symlink+0x562/0xad0 mm/shmem.c:4129 >>>>  vfs_symlink+0x42f/0x4c0 fs/namei.c:5514 >>>>  do_symlinkat+0x2ae/0xbb0 fs/namei.c:5541 >>> >>> +Hugh and Baolin. Thanks for CCing me. >>> >>> This happens in the shmem symlink path, where newly allocated >>> folios are not cleared for some reason. As a result, >>> is_folio_zero_filled() ends up reading uninitialized data. >>> >> >> I'm not Hugh nor Baolin, but I would guess that letting >> is_folio_zero_filled() skip/disable KMSAN would also work. Since all we want >> is to skip writeout if the folio is zero, whether it is incidentally zero, or not, >> does not really matter, I think. > > Hi Pedro, thanks! You’re always welcome to chime in. > > You are probably right. However, I still prefer the remaining > data to be zeroed, as it may be more compression-friendly. > > Random data could potentially lead to larger compressed output, > whereas a large area of zeros would likely result in much smaller > compressed data. Thanks Pedro and Barry. I remember Hugh raised a similar issue before (See [1], but I did not investigate further:(). I agree with Hugh's point that the uninitialized parts should be zeroed before going the outside world. [1] https://lore.kernel.org/all/02a21a55-8fe3-a9eb-f54b-051d75ae8335@google.com/ > Not quite sure if the below can fix the issue: > > diff --git a/mm/shmem.c b/mm/shmem.c > index ec6c01378e9d..0ca2d4bffdb4 100644 > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -4131,6 +4131,7 @@ static int shmem_symlink(struct mnt_idmap *idmap, struct inode *dir, > goto out_remove_offset; > inode->i_op = &shmem_symlink_inode_operations; > memcpy(folio_address(folio), symname, len); > + memset(folio_address(folio) + len, 0, folio_size(folio) - len); > folio_mark_uptodate(folio); > folio_mark_dirty(folio); > folio_unlock(folio); That looks reasonable to me, though I prefer to use the more readable helper: folio_zero_range(). Barry, could you send out a formal patch？ Thanks.