From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E314D42C0A; Fri, 2 Jun 2023 05:33:15 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6D2A2406B8; Fri, 2 Jun 2023 05:33:15 +0200 (CEST) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by mails.dpdk.org (Postfix) with ESMTP id 222FF40693 for ; Fri, 2 Jun 2023 05:33:14 +0200 (CEST) Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-2b1a46ad09fso17477191fa.2 for ; Thu, 01 Jun 2023 20:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1685676793; x=1688268793; h=cc:to:subject:message-id:date:in-reply-to:references:mime-version :from:from:to:cc:subject:date:message-id:reply-to; bh=eOXpTmY00DCYctsec/irbCK6mQq9E9/5GAA1Xon1JjY=; b=KxcdGIpYcYZlBCUyuZbzIIsq9eWKXp+VKd08a9wEOZK5w40ODB+0DpnPuHEP5NFBf5 9Oo3xKBNs6m9PTseIjW88mzKOJ/2hHO2+ea90s+sHuwLsQgUiXkkQD26fzDxcjFtFzum fXs+S9z6aZ33eJei8uiiwD97CjpjjHYqBBjGSgZIANMJD9jJz9miYb4ZeYCEIWvASRm8 t7UlaYUQZweM2Bn6qGfSKYRc6IbqRIWSSxm7IKveOCjvh7NxSrCIA8dV6hFZk2fcJgkK qPovEQJmkTAmY27OgT6fA1OOfxYVKWudZsDw2DG4OHAtE25CC0Q1V1smKkeMyGTID05+ l9jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685676793; x=1688268793; h=cc:to:subject:message-id:date:in-reply-to:references:mime-version :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eOXpTmY00DCYctsec/irbCK6mQq9E9/5GAA1Xon1JjY=; b=HJb318qH+VhXZ18osRP8LHxhYN5GXCVYPrr5fsfwKGoiSG+sCZA4s/TeAqum4cy0u/ nj3n6Q8a9Uvy5X1AS1y1DDVUekbumC3QoVkYZf3SXi/8TaNPP+zIS518X9tBY3T61lBA uPp4qjOuVutRn2RATZrdJzsLAQ2hgZuBuIBgkC0N6JfXbOphU/f8f75/TwW0PxD6sllU 3w1TbU1cduA88Uo/JlNh939pUiJtbVfLi0ijXuMOGW89v/OD5CGXcGJbTvoXAGrqWxQg 08OArw8h1EDCMEeYtWQfXi51ldOu9B5bVmN36MQgbCRM/XVWLqQsFzzNDkOfRqQGokBQ zSyQ== X-Gm-Message-State: AC+VfDxiyZxckfoL23JtiQqORYHSIRk7YkxVLkOMxBbzh0KcocR8OHSr uHh8O3WuSlTpusBOysRGiCGmIKvPA2un/552byZAcQ== X-Google-Smtp-Source: ACHHUZ7JgUkfZPYrsYH1JbG2vjivGPi24cCZclyJFV9RNgFUz/aJXCmnupwQQFaWnvB16r/uGhqLWj4ey4JZl5lWxP8= X-Received: by 2002:a2e:3017:0:b0:2b1:a89a:5f2c with SMTP id w23-20020a2e3017000000b002b1a89a5f2cmr702782ljw.16.1685676793472; Thu, 01 Jun 2023 20:33:13 -0700 (PDT) Received: from 44278815321 named unknown by gmailapi.google.com with HTTPREST; Thu, 1 Jun 2023 20:33:13 -0700 From: =?UTF-8?B?546L5b+X5a6P?= Mime-Version: 1.0 References: <20230531065506.63021-1-wangzhihong.wzh@bytedance.com> <76dfde52-62ab-5497-194c-c49f6a4cc95c@intel.com> In-Reply-To: <76dfde52-62ab-5497-194c-c49f6a4cc95c@intel.com> Date: Thu, 1 Jun 2023 20:33:13 -0700 Message-ID: Subject: Re: [External] Re: [PATCH] eal/linux: register mp hotplug callback after memory init To: "Burakov, Anatoly" Cc: dev@dpdk.org, qi.z.zhang@intel.com Content-Type: multipart/alternative; boundary="0000000000007b515c05fd1d36b4" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --0000000000007b515c05fd1d36b4 Content-Type: text/plain; charset="UTF-8" Apologize that I have to go directly to function names to explain :) - rte_eal_intr_init creates eal_intr_thread_main which starts eal_intr_handle_interrupts - rte_mp_channel_init creates mp_handle which processes messages registered by rte_mp_action_register - then, eal_mp_dev_hotplug_init calls rte_mp_action_register to register handle_primary_request for EAL_DEV_MP_ACTION_REQUEST At this point the whole messaging mechanism starts to function: When primary attaches/detaches devices, it sends EAL_DEV_MP_ACTION_REQUEST, and handle_primary_request invokes __handle_primary_request, which calls local_dev_probe/remove. In the end it goes to for example rte_eth_dev_attach_secondary. Now, if secondary is somewhere after eal_mp_dev_hotplug_init but before memory init done, it will crash due to memory access violation. Thanks Zhihong From: "Burakov, Anatoly" Date: Thu, Jun 1, 2023, 20:26 Subject: [External] Re: [PATCH] eal/linux: register mp hotplug callback after memory init To: "Zhihong Wang", , < qi.z.zhang@intel.com> On 5/31/2023 7:55 AM, Zhihong Wang wrote: > Secondary would crash if it tries to handle mp requests before memory > init, since globals such as eth_dev_shared_data_lock are not accessible > to it at this moment. > --- Please correct me if I'm wrong, but if init is not completed, none of the IPC stuff is initialized either, and any hotplug requests would not trigger any callbacks in the first place? -- Thanks, Anatoly --0000000000007b515c05fd1d36b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologize that I have to go directly to func= tion names to explain :)
=C2=A0 - rte_eal_intr_init creates eal_in= tr_thread_main which starts eal_intr_handle_interrupts
=C2=A0 - rt= e_mp_channel_init creates mp_handle which processes messages registered by = rte_mp_action_register
=C2=A0 - then, eal_mp_dev_hotplug_init call= s rte_mp_action_register to register handle_primary_request for EAL_DEV_MP_= ACTION_REQUEST

