Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1351782 > unrolled thread

RE: [PATCH RESEND] qib:Fix concurrent access in the function, qib_init_iba6120_funcs

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [PATCH RESEND] qib:Fix concurrent access in the function,  qib_init_iba6120_funcs "Marciniszyn, Mike" <mike.marciniszyn@intel.com> - 2016-03-07 17:40 +0100
    Re: [PATCH RESEND] qib:Fix concurrent access in the function,  qib_init_iba6120_funcs Leon Romanovsky <leon@leon.nu> - 2016-03-07 22:00 +0100
    RE: [PATCH RESEND] qib:Fix concurrent access in the function,  qib_init_iba6120_funcs "Marciniszyn, Mike" <mike.marciniszyn@intel.com> - 2016-03-07 22:20 +0100

#1351782 — RE: [PATCH RESEND] qib:Fix concurrent access in the function, qib_init_iba6120_funcs

> This fixes concurrent access in the function, qib_init_iba6120_funcs by locking
> around the calls to when setting up f_sendctrl and f_set_armlauch function
> pointers to the functions, sendctrl_6120_mod qib_set_6120_armlaunch due to
> these functions needing to have their caller to hold the spinlock that is part of
> the qib_ibport pointer they are using and due to the lock not being held by
> higher up functions in the caller stack we need to hold it in qib_init_iba6210 to
> avoid conncurrent access when setting up these function pointers.
> 

I'm not sure I agree.

static struct pci_driver qib_driver = {
        .name = QIB_DRV_NAME,
        .probe = qib_init_one,
        .remove = qib_remove_one,
        .id_table = qib_pci_tbl,
        .err_handler = &qib_pci_err_handler,
};

The only caller is the probe function, which naturally protects since the device cannot be used until the probe returns.

Are you actually having an issue with this older version of a qib card?

The other board specific routines if this indeed is an issue, would need to be fixed as well since that have the same chip specific routine.

Mike

[toc] | [next] | [standalone]

#1351977

On Mon, Mar 07, 2016 at 04:34:04PM +0000, Marciniszyn, Mike wrote:
> > This fixes concurrent access in the function, qib_init_iba6120_funcs by locking
> > around the calls to when setting up f_sendctrl and f_set_armlauch function
> > pointers to the functions, sendctrl_6120_mod qib_set_6120_armlaunch due to
> > these functions needing to have their caller to hold the spinlock that is part of
> > the qib_ibport pointer they are using and due to the lock not being held by
> > higher up functions in the caller stack we need to hold it in qib_init_iba6210 to
> > avoid conncurrent access when setting up these function pointers.
> > 
> 
> I'm not sure I agree.
> 
> static struct pci_driver qib_driver = {
>         .name = QIB_DRV_NAME,
>         .probe = qib_init_one,
>         .remove = qib_remove_one,
>         .id_table = qib_pci_tbl,
>         .err_handler = &qib_pci_err_handler,
> };
> 
> The only caller is the probe function, which naturally protects since the device cannot be used until the probe returns.
> 
> Are you actually having an issue with this older version of a qib card?

IMHO no,
The author is famous developer - Nick Krause [1].

[1]
http://news.softpedia.com/news/Malevolent-Developer-Trolls-Linux-Kernel-Development-with-Lots-of-Broken-Patches-453709.shtml

> 
> The other board specific routines if this indeed is an issue, would need to be fixed as well since that have the same chip specific routine.
> 
> Mike
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1351993

> From: nick [mailto:xerofoify@gmail.com]
> Sent: Monday, March 7, 2016 2:21 PM
> To: Marciniszyn, Mike <mike.marciniszyn@intel.com>
> Cc: dledford@redhat.com; Hefty, Sean <sean.hefty@intel.com>;
> hal.rosenstock@gmail.com; linux-rdma@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH RESEND] qib:Fix concurrent access in the function,
> qib_init_iba6120_funcs
> 
> 
> 
> On 2016-03-07 11:34 AM, Marciniszyn, Mike wrote:
> >> This fixes concurrent access in the function, qib_init_iba6120_funcs
> >> by locking around the calls to when setting up f_sendctrl and
> >> f_set_armlauch function pointers to the functions, sendctrl_6120_mod
> >> qib_set_6120_armlaunch due to these functions needing to have their
> >> caller to hold the spinlock that is part of the qib_ibport pointer
> >> they are using and due to the lock not being held by higher up
> >> functions in the caller stack we need to hold it in qib_init_iba6210 to avoid
> conncurrent access when setting up these function pointers.
> >>
> >
> > I'm not sure I agree.
> >
> > static struct pci_driver qib_driver = {
> >         .name = QIB_DRV_NAME,
> >         .probe = qib_init_one,
> >         .remove = qib_remove_one,
> >         .id_table = qib_pci_tbl,
> >         .err_handler = &qib_pci_err_handler, };
> >
> > The only caller is the probe function, which naturally protects since the device
> cannot be used until the probe returns.
> >
> That's correct my concern was about threads from other kernel contexts but
> then again that's probably me being too conservative about critical region
> protection.
> Cheers,
> Nick

Doug, I'm NAKing this patch based on this reply from Nick.

Given that function vectors cannot be used until the qib_init_iba6120_funcs() functions return, this patch just not needed.

Mike

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web