[stgt] [RESEND] [PATCH] Fix for segfault in tgtd sendtargets

[Chris Webb]

Arne Redlich <arne.redlich at googlemail.com> writes:

> No. And in fact even hardwiring it to 8k could potentially lead to
> problems already, it's just very unlikely.

Indeed. However, it should clearly be allowed to grow at least to
MaxRecvDSL in size. E.g. for our initiators, we have

  discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 262144

Where would I find the the initiator declaring its MaxRecvDSL for the
purposes of discovery? If I can store and get at the value during
text_key_add, it should be trivial to arrange for the realloc to be capped
at MaxRecvDSL, and drop keys only beyond that point.

Meanwhile, I'm going to have to leave it reallocing in my tree for now as
that's the only way I get a usable target daemon. Presumably this is also
true for anyone else trying to use tgtd for a non-trivial number of targets
so it might be worth adding a clear warning to the documentation?

> As I wrote before: to get it right (i.e. support an arbitrarily long list
> of targets), the data must be split into several PDUs, each having a max
> size of the MaxRecvDSL the initiator declared. And sequencing of these
> PDUs is also different from SCSI Data In's, i.e. the first text rsp is
> sent with a tag indicating there is more data, and the initiator can then
> choose to request the next part of the response with another text request.

This is significantly more implementation work, albeit the more general
solution as you say. (I can't bring myself to say 'right solution': this
degree of mechanism complexity for sending a straightforward list of targets
over a TCP connection is truely insane! How did iSCSI become so hideous?) I
don't have the time to try to tackle it. 

Cheers,

Chris.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html