Bug 6399 - [LTP] Kernel panic when running tests for cgroup
Summary: [LTP] Kernel panic when running tests for cgroup
Status: RESOLVED WONTFIX
Alias: None
Product: BSPs
Classification: Build System, Metadata & Runtime
Component: bsps-meta-xilinx (show other bugs)
Version: unspecified
Hardware: Other arm
: Medium normal
Target Milestone: 1.7
Assignee: Saul Wold
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2014-06-04 12:15 UTC by Vaduva Alexandru
Modified: 2014-07-14 17:18 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know


Attachments
First output for the bug before the patch application (1.33 MB, text/plain)
2014-06-04 12:17 UTC, Vaduva Alexandru
no flags Details
The same output but this time only cgroup_xattr tests were run (39.88 KB, text/plain)
2014-06-04 12:20 UTC, Vaduva Alexandru
no flags Details
Output after patch apply (3.56 KB, text/plain)
2014-06-04 12:21 UTC, Vaduva Alexandru
no flags Details
The applied patch (2.07 KB, patch)
2014-06-04 12:23 UTC, Vaduva Alexandru
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Vaduva Alexandru 2014-06-04 12:15:26 UTC
The bug was identified in cgroup_xattr test suite.
I tried to remove 'struct simple_xattrs xattrs' from 'struct cftype' and put it inside 'struct cfent' as I believed that simple_xattrs_free() tried free the same struct simple_xattrs twice (each cgroup has a tasks file, and each tasks file has associated unique cfent structure, but all those files share the same cftype structure).
The cgroup_xattr did not reported a kernel panic no more but other test from cgroup begin to fail.

Sorry for the wall of text but I only tried to let you know where I am at this moment.
I decided to open a bug for you on, because I believed you would be interested in something like this.
The bug output file are attached to this bug:
     - ltp-bash-cgroup_xattr-test-other.txt --- first for of the bug before the patch application
     - ltp-cgroup_xattr-test-output.txt --- the same output but this time only cgroup_xattr tests were run
     - ltp-bash-cgroupr-output-after-patch.txt --- output after patch apply
     - zc702-zynq7-ltp-cgroup_xattr-kernel-panic.patch --- the patch applied
Comment 1 Vaduva Alexandru 2014-06-04 12:17:12 UTC
Created attachment 1992 [details]
First output for the bug before the patch application
Comment 2 Vaduva Alexandru 2014-06-04 12:20:50 UTC
Created attachment 1993 [details]
The same output but this time only cgroup_xattr tests were run
Comment 3 Vaduva Alexandru 2014-06-04 12:21:21 UTC
Created attachment 1994 [details]
Output after patch apply
Comment 4 Vaduva Alexandru 2014-06-04 12:23:03 UTC
Created attachment 1995 [details]
The applied patch
Comment 5 Vaduva Alexandru 2014-06-11 10:42:57 UTC
Tried linux-xlnx 3.14 kernel and the problems did not replicated there.
Comment 6 Saul Wold 2014-06-25 00:02:46 UTC
Is this Xilinx specific or a generic problem?
Comment 7 Nathan Rossi 2014-06-25 03:27:20 UTC
This bug looks like a generic kernel issue, as for the linux-xlnx repo we have no changes that modify the cgroup subsystem.

It appears that a change to the kernel for 3.10+ was made that looks similar to Vaduva's patch:

commit 712317ad97f41e738e1a19aa0a6392a78a84094e                                
Author: Li Zefan <lizefan@huawei.com>                                          
Date:   Thu Apr 18 23:09:52 2013 -0700                                         
                                                                               
    cgroup: fix broken file xattrs                                             
                                                                               
    We should store file xattrs in struct cfent instead of struct cftype,      
    because cftype is a type while cfent is object instance of cftype.         
                                                                               
    For example each cgroup has a tasks file, and each tasks file is           
    associated with a uniq cfent, but all those files share the same           
    struct cftype.                                                             
                                                                               
    Alexey Kodanev reported a crash, which can be reproduced:                  
                                                                               
      # mount -t cgroup -o xattr /sys/fs/cgroup                                
      # mkdir /sys/fs/cgroup/test                                              
      # setfattr -n trusted.value -v test_value /sys/fs/cgroup/tasks           
      # rmdir /sys/fs/cgroup/test                                              
      # umount /sys/fs/cgroup                                                  
      oops!                                                                    
                                                                               
    In this case, simple_xattrs_free() will free the same struct simple_xattrs 
    twice.                                                                     
                                                                               
    tj: Dropped unused local variable @cft from cgroup_diput().                
                                                                               
    Cc: <stable@vger.kernel.org> # 3.8.x                                       
    Reported-by: Alexey Kodanev <alexey.kodanev@oracle.com>                    
    Signed-off-by: Li Zefan <lizefan@huawei.com>                               
    Signed-off-by: Tejun Heo <tj@kernel.org>                                   

Given Vaduva has confirmed it is functional in the linux-xlnx 3.14 kernel, and we have dropped linux-xlnx 3.8 recipe in daisy/1.6, this bug can be closed?
Comment 8 Vaduva Alexandru 2014-06-25 08:20:36 UTC
I approve with Nathan opinion, this bug could be closed, being the fact that the 3.8 kernel was dropped, but maybe some investigation is needed to evaluate the costs for the bug repairing on that version of the kernel.
Comment 9 Saul Wold 2014-07-14 17:18:21 UTC
Closing since this is against the 3.8 kernel and there is a patch here.