Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

7601 #67

Open
wants to merge 6,673 commits into
base: master
Choose a base branch
from
Open

7601 #67

wants to merge 6,673 commits into from
This pull request is big! We’re only showing the most recent 250 commits.

Commits on Jul 9, 2014

  1. Staging: bcm: Create and initialize new device id in InterfaceInit 

    commit e66fc1f upstream.

This patch create and initalizes a new device
id of 0x172 as reported by Rinat Camalov
<[email protected]>. In addition, a
comment is added to the potential invalid
existing device id.

Reported-by: Rinat Camalov <[email protected]>
Signed-off-by: Kevin McKinney <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
Cc: Yijing Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @bytefirst @gregkh
    bytefirst authored and gregkh committed Jul 9, 2014
    Configuration menu
    Copy the full SHA
    f3e786c View commit details
    Browse the repository at this point in the history

  2. Staging: bcm: Add two products and remove an existing product. 

    commit 4f29ef0 upstream.

This patch adds two new products and modifies
the device id table to include them. In addition,
product of 0xbccd - BCM_USB_PRODUCT_ID_SM250 is
removed because Beceem, ZTE, Sprint use this id
for block devices.

Reported-by: Muhammad Minhazul Haque <[email protected]>
Signed-off-by: Kevin McKinney <[email protected]>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
Cc: Yijing Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @bytefirst @gregkh
    bytefirst authored and gregkh committed Jul 9, 2014
    Configuration menu
    Copy the full SHA
    edc9d9a View commit details
    Browse the repository at this point in the history

  3. powerpc: Fix emulation of illegal instructions on PowerNV platform 

    commit bf59390 upstream.

Normally, the kernel emulates a few instructions that are unimplemented
on some processors (e.g. the old dcba instruction), or privileged (e.g.
mfpvr).  The emulation of unimplemented instructions is currently not
working on the PowerNV platform.  The reason is that on these machines,
unimplemented and illegal instructions cause a hypervisor emulation
assist interrupt, rather than a program interrupt as on older CPUs.
Our vector for the emulation assist interrupt just calls
program_check_exception() directly, without setting the bit in SRR1
that indicates an illegal instruction interrupt.  This fixes it by
making the emulation assist interrupt set that bit before calling
program_check_interrupt().  With this, old programs that use no-longer
implemented instructions such as dcba now work again.

Signed-off-by: Paul Mackerras <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
Cc: Yijing Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @paulusmack @gregkh
    paulusmack authored and gregkh committed Jul 9, 2014
    Configuration menu
    Copy the full SHA
    1ee6596 View commit details
    Browse the repository at this point in the history

  4. powerpc/smp: Section mismatch from smp_release_cpus to __initdata spi… 

    …nning_secondaries

commit 8246aca upstream.

the smp_release_cpus is a normal funciton and called in normal environments,
  but it calls the __initdata spinning_secondaries.
  need modify spinning_secondaries to match smp_release_cpus.

the related warning:
  (the linker report boot_paca.33377, but it should be spinning_secondaries)

-----------------------------------------------------------------------------

WARNING: arch/powerpc/kernel/built-in.o(.text+0x23176): Section mismatch in reference from the function .smp_release_cpus() to the variable .init.data:boot_paca.33377
The function .smp_release_cpus() references
the variable __initdata boot_paca.33377.
This is often because .smp_release_cpus lacks a __initdata
annotation or the annotation of boot_paca.33377 is wrong.

WARNING: arch/powerpc/kernel/built-in.o(.text+0x231fe): Section mismatch in reference from the function .smp_release_cpus() to the variable .init.data:boot_paca.33377
The function .smp_release_cpus() references
the variable __initdata boot_paca.33377.
This is often because .smp_release_cpus lacks a __initdata
annotation or the annotation of boot_paca.33377 is wrong.

-----------------------------------------------------------------------------

Signed-off-by: Chen Gang <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
Cc: Yijing Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Chen Gang authored and gregkh committed Jul 9, 2014
    Configuration menu
    Copy the full SHA
    1902a25 View commit details
    Browse the repository at this point in the history

  5. powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without hype… 

    …rvisor

commit f5f6cbb upstream.

/proc/powerpc/lparcfg is an ancient facility (though still actively used)
which allows access to some informations relative to the partition when
running underneath a PAPR compliant hypervisor.

It makes no sense on non-pseries machines. However, currently, not only
can it be created on these if the kernel has pseries support, but accessing
it on such a machine will crash due to trying to do hypervisor calls.

In fact, it should also not do HV calls on older pseries that didn't have
an hypervisor either.

Finally, it has the plumbing to be a module but is a "bool" Kconfig option.

This fixes the whole lot by turning it into a machine_device_initcall
that is only created on pseries, and adding the necessary hypervisor
check before calling the H_GET_EM_PARMS hypercall

Signed-off-by: Benjamin Herrenschmidt <[email protected]>
[bwh: Backported to 3.2: lparcfg_cleanup() was a bit different]
Signed-off-by: Ben Hutchings <[email protected]>
Cc: Yijing Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @ozbenh @gregkh
    ozbenh authored and gregkh committed Jul 9, 2014
    Configuration menu
    Copy the full SHA
    58b9385 View commit details
    Browse the repository at this point in the history

  6. powerpc: Restore registers on error exit from csum_partial_copy_gener… 

    …ic()

commit 8f21bd0 upstream.

The csum_partial_copy_generic() function saves the PowerPC non-volatile
r14, r15, and r16 registers for the main checksum-and-copy loop.
Unfortunately, it fails to restore them upon error exit from this loop,
which results in silent corruption of these registers in the presumably
rare event of an access exception within that loop.

This commit therefore restores these register on error exit from the loop.

Signed-off-by: Paul E. McKenney <[email protected]>
Signed-off-by: Anton Blanchard <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
[bwh: Backported to 3.2: register name macros use lower-case 'r']
Signed-off-by: Ben Hutchings <[email protected]>
Cc: Yijing Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @paulmck @gregkh
    paulmck authored and gregkh committed Jul 9, 2014
    Configuration menu
    Copy the full SHA
    0b36b7f View commit details
    Browse the repository at this point in the history

  7. powerpc/pseries/lparcfg: Fix possible overflow are more than 1026 

    commit 5676005 upstream.

need set '\0' for 'local_buffer'.

SPLPAR_MAXLENGTH is 1026, RTAS_DATA_BUF_SIZE is 4096. so the contents of
rtas_data_buf may truncated in memcpy.

if contents are really truncated.
  the splpar_strlen is more than 1026. the next while loop checking will
  not find the end of buffer. that will cause memory access violation.

Signed-off-by: Chen Gang <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
Cc: Yijing Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Chen Gang authored and gregkh committed Jul 9, 2014
    Configuration menu
    Copy the full SHA
    a1ca0f8 View commit details
    Browse the repository at this point in the history

  8. powerpc/pseries: Duplicate dtl entries sometimes sent to userspace 

    commit 84b0738 upstream.

When reading from the dispatch trace log (dtl) userspace interface, I
sometimes see duplicate entries. One example:

# hexdump -C dtl.out

00000000  07 04 00 0c 00 00 48 44  00 00 00 00 00 00 00 00
00000010  00 0c a0 b4 16 83 6d 68  00 00 00 00 00 00 00 00
00000020  00 00 00 00 10 00 13 50  80 00 00 00 00 00 d0 32

00000030  07 04 00 0c 00 00 48 44  00 00 00 00 00 00 00 00
00000040  00 0c a0 b4 16 83 6d 68  00 00 00 00 00 00 00 00
00000050  00 00 00 00 10 00 13 50  80 00 00 00 00 00 d0 32

The problem is in scan_dispatch_log() where we call dtl_consumer()
but bail out before incrementing the index.

To fix this I moved dtl_consumer() after the timebase comparison.

Signed-off-by: Anton Blanchard <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
Cc: Yijing Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @antonblanchard @gregkh
    antonblanchard authored and gregkh committed Jul 9, 2014
    Configuration menu
    Copy the full SHA
    9e1ba6f View commit details
    Browse the repository at this point in the history

  9. ACPI video: ignore BIOS backlight value for HP dm4 

    commit 771d09b upstream.

On a HP Pavilion dm4 laptop the BIOS sets minimum backlight on boot,
completely dimming the screen. Ignore this initial value for this
machine.

Signed-off-by: Gustavo Maciel Dias Vieira <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
[wyj: Backported to 3.4: adjust context]
Signed-off-by: Yijing Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gmdvieira @gregkh
    gmdvieira authored and gregkh committed Jul 9, 2014
    Configuration menu
    Copy the full SHA
    badd9b7 View commit details
    Browse the repository at this point in the history

  10. powerpc/sysfs: Disable writing to PURR in guest mode 

    commit d1211af upstream.

arch/powerpc/kernel/sysfs.c exports PURR with write permission.
This may be valid for kernel in phyp mode. But writing to
the file in guest mode causes crash due to a priviledge violation

Signed-off-by: Madhavan Srinivasan <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
[Backported to 3.4: adjust context]
Signed-off-by: Yijing Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Madhavan Srinivasan authored and gregkh committed Jul 9, 2014
    Configuration menu
    Copy the full SHA
    08ccce4 View commit details
    Browse the repository at this point in the history

  11. hugetlb: fix copy_hugetlb_page_range() to handle migration/hwpoisoned… 

    … entry

commit 4a705fe upstream.

There's a race between fork() and hugepage migration, as a result we try
to "dereference" a swap entry as a normal pte, causing kernel panic.
The cause of the problem is that copy_hugetlb_page_range() can't handle
"swap entry" family (migration entry and hwpoisoned entry) so let's fix
it.

[[email protected]: coding-style fixes]
Signed-off-by: Naoya Horiguchi <[email protected]>
Acked-by: Hugh Dickins <[email protected]>
Cc: Christoph Lameter <[email protected]>
Cc: <[email protected]>	[2.6.37+]
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Naoya Horiguchi authored and gregkh committed Jul 9, 2014
    Configuration menu
    Copy the full SHA
    2bcdd49 View commit details
    Browse the repository at this point in the history

  12. mm: fix crashes from mbind() merging vmas 

    commit d05f0cd upstream.

In v2.6.34 commit 9d8cebd ("mm: fix mbind vma merge problem")
introduced vma merging to mbind(), but it should have also changed the
convention of passing start vma from queue_pages_range() (formerly
check_range()) to new_vma_page(): vma merging may have already freed
that structure, resulting in BUG at mm/mempolicy.c:1738 and probably
worse crashes.

Fixes: 9d8cebd ("mm: fix mbind vma merge problem")
Reported-by: Naoya Horiguchi <[email protected]>
Tested-by: Naoya Horiguchi <[email protected]>
Signed-off-by: Hugh Dickins <[email protected]>
Acked-by: Christoph Lameter <[email protected]>
Cc: KOSAKI Motohiro <[email protected]>
Cc: Minchan Kim <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Hugh Dickins authored and gregkh committed Jul 9, 2014
    Configuration menu
    Copy the full SHA
    50a28ba View commit details
    Browse the repository at this point in the history

  13. Linux 3.4.98

    @gregkh
    gregkh committed Jul 9, 2014
    Configuration menu
    Copy the full SHA
    0bbbf93 View commit details
    Browse the repository at this point in the history

Commits on Jul 16, 2014

  1. usb: gadget: f_accessory: Enabled Zero Length Packet (ZLP) for acc_write 

    Accessory connected to Android Device requires
Zero Length Packet (ZLP) to be written when data
transferred out from the Android device are multiples
of wMaxPacketSize (64bytes (Full-Speed) / 512bytes (High-Speed))
to end the transfer.

Change-Id: Ib2c2c0ab98ef9afa10e74a720142deca5c0ed476
Signed-off-by: Anson Jacob <[email protected]>
    @DextersHub
    DextersHub committed Jul 16, 2014
    Configuration menu
    Copy the full SHA
    e512280 View commit details
    Browse the repository at this point in the history

Commits on Jul 17, 2014

  1. usb: option: Add ID for Telewell TW-LTE 4G v2 

    commit 3d28bd8 upstream.

Add ID of the Telewell 4G v2 hardware to option driver to get legacy
serial interface working

Signed-off-by: Bernd Wachter <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Bernd Wachter authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    fd7afe2 View commit details
    Browse the repository at this point in the history

  2. USB: cp210x: add support for Corsair usb dongle 

    commit b932605 upstream.

Corsair USB Dongles are shipped with Corsair AXi series PSUs.
These are cp210x serial usb devices, so make driver detect these.
I have a program, that can get information from these PSUs.

Tested with 2 different dongles shipped with Corsair AX860i and
AX1200i units.

Signed-off-by: Andras Kovacs <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @ka87 @gregkh
    ka87 authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    d45a238 View commit details
    Browse the repository at this point in the history

  3. USB: ftdi_sio: Add extra PID. 

    commit 5a7fbe7 upstream.

This patch adds PID 0x0003 to the VID 0x128d (Testo). At least the
Testo 435-4 uses this, likely other gear as well.

Signed-off-by: Bert Vermeulen <[email protected]>
Cc: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @biot @gregkh
    biot authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    d06191b View commit details
    Browse the repository at this point in the history

  4. cpuset,mempolicy: fix sleeping function called from invalid context 

    commit 391acf9 upstream.

When runing with the kernel(3.15-rc7+), the follow bug occurs:
[ 9969.258987] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586
[ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name: python
[ 9969.441175] INFO: lockdep is turned off.
[ 9969.488184] CPU: 26 PID: 160655 Comm: python Tainted: G       A      3.15.0-rc7+ #85
[ 9969.581032] Hardware name: FUJITSU-SV PRIMEQUEST 1800E/SB, BIOS PRIMEQUEST 1000 Series BIOS Version 1.39 11/16/2012
[ 9969.706052]  ffffffff81a20e60 ffff8803e941fbd0 ffffffff8162f523 ffff8803e941fd18
[ 9969.795323]  ffff8803e941fbe0 ffffffff8109995a ffff8803e941fc58 ffffffff81633e6c
[ 9969.884710]  ffffffff811ba5dc ffff880405c6b480 ffff88041fdd90a0 0000000000002000
[ 9969.974071] Call Trace:
[ 9970.003403]  [<ffffffff8162f523>] dump_stack+0x4d/0x66
[ 9970.065074]  [<ffffffff8109995a>] __might_sleep+0xfa/0x130
[ 9970.130743]  [<ffffffff81633e6c>] mutex_lock_nested+0x3c/0x4f0
[ 9970.200638]  [<ffffffff811ba5dc>] ? kmem_cache_alloc+0x1bc/0x210
[ 9970.272610]  [<ffffffff81105807>] cpuset_mems_allowed+0x27/0x140
[ 9970.344584]  [<ffffffff811b1303>] ? __mpol_dup+0x63/0x150
[ 9970.409282]  [<ffffffff811b1385>] __mpol_dup+0xe5/0x150
[ 9970.471897]  [<ffffffff811b1303>] ? __mpol_dup+0x63/0x150
[ 9970.536585]  [<ffffffff81068c86>] ? copy_process.part.23+0x606/0x1d40
[ 9970.613763]  [<ffffffff810bf28d>] ? trace_hardirqs_on+0xd/0x10
[ 9970.683660]  [<ffffffff810ddddf>] ? monotonic_to_bootbased+0x2f/0x50
[ 9970.759795]  [<ffffffff81068cf0>] copy_process.part.23+0x670/0x1d40
[ 9970.834885]  [<ffffffff8106a598>] do_fork+0xd8/0x380
[ 9970.894375]  [<ffffffff81110e4c>] ? __audit_syscall_entry+0x9c/0xf0
[ 9970.969470]  [<ffffffff8106a8c6>] SyS_clone+0x16/0x20
[ 9971.030011]  [<ffffffff81642009>] stub_clone+0x69/0x90
[ 9971.091573]  [<ffffffff81641c29>] ? system_call_fastpath+0x16/0x1b

The cause is that cpuset_mems_allowed() try to take
mutex_lock(&callback_mutex) under the rcu_read_lock(which was hold in
__mpol_dup()). And in cpuset_mems_allowed(), the access to cpuset is
under rcu_read_lock, so in __mpol_dup, we can reduce the rcu_read_lock
protection region to protect the access to cpuset only in
current_cpuset_is_being_rebound(). So that we can avoid this bug.

This patch is a temporary solution that just addresses the bug
mentioned above, can not fix the long-standing issue about cpuset.mems
rebinding on fork():

"When the forker's task_struct is duplicated (which includes
 ->mems_allowed) and it races with an update to cpuset_being_rebound
 in update_tasks_nodemask() then the task's mems_allowed doesn't get
 updated. And the child task's mems_allowed can be wrong if the
 cpuset's nodemask changes before the child has been added to the
 cgroup's tasklist."

Signed-off-by: Gu Zheng <[email protected]>
Acked-by: Li Zefan <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Gu Zheng authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    f54e041 View commit details
    Browse the repository at this point in the history

  5. hwmon: (amc6821) Fix permissions for temp2_input 

    commit df86754 upstream.

temp2_input should not be writable, fix it.

Reported-by: Guenter Roeck <[email protected]>
Signed-off-by: Axel Lin <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @AxelLin @gregkh
    AxelLin authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    5cc80fb View commit details
    Browse the repository at this point in the history

  6. hwmon: (adm1029) Ensure the fan_div cache is updated in set_fan_div 

    commit 1035a9e upstream.

Writing to fanX_div does not clear the cache. As a result, reading
from fanX_div may return the old value for up to two seconds
after writing a new value.

This patch ensures the fan_div cache is updated in set_fan_div().

Reported-by: Guenter Roeck <[email protected]>
Signed-off-by: Axel Lin <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @AxelLin @gregkh
    AxelLin authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    30bbd39 View commit details
    Browse the repository at this point in the history

  7. powerpc/perf: Never program book3s PMCs with values >= 0x80000000 

    commit f560294 upstream.

We are seeing a lot of PMU warnings on POWER8:

    Can't find PMC that caused IRQ

Looking closer, the active PMC is 0 at this point and we took a PMU
exception on the transition from negative to 0. Some versions of POWER8
have an issue where they edge detect and not level detect PMC overflows.

A number of places program the PMC with (0x80000000 - period_left),
where period_left can be negative. We can either fix all of these or
just ensure that period_left is always >= 1.

This patch takes the second option.

Signed-off-by: Anton Blanchard <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @antonblanchard @gregkh
    antonblanchard authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    7b9eab8 View commit details
    Browse the repository at this point in the history

  8. ext4: clarify error count warning messages 

    commit ae0f78d upstream.

Make it clear that values printed are times, and that it is error
since last fsck. Also add note about fsck version required.

Signed-off-by: Pavel Machek <[email protected]>
Signed-off-by: Theodore Ts'o <[email protected]>
Reviewed-by: Andreas Dilger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @tytso @gregkh
    tytso authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    ef01826 View commit details
    Browse the repository at this point in the history

  9. drm/radeon: stop poisoning the GART TLB 

    commit 0986c1a upstream.

When we set the valid bit on invalid GART entries they are
loaded into the TLB when an adjacent entry is loaded. This
poisons the TLB with invalid entries which are sometimes
not correctly removed on TLB flush.

For stable inclusion the patch probably needs to be modified a bit.

Signed-off-by: Christian König <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @ChristianKoenigAMD @gregkh
    ChristianKoenigAMD authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    fa1bd9b View commit details
    Browse the repository at this point in the history

  10. tracing: Remove ftrace_stop/start() from reading the trace file 

    commit 099ed15 upstream.

Disabling reading and writing to the trace file should not be able to
disable all function tracing callbacks. There's other users today
(like kprobes and perf). Reading a trace file should not stop those
from happening.

Reviewed-by: Masami Hiramatsu <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @rostedt @gregkh
    rostedt authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    bf09db9 View commit details
    Browse the repository at this point in the history

  11. rtmutex: Fix deadlock detector for real 

    commit 397335f upstream.

The current deadlock detection logic does not work reliably due to the
following early exit path:

	/*
	 * Drop out, when the task has no waiters. Note,
	 * top_waiter can be NULL, when we are in the deboosting
	 * mode!
	 */
	if (top_waiter && (!task_has_pi_waiters(task) ||
			   top_waiter != task_top_pi_waiter(task)))
		goto out_unlock_pi;

So this not only exits when the task has no waiters, it also exits
unconditionally when the current waiter is not the top priority waiter
of the task.

So in a nested locking scenario, it might abort the lock chain walk
and therefor miss a potential deadlock.

Simple fix: Continue the chain walk, when deadlock detection is
enabled.

We also avoid the whole enqueue, if we detect the deadlock right away
(A-A). It's an optimization, but also prevents that another waiter who
comes in after the detection and before the task has undone the damage
observes the situation and detects the deadlock and returns
-EDEADLOCK, which is wrong as the other task is not in a deadlock
situation.

Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Reviewed-by: Steven Rostedt <[email protected]>
Cc: Lai Jiangshan <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Mike Galbraith <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @KAGA-KOKO @gregkh
    KAGA-KOKO authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    90b421b View commit details
    Browse the repository at this point in the history

  12. rtmutex: Detect changes in the pi lock chain 

    commit 8208498 upstream.

When we walk the lock chain, we drop all locks after each step. So the
lock chain can change under us before we reacquire the locks. That's
harmless in principle as we just follow the wrong lock path. But it
can lead to a false positive in the dead lock detection logic:

T0 holds L0
T0 blocks on L1 held by T1
T1 blocks on L2 held by T2
T2 blocks on L3 held by T3
T4 blocks on L4 held by T4

Now we walk the chain

lock T1 -> lock L2 -> adjust L2 -> unlock T1 ->
     lock T2 ->  adjust T2 ->  drop locks

T2 times out and blocks on L0

Now we continue:

lock T2 -> lock L0 -> deadlock detected, but it's not a deadlock at all.

Brad tried to work around that in the deadlock detection logic itself,
but the more I looked at it the less I liked it, because it's crystal
ball magic after the fact.

We actually can detect a chain change very simple:

lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 ->

     next_lock = T2->pi_blocked_on->lock;

drop locks

T2 times out and blocks on L0

Now we continue:

lock T2 ->

     if (next_lock != T2->pi_blocked_on->lock)
     	   return;

So if we detect that T2 is now blocked on a different lock we stop the
chain walk. That's also correct in the following scenario:

lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 ->

     next_lock = T2->pi_blocked_on->lock;

drop locks

T3 times out and drops L3
T2 acquires L3 and blocks on L4 now

Now we continue:

lock T2 ->

     if (next_lock != T2->pi_blocked_on->lock)
     	   return;

We don't have to follow up the chain at that point, because T2
propagated our priority up to T4 already.

[ Folded a cleanup patch from peterz ]

Signed-off-by: Thomas Gleixner <[email protected]>
Reported-by: Brad Mouring <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Mike Galbraith <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @KAGA-KOKO @gregkh
    KAGA-KOKO authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    307e2e0 View commit details
    Browse the repository at this point in the history

  13. rtmutex: Handle deadlock detection smarter 

    commit 3d5c934 upstream.

Even in the case when deadlock detection is not requested by the
caller, we can detect deadlocks. Right now the code stops the lock
chain walk and keeps the waiter enqueued, even on itself. Silly not to
yell when such a scenario is detected and to keep the waiter enqueued.

Return -EDEADLK unconditionally and handle it at the call sites.

The futex calls return -EDEADLK. The non futex ones dequeue the
waiter, throw a warning and put the task into a schedule loop.

Tagged for stable as it makes the code more robust.

Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Brad Mouring <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Mike Galbraith <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @KAGA-KOKO @gregkh
    KAGA-KOKO authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    ea018da View commit details
    Browse the repository at this point in the history

  14. rtmutex: Plug slow unlock race 

    commit 27e3571 upstream.

When the rtmutex fast path is enabled the slow unlock function can
create the following situation:

spin_lock(foo->m->wait_lock);
foo->m->owner = NULL;
	    			rt_mutex_lock(foo->m); <-- fast path
				free = atomic_dec_and_test(foo->refcnt);
				rt_mutex_unlock(foo->m); <-- fast path
				if (free)
				   kfree(foo);

spin_unlock(foo->m->wait_lock); <--- Use after free.

Plug the race by changing the slow unlock to the following scheme:

     while (!rt_mutex_has_waiters(m)) {
     	    /* Clear the waiters bit in m->owner */
	    clear_rt_mutex_waiters(m);
      	    owner = rt_mutex_owner(m);
      	    spin_unlock(m->wait_lock);
      	    if (cmpxchg(m->owner, owner, 0) == owner)
      	       return;
      	    spin_lock(m->wait_lock);
     }

So in case of a new waiter incoming while the owner tries the slow
path unlock we have two situations:

 unlock(wait_lock);
					lock(wait_lock);
 cmpxchg(p, owner, 0) == owner
 	    	   			mark_rt_mutex_waiters(lock);
	 				acquire(lock);

Or:

 unlock(wait_lock);
					lock(wait_lock);
	 				mark_rt_mutex_waiters(lock);
 cmpxchg(p, owner, 0) != owner
					enqueue_waiter();
					unlock(wait_lock);
 lock(wait_lock);
 wakeup_next waiter();
 unlock(wait_lock);
					lock(wait_lock);
					acquire(lock);

If the fast path is disabled, then the simple

   m->owner = NULL;
   unlock(m->wait_lock);

is sufficient as all access to m->owner is serialized via
m->wait_lock;

Also document and clarify the wakeup_next_waiter function as suggested
by Oleg Nesterov.

Reported-by: Steven Rostedt <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Steven Rostedt <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Mike Galbraith <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @KAGA-KOKO @gregkh
    KAGA-KOKO authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    2a77794 View commit details
    Browse the repository at this point in the history

  15. x86, ioremap: Speed up check for RAM pages 

    commit c81c8a1 upstream.

In __ioremap_caller() (the guts of ioremap), we loop over the range of
pfns being remapped and checks each one individually with page_is_ram().
For large ioremaps, this can be very slow.  For example, we have a
device with a 256 GiB PCI BAR, and ioremapping this BAR can take 20+
seconds -- sometimes long enough to trigger the soft lockup detector!

Internally, page_is_ram() calls walk_system_ram_range() on a single
page.  Instead, we can make a single call to walk_system_ram_range()
from __ioremap_caller(), and do our further checks only for any RAM
pages that we find.  For the common case of MMIO, this saves an enormous
amount of work, since the range being ioremapped doesn't intersect
system RAM at all.

With this change, ioremap on our 256 GiB BAR takes less than 1 second.

Signed-off-by: Roland Dreier <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @rolandd @gregkh
    rolandd authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    d824be9 View commit details
    Browse the repository at this point in the history

  16. ACPI / battery: Retry to get battery information if failed during pro… 

    …bing

commit 75646e7 upstream.

Some machines (eg. Lenovo Z480) ECs are not stable during boot up
and causes battery driver fails to be loaded due to failure of getting
battery information from EC sometimes. After several retries, the
operation will work. This patch is to retry to get battery information 5
times if the first try fails.

[ backport to 3.14.5: removed second parameter in acpi_battery_update(),
introduced by the commit 9e50bc1 (ACPI /
battery: Accelerate battery resume callback)]

[naszar <[email protected]>: backport to 3.14.5]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=75581
Reported-and-tested-by: naszar <[email protected]>
Cc: All applicable <[email protected]>
Signed-off-by: Lan Tianyu <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Lan Tianyu authored and gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    cd0c28d View commit details
    Browse the repository at this point in the history

  17. Linux 3.4.99

    @gregkh
    gregkh committed Jul 17, 2014
    Configuration menu
    Copy the full SHA
    0758142 View commit details
    Browse the repository at this point in the history

Commits on Jul 21, 2014

  1. cgroup: Take css_set_lock from cgroup_css_sets_empty() 

    As indicated in the comment above cgroup_css_sets_empty it needs the
css_set_lock. But neither of the 2 call points have it, so rather then fixing
the callers just take the lock inside cgroup_css_sets_empty().

Signed-off-by: Hans de Goede <[email protected]>
Change-Id: If7aea71824f6d0e3f2cc6c1ce236c3ae6be2037b
    @jwrdegoede @colincross
    jwrdegoede authored and colincross committed Jul 21, 2014
    Configuration menu
    Copy the full SHA
    192ccd0 View commit details
    Browse the repository at this point in the history

  2. cgroup: Fix use after free of cgrp (cgrp->css_sets) 

    Running a 3.4 kernel + Fedora-18 (systemd) userland on my Allwinner A10
(arm cortex a8), I'm seeing repeated, reproducable list_del list corruption
errors when build with CONFIG_DEBUG_LIST, and the backtrace always shows
free_css_set_work as the function making the problematic list_del call.

I've tracked this doen to a use after free of the cgrp struct, specifically
of the cgrp->css_sets list_head, which gets cleared by free_css_set_work.

Since free_css_set_work runs form a workqueue, it is possible for it to not be
done with clearing the list when the cgrp gets free-ed. To avoid this the code
adding the links increases cgrp->count, and the freeing code running from the
workqueue decreases cgrp->count *after* doing list_del, and then if the count
goes to 0 calls cgroup_wakeup_rmdir_waiter().

However cgroup_rmdir() is missing a check for cgrp->count != 0, causing it
to still continue with the rmdir (which leads to the free-ing of the cgrp),
before free_css_set_work is done. Sometimes the free-ed memory is re-used
before free_css_set_work gets around to unlinking link->cgrp_link_list,
triggering the list_del list corruption messages.

This patch fixes this by properly checking for cgrp->count != 0 and waiting
for the cgroup_rmdir_waitq in that case.

