提交 · 5.10.0-4.24.0 · openeuler / Kernel

21 10月, 2021 30 次提交

NFSv4: Fix second deadlock in nfs4_evict_inode() · 9da1d03a

由 Trond Myklebust 提交于 6月 01, 2021

stable inclusion
from stable-v5.10.44
commit d973bd0d6e7f9b4ea976cc619e8d6e0d235b9056
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=462
CVE: NA

-------------------------------------------------

commit c3aba897 upstream.

If the inode is being evicted but has to return a layout first, then
that too can cause a deadlock in the corner case where the server
reboots.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NHang <haihangyiyuan@163.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

9da1d03a

usb: typec: intel_pmc_mux: Put fwnode in error case during ->probe() · 0a518333

由 Andy Shevchenko 提交于 6月 07, 2021

stable inclusion
from stable-v5.10.44
commit 6900ef1b1095e2ffa6538895017a5408e4706e34
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=410
CVE: NA

-------------------------------------------------

commit 1a85b350 upstream.

device_get_next_child_node() bumps a reference counting of a returned variable.
We have to balance it whenever we return to the caller.

Fixes: 6701adfa ("usb: typec: driver for Intel PMC mux control")
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210607205007.71458-1-andy.shevchenko@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYuan Yao <yaoyuan_1999_1@163.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

0a518333

usb: dwc3: gadget: Disable gadget IRQ during pullup disable · bac32994

由 Wesley Cheng 提交于 5月 20, 2021

stable inclusion
from stable-v5.10.44
commit 9e0677c2e39052ac20efae4474bb20614d9a88c9
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=431
CVE: NA

-------------------------------------------------

commit 82129373 upstream.

Current sequence utilizes dwc3_gadget_disable_irq() alongside
synchronize_irq() to ensure that no further DWC3 events are generated.
However, the dwc3_gadget_disable_irq() API only disables device
specific events.  Endpoint events can still be generated.  Briefly
disable the interrupt line, so that the cleanup code can run to
prevent device and endpoint events. (i.e. __dwc3_gadget_stop() and
dwc3_stop_active_transfers() respectively)

Without doing so, it can lead to both the interrupt handler and the
pullup disable routine both writing to the GEVNTCOUNT register, which
will cause an incorrect count being read from future interrupts.

Fixes: ae7e8610 ("usb: dwc3: Stop active transfers before halting the controller")
Signed-off-by: NWesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1621571037-1424-1-git-send-email-wcheng@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NHu Tao <huijiao_love@163.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

bac32994

usb: typec: tcpm: cancel vdm and state machine hrtimer when unregister tcpm port · 8671fa0d

由 Li Jun 提交于 6月 02, 2021

stable inclusion
from stable-v5.10.44
commit 18eaf0de50eadeeb395b83310b259b21ad8ed0a6
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=365
CVE: NA

-------------------------------------------------

commit 3a13ff7e upstream.

A pending hrtimer may expire after the kthread_worker of tcpm port
is destroyed, see below kernel dump when do module unload, fix it
by cancel the 2 hrtimers.

[  111.517018] Unable to handle kernel paging request at virtual address ffff8000118cb880
[  111.518786] blk_update_request: I/O error, dev sda, sector 60061185 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[  111.526594] Mem abort info:
[  111.526597]   ESR = 0x96000047
[  111.526600]   EC = 0x25: DABT (current EL), IL = 32 bits
[  111.526604]   SET = 0, FnV = 0
[  111.526607]   EA = 0, S1PTW = 0
[  111.526610] Data abort info:
[  111.526612]   ISV = 0, ISS = 0x00000047
[  111.526615]   CM = 0, WnR = 1
[  111.526619] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041d75000
[  111.526623] [ffff8000118cb880] pgd=10000001bffff003, p4d=10000001bffff003, pud=10000001bfffe003, pmd=10000001bfffa003, pte=0000000000000000
[  111.526642] Internal error: Oops: 96000047 [#1] PREEMPT SMP
[  111.526647] Modules linked in: dwc3_imx8mp dwc3 phy_fsl_imx8mq_usb [last unloaded: tcpci]
[  111.526663] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc4-00927-gebbe9dbd802c-dirty #36
[  111.526670] Hardware name: NXP i.MX8MPlus EVK board (DT)
[  111.526674] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO BTYPE=--)
[  111.526681] pc : queued_spin_lock_slowpath+0x1a0/0x390
[  111.526695] lr : _raw_spin_lock_irqsave+0x88/0xb4
[  111.526703] sp : ffff800010003e20
[  111.526706] x29: ffff800010003e20 x28: ffff00017f380180
[  111.537156] buffer_io_error: 6 callbacks suppressed
[  111.537162] Buffer I/O error on dev sda1, logical block 60040704, async page read
[  111.539932]  x27: ffff00017f3801c0
[  111.539938] x26: ffff800010ba2490 x25: 0000000000000000 x24: 0000000000000001
[  111.543025] blk_update_request: I/O error, dev sda, sector 60061186 op 0x0:(READ) flags 0x0 phys_seg 7 prio class 0
[  111.548304]
[  111.548306] x23: 00000000000000c0 x22: ffff0000c2a9f184 x21: ffff00017f380180
[  111.551374] Buffer I/O error on dev sda1, logical block 60040705, async page read
[  111.554499]
[  111.554503] x20: ffff0000c5f14210 x19: 00000000000000c0 x18: 0000000000000000
[  111.557391] Buffer I/O error on dev sda1, logical block 60040706, async page read
[  111.561218]
[  111.561222] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[  111.564205] Buffer I/O error on dev sda1, logical block 60040707, async page read
[  111.570887] x14: 00000000000000f5 x13: 0000000000000001 x12: 0000000000000040
[  111.570902] x11: ffff0000c05ac6d8
[  111.583420] Buffer I/O error on dev sda1, logical block 60040708, async page read
[  111.588978]  x10: 0000000000000000 x9 : 0000000000040000
[  111.588988] x8 : 0000000000000000
[  111.597173] Buffer I/O error on dev sda1, logical block 60040709, async page read
[  111.605766]  x7 : ffff00017f384880 x6 : ffff8000118cb880
[  111.605777] x5 : ffff00017f384880
[  111.611094] Buffer I/O error on dev sda1, logical block 60040710, async page read
[  111.617086]  x4 : 0000000000000000 x3 : ffff0000c2a9f184
[  111.617096] x2 : ffff8000118cb880
[  111.622242] Buffer I/O error on dev sda1, logical block 60040711, async page read
[  111.626927]  x1 : ffff8000118cb880 x0 : ffff00017f384888
[  111.626938] Call trace:
[  111.626942]  queued_spin_lock_slowpath+0x1a0/0x390
[  111.795809]  kthread_queue_work+0x30/0xc0
[  111.799828]  state_machine_timer_handler+0x20/0x30
[  111.804624]  __hrtimer_run_queues+0x140/0x1e0
[  111.808990]  hrtimer_interrupt+0xec/0x2c0
[  111.813004]  arch_timer_handler_phys+0x38/0x50
[  111.817456]  handle_percpu_devid_irq+0x88/0x150
[  111.821991]  __handle_domain_irq+0x80/0xe0
[  111.826093]  gic_handle_irq+0xc0/0x140
[  111.829848]  el1_irq+0xbc/0x154
[  111.832991]  arch_cpu_idle+0x1c/0x2c
[  111.836572]  default_idle_call+0x24/0x6c
[  111.840497]  do_idle+0x238/0x2ac
[  111.843729]  cpu_startup_entry+0x2c/0x70
[  111.847657]  rest_init+0xdc/0xec
[  111.850890]  arch_call_rest_init+0x14/0x20
[  111.854988]  start_kernel+0x508/0x540
[  111.858659] Code: 910020e0 8b0200c2 f861d884 aa0203e1 (f8246827)
[  111.864760] ---[ end trace 308b9a4a3dcb73ac ]---
[  111.869381] Kernel panic - not syncing: Oops: Fatal exception in interrupt
[  111.876258] SMP: stopping secondary CPUs
[  111.880185] Kernel Offset: disabled
[  111.883673] CPU features: 0x00001001,20000846
[  111.888031] Memory Limit: none
[  111.891090] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---

