From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Mar 2003 09:37:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Mar 2003 09:37:26 -0500 Received: from mail1-3.netinsight.se ([212.247.11.2]:53518 "HELO ernst.netinsight.se") by vger.kernel.org with SMTP id ; Thu, 27 Mar 2003 09:37:23 -0500 Message-ID: <3E830EC7.651EB9CE@netinsight.se> Date: Thu, 27 Mar 2003 15:46:31 +0100 From: Stephane X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.19-16mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org CC: Stephane Tessier Subject: exit_mmap Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org I have a question about mmap and the close operation of a vm_area_struct. Is there a reason why in exit_mmap, when a process dies unexpectedly, the vm_ops->close is called before zap_page_range is called? The problem is that if you have allocated one or several kernel pages for a vm_area_struct, you can not free them in the vm_ops->close operation since the count field of the pages is not 0 because they are still mapped. The count will be cleared when zap_page_range is called. This means that exit_mmap calls vm_ops->close and zap_page_range in the reverse order of a normal execution of the process, that is when the process unmap the area before dying. It would be more deterministic and simple if vm_ops->close was always called when all the pages of the area was unmapped. PS: please can you CC'ed the answer to stephane.tessier@netinsight.se -- Stephane Tessier Net Insight AB stephane.tessier@netinsight.se Västberga Allé 9 http://www.netinsight.se SE-126 30 Hägersten phone:+46-8-685 04 60 Sweden fax: +46-8-685 04 20