Peter Zijlstra wrote:
On Sat, 2007-10-27 at 23:30 +0200, Peter Zijlstra wrote:
So in short, stick a struct backing_dev_info into whatever represents a
client, initialize it using bdi_init(), destroy using bdi_destroy().
Oh, and the most important point, make your fresh I_NEW inodes point to
Nice, I always hated these double-indented switch statements.
+ case FIBMAP:
+ {
+ struct address_space *mapping = filp-f_mapping;
+ int res;
+ /* do we support this mess? */
+ if (!mapping-a_ops-bmap)
+ return
On Sat, Oct 27, 2007 at 07:10:44PM -0400, Erez Zadok wrote:
Rename old vfs_ioctl to do_ioctl, because the comment above it clearly
indicates that it is an internal function not to be exported to modules;
therefore it should have a more traditional do_XXX name. The new do_ioctl
is exported in
From: J. Bruce Fields [EMAIL PROTECTED]
I think the real solution is to remove deadlock detection completely;
it's hard to imaagine applications really depend on it anyway.
For now, though, just bail out after a few iterations.
Thanks to George Davis for reporting the problem.
Cc: George G.
From: J. Bruce Fields [EMAIL PROTECTED]
We currently attempt to return -EDEALK to blocking fcntl() file locking
requests that would create a cycle in the graph of tasks waiting on
locks.
This is inefficient: in the general case it requires us determining
whether we're adding a cycle to an
In message [EMAIL PROTECTED], Christoph Hellwig writes:
Nice, I always hated these double-indented switch statements.
+ case FIBMAP:
+ {
+ struct address_space *mapping = filp-f_mapping;
+ int res;
+ /* do we support this mess? */
+ if
On Sun, Oct 28, 2007 at 01:43:21PM -0400, J. Bruce Fields wrote:
We currently attempt to return -EDEALK to blocking fcntl() file locking
requests that would create a cycle in the graph of tasks waiting on
locks.
This is inefficient: in the general case it requires us determining
whether
On Sun, 28 Oct 2007 12:27:32 -0600
Matthew Wilcox [EMAIL PROTECTED] wrote:
On Sun, Oct 28, 2007 at 01:43:21PM -0400, J. Bruce Fields wrote:
We currently attempt to return -EDEALK to blocking fcntl() file locking
requests that would create a cycle in the graph of tasks waiting on
locks.
On Sun, Oct 28, 2007 at 06:40:52PM +, Alan Cox wrote:
NAK. This is an ABI change. It was also comprehensively rejected before
because
- EDEADLK behaviour is ABI
Not in any meaningful way.
- EDEADLK behaviour is required by SuSv3
What SuSv3 actually says is:
If the system
Huge,
I took your advise regarding ~(__GFP_FS|__GFP_IO), AOP_WRITEPAGE_ACTIVATE,
and such. I revised my unionfs_writepage and unionfs_sync_page, and tested
it under memory pressure: I have a couple of live CDs that use tmpfs and can
deterministically reproduce the conditions resulting in A_W_A.
- EDEADLK behaviour is ABI
Not in any meaningful way.
I've seen SYS5 software that relies on it so we should be careful. Again
see the 2004 discussion where the conclusion was that EDEADLK should stay
- EDEADLK behaviour is required by SuSv3
What SuSv3 actually says is:
If
On Sun, 28 Oct 2007, Matthew Wilcox wrote:
You can't fix the false EDEADLK detection without solving the halting
problem. Best of luck with that.
Could you please elaborate a little bit more on this? I don't see how
detecting loops in graph relates to solving halting problem.
Of course the
On Sun, Oct 28, 2007 at 05:50:30PM -0400, Trond Myklebust wrote:
You can't fix the false EDEADLK detection without solving the halting
problem. Best of luck with that.
I can see that it would be difficult to do efficiently, but basically,
this boils down to finding a circular path in a
Bzzt. You get a false deadlock with multiple threads like so:
Thread A of task B takes lock 1
Thread C of task D takes lock 2
Thread C of task D blocks on lock 1
Thread E of task B blocks on lock 2
The spec and SYSV certainly ignore threading in this situation and you
know that perfectly
On Sun, Oct 28, 2007 at 10:48:33PM +, Alan Cox wrote:
Bzzt. You get a false deadlock with multiple threads like so:
Thread A of task B takes lock 1
Thread C of task D takes lock 2
Thread C of task D blocks on lock 1
Thread E of task B blocks on lock 2
The spec and SYSV
On Sun, 28 Oct 2007, Matthew Wilcox wrote:
Bzzt. You get a false deadlock with multiple threads like so:
Thread A of task B takes lock 1
Thread C of task D takes lock 2
Thread C of task D blocks on lock 1
Thread E of task B blocks on lock 2
A potential for deadlock occurs if a
On Sun, Oct 28, 2007 at 11:55:52PM +0100, Jiri Kosina wrote:
On Sun, 28 Oct 2007, Matthew Wilcox wrote:
Bzzt. You get a false deadlock with multiple threads like so:
Thread A of task B takes lock 1
Thread C of task D takes lock 2
Thread C of task D blocks on lock 1
Thread E of task B
The spec and SYSV certainly ignore threading in this situation and you
know that perfectly well (or did in 2004)
The discussion petered out (or that mailing list archive lost articles
from the thread) without any kind of resolution, or indeed interest.
I think the resolution was that the
On Sun, Oct 28, 2007 at 09:38:55PM +, Alan Cox wrote:
It doesn't require the system to detect it, only mandate what to return
if it does detect it.
We should be detecting at least the obvious case.
What is the obvious case? A task that has never called clone()?
If SYSV only spots
On Sun, 28 Oct 2007 17:38:14 -0600
Matthew Wilcox [EMAIL PROTECTED] wrote:
On Sun, Oct 28, 2007 at 09:38:55PM +, Alan Cox wrote:
It doesn't require the system to detect it, only mandate what to return
if it does detect it.
We should be detecting at least the obvious case.
What
This series of 4 proposed patches changes fs/ioctl.c and Unionfs as
follows. This series is against v2.6.24-rc1-192-gef49c32.
Patch 1: just applies coding standards to fs/ioctl.c (while I'm at it, I
figured it's worth cleaning VFS files one at a time).
Patch 2: does two things:
(a) Renames
Signed-off-by: Erez Zadok [EMAIL PROTECTED]
---
fs/unionfs/commonfops.c | 32 ++--
1 files changed, 6 insertions(+), 26 deletions(-)
diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 50e5775..c99b519 100644
--- a/fs/unionfs/commonfops.c
+++
Signed-off-by: Erez Zadok [EMAIL PROTECTED]
---
fs/ioctl.c | 164 +++-
1 files changed, 84 insertions(+), 80 deletions(-)
diff --git a/fs/ioctl.c b/fs/ioctl.c
index c2a773e..652cacf 100644
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -12,8 +12,8
Rename old vfs_ioctl to do_ioctl, because the comment above it clearly
indicates that it is an internal function not to be exported to modules;
therefore it should have a more traditional do_XXX name. The new do_ioctl
is exported in fs.h but not to modules.
Rename the old do_ioctl to vfs_ioctl
On Sun, Oct 28, 2007 at 06:40:52PM +, Alan Cox wrote:
On Sun, 28 Oct 2007 12:27:32 -0600
Matthew Wilcox [EMAIL PROTECTED] wrote:
On Sun, Oct 28, 2007 at 01:43:21PM -0400, J. Bruce Fields wrote:
We currently attempt to return -EDEALK to blocking fcntl() file locking
requests that
On Sun, Oct 28, 2007 at 04:41:57PM -0600, Matthew Wilcox wrote:
On Sun, Oct 28, 2007 at 05:50:30PM -0400, Trond Myklebust wrote:
You can't fix the false EDEADLK detection without solving the halting
problem. Best of luck with that.
I can see that it would be difficult to do
On Sun, Oct 28, 2007 at 11:38:26PM +, Alan Cox wrote:
The spec and SYSV certainly ignore threading in this situation and you
know that perfectly well (or did in 2004)
The discussion petered out (or that mailing list archive lost articles
from the thread) without any kind of
On Sun, 28 Oct 2007 20:40:56 -0400 Erez Zadok wrote:
Rename old vfs_ioctl to do_ioctl, because the comment above it clearly
indicates that it is an internal function not to be exported to modules;
therefore it should have a more traditional do_XXX name. The new do_ioctl
is exported in fs.h
On 10/28/07, Christoph Hellwig [EMAIL PROTECTED] wrote:
While you're at it, it's probably worth splitting this out into
a small helper function.
Why? Is the same pattern called from more than one place?
Regards,
Daniel
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel
On Sun, 2007-10-28 at 16:41 -0600, Matthew Wilcox wrote:
On Sun, Oct 28, 2007 at 05:50:30PM -0400, Trond Myklebust wrote:
You can't fix the false EDEADLK detection without solving the halting
problem. Best of luck with that.
I can see that it would be difficult to do efficiently, but
30 matches
Mail list logo
