On Wed, Nov 25, 2020 at 2:47 AM Guilherme G. Piccoli
wrote:
>
> Hi Kuppuswamy Sathyanarayanan (and all involved here), thanks for the
> patch! I'd like to ask what is the status of this patchset - I just
> "parachuted" in the issue, and by tracking the linux-pci ML, I found
> this V7 (and all prev
n one of the possible is
if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
(pcie_ports_dpc_native))
services |= PCIE_PORT_SERVICE_DPC;
after your patch ? nothing about AER ?
Thanks,
Ethan
On Thu, Oct 29, 2020 at 1:14 AM Kuppuswamy, Sathyanarayanan
wrote:
>
>
>
> On 10/27/20
On Sat, Oct 31, 2020 at 6:36 AM Sean V Kelley wrote:
>
> If an OS has not been granted AER control via _OSC, then
> the OS should not make changes to PCI_ERR_ROOT_COMMAND and
> PCI_ERR_ROOT_STATUS related registers. Per section 4.5.1 of
> the System Firmware Intermediary (SFI) _OSC and DPC Updates
On Tue, Oct 27, 2020 at 10:00 PM Kuppuswamy Sathyanarayanan
wrote:
>
> If CONFIG_PCIEPORTBUS is not enabled in kernel then initialing
> struct pci_host_bridge PCIe specific native_* members to "1" is
> incorrect. So protect the PCIe specific member initialization
> with CONFIG_PCIEPORTBUS.
>
> Sig
On Tue, Oct 27, 2020 at 11:12 AM Kuppuswamy Sathyanarayanan
wrote:
>
> Currently, AER and DPC Capabilities dependency checks is
> distributed between DPC and portdrv service drivers. So move
> them out of DPC driver.
>
> Also, since services & PCIE_PORT_SERVICE_AER check already
> ensures AER nati
On Tue, Oct 27, 2020 at 10:00 PM Kuppuswamy Sathyanarayanan
wrote:
>
> In DPC service enable logic, check for
> services & PCIE_PORT_SERVICE_AER implies pci_aer_available()
How about PCIE_PORT_SERVICE_AER is not configured, but
pcie_aer_disable == 0 ？
> is true. So there is no need to explicitly c
On Wed, Oct 28, 2020 at 9:48 AM Vidya Sagar wrote:
>
> Adds pcie_is_ecrc_enabled() API to let other sub-systems (like DesignWare)
> to query if ECRC policy is enabled and perform any configuration
> required in those respective sub-systems.
>
> Signed-off-by: Vidya Sagar
> ---
> V2:
> * None from
On Tue, Oct 20, 2020 at 2:33 PM Sanjay R Mehta wrote:
>
> From: Sanjay R Mehta
>
> if DL_ACTIVE bit is set it means that there is no need to check
> PCI_EXP_LNKSTA_LT bit, as DL_ACTIVE would have set only if the link
> is already trained. Hence adding a check which takes care of this
> scenario.
On Sat, Oct 17, 2020 at 6:29 AM Bjorn Helgaas wrote:
>
> [+cc Christoph, Ethan, Sinan, Keith; sorry should have cc'd you to
> begin with since you're looking at this code too. Particularly
> interested in your thoughts about whether we should be touching
> PCI_ERR_ROOT_COMMAND and PCI_ERR_ROOT_ST
On Thu, Oct 15, 2020 at 1:53 PM Kuppuswamy, Sathyanarayanan
wrote:
>
>
>
> On 10/14/20 10:05 PM, Ethan Zhao wrote:
> > On Thu, Oct 15, 2020 at 11:04 AM Kuppuswamy, Sathyanarayanan
> > wrote:
> >>
> >>
> >>
> >> On 10/14/20 6:58
On Wed, Oct 14, 2020 at 5:00 PM Kuppuswamy Sathyanarayanan
wrote:
>
> Commit bdb5ac85777d ("PCI/ERR: Handle fatal error recovery")
> merged fatal and non-fatal error recovery paths, and also made
> recovery code depend on hotplug handler for "remove affected
> device + rescan" support. But this ch
On Thu, Oct 15, 2020 at 11:04 AM Kuppuswamy, Sathyanarayanan
wrote:
>
>
>
> On 10/14/20 6:58 PM, Ethan Zhao wrote:
> > On Thu, Oct 15, 2020 at 1:06 AM Kuppuswamy, Sathyanarayanan
> > wrote:
> >>
> >>
> >>
> >> On 10/14/20 8:07
On Thu, Oct 15, 2020 at 1:06 AM Kuppuswamy, Sathyanarayanan
wrote:
>
>
>
> On 10/14/20 8:07 AM, Ethan Zhao wrote:
> > On Wed, Oct 14, 2020 at 5:00 PM Kuppuswamy Sathyanarayanan
> > wrote:
> >>
> >> Commit bdb5ac85777d ("PCI/ERR: Handle fatal error r
On Wed, Oct 14, 2020 at 5:00 PM Kuppuswamy Sathyanarayanan
wrote:
>
> Commit bdb5ac85777d ("PCI/ERR: Handle fatal error recovery")
> merged fatal and non-fatal error recovery paths, and also made
> recovery code depend on hotplug handler for "remove affected
> device + rescan" support. But this ch
Please fix the building issue.
drivers/pci/pcie/err.c:144:25: error: static declaration of
‘pcie_do_fatal_recovery’ follows non-static declaration
static pci_ers_result_t pcie_do_fatal_recovery(struct pci_dev *dev,
^~
In file included from drivers/pci/
On Mon, Oct 12, 2020 at 1:10 PM wrote:
>
> From: Kuppuswamy Sathyanarayanan
>
> Commit bdb5ac85777d ("PCI/ERR: Handle fatal error recovery")
> merged fatal and non-fatal error recovery paths, and also made
> recovery code depend on hotplug handler for "remove affected
> device + rescan" support.
On Thu, Oct 8, 2020 at 2:16 AM Kuppuswamy, Sathyanarayanan
wrote:
>
>
> On 10/7/20 4:31 AM, Ethan Zhao wrote:
> > Once root port DPC capability is enabled and triggered, at the beginning
> > of DPC is triggered, the DPC status bits are set by hardware and then
> > sen
On Thu, Oct 8, 2020 at 2:16 AM Kuppuswamy, Sathyanarayanan
wrote:
>
>
> On 10/7/20 4:31 AM, Ethan Zhao wrote:
> > Once root port DPC capability is enabled and triggered, at the beginning
> > of DPC is triggered, the DPC status bits are set by hardware and then
> > sen
On Thu, Oct 8, 2020 at 1:24 AM Kuppuswamy, Sathyanarayanan
wrote:
>
>
> On 10/7/20 4:31 AM, Ethan Zhao wrote:
> > During DPC error injection test we found there is race condition between
> > pciehp and DPC driver, NULL pointer dereference caused panic as following
> >
When we see 'can't recover (no error_detected callback)' on console,
Maybe the reason is io state is not changed by calling
pci_dev_set_io_state(), that is confused. fix it.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Chagnes:
v2: no change.
v3:
e function change code of pci_dev_set_io_state().
per Ashok's request, add more description to this cover-letter part.
Thanks,
Ethan
Ethan Zhao (6):
PCI/ERR: get device before call device driver to avoid NULL pointer
dereference
PCI/DPC: define a function to check and wait till port
ed-off-by: Ethan Zhao
---
Changnes:
v2: revise description and code according to suggestion from Andy.
v3: change code to simpler.
v4: no change.
v5: no change.
v6: no change.
v7: changed based on Bjorn's code and truth table.
v8: according to Bjorn's suggestion, rebase on another simpli
No function change.
Signed-off-by: Ethan Zhao
---
Changes:
v8: based on Bjorn's code and truth table, simplify the logic of
function pci_dev_set_io_state(), no function change.
drivers/pci/pci.h | 54 ---
1 file changed, 23 insertions(+
ev_put().
So does pci_dev_get() before using the device instance to avoid NULL
pointer dereference.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Changes:
v2: revise doc according to Andy's suggestion.
v3: no change.
v4: no change.
v5: no change.
v6: m
atus
and wait till the hardware and software completed the procedure.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
changes:
v2???align ICS code name to public doc.
v3: no change.
v4: response to Christoph's (Christoph Hellwig )
tip, move pci_wait_port_ou
r malfunction.
Brute DPC error injection script:
for i in {0..100}
do
setpci -s 64:02.0 0x196.w=000a
setpci -s 65:00.0 0x04.w=0544
mount /dev/nvme0n1p1 /root/nvme
sleep 1
done
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Changes:
v2:
Bjorn,
On Sun, Oct 4, 2020 at 12:44 AM Bjorn Helgaas wrote:
>
> On Sat, Oct 03, 2020 at 03:55:13AM -0400, Ethan Zhao wrote:
> > When uncorrectable error happens, AER driver and DPC driver interrupt
> > handlers likely call
> >
> >pcie_do_re
Lukas,
On Mon, Oct 5, 2020 at 3:13 AM Lukas Wunner wrote:
>
> On Sat, Oct 03, 2020 at 03:55:12AM -0400, Ethan Zhao wrote:
> > When root port has DPC capability and it is enabled, then triggered by
> > errors, DPC DLLSC and PDC etc interrupts will be sent to DPC driver, pciehp
Raj,
On Sun, Oct 4, 2020 at 12:57 PM Raj, Ashok wrote:
>
> Hi Ethan
>
> On Sat, Oct 03, 2020 at 03:55:09AM -0400, Ethan Zhao wrote:
> > Hi,folks,
> >
> > This simple patch set fixed some serious security issues found when DPC
> > error injection and NVMe SSD
When we see 'can't recover (no error_detected callback)' on console,
Maybe the reason is io state is not changed by calling
pci_dev_set_io_state(), that is confused. fix it.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Chagnes:
v2: no change.
v3:
ed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
Reviewed-by: Alexandru Gagniuc
Reviewed-by: Andy Shevchenko
---
Changnes:
v2: revise description and code according to suggestion from Andy.
v3: change code to simpler.
v4: no change.
v5: no change.
v6: no change.
v7: changed
ev_put().
So does pci_dev_get() before using the device instance to avoid NULL pointer
dereference.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Changes:
v2: revise doc according to Andy's suggestion.
v3: no change.
v4: no change.
v5: no change.
v6: moved
r malfunction.
Brute DPC error injection script:
for i in {0..100}
do
setpci -s 64:02.0 0x196.w=000a
setpci -s 65:00.0 0x04.w=0544
mount /dev/nvme0n1p1 /root/nvme
sleep 1
done
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Changes:
v2:
atus
and wait till the hardware and software completed the procedure.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
changes:
v2：align ICS code name to public doc.
v3: no change.
v4: response to Christoph's (Christoph Hellwig )
tip, move pci_wait_port_outdpc
on Bjorn's code and truth table.
change the patch[5/5] about the debug output information.
Thanks,
Ethan
Ethan Zhao (5):
PCI/ERR: get device before call device driver to avoid NULL pointer
dereference
PCI/DPC: define a function to check and wait till port finish DPC
handlin
Bjorn,
On Sat, Oct 3, 2020 at 1:29 AM Bjorn Helgaas wrote:
>
> [+cc Sinan]
>
> On Wed, Sep 30, 2020 at 03:05:36AM -0400, Ethan Zhao wrote:
> > When uncorrectable error happens, AER driver and DPC driver interrupt
> > handlers likely call
> >
> >pcie
Sinan,
On Sat, Oct 3, 2020 at 12:08 AM Sinan Kaya wrote:
>
> On 9/30/2020 3:05 AM, Ethan Zhao wrote:
> > When uncorrectable error happens, AER driver and DPC driver interrupt
> > handlers likely call
> >
> >pcie_do_recovery()
> >->pci_walk_
r malfunction.
Brute DPC error injection script:
for i in {0..100}
do
setpci -s 64:02.0 0x196.w=000a
setpci -s 65:00.0 0x04.w=0544
mount /dev/nvme0n1p1 /root/nvme
sleep 1
done
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Changes:
v2:
o DPC driver and its
declaration to pci.h. (tip from Christoph Hellwig ).
v5: fix building issue reported by l...@intel.com with some config.
v6: move patch[3/5] as the first patch according to Lukas's suggestion.
and rewrite the comment part of patch[3/5].
Ethan Zhao (5):
PCI/ERR:
When we see 'can't recover (no error_detected callback)' on console,
Maybe the reason is io state is not changed by calling
pci_dev_set_io_state(), that is confused. fix it.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Chagnes:
v2: no change.
v3:
atus
and wait till the hardware and software completed the procedure.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
changes:
v2：align ICS code name to public doc.
v3: no change.
v4: response to Christoph's (Christoph Hellwig )
tip, move pci_wait_port_outdpc
ate is
pci_channel_io_frozen, that will cause AER or DPC handler re-enter
the error detecting and recovery procedure one after another.
The result is the recovery flow mixed between AER and DPC.
So simplify the pci_dev_set_io_state() function to only return true
when dev->error_state is changed.
Signed-off-
pci_dev_put().
So does pci_dev_get() before using the device instance to avoid NULL
pointer dereference.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
v2: revise doc according to Andy's suggestion.
v3: no change.
v4: no change.
v5: no change.
v6: moved
On Tue, Sep 29, 2020 at 6:08 PM Lukas Wunner wrote:
>
> On Tue, Sep 29, 2020 at 05:46:41PM +0800, Ethan Zhao wrote:
> > On Tue, Sep 29, 2020 at 4:29 PM Lukas Wunner wrote:
> > > On Sun, Sep 27, 2020 at 11:27:46AM -0400, Sinan Kaya wrote:
> > > > On 9/2
On Tue, Sep 29, 2020 at 6:48 PM Andy Shevchenko
wrote:
>
> On Tue, Sep 29, 2020 at 05:38:00PM +0800, Ethan Zhao wrote:
> > On Tue, Sep 29, 2020 at 4:51 PM Andy Shevchenko
> > wrote:
> > > On Tue, Sep 29, 2020 at 10:35:14AM +0800, Ethan Zhao wrote:
> > > >
On Tue, Sep 29, 2020 at 4:29 PM Lukas Wunner wrote:
>
> On Sun, Sep 27, 2020 at 11:27:46AM -0400, Sinan Kaya wrote:
> > On 9/26/2020 11:28 PM, Ethan Zhao wrote:
> > > --- a/drivers/pci/hotplug/pciehp_hpc.c
> > > +++ b/drivers/pci/hotplug/pciehp_hpc.c
> > >
Andy,
On Tue, Sep 29, 2020 at 4:51 PM Andy Shevchenko
wrote:
>
> On Tue, Sep 29, 2020 at 10:35:14AM +0800, Ethan Zhao wrote:
> > Preferred style, there will be cleared comment in v6.
>
> Avoid top postings.
>
> > On Sat, Sep 26, 2020 at 12:42 AM Andy Shevchenko
>
On Tue, Sep 29, 2020 at 12:44 AM Sinan Kaya wrote:
>
> On 9/28/2020 7:10 AM, Sinan Kaya wrote:
> > On 9/27/2020 10:01 PM, Zhao, Haifeng wrote:
> >> Sinan,
> >>I explained the reason why locks don't protect this case in the patch
> >> description part.
> >> Write side and read side hold differ
Preferred style, there will be cleared comment in v6.
Thanks,
Ethan
On Sat, Sep 26, 2020 at 12:42 AM Andy Shevchenko
wrote:
>
> On Thu, Sep 24, 2020 at 10:34:21PM -0400, Ethan Zhao wrote:
> > During DPC error injection test we found there is race condition between
> > pci
Fixed this concern by moving the function to DPC driver and its
declaration to pci.h. see v5
Thanks,
Ethan
On Sun, Sep 27, 2020 at 2:27 PM Christoph Hellwig wrote:
>
> > +#ifdef CONFIG_PCIE_DPC
> > +static inline bool pci_wait_port_outdpc(struct pci_dev *pdev)
> > +{
> > + u16 cap = pdev->d
On Tue, Sep 29, 2020 at 12:45 AM Kuppuswamy, Sathyanarayanan
wrote:
>
>
> On 9/28/20 9:43 AM, Sinan Kaya wrote:
> > On 9/28/2020 7:10 AM, Sinan Kaya wrote:
> >> On 9/27/2020 10:01 PM, Zhao, Haifeng wrote:
> >>> Sinan,
> >>> I explained the reason why locks don't protect this case in the patch
On Mon, Sep 28, 2020 at 4:46 PM Andy Shevchenko
wrote:
>
> On Mon, Sep 28, 2020 at 7:13 AM Ethan Zhao wrote:
>
> Same comments as per v4.
> Also you have an issue in versioning here. Use -v parameter to `git
> format-patch`, it will do it for you nicely.
Aha, git has go
On Mon, Sep 28, 2020 at 4:45 PM Andy Shevchenko
wrote:
>
> On Mon, Sep 28, 2020 at 7:10 AM Ethan Zhao wrote:
>
> We didn't settle on the v4, why v5?
We could fix it with v6, v5 is used to fix other things.
>
> > When root port has DPC capability and it is enabled, th
Sathyanarayanan,
On Mon, Sep 28, 2020 at 10:44 AM Kuppuswamy, Sathyanarayanan
wrote:
>
> Hi,
>
> On 9/25/20 11:30 AM, Sinan Kaya wrote:
> > On 9/25/2020 2:16 PM, Kuppuswamy, Sathyanarayanan wrote:
> >>>
> >>> If this is a too involved change, DPC driver should restore state
> >>> when hotplug is
When we see 'can't recover (no error_detected callback)' on console,
Maybe the reason is io state is not changed by calling
pci_dev_set_io_state(), that is confused. fix it.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Chagnes:
V2: no change.
V3:
recovery action first, then DPC driver handling the call-back from
device drivers, clear the DPC status, at the end, pciehp handle the DLLSC
and PDC etc.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Changes:
V2: revise doc according to Andy's suggestion.
V3: no ch
atus
and wait till the hardware and software completed the procedure.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
changes:
V2：align ICS code name to public doc.
V3: no change.
V4: response to Christoph's (Christoph Hellwig )
tip, move pci_wait_port_ou
d its
declaration to pci.h. (tip from Christoph Hellwig ).
V5: fix building issue reported by l...@intel.com with some config.
Thanks,
Ethan
Ethan Zhao (5):
PCI: define a function to check and wait till port finish DPC handling
PCI: pciehp: check and wait port status out of DPC before han
ate is
pci_channel_io_frozen, that will cause AER or DPC handler re-enter
the error detecting and recovery procedure one after another.
The result is the recovery flow mixed between AER and DPC.
So simplify the pci_dev_set_io_state() function to only return true
when dev->error_state is changed.
Signed-off-
C error injection script:
for i in {0..100}
do
setpci -s 64:02.0 0x196.w=000a
setpci -s 65:00.0 0x04.w=0544
mount /dev/nvme0n1p1 /root/nvme
sleep 1
done
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Changes:
V2: revise doc according
When we see 'can't recover (no error_detected callback)' on console,
Maybe the reason is io state is not changed by calling
pci_dev_set_io_state(), that is confused. fix it.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Chagnes:
V2: no change.
V3:
C error injection script:
for i in {0..100}
do
setpci -s 64:02.0 0x196.w=000a
setpci -s 65:00.0 0x04.w=0544
mount /dev/nvme0n1p1 /root/nvme
sleep 1
done
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
Reviewed-by: Andy Shevchenko
---
Chan
ate is
pci_channel_io_frozen, that will cause AER or DPC handler re-enter
the error detecting and recovery procedure one after another.
The result is the recovery flow mixed between AER and DPC.
So simplify the pci_dev_set_io_state() function to only return true
when dev->error_state is changed.
Signed-off-
recovery action first, then DPC driver handling the call-back from
device drivers, clear the DPC status, at the end, pciehp handle the DLLSC
and PDC etc.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
Reviewed-by: Andy Shevchenko
---
Changes:
V2: revise doc according to An
d its
declaration to pci.h. (tip from Christoph Hellwig ).
Thanks,
Ethan
Ethan Zhao (5):
PCI: define a function to check and wait till port finish DPC handling
PCI: pciehp: check and wait port status out of DPC before handling
DLLSC and PDC
PCI/ERR: get device before call device driver to
atus
and wait till the hardware and software completed the procedure.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
Reviewed-by: Andy Shevchenko
Reviewed-by: Christoph Hellwig
---
changes:
V2：align ICS code name to public doc.
V3: no change.
V4: response to Christo
When we see 'can't recover (no error_detected callback)' on console,
Maybe the reason is io state is not changed by calling
pci_dev_set_io_state(), that is confused. fix it.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Chagnes:
V2: no change.
C error injection script:
for i in {0..100}
do
setpci -s 64:02.0 0x196.w=000a
setpci -s 65:00.0 0x04.w=0544
mount /dev/nvme0n1p1 /root/nvme
sleep 1
done
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
Reviewed-by: Andy Shevchenko
---
Chan
ate is
pci_channel_io_frozen, that will cause AER or DPC handler re-enter
the error detecting and recovery procedure one after another.
The result is the recovery flow mixed between AER and DPC.
So simplify the pci_dev_set_io_state() function to only return true
when dev->error_state is changed.
Signed-off-
eep 1
done
Other details see every commits description part.
This patch set could be applied to stable 5.9-rc6 directly.
Help to review and test.
V2: changed according to review by Andy Shevchenko.
V3: changed patch 4/5 to simpler coding.
Thanks,
Ethan
Ethan Zhao (5):
PCI: define a functi
recovery action first, then DPC driver handling the call-back from
device drivers, clear the DPC status, at the end, pciehp handle the DLLSC
and PDC etc.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
Reviewed-by: Andy Shevchenko
---
Changes:
V2: revise doc according to An
atus
and wait till the hardware and software completed the procedure.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
Reviewed-by: Andy Shevchenko
---
changes:
V2：align ICS code name to public doc.
V3: no change.
include/linux/pci.h | 31 ++
recovery action first, then DPC driver handling the call-back from
device drivers, clear the DPC status, at the end, pciehp handle the DLLSC
and PDC etc.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
Reviewed-by: Andy Shevchenko
---
Changes:
V2: revise doc according to An
C error injection script:
for i in {0..100}
do
setpci -s 64:02.0 0x196.w=000a
setpci -s 65:00.0 0x04.w=0544
mount /dev/nvme0n1p1 /root/nvme
sleep 1
done
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
Reviewed-by: Andy Shevchenko
---
Chan
When we see 'can't recover (no error_detected callback)' on console,
Maybe the reason is io state is not changed by calling
pci_dev_set_io_state(), that is confused. fix it.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
---
Chagnes:
V2: no change.
d
ate is
pci_channel_io_frozen, that will cause AER or DPC handler re-enter
the error detecting and recovery procedure one after another.
The result is the recovery flow mixed between AER and DPC.
So simplify the pci_dev_set_io_state() function to only return true
when dev->error_state is changed.
Signed-off-
atus
and wait till the hardware and software completed the procedure.
Signed-off-by: Ethan Zhao
Tested-by: Wen Jin
Tested-by: Shanshan Zhang
Reviewed-by: Andy Shevchenko
---
changes:
V2：align ICS code name to public doc.
include/linux/pci.h | 31 +++
1 file changed
eep 1
done
Other details see every commits description part.
This patch set could be applied to stable 5.9-rc6 directly.
Help to review and test.
V2: changed according to review by Andy Shevchenko.
Thanks,
Ethan
Ethan Zhao (5):
PCI: define a function to check and wait till port finish DPC han
When we see 'can't recover (no error_detected callback)' on console,
Maybe the reason is io state is not changed by calling
pci_dev_set_io_state(), that is confused. fix it.
Signed-off-by: Ethan Zhao
Tested-by: Wen jin
Tested-by: Shanshan Zhang
---
drivers/pci/pcie/err.c | 6
, that will cause AER or DPC handler re-enter
the error detecting and recovery procedure one after another.
The result is the recovery flow mixed between AER and DPC.
So simplify the pci_dev_set_io_state() function to only return true
when dev->error_state is changed.
Signed-off-by: Ethan Zhao
9-rc6 directly.
Help to review and test.
Thanks,
Ethan
Ethan Zhao (5):
PCI: define a function to check and wait till port finish DPC handling
PCI: pciehp: check and wait port status out of DPC before handling
DLLSC and PDC
PCI/ERR: get device before call device driver to avoid null po
From: Ethan Zhao
'commit e8c7d14ac6c3 ("block: revert back to synchronous request_queue
removal")' introduced panic issue to NVMe hotplug as following(hit
after just 2 times NVMe SSD hotplug under stable 5.9-RC2):
BUG: sleeping function called from invalid context a
David，
May I ask a question here -- Is it intentionally enabling the
read-only mode, so userspace
tools like dmidecode could work with kernel_is_locked_down ? while it
was impossible to work
with the attached patch applied. Is it a security policy change with
secure boot ?
Thanks,
Ethan
On
Commit-ID: 5ccba44ba118a500050076b0344632459779
Gitweb: https://git.kernel.org/tip/5ccba44ba118a500050076b0344632459779
Author: Ethan Zhao
AuthorDate: Mon, 4 Sep 2017 13:59:34 +0800
Committer: Ingo Molnar
CommitDate: Fri, 29 Sep 2017 13:20:13 +0200
sched/sysctl: Check user
On 2017/9/7 3:50, Luis R. Rodriguez wrote:
On Mon, Sep 04, 2017 at 03:54:23PM +0800, Ethan Zhao wrote:
Peter,
On 2017/9/4 15:49, Peter Zijlstra wrote:
On Sat, Sep 02, 2017 at 02:57:32PM +0800, Ethan Zhao wrote:
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 6648fbb..609bed2 100644
Peter,
On 2017/9/4 15:49, Peter Zijlstra wrote:
On Sat, Sep 02, 2017 at 02:57:32PM +0800, Ethan Zhao wrote:
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 6648fbb..609bed2 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -367,7 +367,7 @@ static int sysrq_sysctl_handler(struct
Peter,
On 2017/9/4 15:32, Peter Zijlstra wrote:
On Sat, Sep 02, 2017 at 08:33:03AM +0800, Ethan Zhao wrote:
Yep, that is the first place I considered to set the limit, but that would
break KABI ?
nah..
V4 sent, please ignore v2 & v3.
Thanks,
Ethan
-by: James Puthukattukaran
Signed-off-by: Ethan Zhao
---
v2: Check it at user input side in sysctl table (peterz).
v3: Use proc_dointvec_minmax().
v4: Fix a too long line in descripton part.
kernel/sysctl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sysctl.c b
: James Puthukattukaran
Signed-off-by: Ethan Zhao
---
v2: Check it at user input side in sysctl table (peterz).
v3: Use proc_dointvec_minmax().
kernel/sysctl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 6648fbb..423554a 100644
= div_u64(avg, total);
...
}
Seems this issue could be reproduced on all I tried stable 4.1 - last
kernel.
To fix this issue, check user input value of sysctl_sched_time_avg, keep
it unchanged when hit invalid input.
Reported-by: James Puthukattukaran
Signed-off-by: Ethan Zhao
---
v2
at 8:33 AM, Ethan Zhao wrote:
> Yep, that is the first place I considered to set the limit, but that would
> break KABI ?
>
> Thanks,
> Ethan
>
> On Fri, Sep 1, 2017 at 8:32 PM, Peter Zijlstra wrote:
>> On Fri, Sep 01, 2017 at 07:31:54PM +0800, Ethan Zhao wr
Yep, that is the first place I considered to set the limit, but that would
break KABI ?
Thanks,
Ethan
On Fri, Sep 1, 2017 at 8:32 PM, Peter Zijlstra wrote:
> On Fri, Sep 01, 2017 at 07:31:54PM +0800, Ethan Zhao wrote:
>> System will hang if user set sysctl_sched_time_avg to 0 by
>&g
()
Reported-by: James Puthukattukaran
Signed-off-by: Ethan Zhao
---
Tested on stable 4.1, compiled on stable 4.13-rc5
kernel/sched/sched.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index eeef1a3..b398560 100644
--- a/kernel/sched/sched.h
+++ b
Grep,
On 2017/8/2 2:06, Greg KH wrote:
On Tue, Aug 01, 2017 at 05:02:25PM +0900, Ethan Zhao wrote:
There is no enough error handling in block device adding/registration
path, for example,
device_add_disk()
blk_register_queue()
When kernel returns from device_add_disk(), no return value
ess the warning flood by replacing WARN() with
pr_debug() as shortcut before refactoring all related block device
code.
This issue also could be reproduced with stable v4.12 kernel.
Reported-by: Lifei Cai
Signed-off-by: Ethan Zhao
---
Built and tested with stable v4.12
fs/sysfs/group.c | 3 +--
On Thu, Jul 13, 2017 at 3:34 AM, Bjorn Helgaas wrote:
> On Wed, Jul 12, 2017 at 08:15:43AM -0400, Sinan Kaya wrote:
>> On 7/12/2017 5:44 AM, Ethan Zhao wrote:
>> > The dmesg yelled "...Tag handling is broken" , but didn't say how it
>> > was handled,
Hi,
On Wed, Jul 12, 2017 at 4:55 PM, Wim ten Have wrote:
> On Wed, 12 Jul 2017 00:04:14 -0400
> Sinan Kaya wrote:
>
>> All PCIe devices are expected to be able to handle 8-bit tags.
>> 'commit 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported")'
>> enabled extended tags for all devices
Zheng,
On Thu, Jul 6, 2017 at 3:00 PM, Zheng Li wrote:
> From: Zheng Li
>
> if there are several same route entries with different outgoing net device,
> application's socket specifies the oif through setsockopt with
> SO_BINDTODEVICE, sctpv6 should choose the route entry whose outgoing net
> de
Hanjun，
What branch is this patch for ? Check v4.12, failed to apply.
Thanks,
Ethan
On Thu, Jul 6, 2017 at 12:35 PM, Hanjun Guo wrote:
> From: Hanjun Guo
>
> is_fwnode_irqchip() already check fwnode is NULL or not,
> just use is_fwnode_irqchip() directly.
>
> Signed-off-by: Hanjun Guo
> -
James,
On Tue, Jul 4, 2017 at 2:17 AM, james puthukattukaran
wrote:
>
> Ethan -
>
>
> On 7/2/2017 9:55 PM, Ethan Zhao wrote:
>>
>> James,
>>
>> On Wed, Jun 28, 2017 at 5:42 AM, James Puthukattukaran
>> wrote:
>>>
>>> From: James P
1 - 100 of 364 matches
Mail list logo
