Last commit made on 2016-01-22
Get this branch:
git clone -b xenial-4.3 https://git.launchpad.net/~tuxonice/linux
Members of TuxOnIce can upload to this branch. Log in for directions.

Branch merges

Branch information


Recent commits

0b9c89b... by Martin Schläffer

Merge tag 'Ubuntu-4.3.0-7.18'

3446533... by Martin Schläffer

Merge tag 'Ubuntu-4.3.0-6.17'

50ecba5... by Tim Gardner

UBUNTU: Ubuntu-4.3.0-7.18

Signed-off-by: Tim Gardner <email address hidden>

5b6cce0... by Andy Whitcroft

UBUNTU: [Config] s390x -- the kernel provides ppp-modules such as there are

Signed-off-by: Andy Whitcroft <email address hidden>

182fc6c... by Yevgeny

KEYS: Fix keyring ref leak in join_session_keyring()

If a thread is asked to join as a session keyring the keyring that's already
set as its session, we leak a keyring reference.

This can be tested with the following program:

int main(int argc, const char *argv[])
 int i = 0;
 key_serial_t serial;

 if (serial < 0) {
  return -1;

 if (keyctl(KEYCTL_SETPERM, serial,
     KEY_POS_ALL | KEY_USR_ALL) < 0) {
  return -1;

 for (i = 0; i < 100; i++) {
  if (serial < 0) {
   return -1;

 return 0;

If, after the program has run, there something like the following line in

3f3d898f I--Q--- 100 perm 3f3f0000 0 0 keyring leaked-keyring: empty

with a usage count of 100 * the number of times the program has been run,
then the kernel is malfunctioning. If leaked-keyring has zero usages or
has been garbage collected, then the problem is fixed.

Reported-by: Yevgeny Pats <email address hidden>
Signed-off-by: David Howells <email address hidden>
BugLink: https://bugs.launchpad.net/bugs/1534887
Acked-by: Steve Beattie <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>
Signed-off-by: Andy Whitcroft <email address hidden>

e8bcabb... by Martin Schläffer

Merge tag 'Ubuntu-4.3.0-5.16'


c250300... by Tim Gardner

UBUNTU: Start new release

Ignore: yes
Signed-off-by: Tim Gardner <email address hidden>

2a8b8bd... by Tim Gardner

UBUNTU: Ubuntu-4.3.0-6.17

Signed-off-by: Tim Gardner <email address hidden>

773dc56... by Guilherme G. Piccoli

UBUNTU: SAUCE: powerpc/eeh: Validate arch in eeh_add_device_early()

BugLink: http://bugs.launchpad.net/bugs/1486180

Commit 89a51df5ab1d ("powerpc/eeh: Fix crash in eeh_add_device_early() on Cell")
added a check on function eeh_add_device_early(): since in Cell arch eeh_ops
is NULL, that code used to crash on Cell. The commit's approach was validate
if EEH was available by checking the result of function eeh_enabled().

Since the function eeh_add_device_early() is used to perform EEH
initialization in devices added later on the system, like in hotplug/DLPAR
scenarios, we might reach a case in which no PCI devices are present on boot
and so EEH is not initialized. Then, if a device is added via DLPAR for
example, eeh_add_device_early() fails because eeh_enabled() is false.

We can hit a kernel oops on pSeries arch if eeh_add_device_early() fails:
if we have no PCI devices on machine at boot time, and then we add a PCI device
via DLPAR operation, the function query_ddw() triggers the oops on NULL pointer
dereference in the line "cfg_addr = edev->config_addr;". It happens because
config_addr in edev is NULL, since the function eeh_add_device_early() was not
completed successfully.

This patch just changes the way the arch checking is done in function
eeh_add_device_early(): we use no more eeh_enabled(), but instead we check the
running architecture by using the macro machine_is(). If we are running on
pSeries or PowerNV, the EEH mechanism can be enabled; otherwise, we bail out
the function. This way, we don't enable EEH on Cell and we don't hit the oops
on DLPAR either.

Fixes: 89a51df5ab1d ("powerpc/eeh: Fix crash in eeh_add_device_early() on Cell")
Signed-off-by: Guilherme G. Piccoli <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>

f700a3c... by Tim Gardner


BugLink: http://bugs.launchpad.net/bugs/1532886

Change these config settings to be consistent with all of the other

Signed-off-by: Tim Gardner <email address hidden>