Messages in this thread | | | Subject | Re: Patch?: linux-2.5.59/sound/soundcore.c referenced non-existant errno variable | From | Raja R Harinath <> | Date | Sat, 18 Jan 2003 09:40:36 -0600 |
| |
Hi,
Petr Vandrovec <vandrove@vc.cvut.cz> writes:
> On Fri, Jan 17, 2003 at 08:49:36PM -0600, Raja R Harinath wrote: >> Hi, >> >> "Adam J. Richter" <adam@yggdrasil.com> writes: >> >> > linux-2.5.59/sound/sound_firmware.c attempts to use the >> > user level system call interface from the kernel, which I understand >> > works on i386 and perhaps all architectures, but requires a variable >> > named "errno." >> >> Which is provided in-kernel (not for modules) by 'lib/errno.c'. > > Not safe. We should either remove errno from kernel syscall wrappers > completely when building __KERNEL__ (just return -1 and nothing more > specific), or even disallow use of unistd.h wrappers from kernel > completely (which is best solution IMHO).
__KERNEL_SYSCALLS__ appears to be defined in several files. Don't know if they actually use any of them.
> BTW, static int errno is by far best solution if you do not agree with > patch below: due to toolchain behavior soundcore will use its own > errno for syscall wrappers it uses, and it is nearest to the behavior > we wanted... [snip] > static int do_mod_firmware_load(const char *fn, char **fp) > { > - int fd; > + struct file* filp; > long l; > char *dp; > + loff_t pos; > > - fd = open(fn, 0, 0); > - if (fd == -1) > + filp = filp_open(fn, 0, 0); > + if (IS_ERR(filp)) > { > printk(KERN_INFO "Unable to load '%s'.\n", fn); > return 0; > } [snip]
I noticed that do_mod_firmware_load is wrapped by a set_fs(get_gs())/set_fs(fs) pair in mod_firmware_load, presumably because it performs an 'int 0x80' kernel syscall in there. The cleanup to use the VFS directly should probably kill the wrapper too.
- Hari -- Raja R Harinath ------------------------------ harinath@cs.umn.edu - 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/
| |