Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Jul 01, 2016
  3. Jun 28, 2016
  5. Jun 27, 2016
  7. Jun 26, 2016
    • Arnd Bergmann's avatar
      arm64: simplify dma_get_ops · ecda003d
      Arnd Bergmann authored 
      
Including linux/acpi.h from asm/dma-mapping.h causes tons of compile-time
warnings, e.g.

 drivers/isdn/mISDN/dsp_ecdis.h:43:0: warning: "FALSE" redefined
 drivers/isdn/mISDN/dsp_ecdis.h:44:0: warning: "TRUE" redefined
 drivers/net/fddi/skfp/h/targetos.h:62:0: warning: "TRUE" redefined
 drivers/net/fddi/skfp/h/targetos.h:63:0: warning: "FALSE" redefined

However, it looks like the dependency should not even there as
I do not see why __generic_dma_ops() cares about whether we have
an ACPI based system or not.

The current behavior is to fall back to the global dma_ops when
a device has not set its own dma_ops, but only for DT based systems.
This seems dangerous, as a random device might have different
requirements regarding IOMMU or coherency, so we should really
never have that fallback and just forbid DMA when we have not
initialized DMA for a device.

This removes the global dma_ops variable and the special-casing
for ACPI, and just returns the dma ops that got set for the
device, or the dummy_dma_ops if none were present.

The original code has apparently been copied from arm32 where we
rely on it for ISA devices things like the floppy controller, but
we should have no such devices on ARM64.

Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
[catalin.marinas@arm.com: removed acpi_disabled check in arch_setup_dma_ops()]
Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>

(cherry picked from commit 1dccb598

)
Signed-off-by: default avatarAlex Shi <alex.shi@linaro.org>
      ecda003d
  9. Jun 24, 2016
    • Alex Shi's avatar
      Merge branch 'v4.1/topic/writeback-cg' into linux-linaro-lsk-v4.1 · 201b6f2a
      Alex Shi authored
      201b6f2a
    • Peter Zijlstra's avatar
      jump_label/x86: Work around asm build bug on older/backported GCCs · 46cb70a5
      Peter Zijlstra authored 
      Boris reported that gcc version 4.4.4 20100503 (Red Hat
4.4.4-2) fails to build linux-next kernels that have
this fresh commit via the locking tree:

  11276d53

 ("locking/static_keys: Add a new static_key interface")

The problem appears to be that even though @key and @branch are
compile time constants, it doesn't see the following expression
as an immediate value:

   &((char *)key)[branch]

More recent GCCs don't appear to have this problem.

In particular, Red Hat backported the 'asm goto' feature into 4.4,
'normal' 4.4 compilers will not have this feature and thus not
run into this asm.

The workaround is to supply both values to the asm as immediates
and do the addition in asm.

Suggested-by: default avatarH. Peter Anvin <hpa@zytor.com>
Reported-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
Tested-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
(cherry picked from commit d420acd8

)
Signed-off-by: default avatarAlex Shi <alex.shi@linaro.org>
      46cb70a5
    • Tejun Heo's avatar
      blkcg: fix incorrect read/write sync/async stat accounting · 44069b08
      Tejun Heo authored 
      While unifying how blkcg stats are collected, 77ea7338

 ("blkcg:
move io_service_bytes and io_serviced stats into blkcg_gq")
incorrectly used bio->flags instead of bio->rw to tell the IO type.
This made IOs to be accounted as the wrong type.  Fix it.

Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Fixes: 77ea7338

 ("blkcg: move io_service_bytes and io_serviced stats into blkcg_gq")
Reviewed-by: default avatarJeff Moyer <jmoyer@redhat.com>
Signed-off-by: default avatarJens Axboe <axboe@fb.com>
(cherry picked from commit 174fd8d3

)
Signed-off-by: default avatarAlex Shi <alex.shi@linaro.org>
      44069b08
    • Kees Cook's avatar
      cgroup: fix seq_show_option merge with legacy_name · 8a5f8dc0
      Kees Cook authored 
      When seq_show_option (commit a068acf2: "fs: create and use
seq_show_option for escaping") was merged, it did not correctly collide
with cgroup's addition of legacy_name (commit 3e1d2eed

: "cgroup:
introduce cgroup_subsys->legacy_name") changes.

This fixes the reported name.

Signed-off-by: default avatarKees Cook <keescook@chromium.org>
Acked-by: default avatarTejun Heo <tj@kernel.org>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 61e57c0c

)
Signed-off-by: default avatarAlex Shi <alex.shi@linaro.org>
      8a5f8dc0
    • Linus Torvalds's avatar
      Revert "writeback: plug writeback at a high level" · b39b4806
      Linus Torvalds authored 
      This reverts commit d353d758

.

Doing the block layer plug/unplug inside writeback_sb_inodes() is
broken, because that function is actually called with a spinlock held:
wb->list_lock, as pointed out by Chris Mason.

Chris suggested just dropping and re-taking the spinlock around the
blk_finish_plug() call (the plgging itself can happen under the
spinlock), and that would technically work, but is just disgusting.

We do something fairly similar - but not quite as disgusting because we
at least have a better reason for it - in writeback_single_inode(), so
it's not like the caller can depend on the lock being held over the
call, but in this case there just isn't any good reason for that
"release and re-take the lock" pattern.

[ In general, we should really strive to avoid the "release and retake"
  pattern for locks, because in the general case it can easily cause
  subtle bugs when the caller caches any state around the call that
  might be invalidated by dropping the lock even just temporarily. ]

But in this case, the plugging should be easy to just move up to the
callers before the spinlock is taken, which should even improve the
effectiveness of the plug.  So there is really no good reason to play
games with locking here.

I'll send off a test-patch so that Dave Chinner can verify that that
plug movement works.  In the meantime this just reverts the problematic
commit and adds a comment to the function so that we hopefully don't
make this mistake again.

Reported-by: default avatarChris Mason <clm@fb.com>
Cc: Josef Bacik <jbacik@fb.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Neil Brown <neilb@suse.de>
Cc: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 0ba13fd1

)
Signed-off-by: default avatarAlex Shi <alex.shi@linaro.org>
      b39b4806
    • Tejun Heo's avatar
      block: don't release bdi while request_queue has live references · 9c580658
      Tejun Heo authored 
      bdi's are initialized in two steps, bdi_init() and bdi_register(), but
