| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Make sure v4l2_device_unregister_subdev() is called for both:
oif and sensor subdev and both media entities are freed on
driver removal.
Signed-off-by: Sylwester Nawrocki <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
index variable is used to check the validity of the data by
testing for negative values. Hence make it signed.
Signed-off-by: Sachin Kamat <[email protected]>
Signed-off-by: Sylwester Nawrocki <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
If fimc->drv_data is NULL, then fimc->drv_data->num_entities would
cause NULL pointer dereferencing. Hence remove it from print statement.
Signed-off-by: Sachin Kamat <[email protected]>
Signed-off-by: Sylwester Nawrocki <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Pull sparc fix from David Miller:
"Brown paper bag fix for sparc64"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
sparc64: Fix missing put_cpu_var() in tlb_batch_add_one() when not batching.
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull gpi fix from Linus Walleij:
"This is a last minute revert for the GPIO tree, as Mike Dunn noticed
breakage on some older PXA machines due to moving PXA GPIO initcalls
to the module_init initlevel"
* tag 'gpio-v3.9-lastminute' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
Revert "gpio: pxa: set initcall level to module init"
|
|
Reported-by: Meelis Roos <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This reverts commit 6c7e660a27da7494c670bfba21cfeba30457656c.
The commit causes breakage on several older PXA machines.
Reported-by: Mike Dunn <[email protected]>
Acked-by: Haojian Zhuang <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
We need to check the runtime sys_table for the EFI version the firmware
specifies instead of just checking for a NULL QueryVariableInfo. Older
implementations of EFI don't have QueryVariableInfo but the runtime is
a smaller structure, so the pointer to it may be pointing off into garbage.
This is apparently the case with several Apple firmwares that support EFI
1.10, and the current check causes them to no longer boot. Fix based on
a suggestion from Matthew Garrett.
Signed-off-by: Josh Boyer <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
|
|
Fix this:
arch/x86/boot/compressed/eboot.c: In function ‘setup_efi_vars’:
arch/x86/boot/compressed/eboot.c:269:2: warning: passing argument 1 of ‘efi_call_phys’ makes pointer from integer without a cast [enabled by default]
In file included from arch/x86/boot/compressed/eboot.c:12:0:
/w/kernel/linux/arch/x86/include/asm/efi.h:8:33: note: expected ‘void *’ but argument is of type ‘long unsigned int’
after cc5a080c5d40 ("efi: Pass boot services variable info to runtime
code").
Reported-by: Paul Bolle <[email protected]>
Cc: Matthew Garrett <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
|
|
This avoids:
Apr 12 23:52:16 homeserver kernel: imon:send_packet: task interrupted
Apr 12 23:52:16 homeserver kernel: ------------[ cut here ]------------
Apr 12 23:52:16 homeserver kernel: WARNING: at drivers/usb/core/urb.c:327 usb_submit_urb+0x353/0x370()
Apr 12 23:52:16 homeserver kernel: Hardware name: Unknow
Apr 12 23:52:16 homeserver kernel: URB f64b6f00 submitted while active
Apr 12 23:52:16 homeserver kernel: Modules linked in:
Apr 12 23:52:16 homeserver kernel: Pid: 3154, comm: LCDd Not tainted 3.8.6-htpc-00005-g9e6fc5e #26
Apr 12 23:52:16 homeserver kernel: Call Trace:
Apr 12 23:52:16 homeserver kernel: [<c012d778>] ? warn_slowpath_common+0x78/0xb0
Apr 12 23:52:16 homeserver kernel: [<c04136c3>] ? usb_submit_urb+0x353/0x370
Apr 12 23:52:16 homeserver kernel: [<c04136c3>] ? usb_submit_urb+0x353/0x370
Apr 12 23:52:16 homeserver kernel: [<c0447010>] ? imon_ir_change_protocol+0x150/0x150
Apr 12 23:52:16 homeserver kernel: [<c012d843>] ? warn_slowpath_fmt+0x33/0x40
Apr 12 23:52:16 homeserver kernel: [<c04136c3>] ? usb_submit_urb+0x353/0x370
Apr 12 23:52:16 homeserver kernel: [<c0446c67>] ? send_packet+0x97/0x270
Apr 12 23:52:16 homeserver kernel: [<c0446cfe>] ? send_packet+0x12e/0x270
Apr 12 23:52:16 homeserver kernel: [<c05c5743>] ? do_nanosleep+0xa3/0xd0
Apr 12 23:52:16 homeserver kernel: [<c044760e>] ? vfd_write+0xae/0x250
Apr 12 23:52:16 homeserver kernel: [<c0447560>] ? lcd_write+0x180/0x180
Apr 12 23:52:16 homeserver kernel: [<c01b2b19>] ? vfs_write+0x89/0x140
Apr 12 23:52:16 homeserver kernel: [<c01b2dda>] ? sys_write+0x4a/0x90
Apr 12 23:52:16 homeserver kernel: [<c05c7c45>] ? sysenter_do_call+0x12/0x26
Apr 12 23:52:16 homeserver kernel: ---[ end trace a0b6f0fcfd2f9a1d ]---
Apr 12 23:52:16 homeserver kernel: imon:send_packet: error submitting urb(-16)
Apr 12 23:52:16 homeserver kernel: imon:vfd_write: send packet #3 failed
Apr 12 23:52:16 homeserver kernel: imon:send_packet: error submitting urb(-16)
Apr 12 23:52:16 homeserver kernel: imon:vfd_write: send packet #0 failed
Signed-off-by: Kevin Baradon <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
This bug could be triggered if 1st interface configuration fails:
Apr 8 18:20:30 homeserver kernel: usb 5-1: new low-speed USB device number 2 using ohci_hcd
Apr 8 18:20:30 homeserver kernel: input: iMON Panel, Knob and Mouse(15c2:0036) as /devices/pci0000:00/0000:00:13.0/usb5/5-1/5-1:1.0/input/input2
Apr 8 18:20:30 homeserver kernel: Registered IR keymap rc-imon-pad
Apr 8 18:20:30 homeserver kernel: input: iMON Remote (15c2:0036) as /devices/pci0000:00/0000:00:13.0/usb5/5-1/5-1:1.0/rc/rc0/input3
Apr 8 18:20:30 homeserver kernel: rc0: iMON Remote (15c2:0036) as /devices/pci0000:00/0000:00:13.0/usb5/5-1/5-1:1.0/rc/rc0
Apr 8 18:20:30 homeserver kernel: imon:send_packet: packet tx failed (-32)
Apr 8 18:20:30 homeserver kernel: imon 5-1:1.0: remote input dev register failed
Apr 8 18:20:30 homeserver kernel: imon 5-1:1.0: imon_init_intf0: rc device setup failed
Apr 8 18:20:30 homeserver kernel: imon 5-1:1.0: unable to initialize intf0, err 0
Apr 8 18:20:30 homeserver kernel: imon:imon_probe: failed to initialize context!
Apr 8 18:20:30 homeserver kernel: imon 5-1:1.0: unable to register, err -19
Apr 8 18:20:30 homeserver kernel: BUG: unable to handle kernel NULL pointer dereference at 00000014
Apr 8 18:20:30 homeserver kernel: IP: [<c05c4e4c>] mutex_lock+0xc/0x30
Apr 8 18:20:30 homeserver kernel: *pde = 00000000
Apr 8 18:20:30 homeserver kernel: Oops: 0002 [#1] PREEMPT SMP
Apr 8 18:20:30 homeserver kernel: Modules linked in:
Apr 8 18:20:30 homeserver kernel: Pid: 367, comm: khubd Not tainted 3.8.3-htpc-00002-g79b1403 #23 Unknow Unknow/RS780-SB700
Apr 8 18:20:30 homeserver kernel: EIP: 0060:[<c05c4e4c>] EFLAGS: 00010296 CPU: 1
Apr 8 18:20:30 homeserver kernel: EIP is at mutex_lock+0xc/0x30
Apr 8 18:20:30 homeserver kernel: EAX: 00000014 EBX: 00000014 ECX: 00000000 EDX: f590e480
Apr 8 18:20:30 homeserver kernel: ESI: f5deac00 EDI: f590e480 EBP: f5f3ee00 ESP: f6577c28
Apr 8 18:20:30 homeserver kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Apr 8 18:20:30 homeserver kernel: CR0: 8005003b CR2: 00000014 CR3: 0081b000 CR4: 000007d0
Apr 8 18:20:30 homeserver kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Apr 8 18:20:30 homeserver kernel: DR6: ffff0ff0 DR7: 00000400
Apr 8 18:20:30 homeserver kernel: Process khubd (pid: 367, ti=f6576000 task=f649ea00 task.ti=f6576000)
Apr 8 18:20:30 homeserver kernel: Stack:
Apr 8 18:20:30 homeserver kernel: 00000000 f5deac00 c0448de4 f59714c0 f5deac64 c03b8ad2 f6577c90 00000004
Apr 8 18:20:30 homeserver kernel: f649ea00 c0205142 f6779820 a1ff7f08 f5deac00 00000001 f5f3ee1c 00000014
Apr 8 18:20:30 homeserver kernel: 00000004 00000202 15c20036 c07a03e8 fffee0ca f6795c00 f5f3ee1c f5deac00
Apr 8 18:20:30 homeserver kernel: Call Trace:
Apr 8 18:20:30 homeserver kernel: [<c0448de4>] ? imon_probe+0x494/0xde0
Apr 8 18:20:30 homeserver kernel: [<c03b8ad2>] ? rpm_resume+0xb2/0x4f0
Apr 8 18:20:30 homeserver kernel: [<c0205142>] ? sysfs_addrm_finish+0x12/0x90
Apr 8 18:20:30 homeserver kernel: [<c04170e9>] ? usb_probe_interface+0x169/0x240
Apr 8 18:20:30 homeserver kernel: [<c03b0ca0>] ? __driver_attach+0x80/0x80
Apr 8 18:20:30 homeserver kernel: [<c03b0ca0>] ? __driver_attach+0x80/0x80
Apr 8 18:20:30 homeserver kernel: [<c03b0a94>] ? driver_probe_device+0x54/0x1e0
Apr 8 18:20:30 homeserver kernel: [<c0416abe>] ? usb_device_match+0x4e/0x80
Apr 8 18:20:30 homeserver kernel: [<c03af314>] ? bus_for_each_drv+0x34/0x70
Apr 8 18:20:30 homeserver kernel: [<c03b0a0b>] ? device_attach+0x7b/0x90
Apr 8 18:20:30 homeserver kernel: [<c03b0ca0>] ? __driver_attach+0x80/0x80
Apr 8 18:20:30 homeserver kernel: [<c03b00ff>] ? bus_probe_device+0x5f/0x80
Apr 8 18:20:30 homeserver kernel: [<c03aeab7>] ? device_add+0x567/0x610
Apr 8 18:20:30 homeserver kernel: [<c041a7bc>] ? usb_create_ep_devs+0x7c/0xd0
Apr 8 18:20:30 homeserver kernel: [<c0413837>] ? create_intf_ep_devs+0x47/0x70
Apr 8 18:20:30 homeserver kernel: [<c04156c4>] ? usb_set_configuration+0x454/0x750
Apr 8 18:20:30 homeserver kernel: [<c03b0ca0>] ? __driver_attach+0x80/0x80
Apr 8 18:20:30 homeserver kernel: [<c041de8a>] ? generic_probe+0x2a/0x80
Apr 8 18:20:30 homeserver kernel: [<c03b0ca0>] ? __driver_attach+0x80/0x80
Apr 8 18:20:30 homeserver kernel: [<c0205aff>] ? sysfs_create_link+0xf/0x20
Apr 8 18:20:30 homeserver kernel: [<c04171db>] ? usb_probe_device+0x1b/0x40
Apr 8 18:20:30 homeserver kernel: [<c03b0a94>] ? driver_probe_device+0x54/0x1e0
Apr 8 18:20:30 homeserver kernel: [<c03af314>] ? bus_for_each_drv+0x34/0x70
Apr 8 18:20:30 homeserver kernel: [<c03b0a0b>] ? device_attach+0x7b/0x90
Apr 8 18:20:30 homeserver kernel: [<c03b0ca0>] ? __driver_attach+0x80/0x80
Apr 8 18:20:30 homeserver kernel: [<c03b00ff>] ? bus_probe_device+0x5f/0x80
Apr 8 18:20:30 homeserver kernel: [<c03aeab7>] ? device_add+0x567/0x610
Apr 8 18:20:30 homeserver kernel: [<c040e6df>] ? usb_new_device+0x12f/0x1e0
Apr 8 18:20:30 homeserver kernel: [<c040f4d8>] ? hub_thread+0x458/0x1230
Apr 8 18:20:30 homeserver kernel: [<c015554f>] ? dequeue_task_fair+0x9f/0xc0
Apr 8 18:20:30 homeserver kernel: [<c0131312>] ? release_task+0x1d2/0x330
Apr 8 18:20:30 homeserver kernel: [<c01477b0>] ? abort_exclusive_wait+0x90/0x90
Apr 8 18:20:30 homeserver kernel: [<c040f080>] ? usb_remote_wakeup+0x40/0x40
Apr 8 18:20:30 homeserver kernel: [<c0146ed2>] ? kthread+0x92/0xa0
Apr 8 18:20:30 homeserver kernel: [<c05c7877>] ? ret_from_kernel_thread+0x1b/0x28
Apr 8 18:20:30 homeserver kernel: [<c0146e40>] ? kthread_freezable_should_stop+0x50/0x50
Apr 8 18:20:30 homeserver kernel: Code: 89 04 24 89 f0 e8 05 ff ff ff 8b 5c 24 24 8b 74 24 28 8b 7c 24 2c 8b 6c 24 30 83 c4 34 c3 00 83 ec 08 89 1c 24 89 74 24 04 89 c3 <f0> ff 08 79 05 e8 ca 03 00 00 64 a1 70 d6 80 c0 8b 74 24 04 89
Apr 8 18:20:30 homeserver kernel: EIP: [<c05c4e4c>] mutex_lock+0xc/0x30 SS:ESP 0068:f6577c28
Apr 8 18:20:30 homeserver kernel: CR2: 0000000000000014
Apr 8 18:20:30 homeserver kernel: ---[ end trace df134132c967205c ]---
Signed-off-by: Kevin Baradon <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
send_packet() is used during initialization, before send_packet_delay
is set. So, move ictx->send_packet_delay to happen earlier.
[[email protected]: fold two patches into one to make git history clearer]
Signed-off-by: Kevin Baradon <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
The last part of the "u_ent.name" buffer isn't cleared so it still has
uninitialized stack memory.
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Pull MIPS fix from Ralf Baechle:
"Revert the change of the definition of PAGE_MASK which was prettier
but broke a few relativly rare platforms"
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
Revert "MIPS: page.h: Provide more readable definition for PAGE_MASK."
|
|
The intend of this patch is to improve the support of the dib7090 and
dib7790. The AGC1 min value is set to 32768 by default. The actual AGC1 min
and the external attenuation are controled depending on the received RF
level.
Signed-off-by: Olivier Grenie <[email protected]>
Signed-off-by: Patrick Boettcher <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
The intend of this patch is to remove the support for the dib7090E. The
DiB7090E-package has never left prototype state and never made it to
mass-prod-state.
Signed-off-by: Olivier Grenie <[email protected]>
Signed-off-by: Patrick Boettcher <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
The intend of this patch is to improve the support of the dib8096. The PLL
parameters are not automatically computed. The limit to set/unset external
diode for attenuation has been updated. The TFE8096P board is using the
new I2C API.
Signed-off-by: Olivier Grenie <[email protected]>
Signed-off-by: Patrick Boettcher <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
The intend of this patch is to improve the support of the dib0090 tuner.
The ramp tables have been updated. Also some minor enhancements has been
added (EFUSE and reset).
Signed-off-by: Olivier Grenie <[email protected]>
Signed-off-by: Patrick Boettcher <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
The intend of this patch is to improve the support of the dib7000p. It is
now possible to set the minimum value for the AGC1. Also, the driver takes
into account the frequency offset introduced in the tuned frequency.
Signed-off-by: Olivier Grenie <[email protected]>
Signed-off-by: Patrick Boettcher <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
The intend of this patch is to improve the support of the dib8000.
Signed-off-by: Olivier Grenie <[email protected]>
Signed-off-by: Patrick Boettcher <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
This reverts commit c17a6554782ad531f4713b33fd6339ba67ef6391.
Manuel Lauss writes:
lmo commit c17a6554 (MIPS: page.h: Provide more readable definition for
PAGE_MASK) apparently breaks ioremap of 36-bit addresses on my Alchemy
systems (PCI and PCMCIA) The reason is that in arch/mips/mm/ioremap.c
line 157 (phys_addr &= PAGE_MASK) bits 32-35 are cut off. Seems the
new PAGE_MASK is explicitly 32bit, or one could make it signed instead
of unsigned long.
|
|
Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Pull crypto fix from Herbert Xu:
"This fixes a kernel memory leak in the algif interface"
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: algif - suppress sending source address information in recvmsg
|
|
commit 61ff5d69 "em28xx: improve em2710/em2820 distinction" missed the
le16_to_cpu conversion of the USB vendor ID.
Signed-off-by: Frank Schäfer <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
The 6010 produces MPEG-4 part 2, while 6110 produces H.264.
Signed-off-by: Ismael Luceno <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Because they're signed, "is_video" and "is_audio" can be 0 and -1
instead of 0 and 1 as intended. It doesn't cause a bug, but it makes
Sparse complain:
drivers/staging/media/go7007/go7007-priv.h:94:31: error: dubious one-bit signed bitfield
drivers/staging/media/go7007/go7007-priv.h:95:31: error: dubious one-bit signed bitfield
Signed-off-by: Dan Carpenter <[email protected]>
Acked-by: Hans Verkuil <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Legacy PCI suspend-resume handlers are called with interrupts enabled.
But cx8800_suspend/cx8800_resume and
cx8802_suspend_common/cx8802_resume_common use spin_lock/spin_unlock
functions to acquire dev->slock, while the same lock is acquired in the
corresponding irq-handlers: cx8800_irq and cx8802_irq.
That means a deadlock is possible if an interrupt happens while suspend
or resume owns the lock. The patch replaces spin_lock/spin_unlock with
spin_lock_irqsave/spin_unlock_irqrestore.
Found by Linux Driver Verification project (linuxtesting.org).
[[email protected]: Fix CodingStyle]
Signed-off-by: Alexey Khoroshilov <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Signed-off-by: Ismael Luceno <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
Sparse complains that these are "dubious one-bit signed bitfields" and
the comment says it was intended to be 1 and 0 instead of -1 and 0.
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Michael Krufky <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fixes from Ingo Molnar:
"Misc fixes"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/x86: Fix offcore_rsp valid mask for SNB/IVB
perf: Treat attr.config as u64 in perf_swevent_init()
|
|
I'm going to do an -rc8, so I'm just going to do this rather than delay
it any further. They are arguably stable material anyway.
* vm_ioremap_memory-examples:
mtdchar: remove no-longer-used vma helpers
vm: convert snd_pcm_lib_mmap_iomem() to vm_iomap_memory() helper
vm: convert fb_mmap to vm_iomap_memory() helper
vm: convert mtdchar mmap to vm_iomap_memory() helper
vm: convert HPET mmap to vm_iomap_memory() helper
|
|
The following RCU splat indicates lack of RCU protection:
[ 953.267649] ===============================
[ 953.267652] [ INFO: suspicious RCU usage. ]
[ 953.267657] 3.9.0-0.rc6.git2.4.fc19.ppc64p7 #1 Not tainted
[ 953.267661] -------------------------------
[ 953.267664] include/linux/cgroup.h:534 suspicious rcu_dereference_check() usage!
[ 953.267669]
[ 953.267669] other info that might help us debug this:
[ 953.267669]
[ 953.267675]
[ 953.267675] rcu_scheduler_active = 1, debug_locks = 0
[ 953.267680] 1 lock held by glxgears/1289:
[ 953.267683] #0: (&sig->cred_guard_mutex){+.+.+.}, at: [<c00000000027f884>] .prepare_bprm_creds+0x34/0xa0
[ 953.267700]
[ 953.267700] stack backtrace:
[ 953.267704] Call Trace:
[ 953.267709] [c0000001f0d1b6e0] [c000000000016e30] .show_stack+0x130/0x200 (unreliable)
[ 953.267717] [c0000001f0d1b7b0] [c0000000001267f8] .lockdep_rcu_suspicious+0x138/0x180
[ 953.267724] [c0000001f0d1b840] [c0000000001d43a4] .perf_event_comm+0x4c4/0x690
[ 953.267731] [c0000001f0d1b950] [c00000000027f6e4] .set_task_comm+0x84/0x1f0
[ 953.267737] [c0000001f0d1b9f0] [c000000000280414] .setup_new_exec+0x94/0x220
[ 953.267744] [c0000001f0d1ba70] [c0000000002f665c] .load_elf_binary+0x58c/0x19b0
...
This commit therefore adds the required RCU read-side critical
section to perf_event_comm().
Reported-by: Adam Jackson <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Tested-by: Gustavo Luiz Duarte <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull kdump fixes from Peter Anvin:
"The kexec/kdump people have found several problems with the support
for loading over 4 GiB that was introduced in this merge cycle. This
is partly due to a number of design problems inherent in the way the
various pieces of kdump fit together (it is pretty horrifically manual
in many places.)
After a *lot* of iterations this is the patchset that was agreed upon,
but of course it is now very late in the cycle. However, because it
changes both the syntax and semantics of the crashkernel option, it
would be desirable to avoid a stable release with the broken
interfaces."
I'm not happy with the timing, since originally the plan was to release
the final 3.9 tomorrow. But apparently I'm doing an -rc8 instead...
* 'x86-kdump-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
kexec: use Crash kernel for Crash kernel low
x86, kdump: Change crashkernel_high/low= to crashkernel=,high/low
x86, kdump: Retore crashkernel= to allocate under 896M
x86, kdump: Set crashkernel_low automatically
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Peter Anvin:
"Three groups of fixes:
1. Make sure we don't execute the early microcode patching if family
< 6, since it would touch MSRs which don't exist on those
families, causing crashes.
2. The Xen partial emulation of HyperV can be dealt with more
gracefully than just disabling the driver.
3. More EFI variable space magic. In particular, variables hidden
from runtime code need to be taken into account too."
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, microcode: Verify the family before dispatching microcode patching
x86, hyperv: Handle Xen emulation of Hyper-V more gracefully
x86,efi: Implement efi_no_storage_paranoia parameter
efi: Export efi_query_variable_store() for efivars.ko
x86/Kconfig: Make EFI select UCS2_STRING
efi: Distinguish between "remaining space" and actually used space
efi: Pass boot services variable info to runtime code
Move utf16 functions to kernel core and rename
x86,efi: Check max_size only if it is non-zero.
x86, efivars: firmware bug workarounds should be in platform code
|
|
Pull ARM fixes from Russell King:
"A set of fixes from various people - Will Deacon gets a prize for
removing code this time around. The biggest fix in this lot is
sorting out the ARM740T mess. The rest are relatively small fixes."
* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
ARM: 7699/1: sched_clock: Add more notrace to prevent recursion
ARM: 7698/1: perf: fix group validation when using enable_on_exec
ARM: 7697/1: hw_breakpoint: do not use __cpuinitdata for dbg_cpu_pm_nb
ARM: 7696/1: Fix kexec by setting outer_cache.inv_all for Feroceon
ARM: 7694/1: ARM, TCM: initialize TCM in paging_init(), instead of setup_arch()
ARM: 7692/1: iop3xx: move IOP3XX_PERIPHERAL_VIRT_BASE
ARM: modules: don't export cpu_set_pte_ext when !MMU
ARM: mm: remove broken condition check for v4 flushing
ARM: mm: fix numerous hideous errors in proc-arm740.S
ARM: cache: remove ARMv3 support code
ARM: tlbflush: remove ARMv3 support
|
|
Pull sparc fixes from David Miller:
1) Fix race in sparc64 TLB shootdowns, we have to synchronize with the
sibling cpus completing if we are passing them a reference via
pointer to a data structure.
2) Fix cleaning of bitmaps in sparc32, from Akinobu Mita.
3) Fix various sparc header mistakes, some of which resulted in
userland build breakage. From Sam Ravnborg.
4) Kill ghost declarations and defines missed when several bits of code
got deleted recently.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
sparc64: Fix race in TLB batch processing.
sparc: use asm-generic version of types.h
bbc_i2c: fix section mismatch warning
sparc: use generic headers
sparc:cleanup unused code in smp_32.h
sparc/iommu: fix typo s/265KB/256KB/
sparc/srmmu: clear trailing edge of bitmap properly
sparc:remove unused declaration smp_boot_cpus()
|
|
Pull networking updates from David Miller:
1) ax88796 does 64-bit divides which causes link errors on ARM, fix
from Arnd Bergmann.
2) Once an improper offload setting is detected on an SKB we don't rate
limit the log message so we can very easily live lock. From Ben
Greear.
3) Openvswitch cannot report vport configuration changes reliably
because it didn't preallocate the netlink notification message
before changing state. From Jesse Gross.
4) The effective UID/GID SCM credentials fix, from Linus.
5) When a user explicitly asks for wireless authentication, cfg80211
isn't told about the AP detachment leaving inconsistent state. Fix
from Johannes Berg.
6) Fix self-MAC checks in batman-adv on multi-mesh nodes, from Antonio
Quartulli.
7) Revert build_skb() change sin IGB driver, can result in memory
corruption. From Alexander Duyck.
8) Fix setting VLANs on virtual functions in IXGBE, from Greg Rose.
9) Fix TSO races in qlcnic driver, from Sritej Velaga.
10) In bnx2x the kernel driver and UNDI firmware can try to program the
chip at the same time, resulting in corruption. Add proper
synchronization. From Dmitry Kravkov.
11) Fix corruption of status block in firmware ram in bxn2x, from Ariel
Elior.
12) Fix load balancing hash regression of bonding driver in forwarding
configurations, from Eric Dumazet.
13) Fix TS ECR regression in TCP by calling tcp_replace_ts_recent() in
all the right spots, from Eric Dumazet.
14) Fix several bonding bugs having to do with address manintainence,
including not removing address when configuration operations
encounter errors, missed locking on the address lists, missing
refcounting on VLAN objects, etc. All from Nikolay Aleksandrov.
15) Add workarounds for firmware bugs in LTE qmi_wwan devices, wherein
the devices fail to add a proper ethernet header while on LTE
networks but otherwise properly do so on 2G and 3G ones. From Bjørn
Mork.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (38 commits)
net: fix incorrect credentials passing
net: rate-limit warn-bad-offload splats.
net: ax88796: avoid 64 bit arithmetic
qlge: Update version to 1.00.00.32.
qlge: Fix ethtool autoneg advertising.
qlge: Fix receive path to drop error frames
net: qmi_wwan: prevent duplicate mac address on link (firmware bug workaround)
net: qmi_wwan: fixup destination address (firmware bug workaround)
net: qmi_wwan: fixup missing ethernet header (firmware bug workaround)
bonding: in bond_mc_swap() bond's mc addr list is walked without lock
bonding: disable netpoll on enslave failure
bonding: primary_slave & curr_active_slave are not cleaned on enslave failure
bonding: vlans don't get deleted on enslave failure
bonding: mc addresses don't get deleted on enslave failure
pkt_sched: fix error return code in fw_change_attrs()
irda: small read past the end of array in debug code
tcp: call tcp_replace_ts_recent() from tcp_ack()
netfilter: xt_rpfilter: skip locally generated broadcast/multicast, too
netfilter: ipset: bitmap:ip,mac: fix listing with timeout
bonding: fix l23 and l34 load balancing in forwarding path
...
|
|
Commit 257b5358b32f ("scm: Capture the full credentials of the scm
sender") changed the credentials passing code to pass in the effective
uid/gid instead of the real uid/gid.
Obviously this doesn't matter most of the time (since normally they are
the same), but it results in differences for suid binaries when the wrong
uid/gid ends up being used.
This just undoes that (presumably unintentional) part of the commit.
Reported-by: Andy Lutomirski <[email protected]>
Cc: Eric W. Biederman <[email protected]>
Cc: Serge E. Hallyn <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: [email protected]
Signed-off-by: Linus Torvalds <[email protected]>
Acked-by: "Eric W. Biederman" <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Matt Fleming (1):
x86, efivars: firmware bug workarounds should be in platform
code
Matthew Garrett (3):
Move utf16 functions to kernel core and rename
efi: Pass boot services variable info to runtime code
efi: Distinguish between "remaining space" and actually used
space
Richard Weinberger (2):
x86,efi: Check max_size only if it is non-zero.
x86,efi: Implement efi_no_storage_paranoia parameter
Sergey Vlasov (2):
x86/Kconfig: Make EFI select UCS2_STRING
efi: Export efi_query_variable_store() for efivars.ko
Signed-off-by: H. Peter Anvin <[email protected]>
|
|
For each CPU vendor that implements CPU microcode patching, there will
be a minimum family for which this is implemented. Verify this
minimum level of support.
This can be done in the dispatch function or early in the application
functions. Doing the latter turned out to be somewhat awkward because
of the ineviable split between the BSP and the AP paths, and rather
than pushing deep into the application functions, do this in
the dispatch function.
Reported-by: "Bryan O'Donoghue" <[email protected]>
Suggested-by: Borislav Petkov <[email protected]>
Cc: Fenghua Yu <[email protected]>
Link: http://lkml.kernel.org/r/1366392183-4149-1-git-send-email-bryan.odonoghue.lkml@nexus-software.ie
|
|
If one does do something unfortunate and allow a
bad offload bug into the kernel, this the
skb_warn_bad_offload can effectively live-lock the
system, filling the logs with the same error over
and over.
Add rate limitation to this so that box remains otherwise
functional in this case.
Signed-off-by: Ben Greear <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
When building ax88796 on an ARM platform with 64-bit resource_size_t,
we currently get
drivers/net/ethernet/8390/ax88796.c:875: undefined reference to `__aeabi_uldivmod'
because we do a division on the length of the MMIO resource.
Since we know that this resource is very short, using an
"unsigned long" instead of "resource_size_t" is entirely
sufficient, and avoids this link-time error.
Cc: Ben Dooks <[email protected]>
Cc: [email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Signed-off-by: Jitendra Kalsaria <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Autoneg is supported on specific port types only. Fix the driver to advertise
autoneg based on the port type.
Signed-off-by: Jitendra Kalsaria <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
o Fix the driver to drop error frames in the receive path
o Update error counter which was not getting incremented
Signed-off-by: Sritej Velaga <[email protected]>
Signed-off-by: Jitendra Kalsaria <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Bjørn Mork says:
====================
This series adds workarounds for 3 different firmware bugs, each
preventing the affected devices from working at all. I therefore
humbly request that these fixes go to stable-3.8 (if still
maintained) and 3.9 (either via net if still possible, or via
stable if not).
All 3 workarounds are applied to all devices supported by the driver.
Adding quirks for specific devices was considered as an alternative,
but was rejected because we have too little information about the
exact distribution of the buggy firmwares. All we know is that the
same bug shows up in devices from at least 3 different, and presumably
independent, vendors.
The workarounds have instead been designed to automatically apply
when necessary, and to have as little impact as possible on unaffected
devices. The series has been tested on a number of devices both with
and without these bugs.
The series should apply cleanly to net/master, net-next/master and
stable/linux-3.8.y
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
We normally trust and use the CDC functional descriptors provided by a
number of devices. But some of these will erroneously list the address
reserved for the device end of the link. Attempting to use this on
both the device and host side will naturally not work.
Work around this bug by ignoring the functional descriptor and assign a
random address instead in this case.
Signed-off-by: Bjørn Mork <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Received packets are sometimes addressed to 00:a0:c6:00:00:00
instead of the address the device firmware should have learned
from the host:
321.224126 77.16.85.204 -> 148.122.171.134 ICMP 98 Echo (ping) request id=0x4025, seq=64/16384, ttl=64
0000 82 c0 82 c9 f1 67 82 c0 82 c9 f1 67 08 00 45 00 .....g.....g..E.
0010 00 54 00 00 40 00 40 01 57 cc 4d 10 55 cc 94 7a .T..@[email protected]
0020 ab 86 08 00 62 fc 40 25 00 40 b2 bc 6e 51 00 00 ....b.@%[email protected]..
0030 00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15 ..k.............
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
321.240607 148.122.171.134 -> 77.16.85.204 ICMP 98 Echo (ping) reply id=0x4025, seq=64/16384, ttl=55
0000 00 a0 c6 00 00 00 02 50 f3 00 00 00 08 00 45 00 .......P......E.
0010 00 54 00 56 00 00 37 01 a0 76 94 7a ab 86 4d 10 .T.V..7..v.z..M.
0020 55 cc 00 00 6a fc 40 25 00 40 b2 bc 6e 51 00 00 U...j.@%[email protected]..
0030 00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15 ..k.............
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
The bogus address is always the same, and matches the address
suggested by many devices as a default address. It is likely a
hardcoded firmware default.
The circumstances where this bug has been observed indicates that
the trigger is related to timing or some other factor the host
cannot control. Repeating the exact same configuration sequence
that caused it to trigger once, will not necessarily cause it to
trigger the next time. Reproducing the bug is therefore difficult.
This opens up a possibility that the bug is more common than we can
confirm, because affected devices often will work properly again
after a reset. A procedure most users are likely to try out before
reporting a bug.
Unconditionally rewriting the destination address if the first digit
of the received packet is 0, is considered an acceptable compromise
since we already have to inspect this digit. The simplification will
cause unnecessary rewrites if the real address starts with 0, but this
is still better than adding additional tests for this particular case.
Signed-off-by: Bjørn Mork <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
A number of LTE devices from different vendors all suffer from the
same firmware bug: Most of the packets received from the device while
it is attached to a LTE network will not have an ethernet header. The
devices work as expected when attached to 2G or 3G networks, sending
an ethernet header with all packets.
This driver is not aware of which network the modem attached to, and
even if it were there are still some packet types which are always
received with the header intact.
All devices supported by this driver have severely limited
networking capabilities:
- can only transmit IPv4, IPv6 and possibly ARP
- can only support a single host hardware address at any time
- will only do point-to-point communcation with the host
Because of this, we are able to reliably identify any bogus raw IP
packets by simply looking at the 4 IP version bits. All we need to
do is to avoid 4 or 6 in the first digit of the mac address. This
workaround ensures this, and fix up the received packets as necessary.
Given the distribution of the bug, it is believed that the source is
the chipset vendor. The devices which are verified to be affected are:
Huawei E392u-12 (Qualcomm MDM9200)
Pantech UML290 (Qualcomm MDM9600)
Novatel USB551L (Qualcomm MDM9600)
Novatel E362 (Qualcomm MDM9600)
It is believed that the bug depend on firmware revision, which means
that possibly all devices based on the above mentioned chipset may be
affected if we consider all available firmware revisions.
The information about affected devices and versions is likely
incomplete. As the additional overhead for packets not needing this
fixup is very small, it is considered acceptable to apply the
workaround to all devices handled by this driver.
Reported-by: Dan Williams <[email protected]>
Signed-off-by: Bjørn Mork <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|