Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 9:14 PM, Linus Torvalds wrote: > On Fri, Mar 16, 2018 at 1:03 PM, Miguel Ojeda > wrote: >>> >>> Kees - is there some online "gcc-4.4 checker" somewhere? This does >>> seem to work with my gcc. I actually

Re: btrfs errors

Thanks for the reply! On Tue, 13 Mar 2018 22:24:43 -0600, Chris Murphy wrote: > If you search the list for 'corrupt leaf bad key ordering' the top two > causes are bad RAM and flaky power supply. These can be hard to narrow > down. I will try to get new power

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 9:14 PM, Linus Torvalds wrote: > On Fri, Mar 16, 2018 at 1:03 PM, Miguel Ojeda > wrote: >>> >>> Kees - is there some online "gcc-4.4 checker" somewhere? This does >>> seem to work with my gcc. I actually

RE: Crashes running btrfs scrub

> Could you please paste the whole dmesg, it looks like it hit > btrfs_abort_transaction(), > which should give us more information about where goes wrong. The whole thing is here https://pastebin.com/4ENq2saQ The

Re: Crashes running btrfs scrub

On Thu, Mar 15, 2018 at 2:07 PM, Mike Stevens wrote: >> That's a hell of a filesystem. RAID5 and RAID5 is unstable and should >> not be used for anything but throw away data. You will be happy that you >> value you data enough to have backups because all sensible

Re: [PATCH] btrfs: fix lockdep splat in btrfs_alloc_subvolume_writers

On 3/16/18 4:12 PM, David Sterba wrote: > On Fri, Mar 16, 2018 at 02:36:27PM -0400, je...@suse.com wrote: >> From: Jeff Mahoney >> >> While running btrfs/011, I hit the following lockdep splat. >> >> This is the important bit: >>pcpu_alloc+0x1ac/0x5e0 >>

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 10:44 AM, David Laight wrote: > > I looked at the generated code for one of the constant sized VLA that > the compiler barfed at. > It seemed to subtract constants from %sp separately for the VLA. > So it looks like the compiler treats them as VLA

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 1:14 PM, Linus Torvalds wrote: > > It does not work with gcc-4.1.x, but works with gcc-4.4.x. > > I can't seem to see the errors any way, I wonder if > __builtin_choose_expr() simply didn't exist back then. No, that goes further back. It

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 01:15:27PM -0700, Linus Torvalds wrote: > On Fri, Mar 16, 2018 at 1:12 PM, Al Viro wrote: > > > > That's C99, straight from N1256.pdf (C99-TC3)... > > I checked C90, since the error is > >ISO C90 forbids variable length array > > and I

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 1:12 PM, Al Viro wrote: > > That's C99, straight from N1256.pdf (C99-TC3)... I checked C90, since the error is ISO C90 forbids variable length array and I didn't see anything there. Admittedly I only found a draft copy.

Re: [PATCH] btrfs: fix lockdep splat in btrfs_alloc_subvolume_writers

On Fri, Mar 16, 2018 at 02:36:27PM -0400, je...@suse.com wrote: > From: Jeff Mahoney > > While running btrfs/011, I hit the following lockdep splat. > > This is the important bit: >pcpu_alloc+0x1ac/0x5e0 >__percpu_counter_init+0x4e/0xb0 >btrfs_init_fs_root+0x99/0x1c0

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 1:03 PM, Miguel Ojeda wrote: >> >> Kees - is there some online "gcc-4.4 checker" somewhere? This does >> seem to work with my gcc. I actually tested some of those files you >> pointed at now. > > I use this one: > > https://godbolt.org/

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 12:27:23PM -0700, Linus Torvalds wrote: > But it sure isn't "variable" either as far as the standard is > concerned, because the standard doesn't even have that concept (it > uses "variable" for argument numbers and for variables). Huh? 6.7.5.2p4: If the size is not

Re: [PATCH] btrfs: Document parameters of btrfs_reserve_extent

On Fri, Mar 16, 2018 at 08:44:56PM +0200, Nikolay Borisov wrote: > >> + * @min_alloc_size - Indicates the minimum amount of memory that the > > > > Could you please pick another word instead of "memory", like hole or > > extent or space? > > Good point, i guess it's a brain fair. I'd rather

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 8:27 PM, Linus Torvalds wrote: > On Fri, Mar 16, 2018 at 10:55 AM, Al Viro wrote: >> >> That's not them, that's C standard regarding ICE. > > Yes. The C standard talks about "integer constant expression". I know. >

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 10:55 AM, Al Viro wrote: > > That's not them, that's C standard regarding ICE. Yes. The C standard talks about "integer constant expression". I know. It's come up in this very thread before. The C standard at no point talks about - or forbids -

