Hello, this week we had some fun with kernel 4.10 on s390. Carsten found that the kernel kept crashing reproducibly on his system. Not on mine or any other system, just his.
The kdevtmpfs kernel thread crashed in __queued_work as it tried to terminate. The devtmpfsd function got an error on the sys_mount() call. Why it crashes on termination is a different story, the interesing part is why sys_mount() got an error. After some more debugging Carsten found out that copy_mount_options() only got 2 bytes of the option string, "mo" instead of "mode=0755". It turned out that the s390 definition of TASK_SIZE together with the size calculation in copy_mount_options causes this: #define TASK_SIZE_OF(tsk) ((tsk)->mm->context.asce_limit) and size = TASK_SIZE - (unsigned long)data; For a kernel thread (tsk)->mm is zero and the value located at (0)->context.asce_limit happened to be close enough to the data pointer that the 'size' result is a small number, in this case 2. Now I fixed this in the s390 code, the patch is queued and will be included in next weeks please-pull. But I am wondering about the use of TASK_SIZE in kernel threads. For x86 copy_mount_options works because the size calculation will give a negative result for 'data' pointing to kernel space. Which is corrected by the size limit: if (size > PAGE_SIZE) size = PAGE_SIZE; Wouldn't it be cleaner to test "get_fs()==KERNEL_DS" and just use size=4096 in this case? The detour via TASK_SIZE does not make much sense to me. To find out how big the problem is, I have added a warning to TASK_SIZE to create a console messsage if it is called for a task without an mm. The only hit has been copy_mount_options. For reference I have included the s390 patch. Martin Schwidefsky (1): s390: TASK_SIZE for kernel threads arch/s390/include/asm/processor.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.7.4