Hi Matias,

On Wed, May 29, 2019 at 10:08 AM Matias Bjørling mb@lightnvm.io wrote:

On 5/28/19 4:24 PM, Geert Uytterhoeven wrote:

...

With gcc 4.1:

 drivers/lightnvm/core.c: In function ‘nvm_remove_tgt’:
 drivers/lightnvm/core.c:510: warning: ‘t’ is used uninitialized in this function

Indeed, if no NVM devices have been registered, t will be an uninitialized pointer, and may be dereferenced later. A call to nvm_remove_tgt() can be triggered from userspace by issuing the NVM_DEV_REMOVE ioctl on the lightnvm control device.

Fix this by preinitializing t to NULL.

Fixes: 843f2edbdde085b4 ("lightnvm: do not remove instance under global lock") Signed-off-by: Geert Uytterhoeven geert@linux-m68k.org

---

drivers/lightnvm/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c index 0df7454832efe082..aa017f48eb8c588c 100644 --- a/drivers/lightnvm/core.c +++ b/drivers/lightnvm/core.c @@ -492,7 +492,7 @@ static void __nvm_remove_target(struct nvm_target *t, bool graceful) */ static int nvm_remove_tgt(struct nvm_ioctl_remove *remove) {

• struct nvm_target *t;
  

• struct nvm_target *t = NULL;
  struct nvm_dev *dev;
  
  down_read(&nvm_lock);
  
  

Thanks Geert. Would you like me to carry the patch?

Yes please. Thanks!

Gr{oetje,eeting}s,

Geert

Geert Uytterhoeven geert@linux-m68k.org wrote:

While this is not a real false-positive, I believe it cannot cause harm in practice, as AF_RXRPC cannot be used with other transport families than IPv4 and IPv6.

Agreed.

---

net/rxrpc/output.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/rxrpc/output.c b/net/rxrpc/output.c index 004c762c2e8d063c..1473d774d67100c5 100644 --- a/net/rxrpc/output.c +++ b/net/rxrpc/output.c @@ -403,8 +403,10 @@ int rxrpc_send_data_packet(struct rxrpc_call *call, struct sk_buff *skb,

/* send the packet with the don't fragment bit set if we currently * think it's small enough */

• if (iov[1].iov_len >= call->peer->maxdata)

• if (iov[1].iov_len >= call->peer->maxdata) {

• ret = 0;
  

  goto send_fragmentable;

• }

  down_read(&conn->params.local->defrag_sem);

Simply setting 0 is wrong. That would give the impression that the thing worked if support for a new transport address family was added and came through this function without full modification (say AF_INET7 becomes a thing).

A better way to do things would be to add a default case into the send_fragmentable switch statement that either BUG's or sets -EAFNOSUPPORT.

David

Hi Geert,

Here's my take on the patch.

David --- rxrpc: Fix uninitialized error code in rxrpc_send_data_packet()

With gcc 4.1:

net/rxrpc/output.c: In function ‘rxrpc_send_data_packet’: net/rxrpc/output.c:338: warning: ‘ret’ may be used uninitialized in this function

Indeed, if the first jump to the send_fragmentable label is made, and the address family is not handled in the switch() statement, ret will be used uninitialized.

Fix this by BUG()'ing as is done in other places in rxrpc where internal support for future address families will need adding. It should not be possible to reach this normally as the address families are checked up-front.

Fixes: 5a924b8951f835b5 ("rxrpc: Don't store the rxrpc header in the Tx queue sk_buffs") Reported-by: Geert Uytterhoeven geert@linux-m68k.org Signed-off-by: David Howells dhowells@redhat.com --- diff --git a/net/rxrpc/output.c b/net/rxrpc/output.c index 004c762c2e8d..6f2b4fb4b0aa 100644 --- a/net/rxrpc/output.c +++ b/net/rxrpc/output.c @@ -523,6 +523,9 @@ int rxrpc_send_data_packet(struct rxrpc_call *call, struct sk_buff *skb, } break; #endif + + default: + BUG(); }

if (ret < 0)

Hi David,

On Fri, May 31, 2019 at 12:35 PM David Howells dhowells@redhat.com wrote:

Here's my take on the patch.

David

rxrpc: Fix uninitialized error code in rxrpc_send_data_packet()

With gcc 4.1:

net/rxrpc/output.c: In function ‘rxrpc_send_data_packet’:
net/rxrpc/output.c:338: warning: ‘ret’ may be used uninitialized in this function

Indeed, if the first jump to the send_fragmentable label is made, and the address family is not handled in the switch() statement, ret will be used uninitialized.

Fix this by BUG()'ing as is done in other places in rxrpc where internal support for future address families will need adding. It should not be possible to reach this normally as the address families are checked up-front.

Fixes: 5a924b8951f835b5 ("rxrpc: Don't store the rxrpc header in the Tx queue sk_buffs") Reported-by: Geert Uytterhoeven geert@linux-m68k.org Signed-off-by: David Howells dhowells@redhat.com

I'm not such a big fan of BUG(), so I'd go for ret = -EAFNOSUPPORT, but given rxrpc is already full of BUG() calls, I guess it is an acceptable solution.

---

diff --git a/net/rxrpc/output.c b/net/rxrpc/output.c index 004c762c2e8d..6f2b4fb4b0aa 100644 --- a/net/rxrpc/output.c +++ b/net/rxrpc/output.c @@ -523,6 +523,9 @@ int rxrpc_send_data_packet(struct rxrpc_call *call, struct sk_buff *skb, } break; #endif

•   default:
  

•           BUG();
    }
  
    if (ret < 0)
  

Gr{oetje,eeting}s,

Geert

Hi,

On Tue, May 28, 2019 at 04:24:23PM +0200, Geert Uytterhoeven wrote:

With gcc 4.1:

sound/firewire/fireface/ff-protocol-latter.c: In function ‘latter_switch_fetching_mode’:
sound/firewire/fireface/ff-protocol-latter.c:97: warning: integer constant is too large for ‘long’ type
sound/firewire/fireface/ff-protocol-latter.c: In function ‘latter_begin_session’:
sound/firewire/fireface/ff-protocol-latter.c:170: warning: integer constant is too large for ‘long’ type
sound/firewire/fireface/ff-protocol-latter.c:197: warning: integer constant is too large for ‘long’ type
sound/firewire/fireface/ff-protocol-latter.c:205: warning: integer constant is too large for ‘long’ type
sound/firewire/fireface/ff-protocol-latter.c: In function ‘latter_finish_session’:
sound/firewire/fireface/ff-protocol-latter.c:214: warning: integer constant is too large for ‘long’ type

Fix this by adding the missing "ULL" suffixes. Add the same suffix to the last constant, to maintain consistency.

Fixes: fd1cc9de64c2ca6c ("ALSA: fireface: add support for Fireface UCX") Signed-off-by: Geert Uytterhoeven geert@linux-m68k.org

---

sound/firewire/fireface/ff-protocol-latter.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)

