Description of problem: I am running into a lock validator warning indicating a potential recursive locking issues in tcp_v6_rcv() and sk_clone(). A brief investigation and mailing list search makes me believe this is not a real "bug" but the lock validator warning should somehow be corrected. The following post seems to indicate this is a known issue in the mainline kernel but there is no indication as to what the fix is: * http://lkml.org/lkml/2006/7/31/85 Version-Release number of selected component (if applicable): - Kernel 2.6.18-1.2727.2.1.el5.lspp.52 found on Steve Grubb's people page - SELinux MLS policy version 2.3.19-2 How reproducible: Everytime Steps to Reproduce: 1. Boot into SELinux enforcing mode 2. Configure NetLabel as follows: # netlabelctl -p cipsov4 add pass doi:1 tags:1 # netlabelctl -p map del default # netlabelctl -p map add default protocol:cipsov4,1 3. Restart sshd 4. Connect to localhost using ssh Actual results: The lock validator issues a warning very similar to the one shown in the URL above. Expected results: No lock validator warnings. Additional info:
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion.
Hi Paul, Sorry for taking so long to look at this. I've tried to reproduce the problem with 2.6.18-18 following the steps you describe but didn't succeed. It's very likely due to my very limited knowledge of NetLabel policies though. I've booted with selinux=1, configured netlabel like above and restarted sshd. I wasn't able to connect afterwards but didn't see any lockdep warnings either. Anyways, I've looked at any possible socket related lockdep patches upstream which could be backported but haven't found any, they've all been integrated already. Can you reproduce the bug with upstream kernels? Would you be willing to try with a recent RHEL-5 kernel so we can verify that the lockdep problem still exists?
Hi Thomas, No problem on the delay, I'll try to reproduce this with a recent RHEL5 kernel and get back to you. It might take a little while though as I'm currently swamped on another RHEL5 project (LSPP evaluation). The good news is that I have been doing a lot of network testing since this bug was originally posted and I haven't seen any lockdep warnings in recent kernels - the problem may have gone away. Thanks for looking into this.
Please note, that around beta2, we disabled the lockdep warnings for performance reasons. They were re-enabled post GA (starting with -9.el5) but then disabled again with -17.el5. In order to see lockdep warning messages please use the kernel-debug variant kernels staring with -17.el5. These kernels can be found under people.redhat.com/dzickus/el5
I just tried to recreate these lockdep warnings using the kernel-2.6.18-23.el5.ia64 kernel RPM found here: * http://people.redhat.com/dzickus/el5/23.el5/ia64 ... and was not able to reproduce the warnings. I guess at this point I'd consider this a "solved" issue, something must have changed between the earlier version of the kernel and this current version. Sorry about the firedrill guys.