<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/scripts, branch linux-3.2.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-3.2.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-3.2.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2018-03-19T18:58:35Z</updated>
<entry>
<title>module/retpoline: Warn about missing retpoline in module</title>
<updated>2018-03-19T18:58:35Z</updated>
<author>
<name>Andi Kleen</name>
<email>ak@linux.intel.com</email>
</author>
<published>2018-01-25T23:50:28Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8e871207e06c72304f63447afc022668dc874011'/>
<id>urn:sha1:8e871207e06c72304f63447afc022668dc874011</id>
<content type='text'>
commit caf7501a1b4ec964190f31f9c3f163de252273b8 upstream.

There's a risk that a kernel which has full retpoline mitigations becomes
vulnerable when a module gets loaded that hasn't been compiled with the
right compiler or the right option.

To enable detection of that mismatch at module load time, add a module info
string "retpoline" at build time when the module was compiled with
retpoline support. This only covers compiled C source, but assembler source
or prebuilt object files are not checked.

If a retpoline enabled kernel detects a non retpoline protected module at
load time, print a warning and report it in the sysfs vulnerability file.

[ tglx: Massaged changelog ]

Signed-off-by: Andi Kleen &lt;ak@linux.intel.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: David Woodhouse &lt;dwmw2@infradead.org&gt;
Cc: gregkh@linuxfoundation.org
Cc: torvalds@linux-foundation.org
Cc: jeyu@kernel.org
Cc: arjan@linux.intel.com
Link: https://lkml.kernel.org/r/20180125235028.31211-1-andi@firstfloor.org
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>modpost: don't emit section mismatch warnings for compiler optimizations</title>
<updated>2018-03-19T18:58:24Z</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2015-04-20T00:50:40Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f00e1e66622e2d4617db1e4bb24c1ea5616c4dd0'/>
<id>urn:sha1:f00e1e66622e2d4617db1e4bb24c1ea5616c4dd0</id>
<content type='text'>
commit 4a3893d069b788f3570c19c12d9e986e8e15870f upstream.

Currently an allyesconfig build [gcc-4.9.1] can generate the following:

   WARNING: vmlinux.o(.text.unlikely+0x3864): Section mismatch in
   reference from the function cpumask_empty.constprop.3() to the
   variable .init.data:nmi_ipi_mask

which comes from the cpumask_empty usage in arch/x86/kernel/nmi_selftest.c.

Normally we would not see a symbol entry for cpumask_empty since it is:

	static inline bool cpumask_empty(const struct cpumask *srcp)

however in this case, the variant of the symbol gets emitted when GCC does
constant propagation optimization.

Fix things up so that any locally optimized constprop variants don't warn
when accessing variables that live in the __init sections.

Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
[bwh: Backported to 3.2: Add definitions of {OTHER,ALL}_TEXT_SECTIONS]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>modpost: reduce visibility of symbols and constify r/o arrays</title>
<updated>2018-03-19T18:58:24Z</updated>
<author>
<name>Mathias Krause</name>
<email>minipli@googlemail.com</email>
</author>
<published>2014-08-27T10:58:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d4a3239fa159342be1b8a6b1e2346fa40314e4e0'/>
<id>urn:sha1:d4a3239fa159342be1b8a6b1e2346fa40314e4e0</id>
<content type='text'>
commit 7a3ee7538598e0d60e6aa87dcf34a4e8a0adebc2 upstream.

Internally used symbols of modpost don't need to be externally visible;
make them static. Also constify the string arrays so they resist in the
r/o section instead of being runtime writable.

Those changes lead to a small size reduction as can be seen below:

   text    data     bss     dec     hex filename
  51381    2640   12416   66437   10385 scripts/mod/modpost.old
  51765    2224   12416   66405   10365 scripts/mod/modpost.new

Signed-off-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>kconfig/nconf: Fix hang when editing symbol with a long prompt</title>
<updated>2017-03-16T02:18:30Z</updated>
<author>
<name>Ben Hutchings</name>
<email>ben.hutchings@codethink.co.uk</email>
</author>
<published>2016-11-24T22:10:23Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1af5e763960296c76705a20b52777de65abe2e9e'/>
<id>urn:sha1:1af5e763960296c76705a20b52777de65abe2e9e</id>
<content type='text'>
commit 79e51b5c2deea542b3bb8c66e0d502230b017dde upstream.

Currently it is impossible to edit the value of a config symbol with a
prompt longer than (terminal width - 2) characters.  dialog_inputbox()
calculates a negative x-offset for the input window and newwin() fails
as this is invalid.  It also doesn't check for this failure, so it
busy-loops calling wgetch(NULL) which immediately returns -1.

The additions in the offset calculations also don't match the intended
size of the window.

Limit the window size and calculate the offset similarly to
show_scroll_win().

Fixes: 692d97c380c6 ("kconfig: new configuration interface (nconfig)")
Signed-off-by: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
[bwh: Backported to 3.2: replaced code used LINES and COLS]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>scripts/bloat-o-meter: fix python3 syntax error</title>
<updated>2016-02-13T10:34:10Z</updated>
<author>
<name>Sergey Senozhatsky</name>
<email>sergey.senozhatsky.work@gmail.com</email>
</author>
<published>2016-01-14T23:16:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=da7b239bbdcc174c94cc6d0a4b55f9d421508d0c'/>
<id>urn:sha1:da7b239bbdcc174c94cc6d0a4b55f9d421508d0c</id>
<content type='text'>
commit 72214a24a7677d4c7501eecc9517ed681b5f2db2 upstream.

