* About the tcm_fc FCoE target driver
@ 2021-01-04 15:51 Bart Van Assche
2021-01-04 16:06 ` James Bottomley
0 siblings, 1 reply; 3+ messages in thread
From: Bart Van Assche @ 2021-01-04 15:51 UTC (permalink / raw)
To: target-devel, James Bottomley, Hannes Reinecke, Mike Christie
Hi,
My understanding is that the ft_queue_data_in() function in the tcm_fc
driver gets called while processing SCSI READ commands. That function queues
data for sending by calling fc_seq_send(). The FCoE driver translates that
call into a dev_queue_xmit(skb) which sends the data asynchronously.
ft_queue_data_in() frees the data buffer synchronously from inside
ft_queue_status(). I believe that this race condition can trigger data
corruption. Since nobody ever reported this race condition, does this mean
that the FCoE target driver has no users and hence that it can be removed
from the kernel tree?
Thanks,
Bart.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: About the tcm_fc FCoE target driver
2021-01-04 15:51 About the tcm_fc FCoE target driver Bart Van Assche
@ 2021-01-04 16:06 ` James Bottomley
2021-01-04 17:04 ` Bart Van Assche
0 siblings, 1 reply; 3+ messages in thread
From: James Bottomley @ 2021-01-04 16:06 UTC (permalink / raw)
To: Bart Van Assche, target-devel, Hannes Reinecke, Mike Christie
On Mon, 2021-01-04 at 07:51 -0800, Bart Van Assche wrote:
> Hi,
>
> My understanding is that the ft_queue_data_in() function in the
> tcm_fc driver gets called while processing SCSI READ commands. That
> function queues data for sending by calling fc_seq_send(). The FCoE
> driver translates that call into a dev_queue_xmit(skb) which sends
> the data asynchronously. ft_queue_data_in() frees the data buffer
> synchronously from inside ft_queue_status(). I believe that this race
> condition can trigger data corruption. Since nobody ever reported
> this race condition, does this mean that the FCoE target driver has
> no users and hence that it can be removed from the kernel tree?
It could just mean the race condition is so rare no user has ever
triggered it reliably enough to report ... have you managed to trigger
it?
James
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: About the tcm_fc FCoE target driver
2021-01-04 16:06 ` James Bottomley
@ 2021-01-04 17:04 ` Bart Van Assche
0 siblings, 0 replies; 3+ messages in thread
From: Bart Van Assche @ 2021-01-04 17:04 UTC (permalink / raw)
To: jejb, target-devel, Hannes Reinecke, Mike Christie
On 1/4/21 8:06 AM, James Bottomley wrote:
> On Mon, 2021-01-04 at 07:51 -0800, Bart Van Assche wrote:
>> Hi,
>>
>> My understanding is that the ft_queue_data_in() function in the
>> tcm_fc driver gets called while processing SCSI READ commands. That
>> function queues data for sending by calling fc_seq_send(). The FCoE
>> driver translates that call into a dev_queue_xmit(skb) which sends
>> the data asynchronously. ft_queue_data_in() frees the data buffer
>> synchronously from inside ft_queue_status(). I believe that this race
>> condition can trigger data corruption. Since nobody ever reported
>> this race condition, does this mean that the FCoE target driver has
>> no users and hence that it can be removed from the kernel tree?
>
> It could just mean the race condition is so rare no user has ever
> triggered it reliably enough to report ... have you managed to trigger
> it?
Hi James,
That's a great question. With a driver that is closely related (the SCST
FCoE target driver; the driver from which the upstream tcm_fc driver has
been derived) I could trigger this race condition easily by running fio
--verify against the FCoE initiator driver. Changing "use_sg = !(remaining %
4) && lport->sg_supp" into "use_sg = false" made the fio verification errors
disappear.
Bart.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-01-04 17:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-01-04 15:51 About the tcm_fc FCoE target driver Bart Van Assche
2021-01-04 16:06 ` James Bottomley
2021-01-04 17:04 ` Bart Van Assche
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).