Skip to content

L
linux
Switch branch/tag
  1. 10 Jan, 2015 21 commits
  3. 09 Jan, 2015 19 commits
    • Cong Wang's avatar
      freezer: Do not freeze tasks killed by OOM killer · 778de0ed
      Cong Wang authored 
      Since f660daac (oom: thaw threads if oom killed thread is frozen
before deferring) OOM killer relies on being able to thaw a frozen task
to handle OOM situation but a3201227 (freezer: make freezing() test
freeze conditions in effect instead of TIF_FREEZE) has reorganized the
code and stopped clearing freeze flag in __thaw_task. This means that
the target task only wakes up and goes into the fridge again because the
freezing condition hasn't changed for it. This reintroduces the bug
fixed by f660daac.

Fix the issue by checking for TIF_MEMDIE thread flag in
freezing_slow_path and exclude the task from freezing completely. If a
task was already frozen it would get woken by __thaw_task from OOM killer
and get out of freezer after rechecking freezing().

Changes since v1
- put TIF_MEMDIE check into freezing_slowpath rather than in __refrigerator
  as per Oleg
- return __thaw_task into oom_scan_process_thread because
  oom_kill_process will not wake task in the fridge because it is
  sleeping uninterruptible

[mhocko@suse.cz: rewrote the changelog]
Fixes: a3201227 (freezer: make freezing() test freeze conditions in effect instead of TIF_FREEZE)
Cc: 3.3+ <stable@vger.kernel.org> # 3.3+
Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: default avatarMichal Hocko <mhocko@suse.cz>
Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>

(cherry picked from commit 51fae6da)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      778de0ed
    • Eric W. Biederman's avatar
      userns: Don't allow unprivileged creation of gid mappings · 867662d6
      Eric W. Biederman authored 
      As any gid mapping will allow and must allow for backwards
compatibility dropping groups don't allow any gid mappings to be
established without CAP_SETGID in the parent user namespace.

For a small class of applications this change breaks userspace
and removes useful functionality.  This small class of applications
includes tools/testing/selftests/mount/unprivilged-remount-test.c

Most of the removed functionality will be added back with the addition
of a one way knob to disable setgroups.  Once setgroups is disabled
setting the gid_map becomes as safe as setting the uid_map.

For more common applications that set the uid_map and the gid_map
with privilege this change will have no affect.

This is part of a fix for CVE-2014-8989.

Cc: stable@vger.kernel.org
Reviewed-by: default avatarAndy Lutomirski <luto@amacapital.net>
Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>

(cherry picked from commit be7c6dba)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      867662d6
    • Quentin Casasnovas's avatar
      regmap: fix kernel hang on regmap_bulk_write with zero val_count. · 07ebb669
      Quentin Casasnovas authored 
      Fixes commit 2f06fa04 which was an
incorrect backported version of commit
d6b41cb0 upstream.

If val_count is zero we return -EINVAL with map->lock_arg locked, which
will deadlock the kernel next time we try to acquire this lock.

This was introduced by f5942dd ("regmap: fix possible ZERO_SIZE_PTR pointer
dereferencing error.") which improperly back-ported d6b41cb0.

This issue was found during review of Ubuntu Trusty 3.13.0-40.68 kernel to
prepare Ksplice rebootless updates.

Fixes: f5942dd ("regmap: fix possible ZERO_SIZE_PTR pointer dereferencing error.")
Signed-off-by: default avatarQuentin Casasnovas <quentin.casasnovas@oracle.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 197b3975)

(cherry picked from commit HEAD)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      07ebb669
    • bob picco's avatar
      sparc64: T5 PMU · 294aeef2
      bob picco authored 
      The T5 (niagara5) has different PCR related HV fast trap values and a new
HV API Group. This patch utilizes these and shares when possible with niagara4.

We use the same sparc_pmu niagara4_pmu. Should there be new effort to
obtain the MCU perf statistics then this would have to be changed.

Cc: sparclinux@vger.kernel.org
Signed-off-by: default avatarBob Picco <bob.picco@oracle.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>

(cherry picked from commit 05aa1651)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      294aeef2
    • Xiubo Li's avatar
      regmap: fix possible ZERO_SIZE_PTR pointer dereferencing error. · 908f6a42
      Xiubo Li authored 
      Since we cannot make sure the 'val_count' will always be none zero
here, and then if it equals to zero, the kmemdup() will return
ZERO_SIZE_PTR, which equals to ((void *)16).

So this patch fix this with just doing the zero check before calling
kmemdup().
Signed-off-by: default avatarXiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

