Skip to content

GitLab

Switch branch/tag
  1. 12 Feb, 2019 2 commits
    • Bart Van Assche's avatar
      lib/test_rhashtable: Make test_insert_dup() allocate its hash table dynamically · 81733c64
      Bart Van Assche authored 
      [ Upstream commit fc42a689

 ]

The test_insert_dup() function from lib/test_rhashtable.c passes a
pointer to a stack object to rhltable_init(). Allocate the hash table
dynamically to avoid that the following is reported with object
debugging enabled:

ODEBUG: object (ptrval) is on stack (ptrval), but NOT annotated.
WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:368 __debug_object_init+0x312/0x480
Modules linked in:
EIP: __debug_object_init+0x312/0x480
Call Trace:
 ? debug_object_init+0x1a/0x20
 ? __init_work+0x16/0x30
 ? rhashtable_init+0x1e1/0x460
 ? sched_clock_cpu+0x57/0xe0
 ? rhltable_init+0xb/0x20
 ? test_insert_dup+0x32/0x20f
 ? trace_hardirqs_on+0x38/0xf0
 ? ida_dump+0x10/0x10
 ? jhash+0x130/0x130
 ? my_hashfn+0x30/0x30
 ? test_rht_init+0x6aa/0xab4
 ? ida_dump+0x10/0x10
 ? test_rhltable+0xc5c/0xc5c
 ? do_one_initcall+0x67/0x28e
 ? trace_hardirqs_off+0x22/0xe0
 ? restore_all_kernel+0xf/0x70
 ? trace_hardirqs_on_thunk+0xc/0x10
 ? restore_all_kernel+0xf/0x70
 ? kernel_init_freeable+0x142/0x213
 ? rest_init+0x230/0x230
 ? kernel_init+0x10/0x110
 ? schedule_tail_wrapper+0x9/0xc
 ? ret_from_fork+0x19/0x24

Cc: Thomas Graf <tgraf@suug.ch>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81733c64
    • Michael Ellerman's avatar
      seq_buf: Make seq_buf_puts() null-terminate the buffer · 6201e8ad
      Michael Ellerman authored 
      [ Upstream commit 0464ed24 ]

Currently seq_buf_puts() will happily create a non null-terminated
string for you in the buffer. This is particularly dangerous if the
buffer is on the stack.

For example:

  char buf[8];
  char secret = "secret";
  struct seq_buf s;

  seq_buf_init(&s, buf, sizeof(buf));
  seq_buf_puts(&s, "foo");
  printk("Message is %s\n", buf);

Can result in:

  Message is fooªªªªªsecret

We could require all users to memset() their buffer to zero before
use. But that seems likely to be forgotten and lead to bugs.

Instead we can change seq_buf_puts() to always leave the buffer in a
null-terminated state.

The only downside is that this makes the buffer 1 character smaller
for seq_buf_puts(), but that seems like a good trade off.

Link: http://lkml.kernel.org/r/20181019042109.8064-1-mpe@ellerman.id.au

Acked-by: default avatarKees Cook <keescook@chromium.org>
Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6201e8ad
  3. 22 Jan, 2019 1 commit
  5. 13 Jan, 2019 2 commits
  7. 17 Dec, 2018 1 commit
  9. 13 Dec, 2018 1 commit
  11. 08 Dec, 2018 1 commit
  13. 05 Dec, 2018 1 commit
  15. 27 Nov, 2018 1 commit
  17. 21 Nov, 2018 1 commit
  19. 13 Nov, 2018 1 commit
    • Waiman Long's avatar
      locking/lockdep: Fix debug_locks off performance problem · 117d5fbd
      Waiman Long authored 
      [ Upstream commit 9506a742

 ]

It was found that when debug_locks was turned off because of a problem
found by the lockdep code, the system performance could drop quite
significantly when the lock_stat code was also configured into the
kernel. For instance, parallel kernel build time on a 4-socket x86-64
server nearly doubled.

Further analysis into the cause of the slowdown traced back to the
frequent call to debug_locks_off() from the __lock_acquired() function
probably due to some inconsistent lockdep states with debug_locks
off. The debug_locks_off() function did an unconditional atomic xchg
to write a 0 value into debug_locks which had already been set to 0.
This led to severe cacheline contention in the cacheline that held
debug_locks.  As debug_locks is being referenced in quite a few different
places in the kernel, this greatly slow down the system performance.

To prevent that trashing of debug_locks cacheline, lock_acquired()
and lock_contended() now checks the state of debug_locks before
proceeding. The debug_locks_off() function is also modified to check
debug_locks before calling __debug_locks_off().
Signed-off-by: default avatarWaiman Long <longman@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
Link: http://lkml.kernel.org/r/1539913518-15598-1-git-send-email-longman@redhat.com

Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      117d5fbd
  21. 15 Oct, 2018 1 commit
  23. 12 Oct, 2018 1 commit
    • Arnd Bergmann's avatar
      lib/bch: fix possible stack overrun · f0fe77f6
      Arnd Bergmann authored 
      The previous patch introduced very large kernel stack usage and a Makefile
change to hide the warning about it.

From what I can tell, a number of things went wrong here:

- The BCH_MAX_T constant was set to the maximum value for 'n',
  not the maximum for 't', which is much smaller.

- The stack usage is actually larger than the entire kernel stack
  on some architectures that can use 4KB stacks (m68k, sh, c6x), which
  leads to an immediate overrun.