Fixes: 3ed8e1c2 ("usb: typec: tcpm: Migrate workqueue to RT priority for processing events")
Cc: stable <stable@vger.kernel.org>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NLi Jun <jun.li@nxp.com>
Link: https://lore.kernel.org/r/1622627829-11070-1-git-send-email-jun.li@nxp.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nouyangxuexu <ouyangxuexu@163.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

8671fa0d

spi: Fix spi device unregister flow · 0ed6c4de

由 Saravana Kannan 提交于 4月 26, 2021

stable inclusion
from stable-v5.10.44
commit 01905f3232fdc0737de5c38e9d817f87a06a1a6d
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=347
CVE: NA

-------------------------------------------------

[ Upstream commit c7299fea ]

When an SPI device is unregistered, the spi->controller->cleanup() is
called in the device's release callback. That's wrong for a couple of
reasons:

1. spi_dev_put() can be called before spi_add_device() is called. And
   it's spi_add_device() that calls spi_setup(). This will cause clean()
   to get called without the spi device ever being setup.

2. There's no guarantee that the controller's driver would be present by
   the time the spi device's release function gets called.

3. It also causes "sleeping in atomic context" stack dump[1] when device
   link deletion code does a put_device() on the spi device.

Fix these issues by simply moving the cleanup from the device release
callback to the actual spi_unregister_device() function.

[1] - https://lore.kernel.org/lkml/CAHp75Vc=FCGcUyS0v6fnxme2YJ+qD+Y-hQDQLa2JhWNON9VmsQ@mail.gmail.com/Signed-off-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210426235638.1285530-1-saravanak@google.comSigned-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYu Hua Xiao <xiaoyuhua2332@163.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

0ed6c4de

ALSA: hda/realtek: fix mute/micmute LEDs for HP EliteBook 840 Aero G8 · f04afefe

由 Jeremy Szu 提交于 6月 05, 2021

stable inclusion
from stable-v5.10.44
commit d62d55f3941b99a88384ce764f70bc5865d42c06
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=458
CVE: NA

-------------------------------------------------

commit dfb06401 upstream.

The HP EliteBook 840 Aero G8 using ALC285 codec which using 0x04 to
control mute LED and 0x01 to control micmute LED.
In the other hand, there is no output from right channel of speaker.
Therefore, add a quirk to make it works.
Signed-off-by: NJeremy Szu <jeremy.szu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210605082539.41797-3-jeremy.szu@canonical.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nfeifei <zju_feifei@163.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

f04afefe

tools/bootconfig: Fix error return code in apply_xbc() · 01b6e160

由 Zhen Lei 提交于 5月 08, 2021

stable inclusion
from stable-v5.10.44
commit c9cb5837e92ee3052e0e46e3cd1eb1f7a903411d
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=451
CVE: NA

-------------------------------------------------

commit e8ba0b2b upstream.

Fix to return a negative error code from the error handling case instead
of 0, as done elsewhere in this function.

Link: https://lkml.kernel.org/r/20210508034216.2277-1-thunder.leizhen@huawei.com

Fixes: a995e6bc ("tools/bootconfig: Fix to check the write failure correctly")
Reported-by: NHulk Robot <hulkci@huawei.com>
Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NXiao <zju_xhy@163.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

01b6e160

ASoC: meson: gx-card: fix sound-dai dt schema · 9479babe

由 Jerome Brunet 提交于 5月 24, 2021

stable inclusion
from stable-v5.10.44
commit 62d891861f83ac12e1b00b304211faf3d1e24857
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=407
CVE: NA

-------------------------------------------------

commit d031d99b upstream.

There is a fair amount of warnings when running 'make dtbs_check' with
amlogic,gx-sound-card.yaml.

Ex:
arch/arm64/boot/dts/amlogic/meson-gxm-q200.dt.yaml: sound: dai-link-0:sound-dai:0:1: missing phandle tag in 0
arch/arm64/boot/dts/amlogic/meson-gxm-q200.dt.yaml: sound: dai-link-0:sound-dai:0:2: missing phandle tag in 0
arch/arm64/boot/dts/amlogic/meson-gxm-q200.dt.yaml: sound: dai-link-0:sound-dai:0: [66, 0, 0] is too long

