From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com ([66.111.4.28]:50751 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932688AbbENMuV (ORCPT ); Thu, 14 May 2015 08:50:21 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 67468209B2 for ; Thu, 14 May 2015 08:50:21 -0400 (EDT) Date: Thu, 14 May 2015 05:50:19 -0700 From: Greg KH To: Pan Xinhui Cc: stable@vger.kernel.org Subject: Re: [PATCH V2] kernel/smp.c: fix a panic as cp->info is used wrongly and a, list corruption Message-ID: <20150514125019.GA12247@kroah.com> References: <5555B683.9070300@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5555B683.9070300@intel.com> Sender: stable-owner@vger.kernel.org List-ID: On Fri, May 15, 2015 at 05:04:03PM +0800, Pan Xinhui wrote: > this patch reverts commit 3440a1 which causes the regression and fix a list corruption. > > base knowledge: kernel call cp->func using cp->info as its argument. like cp->func(cp->info); > > current code is totally wrong, as 1) &softirq is at stack. 2) cp->info don't point to struct call_single_data. > So in remote_softirq_receive, > 1) If the caller had left __try_remote_softirq, dereferencing cp->info could not fetch the correct value. > 2) And we can't get struct call_single_data *cp anymore. > > The list corruption is below. > __local_trigger will add cp->list into softirq_work_list. But no one will delete cp->list on behalf of us. > if we can succeed to raise_softirq_irqoff, we must delete it from softirq_work_list. because we will lost control of pointer cp. > cp is passed in and may be freed later in other places. > > Signed-off-by: Pan Xinhui > --- > Changes in v2: > no codes changed from v1, just update the comment. > upstream commit fc21c0 fix this issue, as it removes the total feature. :) > the buggy codes exist in v3.10 and v3.12. Why shouldn't we just include fc21c0 instead? I don't like patches that are not identical to what is in Linus's tree. thanks, greg k-h