Change-Id: I9dbc02a0a75d5dffa1b65d67456e00139dea57c3
Signed-off-by: Hans de Goede <[email protected]>
    @jwrdegoede @colincross
    jwrdegoede authored and colincross committed Jul 21, 2014
    Configuration menu
    Copy the full SHA
    b519f21 View commit details
    Browse the repository at this point in the history

Commits on Jul 23, 2014

  1. Revert "s3c2410_wdt: Add locking to cpu frequency transition notifier" 

    This reverts commit 037e771.

Change-Id: I32a81c1fb2d9ac2eb8570438699e8f9ff01f4c93
    Mark Salyzyn committed Jul 23, 2014
    Configuration menu
    Copy the full SHA
    1d9dbe3 View commit details
    Browse the repository at this point in the history

Commits on Jul 24, 2014

  1. usb: gadget: f_audio_source: change max ISO packet size 

    Re-applying from
https://gitorious.org/shr/linux/commit/eb4c9d2db894c3492c0a848581bd4f6790f93d5f

Most USB-AUDIO devices are limited to 256 byte for max iso buffer size.
If a IN_EP_MAX_PACKET_SIZE is bigger than a USB-AUDIO device's max iso
buffer size, it will cause noise. This patch will prevent this case as
possibe by reducing packet size. When using 44.1khz, 2ch, 16bit audio
data, if max packet size is bigger than 176 bytes, it's no problem.

Credits to: Iliyan Malchev <[email protected]>

Change-Id: I61435bc9ad7ab05faba16cf80bfb9ff0431c3002
Signed-off-by: Anson Jacob <[email protected]>
    @DextersHub
    DextersHub authored and Badhri Jagan Sridharan committed Jul 24, 2014
    Configuration menu
    Copy the full SHA
    a4c9d98 View commit details
    Browse the repository at this point in the history

Commits on Jul 25, 2014

  1. usb: gadget: f_audio_source: Fixed USB Audio Class Interface Descriptor 

    Fixed Android Issue #56549.

When both Vendor Class and Audio Class are activated for AOA 2.0,
the baInterfaceNr of the AudioControl Interface Descriptor points
to wrong interface numbers. They should be pointing to
Audio Control Device and Audio Streaming interfaces.

Replaced baInterfaceNr with the correct value.

Change-Id: Ib20f20c1d65887bac051b7ff9453dc53fc23a8d0
Signed-off-by: Anson Jacob <[email protected]>
    @DextersHub
    DextersHub authored and Badhri Jagan Sridharan committed Jul 25, 2014
    Configuration menu
    Copy the full SHA
    5901dd6 View commit details
    Browse the repository at this point in the history

  2. net: wireless: bcmdhd: Add support for hidden ssid PNO scan 

    Changes to support hidden ssid config to be sent to FW. Earlier
all ssids were hard coded as hidden, now only those indicated
as such by supplicant will be.

Change-Id: I927030fe12f162c52c93277b2ebfb4bf55daef4a
Signed-off-by: Ashwin <[email protected]>
    Ashwin authored and Dmitry Shmidt committed Jul 25, 2014
    Configuration menu
    Copy the full SHA
    c4651bd View commit details
    Browse the repository at this point in the history

Commits on Jul 28, 2014

  1. crypto: testmgr - update LZO compression test vectors 

    commit 0ec7382 upstream.

Update the LZO compression test vectors according to the latest compressor
version.

Signed-off-by: Markus F.X.J. Oberhumer <[email protected]>
Cc: Derrick Pallas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @markus-oberhumer @gregkh
    markus-oberhumer authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    64fb4e2 View commit details
    Browse the repository at this point in the history

  2. shmem: fix faulting into a hole while it's punched 

    commit f00cdc6 upstream.

Trinity finds that mmap access to a hole while it's punched from shmem
can prevent the madvise(MADV_REMOVE) or fallocate(FALLOC_FL_PUNCH_HOLE)
from completing, until the reader chooses to stop; with the puncher's
hold on i_mutex locking out all other writers until it can complete.

It appears that the tmpfs fault path is too light in comparison with its
hole-punching path, lacking an i_data_sem to obstruct it; but we don't
want to slow down the common case.

Extend shmem_fallocate()'s existing range notification mechanism, so
shmem_fault() can refrain from faulting pages into the hole while it's
punched, waiting instead on i_mutex (when safe to sleep; or repeatedly
faulting when not).

[[email protected]: coding-style fixes]
Signed-off-by: Hugh Dickins <[email protected]>
Reported-by: Sasha Levin <[email protected]>
Tested-by: Sasha Levin <[email protected]>
Cc: Dave Jones <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Hugh Dickins authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    a62f374 View commit details
    Browse the repository at this point in the history

  3. shmem: fix faulting into a hole, not taking i_mutex 

    commit 8e205f7 upstream.

Commit f00cdc6 ("shmem: fix faulting into a hole while it's
punched") was buggy: Sasha sent a lockdep report to remind us that
grabbing i_mutex in the fault path is a no-no (write syscall may already
hold i_mutex while faulting user buffer).

We tried a completely different approach (see following patch) but that
proved inadequate: good enough for a rational workload, but not good
enough against trinity - which forks off so many mappings of the object
that contention on i_mmap_mutex while hole-puncher holds i_mutex builds
into serious starvation when concurrent faults force the puncher to fall
back to single-page unmap_mapping_range() searches of the i_mmap tree.

So return to the original umbrella approach, but keep away from i_mutex
this time.  We really don't want to bloat every shmem inode with a new
mutex or completion, just to protect this unlikely case from trinity.
So extend the original with wait_queue_head on stack at the hole-punch
end, and wait_queue item on the stack at the fault end.

This involves further use of i_lock to guard against the races: lockdep
has been happy so far, and I see fs/inode.c:unlock_new_inode() holds
i_lock around wake_up_bit(), which is comparable to what we do here.
i_lock is more convenient, but we could switch to shmem's info->lock.

This issue has been tagged with CVE-2014-4171, which will require commit
f00cdc6 and this and the following patch to be backported: we
suggest to 3.1+, though in fact the trinity forkbomb effect might go
back as far as 2.6.16, when madvise(,,MADV_REMOVE) came in - or might
not, since much has changed, with i_mmap_mutex a spinlock before 3.0.
Anyone running trinity on 3.0 and earlier? I don't think we need care.

Signed-off-by: Hugh Dickins <[email protected]>
Reported-by: Sasha Levin <[email protected]>
Tested-by: Sasha Levin <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: Konstantin Khlebnikov <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Lukas Czerner <[email protected]>
Cc: Dave Jones <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Hugh Dickins authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    0f5a4a0 View commit details
    Browse the repository at this point in the history

  4. shmem: fix splicing from a hole while it's punched 

    commit b1a3665 upstream.

shmem_fault() is the actual culprit in trinity's hole-punch starvation,
and the most significant cause of such problems: since a page faulted is
one that then appears page_mapped(), needing unmap_mapping_range() and
i_mmap_mutex to be unmapped again.

But it is not the only way in which a page can be brought into a hole in
the radix_tree while that hole is being punched; and Vlastimil's testing
implies that if enough other processors are busy filling in the hole,
then shmem_undo_range() can be kept from completing indefinitely.

shmem_file_splice_read() is the main other user of SGP_CACHE, which can
instantiate shmem pagecache pages in the read-only case (without holding
i_mutex, so perhaps concurrently with a hole-punch).  Probably it's
silly not to use SGP_READ already (using the ZERO_PAGE for holes): which
ought to be safe, but might bring surprises - not a change to be rushed.

shmem_read_mapping_page_gfp() is an internal interface used by
drivers/gpu/drm GEM (and next by uprobes): it should be okay.  And
shmem_file_read_iter() uses the SGP_DIRTY variant of SGP_CACHE, when
called internally by the kernel (perhaps for a stacking filesystem,
which might rely on holes to be reserved): it's unclear whether it could
be provoked to keep hole-punch busy or not.

We could apply the same umbrella as now used in shmem_fault() to
shmem_file_splice_read() and the others; but it looks ugly, and use over
a range raises questions - should it actually be per page? can these get
starved themselves?

The origin of this part of the problem is my v3.1 commit d082357
("mm: pincer in truncate_inode_pages_range"), once it was duplicated
into shmem.c.  It seemed like a nice idea at the time, to ensure
(barring RCU lookup fuzziness) that there's an instant when the entire
hole is empty; but the indefinitely repeated scans to ensure that make
it vulnerable.

Revert that "enhancement" to hole-punch from shmem_undo_range(), but
retain the unproblematic rescanning when it's truncating; add a couple
of comments there.

Remove the "indices[0] >= end" test: that is now handled satisfactorily
by the inner loop, and mem_cgroup_uncharge_start()/end() are too light
to be worth avoiding here.

But if we do not always loop indefinitely, we do need to handle the case
of swap swizzled back to page before shmem_free_swap() gets it: add a
retry for that case, as suggested by Konstantin Khlebnikov; and for the
case of page swizzled back to swap, as suggested by Johannes Weiner.

Signed-off-by: Hugh Dickins <[email protected]>
Reported-by: Sasha Levin <[email protected]>
Suggested-by: Vlastimil Babka <[email protected]>
Cc: Konstantin Khlebnikov <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Lukas Czerner <[email protected]>
Cc: Dave Jones <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Hugh Dickins authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    21618a8 View commit details
    Browse the repository at this point in the history

  5. tcp: fix tcp_match_skb_to_sack() for unaligned SACK at end of an skb 

    [ Upstream commit 2cd0d74 ]

If there is an MSS change (or misbehaving receiver) that causes a SACK
to arrive that covers the end of an skb but is less than one MSS, then
tcp_match_skb_to_sack() was rounding up pkt_len to the full length of
the skb ("Round if necessary..."), then chopping all bytes off the skb
and creating a zero-byte skb in the write queue.

This was visible now because the recently simplified TLP logic in
bef1909 ("tcp: fixing TLP's FIN recovery") could find that 0-byte
skb at the end of the write queue, and now that we do not check that
skb's length we could send it as a TLP probe.

Consider the following example scenario:

 mss: 1000
 skb: seq: 0 end_seq: 4000  len: 4000
 SACK: start_seq: 3999 end_seq: 4000

The tcp_match_skb_to_sack() code will compute:

 in_sack = false
 pkt_len = start_seq - TCP_SKB_CB(skb)->seq = 3999 - 0 = 3999
 new_len = (pkt_len / mss) * mss = (3999/1000)*1000 = 3000
 new_len += mss = 4000

Previously we would find the new_len > skb->len check failing, so we
would fall through and set pkt_len = new_len = 4000 and chop off
pkt_len of 4000 from the 4000-byte skb, leaving a 0-byte segment
afterward in the write queue.

With this new commit, we notice that the new new_len >= skb->len check
succeeds, so that we return without trying to fragment.

Fixes: adb92db ("tcp: Make SACK code to split only at mss boundaries")
Reported-by: Eric Dumazet <[email protected]>
Signed-off-by: Neal Cardwell <[email protected]>
Cc: Eric Dumazet <[email protected]>
Cc: Yuchung Cheng <[email protected]>
Cc: Ilpo Jarvinen <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @nealcardwell @gregkh
    nealcardwell authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    06c84e9 View commit details
    Browse the repository at this point in the history

  6. 8021q: fix a potential memory leak 

    [ Upstream commit 916c168 ]

skb_cow called in vlan_reorder_header does not free the skb when it failed,
and vlan_reorder_header returns NULL to reset original skb when it is called
in vlan_untag, lead to a memory leak.

Signed-off-by: Li RongQing <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Li RongQing authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    d7f5473 View commit details
    Browse the repository at this point in the history

  7. igmp: fix the problem when mc leave group 

    [ Upstream commit 52ad353 ]

The problem was triggered by these steps:

1) create socket, bind and then setsockopt for add mc group.
   mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37");
   mreq.imr_interface.s_addr = inet_addr("192.168.1.2");
   setsockopt(sockfd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));

2) drop the mc group for this socket.
   mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37");
   mreq.imr_interface.s_addr = inet_addr("0.0.0.0");
   setsockopt(sockfd, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));

3) and then drop the socket, I found the mc group was still used by the dev:

   netstat -g

   Interface       RefCnt Group
   --------------- ------ ---------------------
   eth2		   1	  255.0.0.37

Normally even though the IP_DROP_MEMBERSHIP return error, the mc group still need
to be released for the netdev when drop the socket, but this process was broken when
route default is NULL, the reason is that:

The ip_mc_leave_group() will choose the in_dev by the imr_interface.s_addr, if input addr
is NULL, the default route dev will be chosen, then the ifindex is got from the dev,
then polling the inet->mc_list and return -ENODEV, but if the default route dev is NULL,
the in_dev and ifIndex is both NULL, when polling the inet->mc_list, the mc group will be
released from the mc_list, but the dev didn't dec the refcnt for this mc group, so
when dropping the socket, the mc_list is NULL and the dev still keep this group.

v1->v2: According Hideaki's suggestion, we should align with IPv6 (RFC3493) and BSDs,
	so I add the checking for the in_dev before polling the mc_list, make sure when
	we remove the mc group, dec the refcnt to the real dev which was using the mc address.
	The problem would never happened again.

Signed-off-by: Ding Tianhong <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @dingtianhong @gregkh
    dingtianhong authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    fbaf3a0 View commit details
    Browse the repository at this point in the history

  8. tcp: fix false undo corner cases 

    [ Upstream commit 6e08d5e ]

The undo code assumes that, upon entering loss recovery, TCP
1) always retransmit something
2) the retransmission never fails locally (e.g., qdisc drop)

so undo_marker is set in tcp_enter_recovery() and undo_retrans is
incremented only when tcp_retransmit_skb() is successful.

When the assumption is broken because TCP's cwnd is too small to
retransmit or the retransmit fails locally. The next (DUP)ACK
would incorrectly revert the cwnd and the congestion state in
tcp_try_undo_dsack() or tcp_may_undo(). Subsequent (DUP)ACKs
may enter the recovery state. The sender repeatedly enter and
(incorrectly) exit recovery states if the retransmits continue to
fail locally while receiving (DUP)ACKs.

The fix is to initialize undo_retrans to -1 and start counting on
the first retransmission. Always increment undo_retrans even if the
retransmissions fail locally because they couldn't cause DSACKs to
undo the cwnd reduction.

Signed-off-by: Yuchung Cheng <[email protected]>
Signed-off-by: Neal Cardwell <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @yuchungcheng @gregkh
    yuchungcheng authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    f37e491 View commit details
    Browse the repository at this point in the history

  9. appletalk: Fix socket referencing in skb 

    [ Upstream commit 36beddc ]

Setting just skb->sk without taking its reference and setting a
destructor is invalid. However, in the places where this was done, skb
is used in a way not requiring skb->sk setting. So dropping the setting
of skb->sk.
Thanks to Eric Dumazet <[email protected]> for correct solution.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79441
Reported-by: Ed Martin <[email protected]>
Signed-off-by: Andrey Utkin <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Andrey Utkin authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    3fa1f50 View commit details
    Browse the repository at this point in the history

  10. be2net: set EQ DB clear-intr bit in be_open() 

    [ Upstream commit 4cad9f3 ]

On BE3, if the clear-interrupt bit of the EQ doorbell is not set the first
time it is armed, ocassionally we have observed that the EQ doesn't raise
anymore interrupts even if it is in armed state.
This patch fixes this by setting the clear-interrupt bit when EQs are
armed for the first time in be_open().

Signed-off-by: Suresh Reddy <[email protected]>
Signed-off-by: Sathya Perla <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Suresh Reddy authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    3c656d4 View commit details
    Browse the repository at this point in the history

  11. tipc: clear 'next'-pointer of message fragments before reassembly 

    [ Upstream commit 9994175 ]

If the 'next' pointer of the last fragment buffer in a message is not
zeroed before reassembly, we risk ending up with a corrupt message,
since the reassembly function itself isn't doing this.

Currently, when a buffer is retrieved from the deferred queue of the
broadcast link, the next pointer is not cleared, with the result as
described above.

This commit corrects this, and thereby fixes a bug that may occur when
long broadcast messages are transmitted across dual interfaces. The bug
has been present since 40ba3cd ("tipc:
message reassembly using fragment chain")

This commit should be applied to both net and net-next.

Signed-off-by: Jon Maloy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Jon Paul Maloy authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    d1558f7 View commit details
    Browse the repository at this point in the history

  12. net: sctp: fix information leaks in ulpevent layer 

    [ Upstream commit 8f2e5ae ]

While working on some other SCTP code, I noticed that some
structures shared with user space are leaking uninitialized
stack or heap buffer. In particular, struct sctp_sndrcvinfo
has a 2 bytes hole between .sinfo_flags and .sinfo_ppid that
remains unfilled by us in sctp_ulpevent_read_sndrcvinfo() when
putting this into cmsg. But also struct sctp_remote_error
contains a 2 bytes hole that we don't fill but place into a skb
through skb_copy_expand() via sctp_ulpevent_make_remote_error().

Both structures are defined by the IETF in RFC6458:

* Section 5.3.2. SCTP Header Information Structure:

  The sctp_sndrcvinfo structure is defined below:

  struct sctp_sndrcvinfo {
    uint16_t sinfo_stream;
    uint16_t sinfo_ssn;
    uint16_t sinfo_flags;
    <-- 2 bytes hole  -->
    uint32_t sinfo_ppid;
    uint32_t sinfo_context;
    uint32_t sinfo_timetolive;
    uint32_t sinfo_tsn;
    uint32_t sinfo_cumtsn;
    sctp_assoc_t sinfo_assoc_id;
  };

* 6.1.3. SCTP_REMOTE_ERROR:

  A remote peer may send an Operation Error message to its peer.
  This message indicates a variety of error conditions on an
  association. The entire ERROR chunk as it appears on the wire
  is included in an SCTP_REMOTE_ERROR event. Please refer to the
  SCTP specification [RFC4960] and any extensions for a list of
  possible error formats. An SCTP error notification has the
  following format:

  struct sctp_remote_error {
    uint16_t sre_type;
    uint16_t sre_flags;
    uint32_t sre_length;
    uint16_t sre_error;
    <-- 2 bytes hole  -->
    sctp_assoc_t sre_assoc_id;
    uint8_t  sre_data[];
  };

Fix this by setting both to 0 before filling them out. We also
have other structures shared between user and kernel space in
SCTP that contains holes (e.g. struct sctp_paddrthlds), but we
copy that buffer over from user space first and thus don't need
to care about it in that cases.

While at it, we can also remove lengthy comments copied from
the draft, instead, we update the comment with the correct RFC
number where one can look it up.

Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Daniel Borkmann authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    9de2be6 View commit details
    Browse the repository at this point in the history

  13. net: pppoe: use correct channel MTU when using Multilink PPP 

    [ Upstream commit a8a3e41 ]

The PPP channel MTU is used with Multilink PPP when ppp_mp_explode() (see
ppp_generic module) tries to determine how big a fragment might be. According
to RFC 1661, the MTU excludes the 2-byte PPP protocol field, see the
corresponding comment and code in ppp_mp_explode():

		/*
		 * hdrlen includes the 2-byte PPP protocol field, but the
		 * MTU counts only the payload excluding the protocol field.
		 * (RFC1661 Section 2)
		 */
		mtu = pch->chan->mtu - (hdrlen - 2);

However, the pppoe module *does* include the PPP protocol field in the channel
MTU, which is wrong as it causes the PPP payload to be 1-2 bytes too big under
certain circumstances (one byte if PPP protocol compression is used, two
otherwise), causing the generated Ethernet packets to be dropped. So the pppoe
module has to subtract two bytes from the channel MTU. This error only
manifests itself when using Multilink PPP, as otherwise the channel MTU is not
used anywhere.

In the following, I will describe how to reproduce this bug. We configure two
pppd instances for multilink PPP over two PPPoE links, say eth2 and eth3, with
a MTU of 1492 bytes for each link and a MRRU of 2976 bytes. (This MRRU is
computed by adding the two link MTUs and subtracting the MP header twice, which
is 4 bytes long.) The necessary pppd statements on both sides are "multilink
mtu 1492 mru 1492 mrru 2976". On the client side, we additionally need "plugin
rp-pppoe.so eth2" and "plugin rp-pppoe.so eth3", respectively; on the server
side, we additionally need to start two pppoe-server instances to be able to
establish two PPPoE sessions, one over eth2 and one over eth3. We set the MTU
of the PPP network interface to the MRRU (2976) on both sides of the connection
in order to make use of the higher bandwidth. (If we didn't do that, IP
fragmentation would kick in, which we want to avoid.)

Now we send a ICMPv4 echo request with a payload of 2948 bytes from client to
server over the PPP link. This results in the following network packet:

   2948 (echo payload)
 +    8 (ICMPv4 header)
 +   20 (IPv4 header)
---------------------
   2976 (PPP payload)

These 2976 bytes do not exceed the MTU of the PPP network interface, so the
IP packet is not fragmented. Now the multilink PPP code in ppp_mp_explode()
prepends one protocol byte (0x21 for IPv4), making the packet one byte bigger
than the negotiated MRRU. So this packet would have to be divided in three
fragments. But this does not happen as each link MTU is assumed to be two bytes
larger. So this packet is diveded into two fragments only, one of size 1489 and
one of size 1488. Now we have for that bigger fragment:

   1489 (PPP payload)
 +    4 (MP header)
 +    2 (PPP protocol field for the MP payload (0x3d))
 +    6 (PPPoE header)
--------------------------
   1501 (Ethernet payload)

This packet exceeds the link MTU and is discarded.

If one configures the link MTU on the client side to 1501, one can see the
discarded Ethernet frames with tcpdump running on the client. A

ping -s 2948 -c 1 192.168.15.254

leads to the smaller fragment that is correctly received on the server side:

(tcpdump -vvvne -i eth3 pppoes and ppp proto 0x3d)
52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
  length 1514: PPPoE  [ses 0x3] MLPPP (0x003d), length 1494: seq 0x000,
  Flags [end], length 1492

and to the bigger fragment that is not received on the server side:

(tcpdump -vvvne -i eth2 pppoes and ppp proto 0x3d)
52:54:00:70:9e:89 > 52:54:00:5d:6f:b0, ethertype PPPoE S (0x8864),
  length 1515: PPPoE  [ses 0x5] MLPPP (0x003d), length 1495: seq 0x000,
  Flags [begin], length 1493

With the patch below, we correctly obtain three fragments:

52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
  length 1514: PPPoE  [ses 0x1] MLPPP (0x003d), length 1494: seq 0x000,
  Flags [begin], length 1492
52:54:00:70:9e:89 > 52:54:00:5d:6f:b0, ethertype PPPoE S (0x8864),
  length 1514: PPPoE  [ses 0x1] MLPPP (0x003d), length 1494: seq 0x000,
  Flags [none], length 1492
52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
  length 27: PPPoE  [ses 0x1] MLPPP (0x003d), length 7: seq 0x000,
  Flags [end], length 5

And the ICMPv4 echo request is successfully received at the server side:

IP (tos 0x0, ttl 64, id 21925, offset 0, flags [DF], proto ICMP (1),
  length 2976)
    192.168.222.2 > 192.168.15.254: ICMP echo request, id 30530, seq 0,
      length 2956

The bug was introduced in commit c9aa689
("[PPPOE]: Advertise PPPoE MTU") from the very beginning. This patch applies
to 3.10 upwards but the fix can be applied (with minor modifications) to
kernels as old as 2.6.32.

Signed-off-by: Christoph Schulz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @kristovschulz @gregkh
    kristovschulz authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    48b83df View commit details
    Browse the repository at this point in the history

  14. sunvnet: clean up objects created in vnet_new() on vnet_exit() 

    [ Upstream commit a4b70a0 ]

Nothing cleans up the objects created by
vnet_new(), they are completely leaked.

vnet_exit(), after doing the vio_unregister_driver() to clean
up ports, should call a helper function that iterates over vnet_list
and cleans up those objects. This includes unregister_netdevice()
as well as free_netdev().

Signed-off-by: Sowmini Varadhan <[email protected]>
Acked-by: Dave Kleikamp <[email protected]>
Reviewed-by: Karl Volz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @sowminiv @gregkh
    sowminiv authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    7670d47 View commit details
    Browse the repository at this point in the history

  15. dns_resolver: assure that dns_query() result is null-terminated 

    [ Upstream commit 84a7c0b ]

dns_query() credulously assumes that keys are null-terminated and
returns a copy of a memory block that is off by one.

Signed-off-by: Manuel Schölling <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @manuels @gregkh
    manuels authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    c304a23 View commit details
    Browse the repository at this point in the history

  16. dns_resolver: Null-terminate the right string 

    [ Upstream commit 640d7ef ]

*_result[len] is parsed as *(_result[len]) which is not at all what we
want to touch here.

Signed-off-by: Ben Hutchings <[email protected]>
Fixes: 84a7c0b ("dns_resolver: assure that dns_query() result is null-terminated")
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @bwhacks @gregkh
    bwhacks authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    4427f9a View commit details
    Browse the repository at this point in the history

  17. ipv4: fix buffer overflow in ip_options_compile() 

    [ Upstream commit 10ec947 ]

There is a benign buffer overflow in ip_options_compile spotted by
AddressSanitizer[1] :

Its benign because we always can access one extra byte in skb->head
(because header is followed by struct skb_shared_info), and in this case
this byte is not even used.

[28504.910798] ==================================================================
[28504.912046] AddressSanitizer: heap-buffer-overflow in ip_options_compile
[28504.913170] Read of size 1 by thread T15843:
[28504.914026]  [<ffffffff81802f91>] ip_options_compile+0x121/0x9c0
[28504.915394]  [<ffffffff81804a0d>] ip_options_get_from_user+0xad/0x120
[28504.916843]  [<ffffffff8180dedf>] do_ip_setsockopt.isra.15+0x8df/0x1630
[28504.918175]  [<ffffffff8180ec60>] ip_setsockopt+0x30/0xa0
[28504.919490]  [<ffffffff8181e59b>] tcp_setsockopt+0x5b/0x90
[28504.920835]  [<ffffffff8177462f>] sock_common_setsockopt+0x5f/0x70
[28504.922208]  [<ffffffff817729c2>] SyS_setsockopt+0xa2/0x140
[28504.923459]  [<ffffffff818cfb69>] system_call_fastpath+0x16/0x1b
[28504.924722]
[28504.925106] Allocated by thread T15843:
[28504.925815]  [<ffffffff81804995>] ip_options_get_from_user+0x35/0x120
[28504.926884]  [<ffffffff8180dedf>] do_ip_setsockopt.isra.15+0x8df/0x1630
[28504.927975]  [<ffffffff8180ec60>] ip_setsockopt+0x30/0xa0
[28504.929175]  [<ffffffff8181e59b>] tcp_setsockopt+0x5b/0x90
[28504.930400]  [<ffffffff8177462f>] sock_common_setsockopt+0x5f/0x70
[28504.931677]  [<ffffffff817729c2>] SyS_setsockopt+0xa2/0x140
[28504.932851]  [<ffffffff818cfb69>] system_call_fastpath+0x16/0x1b
[28504.934018]
[28504.934377] The buggy address ffff880026382828 is located 0 bytes to the right
[28504.934377]  of 40-byte region [ffff880026382800, ffff880026382828)
[28504.937144]
[28504.937474] Memory state around the buggy address:
[28504.938430]  ffff880026382300: ........ rrrrrrrr rrrrrrrr rrrrrrrr
[28504.939884]  ffff880026382400: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28504.941294]  ffff880026382500: .....rrr rrrrrrrr rrrrrrrr rrrrrrrr
[28504.942504]  ffff880026382600: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28504.943483]  ffff880026382700: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28504.944511] >ffff880026382800: .....rrr rrrrrrrr rrrrrrrr rrrrrrrr
[28504.945573]                         ^
[28504.946277]  ffff880026382900: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28505.094949]  ffff880026382a00: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28505.096114]  ffff880026382b00: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28505.097116]  ffff880026382c00: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28505.098472]  ffff880026382d00: ffffffff rrrrrrrr rrrrrrrr rrrrrrrr
[28505.099804] Legend:
[28505.100269]  f - 8 freed bytes
[28505.100884]  r - 8 redzone bytes
[28505.101649]  . - 8 allocated bytes
[28505.102406]  x=1..7 - x allocated bytes + (8-x) redzone bytes
[28505.103637] ==================================================================

