From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755104AbdGJXno (ORCPT ); Mon, 10 Jul 2017 19:43:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39062 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755035AbdGJXnn (ORCPT ); Mon, 10 Jul 2017 19:43:43 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 670D180C26 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jglisse@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 670D180C26 Date: Mon, 10 Jul 2017 19:43:39 -0400 From: Jerome Glisse To: Evgeny Baskakov Cc: "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , John Hubbard , David Nellans , Mark Hairgrove , Sherry Cheung , Subhash Gutti Subject: Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4 Message-ID: <20170710234339.GA15226@redhat.com> References: <20170522165206.6284-1-jglisse@redhat.com> <20170522165206.6284-13-jglisse@redhat.com> <5f476e8c-8256-13a8-2228-a2b9e5650586@nvidia.com> <20170701005749.GA7232@redhat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 10 Jul 2017 23:43:42 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Mon, Jul 10, 2017 at 03:59:37PM -0700, Evgeny Baskakov wrote: > On 6/30/17 5:57 PM, Jerome Glisse wrote: > ... > > Hi Jerome, > > I am seeing a strange crash in our code that uses the hmm_device_new() > helper. After the driver is repeatedly loaded/unloaded, hmm_device_new() > suddenly returns NULL. > > I have reproduced this with the dummy driver from the hmm-next branch: > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000208 Horrible stupid bug in the code, most likely from cut and paste. Attached patch should fix it. I don't know how long it took for you to trigger it. Jérôme --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="0001-mm-hmm-fix-major-device-driver-exhaustion-dumb-cut-a.patch" Content-Transfer-Encoding: 8bit >>From 0abb8ba8e680406d8e860b2645f7f0e98f628916 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= Date: Mon, 10 Jul 2017 19:39:24 -0400 Subject: [PATCH] mm/hmm: fix major device driver exhaustion (dumb cut and paste mistake) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This is likely the result of some cut and paste gone wrong. Signed-off-by: Jérôme Glisse --- mm/hmm.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/mm/hmm.c b/mm/hmm.c index 28e54e3..6d1705a 100644 --- a/mm/hmm.c +++ b/mm/hmm.c @@ -1206,18 +1206,11 @@ static void hmm_device_release(struct device *device) struct hmm_device *hmm_device_new(void *drvdata) { struct hmm_device *hmm_device; - int ret; hmm_device = kzalloc(sizeof(*hmm_device), GFP_KERNEL); if (!hmm_device) return ERR_PTR(-ENOMEM); - ret = alloc_chrdev_region(&hmm_device->device.devt, 0, 1, "hmm_device"); - if (ret < 0) { - kfree(hmm_device); - return NULL; - } - spin_lock(&hmm_device_lock); hmm_device->minor = find_first_zero_bit(hmm_device_mask, HMM_DEVICE_MAX); if (hmm_device->minor >= HMM_DEVICE_MAX) { -- 2.9.4 --9jxsPFA5p3P2qPhR--