1. 19 11月, 2012 1 次提交
    • E
      net: Allow userns root to control llc, netfilter, netlink, packet, and xfrm · df008c91
      Eric W. Biederman 提交于
      Allow an unpriviled user who has created a user namespace, and then
      created a network namespace to effectively use the new network
      namespace, by reducing capable(CAP_NET_ADMIN) and
      capable(CAP_NET_RAW) calls to be ns_capable(net->user_ns,
      CAP_NET_ADMIN), or capable(net->user_ns, CAP_NET_RAW) calls.
      
      Allow creation of af_key sockets.
      Allow creation of llc sockets.
      Allow creation of af_packet sockets.
      
      Allow sending xfrm netlink control messages.
      
      Allow binding to netlink multicast groups.
      Allow sending to netlink multicast groups.
      Allow adding and dropping netlink multicast groups.
      Allow sending to all netlink multicast groups and port ids.
      
      Allow reading the netfilter SO_IP_SET socket option.
      Allow sending netfilter netlink messages.
      Allow setting and getting ip_vs netfilter socket options.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      df008c91
  2. 08 11月, 2012 1 次提交
  3. 26 10月, 2012 1 次提交
  4. 24 8月, 2012 1 次提交
  5. 23 8月, 2012 2 次提交
    • P
      packet: Protect packet sk list with mutex (v2) · 0fa7fa98
      Pavel Emelyanov 提交于
      Change since v1:
      
      * Fixed inuse counters access spotted by Eric
      
      In patch eea68e2f (packet: Report socket mclist info via diag module) I've
      introduced a "scheduling in atomic" problem in packet diag module -- the
      socket list is traversed under rcu_read_lock() while performed under it sk
      mclist access requires rtnl lock (i.e. -- mutex) to be taken.
      
      [152363.820563] BUG: scheduling while atomic: crtools/12517/0x10000002
      [152363.820573] 4 locks held by crtools/12517:
      [152363.820581]  #0:  (sock_diag_mutex){+.+.+.}, at: [<ffffffff81a2dcb5>] sock_diag_rcv+0x1f/0x3e
      [152363.820613]  #1:  (sock_diag_table_mutex){+.+.+.}, at: [<ffffffff81a2de70>] sock_diag_rcv_msg+0xdb/0x11a
      [152363.820644]  #2:  (nlk->cb_mutex){+.+.+.}, at: [<ffffffff81a67d01>] netlink_dump+0x23/0x1ab
      [152363.820693]  #3:  (rcu_read_lock){.+.+..}, at: [<ffffffff81b6a049>] packet_diag_dump+0x0/0x1af
      
      Similar thing was then re-introduced by further packet diag patches (fanount
      mutex and pgvec mutex for rings) :(
      
      Apart from being terribly sorry for the above, I propose to change the packet
      sk list protection from spinlock to mutex. This lock currently protects two
      modifications:
      
      * sklist
      * prot inuse counters
      
      The sklist modifications can be just reprotected with mutex since they already
      occur in a sleeping context. The inuse counters modifications are trickier -- the
      __this_cpu_-s are used inside, thus requiring the caller to handle the potential
      issues with contexts himself. Since packet sockets' counters are modified in two
      places only (packet_create and packet_release) we only need to protect the context
      from being preempted. BH disabling is not required in this case.
      Signed-off-by: NPavel Emelyanov <xemul@parallels.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0fa7fa98
    • D
      af_packet: use define instead of constant · 9e67030a
      danborkmann@iogearbox.net 提交于
      Instead of using a hard-coded value for the status variable, it would make
      the code more readable to use its destined define from linux/if_packet.h.
      
      Signed-off-by: daniel.borkmann@tik.ee.ethz.ch
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9e67030a
  6. 20 8月, 2012 2 次提交
  7. 15 8月, 2012 2 次提交
  8. 13 8月, 2012 1 次提交
    • D
      af_packet: remove BUG statement in tpacket_destruct_skb · 7f5c3e3a
      danborkmann@iogearbox.net 提交于
      Here's a quote of the comment about the BUG macro from asm-generic/bug.h:
      
       Don't use BUG() or BUG_ON() unless there's really no way out; one
       example might be detecting data structure corruption in the middle
       of an operation that can't be backed out of.  If the (sub)system
       can somehow continue operating, perhaps with reduced functionality,
       it's probably not BUG-worthy.
      
       If you're tempted to BUG(), think again:  is completely giving up
       really the *only* solution?  There are usually better options, where
       users don't need to reboot ASAP and can mostly shut down cleanly.
      
      In our case, the status flag of a ring buffer slot is managed from both sides,
      the kernel space and the user space. This means that even though the kernel
      side might work as expected, the user space screws up and changes this flag
      right between the send(2) is triggered when the flag is changed to
      TP_STATUS_SENDING and a given skb is destructed after some time. Then, this
      will hit the BUG macro. As David suggested, the best solution is to simply
      remove this statement since it cannot be used for kernel side internal
      consistency checks. I've tested it and the system still behaves /stable/ in
      this case, so in accordance with the above comment, we should rather remove it.
      Signed-off-by: NDaniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f5c3e3a
  9. 09 8月, 2012 1 次提交
  10. 28 6月, 2012 1 次提交
  11. 12 6月, 2012 1 次提交
  12. 04 6月, 2012 1 次提交
    • J
      net: Remove casts to same type · e3192690
      Joe Perches 提交于
      Adding casts of objects to the same type is unnecessary
      and confusing for a human reader.
      
      For example, this cast:
      
      	int y;
      	int *p = (int *)&y;
      
      I used the coccinelle script below to find and remove these
      unnecessary casts.  I manually removed the conversions this
      script produces of casts with __force and __user.
      
      @@
      type T;
      T *p;
      @@
      
      -	(T *)p
      +	p
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3192690
  13. 22 4月, 2012 1 次提交
  14. 20 4月, 2012 1 次提交
  15. 16 4月, 2012 1 次提交
  16. 29 3月, 2012 1 次提交
  17. 24 2月, 2012 1 次提交
  18. 28 12月, 2011 1 次提交
  19. 23 12月, 2011 1 次提交
  20. 19 11月, 2011 2 次提交
  21. 15 11月, 2011 1 次提交
  22. 14 11月, 2011 1 次提交
  23. 04 11月, 2011 1 次提交
    • O
      af_packet: de-inline some helper functions · eea49cc9
      Olof Johansson 提交于
      This popped some compiler errors due to mismatched prototypes. Just
      remove most manual inlines, the compiler should be able to figure out
      what makes sense to inline and not.
      
      net/packet/af_packet.c:252: warning: 'prb_curr_blk_in_use' declared inline after being called
      net/packet/af_packet.c:252: warning: previous declaration of 'prb_curr_blk_in_use' was here
      net/packet/af_packet.c:258: warning: 'prb_queue_frozen' declared inline after being called
      net/packet/af_packet.c:258: warning: previous declaration of 'prb_queue_frozen' was here
      net/packet/af_packet.c:248: warning: 'packet_previous_frame' declared inline after being called
      net/packet/af_packet.c:248: warning: previous declaration of 'packet_previous_frame' was here
      net/packet/af_packet.c:251: warning: 'packet_increment_head' declared inline after being called
      net/packet/af_packet.c:251: warning: previous declaration of 'packet_increment_head' was here
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Cc: Chetan Loke <loke.chetan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eea49cc9
  24. 19 10月, 2011 1 次提交
  25. 11 10月, 2011 1 次提交
  26. 04 10月, 2011 1 次提交
    • W
      make PACKET_STATISTICS getsockopt report consistently between ring and non-ring · 7091fbd8
      Willem de Bruijn 提交于
      This is a minor change.
      
      Up until kernel 2.6.32, getsockopt(fd, SOL_PACKET, PACKET_STATISTICS,
      ...) would return total and dropped packets since its last invocation. The
      introduction of socket queue overflow reporting [1] changed drop
      rate calculation in the normal packet socket path, but not when using a
      packet ring. As a result, the getsockopt now returns different statistics
      depending on the reception method used. With a ring, it still returns the
      count since the last call, as counts are incremented in tpacket_rcv and
      reset in getsockopt. Without a ring, it returns 0 if no drops occurred
      since the last getsockopt and the total drops over the lifespan of
      the socket otherwise. The culprit is this line in packet_rcv, executed
      on a drop:
      
      drop_n_acct:
              po->stats.tp_drops = atomic_inc_return(&sk->sk_drops);
      
      As it shows, the new drop number it taken from the socket drop counter,
      which is not reset at getsockopt. I put together a small example
      that demonstrates the issue [2]. It runs for 10 seconds and overflows
      the queue/ring on every odd second. The reported drop rates are:
      ring: 16, 0, 16, 0, 16, ...
      non-ring: 0, 15, 0, 30, 0, 46, 0, 60, 0 , 74.
      
      Note how the even ring counts monotonically increase. Because the
      getsockopt adds tp_drops to tp_packets, total counts are similarly
      reported cumulatively. Long story short, reinstating the original code, as
      the below patch does, fixes the issue at the cost of additional per-packet
      cycles. Another solution that does not introduce per-packet overhead
      is be to keep the current data path, record the value of sk_drops at
      getsockopt() at call N in a new field in struct packetsock and subtract
      that when reporting at call N+1. I'll be happy to code that, instead,
      it's just more messy.
      
      [1] http://patchwork.ozlabs.org/patch/35665/
      [2] http://kernel.googlecode.com/files/test-packetsock-getstatistics.cSigned-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7091fbd8
  27. 16 9月, 2011 1 次提交
    • J
      net: consolidate and fix ethtool_ops->get_settings calling · 4bc71cb9
      Jiri Pirko 提交于
      This patch does several things:
      - introduces __ethtool_get_settings which is called from ethtool code and
        from drivers as well. Put ASSERT_RTNL there.
      - dev_ethtool_get_settings() is replaced by __ethtool_get_settings()
      - changes calling in drivers so rtnl locking is respected. In
        iboe_get_rate was previously ->get_settings() called unlocked. This
        fixes it. Also prb_calc_retire_blk_tmo() in af_packet.c had the same
        problem. Also fixed by calling __dev_get_by_index() instead of
        dev_get_by_index() and holding rtnl_lock for both calls.
      - introduces rtnl_lock in bnx2fc_vport_create() and fcoe_vport_create()
        so bnx2fc_if_create() and fcoe_if_create() are called locked as they
        are from other places.
      - use __ethtool_get_settings() in bonding code
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      
      v2->v3:
      	-removed dev_ethtool_get_settings()
      	-added ASSERT_RTNL into __ethtool_get_settings()
      	-prb_calc_retire_blk_tmo - use __dev_get_by_index() and lock
      	 around it and __ethtool_get_settings() call
      v1->v2:
              add missing export_symbol
      Reviewed-by: Ben Hutchings <bhutchings@solarflare.com> [except FCoE bits]
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bc71cb9
  28. 27 8月, 2011 1 次提交
  29. 25 8月, 2011 1 次提交
    • C
      af-packet: TPACKET_V3 flexible buffer implementation. · f6fb8f10
      chetan loke 提交于
      1) Blocks can be configured with non-static frame-size.
      2) Read/poll is at a block-level(as opposed to packet-level).
      3) Added poll timeout to avoid indefinite user-space wait on idle links.
      4) Added user-configurable knobs:
         4.1) block::timeout.
         4.2) tpkt_hdr::sk_rxhash.
      
      Changes:
      C1) tpacket_rcv()
          C1.1) packet_current_frame() is replaced by packet_current_rx_frame()
                The bulk of the processing is then moved in the following chain:
                packet_current_rx_frame()
                  __packet_lookup_frame_in_block
                    fill_curr_block()
                    or
                      retire_current_block
                      dispatch_next_block
                    or
                    return NULL(queue is plugged/paused)
      Signed-off-by: NChetan Loke <loke.chetan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6fb8f10
  30. 14 7月, 2011 1 次提交
  31. 07 7月, 2011 2 次提交
  32. 06 7月, 2011 4 次提交