From: kernel test robot <lkp@intel.com>
To: Zi Yan <ziy@nvidia.com>,
linmiaohe@huawei.com, david@redhat.com, jane.chu@oracle.com,
kernel@pankajraghav.com,
syzbot+e6367ea2fdab6ed46056@syzkaller.appspotmail.com,
syzkaller-bugs@googlegroups.com
Cc: oe-kbuild-all@lists.linux.dev, ziy@nvidia.com,
akpm@linux-foundation.org, mcgrof@kernel.org,
nao.horiguchi@gmail.com,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Nico Pache <npache@redhat.com>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Lance Yang <lance.yang@linux.dev>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 1/2] mm/huge_memory: do not change split_huge_page*() target order silently.
Date: Sat, 11 Oct 2025 17:00:15 +0800 [thread overview]
Message-ID: <202510111633.onu4Yaey-lkp@intel.com> (raw)
In-Reply-To: <20251010173906.3128789-2-ziy@nvidia.com>
Hi Zi,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.17 next-20251010]
[cannot apply to akpm-mm/mm-everything]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Zi-Yan/mm-huge_memory-do-not-change-split_huge_page-target-order-silently/20251011-014145
base: linus/master
patch link: https://lore.kernel.org/r/20251010173906.3128789-2-ziy%40nvidia.com
patch subject: [PATCH 1/2] mm/huge_memory: do not change split_huge_page*() target order silently.
config: parisc-allnoconfig (https://download.01.org/0day-ci/archive/20251011/202510111633.onu4Yaey-lkp@intel.com/config)
compiler: hppa-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251011/202510111633.onu4Yaey-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510111633.onu4Yaey-lkp@intel.com/
All errors (new ones prefixed by >>):
mm/truncate.c: In function 'truncate_inode_partial_folio':
>> mm/truncate.c:229:14: error: too many arguments to function 'try_folio_split'; expected 3, have 4
229 | if (!try_folio_split(folio, split_at, NULL, min_order)) {
| ^~~~~~~~~~~~~~~ ~~~~~~~~~
In file included from include/linux/mm.h:1081,
from arch/parisc/include/asm/cacheflush.h:5,
from include/linux/cacheflush.h:5,
from include/linux/highmem.h:8,
from include/linux/bvec.h:10,
from include/linux/blk_types.h:10,
from include/linux/writeback.h:13,
from include/linux/backing-dev.h:16,
from mm/truncate.c:12:
include/linux/huge_mm.h:588:19: note: declared here
588 | static inline int try_folio_split(struct folio *folio, struct page *page,
| ^~~~~~~~~~~~~~~
mm/truncate.c:259:25: error: too many arguments to function 'try_folio_split'; expected 3, have 4
259 | try_folio_split(folio2, split_at2, NULL, min_order);
| ^~~~~~~~~~~~~~~ ~~~~~~~~~
include/linux/huge_mm.h:588:19: note: declared here
588 | static inline int try_folio_split(struct folio *folio, struct page *page,
| ^~~~~~~~~~~~~~~
vim +/try_folio_split +229 mm/truncate.c
179
180 /*
181 * Handle partial folios. The folio may be entirely within the
182 * range if a split has raced with us. If not, we zero the part of the
183 * folio that's within the [start, end] range, and then split the folio if
184 * it's large. split_page_range() will discard pages which now lie beyond
185 * i_size, and we rely on the caller to discard pages which lie within a
186 * newly created hole.
187 *
188 * Returns false if splitting failed so the caller can avoid
189 * discarding the entire folio which is stubbornly unsplit.
190 */
191 bool truncate_inode_partial_folio(struct folio *folio, loff_t start, loff_t end)
192 {
193 loff_t pos = folio_pos(folio);
194 size_t size = folio_size(folio);
195 unsigned int offset, length;
196 struct page *split_at, *split_at2;
197 unsigned int min_order;
198
199 if (pos < start)
200 offset = start - pos;
201 else
202 offset = 0;
203 if (pos + size <= (u64)end)
204 length = size - offset;
205 else
206 length = end + 1 - pos - offset;
207
208 folio_wait_writeback(folio);
209 if (length == size) {
210 truncate_inode_folio(folio->mapping, folio);
211 return true;
212 }
213
214 /*
215 * We may be zeroing pages we're about to discard, but it avoids
216 * doing a complex calculation here, and then doing the zeroing
217 * anyway if the page split fails.
218 */
219 if (!mapping_inaccessible(folio->mapping))
220 folio_zero_range(folio, offset, length);
221
222 if (folio_needs_release(folio))
223 folio_invalidate(folio, offset, length);
224 if (!folio_test_large(folio))
225 return true;
226
227 min_order = mapping_min_folio_order(folio->mapping);
228 split_at = folio_page(folio, PAGE_ALIGN_DOWN(offset) / PAGE_SIZE);
> 229 if (!try_folio_split(folio, split_at, NULL, min_order)) {
230 /*
231 * try to split at offset + length to make sure folios within
232 * the range can be dropped, especially to avoid memory waste
233 * for shmem truncate
234 */
235 struct folio *folio2;
236
237 if (offset + length == size)
238 goto no_split;
239
240 split_at2 = folio_page(folio,
241 PAGE_ALIGN_DOWN(offset + length) / PAGE_SIZE);
242 folio2 = page_folio(split_at2);
243
244 if (!folio_try_get(folio2))
245 goto no_split;
246
247 if (!folio_test_large(folio2))
248 goto out;
249
250 if (!folio_trylock(folio2))
251 goto out;
252
253 /*
254 * make sure folio2 is large and does not change its mapping.
255 * Its split result does not matter here.
256 */
257 if (folio_test_large(folio2) &&
258 folio2->mapping == folio->mapping)
259 try_folio_split(folio2, split_at2, NULL, min_order);
260
261 folio_unlock(folio2);
262 out:
263 folio_put(folio2);
264 no_split:
265 return true;
266 }
267 if (folio_test_dirty(folio))
268 return false;
269 truncate_inode_folio(folio->mapping, folio);
270 return true;
271 }
272
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2025-10-11 9:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-10 17:39 [PATCH 0/2] Do not change split folio target order Zi Yan
2025-10-10 17:39 ` [PATCH 1/2] mm/huge_memory: do not change split_huge_page*() target order silently Zi Yan
2025-10-10 18:02 ` Luis Chamberlain
2025-10-13 17:11 ` Zi Yan
2025-10-11 2:25 ` Lance Yang
2025-10-13 17:06 ` Zi Yan
2025-10-11 9:00 ` kernel test robot [this message]
2025-10-12 0:41 ` Wei Yang
2025-10-13 17:07 ` Zi Yan
2025-10-12 8:24 ` Pankaj Raghav (Samsung)
2025-10-13 17:11 ` Zi Yan
2025-10-15 14:25 ` Lorenzo Stoakes
2025-10-15 22:57 ` Zi Yan
2025-10-16 8:34 ` Lorenzo Stoakes
2025-10-10 17:39 ` [PATCH 2/2] mm/memory-failure: improve large block size folio handling Zi Yan
2025-10-10 18:05 ` Luis Chamberlain
2025-10-11 4:12 ` Miaohe Lin
2025-10-11 5:00 ` Matthew Wilcox
2025-10-11 9:07 ` Miaohe Lin
2025-10-13 17:04 ` Zi Yan
2025-10-11 10:23 ` kernel test robot
2025-10-13 17:08 ` Zi Yan
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=202510111633.onu4Yaey-lkp@intel.com \
--to=lkp@intel.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@redhat.com \
--cc=dev.jain@arm.com \
--cc=jane.chu@oracle.com \
--cc=kernel@pankajraghav.com \
--cc=lance.yang@linux.dev \
--cc=linmiaohe@huawei.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mcgrof@kernel.org \
--cc=nao.horiguchi@gmail.com \
--cc=npache@redhat.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=ryan.roberts@arm.com \
--cc=syzbot+e6367ea2fdab6ed46056@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/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