* [patch 3/4] mv643xx_eth: fix byte order when checksum offload is enabled
From: akpm @ 2008-02-05 7:47 UTC (permalink / raw)
To: jeff; +Cc: netdev, akpm, byron.bbradley, dale, mlachwani, viro
From: Byron Bradley <byron.bbradley@gmail.com>
The Marvell Orion system on chips have an integrated mv643xx MAC. On these
little endian ARM devices mv643xx will oops when checksum offload is
enabled. Swapping the byte order of the protocol and checksum solves this
problem.
Signed-off-by: Byron Bradley <byron.bbradley@gmail.com>
Cc: Dale Farnsworth <dale@farnsworth.org>
Cc: Manish Lachwani <mlachwani@mvista.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/mv643xx_eth.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff -puN drivers/net/mv643xx_eth.c~mv643xx_eth-fix-byte-order-when-checksum-offload-is-enabled drivers/net/mv643xx_eth.c
--- a/drivers/net/mv643xx_eth.c~mv643xx_eth-fix-byte-order-when-checksum-offload-is-enabled
+++ a/drivers/net/mv643xx_eth.c
@@ -1652,6 +1652,11 @@ static void eth_tx_fill_frag_descs(struc
}
}
+static inline __be16 sum16_as_be(__sum16 sum)
+{
+ return (__force __be16)sum;
+}
+
/**
* eth_tx_submit_descs_for_skb - submit data from an skb to the tx hw
*
@@ -1689,7 +1694,7 @@ static void eth_tx_submit_descs_for_skb(
desc->buf_ptr = dma_map_single(NULL, skb->data, length, DMA_TO_DEVICE);
if (skb->ip_summed == CHECKSUM_PARTIAL) {
- BUG_ON(skb->protocol != ETH_P_IP);
+ BUG_ON(skb->protocol != htons(ETH_P_IP));
cmd_sts |= ETH_GEN_TCP_UDP_CHECKSUM |
ETH_GEN_IP_V_4_CHECKSUM |
@@ -1698,10 +1703,10 @@ static void eth_tx_submit_descs_for_skb(
switch (ip_hdr(skb)->protocol) {
case IPPROTO_UDP:
cmd_sts |= ETH_UDP_FRAME;
- desc->l4i_chk = udp_hdr(skb)->check;
+ desc->l4i_chk = ntohs(sum16_as_be(udp_hdr(skb)->check));
break;
case IPPROTO_TCP:
- desc->l4i_chk = tcp_hdr(skb)->check;
+ desc->l4i_chk = ntohs(sum16_as_be(tcp_hdr(skb)->check));
break;
default:
BUG();
_
^ permalink raw reply
* [patch 2/7] bluetooth: uninlining
From: akpm @ 2008-02-05 7:48 UTC (permalink / raw)
To: marcel; +Cc: netdev, akpm
From: Andrew Morton <akpm@linux-foundation.org>
Remove all those inlines which were either a) unneeded or b) increased code
size.
text data bss dec hex filename
before: 6997 74 8 7079 1ba7 net/bluetooth/hidp/core.o
after: 6492 74 8 6574 19ae net/bluetooth/hidp/core.o
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
net/bluetooth/hidp/core.c | 30 +++++++++++++++++++-----------
1 file changed, 19 insertions(+), 11 deletions(-)
diff -puN net/bluetooth/hidp/core.c~bluetooth-uninlining net/bluetooth/hidp/core.c
--- a/net/bluetooth/hidp/core.c~bluetooth-uninlining
+++ a/net/bluetooth/hidp/core.c
@@ -135,8 +135,8 @@ static void __hidp_copy_session(struct h
}
}
-static inline int hidp_queue_event(struct hidp_session *session, struct input_dev *dev,
- unsigned int type, unsigned int code, int value)
+static int hidp_queue_event(struct hidp_session *session, struct input_dev *dev,
+ unsigned int type, unsigned int code, int value)
{
unsigned char newleds;
struct sk_buff *skb;
@@ -243,7 +243,8 @@ static void hidp_input_report(struct hid
input_sync(dev);
}
-static inline int hidp_queue_report(struct hidp_session *session, unsigned char *data, int size)
+static int hidp_queue_report(struct hidp_session *session,
+ unsigned char *data, int size)
{
struct sk_buff *skb;
@@ -287,7 +288,7 @@ static void hidp_idle_timeout(unsigned l
hidp_schedule(session);
}
-static inline void hidp_set_timer(struct hidp_session *session)
+static void hidp_set_timer(struct hidp_session *session)
{
if (session->idle_to > 0)
mod_timer(&session->timer, jiffies + HZ * session->idle_to);
@@ -332,7 +333,8 @@ static inline int hidp_send_ctrl_message
return err;
}
-static inline void hidp_process_handshake(struct hidp_session *session, unsigned char param)
+static void hidp_process_handshake(struct hidp_session *session,
+ unsigned char param)
{
BT_DBG("session %p param 0x%02x", session, param);
@@ -365,7 +367,8 @@ static inline void hidp_process_handshak
}
}
-static inline void hidp_process_hid_control(struct hidp_session *session, unsigned char param)
+static void hidp_process_hid_control(struct hidp_session *session,
+ unsigned char param)
{
BT_DBG("session %p param 0x%02x", session, param);
@@ -379,7 +382,8 @@ static inline void hidp_process_hid_cont
}
}
-static inline void hidp_process_data(struct hidp_session *session, struct sk_buff *skb, unsigned char param)
+static void hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
+ unsigned char param)
{
BT_DBG("session %p skb %p len %d param 0x%02x", session, skb, skb->len, param);
@@ -406,7 +410,8 @@ static inline void hidp_process_data(str
}
}
-static inline void hidp_recv_ctrl_frame(struct hidp_session *session, struct sk_buff *skb)
+static void hidp_recv_ctrl_frame(struct hidp_session *session,
+ struct sk_buff *skb)
{
unsigned char hdr, type, param;
@@ -440,7 +445,8 @@ static inline void hidp_recv_ctrl_frame(
kfree_skb(skb);
}
-static inline void hidp_recv_intr_frame(struct hidp_session *session, struct sk_buff *skb)
+static void hidp_recv_intr_frame(struct hidp_session *session,
+ struct sk_buff *skb)
{
unsigned char hdr;
@@ -608,7 +614,8 @@ static struct device *hidp_get_device(st
return conn ? &conn->dev : NULL;
}
-static inline int hidp_setup_input(struct hidp_session *session, struct hidp_connadd_req *req)
+static int hidp_setup_input(struct hidp_session *session,
+ struct hidp_connadd_req *req)
{
struct input_dev *input = session->input;
int i;
@@ -685,7 +692,8 @@ static void hidp_setup_quirks(struct hid
hid->quirks = hidp_blacklist[n].quirks;
}
-static inline void hidp_setup_hid(struct hidp_session *session, struct hidp_connadd_req *req)
+static void hidp_setup_hid(struct hidp_session *session,
+ struct hidp_connadd_req *req)
{
struct hid_device *hid = session->hid;
struct hid_report *report;
_
^ permalink raw reply
* [patch 1/7] bluetooth: hidp_process_hid_control remove unnecessary parameter dealing
From: akpm @ 2008-02-05 7:48 UTC (permalink / raw)
To: marcel; +Cc: netdev, akpm, hidave.darkstar
From: Dave Young <hidave.darkstar@gmail.com>
According to the bluetooth HID spec v1.0 chapter 7.4.2
"This code requests a major state change in a BT-HID device. A HID_CONTROL
request does not generate a HANDSHAKE response."
"A HID_CONTROL packet with a parameter of VIRTUAL_CABLE_UNPLUG is the only
HID_CONTROL packet a device can send to a host. A host will ignore all other
packets."
So in the hidp_precess_hid_control function, we just need to deal with the
UNLUG packet.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
net/bluetooth/hidp/core.c | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
diff -puN net/bluetooth/hidp/core.c~bluetooth-hidp_process_hid_control-remove-unnecessary-parameter-dealing net/bluetooth/hidp/core.c
--- a/net/bluetooth/hidp/core.c~bluetooth-hidp_process_hid_control-remove-unnecessary-parameter-dealing
+++ a/net/bluetooth/hidp/core.c
@@ -369,30 +369,13 @@ static inline void hidp_process_hid_cont
{
BT_DBG("session %p param 0x%02x", session, param);
- switch (param) {
- case HIDP_CTRL_NOP:
- break;
-
- case HIDP_CTRL_VIRTUAL_CABLE_UNPLUG:
+ if (param == HIDP_CTRL_VIRTUAL_CABLE_UNPLUG) {
/* Flush the transmit queues */
skb_queue_purge(&session->ctrl_transmit);
skb_queue_purge(&session->intr_transmit);
/* Kill session thread */
atomic_inc(&session->terminate);
- break;
-
- case HIDP_CTRL_HARD_RESET:
- case HIDP_CTRL_SOFT_RESET:
- case HIDP_CTRL_SUSPEND:
- case HIDP_CTRL_EXIT_SUSPEND:
- /* FIXME: We have to parse these and return no error */
- break;
-
- default:
- __hidp_send_ctrl_message(session,
- HIDP_TRANS_HANDSHAKE | HIDP_HSHK_ERR_INVALID_PARAMETER, NULL, 0);
- break;
}
}
_
^ permalink raw reply
* [patch 7/7] rfcomm tty: destroy before tty_close()
From: akpm @ 2008-02-05 7:48 UTC (permalink / raw)
To: marcel; +Cc: netdev, akpm, hidave.darkstar
From: Dave Young <hidave.darkstar@gmail.com>
rfcomm dev could be deleted in tty_hangup, so we must not call
rfcomm_dev_del again to prevent from destroying rfcomm dev before tty
close.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
net/bluetooth/rfcomm/tty.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN net/bluetooth/rfcomm/tty.c~rfcomm-tty-destroy-before-tty_close net/bluetooth/rfcomm/tty.c
--- a/net/bluetooth/rfcomm/tty.c~rfcomm-tty-destroy-before-tty_close
+++ a/net/bluetooth/rfcomm/tty.c
@@ -429,7 +429,8 @@ static int rfcomm_release_dev(void __use
if (dev->tty)
tty_vhangup(dev->tty);
- rfcomm_dev_del(dev);
+ if (!test_bit(RFCOMM_RELEASE_ONHUP, &dev->flags))
+ rfcomm_dev_del(dev);
rfcomm_dev_put(dev);
return 0;
}
_
^ permalink raw reply
* [patch 3/7] drivers/bluetooth/bpa10x.c: fix memleak
From: akpm @ 2008-02-05 7:48 UTC (permalink / raw)
To: marcel; +Cc: netdev, akpm, bunk
From: Adrian Bunk <bunk@kernel.org>
This patch fixea a memleak spotted by the Coverity checker.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/bluetooth/bpa10x.c | 1 +
1 file changed, 1 insertion(+)
diff -puN drivers/bluetooth/bpa10x.c~drivers-bluetooth-bpa10xc-fix-memleak drivers/bluetooth/bpa10x.c
--- a/drivers/bluetooth/bpa10x.c~drivers-bluetooth-bpa10xc-fix-memleak
+++ a/drivers/bluetooth/bpa10x.c
@@ -423,6 +423,7 @@ static int bpa10x_send_frame(struct sk_b
break;
default:
+ usb_free_urb(urb);
return -EILSEQ;
}
_
^ permalink raw reply
* [patch 5/7] bluetooth: blacklist another Broadcom BCM2035 device
From: akpm @ 2008-02-05 7:48 UTC (permalink / raw)
To: marcel; +Cc: netdev, akpm, andy
From: Andy Shevchenko <andy@smile.org.ua>
This device is recognized as bluetooth, but still not works.
Signed-off-by: Andy Shevchenko <andy@smile.org.ua>
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/bluetooth/hci_usb.c | 1 +
1 file changed, 1 insertion(+)
diff -puN drivers/bluetooth/hci_usb.c~bluetooth-blacklist-another-broadcom-bcm2035-device drivers/bluetooth/hci_usb.c
--- a/drivers/bluetooth/hci_usb.c~bluetooth-blacklist-another-broadcom-bcm2035-device
+++ a/drivers/bluetooth/hci_usb.c
@@ -111,6 +111,7 @@ static struct usb_device_id blacklist_id
{ USB_DEVICE(0x0a5c, 0x2033), .driver_info = HCI_IGNORE },
/* Broadcom BCM2035 */
+ { USB_DEVICE(0x0a5c, 0x2035), .driver_info = HCI_RESET | HCI_WRONG_SCO_MTU },
{ USB_DEVICE(0x0a5c, 0x200a), .driver_info = HCI_RESET | HCI_WRONG_SCO_MTU },
{ USB_DEVICE(0x0a5c, 0x2009), .driver_info = HCI_BCM92035 },
_
^ permalink raw reply
* [patch 6/7] hci_ldisc: fix null pointer deref
From: akpm @ 2008-02-05 7:48 UTC (permalink / raw)
To: marcel; +Cc: netdev, akpm, david, alan, arjan
From: David Newall <david@davidnewall.com>
Arjan:
With the help of kerneloops.org I've spotted a nice little interaction
between the TTY layer and the bluetooth code, however the tty layer is not
something I'm all too familiar with so I rather ask than brute-force fix the
code incorrectly.
The raw details are at:
http://www.kerneloops.org/search.php?search=uart_flush_buffer
What happens is that, on closing the bluetooth tty, the tty layer goes
into the release_dev() function, which first does a bunch of stuff, then
sets the file->private_data to NULL, does some more stuff and then calls the
ldisc close function. Which in this case, is hci_uart_tty_close().
Now, hci_uart_tty_close() calls hci_uart_close() which clears some
internal bit, and then calls hci_uart_flush()... which calls back to the
tty layers' uart_flush_buffer() function. (in drivers/bluetooth/hci_tty.c
around line 194) Which then WARN_ON()'s because that's not allowed/supposed
to be called this late in the shutdown of the port....
Should the bluetooth driver even call this flush function at all??
David:
This seems to be what happens: Hci_uart_close() flushes using
hci_uart_flush(). Subsequently, in hci_dev_do_close(), (one step in
hci_unregister_dev()), hci_uart_flush() is called again. The comment in
uart_flush_buffer(), relating to the WARN_ON(), indicates you can't flush
after the port is closed; which sounds reasonable. I think hci_uart_close()
should set hdev->flush to NULL before returning. Hci_dev_do_close() does
check for this. The code path is rather involved and I'm not entirely clear
of all steps, but I think that's what should be done.
akpm:
No idea. trollmerge.
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/bluetooth/hci_ldisc.c | 1 +
1 file changed, 1 insertion(+)
diff -puN drivers/bluetooth/hci_ldisc.c~hci_ldisc-fix-null-pointer-deref drivers/bluetooth/hci_ldisc.c
--- a/drivers/bluetooth/hci_ldisc.c~hci_ldisc-fix-null-pointer-deref
+++ a/drivers/bluetooth/hci_ldisc.c
@@ -208,6 +208,7 @@ static int hci_uart_close(struct hci_dev
return 0;
hci_uart_flush(hdev);
+ hdev->flush = NULL;
return 0;
}
_
^ permalink raw reply
* [patch 4/7] drivers/bluetooth/btsdio.c: fix double-free
From: akpm @ 2008-02-05 7:48 UTC (permalink / raw)
To: marcel; +Cc: netdev, akpm, bunk
From: Adrian Bunk <bunk@kernel.org>
This patch fixes a double-free spotted by the Coverity checker.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/bluetooth/btsdio.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff -puN drivers/bluetooth/btsdio.c~drivers-bluetooth-btsdioc-fix-double-free drivers/bluetooth/btsdio.c
--- a/drivers/bluetooth/btsdio.c~drivers-bluetooth-btsdioc-fix-double-free
+++ a/drivers/bluetooth/btsdio.c
@@ -162,10 +162,8 @@ static int btsdio_rx_packet(struct btsdi
bt_cb(skb)->pkt_type = hdr[3];
err = hci_recv_frame(skb);
- if (err < 0) {
- kfree(skb);
+ if (err < 0)
return err;
- }
sdio_writeb(data->func, 0x00, REG_PC_RRT, NULL);
_
^ permalink raw reply
* Re: [PATCH] SCTP: Fix kernel panic while received AUTH chunk while enabled auth
From: Wei Yongjun @ 2008-02-05 8:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Vlad Yasevich, lksctp-developers
In-Reply-To: <479A112D.5020201@hp.com>
If STCP is started while /proc/sys/net/sctp/auth_enable is set 0 and
association is established between endpoints. Then if
/proc/sys/net/sctp/auth_enable is set 1, a received AUTH chunk will
cause kernel panic.
Test as following:
step 1: echo 0> /proc/sys/net/sctp/auth_enable
step 2:
SCTP client SCTP server
INIT --------->
<--------- INIT-ACK
COOKIE-ECHO --------->
<--------- COOKIE-ACK
step 3:
echo 1> /proc/sys/net/sctp/auth_enable
step 4:
SCTP client SCTP server
AUTH -----------> Kernel Panic
This patch fix this probleam to treat AUTH chunk as unknow chunk if peer
has initialized with no auth capable.
> Sorry for the delay. Was on vacation without net access.
>
> Wei Yongjun wrote:
>>
>>
>> This patch fix this probleam to treat AUTH chunk as unknow chunk if
>> peer has initialized with no auth capable.
>>
>> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
>
> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
>
>>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
--- a/net/sctp/sm_statefuns.c 2008-01-21 00:03:25.000000000 -0500
+++ b/net/sctp/sm_statefuns.c 2008-01-21 05:14:08.000000000 -0500
@@ -3785,6 +3785,10 @@ sctp_disposition_t sctp_sf_eat_auth(cons
struct sctp_chunk *err_chunk;
sctp_ierror_t error;
+ /* Make sure that the peer has AUTH capable */
+ if (!asoc->peer.auth_capable)
+ return sctp_sf_unk_chunk(ep, asoc, type, arg, commands);
+
if (!sctp_vtag_verify(chunk, asoc)) {
sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_BAD_TAG,
SCTP_NULL());
^ permalink raw reply
* Re: [PATCH] SCTP: Fix kernel panic while received AUTH chunk with BAD shared key identifier
From: Wei Yongjun @ 2008-02-05 8:26 UTC (permalink / raw)
To: David Miller; +Cc: Vlad Yasevich, Neil Horman, netdev, lksctp-developers
In-Reply-To: <479A126F.4010505@hp.com>
If SCTP-AUTH is enabled, received AUTH chunk with BAD shared key
identifier will cause kernel panic.
Test as following:
step1: enabled /proc/sys/net/sctp/auth_enable
step 2: connect to SCTP server with auth capable. Association is
established between endpoints. Then send a AUTH chunk with a bad
shareid, SCTP server will kernel panic after received that AUTH chunk.
SCTP client SCTP server
INIT ---------->
(with auth capable)
<---------- INIT-ACK
(with auth capable)
COOKIE-ECHO ---------->
<---------- COOKIE-ACK
AUTH ---------->
AUTH chunk is like this:
AUTH chunk
Chunk type: AUTH (15)
Chunk flags: 0x00
Chunk length: 28
Shared key identifier: 10
HMAC identifier: SHA-1 (1)
HMAC: 0000000000000000000000000000000000000000
The assignment of NULL to key can safely be removed, since key_for_each
(which is just list_for_each_entry under the covers does an initial
assignment to key anyway).
If the endpoint_shared_keys list is empty, or if the key_id being
requested does not exist, the function as it currently stands returns
the actuall list_head (in this case endpoint_shared_keys. Since that
list_head isn't surrounded by an actuall data structure, the last
iteration through list_for_each_entry will do a container_of on key, and
we wind up returning a bogus pointer, instead of NULL, as we should.
> Neil Horman wrote:
>> On Tue, Jan 22, 2008 at 05:29:20PM +0900, Wei Yongjun wrote:
>>
>> FWIW, Ack from me. The assignment of NULL to key can safely be
>> removed, since
>> key_for_each (which is just list_for_each_entry under the covers does
>> an initial
>> assignment to key anyway).
>> If the endpoint_shared_keys list is empty, or if the key_id being
>> requested does
>> not exist, the function as it currently stands returns the actuall
>> list_head (in
>> this case endpoint_shared_keys. Since that list_head isn't
>> surrounded by an
>> actuall data structure, the last iteration through
>> list_for_each_entry will do a
>> container_of on key, and we wind up returning a bogus pointer,
>> instead of NULL,
>> as we should. Wei's patch corrects that.
>>
>> Regards
>> Neil
>>
>> Acked-by: Neil Horman <nhorman@tuxdriver.com>
>>
>
> Yep, the patch is correct.
>
> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
>
> -vlad
>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
--- a/net/sctp/auth.c 2008-01-21 00:03:25.000000000 -0500
+++ b/net/sctp/auth.c 2008-01-21 21:31:47.000000000 -0500
@@ -420,15 +420,15 @@ struct sctp_shared_key *sctp_auth_get_sh
const struct sctp_association *asoc,
__u16 key_id)
{
- struct sctp_shared_key *key = NULL;
+ struct sctp_shared_key *key;
/* First search associations set of endpoint pair shared keys */
key_for_each(key, &asoc->endpoint_shared_keys) {
if (key->key_id == key_id)
- break;
+ return key;
}
- return key;
+ return NULL;
}
/*
^ permalink raw reply
* Re: [Wireless, ath5k] 2.6.24-git13 9135f1901ee6449dfe338adf6e40e9c2025b8150
From: Jiri Slaby @ 2008-02-05 8:54 UTC (permalink / raw)
To: Oliver Pinter
Cc: netdev, ath5k-devel-xDcbHBWguxEUs3QNXV6qNA, John W. Linville,
Linux Kernel, Bruno Randolf, Andrew Morton
In-Reply-To: <6101e8c40802041340g749b1e03k70fda7fdb21452d7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 02/04/2008 10:40 PM, Oliver Pinter wrote:
> On 2/4/08, Oliver Pinter <oliver.pntr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 2/4/08, Jiri Slaby <jirislaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On 02/04/2008 03:00 PM, Oliver Pinter (Pintér Olivér) wrote:
>>>> [ 413.118874] wpa_supplicant[4388]: segfault at 30 ip 080697ca sp
>>>> bfc9cab0 error 4 in wpa_supplicant[8048000+4c000]
>>> Seems like wpa_supplicant is broken. Is this a regression?
>> yes, but with madwifi is all ok
And this... madwifi goes through ported bsd net80211. So which latest git you
tried worked for you when this is a regression, please?
^ permalink raw reply
* RE: LRO ip_summed
From: Kostya B @ 2008-02-05 8:56 UTC (permalink / raw)
To: Jan-Bernd Themann; +Cc: netdev
In-Reply-To: <200802041014.23989.ossthema@de.ibm.com>
1. Let's assume a driver which has a HW csum capability, however it has a privilege to assign any value for ip_summed.
For example the driver assigns "unnecessary" for most of the packets, however it fails to verify the packets less than 96 bytes ("checksum_none").
Now, the LRO will aggregate all of them and assign the value "used for all aggregated packets" - that is wrong,
Of course, it is possible to avoid that situation in driver, however [proposal] from the point of view of the *generic* LRO it could be better to check each newly aggregated skb whether it has the same ip_summed as the first one (preserve coherency). Thus, there is no need to keep ip_summed field in the struct net_lro_mgr.
2. Now, when a skb could not be aggregated (modes: aggregating SKBs) I think where's no need to override its original ip_summed (see "out" label of __lro_proc_skb()) The comment says "Original SKB has to be posted to stack". I would be wrong, but I don't get the reason to possible change of ip_summed.
Regards,
- Kostya
----------------------------------------
> From: ossthema@de.ibm.com
> To: bkostya@hotmail.com
> Subject: Re: LRO ip_summed
> Date: Mon, 4 Feb 2008 10:14:23 +0100
> CC: netdev@vger.kernel.org
>
> On Sunday 03 February 2008 10:48, Kostya B wrote:
>>
>> Hi,
>>
>> The mail is related to the way LRO manipulates the ip_summed value. Could anybody (author) explain why to overwrite the original value of skb->ip_summed, when it's processing by __lro_proc_skb ?
>> E.g. in out: label
>>
>> Why not to preserve the coherency of csum status of each incoming to LRO packet, the same way the IP defragmentation does? That means - all skb in descriptor have the same value of ip_summed.
>>
>
> Hi,
>
> I'm not sure if I understand your proposal correctly.
> Currently the driver decides via the struct net_lro_mgr
> a) which ip_summed value will be used for all aggregated packets
> b) which one to use for those packets that can not be aggregated
>
> to a) this one should always be the same. The driver knows whether its HW is
> capable of performing ip checksum checking for this kind of traffic (TCP)
>
> There are two modes: aggregating SKBs or aggregating fragments.
> When fragments are aggregated, there is no SKB with a filled ip_summed available.
>
> Please outline which parts of which mode you suggest to change.
>
> Regards,
> Jan-Bernd
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
^ permalink raw reply
* [IPV6] fix sysctl compilation error
From: Daniel Lezcano @ 2008-02-05 9:10 UTC (permalink / raw)
To: David Miller
Cc: YOSHIFUJI Hideaki / 吉藤英明,
Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: fix-sysctl-compilation-error.patch --]
[-- Type: text/x-patch, Size: 1547 bytes --]
Subject: fix sysctl compilation error
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Move ipv6_icmp_sysctl_init and ipv6_route_sysctl_init into
the right ifdef section otherwise that does not compile when
CONFIG_SYSCTL=yes and CONFIG_PROC_FS=no
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
include/net/ipv6.h | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
Index: net-2.6.25-fix/include/net/ipv6.h
===================================================================
--- net-2.6.25-fix.orig/include/net/ipv6.h
+++ net-2.6.25-fix/include/net/ipv6.h
@@ -110,7 +110,6 @@ struct frag_hdr {
/* sysctls */
extern int sysctl_mld_max_msf;
-
extern struct ctl_path net_ipv6_ctl_path[];
#define _DEVINC(statname, modifier, idev, field) \
@@ -586,9 +585,6 @@ extern int ip6_mc_msfget(struct sock *sk
int __user *optlen);
#ifdef CONFIG_PROC_FS
-extern struct ctl_table *ipv6_icmp_sysctl_init(struct net *net);
-extern struct ctl_table *ipv6_route_sysctl_init(struct net *net);
-
extern int ac6_proc_init(void);
extern void ac6_proc_exit(void);
extern int raw6_proc_init(void);
@@ -621,6 +617,8 @@ static inline int snmp6_unregister_dev(s
extern ctl_table ipv6_route_table_template[];
extern ctl_table ipv6_icmp_table_template[];
+extern struct ctl_table *ipv6_icmp_sysctl_init(struct net *net);
+extern struct ctl_table *ipv6_route_sysctl_init(struct net *net);
extern int ipv6_sysctl_register(void);
extern void ipv6_sysctl_unregister(void);
#endif
^ permalink raw reply
* [FIB] fix fib_proc compilation error
From: Daniel Lezcano @ 2008-02-05 9:11 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: fix-fib-frontend-compilation-error.patch --]
[-- Type: text/x-patch, Size: 827 bytes --]
Subject: fix fib_proc compilation error
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Fix fib_proc_[init|exit] definition when CONFIG_PROCFS=no
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
---
include/net/ip_fib.h | 10 ++++++++++
1 file changed, 10 insertions(+)
Index: net-2.6/include/net/ip_fib.h
===================================================================
--- net-2.6.orig/include/net/ip_fib.h
+++ net-2.6/include/net/ip_fib.h
@@ -266,6 +266,16 @@ static inline void fib_res_put(struct fi
#ifdef CONFIG_PROC_FS
extern int __net_init fib_proc_init(struct net *net);
extern void __net_exit fib_proc_exit(struct net *net);
+#else
+static inline int fib_proc_init(struct net *net)
+{
+ return 0;
+}
+
+static inline void fib_proc_exit(struct net *net)
+{
+ return ;
+}
#endif
#endif /* _NET_FIB_H */
^ permalink raw reply
* Re: Slow OOM in netif_RX function
From: Ivan Mitev @ 2008-02-05 9:04 UTC (permalink / raw)
To: Andi Kleen; +Cc: Ivan Dichev, Eric Dumazet, Arnaldo Carvalho de Melo, netdev
In-Reply-To: <20080204155526.GA7988@one.firstfloor.org>
[(the other) Ivan took a few days holidays, so I'm replacing him for
this issue.]
Andi, you spotted it, it was really the start of an IP header, and it
shows up that these are ESP packets for a quite complicated VPN tunnel
we have (re-routing packets from an office to another, with some NAT on
top of that). So openswan/ipsec.ko seems to be the problem here, I will
file a bug report there. Meanwhile we'll try to set up manual keying and
decrypt the encrypted payload to gather more details on the packets.
My apologies, the issue seems to be with an out-of-tree module, but we
really didn't think the problem was there (there's no correlation
between the leak increase and vpn/ike traffic). But it was interesting
to understand slabs, learn how to setup/use crash, and analyze memory
bits :)
Thanks again to all the people who helped !
Ivan Mitev
Andi Kleen wrote:
>> Nothing that looks like a struct net_device. All the dumped leaked slab
>> look the same until "45 20 05 d8" (the ascii 'E' on the 3rd line).
>
> 45 ... is often the start of an IP header (IPv4, 5*4=20 bytes length)
>
> You could dump them to a file (e.g. using a sial script) and then
> look at them with tcpdump or similar to get an idea what kinds
> of packets they are.
>
> -Andi
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: LRO ip_summed
From: Jan-Bernd Themann @ 2008-02-05 9:45 UTC (permalink / raw)
To: Kostya B; +Cc: netdev
In-Reply-To: <BAY121-W3321045858D4A665892759B62C0@phx.gbl>
On Tuesday 05 February 2008 09:56, Kostya B wrote:
>
> 1. Let's assume a driver which has a HW csum capability, however it has a privilege to assign any value for ip_summed.
> For example the driver assigns "unnecessary" for most of the packets, however it fails to verify the packets less than 96 bytes ("checksum_none").
> Now, the LRO will aggregate all of them and assign the value "used for all aggregated packets" - that is wrong,
>
> Of course, it is possible to avoid that situation in driver, however [proposal] from the point of view of the *generic* LRO it could be better to check each newly aggregated skb whether it has the same ip_summed as the first one (preserve coherency). Thus, there is no need to keep ip_summed field in the struct net_lro_mgr.
Yes, checking if ip_summed is equal for all aggregated packets would work
for the "aggregating SKB" mode. For the other mode this information is currently
not passed to LRO but could of course be provided as parameter by the driver.
The question is if there is any HW which would benefit from this (meaning multiple
ip_summed values for TCP packets of different sizes) so that this additional
check is really useful. The less required checks the better.
>
> 2. Now, when a skb could not be aggregated (modes: aggregating SKBs) I think where's no need to override its original ip_summed (see "out" label of __lro_proc_skb()) The comment says "Original SKB has to be posted to stack". I would be wrong, but I don't get the reason to possible change of ip_summed.
>
Good point. This assignment seems to be unnecessary.
Regards,
Jan-Bernd
^ permalink raw reply
* Re: [PATCH 00/24 for-2.6.25] DM9000 updates for 2.6.25
From: Laurent Pinchart @ 2008-02-05 9:52 UTC (permalink / raw)
To: Ben Dooks; +Cc: netdev, jeff, akpm, daniel
In-Reply-To: <20080205000159.432081941@fluff.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]
On Tuesday 05 February 2008 01:01, Ben Dooks wrote:
> This patch set is a series of updates for the DM9000
> driver, to tidy-up some of the source, stop the accesses
> to the PHY and EEPROM sitting and spinning with locks
> held, and to add ethtool support.
>
> This set includes a pair of patches from Laurent Pinchart
> for addition platform-data based configuration, please
> apply these from this if you can attribute these correctly
> to Laurent, otherwise ask Laurent to resubmit. I have
> signed-off-by both these patches, but would be equally
> happy acking them.
If you can apply the patches without a resubmission that's of course less work
for me :-) Otherwise I can resubmit them.
> The only missing item in this series is to replace the
> old timer based polling code. This series has been sitting
> long enough on my own trees, and having MII link status
> reports is not a driver-threatening bug.
>
> Hopefully this series meets up to everyone's approval and
> can be applied whilst the current merge window is upon us.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] [IPV4]: Formatting fix for /proc/net/fib_trie.
From: Denis V. Lunev @ 2008-02-05 9:58 UTC (permalink / raw)
To: davem; +Cc: netdev, devel, Denis V. Lunev
The line in the /proc/net/fib_trie for route with TOS specified
- has extra \n at the end
- does not have a space after route scope
like below.
|-- 1.1.1.1
/32 universe UNICASTtos =1
Signed-off-by: Denis V. Lunev <den@openvz.org>
---
net/ipv4/fib_trie.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 35851c9..f5fba3f 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -2431,8 +2431,7 @@ static int fib_trie_seq_show(struct seq_file *seq, void *v)
rtn_type(buf2, sizeof(buf2),
fa->fa_type));
if (fa->fa_tos)
- seq_printf(seq, "tos =%d\n",
- fa->fa_tos);
+ seq_printf(seq, " tos=%d", fa->fa_tos);
seq_putc(seq, '\n');
}
}
--
1.5.3.rc5
^ permalink raw reply related
* Re: [2.6 patch] xfrm4_beet_input(): fix an if()
From: David Miller @ 2008-02-05 10:51 UTC (permalink / raw)
To: herbert; +Cc: bunk, netdev
In-Reply-To: <20080202222226.GB31388@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 3 Feb 2008 09:22:26 +1100
> On Sat, Feb 02, 2008 at 11:16:35PM +0200, Adrian Bunk wrote:
> > A bug every C programmer makes at some point in time...
> >
> > Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
> Good catch!
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: [FIB] fix fib_proc compilation error
From: David Miller @ 2008-02-05 10:54 UTC (permalink / raw)
To: dlezcano; +Cc: netdev
In-Reply-To: <47A8285A.7040205@fr.ibm.com>
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Date: Tue, 05 Feb 2008 10:11:54 +0100
> Subject: fix fib_proc compilation error
> From: Daniel Lezcano <dlezcano@fr.ibm.com>
>
> Fix fib_proc_[init|exit] definition when CONFIG_PROCFS=no
>
> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Li Zefan already posted a fix for this which I've just
applied.
^ permalink raw reply
* Re: [PATCH] [NET_SCHED] Add #ifdef CONFIG_NET_EMATCH in net/sched/cls_flow.c (latest git broken build)
From: David Miller @ 2008-02-05 10:57 UTC (permalink / raw)
To: ramirose; +Cc: kaber, lizf, linux-kernel, netdev
In-Reply-To: <eb3ff54b0802030051x604c991fwe11184e25d0a7550@mail.gmail.com>
From: "Rami Rosen" <ramirose@gmail.com>
Date: Sun, 3 Feb 2008 10:51:42 +0200
> The 2.6 latest git build was broken when using the following
> configuration options:
> CONFIG_NET_EMATCH=n
> CONFIG_NET_CLS_FLOW=y
>
> with the following error:
> net/sched/cls_flow.c: In function 'flow_dump':
> net/sched/cls_flow.c:598: error: 'struct tcf_ematch_tree' has no
> member named 'hdr'
> make[2]: *** [net/sched/cls_flow.o] Error 1
> make[1]: *** [net/sched] Error 2
> make: *** [net] Error 2
>
>
> see the recent post by Li Zefan:
> http://www.spinics.net/lists/netdev/msg54434.html
>
> The reason for this crash is that struct tcf_ematch_tree (net/pkt_cls.h) is
> empty when CONFIG_NET_EMATCH is not defined.
>
> When CONFIG_NET_EMATCH is defined, the tcf_ematch_tree structure indeed holds
> a struct tcf_ematch_tree_hdr (hdr) as flow_dump() expects.
>
> This patch adds #ifdef CONFIG_NET_EMATCH in flow_dump to avoid this.
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [IPV6] fix sysctl compilation error
From: David Miller @ 2008-02-05 10:58 UTC (permalink / raw)
To: dlezcano; +Cc: yoshfuji, netdev
In-Reply-To: <47A827ED.6000908@fr.ibm.com>
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Date: Tue, 05 Feb 2008 10:10:05 +0100
> Subject: fix sysctl compilation error
> From: Daniel Lezcano <dlezcano@fr.ibm.com>
>
> Move ipv6_icmp_sysctl_init and ipv6_route_sysctl_init into
> the right ifdef section otherwise that does not compile when
> CONFIG_SYSCTL=yes and CONFIG_PROC_FS=no
>
> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
> Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] [IPV4]: Formatting fix for /proc/net/fib_trie.
From: David Miller @ 2008-02-05 10:58 UTC (permalink / raw)
To: den; +Cc: netdev, devel
In-Reply-To: <1202205536-9888-1-git-send-email-den@openvz.org>
From: "Denis V. Lunev" <den@openvz.org>
Date: Tue, 5 Feb 2008 12:58:56 +0300
> The line in the /proc/net/fib_trie for route with TOS specified
> - has extra \n at the end
> - does not have a space after route scope
> like below.
> |-- 1.1.1.1
> /32 universe UNICASTtos =1
>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] SCTP: Fix kernel panic while received AUTH chunk while enabled auth
From: David Miller @ 2008-02-05 11:02 UTC (permalink / raw)
To: yjwei; +Cc: netdev, vladislav.yasevich, lksctp-developers
In-Reply-To: <47A81C72.8050207@cn.fujitsu.com>
From: Wei Yongjun <yjwei@cn.fujitsu.com>
Date: Tue, 05 Feb 2008 17:21:06 +0900
> If STCP is started while /proc/sys/net/sctp/auth_enable is set 0 and
> association is established between endpoints. Then if
> /proc/sys/net/sctp/auth_enable is set 1, a received AUTH chunk will
> cause kernel panic.
...
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied.
^ permalink raw reply
* Re: [PATCH] SCTP: Fix kernel panic while received AUTH chunk with BAD shared key identifier
From: David Miller @ 2008-02-05 11:03 UTC (permalink / raw)
To: yjwei; +Cc: vladislav.yasevich, nhorman, netdev, lksctp-developers
In-Reply-To: <47A81DBD.6000802@cn.fujitsu.com>
From: Wei Yongjun <yjwei@cn.fujitsu.com>
Date: Tue, 05 Feb 2008 17:26:37 +0900
> If SCTP-AUTH is enabled, received AUTH chunk with BAD shared key
> identifier will cause kernel panic.
...
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox