Re: [PATCH v4 3/3] RDS: make sure not to loop forever inside rds_send_xmit
From: David Miller
Date: Tue Apr 07 2015 - 18:27:45 EST
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
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/