- 09 2月, 2021 29 次提交
-
-
由 Janosch Frank 提交于
stable inclusion from stable-5.10.13 commit 9218a6b031a163a8b7372d8f137a46205f2d97f6 bugzilla: 47995 -------------------------------- commit e82080e1 upstream. The number reported by the query is N-1 and I think people reading the sysfs file would expect N instead. For users creating VMs there's no actual difference because KVM's limit is currently below the UV's limit. Signed-off-by: NJanosch Frank <frankja@linux.ibm.com> Fixes: a0f60f84 ("s390/protvirt: Add sysfs firmware interface for Ultravisor information") Cc: stable@vger.kernel.org Reviewed-by: NClaudio Imbrenda <imbrenda@linux.ibm.com> Acked-by: NCornelia Huck <cohuck@redhat.com> Signed-off-by: NVasily Gorbik <gor@linux.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Giacinto Cifelli 提交于
stable inclusion from stable-5.10.13 commit 6c6bd9dd1c8d45db80614b24a0667950ffdb9714 bugzilla: 47995 -------------------------------- commit 7e0e63d0 upstream. Bus 003 Device 009: ID 1e2d:006f Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x1e2d idProduct 0x006f bcdDevice 0.00 iManufacturer 3 Cinterion Wireless Modules iProduct 2 PLSx3 iSerial 4 fa3c1419 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 303 bNumInterfaces 9 bConfigurationValue 1 iConfiguration 1 Cinterion Configuration bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 500mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 1 CDC Union: bMasterInterface 0 bSlaveInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 2 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 3 CDC Union: bMasterInterface 2 bSlaveInterface 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 4 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 5 CDC Union: bMasterInterface 4 bSlaveInterface 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 6 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 6 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 7 CDC Union: bMasterInterface 6 bSlaveInterface 7 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 7 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 8 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x89 EP 9 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8a EP 10 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) Cc: stable@vger.kernel.org Signed-off-by: NGiacinto Cifelli <gciofono@gmail.com> Acked-by: NBjørn Mork <bjorn@mork.no> Link: https://lore.kernel.org/r/20210120045650.10855-1-gciofono@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Coly Li 提交于
stable inclusion from stable-5.10.13 commit 1a39162bac95bfd8730120a9b79f12b5b41e265c bugzilla: 47995 -------------------------------- commit 0df28cad upstream. For super block version < BCACHE_SB_VERSION_CDEV_WITH_FEATURES, it doesn't make sense to check the feature sets. This patch checks super block version in bch_has_feature_* routines, if the version doesn't have feature sets yet, returns 0 (false) to the caller. Fixes: 5342fd42 ("bcache: set bcache device into read-only mode for BCH_FEATURE_INCOMPAT_OBSO_LARGE_BUCKET") Fixes: ffa47032 ("bcache: add bucket_size_hi into struct cache_sb_disk for large bucket") Cc: stable@vger.kernel.org # 5.9+ Reported-and-tested-by: NBockholdt Arne <a.bockholdt@precitec-optronik.de> Signed-off-by: NColy Li <colyli@suse.de> Signed-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Lyude Paul 提交于
stable inclusion from stable-5.10.13 commit cc11bd18d4a31abd419f502aded67da1c73e2678 bugzilla: 47995 -------------------------------- commit 7c6d6598 upstream. Nvidia hardware doesn't actually support using tiling formats with the cursor plane, only linear is allowed. In the future, we should write a testcase for this. Fixes: c586f30b ("drm/nouveau/kms: Add format mod prop to base/ovly/nvdisp") Cc: James Jones <jajones@nvidia.com> Cc: Martin Peres <martin.peres@free.fr> Cc: Jeremy Cline <jcline@redhat.com> Cc: Simon Ser <contact@emersion.fr> Cc: <stable@vger.kernel.org> # v5.8+ Signed-off-by: NLyude Paul <lyude@redhat.com> Reviewed-by: NSimon Ser <contact@emersion.fr> Reviewed-by: NJames Jones <jajones@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Chris Wilson 提交于
stable inclusion from stable-5.10.13 commit 29d35b73ead4e41aa0d1a954c9bfbdce659ec5d6 bugzilla: 47995 -------------------------------- commit 489140b5 upstream. Since writing to address 0 is a very common mistake, let's try to avoid putting anything sensitive there. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2989Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210125125033.23656-1-chris@chris-wilson.co.uk Cc: stable@vger.kernel.org (cherry picked from commit 56b429cc584c6ed8b895d8d8540959655db1ff73) Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Chris Wilson 提交于
stable inclusion from stable-5.10.13 commit aa39818d92564ff2a52a40685e363439b9833959 bugzilla: 47995 -------------------------------- commit f6e98a18 upstream. The first thing the active retirement worker does is decrement the i915_active count. The first thing we do during i915_active_wait is try to increment the i915_active count, but only if already active [non-zero]. The wait may see that the retirement is already started and so marked the i915_active as idle, and skip waiting for the retirement handler. However, the caller of i915_active_wait may immediately free the i915_active upon returning (e.g. i915_vma_destroy) so we must not return before the concurrent access from the worker is completed. We must always flush the worker. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2473 Fixes: 274cbf20 ("drm/i915: Push the i915_active.retire into a worker") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.5+ Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210121232807.16618-1-chris@chris-wilson.co.uk (cherry picked from commit 977a372e972cb42799746c284035a33c64ebace9) Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Lyude Paul 提交于
stable inclusion from stable-5.10.13 commit 5ebb1cbe463f85c32f7bb584b661930ec3edb685 bugzilla: 47995 -------------------------------- commit ba839b75 upstream. While we do handle the additional cursor sizes introduced in NVE4, it looks like we accidentally broke this when converting over to use Nvidia's display headers. Since we now use NVVAL in dispnv50/head907d.c in order to format the value for the cursor layout and NVD9 only had one byte reserved vs. the 2 bytes reserved in later generations, we end up accidentally stripping the second bit in the cursor layout format parameter - causing us to set the wrong cursor size. This fixes that by adding our own curs_set hook for 917d which uses the NV917D headers. Cc: Martin Peres <martin.peres@free.fr> Cc: Jeremy Cline <jcline@redhat.com> Cc: Simon Ser <contact@emersion.fr> Cc: <stable@vger.kernel.org> # v5.9+ Signed-off-by: NLyude Paul <lyude@redhat.com> Fixes: ed0b86a9 ("drm/nouveau/kms/nv50-: use NVIDIA's headers for core head_curs_set()") Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Alex Deucher 提交于
stable inclusion from stable-5.10.13 commit 0634449e9977c74c4bb32564ea3faf925d60039f bugzilla: 47995 -------------------------------- commit a119f87b upstream. On some boards the rpm interface apparently does not work at all leading to the fan not spinning or spinning at strange speeds. Revert this for now to fix 5.10, 5.11. The follow on patch fixes this properly for 5.12. This reverts commit 8d6e65ad. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1408Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Jaroslav Kysela 提交于
stable inclusion from stable-5.10.13 commit 39714b66a8b15a4953f75afdd1c457990b20d0a8 bugzilla: 47995 -------------------------------- commit 40caffd6 upstream. Apparently, the DMI board name LNVNB161216 is also used also for products with the digital microphones connected to the AMD's audio bridge. Refine the DMI table - use product name identifiers extracted from https://bugzilla.redhat.com/show_bug.cgi?id=1892115 . The report for Lenovo Yoga Slim 7 14ARE05 (82A2) is in buglink. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211299 Cc: <stable@kernel.org> Signed-off-by: NJaroslav Kysela <perex@perex.cz> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210120144211.817937-1-perex@perex.czSigned-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Juergen Gross 提交于
stable inclusion from stable-5.10.13 commit b444b86e37b296a8ed18479d5b17df9b84cd26a8 bugzilla: 47995 -------------------------------- commit 2e924936 upstream. When booting a kernel which has been built with CONFIG_AMD_MEM_ENCRYPT enabled as a Xen pv guest a warning is issued for each processor: [ 5.964347] ------------[ cut here ]------------ [ 5.968314] WARNING: CPU: 0 PID: 1 at /home/gross/linux/head/arch/x86/xen/enlighten_pv.c:660 get_trap_addr+0x59/0x90 [ 5.972321] Modules linked in: [ 5.976313] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 5.11.0-rc5-default #75 [ 5.980313] Hardware name: Dell Inc. OptiPlex 9020/0PC5F7, BIOS A05 12/05/2013 [ 5.984313] RIP: e030:get_trap_addr+0x59/0x90 [ 5.988313] Code: 42 10 83 f0 01 85 f6 74 04 84 c0 75 1d b8 01 00 00 00 c3 48 3d 00 80 83 82 72 08 48 3d 20 81 83 82 72 0c b8 01 00 00 00 eb db <0f> 0b 31 c0 c3 48 2d 00 80 83 82 48 ba 72 1c c7 71 1c c7 71 1c 48 [ 5.992313] RSP: e02b:ffffc90040033d38 EFLAGS: 00010202 [ 5.996313] RAX: 0000000000000001 RBX: ffffffff82a141d0 RCX: ffffffff8222ec38 [ 6.000312] RDX: ffffffff8222ec38 RSI: 0000000000000005 RDI: ffffc90040033d40 [ 6.004313] RBP: ffff8881003984a0 R08: 0000000000000007 R09: ffff888100398000 [ 6.008312] R10: 0000000000000007 R11: ffffc90040246000 R12: ffff8884082182a8 [ 6.012313] R13: 0000000000000100 R14: 000000000000001d R15: ffff8881003982d0 [ 6.016316] FS: 0000000000000000(0000) GS:ffff888408200000(0000) knlGS:0000000000000000 [ 6.020313] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.024313] CR2: ffffc900020ef000 CR3: 000000000220a000 CR4: 0000000000050660 [ 6.028314] Call Trace: [ 6.032313] cvt_gate_to_trap.part.7+0x3f/0x90 [ 6.036313] ? asm_exc_double_fault+0x30/0x30 [ 6.040313] xen_convert_trap_info+0x87/0xd0 [ 6.044313] xen_pv_cpu_up+0x17a/0x450 [ 6.048313] bringup_cpu+0x2b/0xc0 [ 6.052313] ? cpus_read_trylock+0x50/0x50 [ 6.056313] cpuhp_invoke_callback+0x80/0x4c0 [ 6.060313] _cpu_up+0xa7/0x140 [ 6.064313] cpu_up+0x98/0xd0 [ 6.068313] bringup_nonboot_cpus+0x4f/0x60 [ 6.072313] smp_init+0x26/0x79 [ 6.076313] kernel_init_freeable+0x103/0x258 [ 6.080313] ? rest_init+0xd0/0xd0 [ 6.084313] kernel_init+0xa/0x110 [ 6.088313] ret_from_fork+0x1f/0x30 [ 6.092313] ---[ end trace be9ecf17dceeb4f3 ]--- Reason is that there is no Xen pv trap entry for X86_TRAP_VC. Fix that by adding a generic trap handler for unknown traps and wire all unknown bare metal handlers to this generic handler, which will just crash the system in case such a trap will ever happen. Fixes: 0786138c ("x86/sev-es: Add a Runtime #VC Exception Handler") Cc: <stable@vger.kernel.org> # v5.10 Signed-off-by: NJuergen Gross <jgross@suse.com> Reviewed-by: NAndrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: NJuergen Gross <jgross@suse.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Johannes Berg 提交于
stable inclusion from stable-5.10.13 commit d16c5dfe93ef12bd571a6c478a7ab6ea57925839 bugzilla: 47995 -------------------------------- commit 51225651 upstream. Since cfg80211 doesn't implement commit, we never really cared about that code there (and it's configured out w/o CONFIG_WIRELESS_EXT). After all, since it has no commit, it shouldn't return -EIWCOMMIT to indicate commit is needed. However, EIWCOMMIT is actually an alias for EINPROGRESS, which _can_ happen if e.g. we try to change the frequency but we're already in the process of connecting to some network, and drivers could return that value (or even cfg80211 itself might). This then causes us to crash because dev->wireless_handlers is NULL but we try to check dev->wireless_handlers->standard[0]. Fix this by also checking dev->wireless_handlers. Also simplify the code a little bit. Cc: stable@vger.kernel.org Reported-by: syzbot+444248c79e117bc99f46@syzkaller.appspotmail.com Reported-by: syzbot+8b2a88a09653d4084179@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20210121171621.2076e4a37d5a.I5d9c72220fe7bb133fb718751da0180a57ecba4e@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Koen Vandeputte 提交于
stable inclusion from stable-5.10.13 commit 442278e4928ee2ce0cfae1064612e1f0b580d43a bugzilla: 47995 -------------------------------- commit 5a22747b upstream. 2 regulator descriptions carry identical naming. This leads to following boot warning: [ 0.173138] debugfs: Directory 'vdd1p8' with parent 'regulator' already present! Fix this by renaming the one used for audio. Fixes: 5051bff3 ("ARM: dts: imx: ventana: add LTC3676 PMIC support") Signed-off-by: NTim Harvey <tharvey@gateworks.com> Signed-off-by: NKoen Vandeputte <koen.vandeputte@ncentric.com> Cc: stable@vger.kernel.org # v4.11 Signed-off-by: NShawn Guo <shawnguo@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Linus Walleij 提交于
stable inclusion from stable-5.10.13 commit a9079d8d3b02f30aca58db15590e14f3570798f7 bugzilla: 47995 -------------------------------- commit 8a996b2d upstream. The Ux500 platforms have some memory carveouts set aside for communicating with the modem and for the initial secure software (ISSW). These areas are protected by the memory controller and will result in an external abort if accessed like common read/write memory. On the legacy boot loaders, these were set aside by using cmdline arguments such as this: mem=96M@0 mem_mtrace=15M@96M mem_mshared=1M@111M mem_modem=16M@112M mali.mali_mem=32M@128M mem=96M@160M hwmem=127M@256M mem_issw=1M@383M mem_ram_console=1M@384M mem=638M@385M Reserve the relevant areas in the device tree instead. The "mali", "hwmem", "mem_ram_console" and the trailing 1MB at the end of the memory reservations in the list are not relevant for the upstream kernel as these are nowadays replaced with upstream technologies such as CMA. The modem and ISSW reservations are necessary. This was manifested in a bug that surfaced in response to commit 7fef431b ("mm/page_alloc: place pages to tail in __free_pages_core()") which changes the behaviour of memory allocations in such a way that the platform will sooner run into these dangerous areas, with "Unhandled fault: imprecise external abort (0xc06) at 0xb6fd83dc" or similar: the real reason turns out to be that the PTE is pointing right into one of the reserved memory areas. We were just lucky until now. We need to augment the DB8500 and DB8520 SoCs similarly and also create a new include for the DB9500 used in the Snowball since this does not have a modem and thus does not need the modem memory reservation, albeit it needs the ISSW reservation. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Cc: stable@vger.kernel.org Cc: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20201213225517.3838501-1-linus.walleij@linaro.org' Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Soeren Moch 提交于
stable inclusion from stable-5.10.13 commit 14e3388f2f95449ec868b2ce5263ae5d18e87b3b bugzilla: 47995 -------------------------------- commit fd25c883 upstream. to be consistent with kernel versions up to v5.9 (mmc aliases not used here). usdhc1 is not wired up on this board and therefore cannot be used. Start mmc aliases with usdhc2. Signed-off-by: NSoeren Moch <smoch@web.de> Cc: stable@vger.kernel.org # 5.10.x Signed-off-by: NShawn Guo <shawnguo@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Sean Young 提交于
stable inclusion from stable-5.10.13 commit b3b75f8cd187cb3d17f4930a817a425b6bb1a418 bugzilla: 47995 -------------------------------- commit 896111dc upstream. There is a race condition where if the /sys/class/rc0/uevent file is read before rc_dev->registered is set to true, -ENODEV will be returned. Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1901089 Cc: stable@vger.kernel.org Fixes: a2e2d73f ("media: rc: do not access device via sysfs after rc_unregister_device()") Signed-off-by: NSean Young <sean@mess.org> Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Matthias Reichl 提交于
stable inclusion from stable-5.10.13 commit ce9e154a8bcb620a5e6affaf1d6815f5ee0207b3 bugzilla: 47995 -------------------------------- commit e1def45b upstream. Commit 528222d8 ("media: rc: harmonize infrared durations to microseconds") missed to switch the min_timeout calculation from ns to us. This resulted in a minimum timeout of 1.2 seconds instead of 1.2ms, leading to large delays and long key repeats. Fix this by applying proper ns->us conversion. Cc: stable@vger.kernel.org Fixes: 528222d8 ("media: rc: harmonize infrared durations to microseconds") Signed-off-by: NMatthias Reichl <hias@horus.com> Signed-off-by: NSean Young <sean@mess.org> Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Matthias Reichl 提交于
stable inclusion from stable-5.10.13 commit 8429fee291434b3519fa074a15fa979fc63dbee1 bugzilla: 47995 -------------------------------- commit 06b83158 upstream. Commit 528222d8 ("media: rc: harmonize infrared durations to microseconds") missed to switch some timeout calculations from nanoseconds to microseconds. This resulted in spurious key_up+key_down events at the last scancode if the rc device uses a long timeout (eg 100ms on nuvoton-cir) as the device timeout wasn't properly accounted for in the keyup timeout calculation. Fix this by applying the proper conversion functions. Cc: stable@vger.kernel.org Fixes: 528222d8 ("media: rc: harmonize infrared durations to microseconds") Signed-off-by: NMatthias Reichl <hias@horus.com> Signed-off-by: NSean Young <sean@mess.org> Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Ricardo Ribalda 提交于
stable inclusion from stable-5.10.13 commit 4b5a88b3f45cd0f7a7025c53a4b448f4bab88c00 bugzilla: 47995 -------------------------------- commit e081863a upstream. raw_fmt->height in never initialized. But width in initialized twice. Fixes: 88d06362 ("media: hantro: Refactor for V4L2 API spec compliancy") Signed-off-by: NRicardo Ribalda <ribalda@chromium.org> Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Jernej Skrabec 提交于
stable inclusion from stable-5.10.13 commit ae584fbbb6589b8b65becbdc1f66b5276430cfcb bugzilla: 47995 -------------------------------- commit 73bc0b0c upstream. During H264 API overhaul subtle bug was introduced Cedrus driver. Progressive references have both, top and bottom reference flags set. Cedrus reference list expects only bottom reference flag and only when interlaced frames are decoded. However, due to a bug in Cedrus check, exclusivity is not tested and that flag is set also for progressive references. That causes "jumpy" background with many videos. Fix that by checking that only bottom reference flag is set in control and nothing else. Tested-by: NAndre Heider <a.heider@gmail.com> Fixes: cfc8c3ed ("media: cedrus: h264: Properly configure reference field") Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Yannick Fertre 提交于
stable inclusion from stable-5.10.13 commit e76b40d8e9ad2d6ef6c39f8360344fce8d35aae2 bugzilla: 47995 -------------------------------- commit eaf18a41 upstream. Missing stm32 directory to Makefile. Signed-off-by: NYannick Fertre <yannick.fertre@foss.st.com> Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: 4be5e864 ("media: move CEC platform drivers to a separate directory") Cc: <stable@vger.kernel.org> Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Helge Deller 提交于
stable inclusion from stable-5.10.13 commit 6141f82fd5ee0959a3e81ceb37c8af8816cfa31c bugzilla: 47995 -------------------------------- commit 00e35f2b upstream. When building a kernel without module support, the CONFIG_MLONGCALL option needs to be enabled in order to reach symbols which are outside of a 22-bit branch. This patch changes the autodetection in the Kconfig script to always enable CONFIG_MLONGCALL when modules are disabled and uses a far call to preempt_schedule_irq() in intr_do_preempt() to reach the symbol in all cases. Signed-off-by: NHelge Deller <deller@gmx.de> Reported-by: Nkernel test robot <lkp@intel.com> Cc: stable@vger.kernel.org # v5.6+ Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Takashi Iwai 提交于
stable inclusion from stable-5.10.13 commit d56e3b6a6b148161805773f52f3921861317542f bugzilla: 47995 -------------------------------- commit 4961167b upstream. We've got another report indicating a similar problem wrt the power-saving behavior with VIA codec on Clevo machines. Let's apply the existing workaround generically to all Clevo devices with VIA codecs to cover all in once. BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1181330 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210126165603.11683-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Jian-Hong Pan 提交于
stable inclusion from stable-5.10.13 commit eacb5d4e6b647a2e42969027b6f5a8087d1fd267 bugzilla: 47995 -------------------------------- commit 5de3b943 upstream. ASUS B1400CEPE laptop's headset audio is not enabled until ALC256_FIXUP_ASUS_HPE quirk is applied. Here is the original pin node values: 0x12 0x40000000 0x13 0x411111f0 0x14 0x90170110 0x18 0x411111f0 0x19 0x411111f0 0x1a 0x411111f0 0x1b 0x411111f0 0x1d 0x40461b45 0x1e 0x411111f0 0x21 0x04211020 Signed-off-by: NJian-Hong Pan <jhp@endlessos.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210122054705.48804-1-jhp@endlessos.orgSigned-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Baoquan He 提交于
stable inclusion from stable-5.10.13 commit aa9a6dc6261109d72787d0b4c5bc27238ffabdbf bugzilla: 47995 -------------------------------- commit 56c91a18 upstream. Function kernel_kexec() is called with lock system_transition_mutex held in reboot system call. While inside kernel_kexec(), it will acquire system_transition_mutex agin. This will lead to dead lock. The dead lock should be easily triggered, it hasn't caused any failure report just because the feature 'kexec jump' is almost not used by anyone as far as I know. An inquiry can be made about who is using 'kexec jump' and where it's used. Before that, let's simply remove the lock operation inside CONFIG_KEXEC_JUMP ifdeffery scope. Fixes: 55f2503c ("PM / reboot: Eliminate race between reboot and suspend") Signed-off-by: NBaoquan He <bhe@redhat.com> Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NPingfan Liu <kernelfans@gmail.com> Cc: 4.19+ <stable@vger.kernel.org> # 4.19+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Rafael J. Wysocki 提交于
stable inclusion from stable-5.10.13 commit 2aa7eab3e7f0fd6188baf10bb922cb864cd93ca0 bugzilla: 47995 -------------------------------- commit 81b704d3 upstream. Calling acpi_thermal_check() from acpi_thermal_notify() directly is problematic if _TMP triggers Notify () on the thermal zone for which it has been evaluated (which happens on some systems), because it causes a new acpi_thermal_notify() invocation to be queued up every time and if that takes place too often, an indefinite number of pending work items may accumulate in kacpi_notify_wq over time. Besides, it is not really useful to queue up a new invocation of acpi_thermal_check() if one of them is pending already. For these reasons, rework acpi_thermal_notify() to queue up a thermal check instead of calling acpi_thermal_check() directly and only allow one thermal check to be pending at a time. Moreover, only allow one acpi_thermal_check_fn() instance at a time to run thermal_zone_device_update() for one thermal zone and make it return early if it sees other instances running for the same thermal zone. While at it, fold acpi_thermal_check() into acpi_thermal_check_fn(), as it is only called from there after the other changes made here. [This issue appears to have been exposed by commit 6d25be57 ("sched/core, workqueues: Distangle worker accounting from rq lock"), but it is unclear why it was not visible earlier.] BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208877Reported-by: NStephen Berman <stephen.berman@gmx.net> Diagnosed-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Tested-by: NStephen Berman <stephen.berman@gmx.net> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Kai-Heng Feng 提交于
stable inclusion from stable-5.10.13 commit d6f80e01fade80c472671138114a87559d73335b bugzilla: 47995 -------------------------------- commit 36af2d5c upstream. Commit 8765c5ba ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: https://github.com/systemd/systemd/pull/18163Suggested-by: NMika Westerberg <mika.westerberg@linux.intel.com> Fixes: 8765c5ba ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: 4.1+ <stable@vger.kernel.org> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Linus Torvalds 提交于
stable inclusion from stable-5.10.13 commit 8fe07159fc53d8103da4ca9899be782ec478692f bugzilla: 47995 -------------------------------- commit a9cbbb80 upstream. It turns out that the vfs_iocb_iter_{read,write}() functions are entirely broken, and don't actually use the passed-in file pointer for IO - only for the preparatory work (permission checking and for the write_iter function lookup). That worked fine for overlayfs, which always builds the new iocb with the same file pointer that it passes in, but in the general case it ends up doing nonsensical things (and could cause an iterator call that doesn't even match the passed-in file pointer). This subtly broke the tty conversion to write_iter in commit 9bb48c82 ("tty: implement write_iter"), because the console redirection didn't actually end up redirecting anything, since the passed-in file pointer was basically ignored, and the actual write was done with the original non-redirected console tty after all. The main visible effect of this is that the console messages were no longer logged to /var/log/boot.log during graphical boot. Fix the issue by simply not using the vfs write "helper" function at all, and just redirecting the write entirely internally to the tty layer. Do the target writability permission checks when actually registering the target tty with TIOCCONS instead of at write time. Fixes: 9bb48c82 ("tty: implement write_iter") Reported-and-tested-by: NHans de Goede <hdegoede@redhat.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 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> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Josef Bacik 提交于
stable inclusion from stable-5.10.13 commit 41f6f4a3143506ea1499cda2f14a16a2f82118a8 bugzilla: 47995 -------------------------------- commit b98e762e upstream. When setting up a device, we can krealloc the config->socks array to add new sockets to the configuration. However if we happen to get a IO request in at this point even though we aren't setup we could hit a UAF, as we deref config->socks without any locking, assuming that the configuration was setup already and that ->socks is safe to access it as we have a reference on the configuration. But there's nothing really preventing IO from occurring at this point of the device setup, we don't want to incur the overhead of a lock to access ->socks when it will never change while the device is running. To fix this UAF scenario simply freeze the queue if we are adding sockets. This will protect us from this particular case without adding any additional overhead for the normal running case. Cc: stable@vger.kernel.org Signed-off-by: NJosef Bacik <josef@toxicpanda.com> Signed-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Eric Dumazet 提交于
stable inclusion from stable-5.10.13 commit 51f58c4882ec7be6a439f8c0185ab9cc53111a7f bugzilla: 47995 -------------------------------- commit 81a86e1b upstream. net/core/tso.c got recent support for USO, and this broke iwlfifi because the driver implemented a limited form of GSO. Providing ->gso_type allows for skb_is_gso_tcp() to provide a correct result. Fixes: 3d5b459b ("net: tso: add UDP segmentation support") Signed-off-by: NEric Dumazet <edumazet@google.com> Reported-by: NBen Greear <greearb@candelatech.com> Tested-by: NBen Greear <greearb@candelatech.com> Cc: Luca Coelho <luciano.coelho@intel.com> Cc: Johannes Berg <johannes@sipsolutions.net> Link: https://bugzilla.kernel.org/show_bug.cgi?id=209913 Link: https://lore.kernel.org/r/20210125150949.619309-1-eric.dumazet@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org> Cc: Robert Hancock <hancockrwd@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
- 08 2月, 2021 11 次提交
-
-
由 Chen Zhou 提交于
maillist inclusion category: feature bugzilla: 47954 Reference: https://lkml.org/lkml/2021/1/30/53 ------------------------------------------------- For arm64, the behavior of crashkernel=X has been changed, which tries low allocation in DMA zone or DMA32 zone if CONFIG_ZONE_DMA is disabled, and fall back to high allocation if it fails. We can also use "crashkernel=X,high" to select a high region above DMA zone, which also tries to allocate at least 256M low memory in DMA zone automatically (or the DMA32 zone if CONFIG_ZONE_DMA is disabled). "crashkernel=Y,low" can be used to allocate specified size low memory. So update the Documentation. Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Tested-by: NJohn Donnelly <John.p.donnelly@oracle.com> Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chen Zhou 提交于
maillist inclusion category: feature bugzilla: 47954 Reference: https://lkml.org/lkml/2021/1/30/53 ------------------------------------------------- When reserving crashkernel in high memory, some low memory is reserved for crash dump kernel devices and never mapped by the first kernel. This memory range is advertised to crash dump kernel via DT property under /chosen, linux,usable-memory-range = <BASE1 SIZE1 [BASE2 SIZE2]> We reused the DT property linux,usable-memory-range and made the low memory region as the second range "BASE2 SIZE2", which keeps compatibility with existing user-space and older kdump kernels. Crash dump kernel reads this property at boot time and call memblock_add() to add the low memory region after memblock_cap_memory_range() has been called. Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Tested-by: NJohn Donnelly <John.p.donnelly@oracle.com> Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chen Zhou 提交于
maillist inclusion category: feature bugzilla: 47954 Reference: https://lkml.org/lkml/2021/1/30/53 ------------------------------------------------- We make the functions reserve_crashkernel[_low]() as generic for x86 and arm64. Since reserve_crashkernel[_low]() implementations are quite similar on other architectures as well, we can have more users of this later. So have CONFIG_ARCH_WANT_RESERVE_CRASH_KERNEL in arch/Kconfig and select this by X86 and ARM64. Suggested-by: NMike Rapoport <rppt@kernel.org> Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chen Zhou 提交于
maillist inclusion category: feature bugzilla: 47954 Reference: https://lkml.org/lkml/2021/1/30/53 ------------------------------------------------- There are following issues in arm64 kdump: 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail when there is no enough low memory. 2. If reserving crashkernel above 4G, in this case, crash dump kernel will boot failure because there is no low memory available for allocation. 3. Since commit 1a8e1cef ("arm64: use both ZONE_DMA and ZONE_DMA32"), if the memory reserved for crash dump kernel falled in ZONE_DMA32, the devices in crash dump kernel need to use ZONE_DMA will alloc fail. To solve these issues, change the behavior of crashkernel=X and introduce crashkernel=X,[high,low]. crashkernel=X tries low allocation in DMA zone or DMA32 zone if CONFIG_ZONE_DMA is disabled, and fall back to high allocation if it fails. We can also use "crashkernel=X,high" to select a region above DMA zone, which also tries to allocate at least 256M in DMA zone automatically (or the DMA32 zone if CONFIG_ZONE_DMA is disabled). "crashkernel=Y,low" can be used to allocate specified size low memory. Another minor change, there may be two regions reserved for crash dump kernel, in order to distinct from the high region and make no effect to the use of existing kexec-tools, rename the low region as "Crash kernel (low)". Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Tested-by: NJohn Donnelly <John.p.donnelly@oracle.com> Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chen Zhou 提交于
maillist inclusion category: feature bugzilla: 47954 Reference: https://lkml.org/lkml/2021/1/30/53 ------------------------------------------------- Introduce macro CRASH_ALIGN for alignment, macro CRASH_ADDR_LOW_MAX for upper bound of low crash memory, macro CRASH_ADDR_HIGH_MAX for upper bound of high crash memory, use macroes instead. Besides, keep consistent with x86, use CRASH_ALIGN as the lower bound of crash kernel reservation. Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Tested-by: NJohn Donnelly <John.p.donnelly@oracle.com> Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chen Zhou 提交于
maillist inclusion category: feature bugzilla: 47954 Reference: https://lkml.org/lkml/2021/1/30/53 ------------------------------------------------- Move macro vmcore_elf_check_arch_cross from arch/x86/include/asm/kexec.h to arch/x86/include/asm/elf.h to fix the following compiling warning: In file included from arch/x86/kernel/setup.c:39:0: ./arch/x86/include/asm/kexec.h:77:0: warning: "vmcore_elf_check_arch_cross" redefined # define vmcore_elf_check_arch_cross(x) ((x)->e_machine == EM_X86_64) In file included from arch/x86/kernel/setup.c:9:0: ./include/linux/crash_dump.h:39:0: note: this is the location of the previous definition #define vmcore_elf_check_arch_cross(x) 0 The root cause is that vmcore_elf_check_arch_cross under CONFIG_CRASH_CORE depend on CONFIG_KEXEC_CORE. Commit 532b66d2279d ("x86: kdump: move reserve_crashkernel[_low]() into crash_core.c") triggered the issue. Suggested by Mike, simply move vmcore_elf_check_arch_cross from arch/x86/include/asm/kexec.h to arch/x86/include/asm/elf.h to fix the warning. Fixes: 532b66d2279d ("x86: kdump: move reserve_crashkernel[_low]() into crash_core.c") Reported-by: Nkernel test robot <lkp@intel.com> Suggested-by: NMike Rapoport <rppt@kernel.org> Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chen Zhou 提交于
maillist inclusion category: feature bugzilla: 47954 Reference: https://lkml.org/lkml/2021/1/30/53 ------------------------------------------------- Make the functions reserve_crashkernel[_low]() as generic. Arm64 will use these to reimplement crashkernel=X. Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Tested-by: NJohn Donnelly <John.p.donnelly@oracle.com> Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chen Zhou 提交于
maillist inclusion category: feature bugzilla: 47954 Reference: https://lkml.org/lkml/2021/1/30/53 ------------------------------------------------- We will make the functions reserve_crashkernel() as generic, the xen_pv_domain() check in reserve_crashkernel() is relevant only to x86, the same as insert_resource() in reserve_crashkernel[_low](). So move xen_pv_domain() check and insert_resource() to setup_arch() to keep them in x86. Suggested-by: NMike Rapoport <rppt@kernel.org> Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Tested-by: NJohn Donnelly <John.p.donnelly@oracle.com> Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chen Zhou 提交于
maillist inclusion category: feature bugzilla: 47954 Reference: https://lkml.org/lkml/2021/1/30/53 ------------------------------------------------- To make the functions reserve_crashkernel() as generic, replace some hard-coded numbers with macro CRASH_ADDR_LOW_MAX. Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Tested-by: NJohn Donnelly <John.p.donnelly@oracle.com> Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chen Zhou 提交于
maillist inclusion category: feature bugzilla: 47954 Reference: https://lkml.org/lkml/2021/1/30/53 ------------------------------------------------- The lower bounds of crash kernel reservation and crash kernel low reservation are different, use the consistent value CRASH_ALIGN. Suggested-by: NDave Young <dyoung@redhat.com> Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Tested-by: NJohn Donnelly <John.p.donnelly@oracle.com> Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chen Zhou 提交于
maillist inclusion category: feature bugzilla: 47954 Reference: https://lkml.org/lkml/2021/1/30/53 ------------------------------------------------- Move CRASH_ALIGN to header asm/kexec.h for later use. Besides, the alignment of crash kernel regions in x86 is 16M(CRASH_ALIGN), but function reserve_crashkernel() also used 1M alignment. So just replace hard-coded alignment 1M with macro CRASH_ALIGN. Suggested-by: NDave Young <dyoung@redhat.com> Suggested-by: NBaoquan He <bhe@redhat.com> Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Tested-by: NJohn Donnelly <John.p.donnelly@oracle.com> Signed-off-by: NChen Zhou <chenzhou10@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-