Thanks for your care.

Reviewed-by: Takashi Sakamoto o-takashi@sakamocchi.jp

diff --git a/sound/firewire/fireface/ff-protocol-latter.c b/sound/firewire/fireface/ff-protocol-latter.c index c8236ff89b7fb9de..b30d02d359b1d21b 100644 --- a/sound/firewire/fireface/ff-protocol-latter.c +++ b/sound/firewire/fireface/ff-protocol-latter.c @@ -9,11 +9,11 @@

#include "ff.h"

-#define LATTER_STF 0xffff00000004 -#define LATTER_ISOC_CHANNELS 0xffff00000008 -#define LATTER_ISOC_START 0xffff0000000c -#define LATTER_FETCH_MODE 0xffff00000010 -#define LATTER_SYNC_STATUS 0x0000801c0000 +#define LATTER_STF 0xffff00000004ULL +#define LATTER_ISOC_CHANNELS 0xffff00000008ULL +#define LATTER_ISOC_START 0xffff0000000cULL +#define LATTER_FETCH_MODE 0xffff00000010ULL +#define LATTER_SYNC_STATUS 0x0000801c0000ULL

static int parse_clock_bits(u32 data, unsigned int *rate, enum snd_ff_clock_src *src) -- 2.17.1

Regards

Takashi Sakamoto

Tue, May 28, 2019 at 04:24:24PM CEST, geert@linux-m68k.org wrote:

With gcc 4.1:

net/core/devlink.c: In function ‘devlink_fmsg_prepare_skb’: net/core/devlink.c:4325: warning: ‘err’ may be used uninitialized in this function

Indeed, if the list has less than *start entries, an uninitialized error code will be returned.

Fix this by preinitializing err to zero.

Fixes: 1db64e8733f65381 ("devlink: Add devlink formatted message (fmsg) API") Signed-off-by: Geert Uytterhoeven geert@linux-m68k.org

---

I don't know if this can really happen, and if this is the right fix. Perhaps err should be initialized to some valid error code instead?

0 is correct here. Acked-by: Jiri Pirko jiri@mellanox.com

Thanks!

---

net/core/devlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/devlink.c b/net/core/devlink.c index d43bc52b8840d76b..91377e4eae9a43c1 100644 --- a/net/core/devlink.c +++ b/net/core/devlink.c @@ -4321,8 +4321,8 @@ devlink_fmsg_prepare_skb(struct devlink_fmsg *fmsg, struct sk_buff *skb, { struct devlink_fmsg_item *item; struct nlattr *fmsg_nlattr;

• int err = 0; int i = 0;

• int err;

  fmsg_nlattr = nla_nest_start_noflag(skb, DEVLINK_ATTR_FMSG); if (!fmsg_nlattr)

-- 2.17.1