Skip to content
  1. Jan 07, 2015
    • Pranith Kumar's avatar
      assoc_array: Include rcupdate.h for call_rcu() definition · 990428b8
      Pranith Kumar authored 
      

Include rcupdate.h header to provide call_rcu() definition. This was implicitly
being provided by slab.h file which include srcu.h somewhere in its include
hierarchy which in-turn included rcupdate.h.

Lately, tinification effort added support to remove srcu entirely because of
which we are encountering build errors like

lib/assoc_array.c: In function 'assoc_array_apply_edit':
lib/assoc_array.c:1426:2: error: implicit declaration of function 'call_rcu' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors

Fix these by including rcupdate.h explicitly.

Signed-off-by: default avatarPranith Kumar <bobby.prani@gmail.com>
Reported-by: default avatarScott Wood <scottwood@freescale.com>
      990428b8
  3. Dec 19, 2014
  5. Dec 13, 2014
    • Haesung Kim's avatar
      lib/decompress.c: consistency of compress formats for kernel image · a060bfe0
      Haesung Kim authored 
      

Magic number of compress formats for kernel image is defined by two bytes.
 These numbers are written in hexadecimal number, nevertheless magic
number for only gunzip is written in octal number.  The formats should be
consistent for readability.  Therefore, magic numbers for gunzip are also
defined by hexadecimal number.

Signed-off-by: default avatarHaesung Kim <matia.kim@lge.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a060bfe0
    • Dan Carpenter's avatar
      decompress_bunzip2: off by one in get_next_block() · b5c8afe5
      Dan Carpenter authored 
      

"origPtr" is used as an offset into the bd->dbuf[] array.  That array is
allocated in start_bunzip() and has "bd->dbufSize" number of elements so
the test here should be >= instead of >.

Later we check "origPtr" again before using it as an offset so I don't
know if this bug can be triggered in real life.

Fixes: bc22c17e ('bzip2/lzma: library support for gzip, bzip2 and lzma decompression')
Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Cc: Alain Knaff <alain@knaff.lu>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b5c8afe5
    • Dmitry Monakhov's avatar
      fault-inject: add ratelimit option · 6adc4a22
      Dmitry Monakhov authored 
      

Current debug levels are not optimal.  Especially if one want to provoke
big numbers of faults(broken device simulator) then any verbose level will
produce giant numbers of identical logging messages.  Let's add ratelimit
parameter for that purpose.

Signed-off-by: default avatarDmitry Monakhov <dmonakhov@openvz.org>
Acked-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6adc4a22
    • David Drysdale's avatar
      syscalls: implement execveat() system call · 51f39a1f
      David Drysdale authored 
      This patchset adds execveat(2) for x86, and is derived from Meredydd
Luff's patch from Sept 2012 (https://lkml.org/lkml/2012/9/11/528).

The primary aim of adding an execveat syscall is to allow an
implementation of fexecve(3) that does not rely on the /proc filesystem,
at least for executables (rather than scripts).  The current glibc version
of fexecve(3) is implemented via /proc, which causes problems in sandboxed
or otherwise restricted environments.

