Sven Eckelmann wrote:
> Linus Lüssing wrote:
> > sysfs_del_hardif invokes kobject_put, which might sleep. However, we
> > are not allowed to sleep during a call_rcu. There is also no need to
> > do the removal with an atomic call_rcu, as kobject_put only frees the
> > kobject when there is no more reference to it anyway.
> > 
> > This commit basically revokes 7f32f2e8d97150ba5b80410dda86b01b0879fe8d,
> > despite not reintroducing the synchronize_rcu, our rcu_barrier should
> > handle this.
> 
> This is an extreme bad idea as we would free the object before the rcu
> grace period is over. This would mean that any parallel run through the
> list would probably access memory which is invalid. So this is a good way
> to crash your machine.
> 
> What makes you think that kobject_put sleeps? There is no code which proves
> it. The only reason would be that kobject_put -> kobject_release ->
> kobject_cleanup -> ... sleeps. Please complete that chain to show were the
> problem is. If it really sleeps then please only do the kobject related
> cleanup outside of call_rcu.

Found documentation about it in Documentation/kobject.txt

If you need to do a two-stage delete of the kobject (say you are not
allowed to sleep when you need to destroy the object), then call
kobject_del() which will unregister the kobject from sysfs.  This makes the
kobject "invisible", but it is not cleaned up, and the reference count of
the object is still the same.  At a later time call kobject_put() to finish
the cleanup of the memory associated with the kobject.


Please find another way to fix it - reverting 
7f32f2e8d97150ba5b80410dda86b01b0879fe8d is no option (especially not when 
removing rcu synchronization).

Best regards,
	Sven