* Re: [PATCH] f_phonet: use page-sized rather than MTU-sized RX buffers
From: David Miller @ 2009-08-13 5:15 UTC (permalink / raw)
To: remi.denis-courmont; +Cc: netdev
In-Reply-To: <1249631804-7438-2-git-send-email-remi.denis-courmont@nokia.com>
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Date: Fri, 7 Aug 2009 10:56:44 +0300
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> Instead of a large (physically) linear buffer, we generate a set of
> paged sk_buff, so no extra memory copy is involved. This removes
> high-order allocations and saves quite a bit of memory. Phonet MTU is
> 65541 bytes, so the two buffers were padded to 128 kilo-bytes each.
> Now, we create 17 page buffers, almost a 75% memory use reduction.
>
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied.
^ permalink raw reply
* Re: [PATCH] f_phonet: lock-less MTU change
From: David Miller @ 2009-08-13 5:15 UTC (permalink / raw)
To: remi.denis-courmont; +Cc: netdev
In-Reply-To: <1249631804-7438-1-git-send-email-remi.denis-courmont@nokia.com>
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Date: Fri, 7 Aug 2009 10:56:43 +0300
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> With the current driver, the MTU is purely indicative, so there is no
> need to synchronize with the receive path.
>
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/3] net: Add ftracer to help optimize process scheduling based on incomming frame allocations
From: David Miller @ 2009-08-13 5:15 UTC (permalink / raw)
To: nhorman; +Cc: netdev, rostedt
In-Reply-To: <20090807202130.GA26677@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 7 Aug 2009 16:21:30 -0400
> Tested by me, working well, applies against the head of the net-next tree
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
For some reason they don't apply cleanly to net-next-2.6, probably
because of the net-2.6 merge I did recently.
Neil, could you please respin, and also could you please not
use the same subject line for all 3 patches? That becomes the
commit message header, and it should be unique for each patch
since each patch does something different. :)
^ permalink raw reply
* Re: [PATCH] net: include/linux/icmpv6: includecheck fix for icmpv6.h
From: David Miller @ 2009-08-13 5:14 UTC (permalink / raw)
To: jaswinder; +Cc: netdev
In-Reply-To: <1249824438.2957.10.camel@ht.satnam>
From: Jaswinder Singh Rajput <jaswinder@kernel.org>
Date: Sun, 09 Aug 2009 18:57:18 +0530
>
> fix the following 'make includecheck' warning:
>
> include/linux/icmpv6.h: linux/skbuff.h is included more than once.
>
> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: smc911x: includecheck fix for smc911x.h
From: David Miller @ 2009-08-13 5:13 UTC (permalink / raw)
To: jaswinder; +Cc: nico, netdev, dustin
In-Reply-To: <1249823558.2957.8.camel@ht.satnam>
From: Jaswinder Singh Rajput <jaswinder@kernel.org>
Date: Sun, 09 Aug 2009 18:42:38 +0530
>
> fix the following 'make includecheck' warning:
>
> drivers/net/smc911x.h: mach/dma.h is included more than once.
>
> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6] can: Use WARN_ONCE() instead of BUG_ON() for sanity check in receive path
From: David Miller @ 2009-08-13 5:01 UTC (permalink / raw)
To: oliver; +Cc: urs, l.fu, m.olbrich, netdev
In-Reply-To: <4A80040D.3030009@hartkopp.net>
From: Oliver Hartkopp <oliver@hartkopp.net>
Date: Mon, 10 Aug 2009 13:27:09 +0200
> Additionally it changes the return values to the common NET_RX_xxx constants.
Don't munge unrelated changes together like this, split it up.
Also, this is not net-2.6 material, I will only apply these changes
to net-next-2.6 at this point.
Thanks.
^ permalink raw reply
* Re: [PATCH] e1000e: fix use of pci_enable_pcie_error_reporting
From: Jeff Kirsher @ 2009-08-13 4:54 UTC (permalink / raw)
To: Xiaotian Feng
Cc: john.ronciak, peter.p.waskiewicz.jr, bruce.w.allan,
jesse.brandeburg, davem, e1000-devel, netdev, linux-kernel
In-Reply-To: <1249637774-32419-1-git-send-email-dfeng@redhat.com>
On Fri, Aug 7, 2009 at 02:36, Xiaotian Feng<dfeng@redhat.com> wrote:
> commit 111b9dc5 introduces pcie aer support for e1000e, but it is not
> reasonable to disable it in e1000_remove but enable it in e1000_resume.
> This patch enables aer support in e1000_probe.
>
> Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
> ---
> drivers/net/e1000e/netdev.c | 16 ++++++++--------
> 1 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
> index 63415bb..e2f0304 100644
> --- a/drivers/net/e1000e/netdev.c
> +++ b/drivers/net/e1000e/netdev.c
> @@ -4670,14 +4670,6 @@ static int e1000_resume(struct pci_dev *pdev)
> return err;
> }
>
> - /* AER (Advanced Error Reporting) hooks */
> - err = pci_enable_pcie_error_reporting(pdev);
> - if (err) {
> - dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
> - "0x%x\n", err);
> - /* non-fatal, continue */
> - }
> -
> pci_set_master(pdev);
>
> pci_enable_wake(pdev, PCI_D3hot, 0);
> @@ -4990,6 +4982,14 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
> if (err)
> goto err_pci_reg;
>
> + /* AER (Advanced Error Reporting) hooks */
> + err = pci_enable_pcie_error_reporting(pdev);
> + if (err) {
> + dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
> + "0x%x\n", err);
> + /* non-fatal, continue */
> + }
> +
> pci_set_master(pdev);
> /* PCI config space info */
> err = pci_save_state(pdev);
> --
> 1.6.2.5
>
> --
I have added this to my tree for testing. Sorry I did not respond earlier.
Dave - I will make sure that the tabs/whitespace is correct.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH] e1000e: fix use of pci_enable_pcie_error_reporting
From: Danny Feng @ 2009-08-13 4:29 UTC (permalink / raw)
To: David Miller
Cc: e1000-devel, netdev, bruce.w.allan, jesse.brandeburg,
linux-kernel, john.ronciak, jeffrey.t.kirsher
In-Reply-To: <20090812.204621.87530668.davem@davemloft.net>
On 08/13/2009 11:46 AM, David Miller wrote:
> From: Xiaotian Feng<dfeng@redhat.com>
> Date: Fri, 7 Aug 2009 17:36:14 +0800
>
>> commit 111b9dc5 introduces pcie aer support for e1000e, but it is not
>> reasonable to disable it in e1000_remove but enable it in e1000_resume.
>> This patch enables aer support in e1000_probe.
>>
>> Signed-off-by: Xiaotian Feng<dfeng@redhat.com>
>
> In moving this block of code, you've corrupted the indentation,
> making it more indented than it should be.
>
> In any event, I expect the Intel folks to pick this up.
Yes, I agree.... but each time I resume from suspend or rmmod e1000e,
there's a warning message like "pci_enable_pcie_error_reporting failed
0xfffffffb". Since some devices may not support aer, why not silence
this kind of warning?
modprobe e1000e everything is as usual, but then rmmod e1000e, we'll see
"pci_disable_pcie_error_reporting failed 0xfffffffb", it is so weird...
>
>> diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
>> index 63415bb..e2f0304 100644
>> --- a/drivers/net/e1000e/netdev.c
>> +++ b/drivers/net/e1000e/netdev.c
>> @@ -4670,14 +4670,6 @@ static int e1000_resume(struct pci_dev *pdev)
>> return err;
>> }
>>
>> - /* AER (Advanced Error Reporting) hooks */
>> - err = pci_enable_pcie_error_reporting(pdev);
>> - if (err) {
>> - dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
>> - "0x%x\n", err);
>> - /* non-fatal, continue */
>> - }
>> -
>> pci_set_master(pdev);
>>
>> pci_enable_wake(pdev, PCI_D3hot, 0);
>> @@ -4990,6 +4982,14 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
>> if (err)
>> goto err_pci_reg;
>>
>> + /* AER (Advanced Error Reporting) hooks */
>> + err = pci_enable_pcie_error_reporting(pdev);
>> + if (err) {
>> + dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
>> + "0x%x\n", err);
>> + /* non-fatal, continue */
>> + }
>> +
>> pci_set_master(pdev);
>> /* PCI config space info */
>> err = pci_save_state(pdev);
>> --
>> 1.6.2.5
>>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* Re: [PATCH] Fix xfrm hash collisions by changing __xfrm4_daddr_saddr_hash to hash addresses with addition
From: Herbert Xu @ 2009-08-13 4:19 UTC (permalink / raw)
To: David Miller; +Cc: joamaki, netdev
In-Reply-To: <20090812.205635.244644770.davem@davemloft.net>
On Wed, Aug 12, 2009 at 08:56:35PM -0700, David Miller wrote:
>
> 2) Whoever creates such a hash collision explosion can be
> precisely identified.
BTW the trust issue goes the other way too. I wouldn't want
to connect to any IPsec peer if I knew that they could render
my gateway unuseable whenever they liked :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] net: pcmcia/axnet_cs: includecheck fix axnet_cs.c
From: David Miller @ 2009-08-13 4:19 UTC (permalink / raw)
To: jaswinder; +Cc: netdev, dahinds
In-Reply-To: <1249823125.2957.6.camel@ht.satnam>
From: Jaswinder Singh Rajput <jaswinder@kernel.org>
Date: Sun, 09 Aug 2009 18:35:25 +0530
>
> fix the following 'make includecheck' warning:
>
> drivers/net/pcmcia/axnet_cs.c: linux/etherdevice.h is included more than once.
>
> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: cs89x0: includecheck fix for cs89x0.c
From: David Miller @ 2009-08-13 4:19 UTC (permalink / raw)
To: jaswinder; +Cc: netdev, nelson, akpm, mcruse
In-Reply-To: <1249822796.2957.4.camel@ht.satnam>
From: Jaswinder Singh Rajput <jaswinder@kernel.org>
Date: Sun, 09 Aug 2009 18:29:56 +0530
> fix the following 'make includecheck' warning:
>
> drivers/net/cs89x0.c: asm/irq.h is included more than once.
>
> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] drivers/net: Correct use of request_region/request_mem_region
From: David Miller @ 2009-08-13 4:19 UTC (permalink / raw)
To: julia; +Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0908090943210.13271@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Sun, 9 Aug 2009 09:43:42 +0200 (CEST)
> From: Julia Lawall <julia@diku.dk>
>
> request_mem_region should be used with release_mem_region, not request_region.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH] drivres/net: Change constant name
From: David Miller @ 2009-08-13 4:19 UTC (permalink / raw)
To: julia; +Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0908080953090.25176@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Sat, 8 Aug 2009 09:53:41 +0200 (CEST)
> From: Julia Lawall <julia@diku.dk>
>
> In this series of tests the constants have the form XRXMAC_STATUS, except
> in this one case. The values of XRXMAC_STAT_MSK_RXOCTET_CNT_EXP and
> XRXMAC_STATUS_RXOCTET_CNT_EXP are furthermore the same.
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH] drivers/net/tokenring: Use status field rather than state field
From: David Miller @ 2009-08-13 4:19 UTC (permalink / raw)
To: julia; +Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0908080846000.25176@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Sat, 8 Aug 2009 08:47:33 +0200 (CEST)
> From: Julia Lawall <julia@diku.dk>
>
> In general in this file, it is the status field, not the state field, that
> contains values like OPEN and CLOSED. Indeed, in the first error case, it
> is the field status that is initialized. I have thus assumed that all of
> the error handling code should be the same, and moved it to the end of the
> function to emphasize its commonality.
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] myri10ge: improve parity error detection and recovery
From: David Miller @ 2009-08-13 4:18 UTC (permalink / raw)
To: brice; +Cc: netdev
In-Reply-To: <4A7C9226.80401@myri.com>
From: Brice Goglin <brice@myri.com>
Date: Fri, 07 Aug 2009 22:44:22 +0200
> Improve myri10ge parity error detection and recovery:
> 1) Don't restore PCI config space to a rebooted NIC until AFTER the
> host is quiescent.
> 2) Let myri10ge_close() know the NIC is dead, so it won't waste time
> waiting for a dead nic to respond to MXGEFW_CMD_ETHERNET_DOWN
> 3) When the NIC is quiet (link down, or otherwise idle link) use
> a pci config space read to detect a rebooted NIC. Otherwise
> we might never notice that a NIC rebooted
>
> Signed-off-by: Andrew Gallatin <gallatin@myri.com>
> Signed-off-by: Brice Goglin <brice@myri.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] Fix xfrm hash collisions by changing __xfrm4_daddr_saddr_hash to hash addresses with addition
From: David Miller @ 2009-08-13 4:18 UTC (permalink / raw)
To: herbert; +Cc: joamaki, netdev
In-Reply-To: <20090813041115.GA19344@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 13 Aug 2009 14:11:15 +1000
> Some IPsec applications use a policy that spawns one SA per
> src/dst address pair. In that case, even an entity that is
> not on the IPsec side would be able to spawn SAs with the intent
> of causing collisions. It simply needs to send packets through
> the IPsec gateway with the appropriate destination addresses.
Ok, all good points. We need to do something about this.
So probably we need to eat jhash after all.
Resistence is futile, sigh :-)
^ permalink raw reply
* Re: [PATCH] Fix xfrm hash collisions by changing __xfrm4_daddr_saddr_hash to hash addresses with addition
From: Herbert Xu @ 2009-08-13 4:11 UTC (permalink / raw)
To: David Miller; +Cc: joamaki, netdev
In-Reply-To: <20090812.205635.244644770.davem@davemloft.net>
On Wed, Aug 12, 2009 at 08:56:35PM -0700, David Miller wrote:
>
> 1) The client is on your private network, much more serious
> mischief is possible.
Not necessarily as having an IPsec connection does not entail
full access to the network on the other side.
> 2) Whoever creates such a hash collision explosion can be
> precisely identified.
>
> The ikev1 failure case is an interesting situation I hadn't
> considered.
>
> Maybe that can matter, but again the guilty party is easy to identify
> and easy to block via whatever means appropriate.
For corporate networks perhaps. However, in other cases the
peer may be trusted even less. For instance, if IPsec were
used for mobility purposes then you essentially don't know
the client at all.
It's like Facebook. If one user mounts a DoS attack you can
block their account. However, if they can simply come back
with a new account then you need to make sure that the attack
can be mitigated in other ways so that it doesn't bring the
whole thing down.
BTW, this isn't just exposed to IPsec peers. It can also be
exposed to those behind the gateway not using IPsec.
Some IPsec applications use a policy that spawns one SA per
src/dst address pair. In that case, even an entity that is
not on the IPsec side would be able to spawn SAs with the intent
of causing collisions. It simply needs to send packets through
the IPsec gateway with the appropriate destination addresses.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] yellowfin: Fix buffer underrun after dev_alloc_skb() failure
From: David Miller @ 2009-08-13 4:08 UTC (permalink / raw)
To: roel.kluin; +Cc: netdev, akpm
In-Reply-To: <4A7C6B08.1040800@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Fri, 07 Aug 2009 19:57:28 +0200
> When dev_alloc_skb fails in the first iteration, a buffer underrun occurs.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> Is this the best way to fix this? Untested, please review.
I think this is a case where this code is going to need to
be majorly reworked so that you can pass error status up
to the caller when this allocation failure happens, and
the caller can properly act upon it.
Just silently returning when no RX ring has been allocated,
and the TX ring hasn't been setup at all, is going to be
worse than the array overrun you're supposedly fixing.
^ permalink raw reply
* Re: [PATCH] Fix xfrm hash collisions by changing __xfrm4_daddr_saddr_hash to hash addresses with addition
From: David Miller @ 2009-08-13 3:56 UTC (permalink / raw)
To: herbert; +Cc: joamaki, netdev
In-Reply-To: <20090813035310.GA19182@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 13 Aug 2009 13:53:10 +1000
> Take corporate VPN servers for instance. Yes each client is
> trusted to the extent that it is being offered connectivity to
> the corporate network. However, it would not be ideal if one
> rogue client can take down the entire VPN server, especially
> in this case because repeatedly creating identical SAs can often
> occur purely by accident.
1) The client is on your private network, much more serious
mischief is possible.
2) Whoever creates such a hash collision explosion can be
precisely identified.
The ikev1 failure case is an interesting situation I hadn't
considered.
Maybe that can matter, but again the guilty party is easy to identify
and easy to block via whatever means appropriate.
^ permalink raw reply
* Re: [PATCH 09/10] nl802154: support START-CONFIRM primitive
From: David Miller @ 2009-08-13 3:53 UTC (permalink / raw)
To: dbaryshkov; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <20090812.205256.188942819.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 12 Aug 2009 20:52:56 -0700 (PDT)
> From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> Date: Fri, 7 Aug 2009 16:58:44 +0400
>
>> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>
> Applied to net-next-2.6
Patch #10 is applied too, I don't have a copy in my inbox
for some reason to apply explicitly to it, sorry.
^ permalink raw reply
* Re: [PATCH] Fix xfrm hash collisions by changing __xfrm4_daddr_saddr_hash to hash addresses with addition
From: Herbert Xu @ 2009-08-13 3:53 UTC (permalink / raw)
To: David Miller; +Cc: joamaki, netdev
In-Reply-To: <20090812.204247.183387787.davem@davemloft.net>
On Wed, Aug 12, 2009 at 08:42:47PM -0700, David Miller wrote:
>
> Isn't it fruitless to talk about exploiting SA IDs when such things
> are setup using an encrypted negotiation sequence and some level of
> trust?
>
> Just wondering :-)
It's a good question :)
However, IPsec is not always carried out between two parties
that trust each other. In fact, quite often IPsec is used in
a hub and spoke fashion where a central IPsec gateway serves a
number of IPsec clients that may or may not be trustworthy.
Take corporate VPN servers for instance. Yes each client is
trusted to the extent that it is being offered connectivity to
the corporate network. However, it would not be ideal if one
rogue client can take down the entire VPN server, especially
in this case because repeatedly creating identical SAs can often
occur purely by accident.
With IKEv1, it is quite possible for the client to think that
SA negotiation failed while in fact it had been created at the
server's end. In that case the client depending on configuration
may retry indefinitely, causing a large number of identical SAs
to be created at the server end.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 09/10] nl802154: support START-CONFIRM primitive
From: David Miller @ 2009-08-13 3:52 UTC (permalink / raw)
To: dbaryshkov; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-10-git-send-email-dbaryshkov@gmail.com>
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Fri, 7 Aug 2009 16:58:44 +0400
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 08/10] af_ieee802154: add support for WANT_ACK socket option
From: David Miller @ 2009-08-13 3:52 UTC (permalink / raw)
To: dbaryshkov; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-9-git-send-email-dbaryshkov@gmail.com>
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Fri, 7 Aug 2009 16:58:43 +0400
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 07/10] af_ieee802154: minor cleanup in dgram_bind
From: David Miller @ 2009-08-13 3:52 UTC (permalink / raw)
To: dbaryshkov; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-8-git-send-email-dbaryshkov@gmail.com>
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Fri, 7 Aug 2009 16:58:42 +0400
> 1) fix ro->bound protection by socket lock
> 2) make ro->bound bit instead of int
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 06/10] af_ieee802154: provide dummy get/setsockopt
From: David Miller @ 2009-08-13 3:52 UTC (permalink / raw)
To: dbaryshkov; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-7-git-send-email-dbaryshkov@gmail.com>
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Fri, 7 Aug 2009 16:58:41 +0400
> Provide dummt get/setsockopt implementations to stop these
> syscalls from oopsing on our sockets.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
No need for me to apply this, already in the tree.
^ 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