* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Fabio Checconi @ 2011-03-02 2:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Luigi Rizzo, netdev
In-Reply-To: <20110228171738.2cc8c9a0@nehalam>
Hi,
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Mon, Feb 28, 2011 05:17:38PM -0800
>
> This is an implementation of the Quick Fair Queue scheduler developed
> by Fabio Checconi. The same algorithm is already implemented in ipfw
> in FreeBSD. Fabio had an earlier version developed on Linux, I just
> cleaned it up and tested it. All bugs are mine.
>
thanks for posting, I'm pretty sure that bugs are more likely to be
ours than yours :)
During the development of the algorithm we used a simple traffic
simulator to verify (informally) the timestamping and the guarantees
provided. I've tested this version of the code with the simulator and
so far it worked fine, so I think that timestamping and guarantees should
be OK.
Please let us know if we can be of any help,
fabio
^ permalink raw reply
* Re: [PATCH 4/4 V2] net,rcu: don't assume the size of struct rcu_head
From: Eric Dumazet @ 2011-03-02 3:02 UTC (permalink / raw)
To: Lai Jiangshan
Cc: David Miller, mingo, paulmck, cl, penberg, mpm, linux-mm,
linux-kernel, netdev
In-Reply-To: <4D6DAF86.2000407@cn.fujitsu.com>
Le mercredi 02 mars 2011 à 10:46 +0800, Lai Jiangshan a écrit :
> Is it the cause of false sharing? I thought that all are rare write(except __refcnt)
> since it is protected by RCU.
>
> Do you allow me just move the seldom access rcu_head to the end of the structure
> and add pads before __refcnt? I guess it increases about 3% the size of dst_entry.
dst_entry is a base class.
Its included at the beginning of other structs.
Moving rcu_head "at the end" just move it right in the middle of upper
objects as a matter of fact. This might add one cache line miss on
critical network object. A complete audit is needed.
David is doing some changes in this area, so things move fast anyway.
> I accept that I leave this code as is, when I change rcu_head I will
notify you.
>
Thanks
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Eric Dumazet @ 2011-03-02 2:56 UTC (permalink / raw)
To: Herbert Xu
Cc: Thomas Graf, David Miller, rick.jones2, therbert, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <20110302023920.GA16072@gondor.apana.org.au>
Le mercredi 02 mars 2011 à 10:39 +0800, Herbert Xu a écrit :
> UDP is a datagram protocol, TCP is not.
>
> Anyway, here is an alternate proposal. When a TCP socket transmits
> for the first time (SYN or SYN-ACK), we pick a queue based on CPU and
> store it in the socket. From then on we stick to that selection.
>
Many TCP apps I know use one thread to perform listen/accept and a pool
of threads to handle each new conn.
Anyway, the SYN-ACK is generated by softirq, not really user choice.
CPU depends if NIC is RX multiqueue or RPS is setup.
All this discussion is about letting process scheduler decide TX queue,
(because user/admin used cpu affinity) or let network stack drive
scheduler : Please migrate this thread on this cpu.
Both schems should be allowed/configurable so that best results are
available.
> We would only allow changes if we can ensure that all transmitted
> packets have left the queue. Or we just never change it like we
> do now.
>
We do change in case of dst/route change. Each device can have different
number of TX queues.
^ permalink raw reply
* Re: [PATCH] bonding: added 802.3ad round-robin hashing policy and source mac selection mode
From: Jay Vosburgh @ 2011-03-02 2:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Oleg V. Ukhno, netdev, David S. Miller
In-Reply-To: <20110301152951.646451c6@nehalam>
Stephen Hemminger <shemminger@vyatta.com> wrote:
>On Wed, 2 Mar 2011 01:34:58 +0300
>"Oleg V. Ukhno" <olegu@yandex-team.ru> wrote:
>
>> Patch introduces two new (related) features to bonding module.
>> First feature is round-robin hashing policy, which is primarily
>> intended for use with 802.3ad mode, and puts every next IPv4 and
>> IPv6 packet into next availables slave without taling into account
>> which layer3 and above protocol is used.
>> Second feature makes possible choosing which MAC-address will be set
>> in the transmitted packet - when set to src-mac it will force setting
>> slave's interface real MAC address as source MAC address in every
>> packet, sent via this slave interface.
>> Main goal of this patch is to make possible single TCP stream
>> equally striped for both transmitted and received packets over all
>> available slaves.
>> This operating mode is not fully 802.3ad compliant, and will cause
>> some packet reordering in TCP stream, to some kernel tuning may be
>> required.
>> For correct working enabling round-robin hashing policy plus using
>> real slave's MAC addresses as source MAC addresses in transmitted
>> packets requires specific switch setting)hashing mode for port-channel
>> ("etherchannel) should be set to src-mac or src-dst-mac to get
>> correct load-striping on the receiving host's etherchannel.
>> General requirements for using bonding in this operating mode are:
>> - even and preferrably equal number of slaves on sending and receiving
>> hosts;
>> - equal RTT between sending and receiving hosts on all slaves;
>> - switch capable of doing etherchannels and using src-mac or src-dst-mac
>> hashing policy for egress load striping
>>
>> Signed-off-by: Oleg V. Ukhno <olegu@yandex-team.ru>
>
>It seems to me the whole bonding policy is getting so complex
>that the code is a mess. Perhaps it should be somehow linked into
>existing packet classification or firewall mechanisms. This would
>increase the flexibility and reduce the amount of policy code
>in the bonding driver itself.
Hmm.
Yes, the number of special case knobs in bonding is getting
rather large, and there are one or two other proposals in the pipe
besides this one.
It would be handy to be able to do things like run ebtables
style rules against traffic going in and out of the bond. Right now
ebtables is pretty tightly coupled with the bridge, so we'd need to add
a whole new set of netfilter "bondtables" or something. Or add hooks
for ebtables outside of the bridge.
For this particular patch, the src-mac business could be handled
by a netfilter module. The round-robin hash policy part would probably
have to stay in bonding.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH 2/4] slub,rcu: don't assume the size of struct rcu_head
From: Lai Jiangshan @ 2011-03-02 2:55 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Ingo Molnar, Paul E. McKenney, Eric Dumazet,
David S. Miller, Matt Mackall, linux-mm, linux-kernel, netdev
In-Reply-To: <alpine.DEB.2.00.1103010909320.6253@router.home>
On 03/01/2011 11:11 PM, Christoph Lameter wrote:
> On Tue, 1 Mar 2011, Pekka Enberg wrote:
>
>> The SLAB and SLUB patches are fine by me if there are going to be real
>> users for this. Christoph, Paul?
>
> The solution is a bit overkill. It would be much simpler to add a union to
> struct page that has lru and the rcu in there similar things can be done
> for SLAB and the network layer. A similar issue already exists for the
> spinlock in struct page. Lets follow the existing way of handling this.
I don't want to impact the whole system too much to
touch struct page. The solution changes existed things little,
and the reversed data may just make use of the pad data.
>
> Struct page may be larger for debugging purposes already because of the
> need for extended spinlock data.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 4/4 V2] net,rcu: don't assume the size of struct rcu_head
From: Lai Jiangshan @ 2011-03-02 2:46 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, mingo, paulmck, cl, penberg, mpm, linux-mm,
linux-kernel, netdev
In-Reply-To: <1298971213.3284.4.camel@edumazet-laptop>
On 03/01/2011 05:20 PM, Eric Dumazet wrote:
> Le mardi 01 mars 2011 à 16:53 +0800, Lai Jiangshan a écrit :
>> On 03/01/2011 04:16 PM, David Miller wrote:
>>> From: Lai Jiangshan <laijs@cn.fujitsu.com>
>>> Date: Tue, 01 Mar 2011 16:03:44 +0800
>>>
>>>>
>>>> struct dst_entry assumes the size of struct rcu_head as 2 * sizeof(long)
>>>> and manually adds pads for aligning for "__refcnt".
>>>>
>>>> When the size of struct rcu_head is changed, these manual padding
>>>> is wrong. Use __attribute__((aligned (64))) instead.
>>>>
>>>> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>>>
>>> We don't want to use the align if it's going to waste lots of space.
>>>
>>> Instead we want to rearrange the structure so that the alignment comes
>>> more cheaply.
>>
>> Subject: [PATCH 4/4 V2] net,rcu: don't assume the size of struct rcu_head
>>
>> struct dst_entry assumes the size of struct rcu_head as 2 * sizeof(long)
>> and manually adds pads for aligning for "__refcnt".
>>
>> When the size of struct rcu_head is changed, these manual padding
>> are hardly suit for the changes. So we rearrange the structure,
>> and move the seldom access rcu_head to the end of the structure.
>>
>> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>> ---
>>
>> diff --git a/include/net/dst.h b/include/net/dst.h
>> index 93b0310..d8c5296 100644
>> --- a/include/net/dst.h
>> +++ b/include/net/dst.h
>> @@ -37,7 +37,6 @@
>> struct sk_buff;
>>
>> struct dst_entry {
>> - struct rcu_head rcu_head;
>> struct dst_entry *child;
>> struct net_device *dev;
>> short error;
>> @@ -78,6 +77,13 @@ struct dst_entry {
>> __u32 __pad2;
>> #endif
>>
>> + unsigned long lastuse;
>> + union {
>> + struct dst_entry *next;
>> + struct rtable __rcu *rt_next;
>> + struct rt6_info *rt6_next;
>> + struct dn_route __rcu *dn_next;
>> + };
>>
>> /*
>> * Align __refcnt to a 64 bytes alignment
>> @@ -92,13 +98,7 @@ struct dst_entry {
>> */
>> atomic_t __refcnt; /* client references */
>> int __use;
>> - unsigned long lastuse;
>> - union {
>> - struct dst_entry *next;
>> - struct rtable __rcu *rt_next;
>> - struct rt6_info *rt6_next;
>> - struct dn_route __rcu *dn_next;
>> - };
>> + struct rcu_head rcu_head;
>> };
>>
>> #ifdef __KERNEL__
>
> Nope...
>
> "lastuse" and "next" must be in this place, or this introduce false
> sharing we wanted to avoid in the past.
>
> I suggest you leave this code as is, we will address the problem when
> rcu_head changes (assuming we can test a CONFIG_RCU_HEAD_DEBUG or
> something)
>
> First part of "struct dst_entry" is mostly read, while part beginning
> after refcnt is often written.
>
Is it the cause of false sharing? I thought that all are rare write(except __refcnt)
since it is protected by RCU.
Do you allow me just move the seldom access rcu_head to the end of the structure
and add pads before __refcnt? I guess it increases about 3% the size of dst_entry.
I accept that I leave this code as is, when I change rcu_head I will notify you.
Thanks,
Lai
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Herbert Xu @ 2011-03-02 2:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas Graf, David Miller, rick.jones2, therbert, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <1299031203.2930.26.camel@edumazet-laptop>
On Wed, Mar 02, 2011 at 03:00:03AM +0100, Eric Dumazet wrote:
> >
> > Think about it, a TCP socket cannot be used by a multi-threaded app
> > in a scalable way.
>
> Well...
>
> If you think about it, SO_REUSEPORT patch has exactly the same goal :
UDP is a datagram protocol, TCP is not.
Anyway, here is an alternate proposal. When a TCP socket transmits
for the first time (SYN or SYN-ACK), we pick a queue based on CPU and
store it in the socket. From then on we stick to that selection.
We would only allow changes if we can ensure that all transmitted
packets have left the queue. Or we just never change it like we
do now.
For datagram protocols we simply use the current CPU.
> We added RPS and XPS that works correctly if each socket is used by one
> thread. Maybe we need to add an user API or automatically detect a
> particular DGRAM socket is used by many different threads to :
No we don't need that for datagram protocols at all. By definition
there is no ordering guarantee across CPUs for datagram sockets.
Cheers,
--
Email: Herbert Xu <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: SO_REUSEPORT - can it be done in kernel?
From: Eric Dumazet @ 2011-03-02 2:00 UTC (permalink / raw)
To: Herbert Xu
Cc: Thomas Graf, David Miller, rick.jones2, therbert, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <20110302002353.GA15009@gondor.apana.org.au>
Le mercredi 02 mars 2011 à 08:23 +0800, Herbert Xu a écrit :
> On Tue, Mar 01, 2011 at 05:31:24PM +0100, Eric Dumazet wrote:
> >
> > This wont work for tcp streams, you could imagine a multi-threaded
> > application using a shared tcp socket as well. Too many OOO packets.
>
> Think about it, a TCP socket cannot be used by a multi-threaded app
> in a scalable way.
Well...
If you think about it, SO_REUSEPORT patch has exactly the same goal :
Let each thread use a different socket, to scale without kernel limits.
We cant modify TX selection each time we want to "fix" a problem without
changing user side (not adding an API), and as side effect make non
optimal applications become miserable.
We added RPS and XPS that works correctly if each socket is used by one
thread. Maybe we need to add an user API or automatically detect a
particular DGRAM socket is used by many different threads to :
0) Decide OOM is ok for this workload (many threads issuing send() at
the same time)
1) Setup several receive queues (up to num_possible_cpus())
2) Use an appropriate TX queue selection
^ permalink raw reply
* Re: [PATCH 1/2 net-next][v2] bonding: fix incorrect transmit queue offset
From: Phil Oester @ 2011-03-02 1:40 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: David Miller, bhutchings, netdev, fubar
In-Reply-To: <20110301153135.GL11864@gospo.rdu.redhat.com>
On Tue, Mar 01, 2011 at 10:31:36AM -0500, Andy Gospodarek wrote:
> > The patch works as expected. Do we have any agreement on a final version?
> >
>
> Thanks for the testing, Phil.
>
> I'm in favor of this patch as it does alert the admin that bonding may
> not have enough default queues, but it is not as verbose (backtrace et
> al) and likely to create bug reports as a message from WARN_ON.
> + if (net_ratelimit())
> + pr_warning("%s selects invalid tx queue %d. Consider"
> + " setting module option tx_queues > %d.",
> + dev->name, txq, dev->real_num_tx_queues);
It is unclear why we need to alert the admin to this situation (repeatedly).
Say the incoming nic has 32 queues, and is headed out a bond (with 16).
With your patch, we will log 50% of the time, no? What benefit is this
log spew?
While WARN_ONCE may be a bit extreme due to the backtrace, perhaps we
should at least throw a 'static bool warned' variable in there to lessen
the nuisance?
Phil
^ permalink raw reply
* RE: e1000 - rx misses
From: Brandeburg, Jesse @ 2011-03-02 1:01 UTC (permalink / raw)
To: John Bermudez
Cc: Ronciak, John, Kirsher, Jeffrey T, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net
In-Reply-To: <2DF55ECAAA7FFF478FB4ED007EF478E7656B100F27@NETS.hillside.glowpoint.com>
<removed non-relevant users>
On Tue, 1 Mar 2011, John Bermudez wrote:
> Thanks for your time
> Can you tell me the command to lengthen the input fifo rx queue?
> is this possible
You can try increasing the number of rx buffers via the command
# ethtool -G ethX rx 4096
and if you were really gung ho, you could increase the amount of fifo
allocated to the rx side of the fifo by modifying the source. That said,
I don't think that will buy you anything because it seems from the small
amount of data provided that you are having exceptionally long periods of
time where the data is coming faster than your machine can process (for
whatever reason) and increasing the fifo only will give you a marginal
(4kB or so) increasing in buffering.
>
> -----Original Message-----
> From: Brandeburg, Jesse [mailto:jesse.brandeburg@intel.com]
> Sent: Monday, February 28, 2011 11:05 AM
> To: John Bermudez
> Cc: cramerj; Ronciak, John; Kirsher, Jeffrey T; Kok, Auke-jan H; netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net
> Subject: Re: e1000 - rx misses
>
> added e1000-devel, responses inline...
>
> On Wed, 23 Feb 2011, John Bermudez wrote:
>
> > Hello All,
> > I got your contact info in a forum.
> > maybe you could give me a quick pointer.
> >
> > I have a device that is experiencing RX misses. I tried 1000/full and 100/full
> > it occurs at both speeds. I seem to get a burst of loss so I am assuming I am overrunning the FIFO RX queue.
>
> overrunning at 100Mb/s seems pretty unlikely to be our hardware's fault,
> as your buffer (in time) is increasing by 10x.
>
> >
> > Any known workarounds?
> > Configuration modifications?
> >
> > your time is much appreciated
> >
> >
> >
> > /lib/modules/2.4.31-uc0/kernel/drivers/net/e1000
> > # ls
> > e1000.o
>
> ow, 2.4.31 kernel is pretty much so old as to not be supportable.
>
> > # ethtool -S eth1
> > NIC statistics:
> > rx_packets: 217454512
> > tx_packets: 266698397
> > rx_bytes: 172995819593
> > tx_bytes: 246744709750
> > rx_broadcast: 0
> > tx_broadcast: 528
> <snip>
> > rx_no_buffer_count: 925
>
> This count above indicates that your cpu is not returning buffers to
> hardware fast enough. Do you have NAPI enabled?
>
> > rx_missed_errors: 48206
>
> This error means that for the length of time the fifo was buffering the
> adapter was not able to get any data buffers from the OS, filled the FIFO
> and had to drop this many packets.
>
> > tx_aborted_errors: 0
> > tx_carrier_errors: 0
> > tx_fifo_errors: 0
> > tx_heartbeat_errors: 0
> > tx_window_errors: 0
> > tx_abort_late_coll: 0
> > tx_deferred_ok: 0
> > tx_single_coll_ok: 0
> > tx_multi_coll_ok: 0
> > tx_timeout_count: 0
> > tx_restart_queue: 0
> > rx_long_length_errors: 0
> > rx_short_length_errors: 0
> > rx_align_errors: 0
> > tx_tcp_seg_good: 0
> > tx_tcp_seg_failed: 0
> > rx_flow_control_xon: 0
> > rx_flow_control_xoff: 0
> > tx_flow_control_xon: 0
> > tx_flow_control_xoff: 0
>
> flow control is either not happenning or is disabled, if it is disabled
> you could try enabling it on both ends to get a little more buffering in
> your switch.
>
> > rx_long_byte_count: 172995819593
> > rx_csum_offload_good: 217406235
> > rx_csum_offload_errors: 17
> > rx_header_split: 0
> > alloc_rx_buff_failed: 0
> > tx_smbus: 0
> > rx_smbus: 5262
>
> hm, you have IPMI traffic, could these be related to your stalls?
>
> > dropped_smbus: 0
> > #
> >
> >
> > Thank you and have a nice day,
> >
> > Mr. John Bermudez
> > NOC Level 3 Engineer
> >
> >
>
> You didn't include lots of data we need, like hardware type, adapter/chip,
> ethtool -i output, cat /proc/interrupts, system info, .config, etc.
>
> I suggest that something is running either in interrupt context on your
> system for a very long time (keeping us from running our interrupt
> handler) or that your cpu is underpowered and unable to keep up with
> whatever tasks it is running besides the network driver.
>
> If you wish to continue troubleshooting please file a bug at e1000.sf.net
> and attach the requested info there.
>
> Jesse
>
^ permalink raw reply
* Re: [PATCH] ipv4: Make icmp route lookup code a bit clearer.
From: Herbert Xu @ 2011-03-02 0:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110301.155015.258117084.davem@davemloft.net>
On Tue, Mar 01, 2011 at 03:50:15PM -0800, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 01 Mar 2011 15:48:16 -0800 (PST)
>
> >
> > The route lookup code in icmp_send() is slightly tricky as a result of
> > having to handle all of the requirements of RFC 4301 host relookups.
> >
> > Pull the route resolution into a seperate function, so that the error
> > handling and route reference counting is hopefully easier to see and
> > contained wholly within this new routine.
> >
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> ...
> > +struct rtable *icmp_route_lookup(struct net *net, struct sk_buff *skb_in,
>
> Of course this should be static :-)
Looks good to me.
Thanks!
--
Email: Herbert Xu <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: SO_REUSEPORT - can it be done in kernel?
From: Herbert Xu @ 2011-03-02 0:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas Graf, David Miller, rick.jones2, therbert, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <1298997084.3284.119.camel@edumazet-laptop>
On Tue, Mar 01, 2011 at 05:31:24PM +0100, Eric Dumazet wrote:
>
> This wont work for tcp streams, you could imagine a multi-threaded
> application using a shared tcp socket as well. Too many OOO packets.
Think about it, a TCP socket cannot be used by a multi-threaded app
in a scalable way.
Cheers,
--
Email: Herbert Xu <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
* (unknown),
From: Mr. henry @ 2011-03-01 23:47 UTC (permalink / raw)
Van szüksége a hitel bármilyen célra? Van egy pénzügyi probléma? Nem
szükség van a pénzügyi megoldás? Mr. Henrik
hitelek a megoldás toall a pénzügyi problémákat, mi hitelek könnyen,
olcsó, és gyors. Írjon nekünk ma, hogy a kölcsönt, amire vágytok, akkor
intézkedik minden olyan kölcsön, hogy megfeleljen a költségvetés mindössze
3%-os kamat. Ha
érdekli, lépjen velünk kapcsolatba immediately.Optional Hitel A védelem
lehetővé teszi,
hogy megfeleljen a hiteltörlesztés, ha nem tud dolgozni, betegség miatt,
baleset vagy
munkanélküliség. Csak akkor vegye ki az értékes biztosítást, ha alkalmazni
az Ön kölcsönt,
emlékszem, hogy elmondja nekünk, ha azt szeretné, hogy
henmoralendingfirm@gmail.com
* HITEL JELENTKEZÉSI LAP *
* Teljes név ............*
* Otthoni cím ....................... ..*
* Születési dátum ......................*
* Telefonszám ...................*
* MOBIL szám, ha ..............*
* HITEL szükséges mennyiség .................*
* FAX .................*
* Állampolgárság ..................*
* ORSZÁG ........................*
* SZAKMA ....................*
* SEX ..................................*
* FÉRFI .............................*
* FEMAL .........................*
* VÁLÁS HA ......................*
* Legközelebbi hozzátartozó .......................*
* NÉV .......................... ...*
* Születési dátum .....................*
* CÉLJA KÖLCSÖNZÉS .......................... .......*
* A kölcsön időtartamát ........................*
* ID .......................*
* A Üdvözlettel *
* Mr. henry *
^ permalink raw reply
* Re: [Bugme-new] [Bug 30092] New: smsc911x.c drops long packets with VLAN tags
From: Andrew Morton @ 2011-03-02 0:15 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, weinholt, Steve Glendinning
In-Reply-To: <bug-30092-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 28 Feb 2011 15:57:14 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=30092
>
> Summary: smsc911x.c drops long packets with VLAN tags
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.36.4
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: weinholt@csbnet.se
> Regression: No
>
>
> The smsc911x.c driver can't receive packets of the maximum MTU if they have a
> 802.1q tag. Testing with ping -s 1500 shows that the frame with the first IP
> segment is dropped.
>
> The source of the problem is this line at smsc911x.c:1023 (smsc911x_poll):
>
> if (unlikely(rxstat & RX_STS_ES_)) {
>
> The datasheet at
> http://www.smsc.com/media/Downloads_Public/Data_Sheets/9221.pdf describes this
> bit as a logical OR of bits 11, 7, 6 and 1. The problem is that bit 7 is set if
> the packet is longer than 1518 bytes, which is true for the 802.1q tagged
> packets. As a quick and dirty solution, I replaced RX_STS_ES_ with
> (1<<11|1<<6|1<<1), and now 802.1q tagged packets are received just fine.
>
> This was tested on an IGEPv2, which has a SMSC LAN9221i.
>
Thanks. Become famous, get more girls: send us a patch as per
Documentation/SubmittingPatches :)
^ permalink raw reply
* RE: e1000 - rx misses
From: John Bermudez @ 2011-03-02 0:14 UTC (permalink / raw)
To: Brandeburg, Jesse
Cc: cramerj, Ronciak, John, Kirsher, Jeffrey T, Kok, Auke-jan H,
netdev@vger.kernel.org, e1000-devel@lists.sourceforge.net
In-Reply-To: <alpine.WNT.2.00.1102281058040.5424@JBRANDEB-DESK2.amr.corp.intel.com>
Thanks for your time
Can you tell me the command to lengthen the input fifo rx queue?
is this possible
Thank you and have a nice day,
Mr. John Bermudez
NOC Level 3 Engineer
-----Original Message-----
From: Brandeburg, Jesse [mailto:jesse.brandeburg@intel.com]
Sent: Monday, February 28, 2011 11:05 AM
To: John Bermudez
Cc: cramerj; Ronciak, John; Kirsher, Jeffrey T; Kok, Auke-jan H; netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net
Subject: Re: e1000 - rx misses
added e1000-devel, responses inline...
On Wed, 23 Feb 2011, John Bermudez wrote:
> Hello All,
> I got your contact info in a forum.
> maybe you could give me a quick pointer.
>
> I have a device that is experiencing RX misses. I tried 1000/full and 100/full
> it occurs at both speeds. I seem to get a burst of loss so I am assuming I am overrunning the FIFO RX queue.
overrunning at 100Mb/s seems pretty unlikely to be our hardware's fault,
as your buffer (in time) is increasing by 10x.
>
> Any known workarounds?
> Configuration modifications?
>
> your time is much appreciated
>
>
>
> /lib/modules/2.4.31-uc0/kernel/drivers/net/e1000
> # ls
> e1000.o
ow, 2.4.31 kernel is pretty much so old as to not be supportable.
> # ethtool -S eth1
> NIC statistics:
> rx_packets: 217454512
> tx_packets: 266698397
> rx_bytes: 172995819593
> tx_bytes: 246744709750
> rx_broadcast: 0
> tx_broadcast: 528
<snip>
> rx_no_buffer_count: 925
This count above indicates that your cpu is not returning buffers to
hardware fast enough. Do you have NAPI enabled?
> rx_missed_errors: 48206
This error means that for the length of time the fifo was buffering the
adapter was not able to get any data buffers from the OS, filled the FIFO
and had to drop this many packets.
> tx_aborted_errors: 0
> tx_carrier_errors: 0
> tx_fifo_errors: 0
> tx_heartbeat_errors: 0
> tx_window_errors: 0
> tx_abort_late_coll: 0
> tx_deferred_ok: 0
> tx_single_coll_ok: 0
> tx_multi_coll_ok: 0
> tx_timeout_count: 0
> tx_restart_queue: 0
> rx_long_length_errors: 0
> rx_short_length_errors: 0
> rx_align_errors: 0
> tx_tcp_seg_good: 0
> tx_tcp_seg_failed: 0
> rx_flow_control_xon: 0
> rx_flow_control_xoff: 0
> tx_flow_control_xon: 0
> tx_flow_control_xoff: 0
flow control is either not happenning or is disabled, if it is disabled
you could try enabling it on both ends to get a little more buffering in
your switch.
> rx_long_byte_count: 172995819593
> rx_csum_offload_good: 217406235
> rx_csum_offload_errors: 17
> rx_header_split: 0
> alloc_rx_buff_failed: 0
> tx_smbus: 0
> rx_smbus: 5262
hm, you have IPMI traffic, could these be related to your stalls?
> dropped_smbus: 0
> #
>
>
> Thank you and have a nice day,
>
> Mr. John Bermudez
> NOC Level 3 Engineer
>
>
You didn't include lots of data we need, like hardware type, adapter/chip,
ethtool -i output, cat /proc/interrupts, system info, .config, etc.
I suggest that something is running either in interrupt context on your
system for a very long time (keeping us from running our interrupt
handler) or that your cpu is underpowered and unable to keep up with
whatever tasks it is running besides the network driver.
If you wish to continue troubleshooting please file a bug at e1000.sf.net
and attach the requested info there.
Jesse
^ permalink raw reply
* Re: [Bugme-new] [Bug 30082] New: after lxc-stop: unregister_netdevice: waiting for lo to become free. Usage count: 3
From: Andrew Morton @ 2011-03-02 0:13 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, mjt
In-Reply-To: <bug-30082-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 28 Feb 2011 14:47:03 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=30082
>
> Summary: after lxc-stop: unregister_netdevice: waiting for lo
> to become free. Usage count: 3
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.36 2.6.37
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: acme@ghostprotocols.net
> ReportedBy: mjt@tls.msk.ru
> Regression: No
>
>
> As far as I can tell so far this is triggered by lxc version 0.7.4, at least I
> haven't seen this before. I tried 2.6.36[.3] and 2.6.37[.2] kernels so far,
> both behaves similarly.
>
> The problem is, when I shut down a container which uses bridged veth interface
> pair using lxc-stop, the container terminates, but host system starts crying
> about unregister_netdevice like this:
>
> [902885.096462] unregister_netdevice: waiting for lo to become free. Usage
> count = 3
> [902895.229785] unregister_netdevice: waiting for lo to become free. Usage
> count = 3
> [...]
> [904247.123002] unregister_netdevice: waiting for lo to become free. Usage
> count = 3
>
> After some, random, time, this stops - sometimes after just one message,
> sometimes after several minutes. Sometimes it does not happen at all.
>
> This looks like a kernel issue triggerable by lxc-0.7.4.
>
^ permalink raw reply
* (unknown),
From: Mr. henry @ 2011-03-01 23:48 UTC (permalink / raw)
Van szüksége a hitel bármilyen célra? Van egy pénzügyi probléma? Nem
szükség van a pénzügyi megoldás? Mr. Henrik
hitelek a megoldás toall a pénzügyi problémákat, mi hitelek könnyen,
olcsó, és gyors. Írjon nekünk ma, hogy a kölcsönt, amire vágytok, akkor
intézkedik minden olyan kölcsön, hogy megfeleljen a költségvetés mindössze
3%-os kamat. Ha
érdekli, lépjen velünk kapcsolatba immediately.Optional Hitel A védelem
lehetővé teszi,
hogy megfeleljen a hiteltörlesztés, ha nem tud dolgozni, betegség miatt,
baleset vagy
munkanélküliség. Csak akkor vegye ki az értékes biztosítást, ha alkalmazni
az Ön kölcsönt,
emlékszem, hogy elmondja nekünk, ha azt szeretné, hogy
henmoralendingfirm@gmail.com
* HITEL JELENTKEZÉSI LAP *
* Teljes név ............*
* Otthoni cím ....................... ..*
* Születési dátum ......................*
* Telefonszám ...................*
* MOBIL szám, ha ..............*
* HITEL szükséges mennyiség .................*
* FAX .................*
* Állampolgárság ..................*
* ORSZÁG ........................*
* SZAKMA ....................*
* SEX ..................................*
* FÉRFI .............................*
* FEMAL .........................*
* VÁLÁS HA ......................*
* Legközelebbi hozzátartozó .......................*
* NÉV .......................... ...*
* Születési dátum .....................*
* CÉLJA KÖLCSÖNZÉS .......................... .......*
* A kölcsön időtartamát ........................*
* ID .......................*
* A Üdvözlettel *
* Mr. henry *
^ permalink raw reply
* Re: [question] fcoe: bonding support
From: Robert Love @ 2011-03-02 0:05 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev@vger.kernel.org
In-Reply-To: <20110228122957.GB4043@psychotron.brq.redhat.com>
On Mon, 2011-02-28 at 04:29 -0800, Jiri Pirko wrote:
> Hi Robert.
>
Hi Jirka,
I think the other community members have probably answered your
questions sufficiently, but since you addressed me directly I figured I
should reply. Let me know if you need any further assistance. I'll also
be happy to pick up your patch when it's done.
//Rob
> I wonder what's the meaning of the following code in fcoe_interface_setup():
>
> /* Do not support for bonding device */
> if ((netdev->priv_flags & IFF_MASTER_ALB) ||
> (netdev->priv_flags & IFF_SLAVE_INACTIVE) ||
> (netdev->priv_flags & IFF_MASTER_8023AD)) {
> FCOE_NETDEV_DBG(netdev, "Bonded interfaces not supported\n");
> return -EOPNOTSUPP;
> }
>
> From this I cannot understand if bonding is not supported at all or
> only alb and 8023ad modes are not supported (leaving aside completely
> bogus checking for IFF_SLAVE_INACTIVE).
>
> How about to check IFF_BONDING only (in case bonding should not be
> supported at all)
>
> Thanks.
>
> Jirka
^ permalink raw reply
* Re: [PATCH] ipv4: Make icmp route lookup code a bit clearer.
From: David Miller @ 2011-03-01 23:50 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20110301.154816.212683830.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 01 Mar 2011 15:48:16 -0800 (PST)
>
> The route lookup code in icmp_send() is slightly tricky as a result of
> having to handle all of the requirements of RFC 4301 host relookups.
>
> Pull the route resolution into a seperate function, so that the error
> handling and route reference counting is hopefully easier to see and
> contained wholly within this new routine.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
...
> +struct rtable *icmp_route_lookup(struct net *net, struct sk_buff *skb_in,
Of course this should be static :-)
^ permalink raw reply
* [PATCH] ipv4: Make icmp route lookup code a bit clearer.
From: David Miller @ 2011-03-01 23:48 UTC (permalink / raw)
To: herbert; +Cc: netdev
The route lookup code in icmp_send() is slightly tricky as a result of
having to handle all of the requirements of RFC 4301 host relookups.
Pull the route resolution into a seperate function, so that the error
handling and route reference counting is hopefully easier to see and
contained wholly within this new routine.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/icmp.c | 175 ++++++++++++++++++++++++++++++-------------------------
1 files changed, 96 insertions(+), 79 deletions(-)
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index ad2bcf1..527ffd1 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -369,6 +369,98 @@ out_unlock:
icmp_xmit_unlock(sk);
}
+struct rtable *icmp_route_lookup(struct net *net, struct sk_buff *skb_in,
+ struct iphdr *iph,
+ __be32 saddr, u8 tos,
+ int type, int code,
+ struct icmp_bxm *param)
+{
+ struct flowi fl = {
+ .fl4_dst = (param->replyopts.srr ?
+ param->replyopts.faddr : iph->saddr),
+ .fl4_src = saddr,
+ .fl4_tos = RT_TOS(tos),
+ .proto = IPPROTO_ICMP,
+ .fl_icmp_type = type,
+ .fl_icmp_code = code,
+ };
+ struct rtable *rt, *rt2;
+ int err;
+
+ security_skb_classify_flow(skb_in, &fl);
+ err = __ip_route_output_key(net, &rt, &fl);
+ if (err)
+ return ERR_PTR(err);
+
+ /* No need to clone since we're just using its address. */
+ rt2 = rt;
+
+ if (!fl.fl4_src)
+ fl.fl4_src = rt->rt_src;
+
+ err = xfrm_lookup(net, (struct dst_entry **)&rt, &fl, NULL, 0);
+ switch (err) {
+ case 0:
+ if (rt != rt2)
+ return rt;
+ break;
+ case -EPERM:
+ rt = NULL;
+ break;
+ default:
+ return ERR_PTR(err);
+ }
+
+ err = xfrm_decode_session_reverse(skb_in, &fl, AF_INET);
+ if (err)
+ goto relookup_failed;
+
+ if (inet_addr_type(net, fl.fl4_src) == RTN_LOCAL) {
+ err = __ip_route_output_key(net, &rt2, &fl);
+ } else {
+ struct flowi fl2 = {};
+ unsigned long orefdst;
+
+ fl2.fl4_dst = fl.fl4_src;
+ err = ip_route_output_key(net, &rt2, &fl2);
+ if (err)
+ goto relookup_failed;
+ /* Ugh! */
+ orefdst = skb_in->_skb_refdst; /* save old refdst */
+ err = ip_route_input(skb_in, fl.fl4_dst, fl.fl4_src,
+ RT_TOS(tos), rt2->dst.dev);
+
+ dst_release(&rt2->dst);
+ rt2 = skb_rtable(skb_in);
+ skb_in->_skb_refdst = orefdst; /* restore old refdst */
+ }
+
+ if (err)
+ goto relookup_failed;
+
+ err = xfrm_lookup(net, (struct dst_entry **)&rt2, &fl, NULL,
+ XFRM_LOOKUP_ICMP);
+ switch (err) {
+ case 0:
+ dst_release(&rt->dst);
+ rt = rt2;
+ break;
+ case -EPERM:
+ return ERR_PTR(err);
+ default:
+ if (!rt)
+ return ERR_PTR(err);
+ break;
+ }
+
+
+ return rt;
+
+relookup_failed:
+ if (rt)
+ return rt;
+ return ERR_PTR(err);
+}
/*
* Send an ICMP message in response to a situation
@@ -506,86 +598,11 @@ void icmp_send(struct sk_buff *skb_in, int type, int code, __be32 info)
ipc.opt = &icmp_param.replyopts;
ipc.tx_flags = 0;
- {
- struct flowi fl = {
- .fl4_dst = icmp_param.replyopts.srr ?
- icmp_param.replyopts.faddr : iph->saddr,
- .fl4_src = saddr,
- .fl4_tos = RT_TOS(tos),
- .proto = IPPROTO_ICMP,
- .fl_icmp_type = type,
- .fl_icmp_code = code,
- };
- int err;
- struct rtable *rt2;
-
- security_skb_classify_flow(skb_in, &fl);
- if (__ip_route_output_key(net, &rt, &fl))
- goto out_unlock;
-
- /* No need to clone since we're just using its address. */
- rt2 = rt;
-
- if (!fl.nl_u.ip4_u.saddr)
- fl.nl_u.ip4_u.saddr = rt->rt_src;
-
- err = xfrm_lookup(net, (struct dst_entry **)&rt, &fl, NULL, 0);
- switch (err) {
- case 0:
- if (rt != rt2)
- goto route_done;
- break;
- case -EPERM:
- rt = NULL;
- break;
- default:
- goto out_unlock;
- }
-
- if (xfrm_decode_session_reverse(skb_in, &fl, AF_INET))
- goto relookup_failed;
-
- if (inet_addr_type(net, fl.fl4_src) == RTN_LOCAL)
- err = __ip_route_output_key(net, &rt2, &fl);
- else {
- struct flowi fl2 = {};
- unsigned long orefdst;
-
- fl2.fl4_dst = fl.fl4_src;
- if (ip_route_output_key(net, &rt2, &fl2))
- goto relookup_failed;
-
- /* Ugh! */
- orefdst = skb_in->_skb_refdst; /* save old refdst */
- err = ip_route_input(skb_in, fl.fl4_dst, fl.fl4_src,
- RT_TOS(tos), rt2->dst.dev);
-
- dst_release(&rt2->dst);
- rt2 = skb_rtable(skb_in);
- skb_in->_skb_refdst = orefdst; /* restore old refdst */
- }
-
- if (err)
- goto relookup_failed;
-
- err = xfrm_lookup(net, (struct dst_entry **)&rt2, &fl, NULL,
- XFRM_LOOKUP_ICMP);
- switch (err) {
- case 0:
- dst_release(&rt->dst);
- rt = rt2;
- break;
- case -EPERM:
- goto ende;
- default:
-relookup_failed:
- if (!rt)
- goto out_unlock;
- break;
- }
- }
+ rt = icmp_route_lookup(net, skb_in, iph, saddr, tos,
+ type, code, &icmp_param);
+ if (IS_ERR(rt))
+ goto out_unlock;
-route_done:
if (!icmpv4_xrlim_allow(net, rt, type, code))
goto ende;
--
1.7.4.1
^ permalink raw reply related
* Re: skb->frag_list != NULL in start_xmit for device without NETIF_F_FRAGLIST
From: Jesse Gross @ 2011-03-01 23:41 UTC (permalink / raw)
To: Ian Campbell; +Cc: netdev, Paul Durrant
In-Reply-To: <1298980019.5034.2238.camel@zakaz.uk.xensource.com>
On Tue, Mar 1, 2011 at 3:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> Hi,
>
> We are seeing cases where Xen netback's start_xmit is being passed an
> skb which has a ->frag_list, despite the driver not advertising the
> NETIF_F_FRAGLIST feature.
>
> Is this indicative of a problem somewhere? Are drivers expected to
> handle a frag_list? grepping for frag_list in drivers/net it appears not
> many drivers do anything with the frag_list.
It certainly sounds like a problem to me. Off the top of my head I
don't know of any drivers that actually set and handle
NETIF_F_FRAGLIST (except for pseudo-devices like bridging).
>
> The netback driver is bridged with a tg3 physical device and we think
> the problematic skb's are originating on the wire.
>
> The case we are actually seeing is with 2.6.32 + tg3 3.110g so obviously
> the next step is to reproduce on a more modern kernel and the in-tree
> driver and then to attempt to determine if the fault is in what the
> physical interface's driver is passing up the stack or in the stack's
> handling of those skbs. Any hints on where to look would be much
> appreciated.
I'd guess that the most likely source of frag_lists generated here are
from GRO, in skb_gro_receive(). The driver/NIC can definitely
influence the strategy that GRO uses for reassembly but it seems less
likely that the driver itself will create frag_lists.
>
> In particular I'm not sure where the frag_list is supposed to get
> resolved in the case where dev_hard_start_xmit takes the netif_needs_gso
> == true path and calls dev_gso_segment rather than taking the
> __skb_linearize path (the issue appears to occur only when the netback
> device has NETIF_F_GSO but not NETIF_F_TSO). AFAICT dev_gso_segment goes
> to tcp_tso_segment and then to skb_segment which does appear to create
> skbs with a frag_list (although it's not outside the realms of
> possibility that I'm reading it wrong).
I'm fairly certain that the problem is in skb_segment(). It's not the
most tolerant of skbs with frag_lists that do not line up with the
requested mss. Depending on how the original skb is laid out,
sometimes this will trigger a BUG_ON and sometimes it creates new
frag_lists. Since there are no further checks after GSO, the skb with
a frag_list will get passed to the driver, even if it is not
supported.
I believe that not much has changed in this regard between 2.6.32 and net-next.
> I did wonder if perhaps we should just ignore the field, since something
> higher up the stack walked the list and called start_xmit repeatedly,
> but if that's the case I can't see where...
That will happen for GSO but those packets shouldn't have a frag_list
if the driver doesn't support it.
^ permalink raw reply
* Re: [PATCH] bonding: added 802.3ad round-robin hashing policy and source mac selection mode
From: Stephen Hemminger @ 2011-03-01 23:29 UTC (permalink / raw)
To: Oleg V. Ukhno; +Cc: netdev, Jay Vosburgh, David S. Miller
In-Reply-To: <20110301223458.GA24403@yandex-team.ru>
On Wed, 2 Mar 2011 01:34:58 +0300
"Oleg V. Ukhno" <olegu@yandex-team.ru> wrote:
> Patch introduces two new (related) features to bonding module.
> First feature is round-robin hashing policy, which is primarily
> intended for use with 802.3ad mode, and puts every next IPv4 and
> IPv6 packet into next availables slave without taling into account
> which layer3 and above protocol is used.
> Second feature makes possible choosing which MAC-address will be set
> in the transmitted packet - when set to src-mac it will force setting
> slave's interface real MAC address as source MAC address in every
> packet, sent via this slave interface.
> Main goal of this patch is to make possible single TCP stream
> equally striped for both transmitted and received packets over all
> available slaves.
> This operating mode is not fully 802.3ad compliant, and will cause
> some packet reordering in TCP stream, to some kernel tuning may be
> required.
> For correct working enabling round-robin hashing policy plus using
> real slave's MAC addresses as source MAC addresses in transmitted
> packets requires specific switch setting)hashing mode for port-channel
> ("etherchannel) should be set to src-mac or src-dst-mac to get
> correct load-striping on the receiving host's etherchannel.
> General requirements for using bonding in this operating mode are:
> - even and preferrably equal number of slaves on sending and receiving
> hosts;
> - equal RTT between sending and receiving hosts on all slaves;
> - switch capable of doing etherchannels and using src-mac or src-dst-mac
> hashing policy for egress load striping
>
> Signed-off-by: Oleg V. Ukhno <olegu@yandex-team.ru>
It seems to me the whole bonding policy is getting so complex
that the code is a mess. Perhaps it should be somehow linked into
existing packet classification or firewall mechanisms. This would
increase the flexibility and reduce the amount of policy code
in the bonding driver itself.
--
^ permalink raw reply
* Re: [PATCH 7/7] ipx: remove the BKL
From: David Miller @ 2011-03-01 23:15 UTC (permalink / raw)
To: arnd; +Cc: linux-kernel, acme, netdev
In-Reply-To: <1299021191-17961-8-git-send-email-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 2 Mar 2011 00:13:11 +0100
> This replaces all instances of lock_kernel in the
> IPX code with lock_sock. As far as I can tell, this
> is safe to do, because there is no global state
> that needs to be locked in IPX, and the code does
> not recursively take the lock or sleep indefinitely
> while holding it.
>
> Compile-tested only.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 5/7] x25: remove the BKL
From: David Miller @ 2011-03-01 23:16 UTC (permalink / raw)
To: arnd; +Cc: linux-kernel, andrew.hendry, linux-x25, netdev, eric.dumazet
In-Reply-To: <1299021191-17961-6-git-send-email-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 2 Mar 2011 00:13:09 +0100
> This replaces all instances of lock_kernel in x25
> with lock_sock, taking care to release the socket
> lock around sleeping functions (sock_alloc_send_skb
> and skb_recv_datagram). It is not clear whether
> this is a correct solution, but it seem to be what
> other protocols do in the same situation.
>
> Includes a fix suggested by Eric Dumazet.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 6/7] appletalk: remove the BKL
From: David Miller @ 2011-03-01 23:15 UTC (permalink / raw)
To: arnd; +Cc: linux-kernel, acme, netdev
In-Reply-To: <1299021191-17961-7-git-send-email-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 2 Mar 2011 00:13:10 +0100
> This changes appletalk to use lock_sock instead of
> lock_kernel for serialization. I tried to make sure
> that we don't hold the socket lock during sleeping
> functions, but I did not try to prove whether the
> locks are necessary in the first place.
>
> Compile-tested only.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: David S. Miller <davem@davemloft.net>
^ 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