[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250517020653.GX2023217@ZenIV>
Date: Sat, 17 May 2025 03:06:53 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Stanislav Fomichev <stfomichev@...il.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, horms@...nel.org,
willemb@...gle.com, sagi@...mberg.me, asml.silence@...il.com,
almasrymina@...gle.com, kaiyuanz@...gle.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] net: devmem: remove min_t(iter_iov_len) in
sendmsg
On Fri, May 16, 2025 at 06:24:03PM -0700, Stanislav Fomichev wrote:
> On 05/17, Al Viro wrote:
> > On Fri, May 16, 2025 at 05:04:31PM -0700, Stanislav Fomichev wrote:
> > > iter_iov_len looks broken for UBUF. When iov_iter_advance is called
> > > for UBUF, it increments iov_offset and also decrements the count.
> > > This makes the iterator only go over half of the range (unless I'm
> > > missing something).
> >
> > What do you mean by "broken"? iov_iter_len(from) == "how much data is
> > left in that iterator". That goes for all flavours, UBUF included...
> >
> > Confused...
[snip]
> iov_len. And now, calling iter_iov_len (which does iov_len - iov_offset)
Wait a sec... Sorry, I've misread that as iov_iter_count(); iter_iov_len()
(as well as iter_iov_addr()) should not be used on anything other that
ITER_IOVEC
<checks>
Wait, in the same commit there's
+ if (iov_iter_type(from) != ITER_IOVEC)
+ return -EFAULT;
shortly prior to the loop iter_iov_{addr,len}() are used. What am I missing now?
Powered by blists - more mailing lists