+++ linux/fs/fcntl.c
@@ -240,11 +240,15 @@ static int setfl(int fd, struct file * f
lock_kernel();
if ((arg ^ filp-f_flags) FASYNC) {
- if (filp-f_op filp-f_op-fasync) {
+ if (filp-f_op filp-f_op-unlocked_fasync)
+
Adrian Bunk пишет:
On Sat, Jan 26, 2008 at 06:35:41PM +, Tigran Aivazian wrote:
On Sat, 26 Jan 2008, Dmitri Vorobiev wrote:
- inode-i_mtime = inode-i_atime = inode-i_ctime = CURRENT_TIME_SEC;
+ inode-i_mtime = CURRENT_TIME_SEC;
+ inode-i_atime = CURRENT_TIME_SEC;
+ inode-i_ctime
No goto if you use unlocked_fasync?
Indeed. There was another problem in the patch too. Here's an updated
patch that also fixes another latent bug.
The whole f_flags still seems to be somewhat fragile because
the checks tend to happen without any lock, but that has not
changed to the previous
Don't you need to a spinlock/spinunlock(i_lock) or something similar
(there isn't a spinlock in the file struct unfortunately) around the
reads and writes from f_pos in fs/read_write.c in remote_llseek with
your patch since the reads/writes from that field are not necessarily
atomic and threads
On Sun, 2008-01-27 at 10:57 -0600, Steve French wrote:
Don't you need to a spinlock/spinunlock(i_lock) or something similar
(there isn't a spinlock in the file struct unfortunately) around the
reads and writes from f_pos in fs/read_write.c in remote_llseek with
your patch since the
Lachlan McIlroy ([EMAIL PROTECTED]) wrote on 25 January 2008 13:00:
Carlos Carvalho wrote:
I compiled the kernel with Ingo's CONFIG_PROVE_LOCKING and got the
below at boot. Is it a problem?
It was a problem - it has since been fixed in 2.6.23.
Patch is attached in case you're interested.
If two seeks overlap, can't you end up with an f_pos value that is
different than what either thread seeked to? or if you have a seek and
a read overlap can't you end up with the read occurring in the midst
of an update of f_pos (which takes more than one instruction on
various architectures),
On Sun, 2008-01-27 at 03:17 +0100, Andi Kleen wrote:
Convert jfs_ioctl over to not use the BKL. The only potential race
I could see was with two ioctls in parallel changing the flags
and losing the updates. Use the i_mutex to protect against this.
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi
On Sun, 2008-01-27 at 03:17 +0100, Andi Kleen wrote:
The ioctls were already compatible except for the actual values so this
was fairly easy to do.
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Added to the jfs git tree.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux
On Sun, 2008-01-27 at 16:18 -0600, Steve French wrote:
If two seeks overlap, can't you end up with an f_pos value that is
different than what either thread seeked to? or if you have a seek and
a read overlap can't you end up with the read occurring in the midst
of an update of f_pos (which
This patch enables the uncompressed files support in cramfs.
The word 'uncompressed file' is from linear cramfs (aka Application XIP).
In linear cramfs, it is used to suport XIP on NOR. However it is also
helpful on OneNAND. It makes a filesystem faster by removing compression
On Sunday 27 January 2008 13:17, Andi Kleen wrote:
[Andrew: I believe this is -mm material for .25]
- Convert some more file systems (generally those who don't use the BKL
for anything except mount) to use unlocked_bkl.
- Implement BKL less fasync (see patch for the rationale)
This is
On Sunday 27 January 2008 17:57:14 Steve French wrote:
Don't you need to a spinlock/spinunlock(i_lock) or something similar
(there isn't a spinlock in the file struct unfortunately) around the
reads and writes from f_pos in fs/read_write.c in remote_llseek with
your patch since the
On Mon, 2008-01-28 at 03:58 +0100, Andi Kleen wrote:
The problem is that it's not a race in who gets to do its thing first, but a
parallel reader can actually see a corrupted value from the two independent
words on 32bit (e.g. during a 4GB). And this could actually completely
corrupt
14 matches
Mail list logo