Given the desire for a /proc-free fexecve() implementation, HPA suggested
(https://lkml.org/lkml/2006/7/11/556) that an execveat(2) syscall would be
an appropriate generalization.

Also, having a new syscall means that it can take a flags argument without
back-compatibility concerns.  The current implementation just defines the
AT_EMPTY_PATH and AT_SYMLINK_NOFOLLOW flags, but other flags could be
added in future -- for example, flags for new namespaces (as suggested at
https://lkml.org/lkml/2006/7/11/474).

Related history:
 - https://lkml.org/lkml/2006/12/27/123 is an example of someone
   realizing that fexecve() is likely to fail in a chroot environment.
 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514043 covered
   documenting the /proc requirement of fexecve(3) in its manpage, to
   "prevent other people from wasting their time".
 - https://bugzilla.redhat.com/show_bug.cgi?id=241609

 described a
   problem where a process that did setuid() could not fexecve()
   because it no longer had access to /proc/self/fd; this has since
   been fixed.

This patch (of 4):

Add a new execveat(2) system call.  execveat() is to execve() as openat()
is to open(): it takes a file descriptor that refers to a directory, and
resolves the filename relative to that.

In addition, if the filename is empty and AT_EMPTY_PATH is specified,
execveat() executes the file to which the file descriptor refers.  This
replicates the functionality of fexecve(), which is a system call in other
UNIXen, but in Linux glibc it depends on opening "/proc/self/fd/<fd>" (and
so relies on /proc being mounted).

The filename fed to the executed program as argv[0] (or the name of the
script fed to a script interpreter) will be of the form "/dev/fd/<fd>"
(for an empty filename) or "/dev/fd/<fd>/<filename>", effectively
reflecting how the executable was found.  This does however mean that
execution of a script in a /proc-less environment won't work; also, script
execution via an O_CLOEXEC file descriptor fails (as the file will not be
accessible after exec).

Based on patches by Meredydd Luff.

Signed-off-by: default avatarDavid Drysdale <drysdale@google.com>
Cc: Meredydd Luff <meredydd@senatehouse.org>
Cc: Shuah Khan <shuah.kh@samsung.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rich Felker <dalias@aerifal.cx>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      51f39a1f
    • Joonsoo Kim's avatar
      mm/page_owner: keep track of page owners · 48c96a36
      Joonsoo Kim authored 
      

This is the page owner tracking code which is introduced so far ago.  It
is resident on Andrew's tree, though, nobody tried to upstream so it
remain as is.  Our company uses this feature actively to debug memory leak
or to find a memory hogger so I decide to upstream this feature.

This functionality help us to know who allocates the page.  When
allocating a page, we store some information about allocation in extra
memory.  Later, if we need to know status of all pages, we can get and
analyze it from this stored information.

In previous version of this feature, extra memory is statically defined in
struct page, but, in this version, extra memory is allocated outside of
struct page.  It enables us to turn on/off this feature at boottime
without considerable memory waste.

Although we already have tracepoint for tracing page allocation/free,
using it to analyze page owner is rather complex.  We need to enlarge the
trace buffer for preventing overlapping until userspace program launched.
And, launched program continually dump out the trace buffer for later
analysis and it would change system behaviour with more possibility rather
than just keeping it in memory, so bad for debug.

Moreover, we can use page_owner feature further for various purposes.  For
example, we can use it for fragmentation statistics implemented in this
patch.  And, I also plan to implement some CMA failure debugging feature
using this interface.

I'd like to give the credit for all developers contributed this feature,
but, it's not easy because I don't know exact history.  Sorry about that.
Below is people who has "Signed-off-by" in the patches in Andrew's tree.

Contributor:
Alexander Nyberg <alexn@dsv.su.se>
Mel Gorman <mgorman@suse.de>
Dave Hansen <dave@linux.vnet.ibm.com>
Minchan Kim <minchan@kernel.org>
Michal Nazarewicz <mina86@mina86.com>
Andrew Morton <akpm@linux-foundation.org>
Jungsoo Son <jungsoo.son@lge.com>

Signed-off-by: default avatarJoonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Dave Hansen <dave@sr71.net>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Jungsoo Son <jungsoo.son@lge.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      48c96a36
    • Michal Nazarewicz's avatar
      lib: bitmap: add alignment offset for bitmap_find_next_zero_area() · 5e19b013
      Michal Nazarewicz authored 
      Add a bitmap_find_next_zero_area_off() function which works like
bitmap_find_next_zero_area() function except it allows an offset to be
specified when alignment is checked.  This lets caller request a bit such
that its number plus the offset is aligned according to the mask.

[gregory.0xf0@gmail.com: Retrieved from https://patchwork.linuxtv.org/patch/6254/

 and updated documentation]
Signed-off-by: default avatarMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: default avatarGregory Fong <gregory.0xf0@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5e19b013
  7. Dec 11, 2014
  9. Dec 10, 2014
    • Daniel Borkmann's avatar
      net, lib: kill arch_fast_hash library bits · 0cb6c969
      Daniel Borkmann authored 
      

As there are now no remaining users of arch_fast_hash(), lets kill
it entirely.

This basically reverts commit 71ae8aac ("lib: introduce arch
optimized hash library") and follow-up work, that is f.e., commit
23721754 ("lib: hash: follow-up fixups for arch hash"),
commit e3fec2f7 ("lib: Add missing arch generic-y entries for
asm-generic/hash.h") and last but not least commit 6a02652d
("perf tools: Fix include for non x86 architectures").

Cc: Francesco Fusco <fusco@ntop.org>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0cb6c969
    • Daniel Borkmann's avatar
      net: replace remaining users of arch_fast_hash with jhash · 87545899
      Daniel Borkmann authored 
      This patch effectively reverts commit 500f8087 ("net: ovs: use CRC32
accelerated flow hash if available"), and other remaining arch_fast_hash()
users such as from nfsd via commit 6282cd56 ("NFSD: Don't hand out
delegations for 30 seconds after recalling them.") where it has been used
as a hash function for bloom filtering.

While we think that these users are actually not much of concern, it has
been requested to remove the arch_fast_hash() library bits that arose
from [1] entirely as per recent discussion [2]. The main argument is that
using it as a hash may introduce bias due to its linearity (see avalanche
criterion) and thus makes it less clear (though we tried to document that)
when this security/performance trade-off is actually acceptable for a
general purpose library function.

Lets therefore avoid any further confusion on this matter and remove it to
prevent any future accidental misuse of it. For the time being, this is
going to make hashing of flow keys a bit more expensive in the ovs case,
but future work could reevaluate a different hashing discipline.

  [1] https://patchwork.ozlabs.org/patch/299369/
  [2] https://patchwork.ozlabs.org/patch/418756/



Cc: Neil Brown <neilb@suse.de>
Cc: Francesco Fusco <fusco@ntop.org>
Cc: Jesse Gross <jesse@nicira.com>
Cc: Thomas Graf <tgraf@suug.ch>
Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      87545899
  11. Dec 09, 2014
  13. Dec 03, 2014
  15. Nov 24, 2014
  17. Nov 20, 2014
    • Steven Rostedt (Red Hat)'s avatar
      seq_buf: Move the seq_buf code to lib/ · 8d58e99a
      Steven Rostedt (Red Hat) authored 
      The seq_buf functions are rather useful outside of tracing. Instead
of having it be dependent on CONFIG_TRACING, move the code into lib/
and allow other users to have access to it even when tracing is not
configured.

The seq_buf utility is similar to the seq_file utility, but instead of
writing sending data back up to userland, it writes it into a buffer
defined at seq_buf_init(). This allows us to send a descriptor around
that writes printf() formatted strings into it that can be retrieved
later.

It is currently used by the tracing facility for such things like trace
events to convert its binary saved data in the ring buffer into an
ASCII human readable context to be displayed in /sys/kernel/debug/trace.

It can also be used for doing NMI prints safely from NMI context into
the seq_buf and retrieved later and dumped to printk() safely. Doing
printk() from an NMI context is dangerous because an NMI can preempt
a current printk() and deadlock on it.

Link: http://lkml.kernel.org/p/20140619213952.058255809@goodmis.org



Tested-by: default avatarJiri Kosina <jkosina@suse.cz>
Acked-by: default avatarJiri Kosina <jkosina@suse.cz>
Reviewed-by: default avatarPetr Mladek <pmladek@suse.cz>
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      8d58e99a
  19. Nov 16, 2014
  21. Nov 14, 2014
    • Jay Vosburgh's avatar
      Revert "fast_hash: avoid indirect function calls" · a77f9c5d
      Jay Vosburgh authored 
      

This reverts commit e5a2c899.

	Commit e5a2c899 introduced an alternative_call, arch_fast_hash2,
that selects between __jhash2 and __intel_crc4_2_hash based on the
X86_FEATURE_XMM4_2.

	Unfortunately, the alternative_call system does not appear to be
suitable for use with C functions, as register usage is not handled
properly for the called functions.  The __jhash2 function in particular
clobbers registers that are not preserved when called via
alternative_call, resulting in a panic for direct callers of
arch_fast_hash2 on older CPUs lacking sse4_2.  It is possible that
__intel_crc4_2_hash works merely by chance because it uses fewer
registers.

	This commit was suggested as the source of the problem by Jesse
Gross <jesse@nicira.com>.

Signed-off-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a77f9c5d
  23. Nov 13, 2014
  25. Nov 11, 2014
  27. Nov 07, 2014
    • Sudeep Holla's avatar
      cpumask: factor out show_cpumap into separate helper function · 5aaba363
      Sudeep Holla authored 
      

Many sysfs *_show function use cpu{list,mask}_scnprintf to copy cpumap
to the buffer aligned to PAGE_SIZE, append '\n' and '\0' to return null
terminated buffer with newline.

This patch creates a new helper function cpumap_print_to_pagebuf in
cpumask.h using newly added bitmap_print_to_pagebuf and consolidates
most of those sysfs functions using the new helper function.

Signed-off-by: Sudeep Holla's avatarSudeep Holla <sudeep.holla@arm.com>
Suggested-by: default avatarStephen Boyd <sboyd@codeaurora.org>
Tested-by: default avatarStephen Boyd <sboyd@codeaurora.org>
Acked-by: default avatar"Rafael J. Wysocki" <rjw@rjwysocki.net>
Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: x86@kernel.org
Cc: linux-acpi@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5aaba363
    • Pankaj Dubey's avatar
      kobject: fix NULL pointer derefernce in kobj_child_ns_ops · 41fb96a4
      Pankaj Dubey authored 
      

We will hit NULL pointer dereference if we call
platform_device_register_simple or platform_device_add at very early
stage. I have observed following crash when called platform_device_add
from "init_irq" hook of machine_desc. This patch fixes this issue and
let system handle this case gracefully instead of kernel panic.

[0.000000] Unable to handle kernel NULL pointer dereference at
virtual address 0000000c
[0.000000] pgd = c0004000
[0.000000] [0000000c] *pgd=00000000
[0.000000] Internal error: Oops: 5 [#1] PREEMPT ARM
[0.000000] Modules linked in:
[0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G        W 3.17.0-rc6-00198-ga1603f1-dirty #319
[0.000000] task: c05b23f0 ti: c05a8000 task.ti: c05a8000
[0.000000] PC is at kobject_namespace+0x18/0x58
[0.000000] LR is at kobject_add_internal+0x90/0x2ec
[snip]
[0.000000] [<c01b1df0>] (kobject_namespace) from [<c01b2338>] (kobject_add_internal+0x90/0x2ec)
[0.000000] [<c01b2338>] (kobject_add_internal) from [<c01b2728>] (kobject_add+0x4c/0x98)
[0.000000] [<c01b2728>] (kobject_add) from [<c0226274>] (device_add+0xe8/0x51c)
[0.000000] [<c0226274>] (device_add) from [<c0229c70>] (platform_device_add+0xb4/0x214)
[0.000000] [<c0229c70>] (platform_device_add) from [<c022a338>] (platform_device_register_full+0xb8/0xdc)
[0.000000] [<c022a338>] (platform_device_register_full) from [<c0570214>] (exynos_init_irq+0x90/0x9c)
[0.000000] [<c0570214>] (exynos_init_irq) from [<c056c18c>] (init_IRQ+0x2c/0x78)
[0.000000] [<c056c18c>] (init_IRQ) from [<c0569a54>] (start_kernel+0x22c/0x378)
[0.000000] [<c0569a54>] (start_kernel) from [<40008070>] (0x40008070)
[0.000000] Code: e590000c e3500000 0a00000e e5903014 (e593300c)

Signed-off-by: default avatarPankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      41fb96a4
    • Cristian Stoica's avatar
      devres: support sizes greater than an unsigned long · 5559b7bc
      Cristian Stoica authored 
      

As in 4f452e8a, use resource_size_t
to accomodate sizes greater than the size of an unsigned long int on
platforms that have more than 32 bit physical addresses.

Signed-off-by: default avatarCristian Stoica <cristian.stoica@freescale.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5559b7bc
  29. Nov 06, 2014
  31. Oct 30, 2014
  33. Oct 29, 2014
  35. Oct 28, 2014
  37. Oct 17, 2014