Re: thread-unsafety problems as spl*() ones are NOP

2016-01-31 Thread Slawa Olhovchenkov
On Sun, Jan 31, 2016 at 10:00:51AM +0330, mokhi wrote: > @imp: > i exactly mean (Okay not so exact but very near ;D) what you said. > after analyzing kbd.c functions (eg, kbd_realloc_array()) i concluded > there are race conditions (and at result in some places there are > un-protected data too)

Re: thread-unsafety problems as spl*() ones are NOP

2016-01-30 Thread mokhi
So in your opinion I shouldn't put mutex/spin/lock/unlock under splitty/splx? Can you please explain a bit more about MPSAFE using for me too? Regards, Mokhi. ___ freebsd-current@freebsd.org mailing list

Re: thread-unsafety problems as spl*() ones are NOP

2016-01-30 Thread Hans Petter Selasky
On 01/30/16 19:31, Slawa Olhovchenkov wrote: On Sat, Jan 30, 2016 at 09:25:21PM +0300, Slawa Olhovchenkov wrote: On Sat, Jan 30, 2016 at 09:42:13PM +0330, mokhi wrote: i currently only wanna do patch on kbd.c (because i'm sure there is a thread-unsafety) and i don't want to add anything to

Re: thread-unsafety problems as spl*() ones are NOP

2016-01-30 Thread Ian Lepore
On Sat, 2016-01-30 at 18:56 +0330, mokhi wrote: > Hi. > in kbd.c there are many places spltty()/splx() used assuming it > locks/unlocks. > though there is bug filed for this, and ive asked in #bsddev, Ive > preferred to ask and ensure it from here again. > As these functions are obsoleted now,

Re: thread-unsafety problems as spl*() ones are NOP

2016-01-30 Thread Warner Losh
On Sat, Jan 30, 2016 at 2:09 PM, Ian Lepore wrote: > On Sat, 2016-01-30 at 18:56 +0330, mokhi wrote: > > Hi. > > in kbd.c there are many places spltty()/splx() used assuming it > > locks/unlocks. > > though there is bug filed for this, and ive asked in #bsddev, Ive > >

Re: thread-unsafety problems as spl*() ones are NOP

2016-01-30 Thread Slawa Olhovchenkov
On Sat, Jan 30, 2016 at 09:42:13PM +0330, mokhi wrote: > i currently only wanna do patch on kbd.c (because i'm sure there is a > thread-unsafety) > and i don't want to add anything to spltty() nor splx(), i just wanna > add things under where they've been used. > isn't problem with using

thread-unsafety problems as spl*() ones are NOP

2016-01-30 Thread mokhi
Hi. in kbd.c there are many places spltty()/splx() used assuming it locks/unlocks. though there is bug filed for this, and ive asked in #bsddev, Ive preferred to ask and ensure it from here again. As these functions are obsoleted now, this assumption is incorrect and some places we have

Re: thread-unsafety problems as spl*() ones are NOP

2016-01-30 Thread Slawa Olhovchenkov
On Sat, Jan 30, 2016 at 06:56:00PM +0330, mokhi wrote: > Hi. > in kbd.c there are many places spltty()/splx() used assuming it locks/unlocks. > though there is bug filed for this, and ive asked in #bsddev, Ive > preferred to ask and ensure it from here again. > As these functions are obsoleted

Re: thread-unsafety problems as spl*() ones are NOP

2016-01-30 Thread mokhi
i currently only wanna do patch on kbd.c (because i'm sure there is a thread-unsafety) and i don't want to add anything to spltty() nor splx(), i just wanna add things under where they've been used. isn't problem with using mutex/spin/lock/unlock etc there?

Re: thread-unsafety problems as spl*() ones are NOP

2016-01-30 Thread Slawa Olhovchenkov
On Sat, Jan 30, 2016 at 09:25:21PM +0300, Slawa Olhovchenkov wrote: > On Sat, Jan 30, 2016 at 09:42:13PM +0330, mokhi wrote: > > > i currently only wanna do patch on kbd.c (because i'm sure there is a > > thread-unsafety) > > and i don't want to add anything to spltty() nor splx(), i just wanna

Re: thread-unsafety problems as spl*() ones are NOP

2016-01-30 Thread mokhi
@imp So you think I should start to put locks there and see what happens? :) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to

Re: thread-unsafety problems as spl*() ones are NOP

2016-01-30 Thread mokhi
@imp: i exactly mean (Okay not so exact but very near ;D) what you said. after analyzing kbd.c functions (eg, kbd_realloc_array()) i concluded there are race conditions (and at result in some places there are un-protected data too) i don't mean to blindly replace splXXX() with locks, but the

Re: thread-unsafety problems as spl*() ones are NOP

2016-01-30 Thread Warner Losh
> On Jan 30, 2016, at 9:37 PM, mokhi wrote: > > @imp So you think I should start to put locks there and see what happens? :) I’d advocate a deeper understanding of the code. splXXX() is for code path exclusion. Locks are for data protection. These are subtly different