On Fri, 22 Mar 2024 03:24:56 -0400 (EDT) Julia Lawall wrote:
> > At present I find this construct unreadable.
> > I may get used to it, hard to say.
> >
> > Also I don't see the benefit of the auto-freeing construct,
> > I'd venture a guess that all the bugs it may prevent would
> > have been caugh
On Thu, 21 Mar 2024, Jakub Kicinski wrote:
> On Thu, 21 Mar 2024 15:27:47 -0700 Jesse Brandeburg wrote:
> > The gist of it is that we should instead be using inline declarations,
> > which I also agree is a reasonable style for this. It more clearly shows
> > the __free(kfree) and the allocation
On Thu, Mar 21, 2024 at 04:20:09PM -0400, Julia Lawall wrote:
> Does one prefer an initialization of null at the top of the function
> or an initialization to a meaningful value in the middle of the
> function?
I prefer at the top, but it will be interesting to see where the
consensus is. Kent Ov
On Thu, 21 Mar 2024 18:48:28 -0700 Jakub Kicinski wrote:
> On Thu, 21 Mar 2024 15:27:47 -0700 Jesse Brandeburg wrote:
> > The gist of it is that we should instead be using inline declarations,
> > which I also agree is a reasonable style for this. It more clearly shows
> > the __free(kfree) and t
On Thu, 21 Mar 2024 15:27:47 -0700 Jesse Brandeburg wrote:
> The gist of it is that we should instead be using inline declarations,
> which I also agree is a reasonable style for this. It more clearly shows
> the __free(kfree) and the allocation (kzalloc, kcalloc, etc) on the same
> (or virtuall
On 3/21/2024 1:20 PM, Julia Lawall wrote:
Does one prefer an initialization of null at the top of the function
or an initialization to a meaningful value in the middle of the
function ?
I think the latter.
There was a related patch explaining the direction, from Dan posted here:
https://lore.k
Does one prefer an initialization of null at the top of the function or an
initialization to a meaningful value in the middle of the function ?
(Sorry for top posting)
Sent from my iPhone
> On 21 Mar 2024, at 14:14, Markus Elfring wrote:
>
>
>>
>>> How do you think about to reduce the sco
>> How do you think about to reduce the scope for the affected local variable
>> instead
>> with the help of a small script (like the following) for the semantic patch
>> language?
>>
>> @movement@
>> attribute name __free;
>> @@
>> -u8 *tx_frame __free(kfree);
>> int i;
>> ... when any
>> if
> Automatically cleaned up pointers need to be initialized before exiting
> their scope. In this case, they need to be initialized to NULL before
> any return statement.
How will development interests evolve further for such design aspects?
…
> +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
On Thu, Mar 21, 2024 at 06:59:00PM +0100, Markus Elfring wrote:
…
> > +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
> > @@ -941,11 +941,11 @@ static u64 ice_loopback_test(struct net_device
> > *netdev)
> > struct ice_netdev_priv *np = netdev_priv(netdev);
> > struct ice_vsi *orig_vs
On Thu, Mar 21, 2024 at 10:59:42AM +0100, Przemek Kitszel wrote:
> Simplest solution would be to add a macro wrapper, especially that there
> are only a few deallocation methods.
>
> in cleanup.h:
> +#define auto_kfree __free(kfree) = NULL
>
> and similar macros for auto vfree(), etc.
>
> then i
On 3/21/24 04:29, Jakub Kicinski wrote:
On Wed, 20 Mar 2024 08:01:49 +0300 Dan Carpenter wrote:
This is just trading one kind of bug for another, and the __free()
magic is at a cost of readability.
Apologies for not catching it during review.
It's good that we have started small, with just a f
On Wed, 20 Mar 2024 08:01:49 +0300 Dan Carpenter wrote:
> > This is just trading one kind of bug for another, and the __free()
> > magic is at a cost of readability.
> >
> > I think we should ban the use of __free() in all of networking,
> > until / unless it cleanly handles the NULL init case.
On 20 March 2024 07:32:17 GMT, Julia Lawall wrote:
>
>
>On Wed, 20 Mar 2024, Dan Carpenter wrote:
>
>> On Tue, Mar 19, 2024 at 12:43:17PM -0700, Jakub Kicinski wrote:
>> > On Sat, 16 Mar 2024 12:44:40 +0300 Dan Carpenter wrote:
>> > > -struct ice_aqc_get_phy_caps_data *pcaps __free(kfre
> Automatically cleaned up pointers need to be initialized before exiting
> their scope. In this case, they need to be initialized to NULL before
> any return statement.
I suggest to reconsider such information a bit more.
…
> +++ b/drivers/net/ethernet/intel/ice/ice_common.c
> @@ -1002,8 +1002
On Wed, 20 Mar 2024, Dan Carpenter wrote:
> On Tue, Mar 19, 2024 at 12:43:17PM -0700, Jakub Kicinski wrote:
> > On Sat, 16 Mar 2024 12:44:40 +0300 Dan Carpenter wrote:
> > > - struct ice_aqc_get_phy_caps_data *pcaps __free(kfree);
> > > - void *mac_buf __free(kfree);
> > > + struct ice_aqc_get_
On Tue, Mar 19, 2024 at 12:43:17PM -0700, Jakub Kicinski wrote:
> On Sat, 16 Mar 2024 12:44:40 +0300 Dan Carpenter wrote:
> > - struct ice_aqc_get_phy_caps_data *pcaps __free(kfree);
> > - void *mac_buf __free(kfree);
> > + struct ice_aqc_get_phy_caps_data *pcaps __free(kfree) = NULL;
> > +
On Sat, 16 Mar 2024 12:44:40 +0300 Dan Carpenter wrote:
> - struct ice_aqc_get_phy_caps_data *pcaps __free(kfree);
> - void *mac_buf __free(kfree);
> + struct ice_aqc_get_phy_caps_data *pcaps __free(kfree) = NULL;
> + void *mac_buf __free(kfree) = NULL;
This is just trading one kin
On Mon, Mar 18, 2024 at 08:58:24AM +0100, Jiri Pirko wrote:
> Sat, Mar 16, 2024 at 10:44:40AM CET, dan.carpen...@linaro.org wrote:
> >Automatically cleaned up pointers need to be initialized before exiting
> >their scope. In this case, they need to be initialized to NULL before
> >any return state
Sat, Mar 16, 2024 at 10:44:40AM CET, dan.carpen...@linaro.org wrote:
>Automatically cleaned up pointers need to be initialized before exiting
>their scope. In this case, they need to be initialized to NULL before
>any return statement.
>
>Fixes: 90f821d72e11 ("ice: avoid unnecessary devm_ usage")
Automatically cleaned up pointers need to be initialized before exiting
their scope. In this case, they need to be initialized to NULL before
any return statement.
Fixes: 90f821d72e11 ("ice: avoid unnecessary devm_ usage")
Signed-off-by: Dan Carpenter
---
drivers/net/ethernet/intel/ice/ice_comm
21 matches
Mail list logo
