> On Fri, Jul 07, 2017 at 12:04:28PM +0300, Elena Reshetova wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > > situations. > > > > Signed-off-by: Elena Reshetova <elena.reshetova@xxxxxxxxx> > > Signed-off-by: Hans Liljestrand <ishkamiel@xxxxxxxxx> > > Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx> > > Signed-off-by: David Windsor <dwindsor@xxxxxxxxx> > > I'll let tglx comment on the SoB chain, I know he likes those :-) You > did Cc him right, seeing how he's the maintainer of this stuff.. > > *sigh* you didn't :-( After so many patches send you _really_ should > know to Cc the right people. It is not so trivial as you might think. Unless right person shows up as maintainer/supporter when I run get_maintainer script, it is hard to figure out who is the right CC person. And the amount of sending patches doesn't help, because if a person reacts on patches and asks to change/fix stuff, it doesn't mean he is the right person, he might be just reading mailing list and having time to do reviews :( That's said, I will try to improve the CC list. > > > --- > > kernel/futex.c | 13 +++++++------ > > 1 file changed, 7 insertions(+), 6 deletions(-) > > > @@ -814,7 +815,7 @@ static struct futex_pi_state *alloc_pi_state(void) > > > > static void get_pi_state(struct futex_pi_state *pi_state) > > { > > - WARN_ON_ONCE(!atomic_inc_not_zero(&pi_state->refcount)); > > + WARN_ON_ONCE(!refcount_inc_not_zero(&pi_state->refcount)); > > } > > I think we have refcount_inc() for just that case, no? > Yes, this slipped through. Will fix so it would look shorted. Thank you for catching it! Best Regards, Elena. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html