* Re: [PATCH v2] acpi: fix acpi_get_table() leak / acpi-sysfs denial of service
From: Dan Williams @ 2017-05-24 19:01 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael Wysocki, Anush Seetharaman, Tiffany Kasanicky, Ryon Jensen,
Linux Kernel Mailing List, Stable, ACPI Devel Maling List,
Kristin Jacque, Zhang Rui
In-Reply-To: <CAPcyv4i_mRLSxm7YAnk_p8PhP=kyhT1aZZcrG-zZxXXWhGQuew@mail.gmail.com>
On Wed, Apr 26, 2017 at 3:37 PM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Wed, Apr 26, 2017 at 3:25 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> On Tue, Apr 25, 2017 at 9:58 PM, Dan Williams <dan.j.williams@intel.com> wrote:
>>> Reading an ACPI table through the /sys/firmware/acpi/tables interface
>>> more than 65,536 times leads to the following log message:
>>>
>>> ACPI Error: Table ffff88033595eaa8, Validation count is zero after increment
>>> (20170119/tbutils-423)
>>>
>>> ...and the table being unavailable until the next reboot. Add the
>>> missing acpi_put_table() so the table ->validation_count is decremented
>>> after each read.
>>>
>>> Cc: <stable@vger.kernel.org>
>>> Cc: Zhang Rui <rui.zhang@intel.com>
>>> Cc: Rafael Wysocki <rafael.j.wysocki@intel.com>
>>> Cc: Kristin Jacque <kristin.jacque@intel.com>
>>> Cc: Tiffany Kasanicky <tiffany.j.kasanicky@intel.com>
>>> Cc: Ryon Jensen <ryon.jensen@intel.com>
>>> Reported-by: Anush Seetharaman <anush.seetharaman@intel.com>
>>> Fixes: 1c8fce27e275 ("ACPI: introduce drivers/acpi/sysfs.c")
>>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>>
>> I'm going to apply this, but your Fixes tag is not correct.
>>
>> validation_count was added to struct acpi_table_desc by commit
>>
>> commit 174cc7187e6f088942c8e74daa7baff7b44b33c9
>> Author: Lv Zheng <lv.zheng@intel.com>
>> Date: Wed Dec 14 15:04:25 2016 +0800
>>
>> ACPICA: Tables: Back port acpi_get_table_with_size() and
>> early_acpi_os_unmap_memory()
>> from Linux kernel
>>
>> from the 4.10 time frame, so IMO it should be
>>
>> Fixes: 174cc7187e6f (ACPICA: Tables: Back port
>> acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux
>> kernel)
>>
>
> Ah, thanks for the catch, I missed that detail and was wrong to argue
> it was a 7 year old bug. Apologies Lv!
Hi Rafael, I don't see this in latest Linus master or queued in your
bleeding-edge branch.
^ permalink raw reply
* Re: [PATCH] clk: sunxi-ng: sun5i: Fix ahb_bist_clk definition
From: Angus Ainslie @ 2017-05-24 18:51 UTC (permalink / raw)
To: Boris Brezillon
Cc: Maxime Ripard, Chen-Yu Tsai, Mike Turquette, Stephen Boyd,
linux-clk, linux-arm-kernel, stable
In-Reply-To: <1495643669-28221-1-git-send-email-boris.brezillon@free-electrons.com>
On 2017-05-24 10:34, Boris Brezillon wrote:
> AHB BIST gate is actually controlled with bit 7.
>
> This bug was detected while trying to use the NAND controller which is
> using the DMA engine to transfer data to the NAND.
> Since the ahb_bist_clk gate bit conflicts with the ahb_dma_clk gate
> bit,
> the core was disabling the DMA engine clock as part of its 'disable
> unused clks' procedure, which was causing all DMA transfers to fail
> after
> this point.
>
> Fixes: 5e73761786d6 ("clk: sunxi-ng: Add sun5i CCU driver")
> Cc: stable@vger.kernel.org
> Reported-by: Angus Ainslie <angus@akkea.ca>compatible =
> "nextthing,chip-pro", "nextthing,gr8";
> Signed-off-by: Boris Brezillon <boris.brezillon@frecompatible =
> "nextthing,chip-pro", "nextthing,gr8";e-electrons.com>
> ---
> drivers/clk/sunxi-ng/ccu-sun5i.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun5i.c
> b/drivers/clk/sunxi-ng/ccu-sun5i.c
> index 5c476f966a72..5372bf8be5e6 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun5i.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun5i.c
> @@ -243,7 +243,7 @@ static SUNXI_CCU_GATE(ahb_ss_clk, "ahb-ss", "ahb",
> static SUNXI_CCU_GATE(ahb_dma_clk, "ahb-dma", "ahb",
> 0x060, BIT(6), 0);
> static SUNXI_CCU_GATE(ahb_bist_clk, "ahb-bist", "ahb",
> - 0x060, BIT(6), 0);
> + 0x060, BIT(7), 0);
> static SUNXI_CCU_GATE(ahb_mmc0_clk, "ahb-mmc0", "ahb",
> 0x060, BIT(8), 0);
> static SUNXI_CCU_GATE(ahb_mmc1_clk, "ahb-mmc1", "ahb",
The patch works perfectly. Using that I was able to remove the
clk_ignore_unsed and CLK_IS_CRITICAL.
^ permalink raw reply
* Re: [PATCH] drm/radeon: Unbreak HPD handling for r600+
From: Alex Deucher @ 2017-05-24 18:31 UTC (permalink / raw)
To: Christian König
Cc: Lyude, amd-gfx list, Alex Deucher, David Airlie,
Maling list - DRI developers, for 3.8, LKML
In-Reply-To: <70de5a62-1afa-b13b-d0d1-c3415ddbc788@amd.com>
On Fri, May 12, 2017 at 2:56 AM, Christian König
<christian.koenig@amd.com> wrote:
> Am 12.05.2017 um 01:31 schrieb Lyude:
>>
>> We end up reading the interrupt register for HPD5, and then writing it
>> to HPD6 which on systems without anything using HPD5 results in
>> permanently disabling hotplug on one of the display outputs after the
>> first time we acknowledge a hotplug interrupt from the GPU.
>>
>> This code is really bad. But for now, let's just fix this. I will
>> hopefully have a large patch series to refactor all of this soon.
>>
>> Signed-off-by: Lyude <lyude@redhat.com>
>> Cc: stable@vger.kernel.org
>
>
> Really nice catch! And yes I agree the copy&pasted code in HPD handling
> always scared me as well.
>
> Patch is Reviewed-by: Christian König <christian.koenig@amd.com>.
Applied. thanks!
Alex
>
> Christian.
>
>
>> ---
>> drivers/gpu/drm/radeon/cik.c | 4 ++--
>> drivers/gpu/drm/radeon/evergreen.c | 4 ++--
>> drivers/gpu/drm/radeon/r600.c | 2 +-
>> drivers/gpu/drm/radeon/si.c | 4 ++--
>> 4 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
>> index 53710dd..cfc917c 100644
>> --- a/drivers/gpu/drm/radeon/cik.c
>> +++ b/drivers/gpu/drm/radeon/cik.c
>> @@ -7401,7 +7401,7 @@ static inline void cik_irq_ack(struct radeon_device
>> *rdev)
>> WREG32(DC_HPD5_INT_CONTROL, tmp);
>> }
>> if (rdev->irq.stat_regs.cik.disp_int_cont5 & DC_HPD6_INTERRUPT) {
>> - tmp = RREG32(DC_HPD5_INT_CONTROL);
>> + tmp = RREG32(DC_HPD6_INT_CONTROL);
>> tmp |= DC_HPDx_INT_ACK;
>> WREG32(DC_HPD6_INT_CONTROL, tmp);
>> }
>> @@ -7431,7 +7431,7 @@ static inline void cik_irq_ack(struct radeon_device
>> *rdev)
>> WREG32(DC_HPD5_INT_CONTROL, tmp);
>> }
>> if (rdev->irq.stat_regs.cik.disp_int_cont5 & DC_HPD6_RX_INTERRUPT)
>> {
>> - tmp = RREG32(DC_HPD5_INT_CONTROL);
>> + tmp = RREG32(DC_HPD6_INT_CONTROL);
>> tmp |= DC_HPDx_RX_INT_ACK;
>> WREG32(DC_HPD6_INT_CONTROL, tmp);
>> }
>> diff --git a/drivers/gpu/drm/radeon/evergreen.c
>> b/drivers/gpu/drm/radeon/evergreen.c
>> index d1b1e0c..c48d19e 100644
>> --- a/drivers/gpu/drm/radeon/evergreen.c
>> +++ b/drivers/gpu/drm/radeon/evergreen.c
>> @@ -4933,7 +4933,7 @@ static void evergreen_irq_ack(struct radeon_device
>> *rdev)
>> WREG32(DC_HPD5_INT_CONTROL, tmp);
>> }
>> if (rdev->irq.stat_regs.evergreen.disp_int_cont5 &
>> DC_HPD6_INTERRUPT) {
>> - tmp = RREG32(DC_HPD5_INT_CONTROL);
>> + tmp = RREG32(DC_HPD6_INT_CONTROL);
>> tmp |= DC_HPDx_INT_ACK;
>> WREG32(DC_HPD6_INT_CONTROL, tmp);
>> }
>> @@ -4964,7 +4964,7 @@ static void evergreen_irq_ack(struct radeon_device
>> *rdev)
>> WREG32(DC_HPD5_INT_CONTROL, tmp);
>> }
>> if (rdev->irq.stat_regs.evergreen.disp_int_cont5 &
>> DC_HPD6_RX_INTERRUPT) {
>> - tmp = RREG32(DC_HPD5_INT_CONTROL);
>> + tmp = RREG32(DC_HPD6_INT_CONTROL);
>> tmp |= DC_HPDx_RX_INT_ACK;
>> WREG32(DC_HPD6_INT_CONTROL, tmp);
>> }
>> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
>> index 0a08517..e06e2d8 100644
>> --- a/drivers/gpu/drm/radeon/r600.c
>> +++ b/drivers/gpu/drm/radeon/r600.c
>> @@ -3988,7 +3988,7 @@ static void r600_irq_ack(struct radeon_device *rdev)
>> WREG32(DC_HPD5_INT_CONTROL, tmp);
>> }
>> if (rdev->irq.stat_regs.r600.disp_int_cont2 &
>> DC_HPD6_INTERRUPT) {
>> - tmp = RREG32(DC_HPD5_INT_CONTROL);
>> + tmp = RREG32(DC_HPD6_INT_CONTROL);
>> tmp |= DC_HPDx_INT_ACK;
>> WREG32(DC_HPD6_INT_CONTROL, tmp);
>> }
>> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
>> index 528e5a4..bfeb774 100644
>> --- a/drivers/gpu/drm/radeon/si.c
>> +++ b/drivers/gpu/drm/radeon/si.c
>> @@ -6330,7 +6330,7 @@ static inline void si_irq_ack(struct radeon_device
>> *rdev)
>> WREG32(DC_HPD5_INT_CONTROL, tmp);
>> }
>> if (rdev->irq.stat_regs.evergreen.disp_int_cont5 &
>> DC_HPD6_INTERRUPT) {
>> - tmp = RREG32(DC_HPD5_INT_CONTROL);
>> + tmp = RREG32(DC_HPD6_INT_CONTROL);
>> tmp |= DC_HPDx_INT_ACK;
>> WREG32(DC_HPD6_INT_CONTROL, tmp);
>> }
>> @@ -6361,7 +6361,7 @@ static inline void si_irq_ack(struct radeon_device
>> *rdev)
>> WREG32(DC_HPD5_INT_CONTROL, tmp);
>> }
>> if (rdev->irq.stat_regs.evergreen.disp_int_cont5 &
>> DC_HPD6_RX_INTERRUPT) {
>> - tmp = RREG32(DC_HPD5_INT_CONTROL);
>> + tmp = RREG32(DC_HPD6_INT_CONTROL);
>> tmp |= DC_HPDx_RX_INT_ACK;
>> WREG32(DC_HPD6_INT_CONTROL, tmp);
>> }
>
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Applied "ASoC: Fix use-after-free at card unregistration" to the asoc tree
From: Mark Brown @ 2017-05-24 17:42 UTC (permalink / raw)
To: Takashi Iwai
Cc: Mark Brown, stable, Mark Brown, alsa-devel, Robert Jarzmik,
alsa-devel
In-Reply-To: <20170524081945.29116-1-tiwai@suse.de>
The patch
ASoC: Fix use-after-free at card unregistration
has been applied to the asoc tree at
git://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 4efda5f2130da033aeedc5b3205569893b910de2 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai@suse.de>
Date: Wed, 24 May 2017 10:19:45 +0200
Subject: [PATCH] ASoC: Fix use-after-free at card unregistration
soc_cleanup_card_resources() call snd_card_free() at the last of its
procedure. This turned out to lead to a use-after-free.
PCM runtimes have been already removed via soc_remove_pcm_runtimes(),
while it's dereferenced later in soc_pcm_free() called via
snd_card_free().
The fix is simple: just move the snd_card_free() call to the beginning
of the whole procedure. This also gives another benefit: it
guarantees that all operations have been shut down before actually
releasing the resources, which was racy until now.
Reported-and-tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
---
sound/soc/soc-core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index aae099c0e502..754e3ef8d7ae 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -2286,6 +2286,9 @@ static int soc_cleanup_card_resources(struct snd_soc_card *card)
list_for_each_entry(rtd, &card->rtd_list, list)
flush_delayed_work(&rtd->delayed_work);
+ /* free the ALSA card at first; this syncs with pending operations */
+ snd_card_free(card->snd_card);
+
/* remove and free each DAI */
soc_remove_dai_links(card);
soc_remove_pcm_runtimes(card);
@@ -2300,9 +2303,7 @@ static int soc_cleanup_card_resources(struct snd_soc_card *card)
if (card->remove)
card->remove(card);
- snd_card_free(card->snd_card);
return 0;
-
}
/* removes a socdev */
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 4.11 000/197] 4.11.3-stable review
From: Guenter Roeck @ 2017-05-24 16:50 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
stable
In-Reply-To: <20170523200821.666872592@linuxfoundation.org>
On Tue, May 23, 2017 at 10:06:01PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.11.3 release.
> There are 197 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu May 25 20:07:44 UTC 2017.
> Anything received after that time might be too late.
>
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 122 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply
* [PATCH] clk: sunxi-ng: sun5i: Fix ahb_bist_clk definition
From: Boris Brezillon @ 2017-05-24 16:34 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Mike Turquette, Stephen Boyd,
linux-clk
Cc: linux-arm-kernel, Angus Ainslie, Boris Brezillon, stable
AHB BIST gate is actually controlled with bit 7.
This bug was detected while trying to use the NAND controller which is
using the DMA engine to transfer data to the NAND.
Since the ahb_bist_clk gate bit conflicts with the ahb_dma_clk gate bit,
the core was disabling the DMA engine clock as part of its 'disable
unused clks' procedure, which was causing all DMA transfers to fail after
this point.
Fixes: 5e73761786d6 ("clk: sunxi-ng: Add sun5i CCU driver")
Cc: stable@vger.kernel.org
Reported-by: Angus Ainslie <angus@akkea.ca>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
drivers/clk/sunxi-ng/ccu-sun5i.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun5i.c b/drivers/clk/sunxi-ng/ccu-sun5i.c
index 5c476f966a72..5372bf8be5e6 100644
--- a/drivers/clk/sunxi-ng/ccu-sun5i.c
+++ b/drivers/clk/sunxi-ng/ccu-sun5i.c
@@ -243,7 +243,7 @@ static SUNXI_CCU_GATE(ahb_ss_clk, "ahb-ss", "ahb",
static SUNXI_CCU_GATE(ahb_dma_clk, "ahb-dma", "ahb",
0x060, BIT(6), 0);
static SUNXI_CCU_GATE(ahb_bist_clk, "ahb-bist", "ahb",
- 0x060, BIT(6), 0);
+ 0x060, BIT(7), 0);
static SUNXI_CCU_GATE(ahb_mmc0_clk, "ahb-mmc0", "ahb",
0x060, BIT(8), 0);
static SUNXI_CCU_GATE(ahb_mmc1_clk, "ahb-mmc1", "ahb",
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 3.18 00/59] 3.18.55-stable review
From: Guenter Roeck @ 2017-05-24 15:45 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
stable
In-Reply-To: <20170523200849.241966497@linuxfoundation.org>
On Tue, May 23, 2017 at 10:09:28PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.55 release.
> There are 59 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu May 25 20:08:28 UTC 2017.
> Anything received after that time might be too late.
>
Build results:
total: 136 pass: 136 fail: 0
Qemu test results:
total: 111 pass: 111 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply
* Re: [PATCH 09/31] block: Avoid that blk_exit_rl() triggers a use-after-free
From: Tejun Heo @ 2017-05-24 15:09 UTC (permalink / raw)
To: Bart Van Assche
Cc: Martin K . Petersen, James Bottomley, linux-scsi, linux-block,
Jens Axboe, Christoph Hellwig, Jan Kara, Hannes Reinecke, stable
In-Reply-To: <20170524003420.5381-10-bart.vanassche@sandisk.com>
On Tue, May 23, 2017 at 05:33:58PM -0700, Bart Van Assche wrote:
> Since the introduction of the .init_rq_fn() and .exit_rq_fn() it
> is essential that the memory allocated for struct request_queue
> stays around until all blk_exit_rl() calls have finished. Hence
> make blk_init_rl() take a reference on struct request_queue.
>
> This patch fixes the following crash:
>
> general protection fault: 0000 [#2] SMP
> CPU: 3 PID: 28 Comm: ksoftirqd/3 Tainted: G D 4.12.0-rc2-dbg+ #2
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
> task: ffff88013a108040 task.stack: ffffc9000071c000
> RIP: 0010:free_request_size+0x1a/0x30
> RSP: 0018:ffffc9000071fd38 EFLAGS: 00010202
> RAX: 6b6b6b6b6b6b6b6b RBX: ffff880067362a88 RCX: 0000000000000003
> RDX: ffff880067464178 RSI: ffff880067362a88 RDI: ffff880135ea4418
> RBP: ffffc9000071fd40 R08: 0000000000000000 R09: 0000000100180009
> R10: ffffc9000071fd38 R11: ffffffff81110800 R12: ffff88006752d3d8
> R13: ffff88006752d3d8 R14: ffff88013a108040 R15: 000000000000000a
> FS: 0000000000000000(0000) GS:ffff88013fd80000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fa8ec1edb00 CR3: 0000000138ee8000 CR4: 00000000001406e0
> Call Trace:
> mempool_destroy.part.10+0x21/0x40
> mempool_destroy+0xe/0x10
> blk_exit_rl+0x12/0x20
> blkg_free+0x4d/0xa0
> __blkg_release_rcu+0x59/0x170
> rcu_process_callbacks+0x260/0x4e0
> __do_softirq+0x116/0x250
> smpboot_thread_fn+0x123/0x1e0
> kthread+0x109/0x140
> ret_from_fork+0x31/0x40
>
> Fixes: commit e9c787e65c0c ("scsi: allocate scsi_cmnd structures as part of struct request")
> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
> Cc: Jens Axboe <axboe@fb.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Hannes Reinecke <hare@suse.com>
> Cc: <stable@vger.kernel.org> # v4.11+
Acked-by: Tejun Heo <tj@kernel.org>
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
From: Mark Brown @ 2017-05-24 15:08 UTC (permalink / raw)
To: Guenter Roeck
Cc: Greg Kroah-Hartman, kernelci.org bot, linux-kernel, torvalds,
akpm, shuahkh, patches, ben.hutchings, stable
In-Reply-To: <14a9e17b-40a3-c0c6-549d-60d10a6c876a@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
On Wed, May 24, 2017 at 06:18:00AM -0700, Guenter Roeck wrote:
> On 05/24/2017 05:58 AM, Mark Brown wrote:
> > which seem to have managed to boot somehow. It's a minnowboard with no
> > video and it's booting to a ramdisk, I don't know if either of those
> > helped avoid the issue.
> Either that or it is related to the kernel configuration (which, in my case,
> was picked from an old yocto version).
Yeah, kernelci is using upstream defconfigs plus a couple of defconfig+X
things. What's the config you're using, perhaps there's some options
that we ought to be adding somewhere for coverage?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] [stable 3.18] fix __unflatten_device_tree warning
From: Greg KH @ 2017-05-24 15:07 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: stable
In-Reply-To: <20170524143001.1678102-1-arnd@arndb.de>
On Wed, May 24, 2017 at 04:30:01PM +0200, Arnd Bergmann wrote:
> A backported patch needs to be modified for a context change
>
> drivers/of/fdt.c:384:10: warning: 'return' with a value, in function returning void
>
> Fixes: 0aa459efa045 ("of: fdt: add missing allocation-failure check")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/of/fdt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index e706bced9b6b..74c7aba476f6 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -381,7 +381,7 @@ static void __unflatten_device_tree(void *blob,
> /* Allocate memory for the expanded device tree */
> mem = dt_alloc(size + 4, __alignof__(struct device_node));
> if (!mem)
> - return NULL;
> + return;
>
> memset(mem, 0, size);
>
Ah, this is still in a patch that I have not released yet, nice! I've
now flattened this with the original one, many thanks for it.
greg k-h
^ permalink raw reply
* Re: [PATCH 3.18 34/59] tty: Prevent ldisc drivers from re-using stale tty fields
From: Greg Kroah-Hartman @ 2017-05-24 15:03 UTC (permalink / raw)
To: Alan Cox
Cc: linux-kernel, stable, Tilman Schmidt, Sasha Levin, Peter Hurley,
Amit Pundir
In-Reply-To: <20170524144433.28ddf836@alans-desktop>
On Wed, May 24, 2017 at 02:44:33PM +0100, Alan Cox wrote:
> On Tue, 23 May 2017 22:10:02 +0200
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> > 3.18-stable review patch. If anyone has any objections, please let me know.
> >
>
> Thiis is a patch designed to cause a crash in order to stop future errors
> occurring. It seems less than ideal as a stable candidate.
It has been in the 4.4-stable tree since 4.4.34, which was released last
November, and now it seems the Google "security" team thought it was
worthwhile to backport to 3.18 for their Android devices as well. So
I'll take it, it can't hurt, and crashing is usually better than odd
errors.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] [stable 3.18] fix __unflatten_device_tree warning
From: Arnd Bergmann @ 2017-05-24 14:30 UTC (permalink / raw)
To: gregkh; +Cc: stable, Arnd Bergmann
A backported patch needs to be modified for a context change
drivers/of/fdt.c:384:10: warning: 'return' with a value, in function returning void
Fixes: 0aa459efa045 ("of: fdt: add missing allocation-failure check")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/of/fdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index e706bced9b6b..74c7aba476f6 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -381,7 +381,7 @@ static void __unflatten_device_tree(void *blob,
/* Allocate memory for the expanded device tree */
mem = dt_alloc(size + 4, __alignof__(struct device_node));
if (!mem)
- return NULL;
+ return;
memset(mem, 0, size);
--
2.9.0
^ permalink raw reply related
* Re: [PATCH 3.18 34/59] tty: Prevent ldisc drivers from re-using stale tty fields
From: Alan Cox @ 2017-05-24 13:44 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Tilman Schmidt, Sasha Levin, Peter Hurley,
Amit Pundir
In-Reply-To: <20170523200851.752940269@linuxfoundation.org>
On Tue, 23 May 2017 22:10:02 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 3.18-stable review patch. If anyone has any objections, please let me know.
>
Thiis is a patch designed to cause a crash in order to stop future errors
occurring. It seems less than ideal as a stable candidate.
> ------------------
>
> From: Peter Hurley <peter@hurleysoftware.com>
>
> commit dd42bf1197144ede075a9d4793123f7689e164bc upstream.
>
> Line discipline drivers may mistakenly misuse ldisc-related fields
> when initializing. For example, a failure to initialize tty->receive_room
> in the N_GIGASET_M101 line discipline was recently found and fixed [1].
> Now, the N_X25 line discipline has been discovered accessing the previous
> line discipline's already-freed private data [2].
>
> Harden the ldisc interface against misuse by initializing revelant
> tty fields before instancing the new line discipline.
>
> [1]
> commit fd98e9419d8d622a4de91f76b306af6aa627aa9c
> Author: Tilman Schmidt <tilman@imap.cc>
> Date: Tue Jul 14 00:37:13 2015 +0200
>
> isdn/gigaset: reset tty->receive_room when attaching ser_gigaset
>
> [2] Report from Sasha Levin <sasha.levin@oracle.com>
> [ 634.336761] ==================================================================
> [ 634.338226] BUG: KASAN: use-after-free in x25_asy_open_tty+0x13d/0x490 at addr ffff8800a743efd0
> [ 634.339558] Read of size 4 by task syzkaller_execu/8981
> [ 634.340359] =============================================================================
> [ 634.341598] BUG kmalloc-512 (Not tainted): kasan: bad access detected
> ...
> [ 634.405018] Call Trace:
> [ 634.405277] dump_stack (lib/dump_stack.c:52)
> [ 634.405775] print_trailer (mm/slub.c:655)
> [ 634.406361] object_err (mm/slub.c:662)
> [ 634.406824] kasan_report_error (mm/kasan/report.c:138 mm/kasan/report.c:236)
> [ 634.409581] __asan_report_load4_noabort (mm/kasan/report.c:279)
> [ 634.411355] x25_asy_open_tty (drivers/net/wan/x25_asy.c:559 (discriminator 1))
> [ 634.413997] tty_ldisc_open.isra.2 (drivers/tty/tty_ldisc.c:447)
> [ 634.414549] tty_set_ldisc (drivers/tty/tty_ldisc.c:567)
> [ 634.415057] tty_ioctl (drivers/tty/tty_io.c:2646 drivers/tty/tty_io.c:2879)
> [ 634.423524] do_vfs_ioctl (fs/ioctl.c:43 fs/ioctl.c:607)
> [ 634.427491] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613)
> [ 634.427945] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:188)
>
> Cc: Tilman Schmidt <tilman@imap.cc>
> Cc: Sasha Levin <sasha.levin@oracle.com>
> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
> drivers/tty/tty_ldisc.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> --- a/drivers/tty/tty_ldisc.c
> +++ b/drivers/tty/tty_ldisc.c
> @@ -414,6 +414,10 @@ EXPORT_SYMBOL_GPL(tty_ldisc_flush);
> * they are not on hot paths so a little discipline won't do
> * any harm.
> *
> + * The line discipline-related tty_struct fields are reset to
> + * prevent the ldisc driver from re-using stale information for
> + * the new ldisc instance.
> + *
> * Locking: takes termios_rwsem
> */
>
> @@ -422,6 +426,9 @@ static void tty_set_termios_ldisc(struct
> down_write(&tty->termios_rwsem);
> tty->termios.c_line = num;
> up_write(&tty->termios_rwsem);
> +
> + tty->disc_data = NULL;
> + tty->receive_room = 0;
> }
>
> /**
>
^ permalink raw reply
* Re: wlcore: fix 64K page support
From: Kalle Valo @ 2017-05-24 13:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, stable, Reizer, Eyal, Tony Lindgren, Wei Yongjun,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20170511115307.3060650-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> In the stable linux-3.16 branch, I ran into a warning in the
> wlcore driver:
>
> drivers/net/wireless/ti/wlcore/spi.c: In function 'wl12xx_spi_raw_write':
> drivers/net/wireless/ti/wlcore/spi.c:315:1: error: the frame size of 12848 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
>
> Newer kernels no longer show the warning, but the bug is still there,
> as the allocation is based on the CPU page size rather than the
> actual capabilities of the hardware.
>
> This replaces the PAGE_SIZE macro with the SZ_4K macro, i.e. 4096 bytes
> per buffer.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied to wireless-drivers-next.git, thanks.
4a4274bf2dbb wlcore: fix 64K page support
--
https://patchwork.kernel.org/patch/9721269/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
From: Guenter Roeck @ 2017-05-24 13:33 UTC (permalink / raw)
To: Mark Brown
Cc: Greg Kroah-Hartman, kernelci.org bot, linux-kernel, torvalds,
akpm, shuahkh, patches, ben.hutchings, stable
In-Reply-To: <20170524125840.x2vp4ejwrlvehule@sirena.org.uk>
On 05/24/2017 05:58 AM, Mark Brown wrote:
> On Wed, May 24, 2017 at 05:47:13AM -0700, Guenter Roeck wrote:
>> On 05/24/2017 12:03 AM, Greg Kroah-Hartman wrote:
>
>>> 54 passed? I had a bug here such that all x86 builds were crashing, in
>>> the core tty layer, which seems odd that anything would be able to boot
>>> with this tree...
>
>> Final qemu test result was
>> total: 115 pass: 89 fail: 26
>> with only the x86 and x86_64 images crashing, so this isn't entirely surprising,
>> assuming kernelci does not (yet) run any x86/x86_64 qemu tests.
>
> Not qemu but it has some physical x86 tests like:
>
> https://storage.kernelci.org/stable-rc/linux-4.4.y/v4.4.69-104-g2ebff3b7590b/x86/x86_64_defconfig/lab-collabora/boot-minnowboard-max.html
>
> which seem to have managed to boot somehow. It's a minnowboard with no
> video and it's booting to a ramdisk, I don't know if either of those
> helped avoid the issue.
>
I had another look; it may be related to the configuration. Turns out
I also had crashes in some mips64 and ppc/ppc64 tests, but not all of
them. For example, mips64 big endian crashed, but the same configuration
little endian passed.
I think I'll add some config file variations to my x86 tests.
Guenter
^ permalink raw reply
* Re: [PATCH 0/2] nohz: Deal with clock reprogram skipping issues v3
From: Frederic Weisbecker @ 2017-05-24 13:28 UTC (permalink / raw)
To: Ingo Molnar
Cc: LKML, Peter Zijlstra, Rik van Riel, James Hartsock,
Thomas Gleixner, stable, Tim Wright, Pavel Machek
In-Reply-To: <20170524071628.ftwjuh27jpdo6qkm@gmail.com>
On Wed, May 24, 2017 at 09:16:28AM +0200, Ingo Molnar wrote:
>
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
>
> > On Tue, May 23, 2017 at 09:25:08AM +0200, Ingo Molnar wrote:
> > >
> > > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > >
> > > > v2 had issues on -tip tree and triggered a warning. It seems to have
> > > > disappeared. Perhaps it was due to another timer issue. Anyway this
> > > > version brings more debugging informations, with a layout that is more
> > > > bisection-friendly and it also handles ticks that fire outside IRQ
> > > > context and thus carry NULL irq regs. This happen when
> > > > hrtimer_interrupt() is called on hotplug cpu down for example.
> > > >
> > > > We'll see if the issue arises again.
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> > > > nohz/fixes
> > > >
> > > > HEAD: cd15f46b284f04dbedd065a9d99a4e0badae379a
> > > >
> > > > Thanks,
> > > > Frederic
> > > > ---
> > > >
> > > > Frederic Weisbecker (2):
> > > > nohz: Add hrtimer sanity check
> > > > nohz: Fix collision between tick and other hrtimers, again
> > > >
> > > >
> > > > kernel/time/tick-sched.c | 48 +++++++++++++++++++++++++++++++++++++++++++-----
> > > > kernel/time/tick-sched.h | 2 ++
> > > > 2 files changed, 45 insertions(+), 5 deletions(-)
> > >
> > > So I think the 3 commits queued up right now:
> > >
> > > 99fa871820cf: nohz: Reset next_tick cache even when the timer has no regs
> > > 411fe24e6b7c: nohz: Fix collision between tick and other hrtimers, again
> > > ce6cf9a15d62: nohz: Add hrtimer sanity check
> > >
> > > are OK and I'd not rebase them unless there's some breakage.
> > >
> > > One thing I noticed: your second series does appear to have:
> > >
> > > 99fa871820cf: nohz: Reset next_tick cache even when the timer has no regs
> > >
> > > is that intentional? That is pretty much the only commit I'd love to rebase with a
> > > proper description added.
> >
> > Yes in my latest series I melted "nohz: Reset next_tick cache even when the timer has no regs"
> > into "nohz: Fix collision between tick and other hrtimers, again" because it's a fixup and
> > keeping that patch separate may break bisection.
> >
> > So ideally, it would be nice if you could fixup 411fe24e6b7c with 99fa871820cf. That's roughly
> > all I did in my latest series.
>
> So the interdiff between your two patches and the 3 commits already queued up is:
>
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index e3043873fcdc..30253ed0380b 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -150,12 +150,6 @@ static void tick_sched_handle(struct tick_sched *ts, struct pt_regs *regs)
> touch_softlockup_watchdog_sched();
> if (is_idle_task(current))
> ts->idle_jiffies++;
> - /*
> - * In case the current tick fired too early past its expected
> - * expiration, make sure we don't bypass the next clock reprogramming
> - * to the same deadline.
> - */
> - ts->next_tick = 0;
> }
> #endif
> update_process_times(user_mode(regs));
> @@ -1103,8 +1097,15 @@ static void tick_nohz_handler(struct clock_event_device *dev)
> tick_sched_handle(ts, regs);
>
> /* No need to reprogram if we are running tickless */
> - if (unlikely(ts->tick_stopped))
> + if (unlikely(ts->tick_stopped)) {
> + /*
> + * In case the current tick fired too early past its expected
> + * expiration, make sure we don't bypass the next clock reprogramming
> + * to the same deadline.
> + */
> + ts->next_tick = 0;
> return;
> + }
>
> hrtimer_forward(&ts->sched_timer, now, tick_period);
> tick_program_event(hrtimer_get_expires(&ts->sched_timer), 1);
> @@ -1202,12 +1203,17 @@ static enum hrtimer_restart tick_sched_timer(struct hrtimer *timer)
> */
> if (regs)
> tick_sched_handle(ts, regs);
> - else
> - ts->next_tick = 0;
>
> /* No need to reprogram if we are in idle or full dynticks mode */
> - if (unlikely(ts->tick_stopped))
> + if (unlikely(ts->tick_stopped)) {
> + /*
> + * In case the current tick fired too early past its expected
> + * expiration, make sure we don't bypass the next clock reprogramming
> + * to the same deadline.
> + */
> + ts->next_tick = 0;
> return HRTIMER_NORESTART;
> + }
>
> hrtimer_forward(timer, now, tick_period);
>
>
> ... so the two are not the same - I'd rather not rebase it, I'd like to keep what
> is working, we had problems with these changes before ...
>
> If you'd like the changes in this interdiff to be applied as well, please add a
> changelog to it and post it as a fourth patch.
After all, things are ok as they are. The difference is (at least intended to be) cosmetic
and I'm not sure it's even better with the new version of the patches.
What can I do for the changelog of the top patch in your current branch? Should I repost
the patch with a changelog? I may need to add a comment as well on the code. In the end you'll
need to only rebase that one and the code diff will only be an added comment. How does that sound?
Thanks.
>
> Thanks,
>
> Ingo
^ permalink raw reply
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
From: Guenter Roeck @ 2017-05-24 13:18 UTC (permalink / raw)
To: Mark Brown
Cc: Greg Kroah-Hartman, kernelci.org bot, linux-kernel, torvalds,
akpm, shuahkh, patches, ben.hutchings, stable
In-Reply-To: <20170524125840.x2vp4ejwrlvehule@sirena.org.uk>
On 05/24/2017 05:58 AM, Mark Brown wrote:
> On Wed, May 24, 2017 at 05:47:13AM -0700, Guenter Roeck wrote:
>> On 05/24/2017 12:03 AM, Greg Kroah-Hartman wrote:
>
>>> 54 passed? I had a bug here such that all x86 builds were crashing, in
>>> the core tty layer, which seems odd that anything would be able to boot
>>> with this tree...
>
>> Final qemu test result was
>> total: 115 pass: 89 fail: 26
>> with only the x86 and x86_64 images crashing, so this isn't entirely surprising,
>> assuming kernelci does not (yet) run any x86/x86_64 qemu tests.
>
> Not qemu but it has some physical x86 tests like:
>
> https://storage.kernelci.org/stable-rc/linux-4.4.y/v4.4.69-104-g2ebff3b7590b/x86/x86_64_defconfig/lab-collabora/boot-minnowboard-max.html
>
> which seem to have managed to boot somehow. It's a minnowboard with no
> video and it's booting to a ramdisk, I don't know if either of those
> helped avoid the issue.
>
Either that or it is related to the kernel configuration (which, in my case,
was picked from an old yocto version).
Guenter
^ permalink raw reply
* [PATCH v4 9/9] arm64: hugetlb: Cleanup setup_hugepagesz
From: Punit Agrawal @ 2017-05-24 13:11 UTC (permalink / raw)
To: will.deacon, catalin.marinas
Cc: Steve Capper, linux-arm-kernel, mark.rutland, linux-mm,
David Woods, stable, Punit Agrawal
In-Reply-To: <20170524131122.5309-1-punit.agrawal@arm.com>
From: Steve Capper <steve.capper@arm.com>
Replace a lot of if statements with switch and case labels to make it
much clearer which huge page sizes are supported.
Also, we prevent PUD_SIZE from being used on systems not running with
4KB PAGE_SIZE. Before if one supplied PUD_SIZE in these circumstances,
then unusuable huge page sizes would be in use.
Fixes: 084bd29810a5 ("ARM64: mm: HugeTLB support.")
Cc: David Woods <dwoods@mellanox.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Steve Capper <steve.capper@arm.com>
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
---
arch/arm64/mm/hugetlbpage.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index a10dfbd0ffd5..b5dc7cca3f45 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -381,20 +381,20 @@ static __init int setup_hugepagesz(char *opt)
{
unsigned long ps = memparse(opt, &opt);
- if (ps == PMD_SIZE) {
- hugetlb_add_hstate(PMD_SHIFT - PAGE_SHIFT);
- } else if (ps == PUD_SIZE) {
- hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
- } else if (ps == (PAGE_SIZE * CONT_PTES)) {
- hugetlb_add_hstate(CONT_PTE_SHIFT);
- } else if (ps == (PMD_SIZE * CONT_PMDS)) {
- hugetlb_add_hstate((PMD_SHIFT + CONT_PMD_SHIFT) - PAGE_SHIFT);
- } else {
- hugetlb_bad_size();
- pr_err("hugepagesz: Unsupported page size %lu K\n", ps >> 10);
- return 0;
+ switch (ps) {
+#ifdef CONFIG_ARM64_4K_PAGES
+ case PUD_SIZE:
+#endif
+ case PMD_SIZE * CONT_PMDS:
+ case PMD_SIZE:
+ case PAGE_SIZE * CONT_PTES:
+ hugetlb_add_hstate(ilog2(ps) - PAGE_SHIFT);
+ return 1;
}
- return 1;
+
+ hugetlb_bad_size();
+ pr_err("hugepagesz: Unsupported page size %lu K\n", ps >> 10);
+ return 0;
}
__setup("hugepagesz=", setup_hugepagesz);
--
2.11.0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
From: Mark Brown @ 2017-05-24 12:58 UTC (permalink / raw)
To: Guenter Roeck
Cc: Greg Kroah-Hartman, kernelci.org bot, linux-kernel, torvalds,
akpm, shuahkh, patches, ben.hutchings, stable
In-Reply-To: <956482c6-4666-dee9-69d4-099d0755b6e4@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
On Wed, May 24, 2017 at 05:47:13AM -0700, Guenter Roeck wrote:
> On 05/24/2017 12:03 AM, Greg Kroah-Hartman wrote:
> > 54 passed? I had a bug here such that all x86 builds were crashing, in
> > the core tty layer, which seems odd that anything would be able to boot
> > with this tree...
> Final qemu test result was
> total: 115 pass: 89 fail: 26
> with only the x86 and x86_64 images crashing, so this isn't entirely surprising,
> assuming kernelci does not (yet) run any x86/x86_64 qemu tests.
Not qemu but it has some physical x86 tests like:
https://storage.kernelci.org/stable-rc/linux-4.4.y/v4.4.69-104-g2ebff3b7590b/x86/x86_64_defconfig/lab-collabora/boot-minnowboard-max.html
which seem to have managed to boot somehow. It's a minnowboard with no
video and it's booting to a ramdisk, I don't know if either of those
helped avoid the issue.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
From: Greg Kroah-Hartman @ 2017-05-24 12:53 UTC (permalink / raw)
To: Thomas Voegtle
Cc: kernelci.org bot, linux-kernel, torvalds, akpm, linux, shuahkh,
patches, ben.hutchings, stable
In-Reply-To: <alpine.LSU.2.20.1705241355570.14102@er-systems.de>
On Wed, May 24, 2017 at 02:04:32PM +0200, Thomas Voegtle wrote:
> On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
>
> > On Wed, May 24, 2017 at 11:26:25AM +0200, Thomas Voegtle wrote:
> > > On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
> > >
> > > > On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
> > > > > stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
> > > > >
> > > > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> > > > > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> > > > >
> > > > > Tree: stable-rc
> > > > > Branch: linux-4.4.y
> > > > > Git Describe: v4.4.69-104-g2ebff3b7590b
> > > > > Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
> > > > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > > > Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
> > > >
> > > > 54 passed? I had a bug here such that all x86 builds were crashing, in
> > > > the core tty layer, which seems odd that anything would be able to boot
> > > > with this tree...
> > > >
> > > > I've pushed out an update, can you all verify that it also works?
> > >
> > >
> > > I got this:
> > >
> > > CALL scripts/checksyscalls.sh
> > > CHK include/generated/compile.h
> > > CC kernel/fork.o
> > > kernel/fork.c: In function 'dup_task_struct':
> > > kernel/fork.c:371:2: error: implicit declaration of function
> > > 'get_random_long' [-Werror=implicit-function-declaration]
> > > cc1: some warnings being treated as errors
> > > make[1]: *** [kernel/fork.o] Error 1
> > > make: *** [kernel] Error 2
> > >
> > >
> > > This is stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
> >
> > What arch/.config are you building for that causes this?
>
>
> x86_64 and CONFIG_CC_STACKPROTECTOR=y
>
> The rest of my kernel config is SuSE's kernel-default config.
>
> get_random_long came with v4.5 as far as I know
>
> I have a running 4.4.70-rc1, Without that mentioned patch and using the
> latest rc patch.
You are right, this shouldn't have gone to the 4.4-stable tree, thanks
for catching it. I've now dropped it.
thanks again,
greg k-h
^ permalink raw reply
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
From: Guenter Roeck @ 2017-05-24 12:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, kernelci.org bot
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
stable
In-Reply-To: <20170524070353.GA5785@kroah.com>
On 05/24/2017 12:03 AM, Greg Kroah-Hartman wrote:
> On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
>> stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
>>
>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>>
>> Tree: stable-rc
>> Branch: linux-4.4.y
>> Git Describe: v4.4.69-104-g2ebff3b7590b
>> Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
>
> 54 passed? I had a bug here such that all x86 builds were crashing, in
> the core tty layer, which seems odd that anything would be able to boot
> with this tree...
>
Final qemu test result was
total: 115 pass: 89 fail: 26
with only the x86 and x86_64 images crashing, so this isn't entirely surprising,
assuming kernelci does not (yet) run any x86/x86_64 qemu tests.
Guenter
^ permalink raw reply
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
From: Thomas Voegtle @ 2017-05-24 12:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Thomas Voegtle, kernelci.org bot, linux-kernel, torvalds, akpm,
linux, shuahkh, patches, ben.hutchings, stable
In-Reply-To: <20170524113531.GA9460@kroah.com>
On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
> On Wed, May 24, 2017 at 11:26:25AM +0200, Thomas Voegtle wrote:
>> On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
>>
>>> On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
>>>> stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
>>>>
>>>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>>>> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>>>>
>>>> Tree: stable-rc
>>>> Branch: linux-4.4.y
>>>> Git Describe: v4.4.69-104-g2ebff3b7590b
>>>> Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
>>>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>>>> Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
>>>
>>> 54 passed? I had a bug here such that all x86 builds were crashing, in
>>> the core tty layer, which seems odd that anything would be able to boot
>>> with this tree...
>>>
>>> I've pushed out an update, can you all verify that it also works?
>>
>>
>> I got this:
>>
>> CALL scripts/checksyscalls.sh
>> CHK include/generated/compile.h
>> CC kernel/fork.o
>> kernel/fork.c: In function 'dup_task_struct':
>> kernel/fork.c:371:2: error: implicit declaration of function
>> 'get_random_long' [-Werror=implicit-function-declaration]
>> cc1: some warnings being treated as errors
>> make[1]: *** [kernel/fork.o] Error 1
>> make: *** [kernel] Error 2
>>
>>
>> This is stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
>
> What arch/.config are you building for that causes this?
x86_64 and CONFIG_CC_STACKPROTECTOR=y
The rest of my kernel config is SuSE's kernel-default config.
get_random_long came with v4.5 as far as I know
I have a running 4.4.70-rc1, Without that mentioned patch and using the
latest rc patch.
^ permalink raw reply
* Re: stable-rc build: 59 warnings 0 failures (stable-rc/v3.18.54-60-g35c7f23)
From: gregkh @ 2017-05-24 11:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Olof's autobuilder, Olof Johansson,
Kernel Build Reports Mailman List, stable
In-Reply-To: <CAK8P3a2_tQzqtU7V8d-3iDREZHNM34sOY=yU=zeNwP9jKvpGeQ@mail.gmail.com>
On Wed, May 24, 2017 at 12:31:21PM +0200, Arnd Bergmann wrote:
> On Tue, May 23, 2017 at 11:53 PM, Olof's autobuilder <build@lixom.net> wrote:
> > Here are the build results from automated periodic testing.
> >
> > The tree being built was stable-rc, found at:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
> >
> > 35c7f23 Linux 3.18.55-rc1
>
> > Warnings:
> >
> > 2 include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
> > 57 drivers/of/fdt.c:384:10: warning: 'return' with a value, in function returning void
>
> Caused by the backport of
>
> 0aa459efa045 ("of: fdt: add missing allocation-failure check")
>
> which relies on another change from:
>
> 83262418b0ef ("drivers/of: Return allocated memory from
> of_fdt_unflatten_tree()")
>
> Possible fixes are
>
> a) drop 0aa459efa045, as it won't be that important on 3.18: DT overlays
> were added only in 3.19, so this won't ever be called at runtime, and
> we don't normally worry about kmalloc failures during early boot.
>
> b) backport 83262418b0ef, which is otherwise not needed on stable
>
> c) apply or fold the trivial fixup:
>
> 8<--------
> [stable 3.18] fix __unflatten_device_tree warning
>
> A backported patch needs to be modified for a context change
>
> drivers/of/fdt.c:384:10: warning: 'return' with a value, in function
> returning void
>
> Fixes: 0aa459efa045 ("of: fdt: add missing allocation-failure check")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 43bd69dceabf..ca352d3a7d7e 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -508,7 +508,7 @@ void *__unflatten_device_tree(const void *blob,
> /* Allocate memory for the expanded device tree */
> mem = dt_alloc(size + 4, __alignof__(struct device_node));
> if (!mem)
> - return NULL;
> + return;
>
> memset(mem, 0, size);
Patch looks corrupted, can you resend it?
thanks,
greg k-h
^ permalink raw reply
* Re: stable-rc build: 0 warnings 4 failures (stable-rc/v4.9.29-165-g04accbb)
From: gregkh @ 2017-05-24 11:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Olof's autobuilder, Olof Johansson,
Kernel Build Reports Mailman List, Marc Zyngier, Christoffer Dall,
stable
In-Reply-To: <CAK8P3a31pfSxNPFNe6NmtKs9KwcM8Y5CDSPyFhEPxA0PtoBMBg@mail.gmail.com>
On Wed, May 24, 2017 at 12:36:42PM +0200, Arnd Bergmann wrote:
> On Wed, May 24, 2017 at 1:36 AM, Olof's autobuilder <build@lixom.net> wrote:
> >
> > Errors:
> >
> > arm64.allmodconfig:
> > /work/build/batch/arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v3.c:159:22: error: implicit declaration of function 'irq_is_pending' [-Werror=implicit-function-declaration]
> > /work/build/batch/arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c:176:22: error: implicit declaration of function 'irq_is_pending' [-Werror=implicit-function-declaration]
>
> Caused by the backport of 3d6e77ad1489 ("KVM: arm/arm64: vgic-v3: Do not
> use Active+Pending state for a HW interrupt"), which Greg has apparently
> dropped already from stable-rc.
Yes, already gone, sorry about that...
^ permalink raw reply
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
From: Greg Kroah-Hartman @ 2017-05-24 11:35 UTC (permalink / raw)
To: Thomas Voegtle
Cc: kernelci.org bot, linux-kernel, torvalds, akpm, linux, shuahkh,
patches, ben.hutchings, stable
In-Reply-To: <alpine.LSU.2.20.1705241122140.21307@er-systems.de>
On Wed, May 24, 2017 at 11:26:25AM +0200, Thomas Voegtle wrote:
> On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
>
> > On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
> > > stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
> > >
> > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> > > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> > >
> > > Tree: stable-rc
> > > Branch: linux-4.4.y
> > > Git Describe: v4.4.69-104-g2ebff3b7590b
> > > Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
> > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
> >
> > 54 passed? I had a bug here such that all x86 builds were crashing, in
> > the core tty layer, which seems odd that anything would be able to boot
> > with this tree...
> >
> > I've pushed out an update, can you all verify that it also works?
>
>
> I got this:
>
> CALL scripts/checksyscalls.sh
> CHK include/generated/compile.h
> CC kernel/fork.o
> kernel/fork.c: In function 'dup_task_struct':
> kernel/fork.c:371:2: error: implicit declaration of function
> 'get_random_long' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> make[1]: *** [kernel/fork.o] Error 1
> make: *** [kernel] Error 2
>
>
> This is stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
What arch/.config are you building for that causes this?
thanks,
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox