From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Cox Subject: Re: [RFC/PATCH] revoke/frevoke system calls V2 Date: Thu, 27 Jul 2006 16:07:02 +0100 Message-ID: <1154012822.13509.52.camel@localhost.localdomain> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, akpm@osdl.org, viro@zeniv.linux.org.uk, tytso@mit.edu, tigran@veritas.com Return-path: Received: from outpipe-village-512-1.bc.nu ([81.2.110.250]:50139 "EHLO lxorguk.ukuu.org.uk") by vger.kernel.org with ESMTP id S1751084AbWG0Osp (ORCPT ); Thu, 27 Jul 2006 10:48:45 -0400 To: Pekka J Enberg In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Ar Iau, 2006-07-27 am 17:25 +0300, ysgrifennodd Pekka J Enberg: > There are two known remaining issues: if someone expands the fd > tables, we will BUG_ON. Edgar Toerning expressed concers over allowing > any user to remove mappings from another process and letting it > crash. Albert Cahalan suggested either converting the shared mapping > to private or substitute the unmapped pages with zeroed pages. That should be three I think. frevoke and revoke should not return until all the existing outstanding is dead. For devices that means we need to wake up the device where possible and really suggests we need a device ->revoke method. TTY devices need this to allow us to re-implement vhangup in terms of revoke. Other devices devices are not all sufficiently secure without this check. Some may also want to use this hook to ensure that any security context is dead (eg cached crypto keys). Alan