[1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel

Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Eric Dumazet authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    26adeae View commit details
    Browse the repository at this point in the history

  18. perf/x86/intel: ignore CondChgd bit to avoid false NMI handling 

    commit b292d7a upstream.

Currently, any NMI is falsely handled by a NMI handler of NMI watchdog
if CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR is set.

For example, we use external NMI to make system panic to get crash
dump, but in this case, the external NMI is falsely handled do to the
issue.

This commit deals with the issue simply by ignoring CondChgd bit.

Here is explanation in detail.

On x86 NMI watchdog uses performance monitoring feature to
periodically signal NMI each time performance counter gets overflowed.

intel_pmu_handle_irq() is called as a NMI_LOCAL handler from a NMI
handler of NMI watchdog, perf_event_nmi_handler(). It identifies an
owner of a given NMI by looking at overflow status bits in
MSR_CORE_PERF_GLOBAL_STATUS MSR. If some of the bits are set, then it
handles the given NMI as its own NMI.

The problem is that the intel_pmu_handle_irq() doesn't distinguish
CondChgd bit from other bits. Unlike the other status bits, CondChgd
bit doesn't represent overflow status for performance counters. Thus,
CondChgd bit cannot be thought of as a mark indicating a given NMI is
NMI watchdog's.

As a result, if CondChgd bit is set, any NMI is falsely handled by the
NMI handler of NMI watchdog. Also, if type of the falsely handled NMI
is either NMI_UNKNOWN, NMI_SERR or NMI_IO_CHECK, the corresponding
action is never performed until CondChgd bit is cleared.

I noticed this behavior on systems with Ivy Bridge processors: Intel
Xeon CPU E5-2630 v2 and Intel Xeon CPU E7-8890 v2. On both systems,
CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR has already been set
in the beginning at boot. Then the CondChgd bit is immediately cleared
by next wrmsr to MSR_CORE_PERF_GLOBAL_CTRL MSR and appears to remain
0.

On the other hand, on older processors such as Nehalem, Xeon E7540,
CondChgd bit is not set in the beginning at boot.

I'm not sure about exact behavior of CondChgd bit, in particular when
this bit is set. Although I read Intel System Programmer's Manual to
figure out that, the descriptions I found are:

  In 18.9.1:

  "The MSR_PERF_GLOBAL_STATUS MSR also provides a ¡sticky bit¢ to
   indicate changes to the state of performancmonitoring hardware"

  In Table 35-2 IA-32 Architectural MSRs

  63 CondChg: status bits of this register has changed.

These are different from the bahviour I see on the actual system as I
explained above.

At least, I think ignoring CondChgd bit should be enough for NMI
watchdog perspective.

Signed-off-by: HATAYAMA Daisuke <[email protected]>
Acked-by: Don Zickus <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    HATAYAMA Daisuke authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    a2b2c03 View commit details
    Browse the repository at this point in the history

  19. mwifiex: fix Tx timeout issue 

    commit d76744a upstream.

https://bugzilla.kernel.org/show_bug.cgi?id=70191
https://bugzilla.kernel.org/show_bug.cgi?id=77581

It is observed that sometimes Tx packet is downloaded without
adding driver's txpd header. This results in firmware parsing
garbage data as packet length. Sometimes firmware is unable
to read the packet if length comes out as invalid. This stops
further traffic and timeout occurs.

The root cause is uninitialized fields in tx_info(skb->cb) of
packet used to get garbage values. In this case if
MWIFIEX_BUF_FLAG_REQUEUED_PKT flag is mistakenly set, txpd
header was skipped. This patch makes sure that tx_info is
correctly initialized to fix the problem.

Reported-by: Andrew Wiley <[email protected]>
Reported-by: Linus Gasser <[email protected]>
Reported-by: Michael Hirsch <[email protected]>
Tested-by: Xinming Hu <[email protected]>
Signed-off-by: Amitkumar Karwar <[email protected]>
Signed-off-by: Maithili Hinge <[email protected]>
Signed-off-by: Avinash Patil <[email protected]>
Signed-off-by: Bing Zhao <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Amitkumar Karwar authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    ed37976 View commit details
    Browse the repository at this point in the history

  20. drm/radeon: avoid leaking edid data 

    commit 0ac66ef upstream.

In some cases we fetch the edid in the detect() callback
in order to determine what sort of monitor is connected.
If that happens, don't fetch the edid again in the get_modes()
callback or we will leak the edid.

Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @alexdeucher @gregkh
    alexdeucher authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    b63dd4c View commit details
    Browse the repository at this point in the history

  21. alarmtimer: Fix bug where relative alarm timers were treated as absolute 

    commit 1692777 upstream.

Sharvil noticed with the posix timer_settime interface, using the
CLOCK_REALTIME_ALARM or CLOCK_BOOTTIME_ALARM clockid, if the users
tried to specify a relative time timer, it would incorrectly be
treated as absolute regardless of the state of the flags argument.

This patch corrects this, properly checking the absolute/relative flag,
as well as adds further error checking that no invalid flag bits are set.

Reported-by: Sharvil Nanavati <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Cc: Sharvil Nanavati <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @johnstultz-work @gregkh
    johnstultz-work authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    299e667 View commit details
    Browse the repository at this point in the history

  22. PM / sleep: Fix request_firmware() error at resume 

    commit 4320f6b upstream.

The commit [247bc037: PM / Sleep: Mitigate race between the freezer
and request_firmware()] introduced the finer state control, but it
also leads to a new bug; for example, a bug report regarding the
firmware loading of intel BT device at suspend/resume:
  https://bugzilla.novell.com/show_bug.cgi?id=873790

The root cause seems to be a small window between the process resume
and the clear of usermodehelper lock.  The request_firmware() function
checks the UMH lock and gives up when it's in UMH_DISABLE state.  This
is for avoiding the invalid  f/w loading during suspend/resume phase.
The problem is, however, that usermodehelper_enable() is called at the
end of thaw_processes().  Thus, a thawed process in between can kick
off the f/w loader code path (in this case, via btusb_setup_intel())
even before the call of usermodehelper_enable().  Then
usermodehelper_read_trylock() returns an error and request_firmware()
spews WARN_ON() in the end.

This oneliner patch fixes the issue just by setting to UMH_FREEZING
state again before restarting tasks, so that the call of
request_firmware() will be blocked until the end of this function
instead of returning an error.

Fixes: 247bc03 (PM / Sleep: Mitigate race between the freezer and request_firmware())
Link: https://bugzilla.novell.com/show_bug.cgi?id=873790
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @tiwai @gregkh
    tiwai authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    5dc1c88 View commit details
    Browse the repository at this point in the history

  23. iommu/vt-d: Disable translation if already enabled 

    commit 3a93c84 upstream.

This patch disables translation(dma-remapping) before its initialization
if it is already enabled.

This is needed for kexec/kdump boot. If dma-remapping is enabled in the
first kernel, it need to be disabled before initializing its page table
during second kernel boot. Wei Hu also reported that this is needed
when second kernel boots with intel_iommu=off.

Basically iommu->gcmd is used to know whether translation is enabled or
disabled, but it is always zero at boot time even when translation is
enabled since iommu->gcmd is initialized without considering such a
case. Therefor this patch synchronizes iommu->gcmd value with global
command register when iommu structure is allocated.

Signed-off-by: Takao Indoh <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
[wyj: Backported to 3.4: adjust context]
Signed-off-by: Yijing Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Takao Indoh authored and gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    21870a3 View commit details
    Browse the repository at this point in the history

  24. Linux 3.4.100

    @gregkh
    gregkh committed Jul 28, 2014
    Configuration menu
    Copy the full SHA
    82f9c4a View commit details
    Browse the repository at this point in the history

Commits on Jul 31, 2014

  1. block: don't assume last put of shared tags is for the host 

    commit d45b327 upstream.

There is no inherent reason why the last put of a tag structure must be
the one for the Scsi_Host, as device model objects can be held for
arbitrary periods.  Merge blk_free_tags and __blk_free_tags into a single
funtion that just release a references and get rid of the BUG() when the
host reference wasn't the last.

Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Christoph Hellwig authored and gregkh committed Jul 31, 2014
    Configuration menu
    Copy the full SHA
    696acd9 View commit details
    Browse the repository at this point in the history

  2. libata: support the ata host which implements a queue depth less than 32 

    commit 1871ee1 upstream.

The sata on fsl mpc8315e is broken after the commit 8a4aeec
("libata/ahci: accommodate tag ordered controllers"). The reason is
that the ata controller on this SoC only implement a queue depth of
16. When issuing the commands in tag order, all the commands in tag
16 ~ 31 are mapped to tag 0 unconditionally and then causes the sata
malfunction. It makes no senses to use a 32 queue in software while
the hardware has less queue depth. So consider the queue depth
implemented by the hardware when requesting a command tag.

Fixes: 8a4aeec ("libata/ahci: accommodate tag ordered controllers")
Signed-off-by: Kevin Hao <[email protected]>
Acked-by: Dan Williams <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @haokexin @gregkh
    haokexin authored and gregkh committed Jul 31, 2014
    Configuration menu
    Copy the full SHA
    6f0844c View commit details
    Browse the repository at this point in the history

  3. libata: introduce ata_host->n_tags to avoid oops on SAS controllers 

    commit 1a112d1 upstream.

1871ee1 ("libata: support the ata host which implements a queue
depth less than 32") directly used ata_port->scsi_host->can_queue from
ata_qc_new() to determine the number of tags supported by the host;
unfortunately, SAS controllers doing SATA don't initialize ->scsi_host
leading to the following oops.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
 IP: [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
 PGD 0
 Oops: 0002 [#1] SMP
 Modules linked in: isci libsas scsi_transport_sas mgag200 drm_kms_helper ttm
 CPU: 1 PID: 518 Comm: udevd Not tainted 3.16.0-rc6+ #62
 Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
 task: ffff880c1a00b280 ti: ffff88061a000000 task.ti: ffff88061a000000
 RIP: 0010:[<ffffffff814e0618>]  [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
 RSP: 0018:ffff88061a003ae8  EFLAGS: 00010012
 RAX: 0000000000000001 RBX: ffff88000241ca80 RCX: 00000000000000fa
 RDX: 0000000000000020 RSI: 0000000000000020 RDI: ffff8806194aa298
 RBP: ffff88061a003ae8 R08: ffff8806194a8000 R09: 0000000000000000
 R10: 0000000000000000 R11: ffff88000241ca80 R12: ffff88061ad58200
 R13: ffff8806194aa298 R14: ffffffff814e67a0 R15: ffff8806194a8000
 FS:  00007f3ad7fe3840(0000) GS:ffff880627620000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000058 CR3: 000000061a118000 CR4: 00000000001407e0
 Stack:
  ffff88061a003b20 ffffffff814e96e1 ffff88000241ca80 ffff88061ad58200
  ffff8800b6bf6000 ffff880c1c988000 ffff880619903850 ffff88061a003b68
  ffffffffa0056ce1 ffff88061a003b48 0000000013d6e6f8 ffff88000241ca80
 Call Trace:
  [<ffffffff814e96e1>] ata_sas_queuecmd+0xa1/0x430
  [<ffffffffa0056ce1>] sas_queuecommand+0x191/0x220 [libsas]
  [<ffffffff8149afee>] scsi_dispatch_cmd+0x10e/0x300 [<ffffffff814a3bc5>] scsi_request_fn+0x2f5/0x550
  [<ffffffff81317613>] __blk_run_queue+0x33/0x40
  [<ffffffff8131781a>] queue_unplugged+0x2a/0x90
  [<ffffffff8131ceb4>] blk_flush_plug_list+0x1b4/0x210
  [<ffffffff8131d274>] blk_finish_plug+0x14/0x50
  [<ffffffff8117eaa8>] __do_page_cache_readahead+0x198/0x1f0
  [<ffffffff8117ee21>] force_page_cache_readahead+0x31/0x50
  [<ffffffff8117ee7e>] page_cache_sync_readahead+0x3e/0x50
  [<ffffffff81172ac6>] generic_file_read_iter+0x496/0x5a0
  [<ffffffff81219897>] blkdev_read_iter+0x37/0x40
  [<ffffffff811e307e>] new_sync_read+0x7e/0xb0
  [<ffffffff811e3734>] vfs_read+0x94/0x170
  [<ffffffff811e43c6>] SyS_read+0x46/0xb0
  [<ffffffff811e33d1>] ? SyS_lseek+0x91/0xb0
  [<ffffffff8171ee29>] system_call_fastpath+0x16/0x1b
 Code: 00 00 00 88 50 29 83 7f 08 01 19 d2 83 e2 f0 83 ea 50 88 50 34 c6 81 1d 02 00 00 40 c6 81 17 02 00 00 00 5d c3 66 0f 1f 44 00 00 <89> 14 25 58 00 00 00

Fix it by introducing ata_host->n_tags which is initialized to
ATA_MAX_QUEUE - 1 in ata_host_init() for SAS controllers and set to
scsi_host_template->can_queue in ata_host_register() for !SAS ones.
As SAS hosts are never registered, this will give them the same
ATA_MAX_QUEUE - 1 as before.  Note that we can't use
scsi_host->can_queue directly for SAS hosts anyway as they can go
higher than the libata maximum.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Mike Qiu <[email protected]>
Reported-by: Jesse Brandeburg <[email protected]>
Reported-by: Peter Hurley <[email protected]>
Reported-by: Peter Zijlstra <[email protected]>
Tested-by: Alexey Kardashevskiy <[email protected]>
Fixes: 1871ee1 ("libata: support the ata host which implements a queue depth less than 32")
Cc: Kevin Hao <[email protected]>
Cc: Dan Williams <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @htejun @gregkh
    htejun authored and gregkh committed Jul 31, 2014
    Configuration menu
    Copy the full SHA
    80cd492 View commit details
    Browse the repository at this point in the history

  4. ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode) 

    commit b32bfc0 upstream.

Add support of the Promise FastTrak TX8660 SATA HBA in ahci mode by
registering the board in the ahci_pci_tbl[].

Note: this HBA also provide a hardware RAID mode when activated in
BIOS but specific drivers from the manufacturer are required in this
case.

Signed-off-by: Romain Degez <[email protected]>
Tested-by: Romain Degez <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @rdegez @gregkh
    rdegez authored and gregkh committed Jul 31, 2014
    Configuration menu
    Copy the full SHA
    4600552 View commit details
    Browse the repository at this point in the history

  5. x86_32, entry: Store badsys error code in %eax 

    commit 8142b21 upstream.

Commit 554086d ("x86_32, entry: Do syscall exit work on badsys
(CVE-2014-4508)") introduced a regression in the x86_32 syscall entry
code, resulting in syscall() not returning proper errors for undefined
syscalls on CPUs supporting the sysenter feature.

The following code:

> int result = syscall(666);
> printf("result=%d errno=%d error=%s\n", result, errno, strerror(errno));

results in:

> result=666 errno=0 error=Success

Obviously, the syscall return value is the called syscall number, but it
should have been an ENOSYS error. When run under ptrace it behaves
correctly, which makes it hard to debug in the wild:

> result=-1 errno=38 error=Function not implemented

The %eax register is the return value register. For debugging via ptrace
the syscall entry code stores the complete register context on the
stack. The badsys handlers only store the ENOSYS error code in the
ptrace register set and do not set %eax like a regular syscall handler
would. The old resume_userspace call chain contains code that clobbers
%eax and it restores %eax from the ptrace registers afterwards. The same
goes for the ptrace-enabled call chain. When ptrace is not used, the
syscall return value is the passed-in syscall number from the untouched
%eax register.

Use %eax as the return value register in syscall_badsys and
sysenter_badsys, like a real syscall handler does, and have the caller
push the value onto the stack for ptrace access.

Signed-off-by: Sven Wegener <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Reviewed-and-tested-by: Andy Lutomirski <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @swegener @gregkh
    swegener authored and gregkh committed Jul 31, 2014
    Configuration menu
    Copy the full SHA
    4aedd4b View commit details
    Browse the repository at this point in the history

  6. mm: hugetlb: fix copy_hugetlb_page_range() 

    commit 0253d63 upstream.

Commit 4a705fe ("hugetlb: fix copy_hugetlb_page_range() to handle
migration/hwpoisoned entry") changed the order of
huge_ptep_set_wrprotect() and huge_ptep_get(), which leads to breakage
in some workloads like hugepage-backed heap allocation via libhugetlbfs.
This patch fixes it.

The test program for the problem is shown below:

  $ cat heap.c
  #include <unistd.h>
  #include <stdlib.h>
  #include <string.h>

  #define HPS 0x200000

  int main() {
  	int i;
  	char *p = malloc(HPS);
  	memset(p, '1', HPS);
  	for (i = 0; i < 5; i++) {
  		if (!fork()) {
  			memset(p, '2', HPS);
  			p = malloc(HPS);
  			memset(p, '3', HPS);
  			free(p);
  			return 0;
  		}
  	}
  	sleep(1);
  	free(p);
  	return 0;
  }

  $ export HUGETLB_MORECORE=yes ; export HUGETLB_NO_PREFAULT= ; hugectl --heap ./heap

Fixes 4a705fe ("hugetlb: fix copy_hugetlb_page_range() to handle
migration/hwpoisoned entry"), so is applicable to -stable kernels which
include it.

Signed-off-by: Naoya Horiguchi <[email protected]>
Reported-by: Guillaume Morin <[email protected]>
Suggested-by: Guillaume Morin <[email protected]>
Acked-by: Hugh Dickins <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Naoya Horiguchi authored and gregkh committed Jul 31, 2014
    Configuration menu
    Copy the full SHA
    97f5dab View commit details
    Browse the repository at this point in the history

  7. Fix gcc-4.9.0 miscompilation of load_balance() in scheduler 

    commit 2062afb upstream.

Michel Dänzer and a couple of other people reported inexplicable random
oopses in the scheduler, and the cause turns out to be gcc mis-compiling
the load_balance() function when debugging is enabled.  The gcc bug
apparently goes back to gcc-4.5, but slight optimization changes means
that it now showed up as a problem in 4.9.0 and 4.9.1.

The instruction scheduling problem causes gcc to schedule a spill
operation to before the stack frame has been created, which in turn can
corrupt the spilled value if an interrupt comes in.  There may be other
effects of this bug too, but that's the code generation problem seen in
Michel's case.

This is fixed in current gcc HEAD, but the workaround as suggested by
Markus Trippelsdorf is pretty simple: use -fno-var-tracking-assignments
when compiling the kernel, which disables the gcc code that causes the
problem.  This can result in slightly worse debug information for
variable accesses, but that is infinitely preferable to actual code
generation problems.

Doing this unconditionally (not just for CONFIG_DEBUG_INFO) also allows
non-debug builds to verify that the debug build would be identical: we
can do

    export GCC_COMPARE_DEBUG=1

to make gcc internally verify that the result of the build is
independent of the "-g" flag (it will make the compiler build everything
twice, toggling the debug flag, and compare the results).

Without the "-fno-var-tracking-assignments" option, the build would fail
(even with 4.8.3 that didn't show the actual stack frame bug) with a gcc
compare failure.

See also gcc bugzilla:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801

Reported-by: Michel Dänzer <[email protected]>
Suggested-by: Markus Trippelsdorf <[email protected]>
Cc: Jakub Jelinek <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @torvalds @gregkh
    torvalds authored and gregkh committed Jul 31, 2014
    Configuration menu
    Copy the full SHA
    e5c662d View commit details
    Browse the repository at this point in the history

  8. s390/ptrace: fix PSW mask check 

    commit dab6cf5 upstream.

The PSW mask check of the PTRACE_POKEUSR_AREA command is incorrect.
The PSW_MASK_USER define contains the PSW_MASK_ASC bits, the ptrace
interface accepts all combinations for the address-space-control
bits. To protect the kernel space the PSW mask check in ptrace needs
to reject the address-space-control bit combination for home space.

Fixes CVE-2014-3534

Signed-off-by: Martin Schwidefsky <[email protected]>
Cc: Ben Hutchings <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Martin Schwidefsky authored and gregkh committed Jul 31, 2014
    Configuration menu
    Copy the full SHA
    883ea13 View commit details
    Browse the repository at this point in the history

  9. introduce SIZE_MAX 

    commit a3860c1 upstream.

ULONG_MAX is often used to check for integer overflow when calculating
allocation size.  While ULONG_MAX happens to work on most systems, there
is no guarantee that `size_t' must be the same size as `long'.

This patch introduces SIZE_MAX, the maximum value of `size_t', to improve
portability and readability for allocation size validation.

Signed-off-by: Xi Wang <[email protected]>
Acked-by: Alex Elder <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Pekka Enberg <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Cc: Qiang Huang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @xiw @gregkh
    xiw authored and gregkh committed Jul 31, 2014
    Configuration menu
    Copy the full SHA
    b06b5c6 View commit details
    Browse the repository at this point in the history

  10. mm: kmemleak: avoid false negatives on vmalloc'ed objects 

    commit 7f88f88 upstream.

Commit 248ac0e ("mm/vmalloc: remove guard page from between vmap
blocks") had the side effect of making vmap_area.va_end member point to
the next vmap_area.va_start.  This was creating an artificial reference
to vmalloc'ed objects and kmemleak was rarely reporting vmalloc() leaks.

This patch marks the vmap_area containing pointers explicitly and
reduces the min ref_count to 2 as vm_struct still contains a reference
to the vmalloc'ed object.  The kmemleak add_scan_area() function has
been improved to allow a SIZE_MAX argument covering the rest of the
object (for simpler calling sites).

Signed-off-by: Catalin Marinas <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
[hq: Backported to 3.4: Adjust context]
Signed-off-by: Qiang Huang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @ctmarinas @gregkh
    ctmarinas authored and gregkh committed Jul 31, 2014
    Configuration menu
    Copy the full SHA
    7e2e611 View commit details
    Browse the repository at this point in the history

  11. Linux 3.4.101

    @gregkh
    gregkh committed Jul 31, 2014
    Configuration menu
    Copy the full SHA
    91f7c8c View commit details
    Browse the repository at this point in the history

Commits on Aug 4, 2014

  1. Merge tag 'v3.4.92' into reference-3.4 

    This is the 3.4.92 stable release
    @amery
    amery committed Aug 4, 2014
    Configuration menu
    Copy the full SHA
    5a1deeb View commit details
    Browse the repository at this point in the history

  2. Merge tag 'v3.4.93' into reference-3.4 

    This is the 3.4.93 stable release
    @amery
    amery committed Aug 4, 2014
    Configuration menu
    Copy the full SHA
    58aa071 View commit details
    Browse the repository at this point in the history

  3. Merge tag 'v3.4.94' into reference-3.4 

    This is the 3.4.94 stable release
    @amery
    amery committed Aug 4, 2014
    Configuration menu
    Copy the full SHA
    19d1f52 View commit details
    Browse the repository at this point in the history

  4. Merge tag 'v3.4.95' into reference-3.4 

    This is the 3.4.95 stable release

Conflicts:
	lib/lzo/lzo1x_decompress_safe.c
	lib/lzo/lzodefs.h
    @amery
    amery committed Aug 4, 2014
    Configuration menu
    Copy the full SHA
    b6aee3c View commit details
    Browse the repository at this point in the history

  5. Merge tag 'v3.4.96' into reference-3.4 

    This is the 3.4.96 stable release
    @amery
    amery committed Aug 4, 2014
    Configuration menu
    Copy the full SHA
    1855cb6 View commit details
    Browse the repository at this point in the history

  6. Merge tag 'v3.4.97' into reference-3.4 

    This is the 3.4.97 stable release
    @amery
    amery committed Aug 4, 2014
    Configuration menu
    Copy the full SHA
    262484f View commit details
    Browse the repository at this point in the history

  7. Merge tag 'v3.4.98' into reference-3.4 

    This is the 3.4.98 stable release
    @amery
    amery committed Aug 4, 2014
    Configuration menu
    Copy the full SHA
    b17bea3 View commit details
    Browse the repository at this point in the history

  8. Merge tag 'v3.4.99' into reference-3.4 

    This is the 3.4.99 stable release
    @amery
    amery committed Aug 4, 2014
    Configuration menu
    Copy the full SHA
    a5cf581 View commit details
    Browse the repository at this point in the history

  9. Merge tag 'v3.4.100' into reference-3.4 

    This is the 3.4.100 stable release
    @amery
    amery committed Aug 4, 2014
    Configuration menu
    Copy the full SHA
    527fcc3 View commit details
    Browse the repository at this point in the history

  10. Merge tag 'v3.4.101' into reference-3.4 

    This is the 3.4.101 stable release
    @amery
    amery committed Aug 4, 2014
    Configuration menu
    Copy the full SHA
    0b2d5cf View commit details
    Browse the repository at this point in the history

  11. Merge remote-tracking branch 'origin/mirror/android-3.4' into referen… 

    …ce-3.4

Conflicts:
	net/ipv6/route.c
    @amery
    amery committed Aug 4, 2014
    Configuration menu
    Copy the full SHA
    2e1be50 View commit details
    Browse the repository at this point in the history

  12. Merge branch 'reference-3.4' into stage/sunxi-3.4

    @amery
    amery committed Aug 4, 2014
    Configuration menu
    Copy the full SHA
    38ecdee View commit details
    Browse the repository at this point in the history

Commits on Aug 7, 2014

  1. crypto: af_alg - properly label AF_ALG socket 

    commit 4c63f83 upstream.

Th AF_ALG socket was missing a security label (e.g. SELinux)
which means that socket was in "unlabeled" state.

This was recently demonstrated in the cryptsetup package
(cryptsetup v1.6.5 and later.)
See https://bugzilla.redhat.com/show_bug.cgi?id=1115120

This patch clones the sock's label from the parent sock
and resolves the issue (similar to AF_BLUETOOTH protocol family).

Signed-off-by: Milan Broz <[email protected]>
Acked-by: Paul Moore <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @mbroz @gregkh
    mbroz authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    44ce8f8 View commit details
    Browse the repository at this point in the history

  2. ARM: 8115/1: LPAE: reduce damage caused by idmap to virtual memory la… 

    …yout

commit 811a240 upstream.

On LPAE, each level 1 (pgd) page table entry maps 1GiB, and the level 2
(pmd) entries map 2MiB.

When the identity mapping is created on LPAE, the pgd pointers are copied
from the swapper_pg_dir.  If we find that we need to modify the contents
of a pmd, we allocate a new empty pmd table and insert it into the
appropriate 1GB slot, before then filling it with the identity mapping.

However, if the 1GB slot covers the kernel lowmem mappings, we obliterate
those mappings.

When replacing a PMD, first copy the old PMD contents to the new PMD, so
that we preserve the existing mappings, particularly the mappings of the
kernel itself.

[rewrote commit message and added code comment -- rmk]

Fixes: ae2de10 ("ARM: LPAE: Add identity mapping support for the 3-level page table format")
Signed-off-by: Konstantin Khlebnikov <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Konstantin Khlebnikov authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    2e926a6 View commit details
    Browse the repository at this point in the history

  3. scsi: handle flush errors properly 

    commit 89fb4cd upstream.

Flush commands don't transfer data and thus need to be special cased
in the I/O completion handler so that we can propagate errors to
the block layer and filesystem.

Signed-off-by: James Bottomley <[email protected]>
Reported-by: Steven Haber <[email protected]>
Tested-by: Steven Haber <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    James Bottomley authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    0e04ec4 View commit details
    Browse the repository at this point in the history

  4. mm, thp: do not allow thp faults to avoid cpuset restrictions 

    commit b104a35 upstream.

The page allocator relies on __GFP_WAIT to determine if ALLOC_CPUSET
should be set in allocflags.  ALLOC_CPUSET controls if a page allocation
should be restricted only to the set of allowed cpuset mems.

Transparent hugepages clears __GFP_WAIT when defrag is disabled to prevent
the fault path from using memory compaction or direct reclaim.  Thus, it
is unfairly able to allocate outside of its cpuset mems restriction as a
side-effect.

This patch ensures that ALLOC_CPUSET is only cleared when the gfp mask is
truly GFP_ATOMIC by verifying it is also not a thp allocation.

Signed-off-by: David Rientjes <[email protected]>
Reported-by: Alex Thorlton <[email protected]>
Tested-by: Alex Thorlton <[email protected]>
Cc: Bob Liu <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Hedi Berriche <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Srivatsa S. Bhat <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @rientjes @gregkh
    rientjes authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    7f6c1de View commit details
    Browse the repository at this point in the history

  5. printk: rename printk_sched to printk_deferred 

    commit aac74dc upstream.

After learning we'll need some sort of deferred printk functionality in
the timekeeping core, Peter suggested we rename the printk_sched function
so it can be reused by needed subsystems.

This only changes the function name. No logic changes.

Signed-off-by: John Stultz <[email protected]>
Reviewed-by: Steven Rostedt <[email protected]>
Cc: Jan Kara <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Jiri Bohac <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @johnstultz-work @gregkh
    johnstultz-work authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    f73ff69 View commit details
    Browse the repository at this point in the history

  6. timer: Fix lock inversion between hrtimer_bases.lock and scheduler locks 

    commit 504d587 upstream.

clockevents_increase_min_delta() calls printk() from under
hrtimer_bases.lock. That causes lock inversion on scheduler locks because
printk() can call into the scheduler. Lockdep puts it as:

======================================================
[ INFO: possible circular locking dependency detected ]
3.15.0-rc8-06195-g939f04b #2 Not tainted
-------------------------------------------------------
trinity-main/74 is trying to acquire lock:
 (&port_lock_key){-.....}, at: [<811c60be>] serial8250_console_write+0x8c/0x10c

but task is already holding lock:
 (hrtimer_bases.lock){-.-...}, at: [<8103caeb>] hrtimer_try_to_cancel+0x13/0x66

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #5 (hrtimer_bases.lock){-.-...}:
       [<8104a942>] lock_acquire+0x92/0x101
       [<8142f11d>] _raw_spin_lock_irqsave+0x2e/0x3e
       [<8103c918>] __hrtimer_start_range_ns+0x1c/0x197
       [<8107ec20>] perf_swevent_start_hrtimer.part.41+0x7a/0x85
       [<81080792>] task_clock_event_start+0x3a/0x3f
       [<810807a4>] task_clock_event_add+0xd/0x14
       [<8108259a>] event_sched_in+0xb6/0x17a
       [<810826a2>] group_sched_in+0x44/0x122
       [<81082885>] ctx_sched_in.isra.67+0x105/0x11f
       [<810828e6>] perf_event_sched_in.isra.70+0x47/0x4b
       [<81082bf6>] __perf_install_in_context+0x8b/0xa3
       [<8107eb8e>] remote_function+0x12/0x2a
       [<8105f5af>] smp_call_function_single+0x2d/0x53
       [<8107e17d>] task_function_call+0x30/0x36
       [<8107fb82>] perf_install_in_context+0x87/0xbb
       [<810852c9>] SYSC_perf_event_open+0x5c6/0x701
       [<810856f9>] SyS_perf_event_open+0x17/0x19
       [<8142f8ee>] syscall_call+0x7/0xb

-> #4 (&ctx->lock){......}:
       [<8104a942>] lock_acquire+0x92/0x101
       [<8142f04c>] _raw_spin_lock+0x21/0x30
       [<81081df3>] __perf_event_task_sched_out+0x1dc/0x34f
       [<8142cacc>] __schedule+0x4c6/0x4cb
       [<8142cae0>] schedule+0xf/0x11
       [<8142f9a6>] work_resched+0x5/0x30

-> #3 (&rq->lock){-.-.-.}:
       [<8104a942>] lock_acquire+0x92/0x101
       [<8142f04c>] _raw_spin_lock+0x21/0x30
       [<81040873>] __task_rq_lock+0x33/0x3a
       [<8104184c>] wake_up_new_task+0x25/0xc2
       [<8102474b>] do_fork+0x15c/0x2a0
       [<810248a9>] kernel_thread+0x1a/0x1f
       [<814232a2>] rest_init+0x1a/0x10e
       [<817af949>] start_kernel+0x303/0x308
       [<817af2ab>] i386_start_kernel+0x79/0x7d

-> #2 (&p->pi_lock){-.-...}:
       [<8104a942>] lock_acquire+0x92/0x101
       [<8142f11d>] _raw_spin_lock_irqsave+0x2e/0x3e
       [<810413dd>] try_to_wake_up+0x1d/0xd6
       [<810414cd>] default_wake_function+0xb/0xd
       [<810461f3>] __wake_up_common+0x39/0x59
       [<81046346>] __wake_up+0x29/0x3b
       [<811b8733>] tty_wakeup+0x49/0x51
       [<811c3568>] uart_write_wakeup+0x17/0x19
       [<811c5dc1>] serial8250_tx_chars+0xbc/0xfb
       [<811c5f28>] serial8250_handle_irq+0x54/0x6a
       [<811c5f57>] serial8250_default_handle_irq+0x19/0x1c
       [<811c56d8>] serial8250_interrupt+0x38/0x9e
       [<810510e7>] handle_irq_event_percpu+0x5f/0x1e2
       [<81051296>] handle_irq_event+0x2c/0x43
       [<81052cee>] handle_level_irq+0x57/0x80
       [<81002a72>] handle_irq+0x46/0x5c
       [<810027df>] do_IRQ+0x32/0x89
       [<8143036e>] common_interrupt+0x2e/0x33
       [<8142f23c>] _raw_spin_unlock_irqrestore+0x3f/0x49
       [<811c25a4>] uart_start+0x2d/0x32
       [<811c2c04>] uart_write+0xc7/0xd6
       [<811bc6f6>] n_tty_write+0xb8/0x35e
       [<811b9beb>] tty_write+0x163/0x1e4
       [<811b9cd9>] redirected_tty_write+0x6d/0x75
       [<810b6ed6>] vfs_write+0x75/0xb0
       [<810b7265>] SyS_write+0x44/0x77
       [<8142f8ee>] syscall_call+0x7/0xb

-> #1 (&tty->write_wait){-.....}:
       [<8104a942>] lock_acquire+0x92/0x101
       [<8142f11d>] _raw_spin_lock_irqsave+0x2e/0x3e
       [<81046332>] __wake_up+0x15/0x3b
       [<811b8733>] tty_wakeup+0x49/0x51
       [<811c3568>] uart_write_wakeup+0x17/0x19
       [<811c5dc1>] serial8250_tx_chars+0xbc/0xfb
       [<811c5f28>] serial8250_handle_irq+0x54/0x6a
       [<811c5f57>] serial8250_default_handle_irq+0x19/0x1c
       [<811c56d8>] serial8250_interrupt+0x38/0x9e
       [<810510e7>] handle_irq_event_percpu+0x5f/0x1e2
       [<81051296>] handle_irq_event+0x2c/0x43
       [<81052cee>] handle_level_irq+0x57/0x80
       [<81002a72>] handle_irq+0x46/0x5c
       [<810027df>] do_IRQ+0x32/0x89
       [<8143036e>] common_interrupt+0x2e/0x33
       [<8142f23c>] _raw_spin_unlock_irqrestore+0x3f/0x49
       [<811c25a4>] uart_start+0x2d/0x32
       [<811c2c04>] uart_write+0xc7/0xd6
       [<811bc6f6>] n_tty_write+0xb8/0x35e
       [<811b9beb>] tty_write+0x163/0x1e4
       [<811b9cd9>] redirected_tty_write+0x6d/0x75
       [<810b6ed6>] vfs_write+0x75/0xb0
       [<810b7265>] SyS_write+0x44/0x77
       [<8142f8ee>] syscall_call+0x7/0xb

-> #0 (&port_lock_key){-.....}:
       [<8104a62d>] __lock_acquire+0x9ea/0xc6d
       [<8104a942>] lock_acquire+0x92/0x101
       [<8142f11d>] _raw_spin_lock_irqsave+0x2e/0x3e
       [<811c60be>] serial8250_console_write+0x8c/0x10c
       [<8104e402>] call_console_drivers.constprop.31+0x87/0x118
       [<8104f5d5>] console_unlock+0x1d7/0x398
       [<8104fb70>] vprintk_emit+0x3da/0x3e4
       [<81425f76>] printk+0x17/0x19
       [<8105bfa0>] clockevents_program_min_delta+0x104/0x116
       [<8105c548>] clockevents_program_event+0xe7/0xf3
       [<8105cc1c>] tick_program_event+0x1e/0x23
       [<8103c43c>] hrtimer_force_reprogram+0x88/0x8f
       [<8103c49e>] __remove_hrtimer+0x5b/0x79
       [<8103cb21>] hrtimer_try_to_cancel+0x49/0x66
       [<8103cb4b>] hrtimer_cancel+0xd/0x18
       [<8107f102>] perf_swevent_cancel_hrtimer.part.60+0x2b/0x30
       [<81080705>] task_clock_event_stop+0x20/0x64
       [<81080756>] task_clock_event_del+0xd/0xf
       [<81081350>] event_sched_out+0xab/0x11e
       [<810813e0>] group_sched_out+0x1d/0x66
       [<81081682>] ctx_sched_out+0xaf/0xbf
       [<81081e04>] __perf_event_task_sched_out+0x1ed/0x34f
       [<8142cacc>] __schedule+0x4c6/0x4cb
       [<8142cae0>] schedule+0xf/0x11
       [<8142f9a6>] work_resched+0x5/0x30

other info that might help us debug this:

Chain exists of:
  &port_lock_key --> &ctx->lock --> hrtimer_bases.lock

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(hrtimer_bases.lock);
                               lock(&ctx->lock);
                               lock(hrtimer_bases.lock);
  lock(&port_lock_key);

 *** DEADLOCK ***

4 locks held by trinity-main/74:
 #0:  (&rq->lock){-.-.-.}, at: [<8142c6f3>] __schedule+0xed/0x4cb
 #1:  (&ctx->lock){......}, at: [<81081df3>] __perf_event_task_sched_out+0x1dc/0x34f
 #2:  (hrtimer_bases.lock){-.-...}, at: [<8103caeb>] hrtimer_try_to_cancel+0x13/0x66
 #3:  (console_lock){+.+...}, at: [<8104fb5d>] vprintk_emit+0x3c7/0x3e4

stack backtrace:
CPU: 0 PID: 74 Comm: trinity-main Not tainted 3.15.0-rc8-06195-g939f04b #2
 00000000 81c3a310 8b995c14 81426f69 8b995c44 81425a99 8161f671 8161f570
 8161f538 8161f559 8161f538 8b995c78 8b142bb0 00000004 8b142fdc 8b142bb0
 8b995ca8 8104a62d 8b142fac 000016f2 81c3a310 00000001 00000001 00000003
Call Trace:
 [<81426f69>] dump_stack+0x16/0x18
 [<81425a99>] print_circular_bug+0x18f/0x19c
 [<8104a62d>] __lock_acquire+0x9ea/0xc6d
 [<8104a942>] lock_acquire+0x92/0x101
 [<811c60be>] ? serial8250_console_write+0x8c/0x10c
 [<811c6032>] ? wait_for_xmitr+0x76/0x76
 [<8142f11d>] _raw_spin_lock_irqsave+0x2e/0x3e
 [<811c60be>] ? serial8250_console_write+0x8c/0x10c
 [<811c60be>] serial8250_console_write+0x8c/0x10c
 [<8104af87>] ? lock_release+0x191/0x223
 [<811c6032>] ? wait_for_xmitr+0x76/0x76
 [<8104e402>] call_console_drivers.constprop.31+0x87/0x118
 [<8104f5d5>] console_unlock+0x1d7/0x398
 [<8104fb70>] vprintk_emit+0x3da/0x3e4
 [<81425f76>] printk+0x17/0x19
 [<8105bfa0>] clockevents_program_min_delta+0x104/0x116
 [<8105cc1c>] tick_program_event+0x1e/0x23
 [<8103c43c>] hrtimer_force_reprogram+0x88/0x8f
 [<8103c49e>] __remove_hrtimer+0x5b/0x79
 [<8103cb21>] hrtimer_try_to_cancel+0x49/0x66
 [<8103cb4b>] hrtimer_cancel+0xd/0x18
 [<8107f102>] perf_swevent_cancel_hrtimer.part.60+0x2b/0x30
 [<81080705>] task_clock_event_stop+0x20/0x64
 [<81080756>] task_clock_event_del+0xd/0xf
 [<81081350>] event_sched_out+0xab/0x11e
 [<810813e0>] group_sched_out+0x1d/0x66
 [<81081682>] ctx_sched_out+0xaf/0xbf
 [<81081e04>] __perf_event_task_sched_out+0x1ed/0x34f
 [<8104416d>] ? __dequeue_entity+0x23/0x27
 [<81044505>] ? pick_next_task_fair+0xb1/0x120
 [<8142cacc>] __schedule+0x4c6/0x4cb
 [<81047574>] ? trace_hardirqs_off_caller+0xd7/0x108
 [<810475b0>] ? trace_hardirqs_off+0xb/0xd
 [<81056346>] ? rcu_irq_exit+0x64/0x77

Fix the problem by using printk_deferred() which does not call into the
scheduler.

Reported-by: Fengguang Wu <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @jankara @gregkh
    jankara authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    fbbb720 View commit details
    Browse the repository at this point in the history

  7. Revert "x86-64, modify_ldt: Make support for 16-bit segments a runtim… 

    …e option"

commit 7ed6fb9 upstream.

This reverts commit fa81511 in
preparation of merging in the proper fix (espfix64).

Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    H. Peter Anvin authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    6c7e43a View commit details
    Browse the repository at this point in the history

  8. x86-64, espfix: Don't leak bits 31:16 of %esp returning to 16-bit stack 

    commit 3891a04 upstream.

The IRET instruction, when returning to a 16-bit segment, only
restores the bottom 16 bits of the user space stack pointer.  This
causes some 16-bit software to break, but it also leaks kernel state
to user space.  We have a software workaround for that ("espfix") for
the 32-bit kernel, but it relies on a nonzero stack segment base which
is not available in 64-bit mode.

In checkin:

    b3b42ac x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

we "solved" this by forbidding 16-bit segments on 64-bit kernels, with
the logic that 16-bit support is crippled on 64-bit kernels anyway (no
V86 support), but it turns out that people are doing stuff like
running old Win16 binaries under Wine and expect it to work.

This works around this by creating percpu "ministacks", each of which
is mapped 2^16 times 64K apart.  When we detect that the return SS is
on the LDT, we copy the IRET frame to the ministack and use the
relevant alias to return to userspace.  The ministacks are mapped
readonly, so if IRET faults we promote #GP to #DF which is an IST
vector and thus has its own stack; we then do the fixup in the #DF
handler.

(Making #GP an IST exception would make the msr_safe functions unsafe
in NMI/MC context, and quite possibly have other effects.)

Special thanks to:

- Andy Lutomirski, for the suggestion of using very small stack slots
  and copy (as opposed to map) the IRET frame there, and for the
  suggestion to mark them readonly and let the fault promote to #DF.
- Konrad Wilk for paravirt fixup and testing.
- Borislav Petkov for testing help and useful comments.

Reported-by: Brian Gerst <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Cc: Konrad Rzeszutek Wilk <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Andrew Lutomriski <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Dirk Hohndel <[email protected]>
Cc: Arjan van de Ven <[email protected]>
Cc: comex <[email protected]>
Cc: Alexander van Heukelum <[email protected]>
Cc: Boris Ostrovsky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    H. Peter Anvin authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    3989298 View commit details
    Browse the repository at this point in the history

  9. x86, espfix: Move espfix definitions into a separate header file 

    commit e1fe9ed upstream.

Sparse warns that the percpu variables aren't declared before they are
defined.  Rather than hacking around it, move espfix definitions into
a proper header file.

Reported-by: Fengguang Wu <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    H. Peter Anvin authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    18e63ea View commit details
    Browse the repository at this point in the history

  10. x86, espfix: Fix broken header guard 

    commit 20b6853 upstream.

Header guard is #ifndef, not #ifdef...

Reported-by: Fengguang Wu <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    H. Peter Anvin authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    111f0ce View commit details
    Browse the repository at this point in the history

  11. x86, espfix: Make espfix64 a Kconfig option, fix UML 

    commit 197725d upstream.

Make espfix64 a hidden Kconfig option.  This fixes the x86-64 UML
build which had broken due to the non-existence of init_espfix_bsp()
in UML: since UML uses its own Kconfig, this option does not appear in
the UML build.

This also makes it possible to make support for 16-bit segments a
configuration option, for the people who want to minimize the size of
the kernel.

Reported-by: Ingo Molnar <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Cc: Richard Weinberger <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    H. Peter Anvin authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    7b6354e View commit details
    Browse the repository at this point in the history

  12. x86, espfix: Make it possible to disable 16-bit support 

    commit 34273f4 upstream.

Embedded systems, which may be very memory-size-sensitive, are
extremely unlikely to ever encounter any 16-bit software, so make it
a CONFIG_EXPERT option to turn off support for any 16-bit software
whatsoever.

Signed-off-by: H. Peter Anvin <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    H. Peter Anvin authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    4a0db8a View commit details
    Browse the repository at this point in the history

  13. x86_64/entry/xen: Do not invoke espfix64 on Xen 

    commit 7209a75 upstream.

This moves the espfix64 logic into native_iret.  To make this work,
it gets rid of the native patch for INTERRUPT_RETURN:
INTERRUPT_RETURN on native kernels is now 'jmp native_iret'.

This changes the 16-bit SS behavior on Xen from OOPSing to leaking
some bits of the Xen hypervisor's RSP (I think).

[ hpa: this is a nonzero cost on native, but probably not enough to
  measure. Xen needs to fix this in their own code, probably doing
  something equivalent to espfix64. ]

Signed-off-by: Andy Lutomirski <[email protected]>
Link: http://lkml.kernel.org/r/7b8f1d8ef6597cb16ae004a43c56980a7de3cf94.1406129132.git.luto@amacapital.net
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @amluto @gregkh
    amluto authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    473d8a2 View commit details
    Browse the repository at this point in the history

  14. Revert: "net: ip, ipv6: handle gso skbs in forwarding path" 

    This reverts commit 29a3cd4 which is
commit fe6cc55 upstream.

Cc: Herbert Xu <[email protected]>
Cc: Marcelo Ricardo Leitner <[email protected]>
Cc: Florian Westphal <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: Thomas Jarosch <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    68199d6 View commit details
    Browse the repository at this point in the history

  15. net/l2tp: don't fall back on UDP [get|set]sockopt 

    commit 3cf521f upstream.

The l2tp [get|set]sockopt() code has fallen back to the UDP functions
for socket option levels != SOL_PPPOL2TP since day one, but that has
never actually worked, since the l2tp socket isn't an inet socket.

As David Miller points out:

  "If we wanted this to work, it'd have to look up the tunnel and then
   use tunnel->sk, but I wonder how useful that would be"

Since this can never have worked so nobody could possibly have depended
on that functionality, just remove the broken code and return -EINVAL.

Reported-by: Sasha Levin <[email protected]>
Acked-by: James Chapman <[email protected]>
Acked-by: David Miller <[email protected]>
Cc: Phil Turnbull <[email protected]>
Cc: Vegard Nossum <[email protected]>
Cc: Willy Tarreau <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @sashalevin @gregkh
    sashalevin authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    56a2a6f View commit details
    Browse the repository at this point in the history

  16. lib/btree.c: fix leak of whole btree nodes 

    commit c75b53a upstream.

I use btree from 3.14-rc2 in my own module.  When the btree module is
removed, a warning arises:

 kmem_cache_destroy btree_node: Slab cache still has objects
 CPU: 13 PID: 9150 Comm: rmmod Tainted: GF          O 3.14.0-rc2 #1
 Hardware name: Inspur NF5270M3/NF5270M3, BIOS CHEETAH_2.1.3 09/10/2013
 Call Trace:
   dump_stack+0x49/0x5d
   kmem_cache_destroy+0xcf/0xe0
   btree_module_exit+0x10/0x12 [btree]
   SyS_delete_module+0x198/0x1f0
   system_call_fastpath+0x16/0x1b

The cause is that it doesn't release the last btree node, when height = 1
and fill = 1.

[[email protected]: remove unneeded test of NULL]
Signed-off-by: Minfei Huang <[email protected]>
Cc: Joern Engel <[email protected]>
Cc: Johannes Berg <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Minfei Huang authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    cca6995 View commit details
    Browse the repository at this point in the history

  17. x86/espfix/xen: Fix allocation of pages for paravirt page tables 

    commit 8762e50 upstream.

init_espfix_ap() is currently off by one level when informing hypervisor
that allocated pages will be used for ministacks' page tables.

The most immediate effect of this on a PV guest is that if
'stack_page = __get_free_page()' returns a non-zeroed-out page the hypervisor
will refuse to use it for a page table (which it shouldn't be anyway). This will
result in warnings by both Xen and Linux.

More importantly, a subsequent write to that page (again, by a PV guest) is
likely to result in fatal page fault.

Signed-off-by: Boris Ostrovsky <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Reviewed-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Boris Ostrovsky authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    9c98268 View commit details
    Browse the repository at this point in the history

  18. mm: try_to_unmap_cluster() should lock_page() before mlocking 

    commit 57e68e9 upstream.

A BUG_ON(!PageLocked) was triggered in mlock_vma_page() by Sasha Levin
fuzzing with trinity.  The call site try_to_unmap_cluster() does not lock
the pages other than its check_page parameter (which is already locked).

The BUG_ON in mlock_vma_page() is not documented and its purpose is
somewhat unclear, but apparently it serializes against page migration,
which could otherwise fail to transfer the PG_mlocked flag.  This would
not be fatal, as the page would be eventually encountered again, but
NR_MLOCK accounting would become distorted nevertheless.  This patch adds
a comment to the BUG_ON in mlock_vma_page() and munlock_vma_page() to that
effect.

The call site try_to_unmap_cluster() is fixed so that for page !=
check_page, trylock_page() is attempted (to avoid possible deadlocks as we
already have check_page locked) and mlock_vma_page() is performed only
upon success.  If the page lock cannot be obtained, the page is left
without PG_mlocked, which is again not a problem in the whole unevictable
memory design.

Signed-off-by: Vlastimil Babka <[email protected]>
Signed-off-by: Bob Liu <[email protected]>
Reported-by: Sasha Levin <[email protected]>
Cc: Wanpeng Li <[email protected]>
Cc: Michel Lespinasse <[email protected]>
Cc: KOSAKI Motohiro <[email protected]>
Acked-by: Rik van Riel <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Joonsoo Kim <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <[email protected]>
Cc: Yijing Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @tehcaster @gregkh
    tehcaster authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    21dbd45 View commit details
    Browse the repository at this point in the history

  19. ipv6: reallocate addrconf router for ipv6 address when lo device up 

    commit 33d9911 upstream.

commit 25fb6ca
"net IPv6 : Fix broken IPv6 routing table after loopback down-up"
allocates addrconf router for ipv6 address when lo device up.
but commit a881ae1
"ipv6:don't call addrconf_dst_alloc again when enable lo" breaks
this behavior.

Since the addrconf router is moved to the garbage list when
lo device down, we should release this router and rellocate
a new one for ipv6 address when lo device up.

This patch solves bug 67951 on bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=67951

change from v1:
use ip6_rt_put to repleace ip6_del_rt, thanks Hannes!
change code style, suggested by Sergei.

CC: Sabrina Dubroca <[email protected]>
CC: Hannes Frederic Sowa <[email protected]>
Reported-by: Weilong Chen <[email protected]>
Signed-off-by: Weilong Chen <[email protected]>
Signed-off-by: Gao feng <[email protected]>
Acked-by: Hannes Frederic Sowa <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
[weilong: s/ip6_rt_put/dst_release]
Signed-off-by: Chen Weilong <[email protected]>
Signed-off-by: Li Zefan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Gao feng authored and gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    a066704 View commit details
    Browse the repository at this point in the history

  20. Linux 3.4.102

    @gregkh
    gregkh committed Aug 7, 2014
    Configuration menu
    Copy the full SHA
    0a9d91d View commit details
    Browse the repository at this point in the history

Commits on Aug 8, 2014

  1. ext4: Add support for FIDTRIM, a best-effort ioctl for deep discard trim 

    * What
This provides an interface for issuing an FITRIM which uses the
secure discard instead of just a discard.
Only the eMMC command is "secure", and not how the FS uses it:
due to the fact that the FS might reassign a region somewhere else,
the original deleted data will not be affected by the "trim" which only
handles un-used regions.
So we'll just call it "deep discard", and note that this is a
"best effort" cleanup.

* Why
Once in a while, We want to be able to cleanup most of the unused blocks
after erasing a bunch of files.
We don't want to constantly secure-discard via a mount option.

From an eMMC spec perspective, it tells the device to really get rid of
all the data for the specified blocks and not just put them back into the
pool of free ones (unlike the normal TRIM). The eMMC spec says the
secure trim handling must make sure the data (and metadata) is not available
anymore. A simple TRIM doesn't clear the data, it just puts blocks in the
free pool.
JEDEC Standard No. 84-A441
  7.6.9 Secure Erase
  7.6.10 Secure Trim

From an FS perspective, it is acceptable to leave some data behind.
 - directory entries related to deleted files
 - databases entries related to deleted files
 - small-file data stored in inode extents
 - blocks held by the FS waiting to be re-used (mitigated by sync).
 - blocks reassigned by the FS prior to FIDTRIM.

Change-Id: I676a1404a80130d93930c84898360f2e6fb2f81e
Signed-off-by: Geremy Condra <[email protected]>
Signed-off-by: JP Abgrall <[email protected]>
    @jpa468
    jpa468 committed Aug 8, 2014
    Configuration menu
    Copy the full SHA
    9197ac4 View commit details
    Browse the repository at this point in the history

Commits on Aug 10, 2014

  1. Merge remote-tracking branch 'origin/mirror/android-3.4' into referen… 

    …ce-3.4
    @amery
    amery committed Aug 10, 2014
    Configuration menu
    Copy the full SHA
    2af0c35 View commit details
    Browse the repository at this point in the history

  2. Merge tag 'v3.4.102' into reference-3.4 

    This is the 3.4.102 stable release
    @amery
    amery committed Aug 10, 2014
    Configuration menu
    Copy the full SHA
    59c1c6b View commit details
    Browse the repository at this point in the history

  3. Merge branch 'reference-3.4' into stage/sunxi-3.4

    @amery
    amery committed Aug 10, 2014
    Configuration menu
    Copy the full SHA
    cf33a32 View commit details
    Browse the repository at this point in the history

  4. sun7i: Fixed symlink to sys_config.h

    @vbmithr @amery
    vbmithr authored and amery committed Aug 10, 2014
    Configuration menu
    Copy the full SHA
    d050898 View commit details
    Browse the repository at this point in the history

  5. sunxi: Possible G2D kernel bug 

    G2D seems to break if a zero value of src_rect.w or src_rect.h is
provided to g2d_blit, g2d_fill or g2d_stretchblit.
para.src_rect.w == 0 or para.src_rect.h == 0 results in trying to write
-1 toG2D_DMA0_SIZE_REG register within the mixer_* functions, e.g. here
https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/char/sunxi_g2d/g2d_bsp.c#L682

The following patch catches these zero value cases.

Signed-off-by: Andreas Baierl <[email protected]>
Signed-off-by: Henrik Nordstrom <[email protected]>
    @rellla @amery
    rellla authored and amery committed Aug 10, 2014
    Configuration menu
    Copy the full SHA
    3303e27 View commit details
    Browse the repository at this point in the history

  6. driver-core: cpu: export total_cpus to fix CPU_FREQ_STAT=m build 

    Commit a2425ff ("cpufreq: Persist cpufreq time in state data across
hotplug") from android-3.4 used total_cpus on the cpufreq stats module.
Unfortunately, this symbol is not exported, so build fails when
CPU_FREQ_STAT=m. This patch exports it for the time being to get the
tree building again.

Signed-off-by: Emilio López <[email protected]>
    @turl
    turl committed Aug 10, 2014
    Configuration menu
    Copy the full SHA
    83af551 View commit details
    Browse the repository at this point in the history

Commits on Aug 12, 2014

  1. staging: android: ashmem: Avoid deadlock with mmap/shrink 

    Both ashmem_mmap and ashmem_shrink take the ashmem_lock. It may
be possible for ashmem_mmap to invoke ashmem_shrink:

-000|mutex_lock(lock = 0x0)
-001|ashmem_shrink(?, sc = 0x0) <--- try to take ashmem_mutex again
-002|shrink_slab(shrink = 0xDA5F1CC0, nr_pages_scanned = 0, lru_pages
-002|=
-002|124)
-003|try_to_free_pages(zonelist = 0x0, ?, ?, ?)
-004|__alloc_pages_nodemask(gfp_mask = 21200, order = 1, zonelist =
-004|0xC11D0940,
-005|new_slab(s = 0xE4841E80, ?, node = -1)
-006|__slab_alloc.isra.43.constprop.50(s = 0xE4841E80, gfpflags =
-006|2148925462, ad
-007|kmem_cache_alloc(s = 0xE4841E80, gfpflags = 208)
-008|shmem_alloc_inode(?)
-009|alloc_inode(sb = 0xE480E800)
-010|new_inode_pseudo(?)
-011|new_inode(?)
-012|shmem_get_inode(sb = 0xE480E800, dir = 0x0, ?, dev = 0, flags =
-012|187)
-013|shmem_file_setup(?, ?, flags = 187)
-014|ashmem_mmap(?, vma = 0xC5D64210) <---- Acquire ashmem_mutex
-015|mmap_region(file = 0xDF8E2C00, addr = 1772974080, len = 233472,
-015|flags = 57,
-016|sys_mmap_pgoff(addr = 0, len = 230400, prot = 3, flags = 1, fd =
-016|157, pgoff
-017|ret_fast_syscall(asm)
-->|exception
-018|NUR:0x40097508(asm)
---|end of frame

Avoid this deadlock by using mutex_trylock in ashmem_shrink; if the mutex
is already held, do not attempt to shrink.

Change-Id: I222bbf55856d5849da813b730de0636c80966c8e
Reported-by: Matt Wagantall <[email protected]>
Reported-by: Syed Rameez Mustafa <[email protected]>
Reported-by: Osvaldo Banuelos <[email protected]>
Reported-by: Subbaraman Narayanamurthy <[email protected]>
Signed-off-by: Laura Abbott <[email protected]>
    @labbott
    labbott authored and Badhri Jagan Sridharan committed Aug 12, 2014
    Configuration menu
    Copy the full SHA
    6af84c9 View commit details
    Browse the repository at this point in the history

Commits on Aug 13, 2014

  1. mm: fix prctl_set_vma_anon_name 

    prctl_set_vma_anon_name could attempt to set the name across
two vmas at the same time due to a typo, which might corrupt
the vma list.  Fix it to use tmp instead of end to limit
the name setting to a single vma at a time.

Change-Id: Ie32d8ddb0fd547efbeedd6528acdab5ca5b308b4
Reported-by: Jed Davis <[email protected]>
Signed-off-by: Colin Cross <[email protected]>
    @colincross
    colincross committed Aug 13, 2014
    Configuration menu
    Copy the full SHA
    69bfe2d View commit details
    Browse the repository at this point in the history

Commits on Aug 14, 2014

  1. inetpeer: get rid of ip_id_count 

    [ Upstream commit 73f156a ]

Ideally, we would need to generate IP ID using a per destination IP
generator.

linux kernels used inet_peer cache for this purpose, but this had a huge
cost on servers disabling MTU discovery.

1) each inet_peer struct consumes 192 bytes

2) inetpeer cache uses a binary tree of inet_peer structs,
   with a nominal size of ~66000 elements under load.

3) lookups in this tree are hitting a lot of cache lines, as tree depth
   is about 20.

4) If server deals with many tcp flows, we have a high probability of
   not finding the inet_peer, allocating a fresh one, inserting it in
   the tree with same initial ip_id_count, (cf secure_ip_id())

5) We garbage collect inet_peer aggressively.

IP ID generation do not have to be 'perfect'

Goal is trying to avoid duplicates in a short period of time,
so that reassembly units have a chance to complete reassembly of
fragments belonging to one message before receiving other fragments
with a recycled ID.

We simply use an array of generators, and a Jenkin hash using the dst IP
as a key.

ipv6_select_ident() is put back into net/ipv6/ip6_output.c where it
belongs (it is only used from this file)

secure_ip_id() and secure_ipv6_id() no longer are needed.

Rename ip_select_ident_more() to ip_select_ident_segs() to avoid
unnecessary decrement/increment of the number of segments.

Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Eric Dumazet authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    ad52eef View commit details
    Browse the repository at this point in the history

  2. ip: make IP identifiers less predictable 

    [ Upstream commit 04ca697 ]

In "Counting Packets Sent Between Arbitrary Internet Hosts", Jeffrey and
Jedidiah describe ways exploiting linux IP identifier generation to
infer whether two machines are exchanging packets.

With commit 73f156a ("inetpeer: get rid of ip_id_count"), we
changed IP id generation, but this does not really prevent this
side-channel technique.

This patch adds a random amount of perturbation so that IP identifiers
for a given destination [1] are no longer monotonically increasing after
an idle period.

Note that prandom_u32_max(1) returns 0, so if generator is used at most
once per jiffy, this patch inserts no hole in the ID suite and do not
increase collision probability.

This is jiffies based, so in the worst case (HZ=1000), the id can
rollover after ~65 seconds of idle time, which should be fine.

We also change the hash used in __ip_select_ident() to not only hash
on daddr, but also saddr and protocol, so that ICMP probes can not be
used to infer information for other protocols.

For IPv6, adds saddr into the hash as well, but not nexthdr.

If I ping the patched target, we can see ID are now hard to predict.

21:57:11.008086 IP (...)
    A > target: ICMP echo request, seq 1, length 64
21:57:11.010752 IP (... id 2081 ...)
    target > A: ICMP echo reply, seq 1, length 64

21:57:12.013133 IP (...)
    A > target: ICMP echo request, seq 2, length 64
21:57:12.015737 IP (... id 3039 ...)
    target > A: ICMP echo reply, seq 2, length 64

21:57:13.016580 IP (...)
    A > target: ICMP echo request, seq 3, length 64
21:57:13.019251 IP (... id 3437 ...)
    target > A: ICMP echo reply, seq 3, length 64

[1] TCP sessions uses a per flow ID generator not changed by this patch.

Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: Jeffrey Knockel <[email protected]>
Reported-by: Jedidiah R. Crandall <[email protected]>
Cc: Willy Tarreau <[email protected]>
Cc: Hannes Frederic Sowa <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Eric Dumazet authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    509a15a View commit details
    Browse the repository at this point in the history

  3. net: sendmsg: fix NULL pointer dereference 

    [ Upstream commit 40eea80 ]

Sasha's report:
	> While fuzzing with trinity inside a KVM tools guest running the latest -next
	> kernel with the KASAN patchset, I've stumbled on the following spew:
	>
	> [ 4448.949424] ==================================================================
	> [ 4448.951737] AddressSanitizer: user-memory-access on address 0
	> [ 4448.952988] Read of size 2 by thread T19638:
	> [ 4448.954510] CPU: 28 PID: 19638 Comm: trinity-c76 Not tainted 3.16.0-rc4-next-20140711-sasha-00046-g07d3099-dirty torvalds#813
	> [ 4448.956823]  ffff88046d86ca40 0000000000000000 ffff880082f37e78 ffff880082f37a40
	> [ 4448.958233]  ffffffffb6e47068 ffff880082f37a68 ffff880082f37a58 ffffffffb242708d
	> [ 4448.959552]  0000000000000000 ffff880082f37a88 ffffffffb24255b1 0000000000000000
	> [ 4448.961266] Call Trace:
	> [ 4448.963158] dump_stack (lib/dump_stack.c:52)
	> [ 4448.964244] kasan_report_user_access (mm/kasan/report.c:184)
	> [ 4448.965507] __asan_load2 (mm/kasan/kasan.c:352)
	> [ 4448.966482] ? netlink_sendmsg (net/netlink/af_netlink.c:2339)
	> [ 4448.967541] netlink_sendmsg (net/netlink/af_netlink.c:2339)
	> [ 4448.968537] ? get_parent_ip (kernel/sched/core.c:2555)
	> [ 4448.970103] sock_sendmsg (net/socket.c:654)
	> [ 4448.971584] ? might_fault (mm/memory.c:3741)
	> [ 4448.972526] ? might_fault (./arch/x86/include/asm/current.h:14 mm/memory.c:3740)
	> [ 4448.973596] ? verify_iovec (net/core/iovec.c:64)
	> [ 4448.974522] ___sys_sendmsg (net/socket.c:2096)
	> [ 4448.975797] ? put_lock_stats.isra.13 (./arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254)
	> [ 4448.977030] ? lock_release_holdtime (kernel/locking/lockdep.c:273)
	> [ 4448.978197] ? lock_release_non_nested (kernel/locking/lockdep.c:3434 (discriminator 1))
	> [ 4448.979346] ? check_chain_key (kernel/locking/lockdep.c:2188)
	> [ 4448.980535] __sys_sendmmsg (net/socket.c:2181)
	> [ 4448.981592] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2600)
	> [ 4448.982773] ? trace_hardirqs_on (kernel/locking/lockdep.c:2607)
	> [ 4448.984458] ? syscall_trace_enter (arch/x86/kernel/ptrace.c:1500 (discriminator 2))
	> [ 4448.985621] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2600)
	> [ 4448.986754] SyS_sendmmsg (net/socket.c:2201)
	> [ 4448.987708] tracesys (arch/x86/kernel/entry_64.S:542)
	> [ 4448.988929] ==================================================================

This reports means that we've come to netlink_sendmsg() with msg->msg_name == NULL and msg->msg_namelen > 0.

After this report there was no usual "Unable to handle kernel NULL pointer dereference"
and this gave me a clue that address 0 is mapped and contains valid socket address structure in it.

This bug was introduced in f3d3342
(net: rework recvmsg handler msg_name and msg_namelen logic).
Commit message states that:
	"Set msg->msg_name = NULL if user specified a NULL in msg_name but had a
	 non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
	 affect sendto as it would bail out earlier while trying to copy-in the
	 address."
But in fact this affects sendto when address 0 is mapped and contains
socket address structure in it. In such case copy-in address will succeed,
verify_iovec() function will successfully exit with msg->msg_namelen > 0
and msg->msg_name == NULL.

This patch fixes it by setting msg_namelen to 0 if msg_name == NULL.

Cc: Hannes Frederic Sowa <[email protected]>
Cc: Eric Dumazet <[email protected]>
Cc: <[email protected]>
Reported-by: Sasha Levin <[email protected]>
Signed-off-by: Andrey Ryabinin <[email protected]>
Acked-by: Hannes Frederic Sowa <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @aryabinin @gregkh
    aryabinin authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    c28d71c View commit details
    Browse the repository at this point in the history

  4. tcp: Fix integer-overflows in TCP veno 

    [ Upstream commit 45a0769 ]

In veno we do a multiplication of the cwnd and the rtt. This
may overflow and thus their result is stored in a u64. However, we first
need to cast the cwnd so that actually 64-bit arithmetic is done.

A first attempt at fixing 76f1017 ([TCP]: TCP Veno congestion
control) was made by 1591311 (tcp: Overflow bug in Vegas), but it
failed to add the required cast in tcp_veno_cong_avoid().

Fixes: 76f1017 ([TCP]: TCP Veno congestion control)
Signed-off-by: Christoph Paasch <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Christoph Paasch authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    1f9480d View commit details
    Browse the repository at this point in the history

  5. tcp: Fix integer-overflow in TCP vegas 

    [ Upstream commit 1f74e61 ]

In vegas we do a multiplication of the cwnd and the rtt. This
may overflow and thus their result is stored in a u64. However, we first
need to cast the cwnd so that actually 64-bit arithmetic is done.

Then, we need to do do_div to allow this to be used on 32-bit arches.

Cc: Stephen Hemminger <[email protected]>
Cc: Neal Cardwell <[email protected]>
Cc: Eric Dumazet <[email protected]>
Cc: David Laight <[email protected]>
Cc: Doug Leith <[email protected]>
Fixes: 8d3a564 (tcp: tcp_vegas cong avoid fix)
Signed-off-by: Christoph Paasch <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Christoph Paasch authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    1d06a70 View commit details
    Browse the repository at this point in the history

  6. net: sctp: inherit auth_capable on INIT collisions 

    [ Upstream commit 1be9a95 ]

Jason reported an oops caused by SCTP on his ARM machine with
SCTP authentication enabled:

Internal error: Oops: 17 [#1] ARM
CPU: 0 PID: 104 Comm: sctp-test Not tainted 3.13.0-68744-g3632f30c9b20-dirty #1
task: c6eefa40 ti: c6f52000 task.ti: c6f52000
PC is at sctp_auth_calculate_hmac+0xc4/0x10c
LR is at sg_init_table+0x20/0x38
pc : [<c024bb80>]    lr : [<c00f32dc>]    psr: 40000013
sp : c6f538e8  ip : 00000000  fp : c6f53924
r10: c6f50d80  r9 : 00000000  r8 : 00010000
r7 : 00000000  r6 : c7be4000  r5 : 00000000  r4 : c6f56254
r3 : c00c8170  r2 : 00000001  r1 : 00000008  r0 : c6f1e660
Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005397f  Table: 06f28000  DAC: 00000015
Process sctp-test (pid: 104, stack limit = 0xc6f521c0)
Stack: (0xc6f538e8 to 0xc6f54000)
[...]
Backtrace:
[<c024babc>] (sctp_auth_calculate_hmac+0x0/0x10c) from [<c0249af8>] (sctp_packet_transmit+0x33c/0x5c8)
[<c02497bc>] (sctp_packet_transmit+0x0/0x5c8) from [<c023e96c>] (sctp_outq_flush+0x7fc/0x844)
[<c023e170>] (sctp_outq_flush+0x0/0x844) from [<c023ef78>] (sctp_outq_uncork+0x24/0x28)
[<c023ef54>] (sctp_outq_uncork+0x0/0x28) from [<c0234364>] (sctp_side_effects+0x1134/0x1220)
[<c0233230>] (sctp_side_effects+0x0/0x1220) from [<c02330b0>] (sctp_do_sm+0xac/0xd4)
[<c0233004>] (sctp_do_sm+0x0/0xd4) from [<c023675c>] (sctp_assoc_bh_rcv+0x118/0x160)
[<c0236644>] (sctp_assoc_bh_rcv+0x0/0x160) from [<c023d5bc>] (sctp_inq_push+0x6c/0x74)
[<c023d550>] (sctp_inq_push+0x0/0x74) from [<c024a6b0>] (sctp_rcv+0x7d8/0x888)

While we already had various kind of bugs in that area
ec0223e ("net: sctp: fix sctp_sf_do_5_1D_ce to verify if
we/peer is AUTH capable") and b14878c ("net: sctp: cache
auth_enable per endpoint"), this one is a bit of a different
kind.

Giving a bit more background on why SCTP authentication is
needed can be found in RFC4895:

  SCTP uses 32-bit verification tags to protect itself against
  blind attackers. These values are not changed during the
  lifetime of an SCTP association.

  Looking at new SCTP extensions, there is the need to have a
  method of proving that an SCTP chunk(s) was really sent by
  the original peer that started the association and not by a
  malicious attacker.

To cause this bug, we're triggering an INIT collision between
peers; normal SCTP handshake where both sides intent to
authenticate packets contains RANDOM; CHUNKS; HMAC-ALGO
parameters that are being negotiated among peers:

  ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
  <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
  -------------------- COOKIE-ECHO -------------------->
  <-------------------- COOKIE-ACK ---------------------

RFC4895 says that each endpoint therefore knows its own random
number and the peer's random number *after* the association
has been established. The local and peer's random number along
with the shared key are then part of the secret used for
calculating the HMAC in the AUTH chunk.

Now, in our scenario, we have 2 threads with 1 non-blocking
SEQ_PACKET socket each, setting up common shared SCTP_AUTH_KEY
and SCTP_AUTH_ACTIVE_KEY properly, and each of them calling
sctp_bindx(3), listen(2) and connect(2) against each other,
thus the handshake looks similar to this, e.g.:

  ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
  <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
  <--------- INIT[RANDOM; CHUNKS; HMAC-ALGO] -----------
  -------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] -------->
  ...

Since such collisions can also happen with verification tags,
the RFC4895 for AUTH rather vaguely says under section 6.1:

  In case of INIT collision, the rules governing the handling
  of this Random Number follow the same pattern as those for
  the Verification Tag, as explained in Section 5.2.4 of
  RFC 2960 [5]. Therefore, each endpoint knows its own Random
  Number and the peer's Random Number after the association
  has been established.

In RFC2960, section 5.2.4, we're eventually hitting Action B:

  B) In this case, both sides may be attempting to start an
     association at about the same time but the peer endpoint
     started its INIT after responding to the local endpoint's
     INIT. Thus it may have picked a new Verification Tag not
     being aware of the previous Tag it had sent this endpoint.
     The endpoint should stay in or enter the ESTABLISHED
     state but it MUST update its peer's Verification Tag from
     the State Cookie, stop any init or cookie timers that may
     running and send a COOKIE ACK.

In other words, the handling of the Random parameter is the
same as behavior for the Verification Tag as described in
Action B of section 5.2.4.

Looking at the code, we exactly hit the sctp_sf_do_dupcook_b()
case which triggers an SCTP_CMD_UPDATE_ASSOC command to the
side effect interpreter, and in fact it properly copies over
peer_{random, hmacs, chunks} parameters from the newly created
association to update the existing one.

Also, the old asoc_shared_key is being released and based on
the new params, sctp_auth_asoc_init_active_key() updated.
However, the issue observed in this case is that the previous
asoc->peer.auth_capable was 0, and has *not* been updated, so
that instead of creating a new secret, we're doing an early
return from the function sctp_auth_asoc_init_active_key()
leaving asoc->asoc_shared_key as NULL. However, we now have to
authenticate chunks from the updated chunk list (e.g. COOKIE-ACK).

That in fact causes the server side when responding with ...

  <------------------ AUTH; COOKIE-ACK -----------------

... to trigger a NULL pointer dereference, since in
sctp_packet_transmit(), it discovers that an AUTH chunk is
being queued for xmit, and thus it calls sctp_auth_calculate_hmac().

Since the asoc->active_key_id is still inherited from the
endpoint, and the same as encoded into the chunk, it uses
asoc->asoc_shared_key, which is still NULL, as an asoc_key
and dereferences it in ...

  crypto_hash_setkey(desc.tfm, &asoc_key->data[0], asoc_key->len)

... causing an oops. All this happens because sctp_make_cookie_ack()
called with the *new* association has the peer.auth_capable=1
and therefore marks the chunk with auth=1 after checking
sctp_auth_send_cid(), but it is *actually* sent later on over
the then *updated* association's transport that didn't initialize
its shared key due to peer.auth_capable=0. Since control chunks
in that case are not sent by the temporary association which
are scheduled for deletion, they are issued for xmit via
SCTP_CMD_REPLY in the interpreter with the context of the
*updated* association. peer.auth_capable was 0 in the updated
association (which went from COOKIE_WAIT into ESTABLISHED state),
since all previous processing that performed sctp_process_init()
was being done on temporary associations, that we eventually
throw away each time.

The correct fix is to update to the new peer.auth_capable
value as well in the collision case via sctp_assoc_update(),
so that in case the collision migrated from 0 -> 1,
sctp_auth_asoc_init_active_key() can properly recalculate
the secret. This therefore fixes the observed server panic.

Fixes: 730fc3d ("[SCTP]: Implete SCTP-AUTH parameter processing")
Reported-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Tested-by: Jason Gunthorpe <[email protected]>
Cc: Vlad Yasevich <[email protected]>
Acked-by: Vlad Yasevich <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Daniel Borkmann authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    0fd6471 View commit details
    Browse the repository at this point in the history

  7. macvlan: Initialize vlan_features to turn on offload support. 

    [ Upstream commit 081e83a ]

Macvlan devices do not initialize vlan_features.  As a result,
any vlan devices configured on top of macvlans perform very poorly.
Initialize vlan_features based on the vlan features of the lower-level
device.

Signed-off-by: Vlad Yasevich <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Vlad Yasevich authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    e2a2802 View commit details
    Browse the repository at this point in the history

  8. net: Correctly set segment mac_len in skb_segment(). 

    [ Upstream commit fcdfe3a ]

When performing segmentation, the mac_len value is copied right
out of the original skb.  However, this value is not always set correctly
(like when the packet is VLAN-tagged) and we'll end up copying a bad
value.

One way to demonstrate this is to configure a VM which tags
packets internally and turn off VLAN acceleration on the forwarding
bridge port.  The packets show up corrupt like this:
16:18:24.985548 52:54:00:ab:be:25 > 52:54:00:26:ce:a3, ethertype 802.1Q
(0x8100), length 1518: vlan 100, p 0, ethertype 0x05e0,
        0x0000:  8cdb 1c7c 8cdb 0064 4006 b59d 0a00 6402 ...|[email protected].
        0x0010:  0a00 6401 9e0d b441 0a5e 64ec 0330 14fa ..d....A.^d..0..
        0x0020:  29e3 01c9 f871 0000 0101 080a 000a e833)....q.........3
        0x0030:  000f 8c75 6e65 7470 6572 6600 6e65 7470 ...unetperf.netp
        0x0040:  6572 6600 6e65 7470 6572 6600 6e65 7470 erf.netperf.netp
        0x0050:  6572 6600 6e65 7470 6572 6600 6e65 7470 erf.netperf.netp
        0x0060:  6572 6600 6e65 7470 6572 6600 6e65 7470 erf.netperf.netp
        ...

This also leads to awful throughput as GSO packets are dropped and
cause retransmissions.

The solution is to set the mac_len using the values already available
in then new skb.  We've already adjusted all of the header offset, so we
might as well correctly figure out the mac_len using skb_reset_mac_len().
After this change, packets are segmented correctly and performance
is restored.

CC: Eric Dumazet <[email protected]>
Signed-off-by: Vlad Yasevich <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Vlad Yasevich authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    80db167 View commit details
    Browse the repository at this point in the history

  9. iovec: make sure the caller actually wants anything in memcpy_fromiov… 

    …ecend

[ Upstream commit 06ebb06 ]

Check for cases when the caller requests 0 bytes instead of running off
and dereferencing potentially invalid iovecs.

Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @sashalevin @gregkh
    sashalevin authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    8fbbef0 View commit details
    Browse the repository at this point in the history

  10. sctp: fix possible seqlock seadlock in sctp_packet_transmit() 

    [ Upstream commit 757efd3 ]

Dave reported following splat, caused by improper use of
IP_INC_STATS_BH() in process context.

BUG: using __this_cpu_add() in preemptible [00000000] code: trinity-c117/14551
caller is __this_cpu_preempt_check+0x13/0x20
CPU: 3 PID: 14551 Comm: trinity-c117 Not tainted 3.16.0+ #33
 ffffffff9ec898f0 0000000047ea7e23 ffff88022d32f7f0 ffffffff9e7ee207
 0000000000000003 ffff88022d32f818 ffffffff9e397eaa ffff88023ee70b40
 ffff88022d32f970 ffff8801c026d580 ffff88022d32f828 ffffffff9e397ee3
Call Trace:
 [<ffffffff9e7ee207>] dump_stack+0x4e/0x7a
 [<ffffffff9e397eaa>] check_preemption_disabled+0xfa/0x100
 [<ffffffff9e397ee3>] __this_cpu_preempt_check+0x13/0x20
 [<ffffffffc0839872>] sctp_packet_transmit+0x692/0x710 [sctp]
 [<ffffffffc082a7f2>] sctp_outq_flush+0x2a2/0xc30 [sctp]
 [<ffffffff9e0d985c>] ? mark_held_locks+0x7c/0xb0
 [<ffffffff9e7f8c6d>] ? _raw_spin_unlock_irqrestore+0x5d/0x80
 [<ffffffffc082b99a>] sctp_outq_uncork+0x1a/0x20 [sctp]
 [<ffffffffc081e112>] sctp_cmd_interpreter.isra.23+0x1142/0x13f0 [sctp]
 [<ffffffffc081c86b>] sctp_do_sm+0xdb/0x330 [sctp]
 [<ffffffff9e0b8f1b>] ? preempt_count_sub+0xab/0x100
 [<ffffffffc083b350>] ? sctp_cname+0x70/0x70 [sctp]
 [<ffffffffc08389ca>] sctp_primitive_ASSOCIATE+0x3a/0x50 [sctp]
 [<ffffffffc083358f>] sctp_sendmsg+0x88f/0xe30 [sctp]
 [<ffffffff9e0d673a>] ? lock_release_holdtime.part.28+0x9a/0x160
 [<ffffffff9e0d62ce>] ? put_lock_stats.isra.27+0xe/0x30
 [<ffffffff9e73b624>] inet_sendmsg+0x104/0x220
 [<ffffffff9e73b525>] ? inet_sendmsg+0x5/0x220
 [<ffffffff9e68ac4e>] sock_sendmsg+0x9e/0xe0
 [<ffffffff9e1c0c09>] ? might_fault+0xb9/0xc0
 [<ffffffff9e1c0bae>] ? might_fault+0x5e/0xc0
 [<ffffffff9e68b234>] SYSC_sendto+0x124/0x1c0
 [<ffffffff9e0136b0>] ? syscall_trace_enter+0x250/0x330
 [<ffffffff9e68c3ce>] SyS_sendto+0xe/0x10
 [<ffffffff9e7f9be4>] tracesys+0xdd/0xe2

This is a followup of commits f1d8cba ("inet: fix possible
seqlock deadlocks") and 7f88c6b ("ipv6: fix possible seqlock
deadlock in ip6_finish_output2")

Signed-off-by: Eric Dumazet <[email protected]>
Cc: Hannes Frederic Sowa <[email protected]>
Reported-by: Dave Jones <[email protected]>
Acked-by: Neil Horman <[email protected]>
Acked-by: Hannes Frederic Sowa <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Eric Dumazet authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    5c19acc View commit details
    Browse the repository at this point in the history

  11. sparc64: Fix argument sign extension for compat_sys_futex(). 

    [ Upstream commit aa3449e ]

Only the second argument, 'op', is signed.

Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @davem330 @gregkh
    davem330 authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    0da9685 View commit details
    Browse the repository at this point in the history

  12. sparc64: Make itc_sync_lock raw 

    [ Upstream commit 49b6c01 ]

One more place where we must not be able
to be preempted or to be interrupted in RT.

Always actually disable interrupts during
synchronization cycle.

Signed-off-by: Kirill Tkhai <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @tkhai @gregkh
    tkhai authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    4fdf73f View commit details
    Browse the repository at this point in the history

  13. sparc64: Handle 32-bit tasks properly in compute_effective_address(). 

    [ Upstream commit d037d16 ]

If we have a 32-bit task we must chop off the top 32-bits of the
64-bit value just as the cpu would.

Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @davem330 @gregkh
    davem330 authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    d2671e6 View commit details
    Browse the repository at this point in the history

  14. sparc64: Fix top-level fault handling bugs. 

    [ Upstream commit 70ffc6e ]

Make get_user_insn() able to cope with huge PMDs.

Next, make do_fault_siginfo() more robust when get_user_insn() can't
actually fetch the instruction.  In particular, use the MMU announced
fault address when that happens, instead of calling
compute_effective_address() and computing garbage.

Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @davem330 @gregkh
    davem330 authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    86982cf View commit details
    Browse the repository at this point in the history

  15. sparc64: Don't bark so loudly about 32-bit tasks generating 64-bit fa… 

    …ult addresses.

[ Upstream commit e5c460f ]

This was found using Dave Jone's trinity tool.

When a user process which is 32-bit performs a load or a store, the
cpu chops off the top 32-bits of the effective address before
translating it.

This is because we run 32-bit tasks with the PSTATE_AM (address
masking) bit set.

We can't run the kernel with that bit set, so when the kernel accesses
userspace no address masking occurs.

Since a 32-bit process will have no mappings in that region we will
properly fault, so we don't try to handle this using access_ok(),
which can safely just be a NOP on sparc64.

Real faults from 32-bit processes should never generate such addresses
so a bug check was added long ago, and it barks in the logs if this
happens.

But it also barks when a kernel user access causes this condition, and
that _can_ happen.  For example, if a pointer passed into a system call
is "0xfffffffc" and the kernel access 4 bytes offset from that pointer.

Just handle such faults normally via the exception entries.

Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @davem330 @gregkh
    davem330 authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    0de4921 View commit details
    Browse the repository at this point in the history

  16. sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus. 

    [ Upstream commit b18eb2d ]

Access to the TSB hash tables during TLB misses requires that there be
an atomic 128-bit quad load available so that we fetch a matching TAG
and DATA field at the same time.

On cpus prior to UltraSPARC-III only virtual address based quad loads
are available.  UltraSPARC-III and later provide physical address
based variants which are easier to use.

When we only have virtual address based quad loads available this
means that we have to lock the TSB into the TLB at a fixed virtual
address on each cpu when it runs that process.  We can't just access
the PAGE_OFFSET based aliased mapping of these TSBs because we cannot
take a recursive TLB miss inside of the TLB miss handler without
risking running out of hardware trap levels (some trap combinations
can be deep, such as those generated by register window spill and fill
traps).

Without huge pages it's working perfectly fine, but when the huge TSB
got added another chunk of fixed virtual address space was not
allocated for this second TSB mapping.

So we were mapping both the 8K and 4MB TSBs to the same exact virtual
address, causing multiple TLB matches which gives undefined behavior.

Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @davem330 @gregkh
    davem330 authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    fdd8801 View commit details
    Browse the repository at this point in the history

  17. sparc64: Add membar to Niagara2 memcpy code. 

    [ Upstream commit 5aa4ecf ]

This is the prevent previous stores from overlapping the block stores
done by the memcpy loop.

Based upon a glibc patch by Jose E. Marchesi

Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @davem330 @gregkh
    davem330 authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    8e8955a View commit details
    Browse the repository at this point in the history

  18. sparc64: Do not insert non-valid PTEs into the TSB hash table. 

    [ Upstream commit 18f3813 ]

The assumption was that update_mmu_cache() (and the equivalent for PMDs) would
only be called when the PTE being installed will be accessible by the user.

This is not true for code paths originating from remove_migration_pte().

There are dire consequences for placing a non-valid PTE into the TSB.  The TLB
miss frramework assumes thatwhen a TSB entry matches we can just load it into
the TLB and return from the TLB miss trap.

So if a non-valid PTE is in there, we will deadlock taking the TLB miss over
and over, never satisfying the miss.

Just exit early from update_mmu_cache() and friends in this situation.

Based upon a report and patch from Christopher Alexander Tobias Schulze.

Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @davem330 @gregkh
    davem330 authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    afa9b04 View commit details
    Browse the repository at this point in the history

  19. sparc64: Guard against flushing openfirmware mappings. 

    [ Upstream commit 4ca9a23 ]

Based almost entirely upon a patch by Christopher Alexander Tobias
Schulze.

In commit db64fe0 ("mm: rewrite vmap
layer") lazy VMAP tlb flushing was added to the vmalloc layer.  This
causes problems on sparc64.

Sparc64 has two VMAP mapped regions and they are not contiguous with
eachother.  First we have the malloc mapping area, then another
unrelated region, then the vmalloc region.

This "another unrelated region" is where the firmware is mapped.

If the lazy TLB flushing logic in the vmalloc code triggers after
we've had both a module unload and a vfree or similar, it will pass an
address range that goes from somewhere inside the malloc region to
somewhere inside the vmalloc region, and thus covering the
openfirmware area entirely.

The sparc64 kernel learns about openfirmware's dynamic mappings in
this region early in the boot, and then services TLB misses in this
area.  But openfirmware has some locked TLB entries which are not
mentioned in those dynamic mappings and we should thus not disturb
them.

These huge lazy TLB flush ranges causes those openfirmware locked TLB
entries to be removed, resulting in all kinds of problems including
hard hangs and crashes during reboot/reset.

Besides causing problems like this, such huge TLB flush ranges are
also incredibly inefficient.  A plea has been made with the author of
the VMAP lazy TLB flushing code, but for now we'll put a safety guard
into our flush_tlb_kernel_range() implementation.

Since the implementation has become non-trivial, stop defining it as a
macro and instead make it a function in a C source file.

Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @davem330 @gregkh
    davem330 authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    d7bcdfe View commit details
    Browse the repository at this point in the history

  20. bbc-i2c: Fix BBC I2C envctrl on SunBlade 2000 

    [ Upstream commit 5cdceab ]

Fix regression in bbc i2c temperature and fan control on some Sun systems
that causes the driver to refuse to load due to the bbc_i2c_bussel resource not
being present on the (second) i2c bus where the temperature sensors and fan
control are located. (The check for the number of resources was removed when
the driver was ported to a pure OF driver in mid 2008.)

Signed-off-by: Christopher Alexander Tobias Schulze <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @catschulze @gregkh
    catschulze authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    7554c49 View commit details
    Browse the repository at this point in the history

  21. sunsab: Fix detection of BREAK on sunsab serial console 

    [ Upstream commit fe41823 ]

Fix detection of BREAK on sunsab serial console: BREAK detection was only
performed when there were also serial characters received simultaneously.
To handle all BREAKs correctly, the check for BREAK and the corresponding
call to uart_handle_break() must also be done if count == 0, therefore
duplicate this code fragment and pull it out of the loop over the received
characters.

Patch applies to 3.16-rc6.

Signed-off-by: Christopher Alexander Tobias Schulze <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @catschulze @gregkh
    catschulze authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    a46e945 View commit details
    Browse the repository at this point in the history

  22. sparc64: ldc_connect() should not return EINVAL when handshake is in … 

    …progress.

[ Upstream commit 4ec1b01 ]

The LDC handshake could have been asynchronously triggered
after ldc_bind() enables the ldc_rx() receive interrupt-handler
(and thus intercepts incoming control packets)
and before vio_port_up() calls ldc_connect(). If that is the case,
ldc_connect() should return 0 and let the state-machine
progress.

Signed-off-by: Sowmini Varadhan <[email protected]>
Acked-by: Karl Volz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @sowminiv @gregkh
    sowminiv authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    29fa649 View commit details
    Browse the repository at this point in the history

  23. arch/sparc/math-emu/math_32.c: drop stray break operator 

    [ Upstream commit 093758e ]

This commit is a guesswork, but it seems to make sense to drop this
break, as otherwise the following line is never executed and becomes
dead code. And that following line actually saves the result of
local calculation by the pointer given in function argument. So the
proposed change makes sense if this code in the whole makes sense (but I
am unable to analyze it in the whole).

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81641
Reported-by: David Binderman <[email protected]>
Signed-off-by: Andrey Utkin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
    @gregkh
    Andrey Utkin authored and gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    0ace429 View commit details
    Browse the repository at this point in the history

  24. Linux 3.4.103

    @gregkh
    gregkh committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    9f089cf View commit details
    Browse the repository at this point in the history

  25. sunxi: g2d: don't skip mutex_unlock on invalid ioctl 

    Signed-off-by: Jens Kuske <[email protected]>
    @jemk @amery
    jemk authored and amery committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    70025fc View commit details
    Browse the repository at this point in the history

  26. sunxi: disp: Allow negative hardware cursor position 

    The hardware cursor coordinates seem to be signed 14 bit values.
This has been tested on sun4i and sun7i.

Signed-off-by: Jens Kuske <[email protected]>
    @jemk @amery
    jemk authored and amery committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    2aeb0e9 View commit details
    Browse the repository at this point in the history

  27. rename to sunxi_nand to avoid naming conflict 

    rename to sunxi_nand to avoid conflict with drivers/mtd/nand/nand.ko
    @tisdall @amery
    tisdall authored and amery committed Aug 14, 2014
    Configuration menu
    Copy the full SHA
    2a422e6 View commit details
    Browse the repository at this point in the history

Commits on Aug 24, 2014

  1. Merge remote-tracking branch 'origin/mirror/android-3.4' into referen… 

    …ce-3.4
    @amery
    amery committed Aug 24, 2014
    Configuration menu
    Copy the full SHA
    7121213 View commit details
    Browse the repository at this point in the history

  2. Merge tag 'v3.4.103' into reference-3.4 

    This is the 3.4.103 stable release
    @amery
    amery committed Aug 24, 2014
    Configuration menu
    Copy the full SHA
    fad8d8b View commit details
    Browse the repository at this point in the history

  3. Merge branch 'reference-3.4' into stage/sunxi-3.4

    @amery
    amery committed Aug 24, 2014
    Configuration menu
    Copy the full SHA
    0c7986b View commit details
    Browse the repository at this point in the history

Commits on Sep 7, 2014

  1. usb: gadget: midi: Fix ignored "index" and "id" module parameters 

    The MIDI USB gadget driver has "index" and "id" parameters which should
determine the alsa sound card index and id to use when registering the
card. Those parameters had no effect, as the relevant information is only
set on the midi structure after f_midi_register_card is called.

This patch moves the two initialisation statements before the function call.

Signed-off-by: Marcus Weseloh <[email protected]>
    @mawe42 @amery
    mawe42 authored and amery committed Sep 7, 2014
    Configuration menu
    Copy the full SHA
    8b5d92a View commit details
    Browse the repository at this point in the history

Commits on Sep 16, 2014

  1. net: wireless: bcmdhd: Disable OOB interrupt when WLAN is off 

    b/17446901

Change-Id: I99069c584fa7279b8bd5a61d64ce27764edbd1d8
Signed-off-by: Ritter Yeh <[email protected]>
Signed-off-by: Dmitry Shmidt <[email protected]>
    Ritter Yeh authored and Dmitry Shmidt committed Sep 16, 2014
    Configuration menu
    Copy the full SHA
    acddfe9 View commit details
    Browse the repository at this point in the history

Commits on Sep 17, 2014

  1. Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs 

    With this change, calling
  prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)
disables privilege granting operations at execve-time.  For example, a
process will not be able to execute a setuid binary to change their uid
or gid if this bit is set.  The same is true for file capabilities.

Additionally, LSM_UNSAFE_NO_NEW_PRIVS is defined to ensure that
LSMs respect the requested behavior.

To determine if the NO_NEW_PRIVS bit is set, a task may call
  prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0);
It returns 1 if set and 0 if it is not set. If any of the arguments are
non-zero, it will return -1 and set errno to -EINVAL.
(PR_SET_NO_NEW_PRIVS behaves similarly.)

This functionality is desired for the proposed seccomp filter patch
series.  By using PR_SET_NO_NEW_PRIVS, it allows a task to modify the
system call behavior for itself and its child tasks without being
able to impact the behavior of a more privileged task.

Another potential use is making certain privileged operations
unprivileged.  For example, chroot may be considered "safe" if it cannot
affect privileged tasks.

Note, this patch causes execve to fail when PR_SET_NO_NEW_PRIVS is
set and AppArmor is in use.  It is fixed in a subsequent patch.

Signed-off-by: Andy Lutomirski <[email protected]>
Signed-off-by: Will Drewry <[email protected]>
Acked-by: Eric Paris <[email protected]>

v18: updated change desc
v17: using new define values as per 3.4

Conflicts:
	include/linux/prctl.h
	kernel/sys.c
    @amluto @jpa468
    amluto authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    c937fa6 View commit details
    Browse the repository at this point in the history

  2. Fix execve behavior apparmor for PR_{GET,SET}_NO_NEW_PRIVS 

    Add support for AppArmor to explicitly fail requested domain transitions
if NO_NEW_PRIVS is set and the task is not unconfined.

Transitions from unconfined are still allowed because this always results
in a reduction of privileges.

Acked-by: Eric Paris <[email protected]>
Signed-off-by: Will Drewry <[email protected]>
Signed-off-by: John Johansen <[email protected]>
Signed-off-by: Andy Lutomirski <[email protected]>

v18: new acked-by, new description
    @jpa468
    John Johansen authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    db7c31a View commit details
    Browse the repository at this point in the history

  3. sk_run_filter: add BPF_S_ANC_SECCOMP_LD_W 

    Introduces a new BPF ancillary instruction that all LD calls will be
mapped through when skb_run_filter() is being used for seccomp BPF.  The
rewriting will be done using a secondary chk_filter function that is run
after skb_chk_filter.

The code change is guarded by CONFIG_SECCOMP_FILTER which is added,
along with the seccomp_bpf_load() function later in this series.

This is based on http://lkml.org/lkml/2012/3/2/141

Suggested-by: Indan Zupancic <[email protected]>
Signed-off-by: Will Drewry <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Acked-by: Eric Paris <[email protected]>

v18: rebase
...
v15: include seccomp.h explicitly for when seccomp_bpf_load exists.
v14: First cut using a single additional instruction
... v13: made bpf functions generic.
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    62a1475 View commit details
    Browse the repository at this point in the history

  4. net/compat.c,linux/filter.h: share compat_sock_fprog 

    Any other users of bpf_*_filter that take a struct sock_fprog from
userspace will need to be able to also accept a compat_sock_fprog
if the arch supports compat calls.  This change allows the existing
compat_sock_fprog be shared.

Signed-off-by: Will Drewry <[email protected]>
Acked-by: Serge Hallyn <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Acked-by: Eric Paris <[email protected]>

v18: tasered by the apostrophe police
v14: rebase/nochanges
v13: rebase on to 88ebdda
v12: rebase on to linux-next
v11: introduction
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    b21e3a1 View commit details
    Browse the repository at this point in the history

  5. seccomp: kill the seccomp_t typedef 

    Replaces the seccomp_t typedef with struct seccomp to match modern
kernel style.

Signed-off-by: Will Drewry <[email protected]>
Reviewed-by: James Morris <[email protected]>
Acked-by: Serge Hallyn <[email protected]>
Acked-by: Eric Paris <[email protected]>

v18: rebase
...
v14: rebase/nochanges
v13: rebase on to 88ebdda
v12: rebase on to linux-next
v8-v11: no changes
v7: struct seccomp_struct -> struct seccomp
v6: original inclusion in this series.
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    b6058d5 View commit details
    Browse the repository at this point in the history

  6. asm/syscall.h: add syscall_get_arch 

    Adds a stub for a function that will return the AUDIT_ARCH_* value
appropriate to the supplied task based on the system call convention.

For audit's use, the value can generally be hard-coded at the
audit-site.  However, for other functionality not inlined into syscall
entry/exit, this makes that information available.  seccomp_filter is
the first planned consumer and, as such, the comment indicates a tie to
CONFIG_HAVE_ARCH_SECCOMP_FILTER.

Suggested-by: Roland McGrath <[email protected]>
Signed-off-by: Will Drewry <[email protected]>
Acked-by: Serge Hallyn <[email protected]>
Acked-by: Eric Paris <[email protected]>

v18: comment and change reword and rebase.
v14: rebase/nochanges
v13: rebase on to 88ebdda
v12: rebase on to linux-next
v11: fixed improper return type
v10: introduced
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    ee6b389 View commit details
    Browse the repository at this point in the history

  7. arch/x86: add syscall_get_arch to syscall.h 

    Add syscall_get_arch() to export the current AUDIT_ARCH_* based on system call
entry path.

Signed-off-by: Will Drewry <[email protected]>
Acked-by: Serge Hallyn <[email protected]>
Reviewed-by: H. Peter Anvin <[email protected]>
Acked-by: Eric Paris <[email protected]>

v18: - update comment about x32 tasks
     - rebase to v3.4-rc2
v17: rebase and reviewed-by
v14: rebase/nochanges
v13: rebase on to 88ebdda
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    51db3fa View commit details
    Browse the repository at this point in the history

  8. seccomp: add system call filtering using BPF 

    [This patch depends on [email protected]'s no_new_privs patch:
   https://lkml.org/lkml/2012/1/30/264
 The whole series including Andrew's patches can be found here:
   https://github.com/redpig/linux/tree/seccomp
 Complete diff here:
   redpig/linux@1dc65fe...seccomp
]

This patch adds support for seccomp mode 2.  Mode 2 introduces the
ability for unprivileged processes to install system call filtering
policy expressed in terms of a Berkeley Packet Filter (BPF) program.
This program will be evaluated in the kernel for each system call
the task makes and computes a result based on data in the format
of struct seccomp_data.

A filter program may be installed by calling:
  struct sock_fprog fprog = { ... };
  ...
  prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &fprog);

The return value of the filter program determines if the system call is
allowed to proceed or denied.  If the first filter program installed
allows prctl(2) calls, then the above call may be made repeatedly
by a task to further reduce its access to the kernel.  All attached
programs must be evaluated before a system call will be allowed to
proceed.

Filter programs will be inherited across fork/clone and execve.
However, if the task attaching the filter is unprivileged
(!CAP_SYS_ADMIN) the no_new_privs bit will be set on the task.  This
ensures that unprivileged tasks cannot attach filters that affect
privileged tasks (e.g., setuid binary).

There are a number of benefits to this approach. A few of which are
as follows:
- BPF has been exposed to userland for a long time
- BPF optimization (and JIT'ing) are well understood
- Userland already knows its ABI: system call numbers and desired
  arguments
- No time-of-check-time-of-use vulnerable data accesses are possible.
- system call arguments are loaded on access only to minimize copying
  required for system call policy decisions.

Mode 2 support is restricted to architectures that enable
HAVE_ARCH_SECCOMP_FILTER.  In this patch, the primary dependency is on
syscall_get_arguments().  The full desired scope of this feature will
add a few minor additional requirements expressed later in this series.
Based on discussion, SECCOMP_RET_ERRNO and SECCOMP_RET_TRACE seem to be
the desired additional functionality.

No architectures are enabled in this patch.

Signed-off-by: Will Drewry <[email protected]>
Acked-by: Serge Hallyn <[email protected]>
Reviewed-by: Indan Zupancic <[email protected]>
Acked-by: Eric Paris <[email protected]>

v18: - rebase to v3.4-rc2
     - s/chk/check/ ([email protected],[email protected])
     - allocate with GFP_KERNEL|__GFP_NOWARN ([email protected])
     - add a comment for get_u32 regarding endianness (akpm@)
     - fix other typos, style mistakes (akpm@)
     - added acked-by
v17: - properly guard seccomp filter needed headers ([email protected])
     - tighten return mask to 0x7fff0000
v16: - no change
v15: - add a 4 instr penalty when counting a path to account for seccomp_filter
       size ([email protected])
     - drop the max insns to 256KB ([email protected])
     - return ENOMEM if the max insns limit has been hit ([email protected])
     - move IP checks after args ([email protected])
     - drop !user_filter check ([email protected])
     - only allow explicit bpf codes ([email protected])
     - exit_code -> exit_sig
v14: - put/get_seccomp_filter takes struct task_struct
       ([email protected],[email protected])
     - adds seccomp_chk_filter and drops general bpf_run/chk_filter user
     - add seccomp_bpf_load for use by net/core/filter.c
     - lower max per-process/per-hierarchy: 1MB
     - moved nnp/capability check prior to allocation
       (all of the above: [email protected])
v13: - rebase on to 88ebdda
v12: - added a maximum instruction count per path ([email protected],[email protected])
     - removed copy_seccomp ([email protected],[email protected])
     - reworded the prctl_set_seccomp comment ([email protected])
v11: - reorder struct seccomp_data to allow future args expansion ([email protected])
     - style clean up, @compat dropped, compat_sock_fprog32 ([email protected])
     - do_exit(SIGSYS) ([email protected], [email protected])
     - pare down Kconfig doc reference.
     - extra comment clean up
v10: - seccomp_data has changed again to be more aesthetically pleasing
       ([email protected])
     - calling convention is noted in a new u32 field using syscall_get_arch.
       This allows for cross-calling convention tasks to use seccomp filters.
       ([email protected])
     - lots of clean up (thanks, Indan!)
 v9: - n/a
 v8: - use bpf_chk_filter, bpf_run_filter. update load_fns
     - Lots of fixes courtesy of [email protected]:
     -- fix up load behavior, compat fixups, and merge alloc code,
     -- renamed pc and dropped __packed, use bool compat.
     -- Added a hidden CONFIG_SECCOMP_FILTER to synthesize non-arch
        dependencies
 v7:  (massive overhaul thanks to Indan, others)
     - added CONFIG_HAVE_ARCH_SECCOMP_FILTER
     - merged into seccomp.c
     - minimal seccomp_filter.h
     - no config option (part of seccomp)
     - no new prctl
     - doesn't break seccomp on systems without asm/syscall.h
       (works but arg access always fails)
     - dropped seccomp_init_task, extra free functions, ...
     - dropped the no-asm/syscall.h code paths
     - merges with network sk_run_filter and sk_chk_filter
 v6: - fix memory leak on attach compat check failure
     - require no_new_privs || CAP_SYS_ADMIN prior to filter
       installation. ([email protected])
     - s/seccomp_struct_/seccomp_/ for macros/functions ([email protected])
     - cleaned up Kconfig ([email protected])
     - on block, note if the call was compat (so the # means something)
 v5: - uses syscall_get_arguments
       ([email protected],[email protected], [email protected])
      - uses union-based arg storage with hi/lo struct to
        handle endianness.  Compromises between the two alternate
        proposals to minimize extra arg shuffling and account for
        endianness assuming userspace uses offsetof().
        ([email protected], [email protected])
      - update Kconfig description
      - add include/seccomp_filter.h and add its installation
      - (naive) on-demand syscall argument loading
      - drop seccomp_t ([email protected])
 v4:  - adjusted prctl to make room for PR_[SG]ET_NO_NEW_PRIVS
      - now uses current->no_new_privs
        ([email protected],[email protected])
      - assign names to seccomp modes ([email protected])
      - fix style issues ([email protected])
      - reworded Kconfig entry ([email protected])
 v3:  - macros to inline ([email protected])
      - init_task behavior fixed ([email protected])
      - drop creator entry and extra NULL check ([email protected])
      - alloc returns -EINVAL on bad sizing ([email protected])
      - adds tentative use of "always_unprivileged" as per
        [email protected] and [email protected]
 v2:  - (patch 2 only)
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    c67baf9 View commit details
    Browse the repository at this point in the history

  9. seccomp: remove duplicated failure logging 

    This consolidates the seccomp filter error logging path and adds more
details to the audit log.

Signed-off-by: Will Drewry <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
Acked-by: Eric Paris <[email protected]>

v18: make compat= permanent in the record
v15: added a return code to the audit_seccomp path by [email protected]
     (suggested by [email protected])
v*: original by [email protected]
    @kees @jpa468
    kees authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    6879398 View commit details
    Browse the repository at this point in the history

  10. seccomp: add SECCOMP_RET_ERRNO 

    This change adds the SECCOMP_RET_ERRNO as a valid return value from a
seccomp filter.  Additionally, it makes the first use of the lower
16-bits for storing a filter-supplied errno.  16-bits is more than
enough for the errno-base.h calls.

Returning errors instead of immediately terminating processes that
violate seccomp policy allow for broader use of this functionality
for kernel attack surface reduction.  For example, a linux container
could maintain a whitelist of pre-existing system calls but drop
all new ones with errnos.  This would keep a logically static attack
surface while providing errnos that may allow for graceful failure
without the downside of do_exit() on a bad call.

This change also changes the signature of __secure_computing.  It
appears the only direct caller is the arm entry code and it clobbers
any possible return value (register) immediately.

Signed-off-by: Will Drewry <[email protected]>
Acked-by: Serge Hallyn <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Acked-by: Eric Paris <[email protected]>

v18: - fix up comments and rebase
     - fix bad var name which was fixed in later revs
     - remove _int() and just change the __secure_computing signature
v16-v17: ...
v15: - use audit_seccomp and add a skip label. ([email protected])
     - clean up and pad out return codes ([email protected])
v14: - no change/rebase
v13: - rebase on to 88ebdda
v12: - move to WARN_ON if filter is NULL
       ([email protected], [email protected], [email protected])
     - return immediately for filter==NULL ([email protected])
     - change evaluation to only compare the ACTION so that layered
       errnos don't result in the lowest one being returned.
       ([email protected])
v11: - check for NULL filter ([email protected])
v10: - change loaders to fn
 v9: - n/a
 v8: - update Kconfig to note new need for syscall_set_return_value.
     - reordered such that TRAP behavior follows on later.
     - made the for loop a little less indent-y
 v7: - introduced
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    4aa8c42 View commit details
    Browse the repository at this point in the history

  11. signal, x86: add SIGSYS info and make it synchronous. 

    This change enables SIGSYS, defines _sigfields._sigsys, and adds
x86 (compat) arch support.  _sigsys defines fields which allow
a signal handler to receive the triggering system call number,
the relevant AUDIT_ARCH_* value for that number, and the address
of the callsite.

SIGSYS is added to the SYNCHRONOUS_MASK because it is desirable for it
to have setup_frame() called for it. The goal is to ensure that
ucontext_t reflects the machine state from the time-of-syscall and not
from another signal handler.

The first consumer of SIGSYS would be seccomp filter.  In particular,
a filter program could specify a new return value, SECCOMP_RET_TRAP,
which would result in the system call being denied and the calling
thread signaled.  This also means that implementing arch-specific
support can be dependent upon HAVE_ARCH_SECCOMP_FILTER.

Suggested-by: H. Peter Anvin <[email protected]>
Signed-off-by: Will Drewry <[email protected]>
Acked-by: Serge Hallyn <[email protected]>
Reviewed-by: H. Peter Anvin <[email protected]>
Acked-by: Eric Paris <[email protected]>

v18: - added acked by, rebase
v17: - rebase and reviewed-by addition
v14: - rebase/nochanges
v13: - rebase on to 88ebdda
v12: - reworded changelog ([email protected])
v11: - fix dropped words in the change description
     - added fallback copy_siginfo support.
     - added __ARCH_SIGSYS define to allow stepped arch support.
v10: - first version based on suggestion
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    ac119cb View commit details
    Browse the repository at this point in the history

  12. seccomp: Add SECCOMP_RET_TRAP 

    Adds a new return value to seccomp filters that triggers a SIGSYS to be
delivered with the new SYS_SECCOMP si_code.

This allows in-process system call emulation, including just specifying
an errno or cleanly dumping core, rather than just dying.

Suggested-by: Markus Gutschke <[email protected]>
Suggested-by: Julien Tinnes <[email protected]>
Signed-off-by: Will Drewry <[email protected]>
Acked-by: Eric Paris <[email protected]>

v18: - acked-by, rebase
     - don't mention secure_computing_int() anymore
v15: - use audit_seccomp/skip
     - pad out error spacing; clean up switch ([email protected])
v14: - n/a
v13: - rebase on to 88ebdda
v12: - rebase on to linux-next
v11: - clarify the comment ([email protected])
     - s/sigtrap/sigsys
v10: - use SIGSYS, syscall_get_arch, updates arch/Kconfig
       note suggested-by (though original suggestion had other behaviors)
v9:  - changes to SIGILL
v8:  - clean up based on changes to dependent patches
v7:  - introduction
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    4c4e7da View commit details
    Browse the repository at this point in the history

  13. ptrace,seccomp: Add PTRACE_SECCOMP support 

    This change adds support for a new ptrace option, PTRACE_O_TRACESECCOMP,
and a new return value for seccomp BPF programs, SECCOMP_RET_TRACE.

When a tracer specifies the PTRACE_O_TRACESECCOMP ptrace option, the
tracer will be notified, via PTRACE_EVENT_SECCOMP, for any syscall that
results in a BPF program returning SECCOMP_RET_TRACE.  The 16-bit
SECCOMP_RET_DATA mask of the BPF program return value will be passed as
the ptrace_message and may be retrieved using PTRACE_GETEVENTMSG.

If the subordinate process is not using seccomp filter, then no
system call notifications will occur even if the option is specified.

If there is no tracer with PTRACE_O_TRACESECCOMP when SECCOMP_RET_TRACE
is returned, the system call will not be executed and an -ENOSYS errno
will be returned to userspace.

This change adds a dependency on the system call slow path.  Any future
efforts to use the system call fast path for seccomp filter will need to
address this restriction.

Signed-off-by: Will Drewry <[email protected]>
Acked-by: Eric Paris <[email protected]>

v18: - rebase
     - comment fatal_signal check
     - acked-by
     - drop secure_computing_int comment
v17: - ...
v16: - update PT_TRACE_MASK to 0xbf4 so that STOP isn't clear on SETOPTIONS call ([email protected])
       [note PT_TRACE_MASK disappears in linux-next]
v15: - add audit support for non-zero return codes
     - clean up style ([email protected])
v14: - rebase/nochanges
v13: - rebase on to 88ebdda
       (Brings back a change to ptrace.c and the masks.)
v12: - rebase to linux-next
     - use ptrace_event and update arch/Kconfig to mention slow-path dependency
     - drop all tracehook changes and inclusion ([email protected])
v11: - invert the logic to just make it a PTRACE_SYSCALL accelerator
       ([email protected])
v10: - moved to PTRACE_O_SECCOMP / PT_TRACE_SECCOMP
v9:  - n/a
v8:  - guarded PTRACE_SECCOMP use with an ifdef
v7:  - introduced
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    f33422b View commit details
    Browse the repository at this point in the history

  14. Change-Id: I7c9d49079d4e18390c2d520513a4afd55e6eaa3e

    @jpa468
    Sasha Levitskiy authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    d4f8f7e View commit details
    Browse the repository at this point in the history

  15. Documentation: prctl/seccomp_filter 

    Documents how system call filtering using Berkeley Packet
Filter programs works and how it may be used.
Includes an example for x86 and a semi-generic
example using a macro-based code generator.

Acked-by: Eric Paris <[email protected]>
Signed-off-by: Will Drewry <[email protected]>

v18: - added acked by
     - update no new privs numbers
v17: - remove @compat note and add Pitfalls section for arch checking
       ([email protected])
v16: -
v15: -
v14: - rebase/nochanges
v13: - rebase on to 88ebdda
v12: - comment on the ptrace_event use
     - update arch support comment
     - note the behavior of SECCOMP_RET_DATA when there are multiple filters
       ([email protected])
     - lots of samples/ clean up incl 64-bit bpf-direct support
       ([email protected])
     - rebase to linux-next
v11: - overhaul return value language, updates ([email protected])
     - comment on do_exit(SIGSYS)
v10: - update for SIGSYS
     - update for new seccomp_data layout
     - update for ptrace option use
v9: - updated bpf-direct.c for SIGILL
v8: - add PR_SET_NO_NEW_PRIVS to the samples.
v7: - updated for all the new stuff in v7: TRAP, TRACE
    - only talk about PR_SET_SECCOMP now
    - fixed bad JLE32 check ([email protected])
    - adds dropper.c: a simple system call disabler
v6: - tweak the language to note the requirement of
      PR_SET_NO_NEW_PRIVS being called prior to use. ([email protected])
v5: - update sample to use system call arguments
    - adds a "fancy" example using a macro-based generator
    - cleaned up bpf in the sample
    - update docs to mention arguments
    - fix prctl value ([email protected])
    - language cleanup ([email protected])
v4: - update for no_new_privs use
    - minor tweaks
v3: - call out BPF <-> Berkeley Packet Filter ([email protected])
    - document use of tentative always-unprivileged
    - guard sample compilation for i386 and x86_64
v2: - move code to samples ([email protected])
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    3e5a21d View commit details
    Browse the repository at this point in the history

  16. seccomp: use a static inline for a function stub 

    Fixes this error message when CONFIG_SECCOMP is not set:

arch/powerpc/kernel/ptrace.c: In function 'do_syscall_trace_enter':
arch/powerpc/kernel/ptrace.c:1713:2: error: statement with no effect [-Werror=unused-value]

Signed-off-by: Stephen Rothwell <[email protected]>
Signed-off-by: James Morris <[email protected]>
    @sfrothwell @jpa468
    sfrothwell authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    ef7720c View commit details
    Browse the repository at this point in the history

  17. seccomp: ignore secure_computing return values 

    This change is inspired by
  https://lkml.org/lkml/2012/4/16/14
which fixes the build warnings for arches that don't support
CONFIG_HAVE_ARCH_SECCOMP_FILTER.

In particular, there is no requirement for the return value of
secure_computing() to be checked unless the architecture supports
seccomp filter.  Instead of silencing the warnings with (void)
a new static inline is added to encode the expected behavior
in a compiler and human friendly way.

v2: - cleans things up with a static inline
    - removes sfr's signed-off-by since it is a different approach
v1: - matches sfr's original change

Reported-by: Stephen Rothwell <[email protected]>
Signed-off-by: Will Drewry <[email protected]>
Acked-by: Kees Cook <[email protected]>
Signed-off-by: James Morris <[email protected]>
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    dc46412 View commit details
    Browse the repository at this point in the history

  18. seccomp: fix build warnings when there is no CONFIG_SECCOMP_FILTER 

    If both audit and seccomp filter support are disabled, 'ret' is marked
as unused.

If just seccomp filter support is disabled, data and skip are considered
unused.

This change fixes those build warnings.

Reported-by: Stephen Rothwell <[email protected]>
Signed-off-by: Will Drewry <[email protected]>
Acked-by: Kees Cook <[email protected]>
Signed-off-by: James Morris <[email protected]>
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    7119ba4 View commit details
    Browse the repository at this point in the history

  19. samples/seccomp: fix dependencies on arch macros 

    This change fixes the compilation error reported for
i386 allmodconfig here:
  http://kisskb.ellerman.id.au/kisskb/buildresult/6123842/

Logic attempting to predict the host architecture has been
removed from the Makefile.  Instead, the bpf-direct sample
should now compile on any architecture, but if the architecture
is not supported, it will compile a minimal main() function.

This change also ensures the samples are not compiled when
there is no seccomp filter support.

Reported-by: Paul Gortmaker <[email protected]>
Suggested-by: Kees Cook <[email protected]>
Signed-off-by: Will Drewry <[email protected]>
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    0d38273 View commit details
    Browse the repository at this point in the history

  20. CHROMIUM: arch/arm: add asm/syscall.h 

    (I will post this upstream after the 3.5 merge window)

Provide an ARM implementation for asm-generic/syscall.h.
This is a pre-requisite for CONFIG_HAVE_ARCH_TRACEHOOK and
CONFIG_HAVE_ARCH_SECCOMP_FILTER.  The latter is the forcing
function for this patch.

Change-Id: Idc5fa7b72691ec9d75418849733633df33482e53
Signed-off-by: Will Drewry <[email protected]>

BUG=chromium-os:27878
TEST=compiles for arm. Need to test on a live machine.

Change-Id: I7b911b51085424aedd2beaf40683c3348b6cede1
Reviewed-on: https://gerrit.chromium.org/gerrit/21375
Reviewed-by: Will Drewry <[email protected]>
Tested-by: Will Drewry <[email protected]>
Signed-off-by: Sasha Levitskiy <[email protected]>
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    1c0d3df View commit details
    Browse the repository at this point in the history

  21. CHROMIUM: arch/arm: move secure_computing into trace; respect return … 

    …code

There is very little difference in the TIF_SECCOMP and TIF_SYSCALL_TRACE
patsh in entry-common.S. In order to add support for
CONFIG_HAVE_ARCH_SECCOMP_FILTER without mangling the assembly too
badly, seccomp was moved into the syscall_trace() handler.

Additionally, the return value for secure_computing() is now checked
and a -1 value will result in the system call being skipped.

(Reworked for 3.4 merge to just piggyback on the audit enter path.)

Signed-off-by: Will Drewry <[email protected]>

BUG=chromium-os:27878
TEST=compiles for arm. Need to test on a live machine.

Change-Id: I9493f28c30356a10eccb320e0a2d1a141388af9a
Reviewed-on: https://gerrit.chromium.org/gerrit/21376
Reviewed-by: Will Drewry <[email protected]>
Tested-by: Will Drewry <[email protected]>
Signed-off-by: Sasha Levitskiy <[email protected]>
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    66a240a View commit details
    Browse the repository at this point in the history

  22. CHROMIUM: arch/arm: select HAVE_ARCH_SECCOMP_FILTER 

    (I will post this upstream after the 3.5 merge window)

Reflect architectural support for seccomp filter.

Change-Id: I163078260e73a8fb7b9967ce740bd21f83902b8e
Signed-off-by: Will Drewry <[email protected]>

BUG=chromium-os:27878
TEST=compiles for arm. Need to test on a live machine.

Change-Id: Ic0286cc7d150838fbfa05e259ea908aeeef1b864
Reviewed-on: https://gerrit.chromium.org/gerrit/21377
Reviewed-by: Will Drewry <[email protected]>
Tested-by: Will Drewry <[email protected]>
Signed-off-by: Sasha Levitskiy <[email protected]>
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    0d245c7 View commit details
    Browse the repository at this point in the history

  23. CHROMIUM: ARM: arch/arm: allow a scno of -1 to not cause a SIGILL 

    On tracehook-friendly platforms, a system call number of -1 falls
through without running much code or taking much action.

ARM is different.  This adds a lightweight check to arm_syscall()
to make sure that ARM behaves the same way.

Signed-off-by: Will Drewry <[email protected]>
TEST=building on tegra2 now. Will live test with seccomp testsuite. It was through SIGILL.
BUG=chromium-os:27878

Change-Id: Ie3896b54e9bfa21c22e0df456a47ad03c8d0aa3f
Reviewed-on: https://gerrit.chromium.org/gerrit/21251
Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Will Drewry <[email protected]>
Tested-by: Will Drewry <[email protected]>
Signed-off-by: Sasha Levitskiy <[email protected]>
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    b99d845 View commit details
    Browse the repository at this point in the history

  24. CHROMIUM: seccomp: set -ENOSYS if there is no tracer 

    [Will attempt to add to -next, but this may need to wait
 until there is a motivating usecase, like ARM, since x86
 does the right thing already.]

On some arches, -ENOSYS is not set as the default system call
return value.  This means that a skipped or invalid system call
does not yield this response.  That behavior is not inline with
the stated ABI of seccomp filter.  To that end, we ensure we set
that value here to avoid arch idiosyncrasies.

Signed-off-by: Will Drewry <[email protected]>
TEST=tegra2_kaen; boot, strace works, seccomp testsuite  trace tests pass
BUG=chromium-os:27878

Change-Id: I03a5e633d2fbb5d3d3cc33c067b2887068364c17
Reviewed-on: https://gerrit.chromium.org/gerrit/21337
Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Will Drewry <[email protected]>
Tested-by: Will Drewry <[email protected]>
Signed-off-by: Sasha Levitskiy <[email protected]>
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    2e48e52 View commit details
    Browse the repository at this point in the history

  25. CHROMIUM: ARM: r1->r0 for get/set arguments 

    ARM reuses r0 as the first argument. This fixes the mistaken
assumption in the original patchset.  These will be merged
into one change when sent upstream.

Signed-off-by: Will Drewry <[email protected]>
TEST=emerge tegra2_kaen; run seccomp testsuite
BUG=chromium-os:27878

Change-Id: Iaaa09995d35f78ee8cef7b600d526e71f3b2fcec
Reviewed-on: https://gerrit.chromium.org/gerrit/21342
Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Will Drewry <[email protected]>
Tested-by: Will Drewry <[email protected]>
Signed-off-by: Sasha Levitskiy <[email protected]>
    @redpig @jpa468
    redpig authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    4e93e06 View commit details
    Browse the repository at this point in the history

  26. MAINTAINERS: create seccomp entry 

    Add myself as seccomp maintainer.

Suggested-by: James Morris <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
    @kees @jpa468
    kees authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    5255fd2 View commit details
    Browse the repository at this point in the history

  27. seccomp: create internal mode-setting function 

    In preparation for having other callers of the seccomp mode setting
logic, split the prctl entry point away from the core logic that performs
seccomp mode setting.

Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Oleg Nesterov <[email protected]>
Reviewed-by: Andy Lutomirski <[email protected]>
    @kees @jpa468
    kees authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    1cf256f View commit details
    Browse the repository at this point in the history

  28. seccomp: extract check/assign mode helpers 

    To support splitting mode 1 from mode 2, extract the mode checking and
assignment logic into common functions.

Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Oleg Nesterov <[email protected]>
Reviewed-by: Andy Lutomirski <[email protected]>
    @kees @jpa468
    kees authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    bd8e1ca View commit details
    Browse the repository at this point in the history

  29. seccomp: split mode setting routines 

    Separates the two mode setting paths to make things more readable with
fewer #ifdefs within function bodies.

Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Oleg Nesterov <[email protected]>
Reviewed-by: Andy Lutomirski <[email protected]>
    @kees @jpa468
    kees authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    4adf2cd View commit details
    Browse the repository at this point in the history

  30. seccomp: add "seccomp" syscall 

    This adds the new "seccomp" syscall with both an "operation" and "flags"
parameter for future expansion. The third argument is a pointer value,
used with the SECCOMP_SET_MODE_FILTER operation. Currently, flags must
be 0. This is functionally equivalent to prctl(PR_SET_SECCOMP, ...).

In addition to the TSYNC flag later in this patch series, there is a
non-zero chance that this syscall could be used for configuring a fixed
argument area for seccomp-tracer-aware processes to pass syscall arguments
in the future. Hence, the use of "seccomp" not simply "seccomp_add_filter"
for this syscall. Additionally, this syscall uses operation, flags,
and user pointer for arguments because strictly passing arguments via
a user pointer would mean seccomp itself would be unable to trivially
filter the seccomp syscall itself.

Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Oleg Nesterov <[email protected]>
Reviewed-by: Andy Lutomirski <[email protected]>

Conflicts:
	arch/x86/syscalls/syscall_32.tbl
	arch/x86/syscalls/syscall_64.tbl
	include/linux/syscalls.h
	include/uapi/asm-generic/unistd.h
	include/uapi/linux/seccomp.h
	kernel/seccomp.c
	kernel/sys_ni.c
    @kees @jpa468
    kees authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    64d484e View commit details
    Browse the repository at this point in the history

  31. ARM: add seccomp syscall 

    Wires up the new seccomp syscall.

Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Oleg Nesterov <[email protected]>

Conflicts:
	arch/arm/include/uapi/asm/unistd.h
	arch/arm/kernel/calls.S
    @kees @jpa468
    kees authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    13b77e1 View commit details
    Browse the repository at this point in the history

  32. sched: move no_new_privs into new atomic flags 

    Since seccomp transitions between threads requires updates to the
no_new_privs flag to be atomic, the flag must be part of an atomic flag
set. This moves the nnp flag into a separate task field, and introduces
accessors.

Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Oleg Nesterov <[email protected]>
Reviewed-by: Andy Lutomirski <[email protected]>

Conflicts:
	fs/exec.c
	include/linux/sched.h
	kernel/sys.c
    @kees @jpa468
    kees authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    db8ca0a View commit details
    Browse the repository at this point in the history

  33. seccomp: split filter prep from check and apply 

    In preparation for adding seccomp locking, move filter creation away
from where it is checked and applied. This will allow for locking where
no memory allocation is happening. The validation, filter attachment,
and seccomp mode setting can all happen under the future locks.

For extreme defensiveness, I've added a BUG_ON check for the calculated
size of the buffer allocation in case BPF_MAXINSN ever changes, which
shouldn't ever happen. The compiler should actually optimize out this
check since the test above it makes it impossible.

Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Oleg Nesterov <[email protected]>
Reviewed-by: Andy Lutomirski <[email protected]>

Conflicts:
	kernel/seccomp.c
    @kees @jpa468
    kees authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    850c366 View commit details
    Browse the repository at this point in the history

  34. seccomp: introduce writer locking 

    Normally, task_struct.seccomp.filter is only ever read or modified by
the task that owns it (current). This property aids in fast access
during system call filtering as read access is lockless.

Updating the pointer from another task, however, opens up race
conditions. To allow cross-thread filter pointer updates, writes to the
seccomp fields are now protected by the sighand spinlock (which is shared
by all threads in the thread group). Read access remains lockless because
pointer updates themselves are atomic.  However, writes (or cloning)
often entail additional checking (like maximum instruction counts)
which require locking to perform safely.

In the case of cloning threads, the child is invisible to the system
until it enters the task list. To make sure a child can't be cloned from
a thread and left in a prior state, seccomp duplication is additionally
moved under the sighand lock. Then parent and child are certain have
the same seccomp state when they exit the lock.

Based on patches by Will Drewry and David Drysdale.

Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Oleg Nesterov <[email protected]>
Reviewed-by: Andy Lutomirski <[email protected]>

Conflicts:
	kernel/fork.c
    @kees @jpa468
    kees authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    4cad9be View commit details
    Browse the repository at this point in the history

  35. seccomp: allow mode setting across threads 

    This changes the mode setting helper to allow threads to change the
seccomp mode from another thread. We must maintain barriers to keep
TIF_SECCOMP synchronized with the rest of the seccomp state.

Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Oleg Nesterov <[email protected]>
Reviewed-by: Andy Lutomirski <[email protected]>

Conflicts:
	kernel/seccomp.c
    @kees @jpa468
    kees authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    a4c269c View commit details
    Browse the repository at this point in the history

  36. introduce for_each_thread() to replace the buggy while_each_thread() 

    while_each_thread() and next_thread() should die, almost every lockless
usage is wrong.

1. Unless g == current, the lockless while_each_thread() is not safe.

   while_each_thread(g, t) can loop forever if g exits, next_thread()
   can't reach the unhashed thread in this case. Note that this can
   happen even if g is the group leader, it can exec.

2. Even if while_each_thread() itself was correct, people often use
   it wrongly.

   It was never safe to just take rcu_read_lock() and loop unless
   you verify that pid_alive(g) == T, even the first next_thread()
   can point to the already freed/reused memory.

This patch adds signal_struct->thread_head and task->thread_node to
create the normal rcu-safe list with the stable head.  The new
for_each_thread(g, t) helper is always safe under rcu_read_lock() as
long as this task_struct can't go away.

Note: of course it is ugly to have both task_struct->thread_node and the
old task_struct->thread_group, we will kill it later, after we change
the users of while_each_thread() to use for_each_thread().

Perhaps we can kill it even before we convert all users, we can
reimplement next_thread(t) using the new thread_head/thread_node.  But
we can't do this right now because this will lead to subtle behavioural
changes.  For example, do/while_each_thread() always sees at least one
task, while for_each_thread() can do nothing if the whole thread group
has died.  Or thread_group_empty(), currently its semantics is not clear
unless thread_group_leader(p) and we need to audit the callers before we
can change it.

So this patch adds the new interface which has to coexist with the old
one for some time, hopefully the next changes will be more or less
straightforward and the old one will go away soon.

Signed-off-by: Oleg Nesterov <[email protected]>
Reviewed-by: Sergey Dyasly <[email protected]>
Tested-by: Sergey Dyasly <[email protected]>
Reviewed-by: Sameer Nanda <[email protected]>
Acked-by: David Rientjes <[email protected]>
Cc: "Eric W. Biederman" <[email protected]>
Cc: Frederic Weisbecker <[email protected]>
Cc: Mandeep Singh Baines <[email protected]>
Cc: "Ma, Xindong" <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: "Tu, Xiaobing" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

Conflicts:
	kernel/fork.c
    @oleg-nesterov @jpa468
    oleg-nesterov authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    4202973 View commit details
    Browse the repository at this point in the history

  37. seccomp: implement SECCOMP_FILTER_FLAG_TSYNC 

    Applying restrictive seccomp filter programs to large or diverse
codebases often requires handling threads which may be started early in
the process lifetime (e.g., by code that is linked in). While it is
possible to apply permissive programs prior to process start up, it is
difficult to further restrict the kernel ABI to those threads after that
point.

This change adds a new seccomp syscall flag to SECCOMP_SET_MODE_FILTER for
synchronizing thread group seccomp filters at filter installation time.

When calling seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC,
filter) an attempt will be made to synchronize all threads in current's
threadgroup to its new seccomp filter program. This is possible iff all
threads are using a filter that is an ancestor to the filter current is
attempting to synchronize to. NULL filters (where the task is running as
SECCOMP_MODE_NONE) are also treated as ancestors allowing threads to be
transitioned into SECCOMP_MODE_FILTER. If prctrl(PR_SET_NO_NEW_PRIVS,
...) has been set on the calling thread, no_new_privs will be set for
all synchronized threads too. On success, 0 is returned. On failure,
the pid of one of the failing threads will be returned and no filters
will have been applied.

The race conditions against another thread are:
- requesting TSYNC (already handled by sighand lock)
- performing a clone (already handled by sighand lock)
- changing its filter (already handled by sighand lock)
- calling exec (handled by cred_guard_mutex)
The clone case is assisted by the fact that new threads will have their
seccomp state duplicated from their parent before appearing on the tasklist.

Holding cred_guard_mutex means that seccomp filters cannot be assigned
while in the middle of another thread's exec (potentially bypassing
no_new_privs or similar). The call to de_thread() may kill threads waiting
for the mutex.

Changes across threads to the filter pointer includes a barrier.

Based on patches by Will Drewry.

Suggested-by: Julien Tinnes <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Oleg Nesterov <[email protected]>
Reviewed-by: Andy Lutomirski <[email protected]>

Conflicts:
	include/linux/seccomp.h
	include/uapi/linux/seccomp.h
    @kees @jpa468
    kees authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    f1a3422 View commit details
    Browse the repository at this point in the history

  38. seccomp: Use atomic operations that are present in kernel 3.4. 

    Signed-off-by: Robert Sesek <[email protected]>
    @rsesek @jpa468
    rsesek authored and jpa468 committed Sep 17, 2014
    Configuration menu
    Copy the full SHA
    a94cffc View commit details
    Browse the repository at this point in the history

Commits on Sep 25, 2014

  1. stable_kernel_rules: Add pointer to netdev-FAQ for network patches 

    commit b76fc28 upstream.

Stable_kernel_rules should point submitters of network stable patches to the
netdev_FAQ.txt as requests for stable network patches should go to netdev
first.

Signed-off-by: Dave Chiluk <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @lizf-os
    Dave Chiluk authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    b402b72 View commit details
    Browse the repository at this point in the history

  2. ASoC: pxa-ssp: drop SNDRV_PCM_FMTBIT_S24_LE 

    commit 9301503 upstream.

This mode is unsupported, as the DMA controller can't do zero-padding
of samples.

Signed-off-by: Daniel Mack <[email protected]>
Reported-by: Johannes Stezenbach <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @zonque @lizf-os
    zonque authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    c27d3b5 View commit details
    Browse the repository at this point in the history

  3. ibmveth: Fix endian issues with rx_no_buffer statistic 

    commit cbd5228 upstream.

Hidden away in the last 8 bytes of the buffer_list page is a solitary
statistic. It needs to be byte swapped or else ethtool -S will
produce numbers that terrify the user.

Since we do this in multiple places, create a helper function with a
comment explaining what is going on.

Signed-off-by: Anton Blanchard <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @antonblanchard @lizf-os
    antonblanchard authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    9220628 View commit details
    Browse the repository at this point in the history

  4. HID: fix a couple of off-by-ones 

    commit 4ab2578 upstream.

There are a few very theoretical off-by-one bugs in report descriptor size
checking when performing a pre-parsing fixup. Fix those.

Reported-by: Ben Hawkes <[email protected]>
Reviewed-by: Benjamin Tissoires <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <[email protected]>
    @lizf-os
    Jiri Kosina authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    dab2f9b View commit details
    Browse the repository at this point in the history

  5. HID: logitech: perform bounds checking on device_id early enough 

    commit ad3e14d upstream.

device_index is a char type and the size of paired_dj_deivces is 7
elements, therefore proper bounds checking has to be applied to
device_index before it is used.

We are currently performing the bounds checking in
logi_dj_recv_add_djhid_device(), which is too late, as malicious device
could send REPORT_TYPE_NOTIF_DEVICE_UNPAIRED early enough and trigger the
problem in one of the report forwarding functions called from
logi_dj_raw_event().

Fix this by performing the check at the earliest possible ocasion in
logi_dj_raw_event().

Reported-by: Ben Hawkes <[email protected]>
Reviewed-by: Benjamin Tissoires <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @lizf-os
    Jiri Kosina authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    c945ed6 View commit details
    Browse the repository at this point in the history

  6. isofs: Fix unbounded recursion when processing relocated directories 

    commit 410dd3c upstream.

We did not check relocated directory in any way when processing Rock
Ridge 'CL' tag. Thus a corrupted isofs image can possibly have a CL
entry pointing to another CL entry leading to possibly unbounded
recursion in kernel code and thus stack overflow or deadlocks (if there
is a loop created from CL entries).

Fix the problem by not allowing CL entry to point to a directory entry
with CL entry (such use makes no good sense anyway) and by checking
whether CL entry doesn't point to itself.

Reported-by: Chris Evans <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @jankara @lizf-os
    jankara authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    5ccd3e2 View commit details
    Browse the repository at this point in the history

  7. MIPS: OCTEON: make get_system_type() thread-safe 

    commit 6083086 upstream.

get_system_type() is not thread-safe on OCTEON. It uses static data,
also more dangerous issue is that it's calling cvmx_fuse_read_byte()
every time without any synchronization. Currently it's possible to get
processes stuck looping forever in kernel simply by launching multiple
readers of /proc/cpuinfo:

	(while true; do cat /proc/cpuinfo > /dev/null; done) &
	(while true; do cat /proc/cpuinfo > /dev/null; done) &
	...

Fix by initializing the system type string only once during the early
boot.

Signed-off-by: Aaro Koskinen <[email protected]>
Reviewed-by: Markos Chandras <[email protected]>
Patchwork: http://patchwork.linux-mips.org/patch/7437/
Signed-off-by: James Hogan <[email protected]>
[lizf: Backport to 3.x: adjust context]
Signed-off-by: Zefan Li <[email protected]>
    @lizf-os
    Aaro Koskinen authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    33df36f View commit details
    Browse the repository at this point in the history

  8. kvm: iommu: fix the third parameter of kvm_iommu_put_pages (CVE-2014-… 

    …3601)

commit 350b8bd upstream.

The third parameter of kvm_iommu_put_pages is wrong,
It should be 'gfn - slot->base_gfn'.

By making gfn very large, malicious guest or userspace can cause kvm to
go to this error path, and subsequently to pass a huge value as size.
Alternatively if gfn is small, then pages would be pinned but never
unpinned, causing host memory leak and local DOS.

Passing a reasonable but large value could be the most dangerous case,
because it would unpin a page that should have stayed pinned, and thus
allow the device to DMA into arbitrary memory.  However, this cannot
happen because of the condition that can trigger the error:

- out of memory (where you can't allocate even a single page)
  should not be possible for the attacker to trigger

- when exceeding the iommu's address space, guest pages after gfn
  will also exceed the iommu's address space, and inside
  kvm_iommu_put_pages() the iommu_iova_to_phys() will fail.  The
  page thus would not be unpinned at all.

Reported-by: Jack Morgenstein <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @mstsirkin @lizf-os
    mstsirkin authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    f0634a3 View commit details
    Browse the repository at this point in the history

  9. pata_scc: propagate return value of scc_wait_after_reset 

    commit 4dc7c76 upstream.

scc_bus_softreset not necessarily should return zero.
Propagate the error code.

Signed-off-by: Arjun Sreedharan <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @arjun024 @lizf-os
    arjun024 authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    db83744 View commit details
    Browse the repository at this point in the history

  10. iommu/amd: Fix cleanup_domain for mass device removal 

    commit 9b29d3c upstream.

When multiple devices are detached in __detach_device, they
are also removed from the domains dev_list. This makes it
unsafe to use list_for_each_entry_safe, as the next pointer
might also not be in the list anymore after __detach_device
returns. So just repeatedly remove the first element of the
list until it is empty.

Tested-by: Marti Raudsepp <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @joergroedel @lizf-os
    joergroedel authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    77e5657 View commit details
    Browse the repository at this point in the history

  11. md/raid6: avoid data corruption during recovery of double-degraded RAID6 

    commit 9c4bdf6 upstream.

During recovery of a double-degraded RAID6 it is possible for
some blocks not to be recovered properly, leading to corruption.

If a write happens to one block in a stripe that would be written to a
missing device, and at the same time that stripe is recovering data
to the other missing device, then that recovered data may not be written.

This patch skips, in the double-degraded case, an optimisation that is
only safe for single-degraded arrays.

Bug was introduced in 2.6.32 and fix is suitable for any kernel since
then.  In an older kernel with separate handle_stripe5() and
handle_stripe6() functions the patch must change handle_stripe6().

Fixes: 6c0069c
Cc: Yuri Tikhonov <[email protected]>
Cc: Dan Williams <[email protected]>
Reported-by: "Manibalan P" <[email protected]>
Tested-by: "Manibalan P" <[email protected]>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1090423
Signed-off-by: NeilBrown <[email protected]>
Acked-by: Dan Williams <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @neilbrown @lizf-os
    neilbrown authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    a0e5b9d View commit details
    Browse the repository at this point in the history

  12. CIFS: Fix wrong directory attributes after rename 

    commit b46799a upstream.

When we requests rename we also need to update attributes
of both source and target parent directories. Not doing it
causes generic/309 xfstest to fail on SMB2 mounts. Fix this
by marking these directories for force revalidating.

Signed-off-by: Pavel Shilovsky <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @piastry @lizf-os
    piastry authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    d06e4b0 View commit details
    Browse the repository at this point in the history

  13. ALSA: hda/realtek - Avoid setting wrong COEF on ALC269 & co 

    commit f3ee07d upstream.

ALC269 & co have many vendor-specific setups with COEF verbs.
However, some verbs seem specific to some codec versions and they
result in the codec stalling.  Typically, such a case can be avoided
by checking the return value from reading a COEF.  If the return value
is -1, it implies that the COEF is invalid, thus it shouldn't be
written.

This patch adds the invalid COEF checks in appropriate places
accessing ALC269 and its variants.  The patch actually fixes the
resume problem on Acer AO725 laptop.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52181
Tested-by: Francesco Muzio <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @tiwai @lizf-os
    tiwai authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    483320c View commit details
    Browse the repository at this point in the history

  14. xtensa: replace IOCTL code definitions with constants 

    commit f61bf8e upstream.

This fixes userspace code that builds on other architectures but fails
on xtensa due to references to structures that other architectures don't
refer to. E.g. this fixes the following issue with python-2.7.8:

  python-2.7.8/Modules/termios.c:861:25: error: invalid application
     of 'sizeof' to incomplete type 'struct serial_multiport_struct'
     {"TIOCSERGETMULTI", TIOCSERGETMULTI},
  python-2.7.8/Modules/termios.c:870:25: error: invalid application
     of 'sizeof' to incomplete type 'struct serial_multiport_struct'
     {"TIOCSERSETMULTI", TIOCSERSETMULTI},
  python-2.7.8/Modules/termios.c:900:24: error: invalid application
     of 'sizeof' to incomplete type 'struct tty_struct'
     {"TIOCTTYGSTRUCT", TIOCTTYGSTRUCT},

Signed-off-by: Max Filippov <[email protected]>
[lizf: Backported to 3.4: adjust filename]
Signed-off-by: Zefan Li <[email protected]>
    @jcmvbkbc @lizf-os
    jcmvbkbc authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    2297927 View commit details
    Browse the repository at this point in the history

  15. xtensa: fix address checks in dma_{alloc,free}_coherent 

    commit 1ca4946 upstream.

Virtual address is translated to the XCHAL_KSEG_CACHED region in the
dma_free_coherent, but is checked to be in the 0...XCHAL_KSEG_SIZE
range.

Change check for end of the range from 'addr >= X' to 'addr > X - 1' to
handle the case of X == 0.

Replace 'if (C) BUG();' construct with 'BUG_ON(C);'.

Signed-off-by: Alan Douglas <[email protected]>
Signed-off-by: Max Filippov <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @lizf-os
    Alan Douglas authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    fb2ae73 View commit details
    Browse the repository at this point in the history

  16. xtensa: fix TLBTEMP_BASE_2 region handling in fast_second_level_miss 

    commit 7128039 upstream.

Current definition of TLBTEMP_BASE_2 is always 32K above the
TLBTEMP_BASE_1, whereas fast_second_level_miss handler for the TLBTEMP
region analyzes virtual address bit (PAGE_SHIFT + DCACHE_ALIAS_ORDER)
to determine TLBTEMP region where the fault happened. The size of the
TLBTEMP region is also checked incorrectly: not 64K, but twice data
cache way size (whicht may as well be less than the instruction cache
way size).

Fix TLBTEMP_BASE_2 to be TLBTEMP_BASE_1 + data cache way size.
Provide TLBTEMP_SIZE that is a greater of doubled data cache way size or
the instruction cache way size, and use it to determine if the second
level TLB miss occured in the TLBTEMP region.

Practical occurence of page faults in the TLBTEMP area is extremely
rare, this code can be tested by deletion of all w[di]tlb instructions
in the tlbtemp_mapping region.

Signed-off-by: Max Filippov <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @jcmvbkbc @lizf-os
    jcmvbkbc authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    bcf20fd View commit details
    Browse the repository at this point in the history

  17. xtensa: fix a6 and a7 handling in fast_syscall_xtensa 

    commit d1b6ba8 upstream.

Remove restoring a6 on some return paths and instead modify and restore
it in a single place, using symbolic name.
Correctly restore a7 from PT_AREG7 in case of illegal a6 value.

Signed-off-by: Max Filippov <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @jcmvbkbc @lizf-os
    jcmvbkbc authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    f40751b View commit details
    Browse the repository at this point in the history

  18. staging: et131x: Fix errors caused by phydev->addr accesses before in… 

    …itialisation

commit ec0a38b upstream.

Fix two reported bugs, caused by et131x_adapter->phydev->addr being accessed
before it is initialised, by:

- letting et131x_mii_write() take a phydev address, instead of using the one
  stored in adapter by default. This is so et131x_mdio_write() can use it's own
  addr value.
- removing implementation of et131x_mdio_reset(), as it's not needed.
- moving a call to et131x_disable_phy_coma() in et131x_pci_setup(), which uses
  phydev->addr, until after the mdiobus has been registered.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=80751
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77121
Signed-off-by: Mark Einon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
[lizf: Backported to 3.4:
- adjust context
- update more update more et131x_mii_write() calls in 
  et1310_phy_access_mii_bit() and et131x_xcvr_init()]
Signed-off-by: Zefan Li <[email protected]>
    @einonm @lizf-os
    einonm authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    c2aa9b7 View commit details
    Browse the repository at this point in the history

  19. USB: option: add VIA Telecom CDS7 chipset device id 

    commit d773027 upstream.

This VIA Telecom baseband processor is used is used by by u-blox in both the
FW2770 and FW2760 products and may be used in others as well.

This patch has been tested on both of these modem versions.

Signed-off-by: Brennan Ashton <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @btashton @lizf-os
    btashton authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    78aea3a View commit details
    Browse the repository at this point in the history

  20. USB: ftdi_sio: add Basic Micro ATOM Nano USB2Serial PID 

    commit 6552cc7 upstream.

Add device id for Basic Micro ATOM Nano USB2Serial adapters.

Reported-by: Nicolas Alt <[email protected]>
Tested-by: Nicolas Alt <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @jhovold @lizf-os
    jhovold authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    262548e View commit details
    Browse the repository at this point in the history

  21. USB: serial: pl2303: add device id for ztek device 

    commit 91fcb1c upstream.

This adds a new device id to the pl2303 driver for the ZTEK device.

Reported-by: Mike Chu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @gregkh @lizf-os
    gregkh authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    68e9929 View commit details
    Browse the repository at this point in the history

  22. USB: ftdi_sio: Added PID for new ekey device 

    commit 646907f upstream.

Added support to the ftdi_sio driver for ekey Converter USB which
uses an FT232BM chip.

Signed-off-by: Jaša Bartelj <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <[email protected]>
    @bartmanus @lizf-os
    bartmanus authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    d232e2c View commit details
    Browse the repository at this point in the history

  23. xhci: Treat not finding the event_seg on COMP_STOP the same as COMP_S… 

    …TOP_INVAL

commit 9a54886 upstream.

When using a Renesas uPD720231 chipset usb-3 uas to sata bridge with a 120G
Crucial M500 ssd, model string: Crucial_ CT120M500SSD1, together with a
the integrated Intel xhci controller on a Haswell laptop:

00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04)

The following error gets logged to dmesg:

xhci error: Transfer event TRB DMA ptr not part of current TD

Treating COMP_STOP the same as COMP_STOP_INVAL when no event_seg gets found
fixes this.

Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @jwrdegoede @lizf-os
    jwrdegoede authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    42494f0 View commit details
    Browse the repository at this point in the history

  24. usb: xhci: amd chipset also needs short TX quirk 

    commit 2597fe9 upstream.

AMD xHC also needs short tx quirk after tested on most of chipset
generations. That's because there is the same incorrect behavior like
Fresco Logic host. Please see below message with on USB webcam
attached on xHC host:

[  139.262944] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.266934] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.270913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.274937] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.278914] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.282936] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.286915] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.290938] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.294913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
[  139.298917] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?

Reported-by: Arindam Nath <[email protected]>
Tested-by: Shriraj-Rai P <[email protected]>
Signed-off-by: Huang Rui <[email protected]>
Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <[email protected]>
    @huangrui @lizf-os
    huangrui authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    1d37c3e View commit details
    Browse the repository at this point in the history

  25. USB: whiteheat: Added bounds checking for bulk command response 

    commit 6817ae2 upstream.

This patch fixes a potential security issue in the whiteheat USB driver
which might allow a local attacker to cause kernel memory corrpution. This
is due to an unchecked memcpy into a fixed size buffer (of 64 bytes). On
EHCI and XHCI busses it's possible to craft responses greater than 64
bytes leading a buffer overflow.

Signed-off-by: James Forshaw <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <[email protected]>
    @lizf-os
    James Forshaw authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    2f2c704 View commit details
    Browse the repository at this point in the history

  26. HID: logitech-dj: prevent false errors to be shown 

    commit 5abfe85 upstream.

Commit "HID: logitech: perform bounds checking on device_id early
enough" unfortunately leaks some errors to dmesg which are not real
ones:
- if the report is not a DJ one, then there is not point in checking
  the device_id
- the receiver (index 0) can also receive some notifications which
  can be safely ignored given the current implementation

Move out the test regarding the report_id and also discards
printing errors when the receiver got notified.

Fixes: ad3e14d

Reported-and-tested-by: Markus Trippelsdorf <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @bentiss @lizf-os
    bentiss authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    86d165e View commit details
    Browse the repository at this point in the history

  27. USB: sisusb: add device id for Magic Control USB video 

    commit 5b6b80a upstream.

I have a j5 create (JUA210) USB 2 video device and adding it device id
to SIS USB video gets it to work.

Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @shemminger @lizf-os
    shemminger authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    818ee41 View commit details
    Browse the repository at this point in the history

  28. NFSv4: Fix problems with close in the presence of a delegation 

    commit aee7af3 upstream.

In the presence of delegations, we can no longer assume that the
state->n_rdwr, state->n_rdonly, state->n_wronly reflect the open
stateid share mode, and so we need to calculate the initial value
for calldata->arg.fmode using the state->flags.

Reported-by: James Drews <[email protected]>
Fixes: 88069f7 (NFSv41: Fix a potential state leakage when...)
Signed-off-by: Trond Myklebust <[email protected]>
[lizf: Backport to 3.4: adjust context]
Signed-off-by: Zefan Li <[email protected]>
    @trondmypd @lizf-os
    trondmypd authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    0bfb000 View commit details
    Browse the repository at this point in the history

  29. HID: magicmouse: sanity check report size in raw_event() callback 

    commit c54def7 upstream.

The report passed to us from transport driver could potentially be
arbitrarily large, therefore we better sanity-check it so that
magicmouse_emit_touch() gets only valid values of raw_id.

Reported-by: Steven Vittitoe <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @lizf-os
    Jiri Kosina authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    e115f02 View commit details
    Browse the repository at this point in the history

  30. HID: picolcd: sanity check report size in raw_event() callback 

    commit 844817e upstream.

The report passed to us from transport driver could potentially be
arbitrarily large, therefore we better sanity-check it so that raw_data
that we hold in picolcd_pending structure are always kept within proper
bounds.

Reported-by: Steven Vittitoe <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
[lizf: Backported to 3.4: adjust filename]
Signed-off-by: Zefan Li <[email protected]>
    @lizf-os
    Jiri Kosina authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    e78c127 View commit details
    Browse the repository at this point in the history

  31. ARM: 8128/1: abort: don't clear the exclusive monitors 

    commit 8586831 upstream.

The ARMv6 and ARMv7 early abort handlers clear the exclusive monitors
upon entry to the kernel, but this is redundant:

  - We clear the monitors on every exception return since commit
    200b812 ("Clear the exclusive monitor when returning from an
    exception"), so this is not necessary to ensure the monitors are
    cleared before returning from a fault handler.

  - Any dummy STREX will target a temporary scratch area in memory, and
    may succeed or fail without corrupting useful data. Its status value
    will not be used.

  - Any other STREX in the kernel must be preceded by an LDREX, which
    will initialise the monitors consistently and will not depend on the
    earlier state of the monitors.

Therefore we have no reason to care about the initial state of the
exclusive monitors when a data abort is taken, and clearing the monitors
prior to exception return (as we already do) is sufficient.

This patch removes the redundant clearing of the exclusive monitors from
the early abort handlers.

Signed-off-by: Mark Rutland <[email protected]>
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @lizf-os
    Mark Rutland authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    5624bb3 View commit details
    Browse the repository at this point in the history

  32. ARM: 8129/1: errata: work around Cortex-A15 erratum 830321 using dumm… 

    …y strex

commit 2c32c65 upstream.

On revisions of Cortex-A15 prior to r3p3, a CLREX instruction at PL1 may
falsely trigger a watchpoint exception, leading to potential data aborts
during exception return and/or livelock.

This patch resolves the issue in the following ways:

  - Replacing our uses of CLREX with a dummy STREX sequence instead (as
    we did for v6 CPUs).

  - Removing the clrex code from v7_exit_coherency_flush and derivatives,
    since this only exists as a minor performance improvement when
    non-cached exclusives are in use (Linux doesn't use these).

Benchmarking on a variety of ARM cores revealed no measurable
performance difference with this change applied, so the change is
performed unconditionally and no new Kconfig entry is added.

Signed-off-by: Mark Rutland <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Russell King <[email protected]>
[lizf: Backported to 3.4:
 - Drop changes to arch/arm/include/asm/cacheflush.h and
   arch/arm/mach-exynos/mcpm-exynos.c]
Signed-off-by: Zefan Li <[email protected]>
    @lizf-os
    Mark Rutland authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    2f3e285 View commit details
    Browse the repository at this point in the history

  33. USB: serial: fix potential stack buffer overflow 

    commit d979e9f upstream.

Make sure to verify the maximum number of endpoints per type to avoid
writing beyond the end of a stack-allocated array.

The current usb-serial implementation is limited to eight ports per
interface but failed to verify that the number of endpoints of a certain
type reported by a device did not exceed this limit.

Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <[email protected]>
    @jhovold @lizf-os
    jhovold authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    62148f7 View commit details
    Browse the repository at this point in the history

  34. USB: serial: fix potential heap buffer overflow 

    commit 5654699 upstream.

Make sure to verify the number of ports requested by subdriver to avoid
writing beyond the end of fixed-size array in interface data.

The current usb-serial implementation is limited to eight ports per
interface but failed to verify that the number of ports requested by a
subdriver (which could have been determined from device descriptors) did
not exceed this limit.

Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
[lizf: Backported to 3.4: s/ddev/\&interface->dev/]
Signed-off-by: Zefan Li <[email protected]>
    @jhovold @lizf-os
    jhovold authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    c804743 View commit details
    Browse the repository at this point in the history

  35. MIPS: perf: Fix build error caused by unused counters_per_cpu_to_total() 

    commit 6c37c95 upstream.

cc1: warnings being treated as errors
arch/mips/kernel/perf_event_mipsxx.c:166: error: 'counters_per_cpu_to_total' defined but not used
make[2]: *** [arch/mips/kernel/perf_event_mipsxx.o] Error 1
make[2]: *** Waiting for unfinished jobs....

It was first introduced by 8209156 [MIPS:
perf: Add support for 64-bit perf counters.] in 3.2.

Signed-off-by: Florian Fainelli <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/3357/
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @ffainelli @lizf-os
    ffainelli authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    9a8fa93 View commit details
    Browse the repository at this point in the history

  36. MIPS: Fix accessing to per-cpu data when flushing the cache 

    commit ff52205 upstream.

This fixes the following issue

BUG: using smp_processor_id() in preemptible [00000000] code: kjournald/1761
caller is blast_dcache32+0x30/0x254
Call Trace:
[<8047f02c>] dump_stack+0x8/0x34
[<802e7e40>] debug_smp_processor_id+0xe0/0xf0
[<80114d94>] blast_dcache32+0x30/0x254
[<80118484>] r4k_dma_cache_wback_inv+0x200/0x288
[<80110ff0>] mips_dma_map_sg+0x108/0x180
[<80355098>] ide_dma_prepare+0xf0/0x1b8
[<8034eaa4>] do_rw_taskfile+0x1e8/0x33c
[<8035951c>] ide_do_rw_disk+0x298/0x3e4
[<8034a3c4>] do_ide_request+0x2e0/0x704
[<802bb0dc>] __blk_run_queue+0x44/0x64
[<802be000>] queue_unplugged.isra.36+0x1c/0x54
[<802beb94>] blk_flush_plug_list+0x18c/0x24c
[<802bec6c>] blk_finish_plug+0x18/0x48
[<8026554c>] journal_commit_transaction+0x3b8/0x151c
[<80269648>] kjournald+0xec/0x238
[<8014ac00>] kthread+0xb8/0xc0
[<8010268c>] ret_from_kernel_thread+0x14/0x1c

Caches in most systems are identical - but not always, so we can't avoid
the use of smp_call_function() by just looking at the boot CPU's data,
have to fiddle with preemption instead.

Signed-off-by: Ralf Baechle <[email protected]>
Cc: Markos Chandras <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/5835
Signed-off-by: Zefan Li <[email protected]>
    @ralfbaechle @lizf-os
    ralfbaechle authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    c1bc007 View commit details
    Browse the repository at this point in the history

  37. openrisc: add missing header inclusion 

    commit 160d837 upstream.

Prevents build issue with updated toolchain

Reported-by: Jack Thomasson <[email protected]>
Tested-by: Christian Svensson <[email protected]>
Signed-off-by: Stefan Kristiansson <[email protected]>
Signed-off-by: Jonas Bonn <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @skristiansson @lizf-os
    skristiansson authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    ab22539 View commit details
    Browse the repository at this point in the history

  38. slab/mempolicy: always use local policy from interrupt context 

    commit e7b691b upstream.

slab_node() could access current->mempolicy from interrupt context.
However there's a race condition during exit where the mempolicy
is first freed and then the pointer zeroed.

Using this from interrupts seems bogus anyways. The interrupt
will interrupt a random process and therefore get a random
mempolicy. Many times, this will be idle's, which noone can change.

Just disable this here and always use local for slab
from interrupts. I also cleaned up the callers of slab_node a bit
which always passed the same argument.

I believe the original mempolicy code did that in fact,
so it's likely a regression.

v2: send version with correct logic
v3: simplify. fix typo.
Reported-by: Arun Sharma <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andi Kleen <[email protected]>
[[email protected]: Rework control flow based on feedback from
[email protected], fix logic, and cleanup current task_struct reference]
Acked-by: David Rientjes <[email protected]>
Acked-by: Christoph Lameter <[email protected]>
Acked-by: KOSAKI Motohiro <[email protected]>
Signed-off-by: David Mackey <[email protected]>
Signed-off-by: Pekka Enberg <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @lizf-os
    Andi Kleen authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    69db2d4 View commit details
    Browse the repository at this point in the history

  39. 8250_pci: fix warnings in backport of Broadcom TruManage support 

    commit 7400ce7 (v3.4.92-76-g7400ce7ee959)
was a backport of commit ebebd49 upstream
("8250/16?50: Add support for Broadcom TruManage redirected serial port")

However, in the context of 3.4.x kernels, the pci setup code was
expecting a struct uart_port and not a struct uart_8250_port, leading to
the following concerning warnings:

drivers/tty/serial/8250/8250_pci.c: In function ‘pci_brcm_trumanage_setup’:
drivers/tty/serial/8250/8250_pci.c:1086:2: warning: passing argument 3 of ‘pci_default_setup’ from incompatible pointer type [enabled by default]
  int ret = pci_default_setup(priv, board, port, idx);
  ^
drivers/tty/serial/8250/8250_pci.c:1036:1: note: expected ‘struct uart_port *’ but argument is of type ‘struct uart_8250_port *’
 pci_default_setup(struct serial_private *priv,
 ^
drivers/tty/serial/8250/8250_pci.c: At top level:
drivers/tty/serial/8250/8250_pci.c:1746:3: warning: initialization from incompatible pointer type [enabled by default]
   .setup  = pci_brcm_trumanage_setup,
   ^
drivers/tty/serial/8250/8250_pci.c:1746:3: warning: (near initialization for ‘pci_serial_quirks[56].setup’) [enabled by default]

I'd also expect the initialization to not function correctly, and
perhaps dereference random garbage due to this.  Since the uart_port
is a field within the uart_8250_port, the adaptation to fix these
warnings is a straightforward removal of a layer of indirection.

Cc: Stephen Hurd <[email protected]>
Cc: Michael Chan <[email protected]>
Cc: Ben Hutchings <[email protected]>
Cc: Rui Xiang <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @lizf-os
    Paul Gortmaker authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    82a938a View commit details
    Browse the repository at this point in the history

  40. unicore32: select generic atomic64_t support 

    commit 82e54a6 upstream.

It's required for the core fs/namespace.c and many other basic features.

Signed-off-by: Guan Xuetao <[email protected]>
Signed-off-by: Fengguang Wu <[email protected]>
Cc: "Eric W. Biederman" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @lizf-os
    Fengguang Wu authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    62cdcce View commit details
    Browse the repository at this point in the history

  41. UniCore32-bugfix: Remove definitions in asm/bug.h to solve difference… 

    … between native and cross compiler

commit 10e1e99 upstream.

For kernel/bound.c being compiled by native compiler, it will generate following errors in gcc 4.4.3:
  CC      kernel/bounds.s
In file included from include/linux/bug.h:4,
                 from include/linux/page-flags.h:9,
                 from kernel/bounds.c:9:
arch/unicore32/include/asm/bug.h:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
arch/unicore32/include/asm/bug.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'

So, we moved definitions in asm/bug.h to arch/unicore32/kernel/setup.h to solve the problem.

Signed-off-by: Guan Xuetao <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @gxt @lizf-os
    gxt authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    4e36063 View commit details
    Browse the repository at this point in the history

  42. UniCore32-bugfix: fix mismatch return value of __xchg_bad_pointer 

    commit 195d457 upstream.

When disintegrate system.h, I left an error in asm/cmpxchg.h, which
will result in following error:

arch/unicore32/include/asm/cmpxchg.h: In function '__xchg':
arch/unicore32/include/asm/cmpxchg.h:38: error: void value not ignored as it ought to be

Signed-off-by: Guan Xuetao <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @gxt @lizf-os
    gxt authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    92a6e26 View commit details
    Browse the repository at this point in the history

  43. alpha: Fix fall-out from disintegrating asm/system.h 

    commit d1b5153 upstream.

Commit ec22120 ("Disintegrate asm/system.h for Alpha") removed
asm/system.h however arch/alpha/oprofile/common.c requires definitions
that were shifted from asm/system.h to asm/special_insns.h.  Include
that.

Signed-off-by: Michael Cree <[email protected]>
Acked-by: Matt Turner <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @lizf-os
    Michael Cree authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    f79bb94 View commit details
    Browse the repository at this point in the history

  44. ext2: Fix fs corruption in ext2_get_xip_mem() 

    commit 7ba3ec5 upstream.

Commit 8e3dffc "Ext2: mark inode dirty after the function
dquot_free_block_nodirty is called" unveiled a bug in __ext2_get_block()
called from ext2_get_xip_mem(). That function called ext2_get_block()
mistakenly asking it to map 0 blocks while 1 was intended. Before the
above mentioned commit things worked out fine by luck but after that commit
we started returning that we allocated 0 blocks while we in fact
allocated 1 block and thus allocation was looping until all blocks in
the filesystem were exhausted.

Fix the problem by properly asking for one block and also add assertion
in ext2_get_blocks() to catch similar problems.

Reported-and-tested-by: Andiry Xu <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Cc: Wang Nan <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @jankara @lizf-os
    jankara authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    3a8f613 View commit details
    Browse the repository at this point in the history

  45. alpha: add io{read,write}{16,32}be functions 

    commit 25534eb upstream.

These functions are used in some PCI drivers with big-endian
MMIO space.

Admittedly it is almost certain that no one this side of the
Moon would use such a card in an Alpha but it does get us
closer to being able to build allyesconfig or allmodconfig,
and it enables the Debian default generic config to build.

Tested-by: Raúl Porcel <[email protected]>
Signed-off-by: Michael Cree <[email protected]>
Signed-off-by: Matt Turner <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Zefan Li <[email protected]>
    @lizf-os
    Michael Cree authored and lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    618dea4 View commit details
    Browse the repository at this point in the history

  46. Linux 3.4.104

    @lizf-os
    lizf-os committed Sep 25, 2014
    Configuration menu
    Copy the full SHA
    bb4a05a View commit details
    Browse the repository at this point in the history

Commits on Oct 2, 2014

  1. HID: input: generic hidinput_input_event handler 

    The hidinput_input_event() callback converts input events written from
userspace into HID reports and sends them to the device. We currently
implement this in every HID transport driver, even though most of them do
the same.

This provides a generic hidinput_input_event() implementation which is
mostly copied from usbhid. It uses a delayed worker to allow multiple LED
events to be collected into a single output event.
We use the custom ->request() transport driver callback to allow drivers
to adjust the outgoing report and handle the request asynchronously. If no
custom ->request() callback is available, we fall back to the generic raw
output report handler (which is synchronous).

Drivers can still provide custom hidinput_input_event() handlers (see
logitech-dj) if the generic implementation doesn't fit their needs.

Conflicts:
	drivers/hid/hid-input.c

Signed-off-by: David Herrmann <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Michael Wright <[email protected]>
Change-Id: I89ccc3f675b3e8a7bbd812a6ebe12588d737cfd6
    David Herrmann authored and Michael Wright committed Oct 2, 2014
    Configuration menu
    Copy the full SHA
    0b20c61 View commit details
    Browse the repository at this point in the history

Commits on Oct 14, 2014

  1. sun4i-keyboard: 250Hz LRADC sampling 

    This is required to have fast enough key presses with sun4i-keyboard
(actually used on sun4i, sun5i and sun7i) on CWM recovery, an Android
initramfs that allows easy flashing of the devices. With any lower
sampling rate, close key presses are not distinguished and reported
as one long press.

Signed-off-by: Paul Kocialkowski <[email protected]>
Acked-by: Siarhei Siamashka <[email protected]>
    @paulkocialkowski @ssvb
    paulkocialkowski authored and ssvb committed Oct 14, 2014
    Configuration menu
    Copy the full SHA
    c4901d9 View commit details
    Browse the repository at this point in the history

  2. sunxi: axp209: Protect dcdc3 voltage from modification 

    The dcdc3 voltage is expected to be set by the bootloader and the right
voltage depends on the DRAM settings (higher clock speed needs more
voltage). Allowing to use the 'dcdc3_vol' parameter from the FEX file
only introduces an unnecessary fragile dependency between the settings
in u-boot and the settings in FEX. So now we ignore this parameter in
FEX and keep the original dcdc3 voltage set by the bootloader.

The dmesg log now looks like this:

[    2.212941] axp20_ldo1: 1300 mV
[    2.221370] axp20_ldo2: 1800 <--> 3300 mV at 3000 mV
[    2.231662] axp20_ldo3: 700 <--> 3500 mV at 2800 mV
[    2.241747] axp20_ldo4: 1250 <--> 3300 mV at 2800 mV
[    2.251906] axp20_buck2: 700 <--> 2275 mV at 1400 mV
[    2.263430] somebody is trying to set dcdc3 range to (1300000, 1300000) uV
[    2.275327] but we keep dcdc3 = 1250000 uV from the bootloader
[    2.285406] axp20_buck3: 700 <--> 3500 mV at 1250 mV
[    2.295299] axp20_ldoio0: 1800 <--> 3300 mV at 2800 mV

Signed-off-by: Siarhei Siamashka <[email protected]>
Acked-by: Hans de Goede <[email protected]>
    @ssvb
    ssvb committed Oct 14, 2014
    Configuration menu
    Copy the full SHA
    5052b83 View commit details
    Browse the repository at this point in the history

  3. sunxi: Calculate PLL5P clock divisors for G2D, ACE and DEBE 

    When PLL5P is used as a parent clock for some of the peripherals,
the current code just selects some hardcoded divisors. This happens
to work, but only under assumption that the PLL5P clock speed is
somewhere between 360MHz and 480MHz (the typical DRAM clock speeds).

However with some tweaks for the DRAM parameters, it is possible to
clock DRAM up to 600MHz and more on some devices:

    http://lists.denx.de/pipermail/u-boot/2014-July/183981.html

And this introduces concerns about the hardcoded divisors in the
kernel, which may cause some peripherals to operate at abnormally
high clock speeds if the PLL5 clock speed is too fast (PLL5 is used
for clocking DRAM).

Moreover, it makes sense to avoid pre-dividing PLL5P and make it run
even faster than DRAM. This provides better granularity of the clock
speed selection for MBUS, G2D and everything else that is using PLL5P
as the parent clock. but running PLL5P faster means that the hardcoded
divisors become even more inappropriate.

This patch improves the clock divisors selection for G2D, ACE and
DEBE to insure that they can work correctly with any PLL5P clock
speed.

Signed-off-by: Siarhei Siamashka <[email protected]>
Acked-by: Hans de Goede <[email protected]>
    @ssvb
    ssvb committed Oct 14, 2014
    Configuration menu
    Copy the full SHA
    9a1cd03 View commit details
    Browse the repository at this point in the history

Commits on Oct 16, 2014

  1. power: Avoids bogus error messages for the suspend aborts. 

    Avoids printing bogus error message "tasks refusing to freeze", in cases
where pending wakeup source caused the suspend abort.

Signed-off-by: Ruchi Kandoi <[email protected]>
Change-Id: I913ad290f501b31cd536d039834c8d24c6f16928
    Ruchi Kandoi committed Oct 16, 2014
    Configuration menu
    Copy the full SHA
    e4ac161 View commit details
    Browse the repository at this point in the history

Commits on Oct 21, 2014

  1. cpufreq: Avoid using global variable total_cpus 

    The change is to compile on kernels where cpufreq stats are compiled as
a module (CONFIG_CPU_FREQ_STAT=m), because total_cpus is not exported for
module use.

Reported-By: Emilio López <[email protected]>
Signed-off-by: Ruchi Kandoi <[email protected]>
Change-Id: I4f3c74f0fac5e8d9449655b26bf3b407b0fe4290
    Ruchi Kandoi committed Oct 21, 2014
    Configuration menu
    Copy the full SHA
    e01bd6b View commit details
    Browse the repository at this point in the history

Commits on Oct 22, 2014

  1. Merge tag 'v3.4.104' into reference-3.4 

    This is the 3.4.104 stable release
    @amery
    amery committed Oct 22, 2014
    Configuration menu
    Copy the full SHA
    a4df1cd View commit details
    Browse the repository at this point in the history

  2. Merge remote-tracking branch 'origin/mirror/android-3.4' into referen… 

    …ce-3.4
    @amery
    amery committed Oct 22, 2014
    Configuration menu
    Copy the full SHA
    7cf03b1 View commit details
    Browse the repository at this point in the history

  3. Merge branch 'reference-3.4' into stage/sunxi-3.4

    @amery
    amery committed Oct 22, 2014
    Configuration menu
    Copy the full SHA
    a8f8ba9 View commit details
    Browse the repository at this point in the history

  4. Revert "driver-core: cpu: export total_cpus to fix CPU_FREQ_STAT=m bu… 

    …ild"

This reverts commit 83af551.
    @amery
    amery committed Oct 22, 2014
    Configuration menu
    Copy the full SHA
    fde9bcc View commit details
    Browse the repository at this point in the history

  5. SUNXI-GMAC driver logs every vlan frame... 

    Hello!

Don't know if i'm the only one who's using vlan with sunxi-gmac, but the
current driver is terribly spammy for the logs, it log every single vlan
frame at the INFO level. Personally i don't think that information is
useful at all but if you want to keep it enable, it should log it at the
DEBUG level instead. So i propose this little simple modification to the
source (or better, remove the whole line.):
    @amery
    Eddy Beaupre authored and amery committed Oct 22, 2014
    Configuration menu
    Copy the full SHA
    d5b9172 View commit details
    Browse the repository at this point in the history

Commits on Oct 23, 2014

  1. remove sunxi_nand from sun7i_defconfig 

    There's a known issue with sunxi_nand on A20 devices where
it will try to read a NAND chip and then make modifications
such that it becomes corrupted.  Until this situation is
resolved, the module should _not_ be included in the defconfig
for A20 devices.

Signed-off-by: Tim Tisdall <[email protected]>
Acked-by: Luc Verhaegen <[email protected]>
    @tisdall @amery
    tisdall authored and amery committed Oct 23, 2014
    Configuration menu
    Copy the full SHA
    2e1c5c5 View commit details
    Browse the repository at this point in the history

  2. Sunxi SATA driver should be built in-kernel in order to allow root fi… 

    …lesystems on sata per default.
    @rellla @amery
    rellla authored and amery committed Oct 23, 2014
    Configuration menu
    Copy the full SHA
    cc0e490 View commit details
    Browse the repository at this point in the history

  3. Cleanup sun7i_defconfig based on sun4i_defconfig.

    @rellla @amery
    rellla authored and amery committed Oct 23, 2014
    Configuration menu
    Copy the full SHA
    50ca729 View commit details
    Browse the repository at this point in the history

Commits on Nov 23, 2014

  1. arm:sunxi:defconfig: Re-Enable symmetric multiprocessing for sun7i 

    Signed-off-by: Andreas Baierl<[email protected]>
Acked-by: Siarhei Siamashka <[email protected]>
    @rellla @ssvb
    rellla authored and ssvb committed Nov 23, 2014
    Configuration menu
    Copy the full SHA
    1bffd2c View commit details
    Browse the repository at this point in the history

  2. arm:sunxi:defconfig: Enable CONFIG_FHANDLE required for systemd >= 209 

    Signed-off-by: Andreas Baierl<[email protected]>
Acked-by: Siarhei Siamashka <[email protected]>
    @rellla @ssvb
    rellla authored and ssvb committed Nov 23, 2014
    Configuration menu
    Copy the full SHA
    c9ec08b View commit details
    Browse the repository at this point in the history

Commits on Nov 24, 2014

  1. sunxi: axp152: Keep DRAM / Vddr at bootloader set value 

    Some fex files contain wrong values, causing stability issues.

Signed-off-by: Hans de Goede <[email protected]>
Acked-by: Siarhei Siamashka <[email protected]>
    @jwrdegoede @ssvb
    jwrdegoede authored and ssvb committed Nov 24, 2014
    Configuration menu
    Copy the full SHA
    c4c4664 View commit details
    Browse the repository at this point in the history

  2. sunxi: nand: Fix nand clk calculation 

    Before the u-boot dram cleanup u-boot would always set PLL5 factor m to
2 (reg value 1) and div p to 1, and get_cmu_clk in the nand code
would calculate the pll5p clk like this:

clk = 24 * factor_n * factor_k / div_p / factor_m;

aka:

clk = 24 * factor_n * factor_k / (div_p * factor_m);

This is wrong however, factor_m is not used to calculate pll5p, and div_p is
not a straight divider, but it divides by 2 ^ div_p. Since with the m == 2 and
p == 1 settings used before the dram cleanup, this happend to do the right
thing in the form of dividing by 2. But with the new dram code div_p is 0,
and then the old get_cmu_clk code fails with a divide by 0 error.

This commit fixes this, by changing the clk calculation to the correct form of:

clk = (24 * factor_n * factor_k) >> div_p;

Signed-off-by: Hans de Goede <[email protected]>
    @jwrdegoede @ssvb
    jwrdegoede authored and ssvb committed Nov 24, 2014
    Configuration menu
    Copy the full SHA
    ade08aa View commit details
    Browse the repository at this point in the history

Commits on Mar 15, 2015

  1. sunxi: axp152: Keep VDD-INT/VDD-DLL at bootloader set value 

    Some fex files contain wrong values, causing stability issues.

Signed-off-by: Hans de Goede <[email protected]>
Acked-by: Siarhei Siamashka <[email protected]>
    @jwrdegoede @ssvb
    jwrdegoede authored and ssvb committed Mar 15, 2015
    Configuration menu
    Copy the full SHA
    16b25a9 View commit details
    Browse the repository at this point in the history

  2. sun5i: clock: Do not change PLL6 frequency 

    Keep the PLL6 frequency as it is set by the bootloader, it may be used as
parent for the mbus, and if we change it we may be changing the mbus frequency,
all peripherals (*) using pll6 are already capable of dealing with it running at
a different frequency.

*) Only mmc uses pll6 as a parent by default

Signed-off-by: Hans de Goede <[email protected]>
Acked-by: Siarhei Siamashka <[email protected]>
    @jwrdegoede @ssvb
    jwrdegoede authored and ssvb committed Mar 15, 2015
    Configuration menu
    Copy the full SHA
    dea62f2 View commit details
    Browse the repository at this point in the history

  3. arm: Use top 4 bits of machine id for u-boot compatibility check 

    This implements ensuring compatibility between the mainline u-boot and the legacy
sunxi-3.4 kernels, proposed earlier at
    http://lists.denx.de/pipermail/u-boot/2014-October/191777.html

Signed-off-by: Siarhei Siamashka <[email protected]>
    @ssvb
    ssvb committed Mar 15, 2015
    Configuration menu
    Copy the full SHA
    d47d367 View commit details
    Browse the repository at this point in the history