Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Hole\s+punching\s+and\s+mmap\s+races\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Hole\s+punching\s+and\s+mmap\s+races\s*$/: 20 ]

Total 20 documents matching your query.

1. Hole punching and mmap races (score: 1): Author: Jan Kara <jack@xxxxxxx>; Date: Wed, 16 May 2012 00:48:05 +0200; Hello, Hugh pointed me to ext4 hole punching code which is clearly missing some locking. But looking at the code more deeply I realized I don't see anything preventing the following race in XFS or ex; /archives/xfs/2012-05/msg00208.html (7,781 bytes)
2. Re: Hole punching and mmap races (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Wed, 16 May 2012 12:14:23 +1000; No, it doesn't. It's a known problem due to not being able to take a lock in .page_mkwrite() to serialise mmap() IO against truncation or other IO such as direct IO. This has been known for, well, lo; /archives/xfs/2012-05/msg00211.html (10,376 bytes)
3. Re: Hole punching and mmap races (score: 1): Author: Jan Kara <jack@xxxxxxx>; Date: Wed, 16 May 2012 15:04:45 +0200; I thought someone must have noticed before since XFS has hole punching for a long time... Actually, I've been playing with VM_FAULT_RETRY recently (for freezing patches) and it's completely unhandled; /archives/xfs/2012-05/msg00212.html (12,292 bytes)
4. Re: Hole punching and mmap races (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 17 May 2012 17:43:08 +1000; Yeah, it's a mess. Seems kind of silly to me to have a generic retry capability in the page fault handler and then not implement it in a useful manner for *anyone*. Which means we'd be adding another; /archives/xfs/2012-05/msg00219.html (11,613 bytes)
5. Re: Hole punching and mmap races (score: 1): Author: Jan Kara <jack@xxxxxxx>; Date: Fri, 18 May 2012 01:28:29 +0200; Yeah. It's only tailored for one specific use in filemap_fault() on x86... Yeah, direct IO case won't be trivial. We would have to take the lock after dio_get_page() and release it before going for n; /archives/xfs/2012-05/msg00225.html (13,207 bytes)
6. Re: Hole punching and mmap races (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 18 May 2012 20:12:10 +1000; Seems the simple answer to me is to prevent page faults while hole punching, then.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx; /archives/xfs/2012-05/msg00230.html (9,158 bytes)
7. Re: Hole punching and mmap races (score: 1): Author: Jan Kara <jack@xxxxxxx>; Date: Fri, 18 May 2012 15:32:50 +0200; Yes, that's what I was suggesting in the beginning :) And I was asking whether people are OK with another lock in the page fault path (in particular in ->page_mkwrite) or whether someone has a better; /archives/xfs/2012-05/msg00233.html (10,067 bytes)
8. Re: Hole punching and mmap races (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Sat, 19 May 2012 11:40:24 +1000; Right. I probably should have been clearer in what I said. We got back here from considering another IO level lock and all the complexity it adds to just solve the hole punch problem.... That's for t; /archives/xfs/2012-05/msg00245.html (14,050 bytes)
9. Re: Hole punching and mmap races (score: 1): Author: Jan Kara <jack@xxxxxxx>; Date: Thu, 24 May 2012 14:35:38 +0200; Yes, this is a nice summary of the most interesting cases. For completeness, here are the remaining cases: 8. mmap vs writeback (page lock) 9. writeback vs direct IO (as direct IO vs buffered IO) 10.; /archives/xfs/2012-05/msg00309.html (16,723 bytes)
10. Re: Hole punching and mmap races (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 5 Jun 2012 15:51:50 +1000; A lot of them are the IO exclusion side of the problem - I ignored them just to make my discussion short and to the point. So thanks for documenting them for everyone. :) .... It seems to me that we; /archives/xfs/2012-06/msg00028.html (14,411 bytes)
11. Re: Hole punching and mmap races (score: 1): Author: Marco Stornelli <marco.stornelli@xxxxxxxxx>; Date: Tue, 5 Jun 2012 08:22:29 +0200; 2012/6/5 Dave Chinner <david@xxxxxxxxxxxxx>: I think we have even the xip cases here. Marco; /archives/xfs/2012-06/msg00030.html (13,306 bytes)
12. Re: Hole punching and mmap races (score: 1): Author: Jan Kara <jack@xxxxxxx>; Date: Wed, 6 Jun 2012 01:15:30 +0200; Yes, we also need to keep things fine grained to keep scalability of direct IO and buffered reads... You cannot just use a lock (not even a shared one) both above and under mmap_sem. That is deadlock; /archives/xfs/2012-06/msg00058.html (12,685 bytes)
13. Re: Hole punching and mmap races (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Wed, 6 Jun 2012 10:06:36 +1000; Well, that's assuming that exclusive lock requests form a barrier to new shared requests. Remember that I'm talking about a range lock here, which we can make up whatever semantics we'd need, includi; /archives/xfs/2012-06/msg00061.html (14,035 bytes)
14. Re: Hole punching and mmap races (score: 1): Author: Jan Kara <jack@xxxxxxx>; Date: Wed, 6 Jun 2012 11:58:27 +0200; That's true. But if you have semantics like this, constant writing to or reading from a file could starve e.g. truncate. So I'd prefer not to open this can of worms and keep semantics of rw semaphore; /archives/xfs/2012-06/msg00065.html (14,546 bytes)
15. Re: Hole punching and mmap races (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Wed, 6 Jun 2012 23:36:16 +1000; Except truncate uses the i_mutex/i_iolock for exclusion, so it would never get held off any more than it already does by buffered IO in this case. i.e. the mapping tree range lock is inside the locks; /archives/xfs/2012-06/msg00067.html (14,565 bytes)
16. Re: Hole punching and mmap races (score: 1): Author: Jan Kara <jack@xxxxxxx>; Date: Thu, 7 Jun 2012 23:58:35 +0200; True. I was just hoping that i_mutex won't be needed if we get our new lock right. Yes. Just as I said before it is not an unsolvable situation since for direct IO we can grab our lock after get_user; /archives/xfs/2012-06/msg00085.html (16,857 bytes)
17. Re: Hole punching and mmap races (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 8 Jun 2012 10:57:00 +1000; Well, we currently allow overlapping direct IO to the same range in XFS, The order of completion is underfined, just like concurrent IOs to the same sector of a disk, but it basically results in dire; /archives/xfs/2012-06/msg00087.html (20,377 bytes)
18. Re: Hole punching and mmap races (score: 1): Author: Jan Kara <jack@xxxxxxx>; Date: Fri, 8 Jun 2012 23:36:29 +0200; Yeah, overlapping direct IO is asking for trouble (except possibly two direct IO reads). For buffered reads we would lock page-by-page anyway (again due to locking constraints with mmap_sem when copy; /archives/xfs/2012-06/msg00118.html (23,381 bytes)
19. Re: Hole punching and mmap races (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Sat, 9 Jun 2012 09:06:16 +1000; Not sure I understand what that constraint is - I hav ebeen thinking that the buffered IO range lok would be across the entire IO, not individual pages. As it is, if we want to do multipage writes (a; /archives/xfs/2012-06/msg00121.html (12,143 bytes)
20. Re: Hole punching and mmap races (score: 1): Author: Jan Kara <jack@xxxxxxx>; Date: Tue, 12 Jun 2012 10:56:39 +0200; The problem is that buffered IO path does (e.g. in generic_perform_write()): iov_iter_fault_in_readable() - that faults in one page worth of buffers, takes mmap_sem ->write_begin() copy data - iov_it; /archives/xfs/2012-06/msg00157.html (13,463 bytes)

Current List: 1 - 20
Page: [1]