* Re: [PATCH v2] xfrm: Fix initialize repl field of struct xfrm_state
From: David Miller @ 2011-03-21 8:01 UTC (permalink / raw)
To: yjwei; +Cc: netdev, steffen.klassert
In-Reply-To: <20110321.010037.59680394.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 21 Mar 2011 01:00:37 -0700 (PDT)
> From: Wei Yongjun <yjwei@cn.fujitsu.com>
> Date: Mon, 21 Mar 2011 15:44:03 +0800
>
>> -int xfrm_init_state(struct xfrm_state *x)
>> +int __xfrm_init_state(struct xfrm_state *x, bool init_replay)
>
> Since it is referenced by modules, this new function symbol must
> be exported to them.
BTW, this is one of the reasons I explicitly mentioned to make
this an inline function. :-)
^ permalink raw reply
* Re: [PATCH v2] xfrm: Fix initialize repl field of struct xfrm_state
From: David Miller @ 2011-03-21 8:00 UTC (permalink / raw)
To: yjwei; +Cc: netdev, steffen.klassert
In-Reply-To: <4D8701C3.5010304@cn.fujitsu.com>
From: Wei Yongjun <yjwei@cn.fujitsu.com>
Date: Mon, 21 Mar 2011 15:44:03 +0800
> -int xfrm_init_state(struct xfrm_state *x)
> +int __xfrm_init_state(struct xfrm_state *x, bool init_replay)
Since it is referenced by modules, this new function symbol must
be exported to them.
^ permalink raw reply
* Re: [PATCH v2] net: add Faraday FTGMAC100 Gigabit Ethernet driver
From: Po-Yu Chuang @ 2011-03-21 7:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-kernel, ratbert
In-Reply-To: <1300361405.3133.175.camel@edumazet-laptop>
Hi Eric,
On Thu, Mar 17, 2011 at 7:30 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 17 mars 2011 à 18:56 +0800, Po-Yu Chuang a écrit :
>> On Thu, Mar 17, 2011 at 6:24 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > Le jeudi 17 mars 2011 à 17:47 +0800, Po-Yu Chuang a écrit :
>> >> From: Po-Yu Chuang <ratbert@faraday-tech.com>
>> >>
>> >> FTGMAC100 Ethernet Media Access Controller supports 10/100/1000 Mbps
>> >> and MII/GMII. This driver has been working on some ARM/NDS32 SoC's
>> >> including Faraday A369 and Andes AG102.
>> >>
>> >> Signed-off-by: Po-Yu Chuang <ratbert@faraday-tech.com>
>> >> ---
>> >
>> > Did you tried GRO support ?
>>
>> No, I don't understand how to do that yet. Let me do some study first.
>> I'd really appreciate it if you could provide me some pointers about GRO. :-)
>> Is there any document about it?
>
> Should be easy and might help performance too.
>
> Take a look at commit :
>
> 2edae08e5b75269855fef3c74fe4292c066e7c33 (r8169: add gro support)
It seems to work fine so far at least the driver is not broken, but I did not
see much difference in performance though. How do I know if GRO is
working indeed?
Best regards,
Po-Yu Chuang
^ permalink raw reply
* Re: xfrm: Fix initialize repl field of struct xfrm_state
From: Steffen Klassert @ 2011-03-21 7:54 UTC (permalink / raw)
To: Wei Yongjun; +Cc: David Miller, netdev
In-Reply-To: <4D86F4EA.6030909@cn.fujitsu.com>
Thanks for catching this!
On Mon, Mar 21, 2011 at 02:49:14PM +0800, Wei Yongjun wrote:
> > Ok, thanks for the explanation.
> >
> > I think there is a simple way out of this:
> >
> > 1) Rename current xfrm_init_state to __xfrm_init_state, add
> > "bool init_replay" argument. Add the xfrm_init_replay()
> > call, as in your patch, but conditionalized on this boolean.
> >
> > 2) Implement xfrm_init_state as inline, which calls
> > __xfrm_init_state(..., true)
> >
> > 3) Replace xfrm_init_state() call in xfrm_user.c with
> > __xfrm_init_state(..., false)
> >
> > This seems to avoid all the problems. We don't need to touch every
> > caller, and we avoid initializing the replay state twice in xfrm_user
> >
> > Ok?
>
> This OK, I will do this change, thanks.
>
This looks ok for me too. I just noticed that we also need to clone the
replay_esn/preplay_esn informations and to reinitialize the sequence
number counting on XFRM MIGRATE from the original state before we
call xfrm_init_replay.
I'll fix this up once your patch is applied.
Thanks,
Steffen
^ permalink raw reply
* [PATCH v2] xfrm: Fix initialize repl field of struct xfrm_state
From: Wei Yongjun @ 2011-03-21 7:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, steffen.klassert
In-Reply-To: <20110320.234606.183056322.davem@davemloft.net>
Commit 'xfrm: Move IPsec replay detection functions to a separate file'
(9fdc4883d92d20842c5acea77a4a21bb1574b495)
introduce repl field to struct xfrm_state, and only initialize it
under SA's netlink create path, the other path, such as pf_key,
ipcomp/ipcomp6 etc, the repl field remaining uninitialize. So if
the SA is created by pf_key, any input packet with SA's encryption
algorithm will cause panic.
int xfrm_input()
{
...
x->repl->advance(x, seq);
...
}
This patch fixed it by introduce new function __xfrm_init_state().
Pid: 0, comm: swapper Not tainted 2.6.38-next+ #14 Bochs Bochs
EIP: 0060:[<c078e5d5>] EFLAGS: 00010206 CPU: 0
EIP is at xfrm_input+0x31c/0x4cc
EAX: dd839c00 EBX: 00000084 ECX: 00000000 EDX: 01000000
ESI: dd839c00 EDI: de3a0780 EBP: dec1de88 ESP: dec1de64
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process swapper (pid: 0, ti=dec1c000 task=c09c0f20 task.ti=c0992000)
Stack:
00000000 00000000 00000002 c0ba27c0 00100000 01000000 de3a0798 c0ba27c0
00000033 dec1de98 c0786848 00000000 de3a0780 dec1dea4 c0786868 00000000
dec1debc c074ee56 e1da6b8c de3a0780 c074ed44 de3a07a8 dec1decc c074ef32
Call Trace:
[<c0786848>] xfrm4_rcv_encap+0x22/0x27
[<c0786868>] xfrm4_rcv+0x1b/0x1d
[<c074ee56>] ip_local_deliver_finish+0x112/0x1b1
[<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
[<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
[<c074ef77>] ip_local_deliver+0x3e/0x44
[<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
[<c074ec03>] ip_rcv_finish+0x30a/0x332
[<c074e8f9>] ? ip_rcv_finish+0x0/0x332
[<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
[<c074f188>] ip_rcv+0x20b/0x247
[<c074e8f9>] ? ip_rcv_finish+0x0/0x332
[<c072797d>] __netif_receive_skb+0x373/0x399
[<c0727bc1>] netif_receive_skb+0x4b/0x51
[<e0817e2a>] cp_rx_poll+0x210/0x2c4 [8139cp]
[<c072818f>] net_rx_action+0x9a/0x17d
[<c0445b5c>] __do_softirq+0xa1/0x149
[<c0445abb>] ? __do_softirq+0x0/0x149
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
include/net/xfrm.h | 1 +
net/xfrm/xfrm_state.c | 13 ++++++++++++-
net/xfrm/xfrm_user.c | 2 +-
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 42a8c32..cffa5dc 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1430,6 +1430,7 @@ extern void xfrm_spd_getinfo(struct net *net, struct xfrmk_spdinfo *si);
extern u32 xfrm_replay_seqhi(struct xfrm_state *x, __be32 net_seq);
extern int xfrm_init_replay(struct xfrm_state *x);
extern int xfrm_state_mtu(struct xfrm_state *x, int mtu);
+extern int __xfrm_init_state(struct xfrm_state *x, bool init_replay);
extern int xfrm_init_state(struct xfrm_state *x);
extern int xfrm_prepare_input(struct xfrm_state *x, struct sk_buff *skb);
extern int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi,
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index d575f05..ff96b14 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1907,7 +1907,7 @@ int xfrm_state_mtu(struct xfrm_state *x, int mtu)
return res;
}
-int xfrm_init_state(struct xfrm_state *x)
+int __xfrm_init_state(struct xfrm_state *x, bool init_replay)
{
struct xfrm_state_afinfo *afinfo;
struct xfrm_mode *inner_mode;
@@ -1980,12 +1980,23 @@ int xfrm_init_state(struct xfrm_state *x)
if (x->outer_mode == NULL)
goto error;
+ if (init_replay) {
+ err = xfrm_init_replay(x);
+ if (err)
+ goto error;
+ }
+
x->km.state = XFRM_STATE_VALID;
error:
return err;
}
+int xfrm_init_state(struct xfrm_state *x)
+{
+ return __xfrm_init_state(x, true);
+}
+
EXPORT_SYMBOL(xfrm_init_state);
int __net_init xfrm_state_init(struct net *net)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 706385a..fc152d2 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -511,7 +511,7 @@ static struct xfrm_state *xfrm_state_construct(struct net *net,
xfrm_mark_get(attrs, &x->mark);
- err = xfrm_init_state(x);
+ err = __xfrm_init_state(x, false);
if (err)
goto error;
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH 2/2] socket: add minimum listen queue length sysctl
From: Eric Dumazet @ 2011-03-21 7:36 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: netdev
In-Reply-To: <1300662282-24741-2-git-send-email-hagen@jauu.net>
Le lundi 21 mars 2011 à 00:04 +0100, Hagen Paul Pfeifer a écrit :
> In the case that a server programmer misjudge network characteristic the
> backlog parameter for listen(2) may not adequate to utilize hosts
> capabilities and lead to unrequired SYN retransmission - a small backlog
> value can form an artificial limitation. From Erics server setup, a
> listen queue length of 8 is often a way to small):
>
> ss -a | head
> State Recv-Q Send-Q Local Address:Port Peer
> Address:Port
> LISTEN 0 8 *:imaps *:*
> LISTEN 0 8 *:pop3s *:*
> LISTEN 0 50 *:mysql *:*
> LISTEN 0 8 *:pop3 *:*
> LISTEN 0 8 *:imap2 *:*
> LISTEN 0 511 *:www *:*
>
> Until now it is not possible for the system (network) administrator to
> increase this value. A bug report must be filled, the backlog increased,
> a new version released or even worse: if using closed source software
> you cannot make anything.
>
> sysctl_min_syn_backlog provides the ability to increase the minimum
> queue length. The default is 8.
>
> Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
>
> ---
> I will spin a second documentation patch if Davem accept this patch.
> ---
> include/net/request_sock.h | 1 +
> net/core/request_sock.c | 5 ++++-
> net/ipv4/sysctl_net_ipv4.c | 7 +++++++
> 3 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/request_sock.h b/include/net/request_sock.h
> index 99e6e19..3e8865f 100644
> --- a/include/net/request_sock.h
> +++ b/include/net/request_sock.h
> @@ -89,6 +89,7 @@ static inline void reqsk_free(struct request_sock *req)
> }
>
> extern int sysctl_max_syn_backlog;
> +extern int sysctl_min_syn_backlog;
>
> /** struct listen_sock - listen state
> *
> diff --git a/net/core/request_sock.c b/net/core/request_sock.c
> index 182236b..e937e9c 100644
> --- a/net/core/request_sock.c
> +++ b/net/core/request_sock.c
> @@ -35,6 +35,9 @@
> int sysctl_max_syn_backlog = 256;
> EXPORT_SYMBOL(sysctl_max_syn_backlog);
>
> +int sysctl_min_syn_backlog = 8;
> +EXPORT_SYMBOL(sysctl_min_syn_backlog);
> +
> int reqsk_queue_alloc(struct request_sock_queue *queue,
> unsigned int nr_table_entries)
> {
> @@ -42,7 +45,7 @@ int reqsk_queue_alloc(struct request_sock_queue *queue,
> struct listen_sock *lopt;
>
> nr_table_entries = min_t(u32, nr_table_entries, sysctl_max_syn_backlog);
> - nr_table_entries = max_t(u32, nr_table_entries, 8);
> + nr_table_entries = max_t(u32, nr_table_entries, sysctl_min_syn_backlog);
> nr_table_entries = roundup_pow_of_two(nr_table_entries + 1);
> lopt_size += nr_table_entries * sizeof(struct request_sock *);
> if (lopt_size > PAGE_SIZE)
I believe you are mistaken.
The code you change is the code sizing the hash table, not
sk->sk_max_ack_backlog
This only matters if one application is able to change its listen
backlog during its lifetime.
Say, it begins with :
listen(fd, 1);
Then, a bit later :
listen(fd, 8192);
This certainly is very unlikely...
With current kernel, it does change the maximum SYN_RECV sockets in
flight, but hash table is not resized and stay with 8 slots, so
performance might be suboptimal, since chains are going to hold 1024
elements.
^ permalink raw reply
* Re: [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware
From: Philip Prindeville @ 2011-03-21 7:25 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings, netdev, linux-atm-general
In-Reply-To: <20110320.230408.112594622.davem@davemloft.net>
On 3/20/11 11:04 PM, David Miller wrote:
> From: Philip Prindeville<philipp_subx@redfish-solutions.com>
> Date: Sun, 20 Mar 2011 22:56:43 -0700
>
>> It's not clear that dropping all VCs abruptly when carrier flapped was
>> ever the right thing to do.
> So you've tested your change with the older firmware present?
I haven't, no: back-revving firmware has been known to brick cards.
I'm waiting to hear back from Guy and Nathan, they have old cards on hand that they can test.
^ permalink raw reply
* Re: xfrm: Fix initialize repl field of struct xfrm_state
From: Wei Yongjun @ 2011-03-21 6:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, steffen.klassert
In-Reply-To: <20110320.234606.183056322.davem@davemloft.net>
> From: Wei Yongjun <yjwei@cn.fujitsu.com>
> Date: Mon, 21 Mar 2011 14:36:45 +0800
>
>> Sorry for not said clearly, at the first time I want to do like this.
>> But when I grep 'xfrm_init_state', it be used in many place, not
>> any pf_key, but also XFRM MIGRATE, ipcomp, ipcomp6. So I did this ugly
>> patch by add this to xfrm_init_state() to avoid dup code.
>>
>> Not sure whether the other case like ipcomp/ipcomp6 etc can cause panic, if
>> it panic, maybe we can fix by introduce new xfrm_init_replay() function
>> like to assign the default reply function.
>> int xfrm_init_replay(struct xfrm_state *x)
>> {
>> x->repl = &xfrm_replay_legacy;
>> return 0;
>> }
>> and change the orig xfrm_init_replay to xfrm_update_replay()?
>> Or dup those code to all used place?
>>
>> If I was wrong, I will fix this by adding the necessary call to af_key.c.
> Ok, thanks for the explanation.
>
> I think there is a simple way out of this:
>
> 1) Rename current xfrm_init_state to __xfrm_init_state, add
> "bool init_replay" argument. Add the xfrm_init_replay()
> call, as in your patch, but conditionalized on this boolean.
>
> 2) Implement xfrm_init_state as inline, which calls
> __xfrm_init_state(..., true)
>
> 3) Replace xfrm_init_state() call in xfrm_user.c with
> __xfrm_init_state(..., false)
>
> This seems to avoid all the problems. We don't need to touch every
> caller, and we avoid initializing the replay state twice in xfrm_user
>
> Ok?
This OK, I will do this change, thanks.
>
>
^ permalink raw reply
* Re: xfrm: Fix initialize repl field of struct xfrm_state
From: David Miller @ 2011-03-21 6:46 UTC (permalink / raw)
To: yjwei; +Cc: netdev, steffen.klassert
In-Reply-To: <4D86F1FD.3080009@cn.fujitsu.com>
From: Wei Yongjun <yjwei@cn.fujitsu.com>
Date: Mon, 21 Mar 2011 14:36:45 +0800
> Sorry for not said clearly, at the first time I want to do like this.
> But when I grep 'xfrm_init_state', it be used in many place, not
> any pf_key, but also XFRM MIGRATE, ipcomp, ipcomp6. So I did this ugly
> patch by add this to xfrm_init_state() to avoid dup code.
>
> Not sure whether the other case like ipcomp/ipcomp6 etc can cause panic, if
> it panic, maybe we can fix by introduce new xfrm_init_replay() function
> like to assign the default reply function.
> int xfrm_init_replay(struct xfrm_state *x)
> {
> x->repl = &xfrm_replay_legacy;
> return 0;
> }
> and change the orig xfrm_init_replay to xfrm_update_replay()?
> Or dup those code to all used place?
>
> If I was wrong, I will fix this by adding the necessary call to af_key.c.
Ok, thanks for the explanation.
I think there is a simple way out of this:
1) Rename current xfrm_init_state to __xfrm_init_state, add
"bool init_replay" argument. Add the xfrm_init_replay()
call, as in your patch, but conditionalized on this boolean.
2) Implement xfrm_init_state as inline, which calls
__xfrm_init_state(..., true)
3) Replace xfrm_init_state() call in xfrm_user.c with
__xfrm_init_state(..., false)
This seems to avoid all the problems. We don't need to touch every
caller, and we avoid initializing the replay state twice in xfrm_user
Ok?
^ permalink raw reply
* Re: [PATCHv2 0/9] macb: add support for Cadence GEM
From: Nicolas Ferre @ 2011-03-21 6:38 UTC (permalink / raw)
To: David Miller, jamie, Russell King - ARM Linux
Cc: netdev, linux-arm-kernel, plagnioj, Andrew Victor,
Peter Korsgaard
In-Reply-To: <20110316.131734.242138246.davem@davemloft.net>
On 3/17/2011 4:17 AM, David Miller :
> From: Jamie Iles <jamie@jamieiles.com>
> Date: Tue, 15 Mar 2011 10:14:47 +0000
>
>> This patch series extends the Atmel MACB driver to support the Cadence
>> GEM (Gigabit Ethernet MAC) to support 10/100 operation. The GEM is
>> based on the MACB block but has a few moved registers and bitfields.
>> This patch series attempts to use the MACB accessors where block
>> functionallity is identical and only overrides to GEM specific
>> acccessors when needed.
>>
>> This has been runtested on a board with a Cadence GEM and compile tested
>> for all at91 configurations and a number of avr32 configurations.
>>
>> Changes since v1:
>> - AT91 now provides a fake "hclk" and "macb_clk" has been
>> renamed to "pclk" to be consistent with AVR32.
>> - Configurable GEM receive buffer size support has been added.
>> - pr_foo() and dev_foo() have been converted to netdev_foo()
>> where appropriate.
>> - New conditional accessors (macb_or_gem_{read,write}l) have
>> been introduced that do the conditional accesses dependent on
>> macb/gem type.
>> - GEM is now dynamically detected from the module ID rather than
>> platform device name.
>>
>> Jean-Christophe, I haven't based this on your conditional clock patch as
>> I wasn't sure what decision had been made on that and whether the
>> at91/avr32 detection is reliable.
>
> I'm happy to ACK this so you guys can merge this via one of the
> ARM trees:
>
> Acked-by: David S. Miller <davem@davemloft.net>
I add my:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Now, tell me if we need to setup a git tree with this and make it handled by linux-next (we do not have for at91 yet)?
or Russell can take the series in a "devel" branch?
I have tested the series with the v2 patches. It is working good with some modification that were discussed (hclk, pclk clocks). I attach modifications I have made to make it work so that you have an idea of my testbed (not a patch as you should already have this and it is on a development platform):
+/* One additional fake clock for macb interfaces */
+static struct clk hclk = {
+ .name = "hclk",
+ .pmc_mask = 0,
+ .type = CLK_TYPE_PERIPHERAL,
+};
@@ -247,6 +254,7 @@ static struct clk *periph_clocks[] __initdata = {
// irq0
&ohci_clk,
&tcb1_clk,
+ &hclk,
};
[..]
/* Clock */
- at91_clock_associate("macb0_clk", &at91sam9x5_eth0_device.dev, "macb_clk");
+ at91_clock_associate("macb0_clk", &at91sam9x5_eth0_device.dev, "pclk");
eth0_data = *data;
platform_device_register(&at91sam9x5_eth0_device);
Thanks, best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: oops / kernel panic in bonding.
From: Jiri Pirko @ 2011-03-21 6:37 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jay Vosburgh, Andy Gospodarek, netdev@vger.kernel.org
In-Reply-To: <4D866F59.5070703@gmail.com>
Sun, Mar 20, 2011 at 10:19:21PM CET, nicolas.2p.debian@gmail.com wrote:
>Le 20/03/2011 21:17, Nicolas de Pesloüan a écrit :
>>Hi Jiri,
>>
>>I suspect we have a race condition somewhere in the new
>>bond_handle_frame function:
>>
>>The following commands produce one of the following errors:
>>
>>modprobe bonding max_bonds=0
>>echo +bond0>/sys/class/net/bonding_masters
>>echo +bond1>/sys/class/net/bonding_masters
>>echo +eth1>/sys/class/net/bond1/bonding/slaves
>>
>>This is mostly reproducible, under VirtualBox.
>>
>>All tests done with 08351fc6a75731226e1112fc7254542bd3a2912e at the top
>>commit (current net-next-2.6).
>
>I suspect netdev_rx_handler_register is called too early in bond_enslave.
>
>I think it should be the last thing we do in bond_enslave, if we
>don't want to face the risk to have bond_handle_frame being called
>before everything is properly setup.
>
> Nicolas.
Hmm, Offset 0x280 is big, I suggest dev->master is not set. Will look at
this.
^ permalink raw reply
* Re: xfrm: Fix initialize repl field of struct xfrm_state
From: Wei Yongjun @ 2011-03-21 6:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev, steffen.klassert
In-Reply-To: <20110320.225542.71119753.davem@davemloft.net>
> From: Wei Yongjun <yjwei@cn.fujitsu.com>
> Date: Mon, 21 Mar 2011 13:45:39 +0800
>
>> Commit 'xfrm: Move IPsec replay detection functions to a separate file'
>> (9fdc4883d92d20842c5acea77a4a21bb1574b495)
>> introduce repl field to struct xfrm_state, and only initialize it
>> under SA's netlink create path, the other path, such as pf_key, the
>> repl field remaining uninitialize. So if the SA is created by pf_key,
>> any input packet with SA's encryption algorithm will cause panic.
> Please, either add an xfrm_init_replay() call to the appropriate spot
> in net/key/af_key.c or, if possible, only have the one call in
> xfrm_init_state(). Don't leave two calls, one in xfrm_user.c and one
> in xfrm_state.c
>
> Anyways, I don't think just making one call from xfrm_init_state() is
> possible, because the replay settings need to be assigned before we
> can properly call xfrm_init_replay().
>
> Therefore, please fix this by adding the necessary call to af_key.c
Sorry for not said clearly, at the first time I want to do like this.
But when I grep 'xfrm_init_state', it be used in many place, not
any pf_key, but also XFRM MIGRATE, ipcomp, ipcomp6. So I did this ugly
patch by add this to xfrm_init_state() to avoid dup code.
Not sure whether the other case like ipcomp/ipcomp6 etc can cause panic, if
it panic, maybe we can fix by introduce new xfrm_init_replay() function
like to assign the default reply function.
int xfrm_init_replay(struct xfrm_state *x)
{
x->repl = &xfrm_replay_legacy;
return 0;
}
and change the orig xfrm_init_replay to xfrm_update_replay()?
Or dup those code to all used place?
If I was wrong, I will fix this by adding the necessary call to af_key.c.
Thanks.
> Thanks.
>
^ permalink raw reply
* Re: [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware
From: David Miller @ 2011-03-21 6:04 UTC (permalink / raw)
To: philipp_subx; +Cc: bhutchings, netdev, linux-atm-general
In-Reply-To: <4D86E89B.1060905@redfish-solutions.com>
From: Philip Prindeville <philipp_subx@redfish-solutions.com>
Date: Sun, 20 Mar 2011 22:56:43 -0700
> It's not clear that dropping all VCs abruptly when carrier flapped was
> ever the right thing to do.
So you've tested your change with the older firmware present?
^ permalink raw reply
* Re: [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware
From: Philip Prindeville @ 2011-03-21 5:56 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings, netdev, linux-atm-general
In-Reply-To: <20110320.215704.193716335.davem@davemloft.net>
On 3/20/11 9:57 PM, David Miller wrote:
> From: Ben Hutchings<bhutchings@solarflare.com>
> Date: Mon, 21 Mar 2011 03:01:36 +0000
>
>> On Sun, 2011-03-20 at 18:52 -0700, Philip Prindeville wrote:
>>> The newest FPGA firmware on the Solos processors correctly signals
>>> carrier transitions, bitrate, etc.
>>>
>>> The driver previously ignored these messages, and the physical state
>>> was always ATM_PHY_SIG_UNKNOWN.
>>>
>>> Now that the board reports its state, we expose a bug whereby the
>>> transition from UNKNOWN to LOST causes us to release all VC's.
>>>
>>> We don't delete any VC's, but instead just send an indication of
>>> carrier change.
>>>
>>> Signed-off-by: Philip A Prindeville<philipp@redfish-solutions.com>
>>> ---
>>>
>>> --- a/drivers/atm/solos-pci.c 2011-03-20 15:27:40.000000000 -0600
>>> +++ b/drivers/atm/solos-pci.c 2011-03-20 16:32:11.000000000 -0600
>>> @@ -382,8 +382,10 @@ static int process_status(struct solos_c
>>>
>>> /* Anything but 'Showtime' is down */
>>> if (strcmp(state_str, "Showtime")) {
>>> atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
>>> +#if 0
>>> atm_dev_release_vccs(card->atmdev[port]);
>>> +#endif
>> Either remove it or don't. #if 0 is for people without version control.
> Also, this would seem to break those using the older firmware.
It's not clear that dropping all VCs abruptly when carrier flapped was ever the right thing to do.
-Philip
^ permalink raw reply
* Re: xfrm: Fix initialize repl field of struct xfrm_state
From: David Miller @ 2011-03-21 5:55 UTC (permalink / raw)
To: yjwei; +Cc: netdev, steffen.klassert
In-Reply-To: <4D86E603.8080704@cn.fujitsu.com>
From: Wei Yongjun <yjwei@cn.fujitsu.com>
Date: Mon, 21 Mar 2011 13:45:39 +0800
> Commit 'xfrm: Move IPsec replay detection functions to a separate file'
> (9fdc4883d92d20842c5acea77a4a21bb1574b495)
> introduce repl field to struct xfrm_state, and only initialize it
> under SA's netlink create path, the other path, such as pf_key, the
> repl field remaining uninitialize. So if the SA is created by pf_key,
> any input packet with SA's encryption algorithm will cause panic.
Please, either add an xfrm_init_replay() call to the appropriate spot
in net/key/af_key.c or, if possible, only have the one call in
xfrm_init_state(). Don't leave two calls, one in xfrm_user.c and one
in xfrm_state.c
Anyways, I don't think just making one call from xfrm_init_state() is
possible, because the replay settings need to be assigned before we
can properly call xfrm_init_replay().
Therefore, please fix this by adding the necessary call to af_key.c
Thanks.
^ permalink raw reply
* [PATCH] xfrm: Fix initialize repl field of struct xfrm_state
From: Wei Yongjun @ 2011-03-21 5:48 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller, Steffen Klassert
In-Reply-To: <4D86E603.8080704@cn.fujitsu.com>
Commit 'xfrm: Move IPsec replay detection functions to a separate file'
(9fdc4883d92d20842c5acea77a4a21bb1574b495)
introduce repl field to struct xfrm_state, and only initialize it
under SA's netlink create path, the other path, such as pf_key, the
repl field remaining uninitialize. So if the SA is created by pf_key,
any input packet with SA's encryption algorithm will cause panic.
int xfrm_input()
{
...
x->repl->advance(x, seq);
...
}
This patch fixed to init default xfrm_replay in xfrm_init_state().
Pid: 0, comm: swapper Not tainted 2.6.38-next+ #14 Bochs Bochs
EIP: 0060:[<c078e5d5>] EFLAGS: 00010206 CPU: 0
EIP is at xfrm_input+0x31c/0x4cc
EAX: dd839c00 EBX: 00000084 ECX: 00000000 EDX: 01000000
ESI: dd839c00 EDI: de3a0780 EBP: dec1de88 ESP: dec1de64
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process swapper (pid: 0, ti=dec1c000 task=c09c0f20 task.ti=c0992000)
Stack:
00000000 00000000 00000002 c0ba27c0 00100000 01000000 de3a0798 c0ba27c0
00000033 dec1de98 c0786848 00000000 de3a0780 dec1dea4 c0786868 00000000
dec1debc c074ee56 e1da6b8c de3a0780 c074ed44 de3a07a8 dec1decc c074ef32
Call Trace:
[<c0786848>] xfrm4_rcv_encap+0x22/0x27
[<c0786868>] xfrm4_rcv+0x1b/0x1d
[<c074ee56>] ip_local_deliver_finish+0x112/0x1b1
[<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
[<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
[<c074ef77>] ip_local_deliver+0x3e/0x44
[<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
[<c074ec03>] ip_rcv_finish+0x30a/0x332
[<c074e8f9>] ? ip_rcv_finish+0x0/0x332
[<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
[<c074f188>] ip_rcv+0x20b/0x247
[<c074e8f9>] ? ip_rcv_finish+0x0/0x332
[<c072797d>] __netif_receive_skb+0x373/0x399
[<c0727bc1>] netif_receive_skb+0x4b/0x51
[<e0817e2a>] cp_rx_poll+0x210/0x2c4 [8139cp]
[<c072818f>] net_rx_action+0x9a/0x17d
[<c0445b5c>] __do_softirq+0xa1/0x149
[<c0445abb>] ? __do_softirq+0x0/0x149
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
net/xfrm/xfrm_state.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index d575f05..4274e11 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1980,6 +1980,10 @@ int xfrm_init_state(struct xfrm_state *x)
if (x->outer_mode == NULL)
goto error;
+ err = xfrm_init_replay(x);
+ if (err)
+ goto error;
+
x->km.state = XFRM_STATE_VALID;
error:
--
1.6.5.2
^ permalink raw reply related
* RE: [PATCH net-next-2.6 2/6] be2net: fix to not drop unfiltered vlan pkts
From: Sathya.Perla @ 2011-03-21 5:41 UTC (permalink / raw)
To: jesse; +Cc: netdev
In-Reply-To: <AANLkTimNHmvFznX-XHmhdVmkRBBjrkEa1OyAB=gSCciu@mail.gmail.com>
Hi, can you pls clarify what you mean by the "new vlan model" below...
thanks,
-Sathya
-----Original Message-----
From: Jesse Gross [mailto:jesse@nicira.com]
Sent: Saturday, March 19, 2011 2:05 AM
To: Perla, Sathya
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net-next-2.6 2/6] be2net: fix to not drop unfiltered vlan pkts
On Fri, Mar 18, 2011 at 6:20 AM, Sathya Perla <sathya.perla@emulex.com> wrote:
> When the device is in promiscuous mode, the driver can receive vlan packets
> (tag is always stripped by card) even when there is no vlan configuration.
> Such packets must be sent to the stack and not dropped.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
> ---
> drivers/net/benet/be_main.c | 9 ++-------
> 1 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
> index 97c5167..18c6da4 100644
> --- a/drivers/net/benet/be_main.c
> +++ b/drivers/net/benet/be_main.c
> @@ -1013,15 +1013,10 @@ static void be_rx_compl_process(struct be_adapter *adapter,
> skb->truesize = skb->len + sizeof(struct sk_buff);
> skb->protocol = eth_type_trans(skb, adapter->netdev);
>
> - if (unlikely(rxcp->vlanf)) {
> - if (!adapter->vlan_grp || adapter->vlans_added == 0) {
> - kfree_skb(skb);
> - return;
> - }
> + if (unlikely(rxcp->vlanf))
> vlan_hwaccel_receive_skb(skb, adapter->vlan_grp, rxcp->vid);
It would be better to use __vlan_hwaccel_put_tag() here - it's
equivalent but at least moves in the right direction. Under the old
vlan model (which vlan_hwaccel_receive_skb() is left over from)
passing in a NULL vlan group is illegal, so it's inconsistent anyways.
Of course even better would be to fully convert over to the new vlan
model. A quick skim through the code shows that there might be
similar issue with vlan_gro_frags() as above, so it could help catch
some of that.
^ permalink raw reply
* xfrm: Fix initialize repl field of struct xfrm_state
From: Wei Yongjun @ 2011-03-21 5:45 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller, Steffen Klassert
Commit 'xfrm: Move IPsec replay detection functions to a separate file'
(9fdc4883d92d20842c5acea77a4a21bb1574b495)
introduce repl field to struct xfrm_state, and only initialize it
under SA's netlink create path, the other path, such as pf_key, the
repl field remaining uninitialize. So if the SA is created by pf_key,
any input packet with SA's encryption algorithm will cause panic.
int xfrm_input()
{
...
x->repl->advance(x, seq);
...
}
This patch fixed to init default xfrm_replay in xfrm_init_state().
Pid: 0, comm: swapper Not tainted 2.6.38-next+ #14 Bochs Bochs
EIP: 0060:[<c078e5d5>] EFLAGS: 00010206 CPU: 0
EIP is at xfrm_input+0x31c/0x4cc
EAX: dd839c00 EBX: 00000084 ECX: 00000000 EDX: 01000000
ESI: dd839c00 EDI: de3a0780 EBP: dec1de88 ESP: dec1de64
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process swapper (pid: 0, ti=dec1c000 task=c09c0f20 task.ti=c0992000)
Stack:
00000000 00000000 00000002 c0ba27c0 00100000 01000000 de3a0798 c0ba27c0
00000033 dec1de98 c0786848 00000000 de3a0780 dec1dea4 c0786868 00000000
dec1debc c074ee56 e1da6b8c de3a0780 c074ed44 de3a07a8 dec1decc c074ef32
Call Trace:
[<c0786848>] xfrm4_rcv_encap+0x22/0x27
[<c0786868>] xfrm4_rcv+0x1b/0x1d
[<c074ee56>] ip_local_deliver_finish+0x112/0x1b1
[<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
[<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
[<c074ef77>] ip_local_deliver+0x3e/0x44
[<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
[<c074ec03>] ip_rcv_finish+0x30a/0x332
[<c074e8f9>] ? ip_rcv_finish+0x0/0x332
[<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
[<c074f188>] ip_rcv+0x20b/0x247
[<c074e8f9>] ? ip_rcv_finish+0x0/0x332
[<c072797d>] __netif_receive_skb+0x373/0x399
[<c0727bc1>] netif_receive_skb+0x4b/0x51
[<e0817e2a>] cp_rx_poll+0x210/0x2c4 [8139cp]
[<c072818f>] net_rx_action+0x9a/0x17d
[<c0445b5c>] __do_softirq+0xa1/0x149
[<c0445abb>] ? __do_softirq+0x0/0x149
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
net/xfrm/xfrm_state.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index d575f05..4274e11 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1980,6 +1980,10 @@ int xfrm_init_state(struct xfrm_state *x)
if (x->outer_mode == NULL)
goto error;
+ err = xfrm_init_replay(x);
+ if (err)
+ goto error;
+
x->km.state = XFRM_STATE_VALID;
error:
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware
From: David Miller @ 2011-03-21 4:57 UTC (permalink / raw)
To: bhutchings; +Cc: philipp_subx, netdev, linux-atm-general
In-Reply-To: <1300676496.26693.318.camel@localhost>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 21 Mar 2011 03:01:36 +0000
> On Sun, 2011-03-20 at 18:52 -0700, Philip Prindeville wrote:
>> The newest FPGA firmware on the Solos processors correctly signals
>> carrier transitions, bitrate, etc.
>>
>> The driver previously ignored these messages, and the physical state
>> was always ATM_PHY_SIG_UNKNOWN.
>>
>> Now that the board reports its state, we expose a bug whereby the
>> transition from UNKNOWN to LOST causes us to release all VC's.
>>
>> We don't delete any VC's, but instead just send an indication of
>> carrier change.
>>
>> Signed-off-by: Philip A Prindeville <philipp@redfish-solutions.com>
>> ---
>>
>> --- a/drivers/atm/solos-pci.c 2011-03-20 15:27:40.000000000 -0600
>> +++ b/drivers/atm/solos-pci.c 2011-03-20 16:32:11.000000000 -0600
>> @@ -382,8 +382,10 @@ static int process_status(struct solos_c
>>
>> /* Anything but 'Showtime' is down */
>> if (strcmp(state_str, "Showtime")) {
>> atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
>> +#if 0
>> atm_dev_release_vccs(card->atmdev[port]);
>> +#endif
>
> Either remove it or don't. #if 0 is for people without version control.
Also, this would seem to break those using the older firmware.
^ permalink raw reply
* Re: [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware
From: Ben Hutchings @ 2011-03-21 3:01 UTC (permalink / raw)
To: Philip Prindeville; +Cc: Netdev, linux-atm-general@lists.sourceforge.net
In-Reply-To: <4D86AF4F.5010203@redfish-solutions.com>
On Sun, 2011-03-20 at 18:52 -0700, Philip Prindeville wrote:
> The newest FPGA firmware on the Solos processors correctly signals
> carrier transitions, bitrate, etc.
>
> The driver previously ignored these messages, and the physical state
> was always ATM_PHY_SIG_UNKNOWN.
>
> Now that the board reports its state, we expose a bug whereby the
> transition from UNKNOWN to LOST causes us to release all VC's.
>
> We don't delete any VC's, but instead just send an indication of
> carrier change.
>
> Signed-off-by: Philip A Prindeville <philipp@redfish-solutions.com>
> ---
>
> --- a/drivers/atm/solos-pci.c 2011-03-20 15:27:40.000000000 -0600
> +++ b/drivers/atm/solos-pci.c 2011-03-20 16:32:11.000000000 -0600
> @@ -382,8 +382,10 @@ static int process_status(struct solos_c
>
> /* Anything but 'Showtime' is down */
> if (strcmp(state_str, "Showtime")) {
> atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
> +#if 0
> atm_dev_release_vccs(card->atmdev[port]);
> +#endif
Either remove it or don't. #if 0 is for people without version control.
Ben.
> dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
> return 0;
> }
>
>
> --
> 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
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2011-03-21 2:51 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) The R8169 PHY fix from Eric Dumazet, which I see you've added to
your tree too. :-)
2) NIU driver broken by OF layer changes, fix by eliminating platform
device name conflict.
3) Fix VHOST receive queue locking, from Michael S. Tsirkin.
4) Some gianfar chips are buggy wrt. checksums for certain packet
buffer alignments, fall back to sw checksumming in those cases.
From Alex Dubov.
5) ECONET leaks 4 uninitialized bytes to the network, fix from Vasiliy
Kulikov.
6) Fix blind deref of ethtool_ops->set_sg(), fix from Roger Luethi.
7) ethtool_rxnfc needs syscall compat handling, from Ben Hutchings.
8) VLAN broken over gre tunnels because it does not take
->needed_headroom into account. Fix from Eric Dumazet.
9) Bridging netfilter needs to init IPCB() of skb before injecting
packet into the IP stack, fix from Herbert Xu.
10) ftmac100 has off-by-one error, fix by using resource_size(). Fix
from Dan Carpenter.
11) IPSET fixes from Jozsef Kadlecsik.
12) Netfilter xtables has some reentrancy issues, fix from Eric Dumazet.
13) CLUSTERIP netfilter iptablesm module needs to check user buffer size
more carefully, fix from Vasiliy Kulikov.
Please pull, thanks a lot!
The following changes since commit a44f99c7efdb88fa41128065c9a9445c19894e34:
Merge branch 'trivial' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6 (2011-03-20 18:14:55 -0700)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Alex Dubov (1):
gianfar: Fall back to software tcp/udp checksum on older controllers
Ben Hutchings (1):
ethtool: Compat handling for struct ethtool_rxnfc
Dan Carpenter (1):
ftmac100: use resource_size()
David S. Miller (3):
niu: Rename NIU parent platform device name to fix conflict.
Merge branch 'master' of git://git.kernel.org/.../kaber/nf-2.6
Merge branch 'vhost-net-next' of git://git.kernel.org/.../mst/vhost
Eric Dumazet (3):
vlan: should take into account needed_headroom
r8169: fix a bug in rtl8169_init_phy()
netfilter: xtables: fix reentrancy
Herbert Xu (1):
bridge: Reset IPCB when entering IP stack on NF_FORWARD
Jason Wang (3):
vhost-net: check the support of mergeable buffer outside the receive loop
vhost-net: Unify the code of mergeable and big buffer handling
vhost: lock receive queue, not the socket
Jozsef Kadlecsik (2):
netfilter: ipset: fix address ranges at hash:*port* types
netfilter: ipset: fix checking the type revision at create command
Krishna Kumar (1):
vhost: Cleanup vhost.c and net.c
Michael S. Tsirkin (2):
vhost: copy_from_user -> __copy_from_user
vhost-net: remove unlocked use of receive_queue
Mike Frysinger (1):
headers: use __aligned_xx types for userspace
Nicolas de Pesloüan (1):
bonding: fix a typo in a comment
Roger Luethi (1):
ethtool: __ethtool_set_sg: check for function pointer before using it
Vasiliy Kulikov (2):
econet: 4 byte infoleak to the network
netfilter: ipt_CLUSTERIP: fix buffer overflow
drivers/net/bonding/bond_main.c | 2 +-
drivers/net/ftmac100.c | 2 +-
drivers/net/gianfar.c | 16 ++-
drivers/net/gianfar.h | 1 +
drivers/net/niu.c | 2 +-
drivers/net/r8169.c | 4 +-
drivers/vhost/net.c | 159 ++++--------------------
drivers/vhost/vhost.c | 55 ++++++---
include/linux/ethtool.h | 34 +++++
include/linux/if_ppp.h | 16 ++--
include/linux/netfilter/ipset/ip_set_getport.h | 10 ++
include/linux/netfilter/nfnetlink_log.h | 4 +-
include/linux/netfilter/nfnetlink_queue.h | 4 +-
include/linux/netfilter/xt_connbytes.h | 4 +-
include/linux/netfilter/xt_quota.h | 2 +-
net/8021q/vlan_dev.c | 1 +
net/bridge/br_netfilter.c | 3 +
net/core/ethtool.c | 3 +
net/econet/af_econet.c | 2 +-
net/ipv4/netfilter/ip_tables.c | 4 +-
net/ipv4/netfilter/ipt_CLUSTERIP.c | 5 +-
net/ipv6/netfilter/ip6_tables.c | 4 +-
net/netfilter/ipset/ip_set_core.c | 22 +++-
net/netfilter/ipset/ip_set_hash_ipport.c | 34 ++----
net/netfilter/ipset/ip_set_hash_ipportip.c | 34 ++----
net/netfilter/ipset/ip_set_hash_ipportnet.c | 34 ++----
net/netfilter/ipset/ip_set_hash_netport.c | 30 ++----
net/socket.c | 114 ++++++++++++++++-
28 files changed, 321 insertions(+), 284 deletions(-)
^ permalink raw reply
* Re: [PULL net-2.6] vhost: cleanups and fixes
From: David Miller @ 2011-03-21 2:08 UTC (permalink / raw)
To: mst
Cc: kvm, virtualization, netdev, linux-kernel, eric.dumazet, jasowang,
krkumar2
In-Reply-To: <20110317140403.GA16390@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Thu, 17 Mar 2011 16:04:04 +0200
> The following changes since commit 1fc050a13473348f5c439de2bb41c8e92dba5588:
>
> ipv4: Cache source address in nexthop entries. (2011-03-07 20:54:48 -0800)
>
> are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net-next
>
> Jason Wang (3):
> vhost-net: check the support of mergeable buffer outside the receive loop
> vhost-net: Unify the code of mergeable and big buffer handling
> vhost: lock receive queue, not the socket
>
> Krishna Kumar (1):
> vhost: Cleanup vhost.c and net.c
>
> Michael S. Tsirkin (2):
> vhost: copy_from_user -> __copy_from_user
> vhost-net: remove unlocked use of receive_queue
Pulled, thanks.
^ permalink raw reply
* [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware
From: Philip Prindeville @ 2011-03-21 1:52 UTC (permalink / raw)
To: Netdev; +Cc: linux-atm-general@lists.sourceforge.net
The newest FPGA firmware on the Solos processors correctly signals carrier transitions, bitrate, etc.
The driver previously ignored these messages, and the physical state was always ATM_PHY_SIG_UNKNOWN.
Now that the board reports its state, we expose a bug whereby the transition from UNKNOWN to LOST causes us to release all VC's.
We don't delete any VC's, but instead just send an indication of carrier change.
Signed-off-by: Philip A Prindeville <philipp@redfish-solutions.com>
---
--- a/drivers/atm/solos-pci.c 2011-03-20 15:27:40.000000000 -0600
+++ b/drivers/atm/solos-pci.c 2011-03-20 16:32:11.000000000 -0600
@@ -382,8 +382,10 @@ static int process_status(struct solos_c
/* Anything but 'Showtime' is down */
if (strcmp(state_str, "Showtime")) {
atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
+#if 0
atm_dev_release_vccs(card->atmdev[port]);
+#endif
dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
return 0;
}
^ permalink raw reply
* [PATCH] irda: validate peer name and attribute lengths
From: Dan Rosenberg @ 2011-03-21 1:32 UTC (permalink / raw)
To: Samuel Ortiz, David S. Miller; +Cc: netdev, security
Length fields provided by a peer for names and attributes may be longer
than the destination array sizes. Validate lengths to prevent stack
buffer overflows.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: stable@kernel.org
---
net/irda/iriap.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/irda/iriap.c b/net/irda/iriap.c
index 5b743bd..3647753 100644
--- a/net/irda/iriap.c
+++ b/net/irda/iriap.c
@@ -656,10 +656,16 @@ static void iriap_getvaluebyclass_indication(struct iriap_cb *self,
n = 1;
name_len = fp[n++];
+
+ IRDA_ASSERT(name_len < IAS_MAX_CLASSNAME + 1, return;);
+
memcpy(name, fp+n, name_len); n+=name_len;
name[name_len] = '\0';
attr_len = fp[n++];
+
+ IRDA_ASSERT(attr_len < IAS_MAX_ATTRIBNAME + 1, return;);
+
memcpy(attr, fp+n, attr_len); n+=attr_len;
attr[attr_len] = '\0';
^ permalink raw reply related
* Re: [PATCH 1/2] socket: increase default maximum listen queue length
From: David Miller @ 2011-03-21 0:18 UTC (permalink / raw)
To: hagen; +Cc: netdev, eric.dumazet
In-Reply-To: <20110320235253.GD3038@nuttenaction>
From: Hagen Paul Pfeifer <hagen@jauu.net>
Date: Mon, 21 Mar 2011 00:52:53 +0100
> The number is somewhat magically - like many other values. I greped
> tglx/history.git but the comment (at that time tcp_ipv4.c) seems pre 2002 era.
Then don't use that number as part of the justification for the
change.
Describe what matters, and only what matters. Providing magic and
arbitrary numbers doesn't help people reading your commit message.
^ 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