The reason is that the sound-dai phandle provided has cells, and in such
case the schema should use 'phandle-array' instead of 'phandle'.

Fixes: fd00366b ("ASoC: meson: gx: add sound card dt-binding documentation")
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20210524093448.357140-1-jbrunet@baylibre.comSigned-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nyxh <yxh_yuanqi@163.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

9479babe

netlink: disable IRQs for netlink_lock_table() · 1e29968e

由 Johannes Berg 提交于 5月 17, 2021

stable inclusion
from stable-v5.10.44
commit 1d6d43d4805da9b3fa0f5841e8b1083c89868f35
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=369
CVE: NA

-------------------------------------------------

[ Upstream commit 1d482e66 ]

Syzbot reports that in mac80211 we have a potential deadlock
between our "local->stop_queue_reasons_lock" (spinlock) and
netlink's nl_table_lock (rwlock). This is because there's at
least one situation in which we might try to send a netlink
message with this spinlock held while it is also possible to
take the spinlock from a hardirq context, resulting in the
following deadlock scenario reported by lockdep:

       CPU0                    CPU1
       ----                    ----
  lock(nl_table_lock);
                               local_irq_disable();
                               lock(&local->queue_stop_reason_lock);
                               lock(nl_table_lock);
  <Interrupt>
    lock(&local->queue_stop_reason_lock);

This seems valid, we can take the queue_stop_reason_lock in
any kind of context ("CPU0"), and call ieee80211_report_ack_skb()
with the spinlock held and IRQs disabled ("CPU1") in some
code path (ieee80211_do_stop() via ieee80211_free_txskb()).

Short of disallowing netlink use in scenarios like these
(which would be rather complex in mac80211's case due to
the deep callchain), it seems the only fix for this is to
disable IRQs while nl_table_lock is held to avoid hitting
this scenario, this disallows the "CPU0" portion of the
reported deadlock.

Note that the writer side (netlink_table_grab()) already
disables IRQs for this lock.

Unfortunately though, this seems like a huge hammer, and
maybe the whole netlink table locking should be reworked.

Reported-by: syzbot+69ff9dff50dcfe14ddd4@syzkaller.appspotmail.com
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYuan yi Qi <yuanyi_qh@163.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

1e29968e

vfio-ccw: Serialize FSM IDLE state with I/O completion · c2b6e5e1

由 Eric Farman 提交于 5月 11, 2021

stable inclusion
from stable-v5.10.44
commit 01905f3232fdc0737de5c38e9d817f87a06a1a6d
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=349
CVE: NA

-------------------------------------------------

[ Upstream commit 2af7a834 ]

Today, the stacked call to vfio_ccw_sch_io_todo() does three things:

  1) Update a solicited IRB with CP information, and release the CP
     if the interrupt was the end of a START operation.
  2) Copy the IRB data into the io_region, under the protection of
     the io_mutex
  3) Reset the vfio-ccw FSM state to IDLE to acknowledge that
     vfio-ccw can accept more work.

The trouble is that step 3 is (A) invoked for both solicited and
unsolicited interrupts, and (B) sitting after the mutex for step 2.
This second piece becomes a problem if it processes an interrupt
for a CLEAR SUBCHANNEL while another thread initiates a START,
thus allowing the CP and FSM states to get out of sync. That is:

    CPU 1                           CPU 2
    fsm_do_clear()
    fsm_irq()
                                    fsm_io_request()
    vfio_ccw_sch_io_todo()
                                    fsm_io_helper()

Since the FSM state and CP should be kept in sync, let's make a
note when the CP is released, and rely on that as an indication
that the FSM should also be reset at the end of this routine and
open up the device for more work.
Signed-off-by: NEric Farman <farman@linux.ibm.com>
Acked-by: NMatthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Message-Id: <20210511195631.3995081-4-farman@linux.ibm.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: Nyilianxueer <yilianxueerl@163.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

c2b6e5e1

cgroup1: don't allow '\n' in renaming · b40b43b7

由 Alexander Kuznetsov 提交于 6月 09, 2021

stable inclusion
from stable-v5.10.44
commit 74d3b20b1b206a76f2cbccc5e09106adf6b5775c
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=415
CVE: NA

-------------------------------------------------

commit b7e24eb1 upstream.

cgroup_mkdir() have restriction on newline usage in names:
$ mkdir $'/sys/fs/cgroup/cpu/test\ntest2'
mkdir: cannot create directory
'/sys/fs/cgroup/cpu/test\ntest2': Invalid argument

But in cgroup1_rename() such check is missed.
This allows us to make /proc/<pid>/cgroup unparsable:
$ mkdir /sys/fs/cgroup/cpu/test
$ mv /sys/fs/cgroup/cpu/test $'/sys/fs/cgroup/cpu/test\ntest2'
$ echo $$ > $'/sys/fs/cgroup/cpu/test\ntest2'
$ cat /proc/self/cgroup
11:pids:/
10:freezer:/
9:hugetlb:/
8:cpuset:/
7:blkio:/user.slice
6:memory:/user.slice
5:net_cls,net_prio:/
4:perf_event:/
3:devices:/user.slice
2:cpu,cpuacct:/test
test2
1:name=systemd:/
0::/
Signed-off-by: NAlexander Kuznetsov <wwfq@yandex-team.ru>
Reported-by: NAndrey Krasichkov <buglloc@yandex-team.ru>
Acked-by: NDmitry Yakunin <zeil@yandex-team.ru>
Cc: stable@vger.kernel.org
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nyinzixiang <yinzixiang1231@163.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

b40b43b7

mmc: renesas_sdhi: abort tuning when timeout detected · 043cc663

由 Wolfram Sang 提交于 6月 02, 2021

stable inclusion
from stable-v5.10.44
commit 67aca230caf346ddf608ee69469777cd52929493
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=408
CVE: NA

-------------------------------------------------

commit 2c9017d0 upstream.

We have to bring the eMMC from sending-data state back to transfer state
once we detected a CRC error (timeout) during tuning. So, send a stop
command via mmc_abort_tuning().

