From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: fs: proc: gpf in find_entry Date: Mon, 22 Dec 2014 13:12:21 -0500 Message-ID: <54985F05.2040603@oracle.com> References: <54982C98.9070806@oracle.com> <87oaqvd6ni.fsf@x220.int.ebiederm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: LKML , linux-fsdevel , Al Viro , "davej @mail.xmission.com>> Dave Jones" To: Andrey Ryabinin , "Eric W. Biederman" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 12/22/2014 12:52 PM, Andrey Ryabinin wrote: > 2014-12-22 18:51 GMT+03:00 Eric W. Biederman : >> These two instructions: >>>> 11: 4d 85 ff test %r15,%r15 >>>> 14: 0f 84 de 01 00 00 je 0x1f8 >> >> Should prevent a NULL %r15 value from ever reaching the trapping >> instruction. > > If they were executed, then yes. But I think there was jump from somewhere > to the instructions below those two. There is indeed a jump direct to that point, which avoids the %r15 check. >> What other horrible things does KASAN do to the machine code? >> > > kasan insert something like following before any memory access: > > s8 *shadow_addr = (add >> 3) + shadow_offset; > > if (unlikely(*shadow_addr)) > if (unlikely(addr & 7 >= *shadow_addr)) > report_bug(addr); > > > I suspect that Sasha is using kasan along with ubsan. > In that case generated code much more horrid. It's not *that* bad :) Thanks, Sasha