similar to: BUG: xend oopses on munmap of /proc/xen/privcmd

I observed several long running dovecot/lmtp processes hogging the CPU. I then strace'd them (strace -c -p 6375) and found them munmap()-ing a lot: % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 97.18 19.592537 1878 10430 munmap 2.28 0.458984 36 12696 epoll_ctl

Hi all! It seems the current ext3 code has some problems; my machine is running 2.4.6-ac1 with ext3-0.9 patches on top of it. This afternoon, I was doing some testing of a little piece of code on my machine, and I was able to crash it. What this program does is, in effect something like (pseudo-code) for(i=0; i<100; i++) { fd=creat file-i truncate fd, 50M mmap fd close fd fill the

The problem affects nv40 cards during booting. It comes from there being two places where subdev arrays are maintained. A commit was recently added to make the two equal. However, the struct nouveau_device version ends up being referenced before it is initialized. The problem arises during the creation of the INSTMEM and THERM subdevs. ' Signed off by: Bob Gleitsmann rjgleits at bellsouth.net

Hello all, Two oopses were found by zhaoyao and Daniel Blueman. Patch against 2.4.23 and 2.6.0-test10 is here. It will be included in next kernel releases of course. ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl

On Tue, Jan 14, 2014 at 1:22 PM, Bob Gleitsmann <rjgleits at bellsouth.net> wrote: > I should have mentioned that this applies to Linus' 3.13.0-rc7 and rc8 > git. Maybe it's obvious. Hey Bob, Thanks for reporting this. Can you try the attached patch instead and report if it helps you? Ben. > > Sorry about that. > > Bob > -------- Forwarded Message --------

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 10 Jun 2014, Charles Marcus wrote: > On 6/9/2014 5:44 PM, Ralf Hildebrandt <r at sys4.de> wrote: >> That's probably the problem here. The user had LOTS of (duplicate!) >> mails in his inbox. > > Anyone ever found a reliable way to do this? > > It sure would be nice if dovecot could perform this on a per

Hi all, In xen-4.1.2 source tree, under directory tools are there many library such lib*, what''s their individual feature? Besides, where is the log info for xl ? I try to trace using gdb after running xl, huge amounts of files\variable structure , complicated relationship between the components make me proceed slowly. Best regards

put_user() may fail. In this case propagate error code from privcmd_ioctl_mmap_batch(). Signed-off-by: Vasiliy Kulikov <segooon at gmail.com> --- Compile tested. drivers/xen/xenfs/privcmd.c | 8 ++------ 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c index f80be7f..2eb04c8 100644 ---

put_user() may fail. In this case propagate error code from privcmd_ioctl_mmap_batch(). Signed-off-by: Vasiliy Kulikov <segooon at gmail.com> --- Compile tested. drivers/xen/xenfs/privcmd.c | 8 ++------ 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c index f80be7f..2eb04c8 100644 ---

Hi Keir, I was encountering an odd error where Xend was tossing an EINVAL on xc_evtchn_alloc_unbound. After tracking it down, it turns out that this was because of an older userspace that was using the _compat version of the hypercalls. Since the hypervisor still supports these calls, is there a compelling reason to not allow privcmd to expose these calls? If not, please apply the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 10 Jun 2014, Reindl Harald wrote: > Am 10.06.2014 15:17, schrieb Steffen Kaiser: >> On Tue, 10 Jun 2014, Charles Marcus wrote: >>> On 6/9/2014 5:44 PM, Ralf Hildebrandt <r at sys4.de> wrote: >>>> That's probably the problem here. The user had LOTS of (duplicate!) >>>> mails in his inbox.

Hi, We've been experiencing repeated (every other day) oopses on hosts with high load glusterfs accesses. Co-occurrent (not immediately tho, but there is some sort of connection) are hanging nginx processes (doing the accessing), which can not be stopped, killed and also block the shutdown of the respective openvz instance. I think I remember at least one instance where this occurred without

If m.num is too large then the "m.num * sizeof(*m.arr)" multiplication could overflow and the access_ok() check wouldn't test the right size. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> --- Only needed in linux-next. diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 215a3c0..fdff8f9 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c

If m.num is too large then the "m.num * sizeof(*m.arr)" multiplication could overflow and the access_ok() check wouldn't test the right size. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> --- Only needed in linux-next. diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 215a3c0..fdff8f9 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c

I have an application ("The Rosetta Stone" 2.0.7a) which segfaults during the startup splash screen. According to strace() it is trying to munmap() an address (0x7a6b3000) which was never mmap()'d. I get identical behavior with Wine 20050111 and kernels 2.6.9 / 2.6.10 (I use gentoo-sources). I noticed some people had similar issues upgrading from 2.6.9 to 2.6.10.

When we use this pointer, we cast away the const modifier and modify the data. I think it was an accident to declare it as const. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h index a853168..58ed953 100644 --- a/include/xen/privcmd.h +++ b/include/xen/privcmd.h @@ -69,7 +69,7 @@ struct privcmd_mmapbatch_v2 {

When we use this pointer, we cast away the const modifier and modify the data. I think it was an accident to declare it as const. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h index a853168..58ed953 100644 --- a/include/xen/privcmd.h +++ b/include/xen/privcmd.h @@ -69,7 +69,7 @@ struct privcmd_mmapbatch_v2 {

I should have mentioned that this applies to Linus' 3.13.0-rc7 and rc8 git. Maybe it's obvious. Sorry about that. Bob -------- Forwarded Message -------- From: Bob Gleitsmann <rjgleits at bellsouth.net> To: bskeggs at redhat.com Cc: nouveau at lists.freedesktop.org, dri-devel at lists.freedesktop.org Subject: [PATCH] Fix null dereference oopses for nv40 cards Date: Mon, 13 Jan

On Tue, Jan 14, 2014 at 3:07 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > On Tue, Jan 14, 2014 at 1:22 PM, Bob Gleitsmann <rjgleits at bellsouth.net> wrote: >> I should have mentioned that this applies to Linus' 3.13.0-rc7 and rc8 >> git. Maybe it's obvious. > Hey Bob, > > Thanks for reporting this. Can you try the attached patch instead and >

OK - this is starting to get frustrating... Are there any known issues with 2.6.9 and traffic shaping? I am using 2.6.9 with geoip 20041115, and get odd oopses. The following script oopses my box: ----------------------------------------------------- #!/bin/sh -x IFOUT=''eth1'' IFIN=''eth0'' TC=''/sbin/tc''