Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751341AbdGQRUw (ORCPT ); Mon, 17 Jul 2017 13:20:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:37260 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751293AbdGQRUu (ORCPT ); Mon, 17 Jul 2017 13:20:50 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E6C122BCE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=jeyu@kernel.org Date: Mon, 17 Jul 2017 19:20:43 +0200 From: Jessica Yu To: Peter Zijlstra Cc: Mike Galbraith , Ilia Mirkin , LKML , "dri-devel@lists.freedesktop.org" , "nouveau@lists.freedesktop.org" , David Airlie , Ben Skeggs Subject: Re: suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335 Message-ID: <20170717172043.xk52z73qrz7wx7xw@redbean> References: <1499796510.5315.27.camel@gmx.de> <1499853345.23742.8.camel@gmx.de> <1499858703.23742.25.camel@gmx.de> <1500039368.5763.12.camel@gmx.de> <20170714155047.2zs3ps7cmnyvvwgb@hirez.programming.kicks-ass.net> <1500047898.5763.25.camel@gmx.de> <20170714161027.5htn5jlswvfgphzw@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170714161027.5htn5jlswvfgphzw@hirez.programming.kicks-ass.net> X-OS: Linux redbean 4.11.9-200.fc25.x86_64 x86_64 User-Agent: NeoMutt/20170714 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1681 Lines: 40 +++ Peter Zijlstra [14/07/17 18:10 +0200]: >On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote: >> On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote: > >> > Urgh, is for some mysterious reason the __bug_table section of modules >> > ending up in RO memory? >> > >> > I forever get lost in that link magic :/ >> >> +1 >> >> drm.ko >> ?20 __bug_table???00000630??0000000000000000??0000000000000000??0004bff3??2**0 >> ??????????????????CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA >> vmlinux >> 15 __bug_table 0000ba84 ffffffff81af26c0 0000000001af26c0 00cf26c0 2**0 >> CONTENTS, ALLOC, LOAD, READONLY, DATA >> >> Danged if I know... um um RELOC business mucks things up? > >Argh, it shouldn't be READONLY for vmlinux either, but apparently that >is working for mysterious reasons. If I'm not mistaken, this works because __bug_table falls outside of the RO range as specified in the vmlinux linker script (using x86_64 as the example, that means _text - __end_rodata_hpage_align). mark_rodata_ro() only sets ro memory protections for pages within this range, so __bug_table remains rw in memory despite its Elf section flags. Interestingly enough, my .rodata section is set 'WA' (rw) in vmlinux on my f25 system, so that leads me to think that Elf section flags in vmlinux don't seem to matter much when it comes to setting ro/nx protections.. However, in the module loader it's a different story; we do set page protections strictly according to the section flags, so since __bug_table only has SHF_ALLOC set, it assumes it's a readonly section and gets treated as such. So I would think that Josh's patch would fix this issue. Jessica