1. 01 12月, 2007 1 次提交
    • E
      [NETNS]: Fix /proc/net breakage · 2b1e300a
      Eric W. Biederman 提交于
      Well I clearly goofed when I added the initial network namespace support
      for /proc/net.  Currently things work but there are odd details visible to
      user space, even when we have a single network namespace.
      
      Since we do not cache proc_dir_entry dentries at the moment we can just
      modify ->lookup to return a different directory inode depending on the
      network namespace of the process looking at /proc/net, replacing the
      current technique of using a magic and fragile follow_link method.
      
      To accomplish that this patch:
      - introduces a shadow_proc method to allow different dentries to
        be returned from proc_lookup.
      - Removes the old /proc/net follow_link magic
      - Fixes a weakness in our not caching of proc generic dentries.
      
      As shadow_proc uses a task struct to decided which dentry to return we can
      go back later and fix the proc generic caching without modifying any code
      that uses the shadow_proc method.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Pavel Emelyanov <xemul@openvz.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      2b1e300a
  2. 13 11月, 2007 1 次提交
  3. 07 11月, 2007 1 次提交
  4. 27 10月, 2007 1 次提交
    • E
      [NET]: Marking struct pernet_operations __net_initdata was inappropriate · 2b008b0a
      Eric W. Biederman 提交于
      It is not safe to to place struct pernet_operations in a special section.
      We need struct pernet_operations to last until we call unregister_pernet_subsys.
      Which doesn't happen until module unload.
      
      So marking struct pernet_operations is a disaster for modules in two ways.
      - We discard it before we call the exit method it points to.
      - Because I keep struct pernet_operations on a linked list discarding
        it for compiled in code removes elements in the middle of a linked
        list and does horrible things for linked insert.
      
      So this looks safe assuming __exit_refok is not discarded
      for modules.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2b008b0a
  5. 26 10月, 2007 1 次提交
  6. 11 10月, 2007 4 次提交
    • P
      [NETNS]: Move some code into __init section when CONFIG_NET_NS=n · 4665079c
      Pavel Emelyanov 提交于
      With the net namespaces many code leaved the __init section,
      thus making the kernel occupy more memory than it did before.
      Since we have a config option that prohibits the namespace
      creation, the functions that initialize/finalize some netns
      stuff are simply not needed and can be freed after the boot.
      
      Currently, this is almost not noticeable, since few calls
      are no longer in __init, but when the namespaces will be
      merged it will be possible to free more code. I propose to
      use the __net_init, __net_exit and __net_initdata "attributes"
      for functions/variables that are not used if the CONFIG_NET_NS
      is not set to save more space in memory.
      
      The exiting functions cannot just reside in the __exit section,
      as noticed by David, since the init section will have
      references on it and the compilation will fail due to modpost
      checks. These references can exist, since the init namespace
      never dies and the exit callbacks are never called. So I
      introduce the __exit_refok attribute just like it is already
      done with the __init_refok.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4665079c
    • E
      [NET]: Fix race when opening a proc file while a network namespace is exiting. · 077130c0
      Eric W. Biederman 提交于
      The problem:  proc_net files remember which network namespace the are
      against but do not remember hold a reference count (as that would pin
      the network namespace).   So we currently have a small window where
      the reference count on a network namespace may be incremented when opening
      a /proc file when it has already gone to zero.
      
      To fix this introduce maybe_get_net and get_proc_net.
      
      maybe_get_net increments the network namespace reference count only if it is
      greater then zero, ensuring we don't increment a reference count after it
      has gone to zero.
      
      get_proc_net handles all of the magic to go from a proc inode to the network
      namespace instance and call maybe_get_net on it.
      
      PROC_NET the old accessor is removed so that we don't get confused and use
      the wrong helper function.
      
      Then I fix up the callers to use get_proc_net and handle the case case
      where get_proc_net returns NULL.  In that case I return -ENXIO because
      effectively the network namespace has already gone away so the files
      we are trying to access don't exist anymore.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Acked-by: NPaul E. McKenney <paulmck@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      077130c0
    • D
      [NETNS]: Fix export symbols. · 36ac3135
      Daniel Lezcano 提交于
      Add the appropriate EXPORT_SYMBOLS for proc_net_create,
      proc_net_fops_create and proc_net_remove to fix errors when
      compiling allmodconfig
      Signed-off-by: NMark Nelson <markn@au1.ibm.com>
      Acked-by: NBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      36ac3135
    • D
      [NET]: Fix missed addition of fs/proc/proc_net.c · 3c12afe7
      David S. Miller 提交于
      My bad.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3c12afe7