Re: [Xen-devel] Regression introduced by bfcfaa77bdf0f775263e906015982a608df01c76 (vfs: use 'unsigned long' accesses for dcache name comparison and hashing)

[Eric Paris <eparis@xxxxxxxxxxxxxx>]

Reverting this patch also fixed the spurious ENOENT problems (and
related boot failures) from SELinux.

Easy reproducer with SELinux enabled (although might I suggest
permissive/enforcing=0 since the box can't boot otherwise):

compute_create system_u:system_r:kernel_t:s0
system_u:object_r:init_exec_t:s0 process

If you get back system_u:object_r:init_exec_t:s0 it failed and you'll
see under strace the ENOENT stat() failure.

If you get back system_u:object_r:init_t:s0 it means it worked...

-Eric


On Thu, Mar 22, 2012 at 3:33 PM, Eric Paris <eparis@xxxxxxxxxxxxxx> wrote:
> No idea if it is related and haven't bisected, but we are seeing
> similar ENOENT issues with things in selinuxfs.  And not a single bit
> of SELinux code has changed since v3.3.  So it's certainly a VFS
> problem.  This sounds likely.
>
> -Eric
>
> On Thu, Mar 22, 2012 at 2:38 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx> wrote:
>> Hey Linus,
>>
>> I am not sure how to debug this but with v3.3 with just that git commit I 
>> can't
>> start an user space application called 'xenstored'. A bit of strace showed 
>> me:
>> [edit, also with todays linus/master I get the same issue, and if I revert
>> your patch it works again]
>>
>> (right is 3.3, left is with your patch)
>> write(3, "Checking store complete.\n", 25) = 25                 write(3, 
>> "Checking store complete.\n", 25) = 25
>> sendto(9, "<11>Mar 22 18:00:27 xenstored: C"..., 55, MSG_NOSI | sendto(9, 
>> "<11>Mar 22 18:06:44 xenstored: C"..., 55, MSG_NOSI
>> open("/proc/xen/privcmd", O_RDWR)       = 10                   
>>  open("/proc/xen/privcmd", O_RDWR)       = 10
>> fcntl(10, F_GETFD)                      = 0                     fcntl(10, 
>> F_GETFD)                      = 0
>> fcntl(10, F_SETFD, FD_CLOEXEC)          = 0                     fcntl(10, 
>> F_SETFD, FD_CLOEXEC)          = 0
>> open("/dev/xen/evtchn", O_RDWR)         = 11                   
>>  open("/dev/xen/evtchn", O_RDWR)         = 11
>> open("/proc/xen/xsd_port", O_RDONLY)    = -1 ENOENT (No such  | 
>> open("/proc/xen/xsd_port", O_RDONLY)    = 12
>> write(2, "FATAL: ", 7FATAL: )                  = 7            | read(12, 
>> "25", 20)                      = 2
>> write(2, "Failed to initialize dom0 state:"..., 59Failed to i | close(12)   
>>                             = 0
>> ) = 59                                                        | ioctl(11, 
>> EVIOCGVERSION, 0x7fff4e3ffc70) = 41
>> close(10)                               = 0                   | write(3, 
>> "CREATE connection 0xe2e7b0\n", 27) = 27
>> close(5)                                = 0                   | 
>> open("/proc/xen/xsd_kva", O_RDWR)       = 12
>> close(4)                                = 0                   | mmap(NULL, 
>> 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 12, 0) = 0
>> exit_group(1)                           = ?                   | close(12)   
>>                             = 0
>>                                                              > ioctl(11, 
>> EVIOCGKEYCODE or EVIOCSKEYCODE, 0x7fff4e3ffc90) = 0
>>                                                              > ioctl(11, 
>> 0x44500, 0x7fff4e3ffc90)      = 42
>>                                                              > 
>> rt_sigaction(SIGHUP, {0x402180, [HUP], SA_RESTORER|SA_RESTART
>>                                                              > select(12, [4 
>> 5 6 11], [], NULL, NULL)  = 1 (in [11])
>>                                                              > read(11, 
>> ")\0\0\0", 4)                  = 4
>>                                                              > write(11, 
>> ")\0\0\0", 4)                 = 4
>>                                                              > select(12, [4 
>> 5 6 11], [], NULL, NULL <unfinished ...>
>>
>> and if I ls /proc/xen (v3.3):
>>
>>> ls -al /proc/xen
>> total 0
>> drwxr-xr-x   2 root root 0 Mar 22 18:05 .
>> dr-xr-xr-x 126 root root 0 Mar 22 18:05 ..
>> -r--r--r--   1 root root 0 Mar 22 18:05 capabilities
>> -rw-------   1 root root 0 Mar 22 18:05 privcmd
>> -rw-------   1 root root 0 Mar 22 18:05 xenbus
>> -rw-------   1 root root 0 Mar 22 18:05 xsd_port
>>
>> while v3.3 with your patch:
>>
>>
>> 8:01:09 # 10 :/proc/xen/
>>> ls -al
>> ls: cannot access xsd_port: No such file or directory
>> total 0
>> drwxr-xr-x   2 root root 0 Mar 22 17:57 .
>> dr-xr-xr-x 126 root root 0 Mar 22 17:57 ..
>> -r--r--r--   1 root root 0 Mar 22 17:57 capabilities
>> -rw-------   1 root root 0 Mar 22 17:57 privcmd
>> -rw-------   1 root root 0 Mar 22 17:57 xenbus
>> -rw-------   1 root root 0 Mar 22 17:57 xsd_kva
>> -?????????   ? ?    ?    ?            ? xsd_port
>>
>>
>> Looking at the code that sets up 'xsd_port' it looks pretty innocent
>> and similar to other drivers (ibmasm for example).
>>
>> Also attached is the .config
>>
>> Note: to actually bootup the latest with Xen there are some fixes required
>> to fix the regressions introduced:
>> http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=106b44388d8f76373149c4ea144f717b6d4d9a6d
>> http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=a759ceb7d1dfe38f4dda147e233aa53c8f477e2a
>> http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=1b34ba936c1adff3020eec1e1834ffa4cf89802f
>> http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=6ac72c4bc49a9afb02b8176b48be019dff0560cd

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel