On 02/20, Jarek Poplawski wrote:
>
> On Mon, Feb 19, 2007 at 06:04:45PM +0300, Oleg Nesterov wrote:
> > On 02/19, Jarek Poplawski wrote:
> > >
> > > It looks like it's to be checked before kfree.
> >
> > Here,
> > br_add_if:
> ...
>
> I meant "it's to be checked",
Jarek, I was too quick and
On Mon, Feb 19, 2007 at 06:04:45PM +0300, Oleg Nesterov wrote:
> On 02/19, Jarek Poplawski wrote:
> >
> > On Mon, Feb 19, 2007 at 03:03:53PM +0300, Oleg Nesterov wrote:
> > > On 02/19, Jarek Poplawski wrote:
> > ...
> > > kfree() doesn't check WORK_STRUCT_PENDING, it makes no
> > > difference if it
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> Yes, destroy_nbp() does dev_put(dev). del_nbp() sets dev->br_port = NULL,
> port_carrier_check() goes to "done" in that case. So everething looks safe
> to me (but again, I do not even know what the "bridge" is :), so we should
> only take care about cont
On 02/19, Jarek Poplawski wrote:
>
> On Mon, Feb 19, 2007 at 03:03:53PM +0300, Oleg Nesterov wrote:
> > On 02/19, Jarek Poplawski wrote:
> ...
> > kfree() doesn't check WORK_STRUCT_PENDING, it makes no
> > difference if it is set or not when work->func() runs.
>
> It looks like it's to be checked
On 02/19, David Howells wrote:
>
> Hmmm... You've got a work_struct (well, a delayed_work actually) - can you
> just punt the destruction of the object over to keventd to perform, I wonder?
Yes, this is close (I think) to what I suggested, see below,
> The big problem with that that I see is tha
On Mon, Feb 19, 2007 at 03:03:53PM +0300, Oleg Nesterov wrote:
> On 02/19, Jarek Poplawski wrote:
...
> kfree() doesn't check WORK_STRUCT_PENDING, it makes no
> difference if it is set or not when work->func() runs.
It looks like it's to be checked before kfree.
> > So, even if this functionality
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> > Called by what? Something outside of br_if.c?
>
> No. if cancel_delayed_work() fails, the work may sit pending in cwq->worklist,
> or it may be running right now, waiting for rtnl_mutex.
OIC. I understood "called" to mean "scheduled", but that's not
On 02/19, Jarek Poplawski wrote:
>
> On Mon, Feb 19, 2007 at 12:43:59AM +0300, Oleg Nesterov wrote:
> > Afaics, noautorel work_struct buys nothing for "struct net_bridge_port".
> >
> > If del_nbp()->cancel_delayed_work(&p->carrier_check) fails,
> > port_carrier_check
> > may be called later anyway
On 02/19, David Howells wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > Afaics, noautorel work_struct buys nothing for "struct net_bridge_port".
>
> You may be right.
>
> > If del_nbp()->cancel_delayed_work(&p->carrier_check) fails,
> > port_carrier_check
> > may be called later anywa
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> Afaics, noautorel work_struct buys nothing for "struct net_bridge_port".
You may be right.
> If del_nbp()->cancel_delayed_work(&p->carrier_check) fails, port_carrier_check
> may be called later anyway.
Called by what? Something outside of br_if.c?
>
On Mon, Feb 19, 2007 at 12:43:59AM +0300, Oleg Nesterov wrote:
> Afaics, noautorel work_struct buys nothing for "struct net_bridge_port".
>
> If del_nbp()->cancel_delayed_work(&p->carrier_check) fails, port_carrier_check
> may be called later anyway. So the reading of *work in port_carrier_check()
Afaics, noautorel work_struct buys nothing for "struct net_bridge_port".
If del_nbp()->cancel_delayed_work(&p->carrier_check) fails, port_carrier_check
may be called later anyway. So the reading of *work in port_carrier_check() is
equally unsafe with or without this patch.
Signed-off-by: Oleg Nes
12 matches
Mail list logo
