Re: [PATCH v2 5/5] module: Remove stop_machine from module unloading
Masami Hiramatsu writes: > Remove stop_machine from module unloading by adding new reference > counting algorithm. Thankyou! I have applied these to my tree, and they will enter Linus' next merge window. Thanks! Rusty. PS. I created stop_machine for module unloading and CPU hotplug. Maybe we'll get to remove it altogether soon :) -- 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 3.10 21/43] m68k: Disable/restore interrupts in hwreg_present()/hwreg_write()
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Geert Uytterhoeven
commit e4dc601bf99ccd1c95b7e6eef1d3cf3c4b0d4961 upstream.
hwreg_present() and hwreg_write() temporarily change the VBR register to
another vector table. This table contains a valid bus error handler
only, all other entries point to arbitrary addresses.
If an interrupt comes in while the temporary table is active, the
processor will start executing at such an arbitrary address, and the
kernel will crash.
While most callers run early, before interrupts are enabled, or
explicitly disable interrupts, Finn Thain pointed out that macsonic has
one callsite that doesn't, causing intermittent boot crashes.
There's another unsafe callsite in hilkbd.
Fix this for good by disabling and restoring interrupts inside
hwreg_present() and hwreg_write().
Explicitly disabling interrupts can be removed from the callsites later.
Reported-by: Finn Thain
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Greg Kroah-Hartman
---
arch/m68k/mm/hwtest.c |6 ++
1 file changed, 6 insertions(+)
--- a/arch/m68k/mm/hwtest.c
+++ b/arch/m68k/mm/hwtest.c
@@ -28,9 +28,11 @@
int hwreg_present( volatile void *regp )
{
intret = 0;
+unsigned long flags;
long save_sp, save_vbr;
long tmp_vectors[3];
+local_irq_save(flags);
__asm__ __volatile__
( "movec %/vbr,%2\n\t"
"movel #Lberr1,%4@(8)\n\t"
@@ -46,6 +48,7 @@ int hwreg_present( volatile void *regp )
: "=" (ret), "=" (save_sp), "=" (save_vbr)
: "a" (regp), "a" (tmp_vectors)
);
+local_irq_restore(flags);
return( ret );
}
@@ -58,9 +61,11 @@ EXPORT_SYMBOL(hwreg_present);
int hwreg_write( volatile void *regp, unsigned short val )
{
int ret;
+ unsigned long flags;
longsave_sp, save_vbr;
longtmp_vectors[3];
+ local_irq_save(flags);
__asm__ __volatile__
( "movec %/vbr,%2\n\t"
"movel #Lberr2,%4@(8)\n\t"
@@ -78,6 +83,7 @@ int hwreg_write( volatile void *regp, un
: "=" (ret), "=" (save_sp), "=" (save_vbr)
: "a" (regp), "a" (tmp_vectors), "g" (val)
);
+ local_irq_restore(flags);
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/
[PATCH 3.10 20/43] Drivers: hv: vmbus: Fix a bug in vmbus_open()
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: "K. Y. Srinivasan"
commit 45d727cee9e200f5b351528b9fb063b69cf702c8 upstream.
Fix a bug in vmbus_open() and properly propagate the error. I would
like to thank Dexuan Cui for identifying the
issue.
Signed-off-by: K. Y. Srinivasan
Tested-by: Sitsofe Wheeler
Signed-off-by: Greg Kroah-Hartman
---
drivers/hv/channel.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -199,8 +199,10 @@ int vmbus_open(struct vmbus_channel *new
ret = vmbus_post_msg(open_msg,
sizeof(struct vmbus_channel_open_channel));
- if (ret != 0)
+ if (ret != 0) {
+ err = ret;
goto error1;
+ }
t = wait_for_completion_timeout(_info->waitevent, 5*HZ);
if (t == 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/
[PATCH 3.10 22/43] Documentation: lzo: document part of the encoding
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Willy Tarreau
commit d98a0526434d27e261f622cf9d2e0028b5ff1a00 upstream.
Add a complete description of the LZO format as processed by the
decompressor. I have not found a public specification of this format
hence this analysis, which will be used to better understand the code.
Cc: Willem Pinckaers
Cc: "Don A. Bailey"
Signed-off-by: Willy Tarreau
Signed-off-by: Greg Kroah-Hartman
---
Documentation/lzo.txt | 164 ++
1 file changed, 164 insertions(+)
--- /dev/null
+++ b/Documentation/lzo.txt
@@ -0,0 +1,164 @@
+
+LZO stream format as understood by Linux's LZO decompressor
+===
+
+Introduction
+
+ This is not a specification. No specification seems to be publicly available
+ for the LZO stream format. This document describes what input format the LZO
+ decompressor as implemented in the Linux kernel understands. The file subject
+ of this analysis is lib/lzo/lzo1x_decompress_safe.c. No analysis was made on
+ the compressor nor on any other implementations though it seems likely that
+ the format matches the standard one. The purpose of this document is to
+ better understand what the code does in order to propose more efficient fixes
+ for future bug reports.
+
+Description
+
+ The stream is composed of a series of instructions, operands, and data. The
+ instructions consist in a few bits representing an opcode, and bits forming
+ the operands for the instruction, whose size and position depend on the
+ opcode and on the number of literals copied by previous instruction. The
+ operands are used to indicate :
+
+- a distance when copying data from the dictionary (past output buffer)
+- a length (number of bytes to copy from dictionary)
+- the number of literals to copy, which is retained in variable "state"
+ as a piece of information for next instructions.
+
+ Optionally depending on the opcode and operands, extra data may follow. These
+ extra data can be a complement for the operand (eg: a length or a distance
+ encoded on larger values), or a literal to be copied to the output buffer.
+
+ The first byte of the block follows a different encoding from other bytes, it
+ seems to be optimized for literal use only, since there is no dictionary yet
+ prior to that byte.
+
+ Lengths are always encoded on a variable size starting with a small number
+ of bits in the operand. If the number of bits isn't enough to represent the
+ length, up to 255 may be added in increments by consuming more bytes with a
+ rate of at most 255 per extra byte (thus the compression ratio cannot exceed
+ around 255:1). The variable length encoding using #bits is always the same :
+
+ length = byte & ((1 << #bits) - 1)
+ if (!length) {
+ length = ((1 << #bits) - 1)
+ length += 255*(number of zero bytes)
+ length += first-non-zero-byte
+ }
+ length += constant (generally 2 or 3)
+
+ For references to the dictionary, distances are relative to the output
+ pointer. Distances are encoded using very few bits belonging to certain
+ ranges, resulting in multiple copy instructions using different encodings.
+ Certain encodings involve one extra byte, others involve two extra bytes
+ forming a little-endian 16-bit quantity (marked LE16 below).
+
+ After any instruction except the large literal copy, 0, 1, 2 or 3 literals
+ are copied before starting the next instruction. The number of literals that
+ were copied may change the meaning and behaviour of the next instruction. In
+ practice, only one instruction needs to know whether 0, less than 4, or more
+ literals were copied. This is the information stored in the variable
+ in this implementation. This number of immediate literals to be copied is
+ generally encoded in the last two bits of the instruction but may also be
+ taken from the last two bits of an extra operand (eg: distance).
+
+ End of stream is declared when a block copy of distance 0 is seen. Only one
+ instruction may encode this distance (0001HLLL), it takes one LE16 operand
+ for the distance, thus requiring 3 bytes.
+
+ IMPORTANT NOTE : in the code some length checks are missing because certain
+ instructions are called under the assumption that a certain number of bytes
+ follow because it has already been garanteed before parsing the instructions.
+ They just have to "refill" this credit if they consume extra bytes. This is
+ an implementation design choice independant on the algorithm or encoding.
+
+Byte sequences
+
+ First byte encoding :
+
+ 0..17 : follow regular instruction encoding, see below. It is worth
+noting that codes 16 and 17 will represent a block copy from
+the dictionary which is empty, and that they will always be
+
Re: [PATCH 2/3] introduce probe_slab_address()
В Вт, 28/10/2014 в 08:44 +0300, Kirill Tkhai пишет:
> В Пн, 27/10/2014 в 20:54 +0100, Oleg Nesterov пишет:
> > Extract the ifdef(CONFIG_DEBUG_PAGEALLOC) code from get_freepointer_safe()
> > into the new generic helper, probe_slab_address(). The next patch will add
> > another user.
> >
> > Signed-off-by: Oleg Nesterov
> > ---
> > include/linux/uaccess.h | 15 +++
> > mm/slub.c |6 +-
> > 2 files changed, 16 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
> > index effb637..3367396 100644
> > --- a/include/linux/uaccess.h
> > +++ b/include/linux/uaccess.h
> > @@ -71,6 +71,21 @@ static inline unsigned long
> > __copy_from_user_nocache(void *to,
> > __probe_kernel_read(&(retval), (__force void *)(addr), sizeof(retval))
> >
> > /*
> > + * Same as probe_kernel_address(), but @addr must be the valid pointer
> > + * to a slab object, potentially freed/reused/unmapped.
> > + */
> > +#ifdef CONFIG_DEBUG_PAGEALLOC
> > +#define probe_slab_address(addr, retval) \
> > + probe_kernel_address(addr, retval)
> > +#else
> > +#define probe_slab_address(addr, retval) \
> > + ({ \
> > + (retval) = *(typeof(retval) *)(addr); \
> > + 0; \
> > + })
> > +#endif
> > +
> > +/*
> > * probe_kernel_read(): safely attempt to read from a location
> > * @dst: pointer to the buffer that shall take the data
> > * @src: address to read from
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 3e8afcc..0467d22 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -265,11 +265,7 @@ static inline void *get_freepointer_safe(struct
> > kmem_cache *s, void *object)
> > {
> > void *p;
> >
> > -#ifdef CONFIG_DEBUG_PAGEALLOC
> > - probe_kernel_read(, (void **)(object + s->offset), sizeof(p));
> > -#else
> > - p = get_freepointer(s, object);
> > -#endif
> > + probe_slab_address(object + s->offset, p);
> > return p;
> > }
> >
>
> probe_kernel_read() was arch-dependent on tree platforms:
Of course, I mean get_freepointer_safe() used to use arch-dependent
probe_kernel_read() on blackfin, parisc and um.
> arch/blackfin/mm/maccess.c
> arch/parisc/lib/memcpy.c
> arch/um/kernel/maccess.c
>
> But now we skip these arch-dependent implementations. Is there no a problem?
--
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/3] introduce probe_slab_address()
В Пн, 27/10/2014 в 20:54 +0100, Oleg Nesterov пишет:
> Extract the ifdef(CONFIG_DEBUG_PAGEALLOC) code from get_freepointer_safe()
> into the new generic helper, probe_slab_address(). The next patch will add
> another user.
>
> Signed-off-by: Oleg Nesterov
> ---
> include/linux/uaccess.h | 15 +++
> mm/slub.c |6 +-
> 2 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
> index effb637..3367396 100644
> --- a/include/linux/uaccess.h
> +++ b/include/linux/uaccess.h
> @@ -71,6 +71,21 @@ static inline unsigned long __copy_from_user_nocache(void
> *to,
> __probe_kernel_read(&(retval), (__force void *)(addr), sizeof(retval))
>
> /*
> + * Same as probe_kernel_address(), but @addr must be the valid pointer
> + * to a slab object, potentially freed/reused/unmapped.
> + */
> +#ifdef CONFIG_DEBUG_PAGEALLOC
> +#define probe_slab_address(addr, retval) \
> + probe_kernel_address(addr, retval)
> +#else
> +#define probe_slab_address(addr, retval) \
> + ({ \
> + (retval) = *(typeof(retval) *)(addr); \
> + 0; \
> + })
> +#endif
> +
> +/*
> * probe_kernel_read(): safely attempt to read from a location
> * @dst: pointer to the buffer that shall take the data
> * @src: address to read from
> diff --git a/mm/slub.c b/mm/slub.c
> index 3e8afcc..0467d22 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -265,11 +265,7 @@ static inline void *get_freepointer_safe(struct
> kmem_cache *s, void *object)
> {
> void *p;
>
> -#ifdef CONFIG_DEBUG_PAGEALLOC
> - probe_kernel_read(, (void **)(object + s->offset), sizeof(p));
> -#else
> - p = get_freepointer(s, object);
> -#endif
> + probe_slab_address(object + s->offset, p);
> return p;
> }
>
probe_kernel_read() was arch-dependent on tree platforms:
arch/blackfin/mm/maccess.c
arch/parisc/lib/memcpy.c
arch/um/kernel/maccess.c
But now we skip these arch-dependent implementations. Is there no a problem?
Kirill
--
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] arm64: ARCH_PFN_OFFSET should be unsigned long
pfns are unsigned long, but PHYS_PFN_OFFSET is phys_addr_t. This leads to page_to_pfn() returning phys_addr_t which cause type mismatches in some print statements. Signed-off-by: Neil Zhang --- arch/arm64/include/asm/memory.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h index ccc7087..a62cd07 100644 --- a/arch/arm64/include/asm/memory.h +++ b/arch/arm64/include/asm/memory.h @@ -142,7 +142,7 @@ static inline void *phys_to_virt(phys_addr_t x) * virt_to_page(k)convert a _valid_ virtual address to struct page * * virt_addr_valid(k) indicates whether a virtual address is valid */ -#define ARCH_PFN_OFFSETPHYS_PFN_OFFSET +#define ARCH_PFN_OFFSET((unsigned long)PHYS_PFN_OFFSET) #define virt_to_page(kaddr)pfn_to_page(__pa(kaddr) >> PAGE_SHIFT) #definevirt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT) -- 1.7.9.5 -- 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: Re: [PATCH V4] kernel, add bug_on_warn
(2014/10/28 3:15), Prarit Bhargava wrote: > > > On 10/27/2014 02:05 PM, Jason Baron wrote: >> Hi Prarit, >> >> On 10/24/2014 08:53 AM, Prarit Bhargava wrote: >>> There have been several times where I have had to rebuild a kernel to >>> cause a panic when hitting a WARN() in the code in order to get a crash >>> dump from a system. Sometimes this is easy to do, other times (such as >>> in the case of a remote admin) it is not trivial to send new images to the >>> user.panic_on_stackoverflow >>> >>> A much easier method would be a switch to change the WARN() over to a >>> BUG(). This makes debugging easier in that I can now test the actual >>> image the WARN() was seen on and I do not have to engage in remote >>> debugging. >>> >>> This patch adds a bug_on_warn kernel parameter and >>> /proc/sys/kernel/bug_on_warn calls BUG() in the warn_slowpath_common() >>> path. The function will still print out the location of the warning. >>> >>> An example of the bug_on_warn output: >>> >>> The first line below is from the WARN_ON() to output the WARN_ON()'s >>> location. >>> After that the new BUG() call is displayed. >>> >>> WARNING: CPU: 27 PID: 3204 at >>> /home/rhel7/redhat/debug/dummy-module/dummy-module.c:25 init_dummy+0x28/0x30 >>> [dummy_module]() >>> bug_on_warn set, calling BUG()... >>> [ cut here ] >>> kernel BUG at kernel/panic.c:434! >> >> Seems reasonable-I'm wondering why you just don't call panic() in this >> case. The BUG() call at line '434' doesn't at anything since its just being >> called from panic.c. +1, I like calling panic() instead of BUG() :) Thank you, > > Hmm ... I didn't even think about that. > >> >> So something like 'panic_on_warn' would seem to be more appropriate >> in keeping with things like 'panic_on_oops' or 'panic_on_stackoverflow'. > > I like it a lot better that way too :) I'm changing it to panic_on_warn > unless > anyone has any strenuous objections. > > P. > >> >> Thanks, >> >> -Jason >> > -- > 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/ > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- 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] thermal-soc changes
Hi, Eduardo, On 一, 2014-10-27 at 15:53 -0400, Eduardo Valentin wrote: > Hello Rui, > > On Thu, Oct 23, 2014 at 07:27:24AM -0400, Eduardo Valentin wrote: > > Hello Rui, > > > > On Thu, Oct 23, 2014 at 01:15:45PM +0800, Zhang Rui wrote: > > > On 二, 2014-10-21 at 09:49 -0400, Eduardo Valentin wrote: > > > > Hello Rui, > > > > > > > > Here are a couple of changes that are in my tree. They include: > > > > - a few code refactoring improving the Exynos code base; > > > > - new feature on the Exynos code base (TRIMINFO and TRIMRELOAD); > > > > - a documentation of RCAR thermal; and > > > > - a fix in the of-thermal, regarding the proper usage of of APIs. > > > > > > > what's their target? > > > please send me separate pull requests for different targets. > > > > > > > All are for 3.18, I forgot to mention. > > Any updates? > Well, I'm on a trip, and unfortunately, my Linux laptop is broken for the moment. so I think first we should keep all the patches for 3.18-rc in your tree to get tested, and then either I can send out the pull request at around 20th Nov, after coming back from travel, or you can help me send the pull request for 3.18-rc. thanks, rui > > > > BR, > > > > Eduardo Valentin > > > > > thanks, > > > rui > > > > They are based on your next branch. > > > > > > > > BR, > > > > > > > > Eduardo Valentin > > > > > > > > The following changes since commit > > > > 6ceaf58abe25e86292152005c51169796bad3407: > > > > > > > > Merge branch 'int340x-thermal' of .git into next (2014-10-17 14:30:58 > > > > +0800) > > > > > > > > are available in the git repository at: > > > > > > > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git > > > > next > > > > > > > > for you to fetch changes up to df67e40f51398fef8dd705dfe4e287ad9b10ba4b: > > > > > > > > thermal: fix multiple disbalanced device node counters (2014-10-21 > > > > 08:05:50 -0400) > > > > > > > > > > > > Bartlomiej Zolnierkiewicz (9): > > > > thermal: exynos: remove unused struct exynos_tmu_registers entries > > > > thermal: exynos: remove dead code for HW_MODE calibration > > > > thermal: exynos: remove redundant pdata checks from > > > > exynos_tmu_initialize() > > > > thermal: exynos: remove redundant threshold_code checks from > > > > exynos_tmu_initialize() > > > > thermal: exynos: simplify temp_to_code() and code_to_temp() > > > > thermal: exynos: cache non_hw_trigger_levels in pdata > > > > thermal: exynos: remove redundant pdata checks from > > > > exynos_tmu_control() > > > > thermal: exynos: remove identical values from > > > > exynos*_tmu_registers structures > > > > thermal: samsung: Exynos5260 and Exynos5420 should not use > > > > TRIM_RELOAD flag > > > > > > > > Chanwoo Choi (2): > > > > thermal: exynos: Add support for many TRIMINFO_CTRL registers > > > > thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250 > > > > > > > > Geert Uytterhoeven (1): > > > > thermal: rcar: Add binding docs for new R-Car Gen2 SoCs > > > > > > > > Vladimir Zapolskiy (1): > > > > thermal: fix multiple disbalanced device node counters > > > > > > > > .../devicetree/bindings/thermal/rcar-thermal.txt | 5 +- > > > > drivers/thermal/of-thermal.c | 40 -- > > > > drivers/thermal/samsung/exynos_thermal_common.h| 2 +- > > > > drivers/thermal/samsung/exynos_tmu.c | 141 > > > > ++--- > > > > drivers/thermal/samsung/exynos_tmu.h | 81 ++-- > > > > drivers/thermal/samsung/exynos_tmu_data.c | 83 > > > > drivers/thermal/samsung/exynos_tmu_data.h | 39 +- > > > > 7 files changed, 111 insertions(+), 280 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/
[PATCH 3.10 08/43] x86/intel/quark: Switch off CR4.PGE so TLB flush uses CR3 instead
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Bryan O'Donoghue
commit ee1b5b165c0a2f04d2107e634e51f05d0eb107de upstream.
Quark x1000 advertises PGE via the standard CPUID method
PGE bits exist in Quark X1000's PTEs. In order to flush
an individual PTE it is necessary to reload CR3 irrespective
of the PTE.PGE bit.
See Quark Core_DevMan_001.pdf section 6.4.11
This bug was fixed in Galileo kernels, unfixed vanilla kernels are expected to
crash and burn on this platform.
Signed-off-by: Bryan O'Donoghue
Cc: Borislav Petkov
Link:
http://lkml.kernel.org/r/1411514784-14885-1-git-send-email-pure.lo...@nexus-software.ie
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/intel.c | 15 +++
1 file changed, 15 insertions(+)
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -154,6 +154,21 @@ static void __cpuinit early_init_intel(s
setup_clear_cpu_cap(X86_FEATURE_ERMS);
}
}
+
+ /*
+* Intel Quark Core DevMan_001.pdf section 6.4.11
+* "The operating system also is required to invalidate (i.e., flush)
+* the TLB when any changes are made to any of the page table entries.
+* The operating system must reload CR3 to cause the TLB to be flushed"
+*
+* As a result cpu_has_pge() in arch/x86/include/asm/tlbflush.h should
+* be false so that __flush_tlb_all() causes CR3 insted of CR4.PGE
+* to be modified
+*/
+ if (c->x86 == 5 && c->x86_model == 9) {
+ pr_info("Disabling PGE capability bit\n");
+ setup_clear_cpu_cap(X86_FEATURE_PGE);
+ }
}
#ifdef CONFIG_X86_32
--
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 3.10 07/43] kvm: dont take vcpu mutex for obviously invalid vcpu ioctls
3.10-stable review patch. If anyone has any objections, please let me know. -- From: David Matlack commit 2ea75be3219571d0ec009ce20d9971e54af96e09 upstream. vcpu ioctls can hang the calling thread if issued while a vcpu is running. However, invalid ioctls can happen when userspace tries to probe the kind of file descriptors (e.g. isatty() calls ioctl(TCGETS)); in that case, we know the ioctl is going to be rejected as invalid anyway and we can fail before trying to take the vcpu mutex. This patch does not change functionality, it just makes invalid ioctls fail faster. Signed-off-by: David Matlack Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman --- virt/kvm/kvm_main.c |4 1 file changed, 4 insertions(+) --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -52,6 +52,7 @@ #include #include +#include #include #include @@ -1981,6 +1982,9 @@ static long kvm_vcpu_ioctl(struct file * if (vcpu->kvm->mm != current->mm) return -EIO; + if (unlikely(_IOC_TYPE(ioctl) != KVMIO)) + return -EINVAL; + #if defined(CONFIG_S390) || defined(CONFIG_PPC) || defined(CONFIG_MIPS) /* * Special cases: vcpu ioctls that are asynchronous to vcpu execution, -- 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 0/8] More eeepc-laptop cleanup
On Wed, Oct 22, 2014 at 09:12:35PM +0200, Frans Klaver wrote: > Hi, > > This is another round of cleanups in eeepc-laptop. It's mostly shuffling > around > stuff, no big things. It's been running on my eeepc for two or three weeks now > without any apparent problems. Comments appreciated. Thanks Frans, Queued for 3.19 except where explicitly noted. -- Darren Hart Intel Open Source Technology Center -- 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 8/8] eeepc-laptop: don't assume get_acpi succeeds
On Wed, Oct 22, 2014 at 09:12:43PM +0200, Frans Klaver wrote:
> In eeepc_hotk_thaw, we assume that get_acpi() will effectively return a
> bool. However, it is possible that get_acpi() returns an error instead.
> We should not be writing error values to the ACPI device, even though
> it's quite possible that we couldn't contact the ACPI device in the
> first place.
>
> Signed-off-by: Frans Klaver
> ---
> drivers/platform/x86/eeepc-laptop.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/x86/eeepc-laptop.c
> b/drivers/platform/x86/eeepc-laptop.c
> index 275a239..14f79ef 100644
> --- a/drivers/platform/x86/eeepc-laptop.c
> +++ b/drivers/platform/x86/eeepc-laptop.c
> @@ -911,7 +911,7 @@ static int eeepc_hotk_thaw(struct device *device)
> struct eeepc_laptop *eeepc = dev_get_drvdata(device);
>
> if (eeepc->wlan_rfkill) {
> - bool wlan;
> + int wlan;
>
> /*
>* Work around bios bug - acpi _PTS turns off the wireless led
> @@ -919,7 +919,8 @@ static int eeepc_hotk_thaw(struct device *device)
>* we should kick it ourselves in case hibernation is aborted.
>*/
> wlan = get_acpi(eeepc, CM_ASL_WLAN);
> - set_acpi(eeepc, CM_ASL_WLAN, wlan);
> + if (wlan >= 0)
> + set_acpi(eeepc, CM_ASL_WLAN, wlan);
And if not? Seems like we should be passing the error code along.
> }
>
> return 0;
> --
> 2.1.0
>
>
--
Darren Hart
Intel Open Source Technology Center
--
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 3.10 24/43] lzo: check for length overrun in variable length encoding.
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Willy Tarreau
commit 72cf90124e87d975d0b2114d930808c58b4c05e4 upstream.
This fix ensures that we never meet an integer overflow while adding
255 while parsing a variable length encoding. It works differently from
commit 206a81c ("lzo: properly check for overruns") because instead of
ensuring that we don't overrun the input, which is tricky to guarantee
due to many assumptions in the code, it simply checks that the cumulated
number of 255 read cannot overflow by bounding this number.
The MAX_255_COUNT is the maximum number of times we can add 255 to a base
count without overflowing an integer. The multiply will overflow when
multiplying 255 by more than MAXINT/255. The sum will overflow earlier
depending on the base count. Since the base count is taken from a u8
and a few bits, it is safe to assume that it will always be lower than
or equal to 2*255, thus we can always prevent any overflow by accepting
two less 255 steps.
This patch also reduces the CPU overhead and actually increases performance
by 1.1% compared to the initial code, while the previous fix costs 3.1%
(measured on x86_64).
The fix needs to be backported to all currently supported stable kernels.
Reported-by: Willem Pinckaers
Cc: "Don A. Bailey"
Signed-off-by: Willy Tarreau
Signed-off-by: Greg Kroah-Hartman
---
lib/lzo/lzo1x_decompress_safe.c | 43 ++--
1 file changed, 37 insertions(+), 6 deletions(-)
--- a/lib/lzo/lzo1x_decompress_safe.c
+++ b/lib/lzo/lzo1x_decompress_safe.c
@@ -25,6 +25,16 @@
#define NEED_OP(x) if (!HAVE_OP(x)) goto output_overrun
#define TEST_LB(m_pos) if ((m_pos) < out) goto lookbehind_overrun
+/* This MAX_255_COUNT is the maximum number of times we can add 255 to a base
+ * count without overflowing an integer. The multiply will overflow when
+ * multiplying 255 by more than MAXINT/255. The sum will overflow earlier
+ * depending on the base count. Since the base count is taken from a u8
+ * and a few bits, it is safe to assume that it will always be lower than
+ * or equal to 2*255, thus we can always prevent any overflow by accepting
+ * two less 255 steps. See Documentation/lzo.txt for more information.
+ */
+#define MAX_255_COUNT size_t)~0) / 255) - 2)
+
int lzo1x_decompress_safe(const unsigned char *in, size_t in_len,
unsigned char *out, size_t *out_len)
{
@@ -55,12 +65,19 @@ int lzo1x_decompress_safe(const unsigned
if (t < 16) {
if (likely(state == 0)) {
if (unlikely(t == 0)) {
+ size_t offset;
+ const unsigned char *ip_last = ip;
+
while (unlikely(*ip == 0)) {
- t += 255;
ip++;
NEED_IP(1);
}
- t += 15 + *ip++;
+ offset = ip - ip_last;
+ if (unlikely(offset > MAX_255_COUNT))
+ return LZO_E_ERROR;
+
+ offset = (offset << 8) - offset;
+ t += offset + 15 + *ip++;
}
t += 3;
copy_literal_run:
@@ -116,12 +133,19 @@ copy_literal_run:
} else if (t >= 32) {
t = (t & 31) + (3 - 1);
if (unlikely(t == 2)) {
+ size_t offset;
+ const unsigned char *ip_last = ip;
+
while (unlikely(*ip == 0)) {
- t += 255;
ip++;
NEED_IP(1);
}
- t += 31 + *ip++;
+ offset = ip - ip_last;
+ if (unlikely(offset > MAX_255_COUNT))
+ return LZO_E_ERROR;
+
+ offset = (offset << 8) - offset;
+ t += offset + 31 + *ip++;
NEED_IP(2);
}
m_pos = op - 1;
@@ -134,12 +158,19 @@ copy_literal_run:
m_pos -= (t & 8) << 11;
t = (t & 7) + (3 - 1);
if (unlikely(t == 2)) {
+ size_t offset;
+ const unsigned char *ip_last = ip;
+
while (unlikely(*ip == 0)) {
-
Re: [RFC][PATCH 0/6] Another go at speculative page faults
Hi Peter, On Fri, 24 Oct 2014 15:14:40 +0200, Peter Zijlstra wrote: > On Fri, Oct 24, 2014 at 09:54:23AM +0200, Ingo Molnar wrote: >> >> * Peter Zijlstra wrote: >> > Its what I thought initially, I tried doing perf record with and >> > without, but then I ran into perf diff not quite working for me and I've >> > yet to find time to kick that thing into shape. >> >> Might be the 'perf diff' regression fixed by this: >> >> 9ab1f50876db perf diff: Add missing hists__init() call at tool start >> >> I just pushed it out into tip:master. > > I was on tip/master, so unlikely to be that as I was likely already > having it. > > perf-report was affected too, for some reason my CONFIG_DEBUG_INFO=y > vmlinux wasn't showing symbols (and I double checked that KASLR crap was > disabled, so that wasn't confusing stuff either). > > When I forced perf-report to use kallsyms it works, however perf-diff > doesn't have that option. > > So there's two issues there, 1) perf-report failing to generate useful > output and 2) per-diff lacking options to force it to behave. Did the perf-report fail to show any (kernel) symbols or are they wrong symbols? Maybe it's related to this: https://lkml.org/lkml/2014/9/22/78 Thanks, Namhyung -- 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 7/8] eeepc-laptop: document fan_pwm conversions
On Wed, Oct 22, 2014 at 09:12:42PM +0200, Frans Klaver wrote:
> eeepc_get_fan_pwm and eeepc_set_fan_pwm convert the PWM value read from
> the fan to a range lmsensors understands. Unfortunately this is only
> clear if you are familiar with how lmsensors handles duty cycles.
>
> Introduce two conversion functions that document the goal of these
> conversions.
>
> Signed-off-by: Frans Klaver
> ---
> drivers/platform/x86/eeepc-laptop.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/platform/x86/eeepc-laptop.c
> b/drivers/platform/x86/eeepc-laptop.c
> index f820bb3..275a239 100644
> --- a/drivers/platform/x86/eeepc-laptop.c
> +++ b/drivers/platform/x86/eeepc-laptop.c
> @@ -974,18 +974,28 @@ static struct platform_driver platform_driver = {
> #define EEEPC_EC_SFB0 0xD0
> #define EEEPC_EC_FAN_CTRL (EEEPC_EC_SFB0 + 3) /* Byte containing SF25 */
>
> +static inline int eeepc_pwm_to_lmsensors(int value)
> +{
> + return value * 255 / 100;
> +}
> +
> +static inline int eeepc_lmsensors_to_pwm(int value)
> +{
> + value = clamp_val(value, 0, 255);
> + return value * 100 / 255;
Says the guy cleaning up all the magic numbers ;-)
But yeah, this is fine IMO. Applied.
--
Darren Hart
Intel Open Source Technology Center
--
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 3.10 25/43] NFSv4: Fix lock recovery when CREATE_SESSION/SETCLIENTID_CONFIRM fails
3.10-stable review patch. If anyone has any objections, please let me know. -- From: Trond Myklebust commit a4339b7b686b4acc8b6de2b07d7bacbe3ae44b83 upstream. If a NFSv4.x server returns NFS4ERR_STALE_CLIENTID in response to a CREATE_SESSION or SETCLIENTID_CONFIRM in order to tell us that it rebooted a second time, then the client will currently take this to mean that it must declare all locks to be stale, and hence ineligible for reboot recovery. RFC3530 and RFC5661 both suggest that the client should instead rely on the server to respond to inelegible open share, lock and delegation reclaim requests with NFS4ERR_NO_GRACE in this situation. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman --- fs/nfs/nfs4state.c |1 - 1 file changed, 1 deletion(-) --- a/fs/nfs/nfs4state.c +++ b/fs/nfs/nfs4state.c @@ -1755,7 +1755,6 @@ static int nfs4_handle_reclaim_lease_err break; case -NFS4ERR_STALE_CLIENTID: clear_bit(NFS4CLNT_LEASE_CONFIRM, >cl_state); - nfs4_state_clear_reclaim_reboot(clp); nfs4_state_start_reclaim_reboot(clp); break; case -NFS4ERR_CLID_INUSE: -- 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/8] eeepc-laptop: clean up control flow in eeepc_acpi_notify
On Wed, Oct 22, 2014 at 09:12:40PM +0200, Frans Klaver wrote:
> eeepc_acpi_notify increases the indentation level to a whopping four. If
> we revise the conditions a bit, we can reduce that to a more soothing
> two and satisfy the indentation guidelines in Documentation/CodingStyle.
>
> Remove an unwanted space while we're in the neighbourhood.
>
> Signed-off-by: Frans Klaver
> ---
> drivers/platform/x86/eeepc-laptop.c | 53
> ++---
> 1 file changed, 26 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/platform/x86/eeepc-laptop.c
> b/drivers/platform/x86/eeepc-laptop.c
> index 73e8d39..21ffe1f 100644
> --- a/drivers/platform/x86/eeepc-laptop.c
> +++ b/drivers/platform/x86/eeepc-laptop.c
> @@ -1213,7 +1213,7 @@ static void eeepc_input_exit(struct eeepc_laptop *eeepc)
> static void eeepc_input_notify(struct eeepc_laptop *eeepc, int event)
> {
> if (!eeepc->inputdev)
> - return ;
> + return;
> if (!sparse_keymap_report_event(eeepc->inputdev, event, 1, true))
> pr_info("Unknown key %x pressed\n", event);
> }
> @@ -1222,6 +1222,7 @@ static void eeepc_acpi_notify(struct acpi_device
> *device, u32 event)
> {
> struct eeepc_laptop *eeepc = acpi_driver_data(device);
> u16 count;
> + int old_brightness, new_brightness;
Variable declarations in order of decreasing line length please.
Otherwise, looks good. Mind sending an update of this one?
--
Darren Hart
Intel Open Source Technology Center
--
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] sched: Fix race between task_group and sched_task_group
В Вт, 28/10/2014 в 00:04 +0100, Oleg Nesterov пишет:
> On 10/27, Kirill Tkhai wrote:
> >
> > +static void cpu_cgroup_fork(struct task_struct *task)
> > +{
> > + sched_move_task(task);
> > +}
> > +
> > static int cpu_cgroup_can_attach(struct cgroup_subsys_state *css,
> > struct cgroup_taskset *tset)
> > {
> > @@ -8205,6 +8210,7 @@ struct cgroup_subsys cpu_cgrp_subsys = {
> > .css_free = cpu_cgroup_css_free,
> > .css_online = cpu_cgroup_css_online,
> > .css_offline= cpu_cgroup_css_offline,
> > + .fork = cpu_cgroup_fork,
>
> Agreed, but it seems that sched_move_task() -> task_css_check() can
> complain if CONFIG_PROVE_RCU...
Thanks, Oleg.
>
> cpu_cgroup_exit() too calls sched_move_task() without any lock, but
> there is the PF_EXITING check and init_css_set can't go away.
>
> perhaps sched_move_task() should just take rcu_read_lock() and use
> task_css() ? This lockdep_is_held(siglock) looks ugly, and iiuc we
> need it to shut up the warning if autogroup_move_group() is the caller.
Shouldn't we do that in separate patch? How about this?
[PATCH]sched: Remove lockdep check in sched_move_task()
sched_move_task() is the only interface to change sched_task_group:
cpu_cgrp_subsys methods and autogroup_move_group() use it.
Everything is synchronized by task_rq_lock(), so cpu_cgroup_attach()
is ordered with other users of sched_move_task(). This means we do
no need RCU here: if we've dereferenced a tg here, the .attach method
hasn't been called for it yet.
Thus, we should pass "true" to task_css_check() to silence lockdep
warnings.
Signed-off-by: Kirill Tkhai
Reported-by: Oleg Nesterov
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index dde8adb..d77e6ee 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7403,8 +7403,12 @@ void sched_move_task(struct task_struct *tsk)
if (unlikely(running))
put_prev_task(rq, tsk);
- tg = container_of(task_css_check(tsk, cpu_cgrp_id,
- lockdep_is_held(>sighand->siglock)),
+ /*
+* All callers are synchronized by task_rq_lock(); we do not use RCU
+* which is pointless here. Thus, we pass "true" to task_css_check()
+* to prevent lockdep warnings.
+*/
+ tg = container_of(task_css_check(tsk, cpu_cgrp_id, true),
struct task_group, css);
tg = autogroup_task_group(tsk, tg);
tsk->sched_task_group = tg;
--
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 3.10 09/43] spi: dw-mid: respect 8 bit mode
3.10-stable review patch. If anyone has any objections, please let me know. -- From: Andy Shevchenko commit b41583e7299046abdc578c33f25ed83ee95b9b31 upstream. In case of 8 bit mode and DMA usage we end up with every second byte written as 0. We have to respect bits_per_word settings what this patch actually does. Signed-off-by: Andy Shevchenko Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman --- drivers/spi/spi-dw-mid.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/spi/spi-dw-mid.c +++ b/drivers/spi/spi-dw-mid.c @@ -136,7 +136,7 @@ static int mid_spi_dma_transfer(struct d txconf.dst_addr = dws->dma_addr; txconf.dst_maxburst = LNW_DMA_MSIZE_16; txconf.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES; - txconf.dst_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES; + txconf.dst_addr_width = dws->dma_width; txconf.device_fc = false; txchan->device->device_control(txchan, DMA_SLAVE_CONFIG, @@ -159,7 +159,7 @@ static int mid_spi_dma_transfer(struct d rxconf.src_addr = dws->dma_addr; rxconf.src_maxburst = LNW_DMA_MSIZE_16; rxconf.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES; - rxconf.src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES; + rxconf.src_addr_width = dws->dma_width; rxconf.device_fc = false; rxchan->device->device_control(rxchan, DMA_SLAVE_CONFIG, -- 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: Tree for Oct 28
Hi all, Changes since 20141027: The bluetooth tree still had its build failure so I used the version from next-20141023. The pinctrl tree still had its build failure so I used the version from next-20141023. The akpm-current tree lost its build failure and gained a conflict against the dma-mapping tree. Non-merge commits (relative to Linus' tree): 1920 1795 files changed, 49930 insertions(+), 56540 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 227 trees (counting Linus' and 32 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (f7e87a44ef60 Merge tag 'media/v3.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (178c3dfe853a ARM: fix some printk formats) Merging m68k-current/for-linus (f7bbd12a4b7e m68k: Wire up bpf) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of flash_block_list in rtas_flash) Merging powerpc-merge-mpe/for-linus (e89dafb5ca50 powerpc: Only do dynamic DMA zone limits on platforms that need it) Merging sparc/master (06090e8ed89e sparc64: Implement __get_user_pages_fast().) Merging net/master (f89b7755f517 bpf: split eBPF out of NET) Merging ipsec/master (d10845fc85b2 Merge branch 'gso_encap_fixes') Merging sound-current/for-linus (d1d0b6b66881 ALSA: bebob: Uninitialized id returned by saffirepro_both_clk_src_get) Merging pci-current/for-linus (c302d35eac32 Revert duplicate "PCI: pciehp: Prevent NULL dereference during probe") Merging wireless/master (99c814066e75 Merge tag 'mac80211-for-john-2014-10-23' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging driver-core.current/driver-core-linus (f114040e3ea6 Linux 3.18-rc1) Merging tty.current/tty-linus (f114040e3ea6 Linux 3.18-rc1) Merging usb.current/usb-linus (9680b60ed79e usb: chipidea: Fix oops when removing the ci_hdrc module) Merging usb-gadget-fixes/fixes (9b1763553a89 usb: gadget: function: Fixed the return value on error path) Merging usb-serial-fixes/usb-linus (7f2719f0003d usb: serial: ftdi_sio: add "bricked" FTDI device PID) Merging staging.current/staging-linus (7e74783a9db7 Merge tag 'iio-fixes-for-3.18a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus) Merging char-misc.current/char-misc-linus (f114040e3ea6 Linux 3.18-rc1) Merging input-current/for-linus (859abd1d59e2 Input: wm97xx - adapt parameters to tosa touchscreen.) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (09adc8789c4e crypto: qat - Enforce valid numa configuration) Merging ide/master (7546e52b5e3d Drivers: ide: Remove typedef atiixp_ide_timing) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (e66c98c7a0ea of: Fix NULL dereference in selftest removal code) Merging rr-fixes/fixes (f49819560f53 virtio-rng: skip reading when we start to remove the device) Merging vfio-fixes/for-linus (239a87020b26 Merge branch 'for-joerg/arm-smmu/fixes' of git://git.kernel.org/
[PATCH 3.10 26/43] NFSv4: fix open/lock state recovery error handling
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit df817ba35736db2d62b07de6f050a4db53492ad8 upstream.
The current open/lock state recovery unfortunately does not handle errors
such as NFS4ERR_CONN_NOT_BOUND_TO_SESSION correctly. Instead of looping,
just proceeds as if the state manager is finished recovering.
This patch ensures that we loop back, handle higher priority errors
and complete the open/lock state recovery.
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/nfs4state.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -1699,7 +1699,8 @@ restart:
if (status < 0) {
set_bit(ops->owner_flag_bit, >so_flags);
nfs4_put_state_owner(sp);
- return nfs4_recovery_handle_error(clp, status);
+ status = nfs4_recovery_handle_error(clp,
status);
+ return (status != 0) ? status : -EAGAIN;
}
nfs4_put_state_owner(sp);
@@ -1708,7 +1709,7 @@ restart:
spin_unlock(>cl_lock);
}
rcu_read_unlock();
- return status;
+ return 0;
}
static int nfs4_check_lease(struct nfs_client *clp)
@@ -2173,14 +2174,11 @@ static void nfs4_state_manager(struct nf
section = "reclaim reboot";
status = nfs4_do_reclaim(clp,
clp->cl_mvops->reboot_recovery_ops);
- if (test_bit(NFS4CLNT_LEASE_EXPIRED, >cl_state) ||
- test_bit(NFS4CLNT_SESSION_RESET, >cl_state))
- continue;
- nfs4_state_end_reclaim_reboot(clp);
- if (test_bit(NFS4CLNT_RECLAIM_NOGRACE, >cl_state))
+ if (status == -EAGAIN)
continue;
if (status < 0)
goto out_error;
+ nfs4_state_end_reclaim_reboot(clp);
}
/* Now recover expired state... */
@@ -2188,9 +2186,7 @@ static void nfs4_state_manager(struct nf
section = "reclaim nograce";
status = nfs4_do_reclaim(clp,
clp->cl_mvops->nograce_recovery_ops);
- if (test_bit(NFS4CLNT_LEASE_EXPIRED, >cl_state) ||
- test_bit(NFS4CLNT_SESSION_RESET, >cl_state) ||
- test_bit(NFS4CLNT_RECLAIM_REBOOT, >cl_state))
+ if (status == -EAGAIN)
continue;
if (status < 0)
goto out_error;
--
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/8] eeepc-laptop: pull out eeepc_destroy_rfkill
On Wed, Oct 22, 2014 at 09:12:39PM +0200, Frans Klaver wrote:
> In eeepc_rfkill_exit, we implement the same code four times. Pull out a
> function that cleans up an rfkill object to get rid of the duplication.
>
> Signed-off-by: Frans Klaver
> ---
> drivers/platform/x86/eeepc-laptop.c | 34 ++
> 1 file changed, 14 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/platform/x86/eeepc-laptop.c
> b/drivers/platform/x86/eeepc-laptop.c
> index e92ea41..73e8d39 100644
> --- a/drivers/platform/x86/eeepc-laptop.c
> +++ b/drivers/platform/x86/eeepc-laptop.c
> @@ -823,35 +823,29 @@ static char EEEPC_RFKILL_NODE_1[] = "\\_SB.PCI0.P0P5";
> static char EEEPC_RFKILL_NODE_2[] = "\\_SB.PCI0.P0P6";
> static char EEEPC_RFKILL_NODE_3[] = "\\_SB.PCI0.P0P7";
>
> +static inline void eeepc_destroy_rfkill(struct rfkill **rfkill)
> +{
> + if (!*rfkill)
> + return;
> + rfkill_unregister(*rfkill);
> + rfkill_destroy(*rfkill);
> + *rfkill = NULL;
> +}
In this case the savings is 6 lines at the cost of some legibility as double
pointers are arguably harder to read, and definitely easier to screw up ;-)
I appreciate the goal, but I'm not convinced it is worth it.
--
Darren Hart
Intel Open Source Technology Center
--
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 3.10 10/43] spi: dw-mid: check that DMA was inited before exit
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Shevchenko
commit fb57862ead652454ceeb659617404c5f13bc34b5 upstream.
If the driver was compiled with DMA support, but DMA channels weren't acquired
by some reason, mid_spi_dma_exit() will crash the kernel.
Fixes: 7063c0d942a1 (spi/dw_spi: add DMA support)
Signed-off-by: Andy Shevchenko
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
---
drivers/spi/spi-dw-mid.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/spi/spi-dw-mid.c
+++ b/drivers/spi/spi-dw-mid.c
@@ -89,6 +89,8 @@ err_exit:
static void mid_spi_dma_exit(struct dw_spi *dws)
{
+ if (!dws->dma_inited)
+ return;
dma_release_channel(dws->txchan);
dma_release_channel(dws->rxchan);
}
--
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 0/6] ACPI/OSL: Rework of ACPICA memory OSLs to improve performance.
There are reasons for why RCU is used here.
Using spinlock here will break specific
acpi_os_read_memory()/acpi_os_write_memory() users.
So this patchset is not correct, please ignore.
Thanks
-Lv
> From: Zheng, Lv
> Sent: Thursday, October 23, 2014 10:12 AM
>
> It is reported that there is a performance issue in the ACPICA OSL
> implementation around memory mappings.
>
> On the reported platforms, there is a debugging facility implemented in the
> ACPI namespace using circular logging buffer:
> Name (DPTR, 0x3AFEB000)
> Name (EPTR, 0x3AFFB000)
> Name (CPTR, 0x3AFEB010)
> Mutex (MMUT, 0x00)
> Method (MDBG, 1, Serialized)
> {
> Store (Acquire (MMUT, 0x03E8), Local0)
> If (Local0 == Zero)
> {
> OperationRegion (ABLK, SystemMemory, CPTR, 0x10)
> Field (ABLK, ByteAcc, NoLock, Preserve)
> {
> , 128
> }
> Store (Arg0, ) /* \MDBG. */
> CPTR = (CPTR + 0x10) /* \CPTR */
> If (CPTR >= EPTR)
> {
> CPTR = (DPTR + 0x10) /* \CPTR */
> }
> Release (MMUT)
> }
> Return (Local0)
> }
> This function is heavily invoked by other ACPI control methods.
> The reported platforms suffer from 2-5 minutes kernel stuck in the end of
> accessing the mapped circular buffer system memory region. By
> instrumentation, the 2-5 minutes time consumption overhead can be seen to
> happen on the synchronize_rcu() invoked in the acpi_os_unmap_memory().
>
> This patchset removes the synchronize_rcu() from the hot path to improve
> the performance.
>
> Lv Zheng (6):
> ACPI/OSL: Split memory operation region implementations to a seperate
> file.
> ACPI/OSL: Rename system memory functions.
> ACPI/OSL: Cleanup memory access functions by merging duplicate code.
> ACPI/OSL: Add acpi_map2virt() to merge duplicate code.
> ACPI/OSL: Cleanup branch logics.
> ACPI/OSL: Fix performance issue in system memory lockings.
>
> drivers/acpi/Makefile |2 +-
> drivers/acpi/mem.c| 414
> +
> drivers/acpi/osl.c| 381 -
> 3 files changed, 415 insertions(+), 382 deletions(-)
> create mode 100644 drivers/acpi/mem.c
>
> --
> 1.7.10
--
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/8] eeepc-laptop: define rfkill notifier nodes only once
On Wed, Oct 22, 2014 at 09:12:38PM +0200, Frans Klaver wrote: > The rfkill notifier node names are used in three different places. As a > matter of style, it is better to store them somewhere and have the > compiler warn us about typos in the function arguments. > > Signed-off-by: Frans Klaver > --- > drivers/platform/x86/eeepc-laptop.c | 22 +- > 1 file changed, 13 insertions(+), 9 deletions(-) > > diff --git a/drivers/platform/x86/eeepc-laptop.c > b/drivers/platform/x86/eeepc-laptop.c > index 6e3be01..e92ea41 100644 > --- a/drivers/platform/x86/eeepc-laptop.c > +++ b/drivers/platform/x86/eeepc-laptop.c > @@ -819,11 +819,15 @@ static int eeepc_new_rfkill(struct eeepc_laptop *eeepc, > return 0; > } > > +static char EEEPC_RFKILL_NODE_1[] = "\\_SB.PCI0.P0P5"; > +static char EEEPC_RFKILL_NODE_2[] = "\\_SB.PCI0.P0P6"; > +static char EEEPC_RFKILL_NODE_3[] = "\\_SB.PCI0.P0P7"; So, out of curiosity, any particular reason for static char[] instead of #define? I see both used frequently and didn't see any advice in CodingStyle. Regardless, Queued and thanks, -- Darren Hart Intel Open Source Technology Center -- 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 3.10 05/43] kvm: x86: fix stale mmio cache bug
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: David Matlack
commit 56f17dd3fbc44adcdbc3340fe3988ddb833a47a7 upstream.
The following events can lead to an incorrect KVM_EXIT_MMIO bubbling
up to userspace:
(1) Guest accesses gpa X without a memory slot. The gfn is cached in
struct kvm_vcpu_arch (mmio_gfn). On Intel EPT-enabled hosts, KVM sets
the SPTE write-execute-noread so that future accesses cause
EPT_MISCONFIGs.
(2) Host userspace creates a memory slot via KVM_SET_USER_MEMORY_REGION
covering the page just accessed.
(3) Guest attempts to read or write to gpa X again. On Intel, this
generates an EPT_MISCONFIG. The memory slot generation number that
was incremented in (2) would normally take care of this but we fast
path mmio faults through quickly_check_mmio_pf(), which only checks
the per-vcpu mmio cache. Since we hit the cache, KVM passes a
KVM_EXIT_MMIO up to userspace.
This patch fixes the issue by using the memslot generation number
to validate the mmio cache.
Signed-off-by: David Matlack
[xiaoguangrong: adjust the code to make it simpler for stable-tree fix.]
Signed-off-by: Xiao Guangrong
Reviewed-by: David Matlack
Reviewed-by: Xiao Guangrong
Tested-by: David Matlack
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/mmu.c |2 +-
arch/x86/kvm/x86.h | 20 +++-
3 files changed, 17 insertions(+), 6 deletions(-)
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -463,6 +463,7 @@ struct kvm_vcpu_arch {
u64 mmio_gva;
unsigned access;
gfn_t mmio_gfn;
+ u64 mmio_gen;
struct kvm_pmu pmu;
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3072,7 +3072,7 @@ static void mmu_sync_roots(struct kvm_vc
if (!VALID_PAGE(vcpu->arch.mmu.root_hpa))
return;
- vcpu_clear_mmio_info(vcpu, ~0ul);
+ vcpu_clear_mmio_info(vcpu, MMIO_GVA_ANY);
kvm_mmu_audit(vcpu, AUDIT_PRE_SYNC);
if (vcpu->arch.mmu.root_level == PT64_ROOT_LEVEL) {
hpa_t root = vcpu->arch.mmu.root_hpa;
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@ -78,15 +78,23 @@ static inline void vcpu_cache_mmio_info(
vcpu->arch.mmio_gva = gva & PAGE_MASK;
vcpu->arch.access = access;
vcpu->arch.mmio_gfn = gfn;
+ vcpu->arch.mmio_gen = kvm_memslots(vcpu->kvm)->generation;
+}
+
+static inline bool vcpu_match_mmio_gen(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.mmio_gen == kvm_memslots(vcpu->kvm)->generation;
}
/*
- * Clear the mmio cache info for the given gva,
- * specially, if gva is ~0ul, we clear all mmio cache info.
+ * Clear the mmio cache info for the given gva. If gva is MMIO_GVA_ANY, we
+ * clear all mmio cache info.
*/
+#define MMIO_GVA_ANY (~(gva_t)0)
+
static inline void vcpu_clear_mmio_info(struct kvm_vcpu *vcpu, gva_t gva)
{
- if (gva != (~0ul) && vcpu->arch.mmio_gva != (gva & PAGE_MASK))
+ if (gva != MMIO_GVA_ANY && vcpu->arch.mmio_gva != (gva & PAGE_MASK))
return;
vcpu->arch.mmio_gva = 0;
@@ -94,7 +102,8 @@ static inline void vcpu_clear_mmio_info(
static inline bool vcpu_match_mmio_gva(struct kvm_vcpu *vcpu, unsigned long
gva)
{
- if (vcpu->arch.mmio_gva && vcpu->arch.mmio_gva == (gva & PAGE_MASK))
+ if (vcpu_match_mmio_gen(vcpu) && vcpu->arch.mmio_gva &&
+ vcpu->arch.mmio_gva == (gva & PAGE_MASK))
return true;
return false;
@@ -102,7 +111,8 @@ static inline bool vcpu_match_mmio_gva(s
static inline bool vcpu_match_mmio_gpa(struct kvm_vcpu *vcpu, gpa_t gpa)
{
- if (vcpu->arch.mmio_gfn && vcpu->arch.mmio_gfn == gpa >> PAGE_SHIFT)
+ if (vcpu_match_mmio_gen(vcpu) && vcpu->arch.mmio_gfn &&
+ vcpu->arch.mmio_gfn == gpa >> PAGE_SHIFT)
return true;
return false;
--
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: [resend Patch v3 1/2] kaslr: check if kernel location is changed
On 10/15/14 at 11:37am, Baoquan He wrote: > On 10/14/14 at 08:49am, Vivek Goyal wrote: > > On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote: > > > Agreed. On x86_64, we should be able to randomize virtual address space > > > and physical address space independently. And in that case whole of > > > the physical memory should be available for a possible location for > > > kernel. (As opposed to a small limit (I guess 1GB) now) > > It can be done to randomize virtual address space and physical address > space independently. But limited by the 2G of kernel text mapping and > module mapping virtual address space, virtual address can be randomized > in (0x100, 1G) range. While physical address can be randomized in > (0x100, 4G) according to the identity mapping of normal kernel. Then > phys_base still stores an relative value, a different offset than before. > > This can be easily implement. One thing is still there's a limit for > physical addr randomization, only below 4G. So I am wondering if we can > extend the identify mapping to complete mapping of 48 bit, using 1G page > frame. This can make physical addr be randomized to anywhere. > > So now there may be 3 options: Hi hpa, About kaslr, do you have a suggestion or plan? Should we fix bug based on current code, or any other solutions? Thanks Baoquan > > 1) Fix this bug in current kaslr. Since when randomize the new kernel > location in choose_kernel_location(), cmdline options has been checked > strictly, e.g if nokaslr is specified, it's safe to do the kernel > location randomization. Then in handle_relocations(), we only need to > check if the kernel location is changed, comparing with kernel loaded > addr. If changed, kaslr is done, let's do the relocation handling. If > not changed, no kaslr id done, just skip the relocation handling like > before. > > 2) randomize the virtual addr space and physical addr space > independently. But physical addr space must be below 4G. > > 3) extend the identity mapping to 48bit of addr space. Then we can > randomized the virtual addr space in (0x100, 1G) and physical addr > space in (0x100, real physical memory end). > > If option 3 is doable, it's the best. If not, I think bug fix should be > better. > -- 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 0/2] xen: Switch to virtual mapped linear p2m list
On 10/27/2014 04:16 PM, David Vrabel wrote: On 27/10/14 14:52, Juergen Gross wrote: Paravirtualized kernels running on Xen use a three level tree for translation of guest specific physical addresses to machine global addresses. This p2m tree is used for construction of page table entries, so the p2m tree walk is performance critical. By using a linear virtual mapped p2m list accesses to p2m elements can be sped up while even simplifying code. To achieve this goal some p2m related initializations have to be performed later in the boot process, as the final p2m list can be set up only after basic memory management functions are available. What impact does this have on 32-bit guests which don't have huge amount of virtual address space? I think a 32-bit guest could have up to 64 GiB of PFNs, which would require a 128 MiB p2m array, which is too large? It is 64 MB (one entry on 32 bit is 32 bits :-) ). With a m2p array of only 16 MB size I doubt a 32 bit guest can be larger than 16 GB, or am I wrong here? Juergen -- 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 3.10 28/43] iwlwifi: Add missing PCI IDs for the 7260 series
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Oren Givon
commit 4f08970f5284dce486f0e2290834aefb2a262189 upstream.
Add 4 missing PCI IDs for the 7260 series.
Signed-off-by: Oren Givon
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/iwlwifi/pcie/drv.c |4
1 file changed, 4 insertions(+)
--- a/drivers/net/wireless/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/iwlwifi/pcie/drv.c
@@ -269,6 +269,8 @@ static DEFINE_PCI_DEVICE_TABLE(iwl_hw_ca
{IWL_PCI_DEVICE(0x08B1, 0x4070, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4072, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4170, iwl7260_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0x4C60, iwl7260_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0x4C70, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4060, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x406A, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0x4160, iwl7260_2n_cfg)},
@@ -306,6 +308,8 @@ static DEFINE_PCI_DEVICE_TABLE(iwl_hw_ca
{IWL_PCI_DEVICE(0x08B1, 0xC770, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B1, 0xC760, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B2, 0xC270, iwl7260_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0xCC70, iwl7260_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x08B1, 0xCC60, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B2, 0xC272, iwl7260_2ac_cfg)},
{IWL_PCI_DEVICE(0x08B2, 0xC260, iwl7260_2n_cfg)},
{IWL_PCI_DEVICE(0x08B2, 0xC26A, iwl7260_n_cfg)},
--
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 3.10 11/43] regmap: debugfs: fix possbile NULL pointer dereference
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Xiubo Li
commit 2c98e0c1cc6b8e86f1978286c3d4e0769ee9d733 upstream.
If 'map->dev' is NULL and there will lead dev_name() to be NULL pointer
dereference. So before dev_name(), we need to have check of the map->dev
pionter.
We also should make sure that the 'name' pointer shouldn't be NULL for
debugfs_create_dir(). So here using one default "dummy" debugfs name when
the 'name' pointer and 'map->dev' are both NULL.
Signed-off-by: Xiubo Li
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
---
drivers/base/regmap/regmap-debugfs.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -460,16 +460,20 @@ void regmap_debugfs_init(struct regmap *
{
struct rb_node *next;
struct regmap_range_node *range_node;
+ const char *devname = "dummy";
INIT_LIST_HEAD(>debugfs_off_cache);
mutex_init(>cache_lock);
+ if (map->dev)
+ devname = dev_name(map->dev);
+
if (name) {
map->debugfs_name = kasprintf(GFP_KERNEL, "%s-%s",
- dev_name(map->dev), name);
+ devname, name);
name = map->debugfs_name;
} else {
- name = dev_name(map->dev);
+ name = devname;
}
map->debugfs = debugfs_create_dir(name, regmap_debugfs_root);
--
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/8] eeepc-laptop: flatten control flow
On Wed, Oct 22, 2014 at 09:12:36PM +0200, Frans Klaver wrote: > In eeepc_rfkill_hotplug there's an if statement with a big tail that > ends right before the out_unlock label. We might as well invert the > condition and jump to out_unlock in that case, pretty much like the rest > of the code does. This removes an indentation level for a large chunk of > code and also stops suggesting there might be an else clause. > > Signed-off-by: Frans Klaver Queued for 3.19, thanks Frans. -- Darren Hart Intel Open Source Technology Center -- 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 3.10 37/43] spi: dw-mid: terminate ongoing transfers at exit
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Shevchenko
commit 8e45ef682cb31fda62ed4eeede5d9745a0a1b1e2 upstream.
Do full clean up at exit, means terminate all ongoing DMA transfers.
Signed-off-by: Andy Shevchenko
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
---
drivers/spi/spi-dw-mid.c |4
1 file changed, 4 insertions(+)
--- a/drivers/spi/spi-dw-mid.c
+++ b/drivers/spi/spi-dw-mid.c
@@ -91,7 +91,11 @@ static void mid_spi_dma_exit(struct dw_s
{
if (!dws->dma_inited)
return;
+
+ dmaengine_terminate_all(dws->txchan);
dma_release_channel(dws->txchan);
+
+ dmaengine_terminate_all(dws->rxchan);
dma_release_channel(dws->rxchan);
}
--
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/
[PATCHv3 2/2] ARM: dts: Add dts files for Exynos4415 SoC
This patch adds new exynos4415.dtsi to support Exynos4415 SoC
based on Cortex-A9 quad cores and includes following dt nodes:
- GIC interrupt controller (GIC-400)
- Pinctrl to control three GPIO parts
- CMU (Clock Management Unit) for CMU/CMU_DMC/AUDSS
- CPU information (Cortex-A9 quad cores)
- UART to support serial port
- MCT (Multi Core Timer)
- ADC (Analog Digital Converter)
- RTC (Real Time Clock)
- I2C/SPI busses
- Power domains (CAM, TV, MFC, G3D, LCD0, ISP0/1)
- PMU (Performance Monitoring Unit)
- MSHC (Mobile Storage Host Controller)
- EHCI (Enhanced Host Controller Interface)
- OHIC (Open Host Controller Interface)
- USB 2.0 device with hsotg
- PWM (Pluse Width Modulation) Timer
- AMBA bus for PDMA0/1
- SYSRAM node for memory mapping
- SYSREG node for memory mapping
- PMU (Power Management Unit) node for memory mapping
Cc: Kukjin Kim
Cc: Ben Dooks
Cc: Russell King
Cc: Mark Rutland
Cc: Olof Johansson
Cc: Arnd Bergmann
Signed-off-by: Chanwoo Choi
Signed-off-by: Seung-Woo Kim
[m.szyprowski: Add OHCI node and correct EHCI node]
Signed-off-by: Marek Szyprowski
[yj44.cho: Add mipi-phy node]
Signed-off-by: YoungJun Cho
[jaewon02: Add EHCI and SPI_2 node]
Signed-off-by: Jaewon Kim
[ideal.song: Add I2S0 node for audio interface]
Signed-off-by: Inha Song
[tomasz.figa: Add L2 cache node]
Signed-off-by: Tomasz Figa
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4415-pinctrl.dtsi | 613 +
arch/arm/boot/dts/exynos4415.dtsi | 627 ++
2 files changed, 1240 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos4415-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/exynos4415.dtsi
diff --git a/arch/arm/boot/dts/exynos4415-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4415-pinctrl.dtsi
new file mode 100644
index 000..5ce4314
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4415-pinctrl.dtsi
@@ -0,0 +1,613 @@
+/*
+ * Samsung's Exynos4415 SoCs pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * Samsung's Exynos4415 SoCs pin-mux and pin-config optiosn are listed as
device
+ * tree nodes are listed in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+_0 {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb: gpb {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc0: gpc0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc1: gpc1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd0: gpd0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd1: gpd1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpf0: gpf0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpf1: gpf1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpf2: gpf2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ uart0_data: uart0-data {
+ samsung,pins = "gpa0-0", "gpa0-1";
+ samsung,pin-function = <0x2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart0_fctl: uart0-fctl {
+ samsung,pins = "gpa0-2", "gpa0-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart1_data: uart1-data {
+ samsung,pins = "gpa0-4", "gpa0-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart1_fctl: uart1-fctl {
+ samsung,pins = "gpa0-6", "gpa0-7";
+ samsung,pin-function = <2>;
+
[PATCHv3 1/2] ARM: EXYNOS: Add EXYNOS4415 SoC
This patch add Exynos4415's SoC. Exynos4415 is based on the 32-bit RISC
processor for Smartphone. Exynos4415 uses Cortex A9 quad-cores and has a target
speed of 1.6GHz and provides 8.5GB/s memory bandwidth.
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/mach-exynos/Kconfig | 5 +
arch/arm/mach-exynos/exynos.c | 2 ++
2 files changed, 7 insertions(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 46f3c0d..349c867 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -75,6 +75,11 @@ config SOC_EXYNOS4412
default y
depends on ARCH_EXYNOS4
+config SOC_EXYNOS4415
+ bool "SAMSUNG EXYNOS4415"
+ default y
+ depends on ARCH_EXYNOS4
+
config SOC_EXYNOS5250
bool "SAMSUNG EXYNOS5250"
default y
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 1b46460..1da531f 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -252,6 +252,7 @@ static const struct of_device_id exynos_dt_pmu_match[] = {
{ .compatible = "samsung,exynos4210-pmu" },
{ .compatible = "samsung,exynos4212-pmu" },
{ .compatible = "samsung,exynos4412-pmu" },
+ { .compatible = "samsung,exynos4415-pmu" },
{ .compatible = "samsung,exynos5250-pmu" },
{ .compatible = "samsung,exynos5260-pmu" },
{ .compatible = "samsung,exynos5410-pmu" },
@@ -359,6 +360,7 @@ static char const *exynos_dt_compat[] __initconst = {
"samsung,exynos4210",
"samsung,exynos4212",
"samsung,exynos4412",
+ "samsung,exynos4415",
"samsung,exynos5",
"samsung,exynos5250",
"samsung,exynos5260",
--
1.8.5.5
--
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/
[PATCHv3 0/2] ARM: EXYNOS: Support new Exynos4415 SoC based on Cortex-A9 quad cores
This patchset support new Exynos4415 Samsung SoC based on Cortex-A9 quad cores. Exynos4415 is a System-On-Chip (SoC) that is based on 32-bit RISC processor for Smartphone. It is desigend with the 28nm low-power high-K metal gate process and provides the best performance features. This patchset include some patches such as: - Support booting of Exynos4415 - Supoort uart/mct/adc/gic/i2c/spi/power-domain/pmu/mshc/ehci/ohci/pwm/amba Changes from v2: - Modify the name of first patch Changes from v1: - Remove legacy helper function to identify SoC - Separate out the clock patches[2] from Exynos4415 patchset[1] and sent it [2] - Separate out the pinctrl patch[3] from Exynos4415 patchset[1] and sent it [3] [1] [PATCH 0/5] Support new Exynos4415 SoC based on Cortex-A9 quad cores : https://lkml.org/lkml/2014/10/19/253 [2] [PATCHv3 1/2] clk: samsung: exynos4415: Add clocks using common clock framework : https://lkml.org/lkml/2014/10/26/159 [3] [PATCHv2] pinctrl: exynos: Add support for Exynos4415 : https://lkml.org/lkml/2014/10/26/160 Chanwoo Choi (2): ARM: EXYNOS: Add EXYNOS4415 SoC ARM: dts: Add dts files for Exynos4415 SoC arch/arm/boot/dts/exynos4415-pinctrl.dtsi | 613 + arch/arm/boot/dts/exynos4415.dtsi | 627 ++ arch/arm/mach-exynos/Kconfig | 5 + arch/arm/mach-exynos/exynos.c | 2 + 4 files changed, 1247 insertions(+) create mode 100644 arch/arm/boot/dts/exynos4415-pinctrl.dtsi create mode 100644 arch/arm/boot/dts/exynos4415.dtsi -- 1.8.5.5 -- 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.10 00/43] 3.10.59-stable review
On 10/27/2014 08:35 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.59 release. There are 43 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 Thu Oct 30 03:35:12 UTC 2014. Anything received after that time might be too late. Build results: total: 137 pass: 137 fail: 0 Qemu test results: total: 27 pass: 27 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter -- 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 3.10 40/43] ALSA: emu10k1: Fix deadlock in synth voice lookup
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Takashi Iwai
commit 95926035b187cc9fee6fb61385b7da9c28123f74 upstream.
The emu10k1 voice allocator takes voice_lock spinlock. When there is
no empty stream available, it tries to release a voice used by synth,
and calls get_synth_voice. The callback function,
snd_emu10k1_synth_get_voice(), however, also takes the voice_lock,
thus it deadlocks.
The fix is simply removing the voice_lock holds in
snd_emu10k1_synth_get_voice(), as this is always called in the
spinlock context.
Reported-and-tested-by: Arthur Marsh
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/pci/emu10k1/emu10k1_callback.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/sound/pci/emu10k1/emu10k1_callback.c
+++ b/sound/pci/emu10k1/emu10k1_callback.c
@@ -85,6 +85,8 @@ snd_emu10k1_ops_setup(struct snd_emux *e
* get more voice for pcm
*
* terminate most inactive voice and give it as a pcm voice.
+ *
+ * voice_lock is already held.
*/
int
snd_emu10k1_synth_get_voice(struct snd_emu10k1 *hw)
@@ -92,12 +94,10 @@ snd_emu10k1_synth_get_voice(struct snd_e
struct snd_emux *emu;
struct snd_emux_voice *vp;
struct best_voice best[V_END];
- unsigned long flags;
int i;
emu = hw->synth;
- spin_lock_irqsave(>voice_lock, flags);
lookup_voices(emu, hw, best, 1); /* no OFF voices */
for (i = 0; i < V_END; i++) {
if (best[i].voice >= 0) {
@@ -113,11 +113,9 @@ snd_emu10k1_synth_get_voice(struct snd_e
vp->emu->num_voices--;
vp->ch = -1;
vp->state = SNDRV_EMUX_ST_OFF;
- spin_unlock_irqrestore(>voice_lock, flags);
return ch;
}
}
- spin_unlock_irqrestore(>voice_lock, flags);
/* not found */
return -ENOMEM;
--
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 0/1] arm64: Fix /proc/cpuinfo
On Fri, Oct 24, 2014 at 6:56 AM, Mark Rutland wrote: > [c] Print different hwcaps for compat tasks > > This would allow for 32-bit and 64-bit applications to function > correctly. Having the format differ depending on the instruction set > of the application reading /proc/cpuinfo may be misleading in some > cases (e.g. a human using a 32-bit cat to read /proc/cpuinfo on a > 64-bit system). FWIW we have an Nvidia-contributed patch in the android-3.10 kernel tree that basically does this. It works well in almost all cases. We've only found one situation so far where this approach falls apart. One specific Android NDK app detects NEON support by running "/system/bin/cat /proc/cpuinfo" in another process and searching for the string "neon" in the output. Even though the app itself is 32-bit, /system/bin/cat is 64-bit, so it reads the "wrong" /proc/cpuinfo and decides the CPU doesn't support NEON. >From Android's perspective, the only downside of using personalities instead is that our runtime will need to ensure 32-bit apps have the right personality. Our runtime team has said they're fine with doing this, if that's the direction the upstream kernel wants to go. > Are there applications for which any of these strategies will not work? We've found a handful of Android apps that expect the "CPU architecture" field to be "7" specifically and get confused by the existence of ARMv8. There's not much you can do on the kernel side to support those apps, other than lying about the CPU architecture to 32-bit apps (and we drew the line at doing that). -- 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 3.10 41/43] ALSA: usb-audio: Add support for Steinberg UR22 USB interface
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Vlad Catoi
commit f0b127fbfdc8756eba7437ab668f3169280bd358 upstream.
Adding support for Steinberg UR22 USB interface via quirks table patch
See Ubuntu bug report:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1317244
Also see threads:
http://linux-audio.4202.n7.nabble.com/Support-for-Steinberg-UR22-Yamaha-USB-chipset-0499-1509-tc82888.html#a82917
http://www.steinberg.net/forums/viewtopic.php?t=62290
Tested by at least 4 people judging by the threads.
Did not test MIDI interface, but audio output and capture both are
functional. Built 3.17 kernel with this driver on Ubuntu 14.04 & tested with
mpg123
Patch applied to 3.13 Ubuntu kernel works well enough for daily use.
Signed-off-by: Vlad Catoi
Acked-by: Clemens Ladisch
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/usb/quirks-table.h | 30 ++
1 file changed, 30 insertions(+)
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -386,6 +386,36 @@ YAMAHA_DEVICE(0x105d, NULL),
}
},
{
+ USB_DEVICE(0x0499, 0x1509),
+ .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) {
+ /* .vendor_name = "Yamaha", */
+ /* .product_name = "Steinberg UR22", */
+ .ifnum = QUIRK_ANY_INTERFACE,
+ .type = QUIRK_COMPOSITE,
+ .data = (const struct snd_usb_audio_quirk[]) {
+ {
+ .ifnum = 1,
+ .type = QUIRK_AUDIO_STANDARD_INTERFACE
+ },
+ {
+ .ifnum = 2,
+ .type = QUIRK_AUDIO_STANDARD_INTERFACE
+ },
+ {
+ .ifnum = 3,
+ .type = QUIRK_MIDI_YAMAHA
+ },
+ {
+ .ifnum = 4,
+ .type = QUIRK_IGNORE_INTERFACE
+ },
+ {
+ .ifnum = -1
+ }
+ }
+ }
+},
+{
USB_DEVICE(0x0499, 0x150a),
.driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) {
/* .vendor_name = "Yamaha", */
--
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 v6] cpuset: Replace all instances of time_t with time64_t
The following patch replaces all instances of time_t with time64_t i.e.
change the type used for representing time from 32-bit to 64-bit. All
32-bit kernels to date use a signed 32-bit time_t type, which can only
represent time until January 2038. Since embedded systems running 32-bit
Linux are going to survive beyond that date, we have to change all
current uses, in a backwards compatible way.
The patch also changes the function get_seconds() that returns a 32-bit
integer to ktime_get_seconds() that returns seconds as 64-bit integer.
The patch changes the type of ticks from time_t to u32. We keep ticks as
32-bits as the function uses 32-bit arithmetic which would prove less
expensive than 64-bit arithmetic and the function is expected to be
called atleast once every 32 seconds.
Signed-off-by: Heena Sirwani
Reviewed-by: Arnd Bergmann
---
Changes in v6:
- Changed the function ktime_get_ts64() to ktime_get_seconds().
kernel/cpuset.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 1f107c7..65c7b20 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#include
#include
@@ -68,7 +69,7 @@ struct static_key cpusets_enabled_key __read_mostly =
STATIC_KEY_INIT_FALSE;
struct fmeter {
int cnt;/* unprocessed events count */
int val;/* most recent output value */
- time_t time;/* clock (secs) when val computed */
+ time64_t time; /* clock (secs) when val computed */
spinlock_t lock;/* guards read or write of above */
};
@@ -1355,7 +1356,7 @@ out:
*/
#define FM_COEF 933/* coefficient for half-life of 10 secs */
-#define FM_MAXTICKS ((time_t)99) /* useless computing more ticks than this */
+#define FM_MAXTICKS ((u32)99) /* useless computing more ticks than this */
#define FM_MAXCNT 100 /* limit cnt to avoid overflow */
#define FM_SCALE 1000 /* faux fixed point scale */
@@ -1371,8 +1372,11 @@ static void fmeter_init(struct fmeter *fmp)
/* Internal meter update - process cnt events and update value */
static void fmeter_update(struct fmeter *fmp)
{
- time_t now = get_seconds();
- time_t ticks = now - fmp->time;
+ time64_t now;
+ u32 ticks;
+
+ now = ktime_get_seconds();
+ ticks = now - fmp->time;
if (ticks == 0)
return;
--
1.9.1
--
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] PM / Sleep: Timer quiesce in freeze state
On 2014/10/24 23:36, Peter Zijlstra wrote:
>> +
>> +static void freezer_idle(int cpu)
>> +{
>> +struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
>> +struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
>> +
>> +stop_critical_timings();
>> +
>> +while (suspend_freeze_wake == -1) {
>> +int next_state;
>> +
>> +/*
>> + * interrupt must be disabled before cpu enters idle
>> + */
>> +local_irq_disable();
>> +
>> +next_state = cpuidle_select(drv, dev);
>> +if (next_state < 0) {
>> +arch_cpu_idle();
>> +continue;
>> +}
>> +/*
>> + * cpuidle_enter will return with interrupt enabled
>> + */
>> +cpuidle_enter(drv, dev, next_state);
>> +}
>> +
>> +if (suspend_freeze_wake == cpu)
>> +kick_all_cpus_sync();
>> +
>
> So I disabled IRQs here
>
>> +start_critical_timings();
>> +}
>> +
>> +static void freezer_resume_tk(int cpu)
>> +{
>> +if (tick_do_timer_cpu != cpu)
>> +return;
>> +
>> cpuidle_pause();
>> cpuidle_use_deepest_state(false);
>> +
>
> Such that they would still be disabled here
>
>> +local_irq_disable();
>> +timekeeping_resume();
>> +local_irq_enable();
>> +}
>> +
>> +static void freezer_resume_clkevt(int cpu)
>> +{
>> +if (tick_do_timer_cpu == cpu)
>> +return;
>> +
>> +touch_softlockup_watchdog();
>> +clockevents_notify(CLOCK_EVT_NOTIFY_RESUME, NULL);
>
> And here.
>
>> +local_irq_disable();
>> +hrtimers_resume();
>> +local_irq_enable();
>> +}
>> +
>> +typedef void (*freezer_fn)(int);
>> +
>> +static freezer_fn freezer_func[FREEZER_EXIT] = {
>> +NULL,
>> +freezer_pick_tk,
>> +freezer_suspend_clkevt,
>> +freezer_suspend_tk,
>> +freezer_idle,
>> +freezer_resume_tk,
>> +freezer_resume_clkevt,
>> +};
>
> Because this is a stop_machine callback, which are nominally run with
> IRQs disabled.
>
>> +static int freezer_stopper_fn(void *arg)
>> +{
>> +struct freezer_data *fd = arg;
>> +enum freezer_state state = FREEZER_NONE;
>> +int cpu = smp_processor_id();
>> +
>> +do {
>> +cpu_relax();
>> +if (fd->state != state) {
>> +state = fd->state;
>> +if (freezer_func[state])
>> +(*freezer_func[state])(cpu);
>> +ack_state(fd);
>> +}
>> +} while (fd->state != FREEZER_EXIT);
>> +return 0;
>> +}
>
> Now I suppose the problem is with cpu_pause() which needs IPIs to
> complete?
Yes, cpu_pause() will invoke smp IPI functions which need interrupt is
enabled. So I changed irq ops like above. Actually, I have an early
version to move cpuidle_pause()/cpuidle_resume() out of stop_machine(),
that might be a better solution?
Thanks,
-Aubrey
--
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 v6] cpuset: Replace all instances of time_t with time64_t
The following patch replaces all instances of time_t with time64_t i.e.
change the type used for representing time from 32-bit to 64-bit. All
32-bit kernels to date use a signed 32-bit time_t type, which can only
represent time until January 2038. Since embedded systems running 32-bit
Linux are going to survive beyond that date, we have to change all
current uses, in a backwards compatible way.
The patch also changes the function get_seconds() that returns a 32-bit
integer to ktime_get_seconds() that returns seconds as 64-bit integer.
The patch changes the type of ticks from time_t to u32. We keep ticks as
32-bits as the function uses 32-bit arithmetic which would prove less
expensive than 64-bit arithmetic and the function is expected to be
called atleast once every 32 seconds.
Signed-off-by: Heena Sirwani
---
Changes in v6:
- Changed the function ktime_get_ts64() to ktime_get_seconds().
kernel/cpuset.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 1f107c7..65c7b20 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#include
#include
@@ -68,7 +69,7 @@ struct static_key cpusets_enabled_key __read_mostly =
STATIC_KEY_INIT_FALSE;
struct fmeter {
int cnt;/* unprocessed events count */
int val;/* most recent output value */
- time_t time;/* clock (secs) when val computed */
+ time64_t time; /* clock (secs) when val computed */
spinlock_t lock;/* guards read or write of above */
};
@@ -1355,7 +1356,7 @@ out:
*/
#define FM_COEF 933/* coefficient for half-life of 10 secs */
-#define FM_MAXTICKS ((time_t)99) /* useless computing more ticks than this */
+#define FM_MAXTICKS ((u32)99) /* useless computing more ticks than this */
#define FM_MAXCNT 100 /* limit cnt to avoid overflow */
#define FM_SCALE 1000 /* faux fixed point scale */
@@ -1371,8 +1372,11 @@ static void fmeter_init(struct fmeter *fmp)
/* Internal meter update - process cnt events and update value */
static void fmeter_update(struct fmeter *fmp)
{
- time_t now = get_seconds();
- time_t ticks = now - fmp->time;
+ time64_t now;
+ u32 ticks;
+
+ now = ktime_get_seconds();
+ ticks = now - fmp->time;
if (ticks == 0)
return;
--
1.9.1
--
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] mmc:core: fix hs400 timing selection
Hi, Chanho. On 10/22/2014 11:55 AM, Chanho Min wrote: > According to JEDEC v5.01 spec (6.6.5), In order to switch to HS400 mode, > host should perform the following steps. > > 1. HS200 mode selection completed > 2. Set HS_TIMING to 0x01(High Speed) > 3. Host changes frequency to =< 52MHz > 4. Set the bus width to DDR 8bit (CMD6) > 5. Host may read Driver Strength (CMD8) > 6. Set HS_TIMING to 0x03 (HS400) > > In current implementation, the order of 2 and 3 is reversed. > The HS_TIMING field should be set to 0x1 before the clock frequency > is set to a value not greater than 52 MHz. Otherwise, Initialization of > timing can be failed. Also, the host contoller's UHS timing mode should > be set to DDR50 after the bus width is set to DDR 8bit. > > Signed-off-by: Hankyung Yu > Signed-off-by: Chanho Min > --- > drivers/mmc/core/mmc.c | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c > index a301a78..52f78e0 100644 > --- a/drivers/mmc/core/mmc.c > +++ b/drivers/mmc/core/mmc.c > @@ -1061,9 +1061,6 @@ static int mmc_select_hs400(struct mmc_card *card) >* Before switching to dual data rate operation for HS400, >* it is required to convert from HS200 mode to HS mode. >*/ > - mmc_set_timing(card->host, MMC_TIMING_MMC_HS); > - mmc_set_bus_speed(card); > - > err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, > EXT_CSD_HS_TIMING, EXT_CSD_TIMING_HS, > card->ext_csd.generic_cmd6_time, > @@ -1074,6 +1071,14 @@ static int mmc_select_hs400(struct mmc_card *card) > return err; > } > > + /* > + * According to JEDEC v5.01 spec (6.6.5), Clock frequency should > + * be set to a value not greater than 52MHz after the HS_TIMING > + * field is set to 0x1. > + */ > + mmc_set_timing(card->host, MMC_TIMING_MMC_HS); > + mmc_set_bus_speed(card); > + > err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, >EXT_CSD_BUS_WIDTH, >EXT_CSD_DDR_BUS_WIDTH_8, > @@ -1084,6 +1089,8 @@ static int mmc_select_hs400(struct mmc_card *card) > return err; > } > > + mmc_set_timing(card->host, MMC_TIMING_MMC_DDR52); > + I didn't know why timing is set to ddr50. Best Regards, Jaehoon Chung > err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, > EXT_CSD_HS_TIMING, EXT_CSD_TIMING_HS400, > card->ext_csd.generic_cmd6_time, > -- 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] quirk for Lenovo Yoga 3: no rfkill switch
On Mon, Oct 27, 2014 at 04:09:50AM +0100, Stephan Mueller wrote: > The Yoga 3 does not contain any physical rfkill switch. Therefore > disable the rfkill switch identically to the Yoga 2 approach. > > Signed-off-by: Stephan Mueller Queued, thanks Stephan. -- Darren Hart Intel Open Source Technology Center -- 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 07/10] ARM: dts: tegra: Use standard power-off property in tps65911 for tegra30 apalis
On Tue, Oct 28, 2014 at 1:42 AM, Felipe Balbi wrote: > On Mon, Oct 27, 2014 at 04:26:52PM +, Romain Perier wrote: >> Signed-off-by: Romain Perier >> --- >> arch/arm/boot/dts/tegra30-apalis.dtsi | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi >> b/arch/arm/boot/dts/tegra30-apalis.dtsi >> index a5446cb..ced4436 100644 >> --- a/arch/arm/boot/dts/tegra30-apalis.dtsi >> +++ b/arch/arm/boot/dts/tegra30-apalis.dtsi >> @@ -412,7 +412,7 @@ >> #interrupt-cells = <2>; >> interrupt-controller; >> >> - ti,system-power-controller; >> + system-power-controller; > > this board is broken until this patch is applied. It should not. Supporting a new property in the tps65911 is fine, but the old property must keep being supported to preserve DT compatibility. If a change removing support for "ti,system-power-controller" has landed in -next, then it should be removed. -- 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 3.10 13/43] be2iscsi: check ip buffer before copying
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Mike Christie
commit a41a9ad3bbf61fae0b6bfb232153da60d14fdbd9 upstream.
Dan Carpenter found a issue where be2iscsi would copy the ip
from userspace to the driver buffer before checking the len
of the data being copied:
http://marc.info/?l=linux-scsi=140982651504251=2
This patch just has us only copy what we the driver buffer
can support.
Tested-by: John Soni Jose
Signed-off-by: Mike Christie
Signed-off-by: Christoph Hellwig
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/be2iscsi/be_mgmt.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/drivers/scsi/be2iscsi/be_mgmt.c
+++ b/drivers/scsi/be2iscsi/be_mgmt.c
@@ -812,17 +812,20 @@ mgmt_static_ip_modify(struct beiscsi_hba
if (ip_action == IP_ACTION_ADD) {
memcpy(req->ip_params.ip_record.ip_addr.addr, ip_param->value,
- ip_param->len);
+ sizeof(req->ip_params.ip_record.ip_addr.addr));
if (subnet_param)
memcpy(req->ip_params.ip_record.ip_addr.subnet_mask,
- subnet_param->value, subnet_param->len);
+ subnet_param->value,
+
sizeof(req->ip_params.ip_record.ip_addr.subnet_mask));
} else {
memcpy(req->ip_params.ip_record.ip_addr.addr,
- if_info->ip_addr.addr, ip_param->len);
+ if_info->ip_addr.addr,
+ sizeof(req->ip_params.ip_record.ip_addr.addr));
memcpy(req->ip_params.ip_record.ip_addr.subnet_mask,
- if_info->ip_addr.subnet_mask, ip_param->len);
+ if_info->ip_addr.subnet_mask,
+ sizeof(req->ip_params.ip_record.ip_addr.subnet_mask));
}
rc = mgmt_exec_nonemb_cmd(phba, _cmd, NULL, 0);
@@ -850,7 +853,7 @@ static int mgmt_modify_gateway(struct be
req->action = gtway_action;
req->ip_addr.ip_type = BE2_IPV4;
- memcpy(req->ip_addr.addr, gt_addr, param_len);
+ memcpy(req->ip_addr.addr, gt_addr, sizeof(req->ip_addr.addr));
return mgmt_exec_nonemb_cmd(phba, _cmd, NULL, 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/
Re: [RFC/PATCH] PM / Sleep: Timer quiesce in freeze state
On 2014/10/27 15:28, Peter Zijlstra wrote: > On Mon, Oct 27, 2014 at 02:27:27PM +0800, Li, Aubrey wrote: >>> Now I suppose the problem is with cpu_pause() which needs IPIs to >>> complete? Do we really need cpuidle_pause() there? >>> cpuidle_uninstall_handlers() seems like a daft thing to call just about >>> there. >> >> Please check the log of 8651f97bd951d0bb1c10fa24e3fa3455193f3548. >> Rafael should know more this question than me. > > That changelog explains its complete bollocks to do it here. We _want_ > to enter and/or remain in deep idle states. cpuidle_resume() will be called at the end of dpm_resume_noirq(). So we still are able to enter deep idle states after resume. Thanks, -Aubrey > -- > 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/ > > -- 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 3.10 38/43] arm64: compat: fix compat types affecting struct compat_elf_prpsinfo
3.10-stable review patch. If anyone has any objections, please let me know. -- From: Victor Kamensky commit 971a5b6fe634bb7b617d8c5f25b6a3ddbc600194 upstream. The compat_elf_prpsinfo structure does not match the arch/arm struct elf_pspsinfo definition. As result NT_PRPSINFO note in core file created by arm64 kernel for aarch32 (compat) process has wrong size. So gdb cannot display command that caused process crash. Fix is to change size of __compat_uid_t, __compat_gid_t so it would match size of similar fields in arch/arm case. Signed-off-by: Victor Kamensky Acked-by: Arnd Bergmann Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman --- arch/arm64/include/asm/compat.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/arm64/include/asm/compat.h +++ b/arch/arm64/include/asm/compat.h @@ -33,8 +33,8 @@ typedef s32 compat_ssize_t; typedef s32compat_time_t; typedef s32compat_clock_t; typedef s32compat_pid_t; -typedef u32__compat_uid_t; -typedef u32__compat_gid_t; +typedef u16__compat_uid_t; +typedef u16__compat_gid_t; typedef u16__compat_uid16_t; typedef u16__compat_gid16_t; typedef u32__compat_uid32_t; -- 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 3.10 30/43] PCI: Generate uppercase hex for modalias interface class
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Ricardo Ribalda Delgado
commit 89ec3dcf17fd3fa009ecf8faaba36828dd6bc416 upstream.
Some implementations of modprobe fail to load the driver for a PCI device
automatically because the "interface" part of the modalias from the kernel
is lowercase, and the modalias from file2alias is uppercase.
The "interface" is the low-order byte of the Class Code, defined in PCI
r3.0, Appendix D. Most interface types defined in the spec do not use
alpha characters, so they won't be affected. For example, 00h, 01h, 10h,
20h, etc. are unaffected.
Print the "interface" byte of the Class Code in uppercase hex, as we
already do for the Vendor ID, Device ID, Class, etc.
[bhelgaas: changelog]
Signed-off-by: Ricardo Ribalda Delgado
Signed-off-by: Bjorn Helgaas
Acked-by: Greg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman
---
drivers/pci/pci-sysfs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -175,7 +175,7 @@ static ssize_t modalias_show(struct devi
{
struct pci_dev *pci_dev = to_pci_dev(dev);
- return sprintf(buf, "pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02x\n",
+ return sprintf(buf, "pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02X\n",
pci_dev->vendor, pci_dev->device,
pci_dev->subsystem_vendor, pci_dev->subsystem_device,
(u8)(pci_dev->class >> 16), (u8)(pci_dev->class >> 8),
--
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: [PATCHv2 1/2] ARM: EXYNOS: Add EXYNOS4415 SoC ID
Chanwoo Choi wrote: > > Dear Kukjin, > [...] > >> > >> +config SOC_EXYNOS4415 > >> + bool "SAMSUNG EXYNOS4415" > >> + default y > >> + depends on ARCH_EXYNOS4 > >> + > > > > I think, this is not required more... > > But, > The clock driver must need to CONFIG_SOC_EXYNOS4415 configuration > to build it. The clock driver[1] of exynos4415 used CONFIG_SOC_EXYNOS4415 as > following diff: > [1] https://lkml.org/lkml/2014/10/26/159 > Oh, yes. OK. Thanks for quick reply. - Kukjin > diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile > index 8909c93..4561297 100644 > --- a/drivers/clk/samsung/Makefile > +++ b/drivers/clk/samsung/Makefile > @@ -5,6 +5,7 @@ > obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o > obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o > obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o > +obj-$(CONFIG_SOC_EXYNOS4415) += clk-exynos4415.o > > Best Regards, > Chanwoo Choi -- 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 3.10 29/43] PCI: Increase IBM ipr SAS Crocodile BARs to at least system page size
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Douglas Lehr
commit 9fe373f9997b48fcd6222b95baf4a20c134b587a upstream.
The Crocodile chip occasionally comes up with 4k and 8k BAR sizes. Due to
an erratum, setting the SR-IOV page size causes the physical function BARs
to expand to the system page size. Since ppc64 uses 64k pages, when Linux
tries to assign the smaller resource sizes to the now 64k BARs the address
will be truncated and the BARs will overlap.
Force Linux to allocate the resource as a full page, which avoids the
overlap.
[bhelgaas: print expanded resource, too]
Signed-off-by: Douglas Lehr
Signed-off-by: Anton Blanchard
Signed-off-by: Bjorn Helgaas
Acked-by: Milton Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/pci/quirks.c | 20
1 file changed, 20 insertions(+)
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include/* isa_dma_bridge_buggy */
#include "pci.h"
@@ -291,6 +292,25 @@ static void quirk_citrine(struct pci_dev
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_IBM,PCI_DEVICE_ID_IBM_CITRINE,
quirk_citrine);
+/* On IBM Crocodile ipr SAS adapters, expand BAR to system page size */
+static void quirk_extend_bar_to_page(struct pci_dev *dev)
+{
+ int i;
+
+ for (i = 0; i < PCI_STD_RESOURCE_END; i++) {
+ struct resource *r = >resource[i];
+
+ if (r->flags & IORESOURCE_MEM && resource_size(r) < PAGE_SIZE) {
+ r->end = PAGE_SIZE - 1;
+ r->start = 0;
+ r->flags |= IORESOURCE_UNSET;
+ dev_info(>dev, "expanded BAR %d to page size:
%pR\n",
+i, r);
+ }
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_IBM, 0x034a, quirk_extend_bar_to_page);
+
/*
* S3 868 and 968 chips report region size equal to 32M, but they decode 64M.
* If it's needed, re-allocate the region.
--
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 7/8] x86, perf: Only allow rdpmc if a perf_event is mapped
On Mon, Oct 27, 2014 at 9:07 PM, Hillf Danton wrote: >> >> Subject: Re: [PATCH v2 7/8] x86, perf: Only allow rdpmc if a perf_event >> >> is mapped >> >> >> > CPU D CPU A >> > switch_mm >> > load_mm_cr4 >> > x86_pmu_event_unmapped >> > >> > I wonder if the X86_CR4_PCE set on CPU D is >> > cleared by CPU A by broadcasting IPI. >> > >> >> It should be okay. The IPI does: >> >> + if (current->mm) >> + load_mm_cr4(current->mm); >> >> which refers to the current task running on the targetted CPU, not to >> the IPI sender's task. So, if it happens after a context switch, it >> will harmlessly reload the new task's cr4. >> > Right, but prev != next is checked in switch_mm. If that happens and !cpumask_test_cpu(cpu, mm_cpumask(next)), then cr4 will be reloaded. So, in the case you described, we should still be okay. It's worth checking whether a more complicated race could be a problem. I think it's okay. Here's my argument. In x86_pmu_event_mapped / x86_pmu_event_unmapped, for each cpu, either that cpu is set in mm_cpumask or it's clear. If it's set, then we'll send the IPI and that cpu is guaranteed to be updated. If it's clear, then it must become set before any user code in this mm can be executed. There are no paths through switch_mm that set the bit in mm_cpumask without reloading cr4, so we should be safe. Is that convincing? --Andy > > Hillf > > -- Andy Lutomirski AMA Capital Management, LLC -- 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] ASoC: fsl_asrc: Add reg_defaults for regmap to fix kernel dump
On Tue, Oct 28, 2014 at 12:19:04AM +, Mark Brown wrote: > On Fri, Oct 24, 2014 at 07:03:57PM -0700, Nicolin Chen wrote: > > Kernel dump (WARN_ON) ocurred during system boot-up inside regmap_write(): > > > > [ cut here ] > > WARNING: CPU: 0 PID: 47 at kernel/locking/lockdep.c:2744 > > lockdep_trace_alloc+0xe8/0x108() > > Even though this may be a bug that should be fixed, I still try to send this > > patch as a quick fix (work around) since it does no harm to assign default > > values of every registers when using regcache. > > It's not a bug, it's not reasonable to default allocations to atomic and > we can't really tell what context we're in. Anything used inside a > heavily locked path should either have a default provided or arrange for > a prior write to set up the cache. I've a little trouble to understand the prior write over here. Inside my probe() there's a register_init() call which has a set of regmap_write(). And then the first regmap_write() results the dump. Does that mean this regmap_write() isn't prior write? If so, how should I do if not setting default values here -- Some IPs may have default value 0 for registers. And this would make reg_defaults tedious since there's nothing special to assign. And actually I remember I haven't seen any dump when I sent the initial patch for the whole ASRC driver but it manifested last month. I thought it might be a partially-merging issue and it would be fixed after merge window's done. Thank you Nicolin -- 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] overlay filesystem v25
On Tue, Oct 28, 2014 at 01:12:14AM +, Al Viro wrote:
> On Mon, Oct 27, 2014 at 10:36:21AM -0700, Paul E. McKenney wrote:
> > Code making direct use of smp_read_barrier_depends() is harder to read,
> > in my experience, but good point on the sparse noise. Maybe a new
> > lockless_dereference() primitive? Maybe something like the following?
> > (Untested, probably does not even build.)
> >
> > #define lockless_dereference(p) \
> > ({ \
> > typeof(*p) *_p1 = ACCESS_ONCE(p); \
> > smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
> > _p1; \
> > })
>
> Hmm... Where would you prefer to put it? rcupdate.h?
Good a place as any, I guess. Please see patch below. Left to myself,
I would send this along for the next merge window, but please let me
know if you would like it sooner.
Thanx, Paul
rcu: Provide counterpart to rcu_dereference() for non-RCU situations
Although rcu_dereference() and friends can be used in situations where
object lifetimes are being managed by something other than RCU, the
resulting sparse and lockdep-RCU noise can be annoying. This commit
therefore supplies a lockless_dereference(), which provides the
protection for dereferences without the RCU-related debugging noise.
Reported-by: Al Viro
Signed-off-by: Paul E. McKenney
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 9575c2d403b5..ed4f5939a452 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -617,6 +617,21 @@ static inline void rcu_preempt_sleep_check(void)
#define RCU_INITIALIZER(v) (typeof(*(v)) __force __rcu *)(v)
/**
+ * lockless_dereference() - safely load a pointer for later dereference
+ * @p: The pointer to load
+ *
+ * Similar to rcu_dereference(), but for situations where the pointed-to
+ * object's lifetime is managed by something other than RCU. That
+ * "something other" might be reference counting or simple immortality.
+ */
+#define lockless_dereference(p) \
+({ \
+ typeof(p) _p1 = ACCESS_ONCE(p); \
+ smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
+ (_p1); \
+})
+
+/**
* rcu_assign_pointer() - assign to RCU-protected pointer
* @p: pointer to assign to
* @v: value to assign (publish)
--
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 3.10 14/43] mptfusion: enable no_write_same for vmware scsi disks
3.10-stable review patch. If anyone has any objections, please let me know. -- From: Chris J Arges commit 4089b71cc820a426d601283c92fcd4ffeb5139c2 upstream. When using a virtual SCSI disk in a VMWare VM if blkdev_issue_zeroout is used data can be improperly zeroed out using the mptfusion driver. This patch disables write_same for this driver and the vmware subsystem_vendor which ensures that manual zeroing out is used instead. BugLink: http://bugs.launchpad.net/bugs/1371591 Reported-by: Bruce Lucas Tested-by: Chris J Arges Signed-off-by: Chris J Arges Reviewed-by: Martin K. Petersen Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman --- drivers/message/fusion/mptspi.c |5 + 1 file changed, 5 insertions(+) --- a/drivers/message/fusion/mptspi.c +++ b/drivers/message/fusion/mptspi.c @@ -1422,6 +1422,11 @@ mptspi_probe(struct pci_dev *pdev, const goto out_mptspi_probe; } + /* VMWare emulation doesn't properly implement WRITE_SAME +*/ + if (pdev->subsystem_vendor == 0x15AD) + sh->no_write_same = 1; + spin_lock_irqsave(>FreeQlock, flags); /* Attach the SCSI Host to the IOC structure -- 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: manual merge of the akpm-current tree with the dma-mapping tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
mm/cma.c between commit 16195ddd4ebc ("mm: cma: Ensure that
reservations never cross the low/high mem boundary") from the
dma-mapping tree and commit 2a70e5a78672 ("mm/cma: ake kmemleak ignore
CMA regions") from the akpm-current tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc mm/cma.c
index fde706e1284f,471fcfef043b..
--- a/mm/cma.c
+++ b/mm/cma.c
@@@ -278,30 -274,20 +278,35 @@@ int __init cma_declare_contiguous(phys_
goto err;
}
} else {
- phys_addr_t addr = memblock_alloc_range(size, alignment, base,
- limit);
+ phys_addr_t addr = 0;
+
+ /*
+ * All pages in the reserved area must come from the same zone.
+ * If the requested region crosses the low/high memory boundary,
+ * try allocating from high memory first and fall back to low
+ * memory in case of failure.
+ */
+ if (base < highmem_start && limit > highmem_start) {
+ addr = memblock_alloc_range(size, alignment,
+ highmem_start, limit);
+ limit = highmem_start;
+ }
+
if (!addr) {
- ret = -ENOMEM;
- goto err;
- } else {
- /*
- * kmemleak scans/reads tracked objects for pointers to
- * other objects but this address isn't mapped and
- * accessible
- */
- kmemleak_ignore(phys_to_virt(addr));
- base = addr;
+ addr = memblock_alloc_range(size, alignment, base,
+ limit);
+ if (!addr) {
+ ret = -ENOMEM;
+ goto err;
+ }
}
-
++ /*
++ * kmemleak scans/reads tracked objects for pointers to
++ * other objects but this address isn't mapped and
++ * accessible
++ */
++ kmemleak_ignore(phys_to_virt(addr));
+ base = addr;
}
ret = cma_init_reserved_mem(base, size, order_per_bit, res_cma);
pgptwzoPjp7Zy.pgp
Description: OpenPGP digital signature
[PATCH 3.10 31/43] rt2800: correct BBP1_TX_POWER_CTRL mask
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Stanislaw Gruszka
commit 01f7feeaf4528bec83798316b3c811701bac5d3e upstream.
Two bits control TX power on BBP_R1 register. Correct the mask,
otherwise we clear additional bit on BBP_R1 register, what can have
unknown, possible negative effect.
Signed-off-by: Stanislaw Gruszka
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/rt2x00/rt2800.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/rt2x00/rt2800.h
+++ b/drivers/net/wireless/rt2x00/rt2800.h
@@ -1920,7 +1920,7 @@ struct mac_iveiv_entry {
* 2 - drop tx power by 12dBm,
* 3 - increase tx power by 6dBm
*/
-#define BBP1_TX_POWER_CTRL FIELD8(0x07)
+#define BBP1_TX_POWER_CTRL FIELD8(0x03)
#define BBP1_TX_ANTENNAFIELD8(0x18)
/*
--
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 3.10 39/43] ALSA: pcm: use the same dma mmap codepath both for arm and arm64
3.10-stable review patch. If anyone has any objections, please let me know. -- From: Anatol Pomozov commit a011e213f3700233ed2a676f1ef0a74a052d7162 upstream. This avoids following kernel crash when try to playback on arm64 [ 107.497203] [] snd_pcm_mmap_data_fault+0x90/0xd4 [ 107.503405] [] __do_fault+0xb0/0x498 [ 107.508565] [] handle_mm_fault+0x224/0x7b0 [ 107.514246] [] do_page_fault+0x11c/0x310 [ 107.519738] [] do_mem_abort+0x38/0x98 Tested: backported to 3.14 and tried to playback on arm64 machine Signed-off-by: Anatol Pomozov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- sound/core/pcm_native.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -3197,7 +3197,7 @@ static const struct vm_operations_struct #ifndef ARCH_HAS_DMA_MMAP_COHERENT /* This should be defined / handled globally! */ -#ifdef CONFIG_ARM +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) #define ARCH_HAS_DMA_MMAP_COHERENT #endif #endif -- 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] Documentation: gpio: guidelines for bindings
Now that ACPI supports named GPIO properties, either through ACPI 5.1 or
the per-driver ACPI GPIO mappings, we can be more narrow about the way
GPIOs should be specified in Device Tree bindings.
This patch updates the GPIO DT bindings documentation to highlight the
following rules for new GPIO bindings:
- All new bindings must have a meaningful name (e.g. the "gpios"
property must not be used)
- The only suffix allowed is "-gpios", no matter the number of
descriptors in the property
- GPIOs can only be grouped under the same property when they serve the
same purpose, a case that should remain exceptional (e.g. bit-banged
data lines).
Signed-off-by: Alexandre Courbot
CC: Linus Walleij
CC: Arnd Bergmann
CC: Rafael J. Wysocki
CC: Mika Westerberg
---
Documentation/devicetree/bindings/gpio/gpio.txt | 41 +
1 file changed, 29 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt
b/Documentation/devicetree/bindings/gpio/gpio.txt
index 3fb8f53071b8..1043f8b47433 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -13,13 +13,23 @@ properties, each containing a 'gpio-list':
gpio-specifier : Array of #gpio-cells specifying specific gpio
(controller specific)
-GPIO properties should be named "[-]gpios". The exact
-meaning of each gpios property must be documented in the device tree
+GPIO properties should be named "[-]gpios", with being the con_id
+argument that is passed to gpiod_get(). While a NULL con_id is accepted by the
+GPIO API for compatibility reasons (resolving to the "gpios" property), it is
+not allowed for new bindings.
+
+GPIO properties can contain one or more GPIO phandles, but only in exceptional
+cases should they contain more than one. If your device uses several GPIOs with
+distinct functions, reference each of them under its own property, giving it a
+meaningful name. The only case where an array of GPIOs is accepted is when
+several GPIOs serve the same function (e.g. a parallel data line). In that case
+individual GPIOs can be retrieved using gpiod_get_index().
+
+The exact meaning of each gpios property must be documented in the device tree
binding for each device.
For example, the following could be used to describe GPIO pins used
-as chip select lines; with chip selects 0, 1 and 3 populated, and chip
-select 2 left empty:
+as device enable and bit-banged data signals:
gpio1: gpio1 {
gpio-controller
@@ -30,10 +40,16 @@ select 2 left empty:
#gpio-cells = <1>;
};
[...]
-chipsel-gpios = < 12 0>,
-< 13 0>,
-<0>, /* holes are permitted, means no GPIO 2 */
-< 2>;
+
+ enable-gpios = < 2>;
+ data-gpios = < 12 0>,
+< 13 0>,
+< 14 0>,
+< 15 0>;
+
+The "enable" GPIO can then be retrieved using gpiod_get(dev, "enable", ...),
+and the data GPIOs are reached by calling gpiod_get_index(dev, "data", idx,
...)
+where idx can go from 0 to 3 included.
Note that gpio-specifier length is controller dependent. In the
above example, uses 2 cells to specify a gpio, while
@@ -42,16 +58,17 @@ only uses one.
gpio-specifier may encode: bank, pin position inside the bank,
whether pin is open-drain and whether pin is logically inverted.
Exact meaning of each specifier cell is controller specific, and must
-be documented in the device tree binding for the device.
+be documented in the device tree binding for the device. Use the macros
+defined in include/dt-bindings/gpio/gpio.h whenever possible:
Example of a node using GPIOs:
node {
- gpios = <_pio_e 18 0>;
+ enable-gpios = <_pio_e 18 GPIO_ACTIVE_HIGH>;
};
-In this example gpio-specifier is "18 0" and encodes GPIO pin number,
-and GPIO flags as accepted by the "qe_pio_e" gpio-controller.
+GPIO_ACTIVE_HIGH is 0, so in this example gpio-specifier is "18 0" and encodes
+GPIO pin number, and GPIO flags as accepted by the "qe_pio_e" gpio-controller.
1.1) GPIO specifier best practices
--
--
2.1.2
--
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 3.10 43/43] ecryptfs: avoid to access NULL pointer when write metadata in xattr
3.10-stable review patch. If anyone has any objections, please let me know. -- From: Chao Yu commit 35425ea2492175fd39f6116481fe98b2b3ddd4ca upstream. Christopher Head 2014-06-28 05:26:20 UTC described: "I tried to reproduce this on 3.12.21. Instead, when I do "echo hello > foo" in an ecryptfs mount with ecryptfs_xattr specified, I get a kernel crash: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] fsstack_copy_attr_all+0x2/0x61 PGD d7840067 PUD b2c3c067 PMD 0 Oops: 0002 [#1] SMP Modules linked in: nvidia(PO) CPU: 3 PID: 3566 Comm: bash Tainted: P O 3.12.21-gentoo-r1 #2 Hardware name: ASUSTek Computer Inc. G60JX/G60JX, BIOS 206 03/15/2010 task: 8801948944c0 ti: 8800bad7 task.ti: 8800bad7 RIP: 0010:[] [] fsstack_copy_attr_all+0x2/0x61 RSP: 0018:8800bad71c10 EFLAGS: 00010246 RAX: 000181a4 RBX: 880198648480 RCX: RDX: 0004 RSI: 880172010450 RDI: RBP: 880198490e40 R08: R09: R10: 880172010450 R11: ea0002c51e80 R12: 2000 R13: 001a R14: R15: 880198490e40 FS: 7ff224caa700() GS:88019fcc() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: bb07f000 CR4: 07e0 Stack: 811826e8 8800a39d8000 001a 8800a01d 8800a39d8000 81185fd5 81082c2c 0001a39d8000 53d0abbc98490e40 0037 8800a39d8220 Call Trace: [] ? ecryptfs_setxattr+0x40/0x52 [] ? ecryptfs_write_metadata+0x1b3/0x223 [] ? should_resched+0x5/0x23 [] ? ecryptfs_initialize_file+0xaf/0xd4 [] ? ecryptfs_create+0xf4/0x142 [] ? vfs_create+0x48/0x71 [] ? do_last.isra.68+0x559/0x952 [] ? link_path_walk+0xbd/0x458 [] ? path_openat+0x224/0x472 [] ? do_filp_open+0x2b/0x6f [] ? __alloc_fd+0xd6/0xe7 [] ? do_sys_open+0x65/0xe9 [] ? system_call_fastpath+0x16/0x1b RIP [] fsstack_copy_attr_all+0x2/0x61 RSP CR2: ---[ end trace df9dba5f1ddb8565 ]---" If we create a file when we mount with ecryptfs_xattr_metadata option, we will encounter a crash in this path: ->ecryptfs_create ->ecryptfs_initialize_file ->ecryptfs_write_metadata ->ecryptfs_write_metadata_to_xattr ->ecryptfs_setxattr ->fsstack_copy_attr_all It's because our dentry->d_inode used in fsstack_copy_attr_all is NULL, and it will be initialized when ecryptfs_initialize_file finish. So we should skip copying attr from lower inode when the value of ->d_inode is invalid. Signed-off-by: Chao Yu Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman --- fs/ecryptfs/inode.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/ecryptfs/inode.c +++ b/fs/ecryptfs/inode.c @@ -1051,7 +1051,7 @@ ecryptfs_setxattr(struct dentry *dentry, } rc = vfs_setxattr(lower_dentry, name, value, size, flags); - if (!rc) + if (!rc && dentry->d_inode) fsstack_copy_attr_all(dentry->d_inode, lower_dentry->d_inode); out: return rc; -- 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 3.10 42/43] ARM: at91/PMC: dont forget to write PMC_PCDR register to disable clocks
3.10-stable review patch. If anyone has any objections, please let me know. -- From: Ludovic Desroches commit cfa1950e6c6b72251e80adc736af3c3d2907ab0e upstream. When introducing support for sama5d3, the write to PMC_PCDR register has been accidentally removed. Reported-by: Nathalie Cyrille Signed-off-by: Ludovic Desroches Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman --- arch/arm/mach-at91/clock.c |1 + 1 file changed, 1 insertion(+) --- a/arch/arm/mach-at91/clock.c +++ b/arch/arm/mach-at91/clock.c @@ -947,6 +947,7 @@ static int __init at91_clock_reset(void) } at91_pmc_write(AT91_PMC_SCDR, scdr); + at91_pmc_write(AT91_PMC_PCDR, pcdr); if (cpu_is_sama5d3()) at91_pmc_write(AT91_PMC_PCDR1, pcdr1); -- 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 3.10 32/43] Bluetooth: Fix HCI H5 corrupted ack value
3.10-stable review patch. If anyone has any objections, please let me know. -- From: Loic Poulain commit 4807b51895dce8aa650ebebc51fa4a795ed6b8b8 upstream. In this expression: seq = (seq - 1) % 8 seq (u8) is implicitly converted to an int in the arithmetic operation. So if seq value is 0, operation is ((0 - 1) % 8) => (-1 % 8) => -1. The new seq value is 0xff which is an invalid ACK value, we expect 0x07. It leads to frequent dropped ACK and retransmission. Fix this by using '&' binary operator instead of '%'. Signed-off-by: Loic Poulain Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman --- drivers/bluetooth/hci_h5.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/bluetooth/hci_h5.c +++ b/drivers/bluetooth/hci_h5.c @@ -237,7 +237,7 @@ static void h5_pkt_cull(struct h5 *h5) break; to_remove--; - seq = (seq - 1) % 8; + seq = (seq - 1) & 0x07; } if (seq != h5->rx_ack) -- 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 3.10 34/43] mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Junxiao Bi
commit 934f3072c17cc8886f4c043b47eeeb1b12f8de33 upstream.
commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O
during memory allocation") introduces PF_MEMALLOC_NOIO flag to avoid doing
I/O inside memory allocation, __GFP_IO is cleared when this flag is set,
but __GFP_FS implies __GFP_IO, it should also be cleared. Or it may still
run into I/O, like in superblock shrinker. And this will make the kernel
run into the deadlock case described in that commit.
See Dave Chinner's comment about io in superblock shrinker:
Filesystem shrinkers do indeed perform IO from the superblock shrinker and
have for years. Even clean inodes can require IO before they can be freed
- e.g. on an orphan list, need truncation of post-eof blocks, need to
wait for ordered operations to complete before it can be freed, etc.
IOWs, Ext4, btrfs and XFS all can issue and/or block on arbitrary amounts
of IO in the superblock shrinker context. XFS, in particular, has been
doing transactions and IO from the VFS inode cache shrinker since it was
first introduced
Fix this by clearing __GFP_FS in memalloc_noio_flags(), this function has
masked all the gfp_mask that will be passed into fs for the processes
setting PF_MEMALLOC_NOIO in the direct reclaim path.
v1 thread at: https://lkml.org/lkml/2014/9/3/32
Signed-off-by: Junxiao Bi
Cc: Dave Chinner
Cc: joyce.xue
Cc: Ming Lei
Cc: Trond Myklebust
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
include/linux/sched.h |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1670,11 +1670,13 @@ extern void thread_group_cputime_adjuste
#define tsk_used_math(p) ((p)->flags & PF_USED_MATH)
#define used_math() tsk_used_math(current)
-/* __GFP_IO isn't allowed if PF_MEMALLOC_NOIO is set in current->flags */
+/* __GFP_IO isn't allowed if PF_MEMALLOC_NOIO is set in current->flags
+ * __GFP_FS is also cleared as it implies __GFP_IO.
+ */
static inline gfp_t memalloc_noio_flags(gfp_t flags)
{
if (unlikely(current->flags & PF_MEMALLOC_NOIO))
- flags &= ~__GFP_IO;
+ flags &= ~(__GFP_IO | __GFP_FS);
return 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/
Re: [PATCH v2] asus-nb-wmi: Add wapf4 quirk for the X550VB
On Sun, Oct 26, 2014 at 11:23:55AM +0100, Stanislaw Gruszka wrote: > X550VB as many others Asus laptops need wapf4 quirk to make RFKILL > switch be functional. Otherwise system boots with wireless card > disabled and is only possible to enable it by suspend/resume. > > Bug report: > http://bugzilla.redhat.com/show_bug.cgi?id=1089731#c23 > > Reported-and-tested-by: Vratislav Podzimek > Signed-off-by: Stanislaw Gruszka Queued, thanks Stanislaw. -- Darren Hart Intel Open Source Technology Center -- 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Tue, Oct 28, 2014 at 7:34 AM, Rafael J. Wysocki wrote: > On Monday, October 27, 2014 02:21:23 PM Alexandre Courbot wrote: >> On Sat, Oct 25, 2014 at 7:05 AM, Rafael J. Wysocki >> wrote: >> > From: Rafael J. Wysocki >> > >> > Provide a way for device drivers using GPIOs described by ACPI >> > GpioIo resources in _CRS to tell the GPIO subsystem what names >> > (connection IDs) to associate with specific GPIO pins defined >> > in there. >> > >> > To do that, a driver needs to define a mapping table as a >> > NULL-terminated array of struct acpi_gpio_mapping objects >> > that each contain a name, a pointer to an array of pin data >> > (struct acpi_gpio_params) objects and the size of that array. >> > >> > Each struct acpi_gpio_params object consists of three fields, >> > crs_entry_index, pin_index, active_low, representing the index of >> > the target GpioIo()/GpioInt() resource in _CRS starting from zero, >> > the index of the target pin in that resource starting from zero, >> > and the active-low flag for that pin, respectively. >> > >> > Next, the mapping table needs to be passed as the second argument to >> > acpi_dev_add_driver_gpios() that will register it with the ACPI device >> > object pointed to by its first argument. That object must represent >> > the ACPI namespace node containing the _CRS object referred to by the >> > GPIO mapping. That should be done in the driver's .probe() routine. >> > >> > On removal, the driver should unregister its GPIO mapping table >> > by calling acpi_dev_remove_driver_gpios() on the ACPI device >> > object where that table was previously registered. >> > >> > Included are fixes from Mika Westerberg. >> >> Acked-by: Alexandre Courbot >> >> As we discussed already, this is a great idea. The only thing that is >> missing is a paragraph in Documentation/gpio/consumer.txt with an >> explanation of the global mechanism and a simple example to illustrate >> how and when this should be used. > > Yes, I'm going to provide documentation. > > One question, though. We're already adding gpio-properties.txt under > Documentation/acpi/ containing analogous information for _DSD-based > mappings. I thought I'd add a section to that file and a short paragraph > pointing to it into consumer.txt, would that work? Definitely yes, since this is ACPI-specific. Thanks! -- 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: [PATCHv3 0/2] clk: samsung: Add clock controller driver for Exynos4415 SoC
Sylwester Nawrocki wrote: > > On 27/10/14 02:11, Chanwoo Choi wrote: > > Chanwoo Choi (2): > > clk: samsung: exynos4415: Add clocks using common clock framework > > clk: samsung: Document binding for Exynos4415 clock controller > > Added both to my tree, thanks. In future please put DT binding > documentation first in the series, before the actual driver patch. > Hi Sylwester, Can you please provide a topic branch for clk-exynos4415? Because exynos4415 dt file needs inclusion of following header files. +#include +#include Thanks, Kukjin -- 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 3.10 27/43] NFSv4.1: Fix an NFSv4.1 state renewal regression
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Adamson
commit d1f456b0b9545f1606a54cd17c20775f159bd2ce upstream.
Commit 2f60ea6b8ced ("NFSv4: The NFSv4.0 client must send RENEW calls if it
holds a delegation") set the NFS4_RENEW_TIMEOUT flag in nfs4_renew_state, and
does
not put an nfs41_proc_async_sequence call, the NFSv4.1 lease renewal heartbeat
call, on the wire to renew the NFSv4.1 state if the flag was not set.
The NFS4_RENEW_TIMEOUT flag is set when "now" is after the last renewal
(cl_last_renewal) plus the lease time divided by 3. This is arbitrary and
sometimes does the following:
In normal operation, the only way a future state renewal call is put on the
wire is via a call to nfs4_schedule_state_renewal, which schedules a
nfs4_renew_state workqueue task. nfs4_renew_state determines if the
NFS4_RENEW_TIMEOUT should be set, and the calls nfs41_proc_async_sequence,
which only gets sent if the NFS4_RENEW_TIMEOUT flag is set.
Then the nfs41_proc_async_sequence rpc_release function schedules
another state remewal via nfs4_schedule_state_renewal.
Without this change we can get into a state where an application stops
accessing the NFSv4.1 share, state renewal calls stop due to the
NFS4_RENEW_TIMEOUT flag _not_ being set. The only way to recover
from this situation is with a clientid re-establishment, once the application
resumes and the server has timed out the lease and so returns
NFS4ERR_BAD_SESSION on the subsequent SEQUENCE operation.
An example application:
open, lock, write a file.
sleep for 6 * lease (could be less)
ulock, close.
In the above example with NFSv4.1 delegations enabled, without this change,
there are no OP_SEQUENCE state renewal calls during the sleep, and the
clientid is recovered due to lease expiration on the close.
This issue does not occur with NFSv4.1 delegations disabled, nor with
NFSv4.0, with or without delegations enabled.
Signed-off-by: Andy Adamson
Link:
http://lkml.kernel.org/r/1411486536-23401-1-git-send-email-and...@netapp.com
Fixes: 2f60ea6b8ced (NFSv4: The NFSv4.0 client must send RENEW calls...)
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/nfs4proc.c |2 +-
fs/nfs/nfs4renewd.c | 12 ++--
2 files changed, 11 insertions(+), 3 deletions(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -6067,7 +6067,7 @@ static int nfs41_proc_async_sequence(str
int ret = 0;
if ((renew_flags & NFS4_RENEW_TIMEOUT) == 0)
- return 0;
+ return -EAGAIN;
task = _nfs41_proc_sequence(clp, cred, false);
if (IS_ERR(task))
ret = PTR_ERR(task);
--- a/fs/nfs/nfs4renewd.c
+++ b/fs/nfs/nfs4renewd.c
@@ -88,10 +88,18 @@ nfs4_renew_state(struct work_struct *wor
}
nfs_expire_all_delegations(clp);
} else {
+ int ret;
+
/* Queue an asynchronous RENEW. */
- ops->sched_state_renewal(clp, cred, renew_flags);
+ ret = ops->sched_state_renewal(clp, cred, renew_flags);
put_rpccred(cred);
- goto out_exp;
+ switch (ret) {
+ default:
+ goto out_exp;
+ case -EAGAIN:
+ case -ENOMEM:
+ break;
+ }
}
} else {
dprintk("%s: failed to call renewd. Reason: lease not expired
\n",
--
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 7/8] x86, perf: Only allow rdpmc if a perf_event is mapped
> >> Subject: Re: [PATCH v2 7/8] x86, perf: Only allow rdpmc if a perf_event is > >> mapped > >> > > CPU D CPU A > > switch_mm > > load_mm_cr4 > > x86_pmu_event_unmapped > > > > I wonder if the X86_CR4_PCE set on CPU D is > > cleared by CPU A by broadcasting IPI. > > > > It should be okay. The IPI does: > > + if (current->mm) > + load_mm_cr4(current->mm); > > which refers to the current task running on the targetted CPU, not to > the IPI sender's task. So, if it happens after a context switch, it > will harmlessly reload the new task's cr4. > Right, but prev != next is checked in switch_mm. Hillf -- 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: [PATCHv2 1/2] ARM: EXYNOS: Add EXYNOS4415 SoC ID
Dear Kukjin, On 10/28/2014 12:48 PM, Kukjin Kim wrote: > Chanwoo Choi wrote: >> >> This patch add Exynos4415's SoC ID. >> > Since the CPU ID has been removed as per comments, need to update the commit > message accordingly. OK, I'll update it. > >> Exynos4415 is based on the 32-bit RISC >> processor for Smartphone. Exynos4415 uses Cortex A9 quad-cores and has a >> target >> speed of 1.6GHz and provides 8.5GB/s memory bandwidth. >> >> Cc: Kukjin Kim >> Signed-off-by: Chanwoo Choi >> Acked-by: Kyungmin Park >> --- >> arch/arm/mach-exynos/Kconfig | 5 + >> arch/arm/mach-exynos/exynos.c | 2 ++ >> 2 files changed, 7 insertions(+) >> >> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig >> index 46f3c0d..349c867 100644 >> --- a/arch/arm/mach-exynos/Kconfig >> +++ b/arch/arm/mach-exynos/Kconfig >> @@ -75,6 +75,11 @@ config SOC_EXYNOS4412 >> default y >> depends on ARCH_EXYNOS4 >> >> +config SOC_EXYNOS4415 >> +bool "SAMSUNG EXYNOS4415" >> +default y >> +depends on ARCH_EXYNOS4 >> + > > I think, this is not required more... But, The clock driver must need to CONFIG_SOC_EXYNOS4415 configuration to build it. The clock driver[1] of exynos4415 used CONFIG_SOC_EXYNOS4415 as following diff: [1] https://lkml.org/lkml/2014/10/26/159 diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile index 8909c93..4561297 100644 --- a/drivers/clk/samsung/Makefile +++ b/drivers/clk/samsung/Makefile @@ -5,6 +5,7 @@ obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o +obj-$(CONFIG_SOC_EXYNOS4415) += clk-exynos4415.o Best Regards, Chanwoo Choi -- 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: Machine crashes right *after* ~successful resume
On Mon, Oct 27, 2014 at 6:12 PM, Yinghai Lu wrote:
> On Mon, Oct 27, 2014 at 5:03 PM, Wilmer van der Gaast
> wrote:
>> I was curious about that already, did that with a 3.16.6 that I think just
>> had your revert applied (and using lspci - to get the dump which I
>> assumed would be the same): No changes to 04:00 at all.
>>
>> Confirmed that this is the case with 3.17 + those patches as well, it's
>> showing this at all times:
>
> can you post
> lspci -vv -s 00:1c.3
> lspci -vv -s 04:00.0
> before reverting enable bridge early patch
> and after reverting on 3.17+?
Please check if attached patch could fix the problem on your setup.
Thanks
Yinghai
---
drivers/pci/quirks.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-2.6/drivers/pci/quirks.c
===
--- linux-2.6.orig/drivers/pci/quirks.c
+++ linux-2.6/drivers/pci/quirks.c
@@ -3098,6 +3098,12 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x8c02, quirk_remove_d3_delay);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x8c22, quirk_remove_d3_delay);
+static void enable_pci_bridge_d0(struct pci_dev *dev)
+{
+ pci_set_power_state(dev, PCI_D0);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ITE, 0x8892, enable_pci_bridge_d0);
+
/*
* Some devices may pass our check in pci_intx_mask_supported if
* PCI_COMMAND_INTX_DISABLE works though they actually do not properly
Re: [PATCH v2 7/8] x86, perf: Only allow rdpmc if a perf_event is mapped
On Mon, Oct 27, 2014 at 8:35 PM, Hillf Danton wrote: >> -Original Message- >> From: Andy Lutomirski [mailto:l...@amacapital.net] >> Sent: Monday, October 27, 2014 11:45 PM >> To: Hillf Danton >> Cc: Peter Zijlstra; Ingo Molnar; Vince Weaver; Paul Mackerras; Kees Cook; >> Arnaldo Carvalho de Melo; Andrea Arcangeli; linux- >> ker...@vger.kernel.org; Valdis Kletnieks >> Subject: Re: [PATCH v2 7/8] x86, perf: Only allow rdpmc if a perf_event is >> mapped >> > CPU D CPU A > switch_mm > load_mm_cr4 > x86_pmu_event_unmapped > > I wonder if the X86_CR4_PCE set on CPU D is > cleared by CPU A by broadcasting IPI. > It should be okay. The IPI does: + if (current->mm) + load_mm_cr4(current->mm); which refers to the current task running on the targetted CPU, not to the IPI sender's task. So, if it happens after a context switch, it will harmlessly reload the new task's cr4. refresh_pce can't happen in between switch_mm and updating current, since irqs are off for the entire duration of the context switch. --Andy -- 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] [percpu] Make the unit size of the first chunk the same as other chunks
On Mon, Oct 27, 2014 at 07:32:47PM -0400, Zhihui Zhang wrote: > I am trying to make each CPU to have a full unit size in the first > chunk, same as in all other chunks. Does this make sense? And why are you trying to do that? Unit size may be highly variable. Why would it make sense to reserve memory area according to a value which can fluctuate for reasons completely unrelated to actual percpu memory usage? 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/
[PATCH resend] sched:check if got a shallowest_idle_cpu before search for least_loaded_cpu
Idle cpu is idler than non-idle cpu, so we needn't search for least_loaded_cpu
after we have found an idle cpu.
Signed-off-by: Yao Dongdong
Reviewed-by: Srikar Dronamraju
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0b069bf..2445a23 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4446,7 +4446,7 @@ find_idlest_cpu(struct sched_group *group, struct
task_struct *p, int this_cpu)
latest_idle_timestamp = rq->idle_stamp;
shallowest_idle_cpu = i;
}
- } else {
+ } else if (shallowest_idle_cpu == -1) {
load = weighted_cpuload(i);
if (load < min_load || (load == min_load && i ==
this_cpu)) {
min_load = load;
--
1.8.3.4
--
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 3.10 36/43] kernel: add support for gcc 5
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Sasha Levin
commit 71458cfc782eafe4b27656e078d379a34e472adf upstream.
We're missing include/linux/compiler-gcc5.h which is required now
because gcc branched off to v5 in trunk.
Just copy the relevant bits out of include/linux/compiler-gcc4.h,
no new code is added as of now.
This fixes a build error when using gcc 5.
Signed-off-by: Sasha Levin
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
include/linux/compiler-gcc5.h | 66 ++
1 file changed, 66 insertions(+)
--- /dev/null
+++ b/include/linux/compiler-gcc5.h
@@ -0,0 +1,66 @@
+#ifndef __LINUX_COMPILER_H
+#error "Please don't include directly, include
instead."
+#endif
+
+#define __used __attribute__((__used__))
+#define __must_check __attribute__((warn_unused_result))
+#define __compiler_offsetof(a, b) __builtin_offsetof(a, b)
+
+/* Mark functions as cold. gcc will assume any path leading to a call
+ to them will be unlikely. This means a lot of manual unlikely()s
+ are unnecessary now for any paths leading to the usual suspects
+ like BUG(), printk(), panic() etc. [but let's keep them for now for
+ older compilers]
+
+ Early snapshots of gcc 4.3 don't support this and we can't detect this
+ in the preprocessor, but we can live with this because they're unreleased.
+ Maketime probing would be overkill here.
+
+ gcc also has a __attribute__((__hot__)) to move hot functions into
+ a special section, but I don't see any sense in this right now in
+ the kernel context */
+#define __cold __attribute__((__cold__))
+
+#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
+
+#ifndef __CHECKER__
+# define __compiletime_warning(message) __attribute__((warning(message)))
+# define __compiletime_error(message) __attribute__((error(message)))
+#endif /* __CHECKER__ */
+
+/*
+ * Mark a position in code as unreachable. This can be used to
+ * suppress control flow warnings after asm blocks that transfer
+ * control elsewhere.
+ *
+ * Early snapshots of gcc 4.5 don't support this and we can't detect
+ * this in the preprocessor, but we can live with this because they're
+ * unreleased. Really, we need to have autoconf for the kernel.
+ */
+#define unreachable() __builtin_unreachable()
+
+/* Mark a function definition as prohibited from being cloned. */
+#define __noclone __attribute__((__noclone__))
+
+/*
+ * Tell the optimizer that something else uses this function or variable.
+ */
+#define __visible __attribute__((externally_visible))
+
+/*
+ * GCC 'asm goto' miscompiles certain code sequences:
+ *
+ * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
+ *
+ * Work it around via a compiler barrier quirk suggested by Jakub Jelinek.
+ * Fixed in GCC 4.8.2 and later versions.
+ *
+ * (asm goto is automatically volatile - the naming reflects this.)
+ */
+#define asm_volatile_goto(x...)do { asm goto(x); asm (""); } while (0)
+
+#ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
+#define __HAVE_BUILTIN_BSWAP32__
+#define __HAVE_BUILTIN_BSWAP64__
+#define __HAVE_BUILTIN_BSWAP16__
+#endif /* CONFIG_ARCH_USE_BUILTIN_BSWAP */
--
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 3.10 33/43] Bluetooth: Fix issue with USB suspend in btusb driver
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Champion Chen
commit 85560c4a828ec9c8573840c9b66487b6ae584768 upstream.
Suspend could fail for some platforms because
btusb_suspend==> btusb_stop_traffic ==> usb_kill_anchored_urbs.
When btusb_bulk_complete returns before system suspend and resubmits
an URB, the system cannot enter suspend state.
Signed-off-by: Champion Chen
Signed-off-by: Larry Finger
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman
---
drivers/bluetooth/btusb.c |9 +
1 file changed, 9 insertions(+)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -302,6 +302,9 @@ static void btusb_intr_complete(struct u
BT_ERR("%s corrupted event packet", hdev->name);
hdev->stat.err_rx++;
}
+ } else if (urb->status == -ENOENT) {
+ /* Avoid suspend failed when usb_kill_urb */
+ return;
}
if (!test_bit(BTUSB_INTR_RUNNING, >flags))
@@ -390,6 +393,9 @@ static void btusb_bulk_complete(struct u
BT_ERR("%s corrupted ACL packet", hdev->name);
hdev->stat.err_rx++;
}
+ } else if (urb->status == -ENOENT) {
+ /* Avoid suspend failed when usb_kill_urb */
+ return;
}
if (!test_bit(BTUSB_BULK_RUNNING, >flags))
@@ -484,6 +490,9 @@ static void btusb_isoc_complete(struct u
hdev->stat.err_rx++;
}
}
+ } else if (urb->status == -ENOENT) {
+ /* Avoid suspend failed when usb_kill_urb */
+ return;
}
if (!test_bit(BTUSB_ISOC_RUNNING, >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/
Re: [PATCH 3.16 000/127] 3.16.7-stable review
On Tue, Oct 28, 2014 at 11:33:55AM +0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.16.7 release. > There are 127 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 Thu Oct 30 03:33:57 UTC 2014. > 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.16.7-rc1.gz > and the diffstat can be found below. Please note, this is going to be the LAST 3.16-stable release from me, after this one, it's end-of-life. thanks, greg k-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/
[PATCH 3.10 23/43] Revert "lzo: properly check for overruns"
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Willy Tarreau
commit af958a38a60c7ca3d8a39c918c1baa2ff7b6b233 upstream.
This reverts commit 206a81c ("lzo: properly check for overruns").
As analysed by Willem Pinckaers, this fix is still incomplete on
certain rare corner cases, and it is easier to restart from the
original code.
Reported-by: Willem Pinckaers
Cc: "Don A. Bailey"
Signed-off-by: Willy Tarreau
Signed-off-by: Greg Kroah-Hartman
---
lib/lzo/lzo1x_decompress_safe.c | 62 +---
1 file changed, 21 insertions(+), 41 deletions(-)
--- a/lib/lzo/lzo1x_decompress_safe.c
+++ b/lib/lzo/lzo1x_decompress_safe.c
@@ -19,31 +19,11 @@
#include
#include "lzodefs.h"
-#define HAVE_IP(t, x) \
- (((size_t)(ip_end - ip) >= (size_t)(t + x)) && \
-(((t + x) >= t) && ((t + x) >= x)))
-
-#define HAVE_OP(t, x) \
- (((size_t)(op_end - op) >= (size_t)(t + x)) && \
-(((t + x) >= t) && ((t + x) >= x)))
-
-#define NEED_IP(t, x) \
- do {\
- if (!HAVE_IP(t, x)) \
- goto input_overrun; \
- } while (0)
-
-#define NEED_OP(t, x) \
- do {\
- if (!HAVE_OP(t, x)) \
- goto output_overrun;\
- } while (0)
-
-#define TEST_LB(m_pos) \
- do {\
- if ((m_pos) < out) \
- goto lookbehind_overrun;\
- } while (0)
+#define HAVE_IP(x) ((size_t)(ip_end - ip) >= (size_t)(x))
+#define HAVE_OP(x) ((size_t)(op_end - op) >= (size_t)(x))
+#define NEED_IP(x) if (!HAVE_IP(x)) goto input_overrun
+#define NEED_OP(x) if (!HAVE_OP(x)) goto output_overrun
+#define TEST_LB(m_pos) if ((m_pos) < out) goto lookbehind_overrun
int lzo1x_decompress_safe(const unsigned char *in, size_t in_len,
unsigned char *out, size_t *out_len)
@@ -78,14 +58,14 @@ int lzo1x_decompress_safe(const unsigned
while (unlikely(*ip == 0)) {
t += 255;
ip++;
- NEED_IP(1, 0);
+ NEED_IP(1);
}
t += 15 + *ip++;
}
t += 3;
copy_literal_run:
#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
- if (likely(HAVE_IP(t, 15) && HAVE_OP(t, 15))) {
+ if (likely(HAVE_IP(t + 15) && HAVE_OP(t + 15)))
{
const unsigned char *ie = ip + t;
unsigned char *oe = op + t;
do {
@@ -101,8 +81,8 @@ copy_literal_run:
} else
#endif
{
- NEED_OP(t, 0);
- NEED_IP(t, 3);
+ NEED_OP(t);
+ NEED_IP(t + 3);
do {
*op++ = *ip++;
} while (--t > 0);
@@ -115,7 +95,7 @@ copy_literal_run:
m_pos -= t >> 2;
m_pos -= *ip++ << 2;
TEST_LB(m_pos);
- NEED_OP(2, 0);
+ NEED_OP(2);
op[0] = m_pos[0];
op[1] = m_pos[1];
op += 2;
@@ -139,10 +119,10 @@ copy_literal_run:
while (unlikely(*ip == 0)) {
t += 255;
ip++;
- NEED_IP(1, 0);
+ NEED_IP(1);
}
t += 31 + *ip++;
- NEED_IP(2, 0);
+ NEED_IP(2);
}
m_pos = op - 1;
next = get_unaligned_le16(ip);
@@ -157,10 +137,10 @@ copy_literal_run:
while (unlikely(*ip == 0)) {
t += 255;
ip++;
-
[PATCH 3.10 00/43] 3.10.59-stable review
This is the start of the stable review cycle for the 3.10.59 release. There are 43 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 Thu Oct 30 03:35:12 UTC 2014. 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.10.59-rc1.gz and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 3.10.59-rc1 Chao Yu ecryptfs: avoid to access NULL pointer when write metadata in xattr Ludovic Desroches ARM: at91/PMC: don't forget to write PMC_PCDR register to disable clocks Vlad Catoi ALSA: usb-audio: Add support for Steinberg UR22 USB interface Takashi Iwai ALSA: emu10k1: Fix deadlock in synth voice lookup Anatol Pomozov ALSA: pcm: use the same dma mmap codepath both for arm and arm64 Victor Kamensky arm64: compat: fix compat types affecting struct compat_elf_prpsinfo Andy Shevchenko spi: dw-mid: terminate ongoing transfers at exit Sasha Levin kernel: add support for gcc 5 Yann Droneaud fanotify: enable close-on-exec on events' fd when requested in fanotify_init() Junxiao Bi mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set Champion Chen Bluetooth: Fix issue with USB suspend in btusb driver Loic Poulain Bluetooth: Fix HCI H5 corrupted ack value Stanislaw Gruszka rt2800: correct BBP1_TX_POWER_CTRL mask Ricardo Ribalda Delgado PCI: Generate uppercase hex for modalias interface class Douglas Lehr PCI: Increase IBM ipr SAS Crocodile BARs to at least system page size Oren Givon iwlwifi: Add missing PCI IDs for the 7260 series Andy Adamson NFSv4.1: Fix an NFSv4.1 state renewal regression Trond Myklebust NFSv4: fix open/lock state recovery error handling Trond Myklebust NFSv4: Fix lock recovery when CREATE_SESSION/SETCLIENTID_CONFIRM fails Willy Tarreau lzo: check for length overrun in variable length encoding. Willy Tarreau Revert "lzo: properly check for overruns" Willy Tarreau Documentation: lzo: document part of the encoding Geert Uytterhoeven m68k: Disable/restore interrupts in hwreg_present()/hwreg_write() K. Y. Srinivasan Drivers: hv: vmbus: Fix a bug in vmbus_open() K. Y. Srinivasan Drivers: hv: vmbus: Cleanup vmbus_establish_gpadl() K. Y. Srinivasan Drivers: hv: vmbus: Cleanup vmbus_teardown_gpadl() K. Y. Srinivasan Drivers: hv: vmbus: Cleanup vmbus_post_msg() Kees Cook firmware_class: make sure fw requests contain a name Arun Easi qla2xxx: Use correct offset to req-q-out for reserve calculation Chris J Arges mptfusion: enable no_write_same for vmware scsi disks Mike Christie be2iscsi: check ip buffer before copying Pankaj Dubey regmap: fix NULL pointer dereference in _regmap_write/read Xiubo Li regmap: debugfs: fix possbile NULL pointer dereference Andy Shevchenko spi: dw-mid: check that DMA was inited before exit Andy Shevchenko spi: dw-mid: respect 8 bit mode Bryan O'Donoghue x86/intel/quark: Switch off CR4.PGE so TLB flush uses CR3 instead David Matlack kvm: don't take vcpu mutex for obviously invalid vcpu ioctls Christian Borntraeger KVM: s390: unintended fallthrough for external call David Matlack kvm: x86: fix stale mmio cache bug Andy Lutomirski fs: Add a missing permission check to do_umount Sage Weil Btrfs: fix race in WAIT_SYNC ioctl Josef Bacik Btrfs: fix build_backref_tree issue with multiple shared blocks Josef Bacik Btrfs: try not to ENOSPC on log replay - Diffstat: Documentation/lzo.txt | 164 Makefile| 4 +- arch/arm/mach-at91/clock.c | 1 + arch/arm64/include/asm/compat.h | 4 +- arch/m68k/mm/hwtest.c | 6 ++ arch/s390/kvm/interrupt.c | 1 + arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kernel/cpu/intel.c | 15 +++ arch/x86/kvm/mmu.c | 2 +- arch/x86/kvm/x86.h | 20 +++- drivers/base/firmware_class.c | 3 + drivers/base/regmap/regmap-debugfs.c| 8 +- drivers/base/regmap/regmap.c| 4 +- drivers/bluetooth/btusb.c | 9 ++ drivers/bluetooth/hci_h5.c | 2 +- drivers/hv/channel.c| 20 ++-- drivers/hv/connection.c | 17 +++- drivers/message/fusion/mptspi.c | 5 + drivers/net/wireless/iwlwifi/pcie/drv.c | 4 + drivers/net/wireless/rt2x00/rt2800.h| 2 +- drivers/pci/pci-sysfs.c | 2 +- drivers/pci/quirks.c| 20 drivers/scsi/be2iscsi/be_mgmt.c | 13 ++-
[PATCH 3.14 099/100] sparc64: Fix register corruption in top-most kernel stack frame during boot.
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: "David S. Miller"
[ Upstream commit ef3e035c3a9b81da8a778bc333d10637acf6c199 ]
Meelis Roos reported that kernels built with gcc-4.9 do not boot, we
eventually narrowed this down to only impacting machines using
UltraSPARC-III and derivitive cpus.
The crash happens right when the first user process is spawned:
[ 54.451346] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0004
[ 54.451346]
[ 54.571516] CPU: 1 PID: 1 Comm: init Not tainted 3.16.0-rc2-00211-gd7933ab
#96
[ 54.666431] Call Trace:
[ 54.698453] [00762f8c] panic+0xb0/0x224
[ 54.759071] [0045cf68] do_exit+0x948/0x960
[ 54.823123] [0042cbc0] fault_in_user_windows+0xe0/0x100
[ 54.902036] [00404ad0] __handle_user_windows+0x0/0x10
[ 54.978662] Press Stop-A (L1-A) to return to the boot prom
[ 55.050713] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0004
Further investigation showed that compiling only per_cpu_patch() with
an older compiler fixes the boot.
Detailed analysis showed that the function is not being miscompiled by
gcc-4.9, but it is using a different register allocation ordering.
With the gcc-4.9 compiled function, something during the code patching
causes some of the %i* input registers to get corrupted. Perhaps
we have a TLB miss path into the firmware that is deep enough to
cause a register window spill and subsequent restore when we get
back from the TLB miss trap.
Let's plug this up by doing two things:
1) Stop using the firmware stack for client interface calls into
the firmware. Just use the kernel's stack.
2) As soon as we can, call into a new function "start_early_boot()"
to put a one-register-window buffer between the firmware's
deepest stack frame and the top-most initial kernel one.
Reported-by: Meelis Roos
Tested-by: Meelis Roos
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
arch/sparc/include/asm/oplib_64.h |3 +-
arch/sparc/include/asm/setup.h|4 +++
arch/sparc/kernel/entry.h |3 --
arch/sparc/kernel/head_64.S | 40 +++---
arch/sparc/kernel/hvtramp.S |1
arch/sparc/kernel/setup_64.c | 28 +++---
arch/sparc/kernel/trampoline_64.S | 12 ++-
arch/sparc/prom/cif.S |5 +---
arch/sparc/prom/init_64.c |6 ++---
arch/sparc/prom/p1275.c |2 -
10 files changed, 42 insertions(+), 62 deletions(-)
--- a/arch/sparc/include/asm/oplib_64.h
+++ b/arch/sparc/include/asm/oplib_64.h
@@ -62,7 +62,8 @@ struct linux_mem_p1275 {
/* You must call prom_init() before using any of the library services,
* preferably as early as possible. Pass it the romvec pointer.
*/
-extern void prom_init(void *cif_handler, void *cif_stack);
+extern void prom_init(void *cif_handler);
+extern void prom_init_report(void);
/* Boot argument acquisition, returns the boot command line string. */
extern char *prom_getbootargs(void);
--- a/arch/sparc/include/asm/setup.h
+++ b/arch/sparc/include/asm/setup.h
@@ -24,6 +24,10 @@ static inline int con_is_present(void)
}
#endif
+#ifdef CONFIG_SPARC64
+extern void __init start_early_boot(void);
+#endif
+
extern void sun_do_break(void);
extern int stop_a_enabled;
extern int scons_pwroff;
--- a/arch/sparc/kernel/entry.h
+++ b/arch/sparc/kernel/entry.h
@@ -66,13 +66,10 @@ struct pause_patch_entry {
extern struct pause_patch_entry __pause_3insn_patch,
__pause_3insn_patch_end;
-extern void __init per_cpu_patch(void);
extern void sun4v_patch_1insn_range(struct sun4v_1insn_patch_entry *,
struct sun4v_1insn_patch_entry *);
extern void sun4v_patch_2insn_range(struct sun4v_2insn_patch_entry *,
struct sun4v_2insn_patch_entry *);
-extern void __init sun4v_patch(void);
-extern void __init boot_cpu_id_too_large(int cpu);
extern unsigned int dcache_parity_tl1_occurred;
extern unsigned int icache_parity_tl1_occurred;
--- a/arch/sparc/kernel/head_64.S
+++ b/arch/sparc/kernel/head_64.S
@@ -672,14 +672,12 @@ tlb_fixup_done:
sethi %hi(init_thread_union), %g6
or %g6, %lo(init_thread_union), %g6
ldx [%g6 + TI_TASK], %g4
- mov %sp, %l6
wr %g0, ASI_P, %asi
mov 1, %g1
sllx%g1, THREAD_SHIFT, %g1
sub %g1, (STACKFRAME_SZ + STACK_BIAS), %g1
add %g6, %g1, %sp
- mov 0, %fp
/* Set per-cpu pointer initially to zero, this makes
* the boot-cpu use the in-kernel-image per-cpu areas
@@ -706,44 +704,14 @@ tlb_fixup_done:
nop
#endif
- mov %l6, %o1! OpenPROM stack
callprom_init
mov%l7, %o0! OpenPROM cif handler
- /* Initialize
[PATCH 3.14 080/100] sparc64: Fix reversed start/end in flush_tlb_kernel_range()
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: "David S. Miller"
[ Upstream commit 473ad7f4fb005d1bb727e4ef27d370d28703a062 ]
When we have to split up a flush request into multiple pieces
(in order to avoid the firmware range) we don't specify the
arguments in the right order for the second piece.
Fix the order, or else we get hangs as the code tries to
flush "a lot" of entries and we get lockups like this:
[ 4422.981276] NMI watchdog: BUG: soft lockup - CPU#12 stuck for 23s!
[expect:117032]
[ 4422.996130] Modules linked in: ipv6 loop usb_storage igb ptp sg sr_mod
ehci_pci ehci_hcd pps_core n2_rng rng_core
[ 4423.016617] CPU: 12 PID: 117032 Comm: expect Not tainted 3.17.0-rc4+ #1608
[ 4423.030331] task: fff8003cc730e220 ti: fff8003d99d54000 task.ti:
fff8003d99d54000
[ 4423.045282] TSTATE: 11001602 TPC: 004521e8 TNPC:
004521ec Y: Not tainted
[ 4423.064905] TPC: <__flush_tlb_kernel_range+0x28/0x40>
[ 4423.074964] g0: 0052fd10 g1: 0001295a8000 g2: ff7176ffc000
g3: 2000
[ 4423.092324] g4: fff8003cc730e220 g5: fff8003dfedcc000 g6: fff8003d99d54000
g7: 0006
[ 4423.109687] o0: o1: o2: 0003
o3: f000
[ 4423.127058] o4: 0080 o5: 0001295a8000 sp: fff8003d99d56d01
ret_pc: 0052ff54
[ 4423.145121] RPC: <__purge_vmap_area_lazy+0x314/0x3a0>
[ 4423.155185] l0: l1: l2: 00a38040
l3:
[ 4423.172559] l4: fff8003dae8965e0 l5: l6:
l7: f7e2b138
[ 4423.189913] i0: fff8003d99d576a0 i1: fff8003d99d576a8 i2: fff8003d99d575e8
i3:
[ 4423.207284] i4: 8008 i5: fff8003d99d575c8 i6: fff8003d99d56df1
i7: 00530c24
[ 4423.224640] I7:
[ 4423.234193] Call Trace:
[ 4423.239051] [00530c24] free_vmap_area_noflush+0x64/0x80
[ 4423.251029] [00531a7c] remove_vm_area+0x5c/0x80
[ 4423.261628] [00531b80] __vunmap+0x20/0x120
[ 4423.271352] [0071cf18] n_tty_close+0x18/0x40
[ 4423.281423] [007222b0] tty_ldisc_close+0x30/0x60
[ 4423.292183] [007225a4] tty_ldisc_reinit+0x24/0xa0
[ 4423.303120] [00722ab4] tty_ldisc_hangup+0xd4/0x1e0
[ 4423.314232] [00719aa0] __tty_hangup+0x280/0x3c0
[ 4423.324835] [00724cb4] pty_close+0x134/0x1a0
[ 4423.334905] [0071aa24] tty_release+0x104/0x500
[ 4423.345316] [005511d0] __fput+0x90/0x1e0
[ 4423.354701] [0047fa54] task_work_run+0x94/0xe0
[ 4423.365126] [00404b44] __handle_signal+0xc/0x2c
Fixes: 4ca9a23765da ("sparc64: Guard against flushing openfirmware mappings.")
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
arch/sparc/mm/init_64.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -2720,8 +2720,8 @@ void flush_tlb_kernel_range(unsigned lon
do_flush_tlb_kernel_range(start, LOW_OBP_ADDRESS);
}
if (end > HI_OBP_ADDRESS) {
- flush_tsb_kernel_range(end, HI_OBP_ADDRESS);
- do_flush_tlb_kernel_range(end, HI_OBP_ADDRESS);
+ flush_tsb_kernel_range(HI_OBP_ADDRESS, end);
+ do_flush_tlb_kernel_range(HI_OBP_ADDRESS, end);
}
} else {
flush_tsb_kernel_range(start, end);
--
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 3.14 086/100] sparc64: support M6 and M7 for building CPU distribution map
3.14-stable review patch. If anyone has any objections, please let me know. -- From: Allen Pais Add M6 and M7 chip type in cpumap.c to correctly build CPU distribution map that spans all online CPUs. Signed-off-by: Allen Pais Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- arch/sparc/kernel/cpumap.c |2 ++ 1 file changed, 2 insertions(+) --- a/arch/sparc/kernel/cpumap.c +++ b/arch/sparc/kernel/cpumap.c @@ -326,6 +326,8 @@ static int iterate_cpu(struct cpuinfo_tr case SUN4V_CHIP_NIAGARA3: case SUN4V_CHIP_NIAGARA4: case SUN4V_CHIP_NIAGARA5: + case SUN4V_CHIP_SPARC_M6: + case SUN4V_CHIP_SPARC_M7: case SUN4V_CHIP_SPARC64X: rover_inc_table = niagara_iterate_method; 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/
[PATCH 3.14 079/100] sparc: Let memset return the address argument
3.14-stable review patch. If anyone has any objections, please let me know. -- From: Andreas Larsson [ Upstream commit 74cad25c076a2f5253312c2fe82d1a4daecc1323 ] This makes memset follow the standard (instead of returning 0 on success). This is needed when certain versions of gcc optimizes around memset calls and assume that the address argument is preserved in %o0. Signed-off-by: Andreas Larsson Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- arch/sparc/lib/memset.S | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) --- a/arch/sparc/lib/memset.S +++ b/arch/sparc/lib/memset.S @@ -3,8 +3,9 @@ * Copyright (C) 1996,1997 Jakub Jelinek (j...@sunsite.mff.cuni.cz) * Copyright (C) 1996 David S. Miller (da...@caip.rutgers.edu) * - * Returns 0, if ok, and number of bytes not yet set if exception - * occurs and we were called as clear_user. + * Calls to memset returns initial %o0. Calls to bzero returns 0, if ok, and + * number of bytes not yet set if exception occurs and we were called as + * clear_user. */ #include @@ -65,6 +66,8 @@ __bzero_begin: .globl __memset_start, __memset_end __memset_start: memset: + mov %o0, %g1 + mov 1, %g4 and %o1, 0xff, %g3 sll %g3, 8, %g2 or %g3, %g2, %g3 @@ -89,6 +92,7 @@ memset: sub%o0, %o2, %o0 __bzero: + clr %g4 mov %g0, %g3 1: cmp %o1, 7 @@ -151,8 +155,8 @@ __bzero: bne,a 8f EX(stb %g3, [%o0], and %o1, 1) 8: - retl -clr%o0 + b 0f +nop 7: be 13b orcc %o1, 0, %g0 @@ -164,6 +168,12 @@ __bzero: bne 8b EX(stb %g3, [%o0 - 1], add %o1, 1) 0: + andcc %g4, 1, %g0 + be 5f +nop + retl +mov%g1, %o0 +5: retl clr%o0 __memset_end: -- 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 3.14 093/100] sparc64: Use kernel page tables for vmemmap.
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: "David S. Miller"
[ Upstream commit c06240c7f5c39c83dfd7849c0770775562441b96 ]
For sparse memory configurations, the vmemmap array behaves terribly
and it takes up an inordinate amount of space in the BSS section of
the kernel image unconditionally.
Just build huge PMDs and look them up just like we do for TLB misses
in the vmalloc area.
Kernel BSS shrinks by about 2MB.
Signed-off-by: David S. Miller
Acked-by: Bob Picco
Signed-off-by: Greg Kroah-Hartman
---
arch/sparc/kernel/ktlb.S |9 +
arch/sparc/mm/init_64.c | 72 ++-
arch/sparc/mm/init_64.h | 11 ---
3 files changed, 36 insertions(+), 56 deletions(-)
--- a/arch/sparc/kernel/ktlb.S
+++ b/arch/sparc/kernel/ktlb.S
@@ -186,13 +186,8 @@ kvmap_dtlb_load:
#ifdef CONFIG_SPARSEMEM_VMEMMAP
kvmap_vmemmap:
- sub %g4, %g5, %g5
- srlx%g5, ILOG2_4MB, %g5
- sethi %hi(vmemmap_table), %g1
- sllx%g5, 3, %g5
- or %g1, %lo(vmemmap_table), %g1
- ba,pt %xcc, kvmap_dtlb_load
-ldx[%g1 + %g5], %g5
+ KERN_PGTABLE_WALK(%g4, %g5, %g2, kvmap_dtlb_longpath)
+ ba,a,pt %xcc, kvmap_dtlb_load
#endif
kvmap_dtlb_nonlinear:
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -2255,18 +2255,9 @@ unsigned long _PAGE_CACHE __read_mostly;
EXPORT_SYMBOL(_PAGE_CACHE);
#ifdef CONFIG_SPARSEMEM_VMEMMAP
-unsigned long vmemmap_table[VMEMMAP_SIZE];
-
-static long __meminitdata addr_start, addr_end;
-static int __meminitdata node_start;
-
int __meminit vmemmap_populate(unsigned long vstart, unsigned long vend,
int node)
{
- unsigned long phys_start = (vstart - VMEMMAP_BASE);
- unsigned long phys_end = (vend - VMEMMAP_BASE);
- unsigned long addr = phys_start & VMEMMAP_CHUNK_MASK;
- unsigned long end = VMEMMAP_ALIGN(phys_end);
unsigned long pte_base;
pte_base = (_PAGE_VALID | _PAGE_SZ4MB_4U |
@@ -2277,47 +2268,52 @@ int __meminit vmemmap_populate(unsigned
_PAGE_CP_4V | _PAGE_CV_4V |
_PAGE_P_4V | _PAGE_W_4V);
- for (; addr < end; addr += VMEMMAP_CHUNK) {
- unsigned long *vmem_pp =
- vmemmap_table + (addr >> VMEMMAP_CHUNK_SHIFT);
- void *block;
+ pte_base |= _PAGE_PMD_HUGE;
- if (!(*vmem_pp & _PAGE_VALID)) {
- block = vmemmap_alloc_block(1UL << ILOG2_4MB, node);
- if (!block)
+ vstart = vstart & PMD_MASK;
+ vend = ALIGN(vend, PMD_SIZE);
+ for (; vstart < vend; vstart += PMD_SIZE) {
+ pgd_t *pgd = pgd_offset_k(vstart);
+ unsigned long pte;
+ pud_t *pud;
+ pmd_t *pmd;
+
+ if (pgd_none(*pgd)) {
+ pud_t *new = vmemmap_alloc_block(PAGE_SIZE, node);
+
+ if (!new)
return -ENOMEM;
+ pgd_populate(_mm, pgd, new);
+ }
- *vmem_pp = pte_base | __pa(block);
+ pud = pud_offset(pgd, vstart);
+ if (pud_none(*pud)) {
+ pmd_t *new = vmemmap_alloc_block(PAGE_SIZE, node);
- /* check to see if we have contiguous blocks */
- if (addr_end != addr || node_start != node) {
- if (addr_start)
- printk(KERN_DEBUG " [%lx-%lx] on node
%d\n",
- addr_start, addr_end-1,
node_start);
- addr_start = addr;
- node_start = node;
- }
- addr_end = addr + VMEMMAP_CHUNK;
+ if (!new)
+ return -ENOMEM;
+ pud_populate(_mm, pud, new);
}
- }
- return 0;
-}
-void __meminit vmemmap_populate_print_last(void)
-{
- if (addr_start) {
- printk(KERN_DEBUG " [%lx-%lx] on node %d\n",
- addr_start, addr_end-1, node_start);
- addr_start = 0;
- addr_end = 0;
- node_start = 0;
+ pmd = pmd_offset(pud, vstart);
+
+ pte = pmd_val(*pmd);
+ if (!(pte & _PAGE_VALID)) {
+ void *block = vmemmap_alloc_block(PMD_SIZE, node);
+
+ if (!block)
+ return -ENOMEM;
+
+ pmd_val(*pmd) = pte_base | __pa(block);
+ }
}
+
+ return 0;
}
void vmemmap_free(unsigned long start, unsigned long end)
{
}
-
#endif /*
[PATCH 3.10 12/43] regmap: fix NULL pointer dereference in _regmap_write/read
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Pankaj Dubey
commit 5336be8416a71b5568d2cf54a2f2066abe9f2a53 upstream.
If LOG_DEVICE is defined and map->dev is NULL it will lead to NULL
pointer dereference. This patch fixes this issue by adding check for
dev->NULL in all such places in regmap.c
Signed-off-by: Pankaj Dubey
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman
---
drivers/base/regmap/regmap.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1177,7 +1177,7 @@ int _regmap_write(struct regmap *map, un
}
#ifdef LOG_DEVICE
- if (strcmp(dev_name(map->dev), LOG_DEVICE) == 0)
+ if (map->dev && strcmp(dev_name(map->dev), LOG_DEVICE) == 0)
dev_info(map->dev, "%x <= %x\n", reg, val);
#endif
@@ -1437,7 +1437,7 @@ static int _regmap_read(struct regmap *m
ret = map->reg_read(context, reg, val);
if (ret == 0) {
#ifdef LOG_DEVICE
- if (strcmp(dev_name(map->dev), LOG_DEVICE) == 0)
+ if (map->dev && strcmp(dev_name(map->dev), LOG_DEVICE) == 0)
dev_info(map->dev, "%x => %x\n", reg, *val);
#endif
--
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 3.10 02/43] Btrfs: fix build_backref_tree issue with multiple shared blocks
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Josef Bacik
commit bbe9051441effce51c9a533d2c56440df64db2d7 upstream.
Marc Merlin sent me a broken fs image months ago where it would blow up in the
upper->checked BUG_ON() in build_backref_tree. This is because we had a
scenario like this
block a -- level 4 (not shared)
|
block b -- level 3 (reloc block, shared)
|
block c -- level 2 (not shared)
|
block d -- level 1 (shared)
|
block e -- level 0 (shared)
We go to build a backref tree for block e, we notice block d is shared and add
it to the list of blocks to lookup it's backrefs for. Now when we loop around
we will check edges for the block, so we will see we looked up block c last
time. So we lookup block d and then see that the block that points to it is
block c and we can just skip that edge since we've already been up this path.
The problem is because we clear need_check when we see block d (as it is shared)
we never add block b as needing to be checked. And because block c is in our
path already we bail out before we walk up to block b and add it to the backref
check list.
To fix this we need to reset need_check if we trip over a block that doesn't
need to be checked. This will make sure that any subsequent blocks in the path
as we're walking up afterwards are added to the list to be processed. With this
patch I can now mount Marc's fs image and it'll complete the balance without
panicing. Thanks,
Reported-by: Marc MERLIN
Signed-off-by: Josef Bacik
Signed-off-by: Chris Mason
Signed-off-by: Greg Kroah-Hartman
---
fs/btrfs/relocation.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -967,8 +967,11 @@ again:
need_check = false;
list_add_tail(>list[UPPER],
);
- } else
+ } else {
+ if (upper->checked)
+ need_check = true;
INIT_LIST_HEAD(>list[UPPER]);
+ }
} else {
upper = rb_entry(rb_node, struct backref_node,
rb_node);
--
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 3.10 15/43] qla2xxx: Use correct offset to req-q-out for reserve calculation
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Arun Easi
commit 75554b68ac1e018bca00d68a430b92ada8ab52dd upstream.
Signed-off-by: Arun Easi
Signed-off-by: Saurav Kashyap
Signed-off-by: Christoph Hellwig
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/qla2xxx/qla_target.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -1514,12 +1514,10 @@ static inline void qlt_unmap_sg(struct s
static int qlt_check_reserve_free_req(struct scsi_qla_host *vha,
uint32_t req_cnt)
{
- struct qla_hw_data *ha = vha->hw;
- device_reg_t __iomem *reg = ha->iobase;
uint32_t cnt;
if (vha->req->cnt < (req_cnt + 2)) {
- cnt = (uint16_t)RD_REG_DWORD(>isp24.req_q_out);
+ cnt = (uint16_t)RD_REG_DWORD(vha->req->req_q_out);
ql_dbg(ql_dbg_tgt, vha, 0xe00a,
"Request ring circled: cnt=%d, vha->->ring_index=%d, "
--
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 3.14 082/100] sparc64: Fix FPU register corruption with AES crypto offload.
3.14-stable review patch. If anyone has any objections, please let me know. -- From: "David S. Miller" [ Upstream commit f4da3628dc7c32a59d1fb7116bb042e6f436d611 ] The AES loops in arch/sparc/crypto/aes_glue.c use a scheme where the key material is preloaded into the FPU registers, and then we loop over and over doing the crypt operation, reusing those pre-cooked key registers. There are intervening blkcipher*() calls between the crypt operation calls. And those might perform memcpy() and thus also try to use the FPU. The sparc64 kernel FPU usage mechanism is designed to allow such recursive uses, but with a catch. There has to be a trap between the two FPU using threads of control. The mechanism works by, when the FPU is already in use by the kernel, allocating a slot for FPU saving at trap time. Then if, within the trap handler, we try to use the FPU registers, the pre-trap FPU register state is saved into the slot. Then at trap return time we notice this and restore the pre-trap FPU state. Over the long term there are various more involved ways we can make this work, but for a quick fix let's take advantage of the fact that the situation where this happens is very limited. All sparc64 chips that support the crypto instructiosn also are using the Niagara4 memcpy routine, and that routine only uses the FPU for large copies where we can't get the source aligned properly to a multiple of 8 bytes. We look to see if the FPU is already in use in this context, and if so we use the non-large copy path which only uses integer registers. Furthermore, we also limit this special logic to when we are doing kernel copy, rather than a user copy. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- arch/sparc/include/asm/visasm.h |8 arch/sparc/lib/NG4memcpy.S | 14 +- 2 files changed, 21 insertions(+), 1 deletion(-) --- a/arch/sparc/include/asm/visasm.h +++ b/arch/sparc/include/asm/visasm.h @@ -39,6 +39,14 @@ 297: wr %o5, FPRS_FEF, %fprs; \ 298: +#define VISEntryHalfFast(fail_label) \ + rd %fprs, %o5; \ + andcc %o5, FPRS_FEF, %g0; \ + be,pt %icc, 297f; \ +nop; \ + ba,a,pt %xcc, fail_label; \ +297: wr %o5, FPRS_FEF, %fprs; + #define VISExitHalf\ wr %o5, 0, %fprs; --- a/arch/sparc/lib/NG4memcpy.S +++ b/arch/sparc/lib/NG4memcpy.S @@ -41,6 +41,10 @@ #endif #endif +#if !defined(EX_LD) && !defined(EX_ST) +#define NON_USER_COPY +#endif + #ifndef EX_LD #define EX_LD(x) x #endif @@ -197,9 +201,13 @@ FUNC_NAME: /* %o0=dst, %o1=src, %o2=len movEX_RETVAL(%o3), %o0 .Llarge_src_unaligned: +#ifdef NON_USER_COPY + VISEntryHalfFast(.Lmedium_vis_entry_fail) +#else + VISEntryHalf +#endif andn%o2, 0x3f, %o4 sub %o2, %o4, %o2 - VISEntryHalf alignaddr %o1, %g0, %g1 add %o1, %o4, %o1 EX_LD(LOAD(ldd, %g1 + 0x00, %f0)) @@ -240,6 +248,10 @@ FUNC_NAME: /* %o0=dst, %o1=src, %o2=len nop ba,a,pt %icc, .Lmedium_unaligned +#ifdef NON_USER_COPY +.Lmedium_vis_entry_fail: +or %o0, %o1, %g2 +#endif .Lmedium: LOAD(prefetch, %o1 + 0x40, #n_reads_strong) andcc %g2, 0x7, %g0 -- 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 3.14 089/100] sparc64: Switch to 4-level page tables.
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: "David S. Miller"
[ Upstream commit ac55c768143aa34cc3789c4820cbb0809a76fd9c ]
This has become necessary with chips that support more than 43-bits
of physical addressing.
Based almost entirely upon a patch by Bob Picco.
Signed-off-by: David S. Miller
Acked-by: Bob Picco
Signed-off-by: Greg Kroah-Hartman
---
arch/sparc/include/asm/page_64.h|6 +
arch/sparc/include/asm/pgalloc_64.h | 28 ++-
arch/sparc/include/asm/pgtable_64.h | 37 +++-
arch/sparc/include/asm/tsb.h| 10 +
arch/sparc/kernel/smp_64.c |7 ++
arch/sparc/mm/init_64.c | 31 ++
6 files changed, 109 insertions(+), 10 deletions(-)
--- a/arch/sparc/include/asm/page_64.h
+++ b/arch/sparc/include/asm/page_64.h
@@ -57,18 +57,21 @@ extern void copy_user_page(void *to, voi
typedef struct { unsigned long pte; } pte_t;
typedef struct { unsigned long iopte; } iopte_t;
typedef struct { unsigned long pmd; } pmd_t;
+typedef struct { unsigned long pud; } pud_t;
typedef struct { unsigned long pgd; } pgd_t;
typedef struct { unsigned long pgprot; } pgprot_t;
#define pte_val(x) ((x).pte)
#define iopte_val(x) ((x).iopte)
#define pmd_val(x) ((x).pmd)
+#define pud_val(x) ((x).pud)
#define pgd_val(x) ((x).pgd)
#define pgprot_val(x) ((x).pgprot)
#define __pte(x) ((pte_t) { (x) } )
#define __iopte(x) ((iopte_t) { (x) } )
#define __pmd(x)((pmd_t) { (x) } )
+#define __pud(x)((pud_t) { (x) } )
#define __pgd(x) ((pgd_t) { (x) } )
#define __pgprot(x)((pgprot_t) { (x) } )
@@ -77,18 +80,21 @@ typedef struct { unsigned long pgprot; }
typedef unsigned long pte_t;
typedef unsigned long iopte_t;
typedef unsigned long pmd_t;
+typedef unsigned long pud_t;
typedef unsigned long pgd_t;
typedef unsigned long pgprot_t;
#define pte_val(x) (x)
#define iopte_val(x) (x)
#define pmd_val(x) (x)
+#define pud_val(x) (x)
#define pgd_val(x) (x)
#define pgprot_val(x) (x)
#define __pte(x) (x)
#define __iopte(x) (x)
#define __pmd(x)(x)
+#define __pud(x)(x)
#define __pgd(x) (x)
#define __pgprot(x)(x)
--- a/arch/sparc/include/asm/pgalloc_64.h
+++ b/arch/sparc/include/asm/pgalloc_64.h
@@ -15,6 +15,13 @@
extern struct kmem_cache *pgtable_cache;
+static inline void __pgd_populate(pgd_t *pgd, pud_t *pud)
+{
+ pgd_set(pgd, pud);
+}
+
+#define pgd_populate(MM, PGD, PUD) __pgd_populate(PGD, PUD)
+
static inline pgd_t *pgd_alloc(struct mm_struct *mm)
{
return kmem_cache_alloc(pgtable_cache, GFP_KERNEL);
@@ -25,7 +32,23 @@ static inline void pgd_free(struct mm_st
kmem_cache_free(pgtable_cache, pgd);
}
-#define pud_populate(MM, PUD, PMD) pud_set(PUD, PMD)
+static inline void __pud_populate(pud_t *pud, pmd_t *pmd)
+{
+ pud_set(pud, pmd);
+}
+
+#define pud_populate(MM, PUD, PMD) __pud_populate(PUD, PMD)
+
+static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
+{
+ return kmem_cache_alloc(pgtable_cache,
+ GFP_KERNEL|__GFP_REPEAT);
+}
+
+static inline void pud_free(struct mm_struct *mm, pud_t *pud)
+{
+ kmem_cache_free(pgtable_cache, pud);
+}
static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
{
@@ -91,4 +114,7 @@ static inline void __pte_free_tlb(struct
#define __pmd_free_tlb(tlb, pmd, addr) \
pgtable_free_tlb(tlb, pmd, false)
+#define __pud_free_tlb(tlb, pud, addr) \
+ pgtable_free_tlb(tlb, pud, false)
+
#endif /* _SPARC64_PGALLOC_H */
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -20,8 +20,6 @@
#include
#include
-#include
-
/* The kernel image occupies 0x400 to 0x600 (4MB --> 96MB).
* The page copy blockops can use 0x600 to 0x800.
* The 8K TSB is mapped in the 0x800 to 0x840 range.
@@ -55,13 +53,21 @@
#define PMD_MASK (~(PMD_SIZE-1))
#define PMD_BITS (PAGE_SHIFT - 3)
-/* PGDIR_SHIFT determines what a third-level page table entry can map */
-#define PGDIR_SHIFT(PAGE_SHIFT + (PAGE_SHIFT-3) + PMD_BITS)
+/* PUD_SHIFT determines the size of the area a third-level page
+ * table can map
+ */
+#define PUD_SHIFT (PMD_SHIFT + PMD_BITS)
+#define PUD_SIZE (_AC(1,UL) << PUD_SHIFT)
+#define PUD_MASK (~(PUD_SIZE-1))
+#define PUD_BITS (PAGE_SHIFT - 3)
+
+/* PGDIR_SHIFT determines what a fourth-level page table entry can map */
+#define PGDIR_SHIFT(PUD_SHIFT + PUD_BITS)
#define PGDIR_SIZE (_AC(1,UL) << PGDIR_SHIFT)
#define PGDIR_MASK (~(PGDIR_SIZE-1))
#define PGDIR_BITS (PAGE_SHIFT - 3)
-#if (PGDIR_SHIFT + PGDIR_BITS) != 43
+#if (PGDIR_SHIFT + PGDIR_BITS) != 53
#error Page table parameters do
[PATCH 3.14 068/100] ARM: mvebu: Netgear RN2120: Use Hardware BCH ECC
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Arnaud Ebalard
commit 500abb6ccb9e3f8d638a7f422443a8549245ef90 upstream.
The bootloader on the Netgear ReadyNAS RN2120 uses Hardware BCH
ECC (strength = 4), while the pxa3xx NAND driver by default uses
Hamming ECC (strength = 1).
This patch changes the ECC mode on these machines to match that
of the bootloader and of the stock firmware. That way, it is
now possible to update the kernel from userland (e.g. using
standard tools from mtd-utils package); u-boot will happily
load and boot it.
The issue was initially reported and fixed by Ben Pedell for
RN102. The RN2120 shares the same Hynix H27U1G8F2BTR NAND
flash and setup. This patch is based on Ben's fix for RN102.
Fixes: ad51eddd95ad ("ARM: mvebu: Enable NAND controller in ReadyNAS 2120 .dts
file")
Signed-off-by: Arnaud Ebalard
Link:
https://lkml.kernel.org/r/61f6a1b7ad0adc57a0e201b9680bc2e5f214a317.1410035142.git.a...@natisbad.org
Signed-off-by: Jason Cooper
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/boot/dts/armada-xp-netgear-rn2120.dts |4
1 file changed, 4 insertions(+)
--- a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
+++ b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
@@ -224,6 +224,10 @@
marvell,nand-enable-arbiter;
nand-on-flash-bbt;
+ /* Use Hardware BCH ECC */
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+
partition@0 {
label = "u-boot";
reg = <0x000 0x18>; /* 1.5MB */
--
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 3.16 105/127] sparc: bpf_jit: fix support for ldx/stx mem and SKF_AD_VLAN_TAG
3.16-stable review patch. If anyone has any objections, please let me know.
--
From: Alexei Starovoitov
[ Upstream commit f6f2332dce0efeea8c5653b6e9d1e8c379ace65c ]
fix several issues in sparc BPF JIT compiler.
ldx/stx related:
. classic BPF instructions that access mem[] slots were not setting
SEEN_MEM flag, so stack wasn't allocated. Fix that by advertising
correct flags
. LDX/STX instructions were missing SEEN_XREG, so register value
could have leaked to user space. Fix it.
. since stack for mem[] slots is allocated with 'sub %sp' instead
of 'save %sp', use %sp as base register instead of %fp.
. ldx mem[0] means first slot in classic BPF which should have
-4 offset instead of 0.
. sparc64 needs 2047 stack bias as per ABI to access stack
. emit_stmem() was using LD32I macro instead of ST32I
SKF_AD_VLAN_TAG* related:
. SKF_AD_VLAN_TAG_PRESENT must return 1 or 0 instead of '> 0' or 0
as per classic BPF de facto standard
. SKF_AD_VLAN_TAG needs to mask the field correctly
Fixes: 2809a2087cc4 ("net: filter: Just In Time compiler for sparc")
Signed-off-by: Alexei Starovoitov
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
arch/sparc/net/bpf_jit_comp.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
--- a/arch/sparc/net/bpf_jit_comp.c
+++ b/arch/sparc/net/bpf_jit_comp.c
@@ -234,12 +234,18 @@ do { BUILD_BUG_ON(FIELD_SIZEOF(STRUCT, F
__emit_load8(BASE, STRUCT, FIELD, DEST);\
} while (0)
-#define emit_ldmem(OFF, DEST) \
-do { *prog++ = LD32I | RS1(FP) | S13(-(OFF)) | RD(DEST); \
+#ifdef CONFIG_SPARC64
+#define BIAS (STACK_BIAS - 4)
+#else
+#define BIAS (-4)
+#endif
+
+#define emit_ldmem(OFF, DEST) \
+do { *prog++ = LD32I | RS1(SP) | S13(BIAS - (OFF)) | RD(DEST); \
} while (0)
-#define emit_stmem(OFF, SRC) \
-do { *prog++ = LD32I | RS1(FP) | S13(-(OFF)) | RD(SRC); \
+#define emit_stmem(OFF, SRC) \
+do { *prog++ = ST32I | RS1(SP) | S13(BIAS - (OFF)) | RD(SRC);\
} while (0)
#ifdef CONFIG_SMP
@@ -615,10 +621,11 @@ void bpf_jit_compile(struct sk_filter *f
case BPF_ANC | SKF_AD_VLAN_TAG:
case BPF_ANC | SKF_AD_VLAN_TAG_PRESENT:
emit_skb_load16(vlan_tci, r_A);
- if (code == (BPF_ANC | SKF_AD_VLAN_TAG)) {
- emit_andi(r_A, VLAN_VID_MASK, r_A);
+ if (code != (BPF_ANC | SKF_AD_VLAN_TAG)) {
+ emit_alu_K(SRL, 12);
+ emit_andi(r_A, 1, r_A);
} else {
- emit_loadimm(VLAN_TAG_PRESENT, r_TMP);
+ emit_loadimm(~VLAN_TAG_PRESENT, r_TMP);
emit_and(r_A, r_TMP, r_A);
}
break;
@@ -630,15 +637,19 @@ void bpf_jit_compile(struct sk_filter *f
emit_loadimm(K, r_X);
break;
case BPF_LD | BPF_MEM:
+ seen |= SEEN_MEM;
emit_ldmem(K * 4, r_A);
break;
case BPF_LDX | BPF_MEM:
+ seen |= SEEN_MEM | SEEN_XREG;
emit_ldmem(K * 4, r_X);
break;
case BPF_ST:
+ seen |= SEEN_MEM;
emit_stmem(K * 4, r_A);
break;
case BPF_STX:
+ seen |= SEEN_MEM | SEEN_XREG;
emit_stmem(K * 4, r_X);
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/
[PATCH 3.14 054/100] futex: Ensure get_futex_key_refs() always implies a barrier
3.14-stable review patch. If anyone has any objections, please let me know. -- From: Catalin Marinas commit 76835b0ebf8a7fe85beb03c75121419a7dec52f0 upstream. Commit b0c29f79ecea (futexes: Avoid taking the hb->lock if there's nothing to wake up) changes the futex code to avoid taking a lock when there are no waiters. This code has been subsequently fixed in commit 11d4616bd07f (futex: revert back to the explicit waiter counting code). Both the original commit and the fix-up rely on get_futex_key_refs() to always imply a barrier. However, for private futexes, none of the cases in the switch statement of get_futex_key_refs() would be hit and the function completes without a memory barrier as required before checking the "waiters" in futex_wake() -> hb_waiters_pending(). The consequence is a race with a thread waiting on a futex on another CPU, allowing the waker thread to read "waiters == 0" while the waiter thread to have read "futex_val == locked" (in kernel). Without this fix, the problem (user space deadlocks) can be seen with Android bionic's mutex implementation on an arm64 multi-cluster system. Signed-off-by: Catalin Marinas Reported-by: Matteo Franchin Fixes: b0c29f79ecea (futexes: Avoid taking the hb->lock if there's nothing to wake up) Acked-by: Davidlohr Bueso Tested-by: Mike Galbraith Cc: Darren Hart Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Paul E. McKenney Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- kernel/futex.c |2 ++ 1 file changed, 2 insertions(+) --- a/kernel/futex.c +++ b/kernel/futex.c @@ -329,6 +329,8 @@ static void get_futex_key_refs(union fut case FUT_OFF_MMSHARED: futex_get_mm(key); /* implies MB (B) */ break; + default: + smp_mb(); /* explicit MB (B) */ } } -- 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 3.14 063/100] ALSA: hda - hdmi: Fix missing ELD change event on plug/unplug
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Anssi Hannula
commit 6acce400d9daf1353fbf497302670c90a3205e1d upstream.
The ELD ALSA control change event is sent by hdmi_present_sense() when
eld_changed is true.
Currently, it is only true when the ELD buffer contents have been
modified. However, the user-visible ELD controls also change to a
zero-length value and back when eld_valid is unset/set, and no event is
currently sent in such cases (such as when unplugging or replugging a
sink).
Fix the code to always set eld_changed if eld_valid value is changed,
and therefore to always send the change event when the user-visible
value changes.
Signed-off-by: Anssi Hannula
Cc: David Henningsson
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/pci/hda/patch_hdmi.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1557,19 +1557,22 @@ static bool hdmi_present_sense(struct hd
}
}
- if (pin_eld->eld_valid && !eld->eld_valid) {
- update_eld = true;
+ if (pin_eld->eld_valid != eld->eld_valid)
eld_changed = true;
- }
+
+ if (pin_eld->eld_valid && !eld->eld_valid)
+ update_eld = true;
+
if (update_eld) {
bool old_eld_valid = pin_eld->eld_valid;
pin_eld->eld_valid = eld->eld_valid;
- eld_changed = pin_eld->eld_size != eld->eld_size ||
+ if (pin_eld->eld_size != eld->eld_size ||
memcmp(pin_eld->eld_buffer, eld->eld_buffer,
-eld->eld_size) != 0;
- if (eld_changed)
+eld->eld_size) != 0) {
memcpy(pin_eld->eld_buffer, eld->eld_buffer,
eld->eld_size);
+ eld_changed = true;
+ }
pin_eld->eld_size = eld->eld_size;
pin_eld->info = eld->info;
--
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 3.14 033/100] mei: bus: fix possible boundaries violation
3.14-stable review patch. If anyone has any objections, please let me know. -- From: Alexander Usyskin commit cfda2794b5afe7ce64ee9605c64bef0e56a48125 upstream. function 'strncpy' will fill whole buffer 'id.name' of fixed size (32) with string value and will not leave place for NULL-terminator. Possible buffer boundaries violation in following string operations. Replace strncpy with strlcpy. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman --- drivers/misc/mei/bus.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/misc/mei/bus.c +++ b/drivers/misc/mei/bus.c @@ -71,7 +71,7 @@ static int mei_cl_device_probe(struct de dev_dbg(dev, "Device probe\n"); - strncpy(id.name, dev_name(dev), sizeof(id.name)); + strlcpy(id.name, dev_name(dev), sizeof(id.name)); return driver->probe(device, ); } -- 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 3.16 103/127] sparc64: Move request_irq() from ldc_bind() to ldc_alloc()
3.16-stable review patch. If anyone has any objections, please let me know.
--
From: Sowmini Varadhan
[ Upstream commit c21c4ab0d6921f7160a43216fa6973b5924de561 ]
The request_irq() needs to be done from ldc_alloc()
to avoid the following (caught by lockdep)
[004a0738] __might_sleep+0xf8/0x120
[0058bea4] kmem_cache_alloc_trace+0x184/0x2c0
[004faf80] request_threaded_irq+0x80/0x160
[0044f71c] ldc_bind+0x7c/0x220
[00452454] vio_port_up+0x54/0xe0
[101f6778] probe_disk+0x38/0x220 [sunvdc]
[101f6b8c] vdc_port_probe+0x22c/0x300 [sunvdc]
[00451a88] vio_device_probe+0x48/0x60
[0074c56c] really_probe+0x6c/0x300
[0074c83c] driver_probe_device+0x3c/0xa0
[0074c92c] __driver_attach+0x8c/0xa0
[0074a6ec] bus_for_each_dev+0x6c/0xa0
[0074c1dc] driver_attach+0x1c/0x40
[0074b0fc] bus_add_driver+0xbc/0x280
Signed-off-by: Sowmini Varadhan
Acked-by: Dwight Engen
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
arch/sparc/include/asm/ldc.h |5 +++--
arch/sparc/kernel/ds.c |4 ++--
arch/sparc/kernel/ldc.c | 41 +
arch/sparc/kernel/viohs.c|4 ++--
4 files changed, 28 insertions(+), 26 deletions(-)
--- a/arch/sparc/include/asm/ldc.h
+++ b/arch/sparc/include/asm/ldc.h
@@ -53,13 +53,14 @@ struct ldc_channel;
/* Allocate state for a channel. */
struct ldc_channel *ldc_alloc(unsigned long id,
const struct ldc_channel_config *cfgp,
- void *event_arg);
+ void *event_arg,
+ const char *name);
/* Shut down and free state for a channel. */
void ldc_free(struct ldc_channel *lp);
/* Register TX and RX queues of the link with the hypervisor. */
-int ldc_bind(struct ldc_channel *lp, const char *name);
+int ldc_bind(struct ldc_channel *lp);
/* For non-RAW protocols we need to complete a handshake before
* communication can proceed. ldc_connect() does that, if the
--- a/arch/sparc/kernel/ds.c
+++ b/arch/sparc/kernel/ds.c
@@ -1200,14 +1200,14 @@ static int ds_probe(struct vio_dev *vdev
ds_cfg.tx_irq = vdev->tx_irq;
ds_cfg.rx_irq = vdev->rx_irq;
- lp = ldc_alloc(vdev->channel_id, _cfg, dp);
+ lp = ldc_alloc(vdev->channel_id, _cfg, dp, "DS");
if (IS_ERR(lp)) {
err = PTR_ERR(lp);
goto out_free_ds_states;
}
dp->lp = lp;
- err = ldc_bind(lp, "DS");
+ err = ldc_bind(lp);
if (err)
goto out_free_ldc;
--- a/arch/sparc/kernel/ldc.c
+++ b/arch/sparc/kernel/ldc.c
@@ -1078,7 +1078,8 @@ static void ldc_iommu_release(struct ldc
struct ldc_channel *ldc_alloc(unsigned long id,
const struct ldc_channel_config *cfgp,
- void *event_arg)
+ void *event_arg,
+ const char *name)
{
struct ldc_channel *lp;
const struct ldc_mode_ops *mops;
@@ -1093,6 +1094,8 @@ struct ldc_channel *ldc_alloc(unsigned l
err = -EINVAL;
if (!cfgp)
goto out_err;
+ if (!name)
+ goto out_err;
switch (cfgp->mode) {
case LDC_MODE_RAW:
@@ -1185,6 +1188,21 @@ struct ldc_channel *ldc_alloc(unsigned l
INIT_HLIST_HEAD(>mh_list);
+ snprintf(lp->rx_irq_name, LDC_IRQ_NAME_MAX, "%s RX", name);
+ snprintf(lp->tx_irq_name, LDC_IRQ_NAME_MAX, "%s TX", name);
+
+ err = request_irq(lp->cfg.rx_irq, ldc_rx, 0,
+ lp->rx_irq_name, lp);
+ if (err)
+ goto out_free_txq;
+
+ err = request_irq(lp->cfg.tx_irq, ldc_tx, 0,
+ lp->tx_irq_name, lp);
+ if (err) {
+ free_irq(lp->cfg.rx_irq, lp);
+ goto out_free_txq;
+ }
+
return lp;
out_free_txq:
@@ -1237,31 +1255,14 @@ EXPORT_SYMBOL(ldc_free);
* state. This does not initiate a handshake, ldc_connect() does
* that.
*/
-int ldc_bind(struct ldc_channel *lp, const char *name)
+int ldc_bind(struct ldc_channel *lp)
{
unsigned long hv_err, flags;
int err = -EINVAL;
- if (!name ||
- (lp->state != LDC_STATE_INIT))
+ if (lp->state != LDC_STATE_INIT)
return -EINVAL;
- snprintf(lp->rx_irq_name, LDC_IRQ_NAME_MAX, "%s RX", name);
- snprintf(lp->tx_irq_name, LDC_IRQ_NAME_MAX, "%s TX", name);
-
- err = request_irq(lp->cfg.rx_irq, ldc_rx, 0,
- lp->rx_irq_name, lp);
- if (err)
- return err;
-
- err = request_irq(lp->cfg.tx_irq, ldc_tx, 0,
- lp->tx_irq_name, lp);
- if (err) {
- free_irq(lp->cfg.rx_irq, lp);
- return err;
- }
-
-
[PATCH 3.14 005/100] Btrfs: cleanup error handling in build_backref_tree
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Josef Bacik
commit 75bfb9aff45e44625260f52a5fd581b92ace3e62 upstream.
When balance panics it tends to panic in the
BUG_ON(!upper->checked);
test, because it means it couldn't build the backref tree properly. This is
annoying to users and frankly a recoverable error, nothing in this function is
actually fatal since it is just an in-memory building of the backrefs for a
given bytenr. So go through and change all the BUG_ON()'s to ASSERT()'s, and
fix the BUG_ON(!upper->checked) thing to just return an error.
This patch also fixes the error handling so it tears down the work we've done
properly. This code was horribly broken since we always just panic'ed instead
of actually erroring out, so it needed to be completely re-worked. With this
patch my broken image no longer panics when I mount it. Thanks,
Signed-off-by: Josef Bacik
Signed-off-by: Chris Mason
Signed-off-by: Greg Kroah-Hartman
---
fs/btrfs/relocation.c | 88 +-
1 file changed, 59 insertions(+), 29 deletions(-)
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -736,7 +736,8 @@ again:
err = ret;
goto out;
}
- BUG_ON(!ret || !path1->slots[0]);
+ ASSERT(ret);
+ ASSERT(path1->slots[0]);
path1->slots[0]--;
@@ -746,10 +747,10 @@ again:
* the backref was added previously when processing
* backref of type BTRFS_TREE_BLOCK_REF_KEY
*/
- BUG_ON(!list_is_singular(>upper));
+ ASSERT(list_is_singular(>upper));
edge = list_entry(cur->upper.next, struct backref_edge,
list[LOWER]);
- BUG_ON(!list_empty(>list[UPPER]));
+ ASSERT(list_empty(>list[UPPER]));
exist = edge->node[UPPER];
/*
* add the upper level block to pending list if we need
@@ -831,7 +832,7 @@ again:
cur->cowonly = 1;
}
#else
- BUG_ON(key.type == BTRFS_EXTENT_REF_V0_KEY);
+ ASSERT(key.type != BTRFS_EXTENT_REF_V0_KEY);
if (key.type == BTRFS_SHARED_BLOCK_REF_KEY) {
#endif
if (key.objectid == key.offset) {
@@ -840,7 +841,7 @@ again:
* backref of this type.
*/
root = find_reloc_root(rc, cur->bytenr);
- BUG_ON(!root);
+ ASSERT(root);
cur->root = root;
break;
}
@@ -868,7 +869,7 @@ again:
} else {
upper = rb_entry(rb_node, struct backref_node,
rb_node);
- BUG_ON(!upper->checked);
+ ASSERT(upper->checked);
INIT_LIST_HEAD(>list[UPPER]);
}
list_add_tail(>list[LOWER], >upper);
@@ -892,7 +893,7 @@ again:
if (btrfs_root_level(>root_item) == cur->level) {
/* tree root */
- BUG_ON(btrfs_root_bytenr(>root_item) !=
+ ASSERT(btrfs_root_bytenr(>root_item) ==
cur->bytenr);
if (should_ignore_root(root))
list_add(>list, );
@@ -927,7 +928,7 @@ again:
need_check = true;
for (; level < BTRFS_MAX_LEVEL; level++) {
if (!path2->nodes[level]) {
- BUG_ON(btrfs_root_bytenr(>root_item) !=
+ ASSERT(btrfs_root_bytenr(>root_item) ==
lower->bytenr);
if (should_ignore_root(root))
list_add(>list, );
@@ -981,7 +982,7 @@ again:
} else {
upper = rb_entry(rb_node, struct backref_node,
rb_node);
- BUG_ON(!upper->checked);
+ ASSERT(upper->checked);
INIT_LIST_HEAD(>list[UPPER]);
if (!upper->owner)
upper->owner = btrfs_header_owner(eb);
@@ -1025,7 +1026,7 @@ next:
* everything goes well, connect backref nodes and insert backref nodes
* into the cache.
*/
- BUG_ON(!node->checked);
+ ASSERT(node->checked);
cowonly = node->cowonly;
if (!cowonly) {
rb_node =
[PATCH 3.14 058/100] arm64: compat: fix compat types affecting struct compat_elf_prpsinfo
3.14-stable review patch. If anyone has any objections, please let me know. -- From: Victor Kamensky commit 971a5b6fe634bb7b617d8c5f25b6a3ddbc600194 upstream. The compat_elf_prpsinfo structure does not match the arch/arm struct elf_pspsinfo definition. As result NT_PRPSINFO note in core file created by arm64 kernel for aarch32 (compat) process has wrong size. So gdb cannot display command that caused process crash. Fix is to change size of __compat_uid_t, __compat_gid_t so it would match size of similar fields in arch/arm case. Signed-off-by: Victor Kamensky Acked-by: Arnd Bergmann Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman --- arch/arm64/include/asm/compat.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/arm64/include/asm/compat.h +++ b/arch/arm64/include/asm/compat.h @@ -37,8 +37,8 @@ typedef s32 compat_ssize_t; typedef s32compat_time_t; typedef s32compat_clock_t; typedef s32compat_pid_t; -typedef u32__compat_uid_t; -typedef u32__compat_gid_t; +typedef u16__compat_uid_t; +typedef u16__compat_gid_t; typedef u16__compat_uid16_t; typedef u16__compat_gid16_t; typedef u32__compat_uid32_t; -- 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 3.14 022/100] be2iscsi: check ip buffer before copying
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Mike Christie
commit a41a9ad3bbf61fae0b6bfb232153da60d14fdbd9 upstream.
Dan Carpenter found a issue where be2iscsi would copy the ip
from userspace to the driver buffer before checking the len
of the data being copied:
http://marc.info/?l=linux-scsi=140982651504251=2
This patch just has us only copy what we the driver buffer
can support.
Tested-by: John Soni Jose
Signed-off-by: Mike Christie
Signed-off-by: Christoph Hellwig
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/be2iscsi/be_mgmt.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/drivers/scsi/be2iscsi/be_mgmt.c
+++ b/drivers/scsi/be2iscsi/be_mgmt.c
@@ -897,17 +897,20 @@ mgmt_static_ip_modify(struct beiscsi_hba
if (ip_action == IP_ACTION_ADD) {
memcpy(req->ip_params.ip_record.ip_addr.addr, ip_param->value,
- ip_param->len);
+ sizeof(req->ip_params.ip_record.ip_addr.addr));
if (subnet_param)
memcpy(req->ip_params.ip_record.ip_addr.subnet_mask,
- subnet_param->value, subnet_param->len);
+ subnet_param->value,
+
sizeof(req->ip_params.ip_record.ip_addr.subnet_mask));
} else {
memcpy(req->ip_params.ip_record.ip_addr.addr,
- if_info->ip_addr.addr, ip_param->len);
+ if_info->ip_addr.addr,
+ sizeof(req->ip_params.ip_record.ip_addr.addr));
memcpy(req->ip_params.ip_record.ip_addr.subnet_mask,
- if_info->ip_addr.subnet_mask, ip_param->len);
+ if_info->ip_addr.subnet_mask,
+ sizeof(req->ip_params.ip_record.ip_addr.subnet_mask));
}
rc = mgmt_exec_nonemb_cmd(phba, _cmd, NULL, 0);
@@ -935,7 +938,7 @@ static int mgmt_modify_gateway(struct be
req->action = gtway_action;
req->ip_addr.ip_type = BE2_IPV4;
- memcpy(req->ip_addr.addr, gt_addr, param_len);
+ memcpy(req->ip_addr.addr, gt_addr, sizeof(req->ip_addr.addr));
return mgmt_exec_nonemb_cmd(phba, _cmd, NULL, 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/
[PATCH 3.14 076/100] sparc64: Fix corrupted thread fault code.
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: "David S. Miller"
[ Upstream commit 84bd6d8b9c0f06b3f188efb479c77e20f05e9a8a ]
Every path that ends up at do_sparc64_fault() must install a valid
FAULT_CODE_* bitmask in the per-thread fault code byte.
Two paths leading to the label winfix_trampoline (which expects the
FAULT_CODE_* mask in register %g4) were not doing so:
1) For pre-hypervisor TLB protection violation traps, if we took
the 'winfix_trampoline' path we wouldn't have %g4 initialized
with the FAULT_CODE_* value yet. Resulting in using the
TLB_TAG_ACCESS register address value instead.
2) In the TSB miss path, when we notice that we are going to use a
hugepage mapping, but we haven't allocated the hugepage TSB yet, we
still have to take the window fixup case into consideration and
in that particular path we leave %g4 not setup properly.
Errors on this sort were largely invisible previously, but after
commit 4ccb9272892c33ef1c19a783cfa87103b30c2784 ("sparc64: sun4v TLB
error power off events") we now have a fault_code mask bit
(FAULT_CODE_BAD_RA) that triggers due to this bug.
FAULT_CODE_BAD_RA triggers because this bit is set in TLB_TAG_ACCESS
(see #1 above) and thus we get seemingly random bus errors triggered
for user processes.
Fixes: 4ccb9272892c ("sparc64: sun4v TLB error power off events")
Reported-by: Meelis Roos
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
arch/sparc/kernel/dtlb_prot.S |6 +++---
arch/sparc/kernel/tsb.S |6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
--- a/arch/sparc/kernel/dtlb_prot.S
+++ b/arch/sparc/kernel/dtlb_prot.S
@@ -24,11 +24,11 @@
mov TLB_TAG_ACCESS, %g4 ! For reload of vaddr
/* PROT ** ICACHE line 2: More real fault processing */
+ ldxa[%g4] ASI_DMMU, %g5 ! Put tagaccess in %g5
bgu,pn %xcc, winfix_trampoline ! Yes, perform winfixup
-ldxa [%g4] ASI_DMMU, %g5 ! Put tagaccess in %g5
- ba,pt %xcc, sparc64_realfault_common ! Nope, normal fault
movFAULT_CODE_DTLB | FAULT_CODE_WRITE, %g4
- nop
+ ba,pt %xcc, sparc64_realfault_common ! Nope, normal fault
+nop
nop
nop
nop
--- a/arch/sparc/kernel/tsb.S
+++ b/arch/sparc/kernel/tsb.S
@@ -162,10 +162,10 @@ tsb_miss_page_table_walk_sun4v_fastpath:
nop
.previous
- rdpr%tl, %g3
- cmp %g3, 1
+ rdpr%tl, %g7
+ cmp %g7, 1
bne,pn %xcc, winfix_trampoline
-nop
+mov%g3, %g4
ba,pt %xcc, etrap
rd %pc, %g7
callhugetlb_setup
--
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 3.14 002/100] Btrfs: add missing compression property remove in btrfs_ioctl_setflags
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Filipe Manana
commit 78a017a2c92df9b571db0a55a016280f9019c65e upstream.
The behaviour of a 'chattr -c' consists of getting the current flags,
clearing the FS_COMPR_FL bit and then sending the result to the set
flags ioctl - this means the bit FS_NOCOMP_FL isn't set in the flags
passed to the ioctl. This results in the compression property not being
cleared from the inode - it was cleared only if the bit FS_NOCOMP_FL
was set in the received flags.
Reproducer:
$ mkfs.btrfs -f /dev/sdd
$ mount /dev/sdd /mnt && cd /mnt
$ mkdir a
$ chattr +c a
$ touch a/file
$ lsattr a/file
c--- a/file
$ chattr -c a
$ touch a/file2
$ lsattr a/file2
c--- a/file2
$ lsattr -d a
a
Reported-by: Andreas Schneider
Signed-off-by: Filipe Manana
Signed-off-by: Chris Mason
Signed-off-by: Greg Kroah-Hartman
---
fs/btrfs/ioctl.c |3 +++
1 file changed, 3 insertions(+)
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -302,6 +302,9 @@ static int btrfs_ioctl_setflags(struct f
goto out_drop;
} else {
+ ret = btrfs_set_prop(inode, "btrfs.compression", NULL, 0, 0);
+ if (ret && ret != -ENODATA)
+ goto out_drop;
ip->flags &= ~(BTRFS_INODE_COMPRESS | BTRFS_INODE_NOCOMPRESS);
}
--
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/
