* Re: [PATCH net-next 2/4] devlink: don't allocate attrs on the stack
From: Jiri Pirko @ 2019-02-09 8:35 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, oss-drivers
In-Reply-To: <20190209031611.1102-3-jakub.kicinski@netronome.com>
Sat, Feb 09, 2019 at 04:16:09AM CET, jakub.kicinski@netronome.com wrote:
>Number of devlink attributes has grown over 128, causing the
>following warning:
>
>../net/core/devlink.c: In function ‘devlink_nl_cmd_region_read_dumpit’:
>../net/core/devlink.c:3740:1: warning: the frame size of 1064 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> }
> ^
>
>Since the number of attributes is only going to grow allocate
>the array dynamically.
>
>Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 1/4] devlink: fix condition for compat device info
From: Jiri Pirko @ 2019-02-09 8:33 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, oss-drivers
In-Reply-To: <20190209031611.1102-2-jakub.kicinski@netronome.com>
Sat, Feb 09, 2019 at 04:16:08AM CET, jakub.kicinski@netronome.com wrote:
>We need the port to be both ethernet and have the rigth netdev,
>not one or the other.
>
>Fixes: ddb6e99e2db1 ("ethtool: add compat for devlink info")
>Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH v2 net-next] net: phy: disregard "Clause 22 registers present" bit in get_phy_c45_devs_in_pkg
From: Heiner Kallweit @ 2019-02-09 8:40 UTC (permalink / raw)
To: David Miller; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <20190208.231100.2168035998559471182.davem@davemloft.net>
On 09.02.2019 08:11, David Miller wrote:
> From: Heiner Kallweit <hkallweit1@gmail.com>
> Date: Fri, 8 Feb 2019 19:25:22 +0100
>
>> Bit 0 in register 1.5 doesn't represent a device but is a flag that
>> Clause 22 registers are present. Therefore disregard this bit when
>> populating the device list. If code needs this information it
>> should read register 1.5 directly instead of accessing the device
>> list.
>> Because this bit doesn't represent a device don't define a
>> MDIO_MMD_XYZ constant, just define a MDIO_DEVS_XYZ constant for
>> the flag in the device list bitmap.
>>
>> v2:
>> - make masking of bit 0 more explicit
>> - improve commit message
>>
Andrew had few further review comments and based on that I prepared a v3,
this time as series of three patches. What you just applied was splitted
to two patches and patch 1 is new. But this shouldn't be a big deal.
We can keep what was applied and I will rebase patch 1 and resubmit it.
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>
> Applied, thanks Heiner.
>
Heiner
^ permalink raw reply
* Re: Possible bug into DSA2 code.
From: Rodolfo Giometti @ 2019-02-09 8:24 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn, Vivien Didelot; +Cc: David S. Miller, netdev
In-Reply-To: <a121e6b5-03cd-da9e-42e8-41c68e12babe@enneenne.com>
Hello,
I'm working with EPRESSObin and DSA2 where I added the ability to dynamically
load and unload switch configurations by using DT-overlay (a patchwork from here
https://lore.kernel.org/patchwork/patch/468129/). During my tests I notice that
when I remove the overlay in order to disable the switch I got the following BUG
message:
[ 24.862079] ------------[ cut here ]------------
[ 24.866767] kernel BUG at drivers/net/phy/mdio_bus.c:448!
[ 24.872328] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 24.877967] Modules linked in:
[ 24.881109] CPU: 0 PID: 2189 Comm: rmdir Not tainted 4.19.0-sw3720tsn1-038561
[ 24.890509] Hardware name: Kbact sw3720tsn1 smart switch (DT)
[ 24.896426] pstate: 20000005 (nzCv daif -PAN -UAO)
[ 24.901365] pc : mdiobus_unregister+0x90/0x98
[ 24.905838] lr : mv88e6xxx_mdios_unregister+0x64/0x88
[ 24.911028] sp : ffff80006aea7730
[ 24.914434] x29: ffff80006aea7730 x28: ffff80006adc27c0
[ 24.919898] x27: ffff0000091e3000 x26: ffff0000090d9000
[ 24.925365] x25: ffff80006c9420a0 x24: ffff80006c3e1c10
[ 24.930828] x23: 0000000000000060 x22: ffff80006c9e6018
[ 24.936294] x21: ffff80006c9e6110 x20: ffff80006c942800
[ 24.941758] x19: ffff80006c942d40 x18: ffffffffffffffff
[ 24.947225] x17: 0000000000000000 x16: ffff80006adc27c0
[ 24.952690] x15: ffff0000090d96c8 x14: ffff000089198737
[ 24.958156] x13: ffff000009198745 x12: ffff0000090d9940
[ 24.963621] x11: ffff0000086be4b0 x10: 0000000000000040
[ 24.969087] x9 : ffff0000090f4710 x8 : 0000000040000000
[ 24.974553] x7 : ffff0000090d96c8 x6 : ffff80006a97a921
[ 24.980018] x5 : ffff80006a97a920 x4 : 0000000000000fff
[ 24.985483] x3 : 0000000000000000 x2 : 0000000000000000
[ 24.990948] x1 : 0000000000000003 x0 : ffff80006c942800
[ 24.996416] Process rmdir (pid: 2189, stack limit = 0x(____ptrval____))
[ 25.003225] Call trace:
[ 25.005737] mdiobus_unregister+0x90/0x98
[ 25.009858] mv88e6xxx_mdios_unregister+0x64/0x88
[ 25.014696] mv88e6xxx_remove+0x2c/0x88
[ 25.018637] mdio_remove+0x20/0x48
[ 25.022135] device_release_driver_internal+0x1a8/0x240
[ 25.027509] device_release_driver+0x14/0x20
[ 25.031899] bus_remove_device+0x110/0x128
[ 25.036109] device_del+0x124/0x340
[ 25.039693] mdio_device_remove+0x14/0x28
[ 25.043815] mdiobus_unregister+0x50/0x98
[ 25.047940] orion_mdio_remove+0x34/0xb0
[ 25.051970] platform_drv_remove+0x24/0x50
[ 25.056181] device_release_driver_internal+0x1a8/0x240
[ 25.061557] device_release_driver+0x14/0x20
[ 25.065947] bus_remove_device+0x110/0x128
[ 25.070158] device_del+0x124/0x340
[ 25.073742] platform_device_del.part.3+0x24/0x90
[ 25.078580] platform_device_unregister+0x18/0x30
[ 25.083422] of_platform_device_destroy+0xb4/0xb8
[ 25.088257] of_platform_notify+0xa8/0x170
[ 25.092471] notifier_call_chain+0x54/0x98
[ 25.096679] blocking_notifier_call_chain+0x48/0x70
[ 25.101697] of_property_notify+0x60/0xa0
[ 25.105819] __of_changeset_entry_notify+0x54/0x100
[ 25.110836] __of_changeset_revert_notify+0x3c/0x70
[ 25.115857] of_overlay_remove+0x2ac/0x378
[ 25.120066] cfs_overlay_release+0x28/0x50
[ 25.124278] config_item_put.part.0+0x70/0xb0
[ 25.128757] config_item_put+0x10/0x20
[ 25.132609] configfs_rmdir+0x1ec/0x2e0
[ 25.136554] vfs_rmdir+0x7c/0x170
[ 25.139956] do_rmdir+0x17c/0x1d0
[ 25.143361] __arm64_sys_unlinkat+0x4c/0x60
[ 25.147664] el0_svc_common+0x60/0xe8
[ 25.151426] el0_svc_handler+0x2c/0x80
[ 25.155279] el0_svc+0x8/0xc
[ 25.158236] Code: a94153f3 a9425bf5 a8c37bfd d65f03c0 (d4210000)
[ 25.164509] ---[ end trace 5138591d8b9c9222 ]---
After looking into the kernel code I discovered that this depends to the commit
1eb59443e72c69edbb836626f9f7f7e82427eeac which modifications I report below:
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 921a36fd139d..4e0f3c268103 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -312,6 +312,18 @@ static int dsa_ds_apply(struct dsa_switch_tree *dst, struct
dsa_switch *ds)
if (err < 0)
return err;
+ if (!ds->slave_mii_bus && ds->drv->phy_read) {
+ ds->slave_mii_bus = devm_mdiobus_alloc(ds->dev);
+ if (!ds->slave_mii_bus)
+ return -ENOMEM;
+
+ dsa_slave_mii_bus_init(ds);
+
+ err = mdiobus_register(ds->slave_mii_bus);
+ if (err < 0)
+ return err;
+ }
+
for (index = 0; index < DSA_MAX_PORTS; index++) {
port = ds->ports[index].dn;
if (!port)
@@ -361,6 +373,9 @@ static void dsa_ds_unapply(struct dsa_switch_tree *dst,
struct dsa_switch *ds)
dsa_user_port_unapply(port, index, ds);
}
+
+ if (ds->slave_mii_bus && ds->drv->phy_read)
+ mdiobus_unregister(ds->slave_mii_bus);
}
static int dsa_dst_apply(struct dsa_switch_tree *dst)
This patch looks buggy to me because if this patch has the target to catch
drivers that call dsa_ds_apply() having ds->slave_mii_bus set to NULL with a
defined ds->ops->phy_read, then it should take into account also those drivers
that have both ds->slave_mii_bus and ds->ops->phy_read already defined and then
DO NOT call mdiobus_unregister() during dsa_ds_unapply()! This because DSA
should NOT undo an operation it never did.
So we I see two possible solutions:
1) having both ds->slave_mii_bus and ds->ops->phy_read already defined is an
error, then it must be signaled to the calling code, or
2) we have to use a flag to signal dsa_ds_unapply() what to do.
I don't know DSA too much to provide the rigth-thing(TM) so I'm waiting for a
reply before proposing a patch. :-)
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@linux.it
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
^ permalink raw reply related
* [PATCH net-next] net/tls: Disable async decrytion for tls1.3
From: Vakul Garg @ 2019-02-09 7:53 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: borisp@mellanox.com, aviadye@mellanox.com, davejwatson@fb.com,
davem@davemloft.net, doronrk@fb.com, Vakul Garg
Function tls_sw_recvmsg() dequeues multiple records from stream parser
and decrypts them. In case the decryption is done by async accelerator,
the records may get submitted for decryption while the previous ones may
not have been decryted yet. For tls1.3, the record type is known only
after decryption. Therefore, for tls1.3, tls_sw_recvmsg() may submit
records for decryption even if it gets 'handshake' records after 'data'
records. These intermediate 'handshake' records may do a key updation.
By the time new keys are given to ktls by userspace, it is possible that
ktls has already submitted some records i(which are encrypted with new
keys) for decryption using old keys. This would lead to decrypt failure.
Therefore, async decryption of records should be disabled for tls1.3.
Fixes: 130b392c6cd6b ("net: tls: Add tls 1.3 support")
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
net/tls/tls_sw.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 8051a9164139..fe8c287cbaa1 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -2215,8 +2215,12 @@ int tls_set_sw_offload(struct sock *sk, struct tls_context *ctx, int tx)
if (sw_ctx_rx) {
tfm = crypto_aead_tfm(sw_ctx_rx->aead_recv);
- sw_ctx_rx->async_capable =
- tfm->__crt_alg->cra_flags & CRYPTO_ALG_ASYNC;
+
+ if (crypto_info->version == TLS_1_3_VERSION)
+ sw_ctx_rx->async_capable = false;
+ else
+ sw_ctx_rx->async_capable =
+ tfm->__crt_alg->cra_flags & CRYPTO_ALG_ASYNC;
/* Set up strparser */
memset(&cb, 0, sizeof(cb));
--
2.13.6
^ permalink raw reply related
* Re: [PATCH v2 net-next] net: phy: disregard "Clause 22 registers present" bit in get_phy_c45_devs_in_pkg
From: David Miller @ 2019-02-09 7:11 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <de542d98-a5c4-3dea-18de-a630f11a945c@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Fri, 8 Feb 2019 19:25:22 +0100
> Bit 0 in register 1.5 doesn't represent a device but is a flag that
> Clause 22 registers are present. Therefore disregard this bit when
> populating the device list. If code needs this information it
> should read register 1.5 directly instead of accessing the device
> list.
> Because this bit doesn't represent a device don't define a
> MDIO_MMD_XYZ constant, just define a MDIO_DEVS_XYZ constant for
> the flag in the device list bitmap.
>
> v2:
> - make masking of bit 0 more explicit
> - improve commit message
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied, thanks Heiner.
^ permalink raw reply
* Re: [PATCH net-next 0/5] mvpp2 phylink fixes
From: David Miller @ 2019-02-09 7:09 UTC (permalink / raw)
To: linux; +Cc: antoine.tenart, maxime.chevallier, baruch, netdev, sven.auhagen
In-Reply-To: <20190208153432.igh26ubphiljsswa@shell.armlinux.org.uk>
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Date: Fri, 8 Feb 2019 15:34:32 +0000
> Having spent a while debugging issues with Sven Auhagen, it appears
> that the mvpp2 network driver's phylink support isn't quite correct.
>
> This series fixes that up, but, despite being tested locally, by
> Sven, and by Antoine, I would prefer it to be applied to net-next
> so that there is time for more people to test before it hits -rc or
> stable backports.
...
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] Revert wake_on_lan devlink parameter
From: David Miller @ 2019-02-09 7:07 UTC (permalink / raw)
To: vasundhara-v.volam; +Cc: michael.chan, jiri, netdev
In-Reply-To: <1549617190-387130-1-git-send-email-vasundhara-v.volam@broadcom.com>
From: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Date: Fri, 8 Feb 2019 14:43:08 +0530
> As per discussion with Jakub Kicinski and Michal Kubecek,
> this will be better addressed by soon-too-come ethtool netlink
> API with additional indication that given WoL configuration request
> is supposed to be persisted.
>
> Retain bnxt_en code for devlink port param table registration.
> There will be follow up patches to add some devlink port params
> for bnxt_en driver.
Please fix the kbuild robot reported build failure and repost.
^ permalink raw reply
* Re: [PATCH net-next] ethtool: Remove unnecessary null check in ethtool_rx_flow_rule_create
From: David Miller @ 2019-02-09 7:05 UTC (permalink / raw)
To: natechancellor; +Cc: netdev, linux-kernel, pablo, jiri, ndesaulniers
In-Reply-To: <20190208044652.32166-1-natechancellor@gmail.com>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Thu, 7 Feb 2019 21:46:53 -0700
> net/core/ethtool.c:3023:19: warning: address of array
> 'ext_m_spec->h_dest' will always evaluate to 'true'
> [-Wpointer-bool-conversion]
> if (ext_m_spec->h_dest) {
> ~~ ~~~~~~~~~~~~^~~~~~
>
> h_dest is an array, it can't be null so remove this check.
>
> Fixes: eca4205f9ec3 ("ethtool: add ethtool_rx_flow_spec to flow_rule structure translator")
> Link: https://github.com/ClangBuiltLinux/linux/issues/353
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ixgbe: Use struct_size() helper
From: David Miller @ 2019-02-09 7:04 UTC (permalink / raw)
To: gustavo; +Cc: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20190208042258.GA32468@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 7 Feb 2019 22:22:58 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = kzalloc(size, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> Notice that, in this case, variable size is not necessary, hence
> it is removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] igc: Use struct_size() helper
From: David Miller @ 2019-02-09 7:04 UTC (permalink / raw)
To: gustavo; +Cc: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20190208041945.GA4687@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 7 Feb 2019 22:19:45 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = kzalloc(size, GFP_KERNEL)
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL)
>
> Notice that, in this case, variable size is not necessary, hence
> it is removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] igb: use struct_size() helper
From: David Miller @ 2019-02-09 7:04 UTC (permalink / raw)
To: gustavo; +Cc: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20190208041540.GA28817@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 7 Feb 2019 22:15:40 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = alloc(size, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> size = struct_size(instance, entry, count);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: don't double-read link status register if link is up
From: David Miller @ 2019-02-09 7:02 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <fd5559ed-6843-9ce5-fbb2-d9ffa9eb92e9@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 7 Feb 2019 20:22:20 +0100
> The link status register latches link-down events. Therefore, if link
> is reported as being up, there's no need for a second read.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Looks good.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: stmmac: Variable "val" in function sun8i_dwmac_set_syscon() could be uninitialized
From: David Miller @ 2019-02-09 7:01 UTC (permalink / raw)
To: yzhai003
Cc: csong, zhiyunq, peppe.cavallaro, alexandre.torgue, maxime.ripard,
wens, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20190207174623.16712-1-yzhai003@ucr.edu>
From: Yizhuo <yzhai003@ucr.edu>
Date: Thu, 7 Feb 2019 09:46:23 -0800
> In function sun8i_dwmac_set_syscon(), local variable "val" could
> be uninitialized if function regmap_read() returns -EINVAL.
> However, it will be used directly in the if statement, which
> is potentially unsafe.
>
> Signed-off-by: Yizhuo <yzhai003@ucr.edu>
This doesn't apply to any of my trees.
^ permalink raw reply
* Re: [PATCH net-next] fm10k: use struct_size() in kzalloc()
From: David Miller @ 2019-02-09 6:58 UTC (permalink / raw)
To: gustavo; +Cc: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20190208035537.GA12318@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 7 Feb 2019 21:55:37 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = kzalloc(size, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> Notice that, in this case, variable size is not necessary, hence
> it is removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] nfp: flower: cmsg: use struct_size() helper
From: David Miller @ 2019-02-09 6:58 UTC (permalink / raw)
To: gustavo; +Cc: jakub.kicinski, oss-drivers, netdev, linux-kernel
In-Reply-To: <20190208034725.GA12043@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 7 Feb 2019 21:47:25 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(void *);
> instance = alloc(size, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = alloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> Notice that, in this case, variable size is not necessary, hence
> it is removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: spectrum_router: Use struct_size() in kzalloc()
From: David Miller @ 2019-02-09 6:58 UTC (permalink / raw)
To: gustavo; +Cc: jiri, idosch, netdev, linux-kernel
In-Reply-To: <20190208034241.GA11858@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 7 Feb 2019 21:42:41 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = kzalloc(size, GFP_KERNEL)
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL)
>
> Notice that, in this case, variable alloc_size is not necessary, hence
> it is removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: Use struct_size() in kzalloc()
From: David Miller @ 2019-02-09 6:58 UTC (permalink / raw)
To: gustavo; +Cc: aelior, skalluru, GR-everest-linux-l2, netdev, linux-kernel
In-Reply-To: <20190208032910.GA3436@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 7 Feb 2019 21:29:10 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = kzalloc(size, GFP_KERNEL)
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL)
>
> Notice that, in this case, variable fsz is not necessary, hence
> it is removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] wimax/i2400m: use struct_size() helper
From: David Miller @ 2019-02-09 6:58 UTC (permalink / raw)
To: gustavo; +Cc: inaky.perez-gonzalez, linux-wimax, netdev, linux-kernel
In-Reply-To: <20190208032217.GA3232@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 7 Feb 2019 21:22:17 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(void *);
> instance = alloc(size, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> size = struct_size(instance, entry, count);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] wan: wanxl: use struct_size() in kzalloc()
From: David Miller @ 2019-02-09 6:58 UTC (permalink / raw)
To: gustavo; +Cc: khc, netdev, linux-kernel
In-Reply-To: <20190208031648.GA3022@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 7 Feb 2019 21:16:48 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = alloc(size, GFP_KERNEL)
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = alloc(struct_size(instance, entry, count), GFP_KERNEL)
>
> Notice that, in this case, variable alloc_size is not necessary, hence
> it is removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: usb: cdc-phonet: use struct_size() in alloc_netdev()
From: David Miller @ 2019-02-09 6:58 UTC (permalink / raw)
To: gustavo; +Cc: linux-usb, netdev, linux-kernel
In-Reply-To: <20190208031313.GA2848@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 7 Feb 2019 21:13:13 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entry[];
> };
>
> instance = alloc(sizeof(struct foo) + count * sizeof(void *));
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = alloc(struct_size(instance, entry, count));
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: use struct_size() in devm_kzalloc()
From: David Miller @ 2019-02-09 6:58 UTC (permalink / raw)
To: gustavo; +Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20190208011603.GA927@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 7 Feb 2019 19:16:03 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = alloc(size, GFP_KERNEL)
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = alloc(struct_size(instance, entry, count), GFP_KERNEL)
>
> Notice that, in this case, variable size is not necessary, hence it is
> removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] mpls_iptunnel: use struct_size() helper
From: David Miller @ 2019-02-09 6:57 UTC (permalink / raw)
To: gustavo; +Cc: netdev, linux-kernel
In-Reply-To: <20190208011052.GA646@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 7 Feb 2019 19:10:52 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> instance = alloc(sizeof(struct foo) + count * sizeof(struct boo));
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = alloc(struct_size(instance, entry, count));
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net/sched: use struct_size() helper
From: David Miller @ 2019-02-09 6:57 UTC (permalink / raw)
To: gustavo; +Cc: jhs, xiyou.wangcong, jiri, netdev, linux-kernel
In-Reply-To: <20190208010252.GA24824@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 7 Feb 2019 19:02:52 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = alloc(size, GFP_KERNEL)
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> size = struct_size(instance, entry, count);
> instance = alloc(size, GFP_KERNEL)
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bridge: use struct_size() helper
From: David Miller @ 2019-02-09 6:57 UTC (permalink / raw)
To: gustavo; +Cc: roopa, nikolay, bridge, netdev, linux-kernel
In-Reply-To: <20190208005856.GA16642@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 7 Feb 2019 18:58:56 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = alloc(size, GFP_KERNEL)
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> size = struct_size(instance, entry, count);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox