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.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 D0AE2C433E1 for ; Mon, 24 Aug 2020 21:49:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AA6492072D for ; Mon, 24 Aug 2020 21:49:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="IpIZWcbA" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727956AbgHXVtg (ORCPT ); Mon, 24 Aug 2020 17:49:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46140 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726090AbgHXVtf (ORCPT ); Mon, 24 Aug 2020 17:49:35 -0400 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 56FCCC061574 for ; Mon, 24 Aug 2020 14:49:35 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id j25so4657034ejk.9 for ; Mon, 24 Aug 2020 14:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:subject:message-id:user-agent:mime-version; bh=kZOPQCIA0tqctsksq6PgHBKbr7xJLGfBW5BydzeehUI=; b=IpIZWcbAEXZKvmAzPnFAN3OffzwftlFEGxfsZl1uMIwxuLB1LXW3dRf+PHJQmCdSkg MtOO6aRkt9rgkGhaWdPWPdbCLofOvNJAX2+1eZQeowE+vKYOH0WXRK4LD7OGggKYmt8E CTMF76dx93J8CL0qRWzrdxj5+WOYwajIJquHyvgDJseyUCF8FrrV3s5pZoQr4LrFmCNV aYvvaqjGolia6tRKRJtjh2Wb8nb3Zs3pqXZaGorYAC5ek0So3fCMWP+8fG/ZZX6tw8dg YK9jN88Pxa/lvu/U2uxLJOyDbKvbQXxeMH2n3RL1LvHa+iazL1yh6cKCc59ha5ClMEXL 02RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:subject:message-id:user-agent :mime-version; bh=kZOPQCIA0tqctsksq6PgHBKbr7xJLGfBW5BydzeehUI=; b=irApKzPMsSaAQ5UK0N+DwNqkGagViCZoFM5u/bKW4mIBfbHcWhW8rURbJBYLHkUg5v kzh3aPfe8V+GKoWsrgKeBd4w09CUDCRVgAwlatqWNL9v/0mQJ0svSqMGiiOxgVuawm8i x7h/6R2Ow3Bm+JmTpRLOarnU/amou3T28lZE7cf3LRgpyaXtmbaOnd1QfU0a5FAIHF8A HM6GunJB9pLK0cZzlTy9U5WVQER1r5Eu5AUrJ3viH//DV1oOkfRto2xFYKZGYt45vlT9 yW7Emh5eBVGQBC6vycCdWfKwH/kXV1xaQGOvJzHdvDDMMw401FVsoavbZCbta+HuZCW3 Ak7Q== X-Gm-Message-State: AOAM531+1XIa/nyXT4UwWqfOPcnRn5vW1UjvoA5PXjbDS8jZKQASDW78 KMZLg7fj2D+WK6wMu2UFyzSWjbM0VD0= X-Google-Smtp-Source: ABdhPJy8tR4j1mxRCK4kcaDea8Xirl5LoM33+4QoiJSyCkB/+zYSGeSNZFGPSj80Wty0WLPOvVWQ7w== X-Received: by 2002:a17:907:36b:: with SMTP id rs11mr7873006ejb.544.1598305772909; Mon, 24 Aug 2020 14:49:32 -0700 (PDT) Received: from [2a02:8108:8440:5da4:b6c4:bfbb:8473:b7bc] ([2a02:8108:8440:5da4:b6c4:bfbb:8473:b7bc]) by smtp.gmail.com with ESMTPSA id v23sm8017135ejc.63.2020.08.24.14.49.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Aug 2020 14:49:32 -0700 (PDT) From: Arne Welzel X-Google-Original-From: Arne Welzel Date: Mon, 24 Aug 2020 23:49:24 +0200 (CEST) To: netdev@vger.kernel.org Subject: Opening /proc//net/dev prevents network namespace from expiring Message-ID: User-Agent: Alpine 2.21.99999 (DEB 380 2019-12-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hello, [reposting from kernelnewbies as suggested by Greg] as an unprivileged user one is able to keep network namespaces from expiring by opening /proc//net/dev of other processes. I've previously put this on stackexchange [1] and then bugzilla [2]. That's been a while though, so posting here for a bit more visibility in case it's something that's worth fixing. The reproducer is roughly as follows. As root: # echo "100" > /proc/sys/user/max_net_namespaces # while true ; do # (unshare -n bash -c 'sleep 0.3 && readlink /proc/self/ns/net') || sleep 0.5 # done As unprivileged user in a second terminal, run below Python script [3]: # python3 pin_net_namespaces.py After about one minute the first terminal will show the following until the Python process keeping the network namespaces alive is terminated. ... unshare: unshare failed: No space left on device unshare: unshare failed: No space left on device Without the change to max_net_namespaces reproducing just takes very long, but then also kernel memory grows fairly large. Does that seem like problematic behavior? I had attached a patch and tests to [2], but I fall into the kernel newbie category, so not sure how useful. Thanks, Arne [1] https://unix.stackexchange.com/questions/576718/opening-proc-pid-net-dev-prevents-network-namespace-from-expiring-is-this-ex/ [2] https://bugzilla.kernel.org/show_bug.cgi?id=207351 [3] $ cat pin_net_namespaces.py #!/usr/bin/env python3 import glob import os import time net_namespaces = {} while True: for net_dev in glob.glob("/proc/*/net/dev"): try: ino = os.stat(net_dev).st_ino if ino not in net_namespaces: net_namespaces[ino] = open(net_dev) print("Have", len(net_namespaces), "namespaces...") except FileNotFoundError: # not fast enough... pass time.sleep(0.2)