Hi Yi,
On Fri, 2012-12-07 at 18:05 +0000, Zou, Yi wrote:
> > On Thu, Dec 6, 2012 at 3:15 PM, Yi Zou <yi.zou@xxxxxxxxx> wrote:
> > > --- a/drivers/target/tcm_fc/tfc_sess.c
> > > +++ b/drivers/target/tcm_fc/tfc_sess.c
> > > @@ -226,8 +226,10 @@ static struct ft_sess *ft_sess_create(struct ft_tport
> > *tport, u32 port_id,
> > >
> > > pr_debug("port_id %x sess %p\n", port_id, sess);
> > >
> > > + local_bh_disable();
> > > transport_register_session(&tport->tpg->se_tpg, &acl->se_node_acl,
> > > sess->se_sess, sess);
> > > + local_bh_enable();
> > > return sess;
> > > }
> >
> > This doesn't seem like the right fix to me. I think
> > transport_deregister_session()
> > doesn't expect to be called from softirq context, and so the right fix is to
> > rearrange things so tcm_fc isn't doing that. (ie defer to process context)
> >
> > - R.
> Hmm...I wasn't aware transport_deregister_session() is not softirq safe,
> the current tcm_fc does the transport_deregister_session from the rcu callback
> which is why lockdeop complains...I'll have to see if that can be rearranged.
>
The nested se_node_acl->nacl_sess_lock access while se_tpg->session_lock
is held within __transport_register_session() is likely the lockdep
warning trigger here..
As mentioned by Roland, the final transport_deregister_session() +
kfree(ft_sess) should really be pushed out to system_wq process context
using a struct work_struct in ft_sess.
Thank you!
--nab
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
