Tetsuo Handa wrote:
> Is it legal to return positive value when do_execve() succeeds?
It seems to me that do_execve() should not return positive return code because
some callers are expecting do_execve() to return 0 on success.
linux-2.6.36-rc6/arch/x86/kernel/process.c:
304 long sys_execve(const char __user *name,
305 const char __user *const __user *argv,
306 const char __user *const __user *envp, struct pt_regs *regs)
307 {
308 long error;
309 char *filename;
310
311 filename = getname(name);
312 error = PTR_ERR(filename);
313 if (IS_ERR(filename))
314 return error;
315 error = do_execve(filename, argv, envp, regs);
316
317 #ifdef CONFIG_X86_32
318 if (error == 0) {
319 /* Make sure we don't return using sysenter.. */
320 set_thread_flag(TIF_IRET);
321 }
322 #endif
323
324 putname(filename);
325 return error;
326 }
But there are several "struct linux_binfmt"->load_binary() users who return
positive return code for error paths.
load_elf_binary() will return positive return code if set_brk() returned
positive return code.
load_aout_binary() will return positive return code if do_brk() or
do_mmap() returned unwanted result.
Are we using positive return code for telling unrecoverable errors?
send_sig(SIGKILL, current, 0) is used when execve() failed after reaching
"the point of no return", isn't it? But set_thread_flag(TIF_IRET) will not be
called if execve() failed after "the point of no return".
Is this no problem as the current task will be SIGKILL'ed as soon as returning
using sysenter()?
Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
