All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Cavitt, Jonathan" <jonathan.cavitt@intel.com>
Cc: "Wajdeczko, Michal" <Michal.Wajdeczko@intel.com>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH 1/3] drm/xe/pf: Disable PF restart worker on device removal
Date: Fri, 1 Aug 2025 16:48:55 -0400	[thread overview]
Message-ID: <aI0oN49hRUsRTyDd@intel.com> (raw)
In-Reply-To: <CH0PR11MB54447679A02AE8747853C484E524A@CH0PR11MB5444.namprd11.prod.outlook.com>

On Wed, Jul 30, 2025 at 09:40:14PM +0000, Cavitt, Jonathan wrote:
> -----Original Message-----
> From: Wajdeczko, Michal <Michal.Wajdeczko@intel.com> 
> Sent: Wednesday, July 30, 2025 2:34 PM
> To: Cavitt, Jonathan <jonathan.cavitt@intel.com>; intel-xe@lists.freedesktop.org
> Subject: Re: [PATCH 1/3] drm/xe/pf: Disable PF restart worker on device removal
> > 
> > On 7/30/2025 11:08 PM, Cavitt, Jonathan wrote:
> > > -----Original Message-----
> > > From: Intel-xe <intel-xe-bounces@lists.freedesktop.org> On Behalf Of Michal Wajdeczko
> > > Sent: Wednesday, July 30, 2025 10:49 AM
> > > To: intel-xe@lists.freedesktop.org
> > > Cc: Wajdeczko, Michal <Michal.Wajdeczko@intel.com>
> > > Subject: [PATCH 1/3] drm/xe/pf: Disable PF restart worker on device removal
> > >>
> > >> We can't let restart worker run once device is removed, since other
> > >> data that it might want to access could be already released.
> > >> Explicitly disable worker as part of device cleanup action.
> > >>
> > >> Fixes: a4d1c5d0b99b ("drm/xe/pf: Move VFs reprovisioning to worker")
> > >> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> > >> ---
> > >>  drivers/gpu/drm/xe/xe_gt_sriov_pf.c | 30 ++++++++++++++++++++++++++++-
> > >>  1 file changed, 29 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_pf.c b/drivers/gpu/drm/xe/xe_gt_sriov_pf.c
> > >> index 35489fa81825..2761319fdc26 100644
> > >> --- a/drivers/gpu/drm/xe/xe_gt_sriov_pf.c
> > >> +++ b/drivers/gpu/drm/xe/xe_gt_sriov_pf.c
> > >> @@ -50,6 +50,11 @@ static void pf_init_workers(struct xe_gt *gt)
> > >>  	INIT_WORK(&gt->sriov.pf.workers.restart, pf_worker_restart_func);
> > >>  }
> > >>  
> > >> +static void pf_fini_workers(struct xe_gt *gt)
> > >> +{
> > >> +	disable_work_sync(&gt->sriov.pf.workers.restart);
> > >> +}
> > >> +
> > >>  /**
> > >>   * xe_gt_sriov_pf_init_early - Prepare SR-IOV PF data structures on PF.
> > >>   * @gt: the &xe_gt to initialize
> > >> @@ -79,6 +84,21 @@ int xe_gt_sriov_pf_init_early(struct xe_gt *gt)
> > >>  	return 0;
> > >>  }
> > >>  
> > >> +static void pf_fini_action(void *arg)
> > >> +{
> > >> +	struct xe_gt *gt = arg;
> > >> +
> > >> +	pf_fini_workers(gt);
> > >> +}
> > >> +
> > >> +static int pf_init_late(struct xe_gt *gt)
> > >> +{
> > >> +	struct xe_device *xe = gt_to_xe(gt);
> > >> +
> > >> +	xe_gt_assert(gt, IS_SRIOV_PF(xe));
> > >> +	return devm_add_action_or_reset(xe->drm.dev, pf_fini_action, gt);
> > >> +}
> > >> +
> > >>  /**
> > >>   * xe_gt_sriov_pf_init - Prepare SR-IOV PF data structures on PF.
> > >>   * @gt: the &xe_gt to initialize
> > >> @@ -95,7 +115,15 @@ int xe_gt_sriov_pf_init(struct xe_gt *gt)
> > >>  	if (err)
> > >>  		return err;
> > >>  
> > 
> > [1]
> > 
> > >> -	return xe_gt_sriov_pf_migration_init(gt);
> > >> +	err = xe_gt_sriov_pf_migration_init(gt);
> > >> +	if (err)
> > >> +		return err;
> > 
> > [2]
> > 
> > >> +
> > >> +	err = pf_init_late(gt);
> > >> +	if (err)
> > >> +		return err;
> > > 
> > > Everything else looks okay, but I don't think this conditional branch is necessary.
> > > I think we can just return err here unconditionally, as if we fail this branch, err
> > > would equal zero anyway, which is what we'd want to return.
> > 
> > this was done on purpose
> > 
> > I'm pretty sure modern compilers can optimize that and
> > IMO it is clearer to leave success path fully visible
> > 
> > especially that in the future we might want to add more steps
> > to this init() function, so we could have smaller diff and
> > avoid diffs like [1-2] above
> 
> *shrugs*
> 
> I don't entirely agree, but I'm not going to cause a problem about it,
> so you can take the Reviewed-by without any changes.

Next time please wait for the answer before stating your reviewed-by
so it comes with more confidence or there are still room for discussions.

Thanks,
Rodrigo.

> 
> -Jonathan Cavitt
> > 
> > > 
> > > With that change:
> > > Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
> > > -Jonathan Cavitt
> > > 
> > >> +
> > >> +	return 0;
> > >>  }
> > >>  
> > >>  static bool pf_needs_enable_ggtt_guest_update(struct xe_device *xe)
> > >> -- 
> > >> 2.47.1
> > >>
> > >>
> > 
> > 

  reply	other threads:[~2025-08-01 20:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-30 17:49 [PATCH 0/3] Misc PF improvements Michal Wajdeczko
2025-07-30 17:49 ` [PATCH 1/3] drm/xe/pf: Disable PF restart worker on device removal Michal Wajdeczko
2025-07-30 21:08   ` Cavitt, Jonathan
2025-07-30 21:34     ` Michal Wajdeczko
2025-07-30 21:40       ` Cavitt, Jonathan
2025-08-01 20:48         ` Rodrigo Vivi [this message]
2025-08-01 10:23   ` Piotr Piórkowski
2025-07-30 17:49 ` [PATCH 2/3] drm/xe/pf: Make sure PF is ready to configure VFs Michal Wajdeczko
2025-07-30 21:09   ` Cavitt, Jonathan
2025-07-30 21:44     ` Michal Wajdeczko
2025-08-01 20:51       ` Rodrigo Vivi
2025-08-01 11:25   ` Piotr Piórkowski
2025-07-30 17:49 ` [PATCH 3/3] drm/xe/pf: Don't resume device from restart worker Michal Wajdeczko
2025-07-30 21:10   ` Cavitt, Jonathan
2025-07-30 21:48     ` Michal Wajdeczko
2025-08-01 20:45       ` Rodrigo Vivi
2025-08-01 22:55         ` Cavitt, Jonathan
2025-08-01 14:04   ` Piotr Piórkowski
2025-07-30 19:12 ` ✓ CI.KUnit: success for Misc PF improvements Patchwork
2025-07-30 20:14 ` ✓ Xe.CI.BAT: " Patchwork
2025-07-30 21:29 ` ✓ Xe.CI.Full: " Patchwork

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=aI0oN49hRUsRTyDd@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=Michal.Wajdeczko@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jonathan.cavitt@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.