On 13 Jan 03 at 15:57, Thomas Schlichter wrote:
> On Mon, 13. Jan. 2003 16:13, Alan Cox wrote:
> > This actually shows a bug that has always been lurking. What if we load two
> > modules firmware at the same time. errno needs to be task private or we
> > perhaps need an errno_sem ?
>
> OK, I think I see the problem now!
> But is soundcore the only place where 'errno' is used? Does this problem not
> occur if any task modifies the errno value and an other one depends on its
> previous value? I think this could happen even if no modules are used...
There is no problem currently, because of nobody uses errno value at
all (in the firmware loader), it is just that inline functions generated
by syscallX() store error codes into errno...
Real problem is that firmware loader should use
filp_open/vfs_read/filp_close (or sys_open/sys_llseek/sys_read/sys_close if
you want to use fd interface, but filp_{open,close} and vfs_read are already
exported for modules while sys_open/sys_llseek/sys_read are not).
As an alternative, do_mod_firmware_load should be standalone userspace
program executed through call_usermodehelper or something like that...
Unfortunately we do not have an interface to distribute userspace binaries
together with kernel (except initrd) yet, so it would require either
adding do_mod_firmware_load into module-init-tools, or some simillar
package required by 2.[56].x kernels.
Also adding "#define errno (current()->exit_code)" at the beginning of
sound_firmware.c (just below #define __KERNEL_SYSCALLS__) should do
the trick, but I do not recommend taking this path.
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 15 2003 - 22:00:46 EST