On Monday 27 June 2011, 16:49:12 sf...@users.sourceforge.net wrote:
> "Hans-Peter Jansen":
> > Jun 25 15:21:46 kuno kernel: [ 4121.973627] ------------[ cut here
> > ]------------ Jun 25 15:21:46 kuno kernel: [ 4121.974561] kernel
> > BUG at
> > /usr/src/packages/BUILD/kernel-desktop-2.6.31.14/linux-2.6.31/mm/tr
> >uncate.c:44 6!
> >
> > Is it possible, that your patch raises the stability for some
> > amount, but doesn't solve it fully or does is happen all by chance?
>
> Looking at the line mm/truncate.c:446, I don't think the problem is
> related to the previous patch. I guess it is a bug in aufs itself.
Okay, that was a red herring.
The behavior after applying the vm_operations_struct patch in respect to
the crashes didn't change significantly.
Unfortunately, I cannot see any real pattern to reproduce the issue. It
seems to happen most often from KDE4 components, while I still use KDE3
as my main desktop. The last crash was from krdc of KDE4, which I
called once, that worked fine, closed it, and started it immediately
again -> crash.
I've analysed the crashes on the workstations of my customer: thanks
god, they happen occasionally only, but nevertheless they happened
practically on any system, and it's always the same crash candidates:
nscd, kded4, knotify4, kmozillahelper. nscd won the competition.
> > I can imagine, how awful it is for you to get to the "real" source.
>
> Thank you, I got it and will build and test tomorrow.
> May I ask you testing a patch which may solve the problem.
The patch didn't apply cleanly to aufs2-31 (standalone), but I applied
the attached patch (build service refuses to apply patches with fuzz).
Build is triggered.
Unfortunately, it bails out with:
usr/src/packages/BUILD/aufs2-standalone.tree-31-20100823/obj/default/fs/aufs/f_op.c:
In function 'aufs_mmap':
/usr/src/packages/BUILD/aufs2-standalone.tree-31-20100823/obj/default/fs/aufs/f_op.c:671:
error: implicit declaration of function 'xip_file_mmap'
I wasn't able to locate the xip_file_mmap function anywhere in the
source. Probably it's introduced in a later version?
Pete
--- a/fs/aufs/f_op.c 2011-06-21 15:04:39.000000000 +0200
+++ b/fs/aufs/f_op.c 2011-06-27 17:39:55.305751073 +0200
@@ -635,7 +635,7 @@ static int aufs_mmap(struct file *file,
mutex_set_owner(&finfo->fi_mmap);
h_dentry = args.h_file->f_dentry;
- if (!args.mmapped && au_test_fs_bad_mapping(h_dentry->d_sb)) {
+ if (!args.mmapped /* && au_test_fs_bad_mapping(h_dentry->d_sb) */) {
/*
* by this assignment, f_mapping will differs from aufs inode
* i_mapping.
@@ -665,7 +665,11 @@ static int aufs_mmap(struct file *file,
* both of the aufs file and the lower file is deny_write_access()-ed.
* finally I hope we can skip handlling MAP_DENYWRITE here.
*/
- err = generic_file_mmap(file, vma);
+ if (!file->f_mapping->a_ops->get_xip_mem)
+ err = generic_file_mmap(file, vma);
+ else
+ err = xip_file_mmap(file, vma);
+ AuTraceErr(err);
if (unlikely(err))
goto out_unlock;
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
