1. 19 1月, 2014 1 次提交
    • M
      net: introduce SO_BPF_EXTENSIONS · ea02f941
      Michal Sekletar 提交于
      For user space packet capturing libraries such as libpcap, there's
      currently only one way to check which BPF extensions are supported
      by the kernel, that is, commit aa1113d9 ("net: filter: return
      -EINVAL if BPF_S_ANC* operation is not supported"). For querying all
      extensions at once this might be rather inconvenient.
      
      Therefore, this patch introduces a new option which can be used as
      an argument for getsockopt(), and allows one to obtain information
      about which BPF extensions are supported by the current kernel.
      
      As David Miller suggests, we do not need to define any bits right
      now and status quo can just return 0 in order to state that this
      versions supports SKF_AD_PROTOCOL up to SKF_AD_PAY_OFFSET. Later
      additions to BPF extensions need to add their bits to the
      bpf_tell_extensions() function, as documented in the comment.
      Signed-off-by: NMichal Sekletar <msekleta@redhat.com>
      Cc: David Miller <davem@davemloft.net>
      Reviewed-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ea02f941
  2. 13 11月, 2013 1 次提交
  3. 29 9月, 2013 1 次提交
    • E
      net: introduce SO_MAX_PACING_RATE · 62748f32
      Eric Dumazet 提交于
      As mentioned in commit afe4fd06 ("pkt_sched: fq: Fair Queue packet
      scheduler"), this patch adds a new socket option.
      
      SO_MAX_PACING_RATE offers the application the ability to cap the
      rate computed by transport layer. Value is in bytes per second.
      
      u32 val = 1000000;
      setsockopt(sockfd, SOL_SOCKET, SO_MAX_PACING_RATE, &val, sizeof(val));
      
      To be effectively paced, a flow must use FQ packet scheduler.
      
      Note that a packet scheduler takes into account the headers for its
      computations. The effective payload rate depends on MSS and retransmits
      if any.
      
      I chose to make this pacing rate a SOL_SOCKET option instead of a
      TCP one because this can be used by other protocols.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Steinar H. Gunderson <sesse@google.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      62748f32
  4. 13 7月, 2013 1 次提交
    • A
      Safer ABI for O_TMPFILE · bb458c64
      Al Viro 提交于
      [suggested by Rasmus Villemoes] make O_DIRECTORY | O_RDWR part of O_TMPFILE;
      that will fail on old kernels in a lot more cases than what I came up with.
      And make sure O_CREAT doesn't get there...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      bb458c64
  5. 11 7月, 2013 1 次提交
  6. 29 6月, 2013 1 次提交
  7. 18 6月, 2013 1 次提交
  8. 01 4月, 2013 2 次提交
    • K
      net: add option to enable error queue packets waking select · 7d4c04fc
      Keller, Jacob E 提交于
      Currently, when a socket receives something on the error queue it only wakes up
      the socket on select if it is in the "read" list, that is the socket has
      something to read. It is useful also to wake the socket if it is in the error
      list, which would enable software to wait on error queue packets without waking
      up for regular data on the socket. The main use case is for receiving
      timestamped transmit packets which return the timestamp to the socket via the
      error queue. This enables an application to select on the socket for the error
      queue only instead of for the regular traffic.
      
      -v2-
      * Added the SO_SELECT_ERR_QUEUE socket option to every architechture specific file
      * Modified every socket poll function that checks error queue
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Cc: Jeffrey Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Matthew Vick <matthew.vick@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d4c04fc
    • S
      sparc: use asm-generic version of types.h · cbf1ef6b
      Sam Ravnborg 提交于
      In sparc headers we use the following pattern:
      
          #if defined(__sparc__) && defined(__arch64__)
      
          sparc64 specific stuff
      
          #else
      
          sparc32 specific stuff
      
          #endif
      
      In types.h this pattern was not followed and here
      we only checked for __sparc__ for no good reason.
      It was a left-over from long time ago.
      
      I checked other architectures - and most of them
      do not have any such checks. And all the recently
      merged versions uses the asm-generic version.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cbf1ef6b
  9. 04 2月, 2013 2 次提交
  10. 24 1月, 2013 1 次提交
  11. 17 1月, 2013 1 次提交
    • V
      sk-filter: Add ability to lock a socket filter program · d59577b6
      Vincent Bernat 提交于
      While a privileged program can open a raw socket, attach some
      restrictive filter and drop its privileges (or send the socket to an
      unprivileged program through some Unix socket), the filter can still
      be removed or modified by the unprivileged program. This commit adds a
      socket option to lock the filter (SO_LOCK_FILTER) preventing any
      modification of a socket filter program.
      
      This is similar to OpenBSD BIOCLOCK ioctl on bpf sockets, except even
      root is not allowed change/drop the filter.
      
      The state of the lock can be read with getsockopt(). No error is
      triggered if the state is not changed. -EPERM is returned when a user
      tries to remove the lock or to change/remove the filter while the lock
      is active. The check is done directly in sk_attach_filter() and
      sk_detach_filter() and does not affect only setsockopt() syscall.
      Signed-off-by: NVincent Bernat <bernat@luffy.cx>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d59577b6
  12. 29 12月, 2012 1 次提交
  13. 20 12月, 2012 1 次提交
  14. 01 11月, 2012 1 次提交
    • P
      sk-filter: Add ability to get socket filter program (v2) · a8fc9277
      Pavel Emelyanov 提交于
      The SO_ATTACH_FILTER option is set only. I propose to add the get
      ability by using SO_ATTACH_FILTER in getsockopt. To be less
      irritating to eyes the SO_GET_FILTER alias to it is declared. This
      ability is required by checkpoint-restore project to be able to
      save full state of a socket.
      
      There are two issues with getting filter back.
      
      First, kernel modifies the sock_filter->code on filter load, thus in
      order to return the filter element back to user we have to decode it
      into user-visible constants. Fortunately the modification in question
      is interconvertible.
      
      Second, the BPF_S_ALU_DIV_K code modifies the command argument k to
      speed up the run-time division by doing kernel_k = reciprocal(user_k).
      Bad news is that different user_k may result in same kernel_k, so we
      can't get the original user_k back. Good news is that we don't have
      to do it. What we need to is calculate a user2_k so, that
      
        reciprocal(user2_k) == reciprocal(user_k) == kernel_k
      
      i.e. if it's re-loaded back the compiled again value will be exactly
      the same as it was. That said, the user2_k can be calculated like this
      
        user2_k = reciprocal(kernel_k)
      
      with an exception, that if kernel_k == 0, then user2_k == 1.
      
      The optlen argument is treated like this -- when zero, kernel returns
      the amount of sock_fprog elements in filter, otherwise it should be
      large enough for the sock_fprog array.
      
      changes since v1:
      * Declared SO_GET_FILTER in all arch headers
      * Added decode of vlan-tag codes
      Signed-off-by: NPavel Emelyanov <xemul@parallels.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8fc9277
  15. 29 10月, 2012 1 次提交
  16. 27 10月, 2012 1 次提交
    • D
      sparc64: Make montmul/montsqr/mpmul usable in 32-bit threads. · 517ffce4
      David S. Miller 提交于
      The Montgomery Multiply, Montgomery Square, and Multiple-Precision
      Multiply instructions work by loading a combination of the floating
      point and multiple register windows worth of integer registers
      with the inputs.
      
      These values are 64-bit.  But for 32-bit userland processes we only
      save the low 32-bits of each integer register during a register spill.
      This is because the register window save area is in the user stack and
      has a fixed layout.
      
      Therefore, the only way to use these instruction in 32-bit mode is to
      perform the following sequence:
      
      1) Load the top-32bits of a choosen integer register with a sentinel,
         say "-1".  This will be in the outer-most register window.
      
         The idea is that we're trying to see if the outer-most register
         window gets spilled, and thus the 64-bit values were truncated.
      
      2) Load all the inputs for the montmul/montsqr/mpmul instruction,
         down to the inner-most register window.
      
      3) Execute the opcode.
      
      4) Traverse back up to the outer-most register window.
      
      5) Check the sentinel, if it's still "-1" store the results.
         Otherwise retry the entire sequence.
      
      This retry is extremely troublesome.  If you're just unlucky and an
      interrupt or other trap happens, it'll push that outer-most window to
      the stack and clear the sentinel when we restore it.
      
      We could retry forever and never make forward progress if interrupts
      arrive at a fast enough rate (consider perf events as one example).
      So we have do limited retries and fallback to software which is
      extremely non-deterministic.
      
      Luckily it's very straightforward to provide a mechanism to let
      32-bit applications use a 64-bit stack.  Stacks in 64-bit mode are
      biased by 2047 bytes, which means that the lowest bit is set in the
      actual %sp register value.
      
      So if we see bit zero set in a 32-bit application's stack we treat
      it like a 64-bit stack.
      
      Runtime detection of such a facility is tricky, and cumbersome at
      best.  For example, just trying to use a biased stack and seeing if it
      works is hard to recover from (the signal handler will need to use an
      alt stack, plus something along the lines of longjmp).  Therefore, we
      add a system call to report a bitmask of arch specific features like
      this in a cheap and less hairy way.
      
      With help from Andy Polyakov.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      517ffce4
  17. 26 10月, 2012 1 次提交
  18. 17 10月, 2012 1 次提交
    • D
      UAPI: Make arch/sparc/include/uapi/asm/sigcontext.h non-empty · bb2bab17
      David Howells 提交于
      arch/sparc/include/uapi/asm/sigcontext.h was emitted by the UAPI disintegration
      script as an empty file because the parent file had no UAPI stuff in it,
      despite being marked with "header-y".
      
      Unfortunately, the patch program deletes resultant empty files when applying a
      kernel patch.
      
      So just stick a comment in there as a placeholder.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: David S. Miller <davem@davemloft.net>
      cc: sparclinux@vger.kernel.org
      bb2bab17
  19. 09 10月, 2012 1 次提交
  20. 03 10月, 2012 1 次提交