* [PATCH v2 3/5] SUNRPC: make RPC service dependable on rpcbind clients creation
From: Stanislav Kinsbursky @ 2011-09-09 12:08 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem
In-Reply-To: <20110909115146.13697.71682.stgit@localhost6.localdomain6>
Create rcbind clients or increase rpcbind users counter during RPC service
creation and decrease this counter (and possibly destroy those clients) on RPC
service destruction.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
include/linux/sunrpc/clnt.h | 2 ++
net/sunrpc/rpcb_clnt.c | 2 +-
net/sunrpc/svc.c | 13 +++++++++++--
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/include/linux/sunrpc/clnt.h b/include/linux/sunrpc/clnt.h
index db7bcaf..65a8115 100644
--- a/include/linux/sunrpc/clnt.h
+++ b/include/linux/sunrpc/clnt.h
@@ -135,10 +135,12 @@ void rpc_shutdown_client(struct rpc_clnt *);
void rpc_release_client(struct rpc_clnt *);
void rpc_task_release_client(struct rpc_task *);
+int rpcb_create_local(void);
int rpcb_register(u32, u32, int, unsigned short);
int rpcb_v4_register(const u32 program, const u32 version,
const struct sockaddr *address,
const char *netid);
+void rpcb_put_local(void);
void rpcb_getport_async(struct rpc_task *);
void rpc_call_start(struct rpc_task *);
diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
index b4cc0f1..437ec60 100644
--- a/net/sunrpc/rpcb_clnt.c
+++ b/net/sunrpc/rpcb_clnt.c
@@ -318,7 +318,7 @@ out:
* Returns zero on success, otherwise a negative errno value
* is returned.
*/
-static int rpcb_create_local(void)
+int rpcb_create_local(void)
{
static DEFINE_MUTEX(rpcb_create_local_mutex);
int result = 0;
diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index 6a69a11..9095c0e 100644
--- a/net/sunrpc/svc.c
+++ b/net/sunrpc/svc.c
@@ -367,8 +367,11 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
unsigned int xdrsize;
unsigned int i;
- if (!(serv = kzalloc(sizeof(*serv), GFP_KERNEL)))
+ if (rpcb_create_local() < 0)
return NULL;
+
+ if (!(serv = kzalloc(sizeof(*serv), GFP_KERNEL)))
+ goto out_err;
serv->sv_name = prog->pg_name;
serv->sv_program = prog;
serv->sv_nrthreads = 1;
@@ -403,7 +406,7 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
GFP_KERNEL);
if (!serv->sv_pools) {
kfree(serv);
- return NULL;
+ goto out_err;
}
for (i = 0; i < serv->sv_nrpools; i++) {
@@ -423,6 +426,10 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
svc_unregister(serv);
return serv;
+
+out_err:
+ rpcb_put_local();
+ return NULL;
}
struct svc_serv *
@@ -491,6 +498,8 @@ svc_destroy(struct svc_serv *serv)
svc_unregister(serv);
kfree(serv->sv_pools);
kfree(serv);
+
+ rpcb_put_local();
}
EXPORT_SYMBOL_GPL(svc_destroy);
^ permalink raw reply related
* [PATCH v2 4/5] SUNRPC: remove rpcbind clients creation during service registering
From: Stanislav Kinsbursky @ 2011-09-09 12:08 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem
In-Reply-To: <20110909115146.13697.71682.stgit@localhost6.localdomain6>
We don't need this code since rpcbind clients are creating during RPC service
creation.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/rpcb_clnt.c | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
index 437ec60..f363efe 100644
--- a/net/sunrpc/rpcb_clnt.c
+++ b/net/sunrpc/rpcb_clnt.c
@@ -429,11 +429,6 @@ int rpcb_register(u32 prog, u32 vers, int prot, unsigned short port)
struct rpc_message msg = {
.rpc_argp = &map,
};
- int error;
-
- error = rpcb_create_local();
- if (error)
- return error;
dprintk("RPC: %sregistering (%u, %u, %d, %u) with local "
"rpcbind\n", (port ? "" : "un"),
@@ -569,11 +564,7 @@ int rpcb_v4_register(const u32 program, const u32 version,
struct rpc_message msg = {
.rpc_argp = &map,
};
- int error;
- error = rpcb_create_local();
- if (error)
- return error;
if (rpcb_local_clnt4 == NULL)
return -EPROTONOSUPPORT;
^ permalink raw reply related
* [PATCH v2 5/5] SUNRPC: remove rpcbind clients destruction on module cleanup
From: Stanislav Kinsbursky @ 2011-09-09 12:09 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, bfields, davem
In-Reply-To: <20110909115146.13697.71682.stgit@localhost6.localdomain6>
Rpcbind clients destruction during SUNRPC module removing is obsolete since now
those clients are destroying during last RPC service shutdown.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
net/sunrpc/rpcb_clnt.c | 12 ------------
net/sunrpc/sunrpc_syms.c | 3 ---
2 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
index f363efe..94a310d 100644
--- a/net/sunrpc/rpcb_clnt.c
+++ b/net/sunrpc/rpcb_clnt.c
@@ -1098,15 +1098,3 @@ static struct rpc_program rpcb_program = {
.version = rpcb_version,
.stats = &rpcb_stats,
};
-
-/**
- * cleanup_rpcb_clnt - remove xprtsock's sysctls, unregister
- *
- */
-void cleanup_rpcb_clnt(void)
-{
- if (rpcb_local_clnt4)
- rpc_shutdown_client(rpcb_local_clnt4);
- if (rpcb_local_clnt)
- rpc_shutdown_client(rpcb_local_clnt);
-}
diff --git a/net/sunrpc/sunrpc_syms.c b/net/sunrpc/sunrpc_syms.c
index 9d08091..8ec9778 100644
--- a/net/sunrpc/sunrpc_syms.c
+++ b/net/sunrpc/sunrpc_syms.c
@@ -61,8 +61,6 @@ static struct pernet_operations sunrpc_net_ops = {
extern struct cache_detail unix_gid_cache;
-extern void cleanup_rpcb_clnt(void);
-
static int __init
init_sunrpc(void)
{
@@ -102,7 +100,6 @@ out:
static void __exit
cleanup_sunrpc(void)
{
- cleanup_rpcb_clnt();
rpcauth_remove_module();
cleanup_socket_xprt();
svc_cleanup_xprt_sock();
^ permalink raw reply related
* Re: [PATCH v3] net/smsc911x: add device tree probe support
From: Shawn Guo @ 2011-09-09 12:59 UTC (permalink / raw)
To: Dave Martin
Cc: Grant Likely, Shawn Guo, netdev, patches, devicetree-discuss,
Steve Glendinning, David S. Miller, linux-arm-kernel
In-Reply-To: <20110909085030.GA3069@arm.com>
On Fri, Sep 09, 2011 at 09:50:30AM +0100, Dave Martin wrote:
> On Thu, Sep 08, 2011 at 11:29:20AM -0700, Grant Likely wrote:
> > On Thu, Sep 08, 2011 at 03:59:46PM +0100, Dave Martin wrote:
> > > Hi Shawn,
> > >
> > > On Sun, Jul 31, 2011 at 02:26:00AM +0800, Shawn Guo wrote:
> > > > It adds device tree probe support for smsc911x driver.
> > > >
> > > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > > > Cc: Grant Likely <grant.likely@secretlab.ca>
> > > > Cc: Steve Glendinning <steve.glendinning@smsc.com>
> > > > Cc: David S. Miller <davem@davemloft.net>
> > > > Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
> > > > ---
> > > > Changes since v2:
> > > > * Fix a typo in smsc911x.txt
> > > >
> > > > Changes since v1:
> > > > * Instead of getting irq line from gpio number, it use irq domain
> > > > to keep platform_get_resource(IORESOURCE_IRQ) works for dt too.
> > > > * Use 'lan9115' the first model that smsc911x supports in the match
> > > > table
> > > > * Use reg-shift and reg-io-width which already used in of_serial for
> > > > shift and access size binding
> > >
> > > When using this patch with vexpress, I found that 16-bit register access
> > > mode doesn't seem to be getting set correctly.
> > >
> > > Can you take a look at this additional patch and let me know if it looks
> > > correct?
> > >
> > > Cheers
> > > ---Dave
> > >
> > > From: Dave Martin <dave.martin@linaro.org>
> > > Date: Wed, 7 Sep 2011 17:26:31 +0100
> > > Subject: [PATCH] net/smsc911x: Correctly configure 16-bit register access from DT
> > >
> > > The SMSC911X_USE_16BIT needs to be set when using 16-bit register
> > > access. However, currently no flag is set if the DT doesn't specify
> > > 32-bit access.
> > >
> > > This patch should set the SMSC911X_USE_16BIT flag in a manner consistent
> > > with the documented DT bindings.
> > >
> > > Signed-off-by: Dave Martin <dave.martin@linaro.org>
> > > ---
> > > drivers/net/smsc911x.c | 2 ++
> > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c
> > > index 75c08a5..1a35c25 100644
> > > --- a/drivers/net/smsc911x.c
> > > +++ b/drivers/net/smsc911x.c
> > > @@ -2121,6 +2121,8 @@ static int __devinit smsc911x_probe_config_dt(
> > > of_property_read_u32(np, "reg-io-width", &width);
> > > if (width == 4)
> > > config->flags |= SMSC911X_USE_32BIT;
> > > + else
> > > + config->flags |= SMSC911X_USE_16BIT;
> >
> > Would it be better to do "else if (width == 2)"? (completely
> > uninformed comment. I've not looked at what the non-DT probe path
> > does on this driver.)
>
> I wouldn't have a problem with that. But currently the binding
> documentation says that any value other than 4, or a missing property,
> implies 16-bit register access.
>
> So the binding documentation would need to change too in that case.
>
> Personally I think this would be better, but it's just an opinion.
>
Yes. SMSC911X_USE_32BIT and SMSC911X_USE_16BIT are the only two cases
supported by the driver.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH 03/10] mm: Add support for a filesystem to control swap files
From: Christoph Hellwig @ 2011-09-09 13:00 UTC (permalink / raw)
To: Mel Gorman
Cc: Linux-MM, Linux-Netdev, Linux-NFS, LKML, Andrew Morton,
David Miller, Trond Myklebust, Neil Brown, Peter Zijlstra
In-Reply-To: <1315566054-17209-4-git-send-email-mgorman-l3A5Bk7waGM@public.gmane.org>
On Fri, Sep 09, 2011 at 12:00:47PM +0100, Mel Gorman wrote:
> Currently swapfiles are managed entirely by the core VM by using
> ->bmap to allocate space and write to the blocks directly. This
> patch adds address_space_operations methods that allow a filesystem
> to optionally control the swapfile.
>
> int swap_activate(struct file *);
> int swap_deactivate(struct file *);
> int swap_writepage(struct file *, struct page *, struct writeback_control *);
> int swap_readpage(struct file *, struct page *);
Just as the last two dozen times this came up:
NAK
The right fix is to add a filesystem method to support direct-I/O on
arbitrary kernel pages, instead of letting the wap abstraction leak into
the filesystem.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 10/10] Avoid dereferencing bd_disk during swap_entry_free for network storage
From: Christoph Hellwig @ 2011-09-09 13:02 UTC (permalink / raw)
To: Mel Gorman
Cc: Linux-MM, Linux-Netdev, Linux-NFS, LKML, Andrew Morton,
David Miller, Trond Myklebust, Neil Brown, Peter Zijlstra
In-Reply-To: <1315566054-17209-11-git-send-email-mgorman@suse.de>
On Fri, Sep 09, 2011 at 12:00:54PM +0100, Mel Gorman wrote:
> Commit [b3a27d: swap: Add swap slot free callback to
> block_device_operations] dereferences p->bdev->bd_disk but this is a
> NULL dereference if using swap-over-NFS. This patch checks SWP_BLKDEV
> on the swap_info_struct before dereferencing.
Please just remove the callback entirely. It has no user outside the
staging tree and was added clearly against the rules for that staging
tree.
(and it's butt ugly)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 01/15] add Documentation/namespaces/user_namespace.txt (v3)
From: Serge E. Hallyn @ 2011-09-09 13:10 UTC (permalink / raw)
To: Andrew Morton
Cc: Serge Hallyn, segooon, linux-kernel, netdev, containers, dhowells,
ebiederm, rdunlap
In-Reply-To: <20110907155024.42e3fe27.akpm@linux-foundation.org>
Quoting Andrew Morton (akpm@linux-foundation.org):
> On Fri, 2 Sep 2011 19:56:26 +0000
> Serge Hallyn <serge@hallyn.com> wrote:
>
> > +Note that this userid mapping for the VFS is not yet implemented, though the
> > +lkml and containers mailing list archives will show several previous
> > +prototypes. In the end, those got hung up waiting on the concept of targeted
> > +capabilities to be developed, which, thanks to the insight of Eric Biederman,
> > +they finally did.
>
> not-yet-implemented things worry me. When can we expect this to
> happen, and how big and ugly will it be?
Hi Andrew,
We did a proof of concept of the simplest version of this in early August
(see git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/linux-userns-devel.git)
which actually was very un-scary. So technically we could push it at the
same time as this set, but I thought that might just be too much for
review in one cycle. That set (Eric's) is the very simplest approach
which tags an entire filesystem with a user namespace.
We would also want to pursue the more baroque approach, where filesystems
themselves are user-namespace aware. I did an approach like that in
2008, see
https://lists.linux-foundation.org/pipermail/containers/2008-August/012679.html
It again is very do-able without being ugly, but, importantly, user
namespaces are usable for containers without that. For starters, we only
need /proc and /sys to be user namespace aware (since they must allow
access from multiple namespaces), and that is simple as they are not
persistent.
So I believe that this is the last scary patchset, and that user
namespaces could actually be usable by the end of the year!
> I'm not seeing many (any) reviewed-by's on these patches. I could get
> down and stare at them myself, but that wouldn't be very useful. This
> work goes pretty deep and is quite security-affecting. And network-afecting.
> Can you round up some suitable people and get the reviewing and testing happening
> please?
Will try. Unfortunately I missed my chance to beg and bribe people in
person at plumbers :(
thanks,
-serge
^ permalink raw reply
* Re: [PATCH 03/10] mm: Add support for a filesystem to control swap files
From: Mel Gorman @ 2011-09-09 13:15 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Linux-MM, Linux-Netdev, Linux-NFS, LKML, Andrew Morton,
David Miller, Trond Myklebust, Neil Brown, Peter Zijlstra
In-Reply-To: <20110909130007.GA11810@infradead.org>
On Fri, Sep 09, 2011 at 09:00:08AM -0400, Christoph Hellwig wrote:
> On Fri, Sep 09, 2011 at 12:00:47PM +0100, Mel Gorman wrote:
> > Currently swapfiles are managed entirely by the core VM by using
> > ->bmap to allocate space and write to the blocks directly. This
> > patch adds address_space_operations methods that allow a filesystem
> > to optionally control the swapfile.
> >
> > int swap_activate(struct file *);
> > int swap_deactivate(struct file *);
> > int swap_writepage(struct file *, struct page *, struct writeback_control *);
> > int swap_readpage(struct file *, struct page *);
>
> Just as the last two dozen times this came up:
>
> NAK
>
> The right fix is to add a filesystem method to support direct-I/O on
> arbitrary kernel pages, instead of letting the wap abstraction leak into
> the filesystem.
Ok.
I confess I haven't investigated this direction at
all yet. Is it correct that your previous objection was
http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-10/msg00455.html
and the direct-IO patchset you were thinking of was
http://copilotco.com/mail-archives/linux-kernel.2009/msg87176.html ?
If so, are you suggesting that instead of swap_readpage and
swap_writepage I look into what is required for swap to use ->readpage
method and ->direct_IO aops?
--
Mel Gorman
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Octeon crash in virt_to_page(&core0_stack_variable)
From: Cosmin Ratiu @ 2011-09-09 13:23 UTC (permalink / raw)
To: linux-mips; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]
Hello,
I've been investigating a strange crash and I wanted to ask for your help.
The crash happens when virt_to_page is called with an address from the softirq
stack of core 0 on Cavium Octeon. It may happen on other MIPS processors as
well, but I'm not sure.
I've attached a simple kernel module to demonstrate the problem and the output
of dmesg + the crash. Two seconds after inserting the module, the kernel
should crash.
From what I've dug up in the kernel sources, it seems the stack for the first
idle task resides in the data segment (mapped in kseg2) while the rest are
allocated with kmalloc in __cpu_up() and reside in a different area (CAC_BASE
upwards).
It seems virt_to_phys produces bogus results for kseg2 and after that,
virt_to_page crashes trying to access invalid memory.
This problem was discovered when doing BGP traffic with the TCP MD5 option
activated, where the following call chain caused a crash:
* tcp_v4_rcv
* tcp_v4_timewait_ack
* tcp_v4_send_ack -> follow stack variable rep.th
* tcp_v4_md5_hash_hdr
* tcp_md5_hash_header
* sg_init_one
* sg_set_buf
* virt_to_page
I noticed that tcp_v4_send_reset uses a similar stack variable and also calls
tcp_v4_md5_hash_hdr, so it has the same problem.
I don't fully understand octeon mm details, so I wanted to bring up this issue
in order to find a proper fix.
To avoid the problem, I've implemented a quick hack to declare those variables
percpu instead of on the stack, so they would also reside in CAC_BASE upwards.
I've attached a patch against 2.6.32 for reference.
Cosmin.
[-- Attachment #2: dmesg.log --]
[-- Type: text/x-log, Size: 20013 bytes --]
[ 0.000/0] Linux version 2.6.32 (IxOS linux_2.6.32/main/6.20.0.298) (ixsdk@ixca-cm-vmbld72) (gcc version 4.3.3 (Cavium Networks Version: 2_0_0 build 95) ) #1 SMP Wed Aug 24 09:26:59 PDT 2011
[ 0.000/0] boot_desc_ptr 800000000fde4300 bootinfo 800000000fde5c00 phy_mem_desc_addr 24108
[ 0.000/0] Ixia kernel instance 0, cores_per_instance 12, port_type 161
[ 0.000/0] CVMSEG size: 2 cache lines (256 bytes)
[ 0.000/0] ixia_uart: configured at 800000000ffa9000
[ 0.000/0] bootconsole [early0] enabled
[ 0.000/0] CPU revision is: 000d0409 (Cavium Octeon+)
[ 0.000/0] Checking for the multiply/shift bug... no.
[ 0.000/0] Checking for the daddiu bug... no.
[ 0.000/0] Found named block linmem0.0 @ 0x3000000, size= 0xb000000
[ 0.000/0] Found named block linmem0.1 @ 0x410000000, size= 0x10000000
[ 0.000/0] Found named block linmem0.2 @ 0x20000000, size= 0x20000000
[ 0.000/0] Found named block linmem0.3 @ 0x40000000, size= 0xc0000000
[ 0.000/0] Scan_named_regions complete
[ 0.000/0] Determined physical RAM map:
[ 0.000/0] memory: 00000000008dd000 @ 00000000013f3000 (usable after init)
[ 0.000/0] memory: 000000000b000000 @ 0000000003000000 (usable)
[ 0.000/0] memory: 0000000010000000 @ 0000000410000000 (usable)
[ 0.000/0] memory: 00000000e0000000 @ 0000000020000000 (usable)
[ 0.000/0] Wasting 285992 bytes for tracking 5107 unused pages
[ 0.000/0] Initrd not found or empty - disabling initrd
[ 0.000/0] Zone PFN ranges:
[ 0.000/0] Normal 0x000013f3 -> 0x00420000
[ 0.000/0] Movable zone start PFN for each node
[ 0.000/0] early_node_map[4] active PFN ranges
[ 0.000/0] 0: 0x000013f3 -> 0x00001cd0
[ 0.000/0] 0: 0x00003000 -> 0x0000e000
[ 0.000/0] 0: 0x00020000 -> 0x00100000
[ 0.000/0] 0: 0x00410000 -> 0x00420000
[ 0.000/0] On node 0 totalpages: 1030365
[ 0.000/0] Normal zone: 59067 pages used for memmap
[ 0.000/0] Normal zone: 0 pages reserved
[ 0.000/0] Normal zone: 971298 pages, LIFO batch:31
[ 0.000/0] Failed to allocate memory for Hotplug memory block
[ 0.000/0] PERCPU: Embedded 10 pages/cpu @a8000000068a0000 s10624 r8192 d22144 u65536
[ 0.000/0] pcpu-alloc: s10624 r8192 d22144 u65536 alloc=16*4096
[ 0.000/0] pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] 06 [0] 07
[ 0.000/0] pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11
[ 0.000/0] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 971298
[ 0.000/0] Kernel command line: console=ttyS0,115200
[ 0.000/0] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000/0] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.000/0] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[ 0.000/0] Primary instruction cache 32kB, virtually tagged, 4 way, 64 sets, linesize 128 bytes.
[ 0.000/0] Primary data cache 16kB, 64-way, 2 sets, linesize 128 bytes.
[ 0.000/0] Memory: 4047476k/4121460k available (2975k kernel code, 73196k reserved, 1067k data, 9076k init, 0k highmem)
[ 0.000/0] Hierarchical RCU implementation.
[ 0.000/0] NR_IRQS:408
[ 0.000/0] console [ttyS0] enabled, bootconsole disabled
[ 1951.025/0] Calibrating delay loop (skipped) preset value.. 1200.00 BogoMIPS (lpj=600000)
[ 1951.026/0] Mount-cache hash table entries: 256
[ 1951.026/0] Checking for the daddi bug... no.
[ 1951.027/0] SMP: Booting CPU01 (CoreId 1)...
[ 1951.027/1] CPU revision is: 000d0409 (Cavium Octeon+)
[ 1951.027/0] SMP: Booting CPU02 (CoreId 2)...
[ 1951.027/2] CPU revision is: 000d0409 (Cavium Octeon+)
[ 1951.028/0] SMP: Booting CPU03 (CoreId 3)...
[ 1951.028/3] CPU revision is: 000d0409 (Cavium Octeon+)
[ 1951.028/0] SMP: Booting CPU04 (CoreId 4)...
[ 1951.028/4] CPU revision is: 000d0409 (Cavium Octeon+)
[ 1951.029/0] SMP: Booting CPU05 (CoreId 5)...
[ 1951.029/5] CPU revision is: 000d0409 (Cavium Octeon+)
[ 1951.030/0] SMP: Booting CPU06 (CoreId 6)...
[ 1951.030/6] CPU revision is: 000d0409 (Cavium Octeon+)
[ 1951.030/0] SMP: Booting CPU07 (CoreId 7)...
[ 1951.030/7] CPU revision is: 000d0409 (Cavium Octeon+)
[ 1951.031/0] SMP: Booting CPU08 (CoreId 8)...
[ 1951.031/8] CPU revision is: 000d0409 (Cavium Octeon+)
[ 1951.031/0] SMP: Booting CPU09 (CoreId 9)...
[ 1951.031/9] CPU revision is: 000d0409 (Cavium Octeon+)
[ 1951.032/0] SMP: Booting CPU10 (CoreId 10)...
[ 1951.032/a] CPU revision is: 000d0409 (Cavium Octeon+)
[ 1951.033/0] SMP: Booting CPU11 (CoreId 11)...
[ 1951.033/b] CPU revision is: 000d0409 (Cavium Octeon+)
[ 1951.033/0] Brought up 12 CPUs
[ 1951.033/0] CPU0 attaching sched-domain:
[ 1951.033/0] domain 0: span 0-11 level CPU
[ 1951.033/0] groups: 0 1 2 3 4 5 6 7 8 9 10 11
[ 1951.033/0] CPU1 attaching sched-domain:
[ 1951.033/0] domain 0: span 0-11 level CPU
[ 1951.033/0] groups: 1 2 3 4 5 6 7 8 9 10 11 0
[ 1951.033/0] CPU2 attaching sched-domain:
[ 1951.033/0] domain 0: span 0-11 level CPU
[ 1951.033/0] groups: 2 3 4 5 6 7 8 9 10 11 0 1
[ 1951.033/0] CPU3 attaching sched-domain:
[ 1951.033/0] domain 0: span 0-11 level CPU
[ 1951.033/0] groups: 3 4 5 6 7 8 9 10 11 0 1 2
[ 1951.033/0] CPU4 attaching sched-domain:
[ 1951.033/0] domain 0: span 0-11 level CPU
[ 1951.033/0] groups: 4 5 6 7 8 9 10 11 0 1 2 3
[ 1951.033/0] CPU5 attaching sched-domain:
[ 1951.033/0] domain 0: span 0-11 level CPU
[ 1951.033/0] groups: 5 6 7 8 9 10 11 0 1 2 3 4
[ 1951.033/0] CPU6 attaching sched-domain:
[ 1951.033/0] domain 0: span 0-11 level CPU
[ 1951.033/0] groups: 6 7 8 9 10 11 0 1 2 3 4 5
[ 1951.033/0] CPU7 attaching sched-domain:
[ 1951.033/0] domain 0: span 0-11 level CPU
[ 1951.033/0] groups: 7 8 9 10 11 0 1 2 3 4 5 6
[ 1951.034/0] CPU8 attaching sched-domain:
[ 1951.034/0] domain 0: span 0-11 level CPU
[ 1951.034/0] groups: 8 9 10 11 0 1 2 3 4 5 6 7
[ 1951.034/0] CPU9 attaching sched-domain:
[ 1951.034/0] domain 0: span 0-11 level CPU
[ 1951.034/0] groups: 9 10 11 0 1 2 3 4 5 6 7 8
[ 1951.034/0] CPU10 attaching sched-domain:
[ 1951.034/0] domain 0: span 0-11 level CPU
[ 1951.034/0] groups: 10 11 0 1 2 3 4 5 6 7 8 9
[ 1951.034/0] CPU11 attaching sched-domain:
[ 1951.034/0] domain 0: span 0-11 level CPU
[ 1951.034/0] groups: 11 0 1 2 3 4 5 6 7 8 9 10
[ 1951.039/0] NET: Registered protocol family 16
[ 1951.039/0] bio: create slab <bio-0> at 0
[ 1951.041/0] SCSI subsystem initialized
[ 1951.041/0] Switching to clocksource OCTEON_CVMCOUNT
[ 1951.043/8] [multinic] Initializing ...
[ 1951.043/8] NET: Registered protocol family 2
[ 1951.044/8] IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 1951.045/8] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[ 1951.051/8] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[ 1951.052/8] TCP portaddr_bind hash table entries: 65536 (order: 8, 1048576 bytes)
[ 1951.053/8] TCP listening hash table entries: 65536 (order: 8, 1048576 bytes)
[ 1951.055/8] TCP: Hash tables configured (established 262144 bind 65536 listening 65536)
[ 1951.055/8] TCP reno registered
[ 1951.056/8] NET: Registered protocol family 1
[ 1951.057/8] RPC: Registered udp transport module.
[ 1951.057/8] RPC: Registered tcp transport module.
[ 1951.058/8] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 1952.710/8] /proc/octeon_perf: Octeon performace counter interface loaded
[ 1952.713/8] msgmni has been set to 7906
[ 1952.715/1] alg: No test for stdrng (krng)
[ 1952.715/8] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
[ 1952.715/8] io scheduler noop registered
[ 1952.715/8] io scheduler anticipatory registered
[ 1952.715/8] io scheduler deadline registered
[ 1952.716/8] io scheduler cfq registered (default)
[ 1952.720/8] Ixia Backplane UART version 0.01
[ 1952.720/8] Fixed MDIO Bus: probed
[ 1952.720/8] oprofile: using mips/octeon performance monitoring.
[ 1952.720/8] NET: Registered protocol family 26
[ 1952.722/8] [ixroute] Initialized.
[ 1952.722/8] TCP cubic registered
[ 1952.723/8] NET: Registered protocol family 10
[ 1952.742/8] [ixroute6] Initialized.
[ 1952.742/8] IPv6 over IPv4 tunneling driver
[ 1952.742/8] NET: Registered protocol family 17
[ 1952.743/8] L2 lock: TLB refill 256 bytes
[ 1952.743/8] L2 lock: General exception 128 bytes
[ 1952.743/8] L2 lock: low-level interrupt 128 bytes
[ 1952.743/8] L2 lock: interrupt 640 bytes
[ 1952.743/8] L2 lock: memcpy 1152 bytes
[ 1952.749/8] Freeing unused kernel memory: 9076k freed
[ 1953.050/8] ixsysctl: module license 'Copyright 2002, Ixia Communications; all rights reserved' taints kernel.
[ 1953.050/8] Disabling lock debugging due to kernel taint
[ 1953.051/8] ixsysctl: ixsysctl_init: Ixia System Control Utility Module Aug 25 2011 19:38:20
[ 1953.090/a] ixllm: init_module: Ixia Link Layer Manager Aug 25 2011 19:37:57
[ 1953.126/7] pcie: TX FPGA Version 0x1107
[ 1953.126/7] pcie: RX FPGA Version 0x10e5
[ 1953.132/8] octeon_msi_irq_dispatcher_init, kernel instance 0
[ 1953.132/8] ixia_irq_msi_dispatcher_init
[ 1953.195/2] cavium-ethernet: Cavium Networks Octeon SDK version 2.0.0-p4, build 373
[ 1953.195/2] Driver compiled with: USE_NAMEDBLOCK_FOR_FPA
[ 1953.195/2] cavium-ethernet: Using dev: ixint0 as Ixia root dev
[ 1953.195/2] everest_hw_init: kernel instance 0, cores_per_os: 12
[ 1953.195/2] octeon_ethernet.ko: Enable TX 1588
[ 1953.195/2] octeon_ethernet.ko: Enable RX 1588
[ 1953.196/2] nb name: ixia-platform-control-block size: 0x10000 addr: 0xfe15000
[ 1953.196/2] >> Core 2 coremask: fff
[ 1953.196/2] cvm_eth_instance_count_add Instance count: 1
[ 1953.196/2] >> Instance 0 mac_offset: 1 fau_offset: 2044 group: 0
[ 1953.196/2] Reclaimed 0 WQE and 0 FPA entries from POW
[ 1953.196/2] fpa 0: que-available: 1fb0
[ 1953.196/2] fpa 1: que-available: 1fc0
[ 1953.196/2] fpa 2: que-available: 53
[ 1953.196/2] cvm_oct_configure_common_hw: group 0
[ 1953.196/2] cvm_eth_get_interfaces_of_interest Adding interface 0 of type 5
[ 1953.196/2] Interface 0 has 1 ports (XAUI)
[ 1953.196/2] Interface 1 has 1 ports (XAUI)
[ 1953.196/2] cvmx_helper_interface_probe_mi: Not probing Interface type 8
[ 1953.196/2] cvmx_helper_interface_probe_mi: Not probing Interface type 9
[ 1953.196/2] Checking port 0, max_port: 0 num_ports: 1
[ 1953.196/2] ixia_probe_hw
[ 1953.196/2] Bringing up device ixint0 (i/f: 0 port: 0)
[ 1953.196/2] priv->tx_port 0 priv->tx_queue 0
[ 1953.196/2] cvm_oct_init_module dev->mtu: 14000
[ 1953.196/2] cvm_oct_rx_initialize: max_rx_cpus=12
[ 1953.196/2] IRQ request for 24 succeeded
[ 1953.196/2] MSI Enable for msi_num 4 is location 0x80011f000000bc50 value 0x10
[ 1953.282/3] Basic DMA tests passed
[ 1953.301/4] IXHOST mcb->dwBootRamBase = 0x800000000ffe9000
[ 1953.301/4] CPU Frequency: 600 MHz
[ 1953.302/4] ADVERTISED FLAG = 0x0000000000008f8f
[ 1953.302/4] dma_xmit_open: dma_idx: 0, tx_fifo_base: 0x8000c00000000000
[ 1953.302/4] MSI Enable for msi_num 0 is location 0x80011f000000bc50 value 0x11
[ 1953.302/4] CIU_INT0_EN0 = 0x10300000001
[ 1953.302/4] ixhostm: MessageQueueInit success
[ 1953.302/4] Virtual queue base = 0x800000000fb20000
[ 1953.302/4] Base physical = 0xfb20000
[ 1953.302/4] OS instance = 0
[ 1953.302/4] Virtual chassis card map base = 0x800000000fbb0000
[ 1953.302/4] Virtual P2P rx_que_base = 0x800000000fb20000
[ 1953.302/4] [2 s. 276082 us] p2p_message_queue_init success
[ 1953.302/4] IXHOST ver 3.0.0
[ 1953.322/7] hwstate: timestamp test passed
[ 1953.617/2] [multinic] operation: +
[ 1953.617/2] [multinic] device: ixint0
[ 1953.617/2] [multinic] id: 0
[ 1996.813/0] [1315571465 s. 798972 us] Refreshing topology Chassis X2 ...
[ 1996.813/0] ---- Slot= 1 PortType=161 PortMap=0x0000ffff
[ 1996.814/0] ---- Slot= 2 PortType= 83 PortMap=0x000000ff
[ 2038.300/0] vcrash initializing
[ 2040.299/8] core 8: &x a80000041f98fbd0 virt_to_phys(&x) 41f98fbd0
[ 2040.299/b] core 11: &x a80000041fa0bbd0 virt_to_phys(&x) 41fa0bbd0
[ 2040.299/a] core 10: &x a80000041f9cbbd0 virt_to_phys(&x) 41f9cbbd0
[ 2040.299/1] core 1: &x a80000041f87bbd0 virt_to_phys(&x) 41f87bbd0
[ 2040.299/2] core 2: &x a80000041f8bbbd0 virt_to_phys(&x) 41f8bbbd0
[ 2040.299/3] core 3: &x a80000041f8d7bd0 virt_to_phys(&x) 41f8d7bd0
[ 2040.299/5] core 5: &x a80000041f917bd0 virt_to_phys(&x) 41f917bd0
[ 2040.299/4] core 4: &x a80000041f8f7bd0 virt_to_phys(&x) 41f8f7bd0
[ 2040.299/0] core 0: &x ffffffffc03a3b70 virt_to_phys(&x) 57ffffffc03a3b70
[ 2040.299/b] core 11: virt_to_page(&x) a800000006870268
[ 2040.299/6] core 6: &x a80000041f953bd0 virt_to_phys(&x) 41f953bd0
[ 2040.299/9] core 9: &x a80000041f9afbd0 virt_to_phys(&x) 41f9afbd0
[ 2040.299/7] core 7: &x a80000041f96fbd0 virt_to_phys(&x) 41f96fbd0
[ 2040.299/a] core 10: virt_to_page(&x) a80000000686f468
[ 2040.299/1] core 1: virt_to_page(&x) a80000000686aae8
[ 2040.299/2] core 2: virt_to_page(&x) a80000000686b8e8
[ 2040.299/3] core 3: virt_to_page(&x) a80000000686bf08
[ 2040.299/5] core 5: virt_to_page(&x) a80000000686cd08
[ 2040.299/4] core 4: virt_to_page(&x) a80000000686c608
[ 2040.299/0] CPU 0 Unable to handle kernel paging request at virtual address 00000057c0d14640, epc == ffffffffc123a054, ra == ffffffffc123a030
[ 2040.299/6] core 6: virt_to_page(&x) a80000000686da28
[ 2040.299/9] core 9: virt_to_page(&x) a80000000686ee48
[ 2040.299/7] core 7: virt_to_page(&x) a80000000686e048
[ 2040.299/0] die: oom_log() temporarily disabled on this architecture
[ 2040.299/0] Oops[#1]:
[ 2040.299/0] Cpu 0
[ 2040.299/0] $ 0 : 0000000000000000 0000000000000000 00000057c0d14640 00000057ffffffc0
[ 2040.299/0] $ 4 : ffffffffc1240000 ffffffffc0ce0000 0000000000000000 0000000000020000
[ 2040.299/0] $ 8 : ffffffffc0ce0000 ffffffffffffffff fffffffffffffffb 0000000000000010
[ 2040.299/0] $12 : 0000000000000020 00000000000186a0 0000000000000009 0000000000000000
[ 2040.300/0] $16 : 0133ffffff20cba8 0000000000000100 ffffffffc123a000 ffffffffc0d0a220
[ 2040.300/0] $20 : ffffffffc0d09e20 ffffffffc0d09a20 ffffffffc0d09620 0000000000200200
[ 2040.300/0] $24 : 0000000000000002 ffffffffc000baa4
[ 2040.300/0] $28 : ffffffffc03a0000 ffffffffc03a3b70 ffffffffc03a0000 ffffffffc123a030
[ 2040.300/0] Hi : 00000000000b6854
[ 2040.300/0] Lo : 000000000000012b
[ 2040.300/0] epc : ffffffffc123a054 vcrash+0x54/0x80 [vcrash]
[ 2040.300/0] Tainted: P
[ 2040.300/0] ra : ffffffffc123a030 vcrash+0x30/0x80 [vcrash]
[ 2040.300/0] Status: 1000cce3 KX SX UX KERNEL EXL IE
[ 2040.300/0] Cause : 00800008
[ 2040.300/0] BadVA : 00000057c0d14640
[ 2040.300/0] PrId : 000d0409 (Cavium Octeon+)
[ 2040.300/0] Modules linked in: vcrash ixvaluelist(P) ixgremod(P) ixunc(P) kseusrmgr(P) evfmanager(P) filtermanager hwstate ixhostm octeon_dma octeon_ethernet octeon_mdiobus ixnam_binstats(P) octeon_msi pcie ixllm ixsysctl(P) nlproc_driver
[ 2040.300/0] Process swapper (pid: 0, threadinfo=ffffffffc03a0000, task=ffffffffc03be580, tls=0000000000000000)
[ 2040.300/0] Stack : ffffffffc03a0000 ffffffffc03a4788 ffffffffc0d08600 ffffffffc0065f28
[ 2040.300/0] ffffffffc03a3b90 ffffffffc03a3b90 0000000000000100 0000000000000001
[ 2040.300/0] ffffffffc03a4788 0000000000000101 0000000000000008 ffffffffc0cc31b0
[ 2040.300/0] 000000000000000a 0000000000000000 ffffffffc0d07b80 ffffffffc00609e0
[ 2040.300/0] 0000000000000000 8001070000000000 8001070000000218 8001070000000200
[ 2040.300/0] 8001070000000108 ffffffffc0ce0000 0000000000010000 000000000fde4300
[ 2040.300/0] ffffffffc03a0000 ffffffffc0060adc 0000000000000000 ffffffffc0060cb0
[ 2040.300/0] 0000000000000000 ffffffffc000ba7c a8000000068a0058 0000000000000000
[ 2040.300/0] 0000000000000001 ffffffffc0ce0000 ffffffffc0ce0000 000000000fdd0000
[ 2040.300/0] 0000000000000000 ffffffffc0000888 0000000000000000 0000000000000000
[ 2040.300/0] ...
[ 2040.300/0] Call Trace:
[ 2040.300/0] [<ffffffffc123a054>] vcrash+0x54/0x80 [vcrash]
[ 2040.300/0] [<ffffffffc0065f28>] run_timer_softirq+0x198/0x23c
[ 2040.300/0] [<ffffffffc00609e0>] __do_softirq+0xd8/0x188
[ 2040.300/0] [<ffffffffc0060adc>] do_softirq+0x4c/0x6c
[ 2040.300/0] [<ffffffffc0060cb0>] irq_exit+0x48/0x8c
[ 2040.300/0] [<ffffffffc000ba7c>] plat_irq_dispatch+0x128/0x150
[ 2040.300/0] [<ffffffffc0000888>] ret_from_irq+0x0/0x4
[ 2040.300/0] [<ffffffffc0000a80>] r4k_wait+0x20/0x40
[ 2040.300/0] [<ffffffffc0033fe0>] cpu_idle+0x60/0x9c
[ 2040.300/0] [<ffffffffc03f3a9c>] start_kernel+0x3e8/0x404
[ 2040.300/0]
[ 2040.300/0]
[ 2040.300/0] Code: 64424680 0043102d 3c04c124 <dc460000> 2402fffc 8f850020 6484a2d8 00c23024 0c001c23
[ 2040.300/0] Kernel panic - not syncing: Fatal exception in interrupt
[ 2040.300/0] Call Trace:
[ 2040.300/0] [<ffffffffc0006ef8>] dump_stack+0x8/0x34
[ 2040.300/0] [<ffffffffc0006fa0>] panic+0x7c/0x168
[ 2040.300/0] [<ffffffffc0036bd8>] die+0x114/0x11c
[ 2040.300/0] [<ffffffffc0041468>] do_page_fault+0x314/0x39c
[ 2040.300/0] [<ffffffffc0000880>] ret_from_exception+0x0/0x8
[ 2040.300/0] [<ffffffffc123a054>] vcrash+0x54/0x80 [vcrash]
[ 2040.300/0] [<ffffffffc0065f28>] run_timer_softirq+0x198/0x23c
[ 2040.300/0] [<ffffffffc00609e0>] __do_softirq+0xd8/0x188
[ 2040.300/0] [<ffffffffc0060adc>] do_softirq+0x4c/0x6c
[ 2040.300/0] [<ffffffffc0060cb0>] irq_exit+0x48/0x8c
[ 2040.300/0] [<ffffffffc000ba7c>] plat_irq_dispatch+0x128/0x150
[ 2040.300/0] [<ffffffffc0000888>] ret_from_irq+0x0/0x4
[ 2040.300/0] [<ffffffffc0000a80>] r4k_wait+0x20/0x40
[ 2040.300/0] [<ffffffffc0033fe0>] cpu_idle+0x60/0x9c
[ 2040.300/0] [<ffffffffc03f3a9c>] start_kernel+0x3e8/0x404
[ 2040.300/0]
[ 2040.300/0] ixhost: ENABLE Tx message checksum
[ 2040.300/0] ixhost: DISABLE Rx message checksum
[ 2040.300/0] ixhost: ENABLE SGC Communication mode
[ 2040.300/0] ixhost: ENABLE Lcpu Interrupt Host
[ 2040.300/0] ixhost: ENABLE Host Interrupt Lcpu
[ 2040.300/0] ixhost: ENABLE 32-bit Pointer mode
[ 2040.300/0] ixhost: Advertised BCAST=0x0000
[ 2040.300/0] TxFrameCount= 1097 TxByteCount= 129484
[ 2040.300/0] H/W TxFifoBase=0xa80000041e4dc000 TxFifoEnd=0xa80000041e4dfff0 TxFifoSize=0x3ff0
[ 2040.300/0] RRN=0xa80000041e4dfff0 RRB=0xa80000041e4dfff8 TW=0xa80000041e4dfff4
[ 2040.301/0]
[ 2040.301/0] H/W RxFifoBase=0x800000000ff29000 RxFifoEnd=0x800000000ff38ff8 RxFifoSize=0xfff8
[ 2040.301/0] RW=0x800000000ff38ff8 TR=0x800000000ff38ffc
[ 2040.301/0] RxWrite=0x800000000ff38ff8 RxRead=0xa80000041e4dfff0 TxWrite=0xa80000041e4dfff4 TxRead=0x800000000ff38ffc
[ 2040.301/0] ImagTransmitBase=0xa80000041e4dc000 WritePos=0x3a3c ReadPos=0x3a3c00000000 PrevWrite=0xa80000041e4dfa00
[ 2040.301/0] Receive[normal]
[ 2040.301/0] WritePtr : 0x800096ac0ff2ca3c
[ 2040.301/0] ReadPtr : 0x800000000ff326ac
[ 2040.301/0] Advertised Read Ptr : 0x000096ac
[ 2040.301/0] PrevRead : 0x800000000ff32674
[ 2040.301/0] Receive[broadcast]
[ 2040.301/0] WritePtr : 0x800000000ff39000
[ 2040.301/0] ReadPtr : 0x800000000ff39000
[ 2040.301/0] Advertised Read Ptr : 0x00000000
[ 2040.301/0] PrevRead : 0x800000000ff39000
[ 2040.301/0] Octeon board_info
[ 2040.301/0] ----- head=19 tail=16 buffer:
[ 2040.301/0] pData = 0xa8000000018ca800 len = 64
[ 2040.301/0] (0xa8000000018ca800) 0x0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 2040.301/0] (0xa8000000018ca810) 0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 2040.301/0] (0xa8000000018ca820) 0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 2040.301/0] (0xa8000000018ca830) 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 2040.301/0]
[ 2040.301/0] p2h_fifo_len: 0000 p2p_fifo_len: 0000
[ 2040.301/0] p2h_count: 25524, p2p_count: 0
[ 2040.301/0] fpa 0: que-available: 1fb0
[ 2040.301/0] fpa 1: que-available: 1fc0
[ 2040.301/0] fpa 2: que-available: 53
[ 2040.301/0] ixhost::panic_handler: setting kProcessorHalted bit
[ 2040.301/0] ixhost::panic_handler: done
[ 2041.634/0] Reclaimed 0 WQE and 0 FPA entries from POW
[-- Attachment #3: vcrash.c --]
[-- Type: text/x-csrc, Size: 1001 bytes --]
/*
* A module that should crash the kernel on mips master core by using virt_to_page on a
* softirq stack address.
*
* Cosmin Ratiu <cratiu@ixiacom.com>
*/
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/cpu.h>
#include <linux/timer.h>
#include <linux/mm.h>
struct timer_list t[NR_CPUS];
void vcrash(unsigned long data)
{
int x;
printk("core %i: &x %p virt_to_phys(&x) %lx\n", smp_processor_id(), &x, virt_to_phys(&x));
printk("core %i: virt_to_page(&x) %p\n", smp_processor_id(), virt_to_page(&x));
}
int vcrash_init(void)
{
int cpu;
printk("vcrash initializing\n");
for_each_online_cpu(cpu) {
init_timer(t + cpu);
t[cpu].expires = jiffies + 2 * HZ;
t[cpu].function = vcrash;
add_timer_on(t + cpu, cpu);
}
return 0;
}
void vcrash_exit(void)
{
int cpu;
for_each_online_cpu(cpu) {
del_timer_sync(t + cpu);
}
printk("vcrash exiting\n");
}
module_init(vcrash_init);
module_exit(vcrash_exit);
MODULE_AUTHOR("Cosmin Ratiu");
MODULE_LICENSE("GPL");
[-- Attachment #4: tcp-md5-crash.diff --]
[-- Type: text/x-patch, Size: 4762 bytes --]
Change 3360379 by cratiu@cratiu on 2011/09/02 09:44:48 *pending*
TCP/md5: Switch from a stack var to a percpu var to avoid a crash.
tcp_v4_send_ack uses a stack variable to construct the TCP header for
the response packet.
When using TCP MD5 signatures on mips architecture a crash happens
sometimes when the current core is the master core using the initial
stack allocated in vmlinux.
The reason for this is that the initial stack is mapped in kseg2
so it can't be directly translated to a physical address by
virt_to_phys as expected by sg_set_buf from the following call chain:
> (optimized: sg_set_buf)
> sg_init_one+0x58/0xa4
> tcp_md5_hash_header+0x30/0x64
> tcp_v4_md5_hash_hdr+0xb4/0x134
> tcp_v4_send_ack+0x16c/0x25c
> (optimized: tcp_v4_timewait_ack)
> tcp_v4_rcv+0x1b3c/0x1e58
As a temporary fix that should not affect performance, the stack
variable is converted in a percpu variable allocated at boot time.
Affected files ...
... //packages/linux_2.6.32/main/src/include/net/tcp.h#6 edit
... //packages/linux_2.6.32/main/src/net/ipv4/tcp.c#11 edit
... //packages/linux_2.6.32/main/src/net/ipv4/tcp_ipv4.c#15 edit
include/net/tcp.h | 10 +++++++++
net/ipv4/tcp.c | 5 ++++
net/ipv4/tcp_ipv4.c | 53 ++++++++++++++++++++++++----------------------------
3 files changed, 40 insertions(+), 28 deletions(-)
Signed-off-by: Cosmin Ratiu <cratiu@ixiacom.com>
--- src/include/net/tcp.h~
+++ src/include/net/tcp.h
@@ -1570,5 +1570,15 @@
return skc->skc_net_params->tcp.rmem;
}
+struct tcp_reply_hdr {
+ struct tcphdr th;
+ __be32 opt[(TCPOLEN_TSTAMP_ALIGNED >> 2)
+#ifdef CONFIG_TCP_MD5SIG
+ + (TCPOLEN_MD5SIG_ALIGNED >> 2)
+#endif
+ ];
+};
+
+extern struct tcp_reply_hdr *tcp_rep_percpu;
#endif /* _TCP_H */
--- src/net/ipv4/tcp.c~
+++ src/net/ipv4/tcp.c
@@ -3150,6 +3150,11 @@
tcp_hashinfo.lhash_size);
tcp_register_congestion_control(&tcp_reno);
+
+ /* Hack alert: a proper fix should be implemented for the md5 crash */
+ tcp_rep_percpu = alloc_percpu(struct tcp_reply_hdr);
+ if (!tcp_rep_percpu)
+ panic("Cannot allocate per cpu tcp reply hdr\n");
}
EXPORT_SYMBOL(tcp_close);
--- src/net/ipv4/tcp_ipv4.c~
+++ src/net/ipv4/tcp_ipv4.c
@@ -680,6 +680,8 @@
SOCK_STAT_INC(groupptr, TcpRstSent, skb_get_portid(skb));
}
+struct tcp_reply_hdr *tcp_rep_percpu;
+
/* The code following below sending ACKs in SYN-RECV and TIME-WAIT states
outside socket context is ugly, certainly. What can I do?
*/
@@ -691,53 +693,48 @@
int reply_flags, u32 vlanprio)
{
struct tcphdr *th = tcp_hdr(skb);
- struct {
- struct tcphdr th;
- __be32 opt[(TCPOLEN_TSTAMP_ALIGNED >> 2)
-#ifdef CONFIG_TCP_MD5SIG
- + (TCPOLEN_MD5SIG_ALIGNED >> 2)
-#endif
- ];
- } rep;
+ struct tcp_reply_hdr *rep;
struct ip_reply_arg arg;
- memset(&rep.th, 0, sizeof(struct tcphdr));
+ rep = per_cpu_ptr(tcp_rep_percpu, get_cpu());
+
+ memset(&rep->th, 0, sizeof(struct tcphdr));
memset(&arg, 0, sizeof(arg));
- arg.iov[0].iov_base = (unsigned char *)&rep;
- arg.iov[0].iov_len = sizeof(rep.th);
+ arg.iov[0].iov_base = (unsigned char *)rep;
+ arg.iov[0].iov_len = sizeof(rep->th);
if (ts) {
- rep.opt[0] = htonl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) |
+ rep->opt[0] = htonl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) |
(TCPOPT_TIMESTAMP << 8) |
TCPOLEN_TIMESTAMP);
- rep.opt[1] = htonl(tcp_time_stamp);
- rep.opt[2] = htonl(ts);
+ rep->opt[1] = htonl(tcp_time_stamp);
+ rep->opt[2] = htonl(ts);
arg.iov[0].iov_len += TCPOLEN_TSTAMP_ALIGNED;
}
/* Swap the send and the receive. */
- rep.th.dest = th->source;
- rep.th.source = th->dest;
- rep.th.doff = arg.iov[0].iov_len / 4;
- rep.th.seq = htonl(seq);
- rep.th.ack_seq = htonl(ack);
- rep.th.ack = 1;
- rep.th.window = htons(win);
+ rep->th.dest = th->source;
+ rep->th.source = th->dest;
+ rep->th.doff = arg.iov[0].iov_len / 4;
+ rep->th.seq = htonl(seq);
+ rep->th.ack_seq = htonl(ack);
+ rep->th.ack = 1;
+ rep->th.window = htons(win);
#ifdef CONFIG_TCP_MD5SIG
if (key) {
int offset = (ts) ? 3 : 0;
- rep.opt[offset++] = htonl((TCPOPT_NOP << 24) |
- (TCPOPT_NOP << 16) |
- (TCPOPT_MD5SIG << 8) |
- TCPOLEN_MD5SIG);
+ rep->opt[offset++] = htonl((TCPOPT_NOP << 24) |
+ (TCPOPT_NOP << 16) |
+ (TCPOPT_MD5SIG << 8) |
+ TCPOLEN_MD5SIG);
arg.iov[0].iov_len += TCPOLEN_MD5SIG_ALIGNED;
- rep.th.doff = arg.iov[0].iov_len/4;
+ rep->th.doff = arg.iov[0].iov_len/4;
- tcp_v4_md5_hash_hdr((__u8 *) &rep.opt[offset],
+ tcp_v4_md5_hash_hdr((__u8 *) &rep->opt[offset],
key, ip_hdr(skb)->saddr,
- ip_hdr(skb)->daddr, &rep.th);
+ ip_hdr(skb)->daddr, &rep->th);
}
#endif
arg.flags = reply_flags;
^ permalink raw reply
* Re: [PATCH 2/2] GRETH: avoid overwrite IP-stack's IP-frags checksum
From: Eric Dumazet @ 2011-09-09 13:29 UTC (permalink / raw)
To: Daniel Hellstrom; +Cc: davem, netdev, kristoffer
In-Reply-To: <1315487676-16733-2-git-send-email-daniel@gaisler.com>
Le jeudi 08 septembre 2011 à 15:14 +0200, Daniel Hellstrom a écrit :
> The GRETH GBIT core does not do checksum offloading for IP
> segmentation. This patch adds a check in the xmit function to
> determine if the stack has calculated the checksum for us.
>
> Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
> ---
> drivers/net/greth.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/greth.c b/drivers/net/greth.c
> index 9d39fb9..27ba855 100644
> --- a/drivers/net/greth.c
> +++ b/drivers/net/greth.c
> @@ -489,7 +489,8 @@ greth_start_xmit_gbit(struct sk_buff *skb, struct net_device *dev)
> if (nr_frags != 0)
> status = GRETH_TXBD_MORE;
>
> - status |= GRETH_TXBD_CSALL;
> + if (skb->ip_summed == CHECKSUM_PARTIAL)
> + status |= GRETH_TXBD_CSALL;
> status |= skb_headlen(skb) & GRETH_BD_LEN;
> if (greth->tx_next == GRETH_TXBD_NUM_MASK)
> status |= GRETH_BD_WR;
> @@ -512,7 +513,9 @@ greth_start_xmit_gbit(struct sk_buff *skb, struct net_device *dev)
> greth->tx_skbuff[curr_tx] = NULL;
> bdp = greth->tx_bd_base + curr_tx;
>
> - status = GRETH_TXBD_CSALL | GRETH_BD_EN;
> + status = GRETH_BD_EN;
> + if (skb->ip_summed == CHECKSUM_PARTIAL)
> + status | GRETH_TXBD_CSALL;
typo here ?
> status |= frag->size & GRETH_BD_LEN;
>
> /* Wrap around descriptor ring */
^ permalink raw reply
* Re: [PATCH 03/10] mm: Add support for a filesystem to control swap files
From: Christoph Hellwig @ 2011-09-09 13:36 UTC (permalink / raw)
To: Mel Gorman
Cc: Christoph Hellwig, Linux-MM, Linux-Netdev, Linux-NFS, LKML,
Andrew Morton, David Miller, Trond Myklebust, Neil Brown,
Peter Zijlstra
In-Reply-To: <20110909131550.GV14369@suse.de>
On Fri, Sep 09, 2011 at 02:15:50PM +0100, Mel Gorman wrote:
>
> I confess I haven't investigated this direction at
> all yet. Is it correct that your previous objection was
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-10/msg00455.html
> and the direct-IO patchset you were thinking of was
> http://copilotco.com/mail-archives/linux-kernel.2009/msg87176.html ?
Yes.
> If so, are you suggesting that instead of swap_readpage and
> swap_writepage I look into what is required for swap to use ->readpage
> method and ->direct_IO aops?
The equivalent of ->direct_IO should be used for both reads and writes.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2 3/5] SUNRPC: make RPC service dependable on rpcbind clients creation
From: Jeff Layton @ 2011-09-09 14:07 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bfields-uC3wQj2KruNg9hUCZPvPmw, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20110909120844.13697.48102.stgit-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
On Fri, 09 Sep 2011 16:08:44 +0400
Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
> Create rcbind clients or increase rpcbind users counter during RPC service
> creation and decrease this counter (and possibly destroy those clients) on RPC
> service destruction.
>
> Signed-off-by: Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
>
> ---
> include/linux/sunrpc/clnt.h | 2 ++
> net/sunrpc/rpcb_clnt.c | 2 +-
> net/sunrpc/svc.c | 13 +++++++++++--
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/sunrpc/clnt.h b/include/linux/sunrpc/clnt.h
> index db7bcaf..65a8115 100644
> --- a/include/linux/sunrpc/clnt.h
> +++ b/include/linux/sunrpc/clnt.h
> @@ -135,10 +135,12 @@ void rpc_shutdown_client(struct rpc_clnt *);
> void rpc_release_client(struct rpc_clnt *);
> void rpc_task_release_client(struct rpc_task *);
>
> +int rpcb_create_local(void);
> int rpcb_register(u32, u32, int, unsigned short);
> int rpcb_v4_register(const u32 program, const u32 version,
> const struct sockaddr *address,
> const char *netid);
> +void rpcb_put_local(void);
> void rpcb_getport_async(struct rpc_task *);
>
> void rpc_call_start(struct rpc_task *);
> diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
> index b4cc0f1..437ec60 100644
> --- a/net/sunrpc/rpcb_clnt.c
> +++ b/net/sunrpc/rpcb_clnt.c
> @@ -318,7 +318,7 @@ out:
> * Returns zero on success, otherwise a negative errno value
> * is returned.
> */
> -static int rpcb_create_local(void)
> +int rpcb_create_local(void)
> {
> static DEFINE_MUTEX(rpcb_create_local_mutex);
> int result = 0;
> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
> index 6a69a11..9095c0e 100644
> --- a/net/sunrpc/svc.c
> +++ b/net/sunrpc/svc.c
> @@ -367,8 +367,11 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
> unsigned int xdrsize;
> unsigned int i;
>
> - if (!(serv = kzalloc(sizeof(*serv), GFP_KERNEL)))
> + if (rpcb_create_local() < 0)
> return NULL;
> +
> + if (!(serv = kzalloc(sizeof(*serv), GFP_KERNEL)))
> + goto out_err;
> serv->sv_name = prog->pg_name;
> serv->sv_program = prog;
> serv->sv_nrthreads = 1;
> @@ -403,7 +406,7 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
> GFP_KERNEL);
> if (!serv->sv_pools) {
> kfree(serv);
> - return NULL;
> + goto out_err;
> }
>
> for (i = 0; i < serv->sv_nrpools; i++) {
> @@ -423,6 +426,10 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
> svc_unregister(serv);
>
> return serv;
> +
> +out_err:
> + rpcb_put_local();
> + return NULL;
> }
>
> struct svc_serv *
> @@ -491,6 +498,8 @@ svc_destroy(struct svc_serv *serv)
> svc_unregister(serv);
> kfree(serv->sv_pools);
> kfree(serv);
> +
> + rpcb_put_local();
> }
> EXPORT_SYMBOL_GPL(svc_destroy);
>
>
I don't get it -- what's the advantage of creating rpcbind clients in
__svc_create vs. the old way of creating them just before we plan to
use them?
With this scheme, won't we end up creating rpcbind sockets even when we
don't need them? For instance, if I create a callback socket for NFSv4
then I don't really need to talk to rpcbind. With this patch I'll still
get the rpcbind clients created though.
It would seem to me to make more sense to create the rpcbind clients
somewhere closer to svc_setup_socket, and only if SVC_SOCK_ANONYMOUS is
not set.
--
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] RDSRDMA: Fix to PAGE_MASK interpretation
From: Venkat Venkatsubra @ 2011-09-09 14:35 UTC (permalink / raw)
To: Netdev, Rds-Devel; +Cc: Davem
On 08/29/2011 02:28 PM, Jonathan Lallinger wrote:
> The RDS_RDMA rds_iw_map_scatterlist function assumed PAGE_MASK was the bitwise
> compliment of what it actually is. This problem was introduced in commit
> 404bb72a56e553febe1055f98347a7a3e3145759 when the variable dma_mask was replaced
> by PAGE_MASK, however dma_mask represented the compliment of what PAGE_MASK
> represents.
>
> This fix corrects the logic by flipping the compliments on all uses of PAGE_MASK
> int rds_iw_map_scatterlist.
>
> Signed-off by: Jonathan Lallinger<jonathan@ogc.us>
Signed-off-by: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Venkat
^ permalink raw reply
* [PATCH] RDSRDMA: Fix cleanup of rds_iw_mr_pool
From: Venkat Venkatsubra @ 2011-09-09 14:37 UTC (permalink / raw)
To: Netdev, Rds-Devel; +Cc: Davem
On 09/08/2011 01:04 PM, Jonathan Lallinger wrote:
> In the rds_iw_mr_pool struct the free_pinned field keeps track of memory pinned
> by free MRs. While this field is incremented properly upon allocation, it is never
> decremented upon unmapping. This would cause the rds_rdma module to crash the
> kernel upon unloading, by triggering the BUG_ON in the rds_iw_destroy_mr_pool
> function.
>
> This change keeps track of the MRs that become unpinned, so that free_pinned
> can be decremented appropriately.
>
> Signed-off-by: Jonathan Lallinger<jonathan@ogc.us>
> Signed-off-by: Steve Wise<swise@ogc.us>
Signed-off-by: Venkat Venkatsubra<venkat.x.venkatsubra@oracle.com>
Venkat
^ permalink raw reply
* [PATCH net-next] af_unix: use fragments in unix_dgram_sendmsg()
From: Eric Dumazet @ 2011-09-09 14:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andi Kleen, Tim Chen
unix_dgram_sendmsg() currently builds basic skbs, with a possible huge
head.
This patch uses up to MAX_SKB_FRAGS fragments to reduce the head size.
This lowers memory pressure on high order LOWMEM pages
(frags pages can be allocated from HIGHMEM).
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/unix/af_unix.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 1bd4ecf..58570f5 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1420,6 +1420,7 @@ static int unix_dgram_sendmsg(struct kiocb *kiocb, struct socket *sock,
long timeo;
struct scm_cookie tmp_scm;
int max_level;
+ int fragslen = 0;
if (NULL == siocb->scm)
siocb->scm = &tmp_scm;
@@ -1453,18 +1454,28 @@ static int unix_dgram_sendmsg(struct kiocb *kiocb, struct socket *sock,
if (len > sk->sk_sndbuf - 32)
goto out;
- skb = sock_alloc_send_skb(sk, len, msg->msg_flags&MSG_DONTWAIT, &err);
+ /* try to use fragments to get order-0 header allocation */
+ if (len > SKB_MAX_ORDER(0, 0))
+ fragslen = min_t(size_t,
+ len - SKB_MAX_ORDER(0, 0),
+ MAX_SKB_FRAGS * PAGE_SIZE);
+
+ skb = sock_alloc_send_pskb(sk, len - fragslen, fragslen,
+ msg->msg_flags & MSG_DONTWAIT, &err);
if (skb == NULL)
goto out;
+ skb_put(skb, len - fragslen);
+ skb->data_len = fragslen;
+ skb->len = len;
+
err = unix_scm_to_skb(siocb->scm, skb, true, true);
if (err < 0)
goto out_free;
max_level = err + 1;
unix_get_secdata(siocb->scm, skb);
- skb_reset_transport_header(skb);
- err = memcpy_fromiovec(skb_put(skb, len), msg->msg_iov, len);
+ err = skb_copy_datagram_from_iovec(skb, 0, msg->msg_iov, 0, len);
if (err)
goto out_free;
^ permalink raw reply related
* Re: [PATCH 2/2] GRETH: avoid overwrite IP-stack's IP-frags checksum
From: Daniel Hellstrom @ 2011-09-09 14:41 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, kristoffer
In-Reply-To: <1315574967.2294.28.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 09/09/2011 03:29 PM, Eric Dumazet wrote:
> Le jeudi 08 septembre 2011 à 15:14 +0200, Daniel Hellstrom a écrit :
>> The GRETH GBIT core does not do checksum offloading for IP
>> segmentation. This patch adds a check in the xmit function to
>> determine if the stack has calculated the checksum for us.
>>
>> Signed-off-by: Daniel Hellstrom<daniel@gaisler.com>
>> ---
>> drivers/net/greth.c | 7 +++++--
>> 1 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/greth.c b/drivers/net/greth.c
>> index 9d39fb9..27ba855 100644
>> --- a/drivers/net/greth.c
>> +++ b/drivers/net/greth.c
>> @@ -489,7 +489,8 @@ greth_start_xmit_gbit(struct sk_buff *skb, struct net_device *dev)
>> if (nr_frags != 0)
>> status = GRETH_TXBD_MORE;
>>
>> - status |= GRETH_TXBD_CSALL;
>> + if (skb->ip_summed == CHECKSUM_PARTIAL)
>> + status |= GRETH_TXBD_CSALL;
>> status |= skb_headlen(skb)& GRETH_BD_LEN;
>> if (greth->tx_next == GRETH_TXBD_NUM_MASK)
>> status |= GRETH_BD_WR;
>> @@ -512,7 +513,9 @@ greth_start_xmit_gbit(struct sk_buff *skb, struct net_device *dev)
>> greth->tx_skbuff[curr_tx] = NULL;
>> bdp = greth->tx_bd_base + curr_tx;
>>
>> - status = GRETH_TXBD_CSALL | GRETH_BD_EN;
>> + status = GRETH_BD_EN;
>> + if (skb->ip_summed == CHECKSUM_PARTIAL)
>> + status | GRETH_TXBD_CSALL;
> typo here ?
Hi,
You're right, I had a missed space there so the code-style check failed at that line, then I fixed that by adding a space... but must have screwed it up. Will repost patch.
Thanks,
Daniel
>
>> status |= frag->size& GRETH_BD_LEN;
>>
>> /* Wrap around descriptor ring */
>
> --
> 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: [PATCH net-next-2.6] can/sja1000: driver for PEAK PCAN PCI/PCIe cards
From: Oliver Hartkopp @ 2011-09-09 14:42 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: SocketCAN Core Mailing List, Netdev-u79uwXL29TY76Z2rM5mHXA,
linux-g4cQ8AsIbFbL9ATBNaCtXw, Thomas Wiedemann
In-Reply-To: <4E692080.9020801-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Hello Wolfgang,
many thanks for providing this patch!
On 09/08/11 22:07, Wolfgang Grandegger wrote:
> This patch adds the "peak_pci" driver for the PCAN PCI/PCIe cards (1, 2, 3
> or 4 channels) from PEAK Systems (http://www.peak-system.com).
Yes - that fits, but ...
> +#define PEAK_PCI_VENDOR_ID 0x001C /* The PCI device and vendor IDs */
> +#define PEAK_PCI_DEVICE_ID 0x0001 /* for PCI / PCIe slot cards */
> +#define PEAK_PCIE_DEVICE_ID 0x0002 /* for PCIExpress cards */
> +
> +static const u16 peak_pci_icr_masks[] = {0x02, 0x01, 0x40, 0x80};
> +
> +static DEFINE_PCI_DEVICE_TABLE(peak_pci_tbl) = {
> + {PEAK_PCI_VENDOR_ID, PEAK_PCI_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
> + {PEAK_PCI_VENDOR_ID, PEAK_PCIE_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
> + {0,}
> +};
The problem is the support of the PCAN ExpressCard (device ID 0x0002) here.
This commit
https://lists.berlios.de/pipermail/socketcan-commit/2010-June/000814.html
should be reverted, as you can use the PCAN-ExpressCard (IPEH-00300[12]) only
with a hardware patch, as we need some I2C initialisations to enable the CAN
transceiver (and the funky status LEDs). See at:
http://anonscm.debian.org/gitweb/?p=collab-maint/peak-linux-driver.git;a=blob;f=driver/src/pcan_pciec.c;h=87ce0bda41aa0a6dda8284d48237b1ef7c678e11;hb=HEAD#l36
I'll also test your driver on Monday.
Tnx & best regards,
Oliver
^ permalink raw reply
* Re: [PATCH 02/15] user ns: setns: move capable checks into per-ns attach helper
From: Serge E. Hallyn @ 2011-09-09 14:56 UTC (permalink / raw)
To: Matt Helsley
Cc: akpm, segooon, linux-kernel, netdev, containers, dhowells,
ebiederm, rdunlap
In-Reply-To: <20110904015140.GB32295@count0.beaverton.ibm.com>
Quoting Matt Helsley (matthltc@us.ibm.com):
> On Fri, Sep 02, 2011 at 07:56:27PM +0000, Serge Hallyn wrote:
> > From: "Serge E. Hallyn" <serge@hallyn.com>
>
> I was confused about this patch until I realized that you're not
> simply "moving" the capability checks but "distributing" them. Then
> you're showing that you'll soon change some to nsown_capable() or
> ns_capable() using the strange cpp pattern in the snippet below.
>
> At least I think that's what you intended. A commit message would
> help :).
Yes, sorry - Eric convinced me several times to be more conservative in
the patch, and I failed to fix the commit msg when squashing the
resulting patches. How about the following:
======
user ns: update capable calls when cloning and attaching namespaces
Distribute the capable() checks at ns attach into the namespace-specific
attach handler.
Note the fact that the capable() checks will be changed to targeted
checks at both namespace clone and attach methods, but don't actually
make that change yet. Until that trigger is pulled, you must have
the capabilities targeted toward the initial user namespace in order to
do any of these actions, meaning that a task in a child user namespace
cannot do them. Once we pull the trigger, a task in a child user
namespace will be able to clone new namespaces if it is privileged in
its own user namespace, and attach to existing namespaces to which it
has privilege.
======
Thanks for taking a look, Matt!
-serge
^ permalink raw reply
* [PATCH 2/2 v2] GRETH: avoid overwrite IP-stack's IP-frags checksum
From: Daniel Hellstrom @ 2011-09-09 15:17 UTC (permalink / raw)
To: davem; +Cc: netdev, kristoffer, eric.dumazet
The GRETH GBIT core does not do checksum offloading for IP
segmentation. This patch adds a check in the xmit function to
determine if the stack has calculated the checksum for us.
Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
---
drivers/net/greth.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index 22e24a3..6775c24 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -489,7 +489,8 @@ greth_start_xmit_gbit(struct sk_buff *skb, struct net_device *dev)
if (nr_frags != 0)
status = GRETH_TXBD_MORE;
- status |= GRETH_TXBD_CSALL;
+ if (skb->ip_summed == CHECKSUM_PARTIAL)
+ status |= GRETH_TXBD_CSALL;
status |= skb_headlen(skb) & GRETH_BD_LEN;
if (greth->tx_next == GRETH_TXBD_NUM_MASK)
status |= GRETH_BD_WR;
@@ -512,7 +513,9 @@ greth_start_xmit_gbit(struct sk_buff *skb, struct net_device *dev)
greth->tx_skbuff[curr_tx] = NULL;
bdp = greth->tx_bd_base + curr_tx;
- status = GRETH_TXBD_CSALL | GRETH_BD_EN;
+ status = GRETH_BD_EN;
+ if (skb->ip_summed == CHECKSUM_PARTIAL)
+ status |= GRETH_TXBD_CSALL;
status |= frag->size & GRETH_BD_LEN;
/* Wrap around descriptor ring */
--
1.5.4
^ permalink raw reply related
* Re: [PATCH net-next-2.6] can/sja1000: driver for PEAK PCAN PCI/PCIe cards
From: Wolfgang Grandegger @ 2011-09-09 15:20 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: SocketCAN Core Mailing List, Netdev-u79uwXL29TY76Z2rM5mHXA,
linux-g4cQ8AsIbFbL9ATBNaCtXw, Thomas Wiedemann
In-Reply-To: <4E6A25EE.3000501-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Hi Oliver,
On 09/09/2011 04:42 PM, Oliver Hartkopp wrote:
> Hello Wolfgang,
>
> many thanks for providing this patch!
>
> On 09/08/11 22:07, Wolfgang Grandegger wrote:
>
>> This patch adds the "peak_pci" driver for the PCAN PCI/PCIe cards (1, 2, 3
>> or 4 channels) from PEAK Systems (http://www.peak-system.com).
>
>
> Yes - that fits, but ...
>
>
>> +#define PEAK_PCI_VENDOR_ID 0x001C /* The PCI device and vendor IDs */
>> +#define PEAK_PCI_DEVICE_ID 0x0001 /* for PCI / PCIe slot cards */
>> +#define PEAK_PCIE_DEVICE_ID 0x0002 /* for PCIExpress cards */
>> +
>> +static const u16 peak_pci_icr_masks[] = {0x02, 0x01, 0x40, 0x80};
>> +
>> +static DEFINE_PCI_DEVICE_TABLE(peak_pci_tbl) = {
>> + {PEAK_PCI_VENDOR_ID, PEAK_PCI_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
>> + {PEAK_PCI_VENDOR_ID, PEAK_PCIE_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
>> + {0,}
>> +};
>
>
> The problem is the support of the PCAN ExpressCard (device ID 0x0002) here.
>
> This commit
>
> https://lists.berlios.de/pipermail/socketcan-commit/2010-June/000814.html
>
> should be reverted, as you can use the PCAN-ExpressCard (IPEH-00300[12]) only
> with a hardware patch, as we need some I2C initialisations to enable the CAN
> transceiver (and the funky status LEDs). See at:
>
> http://anonscm.debian.org/gitweb/?p=collab-maint/peak-linux-driver.git;a=blob;f=driver/src/pcan_pciec.c;h=87ce0bda41aa0a6dda8284d48237b1ef7c678e11;hb=HEAD#l36
OK, I see, I will revert then. I already realized the I2C stuff for the
PCAN-ExpressCard. Obviously Thomas does not use that card but a PCIe
slot cards
> I'll also test your driver on Monday.
Thanks,
Wolfgang.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Roopa Prabhu @ 2011-09-09 16:21 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: Michael S. Tsirkin, netdev, dragos.tatulea, arnd, dwang2, benve,
kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <4E699556.6050809@us.ibm.com>
On 9/8/11 9:25 PM, "Sridhar Samudrala" <sri@us.ibm.com> wrote:
> On 9/8/2011 8:00 PM, Roopa Prabhu wrote:
>>
>>
>> On 9/8/11 12:33 PM, "Michael S. Tsirkin"<mst@redhat.com> wrote:
>>
>>> On Thu, Sep 08, 2011 at 12:23:56PM -0700, Roopa Prabhu wrote:
>>>>> I think the main usecase for passthru mode is to assign a SR-IOV VF to
>>>>> a single guest.
>>>>>
>>>> Yes and for the passthru usecase this patch should be enough to enable
>>>> filtering in hw (eventually like I indicated before I need to fix vlan
>>>> filtering too).
>>> So with filtering in hw, and in sriov VF case, VFs
>>> actually share a filtering table. How will that
>>> be partitioned?
>> AFAIK, though it might maintain a single filter table space in hw, hw does
>> know which filter belongs to which VF. And the OS driver does not need to do
>> anything special. The VF driver exposes a VF netdev. And any uc/mc addresses
>> registered with a VF netdev are registered with the hw by the driver. And hw
>> will filter and send only pkts that the VF has expressed interest in.
> Does your NIC & driver support adding multiple mac addresses to a VF?
> I have tried a few other SR-IOV NICs sometime back and they didn't
> support this feature.
Yes our nic does. I thought Intel's also does (see ixgbevf_set_rx_mode).
Though I have not really tried using it on an Intel card. I think most cards
should at the least support multicast filters.
If the lower dev does not support unicast filtering, dev_uc_add(lowerdev,..)
puts the lower dev in promiscous mode. Though..i think I can chcek this
before hand in macvlan_open and put the lowerdev in promiscuous mode if it
does not support filtering.
>
> Currently, we don't have an interface to add multiple mac addresses to a
> netdev other than an
> indirect way of creating a macvlan /if on top of it.
Yes I think so. I have been using only macvlan to test.
Thanks,
Roopa
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Roopa Prabhu @ 2011-09-09 16:33 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, dragos.tatulea, arnd, dwang2, benve, kaber, sri, davem,
eric.dumazet, mchan, kvm
In-Reply-To: <20110909055530.GA4647@redhat.com>
On 9/8/11 10:55 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Thu, Sep 08, 2011 at 07:53:11PM -0700, Roopa Prabhu wrote:
>>>> Phase 1: Goal: Enable hardware filtering for all macvlan modes
>>>> - In macvlan passthru mode the single guest virtio-nic connected will
>>>> receive traffic that he requested for
>>>> - In macvlan non-passthru mode all guest virtio-nics sharing the
>>>> physical nic will see all other guest traffic
>>>> but the filtering at guest virtio-nic
>>>
>>> I don't think guests currently filter anything.
>>>
>> I was referring to Qemu-kvm virtio-net in
>> virtion_net_receive->receive_filter. I think It only passes pkts that the
>> guest OS is interested. It uses the filter table that I am passing to
>> macvtap in this patch.
>
> This happens after userspace thread gets woken up and data
> is copied there. So relying on filtering at that level is
> going to be very inefficient on a system with
> multiple active guests. Further, and for that reason, vhost-net
> doesn't do filtering at all, relying on the backends
> to pass it correct packets.
Ok thanks for the info. So in which case, phase 1 is best for PASSTHRU mode
and for non-PASSTHRU when there is a single guest connected to a VF.
For non-PASSTHRU multi guest sharing the same VF, Phase 1 is definitely
better than putting the VF in promiscuous mode.
But to address the concern you mention above, in phase 2 when we have more
than one guest sharing the VF, we will have to add filter lookup in macvlan
to filter pkts for each guest. This will need some performance tests too.
Will start investigating the netlink interface comments for phase 1 first.
Thanks!
-Roopa
^ permalink raw reply
* Re: [PATCH v2 3/5] SUNRPC: make RPC service dependable on rpcbind clients creation
From: Stanislav Kinsbursky @ 2011-09-09 16:41 UTC (permalink / raw)
To: Jeff Layton
Cc: Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
Pavel Emelianov, neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, bfields@fieldses.org,
davem@davemloft.net
In-Reply-To: <20110909100745.7e2e8bf9@corrin.poochiereds.net>
09.09.2011 18:07, Jeff Layton пишет:
> On Fri, 09 Sep 2011 16:08:44 +0400
> Stanislav Kinsbursky<skinsbursky@parallels.com> wrote:
>
>> Create rcbind clients or increase rpcbind users counter during RPC service
>> creation and decrease this counter (and possibly destroy those clients) on RPC
>> service destruction.
>>
>> Signed-off-by: Stanislav Kinsbursky<skinsbursky@parallels.com>
>>
>> ---
>> include/linux/sunrpc/clnt.h | 2 ++
>> net/sunrpc/rpcb_clnt.c | 2 +-
>> net/sunrpc/svc.c | 13 +++++++++++--
>> 3 files changed, 14 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/linux/sunrpc/clnt.h b/include/linux/sunrpc/clnt.h
>> index db7bcaf..65a8115 100644
>> --- a/include/linux/sunrpc/clnt.h
>> +++ b/include/linux/sunrpc/clnt.h
>> @@ -135,10 +135,12 @@ void rpc_shutdown_client(struct rpc_clnt *);
>> void rpc_release_client(struct rpc_clnt *);
>> void rpc_task_release_client(struct rpc_task *);
>>
>> +int rpcb_create_local(void);
>> int rpcb_register(u32, u32, int, unsigned short);
>> int rpcb_v4_register(const u32 program, const u32 version,
>> const struct sockaddr *address,
>> const char *netid);
>> +void rpcb_put_local(void);
>> void rpcb_getport_async(struct rpc_task *);
>>
>> void rpc_call_start(struct rpc_task *);
>> diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
>> index b4cc0f1..437ec60 100644
>> --- a/net/sunrpc/rpcb_clnt.c
>> +++ b/net/sunrpc/rpcb_clnt.c
>> @@ -318,7 +318,7 @@ out:
>> * Returns zero on success, otherwise a negative errno value
>> * is returned.
>> */
>> -static int rpcb_create_local(void)
>> +int rpcb_create_local(void)
>> {
>> static DEFINE_MUTEX(rpcb_create_local_mutex);
>> int result = 0;
>> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
>> index 6a69a11..9095c0e 100644
>> --- a/net/sunrpc/svc.c
>> +++ b/net/sunrpc/svc.c
>> @@ -367,8 +367,11 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
>> unsigned int xdrsize;
>> unsigned int i;
>>
>> - if (!(serv = kzalloc(sizeof(*serv), GFP_KERNEL)))
>> + if (rpcb_create_local()< 0)
>> return NULL;
>> +
>> + if (!(serv = kzalloc(sizeof(*serv), GFP_KERNEL)))
>> + goto out_err;
>> serv->sv_name = prog->pg_name;
>> serv->sv_program = prog;
>> serv->sv_nrthreads = 1;
>> @@ -403,7 +406,7 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
>> GFP_KERNEL);
>> if (!serv->sv_pools) {
>> kfree(serv);
>> - return NULL;
>> + goto out_err;
>> }
>>
>> for (i = 0; i< serv->sv_nrpools; i++) {
>> @@ -423,6 +426,10 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
>> svc_unregister(serv);
>>
>> return serv;
>> +
>> +out_err:
>> + rpcb_put_local();
>> + return NULL;
>> }
>>
>> struct svc_serv *
>> @@ -491,6 +498,8 @@ svc_destroy(struct svc_serv *serv)
>> svc_unregister(serv);
>> kfree(serv->sv_pools);
>> kfree(serv);
>> +
>> + rpcb_put_local();
>> }
>> EXPORT_SYMBOL_GPL(svc_destroy);
>>
>>
>
> I don't get it -- what's the advantage of creating rpcbind clients in
> __svc_create vs. the old way of creating them just before we plan to
> use them?
>
The main problem here is not in creation, but in destroying those clients.
Now rpcbind clients are created during rpcb_register(). I.e. once per every family, program version and so on.
But can be unregistered for all protocol families by one call. So it's impossible to put reference counting for those clients in the place, where they are created now.
> With this scheme, won't we end up creating rpcbind sockets even when we
> don't need them? For instance, if I create a callback socket for NFSv4
> then I don't really need to talk to rpcbind. With this patch I'll still
> get the rpcbind clients created though.
>
Yep, you right. This is not a real problem from my pow.
But I'll think about how to avoid this creation for nfs callbacks.
> It would seem to me to make more sense to create the rpcbind clients
> somewhere closer to svc_setup_socket, and only if SVC_SOCK_ANONYMOUS is
> not set.
>
Probably. Will try to find better place.
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: Octeon crash in virt_to_page(&core0_stack_variable)
From: David Daney @ 2011-09-09 16:59 UTC (permalink / raw)
To: Cosmin Ratiu; +Cc: linux-mips, netdev
In-Reply-To: <201109091623.29000.cratiu@ixiacom.com>
On 09/09/2011 06:23 AM, Cosmin Ratiu wrote:
> Hello,
>
> I've been investigating a strange crash and I wanted to ask for your help.
> The crash happens when virt_to_page is called with an address from the softirq
> stack of core 0 on Cavium Octeon. It may happen on other MIPS processors as
> well, but I'm not sure.
>
> I've attached a simple kernel module to demonstrate the problem and the output
> of dmesg + the crash. Two seconds after inserting the module, the kernel
> should crash.
>
> From what I've dug up in the kernel sources, it seems the stack for the first
> idle task resides in the data segment (mapped in kseg2) while the rest are
> allocated with kmalloc in __cpu_up() and reside in a different area (CAC_BASE
> upwards).
> It seems virt_to_phys produces bogus results for kseg2 and after that,
> virt_to_page crashes trying to access invalid memory.
>
> This problem was discovered when doing BGP traffic with the TCP MD5 option
> activated, where the following call chain caused a crash:
>
> * tcp_v4_rcv
> * tcp_v4_timewait_ack
> * tcp_v4_send_ack -> follow stack variable rep.th
> * tcp_v4_md5_hash_hdr
> * tcp_md5_hash_header
> * sg_init_one
> * sg_set_buf
> * virt_to_page
>
> I noticed that tcp_v4_send_reset uses a similar stack variable and also calls
> tcp_v4_md5_hash_hdr, so it has the same problem.
>
> I don't fully understand octeon mm details, so I wanted to bring up this issue
> in order to find a proper fix.
> To avoid the problem, I've implemented a quick hack to declare those variables
> percpu instead of on the stack, so they would also reside in CAC_BASE upwards.
> I've attached a patch against 2.6.32 for reference.
>
> Cosmin.
>
>
[...]
> [ 2040.300/0] Call Trace:
> [ 2040.300/0] [<ffffffffc123a054>] vcrash+0x54/0x80 [vcrash]
> [ 2040.300/0] [<ffffffffc0065f28>] run_timer_softirq+0x198/0x23c
> [ 2040.300/0] [<ffffffffc00609e0>] __do_softirq+0xd8/0x188
^^^^^^^^^ CKSEG2 addresses detected!
You are using the out-of-tree mapped kernel patch which mucks about with
the implementation of virt_to_phys().
Can you reproduce the TCP related crash in an unpatched kernel?
If not, then it would point to problems in the out-of-tree patches you
have applied.
David Daney
^ permalink raw reply
* Using gretap to tunnel layer 2 traffic
From: John H @ 2011-09-09 17:25 UTC (permalink / raw)
To: netdev@vger.kernel.org
I am attempting to tunnel Layer 2 traffic through a gretap device,
while encrypting the GRE tunnel with IPsec. My test environment is as follows:
10.0.1.1 10.0.1.2
client_a <--> server_left <==> server_right <---> client_b
gretap/IPsec
On the servers, I have two VLANs per server, corresponding to the unencrypted
and encrypted interfaces. On each server, the unencrypted VLAN is
bridged with the gretap device. All VLANs and physical devices have MTUs of
1500. The gretap device has a resultant MTU of 1462, thereby causing the
bridge device to have an MTU of 1462.
Traffic for the most part works as it is expected to behave. However,
packets are dropped when client_a sends an ICMP packet to client_b which
has an MTU less than client_a's device MTU but larger than server_left's
MTU. I suspect other protocols would behave similarly (silently dropping
packets). I an running "ping -c 1 -s 1450 10.0.1.2" on client_a, this results
in an ICMP packet being sent with an MTU of 1478.
An MTU of 1478 is larger than the bridge device's MTU of 1462, causing the
packet to be silently discarded per net/bridge/br_forward.c
in function br_dev_queue_push_xmit:
int br_dev_queue_push_xmit(struct sk_buff *skb)
{
/* drop mtu oversized packets except gso */
if (packet_length(skb) > skb->dev->mtu && !skb_is_gso(skb))
kfree_skb(skb);
else {
....
If the gretap device supported GSO, I suspect that this would not be a
problem. (ethtool -k gretapLeftRight states that GSO/GRO/LRO is not
supported)
Function br_dev_queue_push_xmit eventually calls ipgre_tunnel_xmit, if the
packet is not dropped.
I would think that br_dev_queue_push_xmit should call ipgre_tunnel_xmit
regardless of the device MTU and ipgre_tunnel_xmit would handle packet
fragmentation internally, but it never has the chance.
I have tried allowing all packets through br_dev_queue_push_xmit
and explicitly setting the Don't Frament field to 0 in ipgre_tunnel_xmit,
but this didn't solve problem.
Given that this would be tunneling Layer 2 traffic, it wouldn't make sense
to send an ICMP_FRAG_NEEDED response from the bridge.
The real question is, however, why is any client able to send a single ICMP
packet with size 1478 bytes when one of the hops along the way only
supports 1462 bytes per its MTU? Shouldn't this have been negotiated
beforehand?
^ 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