Message ID | 20201102142228.14949-2-brgl@bgdev.pl (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | iio: adc: xilinx: use even more devres | expand |
On Mon, 2 Nov 2020 15:22:25 +0100 Bartosz Golaszewski <brgl@bgdev.pl> wrote: > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > When allocating an array of elements, users should check for > multiplication overflow or preferably use one of the provided helpers > like: devm_kmalloc_array(). > > This provides devm_krealloc_array() for users who want to reallocate > managed arrays. > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> +CC Greg KH. As this is going into a very generic place I'd like a relevant ack. That file is a bit of a wild west for acks, but Greg seems most appropriate person. So Greg, any comments on this one? Thanks, Jonathan > --- > include/linux/device.h | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/include/linux/device.h b/include/linux/device.h > index 5ed101be7b2e..e77203faea55 100644 > --- a/include/linux/device.h > +++ b/include/linux/device.h > @@ -226,6 +226,17 @@ static inline void *devm_kmalloc_array(struct device *dev, > > return devm_kmalloc(dev, bytes, flags); > } > +static inline void * > +devm_krealloc_array(struct device *dev, void *ptr, size_t new_n, > + size_t new_size, gfp_t gfp) > +{ > + size_t bytes; > + > + if (unlikely(check_mul_overflow(new_n, new_size, &bytes))) > + return NULL; > + > + return devm_krealloc(dev, ptr, bytes, gfp); > +} > static inline void *devm_kcalloc(struct device *dev, > size_t n, size_t size, gfp_t flags) > {
On Sat, Nov 14, 2020 at 03:46:41PM +0000, Jonathan Cameron wrote: > On Mon, 2 Nov 2020 15:22:25 +0100 > Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > When allocating an array of elements, users should check for > > multiplication overflow or preferably use one of the provided helpers > > like: devm_kmalloc_array(). > > > > This provides devm_krealloc_array() for users who want to reallocate > > managed arrays. > > > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > +CC Greg KH. > > As this is going into a very generic place I'd like a relevant ack. > That file is a bit of a wild west for acks, but Greg seems most > appropriate person. > > So Greg, any comments on this one? As there is only 1 user of this function in the patch series, you don't save any extra code space here, I don't think this is worth it. We are seeing less and less gains from these new devm_* additions, and only more confusion and problems with them. So perhaps don't add this? I don't think it is needed. thanks, greg k-h
On Sat, Nov 14, 2020 at 5:16 PM Greg KH <gregkh@linuxfoundation.org> wrote: > > On Sat, Nov 14, 2020 at 03:46:41PM +0000, Jonathan Cameron wrote: > > On Mon, 2 Nov 2020 15:22:25 +0100 > > Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > > > When allocating an array of elements, users should check for > > > multiplication overflow or preferably use one of the provided helpers > > > like: devm_kmalloc_array(). > > > > > > This provides devm_krealloc_array() for users who want to reallocate > > > managed arrays. > > > > > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > +CC Greg KH. > > > > As this is going into a very generic place I'd like a relevant ack. > > That file is a bit of a wild west for acks, but Greg seems most > > appropriate person. > > > > So Greg, any comments on this one? > > As there is only 1 user of this function in the patch series, you don't > save any extra code space here, I don't think this is worth it. > It's worth it in that the overflow check before allocation doesn't seem to belong in a driver IMO but is a general check that should live in common code. > We are seeing less and less gains from these new devm_* additions, and > only more confusion and problems with them. So perhaps don't add this? > I don't think it is needed. > I think you're referring to the discussion on devm_platform_ioremap_resource()? I would argue that consolidation of common operations in helpers is rarely a bad thing but it's a discussion for another thread. I'm not too attached to this patch - if you think this should be dropped then fine, but I don't see how the name devm_krealloc_array() can confuse anyone. Bartosz
On Mon, Nov 16, 2020 at 11:18 AM Bartosz Golaszewski <bgolaszewski@baylibre.com> wrote: > > On Sat, Nov 14, 2020 at 5:16 PM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Sat, Nov 14, 2020 at 03:46:41PM +0000, Jonathan Cameron wrote: > > > On Mon, 2 Nov 2020 15:22:25 +0100 > > > Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > > > > > When allocating an array of elements, users should check for > > > > multiplication overflow or preferably use one of the provided helpers > > > > like: devm_kmalloc_array(). > > > > > > > > This provides devm_krealloc_array() for users who want to reallocate > > > > managed arrays. > > > > > > > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > > > +CC Greg KH. > > > > > > As this is going into a very generic place I'd like a relevant ack. > > > That file is a bit of a wild west for acks, but Greg seems most > > > appropriate person. > > > > > > So Greg, any comments on this one? > > > > As there is only 1 user of this function in the patch series, you don't > > save any extra code space here, I don't think this is worth it. > > > > It's worth it in that the overflow check before allocation doesn't > seem to belong in a driver IMO but is a general check that should live > in common code. > > > We are seeing less and less gains from these new devm_* additions, and > > only more confusion and problems with them. So perhaps don't add this? > > I don't think it is needed. > > > > I think you're referring to the discussion on > devm_platform_ioremap_resource()? I would argue that consolidation of > common operations in helpers is rarely a bad thing but it's a > discussion for another thread. > > I'm not too attached to this patch - if you think this should be > dropped then fine, but I don't see how the name devm_krealloc_array() > can confuse anyone. > Greg: what's the final call on this? Bartosz
On Mon, 23 Nov 2020 12:38:26 +0100 Bartosz Golaszewski <brgl@bgdev.pl> wrote: > On Mon, Nov 16, 2020 at 11:18 AM Bartosz Golaszewski > <bgolaszewski@baylibre.com> wrote: > > > > On Sat, Nov 14, 2020 at 5:16 PM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > > > On Sat, Nov 14, 2020 at 03:46:41PM +0000, Jonathan Cameron wrote: > > > > On Mon, 2 Nov 2020 15:22:25 +0100 > > > > Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > > > > > > > When allocating an array of elements, users should check for > > > > > multiplication overflow or preferably use one of the provided helpers > > > > > like: devm_kmalloc_array(). > > > > > > > > > > This provides devm_krealloc_array() for users who want to reallocate > > > > > managed arrays. > > > > > > > > > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > > > > > +CC Greg KH. > > > > > > > > As this is going into a very generic place I'd like a relevant ack. > > > > That file is a bit of a wild west for acks, but Greg seems most > > > > appropriate person. > > > > > > > > So Greg, any comments on this one? > > > > > > As there is only 1 user of this function in the patch series, you don't > > > save any extra code space here, I don't think this is worth it. > > > > > > > It's worth it in that the overflow check before allocation doesn't > > seem to belong in a driver IMO but is a general check that should live > > in common code. > > > > > We are seeing less and less gains from these new devm_* additions, and > > > only more confusion and problems with them. So perhaps don't add this? > > > I don't think it is needed. > > > > > > > I think you're referring to the discussion on > > devm_platform_ioremap_resource()? I would argue that consolidation of > > common operations in helpers is rarely a bad thing but it's a > > discussion for another thread. > > > > I'm not too attached to this patch - if you think this should be > > dropped then fine, but I don't see how the name devm_krealloc_array() > > can confuse anyone. > > > > Greg: what's the final call on this? Reroll the series without this patch. If it turns out to be a good idea in the long run we can always bring it back, but for now it's blocking the rest of the series. Thanks, Jonathan > > Bartosz
diff --git a/include/linux/device.h b/include/linux/device.h index 5ed101be7b2e..e77203faea55 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -226,6 +226,17 @@ static inline void *devm_kmalloc_array(struct device *dev, return devm_kmalloc(dev, bytes, flags); } +static inline void * +devm_krealloc_array(struct device *dev, void *ptr, size_t new_n, + size_t new_size, gfp_t gfp) +{ + size_t bytes; + + if (unlikely(check_mul_overflow(new_n, new_size, &bytes))) + return NULL; + + return devm_krealloc(dev, ptr, bytes, gfp); +} static inline void *devm_kcalloc(struct device *dev, size_t n, size_t size, gfp_t flags) {