(cherry picked from commit d6b41cb0)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      908f6a42
    • Bryan O'Donoghue's avatar
      usb: pch_udc: usb gadget device support for Intel Quark X1000 · ae50901c
      Bryan O'Donoghue authored 
      This patch is to enable the USB gadget device for Intel Quark X1000
Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@intel.com>
Signed-off-by: default avatarBing Niu <bing.niu@intel.com>
Signed-off-by: default avatarAlvin (Weike) Chen <alvin.chen@intel.com>
Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>

(cherry picked from commit a68df706)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ae50901c
    • Jan Kara's avatar
      udf: Verify i_size when loading inode · 89e1cc76
      Jan Kara authored 
      Verify that inode size is sane when loading inode with data stored in
ICB. Otherwise we may get confused later when working with the inode and
inode size is too big.

CC: stable@vger.kernel.org
Reported-by: default avatarCarl Henrik Lunde <chlunde@ping.uio.no>
Signed-off-by: default avatarJan Kara <jack@suse.cz>

(cherry picked from commit e159332b)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      89e1cc76
    • NeilBrown's avatar
      md/bitmap: always wait for writes on unplug. · 68dd1d51
      NeilBrown authored 
      If two threads call bitmap_unplug at the same time, then
one might schedule all the writes, and the other might
decide that it doesn't need to wait.  But really it does.

It rarely hurts to wait when it isn't absolutely necessary,
and the current code doesn't really focus on 'absolutely necessary'
anyway.  So just wait always.

This can potentially lead to data corruption if a crash happens
at an awkward time and data was written before the bitmap was
updated.  It is very unlikely, but this should go to -stable
just to be safe.  Appropriate for any -stable.
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
Cc: stable@vger.kernel.org (please delay until 3.18 is released)

(cherry picked from commit 4b5060dd)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      68dd1d51
    • Greg Kroah-Hartman's avatar
      Revert: ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC · dbec5ef7
      Greg Kroah-Hartman authored 
      This reverts commit 2dbfff81, which
really is commit 558e4736 upstream.

Sorry for the confusion, this got applied twice, and reverted once, this
is the second revert and I hope to never touch it again...
Reported-by: default avatarLv Zheng <lv.zheng@intel.com>
Cc: Alexander Mezin <mezin.alexander@gmail.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>

(cherry picked from commit 1c9e23ba)

(cherry picked from commit HEAD)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      dbec5ef7
    • Lv Zheng's avatar
      ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC · 7e602ca5
      Lv Zheng authored 
      commit 558e4736 upstream.

There is platform refusing to respond QR_EC when SCI_EVT isn't set
which is Acer Aspire V5-573G.

By disallowing QR_EC to be issued before the previous one has been
completed we are able to reduce the possibilities to trigger issues on
such platforms.

Note that this fix can only reduce the occurrence rate of this issue, but
this issue may still occur when such a platform doesn't clear SCI_EVT
before or immediately after completing the previous QR_EC transaction.
This patch cannot fix the CLEAR_ON_RESUME quirk which also relies on
the assumption that the platforms are able to respond even when SCI_EVT
isn't set.

But this patch is still useful as it can help to reduce the number of
scheduled QR_EC work items.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611Reported-and-tested-by: default avatarAlexander Mezin <mezin.alexander@gmail.com>
Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>

(cherry picked from commit 2dbfff81)
      7e602ca5
    • Stanislaw Gruszka's avatar
      asus-nb-wmi: Add wapf4 quirk for the X550VB · 022c5a63
      Stanislaw Gruszka authored 
      X550VB as many others Asus laptops need wapf4 quirk to make RFKILL
switch be functional. Otherwise system boots with wireless card
disabled and is only possible to enable it by suspend/resume.

Bug report:
http://bugzilla.redhat.com/show_bug.cgi?id=1089731#c23Reported-and-tested-by: default avatarVratislav Podzimek <vpodzime@redhat.com>
Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>

(cherry picked from commit 4ec7a45b)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      022c5a63
    • Filipe Manana's avatar
      Btrfs: fix fs corruption on transaction abort if device supports discard · ec9ec44e
      Filipe Manana authored 
      When we abort a transaction we iterate over all the ranges marked as dirty
in fs_info->freed_extents[0] and fs_info->freed_extents[1], clear them
from those trees, add them back (unpin) to the free space caches and, if
the fs was mounted with "-o discard", perform a discard on those regions.
Also, after adding the regions to the free space caches, a fitrim ioctl call
can see those ranges in a block group's free space cache and perform a discard
on the ranges, so the same issue can happen without "-o discard" as well.