At this point=C2=A0the whole messagin= g mechanism starts to function: When primary attaches/detaches devices, it = sends EAL_DEV_MP_ACTION_REQUEST, and handle_primary_request invokes __handl= e_primary_request, which calls=C2=A0local_dev_probe/remove. In the end=C2= =A0it goes to=C2=A0for example=C2=A0rte_eth_dev_attach_secondary.
=
Now, if secondary is somewhere after eal_mp_dev_hotplug_init= =C2=A0but before memory init=C2=A0done, it will crash due to memory access = violation.

Thanks
Zhihong
From: "Burakov, Anatoly"= <anatoly.burakov@intel.com>
Date:=C2=A0 Thu, Jun 1, 2023, 20:26
S= ubject:=C2=A0 [External] Re: [PATCH] eal/linux: register mp hotplug callbac= k after memory init
To: "Zhihong Wang"= ;<wangzhihong.wzh@bytedance.com>, <dev@dpdk.org>, <qi.z.zhang@intel.com>
On 5/31/2023 = 7:55 AM, Zhihong Wang wrote:
> Secondary would crash if it tries to handle mp requests = before memory
&= gt; init, since globals such as eth_dev_shared_data_lock are not accessible=
> to it at = this moment.
&g= t; ---

Please correct me = if I'm wrong, but if init is not completed, none of=C2=A0
the IPC stuff is initialized= either, and any hotplug requests would not=C2=A0
trigger any callbacks in the first place= ?
--=C2=A0
Thanks,
=
Anatoly

--0000000000007b515c05fd1d36b4--