I'm not sure if I'm missing something --- is the following a race?
2.5.62/fs/exec.c:1013:search_binary_handler:
read_unlock(&binfmt_lock);
retval = fn(bprm, regs);
if (retval >= 0) {
put_binfmt(fmt);
binfmt_lock is released and then put_binfmt is called. put_binfmt
seems to need locking:
fs/exec.c:1022:search_binary_handle
read_lock(&binfmt_lock);
put_binfmt(fmt);
if (retval != -ENOEXEC)
break;
if (!bprm->file) {
read_unlock(&binfmt_lock);
return retval;
}
2.5.62/fs/exec.c:151:sys_uselib:
error = fmt->load_shlib(file);
read_lock(&binfmt_lock);
put_binfmt(fmt);
if (error != -ENOEXEC)
break;
}
Are these other locks redundant? Or does put_binfmt need protection?
Dawson Engler <[email protected]> wrote:
>
> I'm not sure if I'm missing something --- is the following a race?
>
> 2.5.62/fs/exec.c:1013:search_binary_handler:
> read_unlock(&binfmt_lock);
> retval = fn(bprm, regs);
> if (retval >= 0) {
> put_binfmt(fmt);
Don't think so.
That lock protects the global list of registered formats only. Because we
have a ref against the format's underlying module when that lock is dropped,
the module cannot be unloaded and nobody can unregister the format. Hence
the thing at *fmt is stable, and reading fmt->next after retaking the lock is
safe.
The particular piece of code you quote would be buggy if it continued
to go around the loop and again used fmt->next. But it will unconditionally
return after performing the put_binfmt() call.