On Mon, 2008-01-28 at 12:33 -0600, Steve French wrote:
> On Jan 28, 2008 2:17 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > I completely agree. If one thread writes A and another writes B then the
> > > kernel should record either A or B, not ((A & 0x) | (B &
> > > 0x))
On Jan 28, 2008 2:17 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > I completely agree. If one thread writes A and another writes B then the
> > kernel should record either A or B, not ((A & 0x) | (B &
> > 0x))
>
> The problem is pretty nasty unfortunately. To solve it
El Mon, 28 Jan 2008 15:10:34 +0100, Andi Kleen <[EMAIL PROTECTED]> escribió:
> So you get overlapping reads. Probably not good.
This was discussed in the past i think ->
http://lkml.org/lkml/2006/4/13/124
http://lkml.org/lkml/2006/4/13/130
--
To unsubscribe from this list: send the line
On Mon, 28 Jan 2008 15:10:34 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Monday 28 January 2008 14:38:57 Alan Cox wrote:
> > > Also worse really fixing it would be a major change to the VFS
> > > because of the way ->read/write are defined :/
> >
> > I don't see a problem there. ->read and
On Monday 28 January 2008 14:38:57 Alan Cox wrote:
> > Also worse really fixing it would be a major change to the VFS
> > because of the way ->read/write are defined :/
>
> I don't see a problem there. ->read and ->write update the passed pointer
> which is not the real f_pos anyway. Just the
> Also worse really fixing it would be a major change to the VFS
> because of the way ->read/write are defined :/
I don't see a problem there. ->read and ->write update the passed pointer
which is not the real f_pos anyway. Just the copies need fixing.
Alan
--
To unsubscribe from this list:
On Monday 28 January 2008 13:56:05 Alan Cox wrote:
> > > No specific spec, just general quality of implementation.
> >
> > I completely agree. If one thread writes A and another writes B then the
> > kernel should record either A or B, not ((A & 0x) | (B &
> > 0x))
>
>
> > No specific spec, just general quality of implementation.
>
> I completely agree. If one thread writes A and another writes B then the
> kernel should record either A or B, not ((A & 0x) | (B &
> 0x))
Agree entirely: the spec doesn't allow for random scribbling in
Trond Myklebust <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-01-28 at 05:38 +0100, Andi Kleen wrote:
>> On Monday 28 January 2008 05:13:09 Trond Myklebust wrote:
>> > 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,
>>
> I completely agree. If one thread writes A and another writes B then the
> kernel should record either A or B, not ((A & 0x) | (B &
> 0x))
The problem is pretty nasty unfortunately. To solve it properly I think
the file_operations->read/write prototypes would need to
On Mon, 2008-01-28 at 12:33 -0600, Steve French wrote:
On Jan 28, 2008 2:17 AM, Andi Kleen [EMAIL PROTECTED] wrote:
I completely agree. If one thread writes A and another writes B then the
kernel should record either A or B, not ((A 0x) | (B
0x))
The
Trond Myklebust [EMAIL PROTECTED] wrote:
On Mon, 2008-01-28 at 05:38 +0100, Andi Kleen wrote:
On Monday 28 January 2008 05:13:09 Trond Myklebust wrote:
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
No specific spec, just general quality of implementation.
I completely agree. If one thread writes A and another writes B then the
kernel should record either A or B, not ((A 0x) | (B
0x))
Agree entirely: the spec doesn't allow for random scribbling in the wrong
Also worse really fixing it would be a major change to the VFS
because of the way -read/write are defined :/
I don't see a problem there. -read and -write update the passed pointer
which is not the real f_pos anyway. Just the copies need fixing.
Alan
--
To unsubscribe from this list: send the
El Mon, 28 Jan 2008 15:10:34 +0100, Andi Kleen [EMAIL PROTECTED] escribió:
So you get overlapping reads. Probably not good.
This was discussed in the past i think -
http://lkml.org/lkml/2006/4/13/124
http://lkml.org/lkml/2006/4/13/130
--
To unsubscribe from this list: send the line unsubscribe
On Monday 28 January 2008 14:38:57 Alan Cox wrote:
Also worse really fixing it would be a major change to the VFS
because of the way -read/write are defined :/
I don't see a problem there. -read and -write update the passed pointer
which is not the real f_pos anyway. Just the copies need
On Mon, 28 Jan 2008 15:10:34 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
On Monday 28 January 2008 14:38:57 Alan Cox wrote:
Also worse really fixing it would be a major change to the VFS
because of the way -read/write are defined :/
I don't see a problem there. -read and -write update
On Monday 28 January 2008 13:56:05 Alan Cox wrote:
No specific spec, just general quality of implementation.
I completely agree. If one thread writes A and another writes B then the
kernel should record either A or B, not ((A 0x) | (B
0x))
Agree entirely:
On Jan 28, 2008 2:17 AM, Andi Kleen [EMAIL PROTECTED] wrote:
I completely agree. If one thread writes A and another writes B then the
kernel should record either A or B, not ((A 0x) | (B
0x))
The problem is pretty nasty unfortunately. To solve it properly I think
On Mon, 28 Jan 2008 05:38:25 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Monday 28 January 2008 05:13:09 Trond Myklebust wrote:
> >
> > 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
> > >
On Mon, 2008-01-28 at 05:38 +0100, Andi Kleen wrote:
> On Monday 28 January 2008 05:13:09 Trond Myklebust wrote:
> >
> > 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
On Monday 28 January 2008 05:13:09 Trond Myklebust wrote:
>
> 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
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
On Monday 28 January 2008 00:08:56 Trond Myklebust wrote:
>
> 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
On Sunday 27 January 2008 23:18:26 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?
Yes you can on 32bit. Especially during the 4GB wrap
-Andi
--
To unsubscribe from this list: send the line "unsubscribe
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 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
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 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
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
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
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 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
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 Sunday 27 January 2008 23:18:26 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?
Yes you can on 32bit. Especially during the 4GB wrap
-Andi
--
To unsubscribe from this list: send the line unsubscribe
On Monday 28 January 2008 00:08:56 Trond Myklebust wrote:
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
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
On Monday 28 January 2008 05:13:09 Trond Myklebust wrote:
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.
On Mon, 2008-01-28 at 05:38 +0100, Andi Kleen wrote:
On Monday 28 January 2008 05:13:09 Trond Myklebust wrote:
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
On Mon, 28 Jan 2008 05:38:25 +0100 Andi Kleen [EMAIL PROTECTED] wrote:
On Monday 28 January 2008 05:13:09 Trond Myklebust wrote:
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
- Replace remote_llseek with remote_llseek_unlocked (to force compilation
failures in all users)
- Change all users to either use remote_llseek directly or take the
BKL around. I changed the file systems who don't use the BKL
for anything (CIFS, GFS) to call it directly. NCPFS and SMBFS and NFS
- Replace remote_llseek with remote_llseek_unlocked (to force compilation
failures in all users)
- Change all users to either use remote_llseek directly or take the
BKL around. I changed the file systems who don't use the BKL
for anything (CIFS, GFS) to call it directly. NCPFS and SMBFS and NFS
43 matches
Mail list logo