In Python3+ print is a function so the old syntax is not correct
anymore:

  $ ./scripts/bloat-o-meter vmlinux.o vmlinux.o.old
    File "./scripts/bloat-o-meter", line 61
      print "add/remove: %s/%s grow/shrink: %s/%s up/down: %s/%s (%s)" % \
                                                                     ^
  SyntaxError: invalid syntax

Fix by calling print as a function.

Tested on python 2.7.11, 3.5.1

Signed-off-by: Sergey Senozhatsky &lt;sergey.senozhatsky@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>ftrace/scripts: Fix incorrect use of sprintf in recordmcount</title>
<updated>2016-01-22T21:40:09Z</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2015-12-30T23:06:41Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e02539e109eb34597cd9a92ae1842d2b2181696c'/>
<id>urn:sha1:e02539e109eb34597cd9a92ae1842d2b2181696c</id>
<content type='text'>
commit 713a3e4de707fab49d5aa4bceb77db1058572a7b upstream.

Fix build warning:

scripts/recordmcount.c:589:4: warning: format not a string
literal and no format arguments [-Wformat-security]
    sprintf("%s: failed\n", file);

Fixes: a50bd43935586 ("ftrace/scripts: Have recordmcount copy the object file")
Link: http://lkml.kernel.org/r/1451516801-16951-1-git-send-email-colin.king@canonical.com

Cc: Li Bin &lt;huawei.libin@huawei.com&gt;
Cc: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>ftrace/scripts: Have recordmcount copy the object file</title>
<updated>2016-01-22T21:40:05Z</updated>
<author>
<name>Steven Rostedt (Red Hat)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2015-12-15T21:06:10Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fa41a0adbc216e18afe7a2dd4386f614899a0653'/>
<id>urn:sha1:fa41a0adbc216e18afe7a2dd4386f614899a0653</id>
<content type='text'>
commit a50bd43935586420fb75f4558369eb08566fac5e upstream.

Russell King found that he had weird side effects when compiling the kernel
with hard linked ccache. The reason was that recordmcount modified the
kernel in place via mmap, and when a file gets modified twice by
recordmcount, it will complain about it. To fix this issue, Russell wrote a
patch that checked if the file was hard linked more than once and would
unlink it if it was.

Linus Torvalds was not happy with the fact that recordmcount does this in
place modification. Instead of doing the unlink only if the file has two or
more hard links, it does the unlink all the time. In otherwords, it always
does a copy if it changed something. That is, it does the write out if a
change was made.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>scripts: recordmcount: break hardlinks</title>
<updated>2016-01-22T21:40:05Z</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@arm.linux.org.uk</email>
</author>
<published>2015-12-11T12:09:03Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9475edfee93bc3e1b8b96de3bd4823210e39303c'/>
<id>urn:sha1:9475edfee93bc3e1b8b96de3bd4823210e39303c</id>
<content type='text'>
commit dd39a26538e37f6c6131e829a4a510787e43c783 upstream.

recordmcount edits the file in-place, which can cause problems when
using ccache in hardlink mode.  Arrange for recordmcount to break a
hardlinked object.

Link: http://lkml.kernel.org/r/E1a7MVT-0000et-62@rmk-PC.arm.linux.org.uk

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>recordmcount: Fix endianness handling bug for nop_mcount</title>
<updated>2015-11-27T12:48:22Z</updated>
<author>
<name>libin</name>
<email>huawei.libin@huawei.com</email>
</author>
<published>2015-11-03T00:58:47Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6b8120dbc56a7ecc9e4b664d860011877bdce985'/>
<id>urn:sha1:6b8120dbc56a7ecc9e4b664d860011877bdce985</id>
<content type='text'>
commit c84da8b9ad3761eef43811181c7e896e9834b26b upstream.

In nop_mcount, shdr-&gt;sh_offset and welp-&gt;r_offset should handle
endianness properly, otherwise it will trigger Segmentation fault
if the recordmcount main and file.o have different endianness.

Link: http://lkml.kernel.org/r/563806C7.7070606@huawei.com

Signed-off-by: Li Bin &lt;huawei.libin@huawei.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>localmodconfig: Use Kbuild files too</title>
<updated>2015-10-13T02:46:03Z</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2015-07-26T22:06:55Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bc3356a8b8dedacf18cd8662b06cb4282bb051e9'/>
<id>urn:sha1:bc3356a8b8dedacf18cd8662b06cb4282bb051e9</id>
<content type='text'>
commit c0ddc8c745b7f89c50385fd7aa03c78dc543fa7a upstream.

In kbuild it is allowed to define objects in files named "Makefile"
and "Kbuild".
Currently localmodconfig reads objects only from "Makefile"s and misses
modules like nouveau.

Link: http://lkml.kernel.org/r/1437948415-16290-1-git-send-email-richard@nod.at

Reported-and-tested-by: Leonidas Spyropoulos &lt;artafinde@gmail.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
</feed>
