From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752779AbdCFIWi (ORCPT ); Mon, 6 Mar 2017 03:22:38 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:40861 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752696AbdCFIWc (ORCPT ); Mon, 6 Mar 2017 03:22:32 -0500 Date: Mon, 6 Mar 2017 09:22:21 +0100 From: Heiko Carstens To: Dan Williams Cc: Michal Hocko , Sebastian Ott , Linux MM , "linux-kernel@vger.kernel.org" , Andrew Morton , "Rafael J. Wysocki" , Vladimir Davydov , Ben Hutchings Subject: Re: [PATCH] mm, add_memory_resource: hold device_hotplug lock over mem_hotplug_{begin, done} References: <20170227162031.GA27937@dhcp22.suse.cz> <20170228115729.GB13872@osiris> <20170301125105.GA5208@osiris> <20170301170429.GB5208@osiris> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17030608-0040-0000-0000-0000035627FE X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17030608-0041-0000-0000-00001F232D05 Message-Id: <20170306082221.GA4572@osiris> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-06_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703060071 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Dan, > > If you look at commit 5e33bc4165f3 ("driver core / ACPI: Avoid device hot > > remove locking issues") then lock_device_hotplug_sysfs() was introduced to > > avoid a different subtle deadlock, but it also sleeps uninterruptible, but > > not for more than 5ms ;) > > > > However I'm not sure if the device hotplug lock should also be used to fix > > an unrelated bug that was introduced with the get_online_mems() / > > put_online_mems() interface. Should it? > > No, I don't think it should. > > I like your proposed direction of creating a new lock internal to > mem_hotplug_begin() to protect active_writer, and stop relying on > lock_device_hotplug to serve this purpose. > > > If so, we need to sprinkle around a couple of lock_device_hotplug() calls > > near mem_hotplug_begin() calls, like Sebastian already started, and give it > > additional semantics (protecting mem_hotplug.active_writer), and hope it > > doesn't lead to deadlocks anywhere. > > I'll put your proposed patch through some testing. On s390 it _seems_ to work. Did it pass your testing too? If so I would send a patch with proper patch description for inclusion. Thanks, Heiko