From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:47696 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750791AbdE1F3z (ORCPT ); Sun, 28 May 2017 01:29:55 -0400 Date: Sun, 28 May 2017 07:29:44 +0200 From: Greg KH To: Oleg Drokin Cc: linux-stable Subject: Re: [PATCH] staging/lustre/lov: remove set_fs() call from lov_getstripe() Message-ID: <20170528052944.GA27636@kroah.com> References: <20170527202629.GA16472@kroah.com> <1E4800EB-B661-490B-B39F-6F1C65C47586@linuxhacker.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1E4800EB-B661-490B-B39F-6F1C65C47586@linuxhacker.ru> Sender: stable-owner@vger.kernel.org List-ID: On Sat, May 27, 2017 at 06:38:06PM -0400, Oleg Drokin wrote: > > On May 27, 2017, at 4:26 PM, Greg KH wrote: > > > On Sat, May 27, 2017 at 03:22:18PM -0400, Oleg Drokin wrote: > >> lov_getstripe() calls set_fs(KERNEL_DS) so that it can handle a struct > >> lov_user_md pointer from user- or kernel-space. This changes the > >> behavior of copy_from_user() on SPARC and may result in a misaligned > >> access exception which in turn oopses the kernel. In fact the > >> relevant argument to lov_getstripe() is never called with a > >> kernel-space pointer and so changing the address limits is unnecessary > >> and so we remove the calls to save, set, and restore the address > >> limits. > >> > >> Signed-off-by: John L. Hammond > >> Reviewed-on: http://review.whamcloud.com/6150 > >> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3221 > >> Reviewed-by: Andreas Dilger > >> Reviewed-by: Li Wei > >> CC: linux-stable # >= v3.11 > >> Signed-off-by: Oleg Drokin > >> --- > >> drivers/staging/lustre/lustre/lov/lov_pack.c | 9 --------- > >> 1 file changed, 9 deletions(-) > > > > What was the git commit id of this patch in Linus's tree? > > It's not in Linus tree yet. > I was just informed that this patch should go to stable by Al, so I added stable > to the list. This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.