* Re: [RFC patch net-next-2.6] net: allow multiple rx_handler registration
From: Jiri Pirko @ 2011-07-01 5:45 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: netdev, davem, shemminger, kaber, fubar, eric.dumazet, andy,
Ben Greear
In-Reply-To: <4E0CD39C.8060209@gmail.com>
Thu, Jun 30, 2011 at 09:50:52PM CEST, nicolas.2p.debian@gmail.com wrote:
>Le 30/06/2011 17:16, Jiri Pirko a écrit :
>>For some net topos it is necessary to have multiple "soft-net-devices"
>>hooked on one netdev. For example very common is to have
>>eth<->(br+vlan). Vlan is not using rh_handler (yet) but also for example
>>macvlan would be useful to have hooked on same netdev as br.
>>
>>This patch introduces rx_handler list. size struct net_device stays
>>intact. Measured performance regression on eth-br topo is ~1% (on received
>>pkts generated by pktgen) and on eth-bond topo it is ~0.25%
>>
>>On br I think that the performance can be brought back maybe by using per-cpu
>>variables to store port in rx_path (I must check this)
>>
>>Please comment.
>>
>>Signed-off-by: Jiri Pirko<jpirko@redhat.com>
>
>I like the idea of this patch.
>
>I didn't take time for a technical review yet, but I'm not sure
>ordering should be static, depending on the kind of device (bond, br,
>macvlan). Ordering is currently static, because it is hard coded.
>
>I think rx_handler_prio should be exposed to userspace, to allow user
>setup to decide the exact order. Default order should be safe, but
>user should be allowed to force a different order for special setups.
Hmm I didn't think about this. Not sure about the right way how to expose
this.
>
> Nicolas.
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Alexey Zaytsev @ 2011-07-01 6:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, Gary Zambrano, bugme-daemon
In-Reply-To: <20110629145135.5179fb0c.akpm@linux-foundation.org>
On Thu, Jun 30, 2011 at 01:51, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Thu, 23 Jun 2011 17:33:54 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=38102
>>
>> Summary: BUG kmalloc-2048: Poison overwritten
>> Product: Drivers
>> Version: 2.5
>> Kernel Version: 3.0.0-rc4
>
> Looks like a 2.6.38->2.6.39 regression, perhaps a memory scribble in b44.
Actually, not sure about the version. 39 was the first one I've been
using in the scenario. Checking older versions now.
And git-log does not show a lot of changes to the b44 driver, so it
might be something unrelated.
^ permalink raw reply
* Re: [RFC patch net-next-2.6] net: allow multiple rx_handler registration
From: Michał Mirosław @ 2011-07-01 6:36 UTC (permalink / raw)
To: Jiri Pirko
Cc: Stephen Hemminger, netdev, davem, kaber, fubar, eric.dumazet,
nicolas.2p.debian, andy
In-Reply-To: <20110630172257.GB2056@minipsycho>
2011/6/30 Jiri Pirko <jpirko@redhat.com>:
> Thu, Jun 30, 2011 at 06:27:12PM CEST, shemminger@vyatta.com wrote:
>>On Thu, 30 Jun 2011 17:16:49 +0200
>>Jiri Pirko <jpirko@redhat.com> wrote:
>>
>>> For some net topos it is necessary to have multiple "soft-net-devices"
>>> hooked on one netdev. For example very common is to have
>>> eth<->(br+vlan). Vlan is not using rh_handler (yet) but also for example
>>> macvlan would be useful to have hooked on same netdev as br.
>>>
>>> This patch introduces rx_handler list. size struct net_device stays
>>> intact. Measured performance regression on eth-br topo is ~1% (on received
>>> pkts generated by pktgen) and on eth-bond topo it is ~0.25%
>>>
>>> On br I think that the performance can be brought back maybe by using per-cpu
>>> variables to store port in rx_path (I must check this)
>>>
>>> Please comment.
>>>
>>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>>
>>I am ok with the infrastructure, but why should Vlan use rh_handle.
>
> Well why it shoudln't. It would fit into what rx_handler is here for - the
> code would be more unified. Also net_device struct would lose struct
> vlan_group __rcu *vlgrp pointer (and reducing net_device size is always
> good thing).
>
>>It is wrong to allow macvlan and bridge to share same device.
>>Right now the code blocks users from doing lots of stupid things.
>
> Right, this is since rx_handler was introduced. Before that all these
> stupid configs were allowed. It's possible easily to forbid unwanted
> configs by checking priv flags.
We could introduce a catch-all macvlan/vlan device that would take
addresses/VLANs which are not covered by other configured
macvlans/vlans. This would allow clearer configuration and would make
the evaluation order explicit. As a bonus, this will give another
device to put tcpdump on. ;-)
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH] can: remove useless defaults in Kconfig
From: David Miller @ 2011-07-01 6:54 UTC (permalink / raw)
To: kurt.van.dijck-/BeEPy95v10
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110627150013.GB1874-MxZ6Iy/zr/UdbCeoMzGj59i2O/JbrIOy@public.gmane.org>
From: Kurt Van Dijck <kurt.van.dijck-/BeEPy95v10@public.gmane.org>
Date: Mon, 27 Jun 2011 17:00:13 +0200
> There's no need for "default N' (or 'default n') as it's default.
>
> Signed-off-by: Kurt Van Dijck <kurt.van.dijck-/BeEPy95v10@public.gmane.org>
> Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] Exclude duplicated checking for iface-up. This flags is checked in 'is_skb_forwardable' function, which is subroutine of 'dev_forward_skb'.
From: David Miller @ 2011-07-01 6:55 UTC (permalink / raw)
To: alex.bluesman.smirnov; +Cc: netdev
In-Reply-To: <1309267844-29334-1-git-send-email-alex.bluesman.smirnov@gmail.com>
From: alex.bluesman.smirnov@gmail.com
Date: Tue, 28 Jun 2011 17:30:44 +0400
> From: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
>
> Signed-off-by: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
Applied.
Please put the verbose patch description in the body of your
email message, right before the signoffs, not in the subject.
The subject provides a "summary" not the entire description.
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] jme: Fix compile warning introduced by new pm macro
From: David Miller @ 2011-07-01 6:54 UTC (permalink / raw)
To: cooldavid; +Cc: netdev, arieslee, devinchiu
In-Reply-To: <1309238615-25590-1-git-send-email-cooldavid@cooldavid.org>
From: "Guo-Fu Tseng" <cooldavid@cooldavid.org>
Date: Tue, 28 Jun 2011 13:23:34 +0800
> From: Guo-Fu Tseng <cooldavid@cooldavid.org>
>
> SIMPLE_DEV_PM_OPS is using SET_SYSTEM_SLEEP_PM_OPS
> and SET_SYSTEM_SLEEP_PM_OPS is empty when CONFIG_PM_SLEEP
> is not defined.
>
> Switching #ifdef CONFIG_PM to #ifdef CONFIG_PM_SLEEP
>
> Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
Applied
^ permalink raw reply
* Re: [PATCH net-next-2.6] jme: Cleanup PM operations after using new PM API
From: David Miller @ 2011-07-01 6:55 UTC (permalink / raw)
To: cooldavid; +Cc: netdev, arieslee, devinchiu
In-Reply-To: <1309261110-11883-1-git-send-email-cooldavid@cooldavid.org>
From: "Guo-Fu Tseng" <cooldavid@cooldavid.org>
Date: Tue, 28 Jun 2011 19:38:30 +0800
> From: Guo-Fu Tseng <cooldavid@cooldavid.org>
>
> 1. Using enum name instead of numeric value.
> 2. device_set_wakeup_enable expect bool argument
> adding !!() to the argument to be passed.
> 3. Remove non-jme-hardware related operations from
> jme_clear_pm()
> 4. Reuse jme_clear_pm() in jme_resume() and jme_powersave_phy()
>
> Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: depca: Omit check for multicast bit in netdev_for_each_mc_addr
From: David Miller @ 2011-07-01 6:56 UTC (permalink / raw)
To: tklauser; +Cc: netdev
In-Reply-To: <1309349715-1604-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Wed, 29 Jun 2011 14:15:15 +0200
> There is no need to check for the address being a multicast address in
> the netdev_for_each_mc_addr loop, so remove it.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: iseries_veth: Omit check for multicast bit in netdev_for_each_mc_addr
From: David Miller @ 2011-07-01 6:57 UTC (permalink / raw)
To: tklauser; +Cc: netdev
In-Reply-To: <1309349735-1690-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Wed, 29 Jun 2011 14:15:35 +0200
> There is no need to check for the address being a multicast address in
> the netdev_for_each_mc_addr loop, so remove it.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: de4x5: Omit check for multicast bit in netdev_for_each_mc_addr
From: David Miller @ 2011-07-01 6:57 UTC (permalink / raw)
To: tklauser; +Cc: grundler, netdev
In-Reply-To: <1309349760-1776-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Wed, 29 Jun 2011 14:16:00 +0200
> There is no need to check for the address being a multicast address in
> the netdev_for_each_mc_addr loop, so remove it.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Please build test your patches!
> @@ -1954,7 +1954,6 @@ SetMulticastFilter(struct net_device *dev)
> u16 hashcode;
> u32 omr, crc;
> char *pa;
> - unsigned char *addrs;
>
> omr = inl(DE4X5_OMR);
> omr &= ~(OMR_PR | OMR_PM);
You removed this local variable 'addrs' but you did not remove
all uses of that variable, so the build will fail.
^ permalink raw reply
* Re: [PATCHv2 NEXT 1/2] net: add external loopback test in ethtool self test
From: David Miller @ 2011-07-01 6:58 UTC (permalink / raw)
To: amit.salecha; +Cc: bhutchings, netdev, ameen.rahman, sucheta.chakraborty
In-Reply-To: <1309413650-15952-2-git-send-email-amit.salecha@qlogic.com>
From: amit.salecha@qlogic.com
Date: Wed, 29 Jun 2011 23:00:49 -0700
> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
>
> External loopback test can be performed by application without any driver
> support on normal Ethernet cards.
> But on CNA devices, where multiple functions share same physical port.
> Here internal loopback test and external loopback test can be initiated by
> multiple functions at same time. To co exist all functions, firmware need
> to regulate what test can be run by which function. So before performing external
> loopback test, command need to send to firmware, which will quiescent other functions.
>
> User may not want to run external loopback test always. As special cable need to be
> connected for this test.
> So adding explicit flag in ethtool self test, which will specify interface
> to perform external loopback test.
> ETH_TEST_FL_EXTERNAL_LB: Application set to request external loopback test
> ETH_TEST_FL_EXTERNAL_LB_DONE: Driver ack if test performed
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCHv2 NEXT 2/2] qlcnic: add external loopback support
From: David Miller @ 2011-07-01 6:58 UTC (permalink / raw)
To: amit.salecha; +Cc: bhutchings, netdev, ameen.rahman, sucheta.chakraborty
In-Reply-To: <1309413650-15952-3-git-send-email-amit.salecha@qlogic.com>
From: amit.salecha@qlogic.com
Date: Wed, 29 Jun 2011 23:00:50 -0700
> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
>
> o Add external loopback test in self test:
> - Send set external loopback mode request to fw.
> To quiscent other storage functions.
> - Perform test
> - Send unset loopback mode request to fw.
>
> o Rename ilb to lb.
> o Update driver version 5.0.20.
>
> Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: am79c961a: Omit check for multicast bit in netdev_for_each_mc_addr
From: David Miller @ 2011-07-01 6:56 UTC (permalink / raw)
To: tklauser; +Cc: linux, linux-arm-kernel, netdev
In-Reply-To: <1309349686-1506-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Wed, 29 Jun 2011 14:14:46 +0200
> There is no need to check for the address being a multicast address in
> the netdev_for_each_mc_addr loop, so remove it.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 0/3] be2net fixes
From: David Miller @ 2011-07-01 6:59 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <1309426301-15783-1-git-send-email-sathya.perla@emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Thu, 30 Jun 2011 15:01:41 +0530
> Pls apply.
>
> Sathya Perla (3):
> be2net: fix certain cmd failure logging
> be2net: create/destroy rx-queues on interface open/close
> be2net: clear intr bit in be_probe()
Applied, but I had to fix up many whitespace problems.
Some of your lines began with mixes of spaces and tabs.
Some of your lines had trailing whitespace.
^ permalink raw reply
* Re: [PATCH net-next] net: ucc_geth: Omit check for multicast bit in netdev_for_each_mc_addr
From: David Miller @ 2011-07-01 6:57 UTC (permalink / raw)
To: tklauser; +Cc: leoli, netdev, linuxppc-dev
In-Reply-To: <1309349793-1864-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Wed, 29 Jun 2011 14:16:33 +0200
> There is no need to check for the address being a multicast address in
> the netdev_for_each_mc_addr loop, so remove it.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] netpoll: Trivial updates
From: David Miller @ 2011-07-01 7:06 UTC (permalink / raw)
To: amwang; +Cc: joe, linux-kernel, netdev
In-Reply-To: <4E0D43C3.5090502@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Fri, 01 Jul 2011 11:49:23 +0800
> 于 2011年07月01日 11:35, Joe Perches 写道:
>>
>>> BTW, you can kill the export of netpoll_send_skb_on_dev() too.
>>
>> Not too sure about that.
>>
>> It's used in netpoll.h by netpoll_send_skb.
>> It could be called from anywhere.
>> It's currently called/used by bonding.h.
>
> % git grep netpoll_send_skb_on_dev .
> include/linux/netpoll.h:void netpoll_send_skb_on_dev(struct netpoll
> *np, struct sk_buff *skb,
> include/linux/netpoll.h: netpoll_send_skb_on_dev(np, skb, np->dev);
> net/core/netpoll.c:void netpoll_send_skb_on_dev(struct netpoll *np,
> struct sk_buff *skb,
> net/core/netpoll.c:EXPORT_SYMBOL(netpoll_send_skb_on_dev);
>
> No modules use it...
Right, this is a relic that bonding was using at one point
in the past but it no longer does.
^ permalink raw reply
* Re: [PATCH net-next] net: de4x5: Omit check for multicast bit in netdev_for_each_mc_addr
From: David Miller @ 2011-07-01 7:31 UTC (permalink / raw)
To: tklauser; +Cc: grundler, netdev
In-Reply-To: <20110701072533.GY28247@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Fri, 1 Jul 2011 09:25:33 +0200
> On 2011-07-01 at 08:57:30 +0200, David Miller <davem@davemloft.net> wrote:
>> From: Tobias Klauser <tklauser@distanz.ch>
>> Date: Wed, 29 Jun 2011 14:16:00 +0200
>>
>> > There is no need to check for the address being a multicast address in
>> > the netdev_for_each_mc_addr loop, so remove it.
>> >
>> > Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
>>
>> Please build test your patches!
>
> Sorry for the mess. Here's an updated patch, not removing the addrs
> local variable.
>
> There is no need to check for the address being a multicast address in
> the netdev_for_each_mc_addr loop, so remove it.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Do not mix patch submissions into existing discussions.
Please, instead, make a new fresh patch submission.
Otherwise I have to do a lot of work editing your commit
log messages and the headers.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: de4x5: Omit check for multicast bit in netdev_for_each_mc_addr
From: Tobias Klauser @ 2011-07-01 7:25 UTC (permalink / raw)
To: David Miller; +Cc: grundler, netdev
In-Reply-To: <20110630.235730.726339338074212677.davem@davemloft.net>
On 2011-07-01 at 08:57:30 +0200, David Miller <davem@davemloft.net> wrote:
> From: Tobias Klauser <tklauser@distanz.ch>
> Date: Wed, 29 Jun 2011 14:16:00 +0200
>
> > There is no need to check for the address being a multicast address in
> > the netdev_for_each_mc_addr loop, so remove it.
> >
> > Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
>
> Please build test your patches!
Sorry for the mess. Here's an updated patch, not removing the addrs
local variable.
There is no need to check for the address being a multicast address in
the netdev_for_each_mc_addr loop, so remove it.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/tulip/de4x5.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tulip/de4x5.c b/drivers/net/tulip/de4x5.c
index efaa1d6..d8db2b6 100644
--- a/drivers/net/tulip/de4x5.c
+++ b/drivers/net/tulip/de4x5.c
@@ -1964,9 +1964,7 @@ SetMulticastFilter(struct net_device *dev)
omr |= OMR_PM; /* Pass all multicasts */
} else if (lp->setup_f == HASH_PERF) { /* Hash Filtering */
netdev_for_each_mc_addr(ha, dev) {
- addrs = ha->addr;
- if ((*addrs & 0x01) == 1) { /* multicast address? */
- crc = ether_crc_le(ETH_ALEN, addrs);
+ crc = ether_crc_le(ETH_ALEN, ha->addr);
hashcode = crc & HASH_BITS; /* hashcode is 9 LSb of CRC */
byte = hashcode >> 3; /* bit[3-8] -> byte in filter */
@@ -1977,7 +1975,6 @@ SetMulticastFilter(struct net_device *dev)
byte -= 1;
}
lp->setup_frame[byte] |= bit;
- }
}
} else { /* Perfect filtering */
netdev_for_each_mc_addr(ha, dev) {
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next v2] net: de4x5: Omit check for multicast bit in netdev_for_each_mc_addr
From: Tobias Klauser @ 2011-07-01 7:37 UTC (permalink / raw)
To: David S. Miller, Grant Grundler; +Cc: netdev
In-Reply-To: <1309349760-1776-1-git-send-email-tklauser@distanz.ch>
There is no need to check for the address being a multicast address in
the netdev_for_each_mc_addr loop, so remove it.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/tulip/de4x5.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tulip/de4x5.c b/drivers/net/tulip/de4x5.c
index efaa1d6..d8db2b6 100644
--- a/drivers/net/tulip/de4x5.c
+++ b/drivers/net/tulip/de4x5.c
@@ -1964,9 +1964,7 @@ SetMulticastFilter(struct net_device *dev)
omr |= OMR_PM; /* Pass all multicasts */
} else if (lp->setup_f == HASH_PERF) { /* Hash Filtering */
netdev_for_each_mc_addr(ha, dev) {
- addrs = ha->addr;
- if ((*addrs & 0x01) == 1) { /* multicast address? */
- crc = ether_crc_le(ETH_ALEN, addrs);
+ crc = ether_crc_le(ETH_ALEN, ha->addr);
hashcode = crc & HASH_BITS; /* hashcode is 9 LSb of CRC */
byte = hashcode >> 3; /* bit[3-8] -> byte in filter */
@@ -1977,7 +1975,6 @@ SetMulticastFilter(struct net_device *dev)
byte -= 1;
}
lp->setup_frame[byte] |= bit;
- }
}
} else { /* Perfect filtering */
netdev_for_each_mc_addr(ha, dev) {
--
1.7.5.4
^ permalink raw reply related
* Re: IEEE 802.1ag / 802.1x / Y1731
From: Satendra... @ 2011-07-01 8:16 UTC (permalink / raw)
To: netdev
In-Reply-To: <BANLkTingLv9XxLqU7nQSct8wqhyvkq=LqA@mail.gmail.com>
Hello All,
Could anyone please tell me whether there is any support in Linux
networking stack
for 802.1ag ? If yes please mention the linux version.
What I need to do is to use CFM OAM (802.1ag) open source client on
our routers running linux
on them. Open source client to be used is dot1ag utils.
Thanks,
Satendra
On 24 June 2011 17:36, Satendra... <satendra.pratap@gmail.com> wrote:
> Hi,
> Could someone please tell me which version of linux has got support
> for below (all three) protocols:
> - IEEE 802.1ag
> - 802.1x
> - Y1731
>
> Thanks,
> Satendra
>
^ permalink raw reply
* HELLO
From: Zainur Binta Zakaria @ 2011-07-01 6:12 UTC (permalink / raw)
Zainur Binta Zakaria Advocate & solicitor
No. 18 & 20 1st Floor
Jalan Kampung Nyabor
96000 Sibu,Malaysia
Dear Friend,
I am Barrister Zainur Bin Zakaria, an attorney at law. A deceased client of
mine, that shares the same last name as yours, died as a result of His heart
condition, due to the death of all the members of his family in the tsunami
disaster on the 26th December 2004 in Sumatra Indonesia. As reported by
http://en.wikipedia.org/wiki/2004_Indian_Ocean_earthquake.
I have contacted you to assist in distributing the money left behind by my
client before it is confiscated or declared unserviceable by the bank where this
deposit valued at Five Million, Six Hundred Thousand United States Dollars
(US$5.6 Million). This bank has issued me a notice to contact the next of kin,
or the account will be confiscated.
My proposition to you is to seek your consent to present you as the next-of-kin
and beneficiary of my named client, since you have the same last name, so that
the proceeds of this account can be paid to you. Then we can share the amount
on a mutually agreed-upon percentage. All legal documents to back up your claim
as my client's next-of-kin will be provided. All I require is your honest
cooperation to enable us see this transaction through.
This will be executed under a legitimate arrangement that will protect you from
many breach of the law. If this business proposition offends your moral values,
do accept my apology. I must use this opportunity to implore you to exercise the
utmost indulgence to keep this matter extraordinary confidential, whatever your
decision, while I await your prompt response. Please contact me at once to
indicate your interest. I will like you to acknowledge the receipt of this
e-mail as soon as possible via my private Email: zakaria2010@w.cn
And treats with absolute confidentiality and sincerity. I look forward to your
quick reply.
Best regards,
Zainur Bin Zakaria
Attorney at Law
^ permalink raw reply
* Re: Skipping past TCP lost packet in userspace
From: Josh Lehan @ 2011-07-01 8:39 UTC (permalink / raw)
To: Neil Horman
Cc: Josh Lehan, janardhan.iyengar, Janardhan Iyengar, rick.jones2,
Yuchung Cheng, netdev, Bryan Ford
In-Reply-To: <20110630143614.GA4392@shamino.rdu.redhat.com>
On 06/30/2011 07:36 AM, Neil Horman wrote:
> I'll leave the rest of this alone, since its pretty obvious that no one is going
> to break TCP for you, but just so that you're aware, The only reason you have to
That's the fundamental disconnect we've been trying to communicate: TCP
*won't break*. None of the rules of TCP are broken, from the wire's
point of view. The OS merely gets a richer API, from the application's
point of view, to optimize the TCP protocol implementation to serve a
wider variety of needs.
> use the 2-Wire gateway that AT&T provides is because there are no commercially
> available routers that support the uplink interface (which I expect will change
That would be good to give the customer a choice of access devices with
which to get on the network, and let the market device what is best,
instead of AT&T dictating what's allowed. I'm getting deja vu of a
famous legal case from 27 years ago.
> eventually). In the time being, if you want to use a different router, place
> the RG in bridge mode by selecting a host as your DMZ device. That will assign
> the wan address to that connected device via DHCP and allow you to pass whatever
> traffic you want through it. I use it to pass SCTP and IPv6 traffice all the
> time, works great.
Wow, that's news to me, that it allows this.
http://www.ka9q.net/Uverse/
Have the limitations in these documents been addressed? If so, kudos to
AT&T.
Josh Lehan
^ permalink raw reply
* Re: [PATCH net-next v2] net: de4x5: Omit check for multicast bit in netdev_for_each_mc_addr
From: David Miller @ 2011-07-01 8:51 UTC (permalink / raw)
To: tklauser; +Cc: grundler, netdev
In-Reply-To: <1309505872-28090-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Fri, 1 Jul 2011 09:37:52 +0200
> There is no need to check for the address being a multicast address in
> the netdev_for_each_mc_addr loop, so remove it.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied, thanks.
^ permalink raw reply
* [PATCH] net: sh_eth: remove __flush_purge_region
From: Yoshihiro Shimoda @ 2011-07-01 8:52 UTC (permalink / raw)
To: davem; +Cc: netdev, SH-Linux
It is a function of SuperH architecture. There is no good to use
the function on a driver generally. So, the driver uses
dma_map_single() instead of __flush_purge_region.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/net/sh_eth.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index 8a72a97..09b5aa8 100644
--- a/drivers/net/sh_eth.c
+++ b/drivers/net/sh_eth.c
@@ -33,7 +33,6 @@
#include <linux/pm_runtime.h>
#include <linux/slab.h>
#include <linux/ethtool.h>
-#include <asm/cacheflush.h>
#include "sh_eth.h"
@@ -864,6 +863,8 @@ static int sh_eth_txfree(struct net_device *ndev)
break;
/* Free the original skb. */
if (mdp->tx_skbuff[entry]) {
+ dma_unmap_single(&ndev->dev, txdesc->addr,
+ txdesc->buffer_length, DMA_TO_DEVICE);
dev_kfree_skb_irq(mdp->tx_skbuff[entry]);
mdp->tx_skbuff[entry] = NULL;
freeNum++;
@@ -1487,13 +1488,12 @@ static int sh_eth_start_xmit(struct sk_buff *skb, struct net_device *ndev)
entry = mdp->cur_tx % TX_RING_SIZE;
mdp->tx_skbuff[entry] = skb;
txdesc = &mdp->tx_ring[entry];
- txdesc->addr = virt_to_phys(skb->data);
/* soft swap. */
if (!mdp->cd->hw_swap)
sh_eth_soft_swap(phys_to_virt(ALIGN(txdesc->addr, 4)),
skb->len + 2);
- /* write back */
- __flush_purge_region(skb->data, skb->len);
+ txdesc->addr = dma_map_single(&ndev->dev, skb->data, skb->len,
+ DMA_TO_DEVICE);
if (skb->len < ETHERSMALL)
txdesc->buffer_length = ETHERSMALL;
else
--
1.7.1
^ permalink raw reply related
* Re: pull request: wireless-2.6 2011-06-30
From: David Miller @ 2011-07-01 8:52 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20110630173223.GA12963@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 30 Jun 2011 13:32:25 -0400
> Here is a batch of fixes intended for 3.0. Arik gives us a fix for a
> potential NULL dereference in mac80211. Emmanuel gives us a fix for a
> regression introduced by "iwlagn: support multiple TBs per command" that
> can corrupt memory. Eugene (and Bob) gives a memory leak fix for ath5k.
> Evgeni gives us a preprocessor-related fix that makes modinfo output
> make more sense for iwlagn. Johannes gives us a trio of fixes, all
> isolated to the bowels of iwlagn. I overlayed a fixup on top of one of
> Johannes's patches, since there was some confusion between DMA and PCI
> API usage. Finally, Rajkumar gives us an ath9k fix to ensure the chip
> is properly awakened even if there is no active interface when the
> resume occurs.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ 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