- Linux-stable-mirror - lists.linaro.org

patch "usb: core: handle hub C_PORT_OVER_CURRENT condition" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: core: handle hub C_PORT_OVER_CURRENT condition to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-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 249a32b7eeb3edb6897dd38f89651a62163ac4ed Mon Sep 17 00:00:00 2001 From: Bin Liu <b-liu(a)ti.com> Date: Thu, 19 Jul 2018 14:39:37 -0500 Subject: usb: core: handle hub C_PORT_OVER_CURRENT condition Based on USB2.0 Spec Section 11.12.5, "If a hub has per-port power switching and per-port current limiting, an over-current on one port may still cause the power on another port to fall below specific minimums. In this case, the affected port is placed in the Power-Off state and C_PORT_OVER_CURRENT is set for the port, but PORT_OVER_CURRENT is not set." so let's check C_PORT_OVER_CURRENT too for over current condition. Fixes: 08d1dec6f405 ("usb:hub set hub->change_bits when over-current happens") Cc: <stable(a)vger.kernel.org> Tested-by: Alessandro Antenucci <antenucci(a)korg.it> Signed-off-by: Bin Liu <b-liu(a)ti.com> Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/hub.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index fcae521df29b..1fb266809966 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1142,10 +1142,14 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type) if (!udev || udev->state == USB_STATE_NOTATTACHED) { /* Tell hub_wq to disconnect the device or - * check for a new connection + * check for a new connection or over current condition. + * Based on USB2.0 Spec Section 11.12.5, + * C_PORT_OVER_CURRENT could be set while + * PORT_OVER_CURRENT is not. So check for any of them. */ if (udev || (portstatus & USB_PORT_STAT_CONNECTION) || - (portstatus & USB_PORT_STAT_OVERCURRENT)) + (portstatus & USB_PORT_STAT_OVERCURRENT) || + (portchange & USB_PORT_STAT_C_OVERCURRENT)) set_bit(port1, hub->change_bits); } else if (portstatus & USB_PORT_STAT_ENABLE) { -- 2.18.0

7 years, 1 month

1
0
0 0

patch "USB: serial: sierra: fix potential deadlock at close" added to usb-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: sierra: fix potential deadlock at close to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-next 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 also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From e60870012e5a35b1506d7b376fddfb30e9da0b27 Mon Sep 17 00:00:00 2001 From: John Ogness <john.ogness(a)linutronix.de> Date: Sun, 24 Jun 2018 00:32:11 +0200 Subject: USB: serial: sierra: fix potential deadlock at close The portdata spinlock can be taken in interrupt context (via sierra_outdat_callback()). Disable interrupts when taking the portdata spinlock when discarding deferred URBs during close to prevent a possible deadlock. Fixes: 014333f77c0b ("USB: sierra: fix urb and memory leak on disconnect") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: John Ogness <john.ogness(a)linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> [ johan: amend commit message and add fixes and stable tags ] Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/usb/serial/sierra.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/sierra.c b/drivers/usb/serial/sierra.c index d189f953c891..55956a638f5b 100644 --- a/drivers/usb/serial/sierra.c +++ b/drivers/usb/serial/sierra.c @@ -770,9 +770,9 @@ static void sierra_close(struct usb_serial_port *port) kfree(urb->transfer_buffer); usb_free_urb(urb); usb_autopm_put_interface_async(serial->interface); - spin_lock(&portdata->lock); + spin_lock_irq(&portdata->lock); portdata->outstanding_urbs--; - spin_unlock(&portdata->lock); + spin_unlock_irq(&portdata->lock); } sierra_stop_rx_urbs(port); -- 2.18.0

7 years, 1 month

1
0
0 0

[patch 6/6] mm: memcg: fix use after free in mem_cgroup_iter()

by akpm＠linux-foundation.org

From: Jing Xia <jing.xia.mail(a)gmail.com> Subject: mm: memcg: fix use after free in mem_cgroup_iter() It was reported that a kernel crash happened in mem_cgroup_iter(), which can be triggered if the legacy cgroup-v1 non-hierarchical mode is used. Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b8f ...... Call trace: mem_cgroup_iter+0x2e0/0x6d4 shrink_zone+0x8c/0x324 balance_pgdat+0x450/0x640 kswapd+0x130/0x4b8 kthread+0xe8/0xfc ret_from_fork+0x10/0x20 mem_cgroup_iter(): ...... if (css_tryget(css)) <-- crash here break; ...... The crashing reason is that mem_cgroup_iter() uses the memcg object whose pointer is stored in iter->position, which has been freed before and filled with POISON_FREE(0x6b). And the root cause of the use-after-free issue is that invalidate_reclaim_iterators() fails to reset the value of iter->position to NULL when the css of the memcg is released in non- hierarchical mode. Link: http://lkml.kernel.org/r/1531994807-25639-1-git-send-email-jing.xia@unisoc.… Fixes: 6df38689e0e9 ("mm: memcontrol: fix possible memcg leak due to interrupted reclaim") Signed-off-by: Jing Xia <jing.xia.mail(a)gmail.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Vladimir Davydov <vdavydov.dev(a)gmail.com> Cc: <chunyan.zhang(a)unisoc.com> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memcontrol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN mm/memcontrol.c~mm-memcg-fix-use-after-free-in-mem_cgroup_iter mm/memcontrol.c --- a/mm/memcontrol.c~mm-memcg-fix-use-after-free-in-mem_cgroup_iter +++ a/mm/memcontrol.c @@ -850,7 +850,7 @@ static void invalidate_reclaim_iterators int nid; int i; - while ((memcg = parent_mem_cgroup(memcg))) { + for (; memcg; memcg = parent_mem_cgroup(memcg)) { for_each_node(nid) { mz = mem_cgroup_nodeinfo(memcg, nid); for (i = 0; i <= DEF_PRIORITY; i++) { _

7 years, 1 month

1
0
0 0

[patch 5/6] mm/huge_memory.c: fix data loss when splitting a file pmd

by akpm＠linux-foundation.org

