Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>> > Gilles Chanteperdrix wrote:
>> > > Jan Kiszka wrote:
>> > > > As the #ifdef forest was cut down, I once again looked at xnlock_put.
>> > > > Why do you have this safety check for the owner also in production
>> code?
>
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > Jan Kiszka wrote:
> > > Gilles Chanteperdrix wrote:
> > > > Jan Kiszka wrote:
> > > > > As the #ifdef forest was cut down, I once again looked at
> > xnlock_put.
> > > > > Why do you have this safety check for the owner also in produ
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
> > Gilles Chanteperdrix wrote:
> > > Jan Kiszka wrote:
> > > > As the #ifdef forest was cut down, I once again looked at xnlock_put.
> > > > Why do you have this safety check for the owner also in production
> code?
> > >
> > > Because only
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > Jan Kiszka wrote:
> > > As the #ifdef forest was cut down, I once again looked at xnlock_put.
> > > Why do you have this safety check for the owner also in production code?
> >
> > Because only one broken xnlock_put could entail a chain r
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
> > As the #ifdef forest was cut down, I once again looked at xnlock_put.
> > Why do you have this safety check for the owner also in production code?
>
> Because only one broken xnlock_put could entail a chain reaction of
> broken xnlock sections
Jan Kiszka wrote:
> As the #ifdef forest was cut down, I once again looked at xnlock_put.
> Why do you have this safety check for the owner also in production code?
Because only one broken xnlock_put could entail a chain reaction of
broken xnlock sections with code on multiple CPU violating crit
