Re: [linux-next:master] BUILD REGRESSION 6dc544b66971c7f9909ff038b62149105272d26a

On Wed, May 29, 2024 at 02:19:47AM +0800, kernel test robot wrote: > tree/branch: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > branch HEAD: 6dc544b66971c7f9909ff038b62149105272d26a Add linux-next > specific files for 20240528 > > Error/Warning reports: > >

Re: [PATCH next 09/11] tree-wide: minmax: Replace all the uses of max() for array sizes with max_const()

d > speeding up compilation. > > max_const() will convert enums to int (or unsigned int) so that the > casts added by max_t() are no longer needed. > > Signed-off-by: David Laight > --- For > fs/btrfs/tree-checker.c | 2 +- Acked-by: David Sterba

Re: [PATCH 04/12] btrfs: send: Proactively round up to kmalloc bucket size

; the buffer through the existing __alloc_size() hint. > > Cc: linux-bt...@vger.kernel.org > Signed-off-by: Kees Cook Acked-by: David Sterba

Re: [PATCH] [v2] Kbuild: move to -std=gnu11

On Mon, Feb 28, 2022 at 02:01:06PM +0100, Arnd Bergmann wrote: > On Mon, Feb 28, 2022 at 1:36 PM Jani Nikula > wrote: > > > > > > One minor issue that remains is an added gcc warning for shifts of > > > negative integers when building with -Werror, which happens with the > > > 'make W=1' option,

Re: [PATCH] [v2] Kbuild: move to -std=gnu11

Makefile| 6 +++--- > arch/arm64/kernel/vdso32/Makefile | 2 +- > drivers/gpu/drm/i915/Makefile | 1 + > drivers/staging/greybus/tools/Makefile | 3 ++- For > fs/btrf

Re: [PATCH v2 49/63] btrfs: Use memset_startat() to clear end of struct

confused about writing > beyond the destination member that is intended to be the starting point > of zeroing through the end of the struct. > > Cc: Chris Mason > Cc: Josef Bacik > Cc: David Sterba > Cc: linux-bt...@vger.kernel.org > Signed-off-by: Kees Cook Acked-by: David Sterba

Re: [PATCH 47/64] btrfs: Use memset_after() to clear end of struct

On Sat, Jul 31, 2021 at 08:25:51AM -0700, Kees Cook wrote: > On Thu, Jul 29, 2021 at 12:33:37PM +0200, David Sterba wrote: > > On Wed, Jul 28, 2021 at 02:56:31PM -0700, Kees Cook wrote: > > > On Wed, Jul 28, 2021 at 11:42:15AM +0200, David Sterba wrote: > > > > On T

Re: [PATCH 01/64] media: omap3isp: Extract struct group for memcpy() region

On Thu, Jul 29, 2021 at 11:00:48PM -0700, Kees Cook wrote: > On Thu, Jul 29, 2021 at 11:20:39AM +0300, Dan Carpenter wrote: > > On Thu, Jul 29, 2021 at 07:56:27AM +0200, Greg Kroah-Hartman wrote: > > > On Wed, Jul 28, 2021 at 11:37:30PM +0200, David Sterba wrote: > > > &

Re: [PATCH 02/64] mac80211: Use flex-array for radiotap header bitmap

On Wed, Jul 28, 2021 at 02:54:52PM -0700, Kees Cook wrote: > On Wed, Jul 28, 2021 at 11:23:23AM +0200, David Sterba wrote: > > On Wed, Jul 28, 2021 at 10:35:56AM +0300, Dan Carpenter wrote: > > > @@ -372,7 +372,7 @@ ieee80211_add_rx_radiotap_header(struct > >

Re: [PATCH 47/64] btrfs: Use memset_after() to clear end of struct

On Wed, Jul 28, 2021 at 02:56:31PM -0700, Kees Cook wrote: > On Wed, Jul 28, 2021 at 11:42:15AM +0200, David Sterba wrote: > > On Tue, Jul 27, 2021 at 01:58:38PM -0700, Kees Cook wrote: > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > >

Re: [PATCH 01/64] media: omap3isp: Extract struct group for memcpy() region

On Wed, Jul 28, 2021 at 02:37:20PM -0700, Bart Van Assche wrote: > On 7/28/21 2:14 AM, Dan Carpenter wrote: > > On Wed, Jul 28, 2021 at 10:59:22AM +0200, David Sterba wrote: > >>> drivers/media/platform/omap3isp/ispstat.c | 5 +-- > >>> include/uapi/

Re: [PATCH 01/64] media: omap3isp: Extract struct group for memcpy() region

On Tue, Jul 27, 2021 at 01:57:52PM -0700, Kees Cook wrote: > In preparation for FORTIFY_SOURCE performing compile-time and run-time > field bounds checking for memcpy(), memmove(), and memset(), avoid > intentionally writing across neighboring fields. Wrap the target region > in a common named

Re: [PATCH 47/64] btrfs: Use memset_after() to clear end of struct

gt; + memset_after(item, 0, level); > generate_random_guid(item->uuid); Acked-by: David Sterba

Re: [PATCH 02/64] mac80211: Use flex-array for radiotap header bitmap

On Wed, Jul 28, 2021 at 10:35:56AM +0300, Dan Carpenter wrote: > @@ -372,7 +372,7 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local > *local, > ieee80211_calculate_rx_timestamp(local, status, >mpdulen, 0), >

Re: [patch V3 03/37] fs: Remove asm/kmap_types.h includes

org > Cc: Chris Mason > Cc: Josef Bacik > Cc: David Sterba Acked-by: David Sterba For the btrfs bits > fs/btrfs/ctree.h |1 - > --- a/fs/btrfs/ctree.h > +++ b/fs/btrfs/ctree.h > @@ -17,7 +17,6 @@ > #include > #include > #include

Re: [PATCH 05/35] docs: filesystems: fix renamed references

| 2 +- Acked-by: David Sterba ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg

uble-checked all these drivers to ensure that all ioctl arguments > are used as pointers or are ignored, but are not interpreted as integer > values. > > Signed-off-by: Arnd Bergmann > --- > fs/btrfs/super.c | 2 +- Acked-by: David Sterba _

Re: [PATCH 06/14] btrfs: separate errno from VM_FAULT_* values

On Wed, May 16, 2018 at 07:43:40AM +0200, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: David Sterba <dste...@suse.com> I can add it to the btrfs queue now, unless you need the patch for the res

Re: [PATCH 10/10] fs:btrfs: return -ENOMEM on allocation failure.

On Wed, Sep 13, 2017 at 01:02:19PM +0530, Allen Pais wrote: > Signed-off-by: Allen Pais > --- > fs/btrfs/check-integrity.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c > index

merging printk and WARN

On Sun, Nov 04, 2012 at 09:25:53PM +0100, Julia Lawall wrote: > It looks like these patches were not a good idea, because in each case the > printk provides an error level, and WARN then provides another one. I think this is not a problem within btrfs at the place where this has changed. david

Re: merging printk and WARN

On Sun, Nov 04, 2012 at 09:25:53PM +0100, Julia Lawall wrote: It looks like these patches were not a good idea, because in each case the printk provides an error level, and WARN then provides another one. I think this is not a problem within btrfs at the place where this has changed. david