Re: [GIT PULL] Btrfs fixes for 4.17-rc6

On Sun, May 20, 2018 at 8:21 AM David Sterba wrote: > They IMHO qualify for a late rc, though I did not expect that many. Especially with the tree-log.c changes being fairly big, I took a look, and I have to say that I appreciate (a) the warning in the pull request and (b) the

Re: Please add 21035965f60b ("bitmap: fix memset optimization on big-endian systems") to the stable tree

On Tue, Apr 3, 2018 at 11:14 AM, Omar Sandoval wrote: > Just wanted to make sure this doesn't get missed because I misspelled > the stable email address in the patch. It applies to v4.13+. The "sta...@kernel.org" address for a stable cc is actually better than stable@vger"

Re: [PATCH] bitmap: fix memset optimization on big-endian systems

On Mon, Apr 2, 2018 at 4:37 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > We should probably have at least switched it to "unsigned long int" I meant just "unsigned int", of course. Right now we occasionally have a silly 64-bit field just for a co

Re: [PATCH] bitmap: fix memset optimization on big-endian systems

On Mon, Apr 2, 2018 at 3:58 PM, Omar Sandoval wrote: > > Commit 2a98dc028f91 introduced an optimization to bitmap_{set,clear}() > which uses memset() when the start and length are constants aligned to a > byte. This is wrong on big-endian systems; Ugh, yes. In retrospect, I

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

On Thu, Mar 22, 2018 at 8:01 AM, Kees Cook wrote: > > Seems like it doesn't like void * arguments: Yeah, that was discussed separately, I just didn't realize we had any such users. As David said, just adding a (long) cast to it should be fine, ie #define

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

On Tue, Mar 20, 2018 at 4:23 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > Hmm. So thanks to the diseased mind of Martin Uecker, there's a better > test for "__is_constant()": > > /* Glory to Martin Uecker <martin.uec...@med.uni-goettinge

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

