From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by kanga.kvack.org (Postfix) with ESMTP id 189696B0007 for ; Mon, 4 Jan 2016 13:59:20 -0500 (EST) Received: by mail-wm0-f52.google.com with SMTP id b14so198800274wmb.1 for ; Mon, 04 Jan 2016 10:59:20 -0800 (PST) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com. [2a00:1450:400c:c09::242]) by mx.google.com with ESMTPS id uq9si147140866wjc.17.2016.01.04.10.59.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jan 2016 10:59:18 -0800 (PST) Received: by mail-wm0-x242.google.com with SMTP id l65so56135011wmf.3 for ; Mon, 04 Jan 2016 10:59:18 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <968b4c079271431292fddfa49ceacff576be6849.1451869360.git.tony.luck@intel.com> <20160104120751.GG22941@pd.tnic> Date: Mon, 4 Jan 2016 10:59:18 -0800 Message-ID: Subject: Re: [PATCH v6 1/4] x86: Clean up extable entry format (and free up a bit) From: Tony Luck Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: Borislav Petkov , Ingo Molnar , Andrew Morton , Andy Lutomirski , Dan Williams , Robert , Linux Kernel Mailing List , "linux-mm@kvack.org" , linux-nvdimm , X86-ML > ----- begin comment ----- > > The offset to the fixup is signed, and we're trying to use the high > bits for a different purpose. In C, we could just do: > > u32 class_and_offset = ((target - here) & 0x3fffffff) | class; > > Then, to decode it, we'd mask off the class and sign-extend to recover > the offset. > > In asm, we can't do that, because this all gets laundered through the > linker, and there's no relocation type that supports this chicanery. > Instead we cheat a bit. We first add a large number to the offset > (0x20000000). The result is still nominally signed, but now it's > always positive, and the two high bits are always clear. We can then > set high bits by ordinary addition or subtraction instead of using > bitwise operations. As far as the linker is concerned, all we're > doing is adding a large constant to the difference between here (".") > and the target, and that's a valid relocation type. > > In the C code, we just mask off the class bits and subtract 0x20000000 > to get the offset. > > ----- end comment ----- But presumably those constants get folded together, so the linker is dealing with only one offset. It doesn't (I assume) know that our source code added 0x20000000 and then added/subtracted some more. It looks like we could just use: class0: +0x40000000 class1: +0x80000000 (or subtract ... whatever doesn't make the linker cranky) class2: -0x40000000 class3: don't add/subtract anything ex_class() stays the same (just looks at bit31/bit30) ex_fixup_addr() has to use ex_class() to decide what to add/subtract (if anything). Would that work? Would it be more or less confusing? -Tony -- 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