Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Fedor Pchelkin <pchelkin@ispras.ru>
Cc: Alexey Panov <apanov@astralinux.ru>,
	stable@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Max Kellermann <max.kellermann@ionos.com>,
	lvc-project@linuxtesting.org,
	syzbot+de04e06b28cfecf2281c@syzkaller.appspotmail.com,
	syzbot+c8c8238b394be4a1087d@syzkaller.appspotmail.com,
	Chao Yu <chao@kernel.org>,
	linux-kernel@vger.kernel.org, Yue Hu <huyue2@coolpad.com>,
	syzbot+4fc98ed414ae63d1ada2@syzkaller.appspotmail.com,
	Jeffle Xu <jefflexu@linux.alibaba.com>,
	Gao Xiang <xiang@kernel.org>,
	linux-erofs@lists.ozlabs.org
Subject: Re: [PATCH 6.1 1/2] erofs: handle overlapped pclusters out of crafted images properly
Date: Mon, 3 Mar 2025 08:31:42 +0800	[thread overview]
Message-ID: <0417518e-d02e-48a9-a9ce-8d2be53bc1bd@linux.alibaba.com> (raw)
In-Reply-To: <3vutme7tf24cqdfbf4wjti22u6jfxjewe6gt4ufppp4xplyb5e@xls7aozstoqr>



On 2025/3/3 02:13, Fedor Pchelkin wrote:
> On Mon, 03. Mar 01:41, Gao Xiang wrote:
>>>> diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c
>>>> index 94e9e0bf3bbd..ac01c0ede7f7 100644
>>>
>>> I'm looking at the diff of upstream commit and the first thing it does
>>> is to remove zeroing out the folio/page private field here:
>>>
>>>     // upstream commit 9e2f9d34dd12 ("erofs: handle overlapped pclusters out of crafted images properly")
>>>     @@ -1450,7 +1451,6 @@ static void z_erofs_fill_bio_vec(struct bio_vec *bvec,
>>>              * file-backed folios will be used instead.
>>>              */
>>>             if (folio->private == (void *)Z_EROFS_PREALLOCATED_PAGE) {
>>>     -               folio->private = 0;
>>>                     tocache = true;
>>>                     goto out_tocache;
>>>             }
>>>
>>> while in 6.1.129 the corresponding fragment seems untouched with the
>>> backport patch. Is it intended?
>>
>> Yes, because it was added in
>> commit 2080ca1ed3e4 ("erofs: tidy up `struct z_erofs_bvec`")
>> and dropped again.
>>
>> But for Linux 6.6.y and 6.1.y, we don't need to backport
>> 2080ca1ed3e4.
> 
> Thanks for overall clarification, Gao!
> 
> My concern was that in 6.1 and 6.6 there is still a pattern at that
> place, not directly related to 2080ca1ed3e4 ("erofs: tidy up
> `struct z_erofs_bvec`"):
> 
> 1. checking ->private against Z_EROFS_PREALLOCATED_PAGE
> 2. zeroing out ->private if the previous check holds true
> 
> // 6.1/6.6 fragment
> 
> 	if (page->private == Z_EROFS_PREALLOCATED_PAGE) {
> 		WRITE_ONCE(pcl->compressed_bvecs[nr].page, page);
> 		set_page_private(page, 0);
> 		tocache = true;
> 		goto out_tocache;
> 	}
> 
> while the upstream patch changed the situation. If it's okay then no
> remarks from me. Sorry for the noise..

Yeah, yet as I mentioned `set_page_private(page, 0);`
seems redundant from the codebase, I'm fine with either
way.

Thanks,
Gao Xiang

  reply	other threads:[~2025-03-03  0:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-28 16:51 [PATCH 6.1 0/2] erofs: handle overlapped pclusters out of crafted images properly Alexey Panov
2025-02-28 16:51 ` [PATCH 6.1 1/2] " Alexey Panov
2025-03-01  4:21   ` Sasha Levin
2025-03-02 10:56   ` Fedor Pchelkin
2025-03-02 17:41     ` Gao Xiang
2025-03-02 17:56       ` Gao Xiang
2025-03-02 18:13       ` Fedor Pchelkin
2025-03-03  0:31         ` Gao Xiang [this message]
2025-03-03  9:19           ` Fedor Pchelkin
2025-03-04 11:18             ` Алексей Панов
2025-02-28 16:51 ` [PATCH 6.1 2/2] erofs: fix PSI memstall accounting Alexey Panov
2025-03-01  4:20   ` Sasha Levin
2025-03-01  2:52 ` [PATCH 6.1 0/2] erofs: handle overlapped pclusters out of crafted images properly Gao Xiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0417518e-d02e-48a9-a9ce-8d2be53bc1bd@linux.alibaba.com \
    --to=hsiangkao@linux.alibaba.com \
    --cc=apanov@astralinux.ru \
    --cc=chao@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=huyue2@coolpad.com \
    --cc=jefflexu@linux.alibaba.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lvc-project@linuxtesting.org \
    --cc=max.kellermann@ionos.com \
    --cc=pchelkin@ispras.ru \
    --cc=stable@vger.kernel.org \
    --cc=syzbot+4fc98ed414ae63d1ada2@syzkaller.appspotmail.com \
    --cc=syzbot+c8c8238b394be4a1087d@syzkaller.appspotmail.com \
    --cc=syzbot+de04e06b28cfecf2281c@syzkaller.appspotmail.com \
    --cc=xiang@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox