Hi Josh,
I recently did some randconfig testing with a plain 4.14-stable kernel
and gcc-7.3.0, and came across three distinct objtool warnings:
drivers/misc/lkdtm_bugs.o: warning: objtool:
lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool:
x509_note_pkey_algo()+0xa4: sibling call from callable instruction
with modified stack frame
drivers/infiniband/hw/bnxt_re/qplib_fp.o: warning: objtool:
bnxt_qplib_poll_cq()+0x106: sibling call from callable instruction
with modified stack frame
It's likely that this is the complete set at the moment, I saw each
one multiple times,
but did not see any others. I'll reply with the respective object
files for your reference,
in case these are so far unknown to you. There are only a handful of randconfig
warnings we see overall in the kernel these days (at least on x86 and arm64), so
even if they are false-positive, it would be great to get rid of the
output so we can
do randconfig testing on 4.14.y and treat any output from 'make -s' as
a regression.
I did not check
With gcc-8, things are looking very differently, and we still get an
endless supply of
similar warnings.
Arnd
The patch
spi: atmel: init FIFOs before spi enable
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 9581329eff9db72ab4fbb46a594fd7fdda3c51b0 Mon Sep 17 00:00:00 2001
From: Eugen Hristev <eugen.hristev(a)microchip.com>
Date: Tue, 27 Feb 2018 12:25:07 +0200
Subject: [PATCH] spi: atmel: init FIFOs before spi enable
The datasheet recommends initializing FIFOs before
SPI enable. If we do not do it like this, there may be
a strange behavior. We noticed that DMA does not work properly
with FIFOs if we do not clear them beforehand or enable them
before SPIEN.
Signed-off-by: Eugen Hristev <eugen.hristev(a)microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
drivers/spi/spi-atmel.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 4a11fc0d4136..b7936f815373 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1512,6 +1512,11 @@ static void atmel_spi_init(struct atmel_spi *as)
{
spi_writel(as, CR, SPI_BIT(SWRST));
spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
+
+ /* It is recommended to enable FIFOs first thing after reset */
+ if (as->fifo_size)
+ spi_writel(as, CR, SPI_BIT(FIFOEN));
+
if (as->caps.has_wdrbt) {
spi_writel(as, MR, SPI_BIT(WDRBT) | SPI_BIT(MODFDIS)
| SPI_BIT(MSTR));
@@ -1522,9 +1527,6 @@ static void atmel_spi_init(struct atmel_spi *as)
if (as->use_pdc)
spi_writel(as, PTCR, SPI_BIT(RXTDIS) | SPI_BIT(TXTDIS));
spi_writel(as, CR, SPI_BIT(SPIEN));
-
- if (as->fifo_size)
- spi_writel(as, CR, SPI_BIT(FIFOEN));
}
static int atmel_spi_probe(struct platform_device *pdev)
--
2.16.1
The patch
ASoC: wm_adsp: For TLV controls only register TLV get/set
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From d7789f5bcdb298c4a302db471b1b20f74a20de95 Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald <rf(a)opensource.cirrus.com>
Date: Wed, 28 Feb 2018 10:31:10 +0000
Subject: [PATCH] ASoC: wm_adsp: For TLV controls only register TLV get/set
Normal 512-byte get/set of a TLV isn't supported but we were
registering the normal get/set anyway and relying on omitting
the SNDRV_CTL_ELEM_ACCESS_[READ|WRITE] flags to prevent them
being called.
Trouble is if this gets broken in the core ALSA code - as it has
been since at least 4.14 - the standard get/set can be called
unexpectedly and corrupt memory.
There's no point providing functions that won't be called and
it's a trivial change. The benefit is that if the ALSA core gets
broken again we get a big fat immediate NULL dereference instead
of a memory corruption timebomb.
Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
sound/soc/codecs/wm_adsp.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c
index 66e32f5d2917..989d093abda7 100644
--- a/sound/soc/codecs/wm_adsp.c
+++ b/sound/soc/codecs/wm_adsp.c
@@ -1204,12 +1204,14 @@ static int wmfw_add_ctl(struct wm_adsp *dsp, struct wm_coeff_ctl *ctl)
kcontrol->put = wm_coeff_put_acked;
break;
default:
- kcontrol->get = wm_coeff_get;
- kcontrol->put = wm_coeff_put;
-
- ctl->bytes_ext.max = ctl->len;
- ctl->bytes_ext.get = wm_coeff_tlv_get;
- ctl->bytes_ext.put = wm_coeff_tlv_put;
+ if (kcontrol->access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK) {
+ ctl->bytes_ext.max = ctl->len;
+ ctl->bytes_ext.get = wm_coeff_tlv_get;
+ ctl->bytes_ext.put = wm_coeff_tlv_put;
+ } else {
+ kcontrol->get = wm_coeff_get;
+ kcontrol->put = wm_coeff_put;
+ }
break;
}
--
2.16.1
On Fri, Feb 23, 2018 at 06:29:02PM +0000, Ard Biesheuvel wrote:
> Stable backport commit 173358a49173 ("arm64: kpti: Add ->enable callback
> to remap swapper using nG mappings") of upstream commit f992b4dfd58b did
> not survive the backporting process unscathed, and ends up writing garbage
> into the TTBR1_EL1 register, rather than pointing it to the zero page to
> disable translations. Fix that.
>
> Cc: <stable(a)vger.kernel.org> #v4.14
> Reported-by: Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
> ---
> arch/arm64/mm/proc.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Any reason why you didn't cc: the stable list, as this is a patch that
is not needed in mainline, right?
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index 08572f95bd8a..2b473ddeb7a3 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -155,7 +155,7 @@ ENDPROC(cpu_do_switch_mm)
>
> .macro __idmap_cpu_set_reserved_ttbr1, tmp1, tmp2
> adrp \tmp1, empty_zero_page
> - msr ttbr1_el1, \tmp2
> + msr ttbr1_el1, \tmp1
I don't understand why this isn't also needed in Linus's tree. What
commit there prevents this from being required?
thanks,
greg k-h
This is a note to let you know that I've just added the patch titled
vsprintf: avoid misleading "(null)" for %px
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
vsprintf-avoid-misleading-null-for-px.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3a129cc2151425e5aeb69aeb25fbc994ec738137 Mon Sep 17 00:00:00 2001
From: Adam Borowski <kilobyte(a)angband.pl>
Date: Sun, 4 Feb 2018 18:45:21 +0100
Subject: vsprintf: avoid misleading "(null)" for %px
From: Adam Borowski <kilobyte(a)angband.pl>
commit 3a129cc2151425e5aeb69aeb25fbc994ec738137 upstream.
Like %pK already does, print "00000000" instead.
This confused people -- the convention is that "(null)" means you tried to
dereference a null pointer as opposed to printing the address.
Link: http://lkml.kernel.org/r/20180204174521.21383-1-kilobyte@angband.pl
To: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
To: Steven Rostedt <rostedt(a)goodmis.org>
To: linux-kernel(a)vger.kernel.org
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Joe Perches <joe(a)perches.com>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: "Roberts, William C" <william.c.roberts(a)intel.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: David Laight <David.Laight(a)ACULAB.COM>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Geert Uytterhoeven <geert(a)linux-m68k.org>
Signed-off-by: Adam Borowski <kilobyte(a)angband.pl>
Signed-off-by: Petr Mladek <pmladek(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/vsprintf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1849,7 +1849,7 @@ char *pointer(const char *fmt, char *buf
{
const int default_width = 2 * sizeof(void *);
- if (!ptr && *fmt != 'K') {
+ if (!ptr && *fmt != 'K' && *fmt != 'x') {
/*
* Print (null) with the same width as a pointer so it makes
* tabular output look nice.
Patches currently in stable-queue which might be from kilobyte(a)angband.pl are
queue-4.15/vsprintf-avoid-misleading-null-for-px.patch
Hi,
Please include 3a129cc21514 ("vsprintf: avoid misleading "(null)" for
%px") in the 4.15 stable tree. That patch should have had these
fields:
Fixes: 668533dc0764 ("kallsyms: take advantage of the new '%px' format")
Cc: stable(a)vger.kernel.org
But I didn't notice when it went by originally. (Thanks to Steve for
pointing this out as being missed for 4.15.) :)
Thanks!
-Kees
--
Kees Cook
Pixel Security