* [RFC][CFT] handling Rerror without copy_from_iter_full()
@ 2022-06-08 17:41 Al Viro
2022-06-11 13:27 ` Dominique Martinet
0 siblings, 1 reply; 5+ messages in thread
From: Al Viro @ 2022-06-08 17:41 UTC (permalink / raw)
To: Dominique Martinet; +Cc: linux-fsdevel, v9fs-developer
As it is, p9_client_zc_rpc()/p9_check_zc_errors() is playing fast
and loose with copy_from_iter_full().
Background: reading from file is done by sending Tread request.
Response consists of fixed-sized header (including the amount of data
actually read) followed by the data itself.
For zero-copy case we arrange the things so that the first 11
bytes of reply go into the fixed-sized buffer, with the rest going
straight into the pages we want to read into.
What makes the things inconvenient is that sglist describing
what should go where has to be set *before* the reply arrives. As
the result, if reply is an error, the things get interesting. Success
is
size[4] Rread tag[2] count[4] data[count]
For error layout varies depending upon the protocol variant -
in original 9P and 9P2000 it's
size[4] Rerror tag[2] len[2] error[len]
in 9P2000.U
size[4] Rerror tag[2] len[2] error[len] errno[4]
in 9P2000.L
size[4] Rlerror tag[2] errno[4]
The last case is nice and simple - we have an 11-byte response that fits
into the fixed-sized buffer we hoped to get an Rread into. In other
two, though, we get a variable-length string spill into the pages
we'd prepared for the data to be read.
Had that been in fixed-sized buffer (which is actually 4K), we would've
dealt with that the same way we handle non-zerocopy case. However,
for zerocopy it doesn't end up there, so we need to copy it from
those pages.
The trouble is, by the time we get around to that, the references to
pages in question are already dropped. As the result, p9_zc_check_errors()
tries to get the data using copy_from_iter_full(). Unfortunately, the
iov_iter it's trying to read from might *NOT* be capable of that.
It is, after all, a data destination, not data source. In particular,
if it's an ITER_PIPE one, copy_from_iter_full() will simply fail.
The thing is, in ->zc_request() itself we have those pages. There it
would be a simple matter of memcpy_from_page() into the fixed-sized
buffer and it isn't hard to recognize the (rare) case when such
copying is needed. That way we get rid of p9_zc_check_errors() entirely
- p9_check_errors() can be used instead both for zero-copy and non-zero-copy
cases.
Do you see any problems with the variant below?
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/net/9p/client.c b/net/9p/client.c
index 8bba0d9cf975..d403085b9ef5 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -550,90 +550,6 @@ static int p9_check_errors(struct p9_client *c, struct p9_req_t *req)
return err;
}
-/**
- * p9_check_zc_errors - check 9p packet for error return and process it
- * @c: current client instance
- * @req: request to parse and check for error conditions
- * @uidata: external buffer containing error
- * @in_hdrlen: Size of response protocol buffer.
- *
- * returns error code if one is discovered, otherwise returns 0
- *
- * this will have to be more complicated if we have multiple
- * error packet types
- */
-
-static int p9_check_zc_errors(struct p9_client *c, struct p9_req_t *req,
- struct iov_iter *uidata, int in_hdrlen)
-{
- int err;
- int ecode;
- s8 type;
- char *ename = NULL;
-
- err = p9_parse_header(&req->rc, NULL, &type, NULL, 0);
- /* dump the response from server
- * This should be after parse_header which poplulate pdu_fcall.
- */
- trace_9p_protocol_dump(c, &req->rc);
- if (err) {
- p9_debug(P9_DEBUG_ERROR, "couldn't parse header %d\n", err);
- return err;
- }
-
- if (type != P9_RERROR && type != P9_RLERROR)
- return 0;
-
- if (!p9_is_proto_dotl(c)) {
- /* Error is reported in string format */
- int len;
- /* 7 = header size for RERROR; */
- int inline_len = in_hdrlen - 7;
-
- len = req->rc.size - req->rc.offset;
- if (len > (P9_ZC_HDR_SZ - 7)) {
- err = -EFAULT;
- goto out_err;
- }
-
- ename = &req->rc.sdata[req->rc.offset];
- if (len > inline_len) {
- /* We have error in external buffer */
- if (!copy_from_iter_full(ename + inline_len,
- len - inline_len, uidata)) {
- err = -EFAULT;
- goto out_err;
- }
- }
- ename = NULL;
- err = p9pdu_readf(&req->rc, c->proto_version, "s?d",
- &ename, &ecode);
- if (err)
- goto out_err;
-
- if (p9_is_proto_dotu(c) && ecode < 512)
- err = -ecode;
-
- if (!err) {
- err = p9_errstr2errno(ename, strlen(ename));
-
- p9_debug(P9_DEBUG_9P, "<<< RERROR (%d) %s\n",
- -ecode, ename);
- }
- kfree(ename);
- } else {
- err = p9pdu_readf(&req->rc, c->proto_version, "d", &ecode);
- err = -ecode;
-
- p9_debug(P9_DEBUG_9P, "<<< RLERROR (%d)\n", -ecode);
- }
- return err;
-
-out_err:
- p9_debug(P9_DEBUG_ERROR, "couldn't parse error%d\n", err);
- return err;
-}
-
static struct p9_req_t *
p9_client_rpc(struct p9_client *c, int8_t type, const char *fmt, ...);
@@ -874,7 +790,7 @@ static struct p9_req_t *p9_client_zc_rpc(struct p9_client *c, int8_t type,
if (err < 0)
goto reterr;
- err = p9_check_zc_errors(c, req, uidata, in_hdrlen);
+ err = p9_check_errors(c, req);
trace_9p_client_res(c, type, req->rc.tag, err);
if (!err)
return req;
diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index b24a4fb0f0a2..2a210c2f8e40 100644
--- a/net/9p/trans_virtio.c
+++ b/net/9p/trans_virtio.c
@@ -377,6 +377,35 @@ static int p9_get_mapped_pages(struct virtio_chan *chan,
}
}
+static void handle_rerror(struct p9_req_t *req, int in_hdr_len,
+ size_t offs, struct page **pages)
+{
+ unsigned size, n;
+ void *to = req->rc.sdata + in_hdr_len;
+
+ // Fits entirely into the static data? Nothing to do.
+ if (req->rc.size < in_hdr_len)
+ return;
+
+ // Really long error message? Tough, truncate the reply. Might get
+ // rejected (we can't be arsed to adjust the size encoded in header,
+ // or string size for that matter), but it wouldn't be anything valid
+ // anyway.
+ if (unlikely(req->rc.size > P9_ZC_HDR_SZ))
+ req->rc.size = P9_ZC_HDR_SZ;
+
+ // data won't span more than two pages
+ size = req->rc.size - in_hdr_len;
+ n = PAGE_SIZE - offs;
+ if (size > n) {
+ memcpy_from_page(to, *pages++, offs, n);
+ offs = 0;
+ to += n;
+ size -= n;
+ }
+ memcpy_from_page(to, *pages, offs, size);
+}
+
/**
* p9_virtio_zc_request - issue a zero copy request
* @client: client instance issuing the request
@@ -503,6 +532,11 @@ p9_virtio_zc_request(struct p9_client *client, struct p9_req_t *req,
kicked = 1;
p9_debug(P9_DEBUG_TRANS, "virtio request kicked\n");
err = wait_event_killable(req->wq, req->status >= REQ_STATUS_RCVD);
+ // RERROR needs reply (== error string) in static data
+ if (req->status == REQ_STATUS_RCVD &&
+ unlikely(req->rc.sdata[4] == P9_RERROR))
+ handle_rerror(req, in_hdr_len, offs, in_pages);
+
/*
* Non kernel buffers are pinned, unpin them
*/
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [RFC][CFT] handling Rerror without copy_from_iter_full()
2022-06-08 17:41 [RFC][CFT] handling Rerror without copy_from_iter_full() Al Viro
@ 2022-06-11 13:27 ` Dominique Martinet
2022-06-11 15:19 ` Al Viro
0 siblings, 1 reply; 5+ messages in thread
From: Dominique Martinet @ 2022-06-11 13:27 UTC (permalink / raw)
To: Al Viro; +Cc: linux-fsdevel, v9fs-developer
Al Viro wrote on Wed, Jun 08, 2022 at 05:41:46PM +0000:
> As it is, p9_client_zc_rpc()/p9_check_zc_errors() is playing fast
> and loose with copy_from_iter_full().
>
> Background: reading from file is done by sending Tread request.
> Response consists of fixed-sized header (including the amount of data
> actually read) followed by the data itself.
>
> For zero-copy case we arrange the things so that the first 11
> bytes of reply go into the fixed-sized buffer, with the rest going
> straight into the pages we want to read into.
Ugh... zc really needs something like direct data placement NFS/RDMA has
been doing... (But that's just not possible without extending the
protocol)
> What makes the things inconvenient is that sglist describing
> what should go where has to be set *before* the reply arrives. As
> the result, if reply is an error, the things get interesting. Success
> is
> size[4] Rread tag[2] count[4] data[count]
> For error layout varies depending upon the protocol variant -
> in original 9P and 9P2000 it's
> size[4] Rerror tag[2] len[2] error[len]
> in 9P2000.U
> size[4] Rerror tag[2] len[2] error[len] errno[4]
> in 9P2000.L
> size[4] Rlerror tag[2] errno[4]
>
> The last case is nice and simple - we have an 11-byte response that fits
> into the fixed-sized buffer we hoped to get an Rread into. In other
> two, though, we get a variable-length string spill into the pages
> we'd prepared for the data to be read.
That makes me wonder just how much use we get for the legacy
protocols -- I guess we do have some but all the filesystem-y
implementations that I would expect to be main users for large
IOs/zc are 9P2000.L as far as I know -- especially considering
virtio is pretty much limited to qemu? Are there other 9p virtio
servers?
So would it make sense to just say "not .L? tough luck, no zc",
or am I just being lazy?
> Had that been in fixed-sized buffer (which is actually 4K), we would've
> dealt with that the same way we handle non-zerocopy case. However,
> for zerocopy it doesn't end up there, so we need to copy it from
> those pages.
>
> The trouble is, by the time we get around to that, the references to
> pages in question are already dropped. As the result, p9_zc_check_errors()
> tries to get the data using copy_from_iter_full(). Unfortunately, the
> iov_iter it's trying to read from might *NOT* be capable of that.
> It is, after all, a data destination, not data source. In particular,
> if it's an ITER_PIPE one, copy_from_iter_full() will simply fail.
Silly question, in case of a pipe we'll have written something we
shouldn't have, or is it not gone yet until we actually finish the IO
with iov_iter_advance?
(my understanding is that reader won't have anything to read until
someone else does the advance, and that someone else will have
overwritten the data with their own content so no garbage wlll be read)
> The thing is, in ->zc_request() itself we have those pages. There it
> would be a simple matter of memcpy_from_page() into the fixed-sized
> buffer and it isn't hard to recognize the (rare) case when such
> copying is needed. That way we get rid of p9_zc_check_errors() entirely
> - p9_check_errors() can be used instead both for zero-copy and non-zero-copy
> cases.
>
> Do you see any problems with the variant below?
... With that said though your approach here definitely looks better
than what we currently have -- my main issue is that truncating is fine
for the original 9p2000 but for .U you'd be losing the ecode that we
currently trust for being errno-compatible.
It's *probably* not a problem in practice, but preserving that errno
would theorically make us look for the page where the last few bytes
went to and overwrite the end of the string with it but that's starting
to be ugly.
Anyway even not doing that is probably better than reading from
something we no longer own; but I'm still thinking just refusing non-.L
variants to zc calls is a better decision long term.
--
Dominique
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC][CFT] handling Rerror without copy_from_iter_full()
2022-06-11 13:27 ` Dominique Martinet
@ 2022-06-11 15:19 ` Al Viro
2022-06-11 21:42 ` Dominique Martinet
0 siblings, 1 reply; 5+ messages in thread
From: Al Viro @ 2022-06-11 15:19 UTC (permalink / raw)
To: Dominique Martinet; +Cc: linux-fsdevel, v9fs-developer
On Sat, Jun 11, 2022 at 10:27:54PM +0900, Dominique Martinet wrote:
> That makes me wonder just how much use we get for the legacy
> protocols -- I guess we do have some but all the filesystem-y
> implementations that I would expect to be main users for large
> IOs/zc are 9P2000.L as far as I know -- especially considering
> virtio is pretty much limited to qemu? Are there other 9p virtio
> servers?
Client can trivially force its use - -o version=9p2000.u and there
you go...
> So would it make sense to just say "not .L? tough luck, no zc",
> or am I just being lazy?
>
> > Had that been in fixed-sized buffer (which is actually 4K), we would've
> > dealt with that the same way we handle non-zerocopy case. However,
> > for zerocopy it doesn't end up there, so we need to copy it from
> > those pages.
> >
> > The trouble is, by the time we get around to that, the references to
> > pages in question are already dropped. As the result, p9_zc_check_errors()
> > tries to get the data using copy_from_iter_full(). Unfortunately, the
> > iov_iter it's trying to read from might *NOT* be capable of that.
> > It is, after all, a data destination, not data source. In particular,
> > if it's an ITER_PIPE one, copy_from_iter_full() will simply fail.
>
> Silly question, in case of a pipe we'll have written something we
> shouldn't have, or is it not gone yet until we actually finish the IO
> with iov_iter_advance?
> (my understanding is that reader won't have anything to read until
> someone else does the advance, and that someone else will have
> overwritten the data with their own content so no garbage wlll be read)
More than that, pipe is locked through ->read_iter(), so transient garbage
in it doesn't matter - we will either advance it by zero (it's an error)
or, with iov_iter_get_pages_alloc() switching to advancing variant,
we'll revert by the amount it had reserved there (error is the same as
extremely short read).
> ... With that said though your approach here definitely looks better
> than what we currently have -- my main issue is that truncating is fine
> for the original 9p2000 but for .U you'd be losing the ecode that we
> currently trust for being errno-compatible.
No, we wouldn't - this
len = req->rc.size - req->rc.offset;
if (len > (P9_ZC_HDR_SZ - 7)) {
err = -EFAULT;
goto out_err;
}
in p9_check_zc_errors() means that mainline won't even look at that value.
And we'll get the same -EFAULT when we get to
err = p9pdu_readf(&req->rc, c->proto_version, "s?d",
&ename, &ecode);
in p9_check_errors() and see that the length of string is too large to
fit into (truncated) reply.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [RFC][CFT] handling Rerror without copy_from_iter_full()
2022-06-11 15:19 ` Al Viro
@ 2022-06-11 21:42 ` Dominique Martinet
0 siblings, 0 replies; 5+ messages in thread
From: Dominique Martinet @ 2022-06-11 21:42 UTC (permalink / raw)
To: Al Viro; +Cc: linux-fsdevel, v9fs-developer
Al Viro wrote on Sat, Jun 11, 2022 at 03:19:07PM +0000:
> > That makes me wonder just how much use we get for the legacy
> > protocols -- I guess we do have some but all the filesystem-y
> > implementations that I would expect to be main users for large
> > IOs/zc are 9P2000.L as far as I know -- especially considering
> > virtio is pretty much limited to qemu? Are there other 9p virtio
> > servers?
>
> Client can trivially force its use - -o version=9p2000.u and there
> you go...
Well, yes, but qemu supports .L -- even if we arbitrarily decide .u
won't go through the zero-copy path it's not going to harm the VM case.
If zc had been a thing for e.g. trans_fd there are plenty of servers
that could still be only used with older variants, but I don't think we
have to try supporting 9p2000.u + zc if it's a burden in the code.
> > Silly question, in case of a pipe we'll have written something we
> > shouldn't have, or is it not gone yet until we actually finish the IO
> > with iov_iter_advance?
> > (my understanding is that reader won't have anything to read until
> > someone else does the advance, and that someone else will have
> > overwritten the data with their own content so no garbage wlll be read)
>
> More than that, pipe is locked through ->read_iter(), so transient garbage
> in it doesn't matter - we will either advance it by zero (it's an error)
> or, with iov_iter_get_pages_alloc() switching to advancing variant,
> we'll revert by the amount it had reserved there (error is the same as
> extremely short read).
Ok, thanks
> > ... With that said though your approach here definitely looks better
> > than what we currently have -- my main issue is that truncating is fine
> > for the original 9p2000 but for .U you'd be losing the ecode that we
> > currently trust for being errno-compatible.
>
> No, we wouldn't - this
> len = req->rc.size - req->rc.offset;
> if (len > (P9_ZC_HDR_SZ - 7)) {
> err = -EFAULT;
> goto out_err;
> }
> in p9_check_zc_errors() means that mainline won't even look at that value.
> And we'll get the same -EFAULT when we get to
> err = p9pdu_readf(&req->rc, c->proto_version, "s?d",
> &ename, &ecode);
> in p9_check_errors() and see that the length of string is too large to
> fit into (truncated) reply.
Right, I forgot the string itself has a size, so we're not looking at
the last bytes but something that is no longer there and readf will
fail. Ok.
Sure, I don't see any other problem with this code.
I still think it's complexity we don't really need, but it's better than
what we have -- care to resend it as a real patch? and I'll apply/run
through some basic tests with qemu+2000u a bit.
(well, I don't have to wait to run the tests)
--
Dominique
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC][CFT] handling Rerror without copy_from_iter_full()
@ 2022-06-13 4:54 kernel test robot
0 siblings, 0 replies; 5+ messages in thread
From: kernel test robot @ 2022-06-13 4:54 UTC (permalink / raw)
To: kbuild
[-- Attachment #1: Type: text/plain, Size: 28185 bytes --]
::::::
:::::: Manual check reason: "low confidence static check warning: net/9p/trans_virtio.c:401:24: warning: Dereference of null pointer [clang-analyzer-core.NullDereference]"
::::::
CC: llvm(a)lists.linux.dev
CC: kbuild-all(a)lists.01.org
BCC: lkp(a)intel.com
In-Reply-To: <YqDfWho8+f2AXPrj@zeniv-ca.linux.org.uk>
References: <YqDfWho8+f2AXPrj@zeniv-ca.linux.org.uk>
TO: Al Viro <viro@zeniv.linux.org.uk>
Hi Al,
[FYI, it's a private test report for your RFC patch.]
[auto build test WARNING on v5.19-rc1]
[also build test WARNING on next-20220610]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/intel-lab-lkp/linux/commits/Al-Viro/handling-Rerror-without-copy_from_iter_full/20220609-014338
base: f2906aa863381afb0015a9eb7fefad885d4e5a56
:::::: branch date: 4 days ago
:::::: commit date: 4 days ago
config: x86_64-randconfig-c007 (https://download.01.org/0day-ci/archive/20220613/202206131238.IpT05p4w-lkp(a)intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project ff4abe755279a3a47cc416ef80dbc900d9a98a19)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/0e939f8c227af3b09fc90c8f3b6441a4bfb0b95b
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Al-Viro/handling-Rerror-without-copy_from_iter_full/20220609-014338
git checkout 0e939f8c227af3b09fc90c8f3b6441a4bfb0b95b
# save the config file
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 clang-analyzer
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
clang-analyzer warnings: (new ones prefixed by >>)
include/linux/fortify-string.h:385:26: note: expanded from macro 'memcpy'
#define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:378:2: note: expanded from macro '__fortify_memcpy_chk'
__underlying_##op(p, q, __fortify_size); \
^~~~~~~~~~~~~~~~~
note: expanded from here
include/linux/fortify-string.h:45:29: note: expanded from macro '__underlying_memcpy'
#define __underlying_memcpy __builtin_memcpy
^~~~~~~~~~~~~~~~
net/sunrpc/svcauth_unix.c:883:29: warning: Although the value stored to 'len' is used in the enclosing expression, the value is never actually read from 'len' [clang-analyzer-deadcode.DeadStores]
if (slen > UNX_NGROUPS || (len -= (slen + 2)*4) < 0)
^ ~~~~~~~~~~~~
net/sunrpc/svcauth_unix.c:883:29: note: Although the value stored to 'len' is used in the enclosing expression, the value is never actually read from 'len'
if (slen > UNX_NGROUPS || (len -= (slen + 2)*4) < 0)
^ ~~~~~~~~~~~~
Suppressed 94 warnings (93 in non-user code, 1 with check filters).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
21 warnings generated.
drivers/leds/trigger/ledtrig-oneshot.c:43:9: warning: Call to function 'sprintf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sprintf_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
return sprintf(buf, "%u\n", oneshot_data->invert);
^~~~~~~
drivers/leds/trigger/ledtrig-oneshot.c:43:9: note: Call to function 'sprintf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sprintf_s' in case of C11
return sprintf(buf, "%u\n", oneshot_data->invert);
^~~~~~~
drivers/leds/trigger/ledtrig-oneshot.c:73:9: warning: Call to function 'sprintf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sprintf_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
return sprintf(buf, "%lu\n", led_cdev->blink_delay_on);
^~~~~~~
drivers/leds/trigger/ledtrig-oneshot.c:73:9: note: Call to function 'sprintf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sprintf_s' in case of C11
return sprintf(buf, "%lu\n", led_cdev->blink_delay_on);
^~~~~~~
drivers/leds/trigger/ledtrig-oneshot.c:97:9: warning: Call to function 'sprintf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sprintf_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
return sprintf(buf, "%lu\n", led_cdev->blink_delay_off);
^~~~~~~
drivers/leds/trigger/ledtrig-oneshot.c:97:9: note: Call to function 'sprintf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sprintf_s' in case of C11
return sprintf(buf, "%lu\n", led_cdev->blink_delay_off);
^~~~~~~
Suppressed 18 warnings (18 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
38 warnings generated.
drivers/leds/trigger/ledtrig-gpio.c:53:9: warning: Call to function 'sprintf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sprintf_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
return sprintf(buf, "%u\n", gpio_data->desired_brightness);
^~~~~~~
drivers/leds/trigger/ledtrig-gpio.c:53:9: note: Call to function 'sprintf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sprintf_s' in case of C11
return sprintf(buf, "%u\n", gpio_data->desired_brightness);
^~~~~~~
drivers/leds/trigger/ledtrig-gpio.c:63:8: warning: Call to function 'sscanf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sscanf_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
ret = sscanf(buf, "%u", &desired_brightness);
^~~~~~
drivers/leds/trigger/ledtrig-gpio.c:63:8: note: Call to function 'sscanf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sscanf_s' in case of C11
ret = sscanf(buf, "%u", &desired_brightness);
^~~~~~
drivers/leds/trigger/ledtrig-gpio.c:81:9: warning: Call to function 'sprintf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sprintf_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
return sprintf(buf, "%u\n", gpio_data->inverted);
^~~~~~~
drivers/leds/trigger/ledtrig-gpio.c:81:9: note: Call to function 'sprintf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sprintf_s' in case of C11
return sprintf(buf, "%u\n", gpio_data->inverted);
^~~~~~~
drivers/leds/trigger/ledtrig-gpio.c:115:9: warning: Call to function 'sprintf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sprintf_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
return sprintf(buf, "%u\n", gpio_data->gpio);
^~~~~~~
drivers/leds/trigger/ledtrig-gpio.c:115:9: note: Call to function 'sprintf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sprintf_s' in case of C11
return sprintf(buf, "%u\n", gpio_data->gpio);
^~~~~~~
drivers/leds/trigger/ledtrig-gpio.c:126:8: warning: Call to function 'sscanf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sscanf_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
ret = sscanf(buf, "%u", &gpio);
^~~~~~
drivers/leds/trigger/ledtrig-gpio.c:126:8: note: Call to function 'sscanf' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'sscanf_s' in case of C11
ret = sscanf(buf, "%u", &gpio);
^~~~~~
Suppressed 33 warnings (33 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
71 warnings generated.
net/wireless/lib80211.c:51:2: warning: Call to function 'memset' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memset_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
memset(info, 0, sizeof(*info));
^
include/linux/fortify-string.h:288:25: note: expanded from macro 'memset'
#define memset(p, c, s) __fortify_memset_chk(p, c, s, \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:281:2: note: expanded from macro '__fortify_memset_chk'
__underlying_memset(p, c, __fortify_size); \
^~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:47:29: note: expanded from macro '__underlying_memset'
#define __underlying_memset __builtin_memset
^~~~~~~~~~~~~~~~
net/wireless/lib80211.c:51:2: note: Call to function 'memset' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memset_s' in case of C11
memset(info, 0, sizeof(*info));
^
include/linux/fortify-string.h:288:25: note: expanded from macro 'memset'
#define memset(p, c, s) __fortify_memset_chk(p, c, s, \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:281:2: note: expanded from macro '__fortify_memset_chk'
__underlying_memset(p, c, __fortify_size); \
^~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:47:29: note: expanded from macro '__underlying_memset'
#define __underlying_memset __builtin_memset
^~~~~~~~~~~~~~~~
Suppressed 70 warnings (70 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
86 warnings generated.
>> net/9p/trans_virtio.c:401:24: warning: Dereference of null pointer [clang-analyzer-core.NullDereference]
memcpy_from_page(to, *pages++, offs, n);
^
net/9p/trans_virtio.c:435:2: note: Taking false branch
p9_debug(P9_DEBUG_TRANS, "virtio request\n");
^
include/net/9p/9p.h:56:2: note: expanded from macro 'p9_debug'
no_printk(fmt, ##__VA_ARGS__)
^
include/linux/printk.h:130:2: note: expanded from macro 'no_printk'
if (0) \
^
net/9p/trans_virtio.c:437:6: note: Assuming 'uodata' is null
if (uodata) {
^~~~~~
net/9p/trans_virtio.c:437:2: note: Taking false branch
if (uodata) {
^
net/9p/trans_virtio.c:457:13: note: Assuming 'uidata' is non-null
} else if (uidata) {
^~~~~~
net/9p/trans_virtio.c:457:9: note: Taking true branch
} else if (uidata) {
^
net/9p/trans_virtio.c:460:7: note: Assuming 'n' is >= 0
if (n < 0) {
^~~~~
net/9p/trans_virtio.c:460:3: note: Taking false branch
if (n < 0) {
^
net/9p/trans_virtio.c:465:7: note: Assuming 'n' is equal to 'inlen'
if (n != inlen) {
^~~~~~~~~~
net/9p/trans_virtio.c:465:3: note: Taking false branch
if (n != inlen) {
^
net/9p/trans_virtio.c:473:2: note: Loop condition is false. Exiting loop
spin_lock_irqsave(&chan->lock, flags);
^
include/linux/spinlock.h:379:2: note: expanded from macro 'spin_lock_irqsave'
raw_spin_lock_irqsave(spinlock_check(lock), flags); \
^
include/linux/spinlock.h:240:2: note: expanded from macro 'raw_spin_lock_irqsave'
do { \
^
net/9p/trans_virtio.c:473:2: note: Loop condition is false. Exiting loop
spin_lock_irqsave(&chan->lock, flags);
^
include/linux/spinlock.h:377:43: note: expanded from macro 'spin_lock_irqsave'
#define spin_lock_irqsave(lock, flags) \
^
net/9p/trans_virtio.c:481:6: note: Assuming 'out' is 0
if (out)
^~~
net/9p/trans_virtio.c:481:2: note: Taking false branch
if (out)
^
net/9p/trans_virtio.c:484:6: note: 'out_pages' is null
if (out_pages) {
^~~~~~~~~
net/9p/trans_virtio.c:484:2: note: Taking false branch
if (out_pages) {
^
net/9p/trans_virtio.c:499:6: note: Assuming 'in' is 0
if (in)
^~
net/9p/trans_virtio.c:499:2: note: Taking false branch
if (in)
^
net/9p/trans_virtio.c:502:6: note: Assuming 'in_pages' is null
if (in_pages) {
^~~~~~~~
net/9p/trans_virtio.c:502:2: note: Taking false branch
if (in_pages) {
^
net/9p/trans_virtio.c:508:2: note: Taking false branch
BUG_ON(out_sgs + in_sgs > ARRAY_SIZE(sgs));
^
include/asm-generic/bug.h:71:32: note: expanded from macro 'BUG_ON'
#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
^
net/9p/trans_virtio.c:508:2: note: Loop condition is false. Exiting loop
BUG_ON(out_sgs + in_sgs > ARRAY_SIZE(sgs));
^
include/asm-generic/bug.h:71:27: note: expanded from macro 'BUG_ON'
#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
^
net/9p/trans_virtio.c:511:6: note: Assuming 'err' is >= 0
if (err < 0) {
^~~~~~~
net/9p/trans_virtio.c:511:2: note: Taking false branch
if (err < 0) {
^
net/9p/trans_virtio.c:533:2: note: Taking false branch
p9_debug(P9_DEBUG_TRANS, "virtio request kicked\n");
^
include/net/9p/9p.h:56:2: note: expanded from macro 'p9_debug'
no_printk(fmt, ##__VA_ARGS__)
^
include/linux/printk.h:130:2: note: expanded from macro 'no_printk'
if (0) \
^
net/9p/trans_virtio.c:534:8: note: Loop condition is false. Exiting loop
err = wait_event_killable(req->wq, req->status >= REQ_STATUS_RCVD);
^
include/linux/wait.h:928:2: note: expanded from macro 'wait_event_killable'
might_sleep(); \
^
include/linux/kernel.h:143:2: note: expanded from macro 'might_sleep'
do { __might_sleep(__FILE__, __LINE__); might_resched(); } while (0)
^
net/9p/trans_virtio.c:534:37: note: Assuming field 'status' is >= REQ_STATUS_RCVD
err = wait_event_killable(req->wq, req->status >= REQ_STATUS_RCVD);
^
include/linux/wait.h:929:8: note: expanded from macro 'wait_event_killable'
if (!(condition)) \
^~~~~~~~~
net/9p/trans_virtio.c:534:8: note: Taking false branch
err = wait_event_killable(req->wq, req->status >= REQ_STATUS_RCVD);
^
include/linux/wait.h:929:2: note: expanded from macro 'wait_event_killable'
if (!(condition)) \
^
net/9p/trans_virtio.c:536:6: note: Assuming field 'status' is equal to REQ_STATUS_RCVD
if (req->status == REQ_STATUS_RCVD &&
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/9p/trans_virtio.c:536:6: note: Left side of '&&' is true
net/9p/trans_virtio.c:537:15: note: Assuming the condition is true
unlikely(req->rc.sdata[4] == P9_RERROR))
^
include/linux/compiler.h:78:42: note: expanded from macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
^
net/9p/trans_virtio.c:536:2: note: Taking true branch
if (req->status == REQ_STATUS_RCVD &&
^
net/9p/trans_virtio.c:538:3: note: Calling 'handle_rerror'
handle_rerror(req, in_hdr_len, offs, in_pages);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/9p/trans_virtio.c:387:6: note: Assuming 'in_hdr_len' is <= field 'size'
if (req->rc.size < in_hdr_len)
^~~~~~~~~~~~~~~~~~~~~~~~~
net/9p/trans_virtio.c:387:2: note: Taking false branch
if (req->rc.size < in_hdr_len)
^
net/9p/trans_virtio.c:394:15: note: Assuming field 'size' is <= 4096
if (unlikely(req->rc.size > P9_ZC_HDR_SZ))
^
include/linux/compiler.h:78:42: note: expanded from macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
^
net/9p/trans_virtio.c:394:2: note: Taking false branch
if (unlikely(req->rc.size > P9_ZC_HDR_SZ))
^
net/9p/trans_virtio.c:400:6: note: Assuming 'size' is > 'n'
if (size > n) {
^~~~~~~~
net/9p/trans_virtio.c:400:2: note: Taking true branch
if (size > n) {
^
net/9p/trans_virtio.c:401:25: note: Null pointer value stored to 'pages'
memcpy_from_page(to, *pages++, offs, n);
^~~~~~~
net/9p/trans_virtio.c:401:24: note: Dereference of null pointer
memcpy_from_page(to, *pages++, offs, n);
^~~~~~~~
>> net/9p/trans_virtio.c:406:23: warning: Dereference of null pointer (loaded from variable 'pages') [clang-analyzer-core.NullDereference]
memcpy_from_page(to, *pages, offs, size);
^
net/9p/trans_virtio.c:435:2: note: Taking false branch
p9_debug(P9_DEBUG_TRANS, "virtio request\n");
^
include/net/9p/9p.h:56:2: note: expanded from macro 'p9_debug'
no_printk(fmt, ##__VA_ARGS__)
^
include/linux/printk.h:130:2: note: expanded from macro 'no_printk'
if (0) \
^
net/9p/trans_virtio.c:437:6: note: Assuming 'uodata' is null
if (uodata) {
^~~~~~
net/9p/trans_virtio.c:437:2: note: Taking false branch
if (uodata) {
^
net/9p/trans_virtio.c:457:13: note: Assuming 'uidata' is non-null
} else if (uidata) {
^~~~~~
net/9p/trans_virtio.c:457:9: note: Taking true branch
} else if (uidata) {
^
net/9p/trans_virtio.c:458:11: note: Value assigned to 'in_pages'
int n = p9_get_mapped_pages(chan, &in_pages, uidata,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/9p/trans_virtio.c:460:7: note: Assuming 'n' is >= 0
if (n < 0) {
^~~~~
net/9p/trans_virtio.c:460:3: note: Taking false branch
if (n < 0) {
^
net/9p/trans_virtio.c:465:7: note: Assuming 'n' is equal to 'inlen'
if (n != inlen) {
^~~~~~~~~~
net/9p/trans_virtio.c:465:3: note: Taking false branch
if (n != inlen) {
^
net/9p/trans_virtio.c:473:2: note: Loop condition is false. Exiting loop
spin_lock_irqsave(&chan->lock, flags);
^
include/linux/spinlock.h:379:2: note: expanded from macro 'spin_lock_irqsave'
raw_spin_lock_irqsave(spinlock_check(lock), flags); \
^
include/linux/spinlock.h:240:2: note: expanded from macro 'raw_spin_lock_irqsave'
do { \
^
net/9p/trans_virtio.c:473:2: note: Loop condition is false. Exiting loop
spin_lock_irqsave(&chan->lock, flags);
^
include/linux/spinlock.h:377:43: note: expanded from macro 'spin_lock_irqsave'
#define spin_lock_irqsave(lock, flags) \
^
net/9p/trans_virtio.c:481:6: note: Assuming 'out' is 0
if (out)
^~~
net/9p/trans_virtio.c:481:2: note: Taking false branch
if (out)
^
net/9p/trans_virtio.c:484:6: note: 'out_pages' is null
if (out_pages) {
^~~~~~~~~
net/9p/trans_virtio.c:484:2: note: Taking false branch
if (out_pages) {
^
net/9p/trans_virtio.c:499:6: note: Assuming 'in' is 0
if (in)
^~
net/9p/trans_virtio.c:499:2: note: Taking false branch
if (in)
^
net/9p/trans_virtio.c:502:6: note: Assuming 'in_pages' is null
if (in_pages) {
^~~~~~~~
net/9p/trans_virtio.c:502:2: note: Taking false branch
if (in_pages) {
^
net/9p/trans_virtio.c:508:2: note: Taking false branch
BUG_ON(out_sgs + in_sgs > ARRAY_SIZE(sgs));
^
include/asm-generic/bug.h:71:32: note: expanded from macro 'BUG_ON'
#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
^
net/9p/trans_virtio.c:508:2: note: Loop condition is false. Exiting loop
BUG_ON(out_sgs + in_sgs > ARRAY_SIZE(sgs));
^
include/asm-generic/bug.h:71:27: note: expanded from macro 'BUG_ON'
#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
^
net/9p/trans_virtio.c:511:6: note: Assuming 'err' is >= 0
if (err < 0) {
^~~~~~~
net/9p/trans_virtio.c:511:2: note: Taking false branch
if (err < 0) {
^
net/9p/trans_virtio.c:533:2: note: Taking false branch
p9_debug(P9_DEBUG_TRANS, "virtio request kicked\n");
^
include/net/9p/9p.h:56:2: note: expanded from macro 'p9_debug'
no_printk(fmt, ##__VA_ARGS__)
vim +401 net/9p/trans_virtio.c
4038866dab4e46 Venkateswararao Jujjuri (JV 2011-01-28 379)
0e939f8c227af3 Al Viro 2022-06-08 380 static void handle_rerror(struct p9_req_t *req, int in_hdr_len,
0e939f8c227af3 Al Viro 2022-06-08 381 size_t offs, struct page **pages)
0e939f8c227af3 Al Viro 2022-06-08 382 {
0e939f8c227af3 Al Viro 2022-06-08 383 unsigned size, n;
0e939f8c227af3 Al Viro 2022-06-08 384 void *to = req->rc.sdata + in_hdr_len;
0e939f8c227af3 Al Viro 2022-06-08 385
0e939f8c227af3 Al Viro 2022-06-08 386 // Fits entirely into the static data? Nothing to do.
0e939f8c227af3 Al Viro 2022-06-08 387 if (req->rc.size < in_hdr_len)
0e939f8c227af3 Al Viro 2022-06-08 388 return;
0e939f8c227af3 Al Viro 2022-06-08 389
0e939f8c227af3 Al Viro 2022-06-08 390 // Really long error message? Tough, truncate the reply. Might get
0e939f8c227af3 Al Viro 2022-06-08 391 // rejected (we can't be arsed to adjust the size encoded in header,
0e939f8c227af3 Al Viro 2022-06-08 392 // or string size for that matter), but it wouldn't be anything valid
0e939f8c227af3 Al Viro 2022-06-08 393 // anyway.
0e939f8c227af3 Al Viro 2022-06-08 394 if (unlikely(req->rc.size > P9_ZC_HDR_SZ))
0e939f8c227af3 Al Viro 2022-06-08 395 req->rc.size = P9_ZC_HDR_SZ;
0e939f8c227af3 Al Viro 2022-06-08 396
0e939f8c227af3 Al Viro 2022-06-08 397 // data won't span more than two pages
0e939f8c227af3 Al Viro 2022-06-08 398 size = req->rc.size - in_hdr_len;
0e939f8c227af3 Al Viro 2022-06-08 399 n = PAGE_SIZE - offs;
0e939f8c227af3 Al Viro 2022-06-08 400 if (size > n) {
0e939f8c227af3 Al Viro 2022-06-08 @401 memcpy_from_page(to, *pages++, offs, n);
0e939f8c227af3 Al Viro 2022-06-08 402 offs = 0;
0e939f8c227af3 Al Viro 2022-06-08 403 to += n;
0e939f8c227af3 Al Viro 2022-06-08 404 size -= n;
0e939f8c227af3 Al Viro 2022-06-08 405 }
0e939f8c227af3 Al Viro 2022-06-08 @406 memcpy_from_page(to, *pages, offs, size);
0e939f8c227af3 Al Viro 2022-06-08 407 }
0e939f8c227af3 Al Viro 2022-06-08 408
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-06-13 4:54 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-06-08 17:41 [RFC][CFT] handling Rerror without copy_from_iter_full() Al Viro
2022-06-11 13:27 ` Dominique Martinet
2022-06-11 15:19 ` Al Viro
2022-06-11 21:42 ` Dominique Martinet
-- strict thread matches above, loose matches on Subject: below --
2022-06-13 4:54 kernel test robot
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.