RE: Crashes running btrfs scrub

>>Mar 15 14:03:06 auswscs9903 kernel: BTRFS warning (device sdag): failed >>setting block group ro: -30 > These are only found in scrub.c Interesting. I'm running an offline btrfs check right now, so far extents and free space cache seem to have passed. If that finishes successfully, I'll

Re: [PATCH] btrfs: fix lockdep splat in btrfs_alloc_subvolume_writers

On 3/16/18 2:48 PM, Nikolay Borisov wrote: > > > On 16.03.2018 20:36, je...@suse.com wrote: >> From: Jeff Mahoney >> >> While running btrfs/011, I hit the following lockdep splat. >> >> This is the important bit: >>pcpu_alloc+0x1ac/0x5e0 >>__percpu_counter_init+0x4e/0xb0

Re: [PATCH] btrfs: fix lockdep splat in btrfs_alloc_subvolume_writers

On 16.03.2018 20:36, je...@suse.com wrote: > From: Jeff Mahoney > > While running btrfs/011, I hit the following lockdep splat. > > This is the important bit: >pcpu_alloc+0x1ac/0x5e0 >__percpu_counter_init+0x4e/0xb0 >btrfs_init_fs_root+0x99/0x1c0 [btrfs] >

Re: [PATCH] btrfs: fix lockdep splat in btrfs_alloc_subvolume_writers

On Fri, Mar 16, 2018 at 11:36 AM, wrote: > From: Jeff Mahoney > > While running btrfs/011, I hit the following lockdep splat. > > This is the important bit: >pcpu_alloc+0x1ac/0x5e0 >__percpu_counter_init+0x4e/0xb0 >btrfs_init_fs_root+0x99/0x1c0

Re: [PATCH] btrfs: Document parameters of btrfs_reserve_extent

On 16.03.2018 20:43, Liu Bo wrote: > On Tue, Mar 13, 2018 at 3:22 AM, Nikolay Borisov wrote: >> This function is the entry to the extent allocator and as such has >> quite a number of parameters. Some of those have subtle effects on the >> allocation algorithm. Document the

Re: [PATCH] btrfs: Document parameters of btrfs_reserve_extent

On Tue, Mar 13, 2018 at 3:22 AM, Nikolay Borisov wrote: > This function is the entry to the extent allocator and as such has > quite a number of parameters. Some of those have subtle effects on the > allocation algorithm. Document the parameters. > > Signed-off-by: Nikolay

[PATCH] btrfs: fix lockdep splat in btrfs_alloc_subvolume_writers

From: Jeff Mahoney While running btrfs/011, I hit the following lockdep splat. This is the important bit: pcpu_alloc+0x1ac/0x5e0 __percpu_counter_init+0x4e/0xb0 btrfs_init_fs_root+0x99/0x1c0 [btrfs] btrfs_get_fs_root.part.54+0x5b/0x150 [btrfs]

Re: [PATCH] missing initialization in btrfs_check_shared

On Wed, Mar 14, 2018 at 8:03 AM, Edmund Nadolski wrote: > This patch addresses an issue that causes fiemap to falsely > report a shared extent. The test case is as follows: > > # cat do_xfs_io > xfs_io -f -d -c "pwrite -b 16k 0 64k" -c "fiemap -v" /media/scratch/file5 > sync

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 05:55:02PM +, Al Viro wrote: > On Fri, Mar 16, 2018 at 10:29:16AM -0700, Linus Torvalds wrote: > >t.c: In function ‘test’: > >t.c:6:6: error: argument to variable-length array is too large > > [-Werror=vla-larger-than=] > > int array[(1,100)]; > > > > Gcc

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 10:29:16AM -0700, Linus Torvalds wrote: >t.c: In function ‘test’: >t.c:6:6: error: argument to variable-length array is too large > [-Werror=vla-larger-than=] > int array[(1,100)]; > > Gcc people are crazy. That's not them, that's C standard regarding ICE.

RE: [PATCH v5 0/2] Remove false-positive VLAs when using max()

