lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <97732cc0a75c0be3f2354075085e7fa6d78e82bb.camel@redhat.com> Date: Thu, 02 Nov 2023 17:24:14 +0100 From: Paolo Abeni <pabeni@...hat.com> To: Jijie Shao <shaojijie@...wei.com>, yisen.zhuang@...wei.com, salil.mehta@...wei.com, davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org Cc: shenjian15@...wei.com, wangjie125@...wei.com, liuyonglong@...wei.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH net 6/7] net: hns3: fix VF reset fail issue On Thu, 2023-11-02 at 20:16 +0800, Jijie Shao wrote: > on 2023/11/2 18:45, Paolo Abeni wrote: > > On Sat, 2023-10-28 at 10:59 +0800, Jijie Shao wrote: > > > > > > -static void hclgevf_clear_event_cause(struct hclgevf_dev *hdev, u32 regclr) > > > +static void hclgevf_clear_event_cause(struct hclgevf_dev *hdev, u32 regclr, > > > + bool need_dalay) > > > { > > > +#define HCLGEVF_RESET_DELAY 5 > > > + > > > + if (need_dalay) > > > + mdelay(HCLGEVF_RESET_DELAY); > > 5ms delay in an interrupt handler is quite a lot. What about scheduling > > a timer from the IH to clear the register when such delay is needed? > > > > Thanks! > > > > Paolo > > Using timer in this case will complicate the code and make maintenance difficult. Why? Would something alike the following be ok? (plus reset_timer initialization at vf creation and cleanup at vf removal time): --- diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c index a4d68fb216fb..626bc67065fc 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c @@ -1974,6 +1974,14 @@ static enum hclgevf_evt_cause hclgevf_check_evt_cause(struct hclgevf_dev *hdev, return HCLGEVF_VECTOR0_EVENT_OTHER; } +static void hclgevf_reset_timer(struct timer_list *t) +{ + struct hclgevf_dev *hdev = from_timer(hclgevf_dev, t, reset_timer); + + hclgevf_clear_event_cause(hdev, HCLGEVF_VECTOR0_EVENT_RST); + hclgevf_reset_task_schedule(hdev); +} + static irqreturn_t hclgevf_misc_irq_handle(int irq, void *data) { enum hclgevf_evt_cause event_cause; @@ -1982,13 +1990,13 @@ static irqreturn_t hclgevf_misc_irq_handle(int irq, void *data) hclgevf_enable_vector(&hdev->misc_vector, false); event_cause = hclgevf_check_evt_cause(hdev, &clearval); + if (event_cause == HCLGEVF_VECTOR0_EVENT_RST) + mod_timer(hdev->reset_timer, jiffies + msecs_to_jiffies(5)); + if (event_cause != HCLGEVF_VECTOR0_EVENT_OTHER) hclgevf_clear_event_cause(hdev, clearval); switch (event_cause) { - case HCLGEVF_VECTOR0_EVENT_RST: - hclgevf_reset_task_schedule(hdev); - break; case HCLGEVF_VECTOR0_EVENT_MBX: hclgevf_mbx_handler(hdev); break; --- > We consider reducing the delay time by polling. For example, > the code cycles every 50 us to check whether the write register takes effect. > If yes, the function returns immediately. or the code cycles until 5 ms. > > Is this method appropriate? IMHO such solution will not remove the problem. How frequent is expected to be the irq generating such delay? Thanks Paolo
Powered by blists - more mailing lists