From owner-freebsd-current Thu Mar 4 19:25:39 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 3058614C4A for ; Thu, 4 Mar 1999 19:25:34 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40405>; Fri, 5 Mar 1999 14:13:37 +1100 Date: Fri, 5 Mar 1999 14:25:08 +1100 From: Peter Jeremy Subject: Re: Simple DOS against 3.x locks box solid To: dillon@apollo.backplane.com Cc: current@FreeBSD.ORG Message-Id: <99Mar5.141337est.40405@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > The problem is a deadlock caused by the fgrep. The fgrep is mmap()ing > the file, but then it does some really weird crap when dealing with > larger files. ... > The solution is more difficult. We could hack an exception for PRIVATE > mmap's... there really is no need for the vm_fault code to lock the vnode. > Howver, other situations can occur where this hack would not work. Another interim solution would be to `fix' GNU grep so it doesn't attempt to read() into mmap()'d space. (Having not looked at the code, I don't know how difficult this would be). As for the general problem, is it sensible to allow a read-only file to be mmap'd R/W (with or without MAP_PRIVATE) and then written into? It would be fairly easy to make mmap() return EACCES if the fd was not open for writing (or map the memory R/O and SEGV on a write). I would personally prefer to see a process die with an mmap failure (or SIGSEGV), rather than cause a deadlock - ie even if we do want/ need to support R/W mmap() on R/O files [and I can see some possible use for this], it would be worthwhile restricting mmap() in the short-term - and removing the restriction once the underlying problem is solved. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message