From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 E2174EED8 for ; Wed, 24 Jul 2024 20:02:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721851331; cv=none; b=PJbNktUzN5EkVnZlhQiiSoN/RCH1Xo38TW2WhA2UBirxL5VtyJ0rCv+vLaUqdXxq4vLbzfUxz0SOO+2CAICuussq/gXI5AGGfoHjzcT6dl4elzrXfpZvol/2c6azsRwSrwrcxKKFH77NAZdkaMdZrbTSBpaYHpTlM1iBusL1llM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721851331; c=relaxed/simple; bh=AnAbb5dmG5VfcU6B4Yn+5Mrfjo8HWyP8YyXss+Ds3ac=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=l4AWJKVVwmJKNEGvyAGtyEx++8ZLcvxo7ID7QxC/tnnM05vWVu6PUIo4LoF48uzRt4fBE6s5CCOlwTTrz+dstR1WdN3jtyhp4sszuyQrD1Ht9zGEqcNOkZv7A+k+2syCs/onrYY3lKV4C5A0uOFroUFbedakCqa1aj65V4HSvY8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=ELIfEZvw; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="ELIfEZvw" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=RNDXkPq/hLVDx0ibhbMTtzI+6SBozY+rsScaYjX/r/k=; b=ELIfEZvwq5q99yWUqNEI7+YrKF VH8lYBG42hPEtkpp9jkc/fKCnIICDaTA4MkXcfal34pQoSQTS2a+2HI2DlTSmHr6fdFGfEGaJkOBo m34xy/earl4muLqQHMWmoLHj164+oXrgzAQ1o4llbznxPAC1rcKsIY8ty1w9clUVNGxynQMS19FNI Vf8qCPb8eGPjMYgZt+PdI3JUssHjYVXj8cjl5hetjW0IpIf6akOPEC8hsFiw2/a9UiSU+BCgGsucH SEkw24fgv/uzOTlYUwG3Ub0CCEUg59h1z7X0ibp3aPWSWfCI2rWznCGmSukcCHJ2bYKKNfqw1e31Y K651tnKg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sWiBX-000000088Px-3sDa; Wed, 24 Jul 2024 20:02:03 +0000 Date: Wed, 24 Jul 2024 21:02:03 +0100 From: Matthew Wilcox To: "Hailong.Liu" Cc: Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Vlastimil Babka , Michal Hocko , Barry Song <21cnbao@gmail.com>, "Tangquan . Zheng" , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v1] mm/vmalloc: fix incorrect __vmap_pages_range_noflush() if vm_area_alloc_pages() from high order fallback to order0 Message-ID: References: <20240724181916.31776-1-hailong.liu@oppo.com> <20240724182827.nlgdckimtg2gwns5@oppo.com> 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: <20240724182827.nlgdckimtg2gwns5@oppo.com> On Thu, Jul 25, 2024 at 02:28:27AM +0800, Hailong.Liu wrote: > > if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMALLOC) || > > - page_shift == PAGE_SHIFT) > > - return vmap_small_pages_range_noflush(addr, end, prot, pages); > > + page_shift == PAGE_SHIFT || > > + page_private(pages[0]) == VM_AREA_ALLOC_PAGES_FALLBACK) { > > + int ret = vmap_small_pages_range_noflush(addr, end, prot, pages); > > + > > + set_page_private(pages[0], 0); > > + return ret; > > + } > > > > for (i = 0; i < nr; i += 1U << (page_shift - PAGE_SHIFT)) { > > int err; > > @@ -3583,6 +3590,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid, > > > > /* fall back to the zero order allocations */ > > alloc_gfp |= __GFP_NOFAIL; > > + fallback = true; > Sry for my mistake, I forget define fallback here. > BTW, This is not the optimal solution. Does anyone have a better idea? Glad to > hear:) Yeah, I really don't like this approach. You could return a small struct indicating both nr_allocated and whether you had to fall back. Or you could pass a bool * parameter. They're both pretty nasty.