Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 12 5月, 2021 1 次提交
  3. 04 5月, 2021 13 次提交
  5. 28 4月, 2021 2 次提交
    • L
      Fix misc new gcc warnings · e7c6e405
      由 Linus Torvalds 提交于 
      It seems like Fedora 34 ends up enabling a few new gcc warnings, notably
"-Wstringop-overread" and "-Warray-parameter".

Both of them cause what seem to be valid warnings in the kernel, where
we have array size mismatches in function arguments (that are no longer
just silently converted to a pointer to element, but actually checked).

This fixes most of the trivial ones, by making the function declaration
match the function definition, and in the case of intel_pm.c, removing
the over-specified array size from the argument declaration.

At least one 'stringop-overread' warning remains in the i915 driver, but
that one doesn't have the same obvious trivial fix, and may or may not
actually be indicative of a bug.

[ It was a mistake to upgrade one of my machines to Fedora 34 while
  being busy with the merge window, but if this is the extent of the
  compiler upgrade problems, things are better than usual    - Linus ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e7c6e405
    • A
      vfio/gvt: fix DRM_I915_GVT dependency on VFIO_MDEV · adaeb718
      由 Arnd Bergmann 提交于 
      The Kconfig dependency is incomplete since DRM_I915_GVT is a 'bool'
symbol that depends on the 'tristate' VFIO_MDEV. This allows a
configuration with VFIO_MDEV=m, DRM_I915_GVT=y and DRM_I915=y that
causes a link failure:

x86_64-linux-ld: drivers/gpu/drm/i915/gvt/gvt.o: in function `available_instances_show':
gvt.c:(.text+0x67a): undefined reference to `mtype_get_parent_dev'
x86_64-linux-ld: gvt.c:(.text+0x6a5): undefined reference to `mtype_get_type_group_id'
x86_64-linux-ld: drivers/gpu/drm/i915/gvt/gvt.o: in function `description_show':
gvt.c:(.text+0x76e): undefined reference to `mtype_get_parent_dev'
x86_64-linux-ld: gvt.c:(.text+0x799): undefined reference to `mtype_get_type_group_id'

Clarify the dependency by specifically disallowing the broken
configuration. If VFIO_MDEV is built-in, it will work, but if
VFIO_MDEV=m, the i915 driver cannot be built-in here.

Fixes: 07e543f4 ("vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV")
Fixes: 9169cff1 ("vfio/mdev: Correct the function signatures for the mdev_type_attributes")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Message-Id: <20210422133547.1861063-1-arnd@kernel.org>
Reviewed-by: NJason Gunthorpe <jgg@nvidia.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      adaeb718
  7. 26 4月, 2021 3 次提交
    • L
      drivers/block/null_blk/main: Fix a double free in null_init. · 72ce11dd
      由 Lv Yunlong 提交于 
      In null_init, null_add_dev(dev) is called.
In null_add_dev, it calls null_free_zoned_dev(dev) to free dev->zones
via kvfree(dev->zones) in out_cleanup_zone branch and returns err.
Then null_init accept the err code and then calls null_free_dev(dev).

But in null_free_dev(dev), dev->zones is freed again by
null_free_zoned_dev().

My patch set dev->zones to NULL in null_free_zoned_dev() after
kvfree(dev->zones) is called, to avoid the double free.

Fixes: 2984c868 ("nullb: factor disk parameters")
Signed-off-by: NLv Yunlong <lyl2019@mail.ustc.edu.cn>
Link: https://lore.kernel.org/r/20210426143229.7374-1-lyl2019@mail.ustc.edu.cnSigned-off-by: NJens Axboe <axboe@kernel.dk>
      72ce11dd
    • A
      mmc: block: Issue a cache flush only when it's enabled · 97fce126
      由 Avri Altman 提交于 
      In command queueing mode, the cache isn't flushed via the mmc_flush_cache()
function, but instead by issuing a CMDQ_TASK_MGMT (CMD48) with a
FLUSH_CACHE opcode. In this path, we need to check if cache has been
enabled, before deciding to flush the cache, along the lines of what's
being done in mmc_flush_cache().

To fix this problem, let's add a new bus ops callback ->cache_enabled() and
implement it for the mmc bus type. In this way, the mmc block device driver
can call it to know whether cache flushing should be done.

Fixes: 1e8e55b6 (mmc: block: Add CQE support)
Cc: stable@vger.kernel.org
Reported-by: NBrendan Peter <bpeter@lytx.com>
Signed-off-by: NAvri Altman <avri.altman@wdc.com>
Tested-by: NBrendan Peter <bpeter@lytx.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20210425060207.2591-2-avri.altman@wdc.com
Link: https://lore.kernel.org/r/20210425060207.2591-3-avri.altman@wdc.com
[Ulf: Squashed the two patches and made some minor updates]
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      97fce126
    • A
      memstick: r592: ignore kfifo_out() return code again · 2f156712
      由 Arnd Bergmann 提交于 
      A minor cleanup to address a clang warning removed an assigned
but unused local variable, but this now caused a gcc warning as
kfifo_out() is annotated to require checking its return code:

In file included from drivers/memstick/host/r592.h:13,
                 from drivers/memstick/host/r592.c:21:
drivers/memstick/host/r592.c: In function 'r592_flush_fifo_write':
include/linux/kfifo.h:588:1: error: ignoring return value of '__kfifo_uint_must_check_helper' declared with attribute 'warn_unused_result' [-Werror=unused-result]
  588 | __kfifo_uint_must_check_helper( \
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  589 | ({ \
      | ~~~~
  590 |         typeof((fifo) + 1) __tmp = (fifo); \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  591 |         typeof(__tmp->ptr) __buf = (buf); \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  592 |         unsigned long __n = (n); \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~
  593 |         const size_t __recsize = sizeof(*__tmp->rectype); \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  594 |         struct __kfifo *__kfifo = &__tmp->kfifo; \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  595 |         (__recsize) ?\
      |         ~~~~~~~~~~~~~~
  596 |         __kfifo_out_r(__kfifo, __buf, __n, __recsize) : \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  597 |         __kfifo_out(__kfifo, __buf, __n); \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  598 | }) \
      | ~~~~
  599 | )
      | ~
drivers/memstick/host/r592.c:367:9: note: in expansion of macro 'kfifo_out'
  367 |         kfifo_out(&dev->pio_fifo, buffer, 4);
      |         ^~~~~~~~~

The value was never checked here, and the purpose of the function
is only to flush the contents, so restore the old behavior but
add a cast to void and a comment, which hopefully warns with neither
gcc nor clang now.

If anyone has an idea for how to fix it without ignoring the return
code, that is probably better.

Fixes: 4b00ed3c ("memstick: r592: remove unused variable")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210421135215.3414589-1-arnd@kernel.orgSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      2f156712
  9. 24 4月, 2021 4 次提交
    • R
      irqchip/xilinx: Expose Kconfig option for Zynq/ZynqMP · debf69cf
      由 Robert Hancock 提交于 
      Previously the XILINX_INTC config option was hidden and only
auto-selected on the MicroBlaze platform. However, this IP can also be
used on the Zynq and ZynqMP platforms as a secondary cascaded
controller. Allow this option to be user-enabled on those platforms.
Signed-off-by: NRobert Hancock <robert.hancock@calian.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210423185853.2556087-1-robert.hancock@calian.com
      debf69cf
    • A
      platform/x86: gigabyte-wmi: add support for B550M AORUS PRO-P · e7882cd7
      由 Alexey Klimov 提交于 
      From: Alexey Klimov <klimov.linux@gmail.com>

Add the B550M AORUS PRO-P motherboard description to
gigabyte_wmi_known_working_platforms.
Signed-off-by: NAlexey Klimov <klimov.linux@gmail.com>
Acked-by: NThomas Weißschuh <thomas@weissschuh.net>
Link: https://lore.kernel.org/r/20210421234156.3942343-1-aklimov@redhat.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
      e7882cd7
    • P
      md/raid1: properly indicate failure when ending a failed write request · 2417b986
      由 Paul Clements 提交于 
      This patch addresses a data corruption bug in raid1 arrays using bitmaps.
Without this fix, the bitmap bits for the failed I/O end up being cleared.

Since we are in the failure leg of raid1_end_write_request, the request
either needs to be retried (R1BIO_WriteError) or failed (R1BIO_Degraded).

Fixes: eeba6809 ("md/raid1: end bio when the device faulty")
Cc: stable@vger.kernel.org # v5.2+
Signed-off-by: NPaul Clements <paul.clements@us.sios.com>
Signed-off-by: NSong Liu <song@kernel.org>
      2417b986
    • H
      md-cluster: fix use-after-free issue when removing rdev · f7c7a2f9
      由 Heming Zhao 提交于 
      md_kick_rdev_from_array will remove rdev, so we should
use rdev_for_each_safe to search list.

How to trigger:

env: Two nodes on kvm-qemu x86_64 VMs (2C2G with 2 iscsi luns).

```
node2=192.168.0.3

for i in {1..20}; do
    echo ==== $i `date` ====;

    mdadm -Ss && ssh ${node2} "mdadm -Ss"
    wipefs -a /dev/sda /dev/sdb

    mdadm -CR /dev/md0 -b clustered -e 1.2 -n 2 -l 1 /dev/sda \
       /dev/sdb --assume-clean
    ssh ${node2} "mdadm -A /dev/md0 /dev/sda /dev/sdb"
    mdadm --wait /dev/md0
    ssh ${node2} "mdadm --wait /dev/md0"

    mdadm --manage /dev/md0 --fail /dev/sda --remove /dev/sda
    sleep 1
done
```

Crash stack:

```
stack segment: 0000 [#1] SMP
... ...
RIP: 0010:md_check_recovery+0x1e8/0x570 [md_mod]
... ...
RSP: 0018:ffffb149807a7d68 EFLAGS: 00010207
RAX: 0000000000000000 RBX: ffff9d494c180800 RCX: ffff9d490fc01e50
RDX: fffff047c0ed8308 RSI: 0000000000000246 RDI: 0000000000000246
RBP: 6b6b6b6b6b6b6b6b R08: ffff9d490fc01e40 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000
R13: ffff9d494c180818 R14: ffff9d493399ef38 R15: ffff9d4933a1d800
FS:  0000000000000000(0000) GS:ffff9d494f700000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe68cab9010 CR3: 000000004c6be001 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 raid1d+0x5c/0xd40 [raid1]
 ? finish_task_switch+0x75/0x2a0
 ? lock_timer_base+0x67/0x80
 ? try_to_del_timer_sync+0x4d/0x80
 ? del_timer_sync+0x41/0x50
 ? schedule_timeout+0x254/0x2d0
 ? md_start_sync+0xe0/0xe0 [md_mod]
 ? md_thread+0x127/0x160 [md_mod]
 md_thread+0x127/0x160 [md_mod]
 ? wait_woken+0x80/0x80
 kthread+0x10d/0x130
 ? kthread_park+0xa0/0xa0
 ret_from_fork+0x1f/0x40
```

Fixes: dbb64f86 ("md-cluster: Fix adding of new disk with new reload code")
Fixes: 659b254f ("md-cluster: remove a disk asynchronously from cluster environment")
Cc: stable@vger.kernel.org
Reviewed-by: NGang He <ghe@suse.com>
Signed-off-by: NHeming Zhao <heming.zhao@suse.com>
Signed-off-by: NSong Liu <song@kernel.org>
      f7c7a2f9
  11. 23 4月, 2021 17 次提交