On Sat, Mar 17, 2018 at 1:07 PM, Kees Cook wrote: > > No luck! :( gcc 4.4 refuses to play along. And, hilariously, not only > does it not change the complaint about __builtin_choose_expr(), it > also thinks that's a VLA now. Hmm. So thanks to the diseased mind of Martin

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

On Mon, Mar 19, 2018 at 2:43 AM, David Laight wrote: > > Is it necessary to have the full checks for old versions of gcc? > > Even -Wvla could be predicated on very recent gcc - since we aren't > worried about whether gcc decides to generate a vla, but whether > the

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

On Sun, Mar 18, 2018 at 3:59 PM, Rasmus Villemoes wrote: > > OK, I missed where this was made about side effects of x and y We never made it explicit, since all we really cared about in the end is the constantness. But yes: > but I suppose the idea was to use > >

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

On Sun, Mar 18, 2018 at 2:13 PM, Rasmus Villemoes <li...@rasmusvillemoes.dk> wrote: > On 2018-03-17 19:52, Linus Torvalds wrote: >> >> Ok, so it really looks like that same "__builtin_constant_p() doesn't >> return a constant". >> >> Which is real

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

On Sat, Mar 17, 2018 at 12:27 AM, Kees Cook wrote: > > Unfortunately my 4.4 test fails quickly: > > ./include/linux/jiffies.h: In function ‘jiffies_delta_to_clock_t’: > ./include/linux/jiffies.h:444: error: first argument to > ‘__builtin_choose_expr’ not a constant Ok, so

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 <torva...@linux-foundation.org> 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, t

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 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 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: [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 v4 1/2] kernel.h: Introduce const_max() for VLA removal

On Thu, Mar 15, 2018 at 4:46 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > Well, the explicit typing allows that mixing, in that you can just > have "const_max_t(5,sizeof(x))" I obviously meant "const_max_t(size_t,5,sizeof(x))". Heh.

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

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 have "const_max_t(5,sizeof(x))" So I'm ok with

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

On Thu, Mar 15, 2018 at 3:46 PM, Kees Cook wrote: > > So, AIUI, I can either get strict type checking, in which case, this > is rejected (which I assume there is still a desire to have): > > int foo[const_max(6, sizeof(whatever))]; Ehh, yes, that looks fairly sane, and

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

On Thu, Mar 15, 2018 at 3:16 PM, Kees Cook wrote: > > size_t __error_not_const_arg(void) \ > __compiletime_error("const_max() used with non-compile-time constant arg"); > #define const_max(x, y) \ >

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

On Thu, Mar 15, 2018 at 12:47 PM, Kees Cook wrote: > > To gain the ability to compare differing types, the arguments are > explicitly cast to size_t. Ugh, I really hate this. It silently does insane things if you do const_max(-1,6) and there is nothing in the name

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton wrote: > > Replacing the __builtin_choose_expr() with ?: works of course. Hmm. That sounds like the right thing to do. We were so myopically staring at the __builtin_choose_expr() problem that we overlooked the obvious

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Sun, Mar 11, 2018 at 4:05 AM, Ingo Molnar wrote: > > BTW., while I fully agree with everything you said, it's not entirely correct > to > claim that if a C compiler can generate VLA code it is necessarily able to > parse > and evaluate constant array sizes "just fine". > >

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Sat, Mar 10, 2018 at 9:34 AM, Miguel Ojeda wrote: > > So the warning is probably implemented to just trigger whenever VLAs > are used but the given standard does not allow them, for all > languages. The problem is why the ISO C90 frontend is not giving an >

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Sat, Mar 10, 2018 at 7:33 AM, Kees Cook wrote: > > Alright, I'm giving up on fixing max(). I'll go back to STACK_MAX() or > some other name for the simple macro. Bleh. Oh, and I'm starting to see the real problem. It's not that our current "min/max()" are broiken. It's

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Sat, Mar 10, 2018 at 7:33 AM, Kees Cook wrote: > > And sparse freaks out too: > >drivers/net/ethernet/via/via-velocity.c:97:26: sparse: incorrect > type in initializer (different address spaces) @@expected void > *addr @@got struct mac_regs [noderef]

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 11:03 PM, Miguel Ojeda wrote: > > Just compiled 4.9.0 and it seems to work -- so that would be the > minimum required. > > Sigh... > > Some enterprise distros are either already shipping gcc >= 5 or will > probably be shipping it soon (e.g.

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 5:31 PM, Kees Cook wrote: > > WTF, gmail just blasted HTML into my explicitly plain-text email?! > Apologies... There's more now in your email, I think maybe it's triggered by your signature file and some gmail web interface bug. Or it just tries to

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 4:32 PM, Andrew Morton wrote: > > I wonder which gcc versions actually accept Kees's addition. Note that we already do have this pattern, as seen by: git grep -2 __builtin_choose_expr | grep -2 __builtin_constant_p which show

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 4:07 PM, Andrew Morton wrote: > > A brief poke failed to reveal a workaround - gcc-4.4.4 doesn't appear > to know that __builtin_constant_p(x) is a constant. Or something. LOL. I suspect it might be that it wants to evaluate

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 12:05 PM, Kees Cook wrote: > When max() is used in stack array size calculations from literal values > (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler > thinks this is a dynamic calculation due to the single-eval logic, which >

Re: [PATCH] kernel.h: Skip single-eval logic on literals in min()/max()

On Thu, Mar 8, 2018 at 4:45 PM, Kees Cook wrote: > > Rasmus mentioned this too. What I said there was that I was shy to > make that change, since we already can't mix that kind of thing with > the existing min()/max() implementation. The existing min()/max() is > already

Re: [PATCH] kernel.h: Skip single-eval logic on literals in min()/max()

On Thu, Mar 8, 2018 at 1:40 PM, Kees Cook wrote: > +#define __min(t1, t2, x, y)\ > + __builtin_choose_expr(__builtin_constant_p(x) &&\ > + __builtin_constant_p(y) &&

Re: [PATCH v2] iversion: make inode_cmp_iversion{+raw} return bool instead of s64

On Wed, Jan 31, 2018 at 4:29 AM, Jeff Layton wrote: > > Do you mind just taking it directly? I don't have anything else queued > up for this cycle. Done. I wonder if "false for same, true for different" calling convention makes much sense, but it matches the old "0 for same"

Re: [PATCH v2] iversion: make inode_cmp_iversion{+raw} return bool instead of s64

Ack. Should I expect this in a future pull request, or take it directly? There's no hurry about this, since none of the existing users of that function actually do anything but test the return value against zero, and nobody saves it into anything but a "bool" (which has magical casting properties

Re: [GIT PULL] inode->i_version rework for v4.16

On Tue, Jan 30, 2018 at 4:05 AM, Jeff Layton wrote: > > My intent here was to have this handle wraparound using the same sort of > method that the time_before/time_after macros do. Obviously, I didn't > document that well. Oh, the intent was clear. The implementation was

Re: [GIT PULL] inode->i_version rework for v4.16

On Mon, Jan 29, 2018 at 1:50 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > Hmm. I have pulled this, but it is really really broken in one place, > to the degree that I always went "no, I won't pull this garbage". always=almost. I'd blame auto-correct,

Re: [GIT PULL] inode->i_version rework for v4.16

On Mon, Jan 29, 2018 at 4:26 AM, Jeff Layton wrote: > > This pile of patches is a rework of the inode->i_version field. We have > traditionally incremented that field on every inode data or metadata > change. Typically this increment needs to be logged on disk even when >

Re: [btrfs_mount] general protection fault: 0000 [#1] SMP

On Wed, Nov 29, 2017 at 6:38 PM, Nick Terrell wrote: > > The stack trace looks like the bug fixed by > > Qu Wenruo: > btrfs: Fix wild memory access in compression level parser [1] > > That fix looks to be included in the pull request for 4.15-rc2 [2]. Which got merged

Re: [GIT PULL] Btrfs fixes for 4.15-rc2

On Wed, Nov 29, 2017 at 11:28 AM, David Sterba wrote: > > With signed tag: for-4.15-rc2-tag > > git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-4.15-rc2 Oh, please actually ask me to pull the signed tag (exact same pull-request, just point git request-pull

Re: [PATCH v4 4/5] squashfs: Add zstd support

On Fri, Aug 4, 2017 at 1:19 PM, Nick Terrell wrote: > > This patch was written by Sean Purcell , but I will be > taking over the submission process. Please, if so, get Sean's sign-off, and also make sure that the patch gets submitted with From: Sean Purcell

Re: [GIT PULL] Btrfs for 4.13

On Tue, Jul 4, 2017 at 8:19 AM, David Sterba wrote: > > There are conflicts with the recently merged block layer branch, the > resolutions are a bit tedious but still straightforward. Stephen sent a mail > about that [1]. You can find my merge at for-4.13-part1-merged, there

Re: bio linked list corruption.

On Tue, Dec 6, 2016 at 12:16 AM, Peter Zijlstra wrote: >> >> Of course, I'm really hoping that this shmem.c use is the _only_ such >> case. But I doubt it. > > $ git grep DECLARE_WAIT_QUEUE_HEAD_ONSTACK | wc -l > 28 Hmm. Most of them seem to be ok, because they use

Re: bio linked list corruption.

of mine that just verified that yes, the issue really was that wait queue entries remained on the wait queue head just as we were about to return and free it. Linus On Mon, Dec 5, 2016 at 12:10 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > Anyway, can you t

Re: bio linked list corruption.

On Mon, Dec 5, 2016 at 11:11 AM, Vegard Nossum wrote: > > [ cut here ] > WARNING: CPU: 22 PID: 14012 at mm/shmem.c:2668 shmem_fallocate+0x9a7/0xac0 Ok, good. So that's confirmed as the cause of this problem. And the call chain that I wanted is

Re: bio linked list corruption.

On Mon, Dec 5, 2016 at 10:11 AM, Andy Lutomirski wrote: > > So your kernel has been smp-alternatived. That 3e comes from > alternatives_smp_unlock. If you're running on SMP with UP > alternatives, things will break. I'm assuming he's just running in a VM with a single CPU.

Re: bio linked list corruption.

On Mon, Dec 5, 2016 at 9:09 AM, Vegard Nossum wrote: > > The warning shows that it made it past the list_empty_careful() check > in finish_wait() but then bugs out on the >task_list > dereference. > > Anything stick out? I hate that shmem waitqueue garbage. It's really

Re: bio linked list corruption.

On Mon, Oct 31, 2016 at 11:55 AM, Dave Jones wrote: > > BUG: Bad page state in process kworker/u8:12 pfn:4e0e39 > page:ea0013838e40 count:0 mapcount:0 mapping:8804a20310e0 index:0x100c > flags: 0x400c(referenced|uptodate) > page dumped because:

Re: bio linked list corruption.

On Wed, Oct 26, 2016 at 11:33 PM, Christoph Hellwig wrote: >> Dave, can you hit the warnings with this? Totally untested... > > Can we just kill off the unhelpful blk_map_ctx structure, e.g.: Yeah, I found that hard to read too. The difference between blk_map_ctx and

Re: bio linked list corruption.

On Wed, Oct 26, 2016 at 4:03 PM, Jens Axboe wrote: > > Actually, I think I see what might trigger it. You are on nvme, iirc, > and that has a deep queue. Yes. I have long since moved on from slow disks, so all my systems are not just flash, but m.2 nvme ssd's. So at least that

Re: bio linked list corruption.

On Wed, Oct 26, 2016 at 3:51 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > Dave: it might be a good idea to split that "WARN_ON_ONCE()" in > blk_mq_merge_queue_io() into two I did that myself too, since Dave sees this during boot. But I'm not getting

Re: bio linked list corruption.

On Wed, Oct 26, 2016 at 3:40 PM, Dave Jones wrote: > > I gave it a shot too for shits & giggles. > This falls out during boot. > > [9.278420] WARNING: CPU: 0 PID: 1 at block/blk-mq.c:1181 > blk_sq_make_request+0x465/0x4a0 Hmm. That's the WARN_ON_ONCE(rq->mq_ctx

Re: bio linked list corruption.

On Wed, Oct 26, 2016 at 2:52 PM, Chris Mason wrote: > > This one is special because CONFIG_VMAP_STACK is not set. Btrfs triggers in > < 10 minutes. > I've done 30 minutes each with XFS and Ext4 without luck. Ok, see the email I wrote that crossed yours - if it's really some list

Re: bio linked list corruption.

On Wed, Oct 26, 2016 at 1:00 PM, Chris Mason wrote: > > Today I turned off every CONFIG_DEBUG_* except for list debugging, and > ran dbench 2048: > > [ 2759.118711] WARNING: CPU: 2 PID: 31039 at lib/list_debug.c:33 > __list_add+0xbe/0xd0 > [ 2759.119652] list_add corruption.

Re: bio linked list corruption.

On Wed, Oct 26, 2016 at 11:42 AM, Dave Jones wrote: > > The stacks show nearly all of them are stuck in sync_inodes_sb That's just wb_wait_for_completion(), and it means that some IO isn't completing. There's also a lot of processes waiting for inode_lock(), and a few

Re: bio linked list corruption.

On Wed, Oct 26, 2016 at 9:30 AM, Dave Jones wrote: > > I gave this a go last thing last night. It crashed within 5 minutes, > but it was one we've already seen (the bad page map trace) with nothing > additional that looked interesting. Did the bad page map trace have any

Re: bio linked list corruption.

On Tue, Oct 25, 2016 at 6:33 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > Completely untested. Maybe there's some reason we can't write to the > whole thing like that? That hack boots and seems to work for me, but doesn't show anything. Dave, mind just tryin

Re: bio linked list corruption.

On Tue, Oct 25, 2016 at 5:27 PM, Dave Jones wrote: > > DaveC: Do these look like real problems, or is this more "looks like > random memory corruption" ? It's been a while since I did some stress > testing on XFS, so these might not be new.. Andy, do you think we could

Re: bio linked list corruption.

On Mon, Oct 24, 2016 at 3:42 PM, Andy Lutomirski wrote: > > Here's my theory: I think you're looking at the right code but the > wrong stack. shmem_fault_wait is fine, but shmem_fault_waitq looks > really dicey. Hmm. > Consider: > > fallocate calls wake_up_all(), which

Re: bio linked list corruption.

On Mon, Oct 24, 2016 at 2:17 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > The vmalloc/vfree code itself is a bit scary. In particular, we have a > rather insane model of TLB flushing. We leave the virtual area on a > lazy purge-list, and we delay flushing th

Re: bio linked list corruption.

On Mon, Oct 24, 2016 at 1:46 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > So this is all some really subtle code, but I'm not seeing that it > would be wrong. Ahh... Except maybe.. The vmalloc/vfree code itself is a bit scary. In particular, we have a rather insa

Re: bio linked list corruption.

On Mon, Oct 24, 2016 at 1:06 PM, Andy Lutomirski wrote: >> >> [69943.450108] Oops: 0003 [#1] PREEMPT SMP DEBUG_PAGEALLOC > > This is an unhandled kernel page fault. The string "Oops" is so helpful :-/ I think there was a line above it that DaveJ just didn't include. > >>

Re: bio linked list corruption.

On Wed, Oct 19, 2016 at 10:09 AM, Philipp Hahn wrote: > > Nearly a month ago I reported also a "list_add corruption", but with 4.1.6: > > > That server rungs Samba4, which also is a heavy user of xattr. That one looks very

Re: bio linked list corruption.

On Tue, Oct 18, 2016 at 5:10 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > Adding Andy to the cc, because this *might* be triggered by the > vmalloc stack code itself. Maybe the re-use of stacks showing some > problem? Maybe Chris (who can't see the pro

Re: bio linked list corruption.

On Tue, Oct 18, 2016 at 4:42 PM, Chris Mason wrote: > > Seems to be the whole thing: Ahh. On lkml, so I do have it in my mailbox, but Dave changed the subject line when he tested on ext4 rather than btrfs.. Anyway, the corrupted address is somewhat interesting. As Dave Jones said,

Re: bio linked list corruption.

On Tue, Oct 18, 2016 at 4:31 PM, Chris Mason wrote: > > Jens, not sure if you saw the whole thread. This has triggered bad page > state errors, and also corrupted a btrfs list. It hurts me to say, but it > might not actually be your fault. Where is that thread, and what is the

Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

On Tue, Aug 9, 2016 at 10:39 PM, kernel test robot wrote: > > [ 1537.558739] nfsd: last server has exited, flushing export cache > [ 1540.627795] BUG: Dentry 880027d7c540{i=1846f,n=0a} still in use (1) > [unmount of btrfs vda] > [ 1540.633915] [ cut here

Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

On Wed, Aug 10, 2016 at 11:22 AM, Josef Bacik <jba...@fb.com> wrote: > On 08/10/2016 02:06 PM, Linus Torvalds wrote: >> >> More information in the original email on lkml. > > I'm not subscribed to lkml and for some reason I can't find the original > email in any

Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

On Wed, Aug 10, 2016 at 11:46 AM, Josef Bacik wrote: > > So my naive fix would be something like this Bruce? Josef's patch looks ObviouslyCorrect(tm) to me now that I look at it - all the other callers of fh_compose() also seem to just drop the dentry unconditionally, knowing that

Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

On Wed, Aug 10, 2016 at 12:09 PM, J. Bruce Fields wrote: > > OK with me if you want to take it, otherwise I'll run it through my > usual tests and send you a pull request probably today or tomorrow. I'll let it go through your tree and your usual tests - it's not like this

Re: [lkp] [dm flakey] 99f3c90d0d: WARNING: CPU: 20 PID: 1027 at fs/btrfs/extent-tree.c:2973 btrfs_run_delayed_refs+0x2c5/0x2f0 [btrfs]

This report should probably have gone to the btrfs people, although it doesn't really look like a bug. It looks like it's just dm-flakey now returning more errors, and causing btrfs to complain more. Which seems entirely expected. Maybe the robot just was testing a error case that didn't

Re: [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

On Sun, Jun 19, 2016 at 5:26 PM, Deepa Dinamani wrote: > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > macros. This version now looks ok to me. I do have a comment (or maybe just a RFD) for future work. It does strike me that once we

Re: [GIT PULL] Btrfs

On Mon, Mar 21, 2016 at 7:24 PM, Chris Mason wrote: > > Hmmm, rereading my answer I realized I didn't actually answer. I really > think this is fixed. I left the warning only because I originally > expected something much more exotic. Ok. It's more that you said the top commit

Re: [GIT PULL] Btrfs

On Mon, Mar 21, 2016 at 5:24 PM, Chris Mason wrote: > > I waited an extra day to send this one out because I hit a crash late > last week with CONFIG_DEBUG_PAGEALLOC enabled (fixed in the top commit). Hmm. If that commit helps, it will spit out a warning. So is it actually fixed,

Re: [GIT PULL] Btrfs for 3.19-rc

On Fri, Dec 12, 2014 at 11:07 AM, Chris Mason c...@fb.com wrote: From a feature point of view, most of the code here comes from Miao Xie and others at Fujitsu to implement scrubbing and replacing devices on raid56. This has been in development for a while, and it's a big improvement. So

Re: [PATCH v3 11/12] security, crypto: LLVMLinux: Remove VLAIS from ima_crypto.c

On Mon, Sep 15, 2014 at 12:30 AM, beh...@converseincode.com wrote: From: Behan Webster beh...@converseincode.com Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This patch allocates the appropriate amount of memory using a char array using the

Re: [GIT PULL] Smaller btrfs pull

On Fri, Aug 15, 2014 at 11:26 AM, Chris Mason c...@fb.com wrote: I've been running xfstests with these against your current git overnight, but I'm queueing up longer tests as well. I understand you may want to wait until rc2, but either way I'll get a sane queue into my linux-next branch for

Re: [GIT PULL] Btrfs

On Thu, Aug 14, 2014 at 11:59 AM, Chris Mason c...@fb.com wrote: Hi Linus, Please pull my for-linus branch: Yeah, I think this will be for the next merge window. This clearly got rebased today. At the end of the merge window. After I told people that I was traveling, and asked people to send

Re: [GIT PULL] Btrfs Maintainer update

On Thu, Dec 5, 2013 at 10:19 AM, Chris Mason c...@fb.com wrote: I had used git commit -S instead of signing the tag. Ahh. And that was actually what you had done the first time around for your test too - but back then I didn't actually *merge* it. Then I just looked at the top commit and said

Re: [GIT PULL] Btrfs

On Sat, Mar 2, 2013 at 7:15 AM, Chris Mason chris.ma...@fusionio.com wrote: Our set of btrfs features, fixes and cleanups are in my for-linus branch: I *really* wish that big pull requests like this would come in earlier in the merge window. I hate seeing them the day before I close the window

Re: [GIT PULL] Btrfs fixes

On Thu, Jan 24, 2013 at 1:52 PM, Chris Mason chris.ma...@fusionio.com wrote: Update on this, we've tracked down the crc errors and are doing final checks on the patches. Linus are you planning on taking this pull? If not I can just fold the new stuff into a bigger request. If you have them

Re: [GIT PULL 1/2] Btrfs fixes

On Mon, Aug 20, 2012 at 6:53 PM, Chris Samuel ch...@csamuel.org wrote: This pull request with a whole heap of btrfs fixes (46 commits) appears not to have been merged yet, does anyone know if it was rejected or just missed ? Read my -rc2 release notes. TL;DR: I rejected big pull requests

Re: [GIT PULL] a large btrfs update

On Thu, Jul 26, 2012 at 2:09 PM, Chris Mason chris.ma...@fusionio.com wrote: for-linus-merged has an extra commit on top as well that changes the btrfs send/receive code to Al's new dentry_open. It's a small commit, and my guess is that you'll cherry pick it and do your own merge. Indeed.

Re: [GIT PULL] Btrfs updates

On Fri, Jun 15, 2012 at 11:09 AM, Chris Mason chris.ma...@fusionio.com wrote: Please pull my for-linus branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus This seems to introduce a new warning: In file included from fs/btrfs/ctree.c:22:0:

Re: [RFC, PATCH] fs: push rcu_barrier() from deactivate_locked_super() to filesystems

On Fri, Jun 8, 2012 at 3:00 PM, Kirill A. Shutemov kirill.shute...@linux.intel.com wrote: IIUC, moving rcu_barrier() up should help, but I can't say that I fully understand SLAB_DESTROY_BY_RCU semantics. .. hmm. I think you may be right. Even if we do move it up, we probably shouldn't use it.

Re: [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked_super() to filesystems

On Fri, Jun 8, 2012 at 3:23 PM, Al Viro v...@zeniv.linux.org.uk wrote: Note that module unload is *not* a hot path - not on any even remotely sane use. Actually, I think we've had distributions that basically did a load pretty much everything, and let God sort it out approach to modules. I

Re: [RFC, PATCH, RESEND] fs: push rcu_barrier() from deactivate_locked_super() to filesystems

On Fri, Jun 8, 2012 at 4:37 PM, Andrew Morton a...@linux-foundation.org wrote: So how about open-coding the rcu_barrier() in btrfs and gfs2 for the non-inode caches (which is the appropriate place), and hand the inode cache over to the vfs for treatment (which is the appropriate place). The

Re: [GIT PULL] Btrfs fixes and features

On Fri, Mar 30, 2012 at 10:51 AM, Chris Mason chris.ma...@oracle.com wrote: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus This causes a new warning for me: fs/btrfs/extent_io.c: In function ‘repair_eb_io_failure’: fs/btrfs/extent_io.c:1940:6: warning: ‘ret’

Re: [GIT PULL] Btrfs fixes and features

On Fri, Mar 30, 2012 at 12:50 PM, Linus Torvalds torva...@linux-foundation.org wrote: This causes a new warning for me:  fs/btrfs/extent_io.c: In function ‘repair_eb_io_failure’:  fs/btrfs/extent_io.c:1940:6: warning: ‘ret’ may be used uninitialized in this function Hmm? Ok, so presumably

Re: [PATCH v2] Btrfs: use do_div to avoid compile errors on 32bit box

On Sat, Aug 20, 2011 at 5:21 AM, Josef Bacik jo...@redhat.com wrote: I think Linus was less complaining about how you're dividing here and more about the fact that you are.  A divide by 2 is the same as a 1.  I'll send a patch to fix this.  Thanks, Indeed. A single-bit 64-bit double shift

Re: [GIT PULL] Btrfs updates

On Sun, Jun 12, 2011 at 4:57 AM, Chris Mason chris.ma...@oracle.com wrote: The for-linus branch of the btrfs unstable tree: Chris, this is getting ridiculous. You guys need to start honoring the merge window. None of these big pulls afterwards. If the code wasn't ready, it damn well shouldn't

Re: [GIT PULL] Btrfs updates for 2.6.39

On Mon, Mar 28, 2011 at 5:08 AM, Chris Mason chris.ma...@oracle.com wrote: Linus, I've pushed out two branches for you, for-linus and for-linus-unmerged Thanks. I took the unmerged one, because I do like to see what's going on. But I did end up verifying the end result against your merge, and

Re: [PATCH 2/2] mutex: Apply adaptive spinning on mutex_trylock()

On Thu, Mar 24, 2011 at 8:39 PM, Steven Rostedt rost...@goodmis.org wrote: But now, mutex_trylock(B) becomes a spinner too, and since the B's owner is running (spinning on A) it will spin as well waiting for A's owner to release it. Unfortunately, A's owner is also spinning waiting for B to

Re: [RFC PATCH] mutex: Apply adaptive spinning on mutex_trylock()

On Wed, Mar 23, 2011 at 8:37 AM, Tejun Heo t...@kernel.org wrote: Currently, mutex_trylock() doesn't use adaptive spinning.  It tries just once.  I got curious whether using adaptive spinning on mutex_trylock() would be beneficial and it seems so, at least for btrfs anyway. Hmm. Seems

Re: [GIT PULL] Btrfs updates for 2.6.37

On Sat, Oct 30, 2010 at 6:51 AM, Chris Mason chris.ma...@oracle.com wrote: There were some minor conflicts with Linus' current tree, so my branch is merged with Linus' tree as of this morning. Gaah. Please don't do this. Unless it's a _really_ messy merge, I really do want to do the merge.

Re: [GIT PULL] Btrfs updates for 2.6.35

On Fri, Jun 11, 2010 at 12:37 PM, Chris Mason chris.ma...@oracle.com wrote: The master branch of the btrfs-unstable tree is a collection of fixes and cleanups, including two btrfs regressions from rc1: Ok, no pulling then. See all the millions of threads how I wanted only critical fixes for

Re: [GIT PULL] Btrfs updates for 2.6.35

On Fri, Jun 11, 2010 at 12:48 PM, Chris Mason chris.ma...@oracle.com wrote: The others all fix oopsen or big problems, and I think fixing warnings helps avoid false negatives as others look for real problems? I'm happy to rebase out the 3 non-criticals. There seems to be more than three

Re: [GIT PULL] Btrfs updates

On Thu, 27 May 2010, Chris Mason wrote: fs/btrfs/extent-tree.c | 2317 fs/btrfs/relocation.c | 1991 + fs/btrfs/inode.c| 1797 + fs/btrfs/file.c

Re: [GIT PULL] Btrfs updates

On Thu, 27 May 2010, Chris Mason wrote: # git diff v2.6.34 HEAD | diffstat That still has the potential to be wrong (but got the numbers I expected this time). It will be wrong in several cases: - diffstat has some random common prefix removal logic that I've never figured out the

  1   2   >