1. 17 Nov, 2010 1 commit
  2. 16 Nov, 2010 6 commits
    • Felix Fietkau's avatar
    • Felix Fietkau's avatar
    • Juuso Oikarinen's avatar
      mac80211: Add function to get probe request template for current AP · a619a4c0
      Juuso Oikarinen authored
      Chipsets with hardware based connection monitoring need to autonomically
      send directed probe-request frames to the AP (in the event of beacon loss,
      for example.)
      
      For the hardware to be able to do this, it requires a template for the frame
      to transmit to the AP, filled in with the BSSID and SSID of the AP, but also
      the supported rate IE's.
      
      This patch adds a function to mac80211, which allows the hardware driver to
      fetch this template after association, so it can be configured to the hardware.
      Signed-off-by: default avatarJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a619a4c0
    • Bruno Randolf's avatar
      mac80211: Add antenna configuration · 15d96753
      Bruno Randolf authored
      Allow antenna configuration by calling driver's function for it.
      
      We disallow antenna configuration if the wiphy is already running, mainly to
      make life easier for 802.11n drivers which need to recalculate HT capabilites.
      Signed-off-by: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      15d96753
    • Bruno Randolf's avatar
      cfg80211: Add nl80211 antenna configuration · afe0cbf8
      Bruno Randolf authored
      Allow setting of TX and RX antennas configuration via nl80211.
      
      The antenna configuration is defined as a bitmap of allowed antennas to use.
      This API can be used to mask out antennas which are not attached or should not
      be used for other reasons like regulatory concerns or special setups.
      
      Separate bitmaps are used for RX and TX to allow configuring different antennas
      for receiving and transmitting. Each bitmap is 32 bit long, each bit
      representing one antenna, starting with antenna 1 at the first bit. If an
      antenna bit is set, this means the driver is allowed to use this antenna for RX
      or TX respectively; if the bit is not set the hardware is not allowed to use
      this antenna.
      
      Using bitmaps has the benefit of allowing for a flexible configuration
      interface which can support many different configurations and which can be used
      for 802.11n as well as non-802.11n devices. Instead of relying on some hardware
      specific assumptions, drivers can use this information to know which antennas
      are actually attached to the system and derive their capabilities based on
      that.
      
      802.11n devices should enable or disable chains, based on which antennas are
      present (If all antennas belonging to a particular chain are disabled, the
      entire chain should be disabled). HT capabilities (like STBC, TX Beamforming,
      Antenna selection) should be calculated based on the available chains after
      applying the antenna masks. Should a 802.11n device have diversity antennas
      attached to one of their chains, diversity can be enabled or disabled based on
      the antenna information.
      
      Non-802.11n drivers can use the antenna masks to select RX and TX antennas and
      to enable or disable antenna diversity.
      
      While covering chainmasks for 802.11n and the standard "legacy" modes "fixed
      antenna 1", "fixed antenna 2" and "diversity" this API also allows more rare,
      but useful configurations as follows:
      
      1) Send on antenna 1, receive on antenna 2 (or vice versa). This can be used to
      have a low gain antenna for TX in order to keep within the regulatory
      constraints and a high gain antenna for RX in order to receive weaker signals
      ("speak softly, but listen harder"). This can be useful for building long-shot
      outdoor links. Another usage of this setup is having a low-noise pre-amplifier
      on antenna 1 and a power amplifier on the other antenna. This way transmit
      noise is mostly kept out of the low noise receive channel.
      (This would be bitmaps: tx 1 rx 2).
      
      2) Another similar setup is: Use RX diversity on both antennas, but always send
      on antenna 1. Again that would allow us to benefit from a higher gain RX
      antenna, while staying within the legal limits.
      (This would be: tx 0 rx 3).
      
      3) And finally there can be special experimental setups in research and
      development even with pre 802.11n hardware where more than 2 antennas are
      available. It's good to keep the API simple, yet flexible.
      Signed-off-by: default avatarBruno Randolf <br1@einfach.org>
      
      --
      v7:	Made bitmasks 32 bit wide and rebased to latest wireless-testing.
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      afe0cbf8
    • Arik Nemtsov's avatar
      mac80211: support hardware TX fragmentation offload · f23a4780
      Arik Nemtsov authored
      The lower driver is notified when the fragmentation threshold changes
      and upon a reconfig of the interface.
      
      If the driver supports hardware TX fragmentation, don't fragment
      packets in the stack.
      Signed-off-by: default avatarArik Nemtsov <arik@wizery.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f23a4780
  3. 15 Nov, 2010 11 commits
  4. 30 Oct, 2010 8 commits
  5. 29 Oct, 2010 3 commits
  6. 28 Oct, 2010 11 commits
    • David S. Miller's avatar
      netfilter: xt_socket: Make tproto signed in socket_mt6_v1(). · 089282fb
      David S. Miller authored
      Otherwise error indications from ipv6_find_hdr() won't be noticed.
      
      This required making the protocol argument to extract_icmp6_fields()
      signed too.
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      089282fb
    • Nelson Elhage's avatar
      pktgen: Limit how much data we copy onto the stack. · 448d7b5d
      Nelson Elhage authored
      A program that accidentally writes too much data to the pktgen file can overflow
      the kernel stack and oops the machine. This is only triggerable by root, so
      there's no security issue, but it's still an unfortunate bug.
      
      printk() won't print more than 1024 bytes in a single call, anyways, so let's
      just never copy more than that much data. We're on a fairly shallow stack, so
      that should be safe even with CONFIG_4KSTACKS.
      Signed-off-by: default avatarNelson Elhage <nelhage@ksplice.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      448d7b5d
    • David S. Miller's avatar
      net: Limit socket I/O iovec total length to INT_MAX. · 8acfe468
      David S. Miller authored
      This helps protect us from overflow issues down in the
      individual protocol sendmsg/recvmsg handlers.  Once
      we hit INT_MAX we truncate out the rest of the iovec
      by setting the iov_len members to zero.
      
      This works because:
      
      1) For SOCK_STREAM and SOCK_SEQPACKET sockets, partial
         writes are allowed and the application will just continue
         with another write to send the rest of the data.
      
      2) For datagram oriented sockets, where there must be a
         one-to-one correspondance between write() calls and
         packets on the wire, INT_MAX is going to be far larger
         than the packet size limit the protocol is going to
         check for and signal with -EMSGSIZE.
      
      Based upon a patch by Linus Torvalds.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8acfe468
    • Pavel Emelyanov's avatar
      fib: Fix fib zone and its hash leak on namespace stop · 4aa2c466
      Pavel Emelyanov authored
      When we stop a namespace we flush the table and free one, but the
      added fn_zone-s (and their hashes if grown) are leaked. Need to free.
      Tries releases all its stuff in the flushing code.
      
      Shame on us - this bug exists since the very first make-fib-per-net
      patches in 2.6.27 :(
      Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4aa2c466
    • Gerrit Renker's avatar
      dccp ccid-2: Stop polling · 1c0e0a05
      Gerrit Renker authored
      This updates CCID-2 to use the CCID dequeuing mechanism, converting from
      previous continuous-polling to a now event-driven mechanism.
      Signed-off-by: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c0e0a05
    • Gerrit Renker's avatar
      dccp: Refine the wait-for-ccid mechanism · b1fcf55e
      Gerrit Renker authored
      This extends the existing wait-for-ccid routine so that it may be used with
      different types of CCID, addressing the following problems:
      
       1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for
          example has a full TX queue and becomes network-limited just as the
          application wants to close, then waiting for CCID-2 to become unblocked
          could lead to an indefinite  delay (i.e., application "hangs").
       2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
          in its sending policy while the queue is being drained. This can lead to
          further delays during which the application will not be able to terminate.
       3) The minimum wait time for CCID-3/4 can be expected to be the queue length
          times the current inter-packet delay. For example if tx_qlen=100 and a delay
          of 15 ms is used for each packet, then the application would have to wait
          for a minimum of 1.5 seconds before being allowed to exit.
       4) There is no way for the user/application to control this behaviour. It would
          be good to use the timeout argument of dccp_close() as an upper bound. Then
          the maximum time that an application is willing to wait for its CCIDs to can
          be set via the SO_LINGER option.
      
      These problems are addressed by giving the CCID a grace period of up to the
      `timeout' value.
      
      The wait-for-ccid function is, as before, used when the application
       (a) has read all the data in its receive buffer and
       (b) if SO_LINGER was set with a non-zero linger time, or
       (c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
           state (client application closes after receiving CloseReq).
      
      In addition, there is a catch-all case of __skb_queue_purge() after waiting for
      the CCID. This is necessary since the write queue may still have data when
       (a) the host has been passively-closed,
       (b) abnormal termination (unread data, zero linger time),
       (c) wait-for-ccid could not finish within the given time limit.
      Signed-off-by: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b1fcf55e
    • Gerrit Renker's avatar
      dccp: Extend CCID packet dequeueing interface · dc841e30
      Gerrit Renker authored
      This extends the packet dequeuing interface of dccp_write_xmit() to allow
       1. CCIDs to take care of timing when the next packet may be sent;
       2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds).
      
      The main purpose is to take CCID-2 out of its polling mode (when it is network-
      limited, it tries every millisecond to send, without interruption).
      
      The mode of operation for (2) is as follows:
       * new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(),
       * ccid_hc_tx_send_packet() detects that it may not send (e.g. window full),
       * it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER',
       * dccp_write_xmit() returns without further action;
       * after some time the wait-condition for CCID becomes true,
       * that CCID schedules the tasklet,
       * tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(),
       * since the wait-condition is now true, ccid_hc_tx_packet() returns "send now",
       * packet is sent, and possibly more (since dccp_write_xmit() loops).
      
      Code reuse: the taskled function calls dccp_write_xmit(), the timer function
                  reduces to a wrapper around the same code.
      Signed-off-by: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dc841e30
    • Gerrit Renker's avatar
      dccp: Return-value convention of hc_tx_send_packet() · fe84f414
      Gerrit Renker authored
      This patch reorganises the return value convention of the CCID TX sending
      function, to permit more flexible schemes, as required by subsequent patches.
      
      Currently the convention is
       * values < 0     mean error,
       * a value == 0   means "send now", and
       * a value x > 0  means "send in x milliseconds".
      
      The patch provides symbolic constants and a function to interpret return values.
      
      In addition, it caps the maximum positive return value to 0xFFFF milliseconds,
      corresponding to 65.535 seconds.  This is possible since in CCID-3/4 the
      maximum possible inter-packet gap is fixed at t_mbi = 64 sec.
      Signed-off-by: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe84f414
    • Sanchit Garg's avatar
      net/9p: Return error on read with NULL buffer · f6ac55b6
      Sanchit Garg authored
      This patch ensures that a read(fd, NULL, 10) returns  EFAULT on a 9p file.
      Signed-off-by: default avatarSanchit Garg <sancgarg@linux.vnet.ibm.com>
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarEric Van Hensbergen <ericvh@gmail.com>
      f6ac55b6
    • Venkateswararao Jujjuri (JV)'s avatar
      9p: Add datasync to client side TFSYNC/RFSYNC for dotl · b165d601
      Venkateswararao Jujjuri (JV) authored
      SYNOPSIS
          size[4] Tfsync tag[2] fid[4] datasync[4]
      
          size[4] Rfsync tag[2]
      
      DESCRIPTION
      
          The Tfsync transaction transfers ("flushes") all modified in-core data of
          file identified by fid to the disk device (or other  permanent  storage
          device)  where that  file  resides.
      
          If datasync flag is specified data will be fleshed but does not flush
          modified metadata unless  that  metadata  is  needed  in order to allow a
          subsequent data retrieval to be correctly handled.
      Signed-off-by: default avatarVenkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
      Signed-off-by: default avatarEric Van Hensbergen <ericvh@gmail.com>
      b165d601
    • Aneesh Kumar K.V's avatar
      net/9p: Return error if we fail to encode protocol data · 7b3bb3fe
      Aneesh Kumar K.V authored
      We need to return error in case we fail to encode data in protocol buffer.
      This patch also return error in case of a failed copy_from_user.
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarVenkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
      Signed-off-by: default avatarEric Van Hensbergen <ericvh@gmail.com>
      7b3bb3fe