From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) by kanga.kvack.org (Postfix) with ESMTP id 2B2A96B0005 for ; Thu, 21 Jan 2016 00:11:15 -0500 (EST) Received: by mail-io0-f176.google.com with SMTP id 1so43169940ion.1 for ; Wed, 20 Jan 2016 21:11:15 -0800 (PST) Received: from ozlabs.org (ozlabs.org. [2401:3900:2:1::2]) by mx.google.com with ESMTPS id c18si47974801igr.73.2016.01.20.21.11.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jan 2016 21:11:14 -0800 (PST) From: Rusty Russell Subject: Re: [PATCH v2] mm: make apply_to_page_range more robust In-Reply-To: References: <569F184D.8020602@nextfour.com> Date: Thu, 21 Jan 2016 15:28:18 +1030 Message-ID: <87egdby1ed.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes , Mika =?utf-8?Q?Penttil=C3=A4?= Cc: LKML , linux-mm@kvack.org, Pekka Enberg David Rientjes writes: > On Wed, 20 Jan 2016, Mika Penttil=C3=A4 wrote: > >> Recent changes (4.4.0+) in module loader triggered oops on ARM.=20 >>=20=20=20=20=20 >> can be 0 triggering the bug BUG_ON(addr >=3D end);. >>=20 >> The call path is SyS_init_module()->set_memory_xx()->apply_to_page_range= (), >> and apply_to_page_range gets zero length resulting in triggering : >>=20=20=20=20 >> BUG_ON(addr >=3D end) >>=20 >> This is a consequence of changes in module section handling (Rusty CC:ed= ). >> This may be triggable only with certain modules and/or gcc versions.=20 >>=20 > > Well, what module are you loading to cause this crash? Why would it be=20 > passing size =3D=3D 0 to apply_to_page_range()? Again, that sounds like = a=20 > problem that we _want_ to know about since it is probably the result of=20 > buggy code and this patch would be covering it up. Yes, I'm curious too. It's certainly possible, since I expected a zero-length range to do nothing, but let's make sure we're not papering over some other screwup of mine. Thanks, Rusty. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758858AbcAUFLS (ORCPT ); Thu, 21 Jan 2016 00:11:18 -0500 Received: from ozlabs.org ([103.22.144.67]:44979 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758719AbcAUFLL convert rfc822-to-8bit (ORCPT ); Thu, 21 Jan 2016 00:11:11 -0500 From: Rusty Russell To: David Rientjes , Mika =?utf-8?Q?Penttil=C3=A4?= Cc: LKML , linux-mm@kvack.org, Pekka Enberg Subject: Re: [PATCH v2] mm: make apply_to_page_range more robust In-Reply-To: References: <569F184D.8020602@nextfour.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 21 Jan 2016 15:28:18 +1030 Message-ID: <87egdby1ed.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David Rientjes writes: > On Wed, 20 Jan 2016, Mika Penttilä wrote: > >> Recent changes (4.4.0+) in module loader triggered oops on ARM. >> >> can be 0 triggering the bug BUG_ON(addr >= end);. >> >> The call path is SyS_init_module()->set_memory_xx()->apply_to_page_range(), >> and apply_to_page_range gets zero length resulting in triggering : >> >> BUG_ON(addr >= end) >> >> This is a consequence of changes in module section handling (Rusty CC:ed). >> This may be triggable only with certain modules and/or gcc versions. >> > > Well, what module are you loading to cause this crash? Why would it be > passing size == 0 to apply_to_page_range()? Again, that sounds like a > problem that we _want_ to know about since it is probably the result of > buggy code and this patch would be covering it up. Yes, I'm curious too. It's certainly possible, since I expected a zero-length range to do nothing, but let's make sure we're not papering over some other screwup of mine. Thanks, Rusty.