This causes corruption, affecting one or multiple btree nodes (in the worst
case leaving the fs unmountable) because some of those ranges (the ones in
the fs_info->pinned_extents tree) correspond to btree nodes/leafs that are
referred by the last committed super block - breaking the rule that anything
that was committed by a transaction is untouched until the next transaction
commits successfully.

I ran into this while running in a loop (for several hours) the fstest that
I recently submitted:

  [PATCH] fstests: add btrfs test to stress chunk allocation/removal and fstrim

The corruption always happened when a transaction aborted and then fsck complained
like this:

   _check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
   *** fsck.btrfs output ***
   Check tree block failed, want=94945280, have=0
   Check tree block failed, want=94945280, have=0
   Check tree block failed, want=94945280, have=0
   Check tree block failed, want=94945280, have=0
   Check tree block failed, want=94945280, have=0
   read block failed check_tree_block
   Couldn't open file system

In this case 94945280 corresponded to the root of a tree.
Using frace what I observed was the following sequence of steps happened:

   1) transaction N started, fs_info->pinned_extents pointed to
      fs_info->freed_extents[0];

   2) node/eb 94945280 is created;

   3) eb is persisted to disk;

   4) transaction N commit starts, fs_info->pinned_extents now points to
      fs_info->freed_extents[1], and transaction N completes;

   5) transaction N + 1 starts;

   6) eb is COWed, and btrfs_free_tree_block() called for this eb;

   7) eb range (94945280 to 94945280 + 16Kb) is added to
      fs_info->pinned_extents (fs_info->freed_extents[1]);

   8) Something goes wrong in transaction N + 1, like hitting ENOSPC
      for example, and the transaction is aborted, turning the fs into
      readonly mode. The stack trace I got for example:

      [112065.253935]  [<ffffffff8140c7b6>] dump_stack+0x4d/0x66
      [112065.254271]  [<ffffffff81042984>] warn_slowpath_common+0x7f/0x98
      [112065.254567]  [<ffffffffa0325990>] ? __btrfs_abort_transaction+0x50/0x10b [btrfs]
      [112065.261674]  [<ffffffff810429e5>] warn_slowpath_fmt+0x48/0x50
      [112065.261922]  [<ffffffffa032949e>] ? btrfs_free_path+0x26/0x29 [btrfs]
      [112065.262211]  [<ffffffffa0325990>] __btrfs_abort_transaction+0x50/0x10b [btrfs]
      [112065.262545]  [<ffffffffa036b1d6>] btrfs_remove_chunk+0x537/0x58b [btrfs]
      [112065.262771]  [<ffffffffa033840f>] btrfs_delete_unused_bgs+0x1de/0x21b [btrfs]
      [112065.263105]  [<ffffffffa0343106>] cleaner_kthread+0x100/0x12f [btrfs]
      (...)
      [112065.264493] ---[ end trace dd7903a975a31a08 ]---
      [112065.264673] BTRFS: error (device sdc) in btrfs_remove_chunk:2625: errno=-28 No space left
      [112065.264997] BTRFS info (device sdc): forced readonly

   9) The clear kthread sees that the BTRFS_FS_STATE_ERROR bit is set in
      fs_info->fs_state and calls btrfs_cleanup_transaction(), which in
      turn calls btrfs_destroy_pinned_extent();

   10) Then btrfs_destroy_pinned_extent() iterates over all the ranges
       marked as dirty in fs_info->freed_extents[], and for each one
       it calls discard, if the fs was mounted with "-o discard", and
       adds the range to the free space cache of the respective block
       group;

   11) btrfs_trim_block_group(), invoked from the fitrim ioctl code path,
       sees the free space entries and performs a discard;

   12) After an umount and mount (or fsck), our eb's location on disk was full
       of zeroes, and it should have been untouched, because it was marked as
       dirty in the fs_info->pinned_extents tree, and therefore used by the
       trees that the last committed superblock points to.

Fix this by not performing a discard and not adding the ranges to the free space
caches - it's useless from this point since the fs is now in readonly mode and
we won't write free space caches to disk anymore (otherwise we would leak space)
nor any new superblock. By not adding the ranges to the free space caches, it
prevents other code paths from allocating that space and write to it as well,
therefore being safer and simpler.

This isn't a new problem, as it's been present since 2011 (git commit
acce952b).

Cc: stable@vger.kernel.org  # any kernel released after 2011-01-06
Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
Signed-off-by: default avatarChris Mason <clm@fb.com>

(cherry picked from commit 678886bd)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ec9ec44e
    • Josef Bacik's avatar
      Btrfs: do not move em to modified list when unpinning · 6ad11a4c
      Josef Bacik authored 
      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,

cc: stable@vger.kernel.org
Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
Signed-off-by: default avatarChris Mason <clm@fb.com>

