On Fri, Jun 11, 2021 at 12:58:58PM +, Chris Mason wrote:
> > On Jun 10, 2021, at 12:20 PM, David Sterba wrote:
> > On Thu, Jun 10, 2021 at 04:50:09PM +0200, Christophe Leroy wrote:
> >> Le 10/06/2021 à 15:54, Chris Mason a écrit :
> >>>> On Jun 10
On Thu, Jun 10, 2021 at 05:23:02AM +, Christophe Leroy wrote:
> With a config having PAGE_SIZE set to 256K, BTRFS build fails
> with the following message
>
> include/linux/compiler_types.h:326:38: error: call to
> '__compiletime_assert_791' declared with attribute error: BUILD_BUG_ON
>
On Thu, Jun 10, 2021 at 04:50:09PM +0200, Christophe Leroy wrote:
>
>
> Le 10/06/2021 à 15:54, Chris Mason a écrit :
> >
> >> On Jun 10, 2021, at 1:23 AM, Christophe Leroy
> >> wrote:
> >>
> >> With a config having PAGE_SIZE set to 256K, BTRFS build fails
> >> with the following message
> >>
On Sun, May 02, 2021 at 12:15:38AM +0900, Masahiro Yamada wrote:
> The current minimum GCC version is 4.9 except ARCH=arm64 requiring
> GCC 5.1.
>
> When we discussed last time, we agreed to raise the minimum GCC version
> to 5.1 globally. [1]
There are still a lot of comment references to old
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
> -#include
> #include
> #include
> #include
On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > v4:
> > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > so that it can be backported to stable.
> > - Drop the "crypto: Remove unnecessary
On Mon, Jun 15, 2020 at 09:57:18PM -0400, Waiman Long wrote:
> In btrfs_ioctl_get_subvol_info(), there is a classic case where kzalloc()
> was incorrectly paired with kzfree(). According to David Sterba, there
> isn't any sensitive information in the subvol_info that needs to be
> cl
On Mon, Apr 13, 2020 at 05:15:49PM -0400, Waiman Long wrote:
> fs/btrfs/ioctl.c | 2 +-
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index 40b729dce91c..eab3f8510426 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -2691,7 +2691,7 @@ static int
| 2 +-
Acked-by: David Sterba
On Tue, Sep 03, 2019 at 02:25:07PM +0530, Abdul Haleem wrote:
> Greeting's
>
> Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file
> system on my P9 box running mainline kernel 5.3.0-rc5
Is the issue reproducible? And if yes, how reliably? Thanks.
was there already the only change is the
handling of the updates of the value.
> commit 00801ae4bb2be5f5af46502ef239ac5f4b536094
> Author: David Sterba
> Date: Thu May 2 16:53:47 2019 +0200
>
> btrfs: switch extent_buffer write_locks from atomic to int
>
&g
> > behaviour. The kmem cache based fix can be backported independently to
> > 4.19 regardless of the SL*B fixes.
> >
> >> +extern struct kmem_cache *btrfs_bitmap_cachep;
> >
> > I've renamed the cache to btrfs_free_space_bitmap_cachep
> >
> > Re
ff-by: Christophe Leroy
> ---
> v2: Using kmem_cache instead of get_zeroed_page() in order to benefit from
> SLAB debugging features like redzone.
I'll take this version, thanks. Though I'm not happy about the allocator
behaviour. The kmem cache based fix can be backported independently to
4.19 regardless of the SL*B fixes.
> +extern struct kmem_cache *btrfs_bitmap_cachep;
I've renamed the cache to btrfs_free_space_bitmap_cachep
Reviewed-by: David Sterba
On Sat, Aug 17, 2019 at 07:44:39AM +, Christophe Leroy wrote:
> Various notifications of type "BUG kmalloc-4096 () : Redzone
> overwritten" have been observed recently in various parts of
> the kernel. After some time, it has been made a relation with
> the use of BTRFS filesystem.
>
> [
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
On Tue, Mar 27, 2018 at 09:13:32PM +0200, Thorsten Leemhuis wrote:
> On 26.03.2018 01:37, Linus Torvalds wrote:
> > […] Anyway. Go out and test. And let's hope next week is nice and calm and
> > I can release the final 4.16 next Sunday without any extra rc's.
> >
> >Linus
>
>
16 matches
Mail list logo
