1. 12 7月, 2018 2 次提交
    • S
      net/ipv6: don't reinitialize ndev->cnf.addr_gen_mode on new inet6_dev · 70c30d76
      Sabrina Dubroca 提交于
      The value has already been copied from this netns's devconf_dflt, it
      shouldn't be reset to the global kernel default.
      
      Fixes: d35a00b8 ("net/ipv6: allow sysctl to change link-local address generation mode")
      Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      70c30d76
    • S
      net/ipv6: fix addrconf_sysctl_addr_gen_mode · c6dbf7aa
      Sabrina Dubroca 提交于
      addrconf_sysctl_addr_gen_mode() has multiple problems. First, it ignores
      the errors returned by proc_dointvec().
      
      addrconf_sysctl_addr_gen_mode() calls proc_dointvec() directly, which
      writes the value to memory, and then checks if it's valid and may return
      EINVAL. If a bad value is given, the value displayed when reading
      net.ipv6.conf.foo.addr_gen_mode next time will be invalid. In case the
      value provided by the user was valid, addrconf_dev_config() won't be
      called since idev->cnf.addr_gen_mode has already been updated.
      
      Fix this in the usual way we deal with values that need to be checked
      after the proc_do*() helper has returned: define a local ctl_table and
      storage, call proc_dointvec() on that temporary area, then check and
      store.
      
      addrconf_sysctl_addr_gen_mode() also writes the new value to the global
      ipv6_devconf_dflt, when we're writing to some netns's default, so that
      new netns will inherit the value that was set by the change occuring in
      any netns. That doesn't make any sense, so let's drop this assignment.
      
      Finally, since addr_gen_mode is a __u32, switch to proc_douintvec().
      
      Fixes: d35a00b8 ("net/ipv6: allow sysctl to change link-local address generation mode")
      Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c6dbf7aa
  2. 30 6月, 2018 1 次提交
  3. 12 6月, 2018 1 次提交
    • D
      net/ipv6: Ensure cfg is properly initialized in ipv6_create_tempaddr · 3f2d67b6
      David Ahern 提交于
      Valdis reported a BUG in ipv6_add_addr:
      
      [ 1820.832682] BUG: unable to handle kernel NULL pointer dereference at 0000000000000209
      [ 1820.832728] RIP: 0010:ipv6_add_addr+0x280/0xd10
      [ 1820.832732] Code: 49 8b 1f 0f 84 6a 0a 00 00 48 85 db 0f 84 4e 0a 00 00 48 8b 03 48 8b 53 08 49 89 45 00 49 8b 47 10
      49 89 55 08 48 85 c0 74 15 <48> 8b 50 08 48 8b 00 49 89 95 b8 01 00 00 49 89 85 b0 01 00 00 4c
      [ 1820.832847] RSP: 0018:ffffaa07c2fd7880 EFLAGS: 00010202
      [ 1820.832853] RAX: 0000000000000201 RBX: ffffaa07c2fd79b0 RCX: 0000000000000000
      [ 1820.832858] RDX: a4cfbfba2cbfa64c RSI: 0000000000000000 RDI: ffffffff8a8e9fa0
      [ 1820.832862] RBP: ffffaa07c2fd7920 R08: 000000000000017a R09: ffffffff8a555300
      [ 1820.832866] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888d18e71c00
      [ 1820.832871] R13: ffff888d0a9b1200 R14: 0000000000000000 R15: ffffaa07c2fd7980
      [ 1820.832876] FS:  00007faa51bdb800(0000) GS:ffff888d1d400000(0000) knlGS:0000000000000000
      [ 1820.832880] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1820.832885] CR2: 0000000000000209 CR3: 000000021e8f8001 CR4: 00000000001606e0
      [ 1820.832888] Call Trace:
      [ 1820.832898]  ? __local_bh_enable_ip+0x119/0x260
      [ 1820.832904]  ? ipv6_create_tempaddr+0x259/0x5a0
      [ 1820.832912]  ? __local_bh_enable_ip+0x139/0x260
      [ 1820.832921]  ipv6_create_tempaddr+0x2da/0x5a0
      [ 1820.832926]  ? ipv6_create_tempaddr+0x2da/0x5a0
      [ 1820.832941]  manage_tempaddrs+0x1a5/0x240
      [ 1820.832951]  inet6_addr_del+0x20b/0x3b0
      [ 1820.832959]  ? nla_parse+0xce/0x1e0
      [ 1820.832968]  inet6_rtm_deladdr+0xd9/0x210
      [ 1820.832981]  rtnetlink_rcv_msg+0x1d4/0x5f0
      
      Looking at the code I found 1 element (peer_pfx) of the newly introduced
      ifa6_config struct that is not initialized. Use a memset rather than hard
      coding an init for each struct element.
      Reported-by: NValdis Kletnieks <valdis.kletnieks@vt.edu>
      Fixes: e6464b8c ("net/ipv6: Convert ipv6_add_addr to struct ifa6_config")
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3f2d67b6
  4. 05 6月, 2018 1 次提交
  5. 29 5月, 2018 4 次提交
  6. 16 5月, 2018 1 次提交
  7. 26 4月, 2018 1 次提交
  8. 20 4月, 2018 4 次提交
  9. 18 4月, 2018 9 次提交
  10. 17 4月, 2018 1 次提交
  11. 28 3月, 2018 1 次提交
  12. 27 3月, 2018 2 次提交
  13. 16 3月, 2018 2 次提交
    • D
      net/ipv6: Add l3mdev check to ipv6_chk_addr_and_flags · 1893ff20
      David Ahern 提交于
      Lookup the L3 master device for the passed in device. Only consider
      addresses on netdev's with the same master device. If the device is
      not enslaved or is NULL, then the l3mdev is NULL which means only
      devices not enslaved (ie, in the default domain) are considered.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1893ff20
    • D
      net/ipv6: Change address check to always take a device argument · 232378e8
      David Ahern 提交于
      ipv6_chk_addr_and_flags determines if an address is a local address and
      optionally if it is an address on a specific device. For example, it is
      called by ip6_route_info_create to determine if a given gateway address
      is a local address. The address check currently does not consider L3
      domains and as a result does not allow a route to be added in one VRF
      if the nexthop points to an address in a second VRF. e.g.,
      
          $ ip route add 2001:db8:1::/64 vrf r2 via 2001:db8:102::23
          Error: Invalid gateway address.
      
      where 2001:db8:102::23 is an address on an interface in vrf r1.
      
      ipv6_chk_addr_and_flags needs to allow callers to always pass in a device
      with a separate argument to not limit the address to the specific device.
      The device is used used to determine the L3 domain of interest.
      
      To that end add an argument to skip the device check and update callers
      to always pass a device where possible and use the new argument to mean
      any address in the domain.
      
      Update a handful of users of ipv6_chk_addr with a NULL dev argument. This
      patch handles the change to these callers without adding the domain check.
      
      ip6_validate_gw needs to handle 2 cases - one where the device is given
      as part of the nexthop spec and the other where the device is resolved.
      There is at least 1 VRF case where deferring the check to only after
      the route lookup has resolved the device fails with an unintuitive error
      "RTNETLINK answers: No route to host" as opposed to the preferred
      "Error: Gateway can not be a local address." The 'no route to host'
      error is because of the fallback to a full lookup. The check is done
      twice to avoid this error.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      232378e8
  14. 02 3月, 2018 1 次提交
    • S
      ipv6: allow userspace to add IFA_F_OPTIMISTIC addresses · f1c02cfb
      Sabrina Dubroca 提交于
      According to RFC 4429 (section 3.1), adding new IPv6 addresses as
      optimistic addresses is acceptable, as long as the implementation
      follows some rules:
      
         * Optimistic DAD SHOULD only be used when the implementation is aware
              that the address is based on a most likely unique interface
              identifier (such as in [RFC2464]), generated randomly [RFC3041],
              or by a well-distributed hash function [RFC3972] or assigned by
              Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315].
              Optimistic DAD SHOULD NOT be used for manually entered
              addresses.
      
      Thus, it seems reasonable to allow userspace to set the optimistic flag
      when adding new addresses.
      
      We must not let userspace set NODAD + OPTIMISTIC, since if the kernel is
      not performing DAD we would never clear the optimistic flag. We must
      also ignore userspace's request to add OPTIMISTIC flag to addresses that
      have already completed DAD (addresses that don't have the TENTATIVE
      flag, or that have the DADFAILED flag).
      
      Then we also need to clear the OPTIMISTIC flag on permanent addresses
      when DAD fails. Otherwise, IFA_F_OPTIMISTIC addresses added by userspace
      can still be used after DAD has failed, because in
      ipv6_chk_addr_and_flags(), IFA_F_OPTIMISTIC overrides IFA_F_TENTATIVE.
      
      Setting IFA_F_OPTIMISTIC from userspace is conditional on
      CONFIG_IPV6_OPTIMISTIC_DAD and the optimistic_dad sysctl.
      Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
      Reviewed-by: NStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f1c02cfb
  15. 20 2月, 2018 1 次提交
  16. 13 2月, 2018 1 次提交
  17. 30 1月, 2018 2 次提交
    • E
      ipv6: addrconf: break critical section in addrconf_verify_rtnl() · e64e469b
      Eric Dumazet 提交于
      Heiner reported a lockdep splat [1]
      
      This is caused by attempting GFP_KERNEL allocation while RCU lock is
      held and BH blocked.
      
      We believe that addrconf_verify_rtnl() could run for a long period,
      so instead of using GFP_ATOMIC here as Ido suggested, we should break
      the critical section and restart it after the allocation.
      
      [1]
      [86220.125562] =============================
      [86220.125586] WARNING: suspicious RCU usage
      [86220.125612] 4.15.0-rc7-next-20180110+ #7 Not tainted
      [86220.125641] -----------------------------
      [86220.125666] kernel/sched/core.c:6026 Illegal context switch in RCU-bh read-side critical section!
      [86220.125711]
                     other info that might help us debug this:
      
      [86220.125755]
                     rcu_scheduler_active = 2, debug_locks = 1
      [86220.125792] 4 locks held by kworker/0:2/1003:
      [86220.125817]  #0:  ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000da8e9b73>] process_one_work+0x1de/0x680
      [86220.125895]  #1:  ((addr_chk_work).work){+.+.}, at: [<00000000da8e9b73>] process_one_work+0x1de/0x680
      [86220.125959]  #2:  (rtnl_mutex){+.+.}, at: [<00000000b06d9510>] rtnl_lock+0x12/0x20
      [86220.126017]  #3:  (rcu_read_lock_bh){....}, at: [<00000000aef52299>] addrconf_verify_rtnl+0x1e/0x510 [ipv6]
      [86220.126111]
                     stack backtrace:
      [86220.126142] CPU: 0 PID: 1003 Comm: kworker/0:2 Not tainted 4.15.0-rc7-next-20180110+ #7
      [86220.126185] Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015
      [86220.126250] Workqueue: ipv6_addrconf addrconf_verify_work [ipv6]
      [86220.126288] Call Trace:
      [86220.126312]  dump_stack+0x70/0x9e
      [86220.126337]  lockdep_rcu_suspicious+0xce/0xf0
      [86220.126365]  ___might_sleep+0x1d3/0x240
      [86220.126390]  __might_sleep+0x45/0x80
      [86220.126416]  kmem_cache_alloc_trace+0x53/0x250
      [86220.126458]  ? ipv6_add_addr+0xfe/0x6e0 [ipv6]
      [86220.126498]  ipv6_add_addr+0xfe/0x6e0 [ipv6]
      [86220.126538]  ipv6_create_tempaddr+0x24d/0x430 [ipv6]
      [86220.126580]  ? ipv6_create_tempaddr+0x24d/0x430 [ipv6]
      [86220.126623]  addrconf_verify_rtnl+0x339/0x510 [ipv6]
      [86220.126664]  ? addrconf_verify_rtnl+0x339/0x510 [ipv6]
      [86220.126708]  addrconf_verify_work+0xe/0x20 [ipv6]
      [86220.126738]  process_one_work+0x258/0x680
      [86220.126765]  worker_thread+0x35/0x3f0
      [86220.126790]  kthread+0x124/0x140
      [86220.126813]  ? process_one_work+0x680/0x680
      [86220.126839]  ? kthread_create_worker_on_cpu+0x40/0x40
      [86220.126869]  ? umh_complete+0x40/0x40
      [86220.126893]  ? call_usermodehelper_exec_async+0x12a/0x160
      [86220.126926]  ret_from_fork+0x4b/0x60
      [86220.126999] BUG: sleeping function called from invalid context at mm/slab.h:420
      [86220.127041] in_atomic(): 1, irqs_disabled(): 0, pid: 1003, name: kworker/0:2
      [86220.127082] 4 locks held by kworker/0:2/1003:
      [86220.127107]  #0:  ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<00000000da8e9b73>] process_one_work+0x1de/0x680
      [86220.127179]  #1:  ((addr_chk_work).work){+.+.}, at: [<00000000da8e9b73>] process_one_work+0x1de/0x680
      [86220.127242]  #2:  (rtnl_mutex){+.+.}, at: [<00000000b06d9510>] rtnl_lock+0x12/0x20
      [86220.127300]  #3:  (rcu_read_lock_bh){....}, at: [<00000000aef52299>] addrconf_verify_rtnl+0x1e/0x510 [ipv6]
      [86220.127414] CPU: 0 PID: 1003 Comm: kworker/0:2 Not tainted 4.15.0-rc7-next-20180110+ #7
      [86220.127463] Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015
      [86220.127528] Workqueue: ipv6_addrconf addrconf_verify_work [ipv6]
      [86220.127568] Call Trace:
      [86220.127591]  dump_stack+0x70/0x9e
      [86220.127616]  ___might_sleep+0x14d/0x240
      [86220.127644]  __might_sleep+0x45/0x80
      [86220.127672]  kmem_cache_alloc_trace+0x53/0x250
      [86220.127717]  ? ipv6_add_addr+0xfe/0x6e0 [ipv6]
      [86220.127762]  ipv6_add_addr+0xfe/0x6e0 [ipv6]
      [86220.127807]  ipv6_create_tempaddr+0x24d/0x430 [ipv6]
      [86220.127854]  ? ipv6_create_tempaddr+0x24d/0x430 [ipv6]
      [86220.127903]  addrconf_verify_rtnl+0x339/0x510 [ipv6]
      [86220.127950]  ? addrconf_verify_rtnl+0x339/0x510 [ipv6]
      [86220.127998]  addrconf_verify_work+0xe/0x20 [ipv6]
      [86220.128032]  process_one_work+0x258/0x680
      [86220.128063]  worker_thread+0x35/0x3f0
      [86220.128091]  kthread+0x124/0x140
      [86220.128117]  ? process_one_work+0x680/0x680
      [86220.128146]  ? kthread_create_worker_on_cpu+0x40/0x40
      [86220.128180]  ? umh_complete+0x40/0x40
      [86220.128207]  ? call_usermodehelper_exec_async+0x12a/0x160
      [86220.128243]  ret_from_fork+0x4b/0x60
      
      Fixes: f3d9832e ("ipv6: addrconf: cleanup locking in ipv6_add_addr")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e64e469b
    • D
      net: ipv6: send unsolicited NA after DAD · c76fe2d9
      David Ahern 提交于
      Unsolicited IPv6 neighbor advertisements should be sent after DAD
      completes. Update ndisc_send_unsol_na to skip tentative, non-optimistic
      addresses and have those sent by addrconf_dad_completed after DAD.
      
      Fixes: 4a6e3c5d ("net: ipv6: send unsolicited NA on admin up")
      Reported-by: NVivek Venkatraman <vivek@cumulusnetworks.com>
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c76fe2d9
  18. 17 1月, 2018 1 次提交
    • A
      net: delete /proc THIS_MODULE references · 96890d62
      Alexey Dobriyan 提交于
      /proc has been ignoring struct file_operations::owner field for 10 years.
      Specifically, it started with commit 786d7e16
      ("Fix rmmod/read/write races in /proc entries"). Notice the chunk where
      inode->i_fop is initialized with proxy struct file_operations for
      regular files:
      
      	-               if (de->proc_fops)
      	-                       inode->i_fop = de->proc_fops;
      	+               if (de->proc_fops) {
      	+                       if (S_ISREG(inode->i_mode))
      	+                               inode->i_fop = &proc_reg_file_ops;
      	+                       else
      	+                               inode->i_fop = de->proc_fops;
      	+               }
      
      VFS stopped pinning module at this point.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      96890d62
  19. 08 1月, 2018 3 次提交
  20. 05 12月, 2017 1 次提交