While looking into another problem I noticed an apparently not-handled case in XrdLinkXeq::SendIOV when it resumes a write after an incomplete writev: For instance in the case of iocnt=2, if the writev returns a short number of bytes from the first iov, iov[0], then remainder of iov[0] is sent by write(), and then iov[1] is sent by writev() [all as intended]; but then an attempt would be made to write() the contents of iov[2]. This should either give an error like ("bad address") for the link, or possibly send some trailing nonsense data to the client.
In fact I don't think this was related to the problem I had been looking at, and I didn't find any indication this is happening. e.g. even if I look at a busy server I don't notice any "bad address" link errors. So maybe this is rather rare or even not possible for some reason I've not understood. (e.g. iov[0] is typically very short, e.g. 8 bytes, and iov[1] or iov[2] is much longer, so a short writev is more likely to happen in the last iov[]).
You can view, comment on, or merge this pull request online at:
https://github.com/xrootd/xrootd/pull/1825
-- Commit Summary --
* [Xrd] Fix a short writev recovery case
-- File Changes --
M src/Xrd/XrdLinkXeq.cc (2)
-- Patch Links --
https://github.com/xrootd/xrootd/pull/1825.patch
https://github.com/xrootd/xrootd/pull/1825.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/xrootd/xrootd/pull/1825
You are receiving this because you are subscribed to this thread.
Message ID: <[log in to unmask]>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