destroyed in a single step by bdi_destroy() which, for a bdi embedded
in a request_queue, is called during blk_cleanup_queue() which makes
the queue invisible and starts the draining of remaining usages.

A request_queue's user can access the congestion state of the embedded
bdi as long as it holds a reference to the queue.  As such, it may
access the congested state of a queue which finished
blk_cleanup_queue() but hasn't reached blk_release_queue() yet.
Because the congested state was embedded in backing_dev_info which in
turn is embedded in request_queue, accessing the congested state after
bdi_destroy() was called was fine.  The bdi was destroyed but the
memory region for the congested state remained accessible till the
queue got released.

a13f35e8

 ("writeback: don't embed root bdi_writeback_congested in
bdi_writeback") changed the situation.  Now, the root congested state
which is expected to be pinned while request_queue remains accessible
is separately reference counted and the base ref is put during
bdi_destroy().  This means that the root congested state may go away
prematurely while the queue is between bdi_dstroy() and
blk_cleanup_queue(), which was detected by Andrey's KASAN tests.

The root cause of this problem is that bdi doesn't distinguish the two
steps of destruction, unregistration and release, and now the root
congested state actually requires a separate release step.  To fix the
issue, this patch separates out bdi_unregister() and bdi_exit() from
bdi_destroy().  bdi_unregister() is called from blk_cleanup_queue()
and bdi_exit() from blk_release_queue().  bdi_destroy() is now just a
simple wrapper calling the two steps back-to-back.

While at it, the prototype of bdi_destroy() is moved right below
bdi_setup_and_register() so that the counterpart operations are
located together.

Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Fixes: a13f35e8

 ("writeback: don't embed root bdi_writeback_congested in bdi_writeback")
Cc: stable@vger.kernel.org # v4.2+
Reported-and-tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
Link: http://lkml.kernel.org/g/CAAeHK+zUJ74Zn17=rOyxacHU18SgCfC6bsYW=6kCY5GXJBwGfQ@mail.gmail.com


Reviewed-by: default avatarJan Kara <jack@suse.com>
Reviewed-by: default avatarJeff Moyer <jmoyer@redhat.com>
Signed-off-by: default avatarJens Axboe <axboe@fb.com>
(cherry picked from commit b02176f3

)
Signed-off-by: default avatarAlex Shi <alex.shi@linaro.org>

Conflicts:
	remove old define bdi_unregister() in mm/backing-dev.c
      9c580658
    • Tejun Heo's avatar
      writeback, cgroup: fix use of the wrong bdi_writeback which mismatches the inode · 77b973d3
      Tejun Heo authored 
      
When cgroup writeback is in use, there can be multiple wb's
(bdi_writeback's) per bdi and an inode may switch among them
dynamically.  In a couple places, the wrong wb was used leading to
performing operations on the wrong list under the wrong lock
corrupting the io lists.

* writeback_single_inode() was taking @wb parameter and used it to
  remove the inode from io lists if it becomes clean after writeback.
  The callers of this function were always passing in the root wb
  regardless of the actual wb that the inode was associated with,
  which could also change while writeback is in progress.

  Fix it by dropping the @wb parameter and using
  inode_to_wb_and_lock_list() to determine and lock the associated wb.

* After writeback_sb_inodes() writes out an inode, it re-locks @wb and
  inode to remove it from or move it to the right io list.  It assumes
  that the inode is still associated with @wb; however, the inode may
  have switched to another wb while writeback was in progress.

  Fix it by using inode_to_wb_and_lock_list() to determine and lock
  the associated wb after writeback is complete.  As the function
  requires the original @wb->list_lock locked for the next iteration,
  in the unlikely case where the inode has changed association, switch
  the locks.

Kudos to Tahsin for pinpointing these subtle breakages.

Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Fixes: d10c8095 ("writeback: implement foreign cgroup inode bdi_writeback switching")
Link: http://lkml.kernel.org/g/CAAeU0aMYeM_39Y2+PaRvyB1nqAPYZSNngJ1eBRmrxn7gKAt2Mg@mail.gmail.com


Reported-and-diagnosed-by: default avatarTahsin Erdogan <tahsin@google.com>
Tested-by: default avatarTahsin Erdogan <tahsin@google.com>
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: default avatarJens Axboe <axboe@fb.com>
(cherry picked from commit aaf25593

)
Signed-off-by: default avatarAlex Shi <alex.shi@linaro.org>
      77b973d3
    • Tejun Heo's avatar
      writeback, cgroup: fix premature wb_put() in locked_inode_to_wb_and_lock_list() · 986acce6
      Tejun Heo authored 
      
locked_inode_to_wb_and_lock_list() wb_get()'s the wb associated with
the target inode, unlocks inode, locks the wb's list_lock and verifies
that the inode is still associated with the wb.  To prevent the wb
going away between dropping inode lock and acquiring list_lock, the wb
is pinned while inode lock is held.  The wb reference is put right
after acquiring list_lock citing that the wb won't be dereferenced
anymore.

This isn't true.  If the inode is still associated with the wb, the
inode has reference and it's safe to return the wb; however, if inode
has been switched, the wb still needs to be unlocked which is a
dereference and can lead to use-after-free if it it races with wb
destruction.

Fix it by putting the reference after releasing list_lock.

Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Fixes: 87e1d789

 ("writeback: implement [locked_]inode_to_wb_and_lock_list()")
Cc: stable@vger.kernel.org # v4.2+
Tested-by: default avatarTahsin Erdogan <tahsin@google.com>
Signed-off-by: default avatarJens Axboe <axboe@fb.com>
(cherry picked from commit 614a4e37

)
Signed-off-by: default avatarAlex Shi <alex.shi@linaro.org>
      986acce6
    • Tejun Heo's avatar
      writeback: use higher precision calculation in domain_dirty_limits() · a5d1b396
      Tejun Heo authored 
      
As vm.dirty_[background_]bytes can't be applied verbatim to multiple
cgroup writeback domains, they get converted to percentages in
domain_dirty_limits() and applied the same way as
vm.dirty_[background]ratio.  However, if the specified bytes is lower
than 1% of available memory, the calculated ratios become zero and the
writeback domain gets throttled constantly.

Fix it by using per-PAGE_SIZE instead of percentage for ratio
calculations.  Also, the updated DIV_ROUND_UP() usages now should
yield 1/4096 (0.0244%) as the minimum ratio as long as the specified
bytes are above zero.

Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Reported-by: default avatarMiao Xie <miaoxie@huawei.com>
Link: http://lkml.kernel.org/g/57333E75.3080309@huawei.com
Cc: stable@vger.kernel.org # v4.2+
Fixes: 9fc3a43e

 ("writeback: separate out domain_dirty_limits()")
Reviewed-by: default avatarJan Kara <jack@suse.cz>

Adjusted comment based on Jan's suggestion.
Signed-off-by: default avatarJens Axboe <axboe@fb.com>

(cherry picked from commit 62a584fe

)
Signed-off-by: default avatarAlex Shi <alex.shi@linaro.org>
      a5d1b396
    • Greg Thelen's avatar
      memcg: remove pcp_counter_lock · e90ea859
      Greg Thelen authored 
      Commit 733a572e

 ("memcg: make mem_cgroup_read_{stat|event}() iterate
possible cpus instead of online") removed the last use of the per memcg
pcp_counter_lock but forgot to remove the variable.

Kill the vestigial variable.

Signed-off-by: default avatarGreg Thelen <gthelen@google.com>
Acked-by: default avatarMichal Hocko <mhocko@suse.com>
Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit ef510194

)
Signed-off-by: default avatarAlex Shi <alex.shi@linaro.org>
      e90ea859
    • Geert Uytterhoeven's avatar
      bdi: Remove "inline" keyword from exported I_BDEV() implementation · 42616c8e
      Geert Uytterhoeven authored 
      With gcc 3.4.6/4.1.2/4.2.4 (not with 4.4.7/4.6.4/4.8.4):

      CC      fs/block_dev.o
    include/linux/fs.h:804: warning: ‘I_BDEV’ declared inline after being called
    include/linux/fs.h:804: warning: previous declaration of ‘I_BDEV’ was here

Commit a212b105

 ("bdi: make inode_to_bdi() inline") added a
caller of I_BDEV() in a header file, exposing the bogus "inline" on the
exported implementation.

Drop the "inline" keyword to fix this.

Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: default avatarJens Axboe <axboe@fb.com>
(cherry picked from commit ff5053f6

)
Signed-off-by: default avatarAlex Shi <alex.shi@linaro.org>
      42616c8e
  11. Jun 22, 2016
  13. Jun 18, 2016

Open hardware computers for makers, educators and professionals