linux-kernel - Re: linux-next: build failure after merge of the kspp tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220125222545.353fa400@gandalf.local.home>
Date:   Tue, 25 Jan 2022 22:26:11 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Masami Hiramatsu <mhiramat@...nel.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Beau Belgrave <beaub@...ux.microsoft.com>
Subject: Re: linux-next: build failure after merge of the kspp tree

On Tue, 25 Jan 2022 19:18:53 -0800
Kees Cook <keescook@...omium.org> wrote:

> On Tue, Jan 25, 2022 at 08:16:34PM -0500, Steven Rostedt wrote:
> > On Wed, 26 Jan 2022 09:35:38 +0900
> > Masami Hiramatsu <mhiramat@...nel.org> wrote:
> >   
> > > I think Kees' idea seems better. If you and Beau are good, I will update
> > > the macros for __rel_loc. (This requires to change some user-space
> > > application which Beau is making too.)  
> > 
> > If Beau is OK with it, I'm OK with it too. I need to release a new version
> > of libtraceevent anyway, and I can make the update for that too.
> > 
> > Who's adding the patch (if Beau says it's OK), you or Kees?  
> 
> I don't know anything about libtraceevent, so hopefully not me! :) The
> patches Masami and I already sent fix the warning, so I leave it you
> y'all to decide if you want to make the internals a bit simpler.
> 


Thinking about this more. I may just take both your patches, and leave it
as an offset from the location of the descriptor. It's closer to the
meaning of "relative" than doing it as a fixed offset from data.

And then no other patches or user space needs to be changed.

Thanks,

-- Steve