Hi Greg,
I see that you pushed 4.4.207-rc1 and 4.19.89-rc1 commits on linux-stable-rc at the weekend, but I haven't seen your usual "stable review" emails to the stable mailing list.
Am I just failing to find them or have you not got around to sending them yet?
I ask as I've seen some build issues, but didn't want to make noise in case the next 4.4/4.19 rc releases aren't ready yet.
Kind regards, Chris
Hi,
stable release candidates are a mess right now. Example build/boot
test results from 4.4.y.queue:
Build results:
total: 170 pass: 163 fail: 7
Failed builds:
arm:allmodconfig
arm:u8500_defconfig
arm:axm55xx_defconfig
arm:mxs_defconfig
arm:nhk8815_defconfig
arm64:defconfig
arm64:allmodconfig
Qemu test results:
total: 325 pass: 261 fail: 64
Failed tests:
<too many to list>
Most other branches are just as bad, and it isn't always just arm/arm64.
Is there a need to report details, or will it all be taken care of before
the next set of RCs ?
Thanks,
Guenter
Felix Abecassis reports move_pages() would return random status if the
pages are already on the target node by the below test program:
---8<---
int main(void)
{
const long node_id = 1;
const long page_size = sysconf(_SC_PAGESIZE);
const int64_t num_pages = 8;
unsigned long nodemask = 1 << node_id;
long ret = set_mempolicy(MPOL_BIND, &nodemask, sizeof(nodemask));
if (ret < 0)
return (EXIT_FAILURE);
void **pages = malloc(sizeof(void*) * num_pages);
for (int i = 0; i < num_pages; ++i) {
pages[i] = mmap(NULL, page_size, PROT_WRITE | PROT_READ,
MAP_PRIVATE | MAP_POPULATE | MAP_ANONYMOUS,
-1, 0);
if (pages[i] == MAP_FAILED)
return (EXIT_FAILURE);
}
ret = set_mempolicy(MPOL_DEFAULT, NULL, 0);
if (ret < 0)
return (EXIT_FAILURE);
int *nodes = malloc(sizeof(int) * num_pages);
int *status = malloc(sizeof(int) * num_pages);
for (int i = 0; i < num_pages; ++i) {
nodes[i] = node_id;
status[i] = 0xd0; /* simulate garbage values */
}
ret = move_pages(0, num_pages, pages, nodes, status, MPOL_MF_MOVE);
printf("move_pages: %ld\n", ret);
for (int i = 0; i < num_pages; ++i)
printf("status[%d] = %d\n", i, status[i]);
}
---8<---
Then running the program would return nonsense status values:
$ ./move_pages_bug
move_pages: 0
status[0] = 208
status[1] = 208
status[2] = 208
status[3] = 208
status[4] = 208
status[5] = 208
status[6] = 208
status[7] = 208
This is because the status is not set if the page is already on the
target node, but move_pages() should return valid status as long as it
succeeds. The valid status may be errno or node id.
We can't simply initialize status array to zero since the pages may be
not on node 0. Fix it by updating status with node id which the page is
already on.
Fixes: a49bd4d71637 ("mm, numa: rework do_pages_move")
Reported-by: Felix Abecassis <fabecassis(a)nvidia.com>
Tested-by: Felix Abecassis <fabecassis(a)nvidia.com>
Suggested-by: Michal Hocko <mhocko(a)suse.com>
Reviewed-by: John Hubbard <jhubbard(a)nvidia.com>
Acked-by: Christoph Lameter <cl(a)linux.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: <stable(a)vger.kernel.org> 4.17+
Signed-off-by: Yang Shi <yang.shi(a)linux.alibaba.com>
---
v4: * Fixed the comments from Christopher and John and added their Acked-by
and Reviewed-by.
v3: * Adopted the suggestion from Michal.
v2: * Correted the return value when add_page_for_migration() returns 1.
mm/migrate.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/mm/migrate.c b/mm/migrate.c
index a8f87cb..6b44818f 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1512,9 +1512,11 @@ static int do_move_pages_to_node(struct mm_struct *mm,
/*
* Resolves the given address to a struct page, isolates it from the LRU and
* puts it to the given pagelist.
- * Returns -errno if the page cannot be found/isolated or 0 when it has been
- * queued or the page doesn't need to be migrated because it is already on
- * the target node
+ * Returns:
+ * errno - if the page cannot be found/isolated
+ * 0 - when it doesn't have to be migrated because it is already on the
+ * target node
+ * 1 - when it has been queued
*/
static int add_page_for_migration(struct mm_struct *mm, unsigned long addr,
int node, struct list_head *pagelist, bool migrate_all)
@@ -1553,7 +1555,7 @@ static int add_page_for_migration(struct mm_struct *mm, unsigned long addr,
if (PageHuge(page)) {
if (PageHead(page)) {
isolate_huge_page(page, pagelist);
- err = 0;
+ err = 1;
}
} else {
struct page *head;
@@ -1563,7 +1565,7 @@ static int add_page_for_migration(struct mm_struct *mm, unsigned long addr,
if (err)
goto out_putpage;
- err = 0;
+ err = 1;
list_add_tail(&head->lru, pagelist);
mod_node_page_state(page_pgdat(head),
NR_ISOLATED_ANON + page_is_file_cache(head),
@@ -1640,8 +1642,17 @@ static int do_pages_move(struct mm_struct *mm, nodemask_t task_nodes,
*/
err = add_page_for_migration(mm, addr, current_node,
&pagelist, flags & MPOL_MF_MOVE_ALL);
- if (!err)
+
+ if (!err) {
+ /* The page is already on the target node */
+ err = store_status(status, i, current_node, 1);
+ if (err)
+ goto out_flush;
continue;
+ } else if (err > 0) {
+ /* The page is successfully queued for migration */
+ continue;
+ }
err = store_status(status, i, err, 1);
if (err)
--
1.8.3.1
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From e1e8c1fdce8b00fce08784d9d738c60ebf598ebc Mon Sep 17 00:00:00 2001
From: Kailang Yang <kailang(a)realtek.com>
Date: Tue, 26 Nov 2019 17:04:23 +0800
Subject: [PATCH] ALSA: hda/realtek - Dell headphone has noise on unmute for
ALC236
headphone have noise even the volume is very small.
Let it fill up pcbeep hidden register to default value.
The issue was gone.
Fixes: 4344aec84bd8 ("ALSA: hda/realtek - New codec support for ALC256")
Fixes: 736f20a70608 ("ALSA: hda/realtek - Add support for ALC236/ALC3204")
Signed-off-by: Kailang Yang <kailang(a)realtek.com>
Cc: <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/9ae47f23a64d4e41a9c81e263cd8a250@realtek.com
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index d2bf70a1d2fd..9f355b2f7d7b 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -367,9 +367,7 @@ static void alc_fill_eapd_coef(struct hda_codec *codec)
case 0x10ec0215:
case 0x10ec0233:
case 0x10ec0235:
- case 0x10ec0236:
case 0x10ec0255:
- case 0x10ec0256:
case 0x10ec0257:
case 0x10ec0282:
case 0x10ec0283:
@@ -381,6 +379,11 @@ static void alc_fill_eapd_coef(struct hda_codec *codec)
case 0x10ec0300:
alc_update_coef_idx(codec, 0x10, 1<<9, 0);
break;
+ case 0x10ec0236:
+ case 0x10ec0256:
+ alc_write_coef_idx(codec, 0x36, 0x5757);
+ alc_update_coef_idx(codec, 0x10, 1<<9, 0);
+ break;
case 0x10ec0275:
alc_update_coef_idx(codec, 0xe, 0, 1<<0);
break;
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From e1e8c1fdce8b00fce08784d9d738c60ebf598ebc Mon Sep 17 00:00:00 2001
From: Kailang Yang <kailang(a)realtek.com>
Date: Tue, 26 Nov 2019 17:04:23 +0800
Subject: [PATCH] ALSA: hda/realtek - Dell headphone has noise on unmute for
ALC236
headphone have noise even the volume is very small.
Let it fill up pcbeep hidden register to default value.
The issue was gone.
Fixes: 4344aec84bd8 ("ALSA: hda/realtek - New codec support for ALC256")
Fixes: 736f20a70608 ("ALSA: hda/realtek - Add support for ALC236/ALC3204")
Signed-off-by: Kailang Yang <kailang(a)realtek.com>
Cc: <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/9ae47f23a64d4e41a9c81e263cd8a250@realtek.com
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index d2bf70a1d2fd..9f355b2f7d7b 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -367,9 +367,7 @@ static void alc_fill_eapd_coef(struct hda_codec *codec)
case 0x10ec0215:
case 0x10ec0233:
case 0x10ec0235:
- case 0x10ec0236:
case 0x10ec0255:
- case 0x10ec0256:
case 0x10ec0257:
case 0x10ec0282:
case 0x10ec0283:
@@ -381,6 +379,11 @@ static void alc_fill_eapd_coef(struct hda_codec *codec)
case 0x10ec0300:
alc_update_coef_idx(codec, 0x10, 1<<9, 0);
break;
+ case 0x10ec0236:
+ case 0x10ec0256:
+ alc_write_coef_idx(codec, 0x36, 0x5757);
+ alc_update_coef_idx(codec, 0x10, 1<<9, 0);
+ break;
case 0x10ec0275:
alc_update_coef_idx(codec, 0xe, 0, 1<<0);
break;
Hi Greg,
Please can you include the following for 5.4.y. This fixes long delays
exiting suspend when using NFS and was causing one of our suspend tests
to fail.
commit 66eb3add452aa1be65ad536da99fac4b8f620b74
Author: Trond Myklebust <trond.myklebust(a)hammerspace.com>
Date: Tue Nov 5 09:10:54 2019 -0500
SUNRPC: Avoid RPC delays when exiting suspend
Thanks
Jon
--
nvpublic
Hi,
this series backports the CVE-2019-11487 fixes (page refcount overflow) to
4.4 stable. It differs from Ajay's series [1] in the following:
- gup.c variants of fast gup for x86 and s390 are fixed too. I've not fixed
sparc, mips, sh. It's unlikely the known overflow scenario based on FUSE,
which needs 140GB of RAM, is a problem for those architectures, and I don't
feel confident enough to patch them. I've sent the same fixup for 4.9 [3]
- there are some differences in backport adaptations, hopefully not important.
My version is taken from our 4.4 based kernel, which was just simpler for me
than adding the missing parts to Ajay's version
- The last patch fixes another problem in the fast gup implementation on x86,
that I've previously posted and got merged to 4.9 stable [2].
[1] https://lore.kernel.org/linux-mm/1570581863-12090-1-git-send-email-akaher@v…
[2] https://lore.kernel.org/linux-mm/20190802160614.8089-1-vbabka@suse.cz/
[3] https://lore.kernel.org/linux-mm/9c130fa4-e52d-f8bd-c450-42341c7ab441@suse.…
Linus Torvalds (3):
mm: make page ref count overflow check tighter and more explicit
mm: add 'try_get_page()' helper function
mm: prevent get_user_pages() from overflowing page refcount
Matthew Wilcox (1):
fs: prevent page refcount overflow in pipe_buf_get
Miklos Szeredi (1):
pipe: add pipe_buf_get() helper
Punit Agrawal (1):
mm, gup: ensure real head page is ref-counted when using hugepages
Vlastimil Babka (1):
x86, mm, gup: prevent get_page() race with munmap in paravirt guest
Will Deacon (1):
mm, gup: remove broken VM_BUG_ON_PAGE compound check for hugepages
arch/s390/mm/gup.c | 6 +++--
arch/x86/mm/gup.c | 23 ++++++++++++++++++-
fs/fuse/dev.c | 12 +++++-----
fs/pipe.c | 4 ++--
fs/splice.c | 12 ++++++++--
include/linux/mm.h | 26 ++++++++++++++++++++-
include/linux/pipe_fs_i.h | 17 ++++++++++++--
kernel/trace/trace.c | 6 ++++-
mm/gup.c | 48 +++++++++++++++++++++++++++------------
mm/huge_memory.c | 2 +-
mm/hugetlb.c | 18 +++++++++++++--
mm/internal.h | 17 ++++++++++----
12 files changed, 152 insertions(+), 39 deletions(-)
--
2.23.0
The m_can tries to detect of niso (canfd) is available while in standby,
this function results in the following error:
tcan4x5x spi2.0 (unnamed net_device) (uninitialized): Failed to init module
tcan4x5x spi2.0: m_can device registered (irq=84, version=32)
tcan4x5x spi2.0 can2: TCAN4X5X successfully initialized.
When the tcan device comes out of reset it comes out in standby mode.
The m_can driver tries to access the control register but fails due to
the device is in standby mode.
So this patch will put the tcan device in normal mode before the m_can
driver does the initialization.
Fixes: 5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel")
Cc: stable(a)vger.kernel.org
Signed-off-by: Sean Nyekjaer <sean(a)geanix.com>
---
tcan4x5x_init will now be called from probe and the m_can call.
Would it be better to move the mode switch only to the probe function?
drivers/net/can/m_can/tcan4x5x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/can/m_can/tcan4x5x.c b/drivers/net/can/m_can/tcan4x5x.c
index cb5fdb695ec9..7f26c2d53f8c 100644
--- a/drivers/net/can/m_can/tcan4x5x.c
+++ b/drivers/net/can/m_can/tcan4x5x.c
@@ -456,6 +456,8 @@ static int tcan4x5x_can_probe(struct spi_device *spi)
if (ret)
goto out_clk;
+ tcan4x5x_init(mcan_class);
+
tcan4x5x_power_enable(priv->power, 1);
ret = m_can_class_register(mcan_class);
--
2.24.0
This is a note to let you know that I've just added the patch titled
iio: humidity: hdc100x: fix IIO_HUMIDITYRELATIVE channel reporting
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 342a6928bd5017edbdae376042d8ad6af3d3b943 Mon Sep 17 00:00:00 2001
From: Chris Lesiak <chris.lesiak(a)licor.com>
Date: Thu, 21 Nov 2019 20:39:42 +0000
Subject: iio: humidity: hdc100x: fix IIO_HUMIDITYRELATIVE channel reporting
The IIO_HUMIDITYRELATIVE channel was being incorrectly reported back
as percent when it should have been milli percent. This is via an
incorrect scale value being returned to userspace.
Signed-off-by: Chris Lesiak <chris.lesiak(a)licor.com>
Acked-by: Matt Ranostay <matt.ranostay(a)konsulko.com>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/humidity/hdc100x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c
index 963ff043eecf..7ecd2ffa3132 100644
--- a/drivers/iio/humidity/hdc100x.c
+++ b/drivers/iio/humidity/hdc100x.c
@@ -229,7 +229,7 @@ static int hdc100x_read_raw(struct iio_dev *indio_dev,
*val2 = 65536;
return IIO_VAL_FRACTIONAL;
} else {
- *val = 100;
+ *val = 100000;
*val2 = 65536;
return IIO_VAL_FRACTIONAL;
}
--
2.24.0