Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 25 Jan 2018 16:12:19 +0100
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Jiri Slaby <jslaby@suse.cz>
Cc:     Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
        stable@vger.kernel.org, Li Jinyue <lijinyue@huawei.com>,
        peterz@infradead.org, dvhart@infradead.org,
        "torvalds@linux-foundation.org" <torvalds@linux-foundation.org>
Subject: Re: [PATCH 4.14 17/89] futex: Prevent overflow by strengthen input
 validation
Message-ID: <20180125151219.GA16752@kroah.com>
References: <20180122083954.683903493@linuxfoundation.org>
 <20180122083956.427607580@linuxfoundation.org>
 <20567b49-e0a3-e9e0-d520-74bbfc20d414@suse.cz>
 <alpine.DEB.2.20.1801251502310.2020@nanos>
 <ab877235-a584-1769-a322-f3451bee5ec6@suse.cz>
 <alpine.DEB.2.20.1801251529540.2020@nanos>
 <e08b3b53-9459-35e9-c119-047745603d49@suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e08b3b53-9459-35e9-c119-047745603d49@suse.cz>
User-Agent: Mutt/1.9.2 (2017-12-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jan 25, 2018 at 03:47:32PM +0100, Jiri Slaby wrote:
> On 01/25/2018, 03:30 PM, Thomas Gleixner wrote:
> > So what's the problem?
> 
> The problem I see is that every stable kernel now requires updated
> strace with their commit from yesterday to build correctly. In
> particular, the new stable kernels cause rpm build failures of strace in
> all our distros (based on those stable kernels). Sure, we can patch
> strace in every distro every nth kernel update, but it's mere
> impractical. Kernel should not break userspace, right?

Well, when userspace is doing something stupid... :)

> BTW why was the patch applied to stable? We actually do pass
> -fno-strict-overflow.

The same reason it was applied upstream, it fixes a reported
issue.

Does that mean that all UBSAN overflow error reports are not valid
because of how we build the kernel?

thanks,

greg k-h