[lkml]   [2018]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] UBSAN: support __ubsan_handle_type_mismatch_v1

On 02/08/2018 06:46 PM, Mark Rutland wrote:
> Originally, UBSAN's __ubsan_handle_type_mismatch took a struct
> type_mismatch_data, as defined in lib/ubsan.h. This has an unsigned long
> alignment field.
> New versions of UBSAN call __ubsan_handle_type_mismatch_v1, which is
> similar to __ubsan_handle_type_mismatch, but takes a different struct
> where the alignment is stored in an unsigned char (as log2 of the
> alignment). All other fields are unchanged.
> As we don't implement __ubsan_handle_type_mismatch_v1, the kernel will
> fail to link when compiled with compilers using the new ABI (e.g. clang
> form the LLVM 5.0.0 release).
> This patch adds support for the new ABI. To keep things simple, we
> simply convert the new data format into the old format, and hand it on
> to the existing handlers.
> Signed-off-by: Mark Rutland <>
> Cc: Andrew Morton <>
> Cc: Andrey Ryabinin <>
> ---
> lib/ubsan.c | 14 ++++++++++++++
> lib/ubsan.h | 7 +++++++
> 2 files changed, 21 insertions(+)
> Andrey, does this look correct to you?

Commit 42440c1f9911b4b7b8ba3dc4e90c1197bc561211 looks correct to me ;)

Copying ->location is wrong, because we use bit in location struct to suppress multiple
reports of the same location, see was_reported(). So in you case REPORTED_BIT will be set
on stack and original source_location remain unchanged.

> Are there any other new ABI bits that need to be plumbed in?

ABI of __ubsan_handle_nonnull_return() changed as well, but it's never used in the kernel
and probably never will be. Thus I removed it, see bac7a1fff7926fb9891a18fe33650884b0e13e4

 \ /
  Last update: 2018-02-08 17:05    [W:0.035 / U:0.580 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site