Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754046AbbFDUbf (ORCPT ); Thu, 4 Jun 2015 16:31:35 -0400 Received: from cantor2.suse.de ([195.135.220.15]:37285 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753136AbbFDUbc (ORCPT ); Thu, 4 Jun 2015 16:31:32 -0400 Message-ID: <1433449885.2320.37.camel@stgolabs.net> Subject: Re: [PATCH 1/2] ipc,shm: move BUG_ON check into shm_lock From: Davidlohr Bueso To: Manfred Spraul Cc: Andrew Morton , linux-kernel@vger.kernel.org Date: Thu, 04 Jun 2015 13:31:25 -0700 In-Reply-To: <55709A77.5050504@colorfullife.com> References: <1432944186-7305-1-git-send-email-dave@stgolabs.net> <55709A77.5050504@colorfullife.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2457 Lines: 74 On Thu, 2015-06-04 at 20:35 +0200, Manfred Spraul wrote: > Hi Davidlohr, > > On 05/30/2015 02:03 AM, Davidlohr Bueso wrote: > > Upon every shm_lock call, we BUG_ON if an error was returned, > > indicating racing either in idr or in RMID. Move this logic > > into the locking. > > > > Signed-off-by: Davidlohr Bueso > > --- > > ipc/shm.c | 11 +++++++---- > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/ipc/shm.c b/ipc/shm.c > > index 6d76707..3152dea 100644 > > --- a/ipc/shm.c > > +++ b/ipc/shm.c > > @@ -155,8 +155,14 @@ static inline struct shmid_kernel *shm_lock(struct ipc_namespace *ns, int id) > > { > > struct kern_ipc_perm *ipcp = ipc_lock(&shm_ids(ns), id); > > > > - if (IS_ERR(ipcp)) > > + if (IS_ERR(ipcp)) { > > + /* > > + * We raced in the idr lookup or with RMID, > > + * either way, the ID is busted. > The comment is wrong: > "We raced in the idr lookup or with shm_destroy()" > > shm is not like msg or sem: > RMID merely marks a shmid as deletable (SHM_DEST), delete (i.e.: > shm_rmid(), then ipc_rmid()) happens only after the last attached > segment is detatched. > > And: (unrelated to the patch) > For do_shmat(), I'm not 100% sure that the BUG can't be triggered. Could you be referring to the fact that we don't mark the segment ->deleted when doing RMID (do_shm_rmid)? This would certainly cause checks to ipc_valid_object() to completely screw up. I've actually been chasing that BUG() in shm_open and shm_close during forking and exiting (unmapping) respectively. *Completely untested* Thanks, Davidlohr diff --git a/ipc/shm.c b/ipc/shm.c index 3323c49..4e78cd2 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -95,6 +95,14 @@ static void do_shm_rmid(struct ipc_namespace *ns, struct kern_ipc_perm *ipcp) shp->shm_perm.mode |= SHM_DEST; /* Do not find it any more */ shp->shm_perm.key = IPC_PRIVATE; + /* + * Mark the object deleted. As opposed to + * sems or msg queues, shm only marks the + * shmid deletable upon RMID, and delays + * the freeing until there are no more + * active users of the segment. + */ + shp->shm_perm.deleted = true; shm_unlock(shp); } else shm_destroy(ns, shp); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/