From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754527AbcAEU6V (ORCPT ); Tue, 5 Jan 2016 15:58:21 -0500 Received: from mail-wm0-f42.google.com ([74.125.82.42]:36163 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753539AbcAEU6Q (ORCPT ); Tue, 5 Jan 2016 15:58:16 -0500 Date: Tue, 5 Jan 2016 22:58:12 +0200 From: "Kirill A. Shutemov" To: Alan Stern Cc: linux-mm@kvack.org, Kernel development list , David Laight , "'Steinar H. Gunderson'" , "linux-usb@vger.kernel.org" Subject: Re: Does vm_operations_struct require a .owner field? Message-ID: <20160105205812.GA24738@node.shutemov.name> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 05, 2016 at 11:27:45AM -0500, Alan Stern wrote: > Hello: > > Question: The vm_operations_struct structure contains lots of callback > pointers. Is there any mechanism to prevent the callback routines and > the structure itself being unloaded from memory (if they are built into > modules) while the relevant VMAs are still in use? > > Consider a simple example: A user program calls mmap(2) on a device > file. Later on, the file is closed and the device driver's module is > unloaded. But until munmap(2) is called or the user program exits, the > memory mapping and the corresponding VMA will remain in existence. > (The man page for munmap specifically says "closing the file descriptor > does not unmap the region".) Thus when the user program does do an > munmap(), the callback to vma->vm_ops->close will reference nonexistent > memory and cause an oops. > > Normally this sort of thing is prevented by try_module_get(...->owner). > But vm_operations_struct doesn't include a .owner field. > > Am I missing something here? mmap(2) takes reference of the file, therefore the file is not closed from kernel POV until vma is gone and you cannot unload relevant module. See get_file() in mmap_region(). -- Kirill A. Shutemov