From: Hugh Dickins <hughd(a)google.com> Subject: mm/huge_memory.c: fix data loss when splitting a file pmd __split_huge_pmd_locked() must check if the cleared huge pmd was dirty, and propagate that to PageDirty: otherwise, data may be lost when a huge tmpfs page is modified then split then reclaimed. How has this taken so long to be noticed? Because there was no problem when the huge page is written by a write system call (shmem_write_end() calls set_page_dirty()), nor when the page is allocated for a write fault (fault_dirty_shared_page() calls set_page_dirty()); but when allocated for a read fault (which MAP_POPULATE simulates), no set_page_dirty(). Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1807111741430.1106@eggly.anvils Fixes: d21b9e57c74c ("thp: handle file pages in split_huge_pmd()") Signed-off-by: Hugh Dickins <hughd(a)google.com> Reported-by: Ashwin Chaugule <ashwinch(a)google.com> Reviewed-by: Yang Shi <yang.shi(a)linux.alibaba.com> Reviewed-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: "Huang, Ying" <ying.huang(a)intel.com> Cc: <stable(a)vger.kernel.org> [4.8+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/huge_memory.c | 2 ++ 1 file changed, 2 insertions(+) diff -puN mm/huge_memory.c~thp-fix-data-loss-when-splitting-a-file-pmd mm/huge_memory.c --- a/mm/huge_memory.c~thp-fix-data-loss-when-splitting-a-file-pmd +++ a/mm/huge_memory.c @@ -2084,6 +2084,8 @@ static void __split_huge_pmd_locked(stru if (vma_is_dax(vma)) return; page = pmd_page(_pmd); + if (!PageDirty(page) && pmd_dirty(_pmd)) + set_page_dirty(page); if (!PageReferenced(page) && pmd_young(_pmd)) SetPageReferenced(page); page_remove_rmap(page, true); _

7 years, 1 month

1
0
0 0

[patch 4/6] fat: fix memory allocation failure handling of match_strdup()

by akpm＠linux-foundation.org

From: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> Subject: fat: fix memory allocation failure handling of match_strdup() In parse_options(), if match_strdup() failed, parse_options() leaves opts->iocharset in unexpected state (i.e. still pointing the freed string). And this can be the cause of double free. To fix, this initialize opts->iocharset always when freeing. Link: http://lkml.kernel.org/r/8736wp9dzc.fsf@mail.parknet.co.jp Signed-off-by: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> Reported-by: syzbot+90b8e10515ae88228a92(a)syzkaller.appspotmail.com Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/fat/inode.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff -puN fs/fat/inode.c~fat-fix-memory-allocation-failure-handling-of-match_strdup fs/fat/inode.c --- a/fs/fat/inode.c~fat-fix-memory-allocation-failure-handling-of-match_strdup +++ a/fs/fat/inode.c @@ -707,13 +707,21 @@ static void fat_set_state(struct super_b brelse(bh); } +static void fat_reset_iocharset(struct fat_mount_options *opts) +{ + if (opts->iocharset != fat_default_iocharset) { + /* Note: opts->iocharset can be NULL here */ + kfree(opts->iocharset); + opts->iocharset = fat_default_iocharset; + } +} + static void delayed_free(struct rcu_head *p) { struct msdos_sb_info *sbi = container_of(p, struct msdos_sb_info, rcu); unload_nls(sbi->nls_disk); unload_nls(sbi->nls_io); - if (sbi->options.iocharset != fat_default_iocharset) - kfree(sbi->options.iocharset); + fat_reset_iocharset(&sbi->options); kfree(sbi); } @@ -1132,7 +1140,7 @@ static int parse_options(struct super_bl opts->fs_fmask = opts->fs_dmask = current_umask(); opts->allow_utime = -1; opts->codepage = fat_default_codepage; - opts->iocharset = fat_default_iocharset; + fat_reset_iocharset(opts); if (is_vfat) { opts->shortname = VFAT_SFN_DISPLAY_WINNT|VFAT_SFN_CREATE_WIN95; opts->rodir = 0; @@ -1289,8 +1297,7 @@ static int parse_options(struct super_bl /* vfat specific */ case Opt_charset: - if (opts->iocharset != fat_default_iocharset) - kfree(opts->iocharset); + fat_reset_iocharset(opts); iocharset = match_strdup(&args[0]); if (!iocharset) return -ENOMEM; @@ -1881,8 +1888,7 @@ out_fail: iput(fat_inode); unload_nls(sbi->nls_io); unload_nls(sbi->nls_disk); - if (sbi->options.iocharset != fat_default_iocharset) - kfree(sbi->options.iocharset); + fat_reset_iocharset(&sbi->options); sb->s_fs_info = NULL; kfree(sbi); return error; _

7 years, 1 month

1
0
0 0

[PATCHv3 1/2] libnvdimm: Use max contiguous area for namespace size

by Keith Busch

This patch will find the max contiguous area to determine the largest pmem namespace size that can be created. If the requested size exceeds the largest available, ENOSPC error will be returned. This fixes the allocation underrun error and wrong error return code that have otherwise been observed as the following kernel warning: WARNING: CPU: <CPU> PID: <PID> at drivers/nvdimm/namespace_devs.c:913 size_store Fixes: a1f3e4d6a0c3 ("libnvdimm, region: update nd_region_available_dpa() for multi-pmem support") Cc: <stable(a)vger.kernel.org> Signed-off-by: Keith Busch <keith.busch(a)intel.com> --- v2 -> v3: This one takes block regions into account by reserving pmem regions on dimms and finding the largest intersection among all dimms in the region. drivers/nvdimm/dimm_devs.c | 30 ++++++++++++++++++++++++++++++ drivers/nvdimm/namespace_devs.c | 6 +++--- drivers/nvdimm/nd-core.h | 9 +++++++++ drivers/nvdimm/region_devs.c | 24 ++++++++++++++++++++++++ 4 files changed, 66 insertions(+), 3 deletions(-) diff --git a/drivers/nvdimm/dimm_devs.c b/drivers/nvdimm/dimm_devs.c index 8d348b22ba45..9e977cbd1a60 100644 --- a/drivers/nvdimm/dimm_devs.c +++ b/drivers/nvdimm/dimm_devs.c @@ -536,6 +536,36 @@ resource_size_t nd_blk_available_dpa(struct nd_region *nd_region) return info.available; } +/** + * nd_pmem_max_contiguous_dpa - For the given dimm+region, return the max + * contiguous unallocated dpa range. + * @nd_region: constrain available space check to this reference region + * @nd_mapping: container of dpa-resource-root + labels + */ +resource_size_t nd_pmem_max_contiguous_dpa(struct nd_region *nd_region, + struct nd_mapping *nd_mapping) +{ + struct nvdimm_drvdata *ndd = to_ndd(nd_mapping); + struct nvdimm_bus *nvdimm_bus = walk_to_nvdimm_bus(ndd->dev); + resource_size_t max = 0; + struct resource *res; + + /* if a dimm is disabled the available capacity is zero */ + if (!ndd) + return 0; + + if (reserve_free_pmem(nvdimm_bus, nd_mapping)) + return 0; + for_each_dpa_resource(ndd, res) { + if (strcmp(res->name, "pmem-reserve") != 0) + continue; + if (resource_size(res) > max) + max = resource_size(res); + } + release_free_pmem(nvdimm_bus, nd_mapping); + return max; +} + /** * nd_pmem_available_dpa - for the given dimm+region account unallocated dpa * @nd_mapping: container of dpa-resource-root + labels diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c index 28afdd668905..c3afff2cdf1d 100644 --- a/drivers/nvdimm/namespace_devs.c +++ b/drivers/nvdimm/namespace_devs.c @@ -836,7 +836,7 @@ static int __reserve_free_pmem(struct device *dev, void *data) return 0; } -static void release_free_pmem(struct nvdimm_bus *nvdimm_bus, +void release_free_pmem(struct nvdimm_bus *nvdimm_bus, struct nd_mapping *nd_mapping) { struct nvdimm_drvdata *ndd = to_ndd(nd_mapping); @@ -847,7 +847,7 @@ static void release_free_pmem(struct nvdimm_bus *nvdimm_bus, nvdimm_free_dpa(ndd, res); } -static int reserve_free_pmem(struct nvdimm_bus *nvdimm_bus, +int reserve_free_pmem(struct nvdimm_bus *nvdimm_bus, struct nd_mapping *nd_mapping) { struct nvdimm *nvdimm = nd_mapping->nvdimm; @@ -1032,7 +1032,7 @@ static ssize_t __size_store(struct device *dev, unsigned long long val) allocated += nvdimm_allocated_dpa(ndd, &label_id); } - available = nd_region_available_dpa(nd_region); + available = nd_region_allocatable_dpa(nd_region); if (val > available + allocated) return -ENOSPC; diff --git a/drivers/nvdimm/nd-core.h b/drivers/nvdimm/nd-core.h index 79274ead54fb..1c5f5b389940 100644 --- a/drivers/nvdimm/nd-core.h +++ b/drivers/nvdimm/nd-core.h @@ -100,6 +100,15 @@ struct nd_region; struct nvdimm_drvdata; struct nd_mapping; void nd_mapping_free_labels(struct nd_mapping *nd_mapping); + +int reserve_free_pmem(struct nvdimm_bus *nvdimm_bus, + struct nd_mapping *nd_mapping); +void release_free_pmem(struct nvdimm_bus *nvdimm_bus, + struct nd_mapping *nd_mapping); + +resource_size_t nd_pmem_max_contiguous_dpa(struct nd_region *nd_region, + struct nd_mapping *nd_mapping); +resource_size_t nd_region_allocatable_dpa(struct nd_region *nd_region); resource_size_t nd_pmem_available_dpa(struct nd_region *nd_region, struct nd_mapping *nd_mapping, resource_size_t *overlap); resource_size_t nd_blk_available_dpa(struct nd_region *nd_region); diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c index ec3543b83330..c30d5af02cc2 100644 --- a/drivers/nvdimm/region_devs.c +++ b/drivers/nvdimm/region_devs.c @@ -389,6 +389,30 @@ resource_size_t nd_region_available_dpa(struct nd_region *nd_region) return available; } +resource_size_t nd_region_allocatable_dpa(struct nd_region *nd_region) +{ + resource_size_t available = 0; + int i; + + if (is_memory(&nd_region->dev)) + available = PHYS_ADDR_MAX; + + WARN_ON(!is_nvdimm_bus_locked(&nd_region->dev)); + for (i = 0; i < nd_region->ndr_mappings; i++) { + struct nd_mapping *nd_mapping = &nd_region->mapping[i]; + + if (is_memory(&nd_region->dev)) + available = min(available, + nd_pmem_max_contiguous_dpa(nd_region, + nd_mapping)); + else if (is_nd_blk(&nd_region->dev)) + available += nd_blk_available_dpa(nd_region); + } + if (is_memory(&nd_region->dev)) + return available * nd_region->ndr_mappings; + return available; +} + static ssize_t available_size_show(struct device *dev, struct device_attribute *attr, char *buf) { -- 2.14.3

7 years, 1 month

2
4
0 0

patch "USB: serial: sierra: fix potential deadlock at close" added to usb-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: sierra: fix potential deadlock at close to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-testing 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 be merged to the usb-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From e60870012e5a35b1506d7b376fddfb30e9da0b27 Mon Sep 17 00:00:00 2001 From: John Ogness <john.ogness(a)linutronix.de> Date: Sun, 24 Jun 2018 00:32:11 +0200 Subject: USB: serial: sierra: fix potential deadlock at close The portdata spinlock can be taken in interrupt context (via sierra_outdat_callback()). Disable interrupts when taking the portdata spinlock when discarding deferred URBs during close to prevent a possible deadlock. Fixes: 014333f77c0b ("USB: sierra: fix urb and memory leak on disconnect") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: John Ogness <john.ogness(a)linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> [ johan: amend commit message and add fixes and stable tags ] Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/usb/serial/sierra.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/sierra.c b/drivers/usb/serial/sierra.c index d189f953c891..55956a638f5b 100644 --- a/drivers/usb/serial/sierra.c +++ b/drivers/usb/serial/sierra.c @@ -770,9 +770,9 @@ static void sierra_close(struct usb_serial_port *port) kfree(urb->transfer_buffer); usb_free_urb(urb); usb_autopm_put_interface_async(serial->interface); - spin_lock(&portdata->lock); + spin_lock_irq(&portdata->lock); portdata->outstanding_urbs--; - spin_unlock(&portdata->lock); + spin_unlock_irq(&portdata->lock); } sierra_stop_rx_urbs(port); -- 2.18.0

7 years, 1 month

1
0
0 0

[PATCH V3] sched/deadline: Update rq_clock of later_rq when pushing a task

by Daniel Bristot de Oliveira

Daniel Casini got this warn while running a DL task here at RetisLab: [ 461.137582] ------------[ cut here ]------------ [ 461.137583] rq->clock_update_flags < RQCF_ACT_SKIP [ 461.137599] WARNING: CPU: 4 PID: 2354 at kernel/sched/sched.h:967 assert_clock_updated.isra.32.part.33+0x17/0x20 [a ton of modules] [ 461.137646] CPU: 4 PID: 2354 Comm: label_image Not tainted 4.18.0-rc4+ #3 [ 461.137647] Hardware name: ASUS All Series/Z87-K, BIOS 0801 09/02/2013 [ 461.137649] RIP: 0010:assert_clock_updated.isra.32.part.33+0x17/0x20 [ 461.137649] Code: ff 48 89 83 08 09 00 00 eb c6 66 0f 1f 84 00 00 00 00 00 55 48 c7 c7 98 7a 6c a5 c6 05 bc 0d 54 01 01 48 89 e5 e8 a9 84 fb ff <0f> 0b 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 83 7e 60 01 74 0a 48 3b [ 461.137673] RSP: 0018:ffffa77e08cafc68 EFLAGS: 00010082 [ 461.137674] RAX: 0000000000000000 RBX: ffff8b3fc1702d80 RCX: 0000000000000006 [ 461.137674] RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff8b3fded164b0 [ 461.137675] RBP: ffffa77e08cafc68 R08: 0000000000000026 R09: 0000000000000339 [ 461.137676] R10: ffff8b3fd060d410 R11: 0000000000000026 R12: ffffffffa4e14e20 [ 461.137677] R13: ffff8b3fdec22940 R14: ffff8b3fc1702da0 R15: ffff8b3fdec22940 [ 461.137678] FS: 00007efe43ee5700(0000) GS:ffff8b3fded00000(0000) knlGS:0000000000000000 [ 461.137679] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 461.137680] CR2: 00007efe30000010 CR3: 0000000301744003 CR4: 00000000001606e0 [ 461.137680] Call Trace: [ 461.137684] push_dl_task.part.46+0x3bc/0x460 [ 461.137686] task_woken_dl+0x60/0x80 [ 461.137689] ttwu_do_wakeup+0x4f/0x150 [ 461.137690] ttwu_do_activate+0x77/0x80 [ 461.137692] try_to_wake_up+0x1d6/0x4c0 [ 461.137693] wake_up_q+0x32/0x70 [ 461.137696] do_futex+0x7e7/0xb50 [ 461.137698] __x64_sys_futex+0x8b/0x180 [ 461.137701] do_syscall_64+0x5a/0x110 [ 461.137703] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 461.137705] RIP: 0033:0x7efe4918ca26 [ 461.137705] Code: 00 00 00 74 17 49 8b 48 20 44 8b 59 10 41 83 e3 30 41 83 fb 20 74 1e be 85 00 00 00 41 ba 01 00 00 00 41 b9 01 00 00 04 0f 05 <48> 3d 01 f0 ff ff 73 1f 31 c0 c3 be 8c 00 00 00 49 89 c8 4d 31 d2 [ 461.137738] RSP: 002b:00007efe43ee4928 EFLAGS: 00000283 ORIG_RAX: 00000000000000ca [ 461.137739] RAX: ffffffffffffffda RBX: 0000000005094df0 RCX: 00007efe4918ca26 [ 461.137740] RDX: 0000000000000001 RSI: 0000000000000085 RDI: 0000000005094e24 [ 461.137741] RBP: 00007efe43ee49c0 R08: 0000000005094e20 R09: 0000000004000001 [ 461.137741] R10: 0000000000000001 R11: 0000000000000283 R12: 0000000000000000 [ 461.137742] R13: 0000000005094df8 R14: 0000000000000001 R15: 0000000000448a10 [ 461.137743] ---[ end trace 187df4cad2bf7649 ]--- This warning happened in the push_dl_task(), because __add_running_bw()->cpufreq_update_util() is getting the rq_clock of the later_rq before its update, which takes place at activate_task(). The fix then is to update the rq_clock before calling add_running_bw(). To avoid double rq_clock_update() call, we set ENQUEUE_NOCLOCK flag to activate_task(). Changes: v1->v2: Remove part of the comment regarding the ENQUEUE_NOCLOCK usage (Kirill Tkhai). v0->v1: Cosmetic changes in the log, and correct Juri's email (Daniel). Reported-by: Daniel Casini <daniel.casini(a)santannapisa.it> Signed-off-by: Daniel Bristot de Oliveira <bristot(a)redhat.com> Acked-by: Juri Lelli <juri.lelli(a)redhat.com> Cc: Clark Williams <williams(a)redhat.com> Cc: Juri Lelli <juri.lelli(a)redhat.com> Cc: Luca Abeni <luca.abeni(a)santannapisa.it> Cc: Tommaso Cucinotta <tommaso.cucinotta(a)santannapisa.it> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: linux-kernel(a)vger.kernel.org Cc: <stable(a)vger.kernel.org> # 4.16+ Fixes: e0367b12674b sched/deadline: Move CPU frequency selection triggering points --- kernel/sched/deadline.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index fbfc3f1d368a..8b50eea4b607 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -2090,8 +2090,14 @@ static int push_dl_task(struct rq *rq) sub_rq_bw(&next_task->dl, &rq->dl); set_task_cpu(next_task, later_rq->cpu); add_rq_bw(&next_task->dl, &later_rq->dl); + + /* + * Update the later_rq clock here, because the clock is used + * by the cpufreq_update_util() inside __add_running_bw(). + */ + update_rq_clock(later_rq); add_running_bw(&next_task->dl, &later_rq->dl); - activate_task(later_rq, next_task, 0); + activate_task(later_rq, next_task, ENQUEUE_NOCLOCK); ret = 1; resched_curr(later_rq); -- 2.17.1

7 years, 1 month

3
6
0 0

patch "usb: xhci: Fix memory leak in xhci_endpoint_reset()" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: xhci: Fix memory leak in xhci_endpoint_reset() to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-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 d89b7664f76047e7beca8f07e86f2ccfad085a28 Mon Sep 17 00:00:00 2001 From: Zheng Xiaowei <zhengxiaowei(a)ruijie.com.cn> Date: Fri, 20 Jul 2018 18:05:11 +0300 Subject: usb: xhci: Fix memory leak in xhci_endpoint_reset() If td_list is not empty the cfg_cmd will not be freed, call xhci_free_command to free it. Signed-off-by: Zheng Xiaowei <zhengxiaowei(a)ruijie.com.cn> Cc: <stable(a)vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/host/xhci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 2f4850f25e82..68e6132aa8b2 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -3051,6 +3051,7 @@ static void xhci_endpoint_reset(struct usb_hcd *hcd, if (!list_empty(&ep->ring->td_list)) { dev_err(&udev->dev, "EP not empty, refuse reset\n"); spin_unlock_irqrestore(&xhci->lock, flags); + xhci_free_command(xhci, cfg_cmd); goto cleanup; } xhci_queue_stop_endpoint(xhci, stop_cmd, udev->slot_id, ep_index, 0); -- 2.18.0

7 years, 1 month

1
0
0 0

[PATCH 1/1] usb: xhci: Fix memory leak in xhci_endpoint_reset()

by Mathias Nyman

From: Zheng Xiaowei <zhengxiaowei(a)ruijie.com.cn> If td_list is not empty the cfg_cmd will not be freed, call xhci_free_command to free it. Signed-off-by: Zheng Xiaowei <zhengxiaowei(a)ruijie.com.cn> Cc: <stable(a)vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 2f4850f..68e6132 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -3051,6 +3051,7 @@ static void xhci_endpoint_reset(struct usb_hcd *hcd, if (!list_empty(&ep->ring->td_list)) { dev_err(&udev->dev, "EP not empty, refuse reset\n"); spin_unlock_irqrestore(&xhci->lock, flags); + xhci_free_command(xhci, cfg_cmd); goto cleanup; } xhci_queue_stop_endpoint(xhci, stop_cmd, udev->slot_id, ep_index, 0); -- 2.7.4

7 years, 1 month

1
0
0 0

[PATCH] usb: core: handle hub C_PORT_OVER_CURRENT condition

by Bin Liu

Based on USB2.0 Spec Section 11.12.5, "If a hub has per-port power switching and per-port current limiting, an over-current on one port may still cause the power on another port to fall below specific minimums. In this case, the affected port is placed in the Power-Off state and C_PORT_OVER_CURRENT is set for the port, but PORT_OVER_CURRENT is not set." so let's check C_PORT_OVER_CURRENT too for over current condition. Fixes: 08d1dec6f405 ("usb:hub set hub->change_bits when over-current happens") Cc: <stable(a)vger.kernel.org> Tested-by: Alessandro Antenucci <antenucci(a)korg.it> Signed-off-by: Bin Liu <b-liu(a)ti.com> --- drivers/usb/core/hub.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index fcae521df29b..1fb266809966 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1142,10 +1142,14 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type) if (!udev || udev->state == USB_STATE_NOTATTACHED) { /* Tell hub_wq to disconnect the device or - * check for a new connection + * check for a new connection or over current condition. + * Based on USB2.0 Spec Section 11.12.5, + * C_PORT_OVER_CURRENT could be set while + * PORT_OVER_CURRENT is not. So check for any of them. */ if (udev || (portstatus & USB_PORT_STAT_CONNECTION) || - (portstatus & USB_PORT_STAT_OVERCURRENT)) + (portstatus & USB_PORT_STAT_OVERCURRENT) || + (portchange & USB_PORT_STAT_C_OVERCURRENT)) set_bit(port1, hub->change_bits); } else if (portstatus & USB_PORT_STAT_ENABLE) { -- 1.9.1

7 years, 1 month

2
1
0 0

patch "usb: gadget: f_fs: Only return delayed status when len is 0" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: gadget: f_fs: Only return delayed status when len is 0 to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-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 4d644abf25698362bd33d17c9ddc8f7122c30f17 Mon Sep 17 00:00:00 2001 From: Jerry Zhang <zhangjerry(a)google.com> Date: Mon, 2 Jul 2018 12:48:08 -0700 Subject: usb: gadget: f_fs: Only return delayed status when len is 0 Commit 1b9ba000 ("Allow function drivers to pause control transfers") states that USB_GADGET_DELAYED_STATUS is only supported if data phase is 0 bytes. It seems that when the length is not 0 bytes, there is no need to explicitly delay the data stage since the transfer is not completed until the user responds. However, when the length is 0, there is no data stage and the transfer is finished once setup() returns, hence there is a need to explicitly delay completion. This manifests as the following bugs: Prior to 946ef68ad4e4 ('Let setup() return USB_GADGET_DELAYED_STATUS'), when setup is 0 bytes, ffs would require user to queue a 0 byte request in order to clear setup state. However, that 0 byte request was actually not needed and would hang and cause errors in other setup requests. After the above commit, 0 byte setups work since the gadget now accepts empty queues to ep0 to clear the delay, but all other setups hang. Fixes: 946ef68ad4e4 ("Let setup() return USB_GADGET_DELAYED_STATUS") Signed-off-by: Jerry Zhang <zhangjerry(a)google.com> Cc: stable <stable(a)vger.kernel.org> Acked-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/function/f_fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c index 33e2030503fa..3ada83d81bda 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -3263,7 +3263,7 @@ static int ffs_func_setup(struct usb_function *f, __ffs_event_add(ffs, FUNCTIONFS_SETUP); spin_unlock_irqrestore(&ffs->ev.waitq.lock, flags); - return USB_GADGET_DELAYED_STATUS; + return creq->wLength == 0 ? USB_GADGET_DELAYED_STATUS : 0; } static bool ffs_func_req_match(struct usb_function *f, -- 2.18.0

7 years, 1 month

1
0
0 0

request for 4.14-stable: 1dc3039bc87a ("block: do not use interruptible wait anywhere")

by Sudip Mukherjee

Hi Greg, This was missing in 4.14-stable. Please apply to your queue. -- Regards Sudip

7 years, 1 month

3
4
0 0

[PATCH 00/23] arm64: 4.9 backport of the SSBD mitigation patches

by Marc Zyngier

This is the backport of the arm64 SSBD patches to 4.9. I've had to cherry-pick a number of dependencies: - The ldr_this_cpu macro - parts of the SDEI series that allow tpidr_el2 to be used as the per-cpu offset - one patch from the VHE series that introduce vcpu retrieval as a per-cpu variable - one patch from the the EL2 randomisation series, allowing relative addressing of global structures - the dynamic patching infrastructure Christoffer Dall (1): KVM: arm64: Avoid storing the vcpu pointer on the stack James Morse (5): KVM: arm64: Store vcpu on the stack during __guest_enter() KVM: arm/arm64: Convert kvm_host_cpu_state to a static per-cpu allocation KVM: arm64: Change hyp_panic()s dependency on tpidr_el2 arm64: alternatives: use tpidr_el2 on VHE hosts KVM: arm64: Stop save/restoring host tpidr_el1 on VHE Marc Zyngier (16): arm64: alternatives: Add dynamic patching feature KVM: arm/arm64: Do not use kern_hyp_va() with kvm_vgic_global_state arm/arm64: smccc: Add SMCCC-specific return codes arm64: Call ARCH_WORKAROUND_2 on transitions between EL0 and EL1 arm64: Add per-cpu infrastructure to call ARCH_WORKAROUND_2 arm64: Add ARCH_WORKAROUND_2 probing arm64: Add 'ssbd' command-line option arm64: ssbd: Add global mitigation state accessor arm64: ssbd: Skip apply_ssbd if not using dynamic mitigation arm64: ssbd: Restore mitigation status on CPU resume arm64: ssbd: Introduce thread flag to control userspace mitigation arm64: ssbd: Add prctl interface for per-thread mitigation arm64: KVM: Add HYP per-cpu accessors arm64: KVM: Add ARCH_WORKAROUND_2 support for guests arm64: KVM: Handle guest's ARCH_WORKAROUND_2 requests arm64: KVM: Add ARCH_WORKAROUND_2 discovery through ARCH_FEATURES_FUNC_ID Mark Rutland (1): arm64: assembler: introduce ldr_this_cpu Documentation/kernel-parameters.txt | 17 +++ arch/arm/include/asm/kvm_host.h | 12 ++ arch/arm/include/asm/kvm_mmu.h | 12 ++ arch/arm/kvm/arm.c | 24 ++-- arch/arm/kvm/psci.c | 18 ++- arch/arm64/Kconfig | 9 ++ arch/arm64/include/asm/alternative.h | 43 ++++++- arch/arm64/include/asm/assembler.h | 27 +++- arch/arm64/include/asm/cpucaps.h | 3 +- arch/arm64/include/asm/cpufeature.h | 22 ++++ arch/arm64/include/asm/kvm_asm.h | 41 ++++++ arch/arm64/include/asm/kvm_host.h | 43 +++++++ arch/arm64/include/asm/kvm_mmu.h | 44 +++++++ arch/arm64/include/asm/percpu.h | 12 +- arch/arm64/include/asm/thread_info.h | 1 + arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/alternative.c | 54 +++++--- arch/arm64/kernel/asm-offsets.c | 2 + arch/arm64/kernel/cpu_errata.c | 180 +++++++++++++++++++++++++++ arch/arm64/kernel/cpufeature.c | 17 +++ arch/arm64/kernel/entry.S | 32 ++++- arch/arm64/kernel/hibernate.c | 11 ++ arch/arm64/kernel/ssbd.c | 108 ++++++++++++++++ arch/arm64/kernel/suspend.c | 8 ++ arch/arm64/kvm/hyp-init.S | 4 + arch/arm64/kvm/hyp/entry.S | 12 +- arch/arm64/kvm/hyp/hyp-entry.S | 62 +++++++-- arch/arm64/kvm/hyp/switch.c | 64 +++++++--- arch/arm64/kvm/hyp/sysreg-sr.c | 21 ++-- arch/arm64/kvm/reset.c | 4 + include/linux/arm-smccc.h | 10 ++ virt/kvm/arm/hyp/vgic-v2-sr.c | 2 +- 32 files changed, 835 insertions(+), 85 deletions(-) create mode 100644 arch/arm64/kernel/ssbd.c -- 2.18.0

7 years, 1 month

2
24
0 0

[PATCH 00/22] arm64: 4.14 backport of the SSBD mitigation patches

by Marc Zyngier

This is the backport of the arm64 SSBD patches to 4.14. I've had to cherry-pick a number of dependencies: - parts of the SDEI series that allow tpidr_el2 to be used as the per-cpu offset - one patch from the VHE series that introduce vcpu retrieval as a per-cpu variable - one patch from the the EL2 randomisation series, allowing relative addressing of global structures - the dynamic patching infrastructure Christoffer Dall (1): KVM: arm64: Avoid storing the vcpu pointer on the stack James Morse (5): KVM: arm64: Store vcpu on the stack during __guest_enter() KVM: arm/arm64: Convert kvm_host_cpu_state to a static per-cpu allocation KVM: arm64: Change hyp_panic()s dependency on tpidr_el2 arm64: alternatives: use tpidr_el2 on VHE hosts KVM: arm64: Stop save/restoring host tpidr_el1 on VHE Marc Zyngier (16): arm64: alternatives: Add dynamic patching feature KVM: arm/arm64: Do not use kern_hyp_va() with kvm_vgic_global_state arm/arm64: smccc: Add SMCCC-specific return codes arm64: Call ARCH_WORKAROUND_2 on transitions between EL0 and EL1 arm64: Add per-cpu infrastructure to call ARCH_WORKAROUND_2 arm64: Add ARCH_WORKAROUND_2 probing arm64: Add 'ssbd' command-line option arm64: ssbd: Add global mitigation state accessor arm64: ssbd: Skip apply_ssbd if not using dynamic mitigation arm64: ssbd: Restore mitigation status on CPU resume arm64: ssbd: Introduce thread flag to control userspace mitigation arm64: ssbd: Add prctl interface for per-thread mitigation arm64: KVM: Add HYP per-cpu accessors arm64: KVM: Add ARCH_WORKAROUND_2 support for guests arm64: KVM: Handle guest's ARCH_WORKAROUND_2 requests arm64: KVM: Add ARCH_WORKAROUND_2 discovery through ARCH_FEATURES_FUNC_ID .../admin-guide/kernel-parameters.txt | 17 ++ arch/arm/include/asm/kvm_host.h | 12 ++ arch/arm/include/asm/kvm_mmu.h | 12 ++ arch/arm64/Kconfig | 9 + arch/arm64/include/asm/alternative.h | 43 ++++- arch/arm64/include/asm/assembler.h | 8 + arch/arm64/include/asm/cpucaps.h | 3 +- arch/arm64/include/asm/cpufeature.h | 22 +++ arch/arm64/include/asm/kvm_asm.h | 41 ++++ arch/arm64/include/asm/kvm_host.h | 43 +++++ arch/arm64/include/asm/kvm_mmu.h | 44 +++++ arch/arm64/include/asm/percpu.h | 11 +- arch/arm64/include/asm/thread_info.h | 1 + arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/alternative.c | 52 +++-- arch/arm64/kernel/asm-offsets.c | 2 + arch/arm64/kernel/cpu_errata.c | 180 ++++++++++++++++++ arch/arm64/kernel/cpufeature.c | 17 ++ arch/arm64/kernel/entry.S | 30 +++ arch/arm64/kernel/hibernate.c | 11 ++ arch/arm64/kernel/ssbd.c | 108 +++++++++++ arch/arm64/kernel/suspend.c | 8 + arch/arm64/kvm/hyp-init.S | 4 + arch/arm64/kvm/hyp/entry.S | 12 +- arch/arm64/kvm/hyp/hyp-entry.S | 62 ++++-- arch/arm64/kvm/hyp/switch.c | 64 +++++-- arch/arm64/kvm/hyp/sysreg-sr.c | 21 +- arch/arm64/kvm/reset.c | 4 + arch/arm64/mm/proc.S | 8 + include/linux/arm-smccc.h | 10 + virt/kvm/arm/arm.c | 22 +-- virt/kvm/arm/hyp/vgic-v2-sr.c | 2 +- virt/kvm/arm/psci.c | 18 +- 33 files changed, 823 insertions(+), 79 deletions(-) create mode 100644 arch/arm64/kernel/ssbd.c -- 2.18.0

7 years, 1 month

2
23
0 0

[PATCH 00/14] arm64: 4.17 backport of the SSBD mitigation patches

by Marc Zyngier

This is the backport of the arm64 SSBD patches to 4.17. Not much to say here, this is basically what went into 4.18. 4.14 and 4.9 to follow. Thanks, M. Marc Zyngier (14): arm/arm64: smccc: Add SMCCC-specific return codes arm64: Call ARCH_WORKAROUND_2 on transitions between EL0 and EL1 arm64: Add per-cpu infrastructure to call ARCH_WORKAROUND_2 arm64: Add ARCH_WORKAROUND_2 probing arm64: Add 'ssbd' command-line option arm64: ssbd: Add global mitigation state accessor arm64: ssbd: Skip apply_ssbd if not using dynamic mitigation arm64: ssbd: Restore mitigation status on CPU resume arm64: ssbd: Introduce thread flag to control userspace mitigation arm64: ssbd: Add prctl interface for per-thread mitigation arm64: KVM: Add HYP per-cpu accessors arm64: KVM: Add ARCH_WORKAROUND_2 support for guests arm64: KVM: Handle guest's ARCH_WORKAROUND_2 requests arm64: KVM: Add ARCH_WORKAROUND_2 discovery through ARCH_FEATURES_FUNC_ID .../admin-guide/kernel-parameters.txt | 17 ++ arch/arm/include/asm/kvm_host.h | 12 ++ arch/arm/include/asm/kvm_mmu.h | 5 + arch/arm64/Kconfig | 9 + arch/arm64/include/asm/cpucaps.h | 3 +- arch/arm64/include/asm/cpufeature.h | 22 +++ arch/arm64/include/asm/kvm_asm.h | 30 ++- arch/arm64/include/asm/kvm_host.h | 26 +++ arch/arm64/include/asm/kvm_mmu.h | 24 +++ arch/arm64/include/asm/thread_info.h | 1 + arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/asm-offsets.c | 1 + arch/arm64/kernel/cpu_errata.c | 180 ++++++++++++++++++ arch/arm64/kernel/entry.S | 30 +++ arch/arm64/kernel/hibernate.c | 11 ++ arch/arm64/kernel/ssbd.c | 110 +++++++++++ arch/arm64/kernel/suspend.c | 8 + arch/arm64/kvm/hyp/hyp-entry.S | 38 +++- arch/arm64/kvm/hyp/switch.c | 42 ++++ arch/arm64/kvm/reset.c | 4 + include/linux/arm-smccc.h | 10 + virt/kvm/arm/arm.c | 4 + virt/kvm/arm/psci.c | 18 +- 23 files changed, 600 insertions(+), 6 deletions(-) create mode 100644 arch/arm64/kernel/ssbd.c -- 2.18.0

7 years, 1 month

2
15
0 0

Re: KASAN: use-after-free Read in l2tp_session_create

by Greg Kroah-Hartman

On Fri, Jul 20, 2018 at 10:00:34AM +0200, Dmitry Vyukov wrote: > On Fri, Jul 20, 2018 at 9:53 AM, James Chapman <jchapman(a)katalix.com> wrote: > > On 18/07/18 12:00, Dmitry Vyukov wrote: > >> On Tue, Jan 16, 2018 at 7:29 PM, syzbot > >> <syzbot+065d0fc357520c8f6039(a)syzkaller.appspotmail.com> wrote: > >>> Hello, > >>> > >>> syzkaller hit the following crash on > >>> a8750ddca918032d6349adbf9a4b6555e7db20da > >>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > >>> compiler: gcc (GCC) 7.1.1 20170620 > >>> .config is attached > >>> Raw console output is attached. > >>> Unfortunately, I don't have any reproducer for this bug yet. > >>> > >>> > >>> IMPORTANT: if you fix the bug, please add the following tag to the commit: > >>> Reported-by: syzbot+065d0fc357520c8f6039(a)syzkaller.appspotmail.com > >>> It will help syzbot understand when the bug is fixed. See footer for > >>> details. > >>> If you forward the report, please keep this part and the footer. > >> > >> James, > >> > >> Did you fix this? You asked syzbot to test a fix for this bug some time ago. > >> If yes, did you include the Reported-by tag in the commit? This bug is > >> still considered open by syzbot. But it stopped happening ~4 months > >> ago: > > > > Yes, I think this has been fixed now. I think it was fixed by > > Guillaume's 6b9f34239b00e6956a267abed2bc559ede556ad6 that was actually > > to fix another syzbot bug fbeeb5c3b538e8545644 which looks similar to > > this one. > > > >> https://syzkaller.appspot.com/bug?id=6fed0854381422329e78d7e16fb9cf4af8c9ae… > >> We are also seeing these crashes in 4.4 and 4.9, it would be good to > >> backport the fix. > > > > It looks like 6b9f34239b00e6956a267abed2bc559ede556ad6 hasn't made it to > > 4.9 or 4.4. > > Thanks for the update! > > Let's tell syzbot that this is fixed: > > #syz fix: l2tp: fix races in tunnel creation > > Greg H: so this is probably the patch we need. > > +Greg KH: I think we need this in stable, we hit this in both 4.4 and 4.9. It's also needed in 4.14.y. But it doesn't apply to any of those kernel trees cleanly, can someone please provide a working backport? thanks, greg k-h

7 years, 1 month

1
0
0 0

Ihre Position

by Martin Schoch

Sehr geehrte Damen und Herren, Nach der Analyse Ihrer Internetseite haben wir Fehler im Code ermittelt, die einen groβen Einfluss darauf haben, dass Ihre Webseite eine niedrige Position in den Suchmaschinen, darunter auch in der wichtigsten, d. h. auf Google, einnimmt. Wir bieten Ihnen die Optimierung Ihrer Webseite ohne Abonnement, ohne monatliche Gebühren, ohne versteckte Kosten und ohne Strafen für den Vertragsbruch an. Die Optimierung Ihrer Internetseite wird für die bessere Suchmaschinenfreundlichkeit sorgen und dadurch wird auch ihre Position im Google-Ranking und in anderen Suchmaschinen steigen. *** Aktionspreis: 240 € (inkl. MwSt.) - bis zum 20.07.2018 *** Mehr Informationen finden Sie auf unserer Internetseite: http://www.web-suchmaschinenoptimierung.net Mit freundlichen Grüßen Martin Schoch Web Analytics

7 years, 1 month

1
0
0 0

FAILED: patch "[PATCH] mtd: rawnand: denali_dt: set clk_x_rate to 200 MHz" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-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 3f6e6986045d47f87bd982910821b7ab9758487e Mon Sep 17 00:00:00 2001 From: Masahiro Yamada <yamada.masahiro(a)socionext.com> Date: Sat, 23 Jun 2018 01:06:34 +0900 Subject: [PATCH] mtd: rawnand: denali_dt: set clk_x_rate to 200 MHz unconditionally Since commit 1bb88666775e ("mtd: nand: denali: handle timing parameters by setup_data_interface()"), denali_dt.c gets the clock rate from the clock driver. The driver expects the frequency of the bus interface clock, whereas the clock driver of SOCFPGA provides the core clock. Thus, the setup_data_interface() hook calculates timing parameters based on a wrong frequency. To make it work without relying on the clock driver, hard-code the clock frequency, 200MHz. This is fine for existing DT of UniPhier, and also fixes the issue of SOCFPGA because both platforms use 200 MHz for the bus interface clock. Fixes: 1bb88666775e ("mtd: nand: denali: handle timing parameters by setup_data_interface()") Cc: linux-stable <stable(a)vger.kernel.org> #4.14+ Reported-by: Philipp Rosenberger <p.rosenberger(a)linutronix.de> Suggested-by: Boris Brezillon <boris.brezillon(a)bootlin.com> Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Tested-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com> diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c index cfd33e6ca77f..5869e90cc14b 100644 --- a/drivers/mtd/nand/raw/denali_dt.c +++ b/drivers/mtd/nand/raw/denali_dt.c @@ -123,7 +123,11 @@ static int denali_dt_probe(struct platform_device *pdev) if (ret) return ret; - denali->clk_x_rate = clk_get_rate(dt->clk); + /* + * Hardcode the clock rate for the backward compatibility. + * This works for both SOCFPGA and UniPhier. + */ + denali->clk_x_rate = 200000000; ret = denali_init(denali); if (ret)

7 years, 1 month

3
2
0 0

+ mm-memcg-fix-use-after-free-in-mem_cgroup_iter.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: memcg: fix use after free in mem_cgroup_iter() has been added to the -mm tree. Its filename is mm-memcg-fix-use-after-free-in-mem_cgroup_iter.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-memcg-fix-use-after-free-in-mem… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-memcg-fix-use-after-free-in-mem… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Jing Xia <jing.xia.mail(a)gmail.com> Subject: mm: memcg: fix use after free in mem_cgroup_iter() It was reported that a kernel crash happened in mem_cgroup_iter(), which can be triggered if the legacy cgroup-v1 non-hierarchical mode is used. Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b8f ...... Call trace: mem_cgroup_iter+0x2e0/0x6d4 shrink_zone+0x8c/0x324 balance_pgdat+0x450/0x640 kswapd+0x130/0x4b8 kthread+0xe8/0xfc ret_from_fork+0x10/0x20 mem_cgroup_iter(): ...... if (css_tryget(css)) <-- crash here break; ...... The crashing reason is that mem_cgroup_iter() uses the memcg object whose pointer is stored in iter->position, which has been freed before and filled with POISON_FREE(0x6b). And the root cause of the use-after-free issue is that invalidate_reclaim_iterators() fails to reset the value of iter->position to NULL when the css of the memcg is released in non- hierarchical mode. Link: http://lkml.kernel.org/r/1531994807-25639-1-git-send-email-jing.xia@unisoc.… Fixes: 6df38689e0e9 ("mm: memcontrol: fix possible memcg leak due to interrupted reclaim") Signed-off-by: Jing Xia <jing.xia.mail(a)gmail.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Vladimir Davydov <vdavydov.dev(a)gmail.com> Cc: <chunyan.zhang(a)unisoc.com> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN mm/memcontrol.c~mm-memcg-fix-use-after-free-in-mem_cgroup_iter mm/memcontrol.c --- a/mm/memcontrol.c~mm-memcg-fix-use-after-free-in-mem_cgroup_iter +++ a/mm/memcontrol.c @@ -850,7 +850,7 @@ static void invalidate_reclaim_iterators int nid; int i; - while ((memcg = parent_mem_cgroup(memcg))) { + for (; memcg; memcg = parent_mem_cgroup(memcg)) { for_each_node(nid) { mz = mem_cgroup_nodeinfo(memcg, nid); for (i = 0; i <= DEF_PRIORITY; i++) { _ Patches currently in -mm which might be from jing.xia.mail(a)gmail.com are mm-memcg-fix-use-after-free-in-mem_cgroup_iter.patch

7 years, 1 month

1
0
0 0

[PATCH v2] mtd: rawnand: make subop helpers return unsigned values

by Miquel Raynal

A report from Colin Ian King pointed a CoverityScan issue where error values on these helpers where not checked in the drivers. These helpers can error out only in case of a software bug in driver code, not because of a runtime/hardware error. Hence, let's WARN_ON() in this case and return 0 which is harmless anyway. Fixes: 8878b126df76 ("mtd: nand: add ->exec_op() implementation") Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- Changes since v1: ================= * At first I decided to continue returning negative errors and handling these cases in the drivers. Not sure this was the right thing to do as reported by Boris so now the core WARN_ON() on error (only due to some bug in a controller driver) and return an harmless value. The drivers are not touched anymore, hence this patch is alone now. drivers/mtd/nand/raw/nand_base.c | 44 ++++++++++++++++++++-------------------- include/linux/mtd/rawnand.h | 16 +++++++-------- 2 files changed, 30 insertions(+), 30 deletions(-) diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c index 4fa5e20d9690..9bb76ddff4be 100644 --- a/drivers/mtd/nand/raw/nand_base.c +++ b/drivers/mtd/nand/raw/nand_base.c @@ -2668,8 +2668,8 @@ static bool nand_subop_instr_is_valid(const struct nand_subop *subop, return subop && instr_idx < subop->ninstrs; } -static int nand_subop_get_start_off(const struct nand_subop *subop, - unsigned int instr_idx) +static unsigned int nand_subop_get_start_off(const struct nand_subop *subop, + unsigned int instr_idx) { if (instr_idx) return 0; @@ -2688,12 +2688,12 @@ static int nand_subop_get_start_off(const struct nand_subop *subop, * * Given an address instruction, returns the offset of the first cycle to issue. */ -int nand_subop_get_addr_start_off(const struct nand_subop *subop, - unsigned int instr_idx) +unsigned int nand_subop_get_addr_start_off(const struct nand_subop *subop, + unsigned int instr_idx) { - if (!nand_subop_instr_is_valid(subop, instr_idx) || - subop->instrs[instr_idx].type != NAND_OP_ADDR_INSTR) - return -EINVAL; + if (WARN_ON(!nand_subop_instr_is_valid(subop, instr_idx) || + subop->instrs[instr_idx].type != NAND_OP_ADDR_INSTR)) + return 0; return nand_subop_get_start_off(subop, instr_idx); } @@ -2710,14 +2710,14 @@ EXPORT_SYMBOL_GPL(nand_subop_get_addr_start_off); * * Given an address instruction, returns the number of address cycle to issue. */ -int nand_subop_get_num_addr_cyc(const struct nand_subop *subop, - unsigned int instr_idx) +unsigned int nand_subop_get_num_addr_cyc(const struct nand_subop *subop, + unsigned int instr_idx) { int start_off, end_off; - if (!nand_subop_instr_is_valid(subop, instr_idx) || - subop->instrs[instr_idx].type != NAND_OP_ADDR_INSTR) - return -EINVAL; + if (WARN_ON(!nand_subop_instr_is_valid(subop, instr_idx) || + subop->instrs[instr_idx].type != NAND_OP_ADDR_INSTR)) + return 0; start_off = nand_subop_get_addr_start_off(subop, instr_idx); @@ -2742,12 +2742,12 @@ EXPORT_SYMBOL_GPL(nand_subop_get_num_addr_cyc); * * Given a data instruction, returns the offset to start from. */ -int nand_subop_get_data_start_off(const struct nand_subop *subop, - unsigned int instr_idx) +unsigned int nand_subop_get_data_start_off(const struct nand_subop *subop, + unsigned int instr_idx) { - if (!nand_subop_instr_is_valid(subop, instr_idx) || - !nand_instr_is_data(&subop->instrs[instr_idx])) - return -EINVAL; + if (WARN_ON(!nand_subop_instr_is_valid(subop, instr_idx) || + !nand_instr_is_data(&subop->instrs[instr_idx]))) + return 0; return nand_subop_get_start_off(subop, instr_idx); } @@ -2764,14 +2764,14 @@ EXPORT_SYMBOL_GPL(nand_subop_get_data_start_off); * * Returns the length of the chunk of data to send/receive. */ -int nand_subop_get_data_len(const struct nand_subop *subop, - unsigned int instr_idx) +unsigned int nand_subop_get_data_len(const struct nand_subop *subop, + unsigned int instr_idx) { int start_off = 0, end_off; - if (!nand_subop_instr_is_valid(subop, instr_idx) || - !nand_instr_is_data(&subop->instrs[instr_idx])) - return -EINVAL; + if (WARN_ON(!nand_subop_instr_is_valid(subop, instr_idx) || + !nand_instr_is_data(&subop->instrs[instr_idx]))) + return 0; start_off = nand_subop_get_data_start_off(subop, instr_idx); diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h index e383c7f32574..876a9dd47e74 100644 --- a/include/linux/mtd/rawnand.h +++ b/include/linux/mtd/rawnand.h @@ -1007,14 +1007,14 @@ struct nand_subop { unsigned int last_instr_end_off; }; -int nand_subop_get_addr_start_off(const struct nand_subop *subop, - unsigned int op_id); -int nand_subop_get_num_addr_cyc(const struct nand_subop *subop, - unsigned int op_id); -int nand_subop_get_data_start_off(const struct nand_subop *subop, - unsigned int op_id); -int nand_subop_get_data_len(const struct nand_subop *subop, - unsigned int op_id); +unsigned int nand_subop_get_addr_start_off(const struct nand_subop *subop, + unsigned int op_id); +unsigned int nand_subop_get_num_addr_cyc(const struct nand_subop *subop, + unsigned int op_id); +unsigned int nand_subop_get_data_start_off(const struct nand_subop *subop, + unsigned int op_id); +unsigned int nand_subop_get_data_len(const struct nand_subop *subop, + unsigned int op_id); /** * struct nand_op_parser_addr_constraints - Constraints for address instructions -- 2.14.1

7 years, 1 month

2
4
0 0

request for 4.14-stable: 2278446e2b7cd33ad894b32e7eb63afc7db6c86e

by Sudip Mukherjee

Hi Greg, This was missing in 4.14-stable. Please apply to your queue. -- Regards Sudip

7 years, 1 month

2
3
0 0

v4.4.142 build: 0 failures 31 warnings (v4.4.142)

by Build bot for Mark Brown

Tree/Branch: v4.4.142 Git describe: v4.4.142 Commit: ecb9989751 Linux 4.4.142 Build Time: 63 min 12 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 31 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 19 warnings 0 mismatches : arm64-allmodconfig 17 warnings 0 mismatches : x86_64-allmodconfig ------------------------------------------------------------------------------- Warnings Summary: 31 3 warning: (IMA) selects TCG_CRB which has unmet direct dependencies (TCG_TPM && X86 && ACPI) 2 ../drivers/media/dvb-frontends/stv090x.c:4250:1: warning: the frame size of 4832 bytes is larger than 2048 bytes [-Wframe-larger-than=] 2 ../drivers/media/dvb-frontends/stv090x.c:1211:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] 2 ../drivers/media/dvb-frontends/stv090x.c:1168:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/net/ethernet/rocker/rocker.c:2172:1: warning: the frame size of 2752 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/net/ethernet/rocker/rocker.c:2172:1: warning: the frame size of 2720 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:4759:1: warning: the frame size of 2056 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:4565:1: warning: the frame size of 2096 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:4565:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:3436:1: warning: the frame size of 6784 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:3436:1: warning: the frame size of 5280 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:3095:1: warning: the frame size of 5864 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:3095:1: warning: the frame size of 5840 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:2513:1: warning: the frame size of 2304 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:2513:1: warning: the frame size of 2288 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:2141:1: warning: the frame size of 2104 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:2141:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:2073:1: warning: the frame size of 2552 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:2073:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:1956:1: warning: the frame size of 3264 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:1956:1: warning: the frame size of 3248 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:1858:1: warning: the frame size of 3008 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:1858:1: warning: the frame size of 2992 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:1599:1: warning: the frame size of 5296 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:1599:1: warning: the frame size of 5280 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv0367.c:3147:1: warning: the frame size of 4144 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv0367.c:2490:1: warning: the frame size of 3424 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/cxd2841er.c:2401:1: warning: the frame size of 2984 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/cxd2841er.c:2401:1: warning: the frame size of 2976 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/cxd2841er.c:2282:1: warning: the frame size of 4336 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/cxd2841er.c:2282:1: warning: the frame size of 4328 bytes is larger than 2048 bytes [-Wframe-larger-than=] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm64-allmodconfig : PASS, 0 errors, 19 warnings, 0 section mismatches Warnings: warning: (IMA) selects TCG_CRB which has unmet direct dependencies (TCG_TPM && X86 && ACPI) warning: (IMA) selects TCG_CRB which has unmet direct dependencies (TCG_TPM && X86 && ACPI) warning: (IMA) selects TCG_CRB which has unmet direct dependencies (TCG_TPM && X86 && ACPI) ../drivers/media/dvb-frontends/stv090x.c:1858:1: warning: the frame size of 2992 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:2141:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:2513:1: warning: the frame size of 2288 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:4565:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1956:1: warning: the frame size of 3248 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1599:1: warning: the frame size of 5280 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1211:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:4250:1: warning: the frame size of 4832 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1168:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:2073:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:3095:1: warning: the frame size of 5840 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:3436:1: warning: the frame size of 6784 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv0367.c:2490:1: warning: the frame size of 3424 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/cxd2841er.c:2401:1: warning: the frame size of 2976 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/cxd2841er.c:2282:1: warning: the frame size of 4336 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/net/ethernet/rocker/rocker.c:2172:1: warning: the frame size of 2720 bytes is larger than 2048 bytes [-Wframe-larger-than=] ------------------------------------------------------------------------------- x86_64-allmodconfig : PASS, 0 errors, 17 warnings, 0 section mismatches Warnings: ../drivers/media/dvb-frontends/stv090x.c:1858:1: warning: the frame size of 3008 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:2141:1: warning: the frame size of 2104 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:2513:1: warning: the frame size of 2304 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:4565:1: warning: the frame size of 2096 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1956:1: warning: the frame size of 3264 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1599:1: warning: the frame size of 5296 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1211:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:4250:1: warning: the frame size of 4832 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:4759:1: warning: the frame size of 2056 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1168:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:2073:1: warning: the frame size of 2552 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:3095:1: warning: the frame size of 5864 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:3436:1: warning: the frame size of 5280 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv0367.c:3147:1: warning: the frame size of 4144 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/cxd2841er.c:2401:1: warning: the frame size of 2984 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/cxd2841er.c:2282:1: warning: the frame size of 4328 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/net/ethernet/rocker/rocker.c:2172:1: warning: the frame size of 2752 bytes is larger than 2048 bytes [-Wframe-larger-than=] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm64-defconfig

7 years, 1 month

1
0
0 0

[PATCH 1/2 4.4 Backport] MIPS: Call dump_stack() from show_regs()

by Huacai Chen

From: Paul Burton <paul.burton(a)mips.com> commit 5a267832c2ec47b2dad0fdb291a96bb5b8869315 upstream. The generic nmi_cpu_backtrace() function calls show_regs() when a struct pt_regs is available, and dump_stack() otherwise. If we were to make use of the generic nmi_cpu_backtrace() with MIPS' current implementation of show_regs() this would mean that we see only register data with no accompanying stack information, in contrast with our current implementation which calls dump_stack() regardless of whether register state is available. In preparation for making use of the generic nmi_cpu_backtrace() to implement arch_trigger_cpumask_backtrace(), have our implementation of show_regs() call dump_stack() and drop the explicit dump_stack() call in arch_dump_stack() which is invoked by arch_trigger_cpumask_backtrace(). This will allow the output we produce to remain the same after a later patch switches to using nmi_cpu_backtrace(). It may mean that we produce extra stack output in other uses of show_regs(), but this: 1) Seems harmless. 2) Is good for consistency between arch_trigger_cpumask_backtrace() and other users of show_regs(). 3) Matches the behaviour of the ARM & PowerPC architectures. Marked for stable back to v4.9 as a prerequisite of the following patch "MIPS: Call dump_stack() from show_regs()". Signed-off-by: Paul Burton <paul.burton(a)mips.com> Patchwork: https://patchwork.linux-mips.org/patch/19596/ Cc: James Hogan <jhogan(a)kernel.org> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Huacai Chen <chenhc(a)lemote.com> Cc: linux-mips(a)linux-mips.org Cc: stable(a)vger.kernel.org [ Huacai: backported to 4.4: The next patch is also backported to 4.4 ] Signed-off-by: Huacai Chen <chenhc(a)lemote.com> --- arch/mips/kernel/process.c | 4 ++-- arch/mips/kernel/traps.c | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c index 1ee603d..f96048a 100644 --- a/arch/mips/kernel/process.c +++ b/arch/mips/kernel/process.c @@ -637,8 +637,8 @@ static void arch_dump_stack(void *info) if (regs) show_regs(regs); - - dump_stack(); + else + dump_stack(); } void arch_trigger_all_cpu_backtrace(bool include_self) diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index 31ca2ed..1b90121 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -344,6 +344,7 @@ static void __show_regs(const struct pt_regs *regs) void show_regs(struct pt_regs *regs) { __show_regs((struct pt_regs *)regs); + dump_stack(); } void show_registers(struct pt_regs *regs) -- 2.7.0

7 years, 1 month

2
2
0 0

request for 4.14-stable: 5b9e886a4af97574ca3ce1147f35545da0e7afc7

by Sudip Mukherjee

Hi Greg, This was missing in 4.14-stable. Please apply to your queue. -- Regards Sudip

7 years, 1 month

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror