Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 25 9月, 2012 38 次提交
  3. 22 9月, 2012 2 次提交
    • L
      debugfs: fix u32_array race in format_array_alloc · e05e279e
      由 Linus Torvalds 提交于 
      The format_array_alloc() function is fundamentally racy, in that it
prints the array twice: once to figure out how much space to allocate
for the buffer, and the second time to actually print out the data.

If any of the array contents changes in between, the allocation size may
be wrong, and the end result may be truncated in odd ways.

Just don't do it.  Allocate a maximum-sized array up-front, and just
format the array contents once.  The only user of the u32_array
interfaces is the Xen spinlock statistics code, and it has 31 entries in
the arrays, so the maximum size really isn't that big, and the end
result is much simpler code without the bug.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e05e279e
    • D
      debugfs: fix race in u32_array_read and allocate array at open · 36048853
      由 David Rientjes 提交于 
      u32_array_open() is racy when multiple threads read from a file with a
seek position of zero, i.e. when two or more simultaneous reads are
occurring after the non-seekable files are created.  It is possible that
file->private_data is double-freed because the threads races between

	kfree(file->private-data);

and

	file->private_data = NULL;

The fix is to only do format_array_alloc() when the file is opened and
free it when it is closed.

Note that because the file has always been non-seekable, you can't open
it and read it multiple times anyway, so the data has always been
generated just once.  The difference is that now it is generated at open
time rather than at the time of the first read, and that avoids the
race.
Reported-by: NDave Jones <davej@redhat.com>
Acked-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: NRaghavendra <raghavendra.kt@linux.vnet.ibm.com>
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      36048853