* [PATCHv3 0/9] macb: add support for Cadence GEM
From: Jamie Iles @ 2011-08-09 9:16 UTC (permalink / raw)
To: netdev, linux-arm-kernel; +Cc: plagnioj, Jamie Iles
This is largely a repost of the series I posted back in March. The only changes
since then are rebasing onto 3.1-rc1 and changing the gem conditionals from a
boolean in the macb structure to an inline helper as requested by
Jean-Christophe.
This has been run-tested on picoxcell and compile tested for all AT91 platforms
but I couldn't get a working cross compiler for avr32.
All patches are available in a git branch at
git://github.com/jamieiles/linux-2.6-ji.git macb-gem
Jamie Iles (9):
at91: provide macb clks with "pclk" and "hclk" name
macb: remove conditional clk handling
macb: unify at91 and avr32 platform data
macb: convert printk to netdev_ and friends
macb: initial support for Cadence GEM
macb: support higher rate GEM MDIO clock divisors
macb: support statistics for GEM devices
macb: support DMA bus widths > 32 bits
macb: allow GEM to have configurable receive buffer size
arch/arm/mach-at91/at91cap9.c | 8 +-
arch/arm/mach-at91/at91cap9_devices.c | 6 +-
arch/arm/mach-at91/at91rm9200_devices.c | 6 +-
arch/arm/mach-at91/at91sam9260.c | 8 +-
arch/arm/mach-at91/at91sam9260_devices.c | 6 +-
arch/arm/mach-at91/at91sam9263.c | 8 +-
arch/arm/mach-at91/at91sam9263_devices.c | 6 +-
arch/arm/mach-at91/at91sam9g45.c | 8 +-
arch/arm/mach-at91/at91sam9g45_devices.c | 6 +-
arch/arm/mach-at91/board-1arm.c | 2 +-
arch/arm/mach-at91/board-afeb-9260v1.c | 2 +-
arch/arm/mach-at91/board-cam60.c | 2 +-
arch/arm/mach-at91/board-cap9adk.c | 2 +-
arch/arm/mach-at91/board-carmeva.c | 2 +-
arch/arm/mach-at91/board-cpu9krea.c | 2 +-
arch/arm/mach-at91/board-cpuat91.c | 2 +-
arch/arm/mach-at91/board-csb337.c | 2 +-
arch/arm/mach-at91/board-csb637.c | 2 +-
arch/arm/mach-at91/board-eb9200.c | 2 +-
arch/arm/mach-at91/board-ecbat91.c | 2 +-
arch/arm/mach-at91/board-eco920.c | 2 +-
arch/arm/mach-at91/board-foxg20.c | 2 +-
arch/arm/mach-at91/board-gsia18s.c | 2 +-
arch/arm/mach-at91/board-kafa.c | 2 +-
arch/arm/mach-at91/board-kb9202.c | 2 +-
arch/arm/mach-at91/board-neocore926.c | 2 +-
arch/arm/mach-at91/board-pcontrol-g20.c | 2 +-
arch/arm/mach-at91/board-picotux200.c | 2 +-
arch/arm/mach-at91/board-qil-a9260.c | 2 +-
arch/arm/mach-at91/board-rm9200dk.c | 2 +-
arch/arm/mach-at91/board-rm9200ek.c | 2 +-
arch/arm/mach-at91/board-sam9-l9260.c | 2 +-
arch/arm/mach-at91/board-sam9260ek.c | 2 +-
arch/arm/mach-at91/board-sam9263ek.c | 2 +-
arch/arm/mach-at91/board-sam9g20ek.c | 2 +-
arch/arm/mach-at91/board-sam9m10g45ek.c | 2 +-
arch/arm/mach-at91/board-snapper9260.c | 2 +-
arch/arm/mach-at91/board-stamp9g20.c | 2 +-
arch/arm/mach-at91/board-usb-a9260.c | 2 +-
arch/arm/mach-at91/board-usb-a9263.c | 2 +-
arch/arm/mach-at91/board-yl-9200.c | 2 +-
arch/arm/mach-at91/include/mach/board.h | 14 +-
arch/avr32/boards/atngw100/setup.c | 2 +-
arch/avr32/boards/atstk1000/atstk1002.c | 2 +-
arch/avr32/boards/favr-32/setup.c | 2 +-
arch/avr32/boards/hammerhead/setup.c | 2 +-
arch/avr32/boards/merisc/setup.c | 2 +-
arch/avr32/boards/mimc200/setup.c | 2 +-
arch/avr32/mach-at32ap/at32ap700x.c | 8 +-
arch/avr32/mach-at32ap/include/mach/board.h | 7 +-
drivers/net/Kconfig | 8 +-
drivers/net/arm/at91_ether.c | 3 +-
drivers/net/arm/at91_ether.h | 4 +-
drivers/net/macb.c | 340 +++++++++++++++++----------
drivers/net/macb.h | 150 ++++++++++++-
include/linux/platform_data/macb.h | 17 ++
56 files changed, 486 insertions(+), 203 deletions(-)
create mode 100644 include/linux/platform_data/macb.h
--
1.7.4.1
^ permalink raw reply
* Re: BUG: null pointer deref in rt2800usb_get_txwi
From: Gertjan van Wingerde @ 2011-08-09 9:01 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: Netdev, linux-wireless, Stanislaw Gruszka
In-Reply-To: <4E40EE85.3020208@pengutronix.de>
Hi Marc,
On Tue, Aug 9, 2011 at 10:23 AM, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> Hello,
>
> I'm a running a sheeva plug (ARM/kirkwood) with a rt2800 USB stick in AP mode.
> Bus 001 Device 002: ID 1737:0071 Linksys WUSB600N v1 Dual-Band Wireless-N Network Adapter [Ralink RT2870]
>
> kernel is v3.0.1 +
> 00898a47269ae5e6dda04defad00234b96692d95 rt2x00: fix usage of NULL queue
> b52398b6e4522176dd125722c72c301015d24520 rt2x00: rt2800: fix zeroing skb structure
>
> Which is here for reference:
> (http://git.pengutronix.de/?p=mkl/linux-2.6.git;a=shortlog;h=refs/heads/wireless/rt2x00/v3.0.1)
>
> The Kernel crashes after ~1d with this oopses:
> (Same oops with stock v3.0.0 and v3.0.1)
>
> [69638.429744] Unable to handle kernel NULL pointer dereference at virtual address 000000ac
> [69638.438515] pgd = c0004000
> [69638.441322] [000000ac] *pgd=00000000
> [69638.444974] Internal error: Oops: 17 [#1]
> [69638.449001] Modules linked in: nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc bridge ipv6 stp ext2 arc4 rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00
> lib mac80211 cfg80211 rfkill hmac sha1_generic mv_cesa aes_generic ext4 mbcache jbd2 mmc_block ehci_hcd mvsdio usbcore mmc_core mv643xx_eth libphy inet_lro
> [69638.476620] CPU: 0 Not tainted (3.0.1-100-bs-kirkwood+ #3)
> [69638.482489] PC is at rt2800usb_get_txwi+0x10/0x1c [rt2800usb]
> [69638.488273] LR is at rt2800_txdone_entry+0x34/0xe0 [rt2800lib]
> [69638.494131] pc : [<bf1bb194>] lr : [<bf1affa4>] psr: 80000013
> [69638.494136] sp : de44df08 ip : 00000001 fp : 00000022
> [69638.505672] r10: 0000000e r9 : 00000001 r8 : 0000003c
> [69638.510914] r7 : 00000000 r6 : de6aafc0 r5 : 818c22fd r4 : de6d99c8
> [69638.517472] r3 : 00000000 r2 : 00000000 r1 : 818c22fd r0 : de6d99c8
> [69638.524030] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> [69638.531371] Control: 0005397f Table: 0105c000 DAC: 00000017
> [69638.537144] Process kworker/u:0 (pid: 2089, stack limit = 0xde44c270)
> [69638.543614] Stack: (0xde44df08 to 0xde44e000)
> [69638.547997] df00: 00000000 818c22fd 00000000 de6aafc0 de6d99c8 818c22fd
> [69638.556221] df20: df958eb4 bf1b0128 c041a384 de6aafc0 df959600 de6ab3c4 de6ab3c4 c043defc
> [69638.564443] df40: 00000089 00000012 00000000 bf1bba00 de6ab3c4 c043defc 00000000 df8b86a0
> [69638.572666] df60: df959600 bf1bb9e8 de6ab3c4 c043defc 00000089 00000012 00000000 c005beac
> [69638.580881] df80: df8b86a0 df959605 00000081 df8b86a0 de44c000 c043defc c043def4 df8b86b0
> [69638.589103] dfa0: 00000089 c043defc 00000000 c005ca38 de4c7f30 df8b86a0 c005c878 00000013
> [69638.597325] dfc0: 00000000 00000000 00000000 c005fdcc 00000000 00000000 df8b86a0 00000000
> [69638.605542] dfe0: de44dfe0 de44dfe0 de4c7f30 c005fd50 c0030a94 c0030a94 ebfffffe e3500000
> [69638.613787] [<bf1bb194>] (rt2800usb_get_txwi+0x10/0x1c [rt2800usb]) from [<bf1affa4>] (rt2800_txdone_entry+0x34/0xe0 [rt2800lib])
> [69638.625518] [<bf1affa4>] (rt2800_txdone_entry+0x34/0xe0 [rt2800lib]) from [<bf1b0128>] (rt2800_txdone+0xd8/0x124 [rt2800lib])
> [69638.636894] [<bf1b0128>] (rt2800_txdone+0xd8/0x124 [rt2800lib]) from [<bf1bba00>] (rt2800usb_work_txdone+0x18/0x110 [rt2800usb])
> [69638.648522] [<bf1bba00>] (rt2800usb_work_txdone+0x18/0x110 [rt2800usb]) from [<c005beac>] (process_one_work+0x240/0x404)
> [69638.659451] [<c005beac>] (process_one_work+0x240/0x404) from [<c005ca38>] (worker_thread+0x1c0/0x2e0)
> [69638.668722] [<c005ca38>] (worker_thread+0x1c0/0x2e0) from [<c005fdcc>] (kthread+0x7c/0x84)
> [69638.677036] [<c005fdcc>] (kthread+0x7c/0x84) from [<c0030a94>] (kernel_thread_exit+0x0/0x8)
> [69638.685433] Code: e5903008 e5933008 e3530010 e590300c (e59300ac)
> [69638.691726] ---[ end trace 99d4053be7f17aef ]---
>
> [69638.699949] Unable to handle kernel paging request at virtual address fffffffc
> [69638.707210] pgd = c0004000
> [69638.709930] [fffffffc] *pgd=1fffe831, *pte=00000000, *ppte=00000000
> [69638.716244] Internal error: Oops: 17 [#2]
> [69638.720270] Modules linked in: nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc bridge ipv6 stp ext2 arc4 rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00lib mac80211 cfg80211 rfkill hmac sha1_generic mv_cesa aes_generic ext4 mbcache jbd2 mmc_block ehci_hcd mvsdio usbcore mmc_core mv643xx_eth libphy inet_lro
> [69638.747890] CPU: 0 Tainted: G D (3.0.1-100-bs-kirkwood+ #3)
> [69638.754628] PC is at kthread_data+0x4/0xc
> [69638.758650] LR is at wq_worker_sleeping+0xc/0xc0
> [69638.763292] pc : [<c005ffbc>] lr : [<c005cbb8>] psr: 20000093
> [69638.763297] sp : de44dc68 ip : c03f1958 fp : de44dcf4
> [69638.774833] r10: de44c000 r9 : de755d2c r8 : 00000001
> [69638.780084] r7 : df819ac0 r6 : de755da8 r5 : c03f1910 r4 : 00000000
> [69638.786641] r3 : 00000000 r2 : 93c085a9 r1 : 00000000 r0 : de755c20
> [69638.793199] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
> [69638.800454] Control: 0005397f Table: 1fa78000 DAC: 00000015
> [69638.806226] Process kworker/u:0 (pid: 2089, stack limit = 0xde44c270)
> [69638.812696] Stack: (0xde44dc68 to 0xde44e000)
> [69638.817079] dc60: de755c20 c02d84c8 de7583e0 c01228b4 00000000 00000000
> [69638.825293] dc80: 00000003 c0048920 00393830 de755c50 0ecbd14a 00000000 0ecbd14a 00000000
> [69638.833507] dca0: c03f1dcc c0061c4c 0ecbd14a 00000000 de755c20 debe0840 00000001 c041c348
> [69638.841722] dcc0: de755c20 c0046ffc de755c20 00000001 00000000 de755c20 ffffffff de44dcfc
> [69638.849945] dce0: df819ac0 00000001 de755d2c de755d2c de755c18 c0048920 bf1bb194 de44dcfc
> [69638.858168] dd00: de44dcfc de755d74 de44dd1c de44dec0 de44c000 00000001 bf1bb196 de44dd72
> [69638.866390] dd20: bf1bb194 00000000 00000017 c0033024 de44c270 0000000b 00000001 de44c000
> [69638.874606] dd40: 65000001 33303935 20383030 33393565 38303033 35336520 31303033 35652030
> [69638.882827] dd60: 30333039 28206330 33393565 63613030 00002029 00000017 00000022 000000ac
> [69638.891041] dd80: 00000017 00000000 de44dec0 00000000 00000013 00000017 00000022 c02d5af8
> [69638.899257] dda0: de755c20 c0036430 40000013 c0038fc0 c0038f74 def76020 00000f40 c0035840
> [69638.907479] ddc0: dee26460 df900574 df900400 bf010dac ffdf5000 ffdf56e0 00000010 df900524
> [69638.915702] dde0: 40000013 df9004e4 00000003 00000010 60000093 c0254124 df9004e4 00000006
> [69638.923916] de00: 00000017 c03ec210 000000ac de44dec0 0000003c 00000013 0000000e c002a1cc
> [69638.932130] de20: 00000080 00000000 df900598 00000000 de6b4418 df9004e4 c04196a0 de44c000
> [69638.940344] de40: 00000000 00000001 00000080 00000003 0000012c c02541c0 c043ccf0 0069ca19
> [69638.948558] de60: 00000000 00000001 0000000c de44c000 c043cce4 0000003c 00000001 00000003
> [69638.956773] de80: 00000001 c004af7c de8960a0 de755c50 c03f1958 c03f5fb8 0000000a 00000014
> [69638.964987] dea0: df958eb4 0000000b 00000000 ffffffff de44def4 de6aafc0 00000000 c002f7ac
> [69638.973201] dec0: de6d99c8 818c22fd 00000000 00000000 de6d99c8 818c22fd de6aafc0 00000000
> [69638.981415] dee0: 0000003c 00000001 0000000e 00000022 00000001 de44df08 bf1affa4 bf1bb194
> [69638.989631] df00: 80000013 ffffffff 00000000 818c22fd 00000000 de6aafc0 de6d99c8 818c22fd
> [69638.997854] df20: df958eb4 bf1b0128 c041a384 de6aafc0 df959600 de6ab3c4 de6ab3c4 c043defc
> [69639.006076] df40: 00000089 00000012 00000000 bf1bba00 de6ab3c4 c043defc 00000000 df8b86a0
> [69639.014291] df60: df959600 bf1bb9e8 de6ab3c4 c043defc 00000089 00000012 00000000 c005beac
> [69639.022514] df80: df8b86a0 df959605 00000081 df8b86a0 de44c000 c043defc c043def4 df8b86b0
> [69639.030737] dfa0: 00000089 c043defc 00000000 c005ca38 de4c7f30 df8b86a0 c005c878 00000013
> [69639.038958] dfc0: 00000000 00000000 00000000 c005fdcc 00000000 00000000 df8b86a0 00000001
> [69639.047175] dfe0: de44dfe0 de44dfe0 de4c7f30 c005fd50 c0030a94 c0030a94 ebfffffe e3500000
> [69639.055402] [<c005ffbc>] (kthread_data+0x4/0xc) from [<c005cbb8>] (wq_worker_sleeping+0xc/0xc0)
> [69639.064148] [<c005cbb8>] (wq_worker_sleeping+0xc/0xc0) from [<c02d84c8>] (schedule+0xe8/0x4e8)
> [69639.072806] [<c02d84c8>] (schedule+0xe8/0x4e8) from [<c0048920>] (do_exit+0x6b8/0x6f8)
> [69639.080764] [<c0048920>] (do_exit+0x6b8/0x6f8) from [<c0033024>] (die+0x2e4/0x324)
> [69639.088378] [<c0033024>] (die+0x2e4/0x324) from [<c02d5af8>] (__do_kernel_fault.part.5+0x54/0x74)
> [69639.097301] [<c02d5af8>] (__do_kernel_fault.part.5+0x54/0x74) from [<c0036430>] (do_page_fault+0x260/0x27c)
> [69639.107091] [<c0036430>] (do_page_fault+0x260/0x27c) from [<c002a1cc>] (do_DataAbort+0x34/0x98)
> [69639.115839] [<c002a1cc>] (do_DataAbort+0x34/0x98) from [<c002f7ac>] (__dabt_svc+0x4c/0x60)
> [69639.124139] Exception stack(0xde44dec0 to 0xde44df08)
> [69639.129219] dec0: de6d99c8 818c22fd 00000000 00000000 de6d99c8 818c22fd de6aafc0 00000000
> [69639.137433] dee0: 0000003c 00000001 0000000e 00000022 00000001 de44df08 bf1affa4 bf1bb194
> [69639.145643] df00: 80000013 ffffffff
> [69639.149165] [<c002f7ac>] (__dabt_svc+0x4c/0x60) from [<bf1bb194>] (rt2800usb_get_txwi+0x10/0x1c [rt2800usb])
> [69639.159060] [<bf1bb194>] (rt2800usb_get_txwi+0x10/0x1c [rt2800usb]) from [<bf1affa4>] (rt2800_txdone_entry+0x34/0xe0 [rt2800lib])
> [69639.170786] [<bf1affa4>] (rt2800_txdone_entry+0x34/0xe0 [rt2800lib]) from [<bf1b0128>] (rt2800_txdone+0xd8/0x124 [rt2800lib])
> [69639.182164] [<bf1b0128>] (rt2800_txdone+0xd8/0x124 [rt2800lib]) from [<bf1bba00>] (rt2800usb_work_txdone+0x18/0x110 [rt2800usb])
> [69639.193789] [<bf1bba00>] (rt2800usb_work_txdone+0x18/0x110 [rt2800usb]) from [<c005beac>] (process_one_work+0x240/0x404)
> [69639.204711] [<c005beac>] (process_one_work+0x240/0x404) from [<c005ca38>] (worker_thread+0x1c0/0x2e0)
> [69639.213980] [<c005ca38>] (worker_thread+0x1c0/0x2e0) from [<c005fdcc>] (kthread+0x7c/0x84)
> [69639.222293] [<c005fdcc>] (kthread+0x7c/0x84) from [<c0030a94>] (kernel_thread_exit+0x0/0x8)
> [69639.230685] Code: c03f42e8 c02dea14 c02dbd08 e590315c (e5130004)
> [69639.237041] ---[ end trace 99d4053be7f17af0 ]---
There is a patch from Stanislaw floating around that ought to fix this crash.
You can find the crash at:
http://marc.info/?l=linux-wireless&m=131279612304597&w=2
However, there is still some discussion on the patch and some more
tweaking of the patch may be required.
---
Gertjan
^ permalink raw reply
* Re: [RFC PATCH v2 1/9] dql: Dynamic queue limits
From: Eric Dumazet @ 2011-08-09 8:56 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1108072130380.13721@pokey.mtv.corp.google.com>
Le dimanche 07 août 2011 à 21:43 -0700, Tom Herbert a écrit :
> Implementation of dynamic queue limits (dql). This is a libary which
> allows a queue limit to be dynamically managed. The goal of dql is
> to set the queue limit, number of ojects to the queue, to be minimized
> without allowing the queue to be starved.
>
> dql would be used with a queue whose use has these properties:
>
> 1) Objects are queued up to some limit which can be expressed as a
> count of objects.
> 2) Periodically a completion process executes which retires consumed
> objects.
> 3) Starvation occurs when limit has been reached, all queued data has
> actually been consumed but completion processing has not yet run,
> so queuing new data is blocked.
> 4) Minimizing the amount of queued data is desirable.
>
> A canonical example of such a queue would be a NIC HW transmit queue.
>
> The queue limit is dynamic, it will increase or decrease over time
> depending on the workload. The queue limit is recalculated each time
> completion processing is done. Increases occur when the queue is
> starved and can exponentially increase over successive intervals.
> Decreases occur when more data is being maintained in the queue than
> needed to prevent starvation. The number of extra objects, or "slack",
> is measured over successive intervals, and to avoid hysteresis the
> limit is only reduced by the miminum slack seen over a configurable
> time period.
>
> dql API provides routines to manage the queue:
> - dql_init is called to intialize the dql structure
> - dql_reset is called to reset dynamic structures
> - dql_queued when objects are being enqueued
> - dql_avail returns availability in the queue
> - dql_completed is called when objects have be consumed in the queue
>
> Configuration consists of:
> - max_limit, maximum limit
> - min_limt, minimum limit
> - slack_hold_time, time to measure instances of slack before reducing
> queue limit.
Hi Tom
Not clear to me what value you use for slack_hold_time in your
benches/tests ?
Are you sure jiffy resolution (might be HZ=100) is precise enough for
future uses ?
^ permalink raw reply
* Re: [PATCH 6/6] Export the tcp sock's security context to proc.
From: Rongqing Li @ 2011-08-09 8:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, selinux, linux-security-module, sds
In-Reply-To: <20110809.003326.1002501904080430572.davem@davemloft.net>
On 08/09/2011 03:33 PM, David Miller wrote:
> From:<rongqing.li@windriver.com>
> Date: Tue, 9 Aug 2011 15:28:30 +0800
>
>> if (v == SEQ_START_TOKEN) {
>> seq_printf(seq, "%-*s\n", TMPSZ - 1,
>> " sl local_address rem_address st tx_queue "
>> "rx_queue tr tm->when retrnsmt uid timeout "
>> - "inode");
>> + "inode seclabel");
>> goto out;
>> }
>
> Unfortunately you cannot change the layout of procfs file output in
> this way. It has the potential to break programs which are parsing
> this file in userspace already.
>
> The layout hasn't changed in a very long time because it is essentially
> a uservisible ABI.
>
> If you want to export new information you'll have to do it using the
> facility that is extensible, and that's the netlink based socket dumping
> facility implemented in inet_diag.c, tcp_diag.c and friends.
>
> There, you can simply add a new netlink attribute that gets dumped with
> the entry, which will provide the security context.
>
>
Thanks, I see how I should do.
I will continue to develop it and hope get your help.
Thanks.
--
Best Reagrds,
Roy | RongQing Li
^ permalink raw reply
* Re: [PATCH] net: filter: Convert the BPF VM to threaded code
From: Hagen Paul Pfeifer @ 2011-08-09 8:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, rui314, netdev
In-Reply-To: <1312878988.2371.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Tue, 09 Aug 2011 10:36:28 +0200, Eric Dumazet wrote:
> I am speaking of one single conditional branch, the one that is done for
> every BPF instruction done in a filter. It's never taken, so must be
> predicted by the cpu. A perf session could make sure it is ;)
Ahh, ok - perf is your friend, I know Eric ;-)
>> > + switch ((enum bpf_inst)fentry->code) {
>>
>> That should not differ! Eric, sure that this do the trick?
>
> It is the way to tell gcc to make its optimizations, if they exists on
> enum switch (), as David suggested.
Argl, I see sock_filter.code is declared as __u16 not enum.
Hagen
^ permalink raw reply
* Re: [PATCH] ipv4: Fix ip_getsockopt for IP_PKTOPTIONS
From: Tiberiu Szocs-Mihai @ 2011-08-09 8:41 UTC (permalink / raw)
To: Jean Sacren; +Cc: Daniel Baluta, David S. Miller, Linux Networking
In-Reply-To: <20110809082404.GA24845@mail.gmail.com>
Hi Jean,
That was my first variant of the patch, but that way the code does more than
it's suppose to do: the call of do_ip_getsockopt becomes unaware of the
context from which it is called (ip_getsockopt or compat_ip_getsockopt). We
should act in a compat manner only when called from compat_ip_getsockopt.
The issue that needed a fix was that in compat mode the flag was set to 0 thus
silently disabling the call of put_cmsg_compat (see net/core/scm.c).
Thanks for the review,
Tiberiu
On Tuesday, August 09, 2011 11:24:04 am Jean Sacren wrote:
> From: Daniel Baluta <dbaluta@ixiacom.com>
> Date: Sun, 07 Aug 2011 02:20:50 +0300
>
> > IP_PKTOPTIONS is broken for 32-bit applications running
> > in COMPAT mode on 64-bit kernels.
> >
> > This happens because msghdr's msg_flags field is always
> > set to zero. When running in COMPAT mode this should be
> > set to MSG_CMSG_COMPAT instead.
> >
> > Signed-off-by: Tiberiu Szocs-Mihai <tszocs@ixiacom.com>
> > Signed-off-by: Daniel Baluta <dbaluta@ixiacom.com>
> > ---
> >
> > net/ipv4/ip_sockglue.c | 9 +++++----
> > 1 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> > index ab0c9ef..c77f5a8 100644
> > --- a/net/ipv4/ip_sockglue.c
> > +++ b/net/ipv4/ip_sockglue.c
> > @@ -1067,7 +1067,7 @@ EXPORT_SYMBOL(compat_ip_setsockopt);
> >
> > */
> >
> > static int do_ip_getsockopt(struct sock *sk, int level, int optname,
> >
> > - char __user *optval, int __user *optlen)
> > + char __user *optval, int __user *optlen, unsigned flags)
> >
> > {
> >
> > struct inet_sock *inet = inet_sk(sk);
> > int val;
> >
> > @@ -1240,7 +1240,7 @@ static int do_ip_getsockopt(struct sock *sk, int
> > level, int optname,
> >
> > msg.msg_control = optval;
> > msg.msg_controllen = len;
> >
> > - msg.msg_flags = 0;
> > + msg.msg_flags = flags;
> >
> > if (inet->cmsg_flags & IP_CMSG_PKTINFO) {
> >
> > struct in_pktinfo info;
> >
> > @@ -1294,7 +1294,7 @@ int ip_getsockopt(struct sock *sk, int level,
> >
> > {
> >
> > int err;
> >
> > - err = do_ip_getsockopt(sk, level, optname, optval, optlen);
> > + err = do_ip_getsockopt(sk, level, optname, optval, optlen, 0);
> >
> > #ifdef CONFIG_NETFILTER
> >
> > /* we need to exclude all possible ENOPROTOOPTs except default case
*/
> > if (err == -ENOPROTOOPT && optname != IP_PKTOPTIONS &&
> >
> > @@ -1327,7 +1327,8 @@ int compat_ip_getsockopt(struct sock *sk, int
> > level, int optname,
> >
> > return compat_mc_getsockopt(sk, level, optname, optval, optlen,
> >
> > ip_getsockopt);
> >
> > - err = do_ip_getsockopt(sk, level, optname, optval, optlen);
> > + err = do_ip_getsockopt(sk, level, optname, optval, optlen,
> > + MSG_CMSG_COMPAT);
> >
> > #ifdef CONFIG_NETFILTER
> >
> > /* we need to exclude all possible ENOPROTOOPTs except default case
*/
>
> I think the original patch can be simplified. Feedback is greatly
> appreciated.
>
> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> index ab0c9ef..f6eed68 100644
> --- a/net/ipv4/ip_sockglue.c
> +++ b/net/ipv4/ip_sockglue.c
> @@ -1240,7 +1240,7 @@ static int do_ip_getsockopt(struct sock *sk, int
> level, int optname,
>
> msg.msg_control = optval;
> msg.msg_controllen = len;
> - msg.msg_flags = 0;
> + msg.msg_flags = MSG_CMSG_COMPAT;
>
> if (inet->cmsg_flags & IP_CMSG_PKTINFO) {
> struct in_pktinfo info;
^ permalink raw reply
* Re: [PATCH] net: filter: Convert the BPF VM to threaded code
From: Eric Dumazet @ 2011-08-09 8:36 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: David Miller, rui314, netdev
In-Reply-To: <7f02f2970d225cddfad74ee660f39d1d@localhost>
Le mardi 09 août 2011 à 10:29 +0200, Hagen Paul Pfeifer a écrit :
> On Tue, 09 Aug 2011 07:00:27 +0200, Eric Dumazet wrote:
>
> > I tried this idea since its already an enum and all enum values are
> > handled in the switch, but all gcc versions I used still generate the
> > useless compare and branch (always predicted by modern CPU, so harmless
> > anyway ?)
>
> Don't think so, the list is rather long - the CPU may not have any
> indication. But strange that your gcc generate a conditional sequence of
> cmp and conditional jump instruction instead of a jump table! Look at
> commit 01f2f3f6ef4d076c, this is what I got after I refactored to an
> _dense_ enum list.
I am speaking of one single conditional branch, the one that is done for
every BPF instruction done in a filter. It's never taken, so must be
predicted by the cpu. A perf session could make sure it is ;)
>
> > (But this would need to use a larger kernel_sock_filter with not an u16
> > code, but the target address).
>
> Not sure if the benefit is worth to try it. Can we avoid any cacheline
> misses? I don't think so.
We avoid some instructions (to load the address from the instruction
code), thats all, for each BPF instruction.
>
>
> > + switch ((enum bpf_inst)fentry->code) {
>
> That should not differ! Eric, sure that this do the trick?
It is the way to tell gcc to make its optimizations, if they exists on
enum switch (), as David suggested.
If I add a new BPF_S_ANC_NEW_INST value in the enum list, not handled in
the switch(), gcc complains correctly.
net/core/filter.c: In function ‘sk_run_filter’:
net/core/filter.c:130:3: warning: enumeration value ‘BPF_S_ANC_NEW_INST’
not handled in switch
^ permalink raw reply
* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Wolfgang Grandegger @ 2011-08-09 8:32 UTC (permalink / raw)
To: U Bhaskar-B22300
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Marc Kleine-Budde
In-Reply-To: <9C64B7751C3BCA41B64A68E23005A7BE1B9D6C-TcFNo7jSaXPiTqIcKZ1S2K4g8xLGJsHaLnY5E4hWTkheoWH0uzbU5w@public.gmane.org>
Hi Bhaskar,
On 08/09/2011 09:57 AM, U Bhaskar-B22300 wrote:
>
>
>> -----Original Message-----
>> From: Marc Kleine-Budde [mailto:mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org]
>> Sent: Tuesday, August 09, 2011 12:23 AM
>> To: Wolfgang Grandegger
>> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; U Bhaskar-
>> B22300
>> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
>>
>> On 08/08/2011 05:33 PM, Wolfgang Grandegger wrote:
>>>> ACK - The device tree bindings as in mainline's Documentation is a
>> mess.
>>>> If the powerpc guys are happy with a clock interfaces based approach
>>>> somewhere in arch/ppc, I'm more than happy to remove:
>>>> - fsl,flexcan-clock-source (not implemented, even in the fsl driver)
> [Bhaskar]I have pushed the FlexCAN series of patches, It contains the usage of all the fields posted in the FlexCAN bindings at
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-3.0.y.git;a=blob;f=Documentation/devicetree/bindings/net/can/fsl-flexcan.txt;h=1a729f089866259ef82d0db5893ff7a8c54d5ccf;hb=94ed5b4788a7cdbe68bc7cb8516972cbebdc8274
As Marc already pointed out, Robin already has a much more advanced
patch stack in preparation. Especially your patches do not care about
the already existing Flexcan core on the Freescale's ARM socks.
>>>>
>>>> - fsl,flexcan-clock-divider \__ replace with code in arch/ppc, or
>>>> - clock-frequency / a single clock-frequency attribute
>>>
>>> In the "net-next-2.6" tree there is also:
>>>
>>> $ grep flexcan arch/powerpc/boots/dts/*.dts
>>> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
>>> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
>>> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
>>> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
>>> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
>>> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
>>>
>>> Especially the fsl,flexcan-clock-divider = <2>; might make people
>>> think, that they could set something else.
>>
> [Bhaskar] As it is mentioned in the Flexcan bindings, the need of fsl,flexcan-clock-divider = <2>;
> But I kept it as "2" because FlexCan clock source is the platform clock and it is CCB/2
> If the "2" is misleading, the bindings can be changed or some text can be written to make the meaning of "2"
> Understandable , Please suggest ..
The clock source and frequency is fixed. Why do we need an extra
properties for that. We have panned to remove these bogus bindings from
the Linux kernel, which sneaked in *without* any review on the relevant
mailing lists (at least I have not realized any posting). We do not
think they are really needed. They just confuse the user. We also prefer
to use the compatibility string "fsl,flexcan" instead
"fsl,flexcan-v1.0". It's unusual to add a version number, which is for
the Flexcan on the PowerPC cores only, I assume, but there will be
device tree for ARM soon. A proper compatibility string would be
"fsl,p1010-flexcan" if we really need to distinguish.
Please join the discussion on the mailing list helping to get this
driver mainline.
Thanks,
Wolfgang.
^ permalink raw reply
* Re: [PATCH] net: filter: Convert the BPF VM to threaded code
From: Hagen Paul Pfeifer @ 2011-08-09 8:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, rui314, netdev
In-Reply-To: <1312866027.2531.42.camel@edumazet-laptop>
On Tue, 09 Aug 2011 07:00:27 +0200, Eric Dumazet wrote:
> I tried this idea since its already an enum and all enum values are
> handled in the switch, but all gcc versions I used still generate the
> useless compare and branch (always predicted by modern CPU, so harmless
> anyway ?)
Don't think so, the list is rather long - the CPU may not have any
indication. But strange that your gcc generate a conditional sequence of
cmp and conditional jump instruction instead of a jump table! Look at
commit 01f2f3f6ef4d076c, this is what I got after I refactored to an
_dense_ enum list.
> (But this would need to use a larger kernel_sock_filter with not an u16
> code, but the target address).
Not sure if the benefit is worth to try it. Can we avoid any cacheline
misses? I don't think so.
> + switch ((enum bpf_inst)fentry->code) {
That should not differ! Eric, sure that this do the trick?
Hagen
^ permalink raw reply
* Re: [PATCH] ipv4: Fix ip_getsockopt for IP_PKTOPTIONS
From: Jean Sacren @ 2011-08-09 8:24 UTC (permalink / raw)
To: Daniel Baluta; +Cc: David S. Miller, tszocs, Linux Networking
In-Reply-To: <1312672850-13676-1-git-send-email-dbaluta@ixiacom.com>
From: Daniel Baluta <dbaluta@ixiacom.com>
Date: Sun, 07 Aug 2011 02:20:50 +0300
>
> IP_PKTOPTIONS is broken for 32-bit applications running
> in COMPAT mode on 64-bit kernels.
>
> This happens because msghdr's msg_flags field is always
> set to zero. When running in COMPAT mode this should be
> set to MSG_CMSG_COMPAT instead.
>
> Signed-off-by: Tiberiu Szocs-Mihai <tszocs@ixiacom.com>
> Signed-off-by: Daniel Baluta <dbaluta@ixiacom.com>
> ---
> net/ipv4/ip_sockglue.c | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> index ab0c9ef..c77f5a8 100644
> --- a/net/ipv4/ip_sockglue.c
> +++ b/net/ipv4/ip_sockglue.c
> @@ -1067,7 +1067,7 @@ EXPORT_SYMBOL(compat_ip_setsockopt);
> */
>
> static int do_ip_getsockopt(struct sock *sk, int level, int optname,
> - char __user *optval, int __user *optlen)
> + char __user *optval, int __user *optlen, unsigned flags)
> {
> struct inet_sock *inet = inet_sk(sk);
> int val;
> @@ -1240,7 +1240,7 @@ static int do_ip_getsockopt(struct sock *sk, int level, int optname,
>
> msg.msg_control = optval;
> msg.msg_controllen = len;
> - msg.msg_flags = 0;
> + msg.msg_flags = flags;
>
> if (inet->cmsg_flags & IP_CMSG_PKTINFO) {
> struct in_pktinfo info;
> @@ -1294,7 +1294,7 @@ int ip_getsockopt(struct sock *sk, int level,
> {
> int err;
>
> - err = do_ip_getsockopt(sk, level, optname, optval, optlen);
> + err = do_ip_getsockopt(sk, level, optname, optval, optlen, 0);
> #ifdef CONFIG_NETFILTER
> /* we need to exclude all possible ENOPROTOOPTs except default case */
> if (err == -ENOPROTOOPT && optname != IP_PKTOPTIONS &&
> @@ -1327,7 +1327,8 @@ int compat_ip_getsockopt(struct sock *sk, int level, int optname,
> return compat_mc_getsockopt(sk, level, optname, optval, optlen,
> ip_getsockopt);
>
> - err = do_ip_getsockopt(sk, level, optname, optval, optlen);
> + err = do_ip_getsockopt(sk, level, optname, optval, optlen,
> + MSG_CMSG_COMPAT);
>
> #ifdef CONFIG_NETFILTER
> /* we need to exclude all possible ENOPROTOOPTs except default case */
> --
> 1.7.2.5
I think the original patch can be simplified. Feedback is greatly
appreciated.
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index ab0c9ef..f6eed68 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1240,7 +1240,7 @@ static int do_ip_getsockopt(struct sock *sk, int level, int optname,
msg.msg_control = optval;
msg.msg_controllen = len;
- msg.msg_flags = 0;
+ msg.msg_flags = MSG_CMSG_COMPAT;
if (inet->cmsg_flags & IP_CMSG_PKTINFO) {
struct in_pktinfo info;
--
Jean Sacren
^ permalink raw reply related
* BUG: null pointer deref in rt2800usb_get_txwi
From: Marc Kleine-Budde @ 2011-08-09 8:23 UTC (permalink / raw)
To: Netdev; +Cc: linux-wireless, Stanislaw Gruszka
[-- Attachment #1: Type: text/plain, Size: 10116 bytes --]
Hello,
I'm a running a sheeva plug (ARM/kirkwood) with a rt2800 USB stick in AP mode.
Bus 001 Device 002: ID 1737:0071 Linksys WUSB600N v1 Dual-Band Wireless-N Network Adapter [Ralink RT2870]
kernel is v3.0.1 +
00898a47269ae5e6dda04defad00234b96692d95 rt2x00: fix usage of NULL queue
b52398b6e4522176dd125722c72c301015d24520 rt2x00: rt2800: fix zeroing skb structure
Which is here for reference:
(http://git.pengutronix.de/?p=mkl/linux-2.6.git;a=shortlog;h=refs/heads/wireless/rt2x00/v3.0.1)
The Kernel crashes after ~1d with this oopses:
(Same oops with stock v3.0.0 and v3.0.1)
[69638.429744] Unable to handle kernel NULL pointer dereference at virtual address 000000ac
[69638.438515] pgd = c0004000
[69638.441322] [000000ac] *pgd=00000000
[69638.444974] Internal error: Oops: 17 [#1]
[69638.449001] Modules linked in: nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc bridge ipv6 stp ext2 arc4 rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00
lib mac80211 cfg80211 rfkill hmac sha1_generic mv_cesa aes_generic ext4 mbcache jbd2 mmc_block ehci_hcd mvsdio usbcore mmc_core mv643xx_eth libphy inet_lro
[69638.476620] CPU: 0 Not tainted (3.0.1-100-bs-kirkwood+ #3)
[69638.482489] PC is at rt2800usb_get_txwi+0x10/0x1c [rt2800usb]
[69638.488273] LR is at rt2800_txdone_entry+0x34/0xe0 [rt2800lib]
[69638.494131] pc : [<bf1bb194>] lr : [<bf1affa4>] psr: 80000013
[69638.494136] sp : de44df08 ip : 00000001 fp : 00000022
[69638.505672] r10: 0000000e r9 : 00000001 r8 : 0000003c
[69638.510914] r7 : 00000000 r6 : de6aafc0 r5 : 818c22fd r4 : de6d99c8
[69638.517472] r3 : 00000000 r2 : 00000000 r1 : 818c22fd r0 : de6d99c8
[69638.524030] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[69638.531371] Control: 0005397f Table: 0105c000 DAC: 00000017
[69638.537144] Process kworker/u:0 (pid: 2089, stack limit = 0xde44c270)
[69638.543614] Stack: (0xde44df08 to 0xde44e000)
[69638.547997] df00: 00000000 818c22fd 00000000 de6aafc0 de6d99c8 818c22fd
[69638.556221] df20: df958eb4 bf1b0128 c041a384 de6aafc0 df959600 de6ab3c4 de6ab3c4 c043defc
[69638.564443] df40: 00000089 00000012 00000000 bf1bba00 de6ab3c4 c043defc 00000000 df8b86a0
[69638.572666] df60: df959600 bf1bb9e8 de6ab3c4 c043defc 00000089 00000012 00000000 c005beac
[69638.580881] df80: df8b86a0 df959605 00000081 df8b86a0 de44c000 c043defc c043def4 df8b86b0
[69638.589103] dfa0: 00000089 c043defc 00000000 c005ca38 de4c7f30 df8b86a0 c005c878 00000013
[69638.597325] dfc0: 00000000 00000000 00000000 c005fdcc 00000000 00000000 df8b86a0 00000000
[69638.605542] dfe0: de44dfe0 de44dfe0 de4c7f30 c005fd50 c0030a94 c0030a94 ebfffffe e3500000
[69638.613787] [<bf1bb194>] (rt2800usb_get_txwi+0x10/0x1c [rt2800usb]) from [<bf1affa4>] (rt2800_txdone_entry+0x34/0xe0 [rt2800lib])
[69638.625518] [<bf1affa4>] (rt2800_txdone_entry+0x34/0xe0 [rt2800lib]) from [<bf1b0128>] (rt2800_txdone+0xd8/0x124 [rt2800lib])
[69638.636894] [<bf1b0128>] (rt2800_txdone+0xd8/0x124 [rt2800lib]) from [<bf1bba00>] (rt2800usb_work_txdone+0x18/0x110 [rt2800usb])
[69638.648522] [<bf1bba00>] (rt2800usb_work_txdone+0x18/0x110 [rt2800usb]) from [<c005beac>] (process_one_work+0x240/0x404)
[69638.659451] [<c005beac>] (process_one_work+0x240/0x404) from [<c005ca38>] (worker_thread+0x1c0/0x2e0)
[69638.668722] [<c005ca38>] (worker_thread+0x1c0/0x2e0) from [<c005fdcc>] (kthread+0x7c/0x84)
[69638.677036] [<c005fdcc>] (kthread+0x7c/0x84) from [<c0030a94>] (kernel_thread_exit+0x0/0x8)
[69638.685433] Code: e5903008 e5933008 e3530010 e590300c (e59300ac)
[69638.691726] ---[ end trace 99d4053be7f17aef ]---
[69638.699949] Unable to handle kernel paging request at virtual address fffffffc
[69638.707210] pgd = c0004000
[69638.709930] [fffffffc] *pgd=1fffe831, *pte=00000000, *ppte=00000000
[69638.716244] Internal error: Oops: 17 [#2]
[69638.720270] Modules linked in: nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc bridge ipv6 stp ext2 arc4 rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00lib mac80211 cfg80211 rfkill hmac sha1_generic mv_cesa aes_generic ext4 mbcache jbd2 mmc_block ehci_hcd mvsdio usbcore mmc_core mv643xx_eth libphy inet_lro
[69638.747890] CPU: 0 Tainted: G D (3.0.1-100-bs-kirkwood+ #3)
[69638.754628] PC is at kthread_data+0x4/0xc
[69638.758650] LR is at wq_worker_sleeping+0xc/0xc0
[69638.763292] pc : [<c005ffbc>] lr : [<c005cbb8>] psr: 20000093
[69638.763297] sp : de44dc68 ip : c03f1958 fp : de44dcf4
[69638.774833] r10: de44c000 r9 : de755d2c r8 : 00000001
[69638.780084] r7 : df819ac0 r6 : de755da8 r5 : c03f1910 r4 : 00000000
[69638.786641] r3 : 00000000 r2 : 93c085a9 r1 : 00000000 r0 : de755c20
[69638.793199] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
[69638.800454] Control: 0005397f Table: 1fa78000 DAC: 00000015
[69638.806226] Process kworker/u:0 (pid: 2089, stack limit = 0xde44c270)
[69638.812696] Stack: (0xde44dc68 to 0xde44e000)
[69638.817079] dc60: de755c20 c02d84c8 de7583e0 c01228b4 00000000 00000000
[69638.825293] dc80: 00000003 c0048920 00393830 de755c50 0ecbd14a 00000000 0ecbd14a 00000000
[69638.833507] dca0: c03f1dcc c0061c4c 0ecbd14a 00000000 de755c20 debe0840 00000001 c041c348
[69638.841722] dcc0: de755c20 c0046ffc de755c20 00000001 00000000 de755c20 ffffffff de44dcfc
[69638.849945] dce0: df819ac0 00000001 de755d2c de755d2c de755c18 c0048920 bf1bb194 de44dcfc
[69638.858168] dd00: de44dcfc de755d74 de44dd1c de44dec0 de44c000 00000001 bf1bb196 de44dd72
[69638.866390] dd20: bf1bb194 00000000 00000017 c0033024 de44c270 0000000b 00000001 de44c000
[69638.874606] dd40: 65000001 33303935 20383030 33393565 38303033 35336520 31303033 35652030
[69638.882827] dd60: 30333039 28206330 33393565 63613030 00002029 00000017 00000022 000000ac
[69638.891041] dd80: 00000017 00000000 de44dec0 00000000 00000013 00000017 00000022 c02d5af8
[69638.899257] dda0: de755c20 c0036430 40000013 c0038fc0 c0038f74 def76020 00000f40 c0035840
[69638.907479] ddc0: dee26460 df900574 df900400 bf010dac ffdf5000 ffdf56e0 00000010 df900524
[69638.915702] dde0: 40000013 df9004e4 00000003 00000010 60000093 c0254124 df9004e4 00000006
[69638.923916] de00: 00000017 c03ec210 000000ac de44dec0 0000003c 00000013 0000000e c002a1cc
[69638.932130] de20: 00000080 00000000 df900598 00000000 de6b4418 df9004e4 c04196a0 de44c000
[69638.940344] de40: 00000000 00000001 00000080 00000003 0000012c c02541c0 c043ccf0 0069ca19
[69638.948558] de60: 00000000 00000001 0000000c de44c000 c043cce4 0000003c 00000001 00000003
[69638.956773] de80: 00000001 c004af7c de8960a0 de755c50 c03f1958 c03f5fb8 0000000a 00000014
[69638.964987] dea0: df958eb4 0000000b 00000000 ffffffff de44def4 de6aafc0 00000000 c002f7ac
[69638.973201] dec0: de6d99c8 818c22fd 00000000 00000000 de6d99c8 818c22fd de6aafc0 00000000
[69638.981415] dee0: 0000003c 00000001 0000000e 00000022 00000001 de44df08 bf1affa4 bf1bb194
[69638.989631] df00: 80000013 ffffffff 00000000 818c22fd 00000000 de6aafc0 de6d99c8 818c22fd
[69638.997854] df20: df958eb4 bf1b0128 c041a384 de6aafc0 df959600 de6ab3c4 de6ab3c4 c043defc
[69639.006076] df40: 00000089 00000012 00000000 bf1bba00 de6ab3c4 c043defc 00000000 df8b86a0
[69639.014291] df60: df959600 bf1bb9e8 de6ab3c4 c043defc 00000089 00000012 00000000 c005beac
[69639.022514] df80: df8b86a0 df959605 00000081 df8b86a0 de44c000 c043defc c043def4 df8b86b0
[69639.030737] dfa0: 00000089 c043defc 00000000 c005ca38 de4c7f30 df8b86a0 c005c878 00000013
[69639.038958] dfc0: 00000000 00000000 00000000 c005fdcc 00000000 00000000 df8b86a0 00000001
[69639.047175] dfe0: de44dfe0 de44dfe0 de4c7f30 c005fd50 c0030a94 c0030a94 ebfffffe e3500000
[69639.055402] [<c005ffbc>] (kthread_data+0x4/0xc) from [<c005cbb8>] (wq_worker_sleeping+0xc/0xc0)
[69639.064148] [<c005cbb8>] (wq_worker_sleeping+0xc/0xc0) from [<c02d84c8>] (schedule+0xe8/0x4e8)
[69639.072806] [<c02d84c8>] (schedule+0xe8/0x4e8) from [<c0048920>] (do_exit+0x6b8/0x6f8)
[69639.080764] [<c0048920>] (do_exit+0x6b8/0x6f8) from [<c0033024>] (die+0x2e4/0x324)
[69639.088378] [<c0033024>] (die+0x2e4/0x324) from [<c02d5af8>] (__do_kernel_fault.part.5+0x54/0x74)
[69639.097301] [<c02d5af8>] (__do_kernel_fault.part.5+0x54/0x74) from [<c0036430>] (do_page_fault+0x260/0x27c)
[69639.107091] [<c0036430>] (do_page_fault+0x260/0x27c) from [<c002a1cc>] (do_DataAbort+0x34/0x98)
[69639.115839] [<c002a1cc>] (do_DataAbort+0x34/0x98) from [<c002f7ac>] (__dabt_svc+0x4c/0x60)
[69639.124139] Exception stack(0xde44dec0 to 0xde44df08)
[69639.129219] dec0: de6d99c8 818c22fd 00000000 00000000 de6d99c8 818c22fd de6aafc0 00000000
[69639.137433] dee0: 0000003c 00000001 0000000e 00000022 00000001 de44df08 bf1affa4 bf1bb194
[69639.145643] df00: 80000013 ffffffff
[69639.149165] [<c002f7ac>] (__dabt_svc+0x4c/0x60) from [<bf1bb194>] (rt2800usb_get_txwi+0x10/0x1c [rt2800usb])
[69639.159060] [<bf1bb194>] (rt2800usb_get_txwi+0x10/0x1c [rt2800usb]) from [<bf1affa4>] (rt2800_txdone_entry+0x34/0xe0 [rt2800lib])
[69639.170786] [<bf1affa4>] (rt2800_txdone_entry+0x34/0xe0 [rt2800lib]) from [<bf1b0128>] (rt2800_txdone+0xd8/0x124 [rt2800lib])
[69639.182164] [<bf1b0128>] (rt2800_txdone+0xd8/0x124 [rt2800lib]) from [<bf1bba00>] (rt2800usb_work_txdone+0x18/0x110 [rt2800usb])
[69639.193789] [<bf1bba00>] (rt2800usb_work_txdone+0x18/0x110 [rt2800usb]) from [<c005beac>] (process_one_work+0x240/0x404)
[69639.204711] [<c005beac>] (process_one_work+0x240/0x404) from [<c005ca38>] (worker_thread+0x1c0/0x2e0)
[69639.213980] [<c005ca38>] (worker_thread+0x1c0/0x2e0) from [<c005fdcc>] (kthread+0x7c/0x84)
[69639.222293] [<c005fdcc>] (kthread+0x7c/0x84) from [<c0030a94>] (kernel_thread_exit+0x0/0x8)
[69639.230685] Code: c03f42e8 c02dea14 c02dbd08 e590315c (e5130004)
[69639.237041] ---[ end trace 99d4053be7f17af0 ]---
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v2 9/9] sfc: Support for byte queue limits
From: Eric Dumazet @ 2011-08-09 8:21 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1108072151500.13386@pokey.mtv.corp.google.com>
Le dimanche 07 août 2011 à 21:53 -0700, Tom Herbert a écrit :
> Changes to sfc to use byte queue limits.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> void efx_fini_tx_queue(struct efx_tx_queue *tx_queue)
> @@ -1168,6 +1181,8 @@ static int efx_enqueue_skb_tso(struct efx_tx_queue *tx_queue,
> /* Pass off to hardware */
> efx_nic_push_buffers(tx_queue);
>
> + netdev_tx_sent_queue(tx_queue->core_txq, 1, skb->len);
> +
> tx_queue->tso_bursts++;
> return NETDEV_TX_OK;
>
Hmm, thats too late at this point : Hardware might have sent the buffer
and tx completion already freed skb.
^ permalink raw reply
* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Marc Kleine-Budde @ 2011-08-09 8:13 UTC (permalink / raw)
To: U Bhaskar-B22300
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Wolfgang Grandegger
In-Reply-To: <9C64B7751C3BCA41B64A68E23005A7BE1B9D6C-TcFNo7jSaXPiTqIcKZ1S2K4g8xLGJsHaLnY5E4hWTkheoWH0uzbU5w@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2316 bytes --]
On 08/09/2011 09:57 AM, U Bhaskar-B22300 wrote:
>> On 08/08/2011 05:33 PM, Wolfgang Grandegger wrote:
>>>> ACK - The device tree bindings as in mainline's Documentation is a
>> mess.
>>>> If the powerpc guys are happy with a clock interfaces based approach
>>>> somewhere in arch/ppc, I'm more than happy to remove:
>>>> - fsl,flexcan-clock-source (not implemented, even in the fsl driver)
> [Bhaskar]I have pushed the FlexCAN series of patches, It contains the
> usage of all the fields posted in the FlexCAN bindings at
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-3.0.y.git;a=blob;f=Documentation/devicetree/bindings/net/can/fsl-flexcan.txt;h=1a729f089866259ef82d0db5893ff7a8c54d5ccf;hb=94ed5b4788a7cdbe68bc7cb8516972cbebdc8274
I've commented the patches. They are in a very bad shape. Please test
Robin's patches.
>>>>
>>>> - fsl,flexcan-clock-divider \__ replace with code in arch/ppc, or
>>>> - clock-frequency / a single clock-frequency attribute
>>>
>>> In the "net-next-2.6" tree there is also:
>>>
>>> $ grep flexcan arch/powerpc/boots/dts/*.dts
>>> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
>>> p1010rdb.dts: fsl,flexcan-clock-source = "platform";
>>> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
>>> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
>>> p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
>>> p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
>>>
>>> Especially the fsl,flexcan-clock-divider = <2>; might make people
>>> think, that they could set something else.
>>
> [Bhaskar] As it is mentioned in the Flexcan bindings, the need of
> fsl,flexcan-clock-divider = <2>; But I kept it as "2" because FlexCan
> clock source is the platform clock and it is CCB/2 If the "2" is
> misleading, the bindings can be changed or some text can be written
> to make the meaning of "2" Understandable , Please suggest ..
The clock devider is crap. Why not specify the clockrate that goes into
the flexcan core?
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: Eric Dumazet @ 2011-08-09 8:06 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, therbert, netdev
In-Reply-To: <20110809.004123.2080217558650594315.davem@davemloft.net>
Le mardi 09 août 2011 à 00:41 -0700, David Miller a écrit :
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Mon, 8 Aug 2011 11:19:17 -0700
>
> > On Mon, 8 Aug 2011 11:01:57 -0700
> > Tom Herbert <therbert@google.com> wrote:
> >
> >> > Since transmit completion means calling dev_kfree_skb() why not account
> >> > there? You could add some info to netdev if necessary to get compile
> >> > the statistics.
> >> >
> >> The algorithm depends on knowing the total number of packets competed
> >> in a single execution of transmit completion (epic based). We only
> >> want to recalculate the limits once per completion, which happens when
> >> the completion function is called.
> >
> > So just add some stats to netdev and count the number of dev_kfree_skb
> > calls and do your work at napi complete.
>
> No, I think what Tom's doing here is reasonable.
>
> First off, drivers have never been required to do specific things if
> they return success for ->ndo_start_xmit(). They can kfree_skb(skb)
> and return NET_TX_SUCCESS, and that's fine.
>
> This mean we can't use ->ndo_start_xmit() return values to drive the
> BQL engine.
>
> So we simply have a way for the driver to say when it really does
> queue up a packet, and that might be useful for other things.
>
> Second, you absolutely do not want to run the BQL engine on every
> single dev_kfree_skb() call. You want to batch it, and that's what
> Tom's new interface does, and that is therefore quite reasonable
> too.
>
> In fact, I think the best part about this revision of the BQL patches
> is the device driver interface. :-)
>
I agree, it permits a smooth transition to selected drivers, even some
non NAPI ones ;)
In some stress situations, NAPI never completes, so it would also mean
adding a dql call in this case...
^ permalink raw reply
* RE: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: U Bhaskar-B22300 @ 2011-08-09 7:57 UTC (permalink / raw)
To: Marc Kleine-Budde, Wolfgang Grandegger
Cc: socketcan-core@lists.berlios.de, netdev@vger.kernel.org
In-Reply-To: <4E403097.4020306@pengutronix.de>
> -----Original Message-----
> From: Marc Kleine-Budde [mailto:mkl@pengutronix.de]
> Sent: Tuesday, August 09, 2011 12:23 AM
> To: Wolfgang Grandegger
> Cc: socketcan-core@lists.berlios.de; netdev@vger.kernel.org; U Bhaskar-
> B22300
> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
>
> On 08/08/2011 05:33 PM, Wolfgang Grandegger wrote:
> >> ACK - The device tree bindings as in mainline's Documentation is a
> mess.
> >> If the powerpc guys are happy with a clock interfaces based approach
> >> somewhere in arch/ppc, I'm more than happy to remove:
> >> - fsl,flexcan-clock-source (not implemented, even in the fsl driver)
[Bhaskar]I have pushed the FlexCAN series of patches, It contains the usage of all the fields posted in the FlexCAN bindings at
http://git.kernel.org/?p=linux/kernel/git/stable/linux-3.0.y.git;a=blob;f=Documentation/devicetree/bindings/net/can/fsl-flexcan.txt;h=1a729f089866259ef82d0db5893ff7a8c54d5ccf;hb=94ed5b4788a7cdbe68bc7cb8516972cbebdc8274
> >>
> >> - fsl,flexcan-clock-divider \__ replace with code in arch/ppc, or
> >> - clock-frequency / a single clock-frequency attribute
> >
> > In the "net-next-2.6" tree there is also:
> >
> > $ grep flexcan arch/powerpc/boots/dts/*.dts
> > p1010rdb.dts: fsl,flexcan-clock-source = "platform";
> > p1010rdb.dts: fsl,flexcan-clock-source = "platform";
> > p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
> > p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
> > p1010si.dtsi: compatible = "fsl,flexcan-v1.0";
> > p1010si.dtsi: fsl,flexcan-clock-divider = <2>;
> >
> > Especially the fsl,flexcan-clock-divider = <2>; might make people
> > think, that they could set something else.
>
[Bhaskar] As it is mentioned in the Flexcan bindings, the need of fsl,flexcan-clock-divider = <2>;
But I kept it as "2" because FlexCan clock source is the platform clock and it is CCB/2
If the "2" is misleading, the bindings can be changed or some text can be written to make the meaning of "2"
Understandable , Please suggest ..
> ARGH... :D
>
> Marc
>
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Industrial Linux Solutions | Phone: +49-231-2826-924 |
> Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: David Miller @ 2011-08-09 7:41 UTC (permalink / raw)
To: shemminger; +Cc: therbert, netdev
In-Reply-To: <20110808111917.4b2669de@nehalam.ftrdhcpuser.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 8 Aug 2011 11:19:17 -0700
> On Mon, 8 Aug 2011 11:01:57 -0700
> Tom Herbert <therbert@google.com> wrote:
>
>> > Since transmit completion means calling dev_kfree_skb() why not account
>> > there? You could add some info to netdev if necessary to get compile
>> > the statistics.
>> >
>> The algorithm depends on knowing the total number of packets competed
>> in a single execution of transmit completion (epic based). We only
>> want to recalculate the limits once per completion, which happens when
>> the completion function is called.
>
> So just add some stats to netdev and count the number of dev_kfree_skb
> calls and do your work at napi complete.
No, I think what Tom's doing here is reasonable.
First off, drivers have never been required to do specific things if
they return success for ->ndo_start_xmit(). They can kfree_skb(skb)
and return NET_TX_SUCCESS, and that's fine.
This mean we can't use ->ndo_start_xmit() return values to drive the
BQL engine.
So we simply have a way for the driver to say when it really does
queue up a packet, and that might be useful for other things.
Second, you absolutely do not want to run the BQL engine on every
single dev_kfree_skb() call. You want to batch it, and that's what
Tom's new interface does, and that is therefore quite reasonable
too.
In fact, I think the best part about this revision of the BQL patches
is the device driver interface. :-)
^ permalink raw reply
* Re: [PATCH 6/6] Export the tcp sock's security context to proc.
From: David Miller @ 2011-08-09 7:33 UTC (permalink / raw)
To: rongqing.li; +Cc: netdev, selinux, linux-security-module, sds
In-Reply-To: <1312874910-31010-7-git-send-email-rongqing.li@windriver.com>
From: <rongqing.li@windriver.com>
Date: Tue, 9 Aug 2011 15:28:30 +0800
> if (v == SEQ_START_TOKEN) {
> seq_printf(seq, "%-*s\n", TMPSZ - 1,
> " sl local_address rem_address st tx_queue "
> "rx_queue tr tm->when retrnsmt uid timeout "
> - "inode");
> + "inode seclabel");
> goto out;
> }
Unfortunately you cannot change the layout of procfs file output in
this way. It has the potential to break programs which are parsing
this file in userspace already.
The layout hasn't changed in a very long time because it is essentially
a uservisible ABI.
If you want to export new information you'll have to do it using the
facility that is extensible, and that's the netlink based socket dumping
facility implemented in inet_diag.c, tcp_diag.c and friends.
There, you can simply add a new netlink attribute that gets dumped with
the entry, which will provide the security context.
^ permalink raw reply
* [PATCH 6/6] Export the tcp sock's security context to proc.
From: rongqing.li @ 2011-08-09 7:28 UTC (permalink / raw)
To: netdev, selinux, linux-security-module, sds
In-Reply-To: <1312874910-31010-1-git-send-email-rongqing.li@windriver.com>
From: Roy.Li <rongqing.li@windriver.com>
Export the tcp sock's security context to proc, since it maybe
different from the sock's owner process security context.
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
---
net/ipv4/tcp_ipv4.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 955b8e6..ddac912 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2479,12 +2479,13 @@ static int tcp4_seq_show(struct seq_file *seq, void *v)
{
struct tcp_iter_state *st;
int len;
+ struct sock *s = NULL;
if (v == SEQ_START_TOKEN) {
seq_printf(seq, "%-*s\n", TMPSZ - 1,
" sl local_address rem_address st tx_queue "
"rx_queue tr tm->when retrnsmt uid timeout "
- "inode");
+ "inode seclabel");
goto out;
}
st = seq->private;
@@ -2493,15 +2494,20 @@ static int tcp4_seq_show(struct seq_file *seq, void *v)
case TCP_SEQ_STATE_LISTENING:
case TCP_SEQ_STATE_ESTABLISHED:
get_tcp4_sock(v, seq, st->num, &len);
+ s = v;
break;
case TCP_SEQ_STATE_OPENREQ:
get_openreq4(st->syn_wait_sk, v, seq, st->num, st->uid, &len);
+ s = st->syn_wait_sk;
break;
case TCP_SEQ_STATE_TIME_WAIT:
get_timewait4_sock(v, seq, st->num, &len);
break;
}
- seq_printf(seq, "%*s\n", TMPSZ - 1 - len, "");
+
+ len += sock_write_secctx(s, seq);
+ len = TMPSZ - 1 - len;
+ seq_printf(seq, "%*s\n", len > 0 ? len : 0, "");
out:
return 0;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 5/6] Export the unix sock's security context to proc.
From: rongqing.li @ 2011-08-09 7:28 UTC (permalink / raw)
To: netdev, selinux, linux-security-module, sds
In-Reply-To: <1312874910-31010-1-git-send-email-rongqing.li@windriver.com>
From: Roy.Li <rongqing.li@windriver.com>
Export the unix sock's security context to proc, since it maybe
different from the sock's owner process security context.
Output '-' on Path column if the addr of unix_sock is NULL, rather
than nothing.
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
---
net/unix/af_unix.c | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index ec68e1c..9021f9b 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -2239,12 +2239,14 @@ static void unix_seq_stop(struct seq_file *seq, void *v)
spin_unlock(&unix_table_lock);
}
+#define OFFSET_PATH_START 40
static int unix_seq_show(struct seq_file *seq, void *v)
{
+ int len, offset = OFFSET_PATH_START;
if (v == SEQ_START_TOKEN)
seq_puts(seq, "Num RefCount Protocol Flags Type St "
- "Inode Path\n");
+ "Inode Path SecLabel\n");
else {
struct sock *s = v;
struct unix_sock *u = unix_sk(s);
@@ -2261,9 +2263,9 @@ static int unix_seq_show(struct seq_file *seq, void *v)
(s->sk_state == TCP_ESTABLISHED ? SS_CONNECTING : SS_DISCONNECTING),
sock_i_ino(s));
+ seq_putc(seq, ' ');
if (u->addr) {
- int i, len;
- seq_putc(seq, ' ');
+ int i;
i = 0;
len = u->addr->len - sizeof(short);
@@ -2275,7 +2277,17 @@ static int unix_seq_show(struct seq_file *seq, void *v)
}
for ( ; i < len; i++)
seq_putc(seq, u->addr->name->sun_path[i]);
- }
+ } else
+ seq_printf(seq, " %s%n", "-", &len);
+
+ if (offset > len)
+ offset -= (len + 1);
+ else
+ offset = 0;
+
+ seq_printf(seq, "%*s", offset, " ");
+ sock_write_secctx(s, seq);
+
unix_state_unlock(s);
seq_putc(seq, '\n');
}
--
1.7.1
^ permalink raw reply related
* [PATCH 4/6] Export the udp sock's security context to proc.
From: rongqing.li @ 2011-08-09 7:28 UTC (permalink / raw)
To: netdev, selinux, linux-security-module, sds
In-Reply-To: <1312874910-31010-1-git-send-email-rongqing.li@windriver.com>
From: Roy.Li <rongqing.li@windriver.com>
Export the udp sock's security context to proc, since it maybe
different from the sock's owner process security context.
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
---
net/ipv4/udp.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 1b5a193..6a1aff9 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2102,21 +2102,23 @@ static void udp4_format_sock(struct sock *sp, struct seq_file *f,
0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
atomic_read(&sp->sk_refcnt), sp,
atomic_read(&sp->sk_drops), len);
+
+ *len += sock_write_secctx(sp, f);
}
int udp4_seq_show(struct seq_file *seq, void *v)
{
if (v == SEQ_START_TOKEN)
- seq_printf(seq, "%-127s\n",
+ seq_printf(seq, "%-150s\n",
" sl local_address rem_address st tx_queue "
"rx_queue tr tm->when retrnsmt uid timeout "
- "inode ref pointer drops");
+ "inode ref pointer drops seclabel");
else {
struct udp_iter_state *state = seq->private;
int len;
udp4_format_sock(v, seq, state->bucket, &len);
- seq_printf(seq, "%*s\n", 127 - len, "");
+ seq_printf(seq, "%*s\n", (150 - len) > 0 ? 150 - len : 0, "");
}
return 0;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 3/6] Export the raw sock's security context to proc.
From: rongqing.li @ 2011-08-09 7:28 UTC (permalink / raw)
To: netdev, selinux, linux-security-module, sds
In-Reply-To: <1312874910-31010-1-git-send-email-rongqing.li@windriver.com>
From: Roy.Li <rongqing.li@windriver.com>
The element sk_security of struct sock represents the socket
security context ID, which is inheriting from the process when
creates this socket on most of the time.
but when SELinux type_transition rule is applied to socket, or
application sets /proc/xxx/attr/createsock, the socket security
context would be different from the creating process. on this
condition, the "netstat -Z" will return wrong value, since
"netstat -Z" only returns the process security context as socket
process security.
Export the raw sock's security context to proc, so that "netstat -Z"
could be fixed by reading procfs.
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
---
net/ipv4/raw.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 1457acb..79c17e5 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -979,12 +979,15 @@ static void raw_sock_seq_show(struct seq_file *seq, struct sock *sp, int i)
srcp = inet->inet_num;
seq_printf(seq, "%4d: %08X:%04X %08X:%04X"
- " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %pK %d\n",
+ " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %pK %d",
i, src, srcp, dest, destp, sp->sk_state,
sk_wmem_alloc_get(sp),
sk_rmem_alloc_get(sp),
0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
atomic_read(&sp->sk_refcnt), sp, atomic_read(&sp->sk_drops));
+
+ sock_write_secctx(sp, seq);
+ seq_putc(seq, '\n');
}
static int raw_seq_show(struct seq_file *seq, void *v)
@@ -992,7 +995,7 @@ static int raw_seq_show(struct seq_file *seq, void *v)
if (v == SEQ_START_TOKEN)
seq_printf(seq, " sl local_address rem_address st tx_queue "
"rx_queue tr tm->when retrnsmt uid timeout "
- "inode ref pointer drops\n");
+ "inode ref pointer drops seclabel\n");
else
raw_sock_seq_show(seq, v, raw_seq_private(seq)->bucket);
return 0;
--
1.7.1
^ permalink raw reply related
* [PATCH 1/6] Security: define security_sk_getsecid.
From: rongqing.li @ 2011-08-09 7:28 UTC (permalink / raw)
To: netdev, selinux, linux-security-module, sds
In-Reply-To: <1312874910-31010-1-git-send-email-rongqing.li@windriver.com>
From: Roy.Li <rongqing.li@windriver.com>
Define security_sk_getsecid to get the security id of a sock.
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
---
include/linux/security.h | 6 ++++++
security/security.c | 6 ++++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/include/linux/security.h b/include/linux/security.h
index ebd2a53..739ac39 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -2560,6 +2560,7 @@ int security_sk_alloc(struct sock *sk, int family, gfp_t priority);
void security_sk_free(struct sock *sk);
void security_sk_clone(const struct sock *sk, struct sock *newsk);
void security_sk_classify_flow(struct sock *sk, struct flowi *fl);
+void security_sk_getsecid(struct sock *sk, u32 *secid);
void security_req_classify_flow(const struct request_sock *req, struct flowi *fl);
void security_sock_graft(struct sock*sk, struct socket *parent);
int security_inet_conn_request(struct sock *sk,
@@ -2701,6 +2702,11 @@ static inline void security_sk_classify_flow(struct sock *sk, struct flowi *fl)
{
}
+static inline void security_sk_getsecid(struct sock *sk, u32 *secid)
+{
+ *secid = 0;
+}
+
static inline void security_req_classify_flow(const struct request_sock *req, struct flowi *fl)
{
}
diff --git a/security/security.c b/security/security.c
index 0e4fccf..b0e0825 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1104,6 +1104,12 @@ void security_sk_classify_flow(struct sock *sk, struct flowi *fl)
}
EXPORT_SYMBOL(security_sk_classify_flow);
+void security_sk_getsecid(struct sock *sk, u32 *secid)
+{
+ security_ops->sk_getsecid(sk, secid);
+}
+EXPORT_SYMBOL(security_sk_getsecid);
+
void security_req_classify_flow(const struct request_sock *req, struct flowi *fl)
{
security_ops->req_classify_flow(req, fl);
--
1.7.1
^ permalink raw reply related
* [PATCH 2/6] Define the function to write sock's security context to seq_file.
From: rongqing.li @ 2011-08-09 7:28 UTC (permalink / raw)
To: netdev, selinux, linux-security-module, sds
In-Reply-To: <1312874910-31010-1-git-send-email-rongqing.li@windriver.com>
From: Roy.Li <rongqing.li@windriver.com>
sock_write_secctx will write the sock's security context to a seq_file
and return the number of characters successfully written.
This function will be called when export socket information to proc.
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
---
include/net/sock.h | 1 +
net/core/sock.c | 28 ++++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 8e4062f..8bedb0c 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1828,6 +1828,7 @@ static inline struct sock *skb_steal_sock(struct sk_buff *skb)
extern void sock_enable_timestamp(struct sock *sk, int flag);
extern int sock_get_timestamp(struct sock *, struct timeval __user *);
extern int sock_get_timestampns(struct sock *, struct timespec __user *);
+extern int sock_write_secctx(struct sock *sk, struct seq_file *seq);
/*
* Enable debug/info messages
diff --git a/net/core/sock.c b/net/core/sock.c
index bc745d0..032ea72 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2254,6 +2254,34 @@ void sk_common_release(struct sock *sk)
}
EXPORT_SYMBOL(sk_common_release);
+int sock_write_secctx(struct sock *sk, struct seq_file *seq)
+{
+ char *ctx = NULL;
+ u32 ctxlen, secid;
+ int len;
+
+ if (sk == NULL)
+ goto error;
+
+ if (security_socket_getsockname(sk->sk_socket))
+ goto error;
+
+ security_sk_getsecid(sk, &secid);
+ if (!secid)
+ goto error;
+
+ if (security_secid_to_secctx(secid, &ctx, &ctxlen))
+ goto error;
+
+ seq_printf(seq, " %s%n", ctx, &len);
+ security_release_secctx(ctx, ctxlen);
+ return len;
+
+error:
+ seq_printf(seq, " %s%n", "-", &len);
+ return len;
+}
+
static DEFINE_RWLOCK(proto_list_lock);
static LIST_HEAD(proto_list);
--
1.7.1
^ permalink raw reply related
* [v2 PATCH 0/6] Export the sock's security context to proc
From: rongqing.li @ 2011-08-09 7:28 UTC (permalink / raw)
To: netdev, selinux, linux-security-module, sds
-------
Any review would be much appreciated.
Comments:
--------
Export the sock's security context to proc.
The element sk_security of struct sock represents the socket
security context ID, which is inheriting from the process when
creates this socket on most of the time.
but when SELinux type_transition rule is applied to socket, or
application sets /proc/xxx/attr/createsock, the socket security
context would be different from the creating process. on this
condition, the "netstat -Z" will return wrong value, since
"netstat -Z" only returns the process security context as socket
process security.
Export the raw sock's security context to proc, so that "netstat -Z"
could be fixed by reading procfs.
Test:
--------
1. When Enable SELinux.
1.1 check the socket security context has been exported in procfs
root@qemu-host:/root> head -n 3 /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode seclabel
0: 00000000:05FE 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 4723 1 ffff88001b7f8c00 100 0 0 10 -1 system_u:system_r:initrc_t:s0-s15:c0.c1023
1: 0100007F:024B 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 5070 1 ffff88001b7f9e00 100 0 0 10 -1 system_u:system_r:sendmail_t:s0-s15:c0.c1023
root@qemu-host:/root> head -n 3 /proc/net/udp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops seclabel
54: 00000000:03F2 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4540 2 ffff88001ba30340 0 system_u:system_r:rpcbind_t:s0-s15:c0.c1023
133: 00000000:B641 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4601 2 ffff88001ba30d00 0 system_u:system_r:rpcd_t:s0-s15:c0.c1023
root@qemu-host:/root> head -n 3 /proc/net/unix
Num RefCount Protocol Flags Type St Inode Path SecLabel
ffff88001ea1cc00: 00000002 00000000 00000000 0002 01 972 @/org/kernel/udev/udevd system_u:system_r:udev_t:s0-s15:c0.c1023
ffff88001ea1d500: 00000002 00000000 00010000 0001 01 4371 /var/evlog/evlconfsoc system_u:system_r:initrc_t:s0-s15:c0.c1023
root@qemu-host:/root>
root@qemu-host:/root> tail -n 3 /proc/net/unix
ffff88001e0e2300: 00000003 00000000 00000000 0001 03 4706 - system_u:system_r:rpcd_t:s0-s15:c0.c1023
ffff88001ea1d200: 00000003 00000000 00000000 0002 01 979 - system_u:system_r:udev_t:s0-s15:c0.c1023
ffff88001ea1cf00: 00000003 00000000 00000000 0002 01 978 - system_u:system_r:udev_t:s0-s15:c0.c1023
root@qemu-host:/root>
root@qemu-host:/root> head -n 3 /proc/net/raw
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops seclabel
root@qemu-host:/root>
1.2 check these patches do not affect the netstat, it can still work
root@qemu-host:/root> netstat -a
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:1534 *:* LISTEN
tcp 0 0 *:56290 *:* LISTEN
tcp 0 0 localhost:submission *:* LISTEN
tcp 0 0 *:sunrpc *:* LISTEN
...
1.3 When syslog creates socket, and type transition has been applied on them, the security context of
socket would be syslogd_s_t, not same as its own process security context
syslogd_t, the "netstat -Z" returns wrong value, but the security context in procfs is correct
root@qemu-host:/etc> cat /proc/net/unix |grep syslog
ffff88001f856000: 00000002 00000000 00010000 0001 01 6385 /var/lib/syslog-ng/syslog-ng.ctl system_u:system_r:syslogd_t:s15:c0.c1023
ffff88001f856300: 00000002 00000000 00000000 0002 01 6383 /dev/log system_u:system_r:syslogd_s_t:s15:c0.c1023
root@qemu-host:/etc>
root@qemu-host:/etc> netstat -aZ|grep 6383
unix 2 [ ] DGRAM 6383 793/syslog-ng
system_u:system_r:syslogd_t:s15:c0.c1023 /dev/log
root@qemu-host:/etc>
2. When SElinux is disabled, output - on seclabel column
root@qemu-host:/root> head -n 3 /proc/net/raw
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops seclabel
root@qemu-host:/root> head -n 3 /proc/net/unix
Num RefCount Protocol Flags Type St Inode Path SecLabel
ffff88001e118000: 0000000A 00000000 00000000 0002 01 2647 /dev/log -
ffff88001ea1cc00: 00000002 00000000 00000000 0002 01 897 @/org/kernel/udev/udevd -
root@qemu-host:/root> head -n 3 /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode seclabel
0: 00000000:05FE 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 2935 1 ffff88001d598c00 100 0 0 10 -1 -
1: 0100007F:024B 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 3201 1 ffff88001d599e00 100 0 0 10 -1 -
root@qemu-host:/root> head -n 3 /proc/net/udp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops seclabel
42: 00000000:03E6 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 2754 2 ffff88001da38340 0 -
56: 00000000:B5F4 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 2810 2 ffff88001da389c0 0 -
root@qemu-host:/root>
3. Disable security module configuration, no compiling error.
^ permalink raw reply
* Re: [PATCH 12/12] headers, ppp: Add missing #include to <linux/if_ppp.h>
From: David Miller @ 2011-08-09 7:27 UTC (permalink / raw)
To: ben; +Cc: netdev, paulus, linux-ppp
In-Reply-To: <1312809919.2591.1152.camel@deadeye>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 08 Aug 2011 14:25:19 +0100
> <linux/if_ppp.h> uses various types defined in <linux/ppp_defs.h>.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Unfortunately there is a "net/if_ppp.h" provided by glibc that
includes "net/ppp_defs.h", and all of this is presumably in order
to discourage direct use of the kernel headers.
Even though net/ppp_defs.h ends up including linux/ppp_defs.h
anyways.
Whilst I think your efforts are to be commended, we can't start doing
or else we'll start breaking the build in various unexpected ways.
The SIOCDEVPRIVATE (defined by GLIBC in bits/ioctls.h) case is just
one such example.
^ 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