Searched hist:"095 da6cbb6a1c54c19b11190218eb0fbac666b6d" (Results 1 – 2 of 2) sorted by relevance
| /openbmc/linux/fs/fuse/ |
| H A D | fuse_i.h | diff 095da6cbb6a1c54c19b11190218eb0fbac666b6d Tue Jan 17 00:14:52 CST 2006 Miklos Szeredi <miklos@szeredi.hu> [PATCH] fuse: fix bitfield race
Fix race in setting bitfields of fuse_conn. Spotted by Andrew Morton.
The two fields ->connected and ->mounted were always changed with the
fuse_lock held. But other bitfields in the same structure were changed
without the lock. In theory this could lead to losing the assignment of
even the ones under lock. The chosen solution is to change these two
fields to be a full unsigned type. The other bitfields aren't "important"
enough to warrant the extra complexity of full locking or changing them to
bitops.
For all bitfields document why they are safe wrt. concurrent
assignments.
Also make the initialization of the 'num_waiting' atomic counter explicit.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
| H A D | inode.c | diff 095da6cbb6a1c54c19b11190218eb0fbac666b6d Tue Jan 17 00:14:52 CST 2006 Miklos Szeredi <miklos@szeredi.hu> [PATCH] fuse: fix bitfield race
Fix race in setting bitfields of fuse_conn. Spotted by Andrew Morton.
The two fields ->connected and ->mounted were always changed with the
fuse_lock held. But other bitfields in the same structure were changed
without the lock. In theory this could lead to losing the assignment of
even the ones under lock. The chosen solution is to change these two
fields to be a full unsigned type. The other bitfields aren't "important"
enough to warrant the extra complexity of full locking or changing them to
bitops.
For all bitfields document why they are safe wrt. concurrent
assignments.
Also make the initialization of the 'num_waiting' atomic counter explicit.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|