Fixes: 4f119977 ("mmc: tmio: Add tuning support")
Reported-by Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20210602073435.5955-1-wsa+renesas@sang-engineering.com
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NWangQiQin <wangqiqin111@163.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

043cc663

usb: f_ncm: only first packet of aggregate needs to start timer · 5e786692

由 Maciej Żenczykowski 提交于 6月 08, 2021

stable inclusion
from stable-v5.10.44
commit 0ff5f83ae147e63c297e0a5515c9c271b7448f6f
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=359
CVE: NA

-------------------------------------------------

commit 1958ff5a upstream.

The reasoning for this change is that if we already had
a packet pending, then we also already had a pending timer,
and as such there is no need to reschedule it.

This also prevents packets getting delayed 60 ms worst case
under a tiny packet every 290us transmit load, by keeping the
timeout always relative to the first queued up packet.
(300us delay * 16KB max aggregation / 80 byte packet =~ 60 ms)

As such the first packet is now at most delayed by 300us.

Under low transmit load, this will simply result in us sending
a shorter aggregate, as originally intended.

This patch has the benefit of greatly reducing (by ~10 factor
with 1500 byte frames aggregated into 16 kiB) the number of
(potentially pretty costly) updates to the hrtimer.

Cc: Brooke Basile <brookebasile@gmail.com>
Cc: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: NMaciej Żenczykowski <maze@google.com>
Link: https://lore.kernel.org/r/20210608085438.813960-1-zenczykowski@gmail.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYinXiaoHan <yinxiaohan123321@163.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

5e786692

sched/fair: Keep load_avg and load_sum synced · 9cc06a14

由 Vincent Guittot 提交于 5月 27, 2021

stable inclusion
from stable-v5.10.44
commit 4c37b062edae8ad3e1f279ecc084f254bc8161ae
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=394
CVE: NA

-------------------------------------------------

commit 7c7ad626 upstream.

when removing a cfs_rq from the list we only check _sum value so we must
ensure that _avg and _sum stay synced so load_sum can't be null whereas
load_avg is not after propagating load in the cgroup hierarchy.

Use load_avg to compute load_sum similarly to what is done for util_sum
and runnable_sum.

Fixes: 0e2d2aaa ("sched/fair: Rewrite PELT migration propagation")
Reported-by: NOdin Ugedal <odin@uged.al>
Signed-off-by: NVincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: NOdin Ugedal <odin@uged.al>
Link: https://lkml.kernel.org/r/20210527122916.27683-2-vincent.guittot@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nxx_xiaohang~ <1623836996@qq.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

9cc06a14

ASoC: sti-sas: add missing MODULE_DEVICE_TABLE · af7b63da

由 Zou Wei 提交于 5月 12, 2021

stable inclusion
from stable-v5.10.44
commit 369f3caa4d74380efdbf614a01de067171fa19a1
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=381
CVE: NA

-------------------------------------------------

[ Upstream commit e072b267 ]

This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NZou Wei <zou_wei@huawei.com>
Link: https://lore.kernel.org/r/1620789145-14936-1-git-send-email-zou_wei@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: Nyihanjing <1271728396@qq.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

af7b63da

drm: Fix use-after-free read in drm_getunique() · af679791

由 Desmond Cheong Zhi Xi 提交于 6月 08, 2021

stable inclusion
from stable-v5.10.44
commit 491d52e0078860b33b6c14f0a7ac74ca1b603bd6
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=390
CVE: NA

-------------------------------------------------

commit b436acd1 upstream.

There is a time-of-check-to-time-of-use error in drm_getunique() due
to retrieving file_priv->master prior to locking the device's master
mutex.

An example can be seen in the crash report of the use-after-free error
found by Syzbot:
https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803

In the report, the master pointer was used after being freed. This is
because another process had acquired the device's master mutex in
drm_setmaster_ioctl(), then overwrote fpriv->master in
drm_new_set_master(). The old value of fpriv->master was subsequently
freed before the mutex was unlocked.

To fix this, we lock the device's master mutex before retrieving the
pointer from from fpriv->master. This patch passes the Syzbot
reproducer test.

Reported-by: syzbot+c3a706cec1ea99e1c693@syzkaller.appspotmail.com
Signed-off-by: NDesmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210608110436.239583-1-desmondcheongzx@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NCwj <161434832@qq.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

af679791

NFS: Fix use-after-free in nfs4_init_client() · e66ad26f

由 Anna Schumaker 提交于 6月 02, 2021

stable inclusion
from stable-v5.10.44
commit c3b6cf64dfe4ef96e7341508d50d6998da7062c7
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=449
CVE: NA

-------------------------------------------------

commit 476bdb04 upstream.

KASAN reports a use-after-free when attempting to mount two different
exports through two different NICs that belong to the same server.

Olga was able to hit this with kernels starting somewhere between 5.7
and 5.10, but I traced the patch that introduced the clear_bit() call to
4.13. So something must have changed in the refcounting of the clp
pointer to make this call to nfs_put_client() the very last one.

Fixes: 8dcbec6d ("NFSv41: Handle EXCHID4_FLAG_CONFIRMED_R during NFSv4.1 migration")
Cc: stable@vger.kernel.org # 4.13+
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NKK <323291357@qq.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

e66ad26f

drm/mcde: Fix off by 10^3 in calculation · 996cf07f

由 Linus Walleij 提交于 6月 08, 2021

stable inclusion
from stable-v5.10.44
commit 5a61f69da3b8d735b01dddee72fee4671510d907
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=402
CVE: NA

-------------------------------------------------

commit c8a57044 upstream.

The calclulation of how many bytes we stuff into the
DSI pipeline for video mode panels is off by three
orders of magnitude because we did not account for the
fact that the DRM mode clock is in kilohertz rather
than hertz.

This used to be:
drm_mode_vrefresh(mode) * mode->htotal * mode->vtotal
which would become for example for s6e63m0:
60 x 514 x 831 = 25628040 Hz, but mode->clock is
25628 as it is in kHz.

This affects only the Samsung GT-I8190 "Golden" phone
right now since it is the only MCDE device with a video
mode display.

