From: Neil Horman <nhorman@redhat.com>
To: tanhuazhong <tanhuazhong@huawei.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, salil.mehta@huawei.com,
yisen.zhuang@huawei.com, linuxarm@huawei.com,
Peng Li <lipeng321@huawei.com>
Subject: Re: [PATCH V2 net-next 08/12] net: hns3: stop schedule reset service while unloading driver
Date: Thu, 25 Apr 2019 07:41:04 -0400 [thread overview]
Message-ID: <20190425114104.GC15861@hmswarspite.think-freely.org> (raw)
In-Reply-To: <be5ba555-31bb-8803-66fa-51bfab70bde8@huawei.com>
On Thu, Apr 25, 2019 at 02:06:07PM +0800, tanhuazhong wrote:
>
>
> On 2019/4/24 21:55, Neil Horman wrote:
> > On Wed, Apr 24, 2019 at 07:05:27PM +0800, Huazhong Tan wrote:
> > > This patch uses HCLGE_STATE_REMOVING/HCLGEVF_STATE_REMOVING flag to
> > > indicate that the driver is unloading, and we should stop new coming
> > > reset service to be scheduled, otherwise, reset service will access
> > > some resource which has been freed by unloading.
> > >
> > > Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
> > > Signed-off-by: Peng Li <lipeng321@huawei.com>
> > > ---
> > > V1->V2: fixes a flag setting error
> > > ---
> > > drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 4 +++-
> > > drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 4 +++-
> > > drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 1 +
> > > 3 files changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> > > index 4d5568e..ead8308 100644
> > > --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> > > +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> > > @@ -2175,7 +2175,8 @@ static void hclge_mbx_task_schedule(struct hclge_dev *hdev)
> > > static void hclge_reset_task_schedule(struct hclge_dev *hdev)
> > > {
> > > - if (!test_and_set_bit(HCLGE_STATE_RST_SERVICE_SCHED, &hdev->state))
> > > + if (!test_bit(HCLGE_STATE_REMOVING, &hdev->state) &&
> > > + !test_and_set_bit(HCLGE_STATE_RST_SERVICE_SCHED, &hdev->state))
> > > schedule_work(&hdev->rst_service_task);
> > > }
> >
> > In what use case do you need an extra bit for this? From my read, this work
> > task only gets scheduled from:
> > 1) Interrupt handlers
> > 2) Its own service task
> >
> > Based on the fact that you are calling cancel_work_sync(...rst_service_task)
> > from the pci teardown routine, irqs should all be disabled on your devices
> > already (meaning interrupts shouldn't schedule it), and cancel_work_sync
> > guarantees that rearming cant happen from within its own service task.
> >
> > Neil
> >
>
> Beside these two cases, when the client detects an error and requests a
> reset, it will call hclge_reset_event and schedule the reset work task to
> deal with the request. This may happen after calling
> cancel_work_sync(...rst_service_task) from the pci teardown routine.
>
> Best Regards, Huazhong
>
But that is handled from either:
1) hns_roce_v2_msix_interrupt_abn
or
2) hns3_nic_net_timeout
or
3) hns3_slot_reset
You should be protected from (1) because interrupts should be disabled before
you call cancel_work_syn.
You should be protected from (2) because the network interface will have been
brought down first (disabling the watchdog timer for the any interfaces on this
hardware
You should be protected from (3) because you are tearing down the pci device
anyway, and the pci subsystem should be ignoring resets
Neil
> >
> > .
> >
>
next prev parent reply other threads:[~2019-04-25 11:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-24 11:05 [PATCH V2 net-next 00/12] code optimizations & bugfixes for HNS3 driver Huazhong Tan
2019-04-24 11:05 ` [PATCH V2 net-next 01/12] net: hns3: fix data race between ring->next_to_clean Huazhong Tan
2019-04-24 11:05 ` [PATCH V2 net-next 02/12] net: hns3: fix for TX clean num when cleaning TX BD Huazhong Tan
2019-04-24 11:05 ` [PATCH V2 net-next 03/12] net: hns3: handle the BD info on the last BD of the packet Huazhong Tan
2019-04-24 11:05 ` [PATCH V2 net-next 04/12] net: hns3: stop sending keep alive msg when VF command queue needs reinit Huazhong Tan
2019-04-24 11:05 ` [PATCH V2 net-next 05/12] net: hns3: use atomic_t replace u32 for arq's count Huazhong Tan
2019-04-24 11:05 ` [PATCH V2 net-next 06/12] net: hns3: use a reserved byte to identify need_resp flag Huazhong Tan
2019-04-24 11:05 ` [PATCH V2 net-next 07/12] net: hns3: not reset TQP in the DOWN while VF resetting Huazhong Tan
2019-04-24 11:05 ` [PATCH V2 net-next 08/12] net: hns3: stop schedule reset service while unloading driver Huazhong Tan
2019-04-24 13:55 ` Neil Horman
2019-04-25 6:06 ` tanhuazhong
2019-04-25 11:41 ` Neil Horman [this message]
2019-04-25 12:04 ` tanhuazhong
2019-04-24 11:05 ` [PATCH V2 net-next 09/12] net: hns3: fix pause configure fail problem Huazhong Tan
2019-04-24 11:05 ` [PATCH V2 net-next 10/12] net: hns3: extend the loopback state acquisition time Huazhong Tan
2019-04-24 11:05 ` [PATCH V2 net-next 11/12] net: hns3: prevent double free in hns3_put_ring_config() Huazhong Tan
2019-04-24 11:05 ` [PATCH V2 net-next 12/12] net: hns3: remove reset after command send failed Huazhong Tan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190425114104.GC15861@hmswarspite.think-freely.org \
--to=nhorman@redhat.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=lipeng321@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=salil.mehta@huawei.com \
--cc=tanhuazhong@huawei.com \
--cc=yisen.zhuang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®