From: Linus Torvalds > Sent: 16 March 2018 17:29 > On Fri, Mar 16, 2018 at 4:47 AM, Florian Weimer wrote: > > > > If you want to catch stack frames which have unbounded size, > > -Werror=stack-usage=1000 or -Werror=vla-larger-than=1000 (with the constant > > adjusted as

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On 03/16/2018 06:29 PM, Linus Torvalds wrote: Gcc people are crazy. End of discussion from me. This is not acceptable. Florian -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 4:47 AM, Florian Weimer wrote: > > If you want to catch stack frames which have unbounded size, > -Werror=stack-usage=1000 or -Werror=vla-larger-than=1000 (with the constant > adjusted as needed) might be the better approach. No, we want to catch

Re: [PATCH 2/2] btrfs: replace waitqueue_actvie with cond_wake_up

On Thu, Mar 08, 2018 at 05:47:20PM +0100, David Sterba wrote: > On Thu, Mar 08, 2018 at 02:19:28PM +0200, Nikolay Borisov wrote: > > > @@ -941,9 +941,7 @@ void btrfs_bio_counter_inc_noblocked(struct > > > btrfs_fs_info *fs_info) > > > void btrfs_bio_counter_sub(struct btrfs_fs_info *fs_info, s64

Re: Crashes running btrfs scrub

On Fri, Mar 16, 2018 at 10:17 AM, Mike Stevens wrote: >> Also, in the meantime, maybe the problem can be prevented by >> preventing the balance from resuming when mounting. First umount then >> mount with -o skip_balance. > > Thanks for the suggestion Chris. I already

Re: [PATCH v2 1/2] btrfs: drop num argument from find_live_mirror()

On Wed, Mar 14, 2018 at 04:29:12PM +0800, Anand Jain wrote: > Obtain the stripes info from the map directly and so no need > to pass it as an argument. > > Signed-off-by: Anand Jain 1-2 applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe

RE: Crashes running btrfs scrub

> Also, in the meantime, maybe the problem can be prevented by > preventing the balance from resuming when mounting. First umount then > mount with -o skip_balance. Thanks for the suggestion Chris. I already had mounted it with skip_balance and then cancelled the balance. It will mount, but

Re: [PATCH 4.14 024/110] btrfs: use proper endianness accessors for super_copy

On 03/16/2018 10:02 PM, Greg Kroah-Hartman wrote: On Fri, Mar 16, 2018 at 02:22:02PM +0100, David Sterba wrote: On Fri, Mar 16, 2018 at 01:30:49PM +0100, Greg Kroah-Hartman wrote: On Thu, Mar 15, 2018 at 07:55:42PM +0100, Christoph Biedl wrote: Greg Kroah-Hartman wrote... 4.14-stable

Re: [PATCH 02/22] btrfs: assume that prev_em_start is always valid in __do_readpage

On Tue, Mar 13, 2018 at 11:03:31PM +0800, Anand Jain wrote: > On 03/08/2018 10:33 PM, David Sterba wrote: > > All callers pass a valid pointer, we can remove the redundant checks. > > > > Signed-off-by: David Sterba > > --- > > fs/btrfs/extent_io.c | 9 ++--- > > 1 file

Re: [PATCH 0/8] Make the code -Wunused clean

On Thu, Mar 15, 2018 at 02:36:21PM +0200, Nikolay Borisov wrote: > This series eliminates all -Wunused warnings in the code base. Thanks, 1-8 applied. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo

Re: Crashes running btrfs scrub

Also, in the meantime, maybe the problem can be prevented by preventing the balance from resuming when mounting. First umount then mount with -o skip_balance. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

Re: [PATCH 1/4] btrfs: drop fs_info parameter from btrfs_run_delayed_refs

On Thu, Mar 15, 2018 at 04:00:24PM +0200, Nikolay Borisov wrote: > It's provided by the trans handle > > Signed-off-by: Nikolay Borisov > --- > > As discussed here https://www.spinics.net/lists/linux-btrfs/msg74775.html > those were the last 3 remaining function called from

Re: [PATCH v4 1/2] kernel.h: Introduce const_max() for VLA removal

On 2018-03-16 00:46, Linus Torvalds wrote: > On Thu, Mar 15, 2018 at 4:41 PM, Kees Cook wrote: >> >> I much prefer explicit typing, but both you and Rasmus mentioned >> wanting the int/sizeof_t mixing. > > Well, the explicit typing allows that mixing, in that you can just

[GIT PULL] Btrfs fixes for 4.16-rc6

Hi, there's an important revert in this pull request that needs to go to stable as it causes a corruption on big endian machines. The other fix is for FIEMAP incorrectly reporting shared extents before a sync and one fix for a crash in raid56. So far we got only one report about the BE

Re: [PATCH 4.14 024/110] btrfs: use proper endianness accessors for super_copy

On Fri, Mar 16, 2018 at 02:22:02PM +0100, David Sterba wrote: > On Fri, Mar 16, 2018 at 01:30:49PM +0100, Greg Kroah-Hartman wrote: > > On Thu, Mar 15, 2018 at 07:55:42PM +0100, Christoph Biedl wrote: > > > Greg Kroah-Hartman wrote... > > > > > > > 4.14-stable review patch. If anyone has any

[PATCH] Revert "btrfs: use proper endianness accessors for super_copy"

This reverts commit 3c181c12c431fe33b669410d663beb9cceefcd1b. The offending patch was merged in 4.16-rc4 and was promptly applied to stable kernels 4.14.25 and 4.15.8. The patch causes a corruption in several superblock items on big-endian machines because of messed up endianity conversions. The

Re: [PATCH 4.14 024/110] btrfs: use proper endianness accessors for super_copy

On Fri, Mar 16, 2018 at 01:30:49PM +0100, Greg Kroah-Hartman wrote: > On Thu, Mar 15, 2018 at 07:55:42PM +0100, Christoph Biedl wrote: > > Greg Kroah-Hartman wrote... > > > > > 4.14-stable review patch. If anyone has any objections, please let me > > > know. > > > > > commit

Re: [PATCH 4.14 024/110] btrfs: use proper endianness accessors for super_copy

On Thu, Mar 15, 2018 at 07:55:42PM +0100, Christoph Biedl wrote: > Greg Kroah-Hartman wrote... > > > 4.14-stable review patch. If anyone has any objections, please let me know. > > > commit 3c181c12c431fe33b669410d663beb9cceefcd1b upstream. > (...) > > > If the filesystem is always used on a

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On 03/16/2018 05:25 AM, Kees Cook wrote: In the effort to remove all VLAs from the kernel[1], it is desirable to build with -Wvla. However, this warning is overly pessimistic, in that it is only happy with stack array sizes that are declared as constant expressions, and not constant values. One

eeeffgghhiijjjjklllmnnnnoo

YangLei也越来越多样化。但是，尽管物流企业的前景一片光明，仍旧要居安思危，

Re: [PATCH RFC 3/3] fstests: generic: Check the fs after each FUA writes

On 2018年03月16日 16:33, Eryu Guan wrote: > On Wed, Mar 14, 2018 at 05:02:30PM +0800, Qu Wenruo wrote: >> Basic test case which triggers fsstress with dm-log-writes, and then >> check the fs after each FUA writes. >> With needed infrastructure and special handlers for journal based fs. >> >>

Re: [PATCH RFC 3/3] fstests: generic: Check the fs after each FUA writes

On 2018年03月16日 16:19, Eryu Guan wrote: > On Fri, Mar 16, 2018 at 01:17:07PM +0800, Qu Wenruo wrote: >> >> >> On 2018年03月16日 12:01, Eryu Guan wrote: >>> On Wed, Mar 14, 2018 at 05:02:30PM +0800, Qu Wenruo wrote: Basic test case which triggers fsstress with dm-log-writes, and then check

Re: [PATCH RFC 3/3] fstests: generic: Check the fs after each FUA writes

On Wed, Mar 14, 2018 at 05:02:30PM +0800, Qu Wenruo wrote: > Basic test case which triggers fsstress with dm-log-writes, and then > check the fs after each FUA writes. > With needed infrastructure and special handlers for journal based fs. > > Signed-off-by: Qu Wenruo > --- > In

Re: [PATCH RFC 3/3] fstests: generic: Check the fs after each FUA writes

On Fri, Mar 16, 2018 at 10:19 AM, Eryu Guan wrote: > On Fri, Mar 16, 2018 at 01:17:07PM +0800, Qu Wenruo wrote: >> >> >> On 2018年03月16日 12:01, Eryu Guan wrote: >> > On Wed, Mar 14, 2018 at 05:02:30PM +0800, Qu Wenruo wrote: >> >> Basic test case which triggers fsstress with

Re: [PATCH RFC 3/3] fstests: generic: Check the fs after each FUA writes

On Fri, Mar 16, 2018 at 01:17:07PM +0800, Qu Wenruo wrote: > > > On 2018年03月16日 12:01, Eryu Guan wrote: > > On Wed, Mar 14, 2018 at 05:02:30PM +0800, Qu Wenruo wrote: > >> Basic test case which triggers fsstress with dm-log-writes, and then > >> check the fs after each FUA writes. > >> With

Re: [PATCH 1/1] btrfs-progs: Fix typos in docs and user-facing strings

On 16.03.2018 02:39, Nicholas D Steeves wrote: > Signed-off-by: Nicholas D Steeves All look fine except one nit, see below. > --- > Documentation/btrfs-balance.asciidoc | 2 +- > Documentation/btrfs-check.asciidoc | 2 +- > Documentation/btrfs-man5.asciidoc| 8

Re: [PATCH v4 2/2] Remove false-positive VLAs when using max()

On 15.03.2018 21:47, Kees Cook wrote: > As part of removing VLAs from the kernel[1], we want to build with -Wvla, > but it is overly pessimistic and only accepts constant expressions for > stack array sizes, instead of also constant values. The max() macro > triggers the warning, so this