From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-177.mta0.migadu.com (out-177.mta0.migadu.com [91.218.175.177]) (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 EACD64317D for ; Sat, 21 Mar 2026 03:21:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774063276; cv=none; b=m0d99jYOxp7hvMxAo1ZsjDH1qz1ZO8TS12sQDmgQR3rpLUevXEiXaT0jwOC542hKlCl1kkLK0OWEQmXd00pNmwiH7/N/ElNNcMTfmDuszHK5MQSOlSwkBFbaMmd0J8ZIOH/sCN2xwJM3nuVY/XN0KalRoI1TR24oVgVSYRakEMQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774063276; c=relaxed/simple; bh=CQAyaE2oi1Xy6HEIoO9svdo0D8BUXtFsn8Fw/Mu3fx8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Cc5gkr7MTbMFO/zeCdDJJGjghgQsvADAMVoDRqKhRfzgomBgh08AlLMp2hdQ3k0OCCCFOXWlvr36MDgyE9wtEMHv2UO0qLeO5ugne/XHHkI1Nsl8+ZpG3Z67v5fL7JHxzU00uHV2SDl3B1jj4GwVttPIR769RqHvjjaWPEA9NTs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=wnTSmKSk; arc=none smtp.client-ip=91.218.175.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="wnTSmKSk" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1774063271; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9GGpzAI+tXredIwGhfLL7ax5e2lwF3lCJ5jRuRq0pjM=; b=wnTSmKSk/2HYSuqvl4+ZbksIr7DumBfiHRJswxh0jH8xbzmLHhxUvH7thAFhFmOmfoHkRD 0u2bgUVws3avdrrJSEaamdhXaPu9AbLfNABUuTOm2E9TrIg335jmvGQBvxfsXN69O0yQqj 50S2qEtU/45HKCKE+XRBVW0SfvZIFEY= From: Roman Gushchin To: Andrew Morton Cc: "Lorenzo Stoakes (Oracle)" , David Hildenbrand , Zi Yan , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/9] mm/huge_memory: refactor zap_huge_pmd() In-Reply-To: <20260319200917.ce345a369d035050b6329ac5@linux-foundation.org> (Andrew Morton's message of "Thu, 19 Mar 2026 20:09:17 -0700") References: <20260319200917.ce345a369d035050b6329ac5@linux-foundation.org> Date: Fri, 20 Mar 2026 20:21:04 -0700 Message-ID: <87tsu9kgv3.fsf@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT Andrew Morton writes: > On Thu, 19 Mar 2026 13:00:06 +0000 "Lorenzo Stoakes (Oracle)" wrote: > >> The zap_huge_pmd() function is overly complicated, clean it up and also add >> an assert in the case that we encounter a buggy PMD entry that doesn't >> match expectations. >> >> This is motivated by a bug discovered [0] where the PMD entry was none of: >> >> * A non-DAX, PFN or mixed map. >> * The huge zero folio >> * A present PMD entry >> * A softleaf entry >> >> In zap_huge_pmd(), but due to the bug we manged to reach this code. >> >> It is useful to explicitly call this out rather than have an arbitrary NULL >> pointer dereference happen, which also improves understanding of what's >> going on. >> >> [0]:https://lore.kernel.org/all/6b3d7ad7-49e1-407a-903d-3103704160d8@lucifer.local/ > > AI review has questions, which I assume you've seen > https://sashiko.dev/#/patchset/cover.1773924928.git.ljs%40kernel.org > > > > This isn't going well from a workflow POV. I merge stuff (this was v2) > then half a day later a bunch of potential issues are identified. > > If these reviews are useful (they seem to be, enough) then I guess I'll > need to further increase the lag between seeing-it and merging-it. But > if there's a 2-day lag before I get onto a series and I'm the first to > look at Sashiko then that won't help. > > So it needs to be something like > > - series is posted > - 24 hours pass > - submitter takes a look at the AI review, maybe prepares a new > series. > - 24 hours pass > - rinse, repeat > - it gets merged, hopefully with some Reviewed-by"s. > > Not unreasonable, but it requires that submitter be made aware of > Sashiko's comments. At present that's via me being tiresome. > > > Anyway, early days. I'm thinking that an emailed reply-to-all from > Sashiko will help. Much hinges on how useful submitters find these > questions to be - something which I'm paying close attention to... For bpf Alexei suggested to always send the review to the author and cc the bpf mailing list, but ignore maintainers and other mailing lists like lkml to minimize the traffic. It sounds like a good trade off to me. If there are concerns about polluting the mm mailing list, maybe something like a new list like "mm-new" / "mm-early" might work? Idk what's the best thing here to do, just throwing some ideas. Likely next week I'll be able to send reviews over the email and I can send them to whoever we think it's appropriate. Thanks!