Bug 696396

Clarification.

  It is actually fscache that taints the kernel.

  HOWEVER, NFS is *loading* fscache.
[root@uvmid5-sys ~]# modinfo -F depends nfs
sunrpc,fscache,lockd,auth_rpcgss,nfs_acl

  Therefore on UV loading NFS always TAINTs the
  kernel.

I've added Regression.

George

I think that this might well qualify as a blocker - the fix should be trivial (easy fix, remove the fscache taint code, just about as easy to move it to where fscache attaches a real cache before becoming active).

The downside is that *every* NFS client & CIFS box would be marked as tainted which would be a concern with the field.

Created attachment 492478 [details]
Move FS-Cache taint point to cache-add

This patch moves the point at which fscache taints the kernel to the point at which the cache backend (e.g. cachefiles) attempts to add a cache.

Created attachment 492479 [details]
Prevent lock disablement on tech-review taint

Additional patch to prevent the tech-review taint from causing lock debugging from being disabled.  This can be seen by the third line in the following message logged by the kernel without this patch applied:

        TECH PREVIEW: fscache may not be fully supported.
        Please review provided documentation for limitations.
        Disabling lock debugging due to kernel taint

Created attachment 493455 [details]
Prevent lock disablement on tech-review and unsupported h/w taints

As previous version of patch, but also prevents lock disablement if the unsupported hardware taint is flagged.

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

George, do you have the cachefilesd package installed/service enabled? Without it the fscache module won't get loaded and you'll avoid the tech preview taint.

The cachefilesd package was not installed.  Are you saying it should or should
not be installed?

I installed the cachefilesd package and after reboot the kernel still was
marked tainted due to the TECH PREVIEW.  Looks like with or without cachefilesd
the kernel hits the tech preview taint.

Russ,

To record an exchange with David.

  1) cachefilesd should not be installed
  2) nfs should work
  3) kernel should not be tainted.

I will test this on a UV system.

George

I'm seeing this also on RHEL 6.1 systems without the cachefilesd package installed, that are just plain NFS clients installed with @core.

Is it the case that fscache is inactive without the cachefilesd userspace component installed and that the kernel taint is the only effect?

Patch(es) available on kernel-2.6.32-188.el6

*** Bug 707712 has been marked as a duplicate of this bug. ***

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Prior to this update, loading the FS-Cache kernel module would cause the kernel to be tainted as a Technology Preview via the mark_tech_preview() function, which would cause kernel lock debugging to be disabled by the add_taint() function. However, the NFS and CIFS modules depend on the FS-Cache module so using either NFS or CIFS would cause the FS-Cache module to be loaded and the kernel tainted. With this update, FS-Cache only taints the kernel when a cache is brought online (for instance by starting the cachefilesd service) and, additionally, the add_taint() function has been modified so that it does not disable lock debugging for informational-only taints.

Reproducer:
[root@intel-hermosabeach-01 ~]# stap test.stap -c "modprobe nfs"
add_taint debug_locks=0 flag=0x1d
[root@intel-hermosabeach-01 ~]# uname -a
Linux intel-hermosabeach-01.rhts.eng.rdu.redhat.com 2.6.32-184.el6.x86_64 #1 SMP Tue Aug 9 12:20:06 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
[root@intel-hermosabeach-01 ~]# dmesg 
** snip **
TECH PREVIEW: fscache may not be fully supported.
Please review provided documentation for limitations.
FS-Cache: Loaded
FS-Cache: Netfs 'nfs' registered for caching
[root@intel-hermosabeach-01 ~]# 
[root@intel-hermosabeach-01 ~]# cat test.stap 
probe kernel.function("add_taint") {printf("%s debug_locks=%d %s\n", probefunc(), $debug_locks, $$vars); }

Verifier: Message about "TECH PREVIEW" is printed when cachefilesd start, and lock debug is not closed.
[root@intel-hermosabeach-01 ~]# uname -a ; dmesg -c
Linux intel-hermosabeach-01.rhts.eng.rdu.redhat.com 2.6.32-214.el6.x86_64 #1 SMP Tue Oct 25 19:48:00 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
[root@intel-hermosabeach-01 ~]# stap test.stap -c "mount localhost:/tmp /mnt/test"
[root@intel-hermosabeach-01 ~]# dmesg
stap_04f9029aaf69fa620bf55dee00a8abee_3211: systemtap: 1.6/0.152, base: ffffffffa038d000, memory: 2139data/18text/25ctx/10net/67alloc kb, probes: 1
Slow work thread pool: Starting up
Slow work thread pool: Ready
FS-Cache: Loaded
FS-Cache: Netfs 'nfs' registered for caching
SELinux: initialized (dev 0:14, type nfs4), uses genfs_contexts
SELinux: initialized (dev 0:15, type nfs4), uses genfs_contexts
[root@intel-hermosabeach-01 ~]# stap test.stap -c "service cachefilesd start"
Starting cachefilesd: [  OK  ]
add_taint debug_locks=1 flag=0x1d
[root@intel-hermosabeach-01 ~]# dmesg
stap_04f9029aaf69fa620bf55dee00a8abee_3229: systemtap: 1.6/0.152, base: ffffffffa0647000, memory: 2139data/18text/25ctx/10net/67alloc kb, probes: 1
CacheFiles: Loaded
TECH PREVIEW: fscache may not be fully supported.
Please review provided documentation for limitations.
FS-Cache: Cache "mycache" added (type cachefiles)
CacheFiles: File cache on dm-0 registered

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2011-1530.html