From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3EEE4C433EF for ; Thu, 9 Jun 2022 22:16:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236604AbiFIWQ5 (ORCPT ); Thu, 9 Jun 2022 18:16:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38806 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233876AbiFIWQy (ORCPT ); Thu, 9 Jun 2022 18:16:54 -0400 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 437CB1203EB for ; Thu, 9 Jun 2022 15:16:52 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id c2-20020a25a2c2000000b0066288641421so15477792ybn.14 for ; Thu, 09 Jun 2022 15:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=a7HKcIF+i0T4+qY1S/nBDjlBN8LZbn3HajfMjAd6pgE=; b=myr+KdqGBf+8fU62rrrc6vdWLC4zQ+EyY6QFdgZ42GfmTyENhLo1IAw3h2RNkQhUwn 0XIlmFI5we6dPTmcL5OoVRYkNlg1LkiEp4m7TTvZUlR6ue+fe982BLupBD9KlWv7xdeq tEyC52lTuBzUzYKgufcIPK7Ci1BaDygPGjKQT8u6/zm5afnc2zO7GbJDlDaelSa5C9I6 m1gTG8o78bI6STaoseXyxF12CneUqy+nHYwCQMj9r7YNbTeNrJ/xKj0EQk+nA9+z1UEj WUT+SwL4WoBwN+LsZ0RrnI0mPP8hfuMvwOWrNlfSbRwkDqmNF92nH57ZSUm5tqv4Qcz4 Lc7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=a7HKcIF+i0T4+qY1S/nBDjlBN8LZbn3HajfMjAd6pgE=; b=CvDLjylZgUzt3ryIQVpATFsKvvB7Wjqc9zY1lI2EiHnvntDHh9xCvKBrKAfB5gJHvV T5dqn+UZhNzDWotc0+mTbM2I/QiUIMZtmgLJmV81JIaxjSgk22eWt+cHWTOtPUpcHOEU mqELH8WkVFe2N3zbXzeYKmVrQbWl3qRxtWR4a2V3eRDDTE9XQxaDt5xHzK5YjIVWjKmb qZivViC5+W7066FhwFY4lm3pSXBaRgTVe4Fg6+bseowNFRN0E73ILj0vvqQReoLv81m/ AN/EGAJ4aVJ7kwQEVowWtJ4joc9wpAqE9OjOoHACsa/xTaaGTlpCQUYgv/LxfWuyQnqB AmzA== X-Gm-Message-State: AOAM531jkRPIjgYF+WCH3tgpsNP4RE7itRudIeUgn5zZCHaMM/nhZQFE KzrkiYUdEi4j7FhPnTO+LdHcTpNJkIQTtw== X-Google-Smtp-Source: ABdhPJxssTaeezzS7wEt6X3VKCQoaymqGu0EUoWOB6KOG9bWlT0i99Upi+R4v9esUZodWYU8smo6tDC44wMwrQ== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:20:ed76:c0a8:28b]) (user=shakeelb job=sendgmr) by 2002:a25:2003:0:b0:663:e799:4ab5 with SMTP id g3-20020a252003000000b00663e7994ab5mr13476183ybg.403.1654813011398; Thu, 09 Jun 2022 15:16:51 -0700 (PDT) Date: Thu, 9 Jun 2022 22:16:47 +0000 In-Reply-To: Message-Id: <20220609221647.lqxljj4wlb6mcuvr@google.com> Mime-Version: 1.0 References: <20220609191221.rv3lqbhipnvvzt67@google.com> Subject: Re: [next] arm64: boot failed - next-20220606 From: Shakeel Butt To: Roman Gushchin Cc: Naresh Kamboju , Linux-Next Mailing List , open list , regressions@lists.linux.dev, lkft-triage@lists.linaro.org, Linux ARM , linux-mm , Stephen Rothwell , Andrew Morton , Ard Biesheuvel , Arnd Bergmann , Catalin Marinas , Raghuram Thammiraju , Mark Brown , Will Deacon , Vasily Averin , Qian Cai Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 09, 2022 at 03:05:08PM -0700, Roman Gushchin wrote: > On Thu, Jun 09, 2022 at 07:12:21PM +0000, Shakeel Butt wrote: > > On Thu, Jun 09, 2022 at 10:56:09AM -0700, Roman Gushchin wrote: > > > On Thu, Jun 09, 2022 at 10:47:35AM -0700, Shakeel Butt wrote: > > > > On Thu, Jun 9, 2022 at 10:27 AM Roman Gushchin wrote: > > > > > > > > > [...] > > > > > +struct mem_cgroup *mem_cgroup_from_obj(void *p) > > > > > +{ > > > > > + struct folio *folio; > > > > > + > > > > > + if (mem_cgroup_disabled()) > > > > > + return NULL; > > > > > + > > > > > + if (unlikely(is_vmalloc_addr(p))) > > > > > + folio = page_folio(vmalloc_to_page(p)); > > > > > > > > Do we need to check for NULL from vmalloc_to_page(p)? > > > > > > Idk, can it realistically return NULL after is_vmalloc_addr() returned true? > > > I would be surprised, but maybe I'm missing something. > > > > is_vmalloc_addr() is simply checking the range and some buggy caller can > > provide an unmapped address within the range. Maybe VM_BUG_ON() should > > be good enough (though no strong opinion either way). > > No strong opinion here as well, but I think we don't have to be too defensive > here. Actually we'll know anyway, unlikely a null pointer dereference will be > unnoticed. And it's not different to calling mem_cgroup_from_obj() with some > random invalid address now. > Sounds good. You can add my ack when you send the official version of the patch.