- The justification in the patch description claimed that nothing
  changed, however that is not the case even without the two points above:
  the configuration is machine specific, and most boards  never use the
  maximum BCH_ECC_WORDS() length but instead have something much smaller.
  That maximum would only apply to machines that use both the maximum
  block size and the maximum ECC strength.

The largest value for 't' that I could find is '32', which in turn leads
to a 60 byte array instead of 2048 bytes. Making it '...
      f0fe77f6
  25. 05 Oct, 2018 1 commit
    • Steven Rostedt (VMware)'s avatar
      vsprintf: Fix off-by-one bug in bstr_printf() processing dereferenced pointers · 62165600
      Steven Rostedt (VMware) authored 
      The functions vbin_printf() and bstr_printf() are used by trace_printk() to
try to keep the overhead down during printing. trace_printk() uses
vbin_printf() at the time of execution, as it only scans the fmt string to
record the printf values into the buffer, and then uses vbin_printf() to do
the conversions to print the string based on the format and the saved
values in the buffer.

This is an issue for dereferenced pointers, as before commit 841a915d,
the processing of the pointer could happen some time after the pointer value
was recorded (reading the trace buffer). This means the processing of the
value at a later time could show different results, or even crash the
system, if the pointer no longer existed.

Commit 841a915d addressed this by processing dereferenced pointers at
the time of execution and save the result in the ring buffer as a string.
The bstr_printf() would then treat these pointers as normal strings, and
print the value. But there was an off-by-one bug here, where after
processing the argument, it move the pointer only "strlen(arg)" which made
the arg pointer not point to the next argument in the ring buffer, but
instead point to the nul character of the last argument. This causes any
values after a dereferenced pointer to be corrupted.

Cc: stable@vger.kernel.org
Fixes: 841a915d

 ("vsprintf: Do not have bprintf dereference pointers")
Reported-by: default avatarNikolay Borisov <nborisov@suse.com>
Tested-by: default avatarNikolay Borisov <nborisov@suse.com>
Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      62165600
  27. 01 Oct, 2018 1 commit
    • Joel Stanley's avatar
      lib/xz: Put CRC32_POLY_LE in xz_private.h · 242cdad8
      Joel Stanley authored 
      This fixes a regression introduced by faa16bc4 ("lib: Use
existing define with polynomial").

The cleanup added a dependency on include/linux, which broke the PowerPC
boot wrapper/decompresser when KERNEL_XZ is enabled:

  BOOTCC  arch/powerpc/boot/decompress.o
 In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:233,
                 from arch/powerpc/boot/decompress.c:42:
 arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:10: fatal error:
 linux/crc32poly.h: No such file or directory
  #include <linux/crc32poly.h>
           ^~~~~~~~~~~~~~~~~~~

The powerpc decompresser is a hairy corner of the kernel. Even while building
a 64-bit kernel it needs to build a 32-bit binary and therefore avoid including
files from include/linux.

This allows users of the xz library to avoid including headers from
'include/linux/' while still achieving the cleanup of the magic number.

Fixes: faa16bc4 ("lib: Use existing define with polynomial")
Report...
      242cdad8
  29. 04 Sep, 2018 1 commit
  31. 30 Aug, 2018 1 commit
  33. 24 Aug, 2018 1 commit
  35. 22 Aug, 2018 17 commits
  37. 21 Aug, 2018 1 commit
  39. 18 Aug, 2018 1 commit
    • Linus Torvalds's avatar
      deprecate the '__deprecated' attribute warnings entirely and for good · 771c0353
      Linus Torvalds authored 
      
We haven't had lots of deprecation warnings lately, but the rdma use of
it made them flare up again.

They are not useful.  They annoy everybody, and nobody ever does
anything about them, because it's always "somebody elses problem".  And
when people start thinking that warnings are normal, they stop looking
at them, and the real warnings that mean something go unnoticed.

If you want to get rid of a function, just get rid of it.  Convert every
user to the new world order.

And if you can't do that, then don't annoy everybody else with your
marking that says "I couldn't be bothered to fix this, so I'll just spam
everybody elses build logs with warnings about my laziness".

Make a kernelnewbies wiki page about things that could be cleaned up,
write a blog post about it, or talk to people on the mailing lists.  But
don't add warnings to the kernel build about cleanup that you think
should happen but you aren't doing yourself.

Don't.  Just don't.
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      771c0353
  41. 16 Aug, 2018 1 commit
    • Cong Wang's avatar
      ila: make lockdep happy again · ff93bca7
      Cong Wang authored 
      Previously, alloc_ila_locks() and bucket_table_alloc() call
spin_lock_init() separately, therefore they have two different
lock names and lock class keys. However, after commit b8932817
("ila: Call library function alloc_bucket_locks") they both call
helper alloc_bucket_spinlocks() which now only has one lock
name and lock class key. This causes a few bogus lockdep warnings
as reported by syzbot.

Fix this by making alloc_bucket_locks() a macro and pass declaration
name as lock name and a static lock class key inside the macro.

Fixes: b8932817

 ("ila: Call library function alloc_bucket_locks")
Reported-by: <syzbot+b66a5a554991a8ed027c@syzkaller.appspotmail.com>
Cc: Tom Herbert <tom@quantonium.net>
Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ff93bca7
  43. 11 Aug, 2018 1 commit

Powered by Integricloud