Curiously some specimen work with this code and wild
settings in the EOL and empty packets at the end of the
display, but I have noticed an eeire flicker until now.
Others were not so lucky and got black screens.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-by: NStephan Gerhold <stephan@gerhold.net>
Fixes: 920dd1b1 ("drm/mcde: Use mode->clock instead of reverse calculating it from the vrefresh")
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NStephan Gerhold <stephan@gerhold.net>
Reviewed-by: NStephan Gerhold <stephan@gerhold.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20210608213318.3897858-1-linus.walleij@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJiaoyu <895515570@qq.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

996cf07f

vfio-ccw: Reset FSM state to IDLE inside FSM · d8d022cb

由 Eric Farman 提交于 5月 11, 2021

stable inclusion
from stable-v5.10.44
commit cad3dc73c0645d00adfe96cebc8d950897cc1227
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=453
CVE: NA

-------------------------------------------------

[ Upstream commit 6c02ac4c ]

When an I/O request is made, the fsm_io_request() routine
moves the FSM state from IDLE to CP_PROCESSING, and then
fsm_io_helper() moves it to CP_PENDING if the START SUBCHANNEL
received a cc0. Yet, the error case to go from CP_PROCESSING
back to IDLE is done after the FSM call returns.

Let's move this up into the FSM proper, to provide some
better symmetry when unwinding in this case.
Signed-off-by: NEric Farman <farman@linux.ibm.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NMatthew Rosato <mjrosato@linux.ibm.com>
Message-Id: <20210511195631.3995081-3-farman@linux.ibm.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYuanHuiQ <3552253686@qq.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

d8d022cb

MIPS: Fix kernel hang under FUNCTION_GRAPH_TRACER and PREEMPT_TRACER · f891051d

由 Tiezhu Yang 提交于 5月 15, 2021

stable inclusion
from stable-v5.10.44
commit 7519ece673e300b0362572edbde7e030552705ec
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=417
CVE: NA

-------------------------------------------------

[ Upstream commit 78cf0eb9 ]

When update the latest mainline kernel with the following three configs,
the kernel hangs during startup:

(1) CONFIG_FUNCTION_GRAPH_TRACER=y
(2) CONFIG_PREEMPT_TRACER=y
(3) CONFIG_FTRACE_STARTUP_TEST=y

When update the latest mainline kernel with the above two configs (1)
and (2), the kernel starts normally, but it still hangs when execute
the following command:

echo "function_graph" > /sys/kernel/debug/tracing/current_tracer

Without CONFIG_PREEMPT_TRACER=y, the above two kinds of kernel hangs
disappeared, so it seems that CONFIG_PREEMPT_TRACER has some influences
with function_graph tracer at the first glance.

I use ejtag to find out the epc address is related with preempt_enable()
in the file arch/mips/lib/mips-atomic.c, because function tracing can
trace the preempt_{enable,disable} calls that are traced, replace them
with preempt_{enable,disable}_notrace to prevent function tracing from
going into an infinite loop, and then it can fix the kernel hang issue.

