Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 01 5月, 2008 2 次提交
  3. 30 4月, 2008 4 次提交
    • L
      tcp: Overflow bug in Vegas · 15913114
      由 Lachlan Andrew 提交于 
      From: Lachlan Andrew <lachlan.andrew@gmail.com>

There is an overflow bug in net/ipv4/tcp_vegas.c for large BDPs
(e.g. 400Mbit/s, 400ms).  The multiplication (old_wnd *
vegas->baseRTT) << V_PARAM_SHIFT overflows a u32.

[ Fix tcp_veno.c too, it has similar calculations. -DaveM ]
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      15913114
    • K
      [IPv4] UFO: prevent generation of chained skb destined to UFO device · be9164e7
      由 Kostya B 提交于 
      Problem: ip_append_data() could wrongly generate a chained skb for
devices which support UFO.  When sk_write_queue is not empty
(e.g. MSG_MORE), __instead__ of appending data into the next nr_frag
of the queued skb, a new chained skb is created.

I would normally assume UFO device should get data in nr_frags and not
in frag_list.  Later the udp4_hwcsum_outgoing() resets csum to NONE
and skb_gso_segment() has oops.

Proposal:
1. Even length is less than mtu, employ ip_ufo_append_data()
and append data to the __existed__ skb in the sk_write_queue.

2. ip_ufo_append_data() is fixed due to a wrong manipulation of
peek-ing and later enqueue-ing of the same skb.  Now, enqueuing is
always performed, because on error the further
ip_flush_pending_frames() would release the queued skb.
Signed-off-by: NKostya B <bkostya@hotmail.com>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      be9164e7
    • A
      iwlwifi: move the selects to the tristate drivers · 3a8209d1
      由 Adrian Bunk 提交于 
      This patch moves the following select's:
- RFKILL        : IWLWIFI_RFKILL -> IWLCORE
- RFKILL_INPUT  : IWLWIFI_RFKILL -> IWLCORE
- MAC80211_LEDS : IWL4965_LEDS   -> IWLCORE
- LEDS_CLASS    : IWL4965_LEDS   -> IWLCORE
- MAC80211_LEDS : IWL3945_LEDS   -> IWL3945
- LEDS_CLASS    : IWL3945_LEDS   -> IWL3945

The effects are:
- with IWLCORE=m and/or IWL3945=m RFKILL/RFKILL_INPUT/MAC80211_LEDS/LEDS_CLASS
  are no longer wrongly forced to y
- fixes a build error with IWLCORE=y, IWL4965=m
  might be a bug in kconfig causing it, but doing this change that is 
  anyway the right thing fixes it
Reported-by: NCarlos R. Mafra <crmafra2@gmail.com>
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3a8209d1
    • S
      ipv4: annotate a few functions __init in ipconfig.c · 45e741b8
      由 Sam Ravnborg 提交于 
      A few functions are only used from __init context.
So annotate these with __init for consistency and silence
the following warnings:

WARNING: net/ipv4/built-in.o(.text+0x2a876): Section mismatch
         in reference from the function ic_bootp_init() to
         the variable .init.data:bootp_packet_type
WARNING: net/ipv4/built-in.o(.text+0x2a907): Section mismatch
         in reference from the function ic_bootp_cleanup() to
         the variable .init.data:bootp_packet_type

Note: The warnings only appear with CONFIG_DEBUG_SECTION_MISMATCH=y
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      45e741b8
  5. 29 4月, 2008 34 次提交