Using TASK_SIZE for kernel threads

[Martin Schwidefsky]

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