Re: [PATCH for-next 00/32] spin lock usage optimization for SCSI drivers

Hi Finn, Thanks for reviewing the patch set. On 2021/2/8 15:57, Finn Thain wrote: On Sun, 7 Feb 2021, Xiaofei Tan wrote: Replace spin_lock_irqsave with spin_lock in hard IRQ of SCSI drivers. There are no function changes, but may speed up if interrupt happen too often. This change doesn't ne

Re: [PATCH 1/1] PCI/AER: Change to use helper pcie_aer_is_native() in some places

Hi Krzysztof, On 2021/2/5 5:50, Krzysztof Wilczyński wrote: Hi Tan, This is very nice! Thank you for this. [...] if (dev->aer_cap && pci_aer_available() && - (pcie_ports_native || host->native_aer)) { + pcie_aer_is_native(dev)) { services |= PCIE_P

Re: [PATCH v5] ACPI / APEI: fix the regression of synchronous external aborts occur in user-mode

@James Hi James, please help to review this patch. Thank you very much. :) On 2020/12/10 20:09, Xiaofei Tan wrote: After the commit 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work") applied, do_sea() return directly for user-mode if apei_claim_sea() handled any

Re: [PATCH] EDAC, ghes: use CPER module handles to locate DIMMs

> Does your platform set CPER_MEM_VALID_MODULE_HANDLE in GHES Memory errors? If >> so, any chance you could test this patch on your platform? [0] >> (original patch: https://lore.kernel.org/patchwork/patch/978928/) >> Hi James, Our platform do not set CPER_MEM_VALID_MODULE_HAND

Re: [Question] null pointer risk of kernel workqueue

Hi Bin, Yes, that's it. thanks. -- tanxiaofei On 2017/10/23 9:34, Li Bin wrote: > > > on 2017/10/21 23:35, Tejun Heo wrote: >> On Fri, Oct 20, 2017 at 02:57:18PM +0800, tanxiaofei wrote: >>> Hi Tejun, >>> >>> Any comments about this? >> >

Re: [Question] null pointer risk of kernel workqueue

Hi Tejun, Any comments about this? Thanks On 2017/9/27 17:17, tanxiaofei wrote: > > > On 2017/9/25 23:25, Tejun Heo wrote: >> Hello, >> >> On Sat, Sep 23, 2017 at 05:04:24PM +0800, tanxiaofei wrote: >>> Hi Tejun & Jiangshan, >>> >>>

Re: [Question] null pointer risk of kernel workqueue

On 2017/9/25 23:25, Tejun Heo wrote: > Hello, > > On Sat, Sep 23, 2017 at 05:04:24PM +0800, tanxiaofei wrote: >> Hi Tejun & Jiangshan, >> >> I find an null pointer risk in the code of workqueue. Here is description: >> >> If draining, __queue_work()

[Question] null pointer risk of kernel workqueue

Hi Tejun & Jiangshan, I find an null pointer risk in the code of workqueue. Here is description: If draining, __queue_work() will call the function is_chained_work() to do some checks. In is_chained_work(), worker->current_pwq is used directly. It should be not safe. http://elixir.free-electron