1. 15 Jan, 2015 1 commit
  2. 12 Jan, 2015 31 commits
  3. 05 Jan, 2015 8 commits
    • Josef Bacik's avatar
      Btrfs: do not move em to modified list when unpinning · 736ba53d
      Josef Bacik authored
      commit a2804695 upstream.
      
      We use the modified list to keep track of which extents have been modified so we
      know which ones are candidates for logging at fsync() time.  Newly modified
      extents are added to the list at modification time, around the same time the
      ordered extent is created.  We do this so that we don't have to wait for ordered
      extents to complete before we know what we need to log.  The problem is when
      something like this happens
      
      log extent 0-4k on inode 1
      copy csum for 0-4k from ordered extent into log
      sync log
      commit transaction
      log some other extent on inode 1
      ordered extent for 0-4k completes and adds itself onto modified list again
      log changed extents
      see ordered extent for 0-4k has already been logged
      	at this point we assume the csum has been copied
      sync log
      crash
      
      On replay we will see the extent 0-4k in the log, drop the original 0-4k extent
      which is the same one that we are replaying which also drops the csum, and then
      we won't find the csum in the log for that bytenr.  This of course causes us to
      have errors about not having csums for certain ranges of our inode.  So remove
      the modified list manipulation in unpin_extent_cache, any modified extents
      should have been added well before now, and we don't want them re-logged.  This
      fixes my test that I could reliably reproduce this problem with.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      736ba53d
    • Josef Bacik's avatar
      Btrfs: make sure logged extents complete in the current transaction V3 · d02ab1a9
      Josef Bacik authored
      commit 50d9aa99 upstream.
      
      Liu Bo pointed out that my previous fix would lose the generation update in the
      scenario I described.  It is actually much worse than that, we could lose the
      entire extent if we lose power right after the transaction commits.  Consider
      the following
      
      write extent 0-4k
      log extent in log tree
      commit transaction
      	< power fail happens here
      ordered extent completes
      
      We would lose the 0-4k extent because it hasn't updated the actual fs tree, and
      the transaction commit will reset the log so it isn't replayed.  If we lose
      power before the transaction commit we are save, otherwise we are not.
      
      Fix this by keeping track of all extents we logged in this transaction.  Then
      when we go to commit the transaction make sure we wait for all of those ordered
      extents to complete before proceeding.  This will make sure that if we lose
      power after the transaction commit we still have our data.  This also fixes the
      problem of the improperly updated extent generation.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d02ab1a9
    • Josef Bacik's avatar
      Btrfs: make sure we wait on logged extents when fsycning two subvols · acce1ec2
      Josef Bacik authored
      commit 9dba8cf1 upstream.
      
      If we have two fsync()'s race on different subvols one will do all of its work
      to get into the log_tree, wait on it's outstanding IO, and then allow the
      log_tree to finish it's commit.  The problem is we were just free'ing that
      subvols logged extents instead of waiting on them, so whoever lost the race
      wouldn't really have their data on disk.  Fix this by waiting properly instead
      of freeing the logged extents.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      acce1ec2
    • Ronald Wahl's avatar
      usb: gadget: at91_udc: move prepare clk into process context · 97863cb8
      Ronald Wahl authored
      commit b2ba27a5 upstream.
      
      Commit 76280832 (usb: gadget: at91_udc:
      prepare clk before calling enable) added clock preparation in interrupt
      context. This is not allowed as it might sleep. Also setting the clock
      rate is unsafe to call from there for the same reason. Move clock
      preparation and setting clock rate into process context (at91udc_probe).
      Signed-off-by: default avatarRonald Wahl <ronald.wahl@raritan.com>
      Acked-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Acked-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Felipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      97863cb8
    • Alex Deucher's avatar
      drm/radeon: work around a hw bug in MGCG on CIK · 1e6ce3b8
      Alex Deucher authored
      commit 4bb62c95 upstream.
      
      Always need to set bit 0 of RLC_CGTT_MGCG_OVERRIDE
      to avoid unreliable doorbell updates in some cases.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1e6ce3b8
    • Lars-Peter Clausen's avatar
      ASoC: sigmadsp: Refuse to load firmware files with a non-supported version · 17a29b83
      Lars-Peter Clausen authored
      commit 50c0f21b upstream.
      
      Make sure to check the version field of the firmware header to make sure to
      not accidentally try to parse a firmware file with a different layout.
      Trying to do so can result in loading invalid firmware code to the device.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      17a29b83
    • Tetsuo Handa's avatar
      drm/ttm: Avoid memory allocation from shrinker functions. · bf6132b5
      Tetsuo Handa authored
      commit 881fdaa5 upstream.
      
      Andrew Morton wrote:
      > On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
      >
      > > Andrew Morton wrote:
      > > > Poor ttm guys - this is a bit of a trap we set for them.
      > >
      > > Commit a91576d7 ("drm/ttm: Pass GFP flags in order to avoid deadlock.")
      > > changed to use sc->gfp_mask rather than GFP_KERNEL.
      > >
      > > -       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
      > > -                       GFP_KERNEL);
      > > +       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
      > >
      > > But this bug is caused by sc->gfp_mask containing some flags which are not
      > > in GFP_KERNEL, right? Then, I think
      > >
      > > -       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
      > > +       pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp & GFP_KERNEL);
      > >
      > > would hide this bug.
      > >
      > > But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag)
      >
      > Well no - ttm_page_pool_free() should stop calling kmalloc altogether.
      > Just do
      >
      > 	struct page *pages_to_free[16];
      >
      > and rework the code to free 16 pages at a time.  Easy.
      
      Well, ttm code wants to process 512 pages at a time for performance.
      Memory footprint increased by 512 * sizeof(struct page *) buffer is
      only 4096 bytes. What about using static buffer like below?
      ----------
      >From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001
      From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Date: Thu, 13 Nov 2014 22:21:54 +0900
      Subject: [PATCH] drm/ttm: Avoid memory allocation from shrinker functions.
      
      Commit a91576d7 ("drm/ttm: Pass GFP flags in order to avoid
      deadlock.") caused BUG_ON() due to sc->gfp_mask containing flags
      which are not in GFP_KERNEL.
      
        https://bugzilla.kernel.org/show_bug.cgi?id=87891
      
      Changing from sc->gfp_mask to (sc->gfp_mask & GFP_KERNEL) would
      avoid the BUG_ON(), but avoiding memory allocation from shrinker
      function is better and reliable fix.
      
      Shrinker function is already serialized by global lock, and
      clean up function is called after shrinker function is unregistered.
      Thus, we can use static buffer when called from shrinker function
      and clean up function.
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      bf6132b5
    • Steven Rostedt (Red Hat)'s avatar
      ftrace/x86: Add frames pointers to trampoline as necessary · f79290b6
      Steven Rostedt (Red Hat) authored
      commit 9960efeb upstream.
      
      When CONFIG_FRAME_POINTERS are enabled, it is required that the
      ftrace_caller and ftrace_regs_caller trampolines set up frame pointers
      otherwise a stack trace from a function call wont print the functions
      that called the trampoline. This is due to a check in
      __save_stack_address():
      
       #ifdef CONFIG_FRAME_POINTER
      	if (!reliable)
      		return;
       #endif
      
      The "reliable" variable is only set if the function address is equal to
      contents of the address before the address the frame pointer register
      points to. If the frame pointer is not set up for the ftrace caller
      then this will fail the reliable test. It will miss the function that
      called the trampoline. Worse yet, if fentry is used (gcc 4.6 and
      beyond), it will also miss the parent, as the fentry is called before
      the stack frame is set up. That means the bp frame pointer points
      to the stack of just before the parent function was called.
      
      Link: http://lkml.kernel.org/r/20141119034829.355440340@goodmis.org
      
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f79290b6