Messages in this thread | | | Date | Sun, 12 May 2002 21:51:27 -0700 | Subject | Re: [RFC] ext2 and ext3 block reservations can be bypassed | From | Elladan <> |
| |
On Mon, May 13, 2002 at 06:22:42AM +0200, Kasper Dupont wrote: > Alexander Viro wrote: > > > > On Mon, 13 May 2002, Peter Chubb wrote: > > > > > This is why in SVr4, struct cred is cloned at open time, and passed > > > down to each VFS operation. > > > > That doesn't work for shared mappings over holes. Unfortunately. > > Yes, credentials cache a-la 4.4BSD would help in many cases, but > > we have no reasonably credentials when kswapd writes a dirty page > > on disk. It _can_ cause allocations. And many processes might've > > touched that page until it finally got written out - which credentials > > would you use? > > I'd rather have the check done when the page gets dirty in the > first place. Refuse the CoW if there is not diskspace to write > it back. Right now we can go beyond the diskspace we are allowed > to use and we will silently loose data if we go beyond the > available diskspace.
So, the way this would work (presumably) is that space gets reserved on the filesystem as soon as the page goes dirty, if space is not presently allocated for that page. The process would receive a SIGBUS if they attempt to write to the page, but backing store reservation failed, as they do when, eg., there's an IO error on a page or some such.
If the mapping was held by more than one process, and one had permission to dirty the page and the other did not, then whose credentials should get used would just be a matter of which one writes first. If the disk is full for users and root dirties the page first, then the user can re-dirty it. If the user dirties it first, then the user receives SIGBUS. If the disk is full for everyone, then either one would receive the signal.
-J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |