1. 01 4月, 2013 1 次提交
    • 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
  2. 04 2月, 2013 2 次提交
  3. 24 1月, 2013 1 次提交
  4. 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
  5. 29 12月, 2012 1 次提交
  6. 20 12月, 2012 1 次提交
  7. 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
  8. 29 10月, 2012 1 次提交
  9. 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
  10. 26 10月, 2012 1 次提交
  11. 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
  12. 09 10月, 2012 1 次提交
  13. 03 10月, 2012 1 次提交