Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Fri, Jun 08, 2018 at 04:03:55PM -0400, Steven Rostedt wrote:
> On Thu, 7 Jun 2018 11:18:16 +0200
> Johan Hovold wrote:
>
>
> > If you want to work around the warning and think you can do it in some
> > non-contrived way, then go for it.
> >
> > Clearing the request buffer, checking for termination using strnlen, and
> > then using memcpy might not be too bad.
> >
> > But after all, it is a false positive, so leaving things as they stand
> > is fine too.
>
> Not sure how contrived you think this is, but it solves the warning
> without adding extra work in the normal case.
>
> -- Steve
>
> diff --git a/drivers/staging/greybus/fw-management.c
> b/drivers/staging/greybus/fw-management.c
> index 71aec14f8181..4fb9f1dff47d 100644
> --- a/drivers/staging/greybus/fw-management.c
> +++ b/drivers/staging/greybus/fw-management.c
> @@ -150,15 +150,18 @@ static int fw_mgmt_load_and_validate_operation(struct
> fw_mgmt *fw_mgmt,
> }
>
> request.load_method = load_method;
> - strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> + strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE - 1);
>
> /*
>* The firmware-tag should be NULL terminated, otherwise throw error and
>* fail.
>*/
> - if (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
> - dev_err(fw_mgmt->parent, "load-and-validate: firmware-tag is
> not NULL terminated\n");
> - return -EINVAL;
> + if (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 2] != '\0') {
> + if (tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
> + dev_err(fw_mgmt->parent, "load-and-validate:
> firmware-tag is not NULL terminated\n");
> + return -EINVAL;
> + }
> + request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] = '\0';
> }
Well, I think it's quite far from obvious what is going on above, and
not least why things are being done this way (which a comment may help
with).
And just NUL-terminating the (automatic) buffer before returning wasn't
enough? Then it may be better to do away with strncpy completely.
But should we really be working around gcc this way? If the
implementation of this new warning isn't smart enough yet, should it not
just be disabled instead?
Thanks,
Johan
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Fri, Jun 08, 2018 at 04:03:55PM -0400, Steven Rostedt wrote:
> On Thu, 7 Jun 2018 11:18:16 +0200
> Johan Hovold wrote:
>
>
> > If you want to work around the warning and think you can do it in some
> > non-contrived way, then go for it.
> >
> > Clearing the request buffer, checking for termination using strnlen, and
> > then using memcpy might not be too bad.
> >
> > But after all, it is a false positive, so leaving things as they stand
> > is fine too.
>
> Not sure how contrived you think this is, but it solves the warning
> without adding extra work in the normal case.
>
> -- Steve
>
> diff --git a/drivers/staging/greybus/fw-management.c
> b/drivers/staging/greybus/fw-management.c
> index 71aec14f8181..4fb9f1dff47d 100644
> --- a/drivers/staging/greybus/fw-management.c
> +++ b/drivers/staging/greybus/fw-management.c
> @@ -150,15 +150,18 @@ static int fw_mgmt_load_and_validate_operation(struct
> fw_mgmt *fw_mgmt,
> }
>
> request.load_method = load_method;
> - strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> + strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE - 1);
>
> /*
>* The firmware-tag should be NULL terminated, otherwise throw error and
>* fail.
>*/
> - if (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
> - dev_err(fw_mgmt->parent, "load-and-validate: firmware-tag is
> not NULL terminated\n");
> - return -EINVAL;
> + if (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 2] != '\0') {
> + if (tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
> + dev_err(fw_mgmt->parent, "load-and-validate:
> firmware-tag is not NULL terminated\n");
> + return -EINVAL;
> + }
> + request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] = '\0';
> }
Well, I think it's quite far from obvious what is going on above, and
not least why things are being done this way (which a comment may help
with).
And just NUL-terminating the (automatic) buffer before returning wasn't
enough? Then it may be better to do away with strncpy completely.
But should we really be working around gcc this way? If the
implementation of this new warning isn't smart enough yet, should it not
just be disabled instead?
Thanks,
Johan
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Thu, 7 Jun 2018 11:18:16 +0200
Johan Hovold wrote:
> If you want to work around the warning and think you can do it in some
> non-contrived way, then go for it.
>
> Clearing the request buffer, checking for termination using strnlen, and
> then using memcpy might not be too bad.
>
> But after all, it is a false positive, so leaving things as they stand
> is fine too.
Not sure how contrived you think this is, but it solves the warning
without adding extra work in the normal case.
-- Steve
diff --git a/drivers/staging/greybus/fw-management.c
b/drivers/staging/greybus/fw-management.c
index 71aec14f8181..4fb9f1dff47d 100644
--- a/drivers/staging/greybus/fw-management.c
+++ b/drivers/staging/greybus/fw-management.c
@@ -150,15 +150,18 @@ static int fw_mgmt_load_and_validate_operation(struct
fw_mgmt *fw_mgmt,
}
request.load_method = load_method;
- strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
+ strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE - 1);
/*
* The firmware-tag should be NULL terminated, otherwise throw error and
* fail.
*/
- if (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
- dev_err(fw_mgmt->parent, "load-and-validate: firmware-tag is
not NULL terminated\n");
- return -EINVAL;
+ if (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 2] != '\0') {
+ if (tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
+ dev_err(fw_mgmt->parent, "load-and-validate:
firmware-tag is not NULL terminated\n");
+ return -EINVAL;
+ }
+ request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] = '\0';
}
/* Allocate ids from 1 to 255 (u8-max), 0 is an invalid id */
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Thu, 7 Jun 2018 11:18:16 +0200
Johan Hovold wrote:
> If you want to work around the warning and think you can do it in some
> non-contrived way, then go for it.
>
> Clearing the request buffer, checking for termination using strnlen, and
> then using memcpy might not be too bad.
>
> But after all, it is a false positive, so leaving things as they stand
> is fine too.
Not sure how contrived you think this is, but it solves the warning
without adding extra work in the normal case.
-- Steve
diff --git a/drivers/staging/greybus/fw-management.c
b/drivers/staging/greybus/fw-management.c
index 71aec14f8181..4fb9f1dff47d 100644
--- a/drivers/staging/greybus/fw-management.c
+++ b/drivers/staging/greybus/fw-management.c
@@ -150,15 +150,18 @@ static int fw_mgmt_load_and_validate_operation(struct
fw_mgmt *fw_mgmt,
}
request.load_method = load_method;
- strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
+ strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE - 1);
/*
* The firmware-tag should be NULL terminated, otherwise throw error and
* fail.
*/
- if (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
- dev_err(fw_mgmt->parent, "load-and-validate: firmware-tag is
not NULL terminated\n");
- return -EINVAL;
+ if (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 2] != '\0') {
+ if (tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
+ dev_err(fw_mgmt->parent, "load-and-validate:
firmware-tag is not NULL terminated\n");
+ return -EINVAL;
+ }
+ request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] = '\0';
}
/* Allocate ids from 1 to 255 (u8-max), 0 is an invalid id */
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Thu, Jun 07, 2018 at 05:12:51AM -0500, Alex Elder wrote: > On 06/07/2018 04:19 AM, Viresh Kumar wrote: > > On 07-06-18, 11:18, Johan Hovold wrote: > >> If you want to work around the warning and think you can do it in some > >> non-contrived way, then go for it. > >> > >> Clearing the request buffer, checking for termination using strnlen, and > >> then using memcpy might not be too bad. > >> > >> But after all, it is a false positive, so leaving things as they stand > >> is fine too. > > > > Leave it then :) > > > > It's interesting that the warning isn't reported for this in > fw_mgmt_interface_fw_version_operation(). The difference there is > that you actually put a zero byte at that last position before > returning. I'm mildly impressed if gcc is distinguishing that. Found a redhat blog post claiming it does check for some cases like that: https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/ > You *are* returning the fw_info->firmware_tag array newly filled > with a non-null-terminated string in one of the two cases that > get warnings in "fw-management.c". No, there's no warning for that one (line 250), and there fw_info is used as the source, not the destination, so no unterminated string is returned there either. > But the other one is only > updating a buffer in a local/automatic variable. All three cases, except the one that is explicitly terminated. > Weird. I wish there were a non-clumsy way of marking false positives > like this as A-OK. The gcc docs mentions an attribute for that but it seems a bit overkill here. Thanks, Johan
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Thu, Jun 07, 2018 at 05:12:51AM -0500, Alex Elder wrote: > On 06/07/2018 04:19 AM, Viresh Kumar wrote: > > On 07-06-18, 11:18, Johan Hovold wrote: > >> If you want to work around the warning and think you can do it in some > >> non-contrived way, then go for it. > >> > >> Clearing the request buffer, checking for termination using strnlen, and > >> then using memcpy might not be too bad. > >> > >> But after all, it is a false positive, so leaving things as they stand > >> is fine too. > > > > Leave it then :) > > > > It's interesting that the warning isn't reported for this in > fw_mgmt_interface_fw_version_operation(). The difference there is > that you actually put a zero byte at that last position before > returning. I'm mildly impressed if gcc is distinguishing that. Found a redhat blog post claiming it does check for some cases like that: https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/ > You *are* returning the fw_info->firmware_tag array newly filled > with a non-null-terminated string in one of the two cases that > get warnings in "fw-management.c". No, there's no warning for that one (line 250), and there fw_info is used as the source, not the destination, so no unterminated string is returned there either. > But the other one is only > updating a buffer in a local/automatic variable. All three cases, except the one that is explicitly terminated. > Weird. I wish there were a non-clumsy way of marking false positives > like this as A-OK. The gcc docs mentions an attribute for that but it seems a bit overkill here. Thanks, Johan
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On 06/07/2018 04:19 AM, Viresh Kumar wrote: > On 07-06-18, 11:18, Johan Hovold wrote: >> If you want to work around the warning and think you can do it in some >> non-contrived way, then go for it. >> >> Clearing the request buffer, checking for termination using strnlen, and >> then using memcpy might not be too bad. >> >> But after all, it is a false positive, so leaving things as they stand >> is fine too. > > Leave it then :) > It's interesting that the warning isn't reported for this in fw_mgmt_interface_fw_version_operation(). The difference there is that you actually put a zero byte at that last position before returning. I'm mildly impressed if gcc is distinguishing that. You *are* returning the fw_info->firmware_tag array newly filled with a non-null-terminated string in one of the two cases that get warnings in "fw-management.c". But the other one is only updating a buffer in a local/automatic variable. Weird. I wish there were a non-clumsy way of marking false positives like this as A-OK. -Alex
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On 06/07/2018 04:19 AM, Viresh Kumar wrote: > On 07-06-18, 11:18, Johan Hovold wrote: >> If you want to work around the warning and think you can do it in some >> non-contrived way, then go for it. >> >> Clearing the request buffer, checking for termination using strnlen, and >> then using memcpy might not be too bad. >> >> But after all, it is a false positive, so leaving things as they stand >> is fine too. > > Leave it then :) > It's interesting that the warning isn't reported for this in fw_mgmt_interface_fw_version_operation(). The difference there is that you actually put a zero byte at that last position before returning. I'm mildly impressed if gcc is distinguishing that. You *are* returning the fw_info->firmware_tag array newly filled with a non-null-terminated string in one of the two cases that get warnings in "fw-management.c". But the other one is only updating a buffer in a local/automatic variable. Weird. I wish there were a non-clumsy way of marking false positives like this as A-OK. -Alex
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Thu, 2018-06-07 at 14:08 +0530, Viresh Kumar wrote: > On 07-06-18, 15:46, Du, Changbin wrote: > > I think if the destination is not a null terminated string (If I understand > > your > > description below), memcpy can be used to get rid of such warning. The > > warning > > makes sense in general as explained in mannual. Thanks! > > The destination should be a null terminated string eventually, but we first > need > to make sure src is a null terminated string. Is there strnlen() or memchr() in the kernel? Then check the source before copying it. Kind regards, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Thu, 2018-06-07 at 14:08 +0530, Viresh Kumar wrote: > On 07-06-18, 15:46, Du, Changbin wrote: > > I think if the destination is not a null terminated string (If I understand > > your > > description below), memcpy can be used to get rid of such warning. The > > warning > > makes sense in general as explained in mannual. Thanks! > > The destination should be a null terminated string eventually, but we first > need > to make sure src is a null terminated string. Is there strnlen() or memchr() in the kernel? Then check the source before copying it. Kind regards, Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On 07-06-18, 11:18, Johan Hovold wrote: > If you want to work around the warning and think you can do it in some > non-contrived way, then go for it. > > Clearing the request buffer, checking for termination using strnlen, and > then using memcpy might not be too bad. > > But after all, it is a false positive, so leaving things as they stand > is fine too. Leave it then :) -- viresh
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On 07-06-18, 11:18, Johan Hovold wrote: > If you want to work around the warning and think you can do it in some > non-contrived way, then go for it. > > Clearing the request buffer, checking for termination using strnlen, and > then using memcpy might not be too bad. > > But after all, it is a false positive, so leaving things as they stand > is fine too. Leave it then :) -- viresh
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Thu, Jun 07, 2018 at 02:40:25PM +0530, Viresh Kumar wrote: > On 07-06-18, 11:03, Bernd Petrovitsch wrote: > > On Thu, 2018-06-07 at 14:08 +0530, Viresh Kumar wrote: > > > On 07-06-18, 15:46, Du, Changbin wrote: > > > > I think if the destination is not a null terminated string (If I > > > > understand your > > > > description below), memcpy can be used to get rid of such warning. The > > > > warning > > > > makes sense in general as explained in mannual. Thanks! > > > > > > The destination should be a null terminated string eventually, but we > > > first need > > > to make sure src is a null terminated string. > > > > Is there strnlen() or memchr() in the kernel? > > Then check the source before copying it. > > It would be extra work, but memchr can be used to work around this I believe. > > @Johan ?? If you want to work around the warning and think you can do it in some non-contrived way, then go for it. Clearing the request buffer, checking for termination using strnlen, and then using memcpy might not be too bad. But after all, it is a false positive, so leaving things as they stand is fine too. Thanks, Johan
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Thu, Jun 07, 2018 at 02:40:25PM +0530, Viresh Kumar wrote: > On 07-06-18, 11:03, Bernd Petrovitsch wrote: > > On Thu, 2018-06-07 at 14:08 +0530, Viresh Kumar wrote: > > > On 07-06-18, 15:46, Du, Changbin wrote: > > > > I think if the destination is not a null terminated string (If I > > > > understand your > > > > description below), memcpy can be used to get rid of such warning. The > > > > warning > > > > makes sense in general as explained in mannual. Thanks! > > > > > > The destination should be a null terminated string eventually, but we > > > first need > > > to make sure src is a null terminated string. > > > > Is there strnlen() or memchr() in the kernel? > > Then check the source before copying it. > > It would be extra work, but memchr can be used to work around this I believe. > > @Johan ?? If you want to work around the warning and think you can do it in some non-contrived way, then go for it. Clearing the request buffer, checking for termination using strnlen, and then using memcpy might not be too bad. But after all, it is a false positive, so leaving things as they stand is fine too. Thanks, Johan
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On 07-06-18, 11:03, Bernd Petrovitsch wrote: > On Thu, 2018-06-07 at 14:08 +0530, Viresh Kumar wrote: > > On 07-06-18, 15:46, Du, Changbin wrote: > > > I think if the destination is not a null terminated string (If I > > > understand your > > > description below), memcpy can be used to get rid of such warning. The > > > warning > > > makes sense in general as explained in mannual. Thanks! > > > > The destination should be a null terminated string eventually, but we first > > need > > to make sure src is a null terminated string. > > Is there strnlen() or memchr() in the kernel? > Then check the source before copying it. It would be extra work, but memchr can be used to work around this I believe. @Johan ?? -- viresh
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On 07-06-18, 11:03, Bernd Petrovitsch wrote: > On Thu, 2018-06-07 at 14:08 +0530, Viresh Kumar wrote: > > On 07-06-18, 15:46, Du, Changbin wrote: > > > I think if the destination is not a null terminated string (If I > > > understand your > > > description below), memcpy can be used to get rid of such warning. The > > > warning > > > makes sense in general as explained in mannual. Thanks! > > > > The destination should be a null terminated string eventually, but we first > > need > > to make sure src is a null terminated string. > > Is there strnlen() or memchr() in the kernel? > Then check the source before copying it. It would be extra work, but memchr can be used to work around this I believe. @Johan ?? -- viresh
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On 07-06-18, 15:46, Du, Changbin wrote: > I think if the destination is not a null terminated string (If I understand > your > description below), memcpy can be used to get rid of such warning. The warning > makes sense in general as explained in mannual. Thanks! The destination should be a null terminated string eventually, but we first need to make sure src is a null terminated string. -- viresh
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On 07-06-18, 15:46, Du, Changbin wrote: > I think if the destination is not a null terminated string (If I understand > your > description below), memcpy can be used to get rid of such warning. The warning > makes sense in general as explained in mannual. Thanks! The destination should be a null terminated string eventually, but we first need to make sure src is a null terminated string. -- viresh
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Thu, Jun 07, 2018 at 09:47:18AM +0530, Viresh Kumar wrote: > On 06-06-18, 14:26, Steven Rostedt wrote: > > On Wed, 6 Jun 2018 16:26:00 +0200 > > Johan Hovold wrote: > > > > > Looks like the greybus code above is working as intended by checking for > > > unterminated string after the strncpy, even if this does now triggers > > > the truncation warning. > > So why exactly are we generating a warning here ? Is it because it is possible > that the first n bytes of src may not have the null terminating byte and the > dest may not be null terminated eventually ? Yes, new warning in GCC 8: https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html#index-Wstringop-truncation > Maybe I should just use memcpy here then ? No, as you note below, you use strncpy to clear the rest of the buffer. > But AFAIR, I used strncpy() specifically because it also sets all the > remaining > bytes after the null terminating byte with the null terminating byte. And so > it > is pretty easy for me to check if the final string is null terminated by > checking [max - 1] byte against '\0', which the code is doing right now. > > I am not sure what would the best way to get around this incorrect-warning. It seems gcc just isn't smart enough in this case (where you check for overflow and never use a non-terminated string), but it is supposed to detect when the string is unconditionally terminated. So perhaps just adding a redundant buf[size-1] = '\0' before returning in the error path or after the error path would shut it up. But that's a bit of a long shot, I admit. Probably best to leave things as they are, and let the gcc folks find a way to handle such false positives. Thanks, Johan
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Thu, Jun 07, 2018 at 09:47:18AM +0530, Viresh Kumar wrote: > On 06-06-18, 14:26, Steven Rostedt wrote: > > On Wed, 6 Jun 2018 16:26:00 +0200 > > Johan Hovold wrote: > > > > > Looks like the greybus code above is working as intended by checking for > > > unterminated string after the strncpy, even if this does now triggers > > > the truncation warning. > > So why exactly are we generating a warning here ? Is it because it is possible > that the first n bytes of src may not have the null terminating byte and the > dest may not be null terminated eventually ? Yes, new warning in GCC 8: https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html#index-Wstringop-truncation > Maybe I should just use memcpy here then ? No, as you note below, you use strncpy to clear the rest of the buffer. > But AFAIR, I used strncpy() specifically because it also sets all the > remaining > bytes after the null terminating byte with the null terminating byte. And so > it > is pretty easy for me to check if the final string is null terminated by > checking [max - 1] byte against '\0', which the code is doing right now. > > I am not sure what would the best way to get around this incorrect-warning. It seems gcc just isn't smart enough in this case (where you check for overflow and never use a non-terminated string), but it is supposed to detect when the string is unconditionally terminated. So perhaps just adding a redundant buf[size-1] = '\0' before returning in the error path or after the error path would shut it up. But that's a bit of a long shot, I admit. Probably best to leave things as they are, and let the gcc folks find a way to handle such false positives. Thanks, Johan
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
Hi, On Thu, Jun 07, 2018 at 09:47:18AM +0530, Viresh Kumar wrote: > +Greg/Alex, > > @Fegguang/build-bot: I do see mention of Greg and /me in your initial email's > body saying TO: Viresh, CC: Greg, but I don't see any of us getting cc'd in > your > email. Bug ? > > On 06-06-18, 14:26, Steven Rostedt wrote: > > On Wed, 6 Jun 2018 16:26:00 +0200 > > Johan Hovold wrote: > > > > > Looks like the greybus code above is working as intended by checking for > > > unterminated string after the strncpy, even if this does now triggers > > > the truncation warning. > > So why exactly are we generating a warning here ? Is it because it is possible > that the first n bytes of src may not have the null terminating byte and the > dest may not be null terminated eventually ? > > Maybe I should just use memcpy here then ? > I think if the destination is not a null terminated string (If I understand your description below), memcpy can be used to get rid of such warning. The warning makes sense in general as explained in mannual. Thanks! > But AFAIR, I used strncpy() specifically because it also sets all the > remaining > bytes after the null terminating byte with the null terminating byte. And so > it > is pretty easy for me to check if the final string is null terminated by > checking [max - 1] byte against '\0', which the code is doing right now. > > I am not sure what would the best way to get around this incorrect-warning. > > And I am wondering on why buildbot reported the warning only for two instances > in that file, while I have done the same thing at 4 places. > > > Ah, yes I now see that. Thanks for pointing it out. But perhaps it > > should also add the "- 1" to the strncpy() so that gcc doesn't think > > it's a mistake. > > The src string is passed on from a firmware entity and we need to make sure > the > protocol (greybus) is implemented properly by the other end. For example, in > the > current case if the firmware sends "HELLOWORLD", its an error as it should > have > sent "HELLWORLD\0". But with what you are saying we will forcefully make dest > as > "HELLWORLD\0", which wouldn't be the right thing to do as we will miss the bug > present in firmware. > > -- > viresh -- Thanks, Changbin Du
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
Hi, On Thu, Jun 07, 2018 at 09:47:18AM +0530, Viresh Kumar wrote: > +Greg/Alex, > > @Fegguang/build-bot: I do see mention of Greg and /me in your initial email's > body saying TO: Viresh, CC: Greg, but I don't see any of us getting cc'd in > your > email. Bug ? > > On 06-06-18, 14:26, Steven Rostedt wrote: > > On Wed, 6 Jun 2018 16:26:00 +0200 > > Johan Hovold wrote: > > > > > Looks like the greybus code above is working as intended by checking for > > > unterminated string after the strncpy, even if this does now triggers > > > the truncation warning. > > So why exactly are we generating a warning here ? Is it because it is possible > that the first n bytes of src may not have the null terminating byte and the > dest may not be null terminated eventually ? > > Maybe I should just use memcpy here then ? > I think if the destination is not a null terminated string (If I understand your description below), memcpy can be used to get rid of such warning. The warning makes sense in general as explained in mannual. Thanks! > But AFAIR, I used strncpy() specifically because it also sets all the > remaining > bytes after the null terminating byte with the null terminating byte. And so > it > is pretty easy for me to check if the final string is null terminated by > checking [max - 1] byte against '\0', which the code is doing right now. > > I am not sure what would the best way to get around this incorrect-warning. > > And I am wondering on why buildbot reported the warning only for two instances > in that file, while I have done the same thing at 4 places. > > > Ah, yes I now see that. Thanks for pointing it out. But perhaps it > > should also add the "- 1" to the strncpy() so that gcc doesn't think > > it's a mistake. > > The src string is passed on from a firmware entity and we need to make sure > the > protocol (greybus) is implemented properly by the other end. For example, in > the > current case if the firmware sends "HELLOWORLD", its an error as it should > have > sent "HELLWORLD\0". But with what you are saying we will forcefully make dest > as > "HELLWORLD\0", which wouldn't be the right thing to do as we will miss the bug > present in firmware. > > -- > viresh -- Thanks, Changbin Du
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
+Greg/Alex, @Fegguang/build-bot: I do see mention of Greg and /me in your initial email's body saying TO: Viresh, CC: Greg, but I don't see any of us getting cc'd in your email. Bug ? On 06-06-18, 14:26, Steven Rostedt wrote: > On Wed, 6 Jun 2018 16:26:00 +0200 > Johan Hovold wrote: > > > Looks like the greybus code above is working as intended by checking for > > unterminated string after the strncpy, even if this does now triggers > > the truncation warning. So why exactly are we generating a warning here ? Is it because it is possible that the first n bytes of src may not have the null terminating byte and the dest may not be null terminated eventually ? Maybe I should just use memcpy here then ? But AFAIR, I used strncpy() specifically because it also sets all the remaining bytes after the null terminating byte with the null terminating byte. And so it is pretty easy for me to check if the final string is null terminated by checking [max - 1] byte against '\0', which the code is doing right now. I am not sure what would the best way to get around this incorrect-warning. And I am wondering on why buildbot reported the warning only for two instances in that file, while I have done the same thing at 4 places. > Ah, yes I now see that. Thanks for pointing it out. But perhaps it > should also add the "- 1" to the strncpy() so that gcc doesn't think > it's a mistake. The src string is passed on from a firmware entity and we need to make sure the protocol (greybus) is implemented properly by the other end. For example, in the current case if the firmware sends "HELLOWORLD", its an error as it should have sent "HELLWORLD\0". But with what you are saying we will forcefully make dest as "HELLWORLD\0", which wouldn't be the right thing to do as we will miss the bug present in firmware. -- viresh
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
+Greg/Alex, @Fegguang/build-bot: I do see mention of Greg and /me in your initial email's body saying TO: Viresh, CC: Greg, but I don't see any of us getting cc'd in your email. Bug ? On 06-06-18, 14:26, Steven Rostedt wrote: > On Wed, 6 Jun 2018 16:26:00 +0200 > Johan Hovold wrote: > > > Looks like the greybus code above is working as intended by checking for > > unterminated string after the strncpy, even if this does now triggers > > the truncation warning. So why exactly are we generating a warning here ? Is it because it is possible that the first n bytes of src may not have the null terminating byte and the dest may not be null terminated eventually ? Maybe I should just use memcpy here then ? But AFAIR, I used strncpy() specifically because it also sets all the remaining bytes after the null terminating byte with the null terminating byte. And so it is pretty easy for me to check if the final string is null terminated by checking [max - 1] byte against '\0', which the code is doing right now. I am not sure what would the best way to get around this incorrect-warning. And I am wondering on why buildbot reported the warning only for two instances in that file, while I have done the same thing at 4 places. > Ah, yes I now see that. Thanks for pointing it out. But perhaps it > should also add the "- 1" to the strncpy() so that gcc doesn't think > it's a mistake. The src string is passed on from a firmware entity and we need to make sure the protocol (greybus) is implemented properly by the other end. For example, in the current case if the firmware sends "HELLOWORLD", its an error as it should have sent "HELLWORLD\0". But with what you are saying we will forcefully make dest as "HELLWORLD\0", which wouldn't be the right thing to do as we will miss the bug present in firmware. -- viresh
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Wed, 6 Jun 2018 16:26:00 +0200 Johan Hovold wrote: > Looks like the greybus code above is working as intended by checking for > unterminated string after the strncpy, even if this does now triggers > the truncation warning. Ah, yes I now see that. Thanks for pointing it out. But perhaps it should also add the "- 1" to the strncpy() so that gcc doesn't think it's a mistake. -- Steve
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Wed, 6 Jun 2018 16:26:00 +0200 Johan Hovold wrote: > Looks like the greybus code above is working as intended by checking for > unterminated string after the strncpy, even if this does now triggers > the truncation warning. Ah, yes I now see that. Thanks for pointing it out. But perhaps it should also add the "- 1" to the strncpy() so that gcc doesn't think it's a mistake. -- Steve
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Wed, Jun 06, 2018 at 09:57:14AM -0400, Steven Rostedt wrote:
> On Wed, 6 Jun 2018 05:21:55 +0800
> kbuild test robot wrote:
>
> > Hi Changbin,
> >
> > Thank you for the patch! Perhaps something to improve:
> >
> > [auto build test WARNING on linus/master]
> > [also build test WARNING on v4.17 next-20180605]
> > [if your patch is applied to the wrong git tree, please drop us a note to
> > help improve the system]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
> > config: ia64-allmodconfig (attached as .config)
> > compiler: ia64-linux-gcc (GCC) 8.1.0
> > reproduce:
> > wget
> > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> > ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > make.cross ARCH=ia64
> >
> > All warnings (new ones prefixed by >>):
> >
> >drivers//staging/greybus/fw-management.c: In function
> > 'fw_mgmt_load_and_validate_operation':
> > >> drivers//staging/greybus/fw-management.c:153:2: warning: 'strncpy'
> > >> specified bound 10 equals destination size [-Wstringop-truncation]
> > strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> > ^~~~
> >drivers//staging/greybus/fw-management.c: In function
> > 'fw_mgmt_backend_fw_update_operation':
> >drivers//staging/greybus/fw-management.c:304:2: warning: 'strncpy'
> > specified bound 10 equals destination size [-Wstringop-truncation]
> > strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> > ^~~~
> > --
> >drivers/auxdisplay/panel.c: In function 'panel_bind_key':
> > >> drivers/auxdisplay/panel.c:1509:2: warning: 'strncpy' specified bound 12
> > >> equals destination size [-Wstringop-truncation]
> > strncpy(key->u.kbd.press_str, press, sizeof(key->u.kbd.press_str));
> > ^~
> >drivers/auxdisplay/panel.c:1510:2: warning: 'strncpy' specified bound 12
> > equals destination size [-Wstringop-truncation]
> > strncpy(key->u.kbd.repeat_str, repeat, sizeof(key->u.kbd.repeat_str));
> > ^
>
> Nice! This patch actually caused bugs in other areas of the code to be
> caught by the build system.
>
> The patch is not wrong. The code that has these warnings are.
Looks like the greybus code above is working as intended by checking for
unterminated string after the strncpy, even if this does now triggers
the truncation warning.
drivers/auxdisplay/panel.c looks broken, though.
> > vim +/strncpy +153 drivers//staging/greybus/fw-management.c
> >
> > 013e6653 Viresh Kumar 2016-05-14 138
> > 013e6653 Viresh Kumar 2016-05-14 139 static int
> > fw_mgmt_load_and_validate_operation(struct fw_mgmt *fw_mgmt,
> > 013e6653 Viresh Kumar 2016-05-14 140
> >u8 load_method, const char *tag)
> > 013e6653 Viresh Kumar 2016-05-14 141 {
> > 013e6653 Viresh Kumar 2016-05-14 142 struct
> > gb_fw_mgmt_load_and_validate_fw_request request;
> > 013e6653 Viresh Kumar 2016-05-14 143 int ret;
> > 013e6653 Viresh Kumar 2016-05-14 144
> > 013e6653 Viresh Kumar 2016-05-14 145 if (load_method !=
> > GB_FW_LOAD_METHOD_UNIPRO &&
> > 013e6653 Viresh Kumar 2016-05-14 146 load_method !=
> > GB_FW_LOAD_METHOD_INTERNAL) {
> > 013e6653 Viresh Kumar 2016-05-14 147 dev_err(fw_mgmt->parent,
> > 013e6653 Viresh Kumar 2016-05-14 148 "invalid
> > load-method (%d)\n", load_method);
> > 013e6653 Viresh Kumar 2016-05-14 149 return -EINVAL;
> > 013e6653 Viresh Kumar 2016-05-14 150 }
> > 013e6653 Viresh Kumar 2016-05-14 151
> > 013e6653 Viresh Kumar 2016-05-14 152 request.load_method =
> > load_method;
> > b2abeaa1 Viresh Kumar 2016-08-11 @153 strncpy(request.firmware_tag,
> > tag, GB_FIRMWARE_TAG_MAX_SIZE);
> > 013e6653 Viresh Kumar 2016-05-14 154
> > 013e6653 Viresh Kumar 2016-05-14 155 /*
> > 013e6653 Viresh Kumar 2016-05-14 156* The firmware-tag should be
> > NULL terminated, otherwise throw error and
> > 013e6653 Viresh Kumar 2016-05-14 157* fail.
> > 013e6653 Viresh Kumar 2016-05-14 158*/
> > b2abeaa1 Viresh Kumar 2016-08-11 159 if
> > (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
> > 013e6653 Viresh Kumar 2016-05-14 160
> > dev_err(fw_mgmt->parent, "load-and-validate: firmware-tag is not NULL
> > terminated\n");
> > 013e6653 Viresh Kumar 2016-05-14 161 return -EINVAL;
> > 013e6653 Viresh Kumar 2016-05-14 162 }
Viresh, do you want to work around the warning somehow?
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Wed, Jun 06, 2018 at 09:57:14AM -0400, Steven Rostedt wrote:
> On Wed, 6 Jun 2018 05:21:55 +0800
> kbuild test robot wrote:
>
> > Hi Changbin,
> >
> > Thank you for the patch! Perhaps something to improve:
> >
> > [auto build test WARNING on linus/master]
> > [also build test WARNING on v4.17 next-20180605]
> > [if your patch is applied to the wrong git tree, please drop us a note to
> > help improve the system]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
> > config: ia64-allmodconfig (attached as .config)
> > compiler: ia64-linux-gcc (GCC) 8.1.0
> > reproduce:
> > wget
> > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> > ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > make.cross ARCH=ia64
> >
> > All warnings (new ones prefixed by >>):
> >
> >drivers//staging/greybus/fw-management.c: In function
> > 'fw_mgmt_load_and_validate_operation':
> > >> drivers//staging/greybus/fw-management.c:153:2: warning: 'strncpy'
> > >> specified bound 10 equals destination size [-Wstringop-truncation]
> > strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> > ^~~~
> >drivers//staging/greybus/fw-management.c: In function
> > 'fw_mgmt_backend_fw_update_operation':
> >drivers//staging/greybus/fw-management.c:304:2: warning: 'strncpy'
> > specified bound 10 equals destination size [-Wstringop-truncation]
> > strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> > ^~~~
> > --
> >drivers/auxdisplay/panel.c: In function 'panel_bind_key':
> > >> drivers/auxdisplay/panel.c:1509:2: warning: 'strncpy' specified bound 12
> > >> equals destination size [-Wstringop-truncation]
> > strncpy(key->u.kbd.press_str, press, sizeof(key->u.kbd.press_str));
> > ^~
> >drivers/auxdisplay/panel.c:1510:2: warning: 'strncpy' specified bound 12
> > equals destination size [-Wstringop-truncation]
> > strncpy(key->u.kbd.repeat_str, repeat, sizeof(key->u.kbd.repeat_str));
> > ^
>
> Nice! This patch actually caused bugs in other areas of the code to be
> caught by the build system.
>
> The patch is not wrong. The code that has these warnings are.
Looks like the greybus code above is working as intended by checking for
unterminated string after the strncpy, even if this does now triggers
the truncation warning.
drivers/auxdisplay/panel.c looks broken, though.
> > vim +/strncpy +153 drivers//staging/greybus/fw-management.c
> >
> > 013e6653 Viresh Kumar 2016-05-14 138
> > 013e6653 Viresh Kumar 2016-05-14 139 static int
> > fw_mgmt_load_and_validate_operation(struct fw_mgmt *fw_mgmt,
> > 013e6653 Viresh Kumar 2016-05-14 140
> >u8 load_method, const char *tag)
> > 013e6653 Viresh Kumar 2016-05-14 141 {
> > 013e6653 Viresh Kumar 2016-05-14 142 struct
> > gb_fw_mgmt_load_and_validate_fw_request request;
> > 013e6653 Viresh Kumar 2016-05-14 143 int ret;
> > 013e6653 Viresh Kumar 2016-05-14 144
> > 013e6653 Viresh Kumar 2016-05-14 145 if (load_method !=
> > GB_FW_LOAD_METHOD_UNIPRO &&
> > 013e6653 Viresh Kumar 2016-05-14 146 load_method !=
> > GB_FW_LOAD_METHOD_INTERNAL) {
> > 013e6653 Viresh Kumar 2016-05-14 147 dev_err(fw_mgmt->parent,
> > 013e6653 Viresh Kumar 2016-05-14 148 "invalid
> > load-method (%d)\n", load_method);
> > 013e6653 Viresh Kumar 2016-05-14 149 return -EINVAL;
> > 013e6653 Viresh Kumar 2016-05-14 150 }
> > 013e6653 Viresh Kumar 2016-05-14 151
> > 013e6653 Viresh Kumar 2016-05-14 152 request.load_method =
> > load_method;
> > b2abeaa1 Viresh Kumar 2016-08-11 @153 strncpy(request.firmware_tag,
> > tag, GB_FIRMWARE_TAG_MAX_SIZE);
> > 013e6653 Viresh Kumar 2016-05-14 154
> > 013e6653 Viresh Kumar 2016-05-14 155 /*
> > 013e6653 Viresh Kumar 2016-05-14 156* The firmware-tag should be
> > NULL terminated, otherwise throw error and
> > 013e6653 Viresh Kumar 2016-05-14 157* fail.
> > 013e6653 Viresh Kumar 2016-05-14 158*/
> > b2abeaa1 Viresh Kumar 2016-08-11 159 if
> > (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
> > 013e6653 Viresh Kumar 2016-05-14 160
> > dev_err(fw_mgmt->parent, "load-and-validate: firmware-tag is not NULL
> > terminated\n");
> > 013e6653 Viresh Kumar 2016-05-14 161 return -EINVAL;
> > 013e6653 Viresh Kumar 2016-05-14 162 }
Viresh, do you want to work around the warning somehow?
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Wed, 6 Jun 2018 05:34:29 +0800 kbuild test robot wrote: > Hi Changbin, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on linus/master] > [also build test WARNING on v4.17 next-20180605] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415 > config: sparc64-allyesconfig (attached as .config) > compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=sparc64 > > All warnings (new ones prefixed by >>): > > >> WARNING: vmlinux.o(.text.unlikely+0x1fc): Section mismatch in reference > >> from the function init_tick_ops() to the function > >> .init.text:get_tick_patch() >The function init_tick_ops() references >the function __init get_tick_patch(). >This is often because init_tick_ops lacks a __init >annotation or the annotation of get_tick_patch is wrong. And again this patch uncovered a bug someplace else. -- Steve > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Wed, 6 Jun 2018 05:34:29 +0800 kbuild test robot wrote: > Hi Changbin, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on linus/master] > [also build test WARNING on v4.17 next-20180605] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415 > config: sparc64-allyesconfig (attached as .config) > compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=sparc64 > > All warnings (new ones prefixed by >>): > > >> WARNING: vmlinux.o(.text.unlikely+0x1fc): Section mismatch in reference > >> from the function init_tick_ops() to the function > >> .init.text:get_tick_patch() >The function init_tick_ops() references >the function __init get_tick_patch(). >This is often because init_tick_ops lacks a __init >annotation or the annotation of get_tick_patch is wrong. And again this patch uncovered a bug someplace else. -- Steve > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Wed, 6 Jun 2018 05:21:55 +0800
kbuild test robot wrote:
> Hi Changbin,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.17 next-20180605]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
> config: ia64-allmodconfig (attached as .config)
> compiler: ia64-linux-gcc (GCC) 8.1.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=ia64
>
> All warnings (new ones prefixed by >>):
>
>drivers//staging/greybus/fw-management.c: In function
> 'fw_mgmt_load_and_validate_operation':
> >> drivers//staging/greybus/fw-management.c:153:2: warning: 'strncpy'
> >> specified bound 10 equals destination size [-Wstringop-truncation]
> strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> ^~~~
>drivers//staging/greybus/fw-management.c: In function
> 'fw_mgmt_backend_fw_update_operation':
>drivers//staging/greybus/fw-management.c:304:2: warning: 'strncpy'
> specified bound 10 equals destination size [-Wstringop-truncation]
> strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> ^~~~
> --
>drivers/auxdisplay/panel.c: In function 'panel_bind_key':
> >> drivers/auxdisplay/panel.c:1509:2: warning: 'strncpy' specified bound 12
> >> equals destination size [-Wstringop-truncation]
> strncpy(key->u.kbd.press_str, press, sizeof(key->u.kbd.press_str));
> ^~
>drivers/auxdisplay/panel.c:1510:2: warning: 'strncpy' specified bound 12
> equals destination size [-Wstringop-truncation]
> strncpy(key->u.kbd.repeat_str, repeat, sizeof(key->u.kbd.repeat_str));
> ^
Nice! This patch actually caused bugs in other areas of the code to be
caught by the build system.
The patch is not wrong. The code that has these warnings are.
-- Steve
>
> vim +/strncpy +153 drivers//staging/greybus/fw-management.c
>
> 013e6653 Viresh Kumar 2016-05-14 138
> 013e6653 Viresh Kumar 2016-05-14 139 static int
> fw_mgmt_load_and_validate_operation(struct fw_mgmt *fw_mgmt,
> 013e6653 Viresh Kumar 2016-05-14 140
>u8 load_method, const char *tag)
> 013e6653 Viresh Kumar 2016-05-14 141 {
> 013e6653 Viresh Kumar 2016-05-14 142 struct
> gb_fw_mgmt_load_and_validate_fw_request request;
> 013e6653 Viresh Kumar 2016-05-14 143 int ret;
> 013e6653 Viresh Kumar 2016-05-14 144
> 013e6653 Viresh Kumar 2016-05-14 145 if (load_method !=
> GB_FW_LOAD_METHOD_UNIPRO &&
> 013e6653 Viresh Kumar 2016-05-14 146 load_method !=
> GB_FW_LOAD_METHOD_INTERNAL) {
> 013e6653 Viresh Kumar 2016-05-14 147 dev_err(fw_mgmt->parent,
> 013e6653 Viresh Kumar 2016-05-14 148 "invalid
> load-method (%d)\n", load_method);
> 013e6653 Viresh Kumar 2016-05-14 149 return -EINVAL;
> 013e6653 Viresh Kumar 2016-05-14 150 }
> 013e6653 Viresh Kumar 2016-05-14 151
> 013e6653 Viresh Kumar 2016-05-14 152 request.load_method =
> load_method;
> b2abeaa1 Viresh Kumar 2016-08-11 @153 strncpy(request.firmware_tag,
> tag, GB_FIRMWARE_TAG_MAX_SIZE);
> 013e6653 Viresh Kumar 2016-05-14 154
> 013e6653 Viresh Kumar 2016-05-14 155 /*
> 013e6653 Viresh Kumar 2016-05-14 156 * The firmware-tag should be
> NULL terminated, otherwise throw error and
> 013e6653 Viresh Kumar 2016-05-14 157 * fail.
> 013e6653 Viresh Kumar 2016-05-14 158 */
> b2abeaa1 Viresh Kumar 2016-08-11 159 if
> (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
> 013e6653 Viresh Kumar 2016-05-14 160
> dev_err(fw_mgmt->parent, "load-and-validate: firmware-tag is not NULL
> terminated\n");
> 013e6653 Viresh Kumar 2016-05-14 161 return -EINVAL;
> 013e6653 Viresh Kumar 2016-05-14 162 }
> 013e6653 Viresh Kumar 2016-05-14 163
> 013e6653 Viresh Kumar 2016-05-14 164 /* Allocate ids from 1 to 255
> (u8-max), 0 is an invalid id */
> 013e6653 Viresh Kumar 2016-05-14 165 ret =
> ida_simple_get(_mgmt->id_map, 1, 256, GFP_KERNEL);
> 013e6653 Viresh Kumar 2016-05-14 166 if (ret < 0) {
> 013e6653 Viresh Kumar 2016-05-14 167
> dev_err(fw_mgmt->parent, "failed to allocate request id (%d)\n",
> 013e6653 Viresh Kumar
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
On Wed, 6 Jun 2018 05:21:55 +0800
kbuild test robot wrote:
> Hi Changbin,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.17 next-20180605]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
> config: ia64-allmodconfig (attached as .config)
> compiler: ia64-linux-gcc (GCC) 8.1.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=ia64
>
> All warnings (new ones prefixed by >>):
>
>drivers//staging/greybus/fw-management.c: In function
> 'fw_mgmt_load_and_validate_operation':
> >> drivers//staging/greybus/fw-management.c:153:2: warning: 'strncpy'
> >> specified bound 10 equals destination size [-Wstringop-truncation]
> strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> ^~~~
>drivers//staging/greybus/fw-management.c: In function
> 'fw_mgmt_backend_fw_update_operation':
>drivers//staging/greybus/fw-management.c:304:2: warning: 'strncpy'
> specified bound 10 equals destination size [-Wstringop-truncation]
> strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> ^~~~
> --
>drivers/auxdisplay/panel.c: In function 'panel_bind_key':
> >> drivers/auxdisplay/panel.c:1509:2: warning: 'strncpy' specified bound 12
> >> equals destination size [-Wstringop-truncation]
> strncpy(key->u.kbd.press_str, press, sizeof(key->u.kbd.press_str));
> ^~
>drivers/auxdisplay/panel.c:1510:2: warning: 'strncpy' specified bound 12
> equals destination size [-Wstringop-truncation]
> strncpy(key->u.kbd.repeat_str, repeat, sizeof(key->u.kbd.repeat_str));
> ^
Nice! This patch actually caused bugs in other areas of the code to be
caught by the build system.
The patch is not wrong. The code that has these warnings are.
-- Steve
>
> vim +/strncpy +153 drivers//staging/greybus/fw-management.c
>
> 013e6653 Viresh Kumar 2016-05-14 138
> 013e6653 Viresh Kumar 2016-05-14 139 static int
> fw_mgmt_load_and_validate_operation(struct fw_mgmt *fw_mgmt,
> 013e6653 Viresh Kumar 2016-05-14 140
>u8 load_method, const char *tag)
> 013e6653 Viresh Kumar 2016-05-14 141 {
> 013e6653 Viresh Kumar 2016-05-14 142 struct
> gb_fw_mgmt_load_and_validate_fw_request request;
> 013e6653 Viresh Kumar 2016-05-14 143 int ret;
> 013e6653 Viresh Kumar 2016-05-14 144
> 013e6653 Viresh Kumar 2016-05-14 145 if (load_method !=
> GB_FW_LOAD_METHOD_UNIPRO &&
> 013e6653 Viresh Kumar 2016-05-14 146 load_method !=
> GB_FW_LOAD_METHOD_INTERNAL) {
> 013e6653 Viresh Kumar 2016-05-14 147 dev_err(fw_mgmt->parent,
> 013e6653 Viresh Kumar 2016-05-14 148 "invalid
> load-method (%d)\n", load_method);
> 013e6653 Viresh Kumar 2016-05-14 149 return -EINVAL;
> 013e6653 Viresh Kumar 2016-05-14 150 }
> 013e6653 Viresh Kumar 2016-05-14 151
> 013e6653 Viresh Kumar 2016-05-14 152 request.load_method =
> load_method;
> b2abeaa1 Viresh Kumar 2016-08-11 @153 strncpy(request.firmware_tag,
> tag, GB_FIRMWARE_TAG_MAX_SIZE);
> 013e6653 Viresh Kumar 2016-05-14 154
> 013e6653 Viresh Kumar 2016-05-14 155 /*
> 013e6653 Viresh Kumar 2016-05-14 156 * The firmware-tag should be
> NULL terminated, otherwise throw error and
> 013e6653 Viresh Kumar 2016-05-14 157 * fail.
> 013e6653 Viresh Kumar 2016-05-14 158 */
> b2abeaa1 Viresh Kumar 2016-08-11 159 if
> (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
> 013e6653 Viresh Kumar 2016-05-14 160
> dev_err(fw_mgmt->parent, "load-and-validate: firmware-tag is not NULL
> terminated\n");
> 013e6653 Viresh Kumar 2016-05-14 161 return -EINVAL;
> 013e6653 Viresh Kumar 2016-05-14 162 }
> 013e6653 Viresh Kumar 2016-05-14 163
> 013e6653 Viresh Kumar 2016-05-14 164 /* Allocate ids from 1 to 255
> (u8-max), 0 is an invalid id */
> 013e6653 Viresh Kumar 2016-05-14 165 ret =
> ida_simple_get(_mgmt->id_map, 1, 256, GFP_KERNEL);
> 013e6653 Viresh Kumar 2016-05-14 166 if (ret < 0) {
> 013e6653 Viresh Kumar 2016-05-14 167
> dev_err(fw_mgmt->parent, "failed to allocate request id (%d)\n",
> 013e6653 Viresh Kumar
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
Hi Changbin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.17 next-20180605] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415 config: sparc64-allyesconfig (attached as .config) compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=sparc64 All warnings (new ones prefixed by >>): >> WARNING: vmlinux.o(.text.unlikely+0x1fc): Section mismatch in reference from >> the function init_tick_ops() to the function .init.text:get_tick_patch() The function init_tick_ops() references the function __init get_tick_patch(). This is often because init_tick_ops lacks a __init annotation or the annotation of get_tick_patch is wrong. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
Hi Changbin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.17 next-20180605] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415 config: sparc64-allyesconfig (attached as .config) compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=sparc64 All warnings (new ones prefixed by >>): >> WARNING: vmlinux.o(.text.unlikely+0x1fc): Section mismatch in reference from >> the function init_tick_ops() to the function .init.text:get_tick_patch() The function init_tick_ops() references the function __init get_tick_patch(). This is often because init_tick_ops lacks a __init annotation or the annotation of get_tick_patch is wrong. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
Hi Changbin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17 next-20180605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
All warnings (new ones prefixed by >>):
drivers//staging/greybus/fw-management.c: In function
'fw_mgmt_load_and_validate_operation':
>> drivers//staging/greybus/fw-management.c:153:2: warning: 'strncpy' specified
>> bound 10 equals destination size [-Wstringop-truncation]
strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
^~~~
drivers//staging/greybus/fw-management.c: In function
'fw_mgmt_backend_fw_update_operation':
drivers//staging/greybus/fw-management.c:304:2: warning: 'strncpy' specified
bound 10 equals destination size [-Wstringop-truncation]
strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
^~~~
--
drivers/auxdisplay/panel.c: In function 'panel_bind_key':
>> drivers/auxdisplay/panel.c:1509:2: warning: 'strncpy' specified bound 12
>> equals destination size [-Wstringop-truncation]
strncpy(key->u.kbd.press_str, press, sizeof(key->u.kbd.press_str));
^~
drivers/auxdisplay/panel.c:1510:2: warning: 'strncpy' specified bound 12
equals destination size [-Wstringop-truncation]
strncpy(key->u.kbd.repeat_str, repeat, sizeof(key->u.kbd.repeat_str));
^
vim +/strncpy +153 drivers//staging/greybus/fw-management.c
013e6653 Viresh Kumar 2016-05-14 138
013e6653 Viresh Kumar 2016-05-14 139 static int
fw_mgmt_load_and_validate_operation(struct fw_mgmt *fw_mgmt,
013e6653 Viresh Kumar 2016-05-14 140
u8 load_method, const char *tag)
013e6653 Viresh Kumar 2016-05-14 141 {
013e6653 Viresh Kumar 2016-05-14 142 struct
gb_fw_mgmt_load_and_validate_fw_request request;
013e6653 Viresh Kumar 2016-05-14 143 int ret;
013e6653 Viresh Kumar 2016-05-14 144
013e6653 Viresh Kumar 2016-05-14 145 if (load_method !=
GB_FW_LOAD_METHOD_UNIPRO &&
013e6653 Viresh Kumar 2016-05-14 146 load_method !=
GB_FW_LOAD_METHOD_INTERNAL) {
013e6653 Viresh Kumar 2016-05-14 147 dev_err(fw_mgmt->parent,
013e6653 Viresh Kumar 2016-05-14 148 "invalid load-method
(%d)\n", load_method);
013e6653 Viresh Kumar 2016-05-14 149 return -EINVAL;
013e6653 Viresh Kumar 2016-05-14 150 }
013e6653 Viresh Kumar 2016-05-14 151
013e6653 Viresh Kumar 2016-05-14 152 request.load_method = load_method;
b2abeaa1 Viresh Kumar 2016-08-11 @153 strncpy(request.firmware_tag, tag,
GB_FIRMWARE_TAG_MAX_SIZE);
013e6653 Viresh Kumar 2016-05-14 154
013e6653 Viresh Kumar 2016-05-14 155 /*
013e6653 Viresh Kumar 2016-05-14 156* The firmware-tag should be NULL
terminated, otherwise throw error and
013e6653 Viresh Kumar 2016-05-14 157* fail.
013e6653 Viresh Kumar 2016-05-14 158*/
b2abeaa1 Viresh Kumar 2016-08-11 159 if
(request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
013e6653 Viresh Kumar 2016-05-14 160 dev_err(fw_mgmt->parent,
"load-and-validate: firmware-tag is not NULL terminated\n");
013e6653 Viresh Kumar 2016-05-14 161 return -EINVAL;
013e6653 Viresh Kumar 2016-05-14 162 }
013e6653 Viresh Kumar 2016-05-14 163
013e6653 Viresh Kumar 2016-05-14 164 /* Allocate ids from 1 to 255 (u8-max),
0 is an invalid id */
013e6653 Viresh Kumar 2016-05-14 165 ret = ida_simple_get(_mgmt->id_map,
1, 256, GFP_KERNEL);
013e6653 Viresh Kumar 2016-05-14 166 if (ret < 0) {
013e6653 Viresh Kumar 2016-05-14 167 dev_err(fw_mgmt->parent,
"failed to allocate request id (%d)\n",
013e6653 Viresh Kumar 2016-05-14 168 ret);
013e6653 Viresh Kumar 2016-05-14 169 return ret;
013e6653 Viresh Kumar 2016-05-14 170 }
013e6653 Viresh Kumar 2016-05-14 171
013e6653 Viresh Kumar 2016-05-14 172 fw_mgmt->intf_fw_request_id = ret;
04f0e6eb Viresh Kumar 2016-05-14 173 fw_mgmt->intf_fw_loaded = false;
013e6653 Viresh Kumar 2016-05-14 174 request.request_id = ret;
013e6653 Viresh Kumar 2016-05-14 175
013e6653 Viresh Kumar 2016-05-14 176 ret =
gb_operation_sync(fw_mgmt->connection,
013e6653 Viresh Kumar 2016-05-14 177
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
Hi Changbin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17 next-20180605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
All warnings (new ones prefixed by >>):
drivers//staging/greybus/fw-management.c: In function
'fw_mgmt_load_and_validate_operation':
>> drivers//staging/greybus/fw-management.c:153:2: warning: 'strncpy' specified
>> bound 10 equals destination size [-Wstringop-truncation]
strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
^~~~
drivers//staging/greybus/fw-management.c: In function
'fw_mgmt_backend_fw_update_operation':
drivers//staging/greybus/fw-management.c:304:2: warning: 'strncpy' specified
bound 10 equals destination size [-Wstringop-truncation]
strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
^~~~
--
drivers/auxdisplay/panel.c: In function 'panel_bind_key':
>> drivers/auxdisplay/panel.c:1509:2: warning: 'strncpy' specified bound 12
>> equals destination size [-Wstringop-truncation]
strncpy(key->u.kbd.press_str, press, sizeof(key->u.kbd.press_str));
^~
drivers/auxdisplay/panel.c:1510:2: warning: 'strncpy' specified bound 12
equals destination size [-Wstringop-truncation]
strncpy(key->u.kbd.repeat_str, repeat, sizeof(key->u.kbd.repeat_str));
^
vim +/strncpy +153 drivers//staging/greybus/fw-management.c
013e6653 Viresh Kumar 2016-05-14 138
013e6653 Viresh Kumar 2016-05-14 139 static int
fw_mgmt_load_and_validate_operation(struct fw_mgmt *fw_mgmt,
013e6653 Viresh Kumar 2016-05-14 140
u8 load_method, const char *tag)
013e6653 Viresh Kumar 2016-05-14 141 {
013e6653 Viresh Kumar 2016-05-14 142 struct
gb_fw_mgmt_load_and_validate_fw_request request;
013e6653 Viresh Kumar 2016-05-14 143 int ret;
013e6653 Viresh Kumar 2016-05-14 144
013e6653 Viresh Kumar 2016-05-14 145 if (load_method !=
GB_FW_LOAD_METHOD_UNIPRO &&
013e6653 Viresh Kumar 2016-05-14 146 load_method !=
GB_FW_LOAD_METHOD_INTERNAL) {
013e6653 Viresh Kumar 2016-05-14 147 dev_err(fw_mgmt->parent,
013e6653 Viresh Kumar 2016-05-14 148 "invalid load-method
(%d)\n", load_method);
013e6653 Viresh Kumar 2016-05-14 149 return -EINVAL;
013e6653 Viresh Kumar 2016-05-14 150 }
013e6653 Viresh Kumar 2016-05-14 151
013e6653 Viresh Kumar 2016-05-14 152 request.load_method = load_method;
b2abeaa1 Viresh Kumar 2016-08-11 @153 strncpy(request.firmware_tag, tag,
GB_FIRMWARE_TAG_MAX_SIZE);
013e6653 Viresh Kumar 2016-05-14 154
013e6653 Viresh Kumar 2016-05-14 155 /*
013e6653 Viresh Kumar 2016-05-14 156* The firmware-tag should be NULL
terminated, otherwise throw error and
013e6653 Viresh Kumar 2016-05-14 157* fail.
013e6653 Viresh Kumar 2016-05-14 158*/
b2abeaa1 Viresh Kumar 2016-08-11 159 if
(request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
013e6653 Viresh Kumar 2016-05-14 160 dev_err(fw_mgmt->parent,
"load-and-validate: firmware-tag is not NULL terminated\n");
013e6653 Viresh Kumar 2016-05-14 161 return -EINVAL;
013e6653 Viresh Kumar 2016-05-14 162 }
013e6653 Viresh Kumar 2016-05-14 163
013e6653 Viresh Kumar 2016-05-14 164 /* Allocate ids from 1 to 255 (u8-max),
0 is an invalid id */
013e6653 Viresh Kumar 2016-05-14 165 ret = ida_simple_get(_mgmt->id_map,
1, 256, GFP_KERNEL);
013e6653 Viresh Kumar 2016-05-14 166 if (ret < 0) {
013e6653 Viresh Kumar 2016-05-14 167 dev_err(fw_mgmt->parent,
"failed to allocate request id (%d)\n",
013e6653 Viresh Kumar 2016-05-14 168 ret);
013e6653 Viresh Kumar 2016-05-14 169 return ret;
013e6653 Viresh Kumar 2016-05-14 170 }
013e6653 Viresh Kumar 2016-05-14 171
013e6653 Viresh Kumar 2016-05-14 172 fw_mgmt->intf_fw_request_id = ret;
04f0e6eb Viresh Kumar 2016-05-14 173 fw_mgmt->intf_fw_loaded = false;
013e6653 Viresh Kumar 2016-05-14 174 request.request_id = ret;
013e6653 Viresh Kumar 2016-05-14 175
013e6653 Viresh Kumar 2016-05-14 176 ret =
gb_operation_sync(fw_mgmt->connection,
013e6653 Viresh Kumar 2016-05-14 177
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
Hi Changbin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180512-001150
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers//staging/comedi/drivers/pcl816.c: In function
'pcl816_ai_setup_chanlist':
>> drivers//staging/comedi/drivers/pcl816.c:171:2: warning: 'last_chan' may be
>> used uninitialized in this function [-Wmaybe-uninitialized]
pcl816_ai_set_chan_scan(dev, first_chan, last_chan);
^~~
--
drivers//staging/comedi/drivers/pcl818.c: In function
'pcl818_ai_setup_chanlist':
>> drivers//staging/comedi/drivers/pcl818.c:366:2: warning: 'last_chan' may be
>> used uninitialized in this function [-Wmaybe-uninitialized]
pcl818_ai_set_chan_scan(dev, first_chan, last_chan);
^~~
--
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_mac_init_rd':
>> drivers/net/wireless/ath/ath10k/mac.c:8172:39: warning: 'rd' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
ar->ath_common.regulatory.current_rd = rd;
~^~~~
--
drivers/dma/stm32-mdma.c: In function 'stm32_mdma_setup_xfer':
>> drivers/dma/stm32-mdma.c:767:6: warning: 'ccr' may be used uninitialized in
>> this function [-Wmaybe-uninitialized]
ccr &= ~STM32_MDMA_CCR_IRQ_MASK;
^~
--
drivers/gpio/gpio-aspeed.c: In function 'enable_debounce':
>> drivers/gpio/gpio-aspeed.c:708:6: warning: 'requested_cycles' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
if (requested_cycles == cycles)
^
--
drivers/mmc/host/sdhci-pci-core.c: In function 'intel_dsm_init.isra.3':
>> drivers/mmc/host/sdhci-pci-core.c:527:37: warning: 'val' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
intel_host->d3_retune = err ? true : !!val;
~~~^~~
vim +/last_chan +171 drivers//staging/comedi/drivers/pcl816.c
19720c07 H Hartley Sweeten 2014-03-04 151
19720c07 H Hartley Sweeten 2014-03-04 152 static void
pcl816_ai_setup_chanlist(struct comedi_device *dev,
19720c07 H Hartley Sweeten 2014-03-04 153
unsigned int *chanlist,
19720c07 H Hartley Sweeten 2014-03-04 154
unsigned int seglen)
19720c07 H Hartley Sweeten 2014-03-04 155 {
19720c07 H Hartley Sweeten 2014-03-04 156 unsigned int first_chan =
CR_CHAN(chanlist[0]);
19720c07 H Hartley Sweeten 2014-03-04 157 unsigned int last_chan;
19720c07 H Hartley Sweeten 2014-03-04 158 unsigned int range;
19720c07 H Hartley Sweeten 2014-03-04 159 unsigned int i;
19720c07 H Hartley Sweeten 2014-03-04 160
19720c07 H Hartley Sweeten 2014-03-04 161 /* store range list to card */
19720c07 H Hartley Sweeten 2014-03-04 162 for (i = 0; i < seglen; i++) {
19720c07 H Hartley Sweeten 2014-03-04 163 last_chan =
CR_CHAN(chanlist[i]);
19720c07 H Hartley Sweeten 2014-03-04 164 range =
CR_RANGE(chanlist[i]);
19720c07 H Hartley Sweeten 2014-03-04 165
19720c07 H Hartley Sweeten 2014-03-04 166
pcl816_ai_set_chan_range(dev, last_chan, range);
19720c07 H Hartley Sweeten 2014-03-04 167 }
19720c07 H Hartley Sweeten 2014-03-04 168
19720c07 H Hartley Sweeten 2014-03-04 169 udelay(1);
19720c07 H Hartley Sweeten 2014-03-04 170
19720c07 H Hartley Sweeten 2014-03-04 @171 pcl816_ai_set_chan_scan(dev,
first_chan, last_chan);
19720c07 H Hartley Sweeten 2014-03-04 172 }
19720c07 H Hartley Sweeten 2014-03-04 173
:: The code at line 171 was first introduced by commit
:: 19720c07f1f82c21311f3f7ac3e9b993598d6b70 staging: comedi: pcl816:
cleanup setup_channel_list()
:: TO: H Hartley Sweeten
:: CC: Greg Kroah-Hartman
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
Hi Changbin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180512-001150
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers//staging/comedi/drivers/pcl816.c: In function
'pcl816_ai_setup_chanlist':
>> drivers//staging/comedi/drivers/pcl816.c:171:2: warning: 'last_chan' may be
>> used uninitialized in this function [-Wmaybe-uninitialized]
pcl816_ai_set_chan_scan(dev, first_chan, last_chan);
^~~
--
drivers//staging/comedi/drivers/pcl818.c: In function
'pcl818_ai_setup_chanlist':
>> drivers//staging/comedi/drivers/pcl818.c:366:2: warning: 'last_chan' may be
>> used uninitialized in this function [-Wmaybe-uninitialized]
pcl818_ai_set_chan_scan(dev, first_chan, last_chan);
^~~
--
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_mac_init_rd':
>> drivers/net/wireless/ath/ath10k/mac.c:8172:39: warning: 'rd' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
ar->ath_common.regulatory.current_rd = rd;
~^~~~
--
drivers/dma/stm32-mdma.c: In function 'stm32_mdma_setup_xfer':
>> drivers/dma/stm32-mdma.c:767:6: warning: 'ccr' may be used uninitialized in
>> this function [-Wmaybe-uninitialized]
ccr &= ~STM32_MDMA_CCR_IRQ_MASK;
^~
--
drivers/gpio/gpio-aspeed.c: In function 'enable_debounce':
>> drivers/gpio/gpio-aspeed.c:708:6: warning: 'requested_cycles' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
if (requested_cycles == cycles)
^
--
drivers/mmc/host/sdhci-pci-core.c: In function 'intel_dsm_init.isra.3':
>> drivers/mmc/host/sdhci-pci-core.c:527:37: warning: 'val' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
intel_host->d3_retune = err ? true : !!val;
~~~^~~
vim +/last_chan +171 drivers//staging/comedi/drivers/pcl816.c
19720c07 H Hartley Sweeten 2014-03-04 151
19720c07 H Hartley Sweeten 2014-03-04 152 static void
pcl816_ai_setup_chanlist(struct comedi_device *dev,
19720c07 H Hartley Sweeten 2014-03-04 153
unsigned int *chanlist,
19720c07 H Hartley Sweeten 2014-03-04 154
unsigned int seglen)
19720c07 H Hartley Sweeten 2014-03-04 155 {
19720c07 H Hartley Sweeten 2014-03-04 156 unsigned int first_chan =
CR_CHAN(chanlist[0]);
19720c07 H Hartley Sweeten 2014-03-04 157 unsigned int last_chan;
19720c07 H Hartley Sweeten 2014-03-04 158 unsigned int range;
19720c07 H Hartley Sweeten 2014-03-04 159 unsigned int i;
19720c07 H Hartley Sweeten 2014-03-04 160
19720c07 H Hartley Sweeten 2014-03-04 161 /* store range list to card */
19720c07 H Hartley Sweeten 2014-03-04 162 for (i = 0; i < seglen; i++) {
19720c07 H Hartley Sweeten 2014-03-04 163 last_chan =
CR_CHAN(chanlist[i]);
19720c07 H Hartley Sweeten 2014-03-04 164 range =
CR_RANGE(chanlist[i]);
19720c07 H Hartley Sweeten 2014-03-04 165
19720c07 H Hartley Sweeten 2014-03-04 166
pcl816_ai_set_chan_range(dev, last_chan, range);
19720c07 H Hartley Sweeten 2014-03-04 167 }
19720c07 H Hartley Sweeten 2014-03-04 168
19720c07 H Hartley Sweeten 2014-03-04 169 udelay(1);
19720c07 H Hartley Sweeten 2014-03-04 170
19720c07 H Hartley Sweeten 2014-03-04 @171 pcl816_ai_set_chan_scan(dev,
first_chan, last_chan);
19720c07 H Hartley Sweeten 2014-03-04 172 }
19720c07 H Hartley Sweeten 2014-03-04 173
:: The code at line 171 was first introduced by commit
:: 19720c07f1f82c21311f3f7ac3e9b993598d6b70 staging: comedi: pcl816:
cleanup setup_channel_list()
:: TO: H Hartley Sweeten
:: CC: Greg Kroah-Hartman
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
Hi Changbin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180512-001150
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/video/fbdev/i740fb.c: In function 'i740_calc_fifo.isra.0':
>> drivers/video/fbdev/i740fb.c:331:9: warning: 'wm' may be used uninitialized
>> in this function [-Wmaybe-uninitialized]
return wm;
^~
--
drivers/pci/host/pci-xgene.c: In function 'xgene_pcie_setup_ib_reg':
>> drivers/pci/host/pci-xgene.c:532:2: warning: 'pim_reg' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
xgene_pcie_setup_pims(port, pim_reg, pci_addr, ~(size - 1));
^~~
vim +/wm +331 drivers/video/fbdev/i740fb.c
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 207
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 208 static u32
i740_calc_fifo(struct i740fb_par *par, u32 freq, int bpp)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 209 {
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 210 /*
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 211 * Would like
to calculate these values automatically, but a generic
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 212 * algorithm
does not seem possible. Note: These FIFO water mark
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 213 * values were
tested on several cards and seem to eliminate the
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 214 * all of the
snow and vertical banding, but fine adjustments will
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 215 * probably be
required for other cards.
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 216 */
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 217
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 218 u32 wm;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 219
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 220 switch (bpp) {
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 221 case 8:
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 222 if
(freq > 200)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 223
wm = 0x1812;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 224 else if
(freq > 175)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 225
wm = 0x1611;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 226 else if
(freq > 135)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 227
wm = 0x120E;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 228 else
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 229
wm = 0x100D;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 230 break;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 231 case 15:
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 232 case 16:
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 233 if
(par->has_sgram) {
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 234
if (freq > 140)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 235
wm = 0x2C1D;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 236
else if (freq > 120)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 237
wm = 0x2C18;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 238
else if (freq > 100)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 239
wm = 0x2416;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 240
else if (freq > 90)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 241
wm = 0x1812;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 242
else if (freq > 50)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 243
Re: [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
Hi Changbin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180512-001150
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/video/fbdev/i740fb.c: In function 'i740_calc_fifo.isra.0':
>> drivers/video/fbdev/i740fb.c:331:9: warning: 'wm' may be used uninitialized
>> in this function [-Wmaybe-uninitialized]
return wm;
^~
--
drivers/pci/host/pci-xgene.c: In function 'xgene_pcie_setup_ib_reg':
>> drivers/pci/host/pci-xgene.c:532:2: warning: 'pim_reg' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
xgene_pcie_setup_pims(port, pim_reg, pci_addr, ~(size - 1));
^~~
vim +/wm +331 drivers/video/fbdev/i740fb.c
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 207
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 208 static u32
i740_calc_fifo(struct i740fb_par *par, u32 freq, int bpp)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 209 {
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 210 /*
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 211 * Would like
to calculate these values automatically, but a generic
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 212 * algorithm
does not seem possible. Note: These FIFO water mark
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 213 * values were
tested on several cards and seem to eliminate the
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 214 * all of the
snow and vertical banding, but fine adjustments will
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 215 * probably be
required for other cards.
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 216 */
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 217
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 218 u32 wm;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 219
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 220 switch (bpp) {
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 221 case 8:
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 222 if
(freq > 200)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 223
wm = 0x1812;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 224 else if
(freq > 175)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 225
wm = 0x1611;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 226 else if
(freq > 135)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 227
wm = 0x120E;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 228 else
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 229
wm = 0x100D;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 230 break;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 231 case 15:
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 232 case 16:
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 233 if
(par->has_sgram) {
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 234
if (freq > 140)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 235
wm = 0x2C1D;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 236
else if (freq > 120)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 237
wm = 0x2C18;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 238
else if (freq > 100)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 239
wm = 0x2416;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 240
else if (freq > 90)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 241
wm = 0x1812;
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 242
else if (freq > 50)
5350c65f drivers/video/i740fb.c Ondrej Zary 2012-02-10 243
