Re: [PATCH v4 3/3] RDS: make sure not to loop forever inside rds_send_xmit

[David Miller]

From: Sowmini Varadhan <sowmini.varadhan@xxxxxxxxxx>
Date: Tue, 7 Apr 2015 17:56:05 -0400

> On (04/07/15 17:26), David Miller wrote:
>> >  	/*
>> > +	 * we record the send generation after doing the xmit acquire.
>> > +	 * if someone else manages to jump in and do some work, we'll use
>> > +	 * this to avoid a goto restart farther down.
>> > +	 *
>> > +	 * we don't need a lock because the counter is only incremented
>> > +	 * while we have the in_xmit bit held.
>> > +	 */
>> > +	conn->c_send_gen++;
>> > +	send_gen = conn->c_send_gen;
>> 
>> This increment does need to either be changed to be an atomic_t
>> or covered by a lock.
>> 
>> Otherwise two concurrent callers can both try to increment it at
>> the same time, and it only effectively increments once.  That's
>> corrupted state and will break all of the new logic added here.
> I'm afraid I dont follow what race condiiton you are seeing? Prior
> to this line, the "acquire_in_xmit" check would have only allowed
> one thread to successfully increment c_send_gen, right? What did I
> miss?

Then there is locking protecting this counter increment and the
comment is wrong.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/