(cherry picked from commit a2804695)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      6ad11a4c
    • Michael Halcrow's avatar
      eCryptfs: Remove buggy and unnecessary write in file name decode routine · 36327a4f
      Michael Halcrow authored 
      Dmitry Chernenkov used KASAN to discover that eCryptfs writes past the
end of the allocated buffer during encrypted filename decoding. This
fix corrects the issue by getting rid of the unnecessary 0 write when
the current bit offset is 2.
Signed-off-by: default avatarMichael Halcrow <mhalcrow@google.com>
Reported-by: default avatarDmitry Chernenkov <dmitryc@google.com>
Suggested-by: default avatarKees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org # v2.6.29+: 51ca58dc eCryptfs: Filename Encryption: Encoding and encryption functions
Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>

(cherry picked from commit 94208064)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      36327a4f
    • Tyler Hicks's avatar
      eCryptfs: Force RO mount when encrypted view is enabled · 3817135b
      Tyler Hicks authored 
      The ecryptfs_encrypted_view mount option greatly changes the
functionality of an eCryptfs mount. Instead of encrypting and decrypting
lower files, it provides a unified view of the encrypted files in the
lower filesystem. The presence of the ecryptfs_encrypted_view mount
option is intended to force a read-only mount and modifying files is not
supported when the feature is in use. See the following commit for more
information:

  e77a56dd [PATCH] eCryptfs: Encrypted passthrough

This patch forces the mount to be read-only when the
ecryptfs_encrypted_view mount option is specified by setting the
MS_RDONLY flag on the superblock. Additionally, this patch removes some
broken logic in ecryptfs_open() that attempted to prevent modifications
of files when the encrypted view feature was in use. The check in
ecryptfs_open() was not sufficient to prevent file modifications using
system calls that do not operate on a file descriptor.
Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
Reported-by: default avatarPriya Bansal <p.bansal@samsung.com>
Cc: stable@vger.kernel.org # v2.6.21+: e77a56dd [PATCH] eCryptfs: Encrypted passthrough

(cherry picked from commit 332b122d)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      3817135b
    • Jan Kara's avatar
      udf: Verify symlink size before loading it · 1e924362
      Jan Kara authored 
      UDF specification allows arbitrarily large symlinks. However we support
only symlinks at most one block large. Check the length of the symlink
so that we don't access memory beyond end of the symlink block.

CC: stable@vger.kernel.org
Reported-by: default avatarCarl Henrik Lunde <chlunde@gmail.com>
Signed-off-by: default avatarJan Kara <jack@suse.cz>

(cherry picked from commit a1d47b26)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      1e924362
    • Jan Kara's avatar
      udf: Verify i_size when loading inode · 258d9369
      Jan Kara authored 
      Verify that inode size is sane when loading inode with data stored in
ICB. Otherwise we may get confused later when working with the inode and
inode size is too big.

CC: stable@vger.kernel.org
Reported-by: default avatarCarl Henrik Lunde <chlunde@ping.uio.no>
Signed-off-by: default avatarJan Kara <jack@suse.cz>

(cherry picked from commit e159332b)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      258d9369
    • Oleg Nesterov's avatar
      exit: pidns: alloc_pid() leaks pid_namespace if child_reaper is exiting · 6de1d55c
      Oleg Nesterov authored 
      alloc_pid() does get_pid_ns() beforehand but forgets to put_pid_ns() if it
fails because disable_pid_allocation() was called by the exiting
child_reaper.

We could simply move get_pid_ns() down to successful return, but this fix
tries to be as trivial as possible.
Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
Reviewed-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
Cc: Aaron Tomlin <atomlin@redhat.com>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Serge Hallyn <serge.hallyn@ubuntu.com>
Cc: Sterling Alexander <stalexan@redhat.com>
Cc: <stable@vger.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 24c037eb)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      6de1d55c
    • Jan Kara's avatar
      ncpfs: return proper error from NCP_IOC_SETROOT ioctl · 3b8e625f
      Jan Kara authored 
      If some error happens in NCP_IOC_SETROOT ioctl, the appropriate error
return value is then (in most cases) just overwritten before we return.
This can result in reporting success to userspace although error happened.

This bug was introduced by commit 2e54eb96 ("BKL: Remove BKL from
ncpfs").  Propagate the errors correctly.

Coverity id: 1226925.

Fixes: 2e54eb96 ("BKL: Remove BKL from ncpfs")
Signed-off-by: default avatarJan Kara <jack@suse.cz>
Cc: Petr Vandrovec <petr@vandrovec.name>
Cc: <stable@vger.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 a682e9c2)
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      3b8e625f
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7