So, let's fix this hang on Proliant/1600 first and then "go wild" changing
everything left, right and center :)
Regards,
------
Tigran A. Aivazian | http://www.sco.com
Escalations Research Group | tel: +44-(0)1923-813796
Santa Cruz Operation Ltd | http://www.ocston.org/~tigran
On Mon, 13 Dec 1999, Manfred wrote:
> From: Tigran Aivazian <tigran@sco.COM>
> > Both fget() and fput() seem to be reentrant so even if we assume that
> > down(&inode->i_sem) is not enough for fop->fsync(), we could
> > move lock/unlock_kernel() closer to it like this, right (fs/buffer.c)?
> > /* We need to protect against concurrent writers.. */
> > + lock_kernel();
> > down(&inode->i_sem);
> > err = file->f_op->fsync(file, dentry);
> > up(&inode->i_sem);
> > + unlock_kernel();
> >
> I'd first get the per-file semaphore, then the big kernel lock: you cannot
> dead-lock, and the big kernel lock is more important.
>
> But if you start to fix the lock_kernel calls, could you also fix
> sys_lseek() [same fix as above], sys_pread(), sys_pwrite() [can run without
> the kernel lock], sys_readv()/sys_writev() [everything except
> sock_readv_writev() can run without the kernel lock], old_mmap [in
> arch/i386/kernel/sys_i386.c, just reorder fget() and lock_kernel()]
> ;)
>
> Manfred
>
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/