* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Michael Büsch @ 2011-07-04 13:05 UTC (permalink / raw)
To: Alexey Zaytsev
Cc: Eric Dumazet, Andrew Morton, netdev, Gary Zambrano, bugme-daemon,
David S. Miller, Pekka Pietikainen, Florian Schirmer,
Felix Fietkau, Michael Buesch
In-Reply-To: <CAB9v_DG7e8vDE+4PDwuOR2DYG1FEvUM1fxa+e4a=swwTYGJ9nQ@mail.gmail.com>
On Mon, 4 Jul 2011 15:48:31 +0400
Alexey Zaytsev <alexey.zaytsev@gmail.com> wrote:
> The skb is reinserted into the ring before its data is copied, it
> seems. But this can't be the cause of my problem, as it would lead to
> data corruption at most, not a write-after-free.
Recycling the skb does not imply that the device can reuse it immediately. The device is told at the very end of the RX function (after the loop) that it's now safe to put stuff into the recyceled/new buffers.
> And an other question. Why so we have the logic to work-around the 1Gb
> DMA limit instead of just setting the dma mask?
Because the DMA mask does not work correctly on all arches for masks smaller than 4G.
And btw, I dont understand what that wmb() patch is supposed to fix. There may be a wmb() missing, but rather after the ctrl _and_ the address assignment to the descriptor.
But I don't think this can cause this use-after-free anyway.
^ permalink raw reply
* [PATCH] net/core: Make urgent data inline by default
From: Esa-Pekka Pyokkimies @ 2011-07-04 12:51 UTC (permalink / raw)
To: netdev
Make urgent data inline by default. As explained in RFC 6093, urgent
data should never be handled out-of-band.
"The TCP urgent mechanism is NOT a mechanism for sending "out-of-band"
data: the so-called "urgent data" should be delivered "in-line" to
the TCP user."
Signed-off-by: Esa-Pekka Pyokkimies <esa-pekka.pyokkimies@stonesoft.com>
---
net/core/sock.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 6e81978..83234bd 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1985,6 +1985,7 @@ void sock_init_data(struct socket *sock, struct sock
*sk)
sk_set_socket(sk, sock);
sock_set_flag(sk, SOCK_ZAPPED);
+ sock_set_flag(sk, SOCK_URGINLINE);
if (sock) {
sk->sk_type = sock->type;
^ permalink raw reply related
* Re: libpcap and tc filters
From: Adam Katz @ 2011-07-04 12:37 UTC (permalink / raw)
To: jhs; +Cc: netdev
In-Reply-To: <CAA0qwj70-qUQ+6NL=2LP05TyMN99MdL1BF8tko+v=DhdyjZjJQ@mail.gmail.com>
here's a more concrete example:
An example configuration:
sudo tc qdisc add dev eth1 root handle 1: prio priomap 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2
sudo tc qdisc add dev eth1 parent 1:1 handle 10: pfifo
sudo tc qdisc add dev eth1 parent 1:2 handle 20: pfifo
sudo tc qdisc add dev eth1 parent 1:3 handle 30: pfifo
sudo tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip
dport 22 0xffff flowid 1:1
sudo tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip
sport 22 0xffff flowid 1:1
sudo tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip
dport 80 0xffff flowid 1:2
sudo tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip
sport 80 0xffff flowid 1:2
I then used scp to copy a small file between computers while capturing
with wireshark:
http://dl.dropbox.com/u/3237005/port22example.pcap
and later I replayed the same capture using tcpreplay.
When using scp, the packets once again ended up where they should be
(1:1 in this configuration). With tcpreplay they ended up in the
default 1:3
On Mon, Jul 4, 2011 at 3:06 PM, jamal <hadi@cyberus.ca> wrote:
> On Mon, 2011-07-04 at 15:00 +0300, Adam Katz wrote:
>> Ok, I just tried this:
>>
>> I've opened www.example.com using a browser while capturing with
>> wireshark. TC placed all port 80 packets into the 1:1 as required. I
>> then physically plugged the nic to a different socket, one that isn't
>> connected to the internet (i did this so I wont get any server
>> responses to the packets i'm sending) and then I replayed the capture
>> of me opening www.example.com
>>
>> The second time, none of the packets ended up in 1:1 - they all went
>> to the default class despite being the EXACT same traffic.
>>
>
> Please post a small sample of the tcpdumps and the tc rules you used.
>
> cheers,
> jamal
>
>
On Mon, Jul 4, 2011 at 3:01 PM, Adam Katz <adamkatz0@gmail.com> wrote:
> Ok, I just tried this:
>
> I've opened www.example.com using a browser while capturing with
> wireshark. TC placed all port 80 packets into the 1:1 as required. I
> then physically plugged the nic to a different socket, one that isn't
> connected to the internet (i did this so I wont get any server
> responses to the packets i'm sending) and then I replayed the capture
> of me opening www.example.com
>
> The second time, none of the packets ended up in 1:1 - they all went
> to the default class despite being the EXACT same traffic.
>
> On Mon, Jul 4, 2011 at 2:11 PM, jamal <hadi@cyberus.ca> wrote:
>>
>> Capture tcpdump for both scenario that works and one
>> that doesnt.
>> Make sure the filters match your failing scenario.
>>
>> cheers,
>> jamal
>>
>> On Mon, 2011-07-04 at 10:38 +0300, Adam Katz wrote:
>>> Hi Everyone
>>>
>>> I'm sorry for littering the mailing list with this question, but no
>>> other place could help me..
>>>
>>> I'm attempting to use tc to shape traffic sent using libpcap, I'm
>>> doing this for a research project. I have a classful scheduler with
>>> several classes, to this scheduler I attach a few filters based on
>>> destination tcp ports.
>>>
>>> My problem is this: When sending packets using a normal userland
>>> socket, the filters work and I see the appropriate traffic entering
>>> the right class. BUT when sending packets with libpcap, all packets
>>> end up in the scheduler's default band as if the filters simply refuse
>>> to work.
>>>
>>> Can anyone suggest a solution?
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>
^ permalink raw reply
* RE: bnx2: FTQ dump on heavy workload(bnx2-2.0.23b + kernel 2.6.32.36)
From: MaoXiaoyun @ 2011-07-04 12:20 UTC (permalink / raw)
To: netdev; +Cc: mchan
In-Reply-To: <BLU157-w1411DC0D9D19FE3A6935F5DA5C0@phx.gbl>
Could it be caused by the similar timeout as http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c441b8d2cb2194b05550a558d6d95d8944e56a84.
Maybe timeout still happens in my test scenerino.
Well, from the patch, BNX2_MISC_ECO_HW_CTL is defined 0x000008cc. But I cannot find
the defines in programmer reference Guide.(NetXtremeII-PG203-R.pdf). Could some help
to point out for me or is the doc is out of date.
Also, is there a way to comfirm whether the timeout really happen? (which regisiter
shall I read?) Or is there a bigger timeout I can set?
thanks.
----------------------------------------
> From: tinnycloud@hotmail.com
> To: netdev@vger.kernel.org
> Subject: bnx2: FTQ dump on heavy workload(bnx2-2.0.23b + kernel 2.6.32.36)
> Date: Mon, 4 Jul 2011 15:40:01 +0800
>
>
> Hi:
>
> I met bnx2 FTQ dump over and over again during my testing on Xen live migration which generate
> heavy network workload.
>
> I have two physcial machine, both have xen 4.0.1 installed, and kernel 2.6.32.36, bnx2 2.0.23b.
> I start 15 Virtual Machines totoally, and doing migration between the host over and over again,
> about 16hours, the network will not work, and sometimes, it can reset successfully, sometimes, it
> cause kernel crash.
>
> I've tried debug some, add code in the driver. below is the code when FTQ happened.
> It looks like the NIC is stop transmit the packets, and cause timeout.
>
> BTW, cpu max_cstate=1 in my grub.
>
> Thanks.
>
> --------------
> static void
> bnx2_tx_timeout(struct net_device *dev)
> {
> struct bnx2 *bp = netdev_priv(dev);
> struct bnx2_napi *bnapi = &bp->bnx2_napi[0];
> struct bnx2_tx_ring_info *txr = &bnapi->tx_ring;
> struct bnx2_rx_ring_info *rxr = &bnapi->rx_ring;
> int i ;
> bnx2_dump_ftq(bp);
> bnx2_dump_state(bp);
> if (stop_on_tx_timeout) {
> printk(KERN_WARNING PFX
> "%s: prevent chip reset during tx timeout\n",
> bp->dev->name);
> smp_rmb();
> printk("last status idx %d \n", bnapi->last_status_idx);
> printk("hw_tx_cons %d, txr->hw_tx_conds %d txr->tx_prod %d txr->tx_cons %d\n",
> bnx2_get_hw_tx_cons(bnapi), txr->hw_tx_cons, txr->tx_prod, txr->tx_cons);
> printk("hw_rx_cons %d, txr->hw_rx_conds %d\n", bnx2_get_hw_rx_cons(bnapi), rxr->rx_cons);
> printk("sblk->status_attn_bits %d\n",bnapi->status_blk.msi->status_attn_bits);
> printk("sblk->status_attn_bits_ack %d\n",bnapi->status_blk.msi->status_attn_bits_ack);
> printk("bnx2_tx_avail %d \n",(bnx2_tx_avail(bp, txr)));
> printk("sblk->status_tx_quick_consumer_index0 %d\n",bnapi->status_blk.msi->status_tx_quick_consumer_index0);
> printk("sblk->status_tx_quick_consumer_index1 %d\n",bnapi->status_blk.msi->status_tx_quick_consumer_index1);
> printk("sblk->status_tx_quick_consumer_index2 %d\n",bnapi->status_blk.msi->status_tx_quick_consumer_index2);
> printk("sblk->status_tx_quick_consumer_index3 %d\n",bnapi->status_blk.msi->status_tx_quick_consumer_index3);
> printk("sblk->status_rx_quick_consumer_index0 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index0);
> printk("sblk->status_rx_quick_consumer_index1 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index1);
> printk("sblk->status_rx_quick_consumer_index2 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index2);
> printk("sblk->status_rx_quick_consumer_index3 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index3);
> printk("sblk->status_rx_quick_consumer_index4 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index4);
> printk("sblk->status_rx_quick_consumer_index5 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index5);
> printk("sblk->status_rx_quick_consumer_index6 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index6);
> printk("sblk->status_rx_quick_consumer_index7 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index7);
> printk("sblk->status_rx_quick_consumer_index8 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index8);
> printk("sblk->status_rx_quick_consumer_index9 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index9);
> printk("sblk->status_rx_quick_consumer_index10 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index10);
> printk("sblk->status_rx_quick_consumer_index11 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index11);
> printk("sblk->status_rx_quick_consumer_index12 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index12);
> printk("sblk->status_rx_quick_consumer_index13 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index13);
> printk("sblk->status_rx_quick_consumer_index14 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index14);
> printk("sblk->status_rx_quick_consumer_index15 %d\n",bnapi->status_blk.msi->status_rx_quick_consumer_index15);
> printk("sblk->status_completion_producer_index %d\n",bnapi->status_blk.msi->status_completion_producer_index);
> printk("sblk->status_cmd_consumer_index %d\n",bnapi->status_blk.msi->status_cmd_consumer_index);
> printk("sblk->status_idx %d\n",bnapi->status_blk.msi->status_idx);
> printk("sblk->status_unused %d\n",bnapi->status_blk.msi->status_unused);
> printk("sblk->status_blk_num %d\n",bnapi->status_blk.msi->status_blk_num);
> is_timedout = 1;
> for (i = 0; i < bp->irq_nvecs; i++) {
> bnapi = &bp->bnx2_napi[i];
> bnx2_tx_int(bp, bnapi, 0);
> }
> return;
> }
> -----------------
>
> -------------FTQ log in /var/log/message
> ------------[ cut here ]------------
> WARNING: at net/sched/sch_generic.c:261 dev_watchdog+0x105/0x16a()
> Hardware name: Tecal RH2285
> Modules linked in: iptable_filter ip_tables nfs fscache nfs_acl auth_rpcgss bridge stp llc autofs4 ipmi_devintf ipmi_si ipmi_msghandler lockd sunrpc ipv6 xenfs dm_multipath fuse xen_netback xen_blkback blktap blkback_pagemap loop nbd video output sbs sbshc parport_pc lp parport snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss bnx2 serio_raw snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 iTCO_wdt iTCO_vendor_support i2c_core pata_acpi ata_generic pcspkr ata_piix shpchp mptsas mptscsih mptbase [last unloaded: freq_table]
> Pid: 0, comm: swapper Not tainted 2.6.32.36xen #1
> Call Trace:
> <IRQ> [<ffffffff813ba154>] ? dev_watchdog+0x105/0x16a
> [<ffffffff81056666>] warn_slowpath_common+0x7c/0x94
> [<ffffffff81056738>] warn_slowpath_fmt+0xa4/0xa6
> [<ffffffff81080bfa>] ? clockevents_program_event+0x78/0x81
> [<ffffffff81081fce>] ? tick_program_event+0x2a/0x2c
> [<ffffffff813b951d>] ? __netif_tx_lock+0x1b/0x24
> [<ffffffff813b95a8>] ? netif_tx_lock+0x46/0x6e
> [<ffffffff813a3ed1>] ? netdev_drivername+0x48/0x4f
> [<ffffffff813ba154>] dev_watchdog+0x105/0x16a
> [<ffffffff81063d98>] run_timer_softirq+0x156/0x1f8
> [<ffffffff813ba04f>] ? dev_watchdog+0x0/0x16a
> [<ffffffff8105d6f0>] __do_softirq+0xd7/0x19e
> [<ffffffff81013eac>] call_softirq+0x1c/0x30
> [<ffffffff8101564b>] do_softirq+0x46/0x87
> [<ffffffff8105d575>] irq_exit+0x3b/0x7a
> [<ffffffff8128dcfe>] xen_evtchn_do_upcall+0x38/0x46
> [<ffffffff81013efe>] xen_do_hypervisor_callback+0x1e/0x30
> <EOI> [<ffffffff8103f642>] ? pick_next_task_idle+0x18/0x22
> [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1000
> [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1000
> [<ffffffff8100f1bb>] ? xen_safe_halt+0x10/0x1a
> [<ffffffff81019e14>] ? default_idle+0x39/0x56
> [<ffffffff81011cd0>] ? cpu_idle+0x5d/0x8c
> [<ffffffff8143375d>] ? cpu_bringup_and_idle+0x13/0x15
> ---[ end trace 867bb8f6cd959b03 ]---
> bnx2: <--- start FTQ dump on peth0 --->
> bnx2: peth0: BNX2_RV2P_PFTQ_CTL 10000
> bnx2: peth0: BNX2_RV2P_TFTQ_CTL 20000
> bnx2: peth0: BNX2_RV2P_MFTQ_CTL 4000
> bnx2: peth0: BNX2_TBDR_FTQ_CTL 1004002
> bnx2: peth0: BNX2_TDMA_FTQ_CTL 4010002
> bnx2: peth0: BNX2_TXP_FTQ_CTL 2410002
> bnx2: peth0: BNX2_TPAT_FTQ_CTL 10002
> bnx2: peth0: BNX2_RXP_CFTQ_CTL 8000
> bnx2: peth0: BNX2_RXP_FTQ_CTL 100000
> bnx2: peth0: BNX2_COM_COMXQ_FTQ_CTL 10000
> bnx2: peth0: BNX2_COM_COMTQ_FTQ_CTL 20000
> bnx2: peth0: BNX2_COM_COMQ_FTQ_CTL 10000
> bnx2: peth0: BNX2_CP_CPQ_FTQ_CTL 4000
> bnx2: peth0: TXP mode b84c state 80005000 evt_mask 500 pc 8000d60 pc 8000d60 instr 8f860000
> bnx2: peth0: TPAT mode b84c state 80009000 evt_mask 500 pc 8000a5c pc 8000a5c instr 10400016
> bnx2: peth0: RXP mode b84c state 80001000 evt_mask 500 pc 8004c14 pc 8004c14 instr 10e00088
> bnx2: peth0: COM mode b8cc state 80000000 evt_mask 500 pc 8000b28 pc 8000a9c instr 8c530000
> bnx2: peth0: CP mode b8cc state 80000000 evt_mask 500 pc 8000c50 pc 8000c58 instr 8ca50020
> bnx2: <--- end FTQ dump on peth0 --->
> bnx2: peth0 DEBUG: intr_sem[0]
> bnx2: peth0 DEBUG: intr_sem[0] PCI_CMD[20100406]
> bnx2: peth0 DEBUG: PCI_PM[19002008] PCI_MISC_CFG[92000088]
> bnx2: peth0 DEBUG: EMAC_TX_STATUS[00000008] EMAC_RX_STATUS[00000000]
> bnx2: peth0 RPM_MGMT_PKT_CTRL[40000088]
> bnx2: peth0 DEBUG: MCP_STATE_P0[0007e10e] MCP_STATE_P1[0003e00e]
> bnx2: peth0 DEBUG: HC_STATS_INTERRUPT_STATUS[01ff0000]
> bnx2: peth0 DEBUG: PBA[00000000]
> BNX2_PCICFG_INT_ACK_CMD[00013ce1]
> bnx2: peth0: prevent chip reset during tx timeout
> last status idx 2426
> hw_tx_cons 32474, txr->hw_tx_conds 32474 txr->tx_prod 32641 txr->tx_cons 32474
> hw_rx_cons 19665, txr->hw_rx_conds 19665
> sblk->status_attn_bits 1
> sblk->status_attn_bits_ack 1
> bnx2_tx_avail 88
> sblk->status_tx_quick_consumer_index0 32474
> sblk->status_tx_quick_consumer_index1 0
> sblk->status_tx_quick_consumer_index2 0
> sblk->status_tx_quick_consumer_index3 0
> sblk->status_rx_quick_consumer_index0 19665
> sblk->status_rx_quick_consumer_index1 0
> sblk->status_rx_quick_consumer_index2 0
> sblk->status_rx_quick_consumer_index3 0
> sblk->status_rx_quick_consumer_index4 0
> sblk->status_rx_quick_consumer_index5 0
> sblk->status_rx_quick_consumer_index6 0
> sblk->status_rx_quick_consumer_index7 0
> sblk->status_rx_quick_consumer_index8 0
> sblk->status_rx_quick_consumer_index9 0
> sblk->status_rx_quick_consumer_index10 0
> sblk->status_rx_quick_consumer_index11 0
> sblk->status_rx_quick_consumer_index12 0
> sblk->status_rx_quick_consumer_index13 0
> sblk->status_rx_quick_consumer_index14 0
> sblk->status_rx_quick_consumer_index15 0
> sblk->status_completion_producer_index 0
> sblk->status_cmd_consumer_index 0
> sblk->status_idx 2426
> sblk->status_unused 0
> sblk->status_blk_num 0
> hw_cons 32474 sw_cons 32474 ffff8801d27f85c0 bnapi
> return hw_cons 32474 sw_cons 32474 ffff8801d27f85c0 bnapi
> hw_cons 3628 sw_cons 3625 ffff8801d27f8bc0 bnapi
> return hw_cons 3628 sw_cons 3625 ffff8801d27f8bc0 bnapi
> hw_cons 62094 sw_cons 62090 ffff8801d27f91c0 bnapi
> return hw_cons 62094 sw_cons 62090 ffff8801d27f91c0 bnapi
> hw_cons 3184 sw_cons 3173 ffff8801d27f97c0 bnapi
> return hw_cons 3184 sw_cons 3173 ffff8801d27f97c0 bnapi
> hw_cons 0 sw_cons 0 ffff8801d27f9dc0 bnapi
> return hw_cons 0 sw_cons 0 ffff8801d27f9dc0 bnapi
^ permalink raw reply
* Re: libpcap and tc filters
From: Adam Katz @ 2011-07-04 12:01 UTC (permalink / raw)
To: jhs; +Cc: netdev
In-Reply-To: <1309777908.26180.1.camel@mojatatu>
Ok, I just tried this:
I've opened www.example.com using a browser while capturing with
wireshark. TC placed all port 80 packets into the 1:1 as required. I
then physically plugged the nic to a different socket, one that isn't
connected to the internet (i did this so I wont get any server
responses to the packets i'm sending) and then I replayed the capture
of me opening www.example.com
The second time, none of the packets ended up in 1:1 - they all went
to the default class despite being the EXACT same traffic.
On Mon, Jul 4, 2011 at 2:11 PM, jamal <hadi@cyberus.ca> wrote:
>
> Capture tcpdump for both scenario that works and one
> that doesnt.
> Make sure the filters match your failing scenario.
>
> cheers,
> jamal
>
> On Mon, 2011-07-04 at 10:38 +0300, Adam Katz wrote:
>> Hi Everyone
>>
>> I'm sorry for littering the mailing list with this question, but no
>> other place could help me..
>>
>> I'm attempting to use tc to shape traffic sent using libpcap, I'm
>> doing this for a research project. I have a classful scheduler with
>> several classes, to this scheduler I attach a few filters based on
>> destination tcp ports.
>>
>> My problem is this: When sending packets using a normal userland
>> socket, the filters work and I see the appropriate traffic entering
>> the right class. BUT when sending packets with libpcap, all packets
>> end up in the scheduler's default band as if the filters simply refuse
>> to work.
>>
>> Can anyone suggest a solution?
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Alexey Zaytsev @ 2011-07-04 11:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andrew Morton, netdev, Gary Zambrano, bugme-daemon,
David S. Miller, Pekka Pietikainen, Florian Schirmer,
Felix Fietkau, Michael Buesch
In-Reply-To: <1309707971.2523.20.camel@edumazet-laptop>
On Sun, Jul 3, 2011 at 19:46, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le dimanche 03 juillet 2011 à 01:25 +0400, Alexey Zaytsev a écrit :
>> On Fri, Jul 1, 2011 at 10:01, Alexey Zaytsev <alexey.zaytsev@gmail.com> wrote:
>> > 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.
>> >
>>
>> I've checked back as far as 2.6.27, and the problem is still there.
>> I've also looked through the allocation-related code, and it seemed
>> sane. I'm not sure I understand the 1GB dma workaround, but this path
>> is never hit in my case. So adding the driver authors to CC. This
>> could be something different, but I've been unable to reproduce using
>> an other machine with an rtl8139 nic.
>
> Hmm, looking at b44 code, I believe there is a race there.
>
> Could you try following patch ?
>
This might fix a potential problem, but unfortunately did not help here.
There is an other place that looks suspicious to me:
812 struct sk_buff *copy_skb;
813
814 b44_recycle_rx(bp, cons, bp->rx_prod);
815 copy_skb = netdev_alloc_skb(bp->dev, len + 2);
816 if (copy_skb == NULL)
817 goto drop_it_no_recycle;
818
819 skb_reserve(copy_skb, 2);
820 skb_put(copy_skb, len);
821 /* DMA sync done above, copy just the
actual packet */
822 skb_copy_from_linear_data_offset(skb,
RX_PKT_OFFSET,
823
copy_skb->data, len);
824 skb = copy_skb;
The skb is reinserted into the ring before its data is copied, it
seems. But this can't be the cause of my problem, as it would lead to
data corruption at most, not a write-after-free.
And an other question. Why so we have the logic to work-around the 1Gb
DMA limit instead of just setting the dma mask?
^ permalink raw reply
* [PATCH] net: bind() fix error return on wrong address family
From: Marcus Meissner @ 2011-07-04 11:30 UTC (permalink / raw)
To: davem, kuznet, pekkas, jmorris, yoshfuji, kaber, netdev,
linux-kernel
Cc: Marcus Meissner, Marcus Meissner, Reinhard Max
Hi,
Reinhard Max also pointed out that the error should EAFNOSUPPORT according
to POSIX.
The Linux manpages have it as EINVAL, some other OSes (Minix, HPUX, perhaps BSD) use
EAFNOSUPPORT. Windows uses WSAEFAULT according to MSDN.
Other protocols error values in their af bind() methods in current mainline git as far
as a brief look shows:
EAFNOSUPPORT: atm, appletalk, l2tp, llc, phonet, rxrpc
EINVAL: ax25, bluetooth, decnet, econet, ieee802154, iucv, netlink, netrom, packet, rds, rose, unix, x25,
No check?: can/raw, ipv6/raw, irda, l2tp/l2tp_ip
Ciao, Marcus
Signed-off-by: Marcus Meissner <meissner@suse.de>
Cc: Reinhard Max <max@suse.de>
---
net/ipv4/af_inet.c | 4 +++-
net/ipv6/af_inet6.c | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index eae1f67..ef1528a 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -465,8 +465,10 @@ int inet_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
if (addr_len < sizeof(struct sockaddr_in))
goto out;
- if (addr->sin_family != AF_INET)
+ if (addr->sin_family != AF_INET) {
+ err = -EAFNOSUPPORT;
goto out;
+ }
chk_addr_ret = inet_addr_type(sock_net(sk), addr->sin_addr.s_addr);
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index d450a2f..3b5669a 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -274,7 +274,7 @@ int inet6_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
return -EINVAL;
if (addr->sin6_family != AF_INET6)
- return -EINVAL;
+ return -EAFNOSUPPORT;
addr_type = ipv6_addr_type(&addr->sin6_addr);
if ((addr_type & IPV6_ADDR_MULTICAST) && sock->type == SOCK_STREAM)
--
1.7.5.4
^ permalink raw reply related
* Re: libpcap and tc filters
From: jamal @ 2011-07-04 11:11 UTC (permalink / raw)
To: Adam Katz; +Cc: netdev
In-Reply-To: <CAA0qwj6fWJFVCDW9M9jZhvQnSTy=Pnyp0AhWFYT8FOiroq7C=Q@mail.gmail.com>
Capture tcpdump for both scenario that works and one
that doesnt.
Make sure the filters match your failing scenario.
cheers,
jamal
On Mon, 2011-07-04 at 10:38 +0300, Adam Katz wrote:
> Hi Everyone
>
> I'm sorry for littering the mailing list with this question, but no
> other place could help me..
>
> I'm attempting to use tc to shape traffic sent using libpcap, I'm
> doing this for a research project. I have a classful scheduler with
> several classes, to this scheduler I attach a few filters based on
> destination tcp ports.
>
> My problem is this: When sending packets using a normal userland
> socket, the filters work and I see the appropriate traffic entering
> the right class. BUT when sending packets with libpcap, all packets
> end up in the scheduler's default band as if the filters simply refuse
> to work.
>
> Can anyone suggest a solution?
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] greth: greth_set_mac_add would corrupt the MAC address.
From: Kristoffer Glembo @ 2011-07-04 9:08 UTC (permalink / raw)
To: netdev; +Cc: Kristoffer Glembo
The MAC address was set using the signed char sockaddr->sa_addr
field and thus the address could be corrupted through sign extension.
Signed-off-by: Kristoffer Glembo <kristoffer@gaisler.com>
---
drivers/net/greth.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index 82c3767..16ce45c 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -1017,11 +1017,10 @@ static int greth_set_mac_add(struct net_device *dev, void *p)
return -EINVAL;
memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
+ GRETH_REGSAVE(regs->esa_msb, dev->dev_addr[0] << 8 | dev->dev_addr[1]);
+ GRETH_REGSAVE(regs->esa_lsb, dev->dev_addr[2] << 24 | dev->dev_addr[3] << 16 |
+ dev->dev_addr[4] << 8 | dev->dev_addr[5]);
- GRETH_REGSAVE(regs->esa_msb, addr->sa_data[0] << 8 | addr->sa_data[1]);
- GRETH_REGSAVE(regs->esa_lsb,
- addr->sa_data[2] << 24 | addr->
- sa_data[3] << 16 | addr->sa_data[4] << 8 | addr->sa_data[5]);
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-next] net/wireless: ipw2x00: Use helpers from linux/etherdevice.h
From: Tobias Klauser @ 2011-07-04 10:00 UTC (permalink / raw)
To: David S. Miller, John W. Linville; +Cc: netdev, linux-wireless
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/wireless/ipw2x00/libipw_rx.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/libipw_rx.c b/drivers/net/wireless/ipw2x00/libipw_rx.c
index e5ad76c..32a9966 100644
--- a/drivers/net/wireless/ipw2x00/libipw_rx.c
+++ b/drivers/net/wireless/ipw2x00/libipw_rx.c
@@ -442,7 +442,7 @@ int libipw_rx(struct libipw_device *ieee, struct sk_buff *skb,
* 802.11, but makes it easier to use different keys with
* stations that do not support WEP key mapping). */
- if (!(hdr->addr1[0] & 0x01) || local->bcrx_sta_key)
+ if (is_unicast_ether_addr(hdr->addr1) || local->bcrx_sta_key)
(void)hostap_handle_sta_crypto(local, hdr, &crypt,
&sta);
#endif
@@ -772,7 +772,7 @@ int libipw_rx(struct libipw_device *ieee, struct sk_buff *skb,
#ifdef NOT_YET
if (ieee->iw_mode == IW_MODE_MASTER && !wds && ieee->ap->bridge_packets) {
- if (dst[0] & 0x01) {
+ if (is_multicast_ether_addr(dst)) {
/* copy multicast frame both to the higher layers and
* to the wireless media */
ieee->ap->bridged_multicast++;
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next] net: vxge: Use is_multicast_ether_addr helper
From: Tobias Klauser @ 2011-07-04 9:58 UTC (permalink / raw)
To: David S. Miller, Jon Mason; +Cc: netdev
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/vxge/vxge-main.c | 14 +++++---------
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/net/vxge/vxge-main.c b/drivers/net/vxge/vxge-main.c
index 1c92af3..15d878b 100644
--- a/drivers/net/vxge/vxge-main.c
+++ b/drivers/net/vxge/vxge-main.c
@@ -684,8 +684,7 @@ static int vxge_mac_list_add(struct vxge_vpath *vpath, struct macInfo *mac)
new_mac_entry->state = mac->state;
vpath->mac_addr_cnt++;
- /* Is this a multicast address */
- if (0x01 & mac->macaddr[0])
+ if (is_multicast_ether_addr(mac->macaddr))
vpath->mcast_addr_cnt++;
return TRUE;
@@ -699,7 +698,7 @@ vxge_add_mac_addr(struct vxgedev *vdev, struct macInfo *mac)
struct vxge_vpath *vpath;
enum vxge_hw_vpath_mac_addr_add_mode duplicate_mode;
- if (0x01 & mac->macaddr[0]) /* multicast address */
+ if (is_multicast_ether_addr(mac->macaddr))
duplicate_mode = VXGE_HW_VPATH_MAC_ADDR_ADD_DUPLICATE;
else
duplicate_mode = VXGE_HW_VPATH_MAC_ADDR_REPLACE_DUPLICATE;
@@ -1078,8 +1077,7 @@ static int vxge_mac_list_del(struct vxge_vpath *vpath, struct macInfo *mac)
kfree((struct vxge_mac_addrs *)entry);
vpath->mac_addr_cnt--;
- /* Is this a multicast address */
- if (0x01 & mac->macaddr[0])
+ if (is_multicast_ether_addr(mac->macaddr))
vpath->mcast_addr_cnt--;
return TRUE;
}
@@ -1201,8 +1199,7 @@ static void vxge_set_multicast(struct net_device *dev)
mac_address = (u8 *)&mac_entry->macaddr;
memcpy(mac_info.macaddr, mac_address, ETH_ALEN);
- /* Is this a multicast address */
- if (0x01 & mac_info.macaddr[0]) {
+ if (is_multicast_ether_addr(mac_info.macaddr)) {
for (vpath_idx = 0; vpath_idx <
vdev->no_of_vpath;
vpath_idx++) {
@@ -1244,8 +1241,7 @@ _set_all_mcast:
mac_address = (u8 *)&mac_entry->macaddr;
memcpy(mac_info.macaddr, mac_address, ETH_ALEN);
- /* Is this a multicast address */
- if (0x01 & mac_info.macaddr[0])
+ if (is_multicast_ether_addr(mac_info.macaddr))
break;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next] net: ewrk3: Use helpers from linux/etherdevice.h
From: Tobias Klauser @ 2011-07-04 9:56 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/ewrk3.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ewrk3.c b/drivers/net/ewrk3.c
index b5f6173..d1e229f 100644
--- a/drivers/net/ewrk3.c
+++ b/drivers/net/ewrk3.c
@@ -1008,15 +1008,13 @@ static int ewrk3_rx(struct net_device *dev)
}
}
p = skb->data; /* Look at the dest addr */
- if (p[0] & 0x01) { /* Multicast/Broadcast */
- if ((*(s16 *) & p[0] == -1) && (*(s16 *) & p[2] == -1) && (*(s16 *) & p[4] == -1)) {
+ if (is_multicast_ether_addr(p)) {
+ if (is_broadcast_ether_addr(p)) {
lp->pktStats.broadcast++;
} else {
lp->pktStats.multicast++;
}
- } else if ((*(s16 *) & p[0] == *(s16 *) & dev->dev_addr[0]) &&
- (*(s16 *) & p[2] == *(s16 *) & dev->dev_addr[2]) &&
- (*(s16 *) & p[4] == *(s16 *) & dev->dev_addr[4])) {
+ } else if (compare_ether_addr(p, dev->dev_addr) == 0) {
lp->pktStats.unicast++;
}
lp->pktStats.bins[0]++; /* Duplicates stats.rx_packets */
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next] net: depca: Use helpers from linux/etherdevice.h
From: Tobias Klauser @ 2011-07-04 9:55 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/depca.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/depca.c b/drivers/net/depca.c
index a7ccaa6..f2015a8 100644
--- a/drivers/net/depca.c
+++ b/drivers/net/depca.c
@@ -1073,13 +1073,13 @@ static int depca_rx(struct net_device *dev)
i = DEPCA_PKT_STAT_SZ;
}
}
- if (buf[0] & 0x01) { /* Multicast/Broadcast */
- if ((*(s16 *) & buf[0] == -1) && (*(s16 *) & buf[2] == -1) && (*(s16 *) & buf[4] == -1)) {
+ if (is_multicast_ether_addr(buf)) {
+ if (is_broadcast_ether_addr(buf)) {
lp->pktStats.broadcast++;
} else {
lp->pktStats.multicast++;
}
- } else if ((*(s16 *) & buf[0] == *(s16 *) & dev->dev_addr[0]) && (*(s16 *) & buf[2] == *(s16 *) & dev->dev_addr[2]) && (*(s16 *) & buf[4] == *(s16 *) & dev->dev_addr[4])) {
+ } else if (compare_ether_addr(buf, dev->dev_addr) == 0) {
lp->pktStats.unicast++;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next] net: rionet: Use is_multicast_ether_addr
From: Tobias Klauser @ 2011-07-04 9:54 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/rionet.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/rionet.c b/drivers/net/rionet.c
index 77c5092..bcdc54f 100644
--- a/drivers/net/rionet.c
+++ b/drivers/net/rionet.c
@@ -190,7 +190,7 @@ static int rionet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
return NETDEV_TX_BUSY;
}
- if (eth->h_dest[0] & 0x01) {
+ if (is_multicast_ether_addr(eth->h_dest)) {
for (i = 0; i < RIO_MAX_ROUTE_ENTRIES(rnet->mport->sys_size);
i++)
if (rionet_active[i])
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next] net: iseries_veth: Use is_unicast_ether_addr helper
From: Tobias Klauser @ 2011-07-04 9:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/iseries_veth.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/iseries_veth.c b/drivers/net/iseries_veth.c
index 242bf52..53dd39e 100644
--- a/drivers/net/iseries_veth.c
+++ b/drivers/net/iseries_veth.c
@@ -1182,7 +1182,7 @@ static int veth_start_xmit(struct sk_buff *skb, struct net_device *dev)
struct veth_port *port = netdev_priv(dev);
HvLpIndexMap lpmask;
- if (! (frame[0] & 0x01)) {
+ if (is_unicast_ether_addr(frame)) {
/* unicast packet */
HvLpIndex rlp = frame[5];
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next] net: igb: Use is_multicast_ether_addr helper
From: Tobias Klauser @ 2011-07-04 9:50 UTC (permalink / raw)
To: David S. Miller, Jeff Kirsher; +Cc: e1000-devel, netdev
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/igb/e1000_mac.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/igb/e1000_mac.c b/drivers/net/igb/e1000_mac.c
index ce8255f..c822904 100644
--- a/drivers/net/igb/e1000_mac.c
+++ b/drivers/net/igb/e1000_mac.c
@@ -29,6 +29,7 @@
#include <linux/delay.h>
#include <linux/pci.h>
#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
#include "e1000_mac.h"
@@ -217,7 +218,7 @@ s32 igb_check_alt_mac_addr(struct e1000_hw *hw)
}
/* if multicast bit is set, the alternate address will not be used */
- if (alt_mac_addr[0] & 0x01) {
+ if (is_multicast_ether_addr(alt_mac_addr)) {
hw_dbg("Ignoring Alternate Mac Address with MC bit set\n");
goto out;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next] net: de4x5: Use helpers from linux/etherdevice.h
From: Tobias Klauser @ 2011-07-04 9:48 UTC (permalink / raw)
To: David S. Miller, Grant Grundler; +Cc: netdev
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/tulip/de4x5.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tulip/de4x5.c b/drivers/net/tulip/de4x5.c
index d8db2b6..959b410 100644
--- a/drivers/net/tulip/de4x5.c
+++ b/drivers/net/tulip/de4x5.c
@@ -1868,14 +1868,13 @@ de4x5_local_stats(struct net_device *dev, char *buf, int pkt_len)
i = DE4X5_PKT_STAT_SZ;
}
}
- if (buf[0] & 0x01) { /* Multicast/Broadcast */
- if ((*(s32 *)&buf[0] == -1) && (*(s16 *)&buf[4] == -1)) {
+ if (is_multicast_ether_addr(buf)) {
+ if (is_broadcast_ether_addr(buf)) {
lp->pktStats.broadcast++;
} else {
lp->pktStats.multicast++;
}
- } else if ((*(s32 *)&buf[0] == *(s32 *)&dev->dev_addr[0]) &&
- (*(s16 *)&buf[4] == *(s16 *)&dev->dev_addr[4])) {
+ } else if (compare_ether_addr(buf, dev->dev_addr) == 0) {
lp->pktStats.unicast++;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next] net: e1000e: Use is_multicast_ether_addr helper
From: Tobias Klauser @ 2011-07-04 9:47 UTC (permalink / raw)
To: David S. Miller, Jeff Kirsher; +Cc: e1000-devel, netdev
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/e1000e/lib.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000e/lib.c b/drivers/net/e1000e/lib.c
index dd8ab05..b85b3ca 100644
--- a/drivers/net/e1000e/lib.c
+++ b/drivers/net/e1000e/lib.c
@@ -220,7 +220,7 @@ s32 e1000_check_alt_mac_addr_generic(struct e1000_hw *hw)
}
/* if multicast bit is set, the alternate address will not be used */
- if (alt_mac_addr[0] & 0x01) {
+ if (is_multicast_ether_addr(alt_mac_addr)) {
e_dbg("Ignoring Alternate Mac Address with MC bit set\n");
goto out;
}
--
1.7.5.4
^ permalink raw reply related
* Re: lost NETIF_F_GRO in cxgb3 during conversion to hw_features?
From: David Miller @ 2011-07-04 9:27 UTC (permalink / raw)
To: JBeulich; +Cc: mirq-linux, netdev
In-Reply-To: <4E11A1D0020000780004BFA7@nat28.tlf.novell.com>
From: "Jan Beulich" <JBeulich@novell.com>
Date: Mon, 04 Jul 2011 10:19:44 +0100
> prior to that change of yours, the flag was set unconditionally, while
> now it can be set only through the ioctl. Is that really correct?
Have a look at net/core/dev.c:register_netdevice()
These things get set by default in both ->hw_features and ->features
now.
^ permalink raw reply
* Re: [PATCH 1/2] netpoll: Remove unused EXPORT_SYMBOLs of netpoll_poll and netpoll_poll_dev
From: Harry Wei @ 2011-07-04 9:27 UTC (permalink / raw)
To: Joe Perches; +Cc: amwang, linux-kernel, davem, netdev
In-Reply-To: <1309765589.18925.42.camel@Joe-Laptop>
On Mon, Jul 04, 2011 at 12:46:29AM -0700, Joe Perches wrote:
[...]
> > You have removed the function declaration in include/linux/netpoll.h.
>
> Because it's unused by anything in the tree
> but netpoll.c
Hmmmm..., so sorry. I misunderstood your 'unused', which i thought
there was also no use in netpoll.c :-/
>
> > And you changed the function like
> > static void netpoll_poll_dev(...)
> > {
> > ...
> > }
> > But i don't know its usage.
>
> It's now a local function to netpoll.c
Yeah, it's true.
>
> > The 'static' before this function just says the active area of 'netpoll_poll_dev'
> > is in the file net/core/netpoll.c. What is the purpose? Could you please tell me?
>
> It prods the device to perform network work.
>
> /* Process pending work on NIC */
> ops->ndo_poll_controller(dev);
>
> poll_napi(dev);
Yeah, i will read the codes.
Thanks so much
Harry Wei
^ permalink raw reply
* lost NETIF_F_GRO in cxgb3 during conversion to hw_features?
From: Jan Beulich @ 2011-07-04 9:19 UTC (permalink / raw)
To: mirq-linux@rere.qmqm.pl; +Cc: davem, netdev
Hello,
prior to that change of yours, the flag was set unconditionally, while
now it can be set only through the ioctl. Is that really correct?
Thanks, Jan
^ permalink raw reply
* [PATCH 2/2] Update documented default values for various TCP/UDP tunables
From: Max Matveev @ 2011-06-22 7:18 UTC (permalink / raw)
To: linux-sctp; +Cc: netdev
tcp_rmem and tcp_wmem use 1 page as default value for the minimum
amount of memory to be used, same as udp_wmem_min and udp_rmem_min.
Pages are different size on different architectures - use the right
units when describing the defaults.
Signed-off-by: Max Matveev <makc@redhat.com>
---
Documentation/networking/ip-sysctl.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index f37d374..387ee53 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -394,7 +394,7 @@ tcp_rmem - vector of 3 INTEGERs: min, default, max
min: Minimal size of receive buffer used by TCP sockets.
It is guaranteed to each TCP socket, even under moderate memory
pressure.
- Default: 8K
+ Default: 1 page
default: initial size of receive buffer used by TCP sockets.
This value overrides net.core.rmem_default used by other protocols.
@@ -483,7 +483,7 @@ tcp_window_scaling - BOOLEAN
tcp_wmem - vector of 3 INTEGERs: min, default, max
min: Amount of memory reserved for send buffers for TCP sockets.
Each TCP socket has rights to use it due to fact of its birth.
- Default: 4K
+ Default: 1 page
default: initial size of send buffer used by TCP sockets. This
value overrides net.core.wmem_default used by other protocols.
@@ -553,13 +553,13 @@ udp_rmem_min - INTEGER
Minimal size of receive buffer used by UDP sockets in moderation.
Each UDP socket is able to use the size for receiving data, even if
total pages of UDP sockets exceed udp_mem pressure. The unit is byte.
- Default: 4096
+ Default: 1 page
udp_wmem_min - INTEGER
Minimal size of send buffer used by UDP sockets in moderation.
Each UDP socket is able to use the size for sending data, even if
total pages of UDP sockets exceed udp_mem pressure. The unit is byte.
- Default: 4096
+ Default: 1 page
CIPSOv4 Variables:
--
1.7.3.3
^ permalink raw reply related
* [PATCH 1/2] Update description of net.sctp.sctp_rmem and net.sctp.sctp_wmem tunables
From: Max Matveev @ 2011-06-20 8:08 UTC (permalink / raw)
To: linux-sctp; +Cc: netdev
sctp does not use second and third ("default" and "max") values
of sctp_(r|w)mem tunables. The format is the same and tcp_(r|w)mem
but the meaning is different so make the documentation explicit to
avoid confusion.
Signed-off-by: Max Matveev <makc@redhat.com>
---
Documentation/networking/ip-sysctl.txt | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index d3d653a..f37d374 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1465,10 +1465,17 @@ sctp_mem - vector of 3 INTEGERs: min, pressure, max
Default is calculated at boot time from amount of available memory.
sctp_rmem - vector of 3 INTEGERs: min, default, max
- See tcp_rmem for a description.
+ Only the first value ("min") is used, "default" and "max" are
+ ignored and may be removed in the future versions.
+
+ min: Minimal size of receive buffer used by SCTP socket.
+ It is guaranteed to each STCP socket (but not association) even
+ under moderate memory pressure.
+
+ Default: 1 page
sctp_wmem - vector of 3 INTEGERs: min, default, max
- See tcp_wmem for a description.
+ Currently this tunable has no effect.
addr_scope_policy - INTEGER
Control IPv4 address scoping - draft-stewart-tsvwg-sctp-ipv4-00
--
1.7.3.3
^ permalink raw reply related
* [PATCH 0/2] Minor documentation updates for ip-related tunables
From: Max Matveev @ 2011-07-04 8:28 UTC (permalink / raw)
To: linux-sctp; +Cc: netdev
Confusion about the way SCTP uses its rmem and wmem tunables
prompted a documentation revision.
Max Matveev (2):
Update description of net.sctp.sctp_rmem and net.sctp.sctp_wmem tunables
Update documented default values for various TCP/UDP tunables
Documentation/networking/ip-sysctl.txt | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
--
1.7.3.3
^ permalink raw reply
* Re: libpcap and tc filters
From: Eric Dumazet @ 2011-07-04 10:20 UTC (permalink / raw)
To: Adam Katz; +Cc: netdev
In-Reply-To: <CAA0qwj6fWJFVCDW9M9jZhvQnSTy=Pnyp0AhWFYT8FOiroq7C=Q@mail.gmail.com>
Le lundi 04 juillet 2011 à 10:38 +0300, Adam Katz a écrit :
> Hi Everyone
>
> I'm sorry for littering the mailing list with this question, but no
> other place could help me..
>
> I'm attempting to use tc to shape traffic sent using libpcap, I'm
> doing this for a research project. I have a classful scheduler with
> several classes, to this scheduler I attach a few filters based on
> destination tcp ports.
>
> My problem is this: When sending packets using a normal userland
> socket, the filters work and I see the appropriate traffic entering
> the right class. BUT when sending packets with libpcap, all packets
> end up in the scheduler's default band as if the filters simply refuse
> to work.
>
> Can anyone suggest a solution?
> --
You already asked this yesterday.
No need to repost.
4th July is not the day many people will answer you...
What gives :
tc -s -d filter show dev eth0
^ 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