By the way, it seems that this commit is a complement and improvement of
commit f93a1a00 ("MIPS: Fix crash that occurs when function tracing
is enabled").
Signed-off-by: NTiezhu Yang <yangtiezhu@loongson.cn>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYou Jia <jiayou@zju.edu.cn>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

f891051d

tracing: Correct the length check which causes memory corruption · 26c99e52

由 Liangyan 提交于 10月 18, 2021

stable inclusion
from stable-v5.10.44
commit 43c32c22254b9328d7abb1c2b0f689dc67838e60
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=344
CVE: NA

--------------------------------

commit 3e08a9f9 upstream.

We've suffered from severe kernel crashes due to memory corruption on
our production environment, like,

Call Trace:
[1640542.554277] general protection fault: 0000 [#1] SMP PTI
[1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G
[1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190
[1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286
[1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX:
0000000006e931bf
[1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI:
ffff9a45ff004300
[1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09:
0000000000000000
[1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12:
ffffffff9a20608d
[1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15:
696c662f65636976
[1640542.563128] FS:  00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000)
knlGS:0000000000000000
[1640542.563937] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4:
00000000003606e0
[1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[1640542.566742] Call Trace:
[1640542.567009]  anon_vma_clone+0x5d/0x170
[1640542.567417]  __split_vma+0x91/0x1a0
[1640542.567777]  do_munmap+0x2c6/0x320
[1640542.568128]  vm_munmap+0x54/0x70
[1640542.569990]  __x64_sys_munmap+0x22/0x30
[1640542.572005]  do_syscall_64+0x5b/0x1b0
[1640542.573724]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[1640542.575642] RIP: 0033:0x7f45d6e61e27

James Wang has reproduced it stably on the latest 4.19 LTS.
After some debugging, we finally proved that it's due to ftrace
buffer out-of-bound access using a debug tool as follows:
[   86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000
[   86.780806]  no_context+0xdf/0x3c0
[   86.784327]  __do_page_fault+0x252/0x470
[   86.788367]  do_page_fault+0x32/0x140
[   86.792145]  page_fault+0x1e/0x30
[   86.795576]  strncpy_from_unsafe+0x66/0xb0
[   86.799789]  fetch_memory_string+0x25/0x40
[   86.804002]  fetch_deref_string+0x51/0x60
[   86.808134]  kprobe_trace_func+0x32d/0x3a0
[   86.812347]  kprobe_dispatcher+0x45/0x50
[   86.816385]  kprobe_ftrace_handler+0x90/0xf0
[   86.820779]  ftrace_ops_assist_func+0xa1/0x140
[   86.825340]  0xffffffffc00750bf
[   86.828603]  do_sys_open+0x5/0x1f0
[   86.832124]  do_syscall_64+0x5b/0x1b0
[   86.835900]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

commit b220c049 ("tracing: Check length before giving out
the filter buffer") adds length check to protect trace data
overflow introduced in 0fc1b09f, seems that this fix can't prevent
overflow entirely, the length check should also take the sizeof
entry->array[0] into account, since this array[0] is filled the
length of trace data and occupy addtional space and risk overflow.

Link: https://lkml.kernel.org/r/20210607125734.1770447-1-liangyan.peng@linux.alibaba.com

Cc: stable@vger.kernel.org
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Xunlei Pang <xlpang@linux.alibaba.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes: b220c049 ("tracing: Check length before giving out the filter buffer")
Reviewed-by: NXunlei Pang <xlpang@linux.alibaba.com>
Reviewed-by: Nyinbinbin <yinbinbin@alibabacloud.com>
Reviewed-by: NWetp Zhang <wetp.zy@linux.alibaba.com>
Tested-by: NJames Wang <jnwang@linux.alibaba.com>
Signed-off-by: NLiangyan <liangyan.peng@linux.alibaba.com>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: N李弘宇 <l543306408@bupt.edu.cn>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

26c99e52

proc: Track /proc/$pid/attr/ opener mm_struct · 5cfe20d0

由 Kees Cook 提交于 10月 18, 2021

stable inclusion
from stable-v5.10.44
commit f70102cb369cde6ab7551ca58152d00fd3478fec
bugzilla:
CVE: NA

--------------------------------

commit 591a22c1 upstream.

Commit bfb819ea ("proc: Check /proc/$pid/attr/ writes against file opener")
tried to make sure that there could not be a confusion between the opener of
a /proc/$pid/attr/ file and the writer. It used struct cred to make sure
the privileges didn't change. However, there were existing cases where a more
privileged thread was passing the opened fd to a differently privileged thread
(during container setup). Instead, use mm_struct to track whether the opener
and writer are still the same process. (This is what several other proc files
already do, though for different reasons.)
Reported-by: NChristian Brauner <christian.brauner@ubuntu.com>
Reported-by: NAndrea Righi <andrea.righi@canonical.com>
Tested-by: NAndrea Righi <andrea.righi@canonical.com>
Fixes: bfb819ea ("proc: Check /proc/$pid/attr/ writes against file opener")
Cc: stable@vger.kernel.org
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: bobo~ <931671772@qq.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

5cfe20d0

i2c: mpc: Make use of i2c_recover_bus() · 9bf9936d

由 Chris Packham 提交于 10月 18, 2021

stable inclusion
from stable-v5.10.44
commit d78b76af9f61f384526137d45e53cea0a1020132
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=460
CVE: NA

-------------------------------------------------

[ Upstream commit 65171b2d ]

Move the existing calls of mpc_i2c_fixup() to a recovery function
registered via bus_recovery_info. This makes it more obvious that
recovery is supported and allows for a future where recovery is
triggered by the i2c core.
Signed-off-by: NChris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: NWolfram Sang <wsa@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: Nzhujiahui <1907685700@qq.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

9bf9936d

ftrace: Do not blindly read the ip address in ftrace_bug() · 86478d47

由 Steven Rostedt (VMware) 提交于 10月 18, 2021

stable inclusion
from stable-v5.10.44
commit 97524384762c1fb9b3ded931498dd2047bd0de81
bugzilla: https://bugzilla.openeular.org/show_bug.cgi?id=429
CVE: NA

-------------------------------------------------

commit 6c14133d upstream.

It was reported that a bug on arm64 caused a bad ip address to be used for
updating into a nop in ftrace_init(), but the error path (rightfully)
returned -EINVAL and not -EFAULT, as the bug caused more than one error to
occur. But because -EINVAL was returned, the ftrace_bug() tried to report
what was at the location of the ip address, and read it directly. This
caused the machine to panic, as the ip was not pointing to a valid memory
address.

Instead, read the ip address with copy_from_kernel_nofault() to safely
access the memory, and if it faults, report that the address faulted,
otherwise report what was in that location.

Link: https://lore.kernel.org/lkml/20210607032329.28671-1-mark-pk.tsai@mediatek.com/

Cc: stable@vger.kernel.org
Fixes: 05736a42 ("ftrace: warn on failure to disable mcount callers")
Reported-by: NMark-PK Tsai <mark-pk.tsai@mediatek.com>
Tested-by: NMark-PK Tsai <mark-pk.tsai@mediatek.com>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: fzy <fzy_caesar_0910@163.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

86478d47

drm: Lock pointer access in drm_master_release() · 70500410

由 Desmond Cheong Zhi Xi 提交于 10月 18, 2021

stable inclusion
from stable-v5.10.44
commit aa8591a58cbd2986090709e4202881f18e8ae30e
bugzilla:https://bugzilla.openeuler.org/show_bug.cgi?id=435
CVE: NA

-------------------------------------------------

commit c336a5ee upstream.

This patch eliminates the following smatch warning:
drivers/gpu/drm/drm_auth.c:320 drm_master_release() warn: unlocked access 'master' (line 318) expected lock '&dev->master_mutex'

The 'file_priv->master' field should be protected by the mutex lock to
'&dev->master_mutex'. This is because other processes can concurrently
modify this field and free the current 'file_priv->master'
pointer. This could result in a use-after-free error when 'master' is
dereferenced in subsequent function calls to
'drm_legacy_lock_master_cleanup()' or to 'drm_lease_revoke()'.

An example of a scenario that would produce this error can be seen
from a similar bug in 'drm_getunique()' that was reported by Syzbot:
https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803

In the Syzbot report, another process concurrently acquired the
device's master mutex in 'drm_setmaster_ioctl()', then overwrote
'fpriv->master' in 'drm_new_set_master()'. The old value of
'fpriv->master' was subsequently freed before the mutex was unlocked.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDesmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210609092119.173590-1-desmondcheongzx@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nholmes <holmes@my.swjtu.edu.cn>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

70500410

bpf: Forbid trampoline attach for functions with variable arguments · aeffd8b4

由 Jiri Olsa 提交于 10月 18, 2021

stable inclusion
from stable-v5.10.44
commit 584b2c7ce24450a7c687f976b54333607e14e058
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=399
CVE: NA

-------------------------------------------------

[ Upstream commit 31379397 ]

We can't currently allow to attach functions with variable arguments.
The problem is that we should save all the registers for arguments,
which is probably doable, but if caller uses more than 6 arguments,
we need stack data, which will be wrong, because of the extra stack
frame we do in bpf trampoline, so we could crash.

Also currently there's malformed trampoline code generated for such
functions at the moment as described in:

  https://lore.kernel.org/bpf/20210429212834.82621-1-jolsa@kernel.org/Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Acked-by: NAndrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20210505132529.401047-1-jolsa@kernel.orgSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: Nwangruifeng <972063181@qq.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

aeffd8b4

arm64/mpam: fix device_errcode out of bounds · 020ee452

由 yin-xiujiang 提交于 10月 18, 2021

kylin inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4AHUH?from=project-issue
CVE: NA

---------------------------------------------------

the size of mpam_msc_err_str is _MPAM_NUM_ERRCODE,
so device_errcode needs to be less than _MPAM_NUM_ERRCODE.
Signed-off-by: Nyin-xiujiang <yinxiujiang@kylinos.cn>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

020ee452

arm64/mpam: add return value check for acpi_get_table() · d14ec468

由 mpiglet 提交于 10月 18, 2021

openEuler inclusion
category: bugfix
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=339
CVE: NA
Reference: https://gitee.com/openeuler/kernel/issues/I3U11D

---------------------------------------------------

This fix check return value of acpi_get_table().

MPAM driver need to check return value, thus we need to check
the return value of acpi_get_table(ACPI_SIG_PPTT, 0, &pptt).
Signed-off-by: Nmpiglet <mpiglet@outlook.com>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

d14ec468

perf stat: Add a new --quiet option to 'perf stat' · 30ab85ad

由 Andi Kleen 提交于 10月 18, 2021

mainline inclusion
from mainline-5.11
commit 55a4de94
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4CMQA
CVE: NA

--------------------------------

Add a new --quiet option to 'perf stat'. This is useful with 'perf stat
record' to write the data only to the perf.data file, which can lower
measurement overhead because the data doesn't need to be formatted.

On my 4C desktop:

  % time ./perf stat record  -e $(python -c 'print ",\
".join(["cycles"]*1000)')  -a -I 1000 sleep 5
  ...
  real    0m5.377s
  user    0m0.238s
  sys     0m0.452s
  % time ./perf stat record --quiet -e $(python -c 'print ",\
".join(["cycles"]*1000)')  -a -I 1000 sleep 5

  real    0m5.452s
  user    0m0.183s
  sys     0m0.423s

In this example it cuts the user time by 20%. On systems with more cores
the savings are higher.
Signed-off-by: NAndi Kleen <andi@firstfloor.org>
Acked-by: NJiri Olsa <jolsa@kernel.org>
Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
Link: http://lore.kernel.org/lkml/20201027002737.30942-1-andi@firstfloor.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Nyin-xiujiang <yinxiujiang@kylinos.cn>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

30ab85ad

arm64/mpam: fix the problem that the ret variable is not initialized · 8ead6437

由 wenzhiwei11 提交于 10月 18, 2021

kylin inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4AHUL?from=project-issue
CVE: NA

---------------------------------------------------

initialize the value "ret" in "schemata_list_init()"
Signed-off-by: N温志伟 <wenzhiwei@kylinos.cn>
Reviewed-by: Jian Cheng <cj.chengjian(a)huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

8ead6437

30 9月, 2021 1 次提交

tools/x86: Add a kcpuid tool to show raw CPU features · cf74629c

由 Feng Tang 提交于 3月 05, 2021

mainline inclusion
from mainline-5.13
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4CMB4
CVE: NA

--------------------------------------------------

End users frequently want to know what features their processor
supports, independent of what the kernel supports.

/proc/cpuinfo is great. It is omnipresent and since it is provided by
the kernel it is always as up to date as the kernel. But, it could be
ambiguous about processor features which can be disabled by the kernel
at boot-time or compile-time.

There are some user space tools showing more raw features, but they are
not bound with kernel, and go with distros. Many end users are still
using old distros with new kernels (upgraded by themselves), and may
not upgrade the distros only to get a newer tool.

So here arise the need for a new tool, which
  * shows raw CPU features read from the CPUID instruction
  * will be easier to update compared to existing userspace
    tooling (perhaps distributed like perf)
  * inherits "modern" kernel development process, in contrast to some
    of the existing userspace CPUID tools which are still being developed
    without git and distributed in tarballs from non-https sites.
  * Can produce output consistent with /proc/cpuinfo to make comparison
    easier.

The CPUID leaf definitions are kept in an .csv file which allows for
updating only that file to add support for new feature leafs.

This is based on prototype code from Borislav Petkov
(http://sr71.net/~dave/intel/stupid-cpuid.c).

 [ bp:
   - Massage, add #define _GNU_SOURCE to fix implicit declaration of
     function ‘strcasestr' warning
   - remove superfluous newlines
   - fallback to cpuid.csv in the current dir if none found
   - fix typos
   - move comments over the lines instead of sideways. ]

Originally-from: Borislav Petkov <bp@alien8.de>
Suggested-by: NDave Hansen <dave.hansen@intel.com>
Suggested-by: NBorislav Petkov <bp@alien8.de>
Signed-off-by: NFeng Tang <feng.tang@intel.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/1614928878-86075-1-git-send-email-feng.tang@intel.comSigned-off-by: NDianfang Zhang <zhangdianfang@huawei.com>
Signed-off-by: NXie XiuQi <xiexiuqi@huawei.com>

cf74629c

18 8月, 2021 2 次提交

net: mdiobus: get rid of a BUG_ON() · 734f7d8b

由 Dan Carpenter 提交于 8月 18, 2021

stable inclusion
from stable-v5.10.44
commit be23c4af3d8a1b986fe9b43b8966797653a76ca4
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=341
CVE: NA

--------------------------------

[ Upstream commit 1dde47a6 ]

We spotted a bug recently during a review where a driver was
unregistering a bus that wasn't registered, which would trigger this
BUG_ON().  Let's handle that situation more gracefully, and just print
a warning and return.

Reported-by: Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew(a)lunn.ch>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
Signed-off-by: wangqing <wangqing(a)uniontech.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

734f7d8b

usb: cdns3: Fix runtime PM imbalance on error · efc5ed35

由 Dinghao Liu 提交于 8月 18, 2021

stable inclusion
from stable-v5.10.44
commit 2f523cd4a9311cba629facc7d353eabbd492bd5b
bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=345
CVE: NA

--------------------------------

[ Upstream commit 07adc022 ]

When cdns3_gadget_start() fails, a pairing PM usage counter
decrement is needed to keep the counter balanced.

Signed-off-by: Dinghao Liu <dinghao.liu(a)zju.edu.cn>
Link: https://lore.kernel.org/r/20210412054908.7975-1-dinghao.liu(a)zju.edu.cn
Signed-off-by: Peter Chen <peter.chen(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
Signed-off-by: Xu Zehui <zehuixu(a)whu.edu.cn>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

efc5ed35

30 7月, 2021 1 次提交

seq_file: disallow extremely large seq buffer allocations · 5d1d42ae

由 Eric Sandeen 提交于 7月 30, 2021

stable inclusion
from stable-5.10.52
commit 174c34d9cda1b5818419b8f5a332ced10755e52f
bugzilla: 331
CVE: CVE-2021-33909

---------------------------------------------------------------

commit 8cae8cd8 upstream.

There is no reasonable need for a buffer larger than this, and it avoids
int overflow pitfalls.

Fixes: 058504ed ("fs/seq_file: fallback to vmalloc allocation")
Suggested-by: NAl Viro <viro@zeniv.linux.org.uk>
Reported-by: NQualys Security Advisory <qsa@qualys.com>
Signed-off-by: NEric Sandeen <sandeen@redhat.com>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

5d1d42ae

21 7月, 2021 6 次提交

mm: alloc pages for pmem from peer node · a24270cc

由 Shijie Luo 提交于 7月 21, 2021

euleros inclusion
category: feature
feature: etmem
bugzilla: 48246

-------------------------------------------------

Pmem is slower than dram. So alloc pages from pmem's peer
dram node to accelerate access to pmem page struct.
Signed-off-by: NShijie Luo <luoshijie1@huawei.com>
Signed-off-by: Kemeng Shi<shikemeng@huawei.com>
Reviewed-by: louhongxiang <louhongxiang@huawei.com
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

a24270cc

mm: introduce and export pgdat peer_node · 88da6696

由 Fan Du 提交于 7月 21, 2021

euleros inclusion
category: feature
feature: etmem
bugzilla: 48246

-------------------------------------------------

Each CPU socket can have 1 DRAM and 1 PMEM node, we call them "peer nodes".
Migration between DRAM and PMEM will by default happen between peer nodes.

It's a temp solution. In multiple memory layers, a node can have both
promotion and demotion targets instead of a single peer node. User space
may also be able to infer promotion/demotion targets based on future
HMAT info.
Signed-off-by: NFan Du <fan.du@intel.com>
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NShijie Luo <luoshijie1@huawei.com>
Signed-off-by: NKemeng Shi <shikemeng@huawei.com>
Reviewed-by: Nlouhongxiang <louhongxiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

88da6696

x86: hugepage: use nt copy hugepage to AEP in x86 · ca25518c

由 Kemeng Shi 提交于 7月 21, 2021

euleros inclusion
category: feature
feature: etmem
bugzilla: 48246

-------------------------------------------------

Add proc/sys/vm/hugepage_nocache_copy switch. Set 1 to copy hugepage
with movnt SSE instructoin if cpu support it. Set 0 to copy hugepage
as usual.
Signed-off-by: NKemeng Shi <shikemeng@huawei.com>
Reviewed-by: Nlouhongxiang <louhongxiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ca25518c

hugepage: add sysctl for hugepage alloc and mig · 08b7da3e

由 Kemeng Shi 提交于 7月 21, 2021

euleros inclusion
category: feature
feature: etmem
bugzilla: 48246

-------------------------------------------------

Add /proc/sys/kernel/hugepage_pmem_allocall switch. Set 1 to allowed all
memory in pmem could alloc for hugepage. Set 0(default) hugepage alloc is
limited by zone watermark as usual.
Add /proc/sys/kernel/hugepage_mig_noalloc switch. Set 1 to forbid new
hugepage alloc in hugepage migration when hugepage in dest node runs
out. Set 0(default) to allow hugepage alloc in hugepage migration as
usual.
Signed-off-by: NKemeng Shi <shikemeng@huawei.com>
Reviewed-by: Nlouhongxiang <louhongxiang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

08b7da3e

mm: export node type {pmem|dram} under /sys/bus/node · 533cc721

由 Fan Du 提交于 7月 21, 2021

euleros inclusion
category: feature
feature: etmem
bugzilla: 48246

-------------------------------------------------

User space migration daemon could check
/sys/bus/node/devices/nodeX/type for node type.

Software can interrogate node type for node memory type and distance
to get desirable target node in migration.

grep -r . /sys/devices/system/node/*/type
/sys/devices/system/node/node0/type:dram
/sys/devices/system/node/node1/type:dram
/sys/devices/system/node/node2/type:pmem
/sys/devices/system/node/node3/type:pmem

Along with next patch which export `peer_node`, migration daemon
could easily find the memory type of current node, and the target
node in case of migration.

grep -r . /sys/devices/system/node/*/peer_node
/sys/devices/system/node/node0/peer_node:2
/sys/devices/system/node/node1/peer_node:3
/sys/devices/system/node/node2/peer_node:0
/sys/devices/system/node/node3/peer_node:1
Signed-off-by: NFan Du <fan.du@intel.com>
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NKemeng Shi <shikemeng@huawei.com>
Reviewed-by: louhongxiang <louhongxiang@huawei.com
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

533cc721

acpi/numa: memorize pmem node from SRAT table · 08d0f054

由 Kemeng Shi 提交于 7月 21, 2021

euleros inclusion
category: feature
feature: etmem
bugzilla: 48246

-------------------------------------------------

Driver dax_kmem will export pmem as a NUMA node. This patch will
record node consists of persistent memory for futher use.
Signed-off-by: NKemeng Shi <shikemeng@huawei.com>
Reviewed-by: louhongxiang <louhongxiang@huawei.com
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

08d0f054

openeuler / Kernel 大约 2 年 前同步成功

openeuler / Kernel
大约 2 年前同步成功