[ 03/11] ASoC: wm8903: Fix the bypass to HP/LINEOUT when no DAC or ADC is running
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Alban Bedel
commit f1ca493b0b5e8f42d3b2dc8877860db2983f47b6 upstream.
The Charge Pump needs the DSP clock to work properly, without it the
bypass to HP/LINEOUT is not working properly. This requirement is not
mentioned in the datasheet but has been confirmed by Mark Brown from
Wolfson.
Signed-off-by: Alban Bedel
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
---
sound/soc/codecs/wm8903.c |2 ++
1 file changed, 2 insertions(+)
--- a/sound/soc/codecs/wm8903.c
+++ b/sound/soc/codecs/wm8903.c
@@ -1101,6 +1101,8 @@ static const struct snd_soc_dapm_route w
{ "ROP", NULL, "Right Speaker PGA" },
{ "RON", NULL, "Right Speaker PGA" },
+ { "Charge Pump", NULL, "CLK_DSP" },
+
{ "Left Headphone Output PGA", NULL, "Charge Pump" },
{ "Right Headphone Output PGA", NULL, "Charge Pump" },
{ "Left Line Output PGA", NULL, "Charge Pump" },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 05/11] PM / reboot: call syscore_shutdown() after disable_nonboot_cpus()
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Huacai Chen
commit 6f389a8f1dd22a24f3d9afc2812b30d639e94625 upstream.
As commit 40dc166c (PM / Core: Introduce struct syscore_ops for core
subsystems PM) say, syscore_ops operations should be carried with one
CPU on-line and interrupts disabled. However, after commit f96972f2d
(kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()),
syscore_shutdown() is called before disable_nonboot_cpus(), so break
the rules. We have a MIPS machine with a 8259A PIC, and there is an
external timer (HPET) linked at 8259A. Since 8259A has been shutdown
too early (by syscore_shutdown()), disable_nonboot_cpus() runs without
timer interrupt, so it hangs and reboot fails. This patch call
syscore_shutdown() a little later (after disable_nonboot_cpus()) to
avoid reboot failure, this is the same way as poweroff does.
For consistency, add disable_nonboot_cpus() to kernel_halt().
Signed-off-by: Huacai Chen
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
---
kernel/sys.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -320,7 +320,6 @@ void kernel_restart_prepare(char *cmd)
system_state = SYSTEM_RESTART;
usermodehelper_disable();
device_shutdown();
- syscore_shutdown();
}
/**
@@ -335,6 +334,7 @@ void kernel_restart(char *cmd)
{
kernel_restart_prepare(cmd);
disable_nonboot_cpus();
+ syscore_shutdown();
if (!cmd)
printk(KERN_EMERG "Restarting system.\n");
else
@@ -360,6 +360,7 @@ static void kernel_shutdown_prepare(enum
void kernel_halt(void)
{
kernel_shutdown_prepare(SYSTEM_HALT);
+ disable_nonboot_cpus();
syscore_shutdown();
printk(KERN_EMERG "System halted.\n");
kmsg_dump(KMSG_DUMP_HALT);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 10/11] mtdchar: fix offset overflow detection
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit 9c603e53d380459fb62fec7cd085acb0b74ac18f upstream.
Sasha Levin has been running trinity in a KVM tools guest, and was able
to trigger the BUG_ON() at arch/x86/mm/pat.c:279 (verifying the range of
the memory type). The call trace showed that it was mtdchar_mmap() that
created an invalid remap_pfn_range().
The problem is that mtdchar_mmap() does various really odd and subtle
things with the vma page offset etc, and uses the wrong types (and the
wrong overflow) detection for it.
For example, the page offset may well be 32-bit on a 32-bit
architecture, but after shifting it up by PAGE_SHIFT, we need to use a
potentially 64-bit resource_size_t to correctly hold the full value.
Also, we need to check that the vma length plus offset doesn't overflow
before we check that it is smaller than the length of the mtdmap region.
This fixes things up and tries to make the code a bit easier to read.
Reported-and-tested-by: Sasha Levin
Acked-by: Suresh Siddha
Acked-by: Artem Bityutskiy
Cc: David Woodhouse
Cc: linux-...@lists.infradead.org
Signed-off-by: Linus Torvalds
Cc: Ben Hutchings
Cc: Brad Spengler
Signed-off-by: Greg Kroah-Hartman
---
drivers/mtd/mtdchar.c | 48 ++--
1 file changed, 42 insertions(+), 6 deletions(-)
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -1064,6 +1064,33 @@ static unsigned long mtd_get_unmapped_ar
}
#endif
+static inline unsigned long get_vm_size(struct vm_area_struct *vma)
+{
+ return vma->vm_end - vma->vm_start;
+}
+
+static inline resource_size_t get_vm_offset(struct vm_area_struct *vma)
+{
+ return (resource_size_t) vma->vm_pgoff << PAGE_SHIFT;
+}
+
+/*
+ * Set a new vm offset.
+ *
+ * Verify that the incoming offset really works as a page offset,
+ * and that the offset and size fit in a resource_size_t.
+ */
+static inline int set_vm_offset(struct vm_area_struct *vma, resource_size_t
off)
+{
+ pgoff_t pgoff = off >> PAGE_SHIFT;
+ if (off != (resource_size_t) pgoff << PAGE_SHIFT)
+ return -EINVAL;
+ if (off + get_vm_size(vma) - 1 < off)
+ return -EINVAL;
+ vma->vm_pgoff = pgoff;
+ return 0;
+}
+
/*
* set up a mapping for shared memory segments
*/
@@ -1073,20 +1100,29 @@ static int mtd_mmap(struct file *file, s
struct mtd_file_info *mfi = file->private_data;
struct mtd_info *mtd = mfi->mtd;
struct map_info *map = mtd->priv;
- unsigned long start;
- unsigned long off;
- u32 len;
+ resource_size_t start, off;
+ unsigned long len, vma_len;
if (mtd->type == MTD_RAM || mtd->type == MTD_ROM) {
- off = vma->vm_pgoff << PAGE_SHIFT;
+ off = get_vm_offset(vma);
start = map->phys;
len = PAGE_ALIGN((start & ~PAGE_MASK) + map->size);
start &= PAGE_MASK;
- if ((vma->vm_end - vma->vm_start + off) > len)
+ vma_len = get_vm_size(vma);
+
+ /* Overflow in off+len? */
+ if (vma_len + off < off)
+ return -EINVAL;
+ /* Does it fit in the mapping? */
+ if (vma_len + off > len)
return -EINVAL;
off += start;
- vma->vm_pgoff = off >> PAGE_SHIFT;
+ /* Did that overflow? */
+ if (off < start)
+ return -EINVAL;
+ if (set_vm_offset(vma, off) < 0)
+ return -EINVAL;
vma->vm_flags |= VM_IO | VM_RESERVED;
#ifdef pgprot_noncached
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 02/11] x86-32, mm: Rip out x86_32 NUMA remapping code
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Hansen
commit f03574f2d5b2d6229dcdf2d322848065f72953c7 upstream.
[was already included in 3.0, but I missed the patch hunk for
arch/x86/mm/numa_32.c - gregkh]
This code was an optimization for 32-bit NUMA systems.
It has probably been the cause of a number of subtle bugs over
the years, although the conditions to excite them would have
been hard to trigger. Essentially, we remap part of the kernel
linear mapping area, and then sometimes part of that area gets
freed back in to the bootmem allocator. If those pages get
used by kernel data structures (say mem_map[] or a dentry),
there's no big deal. But, if anyone ever tried to use the
linear mapping for these pages _and_ cared about their physical
address, bad things happen.
For instance, say you passed __GFP_ZERO to the page allocator
and then happened to get handed one of these pages, it zero the
remapped page, but it would make a pte to the _old_ page.
There are probably a hundred other ways that it could screw
with things.
We don't need to hang on to performance optimizations for
these old boxes any more. All my 32-bit NUMA systems are long
dead and buried, and I probably had access to more than most
people.
This code is causing real things to break today:
https://lkml.org/lkml/2013/1/9/376
I looked in to actually fixing this, but it requires surgery
to way too much brittle code, as well as stuff like
per_cpu_ptr_to_phys().
[ hpa: Cc: this for -stable, since it is a memory corruption issue.
However, an alternative is to simply mark NUMA as depends BROKEN
rather than EXPERIMENTAL in the X86_32 subclause... ]
Link: http://lkml.kernel.org/r/20130131005616.1c79f...@kernel.stglabs.ibm.com
Signed-off-by: H. Peter Anvin
Cc: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/mm/numa_32.c | 161 --
1 file changed, 161 deletions(-)
--- a/arch/x86/mm/numa_32.c
+++ b/arch/x86/mm/numa_32.c
@@ -73,167 +73,6 @@ unsigned long node_memmap_size_bytes(int
extern unsigned long highend_pfn, highstart_pfn;
-#define LARGE_PAGE_BYTES (PTRS_PER_PTE * PAGE_SIZE)
-
-static void *node_remap_start_vaddr[MAX_NUMNODES];
-void set_pmd_pfn(unsigned long vaddr, unsigned long pfn, pgprot_t flags);
-
-/*
- * Remap memory allocator
- */
-static unsigned long node_remap_start_pfn[MAX_NUMNODES];
-static void *node_remap_end_vaddr[MAX_NUMNODES];
-static void *node_remap_alloc_vaddr[MAX_NUMNODES];
-
-/**
- * alloc_remap - Allocate remapped memory
- * @nid: NUMA node to allocate memory from
- * @size: The size of allocation
- *
- * Allocate @size bytes from the remap area of NUMA node @nid. The
- * size of the remap area is predetermined by init_alloc_remap() and
- * only the callers considered there should call this function. For
- * more info, please read the comment on top of init_alloc_remap().
- *
- * The caller must be ready to handle allocation failure from this
- * function and fall back to regular memory allocator in such cases.
- *
- * CONTEXT:
- * Single CPU early boot context.
- *
- * RETURNS:
- * Pointer to the allocated memory on success, %NULL on failure.
- */
-void *alloc_remap(int nid, unsigned long size)
-{
- void *allocation = node_remap_alloc_vaddr[nid];
-
- size = ALIGN(size, L1_CACHE_BYTES);
-
- if (!allocation || (allocation + size) > node_remap_end_vaddr[nid])
- return NULL;
-
- node_remap_alloc_vaddr[nid] += size;
- memset(allocation, 0, size);
-
- return allocation;
-}
-
-#ifdef CONFIG_HIBERNATION
-/**
- * resume_map_numa_kva - add KVA mapping to the temporary page tables created
- * during resume from hibernation
- * @pgd_base - temporary resume page directory
- */
-void resume_map_numa_kva(pgd_t *pgd_base)
-{
- int node;
-
- for_each_online_node(node) {
- unsigned long start_va, start_pfn, nr_pages, pfn;
-
- start_va = (unsigned long)node_remap_start_vaddr[node];
- start_pfn = node_remap_start_pfn[node];
- nr_pages = (node_remap_end_vaddr[node] -
- node_remap_start_vaddr[node]) >> PAGE_SHIFT;
-
- printk(KERN_DEBUG "%s: node %d\n", __func__, node);
-
- for (pfn = 0; pfn < nr_pages; pfn += PTRS_PER_PTE) {
- unsigned long vaddr = start_va + (pfn << PAGE_SHIFT);
- pgd_t *pgd = pgd_base + pgd_index(vaddr);
- pud_t *pud = pud_offset(pgd, vaddr);
- pmd_t *pmd = pmd_offset(pud, vaddr);
-
- set_pmd(pmd, pfn_pmd(start_pfn + pfn,
- PAGE_KERNEL_LARGE_EXEC));
-
- printk(KERN_DEBUG "%s: %08lx -> pfn %08lx\n",
- __func__, vaddr, start_pfn + pfn);
- }
- }
-}
-#endif
[ 11/11] r8169: fix auto speed down issue
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Hayes Wang
commit e2409d83434d77874b461b78af6a19cd6e6a1280 upstream.
It would cause no link after suspending or shutdowning when the
nic changes the speed to 10M and connects to a link partner which
forces the speed to 100M.
Check the link partner ability to determine which speed to set.
The link speed down code path is not factored in this kernel version.
Signed-off-by: Hayes Wang
Acked-by: Francois Romieu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/r8169.c | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -3105,11 +3105,34 @@ static void r810x_phy_power_up(struct rt
rtl_writephy(tp, MII_BMCR, BMCR_ANENABLE);
}
+static void rtl_speed_down(struct rtl8169_private *tp)
+{
+ u32 adv;
+ int lpa;
+
+ rtl_writephy(tp, 0x1f, 0x);
+ lpa = rtl_readphy(tp, MII_LPA);
+
+ if (lpa & (LPA_10HALF | LPA_10FULL))
+ adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full;
+ else if (lpa & (LPA_100HALF | LPA_100FULL))
+ adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
+ ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full;
+ else
+ adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
+ ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full |
+ (tp->mii.supports_gmii ?
+ ADVERTISED_1000baseT_Half |
+ ADVERTISED_1000baseT_Full : 0);
+
+ rtl8169_set_speed(tp->dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL,
+ adv);
+}
+
static void r810x_pll_power_down(struct rtl8169_private *tp)
{
if (__rtl8169_get_wol(tp) & WAKE_ANY) {
- rtl_writephy(tp, 0x1f, 0x);
- rtl_writephy(tp, MII_BMCR, 0x);
+ rtl_speed_down(tp);
return;
}
@@ -3201,8 +3224,7 @@ static void r8168_pll_power_down(struct
rtl_ephy_write(ioaddr, 0x19, 0xff64);
if (__rtl8169_get_wol(tp) & WAKE_ANY) {
- rtl_writephy(tp, 0x1f, 0x);
- rtl_writephy(tp, MII_BMCR, 0x);
+ rtl_speed_down(tp);
if (tp->mac_version == RTL_GIGA_MAC_VER_32 ||
tp->mac_version == RTL_GIGA_MAC_VER_33)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 07/11] sched_clock: Prevent 64bit inatomicity on 32bit systems
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit a1cbcaa9ea87b87a96b9fc465951dcf36e459ca2 upstream. The sched_clock_remote() implementation has the following inatomicity problem on 32bit systems when accessing the remote scd->clock, which is a 64bit value. CPU0CPU1 sched_clock_local() sched_clock_remote(CPU0) ... remote_clock = scd[CPU0]->clock read_low32bit(scd[CPU0]->clock) cmpxchg64(scd->clock,...) read_high32bit(scd[CPU0]->clock) While the update of scd->clock is using an atomic64 mechanism, the readout on the remote cpu is not, which can cause completely bogus readouts. It is a quite rare problem, because it requires the update to hit the narrow race window between the low/high readout and the update must go across the 32bit boundary. The resulting misbehaviour is, that CPU1 will see the sched_clock on CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value to this bogus timestamp. This stays that way due to the clamping implementation for about 4 seconds until the synchronization with CLOCK_MONOTONIC undoes the problem. The issue is hard to observe, because it might only result in a less accurate SCHED_OTHER timeslicing behaviour. To create observable damage on realtime scheduling classes, it is necessary that the bogus update of CPU1 sched_clock happens in the context of an realtime thread, which then gets charged 4 seconds of RT runtime, which results in the RT throttler mechanism to trigger and prevent scheduling of RT tasks for a little less than 4 seconds. So this is quite unlikely as well. The issue was quite hard to decode as the reproduction time is between 2 days and 3 weeks and intrusive tracing makes it less likely, but the following trace recorded with trace_clock=global, which uses sched_clock_local(), gave the final hint: -0 0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80 -0 0d..30 400269.477151: hrtimer_start: hrtimer=0xf7061e80 ... irq/20-S-587 1d..32 400273.772118: sched_wakeup: comm= ... target_cpu=0 -0 0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80 What happens is that CPU0 goes idle and invokes sched_clock_idle_sleep_event() which invokes sched_clock_local() and CPU1 runs a remote wakeup for CPU0 at the same time, which invokes sched_remote_clock(). The time jump gets propagated to CPU0 via sched_remote_clock() and stays stale on both cores for ~4 seconds. There are only two other possibilities, which could cause a stale sched clock: 1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic wrong value. 2) sched_clock() which reads the TSC returns a sporadic wrong value. #1 can be excluded because sched_clock would continue to increase for one jiffy and then go stale. #2 can be excluded because it would not make the clock jump forward. It would just result in a stale sched_clock for one jiffy. After quite some brain twisting and finding the same pattern on other traces, sched_clock_remote() remained the only place which could cause such a problem and as explained above it's indeed racy on 32bit systems. So while on 64bit systems the readout is atomic, we need to verify the remote readout on 32bit machines. We need to protect the local->clock readout in sched_clock_remote() on 32bit as well because an NMI could hit between the low and the high readout, call sched_clock_local() and modify local->clock. Thanks to Siegfried Wulsch for bearing with my debug requests and going through the tedious tasks of running a bunch of reproducer systems to generate the debug information which let me decode the issue. Reported-by: Siegfried Wulsch Acked-by: Peter Zijlstra Cc: Steven Rostedt Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman --- kernel/sched_clock.c | 26 ++ 1 file changed, 26 insertions(+) --- a/kernel/sched_clock.c +++ b/kernel/sched_clock.c @@ -176,10 +176,36 @@ static u64 sched_clock_remote(struct sch u64 this_clock, remote_clock; u64 *ptr, old_val, val; +#if BITS_PER_LONG != 64 +again: + /* +* Careful here: The local and the remote clock values need to +* be read out atomic as we need to compare the values and +* then update either the local or the remote side. So the +* cmpxchg64 below only protects one readout. +* +* We must reread via sched_clock_local() in the retry case on +* 32bit as an NMI could use sched_clock_local() via the +* tracer and hit between the readout of +* the low32bit and the high 32bit portion. +*/ + this_clock = sched_clock_local(my_scd); + /* +* We must enforce atomic readout on 32bit, otherwise the +* update on the remote cpu can hit inbetween
[ 08/11] x86, mm, paravirt: Fix vmalloc_fault oops during lazy MMU updates
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Samu Kallio
commit 1160c2779b826c6f5c08e5cc542de58fd1f667d5 upstream.
In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
when lazy MMU updates are enabled, because set_pgd effects are being
deferred.
One instance of this problem is during process mm cleanup with memory
cgroups enabled. The chain of events is as follows:
- zap_pte_range enables lazy MMU updates
- zap_pte_range eventually calls mem_cgroup_charge_statistics,
which accesses the vmalloc'd mem_cgroup per-cpu stat area
- vmalloc_fault is triggered which tries to sync the corresponding
PGD entry with set_pgd, but the update is deferred
- vmalloc_fault oopses due to a mismatch in the PUD entries
The OOPs usually looks as so:
[ cut here ]
kernel BUG at arch/x86/mm/fault.c:396!
invalid opcode: [#1] SMP
.. snip ..
CPU 1
Pid: 10866, comm: httpd Not tainted 3.6.10-4.fc18.x86_64 #1
RIP: e030:[] [] vmalloc_fault+0x11f/0x208
.. snip ..
Call Trace:
[] do_page_fault+0x399/0x4b0
[] ? xen_mc_extend_args+0xec/0x110
[] page_fault+0x25/0x30
[] ? mem_cgroup_charge_statistics.isra.13+0x13/0x50
[] __mem_cgroup_uncharge_common+0xd8/0x350
[] mem_cgroup_uncharge_page+0x57/0x60
[] page_remove_rmap+0xe0/0x150
[] ? vm_normal_page+0x1a/0x80
[] unmap_single_vma+0x531/0x870
[] unmap_vmas+0x52/0xa0
[] ? pte_mfn_to_pfn+0x72/0x100
[] exit_mmap+0x98/0x170
[] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
[] mmput+0x83/0xf0
[] exit_mm+0x104/0x130
[] do_exit+0x15a/0x8c0
[] do_group_exit+0x3f/0xa0
[] sys_exit_group+0x17/0x20
[] system_call_fastpath+0x16/0x1b
Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
changes visible to the consistency checks.
RedHat-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=914737
Tested-by: Josh Boyer
Reported-and-Tested-by: Krishna Raman
Signed-off-by: Samu Kallio
Link:
http://lkml.kernel.org/r/1364045796-10720-1-git-send-email-konrad.w...@oracle.com
Tested-by: Konrad Rzeszutek Wilk
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/mm/fault.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -376,10 +376,12 @@ static noinline __kprobes int vmalloc_fa
if (pgd_none(*pgd_ref))
return -1;
- if (pgd_none(*pgd))
+ if (pgd_none(*pgd)) {
set_pgd(pgd, *pgd_ref);
- else
+ arch_flush_lazy_mmu_mode();
+ } else {
BUG_ON(pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_ref));
+ }
/*
* Below here mismatches are bugs because these lower tables
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 09/11] x86, mm: Patch out arch_flush_lazy_mmu_mode() when running on bare metal
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Boris Ostrovsky
commit 511ba86e1d386f671084b5d0e6f110bb30b8eeb2 upstream.
Invoking arch_flush_lazy_mmu_mode() results in calls to
preempt_enable()/disable() which may have performance impact.
Since lazy MMU is not used on bare metal we can patch away
arch_flush_lazy_mmu_mode() so that it is never called in such
environment.
[ hpa: the previous patch "Fix vmalloc_fault oops during lazy MMU
updates" may cause a minor performance regression on
bare metal. This patch resolves that performance regression. It is
somewhat unclear to me if this is a good -stable candidate. ]
Signed-off-by: Boris Ostrovsky
Link:
http://lkml.kernel.org/r/1364045796-10720-2-git-send-email-konrad.w...@oracle.com
Tested-by: Josh Boyer
Tested-by: Konrad Rzeszutek Wilk
Acked-by: Borislav Petkov
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/paravirt.h |5 -
arch/x86/include/asm/paravirt_types.h |2 ++
arch/x86/kernel/paravirt.c| 25 +
arch/x86/lguest/boot.c|1 +
arch/x86/xen/mmu.c|1 +
5 files changed, 21 insertions(+), 13 deletions(-)
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -731,7 +731,10 @@ static inline void arch_leave_lazy_mmu_m
PVOP_VCALL0(pv_mmu_ops.lazy_mode.leave);
}
-void arch_flush_lazy_mmu_mode(void);
+static inline void arch_flush_lazy_mmu_mode(void)
+{
+ PVOP_VCALL0(pv_mmu_ops.lazy_mode.flush);
+}
static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
phys_addr_t phys, pgprot_t flags)
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -85,6 +85,7 @@ struct pv_lazy_ops {
/* Set deferred update mode, used for batching operations. */
void (*enter)(void);
void (*leave)(void);
+ void (*flush)(void);
};
struct pv_time_ops {
@@ -673,6 +674,7 @@ void paravirt_end_context_switch(struct
void paravirt_enter_lazy_mmu(void);
void paravirt_leave_lazy_mmu(void);
+void paravirt_flush_lazy_mmu(void);
void _paravirt_nop(void);
u32 _paravirt_ident_32(u32);
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -253,6 +253,18 @@ void paravirt_leave_lazy_mmu(void)
leave_lazy(PARAVIRT_LAZY_MMU);
}
+void paravirt_flush_lazy_mmu(void)
+{
+ preempt_disable();
+
+ if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
+ arch_leave_lazy_mmu_mode();
+ arch_enter_lazy_mmu_mode();
+ }
+
+ preempt_enable();
+}
+
void paravirt_start_context_switch(struct task_struct *prev)
{
BUG_ON(preemptible());
@@ -282,18 +294,6 @@ enum paravirt_lazy_mode paravirt_get_laz
return percpu_read(paravirt_lazy_mode);
}
-void arch_flush_lazy_mmu_mode(void)
-{
- preempt_disable();
-
- if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
- arch_leave_lazy_mmu_mode();
- arch_enter_lazy_mmu_mode();
- }
-
- preempt_enable();
-}
-
struct pv_info pv_info = {
.name = "bare hardware",
.paravirt_enabled = 0,
@@ -462,6 +462,7 @@ struct pv_mmu_ops pv_mmu_ops = {
.lazy_mode = {
.enter = paravirt_nop,
.leave = paravirt_nop,
+ .flush = paravirt_nop,
},
.set_fixmap = native_set_fixmap,
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -1309,6 +1309,7 @@ __init void lguest_init(void)
pv_mmu_ops.read_cr3 = lguest_read_cr3;
pv_mmu_ops.lazy_mode.enter = paravirt_enter_lazy_mmu;
pv_mmu_ops.lazy_mode.leave = lguest_leave_lazy_mmu_mode;
+ pv_mmu_ops.lazy_mode.flush = paravirt_flush_lazy_mmu;
pv_mmu_ops.pte_update = lguest_pte_update;
pv_mmu_ops.pte_update_defer = lguest_pte_update;
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2011,6 +2011,7 @@ static const struct pv_mmu_ops xen_mmu_o
.lazy_mode = {
.enter = paravirt_enter_lazy_mmu,
.leave = xen_leave_lazy_mmu,
+ .flush = paravirt_flush_lazy_mmu,
},
.set_fixmap = xen_set_fixmap,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 06/11] target: Fix incorrect fallthrough of ALUA Standby/Offline/Transition CDBs
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Bellinger
commit 30f359a6f9da65a66de8cadf959f0f4a0d498bba upstream.
This patch fixes a bug where a handful of informational / control CDBs
that should be allowed during ALUA access state Standby/Offline/Transition
where incorrectly returning CHECK_CONDITION + ASCQ_04H_ALUA_TG_PT_*.
This includes INQUIRY + REPORT_LUNS, which would end up preventing LUN
registration when LUN scanning occured during these ALUA access states.
Signed-off-by: Nicholas Bellinger
Cc: Hannes Reinecke
Signed-off-by: Greg Kroah-Hartman
---
drivers/target/target_core_alua.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/target/target_core_alua.c
+++ b/drivers/target/target_core_alua.c
@@ -351,6 +351,7 @@ static inline int core_alua_state_standb
case REPORT_LUNS:
case RECEIVE_DIAGNOSTIC:
case SEND_DIAGNOSTIC:
+ return 0;
case MAINTENANCE_IN:
switch (cdb[1]) {
case MI_REPORT_TARGET_PGS:
@@ -393,6 +394,7 @@ static inline int core_alua_state_unavai
switch (cdb[0]) {
case INQUIRY:
case REPORT_LUNS:
+ return 0;
case MAINTENANCE_IN:
switch (cdb[1]) {
case MI_REPORT_TARGET_PGS:
@@ -433,6 +435,7 @@ static inline int core_alua_state_transi
switch (cdb[0]) {
case INQUIRY:
case REPORT_LUNS:
+ return 0;
case MAINTENANCE_IN:
switch (cdb[1]) {
case MI_REPORT_TARGET_PGS:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 04/11] tracing: Fix double free when function profile init failed
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Namhyung Kim commit 83e03b3fe4daffdebbb42151d5410d730ae50bd1 upstream. On the failure path, stat->start and stat->pages will refer same page. So it'll attempt to free the same page again and get kernel panic. Link: http://lkml.kernel.org/r/1364820385-32027-1-git-send-email-namhy...@kernel.org Signed-off-by: Namhyung Kim Cc: Frederic Weisbecker Cc: Namhyung Kim Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman --- kernel/trace/ftrace.c |1 - 1 file changed, 1 deletion(-) --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -566,7 +566,6 @@ int ftrace_profile_pages_init(struct ftr free_page(tmp); } - free_page((unsigned long)stat->pages); stat->pages = NULL; stat->start = NULL; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 01/11] ALSA: usb-audio: fix endianness bug in snd_nativeinstruments_*
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Eldad Zack
commit 889d66848b12d891248b03abcb2a42047f8e172a upstream.
The usb_control_msg() function expects __u16 types and performs
the endianness conversions by itself.
However, in three places, a conversion is performed before it is
handed over to usb_control_msg(), which leads to a double conversion
(= no conversion):
* snd_usb_nativeinstruments_boot_quirk()
* snd_nativeinstruments_control_get()
* snd_nativeinstruments_control_put()
Caught by sparse:
sound/usb/mixer_quirks.c:512:38: warning: incorrect type in argument 6
(different base types)
sound/usb/mixer_quirks.c:512:38:expected unsigned short [unsigned]
[usertype] index
sound/usb/mixer_quirks.c:512:38:got restricted __le16 [usertype]
sound/usb/mixer_quirks.c:543:35: warning: incorrect type in argument 5
(different base types)
sound/usb/mixer_quirks.c:543:35:expected unsigned short [unsigned]
[usertype] value
sound/usb/mixer_quirks.c:543:35:got restricted __le16 [usertype]
sound/usb/mixer_quirks.c:543:56: warning: incorrect type in argument 6
(different base types)
sound/usb/mixer_quirks.c:543:56:expected unsigned short [unsigned]
[usertype] index
sound/usb/mixer_quirks.c:543:56:got restricted __le16 [usertype]
sound/usb/quirks.c:502:35: warning: incorrect type in argument 5 (different
base types)
sound/usb/quirks.c:502:35:expected unsigned short [unsigned] [usertype]
value
sound/usb/quirks.c:502:35:got restricted __le16 [usertype]
Signed-off-by: Eldad Zack
Acked-by: Daniel Mack
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/usb/mixer_quirks.c |4 ++--
sound/usb/quirks.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/sound/usb/mixer_quirks.c
+++ b/sound/usb/mixer_quirks.c
@@ -396,7 +396,7 @@ static int snd_nativeinstruments_control
else
ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), bRequest,
USB_TYPE_VENDOR | USB_RECIP_DEVICE |
USB_DIR_IN,
- 0, cpu_to_le16(wIndex),
+ 0, wIndex,
&tmp, sizeof(tmp), 1000);
up_read(&mixer->chip->shutdown_rwsem);
@@ -427,7 +427,7 @@ static int snd_nativeinstruments_control
else
ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), bRequest,
USB_TYPE_VENDOR | USB_RECIP_DEVICE |
USB_DIR_OUT,
- cpu_to_le16(wValue), cpu_to_le16(wIndex),
+ wValue, wIndex,
NULL, 0, 1000);
up_read(&mixer->chip->shutdown_rwsem);
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -455,7 +455,7 @@ static int snd_usb_nativeinstruments_boo
{
int ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
0xaf, USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- cpu_to_le16(1), 0, NULL, 0, 1000);
+ 1, 0, NULL, 0, 1000);
if (ret < 0)
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 00/17] 3.4.41-stable review
This is the start of the stable review cycle for the 3.4.41 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Apr 17 02:23:06 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.41-rc1.gz and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 3.4.41-rc1 Hayes Wang r8169: fix auto speed down issue Linus Torvalds kobject: fix kset_find_obj() race with concurrent last kobject_put() Linus Torvalds mtdchar: fix offset overflow detection Boris Ostrovsky x86, mm: Patch out arch_flush_lazy_mmu_mode() when running on bare metal Samu Kallio x86, mm, paravirt: Fix vmalloc_fault oops during lazy MMU updates Thomas Gleixner sched_clock: Prevent 64bit inatomicity on 32bit systems Dave Airlie udl: handle EDID failure properly. Thomas Hellstrom kref: Implement kref_get_unless_zero v3 Suleiman Souhlal vfs: Revert spurious fix to spinning prevention in prune_icache_sb Nicholas Bellinger target: Fix incorrect fallthrough of ALUA Standby/Offline/Transition CDBs Sachin Prabhu cifs: Allow passwords which begin with a delimitor Lukasz Dorau SCSI: libsas: fix handling vacant phy in sas_set_ex_phy() Chris Wilson drm/i915: Use the correct size of the GTT for placing the per-process entries Huacai Chen PM / reboot: call syscore_shutdown() after disable_nonboot_cpus() Namhyung Kim tracing: Fix double free when function profile init failed Alban Bedel ASoC: wm8903: Fix the bypass to HP/LINEOUT when no DAC or ADC is running Eldad Zack ALSA: usb-audio: fix endianness bug in snd_nativeinstruments_* - Diffstat: Makefile | 4 +-- arch/x86/include/asm/paravirt.h | 5 +++- arch/x86/include/asm/paravirt_types.h | 2 ++ arch/x86/kernel/paravirt.c| 25 +- arch/x86/lguest/boot.c| 1 + arch/x86/mm/fault.c | 6 +++-- arch/x86/xen/mmu.c| 1 + drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +- drivers/gpu/drm/udl/udl_connector.c | 4 +++ drivers/mtd/mtdchar.c | 48 ++- drivers/net/ethernet/realtek/r8169.c | 28 +--- drivers/scsi/libsas/sas_expander.c| 12 + drivers/target/target_core_alua.c | 3 +++ fs/cifs/connect.c | 16 +--- fs/inode.c| 2 +- include/linux/kref.h | 21 +++ kernel/sched/clock.c | 26 +++ kernel/sys.c | 3 ++- kernel/trace/ftrace.c | 1 - lib/kobject.c | 9 ++- sound/soc/codecs/wm8903.c | 2 ++ sound/usb/mixer_quirks.c | 4 +-- sound/usb/quirks.c| 2 +- 23 files changed, 190 insertions(+), 37 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 12/17] sched_clock: Prevent 64bit inatomicity on 32bit systems
3.4-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit a1cbcaa9ea87b87a96b9fc465951dcf36e459ca2 upstream. The sched_clock_remote() implementation has the following inatomicity problem on 32bit systems when accessing the remote scd->clock, which is a 64bit value. CPU0CPU1 sched_clock_local() sched_clock_remote(CPU0) ... remote_clock = scd[CPU0]->clock read_low32bit(scd[CPU0]->clock) cmpxchg64(scd->clock,...) read_high32bit(scd[CPU0]->clock) While the update of scd->clock is using an atomic64 mechanism, the readout on the remote cpu is not, which can cause completely bogus readouts. It is a quite rare problem, because it requires the update to hit the narrow race window between the low/high readout and the update must go across the 32bit boundary. The resulting misbehaviour is, that CPU1 will see the sched_clock on CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value to this bogus timestamp. This stays that way due to the clamping implementation for about 4 seconds until the synchronization with CLOCK_MONOTONIC undoes the problem. The issue is hard to observe, because it might only result in a less accurate SCHED_OTHER timeslicing behaviour. To create observable damage on realtime scheduling classes, it is necessary that the bogus update of CPU1 sched_clock happens in the context of an realtime thread, which then gets charged 4 seconds of RT runtime, which results in the RT throttler mechanism to trigger and prevent scheduling of RT tasks for a little less than 4 seconds. So this is quite unlikely as well. The issue was quite hard to decode as the reproduction time is between 2 days and 3 weeks and intrusive tracing makes it less likely, but the following trace recorded with trace_clock=global, which uses sched_clock_local(), gave the final hint: -0 0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80 -0 0d..30 400269.477151: hrtimer_start: hrtimer=0xf7061e80 ... irq/20-S-587 1d..32 400273.772118: sched_wakeup: comm= ... target_cpu=0 -0 0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80 What happens is that CPU0 goes idle and invokes sched_clock_idle_sleep_event() which invokes sched_clock_local() and CPU1 runs a remote wakeup for CPU0 at the same time, which invokes sched_remote_clock(). The time jump gets propagated to CPU0 via sched_remote_clock() and stays stale on both cores for ~4 seconds. There are only two other possibilities, which could cause a stale sched clock: 1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic wrong value. 2) sched_clock() which reads the TSC returns a sporadic wrong value. #1 can be excluded because sched_clock would continue to increase for one jiffy and then go stale. #2 can be excluded because it would not make the clock jump forward. It would just result in a stale sched_clock for one jiffy. After quite some brain twisting and finding the same pattern on other traces, sched_clock_remote() remained the only place which could cause such a problem and as explained above it's indeed racy on 32bit systems. So while on 64bit systems the readout is atomic, we need to verify the remote readout on 32bit machines. We need to protect the local->clock readout in sched_clock_remote() on 32bit as well because an NMI could hit between the low and the high readout, call sched_clock_local() and modify local->clock. Thanks to Siegfried Wulsch for bearing with my debug requests and going through the tedious tasks of running a bunch of reproducer systems to generate the debug information which let me decode the issue. Reported-by: Siegfried Wulsch Acked-by: Peter Zijlstra Cc: Steven Rostedt Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman --- kernel/sched/clock.c | 26 ++ 1 file changed, 26 insertions(+) --- a/kernel/sched/clock.c +++ b/kernel/sched/clock.c @@ -176,10 +176,36 @@ static u64 sched_clock_remote(struct sch u64 this_clock, remote_clock; u64 *ptr, old_val, val; +#if BITS_PER_LONG != 64 +again: + /* +* Careful here: The local and the remote clock values need to +* be read out atomic as we need to compare the values and +* then update either the local or the remote side. So the +* cmpxchg64 below only protects one readout. +* +* We must reread via sched_clock_local() in the retry case on +* 32bit as an NMI could use sched_clock_local() via the +* tracer and hit between the readout of +* the low32bit and the high 32bit portion. +*/ + this_clock = sched_clock_local(my_scd); + /* +* We must enforce atomic readout on 32bit, otherwise the +* update on the remote cpu can hit inbetween
[ 05/17] drm/i915: Use the correct size of the GTT for placing the per-process entries
3.4-stable review patch. If anyone has any objections, please let me know. -- From: Chris Wilson commit 9a0f938bde74bf9e50bd75c8de9e38c1787398cd upstream. The current layout is to place the per-process tables at the end of the GTT. However, this is currently using a hardcoded maximum size for the GTT and not taking in account limitations imposed by the BIOS. Use the value for the total number of entries allocated in the table as provided by the configuration registers. Reported-by: Matthew Garrett Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: Ben Widawsky Cc: Matthew Garret Signed-off-by: Daniel Vetter Cc: Jonathan Nieder Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/i915/i915_gem_gtt.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -72,7 +72,7 @@ int i915_gem_init_aliasing_ppgtt(struct /* ppgtt PDEs reside in the global gtt pagetable, which has 512*1024 * entries. For aliasing ppgtt support we just steal them at the end for * now. */ - first_pd_entry_in_global_pt = 512*1024 - I915_PPGTT_PD_ENTRIES; + first_pd_entry_in_global_pt = dev_priv->mm.gtt->gtt_total_entries - I915_PPGTT_PD_ENTRIES; ppgtt = kzalloc(sizeof(*ppgtt), GFP_KERNEL); if (!ppgtt) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 14/17] x86, mm: Patch out arch_flush_lazy_mmu_mode() when running on bare metal
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Boris Ostrovsky
commit 511ba86e1d386f671084b5d0e6f110bb30b8eeb2 upstream.
Invoking arch_flush_lazy_mmu_mode() results in calls to
preempt_enable()/disable() which may have performance impact.
Since lazy MMU is not used on bare metal we can patch away
arch_flush_lazy_mmu_mode() so that it is never called in such
environment.
[ hpa: the previous patch "Fix vmalloc_fault oops during lazy MMU
updates" may cause a minor performance regression on
bare metal. This patch resolves that performance regression. It is
somewhat unclear to me if this is a good -stable candidate. ]
Signed-off-by: Boris Ostrovsky
Link:
http://lkml.kernel.org/r/1364045796-10720-2-git-send-email-konrad.w...@oracle.com
Tested-by: Josh Boyer
Tested-by: Konrad Rzeszutek Wilk
Acked-by: Borislav Petkov
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/paravirt.h |5 -
arch/x86/include/asm/paravirt_types.h |2 ++
arch/x86/kernel/paravirt.c| 25 +
arch/x86/lguest/boot.c|1 +
arch/x86/xen/mmu.c|1 +
5 files changed, 21 insertions(+), 13 deletions(-)
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -741,7 +741,10 @@ static inline void arch_leave_lazy_mmu_m
PVOP_VCALL0(pv_mmu_ops.lazy_mode.leave);
}
-void arch_flush_lazy_mmu_mode(void);
+static inline void arch_flush_lazy_mmu_mode(void)
+{
+ PVOP_VCALL0(pv_mmu_ops.lazy_mode.flush);
+}
static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
phys_addr_t phys, pgprot_t flags)
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -91,6 +91,7 @@ struct pv_lazy_ops {
/* Set deferred update mode, used for batching operations. */
void (*enter)(void);
void (*leave)(void);
+ void (*flush)(void);
};
struct pv_time_ops {
@@ -680,6 +681,7 @@ void paravirt_end_context_switch(struct
void paravirt_enter_lazy_mmu(void);
void paravirt_leave_lazy_mmu(void);
+void paravirt_flush_lazy_mmu(void);
void _paravirt_nop(void);
u32 _paravirt_ident_32(u32);
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -263,6 +263,18 @@ void paravirt_leave_lazy_mmu(void)
leave_lazy(PARAVIRT_LAZY_MMU);
}
+void paravirt_flush_lazy_mmu(void)
+{
+ preempt_disable();
+
+ if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
+ arch_leave_lazy_mmu_mode();
+ arch_enter_lazy_mmu_mode();
+ }
+
+ preempt_enable();
+}
+
void paravirt_start_context_switch(struct task_struct *prev)
{
BUG_ON(preemptible());
@@ -292,18 +304,6 @@ enum paravirt_lazy_mode paravirt_get_laz
return percpu_read(paravirt_lazy_mode);
}
-void arch_flush_lazy_mmu_mode(void)
-{
- preempt_disable();
-
- if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
- arch_leave_lazy_mmu_mode();
- arch_enter_lazy_mmu_mode();
- }
-
- preempt_enable();
-}
-
struct pv_info pv_info = {
.name = "bare hardware",
.paravirt_enabled = 0,
@@ -477,6 +477,7 @@ struct pv_mmu_ops pv_mmu_ops = {
.lazy_mode = {
.enter = paravirt_nop,
.leave = paravirt_nop,
+ .flush = paravirt_nop,
},
.set_fixmap = native_set_fixmap,
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -1333,6 +1333,7 @@ __init void lguest_init(void)
pv_mmu_ops.read_cr3 = lguest_read_cr3;
pv_mmu_ops.lazy_mode.enter = paravirt_enter_lazy_mmu;
pv_mmu_ops.lazy_mode.leave = lguest_leave_lazy_mmu_mode;
+ pv_mmu_ops.lazy_mode.flush = paravirt_flush_lazy_mmu;
pv_mmu_ops.pte_update = lguest_pte_update;
pv_mmu_ops.pte_update_defer = lguest_pte_update;
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2076,6 +2076,7 @@ static const struct pv_mmu_ops xen_mmu_o
.lazy_mode = {
.enter = paravirt_enter_lazy_mmu,
.leave = xen_leave_lazy_mmu,
+ .flush = paravirt_flush_lazy_mmu,
},
.set_fixmap = xen_set_fixmap,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 16/17] kobject: fix kset_find_obj() race with concurrent last kobject_put()
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit a49b7e82cab0f9b41f483359be83f44fbb6b4979 upstream.
Anatol Pomozov identified a race condition that hits module unloading
and re-loading. To quote Anatol:
"This is a race codition that exists between kset_find_obj() and
kobject_put(). kset_find_obj() might return kobject that has refcount
equal to 0 if this kobject is freeing by kobject_put() in other
thread.
Here is timeline for the crash in case if kset_find_obj() searches for
an object tht nobody holds and other thread is doing kobject_put() on
the same kobject:
THREAD A (calls kset_find_obj()) THREAD B (calls kobject_put())
splin_lock()
atomic_dec_return(kobj->kref), counter
gets zero here
... starts kobject cleanup
spin_lock() // WAIT thread A in
kobj_kset_leave()
iterate over kset->list
atomic_inc(kobj->kref) (counter becomes 1)
spin_unlock()
spin_lock() // taken
// it does not know that thread A
increased counter so it
remove obj from list
spin_unlock()
vfree(module) // frees module object
with containing kobj
// kobj points to freed memory area!!
kobject_put(kobj) // OOPS
The race above happens because module.c tries to use kset_find_obj()
when somebody unloads module. The module.c code was introduced in
commit 6494a93d55fa"
Anatol supplied a patch specific for module.c that worked around the
problem by simply not using kset_find_obj() at all, but rather than make
a local band-aid, this just fixes kset_find_obj() to be thread-safe
using the proper model of refusing the get a new reference if the
refcount has already dropped to zero.
See examples of this proper refcount handling not only in the kref
documentation, but in various other equivalent uses of this pattern by
grepping for atomic_inc_not_zero().
[ Side note: the module race does indicate that module loading and
unloading is not properly serialized wrt sysfs information using the
module mutex. That may require further thought, but this is the
correct fix at the kobject layer regardless. ]
Reported-analyzed-and-tested-by: Anatol Pomozov
Cc: Al Viro
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
lib/kobject.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -531,6 +531,13 @@ struct kobject *kobject_get(struct kobje
return kobj;
}
+static struct kobject *kobject_get_unless_zero(struct kobject *kobj)
+{
+ if (!kref_get_unless_zero(&kobj->kref))
+ kobj = NULL;
+ return kobj;
+}
+
/*
* kobject_cleanup - free kobject resources.
* @kobj: object to cleanup
@@ -753,7 +760,7 @@ struct kobject *kset_find_obj(struct kse
list_for_each_entry(k, &kset->list, entry) {
if (kobject_name(k) && !strcmp(kobject_name(k), name)) {
- ret = kobject_get(k);
+ ret = kobject_get_unless_zero(k);
break;
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 17/17] r8169: fix auto speed down issue
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Hayes Wang
commit e2409d83434d77874b461b78af6a19cd6e6a1280 upstream.
It would cause no link after suspending or shutdowning when the
nic changes the speed to 10M and connects to a link partner which
forces the speed to 100M.
Check the link partner ability to determine which speed to set.
Signed-off-by: Hayes Wang
Acked-by: Francois Romieu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/realtek/r8169.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3483,6 +3483,30 @@ static void __devinit rtl_init_mdio_ops(
}
}
+static void rtl_speed_down(struct rtl8169_private *tp)
+{
+ u32 adv;
+ int lpa;
+
+ rtl_writephy(tp, 0x1f, 0x);
+ lpa = rtl_readphy(tp, MII_LPA);
+
+ if (lpa & (LPA_10HALF | LPA_10FULL))
+ adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full;
+ else if (lpa & (LPA_100HALF | LPA_100FULL))
+ adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
+ ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full;
+ else
+ adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
+ ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full |
+ (tp->mii.supports_gmii ?
+ ADVERTISED_1000baseT_Half |
+ ADVERTISED_1000baseT_Full : 0);
+
+ rtl8169_set_speed(tp->dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL,
+ adv);
+}
+
static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -3508,9 +3532,7 @@ static bool rtl_wol_pll_power_down(struc
if (!(__rtl8169_get_wol(tp) & WAKE_ANY))
return false;
- rtl_writephy(tp, 0x1f, 0x);
- rtl_writephy(tp, MII_BMCR, 0x);
-
+ rtl_speed_down(tp);
rtl_wol_suspend_quirk(tp);
return true;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 15/17] mtdchar: fix offset overflow detection
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit 9c603e53d380459fb62fec7cd085acb0b74ac18f upstream.
Sasha Levin has been running trinity in a KVM tools guest, and was able
to trigger the BUG_ON() at arch/x86/mm/pat.c:279 (verifying the range of
the memory type). The call trace showed that it was mtdchar_mmap() that
created an invalid remap_pfn_range().
The problem is that mtdchar_mmap() does various really odd and subtle
things with the vma page offset etc, and uses the wrong types (and the
wrong overflow) detection for it.
For example, the page offset may well be 32-bit on a 32-bit
architecture, but after shifting it up by PAGE_SHIFT, we need to use a
potentially 64-bit resource_size_t to correctly hold the full value.
Also, we need to check that the vma length plus offset doesn't overflow
before we check that it is smaller than the length of the mtdmap region.
This fixes things up and tries to make the code a bit easier to read.
Reported-and-tested-by: Sasha Levin
Acked-by: Suresh Siddha
Acked-by: Artem Bityutskiy
Cc: David Woodhouse
Cc: linux-...@lists.infradead.org
Signed-off-by: Linus Torvalds
Cc: Ben Hutchings
Cc: Brad Spengler
Signed-off-by: Greg Kroah-Hartman
---
drivers/mtd/mtdchar.c | 48 ++--
1 file changed, 42 insertions(+), 6 deletions(-)
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -1123,6 +1123,33 @@ static unsigned long mtdchar_get_unmappe
}
#endif
+static inline unsigned long get_vm_size(struct vm_area_struct *vma)
+{
+ return vma->vm_end - vma->vm_start;
+}
+
+static inline resource_size_t get_vm_offset(struct vm_area_struct *vma)
+{
+ return (resource_size_t) vma->vm_pgoff << PAGE_SHIFT;
+}
+
+/*
+ * Set a new vm offset.
+ *
+ * Verify that the incoming offset really works as a page offset,
+ * and that the offset and size fit in a resource_size_t.
+ */
+static inline int set_vm_offset(struct vm_area_struct *vma, resource_size_t
off)
+{
+ pgoff_t pgoff = off >> PAGE_SHIFT;
+ if (off != (resource_size_t) pgoff << PAGE_SHIFT)
+ return -EINVAL;
+ if (off + get_vm_size(vma) - 1 < off)
+ return -EINVAL;
+ vma->vm_pgoff = pgoff;
+ return 0;
+}
+
/*
* set up a mapping for shared memory segments
*/
@@ -1132,20 +1159,29 @@ static int mtdchar_mmap(struct file *fil
struct mtd_file_info *mfi = file->private_data;
struct mtd_info *mtd = mfi->mtd;
struct map_info *map = mtd->priv;
- unsigned long start;
- unsigned long off;
- u32 len;
+ resource_size_t start, off;
+ unsigned long len, vma_len;
if (mtd->type == MTD_RAM || mtd->type == MTD_ROM) {
- off = vma->vm_pgoff << PAGE_SHIFT;
+ off = get_vm_offset(vma);
start = map->phys;
len = PAGE_ALIGN((start & ~PAGE_MASK) + map->size);
start &= PAGE_MASK;
- if ((vma->vm_end - vma->vm_start + off) > len)
+ vma_len = get_vm_size(vma);
+
+ /* Overflow in off+len? */
+ if (vma_len + off < off)
+ return -EINVAL;
+ /* Does it fit in the mapping? */
+ if (vma_len + off > len)
return -EINVAL;
off += start;
- vma->vm_pgoff = off >> PAGE_SHIFT;
+ /* Did that overflow? */
+ if (off < start)
+ return -EINVAL;
+ if (set_vm_offset(vma, off) < 0)
+ return -EINVAL;
vma->vm_flags |= VM_IO | VM_RESERVED;
#ifdef pgprot_noncached
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 13/17] x86, mm, paravirt: Fix vmalloc_fault oops during lazy MMU updates
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Samu Kallio
commit 1160c2779b826c6f5c08e5cc542de58fd1f667d5 upstream.
In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
when lazy MMU updates are enabled, because set_pgd effects are being
deferred.
One instance of this problem is during process mm cleanup with memory
cgroups enabled. The chain of events is as follows:
- zap_pte_range enables lazy MMU updates
- zap_pte_range eventually calls mem_cgroup_charge_statistics,
which accesses the vmalloc'd mem_cgroup per-cpu stat area
- vmalloc_fault is triggered which tries to sync the corresponding
PGD entry with set_pgd, but the update is deferred
- vmalloc_fault oopses due to a mismatch in the PUD entries
The OOPs usually looks as so:
[ cut here ]
kernel BUG at arch/x86/mm/fault.c:396!
invalid opcode: [#1] SMP
.. snip ..
CPU 1
Pid: 10866, comm: httpd Not tainted 3.6.10-4.fc18.x86_64 #1
RIP: e030:[] [] vmalloc_fault+0x11f/0x208
.. snip ..
Call Trace:
[] do_page_fault+0x399/0x4b0
[] ? xen_mc_extend_args+0xec/0x110
[] page_fault+0x25/0x30
[] ? mem_cgroup_charge_statistics.isra.13+0x13/0x50
[] __mem_cgroup_uncharge_common+0xd8/0x350
[] mem_cgroup_uncharge_page+0x57/0x60
[] page_remove_rmap+0xe0/0x150
[] ? vm_normal_page+0x1a/0x80
[] unmap_single_vma+0x531/0x870
[] unmap_vmas+0x52/0xa0
[] ? pte_mfn_to_pfn+0x72/0x100
[] exit_mmap+0x98/0x170
[] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
[] mmput+0x83/0xf0
[] exit_mm+0x104/0x130
[] do_exit+0x15a/0x8c0
[] do_group_exit+0x3f/0xa0
[] sys_exit_group+0x17/0x20
[] system_call_fastpath+0x16/0x1b
Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
changes visible to the consistency checks.
RedHat-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=914737
Tested-by: Josh Boyer
Reported-and-Tested-by: Krishna Raman
Signed-off-by: Samu Kallio
Link:
http://lkml.kernel.org/r/1364045796-10720-1-git-send-email-konrad.w...@oracle.com
Tested-by: Konrad Rzeszutek Wilk
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/mm/fault.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -377,10 +377,12 @@ static noinline __kprobes int vmalloc_fa
if (pgd_none(*pgd_ref))
return -1;
- if (pgd_none(*pgd))
+ if (pgd_none(*pgd)) {
set_pgd(pgd, *pgd_ref);
- else
+ arch_flush_lazy_mmu_mode();
+ } else {
BUG_ON(pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_ref));
+ }
/*
* Below here mismatches are bugs because these lower tables
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 10/17] kref: Implement kref_get_unless_zero v3
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellstrom
commit 4b20db3de8dab005b07c74161cb041db8c5ff3a7 upstream.
This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock around kref_put + remove from lookup
structure. Furthermore, RCU implementations become extremely tricky.
With a lookup followed by a kref_get_unless_zero *with return value check*
locking in the kref_put path can be deferred to the actual removal from
the lookup structure and RCU lookups become trivial.
v2: Formatting fixes.
v3: Invert the return value.
Signed-off-by: Thomas Hellstrom
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman
---
include/linux/kref.h | 21 +
1 file changed, 21 insertions(+)
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -93,4 +93,25 @@ static inline int kref_put(struct kref *
{
return kref_sub(kref, 1, release);
}
+
+/**
+ * kref_get_unless_zero - Increment refcount for object unless it is zero.
+ * @kref: object.
+ *
+ * Return non-zero if the increment succeeded. Otherwise return 0.
+ *
+ * This function is intended to simplify locking around refcounting for
+ * objects that can be looked up from a lookup structure, and which are
+ * removed from that lookup structure in the object destructor.
+ * Operations on such objects require at least a read lock around
+ * lookup + kref_get, and a write lock around kref_put + remove from lookup
+ * structure. Furthermore, RCU implementations become extremely tricky.
+ * With a lookup followed by a kref_get_unless_zero *with return value check*
+ * locking in the kref_put path can be deferred to the actual removal from
+ * the lookup structure and RCU lookups become trivial.
+ */
+static inline int __must_check kref_get_unless_zero(struct kref *kref)
+{
+ return atomic_add_unless(&kref->refcount, 1, 0);
+}
#endif /* _KREF_H_ */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 03/17] tracing: Fix double free when function profile init failed
3.4-stable review patch. If anyone has any objections, please let me know. -- From: Namhyung Kim commit 83e03b3fe4daffdebbb42151d5410d730ae50bd1 upstream. On the failure path, stat->start and stat->pages will refer same page. So it'll attempt to free the same page again and get kernel panic. Link: http://lkml.kernel.org/r/1364820385-32027-1-git-send-email-namhy...@kernel.org Signed-off-by: Namhyung Kim Cc: Frederic Weisbecker Cc: Namhyung Kim Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman --- kernel/trace/ftrace.c |1 - 1 file changed, 1 deletion(-) --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -642,7 +642,6 @@ int ftrace_profile_pages_init(struct ftr free_page(tmp); } - free_page((unsigned long)stat->pages); stat->pages = NULL; stat->start = NULL; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 04/17] PM / reboot: call syscore_shutdown() after disable_nonboot_cpus()
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Huacai Chen
commit 6f389a8f1dd22a24f3d9afc2812b30d639e94625 upstream.
As commit 40dc166c (PM / Core: Introduce struct syscore_ops for core
subsystems PM) say, syscore_ops operations should be carried with one
CPU on-line and interrupts disabled. However, after commit f96972f2d
(kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()),
syscore_shutdown() is called before disable_nonboot_cpus(), so break
the rules. We have a MIPS machine with a 8259A PIC, and there is an
external timer (HPET) linked at 8259A. Since 8259A has been shutdown
too early (by syscore_shutdown()), disable_nonboot_cpus() runs without
timer interrupt, so it hangs and reboot fails. This patch call
syscore_shutdown() a little later (after disable_nonboot_cpus()) to
avoid reboot failure, this is the same way as poweroff does.
For consistency, add disable_nonboot_cpus() to kernel_halt().
Signed-off-by: Huacai Chen
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
---
kernel/sys.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -320,7 +320,6 @@ void kernel_restart_prepare(char *cmd)
system_state = SYSTEM_RESTART;
usermodehelper_disable();
device_shutdown();
- syscore_shutdown();
}
/**
@@ -366,6 +365,7 @@ void kernel_restart(char *cmd)
{
kernel_restart_prepare(cmd);
disable_nonboot_cpus();
+ syscore_shutdown();
if (!cmd)
printk(KERN_EMERG "Restarting system.\n");
else
@@ -391,6 +391,7 @@ static void kernel_shutdown_prepare(enum
void kernel_halt(void)
{
kernel_shutdown_prepare(SYSTEM_HALT);
+ disable_nonboot_cpus();
syscore_shutdown();
printk(KERN_EMERG "System halted.\n");
kmsg_dump(KMSG_DUMP_HALT);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 06/17] SCSI: libsas: fix handling vacant phy in sas_set_ex_phy()
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Lukasz Dorau
commit d4a2618fa77b5e58ec15342972bd3505a1c3f551 upstream.
If a result of the SMP discover function is PHY VACANT,
the content of discover response structure (dr) is not valid.
It sometimes happens that dr->attached_sas_addr can contain
even SAS address of other phy. In such case an invalid phy
is created, what causes NULL pointer dereference during
destruction of expander's phys.
So if a result of SMP function is PHY VACANT, the content of discover
response structure (dr) must not be copied to phy structure.
This patch fixes the following bug:
BUG: unable to handle kernel NULL pointer dereference at 0030
IP: [] sysfs_find_dirent+0x12/0x90
Call Trace:
[] sysfs_get_dirent+0x35/0x80
[] sysfs_unmerge_group+0x1e/0xb0
[] dpm_sysfs_remove+0x24/0x90
[] device_del+0x44/0x1d0
[] sas_rphy_delete+0x9/0x20 [scsi_transport_sas]
[] sas_destruct_devices+0xe6/0x110 [libsas]
[] process_one_work+0x16c/0x350
[] worker_thread+0x17a/0x410
[] kthread+0x96/0xa0
[] kernel_thread_helper+0x4/0x10
Signed-off-by: Lukasz Dorau
Signed-off-by: Pawel Baldysiak
Reviewed-by: Maciej Patelczyk
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/libsas/sas_expander.c | 12
1 file changed, 12 insertions(+)
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -235,6 +235,17 @@ static void sas_set_ex_phy(struct domain
linkrate = phy->linkrate;
memcpy(sas_addr, phy->attached_sas_addr, SAS_ADDR_SIZE);
+ /* Handle vacant phy - rest of dr data is not valid so skip it */
+ if (phy->phy_state == PHY_VACANT) {
+ memset(phy->attached_sas_addr, 0, SAS_ADDR_SIZE);
+ phy->attached_dev_type = NO_DEVICE;
+ if (!test_bit(SAS_HA_ATA_EH_ACTIVE, &ha->state)) {
+ phy->phy_id = phy_id;
+ goto skip;
+ } else
+ goto out;
+ }
+
phy->attached_dev_type = to_dev_type(dr);
if (test_bit(SAS_HA_ATA_EH_ACTIVE, &ha->state))
goto out;
@@ -272,6 +283,7 @@ static void sas_set_ex_phy(struct domain
phy->phy->maximum_linkrate = dr->pmax_linkrate;
phy->phy->negotiated_linkrate = phy->linkrate;
+ skip:
if (new_phy)
if (sas_phy_add(phy->phy)) {
sas_phy_free(phy->phy);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 09/17] vfs: Revert spurious fix to spinning prevention in prune_icache_sb
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Suleiman Souhlal
commit 5b55d708335a9e3e4f61f2dadf7511502205ccd1 upstream.
Revert commit 62a3ddef6181 ("vfs: fix spinning prevention in prune_icache_sb").
This commit doesn't look right: since we are looking at the tail of the
list (sb->s_inode_lru.prev) if we want to skip an inode, we should put
it back at the head of the list instead of the tail, otherwise we will
keep spinning on it.
Discovered when investigating why prune_icache_sb came top in perf
reports of a swapping load.
Signed-off-by: Suleiman Souhlal
Signed-off-by: Hugh Dickins
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
fs/inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -705,7 +705,7 @@ void prune_icache_sb(struct super_block
* inode to the back of the list so we don't spin on it.
*/
if (!spin_trylock(&inode->i_lock)) {
- list_move_tail(&inode->i_lru, &sb->s_inode_lru);
+ list_move(&inode->i_lru, &sb->s_inode_lru);
continue;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 11/17] udl: handle EDID failure properly.
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Airlie
commit 1baee58638fc58248625255f5c5fcdb987f11b1f upstream.
Don't oops seems proper.
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/udl/udl_connector.c |4
1 file changed, 4 insertions(+)
--- a/drivers/gpu/drm/udl/udl_connector.c
+++ b/drivers/gpu/drm/udl/udl_connector.c
@@ -61,6 +61,10 @@ static int udl_get_modes(struct drm_conn
int ret;
edid = (struct edid *)udl_get_edid(udl);
+ if (!edid) {
+ drm_mode_connector_update_edid_property(connector, NULL);
+ return 0;
+ }
connector->display_info.raw_edid = (char *)edid;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 08/17] target: Fix incorrect fallthrough of ALUA Standby/Offline/Transition CDBs
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Bellinger
commit 30f359a6f9da65a66de8cadf959f0f4a0d498bba upstream.
This patch fixes a bug where a handful of informational / control CDBs
that should be allowed during ALUA access state Standby/Offline/Transition
where incorrectly returning CHECK_CONDITION + ASCQ_04H_ALUA_TG_PT_*.
This includes INQUIRY + REPORT_LUNS, which would end up preventing LUN
registration when LUN scanning occured during these ALUA access states.
Signed-off-by: Nicholas Bellinger
Cc: Hannes Reinecke
Signed-off-by: Greg Kroah-Hartman
---
drivers/target/target_core_alua.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/target/target_core_alua.c
+++ b/drivers/target/target_core_alua.c
@@ -392,6 +392,7 @@ static inline int core_alua_state_standb
case REPORT_LUNS:
case RECEIVE_DIAGNOSTIC:
case SEND_DIAGNOSTIC:
+ return 0;
case MAINTENANCE_IN:
switch (cdb[1]) {
case MI_REPORT_TARGET_PGS:
@@ -434,6 +435,7 @@ static inline int core_alua_state_unavai
switch (cdb[0]) {
case INQUIRY:
case REPORT_LUNS:
+ return 0;
case MAINTENANCE_IN:
switch (cdb[1]) {
case MI_REPORT_TARGET_PGS:
@@ -474,6 +476,7 @@ static inline int core_alua_state_transi
switch (cdb[0]) {
case INQUIRY:
case REPORT_LUNS:
+ return 0;
case MAINTENANCE_IN:
switch (cdb[1]) {
case MI_REPORT_TARGET_PGS:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 07/17] cifs: Allow passwords which begin with a delimitor
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Sachin Prabhu
commit c369c9a4a7c82d33329d869cbaf93304cc7a0c40 upstream.
Fixes a regression in cifs_parse_mount_options where a password
which begins with a delimitor is parsed incorrectly as being a blank
password.
Signed-off-by: Sachin Prabhu
Acked-by: Jeff Layton
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/connect.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -1576,14 +1576,24 @@ cifs_parse_mount_options(const char *mou
}
break;
case Opt_blank_pass:
- vol->password = NULL;
- break;
- case Opt_pass:
/* passwords have to be handled differently
* to allow the character used for deliminator
* to be passed within them
*/
+ /*
+* Check if this is a case where the password
+* starts with a delimiter
+*/
+ tmp_end = strchr(data, '=');
+ tmp_end++;
+ if (!(tmp_end < end && tmp_end[1] == delim)) {
+ /* No it is not. Set the password to NULL */
+ vol->password = NULL;
+ break;
+ }
+ /* Yes it is. Drop down to Opt_pass below.*/
+ case Opt_pass:
/* Obtain the value string */
value = strchr(data, '=');
value++;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 01/17] ALSA: usb-audio: fix endianness bug in snd_nativeinstruments_*
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Eldad Zack
commit 889d66848b12d891248b03abcb2a42047f8e172a upstream.
The usb_control_msg() function expects __u16 types and performs
the endianness conversions by itself.
However, in three places, a conversion is performed before it is
handed over to usb_control_msg(), which leads to a double conversion
(= no conversion):
* snd_usb_nativeinstruments_boot_quirk()
* snd_nativeinstruments_control_get()
* snd_nativeinstruments_control_put()
Caught by sparse:
sound/usb/mixer_quirks.c:512:38: warning: incorrect type in argument 6
(different base types)
sound/usb/mixer_quirks.c:512:38:expected unsigned short [unsigned]
[usertype] index
sound/usb/mixer_quirks.c:512:38:got restricted __le16 [usertype]
sound/usb/mixer_quirks.c:543:35: warning: incorrect type in argument 5
(different base types)
sound/usb/mixer_quirks.c:543:35:expected unsigned short [unsigned]
[usertype] value
sound/usb/mixer_quirks.c:543:35:got restricted __le16 [usertype]
sound/usb/mixer_quirks.c:543:56: warning: incorrect type in argument 6
(different base types)
sound/usb/mixer_quirks.c:543:56:expected unsigned short [unsigned]
[usertype] index
sound/usb/mixer_quirks.c:543:56:got restricted __le16 [usertype]
sound/usb/quirks.c:502:35: warning: incorrect type in argument 5 (different
base types)
sound/usb/quirks.c:502:35:expected unsigned short [unsigned] [usertype]
value
sound/usb/quirks.c:502:35:got restricted __le16 [usertype]
Signed-off-by: Eldad Zack
Acked-by: Daniel Mack
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/usb/mixer_quirks.c |4 ++--
sound/usb/quirks.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/sound/usb/mixer_quirks.c
+++ b/sound/usb/mixer_quirks.c
@@ -396,7 +396,7 @@ static int snd_nativeinstruments_control
else
ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), bRequest,
USB_TYPE_VENDOR | USB_RECIP_DEVICE |
USB_DIR_IN,
- 0, cpu_to_le16(wIndex),
+ 0, wIndex,
&tmp, sizeof(tmp), 1000);
up_read(&mixer->chip->shutdown_rwsem);
@@ -427,7 +427,7 @@ static int snd_nativeinstruments_control
else
ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), bRequest,
USB_TYPE_VENDOR | USB_RECIP_DEVICE |
USB_DIR_OUT,
- cpu_to_le16(wValue), cpu_to_le16(wIndex),
+ wValue, wIndex,
NULL, 0, 1000);
up_read(&mixer->chip->shutdown_rwsem);
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -486,7 +486,7 @@ static int snd_usb_nativeinstruments_boo
{
int ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
0xaf, USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- cpu_to_le16(1), 0, NULL, 0, 1000);
+ 1, 0, NULL, 0, 1000);
if (ret < 0)
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 02/17] ASoC: wm8903: Fix the bypass to HP/LINEOUT when no DAC or ADC is running
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Alban Bedel
commit f1ca493b0b5e8f42d3b2dc8877860db2983f47b6 upstream.
The Charge Pump needs the DSP clock to work properly, without it the
bypass to HP/LINEOUT is not working properly. This requirement is not
mentioned in the datasheet but has been confirmed by Mark Brown from
Wolfson.
Signed-off-by: Alban Bedel
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
---
sound/soc/codecs/wm8903.c |2 ++
1 file changed, 2 insertions(+)
--- a/sound/soc/codecs/wm8903.c
+++ b/sound/soc/codecs/wm8903.c
@@ -1082,6 +1082,8 @@ static const struct snd_soc_dapm_route w
{ "ROP", NULL, "Right Speaker PGA" },
{ "RON", NULL, "Right Speaker PGA" },
+ { "Charge Pump", NULL, "CLK_DSP" },
+
{ "Left Headphone Output PGA", NULL, "Charge Pump" },
{ "Right Headphone Output PGA", NULL, "Charge Pump" },
{ "Left Line Output PGA", NULL, "Charge Pump" },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] PCI/IA64: fix pci_dev->enable_cnt balance when doing pci hotplug
>> @@ -383,6 +383,7 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root >> *root) >> } >> >> pci_scan_child_bus(pbus); >> + pci_enable_bridges(pbus); >> return pbus; >> >> out3: > > I think that with this patch, if you hot-add a PCI host bridge, you > will call pci_enable_bridges() twice (once in pci_acpi_scan_root() and > again in acpi_pci_root_add()), so there will be an enable_cnt error in > the opposite direction. > > I'd like to see the pci_enable_bridges() calls pushed up into the > generic code because I don't think there's anything arch-specific > about it. Hi Bjorn, Thanks for your review and comments! This is my fault, I forgot we will enable pci bridges when we hot add host bridge. Push pci_enable_bridges() into the generic code is a good idea, so we don't need to consider enabling bridge in pci arch-specific code. In IA64 we don't assign the unassigned resources like other arch. This is also a weak point. I will update this patch and resend soon. Thanks! Yijing. > > . > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] memcg: force use_hierarchy if sane_behavior
On Sun 14-04-13 20:13:36, Serge Hallyn wrote: > Quoting Tejun Heo (t...@kernel.org): > > Turn on use_hierarchy by default if sane_behavior is specified and > > don't create .use_hierarchy file. > > > > It is debatable whether to remove .use_hierarchy file or make it ro as > > the former could make transition easier in certain cases; however, the > > behavior changes which will be gated by sane_behavior are intensive > > including changing basic meaning of certain control knobs in a few > > controllers and I don't really think keeping this piece would make > > things easier in any noticeable way, so let's remove it. > > Hi Tejun, > > this actually reminds me of something that's been on my todo list to > report for some time, but I haven't had time to find the source of the > bug... And maybe it's already been reported... but > > If I do > > cd /sys/fs/cgroup/memory > mkdir b > cd b > echo 1 > memory.use_hierarchy > echo 5000 > memory.limit_in_bytes > cat memory.limit_in_bytes > 8192 > mkdir c > cd c > cat memory.use_hierarchy > 1 > cat memory.limit_in_bytes > 9223372036854775807 > echo $$ > tasks > bash > > > So it seems the hierarchy is being enforced, but not reported in > child limit_in_bytes files. This is an intended behavior. Limits are not propagated to the children because they are enforced anyway (by reclaim). The behavior would be quite inconsistent when the parent limit would be changed later otherwise. We only inherit properties which are enforced hierarchically: use_hierarchy, oom_disable and swappiness. > (Last tested tonight on 3.8.0-17-generic #27-Ubuntu fwiw) > > -serge -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] memcg: force use_hierarchy if sane_behavior
Hello, Serge. On Sun, Apr 14, 2013 at 08:13:36PM -0500, Serge Hallyn wrote: > If I do > > cd /sys/fs/cgroup/memory > mkdir b > cd b > echo 1 > memory.use_hierarchy > echo 5000 > memory.limit_in_bytes > cat memory.limit_in_bytes > 8192 > mkdir c > cd c > cat memory.use_hierarchy > 1 > cat memory.limit_in_bytes > 9223372036854775807 > echo $$ > tasks > bash > > > So it seems the hierarchy is being enforced, but not reported in > child limit_in_bytes files. Hmm if I understand you correctly, it ain't bug. It's supposed to work that way. The parent has certain limits and the child doesn't. The child will operate within the paren't limits but in those limits it isn't restricted. We actually have a controller which does propagate configuration, the device security one, which I don't think is really optimal but it seems to be the easier way to implement hierarchical behavior for that controller. Anyways, if you think about the use cases, the current memcg way makes a lot more sense and is more flexible. e.g. You can express things like A + B shouldn't go above 1000 (whatever the unit is) but A and B in each can go upto 700 when there's room. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 03/27] ASoC: wm5102: Correct lookup of arizona struct in SYSCLK event
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Mark Brown
commit f6f629f8332ea70255f6c60c904270640a21a114 upstream.
Reported-by: Ryo Tsutsui
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
---
sound/soc/codecs/wm5102.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/soc/codecs/wm5102.c
+++ b/sound/soc/codecs/wm5102.c
@@ -576,7 +576,7 @@ static int wm5102_sysclk_ev(struct snd_s
struct snd_kcontrol *kcontrol, int event)
{
struct snd_soc_codec *codec = w->codec;
- struct arizona *arizona = dev_get_drvdata(codec->dev);
+ struct arizona *arizona = dev_get_drvdata(codec->dev->parent);
struct regmap *regmap = codec->control_data;
const struct reg_default *patch = NULL;
int i, patch_size;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 09/27] PM / reboot: call syscore_shutdown() after disable_nonboot_cpus()
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Huacai Chen
commit 6f389a8f1dd22a24f3d9afc2812b30d639e94625 upstream.
As commit 40dc166c (PM / Core: Introduce struct syscore_ops for core
subsystems PM) say, syscore_ops operations should be carried with one
CPU on-line and interrupts disabled. However, after commit f96972f2d
(kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()),
syscore_shutdown() is called before disable_nonboot_cpus(), so break
the rules. We have a MIPS machine with a 8259A PIC, and there is an
external timer (HPET) linked at 8259A. Since 8259A has been shutdown
too early (by syscore_shutdown()), disable_nonboot_cpus() runs without
timer interrupt, so it hangs and reboot fails. This patch call
syscore_shutdown() a little later (after disable_nonboot_cpus()) to
avoid reboot failure, this is the same way as poweroff does.
For consistency, add disable_nonboot_cpus() to kernel_halt().
Signed-off-by: Huacai Chen
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
---
kernel/sys.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -323,7 +323,6 @@ void kernel_restart_prepare(char *cmd)
system_state = SYSTEM_RESTART;
usermodehelper_disable();
device_shutdown();
- syscore_shutdown();
}
/**
@@ -369,6 +368,7 @@ void kernel_restart(char *cmd)
{
kernel_restart_prepare(cmd);
disable_nonboot_cpus();
+ syscore_shutdown();
if (!cmd)
printk(KERN_EMERG "Restarting system.\n");
else
@@ -394,6 +394,7 @@ static void kernel_shutdown_prepare(enum
void kernel_halt(void)
{
kernel_shutdown_prepare(SYSTEM_HALT);
+ disable_nonboot_cpus();
syscore_shutdown();
printk(KERN_EMERG "System halted.\n");
kmsg_dump(KMSG_DUMP_HALT);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 10/27] Revert "brcmsmac: support 4313iPA"
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: "John W. Linville"
commit 54683441a92ebe20c5282465ea6f21e5e74d2974 upstream.
This reverts commit b6fc28a158076ca2764edc9a6d1e1402f56e1c0c.
This commit is reported to cause a regression in the support for some
revisions of 4313 ePA devices.
http://marc.info/?l=linux-wireless&m=136360340200943&w=2
Conflicts:
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
Reported-by: David Herrmann
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c| 375 +--
drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.c | 64 +-
2 files changed, 165 insertions(+), 274 deletions(-)
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
@@ -1137,9 +1137,8 @@ wlc_lcnphy_set_rx_gain_by_distribution(s
gain0_15 = ((biq1 & 0xf) << 12) |
((tia & 0xf) << 8) |
((lna2 & 0x3) << 6) |
- ((lna2 & 0x3) << 4) |
- ((lna1 & 0x3) << 2) |
- ((lna1 & 0x3) << 0);
+ ((lna2 &
+0x3) << 4) | ((lna1 & 0x3) << 2) | ((lna1 & 0x3) << 0);
mod_phy_reg(pi, 0x4b6, (0x << 0), gain0_15 << 0);
mod_phy_reg(pi, 0x4b7, (0xf << 0), gain16_19 << 0);
@@ -1157,8 +1156,6 @@ wlc_lcnphy_set_rx_gain_by_distribution(s
}
mod_phy_reg(pi, 0x44d, (0x1 << 0), (!trsw) << 0);
- mod_phy_reg(pi, 0x4b1, (0x3 << 11), lna1 << 11);
- mod_phy_reg(pi, 0x4e6, (0x3 << 3), lna1 << 3);
}
@@ -1331,43 +1328,6 @@ static u32 wlc_lcnphy_measure_digital_po
return (iq_est.i_pwr + iq_est.q_pwr) / nsamples;
}
-static bool wlc_lcnphy_rx_iq_cal_gain(struct brcms_phy *pi, u16 biq1_gain,
- u16 tia_gain, u16 lna2_gain)
-{
- u32 i_thresh_l, q_thresh_l;
- u32 i_thresh_h, q_thresh_h;
- struct lcnphy_iq_est iq_est_h, iq_est_l;
-
- wlc_lcnphy_set_rx_gain_by_distribution(pi, 0, 0, 0, biq1_gain, tia_gain,
- lna2_gain, 0);
-
- wlc_lcnphy_rx_gain_override_enable(pi, true);
- wlc_lcnphy_start_tx_tone(pi, 2000, (40 >> 1), 0);
- udelay(500);
- write_radio_reg(pi, RADIO_2064_REG112, 0);
- if (!wlc_lcnphy_rx_iq_est(pi, 1024, 32, &iq_est_l))
- return false;
-
- wlc_lcnphy_start_tx_tone(pi, 2000, 40, 0);
- udelay(500);
- write_radio_reg(pi, RADIO_2064_REG112, 0);
- if (!wlc_lcnphy_rx_iq_est(pi, 1024, 32, &iq_est_h))
- return false;
-
- i_thresh_l = (iq_est_l.i_pwr << 1);
- i_thresh_h = (iq_est_l.i_pwr << 2) + iq_est_l.i_pwr;
-
- q_thresh_l = (iq_est_l.q_pwr << 1);
- q_thresh_h = (iq_est_l.q_pwr << 2) + iq_est_l.q_pwr;
- if ((iq_est_h.i_pwr > i_thresh_l) &&
- (iq_est_h.i_pwr < i_thresh_h) &&
- (iq_est_h.q_pwr > q_thresh_l) &&
- (iq_est_h.q_pwr < q_thresh_h))
- return true;
-
- return false;
-}
-
static bool
wlc_lcnphy_rx_iq_cal(struct brcms_phy *pi,
const struct lcnphy_rx_iqcomp *iqcomp,
@@ -1382,8 +1342,8 @@ wlc_lcnphy_rx_iq_cal(struct brcms_phy *p
RFOverrideVal0_old, rfoverride2_old, rfoverride2val_old,
rfoverride3_old, rfoverride3val_old, rfoverride4_old,
rfoverride4val_old, afectrlovr_old, afectrlovrval_old;
- int tia_gain, lna2_gain, biq1_gain;
- bool set_gain;
+ int tia_gain;
+ u32 received_power, rx_pwr_threshold;
u16 old_sslpnCalibClkEnCtrl, old_sslpnRxFeClkEnCtrl;
u16 values_to_save[11];
s16 *ptr;
@@ -1408,134 +1368,126 @@ wlc_lcnphy_rx_iq_cal(struct brcms_phy *p
goto cal_done;
}
- WARN_ON(module != 1);
- tx_pwr_ctrl = wlc_lcnphy_get_tx_pwr_ctrl(pi);
- wlc_lcnphy_set_tx_pwr_ctrl(pi, LCNPHY_TX_PWR_CTRL_OFF);
-
- for (i = 0; i < 11; i++)
- values_to_save[i] =
- read_radio_reg(pi, rxiq_cal_rf_reg[i]);
- Core1TxControl_old = read_phy_reg(pi, 0x631);
-
- or_phy_reg(pi, 0x631, 0x0015);
-
- RFOverride0_old = read_phy_reg(pi, 0x44c);
- RFOverrideVal0_old = read_phy_reg(pi, 0x44d);
- rfoverride2_old = read_phy_reg(pi, 0x4b0);
- rfoverride2val_old = read_phy_reg(pi, 0x4b1);
- rfoverride3_old = read_phy_reg(pi, 0x4f9);
- rfoverride3val_old = read_phy_reg(pi, 0x4fa);
- rfoverride4_old = read_phy_reg(pi, 0x938);
- rfoverride4val_old = read_phy_reg(pi, 0x939);
- afectrlovr_old = read_phy_reg(pi, 0x43b);
- afectrlovrval_old = read_phy_reg(pi, 0x43c);
- old_sslpnCalibClkEnCtrl = read_phy_reg(pi, 0x6da);
- old_sslpnRxFeClkEnCtrl = read_phy_reg(pi, 0x6db);
-
- tx_gain_override_old = wlc_lcnphy_tx_gain_override_enable
[ 01/27] ALSA: usb-audio: fix endianness bug in snd_nativeinstruments_*
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Eldad Zack
commit 889d66848b12d891248b03abcb2a42047f8e172a upstream.
The usb_control_msg() function expects __u16 types and performs
the endianness conversions by itself.
However, in three places, a conversion is performed before it is
handed over to usb_control_msg(), which leads to a double conversion
(= no conversion):
* snd_usb_nativeinstruments_boot_quirk()
* snd_nativeinstruments_control_get()
* snd_nativeinstruments_control_put()
Caught by sparse:
sound/usb/mixer_quirks.c:512:38: warning: incorrect type in argument 6
(different base types)
sound/usb/mixer_quirks.c:512:38:expected unsigned short [unsigned]
[usertype] index
sound/usb/mixer_quirks.c:512:38:got restricted __le16 [usertype]
sound/usb/mixer_quirks.c:543:35: warning: incorrect type in argument 5
(different base types)
sound/usb/mixer_quirks.c:543:35:expected unsigned short [unsigned]
[usertype] value
sound/usb/mixer_quirks.c:543:35:got restricted __le16 [usertype]
sound/usb/mixer_quirks.c:543:56: warning: incorrect type in argument 6
(different base types)
sound/usb/mixer_quirks.c:543:56:expected unsigned short [unsigned]
[usertype] index
sound/usb/mixer_quirks.c:543:56:got restricted __le16 [usertype]
sound/usb/quirks.c:502:35: warning: incorrect type in argument 5 (different
base types)
sound/usb/quirks.c:502:35:expected unsigned short [unsigned] [usertype]
value
sound/usb/quirks.c:502:35:got restricted __le16 [usertype]
Signed-off-by: Eldad Zack
Acked-by: Daniel Mack
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/usb/mixer_quirks.c |4 ++--
sound/usb/quirks.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/sound/usb/mixer_quirks.c
+++ b/sound/usb/mixer_quirks.c
@@ -509,7 +509,7 @@ static int snd_nativeinstruments_control
else
ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), bRequest,
USB_TYPE_VENDOR | USB_RECIP_DEVICE |
USB_DIR_IN,
- 0, cpu_to_le16(wIndex),
+ 0, wIndex,
&tmp, sizeof(tmp), 1000);
up_read(&mixer->chip->shutdown_rwsem);
@@ -540,7 +540,7 @@ static int snd_nativeinstruments_control
else
ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), bRequest,
USB_TYPE_VENDOR | USB_RECIP_DEVICE |
USB_DIR_OUT,
- cpu_to_le16(wValue), cpu_to_le16(wIndex),
+ wValue, wIndex,
NULL, 0, 1000);
up_read(&mixer->chip->shutdown_rwsem);
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -486,7 +486,7 @@ static int snd_usb_nativeinstruments_boo
{
int ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
0xaf, USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- cpu_to_le16(1), 0, NULL, 0, 1000);
+ 1, 0, NULL, 0, 1000);
if (ret < 0)
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 14/27] SCSI: libsas: fix handling vacant phy in sas_set_ex_phy()
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Lukasz Dorau
commit d4a2618fa77b5e58ec15342972bd3505a1c3f551 upstream.
If a result of the SMP discover function is PHY VACANT,
the content of discover response structure (dr) is not valid.
It sometimes happens that dr->attached_sas_addr can contain
even SAS address of other phy. In such case an invalid phy
is created, what causes NULL pointer dereference during
destruction of expander's phys.
So if a result of SMP function is PHY VACANT, the content of discover
response structure (dr) must not be copied to phy structure.
This patch fixes the following bug:
BUG: unable to handle kernel NULL pointer dereference at 0030
IP: [] sysfs_find_dirent+0x12/0x90
Call Trace:
[] sysfs_get_dirent+0x35/0x80
[] sysfs_unmerge_group+0x1e/0xb0
[] dpm_sysfs_remove+0x24/0x90
[] device_del+0x44/0x1d0
[] sas_rphy_delete+0x9/0x20 [scsi_transport_sas]
[] sas_destruct_devices+0xe6/0x110 [libsas]
[] process_one_work+0x16c/0x350
[] worker_thread+0x17a/0x410
[] kthread+0x96/0xa0
[] kernel_thread_helper+0x4/0x10
Signed-off-by: Lukasz Dorau
Signed-off-by: Pawel Baldysiak
Reviewed-by: Maciej Patelczyk
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/libsas/sas_expander.c | 12
1 file changed, 12 insertions(+)
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -235,6 +235,17 @@ static void sas_set_ex_phy(struct domain
linkrate = phy->linkrate;
memcpy(sas_addr, phy->attached_sas_addr, SAS_ADDR_SIZE);
+ /* Handle vacant phy - rest of dr data is not valid so skip it */
+ if (phy->phy_state == PHY_VACANT) {
+ memset(phy->attached_sas_addr, 0, SAS_ADDR_SIZE);
+ phy->attached_dev_type = NO_DEVICE;
+ if (!test_bit(SAS_HA_ATA_EH_ACTIVE, &ha->state)) {
+ phy->phy_id = phy_id;
+ goto skip;
+ } else
+ goto out;
+ }
+
phy->attached_dev_type = to_dev_type(dr);
if (test_bit(SAS_HA_ATA_EH_ACTIVE, &ha->state))
goto out;
@@ -272,6 +283,7 @@ static void sas_set_ex_phy(struct domain
phy->phy->maximum_linkrate = dr->pmax_linkrate;
phy->phy->negotiated_linkrate = phy->linkrate;
+ skip:
if (new_phy)
if (sas_phy_add(phy->phy)) {
sas_phy_free(phy->phy);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 17/27] vfs: Revert spurious fix to spinning prevention in prune_icache_sb
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Suleiman Souhlal
commit 5b55d708335a9e3e4f61f2dadf7511502205ccd1 upstream.
Revert commit 62a3ddef6181 ("vfs: fix spinning prevention in prune_icache_sb").
This commit doesn't look right: since we are looking at the tail of the
list (sb->s_inode_lru.prev) if we want to skip an inode, we should put
it back at the head of the list instead of the tail, otherwise we will
keep spinning on it.
Discovered when investigating why prune_icache_sb came top in perf
reports of a swapping load.
Signed-off-by: Suleiman Souhlal
Signed-off-by: Hugh Dickins
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
fs/inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -725,7 +725,7 @@ void prune_icache_sb(struct super_block
* inode to the back of the list so we don't spin on it.
*/
if (!spin_trylock(&inode->i_lock)) {
- list_move_tail(&inode->i_lru, &sb->s_inode_lru);
+ list_move(&inode->i_lru, &sb->s_inode_lru);
continue;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 25/27] x86, mm, paravirt: Fix vmalloc_fault oops during lazy MMU updates
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Samu Kallio
commit 1160c2779b826c6f5c08e5cc542de58fd1f667d5 upstream.
In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
when lazy MMU updates are enabled, because set_pgd effects are being
deferred.
One instance of this problem is during process mm cleanup with memory
cgroups enabled. The chain of events is as follows:
- zap_pte_range enables lazy MMU updates
- zap_pte_range eventually calls mem_cgroup_charge_statistics,
which accesses the vmalloc'd mem_cgroup per-cpu stat area
- vmalloc_fault is triggered which tries to sync the corresponding
PGD entry with set_pgd, but the update is deferred
- vmalloc_fault oopses due to a mismatch in the PUD entries
The OOPs usually looks as so:
[ cut here ]
kernel BUG at arch/x86/mm/fault.c:396!
invalid opcode: [#1] SMP
.. snip ..
CPU 1
Pid: 10866, comm: httpd Not tainted 3.6.10-4.fc18.x86_64 #1
RIP: e030:[] [] vmalloc_fault+0x11f/0x208
.. snip ..
Call Trace:
[] do_page_fault+0x399/0x4b0
[] ? xen_mc_extend_args+0xec/0x110
[] page_fault+0x25/0x30
[] ? mem_cgroup_charge_statistics.isra.13+0x13/0x50
[] __mem_cgroup_uncharge_common+0xd8/0x350
[] mem_cgroup_uncharge_page+0x57/0x60
[] page_remove_rmap+0xe0/0x150
[] ? vm_normal_page+0x1a/0x80
[] unmap_single_vma+0x531/0x870
[] unmap_vmas+0x52/0xa0
[] ? pte_mfn_to_pfn+0x72/0x100
[] exit_mmap+0x98/0x170
[] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
[] mmput+0x83/0xf0
[] exit_mm+0x104/0x130
[] do_exit+0x15a/0x8c0
[] do_group_exit+0x3f/0xa0
[] sys_exit_group+0x17/0x20
[] system_call_fastpath+0x16/0x1b
Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
changes visible to the consistency checks.
RedHat-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=914737
Tested-by: Josh Boyer
Reported-and-Tested-by: Krishna Raman
Signed-off-by: Samu Kallio
Link:
http://lkml.kernel.org/r/1364045796-10720-1-git-send-email-konrad.w...@oracle.com
Tested-by: Konrad Rzeszutek Wilk
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/mm/fault.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -378,10 +378,12 @@ static noinline __kprobes int vmalloc_fa
if (pgd_none(*pgd_ref))
return -1;
- if (pgd_none(*pgd))
+ if (pgd_none(*pgd)) {
set_pgd(pgd, *pgd_ref);
- else
+ arch_flush_lazy_mmu_mode();
+ } else {
BUG_ON(pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_ref));
+ }
/*
* Below here mismatches are bugs because these lower tables
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 23/27] ftrace: Move ftrace_filter_lseek out of CONFIG_DYNAMIC_FTRACE section
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: "Steven Rostedt (Red Hat)"
commit 7f49ef69db6bbf756c0abca7e9b65b32e999eec8 upstream.
As ftrace_filter_lseek is now used with ftrace_pid_fops, it needs to
be moved out of the #ifdef CONFIG_DYNAMIC_FTRACE section as the
ftrace_pid_fops is defined when DYNAMIC_FTRACE is not.
Signed-off-by: Steven Rostedt
Cc: Namhyung Kim
Signed-off-by: Greg Kroah-Hartman
---
include/linux/ftrace.h |3 ++-
kernel/trace/ftrace.c | 28 ++--
2 files changed, 16 insertions(+), 15 deletions(-)
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -394,7 +394,6 @@ ssize_t ftrace_filter_write(struct file
size_t cnt, loff_t *ppos);
ssize_t ftrace_notrace_write(struct file *file, const char __user *ubuf,
size_t cnt, loff_t *ppos);
-loff_t ftrace_filter_lseek(struct file *file, loff_t offset, int whence);
int ftrace_regex_release(struct inode *inode, struct file *file);
void __init
@@ -567,6 +566,8 @@ static inline int
ftrace_regex_release(struct inode *inode, struct file *file) { return -ENODEV;
}
#endif /* CONFIG_DYNAMIC_FTRACE */
+loff_t ftrace_filter_lseek(struct file *file, loff_t offset, int whence);
+
/* totally disable ftrace - can not re-enable after this */
void ftrace_kill(void);
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -1027,6 +1027,19 @@ static __init void ftrace_profile_debugf
static struct pid * const ftrace_swapper_pid = &init_struct_pid;
+loff_t
+ftrace_filter_lseek(struct file *file, loff_t offset, int whence)
+{
+ loff_t ret;
+
+ if (file->f_mode & FMODE_READ)
+ ret = seq_lseek(file, offset, whence);
+ else
+ file->f_pos = ret = 1;
+
+ return ret;
+}
+
#ifdef CONFIG_DYNAMIC_FTRACE
#ifndef CONFIG_FTRACE_MCOUNT_RECORD
@@ -2589,7 +2602,7 @@ static void ftrace_filter_reset(struct f
* routine, you can use ftrace_filter_write() for the write
* routine if @flag has FTRACE_ITER_FILTER set, or
* ftrace_notrace_write() if @flag has FTRACE_ITER_NOTRACE set.
- * ftrace_regex_lseek() should be used as the lseek routine, and
+ * ftrace_filter_lseek() should be used as the lseek routine, and
* release must call ftrace_regex_release().
*/
int
@@ -2673,19 +2686,6 @@ ftrace_notrace_open(struct inode *inode,
inode, file);
}
-loff_t
-ftrace_filter_lseek(struct file *file, loff_t offset, int whence)
-{
- loff_t ret;
-
- if (file->f_mode & FMODE_READ)
- ret = seq_lseek(file, offset, whence);
- else
- file->f_pos = ret = 1;
-
- return ret;
-}
-
static int ftrace_match(char *str, char *regex, int len, int type)
{
int matched = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 21/27] tracing: Fix possible NULL pointer dereferences
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Namhyung Kim
commit 6a76f8c0ab19f215af2a3442870eeb5f0e81998d upstream.
Currently set_ftrace_pid and set_graph_function files use seq_lseek
for their fops. However seq_open() is called only for FMODE_READ in
the fops->open() so that if an user tries to seek one of those file
when she open it for writing, it sees NULL seq_file and then panic.
It can be easily reproduced with following command:
$ cd /sys/kernel/debug/tracing
$ echo 1234 | sudo tee -a set_ftrace_pid
In this example, GNU coreutils' tee opens the file with fopen(, "a")
and then the fopen() internally calls lseek().
Link:
http://lkml.kernel.org/r/1365663302-2170-1-git-send-email-namhy...@kernel.org
Signed-off-by: Namhyung Kim
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: sta...@vger.kernel.org
Signed-off-by: Steven Rostedt
Signed-off-by: Greg Kroah-Hartman
---
include/linux/ftrace.h |2 +-
kernel/trace/ftrace.c | 10 +-
kernel/trace/trace_stack.c |2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -394,7 +394,7 @@ ssize_t ftrace_filter_write(struct file
size_t cnt, loff_t *ppos);
ssize_t ftrace_notrace_write(struct file *file, const char __user *ubuf,
size_t cnt, loff_t *ppos);
-loff_t ftrace_regex_lseek(struct file *file, loff_t offset, int whence);
+loff_t ftrace_filter_lseek(struct file *file, loff_t offset, int whence);
int ftrace_regex_release(struct inode *inode, struct file *file);
void __init
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2674,7 +2674,7 @@ ftrace_notrace_open(struct inode *inode,
}
loff_t
-ftrace_regex_lseek(struct file *file, loff_t offset, int whence)
+ftrace_filter_lseek(struct file *file, loff_t offset, int whence)
{
loff_t ret;
@@ -3548,7 +3548,7 @@ static const struct file_operations ftra
.open = ftrace_filter_open,
.read = seq_read,
.write = ftrace_filter_write,
- .llseek = ftrace_regex_lseek,
+ .llseek = ftrace_filter_lseek,
.release = ftrace_regex_release,
};
@@ -3556,7 +3556,7 @@ static const struct file_operations ftra
.open = ftrace_notrace_open,
.read = seq_read,
.write = ftrace_notrace_write,
- .llseek = ftrace_regex_lseek,
+ .llseek = ftrace_filter_lseek,
.release = ftrace_regex_release,
};
@@ -3761,8 +3761,8 @@ static const struct file_operations ftra
.open = ftrace_graph_open,
.read = seq_read,
.write = ftrace_graph_write,
+ .llseek = ftrace_filter_lseek,
.release= ftrace_graph_release,
- .llseek = seq_lseek,
};
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
@@ -4420,7 +4420,7 @@ static const struct file_operations ftra
.open = ftrace_pid_open,
.write = ftrace_pid_write,
.read = seq_read,
- .llseek = seq_lseek,
+ .llseek = ftrace_filter_lseek,
.release= ftrace_pid_release,
};
--- a/kernel/trace/trace_stack.c
+++ b/kernel/trace/trace_stack.c
@@ -322,7 +322,7 @@ static const struct file_operations stac
.open = stack_trace_filter_open,
.read = seq_read,
.write = ftrace_filter_write,
- .llseek = ftrace_regex_lseek,
+ .llseek = ftrace_filter_lseek,
.release = ftrace_regex_release,
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 27/27] tty: dont deadlock while flushing workqueue
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
commit 852e4a8152b427c3f318bb0e1b5e938d64dcdc32 upstream.
Since commit 89c8d91e31f2 ("tty: localise the lock") I see a dead lock
in one of my dummy_hcd + g_nokia test cases. The first run was usually
okay, the second often resulted in a splat by lockdep and the third was
usually a dead lock.
Lockdep complained about tty->hangup_work and tty->legacy_mutex taken
both ways:
| ==
| [ INFO: possible circular locking dependency detected ]
| 3.7.0-rc6+ #204 Not tainted
| ---
| kworker/2:1/35 is trying to acquire lock:
| (&tty->legacy_mutex){+.+.+.}, at: [] tty_lock_nested+0x36/0x80
|
| but task is already holding lock:
| ((&tty->hangup_work)){+.+...}, at: [] process_one_work+0x124/0x5e0
|
| which lock already depends on the new lock.
|
| the existing dependency chain (in reverse order) is:
|
| -> #2 ((&tty->hangup_work)){+.+...}:
|[] lock_acquire+0x84/0x190
|[] flush_work+0x3d/0x240
|[] tty_ldisc_flush_works+0x16/0x30
|[] tty_ldisc_release+0x21/0x70
|[] tty_release+0x35c/0x470
|[] __fput+0xd8/0x270
|[] fput+0xd/0x10
|[] task_work_run+0xb9/0xf0
|[] do_notify_resume+0x51/0x80
|[] work_notifysig+0x35/0x3b
|
| -> #1 (&tty->legacy_mutex/1){+.+...}:
|[] lock_acquire+0x84/0x190
|[] mutex_lock_nested+0x6c/0x2f0
|[] tty_lock_nested+0x36/0x80
|[] tty_lock_pair+0x29/0x70
|[] tty_release+0x118/0x470
|[] __fput+0xd8/0x270
|[] fput+0xd/0x10
|[] task_work_run+0xb9/0xf0
|[] do_notify_resume+0x51/0x80
|[] work_notifysig+0x35/0x3b
|
| -> #0 (&tty->legacy_mutex){+.+.+.}:
|[] __lock_acquire+0x1189/0x16a0
|[] lock_acquire+0x84/0x190
|[] mutex_lock_nested+0x6c/0x2f0
|[] tty_lock_nested+0x36/0x80
|[] tty_lock+0xf/0x20
|[] __tty_hangup+0x54/0x410
|[] do_tty_hangup+0x12/0x20
|[] process_one_work+0x1a3/0x5e0
|[] worker_thread+0x119/0x3a0
|[] kthread+0x94/0xa0
|[] ret_from_kernel_thread+0x1b/0x28
|
|other info that might help us debug this:
|
|Chain exists of:
| &tty->legacy_mutex --> &tty->legacy_mutex/1 --> (&tty->hangup_work)
|
| Possible unsafe locking scenario:
|
| CPU0CPU1
|
| lock((&tty->hangup_work));
| lock(&tty->legacy_mutex/1);
| lock((&tty->hangup_work));
| lock(&tty->legacy_mutex);
|
| *** DEADLOCK ***
Before the path mentioned tty_ldisc_release() look like this:
| tty_ldisc_halt(tty);
| tty_ldisc_flush_works(tty);
| tty_lock();
As it can be seen, it first flushes the workqueue and then grabs the
tty_lock. Now we grab the lock first:
| tty_lock_pair(tty, o_tty);
| tty_ldisc_halt(tty);
| tty_ldisc_flush_works(tty);
so lockdep's complaint seems valid.
The earlier version of this patch took the ldisc_mutex since the other
user of tty_ldisc_flush_works() (tty_set_ldisc()) did this.
Peter Hurley then said that it is should not be requried. Since it
wasn't done earlier, I dropped this part.
The code under tty_ldisc_kill() was executed earlier with the tty lock
taken so it is taken again.
I was able to reproduce the deadlock on v3.8-rc1, this patch fixes the
problem in my testcase. I didn't notice any problems so far.
Signed-off-by: Sebastian Andrzej Siewior
Cc: Alan Cox
Cc: Peter Hurley
Cc: Bryan O'Donoghue
Signed-off-by: Greg Kroah-Hartman
---
drivers/tty/tty_ldisc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -934,17 +934,17 @@ void tty_ldisc_release(struct tty_struct
* race with the set_ldisc code path.
*/
- tty_lock_pair(tty, o_tty);
tty_ldisc_halt(tty);
- tty_ldisc_flush_works(tty);
- if (o_tty) {
+ if (o_tty)
tty_ldisc_halt(o_tty);
+
+ tty_ldisc_flush_works(tty);
+ if (o_tty)
tty_ldisc_flush_works(o_tty);
- }
+ tty_lock_pair(tty, o_tty);
/* This will need doing differently if we need to lock */
tty_ldisc_kill(tty);
-
if (o_tty)
tty_ldisc_kill(o_tty);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 26/27] x86, mm: Patch out arch_flush_lazy_mmu_mode() when running on bare metal
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Boris Ostrovsky
commit 511ba86e1d386f671084b5d0e6f110bb30b8eeb2 upstream.
Invoking arch_flush_lazy_mmu_mode() results in calls to
preempt_enable()/disable() which may have performance impact.
Since lazy MMU is not used on bare metal we can patch away
arch_flush_lazy_mmu_mode() so that it is never called in such
environment.
[ hpa: the previous patch "Fix vmalloc_fault oops during lazy MMU
updates" may cause a minor performance regression on
bare metal. This patch resolves that performance regression. It is
somewhat unclear to me if this is a good -stable candidate. ]
Signed-off-by: Boris Ostrovsky
Link:
http://lkml.kernel.org/r/1364045796-10720-2-git-send-email-konrad.w...@oracle.com
Tested-by: Josh Boyer
Tested-by: Konrad Rzeszutek Wilk
Acked-by: Borislav Petkov
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/paravirt.h |5 -
arch/x86/include/asm/paravirt_types.h |2 ++
arch/x86/kernel/paravirt.c| 25 +
arch/x86/lguest/boot.c|1 +
arch/x86/xen/mmu.c|1 +
5 files changed, 21 insertions(+), 13 deletions(-)
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -703,7 +703,10 @@ static inline void arch_leave_lazy_mmu_m
PVOP_VCALL0(pv_mmu_ops.lazy_mode.leave);
}
-void arch_flush_lazy_mmu_mode(void);
+static inline void arch_flush_lazy_mmu_mode(void)
+{
+ PVOP_VCALL0(pv_mmu_ops.lazy_mode.flush);
+}
static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
phys_addr_t phys, pgprot_t flags)
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -91,6 +91,7 @@ struct pv_lazy_ops {
/* Set deferred update mode, used for batching operations. */
void (*enter)(void);
void (*leave)(void);
+ void (*flush)(void);
};
struct pv_time_ops {
@@ -679,6 +680,7 @@ void paravirt_end_context_switch(struct
void paravirt_enter_lazy_mmu(void);
void paravirt_leave_lazy_mmu(void);
+void paravirt_flush_lazy_mmu(void);
void _paravirt_nop(void);
u32 _paravirt_ident_32(u32);
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -263,6 +263,18 @@ void paravirt_leave_lazy_mmu(void)
leave_lazy(PARAVIRT_LAZY_MMU);
}
+void paravirt_flush_lazy_mmu(void)
+{
+ preempt_disable();
+
+ if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
+ arch_leave_lazy_mmu_mode();
+ arch_enter_lazy_mmu_mode();
+ }
+
+ preempt_enable();
+}
+
void paravirt_start_context_switch(struct task_struct *prev)
{
BUG_ON(preemptible());
@@ -292,18 +304,6 @@ enum paravirt_lazy_mode paravirt_get_laz
return this_cpu_read(paravirt_lazy_mode);
}
-void arch_flush_lazy_mmu_mode(void)
-{
- preempt_disable();
-
- if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
- arch_leave_lazy_mmu_mode();
- arch_enter_lazy_mmu_mode();
- }
-
- preempt_enable();
-}
-
struct pv_info pv_info = {
.name = "bare hardware",
.paravirt_enabled = 0,
@@ -475,6 +475,7 @@ struct pv_mmu_ops pv_mmu_ops = {
.lazy_mode = {
.enter = paravirt_nop,
.leave = paravirt_nop,
+ .flush = paravirt_nop,
},
.set_fixmap = native_set_fixmap,
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -1333,6 +1333,7 @@ __init void lguest_init(void)
pv_mmu_ops.read_cr3 = lguest_read_cr3;
pv_mmu_ops.lazy_mode.enter = paravirt_enter_lazy_mmu;
pv_mmu_ops.lazy_mode.leave = lguest_leave_lazy_mmu_mode;
+ pv_mmu_ops.lazy_mode.flush = paravirt_flush_lazy_mmu;
pv_mmu_ops.pte_update = lguest_pte_update;
pv_mmu_ops.pte_update_defer = lguest_pte_update;
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2190,6 +2190,7 @@ static const struct pv_mmu_ops xen_mmu_o
.lazy_mode = {
.enter = paravirt_enter_lazy_mmu,
.leave = xen_leave_lazy_mmu,
+ .flush = paravirt_flush_lazy_mmu,
},
.set_fixmap = xen_set_fixmap,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 22/27] udl: handle EDID failure properly.
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Airlie
commit 1baee58638fc58248625255f5c5fcdb987f11b1f upstream.
Don't oops seems proper.
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/udl/udl_connector.c |4
1 file changed, 4 insertions(+)
--- a/drivers/gpu/drm/udl/udl_connector.c
+++ b/drivers/gpu/drm/udl/udl_connector.c
@@ -61,6 +61,10 @@ static int udl_get_modes(struct drm_conn
int ret;
edid = (struct edid *)udl_get_edid(udl);
+ if (!edid) {
+ drm_mode_connector_update_edid_property(connector, NULL);
+ return 0;
+ }
/*
* We only read the main block, but if the monitor reports extension
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 20/27] x86-32: Fix possible incomplete TLB invalidate with PAE pagetables
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Hansen
commit 1de14c3c5cbc9bb17e9dcc648cda51c0c85d54b9 upstream.
This patch attempts to fix:
https://bugzilla.kernel.org/show_bug.cgi?id=56461
The symptom is a crash and messages like this:
chrome: Corrupted page table at address 34a03000
*pdpt = *pde =
Bad pagetable: 000f [#1] PREEMPT SMP
Ingo guesses this got introduced by commit 611ae8e3f520 ("x86/tlb:
enable tlb flush range support for x86") since that code started to free
unused pagetables.
On x86-32 PAE kernels, that new code has the potential to free an entire
PMD page and will clear one of the four page-directory-pointer-table
(aka pgd_t entries).
The hardware aggressively "caches" these top-level entries and invlpg
does not actually affect the CPU's copy. If we clear one we *HAVE* to
do a full TLB flush, otherwise we might continue using a freed pmd page.
(note, we do this properly on the population side in pud_populate()).
This patch tracks whenever we clear one of these entries in the 'struct
mmu_gather', and ensures that we follow up with a full tlb flush.
BTW, I disassembled and checked that:
if (tlb->fullmm == 0)
and
if (!tlb->fullmm && !tlb->need_flush_all)
generate essentially the same code, so there should be zero impact there
to the !PAE case.
Signed-off-by: Dave Hansen
Cc: Peter Anvin
Cc: Ingo Molnar
Cc: Artem S Tashkinov
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/tlb.h |2 +-
arch/x86/mm/pgtable.c |7 +++
include/asm-generic/tlb.h |7 ++-
mm/memory.c|1 +
4 files changed, 15 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/tlb.h
+++ b/arch/x86/include/asm/tlb.h
@@ -7,7 +7,7 @@
#define tlb_flush(tlb) \
{ \
- if (tlb->fullmm == 0) \
+ if (!tlb->fullmm && !tlb->need_flush_all) \
flush_tlb_mm_range(tlb->mm, tlb->start, tlb->end, 0UL); \
else\
flush_tlb_mm_range(tlb->mm, 0UL, TLB_FLUSH_ALL, 0UL); \
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -58,6 +58,13 @@ void ___pte_free_tlb(struct mmu_gather *
void ___pmd_free_tlb(struct mmu_gather *tlb, pmd_t *pmd)
{
paravirt_release_pmd(__pa(pmd) >> PAGE_SHIFT);
+ /*
+* NOTE! For PAE, any changes to the top page-directory-pointer-table
+* entries need a full cr3 reload to flush.
+*/
+#ifdef CONFIG_X86_PAE
+ tlb->need_flush_all = 1;
+#endif
tlb_remove_page(tlb, virt_to_page(pmd));
}
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -99,7 +99,12 @@ struct mmu_gather {
unsigned intneed_flush : 1, /* Did free PTEs */
fast_mode : 1; /* No batching */
- unsigned intfullmm;
+ /* we are in the middle of an operation to clear
+* a full mm and can make some optimizations */
+ unsigned intfullmm : 1,
+ /* we have performed an operation which
+* requires a complete flush of the tlb */
+ need_flush_all : 1;
struct mmu_gather_batch *active;
struct mmu_gather_batch local;
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -212,6 +212,7 @@ void tlb_gather_mmu(struct mmu_gather *t
tlb->mm = mm;
tlb->fullmm = fullmm;
+ tlb->need_flush_all = 0;
tlb->start = -1UL;
tlb->end= 0;
tlb->need_flush = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 24/27] sched_clock: Prevent 64bit inatomicity on 32bit systems
3.8-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit a1cbcaa9ea87b87a96b9fc465951dcf36e459ca2 upstream. The sched_clock_remote() implementation has the following inatomicity problem on 32bit systems when accessing the remote scd->clock, which is a 64bit value. CPU0CPU1 sched_clock_local() sched_clock_remote(CPU0) ... remote_clock = scd[CPU0]->clock read_low32bit(scd[CPU0]->clock) cmpxchg64(scd->clock,...) read_high32bit(scd[CPU0]->clock) While the update of scd->clock is using an atomic64 mechanism, the readout on the remote cpu is not, which can cause completely bogus readouts. It is a quite rare problem, because it requires the update to hit the narrow race window between the low/high readout and the update must go across the 32bit boundary. The resulting misbehaviour is, that CPU1 will see the sched_clock on CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value to this bogus timestamp. This stays that way due to the clamping implementation for about 4 seconds until the synchronization with CLOCK_MONOTONIC undoes the problem. The issue is hard to observe, because it might only result in a less accurate SCHED_OTHER timeslicing behaviour. To create observable damage on realtime scheduling classes, it is necessary that the bogus update of CPU1 sched_clock happens in the context of an realtime thread, which then gets charged 4 seconds of RT runtime, which results in the RT throttler mechanism to trigger and prevent scheduling of RT tasks for a little less than 4 seconds. So this is quite unlikely as well. The issue was quite hard to decode as the reproduction time is between 2 days and 3 weeks and intrusive tracing makes it less likely, but the following trace recorded with trace_clock=global, which uses sched_clock_local(), gave the final hint: -0 0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80 -0 0d..30 400269.477151: hrtimer_start: hrtimer=0xf7061e80 ... irq/20-S-587 1d..32 400273.772118: sched_wakeup: comm= ... target_cpu=0 -0 0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80 What happens is that CPU0 goes idle and invokes sched_clock_idle_sleep_event() which invokes sched_clock_local() and CPU1 runs a remote wakeup for CPU0 at the same time, which invokes sched_remote_clock(). The time jump gets propagated to CPU0 via sched_remote_clock() and stays stale on both cores for ~4 seconds. There are only two other possibilities, which could cause a stale sched clock: 1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic wrong value. 2) sched_clock() which reads the TSC returns a sporadic wrong value. #1 can be excluded because sched_clock would continue to increase for one jiffy and then go stale. #2 can be excluded because it would not make the clock jump forward. It would just result in a stale sched_clock for one jiffy. After quite some brain twisting and finding the same pattern on other traces, sched_clock_remote() remained the only place which could cause such a problem and as explained above it's indeed racy on 32bit systems. So while on 64bit systems the readout is atomic, we need to verify the remote readout on 32bit machines. We need to protect the local->clock readout in sched_clock_remote() on 32bit as well because an NMI could hit between the low and the high readout, call sched_clock_local() and modify local->clock. Thanks to Siegfried Wulsch for bearing with my debug requests and going through the tedious tasks of running a bunch of reproducer systems to generate the debug information which let me decode the issue. Reported-by: Siegfried Wulsch Acked-by: Peter Zijlstra Cc: Steven Rostedt Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman --- kernel/sched/clock.c | 26 ++ 1 file changed, 26 insertions(+) --- a/kernel/sched/clock.c +++ b/kernel/sched/clock.c @@ -176,10 +176,36 @@ static u64 sched_clock_remote(struct sch u64 this_clock, remote_clock; u64 *ptr, old_val, val; +#if BITS_PER_LONG != 64 +again: + /* +* Careful here: The local and the remote clock values need to +* be read out atomic as we need to compare the values and +* then update either the local or the remote side. So the +* cmpxchg64 below only protects one readout. +* +* We must reread via sched_clock_local() in the retry case on +* 32bit as an NMI could use sched_clock_local() via the +* tracer and hit between the readout of +* the low32bit and the high 32bit portion. +*/ + this_clock = sched_clock_local(my_scd); + /* +* We must enforce atomic readout on 32bit, otherwise the +* update on the remote cpu can hit inbetween
[ 16/27] target: Fix incorrect fallthrough of ALUA Standby/Offline/Transition CDBs
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Bellinger
commit 30f359a6f9da65a66de8cadf959f0f4a0d498bba upstream.
This patch fixes a bug where a handful of informational / control CDBs
that should be allowed during ALUA access state Standby/Offline/Transition
where incorrectly returning CHECK_CONDITION + ASCQ_04H_ALUA_TG_PT_*.
This includes INQUIRY + REPORT_LUNS, which would end up preventing LUN
registration when LUN scanning occured during these ALUA access states.
Signed-off-by: Nicholas Bellinger
Cc: Hannes Reinecke
Signed-off-by: Greg Kroah-Hartman
---
drivers/target/target_core_alua.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/target/target_core_alua.c
+++ b/drivers/target/target_core_alua.c
@@ -408,6 +408,7 @@ static inline int core_alua_state_standb
case REPORT_LUNS:
case RECEIVE_DIAGNOSTIC:
case SEND_DIAGNOSTIC:
+ return 0;
case MAINTENANCE_IN:
switch (cdb[1] & 0x1f) {
case MI_REPORT_TARGET_PGS:
@@ -450,6 +451,7 @@ static inline int core_alua_state_unavai
switch (cdb[0]) {
case INQUIRY:
case REPORT_LUNS:
+ return 0;
case MAINTENANCE_IN:
switch (cdb[1] & 0x1f) {
case MI_REPORT_TARGET_PGS:
@@ -490,6 +492,7 @@ static inline int core_alua_state_transi
switch (cdb[0]) {
case INQUIRY:
case REPORT_LUNS:
+ return 0;
case MAINTENANCE_IN:
switch (cdb[1] & 0x1f) {
case MI_REPORT_TARGET_PGS:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 19/27] gpio: fix wrong checking condition for gpio range
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Haojian Zhuang
commit ad4e1a7caf937ad395ced585ca85a7d14395dc80 upstream.
If index++ calculates from 0, the checking condition of "while
(index++)" fails & it doesn't check any more. It doesn't follow
the loop that used at here.
Replace it by endless loop at here. Then it keeps parsing
"gpio-ranges" property until it ends.
Signed-off-by: Haojian Zhuang
Reviewed-by: Linus Walleij
Signed-off-by: Linus Walleij
Signed-off-by: Jonghwan Choi
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpio/gpiolib-of.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -228,7 +228,7 @@ static void of_gpiochip_add_pin_range(st
if (!np)
return;
- do {
+ for (;; index++) {
ret = of_parse_phandle_with_args(np, "gpio-ranges",
"#gpio-range-cells", index, &pinspec);
if (ret)
@@ -257,8 +257,7 @@ static void of_gpiochip_add_pin_range(st
if (ret)
break;
-
- } while (index++);
+ }
}
#else
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 18/27] kobject: fix kset_find_obj() race with concurrent last kobject_put()
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit a49b7e82cab0f9b41f483359be83f44fbb6b4979 upstream.
Anatol Pomozov identified a race condition that hits module unloading
and re-loading. To quote Anatol:
"This is a race codition that exists between kset_find_obj() and
kobject_put(). kset_find_obj() might return kobject that has refcount
equal to 0 if this kobject is freeing by kobject_put() in other
thread.
Here is timeline for the crash in case if kset_find_obj() searches for
an object tht nobody holds and other thread is doing kobject_put() on
the same kobject:
THREAD A (calls kset_find_obj()) THREAD B (calls kobject_put())
splin_lock()
atomic_dec_return(kobj->kref), counter
gets zero here
... starts kobject cleanup
spin_lock() // WAIT thread A in
kobj_kset_leave()
iterate over kset->list
atomic_inc(kobj->kref) (counter becomes 1)
spin_unlock()
spin_lock() // taken
// it does not know that thread A
increased counter so it
remove obj from list
spin_unlock()
vfree(module) // frees module object
with containing kobj
// kobj points to freed memory area!!
kobject_put(kobj) // OOPS
The race above happens because module.c tries to use kset_find_obj()
when somebody unloads module. The module.c code was introduced in
commit 6494a93d55fa"
Anatol supplied a patch specific for module.c that worked around the
problem by simply not using kset_find_obj() at all, but rather than make
a local band-aid, this just fixes kset_find_obj() to be thread-safe
using the proper model of refusing the get a new reference if the
refcount has already dropped to zero.
See examples of this proper refcount handling not only in the kref
documentation, but in various other equivalent uses of this pattern by
grepping for atomic_inc_not_zero().
[ Side note: the module race does indicate that module loading and
unloading is not properly serialized wrt sysfs information using the
module mutex. That may require further thought, but this is the
correct fix at the kobject layer regardless. ]
Reported-analyzed-and-tested-by: Anatol Pomozov
Cc: Al Viro
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
lib/kobject.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -529,6 +529,13 @@ struct kobject *kobject_get(struct kobje
return kobj;
}
+static struct kobject *kobject_get_unless_zero(struct kobject *kobj)
+{
+ if (!kref_get_unless_zero(&kobj->kref))
+ kobj = NULL;
+ return kobj;
+}
+
/*
* kobject_cleanup - free kobject resources.
* @kobj: object to cleanup
@@ -751,7 +758,7 @@ struct kobject *kset_find_obj(struct kse
list_for_each_entry(k, &kset->list, entry) {
if (kobject_name(k) && !strcmp(kobject_name(k), name)) {
- ret = kobject_get(k);
+ ret = kobject_get_unless_zero(k);
break;
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 15/27] cifs: Allow passwords which begin with a delimitor
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Sachin Prabhu
commit c369c9a4a7c82d33329d869cbaf93304cc7a0c40 upstream.
Fixes a regression in cifs_parse_mount_options where a password
which begins with a delimitor is parsed incorrectly as being a blank
password.
Signed-off-by: Sachin Prabhu
Acked-by: Jeff Layton
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/connect.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -1546,14 +1546,24 @@ cifs_parse_mount_options(const char *mou
}
break;
case Opt_blank_pass:
- vol->password = NULL;
- break;
- case Opt_pass:
/* passwords have to be handled differently
* to allow the character used for deliminator
* to be passed within them
*/
+ /*
+* Check if this is a case where the password
+* starts with a delimiter
+*/
+ tmp_end = strchr(data, '=');
+ tmp_end++;
+ if (!(tmp_end < end && tmp_end[1] == delim)) {
+ /* No it is not. Set the password to NULL */
+ vol->password = NULL;
+ break;
+ }
+ /* Yes it is. Drop down to Opt_pass below.*/
+ case Opt_pass:
/* Obtain the value string */
value = strchr(data, '=');
value++;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 11/27] ipc: set msg back to -EAGAIN if copy wasnt performed
3.8-stable review patch. If anyone has any objections, please let me know. -- From: Stanislav Kinsbursky commit 2dc958fa2fe6987e7ab106bd97029a09a82fcd8d upstream. Make sure that msg pointer is set back to error value in case of MSG_COPY flag is set and desired message to copy wasn't found. This garantees that msg is either a error pointer or a copy address. Otherwise the last message in queue will be freed without unlinking from the queue (which leads to memory corruption) and the dummy allocated copy won't be released. Signed-off-by: Stanislav Kinsbursky Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- ipc/msg.c |1 + 1 file changed, 1 insertion(+) --- a/ipc/msg.c +++ b/ipc/msg.c @@ -872,6 +872,7 @@ long do_msgrcv(int msqid, void __user *b goto out_unlock; break; } + msg = ERR_PTR(-EAGAIN); } else break; msg_counter++; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 13/27] GFS2: return error if malloc failed in gfs2_rs_alloc()
3.8-stable review patch. If anyone has any objections, please let me know. -- From: Wei Yongjun commit 441362d06be349430d06e37286adce4b90e6ce96 upstream. The error code in gfs2_rs_alloc() is set to ENOMEM when error but never be used, instead, gfs2_rs_alloc() always return 0. Fix to return 'error'. Signed-off-by: Wei Yongjun Signed-off-by: Steven Whitehouse Signed-off-by: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman --- fs/gfs2/rgrp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/gfs2/rgrp.c +++ b/fs/gfs2/rgrp.c @@ -576,7 +576,7 @@ int gfs2_rs_alloc(struct gfs2_inode *ip) RB_CLEAR_NODE(&ip->i_res->rs_node); out: up_write(&ip->i_rw_mutex); - return 0; + return error; } static void dump_rs(struct seq_file *seq, const struct gfs2_blkreserv *rs) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 12/27] GFS2: Fix unlock of fcntl locks during withdrawn state
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Steven Whitehouse
commit c2952d202f710d326ac36a8ea6bd216b20615ec8 upstream.
When withdraw occurs, we need to continue to allow unlocks of fcntl
locks to occur, however these will only be local, since the node has
withdrawn from the cluster. This prevents triggering a VFS level
bug trap due to locks remaining when a file is closed.
Signed-off-by: Steven Whitehouse
Signed-off-by: Jonghwan Choi
Signed-off-by: Greg Kroah-Hartman
---
fs/gfs2/file.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -924,8 +924,11 @@ static int gfs2_lock(struct file *file,
cmd = F_SETLK;
fl->fl_type = F_UNLCK;
}
- if (unlikely(test_bit(SDF_SHUTDOWN, &sdp->sd_flags)))
+ if (unlikely(test_bit(SDF_SHUTDOWN, &sdp->sd_flags))) {
+ if (fl->fl_type == F_UNLCK)
+ posix_lock_file_wait(file, fl);
return -EIO;
+ }
if (IS_GETLK(cmd))
return dlm_posix_get(ls->ls_dlm, ip->i_no_addr, file, fl);
else if (fl->fl_type == F_UNLCK)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 08/27] dmaengine: omap-dma: Start DMA without delay for cyclic channels
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Peter Ujfalusi
commit 765024697807ad1e1cac332aa891253ca4a339da upstream.
cyclic DMA is only used by audio which needs DMA to be started without a
delay.
If the DMA for audio is started using the tasklet we experience random
channel switch (to be more precise: channel shift).
Reported-by: Peter Meerwald
Signed-off-by: Peter Ujfalusi
Acked-by: Santosh Shilimkar
Acked-by: Russell King
Signed-off-by: Vinod Koul
Signed-off-by: Greg Kroah-Hartman
---
drivers/dma/omap-dma.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -276,12 +276,20 @@ static void omap_dma_issue_pending(struc
spin_lock_irqsave(&c->vc.lock, flags);
if (vchan_issue_pending(&c->vc) && !c->desc) {
- struct omap_dmadev *d = to_omap_dma_dev(chan->device);
- spin_lock(&d->lock);
- if (list_empty(&c->node))
- list_add_tail(&c->node, &d->pending);
- spin_unlock(&d->lock);
- tasklet_schedule(&d->task);
+ /*
+* c->cyclic is used only by audio and in this case the DMA need
+* to be started without delay.
+*/
+ if (!c->cyclic) {
+ struct omap_dmadev *d = to_omap_dma_dev(chan->device);
+ spin_lock(&d->lock);
+ if (list_empty(&c->node))
+ list_add_tail(&c->node, &d->pending);
+ spin_unlock(&d->lock);
+ tasklet_schedule(&d->task);
+ } else {
+ omap_dma_start_desc(c);
+ }
}
spin_unlock_irqrestore(&c->vc.lock, flags);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 07/27] ARM: imx35 Bugfix admux clock
3.8-stable review patch. If anyone has any objections, please let me know. -- From: Markus Pargmann commit 75498083e25e96932ad998ffdeadb17234c68d3a upstream. The admux clock seems to be the audmux clock as tests show. audmux does not work without this clock enabled. Currently imx35 does not register a clock device for audmux. This patch adds this registration. imx-audmux driver already handles a clock device, so no changes are necessary there. Signed-off-by: Markus Pargmann Signed-off-by: Sascha Hauer Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman --- arch/arm/mach-imx/clk-imx35.c |1 + 1 file changed, 1 insertion(+) --- a/arch/arm/mach-imx/clk-imx35.c +++ b/arch/arm/mach-imx/clk-imx35.c @@ -257,6 +257,7 @@ int __init mx35_clocks_init() clk_register_clkdev(clk[wdog_gate], NULL, "imx2-wdt.0"); clk_register_clkdev(clk[nfc_div], NULL, "imx25-nand.0"); clk_register_clkdev(clk[csi_gate], NULL, "mx3-camera.0"); + clk_register_clkdev(clk[admux_gate], "audmux", NULL); clk_prepare_enable(clk[spba_gate]); clk_prepare_enable(clk[gpio1_gate]); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 06/27] ARM: Kirkwood: Fix typo in the definition of ix2-200 rebuild LED
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Nigel Roberts
commit 8f08d6667287241f6818d35e02b223fb5df97cf1 upstream.
In the conversion to pinctrl, an error in the pins for the rebuild
LED was introduced. This patch assigns the correct pins and includes
the correct name for the LED in kirkwood-iomega_ix2_200.dts.
Signed-off-by: Nigel Roberts
Signed-off-by: Jason Cooper
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
--- a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
+++ b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
@@ -96,11 +96,11 @@
marvell,function = "gpio";
};
pmx_led_rebuild_brt_ctrl_1: pmx-led-rebuild-brt-ctrl-1 {
- marvell,pins = "mpp44";
+ marvell,pins = "mpp46";
marvell,function = "gpio";
};
pmx_led_rebuild_brt_ctrl_2: pmx-led-rebuild-brt-ctrl-2 {
- marvell,pins = "mpp45";
+ marvell,pins = "mpp47";
marvell,function = "gpio";
};
@@ -157,14 +157,14 @@
gpios = <&gpio0 16 0>;
linux,default-trigger = "default-on";
};
- health_led1 {
+ rebuild_led {
+ label = "status:white:rebuild_led";
+ gpios = <&gpio1 4 0>;
+ };
+ health_led {
label = "status:red:health_led";
gpios = <&gpio1 5 0>;
};
- health_led2 {
- label = "status:white:health_led";
- gpios = <&gpio1 4 0>;
- };
backup_led {
label = "status:blue:backup_led";
gpios = <&gpio0 15 0>;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 04/27] ASoC: wm8903: Fix the bypass to HP/LINEOUT when no DAC or ADC is running
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Alban Bedel
commit f1ca493b0b5e8f42d3b2dc8877860db2983f47b6 upstream.
The Charge Pump needs the DSP clock to work properly, without it the
bypass to HP/LINEOUT is not working properly. This requirement is not
mentioned in the datasheet but has been confirmed by Mark Brown from
Wolfson.
Signed-off-by: Alban Bedel
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
---
sound/soc/codecs/wm8903.c |2 ++
1 file changed, 2 insertions(+)
--- a/sound/soc/codecs/wm8903.c
+++ b/sound/soc/codecs/wm8903.c
@@ -1083,6 +1083,8 @@ static const struct snd_soc_dapm_route w
{ "ROP", NULL, "Right Speaker PGA" },
{ "RON", NULL, "Right Speaker PGA" },
+ { "Charge Pump", NULL, "CLK_DSP" },
+
{ "Left Headphone Output PGA", NULL, "Charge Pump" },
{ "Right Headphone Output PGA", NULL, "Charge Pump" },
{ "Left Line Output PGA", NULL, "Charge Pump" },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 02/27] ASoC: core: Fix to check return value of snd_soc_update_bits_locked()
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Joonyoung Shim
commit 0eaa6cca1f75e12e4f5ec62cbe887330fe3b5fe9 upstream.
It can be 0 or 1 return value of snd_soc_update_bits_locked() when it is
success. So just check return value is negative.
Signed-off-by: Joonyoung Shim
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
---
sound/soc/soc-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -2959,7 +2959,7 @@ int snd_soc_put_volsw_range(struct snd_k
val = val << shift;
ret = snd_soc_update_bits_locked(codec, reg, val_mask, val);
- if (ret != 0)
+ if (ret < 0)
return ret;
if (snd_soc_volsw_is_stereo(mc)) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 05/27] tracing: Fix double free when function profile init failed
3.8-stable review patch. If anyone has any objections, please let me know. -- From: Namhyung Kim commit 83e03b3fe4daffdebbb42151d5410d730ae50bd1 upstream. On the failure path, stat->start and stat->pages will refer same page. So it'll attempt to free the same page again and get kernel panic. Link: http://lkml.kernel.org/r/1364820385-32027-1-git-send-email-namhy...@kernel.org Signed-off-by: Namhyung Kim Cc: Frederic Weisbecker Cc: Namhyung Kim Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman --- kernel/trace/ftrace.c |1 - 1 file changed, 1 deletion(-) --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -668,7 +668,6 @@ int ftrace_profile_pages_init(struct ftr free_page(tmp); } - free_page((unsigned long)stat->pages); stat->pages = NULL; stat->start = NULL; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] cgroup: introduce sane_behavior mount option
> {
> + .name = "cgroup.sane_behavior",
> + .flags = CFTYPE_ONLY_ON_ROOT,
> + .read_seq_string = cgroup_sane_behavior_show,
> + .mode = S_IRUGO,
> + },
We don't have to set .mode explicitly.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET] cgroup, memcg: introduce sane_behavior mount option
On 2013/4/13 7:10, Tejun Heo wrote: > It's a sad fact that at this point various cgroup controllers are > carrying so many idiosyncrasies and pure insanities that it simply > isn't possible to reach any sort of sane consistent behavior while > staying compatible with what already has been exposed to userland. > > To make progress, those behaviors need to go but we can't simply drop > or change the crazies as those are directly visible to userland. This > patchset implements a mount option - sane_behavior - which turns on > new saner behaviors, so that we can keep providing the old behaviors > while and after transitioning to saner ones. > > As the behaviors which should be changed are still being determined > and then implemented, __DEVEL__ prefix is added to the mount option > and it triggers a warning message when used. > > The mount option changes the following behaviors after this patchset. > > * Mount options "noprefix" and "clone_children" are disallowed. Also, > cgroupfs file cgroup.clone_children is not created. > > * When mounting an existing superblock, mount options should match. > This is currently pretty crazy. If one mounts a cgroup, creates a > subdirectory, unmounts it and then mount it again with different > option, it looks like the new options are applied but they aren't. > > * Remount is disallowed. > > * memcg: .use_hierarchy is forced on and the cgroupfs file is not > created. > > and there are a lot more to come. Basically, when turned on, all > controllers should be ready to be mounted in the same hierarchy and > not get in the way unless specifically configured - making blk-throtl > hierarchical would need this to flip the meaning of limits, cpuset to > allow tasks to run by default in new cgroups and handle empty cpusets > in a way friendly to being co-mounted, and so on. > > This patchset contains the following four patches. > > 0001-cgroup-convert-cgroupfs_root-flag-bits-to-masks-and-.patch > 0002-move-cgroupfs_root-to-include-linux-cgroup.h.patch > 0003-cgroup-introduce-sane_behavior-mount-option.patch > 0004-memcg-force-use_hierarchy-if-sane_behavior.patch > > 0001-0002 are prep patches. It exposes cgroupfs_root in cgroup.h so > that flags can be tested with inline helpers. > > 0003 introduces sane_behavior mount option and implements behavior > changes in cgroup core proper. > > 0004 makes memcg .use_hierarchy changes. > Looks good to me! Acked-by: Li Zefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 00/27] 3.8.8-stable review
This is the start of the stable review cycle for the 3.8.8 release. There are 27 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Apr 17 02:41:37 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.8.8-rc1.gz and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 3.8.8-rc1 Sebastian Andrzej Siewior tty: don't deadlock while flushing workqueue Boris Ostrovsky x86, mm: Patch out arch_flush_lazy_mmu_mode() when running on bare metal Samu Kallio x86, mm, paravirt: Fix vmalloc_fault oops during lazy MMU updates Thomas Gleixner sched_clock: Prevent 64bit inatomicity on 32bit systems Steven Rostedt (Red Hat) ftrace: Move ftrace_filter_lseek out of CONFIG_DYNAMIC_FTRACE section Dave Airlie udl: handle EDID failure properly. Namhyung Kim tracing: Fix possible NULL pointer dereferences Dave Hansen x86-32: Fix possible incomplete TLB invalidate with PAE pagetables Haojian Zhuang gpio: fix wrong checking condition for gpio range Linus Torvalds kobject: fix kset_find_obj() race with concurrent last kobject_put() Suleiman Souhlal vfs: Revert spurious fix to spinning prevention in prune_icache_sb Nicholas Bellinger target: Fix incorrect fallthrough of ALUA Standby/Offline/Transition CDBs Sachin Prabhu cifs: Allow passwords which begin with a delimitor Lukasz Dorau SCSI: libsas: fix handling vacant phy in sas_set_ex_phy() Wei Yongjun GFS2: return error if malloc failed in gfs2_rs_alloc() Steven Whitehouse GFS2: Fix unlock of fcntl locks during withdrawn state Stanislav Kinsbursky ipc: set msg back to -EAGAIN if copy wasn't performed John W. Linville Revert "brcmsmac: support 4313iPA" Huacai Chen PM / reboot: call syscore_shutdown() after disable_nonboot_cpus() Peter Ujfalusi dmaengine: omap-dma: Start DMA without delay for cyclic channels Markus Pargmann ARM: imx35 Bugfix admux clock Nigel Roberts ARM: Kirkwood: Fix typo in the definition of ix2-200 rebuild LED Namhyung Kim tracing: Fix double free when function profile init failed Alban Bedel ASoC: wm8903: Fix the bypass to HP/LINEOUT when no DAC or ADC is running Mark Brown ASoC: wm5102: Correct lookup of arizona struct in SYSCLK event Joonyoung Shim ASoC: core: Fix to check return value of snd_soc_update_bits_locked() Eldad Zack ALSA: usb-audio: fix endianness bug in snd_nativeinstruments_* - Diffstat: Makefile | 4 +- arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 14 +- arch/arm/mach-imx/clk-imx35.c | 1 + arch/x86/include/asm/paravirt.h| 5 +- arch/x86/include/asm/paravirt_types.h | 2 + arch/x86/include/asm/tlb.h | 2 +- arch/x86/kernel/paravirt.c | 25 +- arch/x86/lguest/boot.c | 1 + arch/x86/mm/fault.c| 6 +- arch/x86/mm/pgtable.c | 7 + arch/x86/xen/mmu.c | 1 + drivers/dma/omap-dma.c | 20 +- drivers/gpio/gpiolib-of.c | 5 +- drivers/gpu/drm/udl/udl_connector.c| 4 + .../net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c | 369 - .../wireless/brcm80211/brcmsmac/phy/phytbl_lcn.c | 64 ++-- drivers/scsi/libsas/sas_expander.c | 12 + drivers/target/target_core_alua.c | 3 + drivers/tty/tty_ldisc.c| 10 +- fs/cifs/connect.c | 16 +- fs/gfs2/file.c | 5 +- fs/gfs2/rgrp.c | 2 +- fs/inode.c | 2 +- include/asm-generic/tlb.h | 7 +- include/linux/ftrace.h | 3 +- ipc/msg.c | 1 + kernel/sched/clock.c | 26 ++ kernel/sys.c | 3 +- kernel/trace/ftrace.c | 37 +-- kernel/trace/trace_stack.c | 2 +- lib/kobject.c | 9 +- mm/memory.c| 1 + sound/soc/codecs/wm5102.c | 2 +- sound/soc/codecs/wm8903.c | 2 + sound/soc/soc-core.c | 2 +- sound/usb/mixer_quirks.c | 4 +- soun
Re: [PATCH 3/4] cgroup: introduce sane_behavior mount option
On Mon, Apr 15, 2013 at 10:49:15AM +0800, Li Zefan wrote:
> > {
> > + .name = "cgroup.sane_behavior",
> > + .flags = CFTYPE_ONLY_ON_ROOT,
> > + .read_seq_string = cgroup_sane_behavior_show,
> > + .mode = S_IRUGO,
> > + },
>
> We don't have to set .mode explicitly.
Right, dropping.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/4] x86, kdump: Set crashkernel_low automatically
On Sun, Apr 14, 2013 at 6:59 PM, H. Peter Anvin wrote: > On 04/11/2013 11:54 PM, Yinghai Lu wrote: > >> + /* >> + * two parts from lib/swiotlb.c: >> + * swiotlb size: user specified with swiotlb= or default. >> + * swiotlb overflow buffer: now is hardcoded to 32k, >> + * round to 8M to cover more others. >> + */ > > This comment is incomprehensible. "Cover more others"? i mean other buffers that may need to stay low, but we do not know them eactly yet. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET] cgroup, memcg: introduce sane_behavior mount option
On Fri, Apr 12, 2013 at 04:10:55PM -0700, Tejun Heo wrote: > To make progress, those behaviors need to go but we can't simply drop > or change the crazies as those are directly visible to userland. This > patchset implements a mount option - sane_behavior - which turns on > new saner behaviors, so that we can keep providing the old behaviors > while and after transitioning to saner ones. Applied 1-3 to cgroup/for-3.10. Michal, I left the last memcg one out. Please let me know how you wanna route it. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET] cgroup: implement task_cgroup_path_from_hierarchy()
On Sun, Apr 14, 2013 at 11:36:55AM -0700, Tejun Heo wrote: > kdbus folks want a sane way to determine the cgroup path that a given > task belongs to on a given hierarchy, which is a reasonble thing to > expect from cgroup core. > > This patchset make hierarchy_id allocation use idr instead of ida and > implement task_cgroup_path_from_hierarchy(). In the process, the > yucky ida cyclic allocation is replaced with idr_alloc_cyclic(). > > 0001-cgroup-refactor-hierarchy_id-handling.patch > 0002-cgroup-drop-hierarchy_id_lock.patch > 0003-cgroup-make-hierarchy_id-use-cyclic-idr.patch > 0004-cgroup-implement-task_cgroup_path_from_hierarchy.patch > > 0001-0002 prepare for conversion to idr, which 0003 does. > > 0004 implements the new function. > > This patchset is on top of next-20130412 as idr_alloc_cyclic() patch > is currently in -mm. Given that this isn't an urgent thing and the > merge window is just around the corner, it'd be probably best to route > these through cgroup/for-3.11 once v3.10-rc1 drops. > > These patches are also available in the following git branch. > > git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git > review-task_cgroup_path_from_hierarchy > > And it actually reduces LOC. Woot Woot. > > include/linux/cgroup.h |2 > kernel/cgroup.c| 128 > + > 2 files changed, 89 insertions(+), 41 deletions(-) Heh, I must have been tripping or something. 89 > 41. It's still a lot cleaner tho. :) -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/4] x86, kdump: Set crashkernel_low automatically
Then make the comment so it is actually possible to understand that. Yinghai Lu wrote: >On Sun, Apr 14, 2013 at 6:59 PM, H. Peter Anvin wrote: >> On 04/11/2013 11:54 PM, Yinghai Lu wrote: >> >>> + /* >>> + * two parts from lib/swiotlb.c: >>> + * swiotlb size: user specified with swiotlb= or >default. >>> + * swiotlb overflow buffer: now is hardcoded to >32k, >>> + * round to 8M to cover more others. >>> + */ >> >> This comment is incomprehensible. "Cover more others"? > >i mean other buffers that may need to stay low, but we do not know >them eactly yet. > >Thanks > >Yinghai -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG][s390x] mm: system crashed
Hi All,
I hit the below crashed when doing memory related tests[1] on s390x:
--- snip -
� 15929.351639¨ � <0021c0a6>¨ shrink_inactive_list+0x1c6/0x56c
� 15929.351647¨ � <0021c69e>¨ shrink_lruvec+0x252/0x56c
� 15929.351654¨ � <0021ca44>¨ shrink_zone+0x8c/0x1bc
� 15929.351662¨ � <0021d080>¨ balance_pgdat+0x50c/0x658
� 15929.351671¨ � <0021d318>¨ kswapd+0x14c/0x470
� 15929.351680¨ � <00158292>¨ kthread+0xda/0xe4
� 15929.351690¨ � <0062a5de>¨ kernel_thread_starter+0x6/0xc
� 15929.351700¨ � <0062a5d8>¨ kernel_thread_starter+0x0/0xc
� 16109.346061¨ INFO: rcu_sched self-detected stall on CPU { 0} (t=24006
jiffies
g=89766 c=89765 q=10544)
� 16109.346101¨ CPU: 0 Tainted: G D 3.9.0-rc6+ #1
� 16109.346106¨ Process kswapd0 (pid: 28, task: 3b2a, ksp:
3b
2ab8c0)
� 16109.346110¨0001bb60 0001bb70 0002
000
0
0001bc00 0001bb78 0001bb78 001009ca
2930 000a 000a
0001bbc0 0001bb60
0063bb18 001009ca 0001bb60 0001bbb0
� 16109.346170¨ Call Trace:
� 16109.346179¨ (� <00100920>¨ show_trace+0x128/0x12c)
� 16109.346195¨ � <001cd320>¨ rcu_check_callbacks+0x458/0xccc
� 16109.346209¨ � <00140f2e>¨ update_process_times+0x4a/0x74
� 16109.346222¨ � <00199452>¨ tick_sched_handle.isra.12+0x5e/0x70
� 16109.346235¨ � <001995aa>¨ tick_sched_timer+0x6a/0x98
� 16109.346247¨ � <0015c1ea>¨ __run_hrtimer+0x8e/0x200
� 16109.346381¨ � <0015d1b2>¨ hrtimer_interrupt+0x212/0x2b0
� 16109.346385¨ � <001040f6>¨ clock_comparator_work+0x4a/0x54
� 16109.346390¨ � <0010d658>¨ do_extint+0x158/0x15c
� 16109.346396¨ � <0062aa24>¨ ext_skip+0x38/0x3c
� 16109.346404¨ � <001153c8>¨ smp_yield_cpu+0x44/0x48
� 16109.346412¨ (� <03d10051aec0>¨ 0x3d10051aec0)
� 16109.346457¨ � <0024206a>¨ __page_check_address+0x16a/0x170
� 16109.346466¨ � <002423a2>¨ page_referenced_one+0x3e/0xa0
� 16109.346501¨ � <0024427c>¨ page_referenced+0x32c/0x41c
� 16109.346510¨ � <0021b1dc>¨ shrink_page_list+0x380/0xb9c
� 16109.346521¨ � <0021c0a6>¨ shrink_inactive_list+0x1c6/0x56c
� 16109.346532¨ � <0021c69e>¨ shrink_lruvec+0x252/0x56c
� 16109.346542¨ � <0021ca44>¨ shrink_zone+0x8c/0x1bc
� 16109.346553¨ � <0021d080>¨ balance_pgdat+0x50c/0x658
� 16109.346564¨ � <0021d318>¨ kswapd+0x14c/0x470
� 16109.346576¨ � <00158292>¨ kthread+0xda/0xe4
� 16109.346656¨ � <0062a5de>¨ kernel_thread_starter+0x6/0xc
� 16109.346682¨ � <0062a5d8>¨ kernel_thread_starter+0x0/0xc
[-- MARK -- Fri Apr 12 06:15:00 2013]
� 16289.386061¨ INFO: rcu_sched self-detected stall on CPU { 0} (t=42010
jiffies
g=89766 c=89765 q=10627)
-- snip --
The testing system has 1Gb RAM, kernel is new latest mainline.
please let me know if you need any more info.
[1] reproducer is come from LTP:
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/mtest06/mmap2.c
and execute it using this command: `./mmap2 -x 0.002 -a -p`
--
Thanks,
Zhouping
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] cgroup: implement task_cgroup_path_from_hierarchy()
> +int task_cgroup_path_from_hierarchy(struct task_struct *task, int
> hierarchy_id,
> + char *buf, size_t buflen)
> +{
> + struct cgroupfs_root *root;
> + struct cgroup *cgrp = NULL;
> + int ret = -ENOENT;
> +
> + mutex_lock(&cgroup_mutex);
> +
> + root = idr_find(&cgroup_hierarchy_idr, hierarchy_id);
> + if (root) {
> + cgrp = task_cgroup_from_root(task, root);
task_cgroup_from_root() will never return NULL, and there's a BUG_ON(!res) in
it.
> + if (cgrp)
> + ret = cgroup_path(cgrp, buf, buflen);
> + }
> +
> + mutex_unlock(&cgroup_mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(task_cgroup_path_from_hierarchy);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET] cgroup: implement task_cgroup_path_from_hierarchy()
On 2013/4/15 2:36, Tejun Heo wrote: > kdbus folks want a sane way to determine the cgroup path that a given > task belongs to on a given hierarchy, which is a reasonble thing to > expect from cgroup core. > > This patchset make hierarchy_id allocation use idr instead of ida and > implement task_cgroup_path_from_hierarchy(). In the process, the > yucky ida cyclic allocation is replaced with idr_alloc_cyclic(). > > 0001-cgroup-refactor-hierarchy_id-handling.patch > 0002-cgroup-drop-hierarchy_id_lock.patch > 0003-cgroup-make-hierarchy_id-use-cyclic-idr.patch > 0004-cgroup-implement-task_cgroup_path_from_hierarchy.patch > > 0001-0002 prepare for conversion to idr, which 0003 does. > > 0004 implements the new function. > Acked-by: Li Zefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] cgroup: implement task_cgroup_path_from_hierarchy()
On Mon, Apr 15, 2013 at 11:43:15AM +0800, Li Zefan wrote:
> > +int task_cgroup_path_from_hierarchy(struct task_struct *task, int
> > hierarchy_id,
> > + char *buf, size_t buflen)
> > +{
> > + struct cgroupfs_root *root;
> > + struct cgroup *cgrp = NULL;
> > + int ret = -ENOENT;
> > +
> > + mutex_lock(&cgroup_mutex);
> > +
> > + root = idr_find(&cgroup_hierarchy_idr, hierarchy_id);
> > + if (root) {
> > + cgrp = task_cgroup_from_root(task, root);
>
> task_cgroup_from_root() will never return NULL, and there's a BUG_ON(!res) in
> it.
@hierarchy_id may come from userland, so we probably should update
task_cgroup_from_root() to return NULL if the id is invalid. Will add
a patch.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] cgroup: implement task_cgroup_path_from_hierarchy()
On Sun, Apr 14, 2013 at 08:46:13PM -0700, Tejun Heo wrote:
> On Mon, Apr 15, 2013 at 11:43:15AM +0800, Li Zefan wrote:
> > > +int task_cgroup_path_from_hierarchy(struct task_struct *task, int
> > > hierarchy_id,
> > > + char *buf, size_t buflen)
> > > +{
> > > + struct cgroupfs_root *root;
> > > + struct cgroup *cgrp = NULL;
> > > + int ret = -ENOENT;
> > > +
> > > + mutex_lock(&cgroup_mutex);
> > > +
> > > + root = idr_find(&cgroup_hierarchy_idr, hierarchy_id);
> > > + if (root) {
> > > + cgrp = task_cgroup_from_root(task, root);
> >
> > task_cgroup_from_root() will never return NULL, and there's a BUG_ON(!res)
> > in it.
>
> @hierarchy_id may come from userland, so we probably should update
> task_cgroup_from_root() to return NULL if the id is invalid. Will add
> a patch.
For some reason, I thought you were talking about hierarchy lookup.
Yeap, task_cgroup_from_root() can't be NULL for a valid hierarchy.
Will drop the if.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] msm core for 3.10
Hi, On Fri, Apr 12, 2013 at 03:43:15PM -0700, David Brown wrote: > The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: > > Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git > tags/msm-core-3.10 > > for you to fetch changes up to e25e3d1fef2c57e49aef64535341c15fe2b29b4a: > > ARM: msm: Wait for timer clear to complete (2013-03-22 10:46:16 -0700) > > > Patches for MSM core > > These patches are changes to the MSM timer code that will be for > upcoming targets, including a generalization of the binding and > preventing a missing timer interrupt. > > > Stephen Boyd (2): > ARM: msm: Rework timer binding to be more general > ARM: msm: Wait for timer clear to complete > > .../devicetree/bindings/arm/msm/timer.txt | 41 > arch/arm/boot/dts/msm8660-surf.dts | 20 ++-- > arch/arm/boot/dts/msm8960-cdp.dts | 22 ++--- > arch/arm/mach-msm/timer.c | 110 > ++--- > 4 files changed, 86 insertions(+), 107 deletions(-) I didn't see either of the device tree maintainers cc:d on the bindings update, nor an ack from them. It looks reasonable enough to me, but I also do know that in your private downstream tree you have a lot of new bindings. Please make sure these go through proper review channels as you start to upstream them; i.e. Grant Likely and Rob Herring should either merge or ack them. I've cc:d Rob and Grant on this reply and I'll merge it for now but to avoid delays in getting your code merged in the future please make sure they are in the loop from the beginning. Thanks, -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] module: add kset_obj_exists() and use it
Veaceslav Falico writes:
> On Wed, Apr 10, 2013 at 04:47:34PM +0930, Rusty Russell wrote:
>>That's a bug. We should be cleaning up sysfs before we unlike the
>>removed module from the list.
>>
>>Because the same thing applies to ddebug info, which is also keyed by
>>module name.
>>
>>Something like this (untested!):
>
> Sorry for the late response - I wanted to test it for a longer time.
>
> Your patch works flawlessly and fixes this race, with just a small
> addition, cause otherwise we could BUG() in show_initstate().
>
> Can you apply this patch or should I (re-)send it somehow?
>
> Thank you!
>
> diff --git a/kernel/module.c b/kernel/module.c
> index d0afe23..8be6e97 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -1063,6 +1063,9 @@ static ssize_t show_initstate(struct module_attribute
> *mattr,
> case MODULE_STATE_GOING:
> state = "going";
> break;
> + case MODULE_STATE_UNFORMED:
> + state = "unformed";
> + break;
> default:
> BUG();
> }
Prefer to remove from sysfs before marking it unformed, like so:
diff --git a/kernel/module.c b/kernel/module.c
index 2468fda..2e7189f 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1862,12 +1862,12 @@ static void free_module(struct module *mod)
{
trace_module_free(mod);
- /* We leave it in list to prevent duplicate loads while we clean
-* up sysfs, ddebug and any other external exposure. */
- mod->state = MODULE_STATE_UNFORMED;
-
mod_sysfs_teardown(mod);
+ /* We leave it in list to prevent duplicate loads, but make sure
+* that noone uses it while it's being deconstructed. */
+ mod->state = MODULE_STATE_UNFORMED;
+
/* Remove dynamic debug info */
ddebug_remove_module(mod->name);
Here's the updated total patch:
diff --git a/kernel/module.c b/kernel/module.c
index 69d2600..2e7189f 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1862,12 +1862,12 @@ static void free_module(struct module *mod)
{
trace_module_free(mod);
- /* Delete from various lists */
- mutex_lock(&module_mutex);
- stop_machine(__unlink_module, mod, NULL);
- mutex_unlock(&module_mutex);
mod_sysfs_teardown(mod);
+ /* We leave it in list to prevent duplicate loads, but make sure
+* that noone uses it while it's being deconstructed. */
+ mod->state = MODULE_STATE_UNFORMED;
+
/* Remove dynamic debug info */
ddebug_remove_module(mod->name);
@@ -1880,6 +1880,11 @@ static void free_module(struct module *mod)
/* Free any allocated parameters. */
destroy_params(mod->kp, mod->num_kp);
+ /* Now we can delete it from the lists */
+ mutex_lock(&module_mutex);
+ stop_machine(__unlink_module, mod, NULL);
+ mutex_unlock(&module_mutex);
+
/* This may be NULL, but that's OK */
unset_module_init_ro_nx(mod);
module_free(mod, mod->module_init);
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] cgroup: implement task_cgroup_path_from_hierarchy()
On 2013/4/15 11:46, Tejun Heo wrote:
> On Mon, Apr 15, 2013 at 11:43:15AM +0800, Li Zefan wrote:
>>> +int task_cgroup_path_from_hierarchy(struct task_struct *task, int
>>> hierarchy_id,
>>> + char *buf, size_t buflen)
>>> +{
>>> + struct cgroupfs_root *root;
>>> + struct cgroup *cgrp = NULL;
>>> + int ret = -ENOENT;
>>> +
>>> + mutex_lock(&cgroup_mutex);
>>> +
>>> + root = idr_find(&cgroup_hierarchy_idr, hierarchy_id);
>>> + if (root) {
>>> + cgrp = task_cgroup_from_root(task, root);
>>
>> task_cgroup_from_root() will never return NULL, and there's a BUG_ON(!res)
>> in it.
>
> @hierarchy_id may come from userland, so we probably should update
> task_cgroup_from_root() to return NULL if the id is invalid. Will add
> a patch.
>
But if id is invalid, idr_find() will return NULL. As long as root is not NULL,
task_cgroup_from_root() will always return a valid cgroup.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH UPDATED 4/4] cgroup: implement task_cgroup_path_from_hierarchy()
kdbus folks want a sane way to determine the cgroup path that a given
task belongs to on a given hierarchy, which is a reasonble thing to
expect from cgroup core.
Implement task_cgroup_path_from_hierarchy().
v2: Dropped unnecessary NULL check on the return value of
task_cgroup_from_root() as suggested by Li Zefan.
Signed-off-by: Tejun Heo
Acked-by: Greg Kroah-Hartman
Acked-by: Li Zefan
Cc: Kay Sievers
Cc: Lennart Poettering
Cc: Daniel Mack
---
include/linux/cgroup.h |2 ++
kernel/cgroup.c| 32
2 files changed, 34 insertions(+)
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -443,6 +443,8 @@ int cgroup_is_removed(const struct cgrou
bool cgroup_is_descendant(struct cgroup *cgrp, struct cgroup *ancestor);
int cgroup_path(const struct cgroup *cgrp, char *buf, int buflen);
+int task_cgroup_path_from_hierarchy(struct task_struct *task, int hierarchy_id,
+ char *buf, size_t buflen);
int cgroup_task_count(const struct cgroup *cgrp);
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1842,6 +1842,38 @@ out:
}
EXPORT_SYMBOL_GPL(cgroup_path);
+/**
+ * task_cgroup_path_from_hierarchy - cgroup path of a task on a hierarchy
+ * @task: target task
+ * @hierarchy_id: the hierarchy to look up @task's cgroup from
+ * @buf: the buffer to write the path into
+ * @buflen: the length of the buffer
+ *
+ * Determine @task's cgroup on the hierarchy specified by @hierarchy_id and
+ * copy its path into @buf. This function grabs cgroup_mutex and shouldn't
+ * be used inside locks used by cgroup controller callbacks.
+ */
+int task_cgroup_path_from_hierarchy(struct task_struct *task, int hierarchy_id,
+ char *buf, size_t buflen)
+{
+ struct cgroupfs_root *root;
+ struct cgroup *cgrp = NULL;
+ int ret = -ENOENT;
+
+ mutex_lock(&cgroup_mutex);
+
+ root = idr_find(&cgroup_hierarchy_idr, hierarchy_id);
+ if (root) {
+ cgrp = task_cgroup_from_root(task, root);
+ ret = cgroup_path(cgrp, buf, buflen);
+ }
+
+ mutex_unlock(&cgroup_mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(task_cgroup_path_from_hierarchy);
+
/*
* Control Group taskset
*/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] kernel: kallsyms: memory override issue, need check destination buffer length
Chen Gang writes: > We don't export any symbols > 128 characters, but if we did then > kallsyms_expand_symbol() would overflow the buffer handed to it. > So we need check destination buffer length when copying. > > the related test: > if we define an EXPORT function which name more than 128. > will panic when call kallsyms_lookup_name by init_kprobes on booting. > after check the length (provide this patch), it is ok. > > Implementaion: > add additional destination buffer length parameter (maxlen) > if uncompressed string is too long (>= maxlen), it will be truncated. > not check the parameters whether valid, since it is a static function. Found a bug already: kernel/kallsyms.c: In function ‘kallsyms_lookup’: kernel/kallsyms.c:305:78: error: negative width in bit-field ‘’ kernel/kallsyms.c: In function ‘lookup_symbol_name’: kernel/kallsyms.c:327:78: error: negative width in bit-field ‘’ kernel/kallsyms.c: In function ‘lookup_symbol_attrs’: kernel/kallsyms.c:346:69: error: negative width in bit-field ‘’ Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] hfs/hfsplus: Convert dprint to hfs_dbg
--- On Mon, 15/4/13, Joe Perches wrote:
> On Mon, 2013-04-15 at 02:56 +0100,
> Hin-Tak Leung wrote:
> > --- On Mon, 15/4/13, Joe Perches
> wrote:
> > > On Mon, 2013-04-15 at 01:53 +0100,
> > > Hin-Tak Leung wrote:
> > > > --- On Mon, 8/4/13, Joe Perches
> wrote:
> > > > > Use a more current logging style.
> > > []
> > > > I have been sitting on a patch which changes
> this part
> > > of the code to dynamic debugging, and it is much
> simplier.
> []
> > > This change wouldn't work well as it would make a
> mess
> > > of output that uses no prefix (ie: emits at
> KERN_DEFAULT)
> > > with output that uses KERN_DEBUG
> > >
> > > That's the reason for _dbg and _dbg_cont.
> >
> > Hmm, I don't get it. Is there any *existing* use of
> dprint
> > in the hfplus code which is affected by your comment?
>
> Code like this prints out currently on a single line at
> KERN_DEFAULT.
>
> @@ -138,16 +138,16 @@ void hfs_bnode_dump(struct hfs_bnode
> *node)
> []
> for (i =
> be16_to_cpu(desc.num_recs); i >= 0; off -= 2, i--) {
>
> key_off = hfs_bnode_read_u16(node, off);
> -
> dprint(DBG_BNODE_MOD, " %d", key_off);
> +
> hfs_dbg_cont(BNODE_MOD, " %d", key_off);
>
> By converting this dprint() to pr_debug(), it would
> print out on a multiple lines, one for each read.
>
> That's why it should use a mechanism like dbg_cont.
>
> btw: there is no current pr_debug_cont mechanism.
That's rubbish. dprint() are compiled in/out debug printing statements, and are
entirely suppressed in unmodified kernel source (the value of DBG_MASK being
zero). So your rather large and invasive change - which is still conditional on
DBG_MASK - is just substituting one form of print nothing to another form of
print nothing.
I am not saying what I have in private is correct - otherwise I would have
submitted it a long time ago. What I am saying is that the code snipplet I
posted is functional: it is not conditional on DBG_MASK, but conditional on the
meaning of pr_debug (and only on it), which is either printing
indiscriminantly, or on/off switchable at runtime for dynamically enabled
kernel. And it is a small and non-invasive change in any case, which I can hang
on to indefinitely.
I think the current *implementation* of dprint is bad - it depending on a
modification of kernel source and re-compilation to make debug statement
visible instead of the default "print nothing". But your patch, which modifies
a lot of "print nothing" to another style of "print nothing", has no functional
consequence at all. There is no user-visible change. It changes a few hundred
lines of print nothing to another few hundred lines of print nothing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] msm fixes for 3.10
On Fri, Apr 12, 2013 at 03:43:44PM -0700, David Brown wrote: > The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: > > Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git > tags/msm-fix-3.10 > > for you to fetch changes up to 73a8c28f167c9e7bc42eafc0bcbd298031709430: > > ARM: msm: Fix uncompess.h tx underrun check (2013-04-11 09:40:35 -0700) > > > Some minor fixes for MSM for 3.10 > > - Fix a timer problem that causes missed ticks and hangs. > > - Fix a problem with the decompressor UART dropping characters. > > > Stephen Boyd (2): > ARM: msm: Stop counting before reprogramming clockevent > ARM: msm: Fix uncompess.h tx underrun check > > arch/arm/mach-msm/include/mach/uncompress.h | 2 +- > arch/arm/mach-msm/timer.c | 5 - > 2 files changed, 5 insertions(+), 2 deletions(-) Looks like the "Stop counting before reprogramming" patch has already been merged through fixes for 3.9. Since that was provided in a branch with the same SHA, there's no problem with this branch and I've pulled it, but in the future it'd be nice to get a pull request that doesn't list already merged patches since the diffstat won't match when I compare them otherwise. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] cgroup: implement task_cgroup_path_from_hierarchy()
Hey, Li. On Mon, Apr 15, 2013 at 11:49:57AM +0800, Li Zefan wrote: > But if id is invalid, idr_find() will return NULL. As long as root is not > NULL, > task_cgroup_from_root() will always return a valid cgroup. I'm hopping across multiple devel branches quickly today and somewhat tipsy. Sorry about the blabber. :) -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] hfs/hfsplus: Convert dprint to hfs_dbg
On Mon, 2013-04-15 at 04:46 +0100, Hin-Tak Leung wrote: > > By converting this dprint() to pr_debug(), it would > > print out on a multiple lines, one for each read. > > > > That's why it should use a mechanism like dbg_cont. > > > > btw: there is no current pr_debug_cont mechanism. > > That's rubbish. Don't be silly. > dprint() are compiled in/out debug printing statements, > and are entirely suppressed in unmodified kernel source Of course. > I am not saying what I have in private is correct Then your original post wasn't useful either. > What I am saying is that the code snipplet I posted is functional: Lots of code is functional, I prefer functional and correct though. cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] msm cleanup for 3.10
On Fri, Apr 12, 2013 at 03:40:42PM -0700, David Brown wrote: > The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8: > > Linux 3.9-rc1 (2013-03-03 15:11:05 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git > tags/msm-cleanup-3.10 Hi, I've pulled in all 4 branches, see two comments on the individual pull requests though. Given the date stamps on the commits, it seems like you've been sitting on these for a while. Please try to send them in sooner in future release cycles, it is perfectly OK to send a newer pull request for the same branch with a few more patches on it later on (ideally with a new tag describing the new portions). That way we don't get all the code so late, and you run a lower risk of us being grumpy because several other maintainers have also been late and we're slammed with merges. The bulk of the material for the merge window really should be in arm-soc by -rc6, with minor updates thereafter. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] powerpc/perf: Power8 PMU support
This patch adds preliminary support for the power8 PMU to perf. Signed-off-by: Michael Ellerman --- arch/powerpc/perf/Makefile |3 +- arch/powerpc/perf/power8-pmu.c | 454 2 files changed, 456 insertions(+), 1 deletion(-) create mode 100644 arch/powerpc/perf/power8-pmu.c diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile index af3fac2..472db18 100644 --- a/arch/powerpc/perf/Makefile +++ b/arch/powerpc/perf/Makefile @@ -4,7 +4,8 @@ obj-$(CONFIG_PERF_EVENTS) += callchain.o obj-$(CONFIG_PPC_PERF_CTRS)+= core-book3s.o obj64-$(CONFIG_PPC_PERF_CTRS) += power4-pmu.o ppc970-pmu.o power5-pmu.o \ - power5+-pmu.o power6-pmu.o power7-pmu.o + power5+-pmu.o power6-pmu.o power7-pmu.o \ + power8-pmu.o obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o obj-$(CONFIG_FSL_EMB_PERF_EVENT) += core-fsl-emb.o diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c new file mode 100644 index 000..106ae0b --- /dev/null +++ b/arch/powerpc/perf/power8-pmu.c @@ -0,0 +1,454 @@ +/* + * Performance counter support for POWER8 processors. + * + * Copyright 2009 Paul Mackerras, IBM Corporation. + * Copyright 2013 Michael Ellerman, IBM Corporation. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include + + +/* + * Some power8 event codes. + */ +#define PM_CYC 0x0001e +#define PM_GCT_NOSLOT_CYC 0x100f8 +#define PM_CMPLU_STALL 0x4000a /* or 0x1e054 */ +#define PM_INST_CMPL 0x2 +#define PM_BRU_FIN 0x10068 +#define PM_BR_MPRED_CMPL 0x400f6 + + +/* + * Raw event encoding for POWER8: + * + *60565248444036 32 + * | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | + * [ thresh_cmp ] [ thresh_ctl ] + * | + * thresh start/stop OR FAB match -* + * + *2824201612 8 4 0 + * | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | + * [ ] [ sample ] [cache] [ pmc ] [unit ] c m [pmcxsel ] + * || | | | + * || | | *- mark + * || *- L1/L2/L3 cache_sel | + * || | + * |*- sampling mode for marked events *- combine + * | + * *- thresh_sel + * + * Below uses IBM bit numbering. + * + * MMCR1[x:y] = unit(PMCxUNIT) + * MMCR1[x] = combine (PMCxCOMB) + * + * if pmc == 3 and unit == 0 and pmcxsel[0:6] == 0b0101011 + * # PM_MRK_FAB_RSP_MATCH + * MMCR1[20:27] = thresh_ctl (FAB_CRESP_MATCH / FAB_TYPE_MATCH) + * else if pmc == 4 and unit == 0xf and pmcxsel[0:6] == 0b0101001 + * # PM_MRK_FAB_RSP_MATCH_CYC + * MMCR1[20:27] = thresh_ctl (FAB_CRESP_MATCH / FAB_TYPE_MATCH) + * else + * MMCRA[48:55] = thresh_ctl (THRESH START/END) + * + * if thresh_sel: + * MMCRA[45:47] = thresh_sel + * + * if thresh_cmp: + * MMCRA[22:24] = thresh_cmp[0:2] + * MMCRA[25:31] = thresh_cmp[3:9] + * + * if unit == 6 or unit == 7 + * MMCRC[53:55] = cache_sel[1:3] (L2EVENT_SEL) + * else if unit == 8 or unit == 9: + * if cache_sel[0] == 0: # L3 bank + * MMCRC[47:49] = cache_sel[1:3] (L3EVENT_SEL0) + * else if cache_sel[0] == 1: + * MMCRC[50:51] = cache_sel[2:3] (L3EVENT_SEL1) + * else if cache_sel[1]: # L1 event + * MMCR1[16] = cache_sel[2] + * MMCR1[17] = cache_sel[3] + * + * if mark: + * MMCRA[63]= 1(SAMPLE_ENABLE) + * MMCRA[57:59] = sample[0:2] (RAND_SAMP_ELIG) + * MMCRA[61:62] = sample[3:4] (RAND_SAMP_MODE) + * + */ + +#define EVENT_THR_CMP_SHIFT40 /* Threshold CMP value */ +#define EVENT_THR_CMP_MASK 0x3ff +#define EVENT_THR_CTL_SHIFT32 /* Threshold control value (start/stop) */ +#define EVENT_THR_CTL_MASK 0xffull +#define EVENT_THR_SEL_SHIFT29 /* Threshold select value */ +#define EVENT_THR_SEL_MASK 0x7 +#define EVENT_THRESH_SHIFT 29 /* All threshold bits */ +#define EVENT_THRESH_MASK 0x1full +#define EVENT_SAMPLE_SHIFT 24 /* Sampling mode & eligibility */ +#define EVENT_SAMPLE_MASK 0x1f +#define EVENT_CACHE_SEL_SHIFT 20 /* L2/L3 cache select */ +#define EVENT_CACHE_S
Re: [PATCH 1/2] hfs/hfsplus: Convert dprint to hfs_dbg
--- On Mon, 15/4/13, Joe Perches wrote: > On Mon, 2013-04-15 at 04:46 +0100, > Hin-Tak Leung wrote: > > > By converting this dprint() to pr_debug(), it > would > > > print out on a multiple lines, one for each read. > > > > > > That's why it should use a mechanism like > dbg_cont. > > > > > > btw: there is no current pr_debug_cont mechanism. > > > > That's rubbish. > > Don't be silly. > > > dprint() are compiled in/out debug printing > statements, > > and are entirely suppressed in unmodified kernel > source > > Of course. > > > I am not saying what I have in private is correct > > Then your original post wasn't useful either. > > > What I am saying is that the code snipplet I posted is > functional: > > Lots of code is functional, I prefer functional > and correct though. > > cheers, Joe Hmm, you obvious has a different meaning of "functional" than I. How is converting a few hundred lines of "print nothing" to another few hundred lines of "print nothing" functional? What does it achieve? I have already voiced my (admittedly selfish) concern: changing a few hundred lines of "print nothing" to another few hundred lines of "print nothing" means some of us who have substantial work-in-progress patches needs to spend a fair amount of time on rebase, and manually resolving conflicts from rebase. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv1] crypto: caam - fix job ring cleanup code
The job ring init function creates a platform device for each job ring.
While the job ring is shutdown, e.g. while caam module removal, its
platform device was not being removed. This leads to failure while
reinsertion and then removal of caam module second time.
The following kernel crash dump appears when caam module is reinserted
and then removed again. This patch fixes it.
root@p4080ds:~# rmmod caam.ko
Unable to handle kernel paging request for data at address 0x0008
Faulting instruction address: 0xf94aca18
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=8 P4080 DS
Modules linked in: caam(-) qoriq_dbg(O) [last unloaded: caam]
NIP: f94aca18 LR: f94aca18 CTR: c029f950
REGS: eac47d60 TRAP: 0300 Tainted: G O (3.8.4-rt2)
MSR: 00029002 CR: 22022484 XER: 2000
DEAR: 0008, ESR:
TASK = e49dfaf0[2110] 'rmmod' THREAD: eac46000 CPU: 1
GPR00: f94ad3f4 eac47e10 e49dfaf0 0005 ea2ac210
GPR08: c286de68 e4977ce0 c029b1c0 0001 c029f950 10029738 100e
GPR16: 10023d00 1000cbdc 1000cb8c 1000cbb8 c07dfecc
GPR24: c07e 1000cbd8 f94e ea53cd40
NIP [f94aca18] caam_reset_hw_jr+0x18/0x1c0 [caam]
LR [f94aca18] caam_reset_hw_jr+0x18/0x1c0 [caam]
Call Trace:
[eac47e10] [eac47e30] 0xeac47e30 (unreliable)
[eac47e20] [f94ad3f4] caam_jr_shutdown+0x34/0x220 [caam]
[eac47e60] [f94ac0e4] caam_remove+0x54/0xb0 [caam]
[eac47e80] [c029fb38] __device_release_driver+0x68/0x120
[eac47e90] [c02a05c8] driver_detach+0xd8/0xe0
[eac47eb0] [c029f8e0] bus_remove_driver+0xa0/0x110
[eac47ed0] [c00768e4] sys_delete_module+0x144/0x270
[eac47f40] [c000e2f0] ret_from_syscall+0x0/0x3c
Signed-off-by: Vakul Garg
Signed-off-by: Bharat Bhushan
---
Changes in v1:
Addressed Horia's comments regarding commit log.
drivers/crypto/caam/intern.h |1 +
drivers/crypto/caam/jr.c |4
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/crypto/caam/intern.h b/drivers/crypto/caam/intern.h
index 5cd4c1b..e4a16b7 100644
--- a/drivers/crypto/caam/intern.h
+++ b/drivers/crypto/caam/intern.h
@@ -41,6 +41,7 @@ struct caam_jrentry_info {
/* Private sub-storage for a single JobR */
struct caam_drv_private_jr {
struct device *parentdev; /* points back to controller dev */
+ struct platform_device *jr_pdev;/* points to platform device for JR */
int ridx;
struct caam_job_ring __iomem *rregs;/* JobR's register space */
struct tasklet_struct irqtask;
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index 93d1407..b4aa773e 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -407,6 +407,7 @@ int caam_jr_shutdown(struct device *dev)
dma_free_coherent(dev, sizeof(struct jr_outentry) * JOBR_DEPTH,
jrp->outring, outbusaddr);
kfree(jrp->entinfo);
+ of_device_unregister(jrp->jr_pdev);
return ret;
}
@@ -454,6 +455,8 @@ int caam_jr_probe(struct platform_device *pdev, struct
device_node *np,
kfree(jrpriv);
return -EINVAL;
}
+
+ jrpriv->jr_pdev = jr_pdev;
jrdev = &jr_pdev->dev;
dev_set_drvdata(jrdev, jrpriv);
ctrlpriv->jrdev[ring] = jrdev;
@@ -472,6 +475,7 @@ int caam_jr_probe(struct platform_device *pdev, struct
device_node *np,
/* Now do the platform independent part */
error = caam_jr_init(jrdev); /* now turn on hardware */
if (error) {
+ of_device_unregister(jr_pdev);
kfree(jrpriv);
return error;
}
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] kernel: kallsyms: memory override issue, need check destination buffer length
On 2013年04月15日 10:05, Rusty Russell wrote: > Chen Gang writes: >> > We don't export any symbols > 128 characters, but if we did then >> > kallsyms_expand_symbol() would overflow the buffer handed to it. >> > So we need check destination buffer length when copying. >> > >> > the related test: >> > if we define an EXPORT function which name more than 128. >> > will panic when call kallsyms_lookup_name by init_kprobes on booting. >> > after check the length (provide this patch), it is ok. >> > >> > Implementaion: >> > add additional destination buffer length parameter (maxlen) >> > if uncompressed string is too long (>= maxlen), it will be truncated. >> > not check the parameters whether valid, since it is a static function. > Found a bug already: > > kernel/kallsyms.c: In function ‘kallsyms_lookup’: > kernel/kallsyms.c:305:78: error: negative width in bit-field ‘’ > kernel/kallsyms.c: In function ‘lookup_symbol_name’: > kernel/kallsyms.c:327:78: error: negative width in bit-field ‘’ > kernel/kallsyms.c: In function ‘lookup_symbol_attrs’: > kernel/kallsyms.c:346:69: error: negative width in bit-field ‘’ > oh... it is my fault, I will send v3. I only tested kallsyms_on_each_symbol and kallsyms_lookup_name (they were of cause OK). , not test others. ARRAY_SIZE is really valuable to help find bugs. and next, after code changes, I should compile it again, at least. :-) > Cheers, -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KVM: ARM: Fix wrong address in comment
On Wed, Apr 10, 2013 at 7:37 PM, Jonghwan Choi wrote: > hyp_hvc vector offset should be 0x14 and hyp_svc vector offset should be > 0x8. > > Signed-off-by: Jonghwan Choi > --- > arch/arm/kvm/interrupts.S |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S > index 8ca87ab..a8e0c2d 100644 > --- a/arch/arm/kvm/interrupts.S > +++ b/arch/arm/kvm/interrupts.S > @@ -235,9 +235,9 @@ ENTRY(kvm_call_hyp) > * instruction is issued since all traps are disabled when running the host > * kernel as per the Hyp-mode initialization at boot time. > * > - * HVC instructions cause a trap to the vector page + offset 0x18 (see > hyp_hvc > + * HVC instructions cause a trap to the vector page + offset 0x14 (see > hyp_hvc > * below) when the HVC instruction is called from SVC mode (i.e. a guest or > the > - * host kernel) and they cause a trap to the vector page + offset 0xc when > HVC > + * host kernel) and they cause a trap to the vector page + offset 0x8 when > HVC > * instructions are called from within Hyp-mode. > * > * Hyp-ABI: Calling HYP-mode functions from host (in SVC mode): > -- > 1.7.9.5 > this has already been applied: https://github.com/columbia/linux-kvm-arm/commit/0b5e3bac30c545720f7e6b026241b5f8dd832df2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] hfs/hfsplus: Convert dprint to hfs_dbg
On Mon, 2013-04-15 at 05:22 +0100, Hin-Tak Leung wrote: > How is converting a few hundred lines of "print nothing" to > another few hundred lines of "print nothing" functional? > What does it achieve? Standardization of output style when enabled. Easier conversion to pr_debug/dynamic_debugging. Emitting at KERN_DEBUG when enabled. Besides, I was also doing the other logging conversions at the same time to prefix hfs differently than hfsplus. I don't really care much when this stuff is done, (it took about 10 minutes and it's about all automatic and scripted) but I do think it should be done. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] kernel: kallsyms: memory override issue, need check destination buffer length
We don't export any symbols > 128 characters, but if we did then
kallsyms_expand_symbol() would overflow the buffer handed to it.
So we need check destination buffer length when copying.
the related test:
if we define an EXPORT function which name more than 128.
will panic when call kallsyms_lookup_name by init_kprobes on booting.
after check the length (provide this patch), it is ok.
Implementaion:
add additional destination buffer length parameter (maxlen)
if uncompressed string is too long (>= maxlen), it will be truncated.
not check the parameters whether valid, since it is a static function.
Signed-off-by: Chen Gang
---
kernel/kallsyms.c | 26 ++
1 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 2169fee..3127ad5 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -84,9 +84,11 @@ static int is_ksym_addr(unsigned long addr)
/*
* Expand a compressed symbol data into the resulting uncompressed string,
+ * if uncompressed string is too long (>= maxlen), it will be truncated,
* given the offset to where the symbol is in the compressed stream.
*/
-static unsigned int kallsyms_expand_symbol(unsigned int off, char *result)
+static unsigned int kallsyms_expand_symbol(unsigned int off,
+ char *result, size_t maxlen)
{
int len, skipped_first = 0;
const u8 *tptr, *data;
@@ -113,15 +115,20 @@ static unsigned int kallsyms_expand_symbol(unsigned int
off, char *result)
while (*tptr) {
if (skipped_first) {
+ if (maxlen <= 1)
+ goto tail;
*result = *tptr;
result++;
+ maxlen--;
} else
skipped_first = 1;
tptr++;
}
}
- *result = '\0';
+tail:
+ if (maxlen)
+ *result = '\0';
/* Return to offset to the next symbol. */
return off;
@@ -176,7 +183,7 @@ unsigned long kallsyms_lookup_name(const char *name)
unsigned int off;
for (i = 0, off = 0; i < kallsyms_num_syms; i++) {
- off = kallsyms_expand_symbol(off, namebuf);
+ off = kallsyms_expand_symbol(off, namebuf, ARRAY_SIZE(namebuf));
if (strcmp(namebuf, name) == 0)
return kallsyms_addresses[i];
@@ -195,7 +202,7 @@ int kallsyms_on_each_symbol(int (*fn)(void *, const char *,
struct module *,
int ret;
for (i = 0, off = 0; i < kallsyms_num_syms; i++) {
- off = kallsyms_expand_symbol(off, namebuf);
+ off = kallsyms_expand_symbol(off, namebuf, ARRAY_SIZE(namebuf));
ret = fn(data, namebuf, NULL, kallsyms_addresses[i]);
if (ret != 0)
return ret;
@@ -294,7 +301,8 @@ const char *kallsyms_lookup(unsigned long addr,
pos = get_symbol_pos(addr, symbolsize, offset);
/* Grab name */
- kallsyms_expand_symbol(get_symbol_offset(pos), namebuf);
+ kallsyms_expand_symbol(get_symbol_offset(pos),
+ namebuf, KSYM_NAME_LEN);
if (modname)
*modname = NULL;
return namebuf;
@@ -315,7 +323,8 @@ int lookup_symbol_name(unsigned long addr, char *symname)
pos = get_symbol_pos(addr, NULL, NULL);
/* Grab name */
- kallsyms_expand_symbol(get_symbol_offset(pos), symname);
+ kallsyms_expand_symbol(get_symbol_offset(pos),
+ symname, KSYM_NAME_LEN);
return 0;
}
/* See if it's in a module. */
@@ -333,7 +342,8 @@ int lookup_symbol_attrs(unsigned long addr, unsigned long
*size,
pos = get_symbol_pos(addr, size, offset);
/* Grab name */
- kallsyms_expand_symbol(get_symbol_offset(pos), name);
+ kallsyms_expand_symbol(get_symbol_offset(pos),
+ name, KSYM_NAME_LEN);
modname[0] = '\0';
return 0;
}
@@ -463,7 +473,7 @@ static unsigned long get_ksymbol_core(struct kallsym_iter
*iter)
iter->type = kallsyms_get_symbol_type(off);
- off = kallsyms_expand_symbol(off, iter->name);
+ off = kallsyms_expand_symbol(off, iter->name, ARRAY_SIZE(iter->name));
return off - iter->nameoff;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] kexec: X86: Pass memory ranges via e820 table instead of memmap= boot parameter
(2013/04/13 7:17), Dave Hansen wrote: On 04/12/2013 07:56 AM, H. Peter Anvin wrote: On 04/12/2013 07:31 AM, Vivek Goyal wrote: I also have to admit that I don't see the difference between /dev/mem and /dev/oldmem, as the former allows access to memory ranges outside the ones used by the current kernel, which is what the oldmem device seems to be intended to od. It varies from arch to arch of course. But, /dev/mem has restrictions on it, like CONFIG_STRICT_DEVMEM or the ARCH_HAS_VALID_PHYS_ADDR_RANGE. There's a lot of stuff that depends on it, *and* folks have tried to fix it up so that it's not _as_ blatant of a way to completely screw your system. /dev/mem also tries to be nice to arches that have restrictions like: /* * On ia64 if a page has been mapped somewhere as * uncached, then it must also be accessed uncached * by the kernel or data corruption may occur */ I think /dev/oldmem isn't so nice and could actually cause some real problems if used on ia64 where the cached/uncached accesses are mixed. This sounds like there's no such issue on x86 cache mechanism. Is it correct? If so, what is the difference between ia64 and x86 cache mechanisms? -- Thanks. HATAYAMA, Daisuke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 00/19] kill free_all_bootmem() and clean up VALID_PAGE()
On Sat, Apr 13, 2013 at 11:36:20PM +0800, Jiang Liu wrote: > Commit 600cc5b7f6 "mm: Kill NO_BOOTMEM version free_all_bootmem_node()" > has kill free_all_bootmem_node() for NO_BOOTMEM. > > Currently the usage pattern for free_all_bootmem_node() is like: > for_each_online_pgdat(pgdat) > free_all_bootmem_node(pgdat); > > It's equivalent to free_all_bootmem(), so this patchset goes one > step further to kill free_all_bootmem_node() for BOOTMEM too. > > This patchset also tries to clean up code and comments related to > VALID_PAGE() because it has been removed from kernel long time ago. > > Patch 1-11: > Kill free_all_bootmem_node() > Patch 12-16: > Clean up code and comments related to VALID_PAGE() > Patch 17: > Fix a minor build warning for m68k > Patch 18: > merge Alpha's mem_init() for UMA and NUMA. > Patch 19: > call register_page_bootmem_info_node() from mm core How does this not break bisection? Will a kernel still boot with patches 1-11 applied but not patch 19? As far as I can see such a kernel would have no memory available to it after mem_init() time and would therefore crash early in boot. Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the clk tree
Hi Mike,
After merging the clk tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
ERROR: "of_clk_add_provider" [drivers/clk/clk-si5351.ko] undefined!
ERROR: "of_clk_src_onecell_get" [drivers/clk/clk-si5351.ko] undefined!
ERROR: "__clk_get_flags" [drivers/clk/clk-si5351.ko] undefined!
Caused by commit 9abd5f0555df ("clk: add si5351 i2c common clock
driver"). It probbaly need to depend on CONFIG_OF.
I have used the clk tree from next-20130412 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpTDfKFkeqWL.pgp
Description: PGP signature
[PATCH 06/10] perf util: Get rid of unused header_page_* variables
From: Namhyung Kim They're not used anywhere and same information is kept in a pevent already. So let's get rid of them. Signed-off-by: Namhyung Kim --- tools/perf/util/trace-event-parse.c | 4 tools/perf/util/trace-event.h | 4 2 files changed, 8 deletions(-) diff --git a/tools/perf/util/trace-event-parse.c b/tools/perf/util/trace-event-parse.c index 4454835a9ebc..0deae885c7ba 100644 --- a/tools/perf/util/trace-event-parse.c +++ b/tools/perf/util/trace-event-parse.c @@ -28,10 +28,6 @@ #include "util.h" #include "trace-event.h" -int header_page_size_size; -int header_page_ts_size; -int header_page_data_offset; - bool latency_format; struct pevent *read_trace_init(int file_bigendian, int host_bigendian) diff --git a/tools/perf/util/trace-event.h b/tools/perf/util/trace-event.h index 1978c398ad87..10d6e7b202c5 100644 --- a/tools/perf/util/trace-event.h +++ b/tools/perf/util/trace-event.h @@ -10,10 +10,6 @@ struct perf_sample; union perf_event; struct perf_tool; -extern int header_page_size_size; -extern int header_page_ts_size; -extern int header_page_data_offset; - extern bool latency_format; extern struct pevent *perf_pevent; -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/10] perf util: Move latency_format variable to builtin-script.c
From: Namhyung Kim
It's the only user of the variable, so move it.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-script.c | 1 +
tools/perf/util/trace-event-parse.c | 2 --
tools/perf/util/trace-event.h | 1 -
3 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 92d4658f56fb..3de8979fe87d 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -24,6 +24,7 @@ static u64last_timestamp;
static u64 nr_unordered;
extern const struct option record_options[];
static boolno_callchain;
+static boollatency_format;
static boolsystem_wide;
static const char *cpu_list;
static DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
diff --git a/tools/perf/util/trace-event-parse.c
b/tools/perf/util/trace-event-parse.c
index 0deae885c7ba..fe7a27d67d2b 100644
--- a/tools/perf/util/trace-event-parse.c
+++ b/tools/perf/util/trace-event-parse.c
@@ -28,8 +28,6 @@
#include "util.h"
#include "trace-event.h"
-bool latency_format;
-
struct pevent *read_trace_init(int file_bigendian, int host_bigendian)
{
struct pevent *pevent = pevent_alloc();
diff --git a/tools/perf/util/trace-event.h b/tools/perf/util/trace-event.h
index 10d6e7b202c5..96ad22f98726 100644
--- a/tools/perf/util/trace-event.h
+++ b/tools/perf/util/trace-event.h
@@ -10,7 +10,6 @@ struct perf_sample;
union perf_event;
struct perf_tool;
-extern bool latency_format;
extern struct pevent *perf_pevent;
enum {
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/10] perf util: Rename read_*() functions in trace-event-info.c
From: Namhyung Kim
It's confusing to have same name for two difference functions which
does something opposite way. Since what they do in this file is read
*AND* writing some of tracing metadata files, rename them to
record_*() looks better to me.
Signed-off-by: Namhyung Kim
---
tools/perf/util/trace-event-info.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/trace-event-info.c
b/tools/perf/util/trace-event-info.c
index 3917eb9a8479..9648175e2a1c 100644
--- a/tools/perf/util/trace-event-info.c
+++ b/tools/perf/util/trace-event-info.c
@@ -160,7 +160,7 @@ out:
return err;
}
-static int read_header_files(void)
+static int record_header_files(void)
{
char *path;
struct stat st;
@@ -299,7 +299,7 @@ out:
return err;
}
-static int read_ftrace_files(struct tracepoint_path *tps)
+static int record_ftrace_files(struct tracepoint_path *tps)
{
char *path;
int ret;
@@ -328,7 +328,7 @@ static bool system_in_tp_list(char *sys, struct
tracepoint_path *tps)
return false;
}
-static int read_event_files(struct tracepoint_path *tps)
+static int record_event_files(struct tracepoint_path *tps)
{
struct dirent *dent;
struct stat st;
@@ -403,7 +403,7 @@ out:
return err;
}
-static int read_proc_kallsyms(void)
+static int record_proc_kallsyms(void)
{
unsigned int size;
const char *path = "/proc/kallsyms";
@@ -421,7 +421,7 @@ static int read_proc_kallsyms(void)
return record_file(path, 4);
}
-static int read_ftrace_printk(void)
+static int record_ftrace_printk(void)
{
unsigned int size;
char *path;
@@ -583,19 +583,19 @@ struct tracing_data *tracing_data_get(struct list_head
*pattrs,
err = tracing_data_header();
if (err)
goto out;
- err = read_header_files();
+ err = record_header_files();
if (err)
goto out;
- err = read_ftrace_files(tps);
+ err = record_ftrace_files(tps);
if (err)
goto out;
- err = read_event_files(tps);
+ err = record_event_files(tps);
if (err)
goto out;
- err = read_proc_kallsyms();
+ err = record_proc_kallsyms();
if (err)
goto out;
- err = read_ftrace_printk();
+ err = record_ftrace_printk();
out:
/*
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/10] perf util: Make file/host_bigendian variable local
From: Namhyung Kim They're not used anywhere, just make them local variables. Signed-off-by: Namhyung Kim --- tools/perf/util/trace-event-read.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/trace-event-read.c b/tools/perf/util/trace-event-read.c index 6166294d7f22..0dd9fbda88eb 100644 --- a/tools/perf/util/trace-event-read.c +++ b/tools/perf/util/trace-event-read.c @@ -39,9 +39,6 @@ static int input_fd; -int file_bigendian; -int host_bigendian; - static ssize_t trace_data_size; static bool repipe; @@ -342,6 +339,8 @@ ssize_t trace_report(int fd, struct pevent **ppevent, bool __repipe) int show_funcs = 0; int show_printk = 0; ssize_t size = -1; + int file_bigendian; + int host_bigendian; int file_long_size; int file_page_size; struct pevent *pevent; -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/10] perf util: No need to call read_trace_init() in tracing_data_header()
From: Namhyung Kim It's useless to call the read_trace_init() function at this time as we don't need a returned pevent and it makes me confusing. :) Signed-off-by: Namhyung Kim --- tools/perf/util/trace-event-info.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/tools/perf/util/trace-event-info.c b/tools/perf/util/trace-event-info.c index 9648175e2a1c..e85cbcf298f3 100644 --- a/tools/perf/util/trace-event-info.c +++ b/tools/perf/util/trace-event-info.c @@ -520,8 +520,6 @@ static int tracing_data_header(void) else buf[0] = 0; - read_trace_init(buf[0], buf[0]); - if (write(output_fd, buf, 1) != 1) return -1; -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/10] perf util: Remove unused enum and macro in trace-event.h
From: Namhyung Kim
They're internals of ftrace ring-buffer and not used in perf code
directly. As it now resides on libtraceevent/kbuffer.h, just get
rid of them.
Signed-off-by: Namhyung Kim
---
tools/perf/util/trace-event.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/tools/perf/util/trace-event.h b/tools/perf/util/trace-event.h
index 96ad22f98726..929baae82f71 100644
--- a/tools/perf/util/trace-event.h
+++ b/tools/perf/util/trace-event.h
@@ -12,16 +12,6 @@ struct perf_tool;
extern struct pevent *perf_pevent;
-enum {
- RINGBUF_TYPE_PADDING= 29,
- RINGBUF_TYPE_TIME_EXTEND= 30,
- RINGBUF_TYPE_TIME_STAMP = 31,
-};
-
-#ifndef TS_SHIFT
-#define TS_SHIFT 27
-#endif
-
int bigendian(void);
struct pevent *read_trace_init(int file_bigendian, int host_bigendian);
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/10] perf util: Parse header_page to get proper long size
From: Namhyung Kim
The header_page file describes the format of the ring buffer page
which is used by ftrace (not perf). And size of "commit" field (I
guess it's older name was 'size') represents the real size of long
type used for kernel. So update the pevent's long size.
Signed-off-by: Namhyung Kim
---
tools/perf/util/trace-event-read.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/trace-event-read.c
b/tools/perf/util/trace-event-read.c
index fa45fca2a2d3..b4e8bdd13671 100644
--- a/tools/perf/util/trace-event-read.c
+++ b/tools/perf/util/trace-event-read.c
@@ -212,6 +212,7 @@ static int read_ftrace_printk(struct pevent *pevent)
static int read_header_files(struct pevent *pevent)
{
unsigned long long size;
+ char *header_page;
char buf[BUFSIZ];
int ret = 0;
@@ -224,7 +225,23 @@ static int read_header_files(struct pevent *pevent)
}
size = read8(pevent);
- skip(size);
+
+ if (do_read(buf, size) < 0)
+ return -1;
+
+ header_page = malloc(size);
+ if (header_page == NULL)
+ return -1;
+
+ if (!pevent_parse_header_page(pevent, header_page, size,
+ pevent_get_long_size(pevent))) {
+ /*
+* The commit field in the page is of type long,
+* use that instead, since it represents the kernel.
+*/
+ pevent_set_long_size(pevent, pevent->header_page_size_size);
+ }
+ free(header_page);
if (do_read(buf, 13) < 0)
return -1;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/10] perf util: Skip reading header_event file
From: Namhyung Kim
It seems perf does not parse header_event file so we can skip it as we
do for header_page file.
Signed-off-by: Namhyung Kim
---
tools/perf/util/trace-event-read.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/tools/perf/util/trace-event-read.c
b/tools/perf/util/trace-event-read.c
index 0dd9fbda88eb..fa45fca2a2d3 100644
--- a/tools/perf/util/trace-event-read.c
+++ b/tools/perf/util/trace-event-read.c
@@ -212,7 +212,6 @@ static int read_ftrace_printk(struct pevent *pevent)
static int read_header_files(struct pevent *pevent)
{
unsigned long long size;
- char *header_event;
char buf[BUFSIZ];
int ret = 0;
@@ -236,14 +235,8 @@ static int read_header_files(struct pevent *pevent)
}
size = read8(pevent);
- header_event = malloc(size);
- if (header_event == NULL)
- return -1;
-
- if (do_read(header_event, size) < 0)
- ret = -1;
+ skip(size);
- free(header_event);
return ret;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
