Skip to content

L
linux-davinci
Switch branch/tag
  1. 13 Mar, 2008 4 commits
    • Masakazu Mokuno's avatar
      PS3: gelic: change the prefix of the net interface for wireless · c1e889be
      Masakazu Mokuno authored 
      The gelic driver uses two net interfaces, one for ethernet and the
other for wireless. They share same MAC address and use 'eth' prefix
for the name.
As udev uses the MAC address to check uniqueness, this is
somewhat problematic.  So change the prefix of the network interface
name for the wireless so that udev can have an easy way to distinguish
interfaces.
Signed-off-by: default avatarMasakazu Mokuno <mokuno@sm.sony.co.jp>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      c1e889be
    • Masakazu Mokuno's avatar
      PS3: gelic: ignore scan info from zero SSID beacons · aad4c7d3
      Masakazu Mokuno authored 
      Some implementations of the hidden SSID APs emit beacons which have the zero
length SSID information element instead of SSID padded by null (\0) characters.
If the firmware of the PS3 wireless hardware meets these beacons, it abandons parsing
IEs. Thus guest OSes get the invalid scan information for the AP.

To work around this, ignore these scan informations from the list.
Signed-off-by: default avatarMasakazu Mokuno <mokuno@sm.sony.co.jp>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      aad4c7d3
    • Jan Slupski's avatar
      prism54: support for 124a:4025 - another version of IOGear GWU513 802.11g · 43557e15
      Jan Slupski authored 
      Add support to p54usb driver for apparently another version of IOGear GWU513
802.11g USB network card that uses GW3887IK chipset and is recognized as
"124a:4025 AirVast" by lsusb.

Cc: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      43557e15
    • Zhang Yanmin's avatar
      [NET]: Fix tbench regression in 2.6.25-rc1 · f1dd9c37
      Zhang Yanmin authored 
      Comparing with kernel 2.6.24, tbench result has regression with
2.6.25-rc1.

1) On 2 quad-core processor stoakley: 4%.
2) On 4 quad-core processor tigerton: more than 30%.

bisect located below patch.

b4ce9277 is first bad commit
commit b4ce9277
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Nov 13 21:33:32 2007 -0800

    [IPV6]: Move nfheader_len into rt6_info

    The dst member nfheader_len is only used by IPv6.  It's also currently
    creating a rather ugly alignment hole in struct dst.  Therefore this patch
    moves it from there into struct rt6_info.

Above patch changes the cache line alignment, especially member
__refcnt. I did a testing by adding 2 unsigned long pading before
lastuse, so the 3 members, lastuse/__refcnt/__use, are moved to next
cache line. The performance is recovered.

I created a patch to rearrange the members in struct dst_entry.

With Eric and Valdis Kletnieks's suggestion, I made finer arrangement.

1) Move tclassid under ops in case CONFIG_NET_CLS_ROUTE=y. So
   sizeof(dst_entry)=200 no matter if CONFIG_NET_CLS_ROUTE=y/n. I
   tested many patches on my 16-core tigerton by moving tclassid to
   different place. It looks like tclassid could also have impact on
   performance.  If moving tclassid before metrics, or just don't move
   tclassid, the performance isn't good. So I move it behind metrics.

2) Add comments before __refcnt.

On 16-core tigerton:

If CONFIG_NET_CLS_ROUTE=y, the result with below patch is about 18%
better than the one without the patch;

If CONFIG_NET_CLS_ROUTE=n, the result with below patch is about 30%
better than the one without the patch.

With 32bit 2.6.25-rc1 on 8-core stoakley, the new patch doesn't
introduce regression.

Thank Eric, Valdis, and David!
Signed-off-by: default avatarZhang Yanmin <yanmin.zhang@intel.com>
Acked-by: default avatarEric Dumazet <dada1@cosmosbay.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1dd9c37
  3. 12 Mar, 2008 3 commits
  5. 11 Mar, 2008 4 commits
  7. 10 Mar, 2008 9 commits
  9. 07 Mar, 2008 2 commits
    • Kirill A. Shutemov's avatar
      [NET]: include <linux/types.h> into linux/ethtool.h for __u* typedef · e621e691
      Kirill A. Shutemov authored 
      Signed-off-by: default avatarKirill A. Shutemov <k.shutemov@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e621e691
    • Pavel Emelyanov's avatar
      [NET]: Make /proc/net a symlink on /proc/self/net (v3) · e9720acd
      Pavel Emelyanov authored 
      Current /proc/net is done with so called "shadows", but current
implementation is broken and has little chances to get fixed.

The problem is that dentries subtree of /proc/net directory has
fancy revalidation rules to make processes living in different
net namespaces see different entries in /proc/net subtree, but
currently, tasks see in the /proc/net subdir the contents of any
other namespace, depending on who opened the file first.

The proposed fix is to turn /proc/net into a symlink, which points
to /proc/self/net, which in turn shows what previously was in
/proc/net - the network-related info, from the net namespace the
appropriate task lives in.

# ls -l /proc/net
lrwxrwxrwx  1 root root 8 Mar  5 15:17 /proc/net -> self/net

In other words - this behaves like /proc/mounts, but unlike
"mounts", "net" is not a file, but a directory.

Changes from v2:
* Fixed discrepancy of /proc/net nlink count and selinux labeling
  screwup pointed out by Stephen.

  To get the correct nlink count the ->getattr callback for /proc/net
  is overridden to read one from the net->proc_net entry.

  To make selinux still work the net->proc_net entry is initialized
  properly, i.e. with the "net" name and the proc_net parent.

Selinux fixes are
Acked-by: default avatarStephen Smalley <sds@tycho.nsa.gov>

Changes from v1:
* Fixed a task_struct leak in get_proc_task_net, pointed out by Paul.
Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
Acked-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e9720acd
  11. 06 Mar, 2008 16 commits
  13. 05 Mar, 2008 2 commits
    • Neil Horman's avatar
      [SCTP]: Bring MAX_BURST socket option into ietf API extension compliance · 219b99a9
      Neil Horman authored 
      Brings max_burst socket option set/get into line with the latest ietf
socket extensions api draft, while maintaining backwards
compatibility.
Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      219b99a9
    • Gui Jianfeng's avatar
      SCTP: Fix chunk parameter processing bug · 140ee960
      Gui Jianfeng authored 
      If an address family is not listed in "Supported Address Types"
parameter(INIT Chunk), but the packet is sent by that family, this
address family should be considered as supported by peer.  Otherwise,
an error condition will occur. For instance, if kernel receives an
IPV6 SCTP INIT chunk with "Support Address Types" parameter which
indicates just supporting IPV4 Address family. Kernel will reply an
IPV6 SCTP INIT ACK packet, but the source ipv6 address in ipv6 header
will be vacant. This is not correct.

refer to RFC4460 as following:
      IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported
      Address Types' parameter either IPv4 or IPv6, but uses the other
      family for sending the packet containing the INIT chunk, or if it
      also lists addresses of the other family in the INIT chunk, then
      the address family that is not listed in the 'Supported Address
      Types' parameter SHOULD also be considered as supported by the
      receiver of the INIT chunk.  The receiver of the INIT chunk SHOULD
      NOT respond with any kind of error indication.

Here is a fix to comply to RFC.
Signed-off-by: default avatarGui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      140ee960