Re: [RFC PATCH 04/21] x86/hweight: Add stack frame dependency for __arch_hweight*()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jul 18, 2015 at 08:44:15AM -0500, Josh Poimboeuf wrote:
> Ok, so would you rather adding a whitelist to tell stackvalidate to
> ignore it?  Something like this?

I tried it and maybe I'm missing something but that doesn't work:

$ make drivers/gpu/drm/i915/intel_ringbuffer.o
  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CHK     include/generated/timeconst.h
  CHK     include/generated/bounds.h
  CHK     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  CC      drivers/gpu/drm/i915/intel_ringbuffer.o
./arch/x86/include/asm/arch_hweight.h: Assembler messages:
./arch/x86/include/asm/arch_hweight.h:31: Error: symbol `.Ltemp32' is already defined
./arch/x86/include/asm/arch_hweight.h:31: Error: symbol `.Ltemp32' is already defined
./arch/x86/include/asm/arch_hweight.h:31: Error: symbol `.Ltemp32' is already defined
scripts/Makefile.build:258: recipe for target 'drivers/gpu/drm/i915/intel_ringbuffer.o' failed
make[1]: *** [drivers/gpu/drm/i915/intel_ringbuffer.o] Error 1
Makefile:1528: recipe for target 'drivers/gpu/drm/i915/intel_ringbuffer.o' failed
make: *** [drivers/gpu/drm/i915/intel_ringbuffer.o] Error 2

Also, that label temp32 could be more descriptive.

Regardless of the above, I don't like the idea of adding some
compile-time checking and thus obfuscating what is already non-obvious
code.

And since your tool is already parsing ELF files and all that other fun,
what I'd do is make that checking out-of-line *without* adding any new
code to the kernel.

In this particular case, you have:

#APP
# 28 "./arch/x86/include/asm/arch_hweight.h" 1
        661:
        call __sw_hweight32
662:
.skip -(((6651f-6641f)-(662b-661b)) > 0) * ((6651f-6641f)-(662b-661b)),0x90
663:
.pushsection .altinstructions,"a"
 .long 661b - .
 .long 6641f - .
 .word ( 4*32+23)
 .byte 663b-661b
 .byte 6651f-6641f
 .byte 663b-662b
.popsection
.pushsection .altinstr_replacement, "ax"
6641:
        .byte 0xf3,0x40,0x0f,0xb8,0xc7
6651:
        .popsection
# 0 "" 2

so you see that a CALL instruction gets replaced with a POPCNT and
the feature bit used is 4*32+23 which is X86_FEATURE_POPCNT. This
information is enough to detect that particular case and add the offset
".long 661b - ." to the list of instructions which stackvalidate should
ignore.

Anyway, this is what I'd do.

IMNSVHO, we must be very conservative and not add some
markers/helpers/etc to code only so that tools can do their job. Not if
it can be helped. Instead, tools should do the hard work and we should
keep kernel code clean.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe live-patching" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux