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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5FE7C433EF for ; Fri, 3 Sep 2021 22:21:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9D35C61056 for ; Fri, 3 Sep 2021 22:21:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240269AbhICWWS (ORCPT ); Fri, 3 Sep 2021 18:22:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233620AbhICWWR (ORCPT ); Fri, 3 Sep 2021 18:22:17 -0400 Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04AADC061575 for ; Fri, 3 Sep 2021 15:21:17 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id h1so977070ljl.9 for ; Fri, 03 Sep 2021 15:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V2hoWJQN2mzjm7RN9/wyMT5DuqBSo/d9GUmVSbz0TJw=; b=Gc085IJlGgq95QEC60AuUrcwKvYlFA0D3Q9sv2Trn1ebudU66LqjDOYUXWMF6gr1sm f8xRaQvwmRs7om4gUhY2vJg1RGYwkIaxmuvcRvolFIg3jtushEc4EYI/RB6CZHJNZNqM jcqt/EJjawnGjgXzGIlHfPVqPxpR0J4DIIWLo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V2hoWJQN2mzjm7RN9/wyMT5DuqBSo/d9GUmVSbz0TJw=; b=lohTXqvqcWp2zrId9i2mHJ9sHUlTqSJ6Oi+bmc3lPOeqpCde11FbYqHkEYSNjF+vMb wLvUHHtJPQ1KUNeAQHabwp8Se8VQ5qedGqkFBJKCfBi51Xjaseup0mj7xtqmdFA/5JT3 ATbkXHVJBTLS9pwn3dMRgpT1rt7TeRPTmI+rLkwE4Rh82bTkaSBKGkgZOmdwzozQ3Hzy MoWo0FTFG9iqoxeecfOD1rsKS8M6+mSPkSRU5NsgxBUPTENB/XMipLb+3PRfcRz0WJ6C FlJyk9ZvHeEBADRDsuUyPMhlajzWZRz6dYEbWm2Gj+uGZbyUpufvjfdzl95fyheTPucw 0D9w== X-Gm-Message-State: AOAM530uCKfeMDFzFkGaerPRJjfScLaBvLS5xuTZDe5im0WlBadWfc4K hKnEPfMncKFvmNDRPsdHRjYNdcY90E6/nzAYEbs= X-Google-Smtp-Source: ABdhPJy9QeX1Gr5Rdt6h2IvwCI94MjehNUGzTxcLzaMt+AXvaz+PCMHoC8HicAZZr5XfWMJU7Unmxg== X-Received: by 2002:a2e:9852:: with SMTP id e18mr800702ljj.173.1630707674872; Fri, 03 Sep 2021 15:21:14 -0700 (PDT) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com. [209.85.208.174]) by smtp.gmail.com with ESMTPSA id d21sm45768ljo.70.2021.09.03.15.21.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Sep 2021 15:21:14 -0700 (PDT) Received: by mail-lj1-f174.google.com with SMTP id m4so978924ljq.8 for ; Fri, 03 Sep 2021 15:21:14 -0700 (PDT) X-Received: by 2002:a2e:8185:: with SMTP id e5mr785657ljg.31.1630707673799; Fri, 03 Sep 2021 15:21:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Fri, 3 Sep 2021 15:20:58 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: dozens of sysbot reports To: Eric Dumazet Cc: LKML , Eric Dumazet Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 3, 2021 at 1:44 PM Eric Dumazet wrote: > > I have a pile of (still under triage) sysbot reports coming after one of your patch > > Typical stack trace: > > ------------[ cut here ]------------ > WARNING: CPU: 1 PID: 24889 at mm/util.c:597 kvmalloc_node+0x111/0x120 mm/util.c:597 > Call Trace: > hash_ipport_create+0x3dd/0x1220 net/netfilter/ipset/ip_set_hash_gen.h:1524 > ip_set_create+0x782/0x15a0 net/netfilter/ipset/ip_set_core.c:1100 > nfnetlink_rcv_msg+0xbc9/0x13f0 net/netfilter/nfnetlink.c:296 So the real question is mainly just whether those huge allocations actually make sense or not. If they truly are sensible, we can remove the warning. But it would be good to perhaps look at them more. Because no: > Do we want to fix all problematic callers, with ad-hoc patches like Not insane patches like this, no. > ip_set_alloc(size_t size) > { > + if (size > INT_MAX) > + return NULL; > return kvzalloc(size, GFP_KERNEL_ACCOUNT); > } But does that kind of size really make sense? I'm looking at the particular caller, is it *really* senseible to have a 4GB+ hash table size? IOW, I don't think we want that warning to cause the above kinds of ad-hoc patches. But I _do_ want that warning to make people go "is that allocation truly sensible"? IOW, it sounds like you can send some netlink message that causes insane hash size allocations. Shouldn't _that_ be fixed? Linus