1. 22 3月, 2019 1 次提交
    • D
      net/sched: prepare TC actions to properly validate the control action · 85d0966f
      Davide Caratti 提交于
      - pass a pointer to struct tcf_proto in each actions's init() handler,
        to allow validating the control action, checking whether the chain
        exists and (eventually) refcounting it.
      - remove code that validates the control action after a successful call
        to the action's init() handler, and replace it with a test that forbids
        addition of actions having 'goto_chain' and NULL goto_chain pointer at
        the same time.
      - add tcf_action_check_ctrlact(), that will validate the control action
        and eventually allocate the action 'goto_chain' within the init()
        handler.
      - add tcf_action_set_ctrlact(), that will assign the control action and
        swap the current 'goto_chain' pointer with the new given one.
      
      This disallows 'goto_chain' on actions that don't initialize it properly
      in their init() handler, i.e. calling tcf_action_check_ctrlact() after
      successful IDR reservation and then calling tcf_action_set_ctrlact()
      to assign 'goto_chain' and 'tcf_action' consistently.
      
      By doing this, the kernel does not leak anymore refcounts when a valid
      'goto chain' handle is replaced in TC actions, causing kmemleak splats
      like the following one:
      
       # tc chain add dev dd0 chain 42 ingress protocol ip flower \
       > ip_proto tcp action drop
       # tc chain add dev dd0 chain 43 ingress protocol ip flower \
       > ip_proto udp action drop
       # tc filter add dev dd0 ingress matchall \
       > action gact goto chain 42 index 66
       # tc filter replace dev dd0 ingress matchall \
       > action gact goto chain 43 index 66
       # echo scan >/sys/kernel/debug/kmemleak
       <...>
       unreferenced object 0xffff93c0ee09f000 (size 1024):
       comm "tc", pid 2565, jiffies 4295339808 (age 65.426s)
       hex dump (first 32 bytes):
         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
         00 00 00 00 08 00 06 00 00 00 00 00 00 00 00 00  ................
       backtrace:
         [<000000009b63f92d>] tc_ctl_chain+0x3d2/0x4c0
         [<00000000683a8d72>] rtnetlink_rcv_msg+0x263/0x2d0
         [<00000000ddd88f8e>] netlink_rcv_skb+0x4a/0x110
         [<000000006126a348>] netlink_unicast+0x1a0/0x250
         [<00000000b3340877>] netlink_sendmsg+0x2c1/0x3c0
         [<00000000a25a2171>] sock_sendmsg+0x36/0x40
         [<00000000f19ee1ec>] ___sys_sendmsg+0x280/0x2f0
         [<00000000d0422042>] __sys_sendmsg+0x5e/0xa0
         [<000000007a6c61f9>] do_syscall_64+0x5b/0x180
         [<00000000ccd07542>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
         [<0000000013eaa334>] 0xffffffffffffffff
      
      Fixes: db50514f ("net: sched: add termination action to allow goto chain")
      Fixes: 97763dc0 ("net_sched: reject unknown tcfa_action values")
      Signed-off-by: NDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      85d0966f
  2. 11 2月, 2019 1 次提交
  3. 01 9月, 2018 1 次提交
  4. 22 8月, 2018 1 次提交
  5. 20 8月, 2018 1 次提交
    • V
      net: sched: always disable bh when taking tcf_lock · 653cd284
      Vlad Buslov 提交于
      Recently, ops->init() and ops->dump() of all actions were modified to
      always obtain tcf_lock when accessing private action state. Actions that
      don't depend on tcf_lock for synchronization with their data path use
      non-bh locking API. However, tcf_lock is also used to protect rate
      estimator stats in softirq context by timer callback.
      
      Change ops->init() and ops->dump() of all actions to disable bh when using
      tcf_lock to prevent deadlock reported by following lockdep warning:
      
      [  105.470398] ================================
      [  105.475014] WARNING: inconsistent lock state
      [  105.479628] 4.18.0-rc8+ #664 Not tainted
      [  105.483897] --------------------------------
      [  105.488511] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [  105.494871] swapper/16/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
      [  105.500449] 00000000f86c012e (&(&p->tcfa_lock)->rlock){+.?.}, at: est_fetch_counters+0x3c/0xa0
      [  105.509696] {SOFTIRQ-ON-W} state was registered at:
      [  105.514925]   _raw_spin_lock+0x2c/0x40
      [  105.519022]   tcf_bpf_init+0x579/0x820 [act_bpf]
      [  105.523990]   tcf_action_init_1+0x4e4/0x660
      [  105.528518]   tcf_action_init+0x1ce/0x2d0
      [  105.532880]   tcf_exts_validate+0x1d8/0x200
      [  105.537416]   fl_change+0x55a/0x268b [cls_flower]
      [  105.542469]   tc_new_tfilter+0x748/0xa20
      [  105.546738]   rtnetlink_rcv_msg+0x56a/0x6d0
      [  105.551268]   netlink_rcv_skb+0x18d/0x200
      [  105.555628]   netlink_unicast+0x2d0/0x370
      [  105.559990]   netlink_sendmsg+0x3b9/0x6a0
      [  105.564349]   sock_sendmsg+0x6b/0x80
      [  105.568271]   ___sys_sendmsg+0x4a1/0x520
      [  105.572547]   __sys_sendmsg+0xd7/0x150
      [  105.576655]   do_syscall_64+0x72/0x2c0
      [  105.580757]   entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [  105.586243] irq event stamp: 489296
      [  105.590084] hardirqs last  enabled at (489296): [<ffffffffb507e639>] _raw_spin_unlock_irq+0x29/0x40
      [  105.599765] hardirqs last disabled at (489295): [<ffffffffb507e745>] _raw_spin_lock_irq+0x15/0x50
      [  105.609277] softirqs last  enabled at (489292): [<ffffffffb413a6a3>] irq_enter+0x83/0xa0
      [  105.618001] softirqs last disabled at (489293): [<ffffffffb413a800>] irq_exit+0x140/0x190
      [  105.626813]
                     other info that might help us debug this:
      [  105.633976]  Possible unsafe locking scenario:
      
      [  105.640526]        CPU0
      [  105.643325]        ----
      [  105.646125]   lock(&(&p->tcfa_lock)->rlock);
      [  105.650747]   <Interrupt>
      [  105.653717]     lock(&(&p->tcfa_lock)->rlock);
      [  105.658514]
                      *** DEADLOCK ***
      
      [  105.665349] 1 lock held by swapper/16/0:
      [  105.669629]  #0: 00000000a640ad99 ((&est->timer)){+.-.}, at: call_timer_fn+0x10b/0x550
      [  105.678200]
                     stack backtrace:
      [  105.683194] CPU: 16 PID: 0 Comm: swapper/16 Not tainted 4.18.0-rc8+ #664
      [  105.690249] Hardware name: Supermicro SYS-2028TP-DECR/X10DRT-P, BIOS 2.0b 03/30/2017
      [  105.698626] Call Trace:
      [  105.701421]  <IRQ>
      [  105.703791]  dump_stack+0x92/0xeb
      [  105.707461]  print_usage_bug+0x336/0x34c
      [  105.711744]  mark_lock+0x7c9/0x980
      [  105.715500]  ? print_shortest_lock_dependencies+0x2e0/0x2e0
      [  105.721424]  ? check_usage_forwards+0x230/0x230
      [  105.726315]  __lock_acquire+0x923/0x26f0
      [  105.730597]  ? debug_show_all_locks+0x240/0x240
      [  105.735478]  ? mark_lock+0x493/0x980
      [  105.739412]  ? check_chain_key+0x140/0x1f0
      [  105.743861]  ? __lock_acquire+0x836/0x26f0
      [  105.748323]  ? lock_acquire+0x12e/0x290
      [  105.752516]  lock_acquire+0x12e/0x290
      [  105.756539]  ? est_fetch_counters+0x3c/0xa0
      [  105.761084]  _raw_spin_lock+0x2c/0x40
      [  105.765099]  ? est_fetch_counters+0x3c/0xa0
      [  105.769633]  est_fetch_counters+0x3c/0xa0
      [  105.773995]  est_timer+0x87/0x390
      [  105.777670]  ? est_fetch_counters+0xa0/0xa0
      [  105.782210]  ? lock_acquire+0x12e/0x290
      [  105.786410]  call_timer_fn+0x161/0x550
      [  105.790512]  ? est_fetch_counters+0xa0/0xa0
      [  105.795055]  ? del_timer_sync+0xd0/0xd0
      [  105.799249]  ? __lock_is_held+0x93/0x110
      [  105.803531]  ? mark_held_locks+0x20/0xe0
      [  105.807813]  ? _raw_spin_unlock_irq+0x29/0x40
      [  105.812525]  ? est_fetch_counters+0xa0/0xa0
      [  105.817069]  ? est_fetch_counters+0xa0/0xa0
      [  105.821610]  run_timer_softirq+0x3c4/0x9f0
      [  105.826064]  ? lock_acquire+0x12e/0x290
      [  105.830257]  ? __bpf_trace_timer_class+0x10/0x10
      [  105.835237]  ? __lock_is_held+0x25/0x110
      [  105.839517]  __do_softirq+0x11d/0x7bf
      [  105.843542]  irq_exit+0x140/0x190
      [  105.847208]  smp_apic_timer_interrupt+0xac/0x3b0
      [  105.852182]  apic_timer_interrupt+0xf/0x20
      [  105.856628]  </IRQ>
      [  105.859081] RIP: 0010:cpuidle_enter_state+0xd8/0x4d0
      [  105.864395] Code: 46 ff 48 89 44 24 08 0f 1f 44 00 00 31 ff e8 cf ec 46 ff 80 7c 24 07 00 0f 85 1d 02 00 00 e8 9f 90 4b ff fb 66 0f 1f 44 00 00 <4c> 8b 6c 24 08 4d 29 fd 0f 80 36 03 00 00 4c 89 e8 48 ba cf f7 53
      [  105.884288] RSP: 0018:ffff8803ad94fd20 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
      [  105.892494] RAX: 0000000000000000 RBX: ffffe8fb300829c0 RCX: ffffffffb41e19e1
      [  105.899988] RDX: 0000000000000007 RSI: dffffc0000000000 RDI: ffff8803ad9358ac
      [  105.907503] RBP: ffffffffb6636300 R08: 0000000000000004 R09: 0000000000000000
      [  105.914997] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004
      [  105.922487] R13: ffffffffb6636140 R14: ffffffffb66362d8 R15: 000000188d36091b
      [  105.929988]  ? trace_hardirqs_on_caller+0x141/0x2d0
      [  105.935232]  do_idle+0x28e/0x320
      [  105.938817]  ? arch_cpu_idle_exit+0x40/0x40
      [  105.943361]  ? mark_lock+0x8c1/0x980
      [  105.947295]  ? _raw_spin_unlock_irqrestore+0x32/0x60
      [  105.952619]  cpu_startup_entry+0xc2/0xd0
      [  105.956900]  ? cpu_in_idle+0x20/0x20
      [  105.960830]  ? _raw_spin_unlock_irqrestore+0x32/0x60
      [  105.966146]  ? trace_hardirqs_on_caller+0x141/0x2d0
      [  105.971391]  start_secondary+0x2b5/0x360
      [  105.975669]  ? set_cpu_sibling_map+0x1330/0x1330
      [  105.980654]  secondary_startup_64+0xa5/0xb0
      
      Taking tcf_lock in sample action with bh disabled causes lockdep to issue a
      warning regarding possible irq lock inversion dependency between tcf_lock,
      and psample_groups_lock that is taken when holding tcf_lock in sample init:
      
      [  162.108959]  Possible interrupt unsafe locking scenario:
      
      [  162.116386]        CPU0                    CPU1
      [  162.121277]        ----                    ----
      [  162.126162]   lock(psample_groups_lock);
      [  162.130447]                                local_irq_disable();
      [  162.136772]                                lock(&(&p->tcfa_lock)->rlock);
      [  162.143957]                                lock(psample_groups_lock);
      [  162.150813]   <Interrupt>
      [  162.153808]     lock(&(&p->tcfa_lock)->rlock);
      [  162.158608]
                      *** DEADLOCK ***
      
      In order to prevent potential lock inversion dependency between tcf_lock
      and psample_groups_lock, extract call to psample_group_get() from tcf_lock
      protected section in sample action init function.
      
      Fixes: 4e232818 ("net: sched: act_mirred: remove dependency on rtnl lock")
      Fixes: 764e9a24 ("net: sched: act_vlan: remove dependency on rtnl lock")
      Fixes: 729e0126 ("net: sched: act_tunnel_key: remove dependency on rtnl lock")
      Fixes: d7728495 ("net: sched: act_sample: remove dependency on rtnl lock")
      Fixes: e8917f43 ("net: sched: act_gact: remove dependency on rtnl lock")
      Fixes: b6a2b971 ("net: sched: act_csum: remove dependency on rtnl lock")
      Fixes: 2142236b ("net: sched: act_bpf: remove dependency on rtnl lock")
      Signed-off-by: NVlad Buslov <vladbu@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      653cd284
  6. 14 8月, 2018 1 次提交
  7. 12 8月, 2018 1 次提交
  8. 30 7月, 2018 1 次提交
  9. 08 7月, 2018 5 次提交
  10. 06 4月, 2018 1 次提交
    • D
      net/sched: fix NULL dereference in the error path of tcf_bpf_init() · 3239534a
      Davide Caratti 提交于
      when tcf_bpf_init_from_ops() fails (e.g. because of program having invalid
      number of instructions), tcf_bpf_cfg_cleanup() calls bpf_prog_put(NULL) or
      bpf_prog_destroy(NULL). Unless CONFIG_BPF_SYSCALL is unset, this causes
      the following error:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
       PGD 800000007345a067 P4D 800000007345a067 PUD 340e1067 PMD 0
       Oops: 0000 [#1] SMP PTI
       Modules linked in: act_bpf(E) ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 mbcache jbd2 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic pcbc snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd glue_helper cryptd joydev snd_timer snd virtio_balloon pcspkr soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm virtio_blk drm virtio_net virtio_console i2c_core crc32c_intel serio_raw virtio_pci ata_piix libata virtio_ring floppy virtio dm_mirror dm_region_hash dm_log dm_mod [last unloaded: act_bpf]
       CPU: 3 PID: 5654 Comm: tc Tainted: G            E    4.16.0.bpf_test+ #408
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       RIP: 0010:__bpf_prog_put+0xc/0xc0
       RSP: 0018:ffff9594003ef728 EFLAGS: 00010202
       RAX: 0000000000000000 RBX: ffff9594003ef758 RCX: 0000000000000024
       RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
       RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000044
       R10: 0000000000000220 R11: ffff8a7ab9f17131 R12: 0000000000000000
       R13: ffff8a7ab7c3c8e0 R14: 0000000000000001 R15: ffff8a7ab88f1054
       FS:  00007fcb2f17c740(0000) GS:ffff8a7abfd80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000020 CR3: 000000007c888006 CR4: 00000000001606e0
       Call Trace:
        tcf_bpf_cfg_cleanup+0x2f/0x40 [act_bpf]
        tcf_bpf_cleanup+0x4c/0x70 [act_bpf]
        __tcf_idr_release+0x79/0x140
        tcf_bpf_init+0x125/0x330 [act_bpf]
        tcf_action_init_1+0x2cc/0x430
        ? get_page_from_freelist+0x3f0/0x11b0
        tcf_action_init+0xd3/0x1b0
        tc_ctl_action+0x18b/0x240
        rtnetlink_rcv_msg+0x29c/0x310
        ? _cond_resched+0x15/0x30
        ? __kmalloc_node_track_caller+0x1b9/0x270
        ? rtnl_calcit.isra.29+0x100/0x100
        netlink_rcv_skb+0xd2/0x110
        netlink_unicast+0x17c/0x230
        netlink_sendmsg+0x2cd/0x3c0
        sock_sendmsg+0x30/0x40
        ___sys_sendmsg+0x27a/0x290
        ? mem_cgroup_commit_charge+0x80/0x130
        ? page_add_new_anon_rmap+0x73/0xc0
        ? do_anonymous_page+0x2a2/0x560
        ? __handle_mm_fault+0xc75/0xe20
        __sys_sendmsg+0x58/0xa0
        do_syscall_64+0x6e/0x1a0
        entry_SYSCALL_64_after_hwframe+0x3d/0xa2
       RIP: 0033:0x7fcb2e58eba0
       RSP: 002b:00007ffc93c496c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
       RAX: ffffffffffffffda RBX: 00007ffc93c497f0 RCX: 00007fcb2e58eba0
       RDX: 0000000000000000 RSI: 00007ffc93c49740 RDI: 0000000000000003
       RBP: 000000005ac6a646 R08: 0000000000000002 R09: 0000000000000000
       R10: 00007ffc93c49120 R11: 0000000000000246 R12: 0000000000000000
       R13: 00007ffc93c49804 R14: 0000000000000001 R15: 000000000066afa0
       Code: 5f 00 48 8b 43 20 48 c7 c7 70 2f 7c b8 c7 40 10 00 00 00 00 5b e9 a5 8b 61 00 0f 1f 44 00 00 0f 1f 44 00 00 41 54 55 48 89 fd 53 <48> 8b 47 20 f0 ff 08 74 05 5b 5d 41 5c c3 41 89 f4 0f 1f 44 00
       RIP: __bpf_prog_put+0xc/0xc0 RSP: ffff9594003ef728
       CR2: 0000000000000020
      
      Fix it in tcf_bpf_cfg_cleanup(), ensuring that bpf_prog_{put,destroy}(f)
      is called only when f is not NULL.
      
      Fixes: bbc09e78 ("net/sched: fix idr leak on the error path of tcf_bpf_init()")
      Reported-by: NLucas Bates <lucasb@mojatatu.com>
      Signed-off-by: NDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3239534a
  11. 28 3月, 2018 1 次提交
  12. 22 3月, 2018 1 次提交
    • D
      net/sched: fix idr leak on the error path of tcf_bpf_init() · bbc09e78
      Davide Caratti 提交于
      when the following command sequence is entered
      
       # tc action add action bpf bytecode '4,40 0 0 12,31 0 1 2048,6 0 0 262144,6 0 0 0' index 100
       RTNETLINK answers: Invalid argument
       We have an error talking to the kernel
       # tc action add action bpf bytecode '4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0' index 100
       RTNETLINK answers: No space left on device
       We have an error talking to the kernel
      
      act_bpf correctly refuses to install the first TC rule, because 31 is not
      a valid instruction. However, it refuses to install the second TC rule,
      even if the BPF code is correct. Furthermore, it's no more possible to
      install any other rule having the same value of 'index' until act_bpf
      module is unloaded/inserted again. After the idr has been reserved, call
      tcf_idr_release() instead of tcf_idr_cleanup(), to fix this issue.
      
      Fixes: 65a206c0 ("net/sched: Change act_api and act_xxx modules to use IDR")
      Acked-by: NJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: NDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bbc09e78
  13. 28 2月, 2018 1 次提交
    • K
      net: Convert tc_action_net_init() and tc_action_net_exit() based pernet_operations · 685ecfb1
      Kirill Tkhai 提交于
      These pernet_operations are from net/sched directory, and they call only
      tc_action_net_init() and tc_action_net_exit():
      
      bpf_net_ops
      connmark_net_ops
      csum_net_ops
      gact_net_ops
      ife_net_ops
      ipt_net_ops
      xt_net_ops
      mirred_net_ops
      nat_net_ops
      pedit_net_ops
      police_net_ops
      sample_net_ops
      simp_net_ops
      skbedit_net_ops
      skbmod_net_ops
      tunnel_key_net_ops
      vlan_net_ops
      
      1)tc_action_net_init() just allocates and initializes per-net memory.
      2)There should not be in-flight packets at the time of tc_action_net_exit()
      call, or another pernet_operations send packets to dying net (except
      netlink). So, it seems they can be marked as async.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      685ecfb1
  14. 17 2月, 2018 4 次提交
  15. 14 12月, 2017 1 次提交
  16. 06 12月, 2017 1 次提交
  17. 09 11月, 2017 1 次提交
  18. 03 11月, 2017 1 次提交
  19. 27 9月, 2017 1 次提交
  20. 31 8月, 2017 1 次提交
  21. 22 6月, 2017 1 次提交
  22. 14 4月, 2017 1 次提交
  23. 17 1月, 2017 1 次提交
    • D
      bpf: rework prog_digest into prog_tag · f1f7714e
      Daniel Borkmann 提交于
      Commit 7bd509e3 ("bpf: add prog_digest and expose it via
      fdinfo/netlink") was recently discussed, partially due to
      admittedly suboptimal name of "prog_digest" in combination
      with sha1 hash usage, thus inevitably and rightfully concerns
      about its security in terms of collision resistance were
      raised with regards to use-cases.
      
      The intended use cases are for debugging resp. introspection
      only for providing a stable "tag" over the instruction sequence
      that both kernel and user space can calculate independently.
      It's not usable at all for making a security relevant decision.
      So collisions where two different instruction sequences generate
      the same tag can happen, but ideally at a rather low rate. The
      "tag" will be dumped in hex and is short enough to introspect
      in tracepoints or kallsyms output along with other data such
      as stack trace, etc. Thus, this patch performs a rename into
      prog_tag and truncates the tag to a short output (64 bits) to
      make it obvious it's not collision-free.
      
      Should in future a hash or facility be needed with a security
      relevant focus, then we can think about requirements, constraints,
      etc that would fit to that situation. For now, rework the exposed
      parts for the current use cases as long as nothing has been
      released yet. Tested on x86_64 and s390x.
      
      Fixes: 7bd509e3 ("bpf: add prog_digest and expose it via fdinfo/netlink")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f1f7714e
  24. 06 12月, 2016 1 次提交
    • D
      bpf: add prog_digest and expose it via fdinfo/netlink · 7bd509e3
      Daniel Borkmann 提交于
      When loading a BPF program via bpf(2), calculate the digest over
      the program's instruction stream and store it in struct bpf_prog's
      digest member. This is done at a point in time before any instructions
      are rewritten by the verifier. Any unstable map file descriptor
      number part of the imm field will be zeroed for the hash.
      
      fdinfo example output for progs:
      
        # cat /proc/1590/fdinfo/5
        pos:          0
        flags:        02000002
        mnt_id:       11
        prog_type:    1
        prog_jited:   1
        prog_digest:  b27e8b06da22707513aa97363dfb11c7c3675d28
        memlock:      4096
      
      When programs are pinned and retrieved by an ELF loader, the loader
      can check the program's digest through fdinfo and compare it against
      one that was generated over the ELF file's program section to see
      if the program needs to be reloaded. Furthermore, this can also be
      exposed through other means such as netlink in case of a tc cls/act
      dump (or xdp in future), but also through tracepoints or other
      facilities to identify the program. Other than that, the digest can
      also serve as a base name for the work in progress kallsyms support
      of programs. The digest doesn't depend/select the crypto layer, since
      we need to keep dependencies to a minimum. iproute2 will get support
      for this facility.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7bd509e3
  25. 28 11月, 2016 1 次提交
  26. 18 11月, 2016 1 次提交
    • A
      netns: make struct pernet_operations::id unsigned int · c7d03a00
      Alexey Dobriyan 提交于
      Make struct pernet_operations::id unsigned.
      
      There are 2 reasons to do so:
      
      1)
      This field is really an index into an zero based array and
      thus is unsigned entity. Using negative value is out-of-bound
      access by definition.
      
      2)
      On x86_64 unsigned 32-bit data which are mixed with pointers
      via array indexing or offsets added or subtracted to pointers
      are preffered to signed 32-bit data.
      
      "int" being used as an array index needs to be sign-extended
      to 64-bit before being used.
      
      	void f(long *p, int i)
      	{
      		g(p[i]);
      	}
      
        roughly translates to
      
      	movsx	rsi, esi
      	mov	rdi, [rsi+...]
      	call 	g
      
      MOVSX is 3 byte instruction which isn't necessary if the variable is
      unsigned because x86_64 is zero extending by default.
      
      Now, there is net_generic() function which, you guessed it right, uses
      "int" as an array index:
      
      	static inline void *net_generic(const struct net *net, int id)
      	{
      		...
      		ptr = ng->ptr[id - 1];
      		...
      	}
      
      And this function is used a lot, so those sign extensions add up.
      
      Patch snipes ~1730 bytes on allyesconfig kernel (without all junk
      messing with code generation):
      
      	add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)
      
      Unfortunately some functions actually grow bigger.
      This is a semmingly random artefact of code generation with register
      allocator being used differently. gcc decides that some variable
      needs to live in new r8+ registers and every access now requires REX
      prefix. Or it is shifted into r12, so [r12+0] addressing mode has to be
      used which is longer than [r8]
      
      However, overall balance is in negative direction:
      
      	add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)
      	function                                     old     new   delta
      	nfsd4_lock                                  3886    3959     +73
      	tipc_link_build_proto_msg                   1096    1140     +44
      	mac80211_hwsim_new_radio                    2776    2808     +32
      	tipc_mon_rcv                                1032    1058     +26
      	svcauth_gss_legacy_init                     1413    1429     +16
      	tipc_bcbase_select_primary                   379     392     +13
      	nfsd4_exchange_id                           1247    1260     +13
      	nfsd4_setclientid_confirm                    782     793     +11
      		...
      	put_client_renew_locked                      494     480     -14
      	ip_set_sockfn_get                            730     716     -14
      	geneve_sock_add                              829     813     -16
      	nfsd4_sequence_done                          721     703     -18
      	nlmclnt_lookup_host                          708     686     -22
      	nfsd4_lockt                                 1085    1063     -22
      	nfs_get_client                              1077    1050     -27
      	tcf_bpf_init                                1106    1076     -30
      	nfsd4_encode_fattr                          5997    5930     -67
      	Total: Before=154856051, After=154854321, chg -0.00%
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c7d03a00
  27. 30 10月, 2016 1 次提交
  28. 16 9月, 2016 2 次提交
  29. 26 7月, 2016 1 次提交
    • W
      net_sched: move tc_action into tcf_common · a85a970a
      WANG Cong 提交于
      struct tc_action is confusing, currently we use it for two purposes:
      1) Pass in arguments and carry out results from helper functions
      2) A generic representation for tc actions
      
      The first one is error-prone, since we need to make sure we don't
      miss anything. This patch aims to get rid of this use, by moving
      tc_action into tcf_common, so that they are allocated together
      in hashtable and can be cast'ed easily.
      
      And together with the following patch, we could really make
      tc_action a generic representation for all tc actions and each
      type of action can inherit from it.
      
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a85a970a
  30. 02 7月, 2016 1 次提交
    • D
      bpf: refactor bpf_prog_get and type check into helper · 113214be
      Daniel Borkmann 提交于
      Since bpf_prog_get() and program type check is used in a couple of places,
      refactor this into a small helper function that we can make use of. Since
      the non RO prog->aux part is not used in performance critical paths and a
      program destruction via RCU is rather very unlikley when doing the put, we
      shouldn't have an issue just doing the bpf_prog_get() + prog->type != type
      check, but actually not taking the ref at all (due to being in fdget() /
      fdput() section of the bpf fd) is even cleaner and makes the diff smaller
      as well, so just go for that. Callsites are changed to make use of the new
      helper where possible.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      113214be
  31. 08 6月, 2016 2 次提交