On Mon, Aug 07, 2006 at 10:36:36AM +0400, Evgeniy Polyakov wrote:
>
> Well, theirs comments in code say, that maximum allowed frame size is
> 0x3f00, so there is a little place at the end to put there a pointer,
> so I allocate size + sizeof(void *).
> If they actually can eat all 16k, then we nee
On Mon, Aug 07, 2006 at 04:29:09PM +1000, Herbert Xu ([EMAIL PROTECTED]) wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > Attached patch allows to avoid unnecessary alignment overhead
> > in skb->data allocation.
> > Main idea is to allocate struct skb_shared_info from cache when
> > a
On Sun, Aug 06, 2006 at 11:23:39PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> > + if ((1UL << order) > size + sizeof(void *) + sizeof(struct
> > skb_shared_info)) {
>
> get_order() returns a PAGE_SIZE order not a byte one. So this test
> here at the end is incorrect. It should probably
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> Attached patch allows to avoid unnecessary alignment overhead
> in skb->data allocation.
> Main idea is to allocate struct skb_shared_info from cache when
> addition of sizeof(struct skb_shared_info) ens up in different order
> allocation than initia
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Mon, 7 Aug 2006 10:01:56 +0400
> + int order = get_order(size + sizeof(void *));
> + struct skb_shared_info *sh;
>
> cache = fclone ? skbuff_fclone_cache : skbuff_head_cache;
>
> @@ -156,11 +159,28 @@ struct sk_buff *__alloc_skb(un
From: Steven Rostedt <[EMAIL PROTECTED]>
Date: Mon, 7 Aug 2006 01:34:56 -0400 (EDT)
> My suggestion would be to separate that tg3_timer into 4 different
> timers, which is what it actually looks like.
Timers have non-trivial cost. It's cheaper to have one and
vector off to the necessary operatio
Hello.
Attached patch allows to avoid unnecessary alignment overhead
in skb->data allocation.
Main idea is to allocate struct skb_shared_info from cache when
addition of sizeof(struct skb_shared_info) ens up in different order
allocation than initial size order.
This allows to solve problem with 4
On Thu, 3 Aug 2006, Theodore Tso wrote:
> On Thu, Aug 03, 2006 at 02:48:45PM -0700, David Miller wrote:
> > > eth0: Tigon3 [partno(BCM95704s) rev 2100 PHY(serdes)]
> > > (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:14:5e:86:44:24
> >
> > The 5704 chip will set TG3_FLAG_TAGGED_STATUS, and th
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 07 Aug 2006 07:19:10 +0200
> [IPV6]: Fix policy routing lookup
>
> When the lookup in a table returns ip6_null_entry the policy routing lookup
> returns it instead of continuing in the next table, which effectively means
> it only searches the l
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 07 Aug 2006 07:19:05 +0200
> [IPV6]: Fix crash in ip6_del_rt
>
> ip6_null_entry doesn't have rt6i_table set, when trying to delete it the
> kernel crashes dereferencing table->tb6_lock.
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
App
[IPV6]: Fix policy routing lookup
When the lookup in a table returns ip6_null_entry the policy routing lookup
returns it instead of continuing in the next table, which effectively means
it only searches the local table.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit f5d49889512f24
[IPV6]: Fix crash in ip6_del_rt
ip6_null_entry doesn't have rt6i_table set, when trying to delete it the
kernel crashes dereferencing table->tb6_lock.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit d3ddd45b230e8b56873c77d266004fec49c44f8b
tree 764a548789cd495e2b424824c682734f62e9c
On Sun, Aug 06, 2006 at 08:56:31PM -0700, Michael Chan wrote:
>
> > Because netif_queue_stopped is *not* a memory barrier, it can float
> > above the assignment to tx_cons. So even though netif_stop_queue *is*
> > a memory barrier on x86, the second BUFF_AVAIL test can still fail to
> > see the up
Acked-by: Catherine Zhang <[EMAIL PROTECTED]>
Thomas Graf <[EMAIL PROTECTED]> wrote on 08/05/2006 07:56:20 AM:
> Collision between "[NetLabel]: SELinux support" and
> "[AF_UNIX]: Kernel memory leak fix for af_unix datagram getpeersec"
>
> Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
>
> Inde
Herbert Xu wrote:
> Yes it has the problem in two places. First of all the first
> netif_stop_queue in tg3_start_xmit doesn't take the tx_lock at
> all so it's obviously vulnerable.
Oh, that first one near the top of tg3_start_xmit()? That
condition is not supposed to happen and is a bug condit
On Sun, Aug 06, 2006 at 07:44:47PM -0700, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Mon, 07 Aug 2006 12:40:34 +1000
>
> > The general approach looks sound. I have one esoteric question
> > though. If a retransmitted packet is coalesced with one that is
> > yet to be tran
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Mon, 07 Aug 2006 12:40:34 +1000
> The general approach looks sound. I have one esoteric question
> though. If a retransmitted packet is coalesced with one that is
> yet to be transmitted (a fairly unlikely scenario, but possible I
> think), should it co
Wei Yongjun <[EMAIL PROTECTED]> wrote:
>
> --- a/net/ipv4/tcp_output.c 2006-08-03 18:05:22.425081936 -0400
> +++ b/net/ipv4/tcp_output.c 2006-08-07 09:48:41.186372896 -0400
> @@ -462,7 +462,8 @@ static int tcp_transmit_skb(struct sock
>if (skb->len != tcp_header_size)
>
Patch has been fixed.
On Friday 04 August 2006 07:23, David Miller wrote:
> From: Wei Yongjun <[EMAIL PROTECTED]>
> Date: Fri, 04 Aug 2006 08:46:13 -0400
>
> > This always correct except when do active open in tcp client, which
will
> > send a SYN, that segment will not be counted, even if it is n
Lennert Buytenhek wrote:
> I have one machine at home that appears to be on my employer's network
> via such a tunnel. I don't use bridging, because I don't need any other
> machine at home to access this tunnel. I do want bridging, and not proxy
> ARP, because it allows me to run arpwatch, and d
On 8/6/06, jamal <[EMAIL PROTECTED]> wrote:
Q: Do you know the historical context of why TX_WAKE_THRESHOLD and
E1000_TX_WEIGHT are hard-coded (and not for example related to the size
of the ring)? Jesse?
Otherwise i would like to submit a patch for the above. eventually
probably even allow the se
On Sun, Aug 06, 2006 at 10:20:12AM -0700, Michael Chan wrote:
>
> Do you mean the same race condition bug between tg3_start_xmit()
> and tg3_tx() that I brought up? I don't think tg3 has that problem.
> Did I miss something?
Yes it has the problem in two places. First of all the first
netif_sto
Hi,
> If the EEPROM has a broken checksum, the user should have an option
> that allows him to try and use the device anyways, end of story.
Ive come across this problem a number of times on e1000 chips (to be
clear it was vendor programming issues).
The driver has the option to read and write
On Sun, 2006-06-08 at 08:24 -0400, jamal wrote:
> Will try it before end of day.
Looks good performance-wise; almost as good as the version i had.
Certainly better than the original e1000 (of course i am talking about
the overload case ;->).
Interesting thing to note:
only 0.001% of the time an
On Sun, 6 Aug 2006 07:12:56 -0700
[EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=6966
>
>Summary: ftp conntrack doesn't work
> Kernel Version: 2.6.17.6
> Status: NEW
> Severity: normal
> Owner: [EMAIL PROTECTED]
>
On Saturday 05 August 2006 03:37, Michael Buesch wrote:
> On Saturday 05 August 2006 09:57, Michael Wu wrote:
> > Use IRQF_SHARED instead of SA_SHIRQ
> >
> > This patch switches all instances of SA_SHIRQ to IRQF_SHARED for drivers
> > in the drivers/net/wireless/d80211 directory. According to
> > f
Herbert Xu wrote:
> In fact that reminds me, because tg3 is no longer lockless, we can do
> a nicer bug fix for it than e1000 (it has the same bug).
>
Do you mean the same race condition bug between tg3_start_xmit()
and tg3_tx() that I brought up? I don't think tg3 has that problem.
Did I miss
El Sat, 05 Aug 2006 21:14:49 -0700 (PDT),
David Miller <[EMAIL PROTECTED]> escribió:
>
> on any patches you submit. I'm fixing it this time, but I
> won't next time.
Sorry, I copy-pasted it from the bugzilla without looking too much the patch :/
-
To unsubscribe from this list: send the line "u
BTW, if you notice in the attached patch i have:
+ /* number of descriptors needed to wake up netdev */
+ unsigned int waket;
+ /* number of descriptors we allow to prune at a time */
+ unsigned int prunet;
and:
+ /* hard-coding for now, but we should be able to
+
On Sun, 2006-06-08 at 12:51 +1000, Herbert Xu wrote:
> On Sat, Aug 05, 2006 at 07:36:50PM -0400, jamal wrote:
> >
> > I know the qlen is >= 0 otherwise i will hit the BUG().
> > A qlen of 0 will be interesting to find as well.
>
> When the queue is woken it will always to qdisc_run regardless of
On Sun, Aug 06, 2006 at 07:10:20PM +1000, Herbert Xu wrote:
> On Sun, Aug 06, 2006 at 11:03:54AM +0200, Edgar E. Iglesias wrote:
> >
> > > For UDP yes but does this really make sense for TCP?
> >
> > I don't know :)
> >
> > The flow may end up with SNDBUF worth of skbs on the socket
> > transmit_
On Sun, Aug 06, 2006 at 11:03:54AM +0200, Edgar E. Iglesias wrote:
>
> > For UDP yes but does this really make sense for TCP?
>
> I don't know :)
>
> The flow may end up with SNDBUF worth of skbs on the socket
> transmit_queue + cwnd worth of skbs on the qdisc queue + full tx ring. In slow
> star
On Sun, Aug 06, 2006 at 06:27:35PM +1000, Herbert Xu wrote:
> Edgar E. Iglesias <[EMAIL PROTECTED]> wrote:
> >
> > It makes sense, but I see a problem with this. It will remove some of the
> > control applications have on how much of their data gets queued on local
> > queues. Small SNDBUF's are s
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sun, 6 Aug 2006 17:36:55 +1000
> Actually, why do we charge the memory to the socket at all between
> the packet leaving the TCP stack and it entering the device?
Because it's easy to verify that it prevents all the possible
DoS scenerios a user could pl
Edgar E. Iglesias <[EMAIL PROTECTED]> wrote:
>
> It makes sense, but I see a problem with this. It will remove some of the
> control applications have on how much of their data gets queued on local
> queues. Small SNDBUF's are sometimes used to somewhat avoid/control latency.
For UDP yes but does
On Sun, Aug 06, 2006 at 05:36:55PM +1000, Herbert Xu wrote:
> On Sun, Aug 06, 2006 at 12:26:44AM -0700, David Miller wrote:
> >
> > Increasingly I find that orphan'ing an SKB once it hits the real
> > device for transmit is something to seriously consider.
>
> Yes that certainly makes a lot of se
On Sun, Aug 06, 2006 at 12:26:44AM -0700, David Miller wrote:
>
> Increasingly I find that orphan'ing an SKB once it hits the real
> device for transmit is something to seriously consider.
Yes that certainly makes a lot of sense.
Actually, why do we charge the memory to the socket at all between
On Sun, Aug 06, 2006 at 05:24:41PM +1000, Herbert Xu wrote:
> Edgar E. Iglesias <[EMAIL PROTECTED]> wrote:
> >
> > Not sure what you mean with "most of the time" but a while a go I played
> > around with a something like this for another driver. The tx path was
> > cleaning
> > up the tx ring a
Edgar E. Iglesias <[EMAIL PROTECTED]> wrote:
>
> Not sure what you mean with "most of the time" but a while a go I played
> around with a something like this for another driver. The tx path was
> cleaning
> up the tx ring at certain intervals while the tx irq-handler was not touching
> the rin
From: "Edgar E. Iglesias" <[EMAIL PROTECTED]>
Date: Sun, 6 Aug 2006 09:14:18 +0200
> Later I ended up throwing this away as it was causing some TCP
> connections to deadlock. If you let skb's sit in the tx-ring
> indefintely, the sk->sk_wmem_queued accounting will be inacurate and
> this was causi
On Sun, Aug 06, 2006 at 12:51:23PM +1000, Herbert Xu wrote:
>
> I wonder if we could do the TX clean up within the transmission
> routine most of the time. Has anyone tried this before?
>
Hi Herbert,
Not sure what you mean with "most of the time" but a while a go I played
around with a somethi
41 matches
Mail list logo
