Re: [PATCH 6/6] UBI: Fastmap: Make ubi_refill_pools() fair

[Tanya Brokhman]

Hi Richard

On 12/5/2014 10:56 PM, Richard Weinberger wrote:

-/**
- * refill_wl_user_pool - refills all the fastmap pool used by ubi_wl_get_peb.
- * @ubi: UBI device description object
- */
-static void refill_wl_user_pool(struct ubi_device *ubi)
-{
-struct ubi_fm_pool *pool = &ubi->fm_pool;
+pool->pebs[pool->size] = e->pnum;
+pool->size++;
+} else
+enough++;

-return_unused_pool_pebs(ubi, pool);
+if (wl_pool->size < wl_pool->max_size) {
+if (!ubi->free.rb_node ||
+   (ubi->free_count - ubi->beb_rsvd_pebs < 5))
+break;

-for (pool->size = 0; pool->size < pool->max_size; pool->size++) {
-pool->pebs[pool->size] = __wl_get_peb(ubi);
-if (pool->pebs[pool->size] < 0)
+e = find_wl_entry(ubi, &ubi->free, WL_FREE_MAX_DIFF);
+self_check_in_wl_tree(ubi, e, &ubi->free);
+rb_erase(&e->u.rb, &ubi->free);
+ubi->free_count--;


why don't you use wl_get_peb() here?


Because wl_get_peb() is not equivalent to the above code.
We want a PEB to be used for wear-leveling not for "end users" like UBIFS.


sorry, my mistake. I meant wl_get_wle() (the new function). the only 
diff between wl_get_wle() and the above is that you use find_wl_entry() 
and wl_get_wle() uses find_mean_wl_entry() and takes the anchor into 
consideration. So I;m trying to understand why wl_get_wle() isn't good here?




Thanks,
//richard




Thanks,
Tanya Brokhman
--
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/4] tools/perf: support parsing parameterized events

[Sukadev Bhattiprolu]

Jiri Olsa [jo...@redhat.com] wrote:

| anyway we could assign directly to the param term name as you do,
| but I think we just need to mark the term as parametrized, like:
| 
| in /sys/bus/event_source/devices/pmu/events/event_name you have:
|   param2=?,bar=1,param1=?

I like the idea of just using a single ? for required parameters, but
the problem I had with this approach can be seen with these two sysfs
entries:

$ cat HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE
domain=0x2,offset=0xe0,starting_index=core,lpar=0x0

$ cat HPM_0THRD_NON_IDLE_CCYC__VCPU_HOME_CORE
domain=0x3,offset=0xe0,starting_index=vcpu,lpar=sibling_guest_id

The parameter 'starting_index' refers to a core in one event and vcpu in
another event. We were trying to give a hint as to what it refers to.

Given that, 'starting_index' is not very intuitive, how about discarding
starting_index and replacing with what it really means for the event and,
use a simple '?' to indicate required parameter).

$ cat HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE
domain=0x2,offset=0xe0,core=?,lpar=0x0

$ cat HPM_0THRD_NON_IDLE_CCYC__VCPU_HOME_CORE
domain=0x3,offset=0xe0,vcpu=?,lpar=?

perf list shows these as:

hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=?/ 
hv_24x7/HPM_0THRD_NON_IDLE_CCYC__VCPU_HOME_CHIP,vcpu=?,lpar=?/

command line would be

-e hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=2/ 

or

-e hv_24x7/HPM_0THRD_NON_IDLE_CCYC__VCPU_HOME_CHIP,vcpu=2,lpar=7/

and would fail if a required parameter is missing.

This would eliminate the need for new strings like 'sibling_guest_id' (or
as Cody calls it monopolizing strings...)

Following quick patch on top of the patchset shows the changes:

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 73d5bfc..a82bc64 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -27,6 +27,8 @@
 #include "hv-24x7-catalog.h"
 #include "hv-common.h"
 
+
+#if 0
 static const char *domain_to_index_string(unsigned domain)
 {
switch (domain) {
@@ -40,6 +42,7 @@ static const char *domain_to_index_string(unsigned domain)
return "UNKNOWN_DOMAIN_INDEX_STRING";
}
 }
+#endif
 
 static const char *event_domain_suffix(unsigned domain)
 {
@@ -114,7 +117,8 @@ static bool catalog_entry_domain_is_valid(unsigned domain)
 /* u3 0-6, one of HV_24X7_PERF_DOMAIN */
 EVENT_DEFINE_RANGE_FORMAT(domain, config, 0, 3);
 /* u16 */
-EVENT_DEFINE_RANGE_FORMAT(starting_index, config, 16, 31);
+EVENT_DEFINE_RANGE_FORMAT(core, config, 16, 31);
+EVENT_DEFINE_RANGE_FORMAT(vcpu, config, 16, 31);
 /* u32, see "data_offset" */
 EVENT_DEFINE_RANGE_FORMAT(offset, config, 32, 63);
 /* u16 */
@@ -127,7 +131,8 @@ EVENT_DEFINE_RANGE(reserved3, config2,  0, 63);
 static struct attribute *format_attrs[] = {
&format_attr_domain.attr,
&format_attr_offset.attr,
-   &format_attr_starting_index.attr,
+   &format_attr_core.attr,
+   &format_attr_vcpu.attr,
&format_attr_lpar.attr,
NULL,
 };
@@ -280,19 +285,23 @@ static unsigned core_domains[] = {
 
 static char *event_fmt(struct hv_24x7_event_data *event, unsigned domain)
 {
+   const char *sindex;
const char *lpar;
 
-   if (is_physical_domain(domain))
+   if (is_physical_domain(domain)) {
lpar = "0x0";
-   else
-   lpar = "$sibling_guest_id";
+   sindex = "core";
+   } else {
+   lpar = "?";
+   sindex = "vcpu";
+   }
 
return kasprintf(GFP_KERNEL,
-   "domain=0x%x,offset=0x%x,starting_index=%s,lpar=%s",
+   "domain=0x%x,offset=0x%x,%s=?,lpar=%s",
domain,
be16_to_cpu(event->event_counter_offs) +
be16_to_cpu(event->event_group_record_offs),
-   domain_to_index_string(domain),
+   sindex,
lpar);
 }
 
@@ -1061,9 +1070,17 @@ out:
 static unsigned long event_24x7_request(struct perf_event *event, u64 *res,
bool success_expected)
 {
+   u16 idx;
+   unsigned domain = event_get_domain(event);
+
+   if (is_physical_domain(domain))
+   idx = event_get_core(event);
+   else
+   idx = event_get_vcpu(event);
+
return single_24x7_request(event_get_domain(event),
event_get_offset(event),
-   event_get_starting_index(event),
+   idx,
event_get_lpar(event),
res,
success_expected);
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index f8674c1..d208fef 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -826,7 +826,7 @@ static char *format_alias(char *buf, int len, struct 
per

Re: [PATCH 4/6] UBI: Fastmap: Fix races in ubi_wl_get_peb()

[Tanya Brokhman]

On 12/5/2014 11:08 PM, Richard Weinberger wrote:




spin_unlock(&ubi->wl_lock);
+if (retried) {
+ubi_err(ubi, "Unable to get a free PEB from user WL pool");
+ret = -ENOSPC;
+goto out;
+}
+retried = 1;


Why did you decide to retry in this function? and why only 1 retry attempt? I'm 
not against it, trying to understand the logic.


Because failing immediately with -ENOSPC is not nice.


Why not? this is what was done before


The behavior from before was not good.
If we return here a -ENOSPC it is not because we ran out of free PEBs, it is 
because the pool contains
no free PEBs and needs refilling.
As between refilling the pool and requesting a fresh PEB from it another thread could 
"steal" all PEBs
we retry.


I think what I really bothers me in this case is that you don't sleep, you 
branch immediately to retry again, so the chances that there will be context 
switch and free pebs appear
aren't that high.
I'm used to functions using some sort of "retry" logic to sleep before retrying. Of 
course sleeping isn't a good idea here. That's why the "retry" bugs me a bit.


You mean a cond_resched()?
This retry-logic is common pattern in UBI. For exmaple see ubi_wl_put_peb().


you're right. didn't pay much attention to ubi_wl_put_peb() before. 
don't like it there either :)

perhaps we can rethink this later for both cases.



Thanks,
//richard




Thanks,
Tanya Brokhman
--
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, a Linux Foundation Collaborative Project

--
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] video: ocfb: Fix data type warning

[Stefan Kristiansson]

On Fri, Dec 05, 2014 at 04:18:30PM +0800, Qiang Chen wrote:
> When allocate framebuffer memory using dma_alloc_coherent(),
> we'd better use dma_addr_t instead of phys_addr_t. Because the
> address we got in fact is DMA or bus address for the platform.
> 
> This patch also fixes below build warning:
> drivers/video/fbdev/ocfb.c:335:2:
>   warning: passing argument 3 of ‘dma_alloc_attrs’
>   from incompatible pointer type [enabled by default]
> 
> Signed-off-by: Qiang Chen 

Acked-by: Stefan Kristiansson 
--
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: Where exactly will arch_fast_hash be used

[George Spelvin]

If you want DoS-resistant hash tables, I'm working on adding SipHash
to the kernel.

This is a keyed pseudo-random function designed specifically for that
application.  I am starting with ext4 directory hashes, and then intended
to expand to secure sequence numbers (since it's far faster than MD5).

(I'm trying to figure out a good interface, since the crypto API
is a bit heavy for something to heavily optimized.)

But one comment caught my eye:
> Even if security wasn't an issue, straight CRC32 has really poor
> lower-order bit distribution, which makes it a terrible choice for
> a hash table that simply uses the lower-order bits.

Er... huh?  That's the first time I've heard that claim, and while I'm not
Philip Koopman or Guy Castagnoli, I thought I understood CRCs pretty well.

CRCs generally mix bits pretty well.  The sparse 16-bit CRCs chosen
for implementation simplicity had some limitations, but the Castagnoli
polynomial is quite dense.

And their mathematical symmetry means that the low bits really shouldn't
be any different from any other bits.  But if it is an issue, it's just
as easy work to shift down the correct number of high bits rather than
using the low.

Can you point me to a source for that statement?
--
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/

[no subject]

[Azcarate, Annette]

¿Necesita un préstamo personal o de negocios urgente? Si es así Email: 
customers_solut...@live.com para el 
formulario solicitud de préstamo y obtener más informació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/

[PATCH] arch: arm: mach-mxs: mach-mxs.c: Remove unused function

[Rickard Strandqvist]

Remove the function __mxs_togl() that is not used anywhere.

This was partially found by using a static code analysis program called 
cppcheck.

Signed-off-by: Rickard Strandqvist 
---
 arch/arm/mach-mxs/mach-mxs.c |5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
index 2e7cec8..3362f48 100644
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@ -72,11 +72,6 @@ static inline void __mxs_clrl(u32 mask, void __iomem *reg)
__raw_writel(mask, reg + MXS_CLR_ADDR);
 }
 
-static inline void __mxs_togl(u32 mask, void __iomem *reg)
-{
-   __raw_writel(mask, reg + MXS_TOG_ADDR);
-}
-
 #define OCOTP_WORD_OFFSET  0x20
 #define OCOTP_WORD_COUNT   0x20
 
-- 
1.7.10.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] arch: arm: mach-msm: vreg.c: Remove unused function

[Rickard Strandqvist]

Remove the function vreg_put() that is not used anywhere.

This was partially found by using a static code analysis program called 
cppcheck.

Signed-off-by: Rickard Strandqvist 
---
 arch/arm/mach-msm/include/mach/vreg.h |1 -
 arch/arm/mach-msm/vreg.c  |4 
 2 files changed, 5 deletions(-)

diff --git a/arch/arm/mach-msm/include/mach/vreg.h 
b/arch/arm/mach-msm/include/mach/vreg.h
index 6626e78..28351ff 100644
--- a/arch/arm/mach-msm/include/mach/vreg.h
+++ b/arch/arm/mach-msm/include/mach/vreg.h
@@ -20,7 +20,6 @@
 struct vreg;
 
 struct vreg *vreg_get(struct device *dev, const char *id);
-void vreg_put(struct vreg *vreg);
 
 int vreg_enable(struct vreg *vreg);
 int vreg_disable(struct vreg *vreg);
diff --git a/arch/arm/mach-msm/vreg.c b/arch/arm/mach-msm/vreg.c
index bd66ed0..0bf891d 100644
--- a/arch/arm/mach-msm/vreg.c
+++ b/arch/arm/mach-msm/vreg.c
@@ -96,10 +96,6 @@ struct vreg *vreg_get(struct device *dev, const char *id)
return ERR_PTR(-ENOENT);
 }
 
-void vreg_put(struct vreg *vreg)
-{
-}
-
 int vreg_enable(struct vreg *vreg)
 {
unsigned id = vreg->id;
-- 
1.7.10.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] arch: arm: mach-msm: smd.c: Remove some unused functions

[Rickard Strandqvist]

Removes some functions that are not used anywhere:
smsm_set_sleep_duration() smsm_get_state() smd_wait_until_writable()
smd_wait_until_readable() smd_write_atomic() smd_sleep_exit()

This was partially found by using a static code analysis program called 
cppcheck.

Signed-off-by: Rickard Strandqvist 
---
 arch/arm/mach-msm/include/mach/msm_smd.h |9 ---
 arch/arm/mach-msm/smd.c  |  105 --
 arch/arm/mach-msm/smd_private.h  |2 -
 3 files changed, 116 deletions(-)

diff --git a/arch/arm/mach-msm/include/mach/msm_smd.h 
b/arch/arm/mach-msm/include/mach/msm_smd.h
index 029463e..48ddef98 100644
--- a/arch/arm/mach-msm/include/mach/msm_smd.h
+++ b/arch/arm/mach-msm/include/mach/msm_smd.h
@@ -40,7 +40,6 @@ int smd_read(smd_channel_t *ch, void *data, int len);
 ** it will return the requested length written or an error.
 */
 int smd_write(smd_channel_t *ch, const void *data, int len);
-int smd_write_atomic(smd_channel_t *ch, const void *data, int len);
 
 int smd_write_avail(smd_channel_t *ch);
 int smd_read_avail(smd_channel_t *ch);
@@ -57,14 +56,6 @@ int smd_cur_packet_size(smd_channel_t *ch);
 void smd_kick(smd_channel_t *ch);
 
 
-#if 0
-/* these are interruptable waits which will block you until the specified
-** number of bytes are readable or writable.
-*/
-int smd_wait_until_readable(smd_channel_t *ch, int bytes);
-int smd_wait_until_writable(smd_channel_t *ch, int bytes);
-#endif
-
 typedef enum {
SMD_PORT_DS = 0,
SMD_PORT_DIAG,
diff --git a/arch/arm/mach-msm/smd.c b/arch/arm/mach-msm/smd.c
index b1588a1..4bc1e71 100644
--- a/arch/arm/mach-msm/smd.c
+++ b/arch/arm/mach-msm/smd.c
@@ -401,36 +401,6 @@ static inline int smd_need_int(struct smd_channel *ch)
return 0;
 }
 
-void smd_sleep_exit(void)
-{
-   unsigned long flags;
-   struct smd_channel *ch;
-   int need_int = 0;
-
-   spin_lock_irqsave(&smd_lock, flags);
-   list_for_each_entry(ch, &smd_ch_list_modem, ch_list) {
-   if (smd_need_int(ch)) {
-   need_int = 1;
-   break;
-   }
-   }
-   list_for_each_entry(ch, &smd_ch_list_dsp, ch_list) {
-   if (smd_need_int(ch)) {
-   need_int = 1;
-   break;
-   }
-   }
-   spin_unlock_irqrestore(&smd_lock, flags);
-   do_smd_probe();
-
-   if (need_int) {
-   if (msm_smd_debug_mask & MSM_SMD_DEBUG)
-   pr_info("smd_sleep_exit need interrupt\n");
-   tasklet_schedule(&smd_fake_irq_tasklet);
-   }
-}
-
-
 void smd_kick(smd_channel_t *ch)
 {
unsigned long flags;
@@ -747,16 +717,6 @@ int smd_write(smd_channel_t *ch, const void *data, int len)
return ch->write(ch, data, len);
 }
 
-int smd_write_atomic(smd_channel_t *ch, const void *data, int len)
-{
-   unsigned long flags;
-   int res;
-   spin_lock_irqsave(&smd_lock, flags);
-   res = ch->write(ch, data, len);
-   spin_unlock_irqrestore(&smd_lock, flags);
-   return res;
-}
-
 int smd_read_avail(smd_channel_t *ch)
 {
return ch->read_avail(ch);
@@ -767,16 +727,6 @@ int smd_write_avail(smd_channel_t *ch)
return ch->write_avail(ch);
 }
 
-int smd_wait_until_readable(smd_channel_t *ch, int bytes)
-{
-   return -1;
-}
-
-int smd_wait_until_writable(smd_channel_t *ch, int bytes)
-{
-   return -1;
-}
-
 int smd_cur_packet_size(smd_channel_t *ch)
 {
return ch->current_packet;
@@ -875,61 +825,6 @@ int smsm_change_state(enum smsm_state_item item,
return 0;
 }
 
-uint32_t smsm_get_state(enum smsm_state_item item)
-{
-   unsigned long flags;
-   uint32_t rv;
-
-   spin_lock_irqsave(&smem_lock, flags);
-
-   rv = readl(smd_info.state + item * 4);
-
-   if (item == SMSM_STATE_MODEM && (rv & SMSM_RESET))
-   handle_modem_crash();
-
-   spin_unlock_irqrestore(&smem_lock, flags);
-
-   return rv;
-}
-
-#ifdef CONFIG_ARCH_MSM_SCORPION
-
-int smsm_set_sleep_duration(uint32_t delay)
-{
-   struct msm_dem_slave_data *ptr;
-
-   ptr = smem_find(SMEM_APPS_DEM_SLAVE_DATA, sizeof(*ptr));
-   if (ptr == NULL) {
-   pr_err("smsm_set_sleep_duration \n");
-   return -EIO;
-   }
-   if (msm_smd_debug_mask & MSM_SMSM_DEBUG)
-   pr_info("smsm_set_sleep_duration %d -> %d\n",
-  ptr->sleep_time, delay);
-   ptr->sleep_time = delay;
-   return 0;
-}
-
-#else
-
-int smsm_set_sleep_duration(uint32_t delay)
-{
-   uint32_t *ptr;
-
-   ptr = smem_find(SMEM_SMSM_SLEEP_DELAY, sizeof(*ptr));
-   if (ptr == NULL) {
-   pr_err("smsm_set_sleep_duration \n");
-   return -EIO;
-   }
-   if (msm_smd_debug_mask & MSM_SMSM_DEBUG)
-   pr_info("smsm_set_sleep_duration %d -> %d\n",
-  *ptr, delay);
-   *ptr = delay;
-   return 0;
-}
-
-

[PATCH v3] ASoC: add xtensa xtfpga I2S interface and platform

[Max Filippov]

XTFPGA boards provides an audio subsystem that consists of TI CDCE706
clock synthesizer, I2S transmitter and TLV320AIC23 audio codec.

I2S transmitter has MMIO-based interface that resembles that of the
OpenCores I2S transmitter. I2S transmitter is always a master on I2S
bus. There's no specialized audio DMA, sample data are transferred to
I2S transmitter FIFO by CPU through memory-mapped queue interface.

Signed-off-by: Max Filippov 
---
Changes v2->v3:
- drop .owner = THIS_MODULE from the struct platform_driver initialization;
- rebase to 3.18-rc7.

Changes v1->v2:
- fix module name in the sound/soc/xtensa/Makefile;
- split PCM data transfer code and I2S interface setup code;
- move clock enabling/disabling to runtime PM code;
- document I2S interface RATIO field;
- rewrite I2S interface LEVEL field calculation to avoid overflows;
- drop select statements from Kconfig;
- document RCU usage for tx_substream;
- clean up code running in RCU read-side critical section;
- use threaded IRQ handler instead of IRQ + tasklet;
- remove empty PCM callback handlers;
- add const to static structures where applicable;
- use platform_set_drvdata instead of dev_set_drvdata;
- drop redundant error reporting code;
- use platform_get_irq instead of platform_get_resource;
- clean up xtfpga_i2s_remove;
- add comments.

 .../devicetree/bindings/sound/cdns,xtfpga-i2s.txt  |  18 +
 MAINTAINERS|   1 +
 sound/soc/Kconfig  |   1 +
 sound/soc/Makefile |   1 +
 sound/soc/xtensa/Kconfig   |   7 +
 sound/soc/xtensa/Makefile  |   3 +
 sound/soc/xtensa/xtfpga-i2s.c  | 675 +
 7 files changed, 706 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
 create mode 100644 sound/soc/xtensa/Kconfig
 create mode 100644 sound/soc/xtensa/Makefile
 create mode 100644 sound/soc/xtensa/xtfpga-i2s.c

diff --git a/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt 
b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
new file mode 100644
index 000..befd125
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cdns,xtfpga-i2s.txt
@@ -0,0 +1,18 @@
+Bindings for I2S controller built into xtfpga Xtensa bitstreams.
+
+Required properties:
+- compatible: shall be "cdns,xtfpga-i2s".
+- reg: memory region (address and length) with device registers.
+- interrupts: interrupt for the device.
+- clocks: phandle to the clk used as master clock. I2S bus clock
+  is derived from it.
+
+Examples:
+
+   i2s0: xtfpga-i2s@0d08 {
+   #sound-dai-cells = <0>;
+   compatible = "cdns,xtfpga-i2s";
+   reg = <0x0d08 0x40>;
+   interrupts = <2 1>;
+   clocks = <&cdce706 4>;
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 180d560..6a09926 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10409,6 +10409,7 @@ M:  Max Filippov 
 L: linux-xte...@linux-xtensa.org
 S: Maintained
 F: drivers/spi/spi-xtensa-xtfpga.c
+F: sound/soc/xtensa/xtfpga-i2s.c
 
 YAM DRIVER FOR AX.25
 M: Jean-Paul Roubelat 
diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 7d5d644..dcc79aa 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -55,6 +55,7 @@ source "sound/soc/spear/Kconfig"
 source "sound/soc/tegra/Kconfig"
 source "sound/soc/txx9/Kconfig"
 source "sound/soc/ux500/Kconfig"
+source "sound/soc/xtensa/Kconfig"
 
 # Supported codecs
 source "sound/soc/codecs/Kconfig"
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index d88edfc..6c24e6a 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_SND_SOC) += spear/
 obj-$(CONFIG_SND_SOC)  += tegra/
 obj-$(CONFIG_SND_SOC)  += txx9/
 obj-$(CONFIG_SND_SOC)  += ux500/
+obj-$(CONFIG_SND_SOC)  += xtensa/
diff --git a/sound/soc/xtensa/Kconfig b/sound/soc/xtensa/Kconfig
new file mode 100644
index 000..c201beb
--- /dev/null
+++ b/sound/soc/xtensa/Kconfig
@@ -0,0 +1,7 @@
+config SND_SOC_XTFPGA_I2S
+   tristate "XTFPGA I2S master"
+   select REGMAP_MMIO
+   help
+ Say Y or M if you want to add support for codecs attached to the
+ I2S interface on XTFPGA daughter board. You will also need to select
+ the drivers for the rest of XTFPGA audio subsystem.
diff --git a/sound/soc/xtensa/Makefile b/sound/soc/xtensa/Makefile
new file mode 100644
index 000..15efbf9
--- /dev/null
+++ b/sound/soc/xtensa/Makefile
@@ -0,0 +1,3 @@
+snd-soc-xtfpga-i2s-objs := xtfpga-i2s.o
+
+obj-$(CONFIG_SND_SOC_XTFPGA_I2S) += snd-soc-xtfpga-i2s.o
diff --git a/sound/soc/xtensa/xtfpga-i2s.c b/sound/soc/xtensa/xtfpga-i2s.c
new file mode 100644
index 000..1cfb19e
--- /dev/null
+++ b/sound/soc/xtensa/xtfpga-i2s.c
@@ -0,0 +1,675 @@
+/*
+ * Xtfpga I2S controller driver
+ *
+ * Copyright (c) 2014 Cadence Design Systems Inc.
+ *
+ * This program is free softw

Re: [PATCH 3.12 00/66] 3.12.35-stable review

[Guenter Roeck]

On 12/06/2014 07:07 AM, Jiri Slaby wrote:

This is the start of the stable review cycle for the 3.12.35 release.
There are 66 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Dec 10 16:07:07 CET 2014.
Anything received after that time might be too late.



Build results:
total: 135 pass: 135 fail: 0
Qemu tests:
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 v3] staging: lustre: fix sparse warning on LPROC_SEQ_FOPS macros

[Tristan Lelong]

This patch fix a sparse warning in lustre sources

warning: incorrect type in argument 1 (different address spaces)
expected void [noderef] *to
got char *

This is done by adding the missing __user attribute on userland pointers inside 
the LPROC_SEQ_FOPS like macros:
- LPROC_SEQ_FOPS
- LPROC_SEQ_FOPS_RW_TYPE
- LPROC_SEQ_FOPS_WR_ONLY
- LDLM_POOL_PROC_WRITER

The patch also updates all the functions that are used by this macro:
- lprocfs_wr_*
- *_seq_write

as well as some helpers used by the previously modified functions (otherwise 
fixing the sparse warning add some new ones):
- lprocfs_write_frac_helper
- lprocfs_write_helper
- lprocfs_write_u64_helper

The patch also fixes one __user pointer direct dereference by strncmp in 
function fld_proc_hash_seq_write.

Signed-off-by: Tristan Lelong 
---
Changes in v2:
Use dynamic allocation for 'name' variable instead of having it on the 
stack, per Greg K-H suggestion.

Changes in v3:
Rename added variable from 'name' to 'fh_name'.
Revert to a stack declaration of 'fh_name' since it is not 80 bytes but 
only 8, per Andreas Dilger comment.
---
 drivers/staging/lustre/lustre/fld/lproc_fld.c  | 14 --
 .../staging/lustre/lustre/include/lprocfs_status.h | 44 +
 drivers/staging/lustre/lustre/ldlm/ldlm_internal.h |  5 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_pool.c |  4 +-
 drivers/staging/lustre/lustre/ldlm/ldlm_resource.c |  7 +--
 drivers/staging/lustre/lustre/lov/lproc_lov.c  | 20 +---
 drivers/staging/lustre/lustre/mdc/lproc_mdc.c  |  7 +--
 .../lustre/lustre/obdclass/linux/linux-module.c|  5 +-
 .../lustre/lustre/obdclass/lprocfs_status.c|  2 +-
 drivers/staging/lustre/lustre/osc/lproc_osc.c  | 57 +-
 .../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c| 25 +-
 11 files changed, 114 insertions(+), 76 deletions(-)

diff --git a/drivers/staging/lustre/lustre/fld/lproc_fld.c 
b/drivers/staging/lustre/lustre/fld/lproc_fld.c
index 95e7de1..9b26bb5 100644
--- a/drivers/staging/lustre/lustre/fld/lproc_fld.c
+++ b/drivers/staging/lustre/lustre/fld/lproc_fld.c
@@ -87,13 +87,21 @@ fld_proc_hash_seq_show(struct seq_file *m, void *unused)
 }
 
 static ssize_t
-fld_proc_hash_seq_write(struct file *file, const char *buffer,
-   size_t count, loff_t *off)
+fld_proc_hash_seq_write(struct file *file,
+   const char __user *buffer,
+   size_t count, loff_t *off)
 {
struct lu_client_fld *fld;
struct lu_fld_hash *hash = NULL;
+   char fh_name[8];
int i;
 
+   if (count > sizeof(fh_name))
+   return -ENAMETOOLONG;
+
+   if (copy_from_user(fh_name, buffer, count) != 0)
+   return -EFAULT;
+
fld = ((struct seq_file *)file->private_data)->private;
LASSERT(fld != NULL);
 
@@ -101,7 +109,7 @@ fld_proc_hash_seq_write(struct file *file, const char 
*buffer,
if (count != strlen(fld_hash[i].fh_name))
continue;
 
-   if (!strncmp(fld_hash[i].fh_name, buffer, count)) {
+   if (!strncmp(fld_hash[i].fh_name, fh_name, count)) {
hash = &fld_hash[i];
break;
}
diff --git a/drivers/staging/lustre/lustre/include/lprocfs_status.h 
b/drivers/staging/lustre/lustre/include/lprocfs_status.h
index cfe503b..8a25cf6 100644
--- a/drivers/staging/lustre/lustre/include/lprocfs_status.h
+++ b/drivers/staging/lustre/lustre/include/lprocfs_status.h
@@ -627,16 +627,16 @@ struct adaptive_timeout;
 extern int lprocfs_at_hist_helper(struct seq_file *m,
  struct adaptive_timeout *at);
 extern int lprocfs_rd_timeouts(struct seq_file *m, void *data);
-extern int lprocfs_wr_timeouts(struct file *file, const char *buffer,
+extern int lprocfs_wr_timeouts(struct file *file, const char __user *buffer,
   unsigned long count, void *data);
-extern int lprocfs_wr_evict_client(struct file *file, const char *buffer,
+extern int lprocfs_wr_evict_client(struct file *file, const char __user 
*buffer,
size_t count, loff_t *off);
-extern int lprocfs_wr_ping(struct file *file, const char *buffer,
+extern int lprocfs_wr_ping(struct file *file, const char __user *buffer,
   size_t count, loff_t *off);
-extern int lprocfs_wr_import(struct file *file, const char *buffer,
+extern int lprocfs_wr_import(struct file *file, const char __user *buffer,
  size_t count, loff_t *off);
 extern int lprocfs_rd_pinger_recov(struct seq_file *m, void *n);
-extern int lprocfs_wr_pinger_recov(struct file *file, const char *buffer,
+extern int lprocfs_wr_pinger_recov(struct file *file, const char __user 
*buffer,
   size_t count, loff_t *off);
 
 /* Statfs helpers */
@@ -650,8 +650,8 @@ extern int lprocfs_rd_f

[PATCH v2] staging: lustre: replace static value with define

[Tristan Lelong]

This patch replace the value '80' used in several files in the lustre source 
code
with a define LUSTRE_MDT_MAXNAMELEN.

This value is used in 4 different structures as the maximum len for a service 
name.
According to the comments, these names follow a convention which make it 
possible
to use the same define for LCS, LSS, LCF, and LSF.

Signed-off-by: Tristan Lelong 
---
Notes:
This modification answers Joe Perches suggestion: 
https://lkml.org/lkml/2014/12/5/107

Changes in v2:
Remove check on LUSTRE_MDT_MAXNAMELEN for fh_name which is not 
a MDT service, 
per Andreas Dilger comment.
---
 drivers/staging/lustre/lustre/fld/fld_internal.h  | 2 +-
 drivers/staging/lustre/lustre/include/lustre/lustre_idl.h | 5 +
 drivers/staging/lustre/lustre/include/lustre_fid.h| 4 ++--
 drivers/staging/lustre/lustre/include/lustre_fld.h| 4 ++--
 4 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/lustre/lustre/fld/fld_internal.h 
b/drivers/staging/lustre/lustre/fld/fld_internal.h
index 8806b60..6125bbe 100644
--- a/drivers/staging/lustre/lustre/fld/fld_internal.h
+++ b/drivers/staging/lustre/lustre/fld/fld_internal.h
@@ -111,7 +111,7 @@ struct fld_cache {
 
/**
 * Cache name used for debug and messages. */
-   char fci_name[80];
+   char fci_name[LUSTRE_MDT_MAXNAMELEN];
unsigned int fci_no_shrink:1;
 };
 
diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h 
b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
index 7b7457c..305ecbe 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
@@ -105,6 +105,11 @@
  * FOO_BULK_PORTALis for incoming bulk on the FOO
  */
 
+/* Lustre service names are following the format
+ * service name + MDT + seq name
+ */
+#define LUSTRE_MDT_MAXNAMELEN  80
+
 #define CONNMGR_REQUEST_PORTAL   1
 #define CONNMGR_REPLY_PORTAL   2
 //#define OSC_REQUEST_PORTAL   3
diff --git a/drivers/staging/lustre/lustre/include/lustre_fid.h 
b/drivers/staging/lustre/lustre/include/lustre_fid.h
index 2d6fbb4..0a0929f 100644
--- a/drivers/staging/lustre/lustre/include/lustre_fid.h
+++ b/drivers/staging/lustre/lustre/include/lustre_fid.h
@@ -358,7 +358,7 @@ struct lu_client_seq {
 * Service uuid, passed from MDT + seq name to form unique seq name to
 * use it with procfs.
 */
-   charlcs_name[80];
+   charlcs_name[LUSTRE_MDT_MAXNAMELEN];
 
/*
 * Sequence width, that is how many objects may be allocated in one
@@ -408,7 +408,7 @@ struct lu_server_seq {
 * Service uuid, passed from MDT + seq name to form unique seq name to
 * use it with procfs.
 */
-   charlss_name[80];
+   charlss_name[LUSTRE_MDT_MAXNAMELEN];
 
/*
 * Allocation chunks for super and meta sequences. Default values are
diff --git a/drivers/staging/lustre/lustre/include/lustre_fld.h 
b/drivers/staging/lustre/lustre/include/lustre_fld.h
index 64c5048..5ee4b1e 100644
--- a/drivers/staging/lustre/lustre/include/lustre_fld.h
+++ b/drivers/staging/lustre/lustre/include/lustre_fld.h
@@ -93,7 +93,7 @@ struct lu_server_fld {
 
/**
 * Fld service name in form "fld-srv-lustre-MDTXXX" */
-   char lsf_name[80];
+   char lsf_name[LUSTRE_MDT_MAXNAMELEN];
 
 };
 
@@ -124,7 +124,7 @@ struct lu_client_fld {
 
/**
 * Client fld proc entry name. */
-   char lcf_name[80];
+   char lcf_name[LUSTRE_MDT_MAXNAMELEN];
 
int   lcf_flags;
 };
-- 
2.1.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 v4 2/5] crypto: AF_ALG: add AEAD support

[Herbert Xu]

On Fri, Dec 05, 2014 at 10:51:51PM +0100, Stephan Mueller wrote:
>
> Would you please be so kind and help me understand when some operations are 
> intended for the parent FD and when for the child FD?

If it changes the tfm it goes in the parent FD otherwise it's the
child FD.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 v4 2/5] crypto: AF_ALG: add AEAD support

[Herbert Xu]

On Sat, Dec 06, 2014 at 09:08:54PM +0100, Stephan Mueller wrote:
>
> While implementing that request, I thought about setting the auth size as 
> part 
> of the msg control in sendmsg instead of setsockopt. This would save us a 
> system call and thus CPU cycles.

No, this is a tfm property and therefore you can't set them on the
child sockets sicne two child sockets would share the same tfm.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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/

[PATCHv2 3/3] ARM:dts:sunxi:ps2 dt nodes for A10/A20 PS2 controller.

[vishnupatekar]

 Added ps2 nodes in lime2 board dts. By default ps20 and ps21 nodes are
 commented as ps20 pins conflict with HDMI connector
 on Lime2 Board.

Signed-off-by: vishnupatekar 
---
 arch/arm/boot/dts/sun4i-a10.dtsi|   27 +
 arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts |   13 ++
 arch/arm/boot/dts/sun7i-a20.dtsi|   29 +++
 3 files changed, 69 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 5e2ec2d..4726e8d 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -615,6 +615,19 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+   ps2_0_pins: ps2_0@0 {
+   allwinner,pins = "PI20","PI21";
+   allwinner,function = "ps2";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
+   ps2_1_pins: ps2_1@0 {
+   allwinner,pins = "PH12","PH13";
+   allwinner,function = "ps2";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
+
};
 
timer@01c20c00 {
@@ -781,5 +794,19 @@
#address-cells = <1>;
#size-cells = <0>;
};
+   ps20: ps2@0x01c2a000 {
+   compatible = "allwinner,sun4i-a10-ps2";
+   reg = <0x01c2a000 0x400>;
+   interrupts = <0 62 4>;
+   clocks = <&apb1_gates 6>;
+   status = "disabled";
+   };
+   ps21: ps2@0x01c2a400 {
+   compatible = "allwinner,sun4i-a10-ps2";
+   reg = <0x01c2a400 0x400>;
+   interrupts = <0 63 4>;
+   clocks = <&apb1_gates 7>;
+   status = "disabled";
+   };
};
 };
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts 
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index ed364d5..5624e63 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -112,6 +112,19 @@
pinctrl-0 = <&uart0_pins_a>;
status = "okay";
};
+   /* PS2 0 and PS2 1 are disabled by default
+   To enable PS2 0 and PS2 1 uncomment below ps20 and ps21 nodes
+   Please note that ps20 pins conflict with HDMI on Lime2 Board*/
+   /*ps20: ps2@0x01c2a000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&ps2_0_pins>;
+   status = "okay";
+   };
+   ps21: ps2@0x01c2a400 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&ps2_1_pins>;
+   status = "okay";
+   };*/
 
i2c0: i2c@01c2ac00 {
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 8605f2b..96fe37d 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -852,6 +852,19 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+   ps2_0_pins: ps2_0@0 {
+   allwinner,pins = "PI20","PI21";
+   allwinner,function = "ps2";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
+   ps2_1_pins: ps2_1@0 {
+   allwinner,pins = "PH12","PH13";
+   allwinner,function = "ps2";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
+
};
 
timer@01c20c00 {
@@ -1079,5 +1092,21 @@
#interrupt-cells = <3>;
interrupts = <1 9 0xf04>;
};
+   ps20: ps2@0x01c2a000 {
+   compatible = "allwinner,sun7i-a20-ps2";
+   reg = <0x01c2a000 0x400>;
+   interrupts = <0 62 4>;
+   clocks = <&apb1_gates 6>;
+   status = "disabled";
+   };
+   ps21: ps2@0x01c2a400 {
+   compatible = "allwinner,sun7i-a20-ps2";
+   reg = <0x01c

[PATCHv2 0/3] ARM:sunxi:ps2 Added support for A10/A20 ps2 controller.

[vishnupatekar]

Here is v2 of SUNXI PS2 controller support patch-set as with v1.

Changes in v2: 
1. added default n depends on ARCH_SUNXI || COMPILE_TEST in Kconfig.
2. handled errors and free resources on errors.
3. used BIT(x), DIV_ROUND_UP macros.
4. corrected style errors.
5. added support for A10 also, A10 and A2 have same properties of PS2 
controller.
6. by default commented ps20 and ps21 nodes,as ps20 pins conflict with HDMI
   connector on Lime2 Board.
7. added compatible as allwinner,sun4i-a10-ps2.
8. corrected the possible race condition.

Patch 0 Summary: Allwinner A10/A20 PS2 controller. These modifications are
for PS2 host controller. IBM compliant IBM PS2 and AT-compatible 
keyboard and mouse can be connected.

Patch 1 device tree bindings.

Patch 2 adds support for sun7i ps2 driver.

Patch 3 device tree support for PS2 controller.
 1) Added A10/A20 ps2 nodes to the dtsi
 2) Added A10/A20 ps2 pinmux to the dtsi
 3) Added ps2 nodes to the lime2 dts file

vishnupatekar (3):
  sunxi:dts-bindings:input:ps2 bindings for A10/A20 ps2.
  sunxi:drivers:input:ps2 Added sunxi A10/A20 ps2 driver
  ARM:dts:sunxi:ps2 dt nodes for A10/A20 PS2 controller.

 .../bindings/input/allwinner,sunxi-ps2.txt |   23 ++
 arch/arm/boot/dts/sun4i-a10.dtsi   |   27 ++
 arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts|   13 +
 arch/arm/boot/dts/sun7i-a20.dtsi   |   29 ++
 drivers/input/serio/Kconfig|   10 +
 drivers/input/serio/Makefile   |1 +
 drivers/input/serio/sunxi-ps2.c|  364 
 7 files changed, 467 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/allwinner,sunxi-ps2.txt
 create mode 100644 drivers/input/serio/sunxi-ps2.c

-- 
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/

[PATCHv2 1/3] sunxi:dts-bindings:input:ps2 bindings for A10/A20 ps2.

[vishnupatekar]

A10 and A20 have same PS2 addresses, clocks, interrupts.
added compatible as allwinner,sun4i-a10-ps2.

Signed-off-by: vishnupatekar 
---
 .../bindings/input/allwinner,sunxi-ps2.txt |   23 
 1 file changed, 23 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/allwinner,sunxi-ps2.txt

diff --git a/Documentation/devicetree/bindings/input/allwinner,sunxi-ps2.txt 
b/Documentation/devicetree/bindings/input/allwinner,sunxi-ps2.txt
new file mode 100644
index 000..3a8919a
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/allwinner,sunxi-ps2.txt
@@ -0,0 +1,23 @@
+* Device tree bindings for Allwinner A10, A20 PS2 host controller
+
+A20 PS2 is dual role controller(PS2 host and PS2 device). These bindings are 
for PS2 host controller.
+IBM compliant IBM PS2 and AT-compatible keyboard and mouse can be connected.
+
+Required properties:
+
+ - reg : Offset and length of the register set for the device.
+ - compatible  : Should one of the following:
+ - "allwinner,sun7i-a20-ps2"
+ - "allwinner,sun4i-a10-ps2"
+ - interrupts  : The interrupt line connected to the PS2.
+ - clocks  : The gate clk connected to the PS2.
+
+
+Example:
+   ps20: ps2@0x01c2a000 {
+   compatible = "allwinner,sun7i-a20-ps2";
+   reg = <0x01c2a000 0x400>;
+   interrupts = <0 62 4>;
+   clocks = <&apb1_gates 6>;
+   status = "disabled";
+   };
-- 
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/

[PATCHv2 2/3] sunxi:drivers:input:ps2 Added sunxi A10/A20 ps2 driver

[vishnupatekar]

 -added compatible as allwinner,sun4i-a10-ps2 and allwinner,sun7i-a20-ps2.
 - added default n depends on ARCH_SUNXI || COMPILE_TEST
 in Kconfig.
 -handled errors and free resources on errors.
 -used BIT(x), DIV_ROUND_UP macros.
 -corrected style errors.

Signed-off-by: vishnupatekar 
---
 drivers/input/serio/Kconfig |   10 ++
 drivers/input/serio/Makefile|1 +
 drivers/input/serio/sunxi-ps2.c |  364 +++
 3 files changed, 375 insertions(+)
 create mode 100644 drivers/input/serio/sunxi-ps2.c

diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index bc2d474..3a7599c 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -281,4 +281,14 @@ config HYPERV_KEYBOARD
  To compile this driver as a module, choose M here: the module will
  be called hyperv_keyboard.
 
+config SERIO_SUNXI_PS2
+   tristate "Allwinner Sun4i-A10/Sun7i-A20 PS/2 controller"
+   default n
+   depends on ARCH_SUNXI || COMPILE_TEST
+   help
+ Say Y here if you have Sun4i-A10/Sun7i-A20 Allwinner PS/2 ports.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sunxi-ps2.
+
 endif
diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile
index 815d874..0fa0f78 100644
--- a/drivers/input/serio/Makefile
+++ b/drivers/input/serio/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_SERIO_ARC_PS2)   += arc_ps2.o
 obj-$(CONFIG_SERIO_APBPS2) += apbps2.o
 obj-$(CONFIG_SERIO_OLPC_APSP)  += olpc_apsp.o
 obj-$(CONFIG_HYPERV_KEYBOARD)  += hyperv-keyboard.o
+obj-$(CONFIG_SERIO_SUNXI_PS2)  += sunxi-ps2.o
diff --git a/drivers/input/serio/sunxi-ps2.c b/drivers/input/serio/sunxi-ps2.c
new file mode 100644
index 000..4cd89ae
--- /dev/null
+++ b/drivers/input/serio/sunxi-ps2.c
@@ -0,0 +1,364 @@
+/*
+ * Driver for Allwinner A20 PS2 host controller
+ *
+ * Author: Vishnu Patekar 
+ * Aaron.maoye 
+ *
+ * Based on 3.0 kernel
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME"sunxi-ps2"
+
+/* register offset definitions */
+#define PS2_REG_GCTL   (0x00)  /*  PS2 Module Global Control Reg */
+#define PS2_REG_DATA   (0x04)  /*  PS2 Module Data Reg */
+#define PS2_REG_LCTL   (0x08)  /*  PS2 Module Line Control Reg */
+#define PS2_REG_LSTS   (0x0C)  /*  PS2 Module Line Status Reg  */
+#define PS2_REG_FCTL   (0x10)  /*  PS2 Module FIFO Control Reg */
+#define PS2_REG_FSTS   (0x14)  /*  PS2 Module FIFO Status Reg  */
+#define PS2_REG_CLKDR  (0x18)  /*  PS2 Module Clock Divider Reg*/
+
+/*  PS2 GLOBAL CONTROL REGISTER PS2_GCTL */
+#define PS2_GCTL_INTFLAG   BIT(4)
+#define PS2_GCTL_INTEN BIT(3)
+#define PS2_GCTL_RESET BIT(2)
+#define PS2_GCTL_MASTERBIT(1)
+#define PS2_GCTL_BUSEN BIT(0)
+
+/* PS2 LINE CONTROL REGISTER */
+#define PS2_LCTL_NOACK BIT(18)
+#define PS2_LCTL_TXDTOEN   BIT(8)
+#define PS2_LCTL_STOPERREN BIT(3)
+#define PS2_LCTL_ACKERREN  BIT(2)
+#define PS2_LCTL_PARERREN  BIT(1)
+#define PS2_LCTL_RXDTOEN   BIT(0)
+
+/* PS2 LINE STATUS REGISTER */
+#define PS2_LSTS_TXTDO BIT(8)
+#define PS2_LSTS_STOPERR   BIT(3)
+#define PS2_LSTS_ACKERRBIT(2)
+#define PS2_LSTS_PARERRBIT(1)
+#define PS2_LSTS_RXTDO BIT(0)
+
+/* PS2 FIFO CONTROL REGISTER */
+#define PS2_FCTL_TXRST BIT(17)
+#define PS2_FCTL_RXRST BIT(16)
+#define PS2_FCTL_TXUFIEN   BIT(10)
+#define PS2_FCTL_TXOFIEN   BIT(9)
+#define PS2_FCTL_TXRDYIEN  BIT(8)
+#define PS2_FCTL_RXUFIEN   BIT(2)
+#define PS2_FCTL_RXOFIEN   BIT(1)
+#define PS2_FCTL_RXRDYIEN  BIT(0)
+
+/* PS2 FIFO STATUS REGISTER */
+#define PS2_FSTS_TXUF  BIT(10)
+#define PS2_FSTS_TXOF  BIT(9)
+#define PS2_FSTS_TXRDY BIT(8)
+#define PS2_FSTS_RXUF  BIT(2)
+#define PS2_FSTS_RXOF  BIT(1)
+#define PS2_FSTS_RXRDY BIT(0)
+
+
+#define PS2_LINE_ERROR_BIT \
+   (PS2_LSTS_TXTDO|PS2_LSTS_STOPERR|PS2_LSTS_ACKERR| \
+   PS2_LSTS_PARERR|PS2_LSTS_RXTDO)
+
+#define PS2_FIFO_ERROR_BIT \
+   (PS2_FSTS_TXUF|PS2_FSTS_TXOF|PS2_FSTS_TXRDY|PS2_FSTS_RXUF| \
+   PS2_FSTS_RXOF|PS2_FSTS_RXRDY)
+
+#define PS2_SAMPLE_CLK (100)
+#define PS2_SCLK   (125000)
+
+struct sunxips2data {
+   struct serio *serio;
+   struct device *dev;
+
+   /* IO mapping base */
+   void __iomem*reg_base;
+
+   /* clock management */
+   struct clk  *clk;
+
+   /* irq */
+   spinlock_t  lock;
+   int irq;
+};
+
+/*/
+/* Interrupt handler */
+/*/
+static irqreturn_t sunxips2_interrupt(int irq, void *dev_id)
+{
+   struct sunxips2data *drvdata = dev_i

Re: [PATCH v2 1/4] pwm: kona: Remove setting default smooth type and polarity for all channels

[Tim Kryger]

On Thu, Dec 4, 2014 at 12:22 PM, Jonathan Richardson
 wrote:
> Hi Tim,
>
> I'm going to take over this submission because I made the changes to the
> driver. Arun was filling in for me while I was on leave. Now I'm back
> and I think I can help clarify why these changes were made. A summary
> for all the changes should help.
>
> There were two problems. First was a problem caused by setting the
> polarity in probe. It caused the speaker to click when the polarity was
> set so we took that out as it didn't seem to serve any useful purpose
> that I could see. The polarity changes should be made in the polarity
> callback.

Please provide more details about your configuration.

Are you using the pwm-beeper driver with a piezo?

After a reset, all PWM output will be low until the PWM clock is
enabled at which point it will be constant high.  Are you confident
that this transition is not responsible for the click you are hearing?

> The second and bigger problem was the smooth type sequence. If it isn't
> done according to the spec then one in ten or twenty times you won't
> even get a signal when it's enabled. Following the correct sequence with
> the 400 ns delays solves this problem.

Would the following minor change be sufficient to fix the issue?

diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
index 02bc048..c537efd 100644
--- a/drivers/pwm/pwm-bcm-kona.c
+++ b/drivers/pwm/pwm-bcm-kona.c
@@ -85,6 +85,9 @@ static void kona_pwmc_apply_settings(struct kona_pwmc *kp, uns
value &= ~(1 << PWM_CONTROL_TRIGGER_SHIFT(chan));
writel(value, kp->base + PWM_CONTROL_OFFSET);

+   ndelay(400);
+
/* Set trigger bit and clear smooth bit to apply new settings */
value &= ~(1 << PWM_CONTROL_SMOOTH_SHIFT(chan));
value |= 1 << PWM_CONTROL_TRIGGER_SHIFT(chan);

>
> Additionally, by not following the sequence you won't get a smooth
> transition. You'll get a change in the settings (duty cycle, period) but
> may get a non smooth transition. So it's important to follow the spec
> here. We don't want non-smooth transitions.

Please provide your rationale for requiring smooth transitions.

Thanks,
Tim Kryger
--
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: How can I parse the command name from /proc//stat?

[Steven Stewart-Gallus]

Thank you, I dislike the idea of relying upon stat never gaining any other part
that uses ) but that would work instead of using status.
--
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.17 000/122] 3.17.5-stable review

[Greg Kroah-Hartman]

On Sat, Dec 06, 2014 at 02:35:52PM -0700, Shuah Khan wrote:
> On 12/05/2014 03:42 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.17.5 release.
> > There are 122 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 Sun Dec  7 22:32:17 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.17.5-rc1.gz
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all 3 of these and letting me know.

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] arch: arm: mach-davinci: cdce949.c: Remove unused function

[Rickard Strandqvist]

Remove the function cdce_set_rate() that is not used anywhere.

This was partially found by using a static code analysis program called 
cppcheck.

Signed-off-by: Rickard Strandqvist 
---
 arch/arm/mach-davinci/cdce949.c  |   37 --
 arch/arm/mach-davinci/include/mach/cdce949.h |2 --
 2 files changed, 39 deletions(-)

diff --git a/arch/arm/mach-davinci/cdce949.c b/arch/arm/mach-davinci/cdce949.c
index abafb92..bccac4a 100644
--- a/arch/arm/mach-davinci/cdce949.c
+++ b/arch/arm/mach-davinci/cdce949.c
@@ -212,43 +212,6 @@ static struct cdce_output output_list[] = {
[5] = { cdce_y5_freqs, ARRAY_SIZE(cdce_y5_freqs) },
 };
 
-int cdce_set_rate(struct clk *clk, unsigned long rate)
-{
-   int i, ret = 0;
-   struct cdce_freq *freq_table = output_list[clk->lpsc].freq_table;
-   struct cdce_reg  *regs = NULL;
-
-   if (!cdce_i2c_client)
-   return -ENODEV;
-
-   if (!freq_table)
-   return -EINVAL;
-
-   for (i = 0; i < output_list[clk->lpsc].size; i++) {
-   if (freq_table[i].frequency == rate / 1000) {
-   regs = freq_table[i].reglist;
-   break;
-   }
-   }
-
-   if (!regs)
-   return -EINVAL;
-
-   mutex_lock(&cdce_mutex);
-   for (i = 0; regs[i].addr; i++) {
-   ret = i2c_smbus_write_byte_data(cdce_i2c_client,
-   regs[i].addr | 0x80, regs[i].val);
-   if (ret)
-   break;
-   }
-   mutex_unlock(&cdce_mutex);
-
-   if (!ret)
-   clk->rate = rate;
-
-   return ret;
-}
-
 static int cdce_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
diff --git a/arch/arm/mach-davinci/include/mach/cdce949.h 
b/arch/arm/mach-davinci/include/mach/cdce949.h
index c73331f..2280e0b 100644
--- a/arch/arm/mach-davinci/include/mach/cdce949.h
+++ b/arch/arm/mach-davinci/include/mach/cdce949.h
@@ -14,6 +14,4 @@
 
 #include 
 
-int cdce_set_rate(struct clk *clk, unsigned long rate);
-
 #endif
-- 
1.7.10.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] arch: arm: common: edma.c: Remove some unused functions

[Rickard Strandqvist]

Removes some functions that are not used anywhere:
edma_shadow0_read() edma_or_array()

This was partially found by using a static code analysis program called 
cppcheck.

Signed-off-by: Rickard Strandqvist 
---
 arch/arm/common/edma.c |8 
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index d86771a..163273d 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -160,10 +160,6 @@ static inline void edma_modify_array(unsigned ctlr, int 
offset, int i,
 {
edma_modify(ctlr, offset + (i << 2), and, or);
 }
-static inline void edma_or_array(unsigned ctlr, int offset, int i, unsigned or)
-{
-   edma_or(ctlr, offset + (i << 2), or);
-}
 static inline void edma_or_array2(unsigned ctlr, int offset, int i, int j,
unsigned or)
 {
@@ -174,10 +170,6 @@ static inline void edma_write_array2(unsigned ctlr, int 
offset, int i, int j,
 {
edma_write(ctlr, offset + ((i*2 + j) << 2), val);
 }
-static inline unsigned int edma_shadow0_read(unsigned ctlr, int offset)
-{
-   return edma_read(ctlr, EDMA_SHADOW0 + offset);
-}
 static inline unsigned int edma_shadow0_read_array(unsigned ctlr, int offset,
int i)
 {
-- 
1.7.10.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] arch: arc: plat-arcfpga: smp.c: Remove some unused functions

[Rickard Strandqvist]

Removes some functions that are not used anywhere:
idu_irq_get_pend() idu_irq_get_ack()

This was partially found by using a static code analysis program called 
cppcheck.

Signed-off-by: Rickard Strandqvist 
---
 arch/arc/plat-arcfpga/smp.c |   27 ---
 1 file changed, 27 deletions(-)

diff --git a/arch/arc/plat-arcfpga/smp.c b/arch/arc/plat-arcfpga/smp.c
index 64797ba..2b1b42a 100644
--- a/arch/arc/plat-arcfpga/smp.c
+++ b/arch/arc/plat-arcfpga/smp.c
@@ -157,30 +157,3 @@ void idu_irq_set_tgtcpu(uint8_t irq, uint32_t mask)
IDU_SET_PARAM(mask);
IDU_SET_COMMAND(irq, IDU_IRQ_WBITMASK);
 }
-
-/* Get the Interrupt Acknowledged status for IRQ (as CPU Bitmask) */
-bool idu_irq_get_ack(uint8_t irq)
-{
-   uint32_t val;
-
-   IDU_SET_COMMAND(irq, IDU_IRQ_ACK);
-   val = IDU_GET_PARAM();
-
-   return val & (1 << irq);
-}
-
-/*
- * Get the Interrupt Pending status for IRQ (as CPU Bitmask)
- * -Pending means CPU has not yet noticed the IRQ (e.g. disabled)
- * -After Interrupt has been taken, the IPI expcitily needs to be
- *  cleared, to be acknowledged.
- */
-bool idu_irq_get_pend(uint8_t irq)
-{
-   uint32_t val;
-
-   IDU_SET_COMMAND(irq, IDU_IRQ_PEND);
-   val = IDU_GET_PARAM();
-
-   return val & (1 << irq);
-}
-- 
1.7.10.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/

Re: [PATCH] staging: lustre: replace static value with define

[Tristan Lelong]

On Sat, Dec 06, 2014 at 05:09:29PM +, Dilger, Andreas wrote:
> > 
> >diff --git a/drivers/staging/lustre/lustre/fld/lproc_fld.c
> >b/drivers/staging/lustre/lustre/fld/lproc_fld.c
> >index 74b4db9..7a55941 100644
> >--- a/drivers/staging/lustre/lustre/fld/lproc_fld.c
> >+++ b/drivers/staging/lustre/lustre/fld/lproc_fld.c
> >@@ -96,7 +96,7 @@ fld_proc_hash_seq_write(struct file *file,
> > char *name;
> > int i;
> > 
> >-if (count > 80)
> >+if (count > LUSTRE_MDT_MAXNAMELEN)
> > return -ENAMETOOLONG;
> 
> Sorry for the late reply, but this has nothing to do with an MDT service
> name, so using this #define is misleading here.  As I wrote in my other
> email, this only needs to be at most 8 characters.
> 

I see that now, I will change that according to the other email.

Do you want me to redo this patch and still define the 80 as 
LUSTRE_MDT_MAXNAMELEN
but without this last part (just the define and the string length declaration), 
or
should we just let this go?

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: frequent lockups in 3.18rc4

[Thomas Gleixner]

On Fri, 5 Dec 2014, Linus Torvalds wrote:
> On Fri, Dec 5, 2014 at 10:48 AM, Dave Jones  wrote:
> >
> > In the meantime, I rebooted into the same kernel, and ran trinity
> > solely doing the lsetxattr syscalls.
> 
> Any particular reason for the lsetxattr guess? Just the last call
> chain? I don't recognize it from the other traces, but maybe I just
> didn't notice.
> 
> >   The load was a bit lower, so I
> > cranked up the number of child processes to 512, and then this
> > happened..
> 
> Ugh. "dump_trace()" being broken and looping forever? I don't actually

Looking at the callchain: up to the point where dump_stack() is called
everything is preemtible context. So dump_stack() would need to loop
for a few seconds to trigger the NMI watchdog.

> believe it, because this isn't even on the exception stack (well, the
> NMI dumper is, but that one worked fine - this is the "nested" dumping
> of just the allocation call chain)

I doubt that dump_trace() itself is broken, but the call site might
have handed in something which causes memory corruption. And looking
at set_track() and the completely undocumented way how it retrieves
the storage for the trace entries via get_track() makes my brain melt.

Thanks,

tglx







--
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] staging: lustre: fix sparse warning on LPROC_SEQ_FOPS macros

[Tristan Lelong]

Andreas,

On Sat, Dec 06, 2014 at 05:05:14PM +, Dilger, Andreas wrote:
> On 2014/12/05, 3:41 PM, "Tristan Lelong"  wrote:
> 
> 
> Sorry, but I don't see where you get 80 from?  fh_name is declared as a
> "const char *", and initialized in the declaration of fld_hash[].  I'd
> thought to reply that sizeof(fh_name) would even be better than a #define,
> but sizeof(const char *) doesn't actually make sense.
> 

You are right, I got confused with the names trying to follow the declaration 
of the variable.

> The longest declared fh_name is 4 characters, but I'm not sure of an easy
> way to determine this at compile time.  I guess one option is to change
> the declaration of struct lu_fld_hash to use "const char fh_name[4];" and
> then use sizeof(fh_name), but I don't know if that is better than just
> declaring a small buffer (8 chars) for this usage.  IMHO that is small
> enough to fit on the stack, since it is at the top of a very short
> callchain (userspace->sys_write->vfs_write->fld_proc_hash_seq_write())
> that just saves the value so the chance of stack overflow is basically nil.
> 

I can implement any of those 2 options. If somebody as a strong preference, let 
me know,
otherwise I'll follow Andreas idea and will redo the patch with a stack name 
variable of size 8.

> 
> Cheers, Andreas
> -- 
> Andreas Dilger
> 
> Lustre Software Architect
> Intel High Performance Data Division
> 
> 

Thanks for your comment and help.
--
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] arch: alpha: kernel: core_titan.c: Remove some unused functions

[Rickard Strandqvist]

Removes some functions that are not used anywhere:
titan_write_tig() titan_read_tig()

This was partially found by using a static code analysis program called 
cppcheck.

Signed-off-by: Rickard Strandqvist 
---
 arch/alpha/kernel/core_titan.c |   14 --
 1 file changed, 14 deletions(-)

diff --git a/arch/alpha/kernel/core_titan.c b/arch/alpha/kernel/core_titan.c
index 219bf27..2de2a2a 100644
--- a/arch/alpha/kernel/core_titan.c
+++ b/arch/alpha/kernel/core_titan.c
@@ -62,21 +62,7 @@ mk_tig_addr(int offset)
return (volatile unsigned long *)(TITAN_TIG_SPACE + (offset << 6));
 }
 
-static inline u8 
-titan_read_tig(int offset, u8 value)
-{
-   volatile unsigned long *tig_addr = mk_tig_addr(offset);
-   return (u8)(*tig_addr & 0xff);
-}
-
-static inline void 
-titan_write_tig(int offset, u8 value)
-{
-   volatile unsigned long *tig_addr = mk_tig_addr(offset);
-   *tig_addr = (unsigned long)value;
-}
 
-
 /*
  * Given a bus, device, and function number, compute resulting
  * configuration space address
-- 
1.7.10.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/

Re: [PATCH 2/4] clk: iproc: add initial common clock support

[Tim Kryger]

On Thu, Dec 4, 2014 at 1:43 PM, Ray Jui  wrote:
> This adds basic and generic support for various iProc PLLs and clocks
> including the ARMPLL, GENPLL, LCPLL, MIPIPLL, and ASIU clocks.
>
> SoCs under the iProc architecture can define their specific register
> offsets and clock parameters for their PLL and clock controllers. These
> parameters can be passed as arugments into the generic iProc PLL and
> clock setup functions
>
> Derived from code originally provided by Jonathan Richardson
> 
>
> Signed-off-by: Ray Jui 
> Reviewed-by: Scott Branden 
> ---
>  drivers/clk/Makefile   |2 +-
>  drivers/clk/bcm/Kconfig|9 +
>  drivers/clk/bcm/Makefile   |1 +
>  drivers/clk/bcm/clk-iproc-armpll.c |  286 +
>  drivers/clk/bcm/clk-iproc-asiu.c   |  275 
>  drivers/clk/bcm/clk-iproc-clk.c|  238 ++
>  drivers/clk/bcm/clk-iproc-pll.c|  483 
> 
>  drivers/clk/bcm/clk-iproc.h|  155 
>  8 files changed, 1448 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/clk/bcm/clk-iproc-armpll.c
>  create mode 100644 drivers/clk/bcm/clk-iproc-asiu.c
>  create mode 100644 drivers/clk/bcm/clk-iproc-clk.c
>  create mode 100644 drivers/clk/bcm/clk-iproc-pll.c
>  create mode 100644 drivers/clk/bcm/clk-iproc.h
>
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index d5fba5b..eff0213 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -41,7 +41,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
>  obj-$(CONFIG_COMMON_CLK_WM831X)+= clk-wm831x.o
>  obj-$(CONFIG_COMMON_CLK_XGENE) += clk-xgene.o
>  obj-$(CONFIG_COMMON_CLK_AT91)  += at91/
> -obj-$(CONFIG_ARCH_BCM_MOBILE)  += bcm/
> +obj-$(CONFIG_ARCH_BCM) += bcm/
>  obj-$(CONFIG_ARCH_BERLIN)  += berlin/
>  obj-$(CONFIG_ARCH_HI3xxx)  += hisilicon/
>  obj-$(CONFIG_ARCH_HIP04)   += hisilicon/

It may be best to move the above change into its own commit.

> diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
> index 75506e5..66b5b7f 100644
> --- a/drivers/clk/bcm/Kconfig
> +++ b/drivers/clk/bcm/Kconfig
> @@ -7,3 +7,12 @@ config CLK_BCM_KONA
>   Enable common clock framework support for Broadcom SoCs
>   using "Kona" style clock control units, including those
>   in the BCM281xx and BCM21664 families.
> +
> +config COMMON_CLK_IPROC
> +   bool "Broadcom iProc clock support"
> +   depends on ARCH_BCM_IPROC
> +   depends on COMMON_CLK
> +   default y
> +   help
> + Enable common clock framework support for Broadcom SoCs
> + based on the "iProc" architecture
> diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
> index 6297d05..6926636 100644
> --- a/drivers/clk/bcm/Makefile
> +++ b/drivers/clk/bcm/Makefile
> @@ -2,3 +2,4 @@ obj-$(CONFIG_CLK_BCM_KONA)  += clk-kona.o
>  obj-$(CONFIG_CLK_BCM_KONA) += clk-kona-setup.o
>  obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm281xx.o
>  obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm21664.o
> +obj-$(CONFIG_COMMON_CLK_IPROC) += clk-iproc-armpll.o clk-iproc-pll.o 
> clk-iproc-clk.o clk-iproc-asiu.o
> diff --git a/drivers/clk/bcm/clk-iproc-armpll.c 
> b/drivers/clk/bcm/clk-iproc-armpll.c
> new file mode 100644
> index 000..ec9b130
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-iproc-armpll.c
> @@ -0,0 +1,286 @@
> +/*
> + * Copyright (C) 2014 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define IPROC_CLK_MAX_FREQ_POLICY0x3
> +#define IPROC_CLK_POLICY_FREQ_OFFSET 0x008
> +#define IPROC_CLK_POLICY_FREQ_POLICY_FREQ_SHIFT  8
> +#define IPROC_CLK_POLICY_FREQ_POLICY_FREQ_MASK   0x7
> +
> +#define IPROC_CLK_PLLARMA_OFFSET 0xc00
> +#define IPROC_CLK_PLLARMA_LOCK_SHIFT 28
> +#define IPROC_CLK_PLLARMA_PDIV_SHIFT 24
> +#define IPROC_CLK_PLLARMA_PDIV_MASK  0xf
> +#define IPROC_CLK_PLLARMA_NDIV_INT_SHIFT 8
> +#define IPROC_CLK_PLLARMA_NDIV_INT_MASK  0x3ff
> +
> +#define IPROC_CLK_PLLARMB_OFFSET 0xc04
> +#define IPROC_CLK_PLLARMB_NDIV_FRAC_MASK 0xf
> +
> +#define IPROC_CLK_PLLARMC_OFFSET 0xc08
> +#define IPROC_CLK_PLLARMC_BYPCLK_EN_SHIFT8
> +#define 

Re: next-20141204 crashing on ext4_fill_super()

[Theodore Ts'o]

Please revert fdfe07398761 and that should the crashes; this will be
fixed in the next linux-next release.  My apologies for the inconvenience.

- Ted
--
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: frequent lockups in 3.18rc4

[Thomas Gleixner]

On Sat, 6 Dec 2014, Chuck Ebbert wrote:
> On Fri, 5 Dec 2014 13:48:08 -0500
> Dave Jones  wrote:
> 
> > [ 1611.749570]  [] do_nmi+0xb8/0xf0
> > [ 1611.750438]  [] end_repeat_nmi+0x1e/0x2e
> > [ 1611.751312]  [] ? preempt_count_add+0x18/0xb0
> > [ 1611.752177]  [] ? preempt_count_add+0x18/0xb0
> > [ 1611.753025]  [] ? preempt_count_add+0x18/0xb0
> > [ 1611.753861]  <>  [] 
> > is_module_text_address+0x17/0x50
> > [ 1611.754734]  [] __kernel_text_address+0x58/0x80
> > [ 1611.755575]  [] print_context_stack+0x8f/0x100
> > [ 1611.756410]  [] dump_trace+0x140/0x370
> > [ 1611.757242]  [] ? getname_flags+0x4f/0x1a0
> > [ 1611.758072]  [] ? getname_flags+0x4f/0x1a0
> > [ 1611.758895]  [] save_stack_trace+0x2b/0x50
> > [ 1611.759720]  [] set_track+0x70/0x140
> > [ 1611.760541]  [] alloc_debug_processing+0x92/0x118
> > [ 1611.761366]  [] __slab_alloc+0x45f/0x56f
> > [ 1611.762195]  [] ? getname_flags+0x4f/0x1a0
> > [ 1611.763024]  [] ? __slab_free+0x114/0x309
> > [ 1611.763853]  [] ? debug_check_no_obj_freed+0x17e/0x270
> > [ 1611.764712]  [] ? getname_flags+0x4f/0x1a0
> > [ 1611.765539]  [] kmem_cache_alloc+0x1f6/0x270
> 
> So, every time there is a slab allocation the entire stack trace gets
> saved as human readable text. And for each line in the trace,

Wrong. It gets saved as address. No conversion to text at all.

> is_module_text_address() can be called, which has huge overhead
> walking the entire list of loaded modules. No wonder there are
> timeouts...

You would have to have a gazillion of modules to make that overhead
big enough to trigger a multi seconds watchdog.

Thanks,

tglx




--
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] ASoC: fix platform_no_drv_owner.cocci warnings

[kbuild test robot]

sound/soc/xtensa/xtfpga-i2s.c:666:3-8: No need to set .owner here. The core 
will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

Signed-off-by: Fengguang Wu 
---

 xtfpga-i2s.c |1 -
 1 file changed, 1 deletion(-)

--- a/sound/soc/xtensa/xtfpga-i2s.c
+++ b/sound/soc/xtensa/xtfpga-i2s.c
@@ -663,7 +663,6 @@ static struct platform_driver xtfpga_i2s
.remove  = xtfpga_i2s_remove,
.driver  = {
.name = "xtfpga-i2s",
-   .owner = THIS_MODULE,
.of_match_table = of_match_ptr(xtfpga_i2s_of_match),
.pm = &xtfpga_i2s_pm_ops,
},
--
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] kobject: grammar fix

[John de la Garza]

Signed-off-by: John de la Garza 
---
 Documentation/kobject.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt
index f87241d..1be59a3 100644
--- a/Documentation/kobject.txt
+++ b/Documentation/kobject.txt
@@ -173,7 +173,7 @@ This should be done only after any attributes or children 
of the kobject
 have been initialized properly, as userspace will instantly start to look
 for them when this call happens.
 
-When the kobject is removed from the kernel (details on how to do that is
+When the kobject is removed from the kernel (details on how to do that are
 below), the uevent for KOBJ_REMOVE will be automatically created by the
 kobject core, so the caller does not have to worry about doing that by
 hand.
-- 
2.1.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 3.14 00/73] 3.14.26-stable review

[Shuah Khan]

On 12/05/2014 03:44 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.26 release.
> There are 73 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 Sun Dec  7 22:44:19 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.14.26-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Samsung Open Source Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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/45] 3.10.62-stable review

[Shuah Khan]

On 12/05/2014 03:44 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.62 release.
> There are 45 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 Sun Dec  7 22:32:54 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.62-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Samsung Open Source Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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.17 000/122] 3.17.5-stable review

[Shuah Khan]

On 12/05/2014 03:42 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.17.5 release.
> There are 122 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 Sun Dec  7 22:32:17 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.17.5-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Samsung Open Source Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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: frequent lockups in 3.18rc4

[Martin van Es]

On Sat, Dec 6, 2014 at 9:09 PM, Linus Torvalds
 wrote:
> On Sat, Dec 6, 2014 at 8:22 AM, Martin van Es  wrote:
>>
>> Hope this may help in finding the right direction for this bug?
>
> If you can reproduce it with your spare J1900 system and could perhaps
> bisect it there, that would be a huge help.
>

I'll give it a shot and see if I can get to freeze it on 3.17.3 as a
start by playing content from the prd backend, but don't expect fast
respons times... busy man...

M.
--
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: frequent lockups in 3.18rc4

[Linus Torvalds]

On Sat, Dec 6, 2014 at 12:09 PM, Linus Torvalds
 wrote:
> On Sat, Dec 6, 2014 at 8:22 AM, Martin van Es  wrote:
>>
>> Hope this may help in finding the right direction for this bug?
>
> If you can reproduce it with your spare J1900 system and could perhaps
> bisect it there, that would be a huge help.

Side note: your load sounds superficially more like the one Dâniel
Fraga had, who saw lockups with 3.17 but 3.18-rc7 actually works for
him.

But if you're running 3.17.3, I think you should already have all the
relevant fixes throuigh the -stable tree.

   Linus
--
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: [BUG] kzalloc overflow in lpfc driver on 6k core system

[James Smart]

Alex,

Myself and several others here at Emulex maintain the code. The 
recommendations look fine.   Feel free to post something if you beat us 
to the work.


-- james s


On 12/3/2014 11:05 AM, Alex Thorlton wrote:

On Tue, Dec 02, 2014 at 10:39:40PM +, Elliott, Robert (Server Storage) 
wrote:

In similar code, mpt3sas and lockless hpsa just call get_cpu_mask()
inside the loop:
 cpu = cpumask_first(cpu_online_mask);
 for (i = 0; i < h->msix_vector; i++) {
 rc = irq_set_affinity_hint(h->intr[i], get_cpu_mask(cpu));
 cpu = cpumask_next(cpu, cpu_online_mask);
 }

get_cpu_mask() uses the global cpu_bit_bitmap array, which is declared
in kernel/cpu.c:
extern const unsigned long
 cpu_bit_bitmap[BITS_PER_LONG+1][BITS_TO_LONGS(NR_CPUS)];

That approach should work for lpfc.

Ok, good deal.  Thanks for the info, Robert.  Do you know who the
current maintainer is for this code?  Would that be you?  I included the
two authors that get_maintainer reported, but haven't heard from them.

I like this approach and don't mind implementing it myself, but I'd like
to confirm that whoever would be responsible for merging the code is ok
with the change before going forward.  Of course, if the code has been
orphaned, then I guess we just write away :)

Thanks again for the help!

- Alex




--
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: frequent lockups in 3.18rc4

[Linus Torvalds]

On Sat, Dec 6, 2014 at 8:22 AM, Martin van Es  wrote:
>
> Hope this may help in finding the right direction for this bug?

If you can reproduce it with your spare J1900 system and could perhaps
bisect it there, that would be a huge help.

Linus
--
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 v4 2/5] crypto: AF_ALG: add AEAD support

[Stephan Mueller]

Am Freitag, 5. Dezember 2014, 22:51:51 schrieb Stephan Mueller:

Hi Herbert,

> > > +static struct proto_ops algif_aead_ops = {
> > > + .family =   PF_ALG,
> > > +
> > > + .connect=   sock_no_connect,
> > > + .socketpair =   sock_no_socketpair,
> > > + .getname=   sock_no_getname,
> > > + .ioctl  =   sock_no_ioctl,
> > > + .listen =   sock_no_listen,
> > > + .shutdown   =   sock_no_shutdown,
> > > + .getsockopt =   sock_no_getsockopt,
> > > + .mmap   =   sock_no_mmap,
> > > + .bind   =   sock_no_bind,
> > > + .accept =   sock_no_accept,
> > > +
> > > + .release=   af_alg_release,
> > > + .sendmsg=   aead_sendmsg,
> > > + .sendpage   =   aead_sendpage,
> > > + .recvmsg=   aead_recvmsg,
> > > + .poll   =   aead_poll,
> > > + .setsockopt =   aead_setsockopt,
> > 
> > No it should go into the parent setsockopt.  Perhaps add a setsockopt
> > to af_alg_type in order to keep this out of the generic code.
> 
> I was thinking about that for quite a while. My thought for the current
> approach was that the actual cipher operation happens in the child FD (i.e.
> after accept). AAD is delivered to that FD. Therefore, I thought that the
> size of the AAD can be specific to that operational FD.
> 
> If we move it to the parent setsockopt, all child FDs have the same AAD
> size. If you think that this is the right course of action, I can surely
> implement that.
> 
> Would you please be so kind and help me understand when some operations are
> intended for the parent FD and when for the child FD?

While implementing that request, I thought about setting the auth size as part 
of the msg control in sendmsg instead of setsockopt. This would save us a 
system call and thus CPU cycles.

Thus may I propose that instead of using setsockopt,  ALG_SET_AEAD_AUTHSIZE 
should be added to af_alg_cmsg_send the same way as ALG_SET_AEAD_ASSOCLEN.

Along that line, wouldn't it make sense to get rid of the setsockopt in 
general and move even setting the key into the msg control and thus into 
af_alg_cmsg_send? I understand that this is a change to the user space API.

Thanks

-- 
Ciao
Stephan
--
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 4/5] f2fs: release inmemory pages when the file was closed

[Jaegeuk Kim]

If file is closed, let's drop inmemory pages.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/file.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 146e58a..b6f3fbf 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -901,6 +901,14 @@ static int f2fs_ioc_start_atomic_write(struct file *filp)
return f2fs_convert_inline_inode(inode);
 }
 
+static int f2fs_release_file(struct inode *inode, struct file *filp)
+{
+   /* some remained atomic pages should discarded */
+   if (f2fs_is_atomic_file(inode) || f2fs_is_volatile_file(inode))
+   commit_inmem_pages(inode, true);
+   return 0;
+}
+
 static int f2fs_ioc_commit_atomic_write(struct file *filp)
 {
struct inode *inode = file_inode(filp);
@@ -1010,6 +1018,7 @@ const struct file_operations f2fs_file_operations = {
.read_iter  = generic_file_read_iter,
.write_iter = generic_file_write_iter,
.open   = generic_file_open,
+   .release= f2fs_release_file,
.mmap   = f2fs_file_mmap,
.fsync  = f2fs_sync_file,
.fallocate  = f2fs_fallocate,
-- 
2.1.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/

[PATCH 5/5] f2fs: count the number of inmemory pages

[Jaegeuk Kim]

This patch adds counting # of inmemory pages in the page cache.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/debug.c   | 3 +++
 fs/f2fs/f2fs.h| 3 ++-
 fs/f2fs/segment.c | 3 +++
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
index 40b679c..4e2e39c 100644
--- a/fs/f2fs/debug.c
+++ b/fs/f2fs/debug.c
@@ -39,6 +39,7 @@ static void update_general_status(struct f2fs_sb_info *sbi)
si->ndirty_dent = get_pages(sbi, F2FS_DIRTY_DENTS);
si->ndirty_dirs = sbi->n_dirty_dirs;
si->ndirty_meta = get_pages(sbi, F2FS_DIRTY_META);
+   si->inmem_pages = get_pages(sbi, F2FS_INMEM_PAGES);
si->total_count = (int)sbi->user_block_count / sbi->blocks_per_seg;
si->rsvd_segs = reserved_segments(sbi);
si->overp_segs = overprovision_segments(sbi);
@@ -249,6 +250,8 @@ static int stat_show(struct seq_file *s, void *v)
seq_printf(s, "\nExtent Hit Ratio: %d / %d\n",
   si->hit_ext, si->total_ext);
seq_puts(s, "\nBalancing F2FS Async:\n");
+   seq_printf(s, "  - inmem: %4d\n",
+  si->inmem_pages);
seq_printf(s, "  - nodes: %4d in %4d\n",
   si->ndirty_node, si->node_pages);
seq_printf(s, "  - dents: %4d in dirs:%4d\n",
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index c787fe3..f60b817 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -462,6 +462,7 @@ enum count_type {
F2FS_DIRTY_DENTS,
F2FS_DIRTY_NODES,
F2FS_DIRTY_META,
+   F2FS_INMEM_PAGES,
NR_COUNT_TYPE,
 };
 
@@ -1498,7 +1499,7 @@ struct f2fs_stat_info {
int ndirty_node, ndirty_dent, ndirty_dirs, ndirty_meta;
int nats, sits, fnids;
int total_count, utilization;
-   int bg_gc, inline_inode, inline_dir;
+   int bg_gc, inline_inode, inline_dir, inmem_pages;
unsigned int valid_count, valid_node_count, valid_inode_count;
unsigned int bimodal, avg_vblocks;
int util_free, util_valid, util_invalid;
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 3ebcf96..42607a6 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -201,6 +201,7 @@ retry:
}
get_page(page);
list_add_tail(&new->list, &fi->inmem_pages);
+   inc_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES);
mutex_unlock(&fi->inmem_lock);
 }
 
@@ -216,6 +217,7 @@ void invalidate_inmem_page(struct inode *inode, struct page 
*page)
f2fs_put_page(cur->page, 0);
list_del(&cur->list);
kmem_cache_free(inmem_entry_slab, cur);
+   dec_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES);
}
mutex_unlock(&fi->inmem_lock);
 }
@@ -257,6 +259,7 @@ void commit_inmem_pages(struct inode *inode, bool abort)
f2fs_put_page(cur->page, 1);
list_del(&cur->list);
kmem_cache_free(inmem_entry_slab, cur);
+   dec_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES);
}
if (submit_bio)
f2fs_submit_merged_bio(sbi, DATA, WRITE);
-- 
2.1.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/

[PATCH 2/5] f2fs: count inline_xx in do_read_inode

[Jaegeuk Kim]

In do_read_inode, if we failed __recover_inline_status, the inode has inline
flag without increasing its count.
Later, f2fs_evict_inode will decrease the count, which causes -1.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/inode.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index 9fe110e..196cc78 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -148,6 +148,10 @@ static int do_read_inode(struct inode *inode)
__get_inode_rdev(inode, ri);
 
f2fs_put_page(node_page, 1);
+
+   stat_inc_inline_inode(inode);
+   stat_inc_inline_dir(inode);
+
return err;
 }
 
@@ -199,8 +203,6 @@ make_now:
goto bad_inode;
}
unlock_new_inode(inode);
-   stat_inc_inline_inode(inode);
-   stat_inc_inline_dir(inode);
trace_f2fs_iget(inode);
return inode;
 
-- 
2.1.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/

[PATCH 1/5] f2fs: do retry operations with cond_resched

[Jaegeuk Kim]

This patch revists retrial paths in f2fs.
The basic idea is to use cond_resched instead of retrying from the very early
stage.

Suggested-by: Gu Zheng 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/f2fs.h|  7 +++
 fs/f2fs/gc.c  |  5 ++---
 fs/f2fs/node.c| 41 +
 fs/f2fs/segment.c |  5 ++---
 4 files changed, 20 insertions(+), 38 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index c873140..c787fe3 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1021,6 +1021,13 @@ retry:
return entry;
 }
 
+static inline void f2fs_radix_tree_insert(struct radix_tree_root *root,
+   unsigned long index, void *item)
+{
+   while (radix_tree_insert(root, index, item))
+   cond_resched();
+}
+
 #define RAW_IS_INODE(p)((p)->footer.nid == (p)->footer.ino)
 
 static inline bool IS_INODE(struct page *page)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 2c58c58..eec0933 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -356,12 +356,11 @@ static void add_gc_inode(struct gc_inode_list *gc_list, 
struct inode *inode)
iput(inode);
return;
}
-retry:
new_ie = f2fs_kmem_cache_alloc(winode_slab, GFP_NOFS);
new_ie->inode = inode;
-
+retry:
if (radix_tree_insert(&gc_list->iroot, inode->i_ino, new_ie)) {
-   kmem_cache_free(winode_slab, new_ie);
+   cond_resched();
goto retry;
}
list_add_tail(&new_ie->list, &gc_list->ilist);
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 8de4f55..f83326c 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -147,7 +147,7 @@ static void __set_nat_cache_dirty(struct f2fs_nm_info *nm_i,
 
if (get_nat_flag(ne, IS_DIRTY))
return;
-retry:
+
head = radix_tree_lookup(&nm_i->nat_set_root, set);
if (!head) {
head = f2fs_kmem_cache_alloc(nat_entry_set_slab, GFP_ATOMIC);
@@ -156,11 +156,7 @@ retry:
INIT_LIST_HEAD(&head->set_list);
head->set = set;
head->entry_cnt = 0;
-
-   if (radix_tree_insert(&nm_i->nat_set_root, set, head)) {
-   kmem_cache_free(nat_entry_set_slab, head);
-   goto retry;
-   }
+   f2fs_radix_tree_insert(&nm_i->nat_set_root, set, head);
}
list_move_tail(&ne->list, &head->entry_list);
nm_i->dirty_nat_cnt++;
@@ -238,13 +234,8 @@ static struct nat_entry *grab_nat_entry(struct 
f2fs_nm_info *nm_i, nid_t nid)
 {
struct nat_entry *new;
 
-   new = kmem_cache_alloc(nat_entry_slab, GFP_ATOMIC);
-   if (!new)
-   return NULL;
-   if (radix_tree_insert(&nm_i->nat_root, nid, new)) {
-   kmem_cache_free(nat_entry_slab, new);
-   return NULL;
-   }
+   new = f2fs_kmem_cache_alloc(nat_entry_slab, GFP_ATOMIC);
+   f2fs_radix_tree_insert(&nm_i->nat_root, nid, new);
memset(new, 0, sizeof(struct nat_entry));
nat_set_nid(new, nid);
nat_reset_flag(new);
@@ -257,15 +248,11 @@ static void cache_nat_entry(struct f2fs_nm_info *nm_i, 
nid_t nid,
struct f2fs_nat_entry *ne)
 {
struct nat_entry *e;
-retry:
+
down_write(&nm_i->nat_tree_lock);
e = __lookup_nat_cache(nm_i, nid);
if (!e) {
e = grab_nat_entry(nm_i, nid);
-   if (!e) {
-   up_write(&nm_i->nat_tree_lock);
-   goto retry;
-   }
node_info_from_raw_nat(&e->ni, ne);
}
up_write(&nm_i->nat_tree_lock);
@@ -276,15 +263,11 @@ static void set_node_addr(struct f2fs_sb_info *sbi, 
struct node_info *ni,
 {
struct f2fs_nm_info *nm_i = NM_I(sbi);
struct nat_entry *e;
-retry:
+
down_write(&nm_i->nat_tree_lock);
e = __lookup_nat_cache(nm_i, ni->nid);
if (!e) {
e = grab_nat_entry(nm_i, ni->nid);
-   if (!e) {
-   up_write(&nm_i->nat_tree_lock);
-   goto retry;
-   }
e->ni = *ni;
f2fs_bug_on(sbi, ni->blk_addr == NEW_ADDR);
} else if (new_blkaddr == NEW_ADDR) {
@@ -1833,19 +1816,13 @@ static void remove_nats_in_journal(struct f2fs_sb_info 
*sbi)
nid_t nid = le32_to_cpu(nid_in_journal(sum, i));
 
raw_ne = nat_in_journal(sum, i);
-retry:
+
down_write(&nm_i->nat_tree_lock);
ne = __lookup_nat_cache(nm_i, nid);
-   if (ne)
-   goto found;
-
-   ne = grab_nat_entry(nm_i, nid);
if (!ne) {
-   up_write(&nm_i->nat_tree_lock);
-   goto retry;
+   ne = grab_nat_entry(nm_i, nid);
+   node_info_from_raw_nat(&ne->ni, &raw_ne)

[PATCH 3/5] f2fs: set page private for inmemory pages for truncation

[Jaegeuk Kim]

The inmemory pages should be handled by invalidate_page since it needs to be
released int the truncation path.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/segment.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index c79d67e..3ebcf96 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -180,6 +180,8 @@ void register_inmem_page(struct inode *inode, struct page 
*page)
struct inmem_pages *new;
int err;
 
+   SetPagePrivate(page);
+
new = f2fs_kmem_cache_alloc(inmem_entry_slab, GFP_NOFS);
 
/* add atomic page indices to the list */
-- 
2.1.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/

next-20141204 crashing on ext4_fill_super()

[Murilo Opsfelder Araujo]

Hello, everyone.

next-20141204 started crashing on my laptop with the following error right 
after I enter my disk encryption password:

http://opsfelder.com/~murilo/lkml/next-20141204_crash.jpg

The previous version next-20141203 was working just fine.  next-20141205 is 
also crashing.

Git-bisect pointed me to the commit [1] 
d0079b903022160fee1d673a3c1f3154c84385eb "ext4: 
ext4_da_convert_inline_data_to_extent drop locked page after error".

I tried reverting it from next-20141204 but got no luck.

I'd be happy if someone can help me getting this fixed.

Thanks in advance.

[1]
commit d0079b903022160fee1d673a3c1f3154c84385eb
Author: Dmitry Monakhov 
Date:   Tue Dec 2 18:46:20 2014 -0500

ext4: ext4_da_convert_inline_data_to_extent drop locked page after error

Testcase:
xfstests generic/270
MKFS_OPTIONS="-q -I 256 -O inline_data,64bit"

Call Trace:
 [] lock_page+0x35/0x39 ---> DEADLOCK
 [] pagecache_get_page+0x65/0x15a
 [] truncate_inode_pages_range+0x1db/0x45c
 [] ? ext4_da_get_block_prep+0x439/0x4b6
 [] ? __block_write_begin+0x284/0x29c
 [] ? ext4_change_inode_journal_flag+0x16b/0x16b
 [] truncate_inode_pages+0x12/0x14
 [] ext4_truncate_failed_write+0x19/0x25
 [] ext4_da_write_inline_data_begin+0x196/0x31c
 [] ext4_da_write_begin+0x189/0x302
 [] ? trace_hardirqs_on+0xd/0xf
 [] ? read_seqcount_begin.clone.1+0x9f/0xcc
 [] generic_perform_write+0xc7/0x1c6
 [] ? mark_held_locks+0x59/0x77
 [] __generic_file_write_iter+0x17f/0x1c5
 [] ext4_file_write_iter+0x2a5/0x354
 [] ? file_start_write+0x2a/0x2c
 [] ? bad_area_nosemaphore+0x13/0x15
 [] new_sync_write+0x8a/0xb2
 [] vfs_write+0xb5/0x14d
 [] SyS_write+0x5c/0x8c
 [] system_call_fastpath+0x12/0x17

Signed-off-by: Dmitry Monakhov 
Signed-off-by: Theodore Ts'o 

-- 
Murilo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/3] fanotify: dont recalculate a marks mask if only the ignored mask changed

[Lino Sanfilippo]

If removing bits from a marks ignored mask, the concerning inodes/vfsmounts
mask is not affected. So dont recalculate it.

Signed-off-by: Lino Sanfilippo 
Reviewed-by: Jan Kara 
---
 fs/notify/fanotify/fanotify_user.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/notify/fanotify/fanotify_user.c 
b/fs/notify/fanotify/fanotify_user.c
index ba31055..ddc33fb 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -487,15 +487,15 @@ static __u32 fanotify_mark_remove_from_mask(struct 
fsnotify_mark *fsn_mark,
unsigned int flags,
int *destroy)
 {
-   __u32 oldmask;
+   __u32 oldmask = 0;
 
spin_lock(&fsn_mark->lock);
if (!(flags & FAN_MARK_IGNORED_MASK)) {
oldmask = fsn_mark->mask;
fsnotify_set_mark_mask_locked(fsn_mark, (oldmask & ~mask));
} else {
-   oldmask = fsn_mark->ignored_mask;
-   fsnotify_set_mark_ignored_mask_locked(fsn_mark, (oldmask & 
~mask));
+   __u32 tmask = fsn_mark->ignored_mask & ~mask;
+   fsnotify_set_mark_ignored_mask_locked(fsn_mark, tmask);
}
*destroy = !(fsn_mark->mask | fsn_mark->ignored_mask);
spin_unlock(&fsn_mark->lock);
-- 
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/

[PATCH v3 3/3] fanotify: dont set FAN_ONDIR implicitly on a marks ignored mask

[Lino Sanfilippo]

Currently FAN_ONDIR is always set on a marks ignored mask when the event mask
is extended without FAN_MARK_ONDIR being set. This may result in events for
directories being ignored unexpectedly for call sequences like

fanotify_mark(fd, FAN_MARK_ADD, FAN_OPEN | FAN_ONDIR , AT_FDCWD, "dir");
fanotify_mark(fd, FAN_MARK_ADD, FAN_CLOSE, AT_FDCWD, "dir");

Also FAN_MARK_ONDIR is only honored when adding events to a marks mask, but
not for event removal. Fix both issues by not setting FAN_ONDIR implicitly on
the ignore mask any more. Instead treat FAN_ONDIR as any other event flag and
require FAN_MARK_ONDIR to be set by the user for both event mask and ignore
mask. Furthermore take FAN_MARK_ONDIR into account when set for event removal.

Signed-off-by: Lino Sanfilippo 
Reviewed-by: Jan Kara 
---
 fs/notify/fanotify/fanotify.c  |  2 +-
 fs/notify/fanotify/fanotify_user.c | 24 
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index 30d3add..51ceb81 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -140,7 +140,7 @@ static bool fanotify_should_send_event(struct fsnotify_mark 
*inode_mark,
}
 
if (S_ISDIR(path->dentry->d_inode->i_mode) &&
-   (marks_ignored_mask & FS_ISDIR))
+   !(marks_mask & FS_ISDIR & ~marks_ignored_mask))
return false;
 
if (event_mask & marks_mask & ~marks_ignored_mask)
diff --git a/fs/notify/fanotify/fanotify_user.c 
b/fs/notify/fanotify/fanotify_user.c
index ddc33fb..683d140 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -491,10 +491,17 @@ static __u32 fanotify_mark_remove_from_mask(struct 
fsnotify_mark *fsn_mark,
 
spin_lock(&fsn_mark->lock);
if (!(flags & FAN_MARK_IGNORED_MASK)) {
+   __u32 tmask = fsn_mark->mask & ~mask;
+   if (flags & FAN_MARK_ONDIR)
+   tmask &= ~FAN_ONDIR;
+
oldmask = fsn_mark->mask;
-   fsnotify_set_mark_mask_locked(fsn_mark, (oldmask & ~mask));
+   fsnotify_set_mark_mask_locked(fsn_mark, tmask);
} else {
__u32 tmask = fsn_mark->ignored_mask & ~mask;
+   if (flags & FAN_MARK_ONDIR)
+   tmask &= ~FAN_ONDIR;
+
fsnotify_set_mark_ignored_mask_locked(fsn_mark, tmask);
}
*destroy = !(fsn_mark->mask | fsn_mark->ignored_mask);
@@ -568,20 +575,21 @@ static __u32 fanotify_mark_add_to_mask(struct 
fsnotify_mark *fsn_mark,
 
spin_lock(&fsn_mark->lock);
if (!(flags & FAN_MARK_IGNORED_MASK)) {
+   __u32 tmask = fsn_mark->mask | mask;
+   if (flags & FAN_MARK_ONDIR)
+   tmask |= FAN_ONDIR;
+
oldmask = fsn_mark->mask;
-   fsnotify_set_mark_mask_locked(fsn_mark, (oldmask | mask));
+   fsnotify_set_mark_mask_locked(fsn_mark, tmask);
} else {
__u32 tmask = fsn_mark->ignored_mask | mask;
+   if (flags & FAN_MARK_ONDIR)
+   tmask |= FAN_ONDIR;
+
fsnotify_set_mark_ignored_mask_locked(fsn_mark, tmask);
if (flags & FAN_MARK_IGNORED_SURV_MODIFY)
fsn_mark->flags |= 
FSNOTIFY_MARK_FLAG_IGNORED_SURV_MODIFY;
}
-
-   if (!(flags & FAN_MARK_ONDIR)) {
-   __u32 tmask = fsn_mark->ignored_mask | FAN_ONDIR;
-   fsnotify_set_mark_ignored_mask_locked(fsn_mark, tmask);
-   }
-
spin_unlock(&fsn_mark->lock);
 
return mask & ~oldmask;
-- 
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/

[PATCH v3 1/3] fanotify: only destroy mark when both mask and ignored_mask are cleared

[Lino Sanfilippo]

In fanotify_mark_remove_from_mask() a mark is destroyed if only one of both
bitmasks (mask or ignored_mask) of a mark is cleared. However the other mask
may still be set and contain information that should not be lost. So only
destroy a mark if both masks are cleared.

Signed-off-by: Lino Sanfilippo 
Reviewed-by: Jan Kara 
---
 fs/notify/fanotify/fanotify_user.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/notify/fanotify/fanotify_user.c 
b/fs/notify/fanotify/fanotify_user.c
index c991616..ba31055 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -497,10 +497,9 @@ static __u32 fanotify_mark_remove_from_mask(struct 
fsnotify_mark *fsn_mark,
oldmask = fsn_mark->ignored_mask;
fsnotify_set_mark_ignored_mask_locked(fsn_mark, (oldmask & 
~mask));
}
+   *destroy = !(fsn_mark->mask | fsn_mark->ignored_mask);
spin_unlock(&fsn_mark->lock);
 
-   *destroy = !(oldmask & ~mask);
-
return mask & oldmask;
 }
 
-- 
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/

Vorgeschlagene Finanzdarlehen...

[nicole dulac]

Vorgeschlagene Finanzdarlehen
Ich bin ein und bietet privater Investor Raha Darlehen für alle
Personen, zu haben und gute Manieren in der Lage, mit einem Zinssatz
von und 3% einer von Laufzeit 1-30 aastat zurück, von der abhängig
gewünschten Menge.
Ich will meine Brüder und einfach nur Schwestern surevad finanziellen
Schwierigkeiten sind, und sind von den Banken Daher für weitere
Informationen zu helfen abgelehnt, kontaktieren saatke mulle bitte kohta
E-Mail: nicoledula...@gmail.com
PS: Ich werde auch zu geben Meinen Vollen Namen, ist nichts verborgen,
Weil ich mit Vertrauen und Ehrlichkeit. In Wartestellung ...
nicoledula...@gmail.com
nicoledula...@gmail.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: N900: fixing MMC at boot

[Pali Rohár]

On Saturday 06 December 2014 19:04:29 Pavel Machek wrote:
> On Sat 2014-12-06 18:40:16, Pali Rohár wrote:
> > On Saturday 06 December 2014 18:35:27 Pavel Machek wrote:
> > > Hi!
> > > 
> > > For a long time, MMC was not working during boot...
> > > (making the box unusable without nfsroot). It seems
> > > problem is in the regulators, because with diff below, I
> > > was able to mount root on SD card for a first time ... in
> > > a long time.
> > 
> > Hi, do you mean external SD card or internal eMMC (MyDocs)?
> 
> I mean u-SD card. But it is strange. I reverted the patch now,
> and it still works. Not sure why or what I've done
> differently.
> 
>   Pavel

Remove battery wait some time and try again. Maybe you configured 
something which can be cleared only after full device shutdown...

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Make it clear that cache-l2x0 handles L310 cache controller, too

[Pavel Machek]

It is not clear from the filename, and comment at the begining adds to
the confusion by not listing L310. Fix it.

Signed-off-by: Pavel Machek 

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 5e65ca8..b07cc54 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1,5 +1,5 @@
 /*
- * arch/arm/mm/cache-l2x0.c - L210/L220 cache controller support
+ * arch/arm/mm/cache-l2x0.c - L210/L220/L310 cache controller support
  *
  * Copyright (C) 2007 ARM Limited
  *

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: N900: fixing MMC at boot

[Pavel Machek]

On Sat 2014-12-06 18:40:16, Pali Rohár wrote:
> On Saturday 06 December 2014 18:35:27 Pavel Machek wrote:
> > Hi!
> > 
> > For a long time, MMC was not working during boot... (making
> > the box unusable without nfsroot). It seems problem is in the
> > regulators, because with diff below, I was able to mount root
> > on SD card for a first time ... in a long time.
> > 
> 
> Hi, do you mean external SD card or internal eMMC (MyDocs)?

I mean u-SD card. But it is strange. I reverted the patch now, and it
still works. Not sure why or what I've done differently.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 00/25] 2.6.32.65-longterm review

[Willy Tarreau]

This is the start of the longterm review cycle for the 2.6.32.65 release.
All patches will be posted as a response to this one. If anyone has any
issue with these being applied, please let me know. If anyone is a
maintainer of the proper subsystem, and wants to add a Signed-off-by: line
to the patch, please respond with it.

Responses should be made by Fri Dec 12 12:00:00 CET 2014.
Anything received after that time might be too late. If someone
wants a bit more time for a deeper review, please let me know.

The whole patch series can be found in one patch at :
 kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.32.65-rc1.gz

The shortlog and diffstat are appended below.

Thanks,
Willy

===

Andy Lutomirski (4):
  x86_64/entry/xen: Do not invoke espfix64 on Xen
  x86_64, traps: Stop using IST for #SS
  x86_64, traps: Fix the espfix64 #DF fixup and rewrite it in C
  x86_64, traps: Rework bad_iret

Boris Ostrovsky (1):
  x86/espfix/xen: Fix allocation of pages for paravirt page tables

Brian Gerst (1):
  x86, 64-bit: Move K8 B step iret fixup to fault entry asm

Dan Carpenter (1):
  ttusb-dec: buffer overflow in ioctl

Daniel Borkmann (3):
  net: sctp: fix panic on duplicate ASCONF chunks
  net: sctp: fix remote memory pressure from excessive queueing
  net: sctp: fix NULL pointer dereference in af->from_addr_param on 
malformed packet

H. Peter Anvin (7):
  x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
  x86-32, espfix: Remove filter for espfix32 due to race
  x86-64, espfix: Don't leak bits 31:16 of %esp returning to 16-bit stack
  x86, espfix: Move espfix definitions into a separate header file
  x86, espfix: Fix broken header guard
  x86, espfix: Make espfix64 a Kconfig option, fix UML
  x86, espfix: Make it possible to disable 16-bit support

James Forshaw (1):
  USB: whiteheat: Added bounds checking for bulk command response

Jan Beulich (1):
  x86-64: Adjust frame type at paranoid_exit:

Jan Kara (1):
  udf: Avoid infinite loop when processing indirect ICBs

Johannes Berg (1):
  mac80211: fix fragmentation code, particularly for encryption

Lars-Peter Clausen (2):
  ALSA: control: Don't access controls outside of protected regions
  ALSA: control: Fix replacing user controls

Sasha Levin (1):
  net/l2tp: don't fall back on UDP [get|set]sockopt

Willy Tarreau (1):
  net: sendmsg: fix failed backport of "fix NULL pointer dereference"

 Documentation/x86/x86_64/mm.txt  |  2 +
 arch/x86/Kconfig | 25 ++--
 arch/x86/include/asm/irqflags.h  |  2 +-
 arch/x86/include/asm/page_32_types.h |  1 -
 arch/x86/include/asm/page_64_types.h | 11 ++--
 arch/x86/include/asm/pgtable_64_types.h  |  2 +
 arch/x86/include/asm/setup.h |  2 +
 arch/x86/include/asm/uaccess.h   |  1 -
 arch/x86/kernel/Makefile |  1 +
 arch/x86/kernel/dumpstack_64.c   |  1 -
 arch/x86/kernel/entry_32.S   | 17 --
 arch/x86/kernel/entry_64.S   | 98 
 arch/x86/kernel/ldt.c|  6 ++
 arch/x86/kernel/paravirt_patch_64.c  |  2 -
 arch/x86/kernel/smpboot.c|  7 +++
 arch/x86/kernel/traps.c  | 67 +-
 arch/x86/mm/dump_pagetables.c| 38 +
 arch/x86/mm/extable.c| 31 --
 drivers/media/dvb/ttusb-dec/ttusbdecfe.c |  3 +
 drivers/net/pppol2tp.c   |  4 +-
 drivers/usb/serial/whiteheat.c   |  7 ++-
 fs/udf/inode.c   | 35 +++-
 include/net/sctp/sctp.h  |  5 ++
 init/main.c  |  4 ++
 net/compat.c |  2 +-
 net/mac80211/tx.c|  2 +-
 net/sctp/associola.c |  2 +
 net/sctp/inqueue.c   | 33 +++
 net/sctp/sm_make_chunk.c |  3 +
 net/sctp/sm_statefuns.c  |  3 +
 sound/core/control.c | 31 +-
 31 files changed, 274 insertions(+), 174 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/

[ 19/25] USB: whiteheat: Added bounds checking for bulk command response

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: James Forshaw 

commit c5fd4126151855330280ea9382684980afcfdd03 upstream

This patch fixes a potential security issue in the whiteheat USB driver
which might allow a local attacker to cause kernel memory corrpution. This
is due to an unchecked memcpy into a fixed size buffer (of 64 bytes). On
EHCI and XHCI busses it's possible to craft responses greater than 64
bytes leading a buffer overflow.

Signed-off-by: James Forshaw 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
(backported from commit 6817ae225cd650fb1c3295d769298c38b1eba818)
CVE-2014-3185
BugLink: http://bugs.launchpad.net/bugs/1370036
Signed-off-by: Luis Henriques 
Signed-off-by: Tim Gardner 
Signed-off-by: Willy Tarreau 
---
 drivers/usb/serial/whiteheat.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/whiteheat.c b/drivers/usb/serial/whiteheat.c
index 1247be1..748c627 100644
--- a/drivers/usb/serial/whiteheat.c
+++ b/drivers/usb/serial/whiteheat.c
@@ -1012,6 +1012,10 @@ static void command_port_read_callback(struct urb *urb)
dbg("%s - command_info is NULL, exiting.", __func__);
return;
}
+   if (!urb->actual_length) {
+   dev_dbg(&urb->dev->dev, "%s - empty response, exiting.\n", 
__func__);
+   return;
+   }
if (status) {
dbg("%s - nonzero urb status: %d", __func__, status);
if (status != -ENOENT)
@@ -1033,7 +1037,8 @@ static void command_port_read_callback(struct urb *urb)
/* These are unsolicited reports from the firmware, hence no
   waiting command to wakeup */
dbg("%s - event received", __func__);
-   } else if (data[0] == WHITEHEAT_GET_DTR_RTS) {
+   } else if ((data[0] == WHITEHEAT_GET_DTR_RTS) &&
+   (urb->actual_length - 1 <= 
sizeof(command_info->result_buffer))) {
memcpy(command_info->result_buffer, &data[1],
urb->actual_length - 1);
command_info->command_finished = WHITEHEAT_CMD_COMPLETE;
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 09/25] x86, espfix: Make espfix64 a Kconfig option, fix UML

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: "H. Peter Anvin" 

commit 197725de65477bc8509b41388157c1a2283542bb upstream.

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

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

Reported-by: Ingo Molnar 
Signed-off-by: H. Peter Anvin 
Cc: Richard Weinberger 
Link: 
http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
(cherry picked from 3.2 commit da22646d97b7322c757f3a7a21805a3475fed231)
Signed-off-by: Willy Tarreau 
---
 arch/x86/Kconfig  | 4 
 arch/x86/kernel/Makefile  | 2 +-
 arch/x86/kernel/smpboot.c | 2 +-
 init/main.c   | 2 +-
 4 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ee0168d..026fe60 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -887,6 +887,10 @@ config VM86
  XFree86 to initialize some video cards via BIOS. Disabling this
  option saves about 6k.
 
+config X86_ESPFIX64
+   def_bool y
+   depends on X86_64
+
 config TOSHIBA
tristate "Toshiba Laptop support"
depends on X86_32
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index f58fd89..945ad6f 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -40,7 +40,7 @@ obj-$(CONFIG_X86_32)  += probe_roms_32.o
 obj-$(CONFIG_X86_32)   += sys_i386_32.o i386_ksyms_32.o
 obj-$(CONFIG_X86_64)   += sys_x86_64.o x8664_ksyms_64.o
 obj-$(CONFIG_X86_64)   += syscall_64.o vsyscall_64.o
-obj-$(CONFIG_X86_64)   += espfix_64.o
+obj-$(CONFIG_X86_ESPFIX64) += espfix_64.o
 obj-y  += bootflag.o e820.o
 obj-y  += pci-dma.o quirks.o i8237.o topology.o kdebugfs.o
 obj-y  += alternative.o i8253.o pci-nommu.o
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 0854448..ca6b3f9 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -328,7 +328,7 @@ notrace static void __cpuinit start_secondary(void *unused)
/*
 * Enable the espfix hack for this CPU
 */
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_X86_ESPFIX64
init_espfix_ap();
 #endif
 
diff --git a/init/main.c b/init/main.c
index 0dfcc1a..00e6286 100644
--- a/init/main.c
+++ b/init/main.c
@@ -659,7 +659,7 @@ asmlinkage void __init start_kernel(void)
if (efi_enabled)
efi_enter_virtual_mode();
 #endif
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_X86_ESPFIX64
/* Should be run before the first non-init thread is created */
init_espfix_bsp();
 #endif
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 10/25] x86, espfix: Make it possible to disable 16-bit support

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: "H. Peter Anvin" 

commit 34273f41d57ee8d854dcd2a1d754cbb546cb548f upstream.

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

Signed-off-by: H. Peter Anvin 
Link: 
http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
(cherry picked from 3.2 commit 70d87cbbd92a3611655b39003176ee1033796bf7)
[wt: backport notes for 2.6.32 :
  - Fixed arch/x86/kernel/ldt.c (no IS_ENABLED on 2.6.32).
  - No CONFIG_EXPERT condition in 2.6.32.
/wt]
Signed-off-by: Willy Tarreau 
---
 arch/x86/Kconfig   | 23 ++-
 arch/x86/kernel/entry_32.S | 12 
 arch/x86/kernel/entry_64.S |  8 
 arch/x86/kernel/ldt.c  |  6 ++
 4 files changed, 44 insertions(+), 5 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 026fe60..67c3187 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -882,14 +882,27 @@ config VM86
default y
depends on X86_32
---help---
- This option is required by programs like DOSEMU to run 16-bit legacy
- code on X86 processors. It also may be needed by software like
- XFree86 to initialize some video cards via BIOS. Disabling this
- option saves about 6k.
+ This option is required by programs like DOSEMU to run
+ 16-bit real mode legacy code on x86 processors. It also may
+ be needed by software like XFree86 to initialize some video
+ cards via BIOS. Disabling this option saves about 6K.
+
+config X86_16BIT
+   bool "Enable support for 16-bit segments"
+   default y
+   ---help---
+ This option is required by programs like Wine to run 16-bit
+ protected mode legacy code on x86 processors.  Disabling
+ this option saves about 300 bytes on i386, or around 6K text
+ plus 16K runtime memory on x86-64,
+
+config X86_ESPFIX32
+   def_bool y
+   depends on X86_16BIT && X86_32
 
 config X86_ESPFIX64
def_bool y
-   depends on X86_64
+   depends on X86_16BIT && X86_64
 
 config TOSHIBA
tristate "Toshiba Laptop support"
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index db7dbe7..c1207f7 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -543,6 +543,7 @@ syscall_exit:
 restore_all:
TRACE_IRQS_IRET
 restore_all_notrace:
+#ifdef CONFIG_X86_ESPFIX32
movl PT_EFLAGS(%esp), %eax  # mix EFLAGS, SS and CS
# Warning: PT_OLDSS(%esp) contains the wrong/random values if we
# are returning to the kernel.
@@ -553,6 +554,7 @@ restore_all_notrace:
cmpl $((SEGMENT_LDT << 8) | USER_RPL), %eax
CFI_REMEMBER_STATE
je ldt_ss   # returning to user-space with LDT SS
+#endif
 restore_nocheck:
RESTORE_REGS 4  # skip orig_eax/error_code
CFI_ADJUST_CFA_OFFSET -4
@@ -569,6 +571,7 @@ ENTRY(iret_exc)
.long irq_return,iret_exc
 .previous
 
+#ifdef CONFIG_X86_ESPFIX32
CFI_RESTORE_STATE
 ldt_ss:
 #ifdef CONFIG_PARAVIRT
@@ -614,6 +617,7 @@ ldt_ss:
lss (%esp), %esp/* switch to espfix segment */
CFI_ADJUST_CFA_OFFSET -8
jmp restore_nocheck
+#endif
CFI_ENDPROC
 ENDPROC(system_call)
 
@@ -736,6 +740,7 @@ PTREGSCALL(vm86old)
  * the high word of the segment base from the GDT and swiches to the
  * normal stack and adjusts ESP with the matching offset.
  */
+#ifdef CONFIG_X86_ESPFIX32
/* fixup the stack */
PER_CPU(gdt_page, %ebx)
mov GDT_ENTRY_ESPFIX_SS * 8 + 4(%ebx), %al /* bits 16..23 */
@@ -748,8 +753,10 @@ PTREGSCALL(vm86old)
CFI_ADJUST_CFA_OFFSET 4
lss (%esp), %esp/* switch to the normal stack segment */
CFI_ADJUST_CFA_OFFSET -8
+#endif
 .endm
 .macro UNWIND_ESPFIX_STACK
+#ifdef CONFIG_X86_ESPFIX32
movl %ss, %eax
/* see if on espfix stack */
cmpw $__ESPFIX_SS, %ax
@@ -760,6 +767,7 @@ PTREGSCALL(vm86old)
/* switch to normal stack */
FIXUP_ESPFIX_STACK
 27:
+#endif
 .endm
 
 /*
@@ -1323,6 +1331,7 @@ END(debug)
  */
 ENTRY(nmi)
RING0_INT_FRAME
+#ifdef CONFIG_X86_ESPFIX32
pushl %eax
CFI_ADJUST_CFA_OFFSET 4
movl %ss, %eax
@@ -1330,6 +1339,7 @@ ENTRY(nmi)
popl %eax
CFI_ADJUST_CFA_OFFSET -4
je nmi_espfix_stack
+#endif
cmpl $ia32_sysenter_target,(%esp)
je nmi_stack_fixup
pushl %eax
@@ -1372,6 +1382,7 @@ nmi_debug_stack_check:
FIX_STACK 24, nmi_stack_correct, 1
jmp nmi_stack_correct
 
+#ifdef CONFIG_X86_ESPFIX32
 nmi_espfix_stack:
/* We have a RING0_INT_FRAME here.

[ 16/25] net/l2tp: dont fall back on UDP [get|set]sockopt

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Sasha Levin 

(commit 3cf521f7dc87c031617fd47e4b7aa2593c2f3daf upstream)

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

As David Miller points out:

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

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

Reported-by: Sasha Levin 
Acked-by: James Chapman 
Acked-by: David Miller 
Cc: Phil Turnbull 
Cc: Vegard Nossum 
Cc: Willy Tarreau 
Cc: sta...@vger.kernel.org
Signed-off-by: Linus Torvalds 

[geissert: adjust file paths and context for 2.6.32]
[wt: fixes CVE-2014-4943]
Signed-off-by: Willy Tarreau 
---
 drivers/net/pppol2tp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/pppol2tp.c b/drivers/net/pppol2tp.c
index 4cdc1cf..4c8f019 100644
--- a/drivers/net/pppol2tp.c
+++ b/drivers/net/pppol2tp.c
@@ -2190,7 +2190,7 @@ static int pppol2tp_setsockopt(struct socket *sock, int 
level, int optname,
int err;
 
if (level != SOL_PPPOL2TP)
-   return udp_prot.setsockopt(sk, level, optname, optval, optlen);
+   return -EINVAL;
 
if (optlen < sizeof(int))
return -EINVAL;
@@ -2314,7 +2314,7 @@ static int pppol2tp_getsockopt(struct socket *sock, int 
level,
int err;
 
if (level != SOL_PPPOL2TP)
-   return udp_prot.getsockopt(sk, level, optname, optval, optlen);
+   return -EINVAL;
 
if (get_user(len, (int __user *) optlen))
return -EFAULT;
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 02/25] x86, 64-bit: Move K8 B step iret fixup to fault entry asm

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Brian Gerst 

Move the handling of truncated %rip from an iret fault to the fault
entry path.

This allows x86-64 to use the standard search_extable() function.

Signed-off-by: Brian Gerst 
Cc: Linus Torvalds 
Cc: Jan Beulich 
LKML-Reference: <1255357103-5418-1-git-send-email-brge...@gmail.com>
Signed-off-by: Ingo Molnar 
(cherry picked from commit ae24ffe5ecec17c956ac25371d7c2e12b4b36e53)
[wt: only merged to fix patch context and ease merging of next patches]
Signed-off-by: Willy Tarreau 
---
 arch/x86/include/asm/uaccess.h |  1 -
 arch/x86/kernel/entry_64.S | 11 ---
 arch/x86/mm/extable.c  | 31 ---
 3 files changed, 8 insertions(+), 35 deletions(-)

diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 61c5874..99f0ad7 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -570,7 +570,6 @@ extern struct movsl_mask {
 #ifdef CONFIG_X86_32
 # include "uaccess_32.h"
 #else
-# define ARCH_HAS_SEARCH_EXTABLE
 # include "uaccess_64.h"
 #endif
 
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 34a56a9..4f577eb 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1491,12 +1491,17 @@ error_kernelspace:
leaq irq_return(%rip),%rcx
cmpq %rcx,RIP+8(%rsp)
je error_swapgs
-   movl %ecx,%ecx  /* zero extend */
-   cmpq %rcx,RIP+8(%rsp)
-   je error_swapgs
+   movl %ecx,%eax  /* zero extend */
+   cmpq %rax,RIP+8(%rsp)
+   je bstep_iret
cmpq $gs_change,RIP+8(%rsp)
je error_swapgs
jmp error_sti
+
+bstep_iret:
+   /* Fix truncated RIP */
+   movq %rcx,RIP+8(%rsp)
+   je error_swapgs
 END(error_entry)
 
 
diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index 61b41ca..d0474ad 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -35,34 +35,3 @@ int fixup_exception(struct pt_regs *regs)
 
return 0;
 }
-
-#ifdef CONFIG_X86_64
-/*
- * Need to defined our own search_extable on X86_64 to work around
- * a B stepping K8 bug.
- */
-const struct exception_table_entry *
-search_extable(const struct exception_table_entry *first,
-  const struct exception_table_entry *last,
-  unsigned long value)
-{
-   /* B stepping K8 bug */
-   if ((value >> 32) == 0)
-   value |= 0xUL << 32;
-
-   while (first <= last) {
-   const struct exception_table_entry *mid;
-   long diff;
-
-   mid = (last - first) / 2 + first;
-   diff = mid->insn - value;
-   if (diff == 0)
-   return mid;
-   else if (diff < 0)
-   first = mid+1;
-   else
-   last = mid-1;
-   }
-   return NULL;
-}
-#endif
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 05/25] x86-32, espfix: Remove filter for espfix32 due to race

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: "H. Peter Anvin" 

commit 246f2d2ee1d715e1077fc47d61c394569c8ee692 upstream.

It is not safe to use LAR to filter when to go down the espfix path,
because the LDT is per-process (rather than per-thread) and another
thread might change the descriptors behind our back.  Fortunately it
is always *safe* (if a bit slow) to go down the espfix path, and a
32-bit LDT stack segment is extremely rare.

Signed-off-by: H. Peter Anvin 
Link: 
http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-...@linux.intel.com
Signed-off-by: Ben Hutchings 
(cherry picked from 3.2 commit 6806fa8b6795aba9be8742a8f598f60eed26f875)
Signed-off-by: Willy Tarreau 
---
 arch/x86/kernel/entry_32.S | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 8b5370c..db7dbe7 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -571,11 +571,6 @@ ENTRY(iret_exc)
 
CFI_RESTORE_STATE
 ldt_ss:
-   larl PT_OLDSS(%esp), %eax
-   jnz restore_nocheck
-   testl $0x0040, %eax # returning to 32bit stack?
-   jnz restore_nocheck # allright, normal return
-
 #ifdef CONFIG_PARAVIRT
/*
 * The kernel can't run on a non-flat stack if paravirt mode
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 24/25] mac80211: fix fragmentation code, particularly for encryption

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Johannes Berg 

commit a722a419815ed203b519151f9556859ff256638b upstream

The "new" fragmentation code (since my rewrite almost 5 years ago)
erroneously sets skb->len rather than using skb_trim() to adjust
the length of the first fragment after copying out all the others.
This leaves the skb tail pointer pointing to after where the data
originally ended, and thus causes the encryption MIC to be written
at that point, rather than where it belongs: immediately after the
data.

The impact of this is that if software encryption is done, then
 a) encryption doesn't work for the first fragment, the connection
becomes unusable as the first fragment will never be properly
verified at the receiver, the MIC is practically guaranteed to
be wrong
 b) we leak up to 8 bytes of plaintext (!) of the packet out into
the air

This is only mitigated by the fact that many devices are capable
of doing encryption in hardware, in which case this can't happen
as the tail pointer is irrelevant in that case. Additionally,
fragmentation is not used very frequently and would normally have
to be configured manually.

Fix this by using skb_trim() properly.

Cc: sta...@vger.kernel.org
Fixes: 2de8e0d999b8 ("mac80211: rewrite fragmentation")
Reported-by: Jouni Malinen 
Signed-off-by: Johannes Berg 
(backported from commit 338f977f4eb441e69bb9a46eaa0ac715c931a67f)
CVE-2014-8709
BugLink: http://bugs.launchpad.net/bugs/1392013
Signed-off-by: Luis Henriques 
Acked-by: Andy Whitcroft 
Acked-by: Stefan Bader 
Signed-off-by: Andy Whitcroft 
Signed-off-by: Willy Tarreau 
---
 net/mac80211/tx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index b1d7904..687fc8e 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -770,7 +770,7 @@ static int ieee80211_fragment(struct ieee80211_local *local,
pos += fraglen;
}
 
-   skb->len = hdrlen + per_fragm;
+   skb_trim(skb, hdrlen + per_fragm);
return 0;
 }
 
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 25/25] ttusb-dec: buffer overflow in ioctl

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Dan Carpenter 

commit dc0ab1ddeb0c5f5eb3f37a72eadb394792b3c40d upstream

We need to add a limit check here so we don't overflow the buffer.

Signed-off-by: Dan Carpenter 
Signed-off-by: Mauro Carvalho Chehab 
(backported from commit f2e323ec96077642d397bb1c355def536d489d16)
CVE-2014-8884
BugLink: http://bugs.launchpad.net/bugs/1395187
Signed-off-by: Luis Henriques 
Acked-by: Andy Whitcroft 
Signed-off-by: Andy Whitcroft 
Acked-by: Stefan Bader 
Signed-off-by: Willy Tarreau 
---
 drivers/media/dvb/ttusb-dec/ttusbdecfe.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/dvb/ttusb-dec/ttusbdecfe.c 
b/drivers/media/dvb/ttusb-dec/ttusbdecfe.c
index 21260aa..852870b 100644
--- a/drivers/media/dvb/ttusb-dec/ttusbdecfe.c
+++ b/drivers/media/dvb/ttusb-dec/ttusbdecfe.c
@@ -154,6 +154,9 @@ static int ttusbdecfe_dvbs_diseqc_send_master_cmd(struct 
dvb_frontend* fe, struc
   0x00, 0x00, 0x00, 0x00,
   0x00, 0x00 };
 
+   if (cmd->msg_len > sizeof(b) - 4)
+   return -EINVAL;
+
memcpy(&b[4], cmd->msg, cmd->msg_len);
 
state->config->send_command(fe, 0x72,
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 23/25] net: sctp: fix NULL pointer dereference in af->from_addr_param on malformed packet

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Daniel Borkmann 

commit a6e1af6f5e9e75095ae1b004f6f00082e5fc4d2d upstream

An SCTP server doing ASCONF will panic on malformed INIT ping-of-death
in the form of:

   INIT[PARAM: SET_PRIMARY_IP] >

While the INIT chunk parameter verification dissects through many things
in order to detect malformed input, it misses to actually check parameters
inside of parameters. E.g. RFC5061, section 4.2.4 proposes a 'set primary
IP address' parameter in ASCONF, which has as a subparameter an address
parameter.

So an attacker may send a parameter type other than SCTP_PARAM_IPV4_ADDRESS
or SCTP_PARAM_IPV6_ADDRESS, param_type2af() will subsequently return 0
and thus sctp_get_af_specific() returns NULL, too, which we then happily
dereference unconditionally through af->from_addr_param().

The trace for the log:

BUG: unable to handle kernel NULL pointer dereference at 0078
IP: [] sctp_process_init+0x492/0x990 [sctp]
PGD 0
Oops:  [#1] SMP
[...]
Pid: 0, comm: swapper Not tainted 2.6.32-504.el6.x86_64 #1 Bochs Bochs
RIP: 0010:[]  [] 
sctp_process_init+0x492/0x990 [sctp]
[...]
Call Trace:
 
 [] ? sctp_bind_addr_copy+0x5d/0xe0 [sctp]
 [] sctp_sf_do_5_1B_init+0x21b/0x340 [sctp]
 [] sctp_do_sm+0x71/0x1210 [sctp]
 [] ? sctp_endpoint_lookup_assoc+0xc9/0xf0 [sctp]
 [] sctp_endpoint_bh_rcv+0x116/0x230 [sctp]
 [] sctp_inq_push+0x56/0x80 [sctp]
 [] sctp_rcv+0x982/0xa10 [sctp]
 [] ? ipt_local_in_hook+0x23/0x28 [iptable_filter]
 [] ? nf_iterate+0x69/0xb0
 [] ? ip_local_deliver_finish+0x0/0x2d0
 [] ? nf_hook_slow+0x76/0x120
 [] ? ip_local_deliver_finish+0x0/0x2d0
[...]

A minimal way to address this is to check for NULL as we do on all
other such occasions where we know sctp_get_af_specific() could
possibly return with NULL.

Fixes: d6de3097592b ("[SCTP]: Add the handling of "Set Primary IP Address" 
parameter to INIT")
Signed-off-by: Daniel Borkmann 
Cc: Vlad Yasevich 
Acked-by: Neil Horman 
Signed-off-by: David S. Miller 
(cherry picked from commit e40607cbe270a9e8360907cb1e62ddf0736e4864)
CVE-2014-7841
BugLink: http://bugs.launchpad.net/bugs/1392820
Signed-off-by: Luis Henriques 
Acked-by: Andy Whitcroft 
Acked-by: Stefan Bader 
Signed-off-by: Andy Whitcroft 
Signed-off-by: Willy Tarreau 
---
 net/sctp/sm_make_chunk.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 5f2dc3f..9de3592 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -2544,6 +2544,9 @@ do_addr_param:
addr_param = param.v + sizeof(sctp_addip_param_t);
 
af = sctp_get_af_specific(param_type2af(param.p->type));
+   if (af == NULL)
+   break;
+
af->from_addr_param(&addr, addr_param,
htons(asoc->peer.port), 0);
 
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 22/25] udf: Avoid infinite loop when processing indirect ICBs

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara 

commit 541d302ee5c46336cbad333222bc278b76cc1c42 upstream

We did not implement any bound on number of indirect ICBs we follow when
loading inode. Thus corrupted medium could cause kernel to go into an
infinite loop, possibly causing a stack overflow.

Fix the possible stack overflow by removing recursion from
__udf_read_inode() and limit number of indirect ICBs we follow to avoid
infinite loops.

Signed-off-by: Jan Kara 
(back ported from commit c03aa9f6e1f938618e6db2e23afef0574efeeb65)
[ luis: adjusted context and replaced udf_err() by printk() ]
CVE-2014-6410
BugLink: http://bugs.launchpad.net/bugs/1370042
Signed-off-by: Luis Henriques 
Signed-off-by: Tim Gardner 
Signed-off-by: Willy Tarreau 
---
 fs/udf/inode.c | 35 +--
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 3c4ffb2..11c291e 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1062,13 +1062,22 @@ void udf_truncate(struct inode *inode)
unlock_kernel();
 }
 
+/*
+ * Maximum length of linked list formed by ICB hierarchy. The chosen number is
+ * arbitrary - just that we hopefully don't limit any real use of rewritten
+ * inode on write-once media but avoid looping for too long on corrupted media.
+ */
+#define UDF_MAX_ICB_NESTING 1024
+
 static void __udf_read_inode(struct inode *inode)
 {
struct buffer_head *bh = NULL;
struct fileEntry *fe;
uint16_t ident;
struct udf_inode_info *iinfo = UDF_I(inode);
+   unsigned int indirections = 0;
 
+reread:
/*
 * Set defaults, but the inode is still incomplete!
 * Note: get_new_inode() sets the following on a new inode:
@@ -1106,28 +1115,26 @@ static void __udf_read_inode(struct inode *inode)
ibh = udf_read_ptagged(inode->i_sb, &iinfo->i_location, 1,
&ident);
if (ident == TAG_IDENT_IE && ibh) {
-   struct buffer_head *nbh = NULL;
struct kernel_lb_addr loc;
struct indirectEntry *ie;
 
ie = (struct indirectEntry *)ibh->b_data;
loc = lelb_to_cpu(ie->indirectICB.extLocation);
 
-   if (ie->indirectICB.extLength &&
-   (nbh = udf_read_ptagged(inode->i_sb, &loc, 0,
-   &ident))) {
-   if (ident == TAG_IDENT_FE ||
-   ident == TAG_IDENT_EFE) {
-   memcpy(&iinfo->i_location,
-   &loc,
-   sizeof(struct kernel_lb_addr));
-   brelse(bh);
-   brelse(ibh);
-   brelse(nbh);
-   __udf_read_inode(inode);
+   if (ie->indirectICB.extLength) {
+   brelse(bh);
+   brelse(ibh);
+   memcpy(&iinfo->i_location, &loc,
+  sizeof(struct kernel_lb_addr));
+   if (++indirections > UDF_MAX_ICB_NESTING) {
+   printk(KERN_ERR "udf: "
+   "too many ICBs in ICB hierarchy"
+   " (max %d supported)\n",
+   UDF_MAX_ICB_NESTING);
+   make_bad_inode(inode);
return;
}
-   brelse(nbh);
+   goto reread;
}
}
brelse(ibh);
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 18/25] ALSA: control: Fix replacing user controls

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Lars-Peter Clausen 

(commit 82262a46627bebb0febcc26664746c25cef08563 upstream)

There are two issues with the current implementation for replacing user
controls. The first is that the code does not check if the control is actually a
user control and neither does it check if the control is owned by the process
that tries to remove it. That allows userspace applications to remove arbitrary
controls, which can cause a user after free if a for example a driver does not
expect a control to be removed from under its feed.

The second issue is that on one hand when a control is replaced the
user_ctl_count limit is not checked and on the other hand the user_ctl_count is
increased (even though the number of user controls does not change). This allows
userspace, once the user_ctl_count limit as been reached, to repeatedly replace
a control until user_ctl_count overflows. Once that happens new controls can be
added effectively bypassing the user_ctl_count limit.

Both issues can be fixed by instead of open-coding the removal of the control
that is to be replaced to use snd_ctl_remove_user_ctl(). This function does
proper permission checks as well as decrements user_ctl_count after the control
has been removed.

Note that by using snd_ctl_remove_user_ctl() the check which returns -EBUSY at
beginning of the function if the control already exists is removed. This is not
a problem though since the check is quite useless, because the lock that is
protecting the control list is released between the check and before adding the
new control to the list, which means that it is possible that a different
control with the same settings is added to the list after the check. Luckily
there is another check that is done while holding the lock in snd_ctl_add(), so
we'll rely on that to make sure that the same control is not added twice.

Signed-off-by: Lars-Peter Clausen 
Acked-by: Jaroslav Kysela 
Cc: 
Signed-off-by: Takashi Iwai 
[wt: fixes CVE-2014-4654 & CVE-2014-4655]
Signed-off-by: Willy Tarreau 
---
 sound/core/control.c | 23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/sound/core/control.c b/sound/core/control.c
index e91d79a..ffa7857 100644
--- a/sound/core/control.c
+++ b/sound/core/control.c
@@ -999,21 +999,16 @@ static int snd_ctl_elem_add(struct snd_ctl_file *file,
 SNDRV_CTL_ELEM_ACCESS_TLV_READWRITE));
info->id.numid = 0;
memset(&kctl, 0, sizeof(kctl));
-   down_write(&card->controls_rwsem);
-   _kctl = snd_ctl_find_id(card, &info->id);
-   err = 0;
-   if (_kctl) {
-   if (replace)
-   err = snd_ctl_remove(card, _kctl);
-   else
-   err = -EBUSY;
-   } else {
-   if (replace)
-   err = -ENOENT;
+
+   if (replace) {
+   err = snd_ctl_remove_user_ctl(file, &info->id);
+   if (err)
+   return err;
}
-   up_write(&card->controls_rwsem);
-   if (err < 0)
-   return err;
+
+   if (card->user_ctl_count >= MAX_USER_CONTROLS)
+   return -ENOMEM;
+
memcpy(&kctl.id, &info->id, sizeof(info->id));
kctl.count = info->owner ? info->owner : 1;
access |= SNDRV_CTL_ELEM_ACCESS_USER;
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 11/25] x86_64/entry/xen: Do not invoke espfix64 on Xen

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Andy Lutomirski 

commit 7209a75d2009dbf7745e2fd354abf25c3deb3ca3 upstream.

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

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

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

Signed-off-by: Andy Lutomirski 
Link: 
http://lkml.kernel.org/r/7b8f1d8ef6597cb16ae004a43c56980a7de3cf94.1406129132.git.l...@amacapital.net
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
(cherry picked from 3.2 commit 8ba19cd8c351e16b6be4caca9338d19b0cb8eaa4)
Signed-off-by: Willy Tarreau 
---
 arch/x86/include/asm/irqflags.h |  2 +-
 arch/x86/kernel/entry_64.S  | 31 ++-
 arch/x86/kernel/paravirt_patch_64.c |  2 --
 3 files changed, 11 insertions(+), 24 deletions(-)

diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index 9e2b952..58b0c5c 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -130,7 +130,7 @@ static inline unsigned long __raw_local_irq_save(void)
 
 #define PARAVIRT_ADJUST_EXCEPTION_FRAME/*  */
 
-#define INTERRUPT_RETURN   iretq
+#define INTERRUPT_RETURN   jmp native_iret
 #define USERGS_SYSRET64\
swapgs; \
sysretq;
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index cf9e7d2..4313d48 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -859,33 +859,27 @@ restore_args:
RESTORE_ARGS 0,8,0
 
 irq_return:
+   INTERRUPT_RETURN
+
+ENTRY(native_iret)
/*
 * Are we returning to a stack segment from the LDT?  Note: in
 * 64-bit mode SS:RSP on the exception stack is always valid.
 */
 #ifdef CONFIG_X86_ESPFIX64
testb $4,(SS-RIP)(%rsp)
-   jnz irq_return_ldt
+   jnz native_irq_return_ldt
 #endif
 
-irq_return_iret:
-   INTERRUPT_RETURN
-
-   .section __ex_table, "a"
-   .quad irq_return_iret, bad_iret
-   .previous
-
-#ifdef CONFIG_PARAVIRT
-ENTRY(native_iret)
+native_irq_return_iret:
iretq
 
.section __ex_table,"a"
-   .quad native_iret, bad_iret
+   .quad native_irq_return_iret, bad_iret
.previous
-#endif
 
 #ifdef CONFIG_X86_ESPFIX64
-irq_return_ldt:
+native_irq_return_ldt:
pushq_cfi %rax
pushq_cfi %rdi
SWAPGS
@@ -907,7 +901,7 @@ irq_return_ldt:
SWAPGS
movq %rax,%rsp
popq_cfi %rax
-   jmp irq_return_iret
+   jmp native_irq_return_iret
 #endif
 
.section .fixup,"ax"
@@ -995,13 +989,8 @@ __do_double_fault:
cmpl $__KERNEL_CS,CS(%rdi)
jne do_double_fault
movq RIP(%rdi),%rax
-   cmpq $irq_return_iret,%rax
-#ifdef CONFIG_PARAVIRT
-   je 1f
-   cmpq $native_iret,%rax
-#endif
+   cmpq $native_irq_return_iret,%rax
jne do_double_fault /* This shouldn't happen... */
-1:
movq PER_CPU_VAR(kernel_stack),%rax
subq $(6*8-KERNEL_STACK_OFFSET),%rax/* Reset to original stack */
movq %rax,RSP(%rdi)
@@ -1560,7 +1549,7 @@ error_sti:
  */
 error_kernelspace:
incl %ebx
-   leaq irq_return_iret(%rip),%rcx
+   leaq native_irq_return_iret(%rip),%rcx
cmpq %rcx,RIP+8(%rsp)
je error_swapgs
movl %ecx,%eax  /* zero extend */
diff --git a/arch/x86/kernel/paravirt_patch_64.c 
b/arch/x86/kernel/paravirt_patch_64.c
index 3f08f34..a1da673 100644
--- a/arch/x86/kernel/paravirt_patch_64.c
+++ b/arch/x86/kernel/paravirt_patch_64.c
@@ -6,7 +6,6 @@ DEF_NATIVE(pv_irq_ops, irq_disable, "cli");
 DEF_NATIVE(pv_irq_ops, irq_enable, "sti");
 DEF_NATIVE(pv_irq_ops, restore_fl, "pushq %rdi; popfq");
 DEF_NATIVE(pv_irq_ops, save_fl, "pushfq; popq %rax");
-DEF_NATIVE(pv_cpu_ops, iret, "iretq");
 DEF_NATIVE(pv_mmu_ops, read_cr2, "movq %cr2, %rax");
 DEF_NATIVE(pv_mmu_ops, read_cr3, "movq %cr3, %rax");
 DEF_NATIVE(pv_mmu_ops, write_cr3, "movq %rdi, %cr3");
@@ -50,7 +49,6 @@ unsigned native_patch(u8 type, u16 clobbers, void *ibuf,
PATCH_SITE(pv_irq_ops, save_fl);
PATCH_SITE(pv_irq_ops, irq_enable);
PATCH_SITE(pv_irq_ops, irq_disable);
-   PATCH_SITE(pv_cpu_ops, iret);
PATCH_SITE(pv_cpu_ops, irq_enable_sysexit);
PATCH_SITE(pv_cpu_ops, usergs_sysret32);
PATCH_SITE(pv_cpu_ops, usergs_sysret64);
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess

[ 08/25] x86, espfix: Fix broken header guard

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: "H. Peter Anvin" 

commit 20b68535cd27183ebd3651ff313afb2b97dac941 upstream.

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

Reported-by: Fengguang Wu 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
(cherry picked from 3.2 commit 7d4a9eabfe6c7fed70941aceb3b20bf393652bcb)
Signed-off-by: Willy Tarreau 
---
 arch/x86/include/asm/espfix.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/espfix.h b/arch/x86/include/asm/espfix.h
index e2fb446..f017535 100644
--- a/arch/x86/include/asm/espfix.h
+++ b/arch/x86/include/asm/espfix.h
@@ -1,4 +1,4 @@
-#ifdef _ASM_X86_ESPFIX_H
+#ifndef _ASM_X86_ESPFIX_H
 #define _ASM_X86_ESPFIX_H
 
 #ifdef CONFIG_X86_64
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 03/25] x86-64: Adjust frame type at paranoid_exit:

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Jan Beulich 

As this isn't an exception or interrupt entry point, it doesn't
have any of the hardware provide frame layouts active.

Signed-off-by: Jan Beulich 
Acked-by: Alexander van Heukelum 
LKML-Reference: <4c7fbaa8027800013...@vpn.id2.novell.com>
Signed-off-by: Ingo Molnar 
(cherry picked from commit 1f130a783a796f147b080c594488b566c86007d0)
[WT: only merged to minimize changes from mainline in entry_64.S]
Signed-off-by: Willy Tarreau 
---
 arch/x86/kernel/entry_64.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 4f577eb..fb402d5 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1400,7 +1400,7 @@ paranoidzeroentry machine_check 
*machine_check_vector(%rip)
 
/* ebx: no swapgs flag */
 ENTRY(paranoid_exit)
-   INTR_FRAME
+   DEFAULT_FRAME
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
testl %ebx,%ebx /* swapgs needed? */
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 20/25] net: sctp: fix panic on duplicate ASCONF chunks

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Daniel Borkmann 

commit 12b18fdbbda747ad22a7684413a6559b681e503c upstream

When receiving a e.g. semi-good formed connection scan in the
form of ...

  -- INIT[ASCONF; ASCONF_ACK] ->
  <--- INIT-ACK[ASCONF; ASCONF_ACK] 
   COOKIE-ECHO >
  < COOKIE-ACK -
   ASCONF_a; ASCONF_b ->

... where ASCONF_a equals ASCONF_b chunk (at least both serials
need to be equal), we panic an SCTP server!

The problem is that good-formed ASCONF chunks that we reply with
ASCONF_ACK chunks are cached per serial. Thus, when we receive a
same ASCONF chunk twice (e.g. through a lost ASCONF_ACK), we do
not need to process them again on the server side (that was the
idea, also proposed in the RFC). Instead, we know it was cached
and we just resend the cached chunk instead. So far, so good.

Where things get nasty is in SCTP's side effect interpreter, that
is, sctp_cmd_interpreter():

While incoming ASCONF_a (chunk = event_arg) is being marked
!end_of_packet and !singleton, and we have an association context,
we do not flush the outqueue the first time after processing the
ASCONF_ACK singleton chunk via SCTP_CMD_REPLY. Instead, we keep it
queued up, although we set local_cork to 1. Commit 2e3216cd54b1
changed the precedence, so that as long as we get bundled, incoming
chunks we try possible bundling on outgoing queue as well. Before
this commit, we would just flush the output queue.

Now, while ASCONF_a's ASCONF_ACK sits in the corked outq, we
continue to process the same ASCONF_b chunk from the packet. As
we have cached the previous ASCONF_ACK, we find it, grab it and
do another SCTP_CMD_REPLY command on it. So, effectively, we rip
the chunk->list pointers and requeue the same ASCONF_ACK chunk
another time. Since we process ASCONF_b, it's correctly marked
with end_of_packet and we enforce an uncork, and thus flush, thus
crashing the kernel.

Fix it by testing if the ASCONF_ACK is currently pending and if
that is the case, do not requeue it. When flushing the output
queue we may relink the chunk for preparing an outgoing packet,
but eventually unlink it when it's copied into the skb right
before transmission.

Joint work with Vlad Yasevich.

Fixes: 2e3216cd54b1 ("sctp: Follow security requirement of responding with 1 
packet")
Signed-off-by: Daniel Borkmann 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
(cherry picked from commit b69040d8e39f20d5215a03502a8e8b4c6ab78395)
CVE-2014-3687
BugLink: http://bugs.launchpad.net/bugs/1386392
Signed-off-by: Luis Henriques 
Acked-by: Andy Whitcroft 
Signed-off-by: Brad Figg 
Signed-off-by: Willy Tarreau 
---
 include/net/sctp/sctp.h | 5 +
 net/sctp/associola.c| 2 ++
 2 files changed, 7 insertions(+)

diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index 8a6d529..ad5989a 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -509,6 +509,11 @@ static inline void sctp_assoc_pending_pmtu(struct 
sctp_association *asoc)
asoc->pmtu_pending = 0;
 }
 
+static inline bool sctp_chunk_pending(const struct sctp_chunk *chunk)
+{
+   return !list_empty(&chunk->list);
+}
+
 /* Walk through a list of TLV parameters.  Don't trust the
  * individual parameter lengths and instead depend on
  * the chunk length to indicate when to stop.  Make sure
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index 12137d3..8802516 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -1605,6 +1605,8 @@ struct sctp_chunk *sctp_assoc_lookup_asconf_ack(
 * ack chunk whose serial number matches that of the request.
 */
list_for_each_entry(ack, &asoc->asconf_ack_list, transmitted_list) {
+   if (sctp_chunk_pending(ack))
+   continue;
if (ack->subh.addip_hdr->serial == serial) {
sctp_chunk_hold(ack);
return ack;
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 06/25] x86-64, espfix: Dont leak bits 31:16 of %esp returning to 16-bit stack

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: "H. Peter Anvin" 

commit 3891a04aafd668686239349ea58f3314ea2af86b upstream.

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

In checkin:

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

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

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

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

Special thanks to:

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

Reported-by: Brian Gerst 
Signed-off-by: H. Peter Anvin 
Link: 
http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-...@linux.intel.com
Cc: Konrad Rzeszutek Wilk 
Cc: Borislav Petkov 
Cc: Andrew Lutomriski 
Cc: Linus Torvalds 
Cc: Dirk Hohndel 
Cc: Arjan van de Ven 
Cc: comex 
Cc: Alexander van Heukelum 
Cc: Boris Ostrovsky 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
(cherry picked from 3.2 commit e7836514086d53e0ffaee18d67d85d9477ecdb12)
[wt: backport notes for 2.6.32 differences :
 - use DECLARE_PER_CPU instead of DECLARE_PER_CPU_READ_MOSTLY
 - replace this_cpu_read(foo) with per_cpu(foo, smp_processor_id())
 - replace this_cpu_write(foo,bar) with per_cpu(foo,smp_processor_id())=bar
/wt]
Signed-off-by: Willy Tarreau 
---
 Documentation/x86/x86_64/mm.txt |   2 +
 arch/x86/include/asm/pgtable_64_types.h |   2 +
 arch/x86/kernel/Makefile|   1 +
 arch/x86/kernel/entry_64.S  |  72 ++-
 arch/x86/kernel/espfix_64.c | 208 
 arch/x86/kernel/ldt.c   |  11 --
 arch/x86/kernel/smpboot.c   |   7 ++
 arch/x86/mm/dump_pagetables.c   |  38 --
 init/main.c |   4 +
 9 files changed, 319 insertions(+), 26 deletions(-)
 create mode 100644 arch/x86/kernel/espfix_64.c

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index d6498e3..f33a936 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -12,6 +12,8 @@ c900 - e8ff (=45 bits) 
vmalloc/ioremap space
 e900 - e9ff (=40 bits) hole
 ea00 - eaff (=40 bits) virtual memory map (1TB)
 ... unused hole ...
+ff00 - ff7f (=39 bits) %esp fixup stacks
+... unused hole ...
 8000 - a000 (=512 MB)  kernel text mapping, from phys 0
 a000 - fff0 (=1536 MB) module mapping space
 
diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h
index 766ea16..51817fa 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -59,5 +59,7 @@ typedef struct { pteval_t pte; } pte_t;
 #define MODULES_VADDR_AC(0xa000, UL)
 #define MODULES_END  _AC(0xff00, UL)
 #define MODULES_LEN   (MODULES_END - MODULES_VADDR)
+#define ESPFIX_PGD_ENTRY _AC(-2, UL)
+#define ESPFIX_BASE_ADDR (ESPFIX_PGD_ENTRY << PGDIR_SHIFT)
 
 #endif /* _ASM_X86_PGTABLE_64_DEFS_H */
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index d1911ab..f58fd89 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_X86_32)  += probe_roms_32.o
 obj-$(CONFIG_X86_32)   += sys_i386_32.o i386_ksyms_32.o
 obj-$(CONFIG_X86_64)   += sys_x86_64.o x8664_ksyms_64.o
 obj-$(CONFIG_X86_64)   += syscall_64.o vsyscall_64.o
+obj-$(CONFIG_X86_64)   += espfix_64.o
 obj-y  += bootflag.o e820.o
 obj-y  += pci-dma.o quirks.o i8237.o topology.o kdebugfs.o
 obj-y  += alternative.o i8253.o pci-nommu.o
diff -

[ 12/25] x86/espfix/xen: Fix allocation of pages for paravirt page tables

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Boris Ostrovsky 

commit 8762e5092828c4dc0f49da5a47a644c670df77f3 upstream.

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

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

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

Signed-off-by: Boris Ostrovsky 
Link: 
http://lkml.kernel.org/r/1404926298-5565-1-git-send-email-boris.ostrov...@oracle.com
Reviewed-by: Konrad Rzeszutek Wilk 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
(cherry picked from 3.2 commit 060e7f67c88ebbcf8745505c7ccf44c53601f7de)
Signed-off-by: Willy Tarreau 
---
 arch/x86/kernel/espfix_64.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/espfix_64.c b/arch/x86/kernel/espfix_64.c
index 24bd342..8563154 100644
--- a/arch/x86/kernel/espfix_64.c
+++ b/arch/x86/kernel/espfix_64.c
@@ -175,7 +175,7 @@ void init_espfix_ap(void)
if (!pud_present(pud)) {
pmd_p = (pmd_t *)__get_free_page(PGALLOC_GFP);
pud = __pud(__pa(pmd_p) | (PGTABLE_PROT & ptemask));
-   paravirt_alloc_pud(&init_mm, __pa(pmd_p) >> PAGE_SHIFT);
+   paravirt_alloc_pmd(&init_mm, __pa(pmd_p) >> PAGE_SHIFT);
for (n = 0; n < ESPFIX_PUD_CLONES; n++)
set_pud(&pud_p[n], pud);
}
@@ -185,7 +185,7 @@ void init_espfix_ap(void)
if (!pmd_present(pmd)) {
pte_p = (pte_t *)__get_free_page(PGALLOC_GFP);
pmd = __pmd(__pa(pte_p) | (PGTABLE_PROT & ptemask));
-   paravirt_alloc_pmd(&init_mm, __pa(pte_p) >> PAGE_SHIFT);
+   paravirt_alloc_pte(&init_mm, __pa(pte_p) >> PAGE_SHIFT);
for (n = 0; n < ESPFIX_PMD_CLONES; n++)
set_pmd(&pmd_p[n], pmd);
}
@@ -193,7 +193,6 @@ void init_espfix_ap(void)
pte_p = pte_offset_kernel(&pmd, addr);
stack_page = (void *)__get_free_page(GFP_KERNEL);
pte = __pte(__pa(stack_page) | (__PAGE_KERNEL_RO & ptemask));
-   paravirt_alloc_pte(&init_mm, __pa(stack_page) >> PAGE_SHIFT);
for (n = 0; n < ESPFIX_PTE_CLONES; n++)
set_pte(&pte_p[n*PTE_STRIDE], pte);
 
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 07/25] x86, espfix: Move espfix definitions into a separate header file

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: "H. Peter Anvin" 

commit e1fe9ed8d2a4937510d0d60e20705035c2609aea upstream.

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

Reported-by: Fengguang Wu 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
(cherry picked from 3.2 commit 62358ee6bb9d3d9dd4761d39ac0e1ede9ba70b0e)
[wt: using DECLARE_PER_CPU instead of DECLARE_PER_CPU_READ_MOSTLY]
Signed-off-by: Willy Tarreau 
---
 arch/x86/include/asm/espfix.h | 16 
 arch/x86/include/asm/setup.h  |  2 ++
 arch/x86/kernel/espfix_64.c   |  1 +
 3 files changed, 19 insertions(+)
 create mode 100644 arch/x86/include/asm/espfix.h

diff --git a/arch/x86/include/asm/espfix.h b/arch/x86/include/asm/espfix.h
new file mode 100644
index 000..e2fb446
--- /dev/null
+++ b/arch/x86/include/asm/espfix.h
@@ -0,0 +1,16 @@
+#ifdef _ASM_X86_ESPFIX_H
+#define _ASM_X86_ESPFIX_H
+
+#ifdef CONFIG_X86_64
+
+#include 
+
+DECLARE_PER_CPU(unsigned long, espfix_stack);
+DECLARE_PER_CPU(unsigned long, espfix_waddr);
+
+extern void init_espfix_bsp(void);
+extern void init_espfix_ap(void);
+
+#endif /* CONFIG_X86_64 */
+
+#endif /* _ASM_X86_ESPFIX_H */
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 18e496c..ac45d3b 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -57,6 +57,8 @@ static inline void x86_mrst_early_setup(void) { }
 
 #ifndef _SETUP
 
+#include 
+
 /*
  * This is set up by the setup-routine at boot-time
  */
diff --git a/arch/x86/kernel/espfix_64.c b/arch/x86/kernel/espfix_64.c
index ae10040..24bd342 100644
--- a/arch/x86/kernel/espfix_64.c
+++ b/arch/x86/kernel/espfix_64.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Note: we only need 6*8 = 48 bytes for the espfix stack, but round
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 04/25] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: "H. Peter Anvin" 

commit b3b42ac2cbae1f3cecbb6229964a4d48af31d382 upstream.

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

Since 16-bit support is somewhat crippled anyway on a 64-bit kernel
(no V86 mode), and most (if not quite all) 64-bit processors support
virtualization for the users who really need it, simply reject
attempts at creating a 16-bit segment when running on top of a 64-bit
kernel.

Cc: Linus Torvalds 
Signed-off-by: H. Peter Anvin 
Link: http://lkml.kernel.org/n/tip-kicdm89kzw9lldryb1br9...@git.kernel.org
Signed-off-by: Ben Hutchings 
(cherry picked from 3.2 commit a862b5c4076b1ba4dd6c87aebac478853dc6db47)
Signed-off-by: Willy Tarreau 
---
 arch/x86/kernel/ldt.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/x86/kernel/ldt.c b/arch/x86/kernel/ldt.c
index ec6ef60..75e356c 100644
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@ -229,6 +229,17 @@ static int write_ldt(void __user *ptr, unsigned long 
bytecount, int oldmode)
}
}
 
+   /*
+* On x86-64 we do not support 16-bit segments due to
+* IRET leaking the high bits of the kernel stack address.
+*/
+#ifdef CONFIG_X86_64
+   if (!ldt_info.seg_32bit) {
+   error = -EINVAL;
+   goto out_unlock;
+   }
+#endif
+
fill_ldt(&ldt, &ldt_info);
if (oldmode)
ldt.avl = 0;
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 13/25] x86_64, traps: Stop using IST for #SS

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Andy Lutomirski 

On a 32-bit kernel, this has no effect, since there are no IST stacks.

On a 64-bit kernel, #SS can only happen in user code, on a failed iret
to user space, a canonical violation on access via RSP or RBP, or a
genuine stack segment violation in 32-bit kernel code.  The first two
cases don't need IST, and the latter two cases are unlikely fatal bugs,
and promoting them to double faults would be fine.

This fixes a bug in which the espfix64 code mishandles a stack segment
violation.

This saves 4k of memory per CPU and a tiny bit of code.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Thomas Gleixner 
Cc: sta...@vger.kernel.org
Signed-off-by: Linus Torvalds 
(cherry picked from commit 6f442be2fb22be02cafa606f1769fa1e6f894441)
[wt: no CONFIG_TRACING on 2.6.32, Fixes CVE-2014-9090]
Signed-off-by: Willy Tarreau 
---
 arch/x86/include/asm/page_32_types.h |  1 -
 arch/x86/include/asm/page_64_types.h | 11 +--
 arch/x86/kernel/dumpstack_64.c   |  1 -
 arch/x86/kernel/entry_64.S   |  2 +-
 arch/x86/kernel/traps.c  | 14 +-
 5 files changed, 7 insertions(+), 22 deletions(-)

diff --git a/arch/x86/include/asm/page_32_types.h 
b/arch/x86/include/asm/page_32_types.h
index 6f1b733..775c92f 100644
--- a/arch/x86/include/asm/page_32_types.h
+++ b/arch/x86/include/asm/page_32_types.h
@@ -22,7 +22,6 @@
 #endif
 #define THREAD_SIZE(PAGE_SIZE << THREAD_ORDER)
 
-#define STACKFAULT_STACK 0
 #define DOUBLEFAULT_STACK 1
 #define NMI_STACK 0
 #define DEBUG_STACK 0
diff --git a/arch/x86/include/asm/page_64_types.h 
b/arch/x86/include/asm/page_64_types.h
index 7639dbf..a9e9937 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -14,12 +14,11 @@
 #define IRQ_STACK_ORDER 2
 #define IRQ_STACK_SIZE (PAGE_SIZE << IRQ_STACK_ORDER)
 
-#define STACKFAULT_STACK 1
-#define DOUBLEFAULT_STACK 2
-#define NMI_STACK 3
-#define DEBUG_STACK 4
-#define MCE_STACK 5
-#define N_EXCEPTION_STACKS 5  /* hw limit: 7 */
+#define DOUBLEFAULT_STACK 1
+#define NMI_STACK 2
+#define DEBUG_STACK 3
+#define MCE_STACK 4
+#define N_EXCEPTION_STACKS 4  /* hw limit: 7 */
 
 #define PUD_PAGE_SIZE  (_AC(1, UL) << PUD_SHIFT)
 #define PUD_PAGE_MASK  (~(PUD_PAGE_SIZE-1))
diff --git a/arch/x86/kernel/dumpstack_64.c b/arch/x86/kernel/dumpstack_64.c
index a071e6b..5dc0882 100644
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -23,7 +23,6 @@ static char x86_stack_ids[][8] = {
[DEBUG_STACK - 1] = "#DB",
[NMI_STACK - 1] = "NMI",
[DOUBLEFAULT_STACK - 1] = "#DF",
-   [STACKFAULT_STACK - 1] = "#SS",
[MCE_STACK - 1] = "#MC",
 #if DEBUG_STKSZ > EXCEPTION_STKSZ
[N_EXCEPTION_STACKS ...
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 4313d48..8e2f14a 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1434,7 +1434,7 @@ END(xen_failsafe_callback)
 
 paranoidzeroentry_ist debug do_debug DEBUG_STACK
 paranoidzeroentry_ist int3 do_int3 DEBUG_STACK
-paranoiderrorentry stack_segment do_stack_segment
+errorentry stack_segment do_stack_segment
 #ifdef CONFIG_XEN
 zeroentry xen_debug do_debug
 zeroentry xen_int3 do_int3
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 7e37dce..c4cc05a 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -220,23 +220,11 @@ DO_ERROR_INFO(6, SIGILL, "invalid opcode", invalid_op, 
ILL_ILLOPN, regs->ip)
 DO_ERROR(9, SIGFPE, "coprocessor segment overrun", coprocessor_segment_overrun)
 DO_ERROR(10, SIGSEGV, "invalid TSS", invalid_TSS)
 DO_ERROR(11, SIGBUS, "segment not present", segment_not_present)
-#ifdef CONFIG_X86_32
 DO_ERROR(12, SIGBUS, "stack segment", stack_segment)
-#endif
 DO_ERROR_INFO(17, SIGBUS, "alignment check", alignment_check, BUS_ADRALN, 0)
 
 #ifdef CONFIG_X86_64
 /* Runs on IST stack */
-dotraplinkage void do_stack_segment(struct pt_regs *regs, long error_code)
-{
-   if (notify_die(DIE_TRAP, "stack segment", regs, error_code,
-   12, SIGBUS) == NOTIFY_STOP)
-   return;
-   preempt_conditional_sti(regs);
-   do_trap(12, SIGBUS, "stack segment", regs, error_code, NULL);
-   preempt_conditional_cli(regs);
-}
-
 dotraplinkage void do_double_fault(struct pt_regs *regs, long error_code)
 {
static const char str[] = "double fault";
@@ -927,7 +915,7 @@ void __init trap_init(void)
set_intr_gate(9, &coprocessor_segment_overrun);
set_intr_gate(10, &invalid_TSS);
set_intr_gate(11, &segment_not_present);
-   set_intr_gate_ist(12, &stack_segment, STACKFAULT_STACK);
+   set_intr_gate(12, &stack_segment);
set_intr_gate(13, &general_protection);
set_intr_gate(14, &page_fault);
set_intr_gate(15, &spurious_interrupt_bug);
-

[ 17/25] ALSA: control: Dont access controls outside of protected regions

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Lars-Peter Clausen 

(commit fd9f26e4eca5d08a27d12c0933fceef76ed9663d upstream)

A control that is visible on the card->controls list can be freed at any time.
This means we must not access any of its memory while not holding the
controls_rw_lock. Otherwise we risk a use after free access.

Signed-off-by: Lars-Peter Clausen 
Acked-by: Jaroslav Kysela 
Cc: 
Signed-off-by: Takashi Iwai 
[wt: fixes CVE-2014-4653]
Signed-off-by: Willy Tarreau 
---
 sound/core/control.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/sound/core/control.c b/sound/core/control.c
index 8bf3a6d..e91d79a 100644
--- a/sound/core/control.c
+++ b/sound/core/control.c
@@ -325,6 +325,7 @@ int snd_ctl_add(struct snd_card *card, struct snd_kcontrol 
*kcontrol)
 {
struct snd_ctl_elem_id id;
unsigned int idx;
+   unsigned int count;
int err = -EINVAL;
 
if (! kcontrol)
@@ -356,8 +357,9 @@ int snd_ctl_add(struct snd_card *card, struct snd_kcontrol 
*kcontrol)
card->controls_count += kcontrol->count;
kcontrol->id.numid = card->last_numid + 1;
card->last_numid += kcontrol->count;
+   count = kcontrol->count;
up_write(&card->controls_rwsem);
-   for (idx = 0; idx < kcontrol->count; idx++, id.index++, id.numid++)
+   for (idx = 0; idx < count; idx++, id.index++, id.numid++)
snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_ADD, &id);
return 0;
 
@@ -784,9 +786,9 @@ static int snd_ctl_elem_write(struct snd_card *card, struct 
snd_ctl_file *file,
result = kctl->put(kctl, control);
}
if (result > 0) {
+   struct snd_ctl_elem_id id = control->id;
up_read(&card->controls_rwsem);
-   snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_VALUE,
-  &control->id);
+   snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_VALUE, &id);
return 0;
}
}
-- 
1.7.12.2.21.g234cd45.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 14/25] x86_64, traps: Fix the espfix64 #DF fixup and rewrite it in C

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Andy Lutomirski 

There's nothing special enough about the espfix64 double fault fixup to
justify writing it in assembly.  Move it to C.

This also fixes a bug: if the double fault came from an IST stack, the
old asm code would return to a partially uninitialized stack frame.

Fixes: 3891a04aafd668686239349ea58f3314ea2af86b
Signed-off-by: Andy Lutomirski 
Reviewed-by: Thomas Gleixner 
Cc: sta...@vger.kernel.org
Signed-off-by: Linus Torvalds 
(cherry picked from commit af726f21ed8af2cdaa4e93098dc211521218ae65)
[wt: backport notes for 2.6.32 :
  - Adaptations to entry_64.S in declaration of do_double_fault.
  - no exception_enter() in 2.6.32. Seems to be only for context tracking.
/wt]
Signed-off-by: Willy Tarreau 
---
 arch/x86/kernel/entry_64.S | 34 ++
 arch/x86/kernel/traps.c| 24 
 2 files changed, 26 insertions(+), 32 deletions(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 8e2f14a..c862780 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -871,6 +871,7 @@ ENTRY(native_iret)
jnz native_irq_return_ldt
 #endif
 
+.global native_irq_return_iret
 native_irq_return_iret:
iretq
 
@@ -972,37 +973,6 @@ ENTRY(retint_kernel)
CFI_ENDPROC
 END(common_interrupt)
 
-   /*
-* If IRET takes a fault on the espfix stack, then we
-* end up promoting it to a doublefault.  In that case,
-* modify the stack to make it look like we just entered
-* the #GP handler from user space, similar to bad_iret.
-*/
-#ifdef CONFIG_X86_ESPFIX64
-   ALIGN
-__do_double_fault:
-   XCPT_FRAME 1 RDI+8
-   movq RSP(%rdi),%rax /* Trap on the espfix stack? */
-   sarq $PGDIR_SHIFT,%rax
-   cmpl $ESPFIX_PGD_ENTRY,%eax
-   jne do_double_fault /* No, just deliver the fault */
-   cmpl $__KERNEL_CS,CS(%rdi)
-   jne do_double_fault
-   movq RIP(%rdi),%rax
-   cmpq $native_irq_return_iret,%rax
-   jne do_double_fault /* This shouldn't happen... */
-   movq PER_CPU_VAR(kernel_stack),%rax
-   subq $(6*8-KERNEL_STACK_OFFSET),%rax/* Reset to original stack */
-   movq %rax,RSP(%rdi)
-   movq $0,(%rax)  /* Missing (lost) #GP error code */
-   movq $general_protection,RIP(%rdi)
-   retq
-   CFI_ENDPROC
-END(__do_double_fault)
-#else
-# define __do_double_fault do_double_fault
-#endif
-
 /*
  * APIC interrupts.
  */
@@ -1179,7 +1149,7 @@ zeroentry overflow do_overflow
 zeroentry bounds do_bounds
 zeroentry invalid_op do_invalid_op
 zeroentry device_not_available do_device_not_available
-paranoiderrorentry double_fault __do_double_fault
+paranoiderrorentry double_fault do_double_fault
 zeroentry coprocessor_segment_overrun do_coprocessor_segment_overrun
 errorentry invalid_TSS do_invalid_TSS
 errorentry segment_not_present do_segment_not_present
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index c4cc05a..03563a4 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -230,6 +230,30 @@ dotraplinkage void do_double_fault(struct pt_regs *regs, 
long error_code)
static const char str[] = "double fault";
struct task_struct *tsk = current;
 
+#ifdef CONFIG_X86_ESPFIX64
+   extern unsigned char native_irq_return_iret[];
+
+   /*
+* If IRET takes a non-IST fault on the espfix64 stack, then we
+* end up promoting it to a doublefault.  In that case, modify
+* the stack to make it look like we just entered the #GP
+* handler from user space, similar to bad_iret.
+*/
+   if (((long)regs->sp >> PGDIR_SHIFT) == ESPFIX_PGD_ENTRY &&
+   regs->cs == __KERNEL_CS &&
+   regs->ip == (unsigned long)native_irq_return_iret)
+   {
+   struct pt_regs *normal_regs = task_pt_regs(current);
+
+   /* Fake a #GP(0) from userspace. */
+   memmove(&normal_regs->ip, (void *)regs->sp, 5*8);
+   normal_regs->orig_ax = 0;  /* Missing (lost) #GP error code */
+   regs->ip = (unsigned long)general_protection;
+   regs->sp = (unsigned long)&normal_regs->orig_ax;
+   return;
+   }
+#endif
+
/* Return not checked because double check cannot be ignored */
notify_die(DIE_TRAP, str, regs, error_code, 8, SIGSEGV);
 
-- 
1.7.12.2.21.g234cd45.dirty



--
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] regulator.txt: fix to fit to 80 columns

[Pavel Machek]

Fix documentation to fit into 80 columns.

Signed-off-by: Pavel Machek 

diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt 
b/Documentation/devicetree/bindings/regulator/regulator.txt
index 8607433..a0f9983 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -4,7 +4,8 @@ Optional properties:
 - regulator-name: A string used as a descriptive name for regulator outputs
 - regulator-min-microvolt: smallest voltage consumers may set
 - regulator-max-microvolt: largest voltage consumers may set
-- regulator-microvolt-offset: Offset applied to voltages to compensate for 
voltage drops
+- regulator-microvolt-offset: Offset applied to voltages to compensate for
+  voltage drops
 - regulator-min-microamp: smallest current consumers may set
 - regulator-max-microamp: largest current consumers may set
 - regulator-always-on: boolean, regulator should never be disabled

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 21/25] net: sctp: fix remote memory pressure from excessive queueing

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Daniel Borkmann 

commit b2d33ef40de7161c23032106284959ae75bdf3cd upstream

This scenario is not limited to ASCONF, just taken as one
example triggering the issue. When receiving ASCONF probes
in the form of ...

  -- INIT[ASCONF; ASCONF_ACK] ->
  <--- INIT-ACK[ASCONF; ASCONF_ACK] 
   COOKIE-ECHO >
  < COOKIE-ACK -
   ASCONF_a; [ASCONF_b; ...; ASCONF_n;] JUNK -->
  [...]
   ASCONF_m; [ASCONF_o; ...; ASCONF_z;] JUNK -->

... where ASCONF_a, ASCONF_b, ..., ASCONF_z are good-formed
ASCONFs and have increasing serial numbers, we process such
ASCONF chunk(s) marked with !end_of_packet and !singleton,
since we have not yet reached the SCTP packet end. SCTP does
only do verification on a chunk by chunk basis, as an SCTP
packet is nothing more than just a container of a stream of
chunks which it eats up one by one.

We could run into the case that we receive a packet with a
malformed tail, above marked as trailing JUNK. All previous
chunks are here goodformed, so the stack will eat up all
previous chunks up to this point. In case JUNK does not fit
into a chunk header and there are no more other chunks in
the input queue, or in case JUNK contains a garbage chunk
header, but the encoded chunk length would exceed the skb
tail, or we came here from an entirely different scenario
and the chunk has pdiscard=1 mark (without having had a flush
point), it will happen, that we will excessively queue up
the association's output queue (a correct final chunk may
then turn it into a response flood when flushing the
queue ;)): I ran a simple script with incremental ASCONF
serial numbers and could see the server side consuming
excessive amount of RAM [before/after: up to 2GB and more].

The issue at heart is that the chunk train basically ends
with !end_of_packet and !singleton markers and since commit
2e3216cd54b1 ("sctp: Follow security requirement of responding
with 1 packet") therefore preventing an output queue flush
point in sctp_do_sm() -> sctp_cmd_interpreter() on the input
chunk (chunk = event_arg) even though local_cork is set,
but its precedence has changed since then. In the normal
case, the last chunk with end_of_packet=1 would trigger the
queue flush to accommodate possible outgoing bundling.

In the input queue, sctp_inq_pop() seems to do the right thing
in terms of discarding invalid chunks. So, above JUNK will
not enter the state machine and instead be released and exit
the sctp_assoc_bh_rcv() chunk processing loop. It's simply
the flush point being missing at loop exit. Adding a try-flush
approach on the output queue might not work as the underlying
infrastructure might be long gone at this point due to the
side-effect interpreter run.

One possibility, albeit a bit of a kludge, would be to defer
invalid chunk freeing into the state machine in order to
possibly trigger packet discards and thus indirectly a queue
flush on error. It would surely be better to discard chunks
as in the current, perhaps better controlled environment, but
going back and forth, it's simply architecturally not possible.
I tried various trailing JUNK attack cases and it seems to
look good now.

Joint work with Vlad Yasevich.

Fixes: 2e3216cd54b1 ("sctp: Follow security requirement of responding with 1 
packet")
Signed-off-by: Daniel Borkmann 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
(cherry picked from commit 26b87c7881006311828bb0ab271a551a62dcceb4)
CVE-2014-3688
BugLink: http://bugs.launchpad.net/bugs/1386393
Signed-off-by: Luis Henriques 
Acked-by: Andy Whitcroft 
Signed-off-by: Brad Figg 
Signed-off-by: Willy Tarreau 
---
 net/sctp/inqueue.c  | 33 +++--
 net/sctp/sm_statefuns.c |  3 +++
 2 files changed, 10 insertions(+), 26 deletions(-)

diff --git a/net/sctp/inqueue.c b/net/sctp/inqueue.c
index bbf5dd2..7f33bfa 100644
--- a/net/sctp/inqueue.c
+++ b/net/sctp/inqueue.c
@@ -149,18 +149,9 @@ struct sctp_chunk *sctp_inq_pop(struct sctp_inq *queue)
} else {
/* Nothing to do. Next chunk in the packet, please. */
ch = (sctp_chunkhdr_t *) chunk->chunk_end;
-
/* Force chunk->skb->data to chunk->chunk_end.  */
-   skb_pull(chunk->skb,
-chunk->chunk_end - chunk->skb->data);
-
-   /* Verify that we have at least chunk headers
-* worth of buffer left.
-*/
-   if (skb_headlen(chunk->skb) < sizeof(sctp_chunkhdr_t)) {
-   sctp_chunk_free(chunk);
-   chunk = queue->in_progress = NULL;
-   }
+   skb_pull(chunk->skb, chunk->chunk_end - 
ch

[ 15/25] x86_64, traps: Rework bad_iret

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Andy Lutomirski 

It's possible for iretq to userspace to fail.  This can happen because
of a bad CS, SS, or RIP.

Historically, we've handled it by fixing up an exception from iretq to
land at bad_iret, which pretends that the failed iret frame was really
the hardware part of #GP(0) from userspace.  To make this work, there's
an extra fixup to fudge the gs base into a usable state.

This is suboptimal because it loses the original exception.  It's also
buggy because there's no guarantee that we were on the kernel stack to
begin with.  For example, if the failing iret happened on return from an
NMI, then we'll end up executing general_protection on the NMI stack.
This is bad for several reasons, the most immediate of which is that
general_protection, as a non-paranoid idtentry, will try to deliver
signals and/or schedule from the wrong stack.

This patch throws out bad_iret entirely.  As a replacement, it augments
the existing swapgs fudge into a full-blown iret fixup, mostly written
in C.  It's should be clearer and more correct.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Thomas Gleixner 
Cc: sta...@vger.kernel.org
Signed-off-by: Linus Torvalds 
(cherry picked from commit b645af2d5905c4e32399005b867987919cbfc3ae)
[wt: notes for backport to 2.6.32:
  - _ASM_EXTABLE was open-coded.
  - removed unneeded CFI_ENDPROC
  - removed __visible (introduced in 2.6.37-rc1, not needed here)
/wt]
Signed-off-by: Willy Tarreau 
---
 arch/x86/kernel/entry_64.S | 48 ++
 arch/x86/kernel/traps.c| 29 
 2 files changed, 48 insertions(+), 29 deletions(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index c862780..d9bcee0 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -873,12 +873,14 @@ ENTRY(native_iret)
 
 .global native_irq_return_iret
 native_irq_return_iret:
+   /*
+* This may fault.  Non-paranoid faults on return to userspace are
+* handled by fixup_bad_iret.  These include #SS, #GP, and #NP.
+* Double-faults due to espfix64 are handled in do_double_fault.
+* Other faults here are fatal.
+*/
iretq
 
-   .section __ex_table,"a"
-   .quad native_irq_return_iret, bad_iret
-   .previous
-
 #ifdef CONFIG_X86_ESPFIX64
 native_irq_return_ldt:
pushq_cfi %rax
@@ -905,25 +907,6 @@ native_irq_return_ldt:
jmp native_irq_return_iret
 #endif
 
-   .section .fixup,"ax"
-bad_iret:
-   /*
-* The iret traps when the %cs or %ss being restored is bogus.
-* We've lost the original trap vector and error code.
-* #GPF is the most likely one to get for an invalid selector.
-* So pretend we completed the iret and took the #GPF in user mode.
-*
-* We are now running with the kernel GS after exception recovery.
-* But error_entry expects us to have user GS to match the user %cs,
-* so swap back.
-*/
-   pushq $0
-
-   SWAPGS
-   jmp general_protection
-
-   .previous
-
/* edi: workmask, edx: work */
 retint_careful:
CFI_RESTORE_STATE
@@ -1512,16 +1495,15 @@ error_sti:
 
 /*
  * There are two places in the kernel that can potentially fault with
- * usergs. Handle them here. The exception handlers after iret run with
- * kernel gs again, so don't set the user space flag. B stepping K8s
- * sometimes report an truncated RIP for IRET exceptions returning to
- * compat mode. Check for these here too.
+ * usergs. Handle them here.  B stepping K8s sometimes report a
+ * truncated RIP for IRET exceptions returning to compat mode. Check
+ * for these here too.
  */
 error_kernelspace:
incl %ebx
leaq native_irq_return_iret(%rip),%rcx
cmpq %rcx,RIP+8(%rsp)
-   je error_swapgs
+   je error_bad_iret
movl %ecx,%eax  /* zero extend */
cmpq %rax,RIP+8(%rsp)
je bstep_iret
@@ -1532,7 +1514,15 @@ error_kernelspace:
 bstep_iret:
/* Fix truncated RIP */
movq %rcx,RIP+8(%rsp)
-   je error_swapgs
+   /* fall through */
+
+error_bad_iret:
+   SWAPGS
+   mov %rsp,%rdi
+   call fixup_bad_iret
+   mov %rax,%rsp
+   decl %ebx   /* Return to usergs */
+   jmp error_sti
 END(error_entry)
 
 
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 03563a4..8a39a6c 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -512,6 +512,35 @@ asmlinkage __kprobes struct pt_regs *sync_regs(struct 
pt_regs *eregs)
*regs = *eregs;
return regs;
 }
+
+struct bad_iret_stack {
+   void *error_entry_ret;
+   struct pt_regs regs;
+};
+
+asmlinkage
+struct bad_iret_stack *fixup_bad_iret(struct bad_iret_stack *s)
+{
+   /*
+* This is called from entry_64.S early in handling a fault
+* caus

[ 01/25] net: sendmsg: fix failed backport of "fix NULL pointer dereference"

[Willy Tarreau]

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

--

From: Willy Tarreau 

Luis Henriques reported that while backporting commit 40eea80 ("net:
sendmsg: fix NULL pointer dereference") and applying the diff by hand,
I made a typo resulting in the same test being done twice, and msg_name
not being tested.

This fixes cf90357 ("net: sendmsg: fix NULL pointer dereference")
which was merged into 2.6.32.64.

Cc: Andrey Ryabinin 
Cc: Luis Henriques 
Signed-off-by: Willy Tarreau 
---
 net/compat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/compat.c b/net/compat.c
index 71ed839..a5848ac 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -83,7 +83,7 @@ int verify_compat_iovec(struct msghdr *kern_msg, struct iovec 
*kern_iov,
 {
int tot_len;
 
-   if (kern_msg->msg_namelen && kern_msg->msg_namelen) {
+   if (kern_msg->msg_name && kern_msg->msg_namelen) {
if (mode==VERIFY_READ) {
int err = move_addr_to_kernel(kern_msg->msg_name,
  kern_msg->msg_namelen,
-- 
1.7.12.2.21.g234cd45.dirty



--
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: N900: fixing MMC at boot

[Pali Rohár]

On Saturday 06 December 2014 18:35:27 Pavel Machek wrote:
> Hi!
> 
> For a long time, MMC was not working during boot... (making
> the box unusable without nfsroot). It seems problem is in the
> regulators, because with diff below, I was able to mount root
> on SD card for a first time ... in a long time.
> 

Hi, do you mean external SD card or internal eMMC (MyDocs)?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 2/2 V8] intel_pstate: add kernel parameter to force loading.

[Linda Knippers]

On 12/5/2014 9:16 PM, ethan wrote:
> Linda，
> 
>> 在 2014年12月6日，00:09，Linda Knippers  写道：
>>
>>> On 12/5/2014 4:40 AM, Ethan Zhao wrote:
>>> To force loading on Oracle Sun X86 servers, provide one kernel command line
>>> parameter
>>>
>>>  intel_pstate = force
>>>
>>> For those who be aware of the risk of no power capping capabily working and
>>> try to get better performance with this driver.
>>>
>>> Signed-off-by: Ethan Zhao 
>>> Tested-by: Alexey Kodanev 
>>> ---
>>> v2: change to hardware vendor specific naming parameter.
>>> v4: refine code and doc.
>>> v5&v6: fix a typo in doc.
>>> v7: change enum PCC to PPC.
>>> v8: change the name of kernel command line parameter to generic one.
>>>
>>> Documentation/kernel-parameters.txt | 5 +
>>> drivers/cpufreq/intel_pstate.c  | 6 +-
>>> 2 files changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/kernel-parameters.txt 
>>> b/Documentation/kernel-parameters.txt
>>> index 479f332..7d0983e 100644
>>> --- a/Documentation/kernel-parameters.txt
>>> +++ b/Documentation/kernel-parameters.txt
>>> @@ -1446,6 +1446,11 @@ bytes respectively. Such letter suffixes can also be 
>>> entirely omitted.
>>>   disable
>>> Do not enable intel_pstate as the default
>>> scaling driver for the supported processors
>>> +   force
>>> + Enable intel_pstate on systems where it may cause problems to
>>> + happen due to conflicts with platform firmware attempting to
>>> + drive P-states by itself in certain situations (for thermal 
>>> + control or power capping in general or other purposes).
>>
>> I suggest something like:
>>Enable intel_pstate on systems that prohibit it by
>>default in favor of acpi-cpufreq.  Forcing the
>>intel_pstate driver instead of acpi-cpufreq may disable
>>platform features, such as thermal controls and power
>>capping, that rely on ACPI p-state information being
>  P-States 
>> Used by the OS and therefore should be used with care.
>Indicated to OSPM  
>  caution 
>>This option does not work with processors that aren't
>>supported by the intel_pstate driver or on platforms
>>that use pcc-cpufreq instead of acpi-cpufreq.
>>
>> Maybe this is too specific but I believe it is accurate.  Comments?
>>
> 
> Looks better to me, except some words commented. 

Your suggestions look fine to me.

-- ljk
> 
> Thanks,
> Ethan
>> -- ljk
>>
>>>
>>>intremap=[X86-64, Intel-IOMMU]
>>>onenable Interrupt Remapping (default)
>>> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
>>> index 1bb62ca..2654e13 100644
>>> --- a/drivers/cpufreq/intel_pstate.c
>>> +++ b/drivers/cpufreq/intel_pstate.c
>>> @@ -866,6 +866,7 @@ static struct cpufreq_driver intel_pstate_driver = {
>>> };
>>>
>>> static int __initdata no_load;
>>> +static unsigned int  force_load;
>>>
>>> static int intel_pstate_msrs_not_valid(void)
>>> {
>>> @@ -1003,7 +1004,8 @@ static bool 
>>> intel_pstate_platform_pwr_mgmt_exists(void)
>>>case PSS:
>>>return intel_pstate_no_acpi_pss();
>>>case PPC:
>>> -return intel_pstate_has_acpi_ppc();
>>> +return intel_pstate_has_acpi_ppc() &&
>>> +(!force_load);
>>>}
>>>}
>>>
>>> @@ -1078,6 +1080,8 @@ static int __init intel_pstate_setup(char *str)
>>>
>>>if (!strcmp(str, "disable"))
>>>no_load = 1;
>>> +if (!strcmp(str, "force"))
>>> +force_load = 1;
>>>return 0;
>>> }
>>> early_param("intel_pstate", intel_pstate_setup);
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
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/

N900: fixing MMC at boot

[Pavel Machek]

Hi!

For a long time, MMC was not working during boot... (making the box
unusable without nfsroot). It seems problem is in the regulators,
because with diff below, I was able to mount root on SD card for a
first time ... in a long time.

Signed-off-by: Pavel Machek  [but not for upstream]

diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt 
b/Documentation/devicetree/bindings/regulator/regulator.txt
index 8607433..07791c6 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -4,7 +4,8 @@ Optional properties:
 - regulator-name: A string used as a descriptive name for regulator outputs
 - regulator-min-microvolt: smallest voltage consumers may set
 - regulator-max-microvolt: largest voltage consumers may set
-- regulator-microvolt-offset: Offset applied to voltages to compensate for 
voltage drops
+- regulator-microvolt-offset: Offset applied to voltages to compensate for 
+  voltage drops
 - regulator-min-microamp: smallest current consumers may set
 - regulator-max-microamp: largest current consumers may set
 - regulator-always-on: boolean, regulator should never be disabled
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 11d8afd..707928d 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -287,31 +287,35 @@
regulator-name = "V28";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
-   regulator-always-on; /* due battery cover sensor */
+   regulator-always-on; /* due to battery cover sensor */
 };
 
 &vaux2 {
regulator-name = "VCSI";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-always-on; /* FIXME */
 };
 
 &vaux3 {
regulator-name = "VMMC2_30";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <300>;
+   regulator-always-on; /* FIXME */
 };
 
 &vaux4 {
regulator-name = "VCAM_ANA_28";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
+   regulator-always-on; /* FIXME */
 };
 
 &vmmc1 {
regulator-name = "VMMC1";
regulator-min-microvolt = <185>;
regulator-max-microvolt = <315>;
+   regulator-always-on; /* FIXME */
 };
 
 &vmmc2 {
@@ -339,13 +343,14 @@
regulator-name = "VMMC2_IO_18";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-always-on; /* FIXME */
 };
 
 &vio {
regulator-name = "VIO";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
-
+   regulator-always-on; /* FIXME */
 };
 
 &vintana1 {

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] arm64: Enable CONFIG_COMPAT also for 64k page size

[Alexander Graf]

On 04.12.14 19:20, Will Deacon wrote:
> On Thu, Dec 04, 2014 at 03:46:33PM +, Alexander Graf wrote:
>> With binutils 2.25 the default alignment for 32bit arm sections changed to
>> have everything 64k aligned. Armv7 binaries built with this binutils version
>> run successfully on an arm64 system.
>>
>> Since effectively there is now the chance to run armv7 code on arm64 even
>> with 64k page size, it doesn't make sense to block people from enabling
>> CONFIG_COMPAT on those configurations.
> 
> Is there a distro available that is built with a recent enough binutils for
> this? I'd really like to run our regression tests to check that page-size
> assumptions don't exist for things like shm.

So how much of a distro do you need? I could probably assemble a simple
very minimalistic rootfs with only bash if that helps.


Alex
--
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/4] iio: dht11: IRQ fixes

[harald]

Hi Richard,

finally got around to test this patch on all HW I have.

As expected the preamble needs to be shortend by two edges:
With your patch in its current form, the driver stops to work
reliably with DHT11. Also with DHT22 you get some delay when
reading the data, because you always wait for the timeout to
happen, before trying to decode the data.

Since your patch title includes "fix", the commit message
probably should mention that the patch as a side effect
changes behaviour - even if it's just diagnostic messages.

Thanks,
Harald

On Wed,  3 Dec 2014 00:32:54 +0100, Richard Weinberger 
wrote:
> Signed-off-by: Richard Weinberger 
> ---
>  drivers/iio/humidity/dht11.c | 56
>  
>  1 file changed, 30 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/iio/humidity/dht11.c b/drivers/iio/humidity/dht11.c
> index 168ebc4..0023699 100644
> --- a/drivers/iio/humidity/dht11.c
> +++ b/drivers/iio/humidity/dht11.c
> @@ -140,6 +140,27 @@ static int dht11_decode(struct dht11 *dht11, int
> offset)
>   return 0;
>  }
>  
> +/*
> + * IRQ handler called on GPIO edges
> + */
> +static irqreturn_t dht11_handle_irq(int irq, void *data)
> +{
> + struct iio_dev *iio = data;
> + struct dht11 *dht11 = iio_priv(iio);
> +
> + /* TODO: Consider making the handler safe for IRQ sharing */
> + if (dht11->num_edges < DHT11_EDGES_PER_READ && dht11->num_edges >= 0)
{
> + dht11->edges[dht11->num_edges].ts = iio_get_time_ns();
> + dht11->edges[dht11->num_edges++].value =
> + gpio_get_value(dht11->gpio);
> +
> + if (dht11->num_edges >= DHT11_EDGES_PER_READ)
> + complete(&dht11->completion);
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
>  static int dht11_read_raw(struct iio_dev *iio_dev,
>   const struct iio_chan_spec *chan,
>   int *val, int *val2, long m)
> @@ -160,8 +181,17 @@ static int dht11_read_raw(struct iio_dev *iio_dev,
>   if (ret)
>   goto err;
>  
> + ret = request_irq(dht11->irq, dht11_handle_irq,
> +   IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
> +   iio_dev->name, iio_dev);
> + if (ret)
> + goto err;
> +
>   ret = wait_for_completion_killable_timeout(&dht11->completion,
>HZ);
> +
> + free_irq(dht11->irq, iio_dev);
> +
>   if (ret == 0 && dht11->num_edges < DHT11_EDGES_PER_READ - 1) {
>   dev_err(&iio_dev->dev,
>   "Only %d signal edges detected\n",
> @@ -197,27 +227,6 @@ static const struct iio_info dht11_iio_info = {
>   .read_raw   = dht11_read_raw,
>  };
>  
> -/*
> - * IRQ handler called on GPIO edges
> -*/
> -static irqreturn_t dht11_handle_irq(int irq, void *data)
> -{
> - struct iio_dev *iio = data;
> - struct dht11 *dht11 = iio_priv(iio);
> -
> - /* TODO: Consider making the handler safe for IRQ sharing */
> - if (dht11->num_edges < DHT11_EDGES_PER_READ && dht11->num_edges >= 0)
{
> - dht11->edges[dht11->num_edges].ts = iio_get_time_ns();
> - dht11->edges[dht11->num_edges++].value =
> - gpio_get_value(dht11->gpio);
> -
> - if (dht11->num_edges >= DHT11_EDGES_PER_READ)
> - complete(&dht11->completion);
> - }
> -
> - return IRQ_HANDLED;
> -}
> -
>  static const struct iio_chan_spec dht11_chan_spec[] = {
>   { .type = IIO_TEMP,
>   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), },
> @@ -260,11 +269,6 @@ static int dht11_probe(struct platform_device
*pdev)
>   dev_err(dev, "GPIO %d has no interrupt\n", dht11->gpio);
>   return -EINVAL;
>   }
> - ret = devm_request_irq(dev, dht11->irq, dht11_handle_irq,
> - IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
> - pdev->name, iio);
> - if (ret)
> - return ret;
>  
>   dht11->timestamp = iio_get_time_ns() - DHT11_DATA_VALID_TIME - 1;
>   dht11->num_edges = -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] staging: lustre: replace static value with define

[Dilger, Andreas]

On 2014/12/06, 12:16 AM, "Tristan Lelong"  wrote:

>This patch replace the value '80' used in several files in the lustre
>source code
>with a define LUSTRE_MDT_MAXNAMELEN.
>
>This value is used in 4 different structures as the maximum len for a
>service name.
>According to the comments, these names follow a convention which make it
>possible
>to use the same define for LCS, LSS, LCF, and LSF names.
>
>Signed-off-by: Tristan Lelong 
>---
>Note:
>   This modification answers Joe Perches suggestion:
>https://lkml.org/lkml/2014/12/5/107
>   The patch has to be applied on top of https://lkml.org/lkml/2014/12/6/17
>---
> drivers/staging/lustre/lustre/fld/fld_internal.h  | 2 +-
> drivers/staging/lustre/lustre/fld/lproc_fld.c | 2 +-
> drivers/staging/lustre/lustre/include/lustre/lustre_idl.h | 5 +
> drivers/staging/lustre/lustre/include/lustre_fid.h| 4 ++--
> drivers/staging/lustre/lustre/include/lustre_fld.h| 4 ++--
> 5 files changed, 11 insertions(+), 6 deletions(-)
>
>diff --git a/drivers/staging/lustre/lustre/fld/fld_internal.h
>b/drivers/staging/lustre/lustre/fld/fld_internal.h
>index 8806b60..6125bbe 100644
>--- a/drivers/staging/lustre/lustre/fld/fld_internal.h
>+++ b/drivers/staging/lustre/lustre/fld/fld_internal.h
>@@ -111,7 +111,7 @@ struct fld_cache {
> 
>   /**
>* Cache name used for debug and messages. */
>-  char fci_name[80];
>+  char fci_name[LUSTRE_MDT_MAXNAMELEN];
>   unsigned int fci_no_shrink:1;
> };
> 
>diff --git a/drivers/staging/lustre/lustre/fld/lproc_fld.c
>b/drivers/staging/lustre/lustre/fld/lproc_fld.c
>index 74b4db9..7a55941 100644
>--- a/drivers/staging/lustre/lustre/fld/lproc_fld.c
>+++ b/drivers/staging/lustre/lustre/fld/lproc_fld.c
>@@ -96,7 +96,7 @@ fld_proc_hash_seq_write(struct file *file,
>   char *name;
>   int i;
> 
>-  if (count > 80)
>+  if (count > LUSTRE_MDT_MAXNAMELEN)
>   return -ENAMETOOLONG;

Sorry for the late reply, but this has nothing to do with an MDT service
name, so using this #define is misleading here.  As I wrote in my other
email, this only needs to be at most 8 characters.

Cheers, Andreas

> 
>   name = kmalloc(count, GFP_KERNEL);
>diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
>b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
>index 7b7457c..305ecbe 100644
>--- a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
>+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
>@@ -105,6 +105,11 @@
>  * FOO_BULK_PORTALis for incoming bulk on the FOO
>  */
> 
>+/* Lustre service names are following the format
>+ * service name + MDT + seq name
>+ */
>+#define LUSTRE_MDT_MAXNAMELEN 80
>+
> #define CONNMGR_REQUEST_PORTAL  1
> #define CONNMGR_REPLY_PORTAL  2
> //#define OSC_REQUEST_PORTAL  3
>diff --git a/drivers/staging/lustre/lustre/include/lustre_fid.h
>b/drivers/staging/lustre/lustre/include/lustre_fid.h
>index 2d6fbb4..0a0929f 100644
>--- a/drivers/staging/lustre/lustre/include/lustre_fid.h
>+++ b/drivers/staging/lustre/lustre/include/lustre_fid.h
>@@ -358,7 +358,7 @@ struct lu_client_seq {
>* Service uuid, passed from MDT + seq name to form unique seq name to
>* use it with procfs.
>*/
>-  charlcs_name[80];
>+  charlcs_name[LUSTRE_MDT_MAXNAMELEN];
> 
>   /*
>* Sequence width, that is how many objects may be allocated in one
>@@ -408,7 +408,7 @@ struct lu_server_seq {
>* Service uuid, passed from MDT + seq name to form unique seq name to
>* use it with procfs.
>*/
>-  charlss_name[80];
>+  charlss_name[LUSTRE_MDT_MAXNAMELEN];
> 
>   /*
>* Allocation chunks for super and meta sequences. Default values are
>diff --git a/drivers/staging/lustre/lustre/include/lustre_fld.h
>b/drivers/staging/lustre/lustre/include/lustre_fld.h
>index 64c5048..5ee4b1e 100644
>--- a/drivers/staging/lustre/lustre/include/lustre_fld.h
>+++ b/drivers/staging/lustre/lustre/include/lustre_fld.h
>@@ -93,7 +93,7 @@ struct lu_server_fld {
> 
>   /**
>* Fld service name in form "fld-srv-lustre-MDTXXX" */
>-  char lsf_name[80];
>+  char lsf_name[LUSTRE_MDT_MAXNAMELEN];
> 
> };
> 
>@@ -124,7 +124,7 @@ struct lu_client_fld {
> 
>   /**
>* Client fld proc entry name. */
>-  char lcf_name[80];
>+  char lcf_name[LUSTRE_MDT_MAXNAMELEN];
> 
>   int   lcf_flags;
> };
>-- 
>2.1.1
>
>


Cheers, Andreas
-- 
Andreas Dilger

Lustre Software Architect
Intel High Performance Data Division


--
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

Re: [PATCH] staging: lustre: fix sparse warning on LPROC_SEQ_FOPS macros

[Dilger, Andreas]

On 2014/12/05, 3:41 PM, "Tristan Lelong"  wrote:

>On Fri, Dec 05, 2014 at 01:27:23PM -0800, Greg KH wrote:
>> On Fri, Dec 05, 2014 at 12:03:47AM -0800, Tristan Lelong wrote:
>> >  static ssize_t
>> > -fld_proc_hash_seq_write(struct file *file, const char *buffer,
>> > -  size_t count, loff_t *off)
>> > +fld_proc_hash_seq_write(struct file *file,
>> > +  const char __user *buffer,
>> > +  size_t count, loff_t *off)
>> >  {
>> >struct lu_client_fld *fld;
>> >struct lu_fld_hash *hash = NULL;
>> > +  char name[80];
>> >int i;
>> >  
>> > +  if (count > 80)
>> > +  return -ENAMETOOLONG;
>> > +
>> > +  if (copy_from_user(name, buffer, count) != 0)
>> > +  return -EFAULT;
>> 
>> How was this code ever working before?
>
>I have no idea, and was actually surprised that this was there.
>
>> 
>> And I know Joe asked, but how do you know that 80 is ok?  And why on the
>> stack?
>
>80 is the sizeof(struct lu_fld_hash.fh_name) and there is no define for
>that.  A few other structure members are using this 80 value internally,
>and as I told Joe, I will analyze if they are all related and submit a
>patch to use a define instead.

Sorry, but I don't see where you get 80 from?  fh_name is declared as a
"const char *", and initialized in the declaration of fld_hash[].  I'd
thought to reply that sizeof(fh_name) would even be better than a #define,
but sizeof(const char *) doesn't actually make sense.

The longest declared fh_name is 4 characters, but I'm not sure of an easy
way to determine this at compile time.  I guess one option is to change
the declaration of struct lu_fld_hash to use "const char fh_name[4];" and
then use sizeof(fh_name), but I don't know if that is better than just
declaring a small buffer (8 chars) for this usage.  IMHO that is small
enough to fit on the stack, since it is at the top of a very short
callchain (userspace->sys_write->vfs_write->fld_proc_hash_seq_write())
that just saves the value so the chance of stack overflow is basically nil.

>> 
>> Shouldn't you just compare count to strlen(fld_hash[i].fh_name)? like
>>you
>> do later on?
>> 
>
>This is actually done in the for loop already. I first compare with the
>maximum size, then the loop use the strlen of each entries in the table,
>and finally does the strncmp.
>
>> 
>> Anyway, I don't like large stack variables like this, can you make it
>> dynamic instead?
>> 
>
>I can definitely do this with a kmalloc, I'll submit a v2 tonight.
>
>Thanks
>


Cheers, Andreas
-- 
Andreas Dilger

Lustre Software Architect
Intel High Performance Data Division


--
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] mm: memcontrol.c: Cleaning up function that are not used anywhere

[Rickard Strandqvist]

Remove function mem_cgroup_lru_names_not_uptodate() that is not used anywhere.
And move BUILD_BUG_ON() to the beginning of memcg_stat_show() instead.

This was partially found by using a static code analysis program called 
cppcheck.

Signed-off-by: Rickard Strandqvist 
---
 mm/memcontrol.c |7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index d6ac0e3..5e2f0f3 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4379,17 +4379,14 @@ static int memcg_numa_stat_show(struct seq_file *m, 
void *v)
 }
 #endif /* CONFIG_NUMA */
 
-static inline void mem_cgroup_lru_names_not_uptodate(void)
-{
-   BUILD_BUG_ON(ARRAY_SIZE(mem_cgroup_lru_names) != NR_LRU_LISTS);
-}
-
 static int memcg_stat_show(struct seq_file *m, void *v)
 {
struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
struct mem_cgroup *mi;
unsigned int i;
 
+   BUILD_BUG_ON(ARRAY_SIZE(mem_cgroup_lru_names) != NR_LRU_LISTS);
+
for (i = 0; i < MEM_CGROUP_STAT_NSTATS; i++) {
if (i == MEM_CGROUP_STAT_SWAP && !do_swap_account)
continue;
-- 
1.7.10.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 V4 1/1] Drivers: hv: vmbus: Implement a clockevent device

[K. Y. Srinivasan]

Implement a clockevent device based on the timer support available on
Hyper-V.
In this version of the patch I have addressed Jason's review comments.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Jason Wang 
---
 arch/x86/include/uapi/asm/hyperv.h |   11 +
 drivers/hv/hv.c|   78 
 drivers/hv/hyperv_vmbus.h  |   21 ++
 drivers/hv/vmbus_drv.c |   37 -
 4 files changed, 145 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/uapi/asm/hyperv.h 
b/arch/x86/include/uapi/asm/hyperv.h
index 462efe7..90c458e 100644
--- a/arch/x86/include/uapi/asm/hyperv.h
+++ b/arch/x86/include/uapi/asm/hyperv.h
@@ -187,6 +187,17 @@
 #define HV_X64_MSR_SINT14  0x409E
 #define HV_X64_MSR_SINT15  0x409F
 
+/*
+ * Synthetic Timer MSRs. Four timers per vcpu.
+ */
+#define HV_X64_MSR_STIMER0_CONFIG  0x40B0
+#define HV_X64_MSR_STIMER0_COUNT   0x40B1
+#define HV_X64_MSR_STIMER1_CONFIG  0x40B2
+#define HV_X64_MSR_STIMER1_COUNT   0x40B3
+#define HV_X64_MSR_STIMER2_CONFIG  0x40B4
+#define HV_X64_MSR_STIMER2_COUNT   0x40B5
+#define HV_X64_MSR_STIMER3_CONFIG  0x40B6
+#define HV_X64_MSR_STIMER3_COUNT   0x40B7
 
 #define HV_X64_MSR_HYPERCALL_ENABLE0x0001
 #define HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT12
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 3e4235c..50e51a5 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -28,7 +28,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include "hyperv_vmbus.h"
 
 /* The one and only */
@@ -37,6 +39,10 @@ struct hv_context hv_context = {
.hypercall_page = NULL,
 };
 
+#define HV_TIMER_FREQUENCY (10 * 1000 * 1000) /* 100ns period */
+#define HV_MAX_MAX_DELTA_TICKS 0x
+#define HV_MIN_DELTA_TICKS 1
+
 /*
  * query_hypervisor_info - Get version info of the windows hypervisor
  */
@@ -144,6 +150,8 @@ int hv_init(void)
   sizeof(int) * NR_CPUS);
memset(hv_context.event_dpc, 0,
   sizeof(void *) * NR_CPUS);
+   memset(hv_context.clk_evt, 0,
+  sizeof(void *) * NR_CPUS);
 
max_leaf = query_hypervisor_info();
 
@@ -258,10 +266,63 @@ u16 hv_signal_event(void *con_id)
return status;
 }
 
+static int hv_ce_set_next_event(unsigned long delta,
+   struct clock_event_device *evt)
+{
+   cycle_t current_tick;
+
+   WARN_ON(evt->mode != CLOCK_EVT_MODE_ONESHOT);
+
+   rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
+   current_tick += delta;
+   wrmsrl(HV_X64_MSR_STIMER0_COUNT, current_tick);
+   return 0;
+}
+
+static void hv_ce_setmode(enum clock_event_mode mode,
+ struct clock_event_device *evt)
+{
+   union hv_timer_config timer_cfg;
+
+   switch (mode) {
+   case CLOCK_EVT_MODE_PERIODIC:
+   /* unsupported */
+   break;
+
+   case CLOCK_EVT_MODE_ONESHOT:
+   timer_cfg.enable = 1;
+   timer_cfg.auto_enable = 1;
+   timer_cfg.sintx = VMBUS_MESSAGE_SINT;
+   wrmsrl(HV_X64_MSR_STIMER0_CONFIG, timer_cfg.as_uint64);
+   break;
+
+   case CLOCK_EVT_MODE_UNUSED:
+   case CLOCK_EVT_MODE_SHUTDOWN:
+   wrmsrl(HV_X64_MSR_STIMER0_COUNT, 0);
+   wrmsrl(HV_X64_MSR_STIMER0_CONFIG, 0);
+   break;
+   case CLOCK_EVT_MODE_RESUME:
+   break;
+   }
+}
+
+static void hv_init_clockevent_device(struct clock_event_device *dev, int cpu)
+{
+   dev->name = "Hyper-V clockevent";
+   dev->features = CLOCK_EVT_FEAT_ONESHOT;
+   dev->cpumask = cpumask_of(cpu);
+   dev->rating = 1000;
+   dev->owner = THIS_MODULE;
+
+   dev->set_mode = hv_ce_setmode;
+   dev->set_next_event = hv_ce_set_next_event;
+}
+
 
 int hv_synic_alloc(void)
 {
size_t size = sizeof(struct tasklet_struct);
+   size_t ced_size = sizeof(struct clock_event_device);
int cpu;
 
for_each_online_cpu(cpu) {
@@ -272,6 +333,13 @@ int hv_synic_alloc(void)
}
tasklet_init(hv_context.event_dpc[cpu], vmbus_on_event, cpu);
 
+   hv_context.clk_evt[cpu] = kzalloc(ced_size, GFP_ATOMIC);
+   if (hv_context.clk_evt[cpu] == NULL) {
+   pr_err("Unable to allocate clock event device\n");
+   goto err;
+   }
+   hv_init_clockevent_device(hv_context.clk_evt[cpu], cpu);
+
hv_context.synic_message_page[cpu] =
(void *)get_zeroed_page(GFP_ATOMIC);
 
@@ -305,6 +373,7 @@ err:
 static void hv_synic_free_cpu(int cpu)
 {
kfree(hv_context.event_dpc[cpu]);
+   kfree(hv_context.clk_evt[cpu]);
if (hv_context.synic_event_pag

Re: frequent lockups in 3.18rc4

[Martin van Es]

Hi,

I've been following this thread with some interrest because my mythtv
based media centre suffered from sudden freezes. I thought I had tried
everything to solve the problem (including exchanging hardware) until
I caught the slashdot article discussing this bug. I was running on
3.17.3 and and experienced daily freezes while watching DVB-C recorded
H.264 (HD) video, both live and pre-recorded streams. Both using VAAPI
GPU accelaration and CPU decoding. Ever since downgrading to 3.16.7 my
system has been solid as a rock again.

The load on this machine is marginal. Most playback is done using GPU
and other than that, the main load is hammering at most 2 HD
(1G/10mins) streams to SSD. When idle, the system crawls DVB channels
for EPG info. Crashes happened mostly while watching TV and ~5 minutes
after a background recording started or after a couple of hours
watching live TV, but were very hard to trigger. When freezing the
system was completely inaccessible, without any panic logging on (ssh
remote connected) console. I have never been able to find any evidence
in old logs after reboot. The freezes happened both with and without
NMI watchdog enabled.

Hardware is J1900 BayTrail (ValleyView) based ASRock miniITX board.
The DVB-C card requires out-of-tree built ddbridge drivers
(~endriss/media_build_expermintal) so the kernels (both stable and
unstable) are tainted I guess?

I'm a moderately experienced Linux user. I do build my own kernels,
but am not very knowledgable about the inner workings you guys are
discussing here. The system is a (family) production device so there
is not a lot of room for testing, let alone bisecting. I do now have a
spare J1900 lying around, so there is opportunity to build a dedicated
test system if needed.

Hope this may help in finding the right direction for this bug?

Regards,
Martin
-- 
If 'but' was any useful, it would be a logic operator
--
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/1] Drivers: hv: vmbus: Implement a clockevent device

[KY Srinivasan]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Friday, December 5, 2014 9:08 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; jasow...@redhat.com
> Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Implement a clockevent device
> 
> On Fri, Dec 05, 2014 at 07:58:44PM -0800, K. Y. Srinivasan wrote:
> > Implement a clockevent device based on the timer support available on
> > Hyper-V.
> > In this version of the patch I have addressed Jason's review comments.
> >
> > Signed-off-by: K. Y. Srinivasan 
> > Reviewed-by: Jason Wang 
> > ---
> 
> Why did you resend the 1st version of this patch?
> 
> If you didn't send the first version, why is there no more "vX" on the Subject
> line?
> 
> confused.

Greg,

Sorry, please drop this. I will resend with the correct version number in the 
subject line.

Regards,

K. Y
> 
> 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/

Re: [PATCH] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures

[Chen Gang]

Hello Maintainers:

After this patch, our parisc can pass allmodconfig in linux next tree,
for me, we can say parisc specific code have no touch for allmodconfig.
:-)

But for parisc gcc latest upstream compiler, I found several issues, and
I shall try to analyse them and communicate with gcc related members.

And I also want to consult about parisc assembly instructions, I can not
find the related reference documents, could you help to have a check (or
provide some related information for it)? related contents are below:

  parisc support several store instructions: 'stb' (for store byte),
  'stw(m)' (for store word), and 'std' (for store double word).

  They should be in the same format in binary code, and have neighbour
  numbers, and 'stw(m)' need be in the middle of 'stb' and 'std'. one
  sample for the instruction 'inst' (it is 'unsigned int'):

   - for ((inst >> 26) != 0x3):

 stb: 0x18, or 0x19,
 stw: 0x1a, stwm: 0x1b,
 std: 0x1c.

   - else ((inst >> 26) == 0x3), need check '(inst >> 6) & 0xf':

 stb: 0x08, or 0x09,
 stw: 0x0a,
 std: 0x0b.

  it is about my binutils/gdb patch for parisc, gdb want to recognize
  'st??' to find the position for saving relate context (registers).


Welcome any suggestions, ideas, and completions.

Thanks.


On 12/06/2014 06:00 AM, Chen Gang wrote:
> On 12/05/2014 02:54 PM, Minchan Kim wrote:
>> On Fri, Dec 05, 2014 at 06:58:29AM +0800, Chen Gang wrote:
>>> For uapi, need try to let all macros have same value, and MADV_FREE is
>>> added into main branch recently, so need redefine MADV_FREE for it.
>>>
>>> At present, '8' can be shared with all architectures, so redefine it to
>>> '8'.
>>>
>>> Signed-off-by: Chen Gang 
>>
>>
>> Hello Chen,
>>
>> Thanks for looking at this.
>> Feel free to add my sign.
>>
>> Acked-by: Minchan Kim 
>>
> 
> OK, thanks.
> 
> Originally I sent the same patch like you sent (but later than yours).
> Geert suggested to use same value for MADV_FREE, and Carlos confirmed
> it and suggested more things (sorry, I forgot to Cc them in this mail).
> 
> 
> Thanks.
> 


-- 
Chen Gang

Open share and attitude like air water and life which God blessed
--
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/3] x86, microcode: Reload microcode on resume

[Borislav Petkov]

From: Borislav Petkov 

Normally, we do reapply microcode on resume. However, in the cases where
that microcode comes from the early loader and the late loader hasn't
been utilized yet, there's no easy way for us to go and apply the patch
applied during boot by the early loader.

Thus, reuse the patch stashed by the early loader for the BSP.

Signed-off-by: Borislav Petkov 
---
 arch/x86/include/asm/microcode.h|  2 ++
 arch/x86/include/asm/microcode_amd.h|  2 ++
 arch/x86/include/asm/microcode_intel.h  |  2 ++
 arch/x86/kernel/cpu/microcode/amd_early.c   | 18 +++
 arch/x86/kernel/cpu/microcode/core.c|  8 +
 arch/x86/kernel/cpu/microcode/core_early.c  | 21 +
 arch/x86/kernel/cpu/microcode/intel_early.c | 47 +++--
 7 files changed, 84 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h
index 64dc362506b7..201b520521ed 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -78,6 +78,7 @@ static inline void __exit exit_amd_microcode(void) {}
 extern void __init load_ucode_bsp(void);
 extern void load_ucode_ap(void);
 extern int __init save_microcode_in_initrd(void);
+void reload_early_microcode(void);
 #else
 static inline void __init load_ucode_bsp(void) {}
 static inline void load_ucode_ap(void) {}
@@ -85,6 +86,7 @@ static inline int __init save_microcode_in_initrd(void)
 {
return 0;
 }
+static inline void reload_early_microcode(void) {}
 #endif
 
 #endif /* _ASM_X86_MICROCODE_H */
diff --git a/arch/x86/include/asm/microcode_amd.h 
b/arch/x86/include/asm/microcode_amd.h
index 48a48024ebe4..af935397e053 100644
--- a/arch/x86/include/asm/microcode_amd.h
+++ b/arch/x86/include/asm/microcode_amd.h
@@ -68,10 +68,12 @@ extern u8 amd_ucode_patch[PATCH_MAX_SIZE];
 extern void __init load_ucode_amd_bsp(void);
 extern void load_ucode_amd_ap(void);
 extern int __init save_microcode_in_initrd_amd(void);
+void reload_ucode_amd(void);
 #else
 static inline void __init load_ucode_amd_bsp(void) {}
 static inline void load_ucode_amd_ap(void) {}
 static inline int __init save_microcode_in_initrd_amd(void) { return -EINVAL; }
+void reload_ucode_amd(void) {}
 #endif
 
 #endif /* _ASM_X86_MICROCODE_AMD_H */
diff --git a/arch/x86/include/asm/microcode_intel.h 
b/arch/x86/include/asm/microcode_intel.h
index bbe296e0bce1..dd4c20043ce7 100644
--- a/arch/x86/include/asm/microcode_intel.h
+++ b/arch/x86/include/asm/microcode_intel.h
@@ -68,11 +68,13 @@ extern void __init load_ucode_intel_bsp(void);
 extern void load_ucode_intel_ap(void);
 extern void show_ucode_info_early(void);
 extern int __init save_microcode_in_initrd_intel(void);
+void reload_ucode_intel(void);
 #else
 static inline __init void load_ucode_intel_bsp(void) {}
 static inline void load_ucode_intel_ap(void) {}
 static inline void show_ucode_info_early(void) {}
 static inline int __init save_microcode_in_initrd_intel(void) { return 
-EINVAL; }
+static inline void reload_ucode_intel(void) {}
 #endif
 
 #if defined(CONFIG_MICROCODE_INTEL_EARLY) && defined(CONFIG_HOTPLUG_CPU)
diff --git a/arch/x86/kernel/cpu/microcode/amd_early.c 
b/arch/x86/kernel/cpu/microcode/amd_early.c
index 3d988a30a21d..737737edbd1e 100644
--- a/arch/x86/kernel/cpu/microcode/amd_early.c
+++ b/arch/x86/kernel/cpu/microcode/amd_early.c
@@ -402,3 +402,21 @@ int __init save_microcode_in_initrd_amd(void)
 
return retval;
 }
+
+void reload_ucode_amd(void)
+{
+   struct microcode_amd *mc;
+   u32 rev, eax;
+
+   rdmsr(MSR_AMD64_PATCH_LEVEL, rev, eax);
+
+   mc = (struct microcode_amd *)amd_ucode_patch;
+
+   if (mc && rev < mc->hdr.patch_id) {
+   if (!__apply_microcode_amd(mc)) {
+   ucode_new_rev = mc->hdr.patch_id;
+   pr_info("microcode: reload patch_level=0x%08x\n",
+   ucode_new_rev);
+   }
+   }
+}
diff --git a/arch/x86/kernel/cpu/microcode/core.c 
b/arch/x86/kernel/cpu/microcode/core.c
index ebd232d7de4d..15c29096136b 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -466,13 +466,7 @@ static void mc_bp_resume(void)
if (uci->valid && uci->mc)
microcode_ops->apply_microcode(cpu);
else if (!uci->mc)
-   /*
-* We might resume and not have applied late microcode but still
-* have a newer patch stashed from the early loader. We don't
-* have it in uci->mc so we have to load it the same way we're
-* applying patches early on the APs.
-*/
-   load_ucode_ap();
+   reload_early_microcode();
 }
 
 static struct syscore_ops mc_syscore_ops = {
diff --git a/arch/x86/kernel/cpu/microcode/core_early.c 
b/arch/x86/kernel/cpu/microcode/core_early.c
index 2c017f242a78..d45df4bd16ab 100644
--- a/arch/x86/kernel/cpu/microcode/c

[PATCH 1/3] x86, microcode, intel: Drop unused parameter

[Borislav Petkov]

From: Borislav Petkov 

apply_microcode_early() doesn't use mc_saved_data, kill it.

Signed-off-by: Borislav Petkov 
---
 arch/x86/kernel/cpu/microcode/intel_early.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/microcode/intel_early.c 
b/arch/x86/kernel/cpu/microcode/intel_early.c
index b88343f7a3b3..31e7576a123c 100644
--- a/arch/x86/kernel/cpu/microcode/intel_early.c
+++ b/arch/x86/kernel/cpu/microcode/intel_early.c
@@ -650,8 +650,7 @@ static inline void print_ucode(struct ucode_cpu_info *uci)
 }
 #endif
 
-static int apply_microcode_early(struct mc_saved_data *mc_saved_data,
-struct ucode_cpu_info *uci)
+static int apply_microcode_early(struct ucode_cpu_info *uci)
 {
struct microcode_intel *mc_intel;
unsigned int val[2];
@@ -720,7 +719,7 @@ _load_ucode_intel_bsp(struct mc_saved_data *mc_saved_data,
   mc_saved_in_initrd, uci);
load_microcode(mc_saved_data, mc_saved_in_initrd,
   initrd_start_early, uci);
-   apply_microcode_early(mc_saved_data, uci);
+   apply_microcode_early(uci);
 }
 
 void __init
@@ -783,5 +782,5 @@ void load_ucode_intel_ap(void)
collect_cpu_info_early(&uci);
load_microcode(mc_saved_data_p, mc_saved_in_initrd_p,
   initrd_start_addr, &uci);
-   apply_microcode_early(mc_saved_data_p, &uci);
+   apply_microcode_early(&uci);
 }
-- 
2.0.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 0/3] x86, microcode: Reloading fixes

[Borislav Petkov]

From: Borislav Petkov 

Hi guys,

please pull three fixes for the microcode loader. More specifically,
microcode reloading for 3.19. Patches are against tip/x86/microcode.

I have this also as a tag if you'd prefer to pull:

git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git 
tags/microcode_fixes_for_3.19

This will have a conflict when merging into Linus' tree after
tip/x86/urgent has went in for 3.18 but resolving it should be easy. The
final result should be this with the ifdef dropped:

---
diff --git a/arch/x86/kernel/cpu/microcode/core.c 
b/arch/x86/kernel/cpu/microcode/core.c
index 08fe6e8a726e..15c29096136b 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -465,16 +465,8 @@ static void mc_bp_resume(void)
 
if (uci->valid && uci->mc)
microcode_ops->apply_microcode(cpu);
-#ifdef CONFIG_X86_64
else if (!uci->mc)
-   /*
-* We might resume and not have applied late microcode but still
-* have a newer patch stashed from the early loader. We don't
-* have it in uci->mc so we have to load it the same way we're
-* applying patches early on the APs.
-*/
-   load_ucode_ap();
-#endif
+   reload_early_microcode();
 }
--

Thanks.

Boris Ostrovsky (1):
  x86, microcode: Don't initialize microcode code on paravirt

Borislav Petkov (2):
  x86, microcode, intel: Drop unused parameter
  x86, microcode: Reload microcode on resume

 arch/x86/include/asm/microcode.h|  2 ++
 arch/x86/include/asm/microcode_amd.h|  2 ++
 arch/x86/include/asm/microcode_intel.h  |  2 ++
 arch/x86/kernel/cpu/microcode/amd_early.c   | 18 +++
 arch/x86/kernel/cpu/microcode/core.c| 10 ++
 arch/x86/kernel/cpu/microcode/core_early.c  | 21 +
 arch/x86/kernel/cpu/microcode/intel_early.c | 48 +++--
 7 files changed, 85 insertions(+), 18 deletions(-)

-- 
2.0.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 2/3] x86, microcode: Don't initialize microcode code on paravirt

[Borislav Petkov]

From: Boris Ostrovsky 

Paravirtual guests are not expected to load microcode into processors
and therefore it is not necessary to initialize microcode loading
logic.

In fact, under certain circumstances initializing this logic may cause
the guest to crash. Specifically, 32-bit kernels use __pa_nodebug()
macro which does not work in Xen (the code path that leads to this macro
happens during resume when we call mc_bp_resume()->load_ucode_ap()
->check_loader_disabled_ap())

Signed-off-by: Boris Ostrovsky 
Link: 
http://lkml.kernel.org/r/1417469264-31470-1-git-send-email-boris.ostrov...@oracle.com
Signed-off-by: Borislav Petkov 
---
 arch/x86/kernel/cpu/microcode/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/microcode/core.c 
b/arch/x86/kernel/cpu/microcode/core.c
index 2ce9051174e6..ebd232d7de4d 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -557,7 +557,7 @@ static int __init microcode_init(void)
struct cpuinfo_x86 *c = &cpu_data(0);
int error;
 
-   if (dis_ucode_ldr)
+   if (paravirt_enabled() || dis_ucode_ldr)
return 0;
 
if (c->x86_vendor == X86_VENDOR_INTEL)
-- 
2.0.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: Disable input device

[Chuck Ebbert]

On Sat, 29 Nov 2014 18:24:03 +0100
Pali Rohár  wrote:

> What do you think about adding new sysfs file "disable" (accept 
> values 1 or 0) for every input device? With "1" it cause that 
> kernel will drop all events from specific input device and if 
> driver provide some function is can be called (e.g. for power 
> management or disabling device at hardware level).
> 

Yeah, I'd like to see this too. I am using xinput to disable the
notebook keyboard so the cats walking across it don't cause any
problems. It would be nice to have a better solution.
--
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.12 10/66] PCI/MSI: Return msix_capability_init() failure if populate_msi_sysfs() fails

[Jiri Slaby]

From: Alexander Gordeev 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 2adc7907bac2c72535894732c4b41f9210f9e577 upstream.

If populate_msi_sysfs() function failed msix_capability_init() must return
the error code, but it returns the success instead.  This update fixes the
described misbehaviour.

Signed-off-by: Alexander Gordeev 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Tejun Heo 

Signed-off-by: Jiri Slaby 
---
 drivers/pci/msi.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index d5f90d6383bc..b43f391dc8b6 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -719,7 +719,7 @@ static int msix_capability_init(struct pci_dev *dev,
 
ret = arch_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSIX);
if (ret)
-   goto error;
+   goto out_avail;
 
/*
 * Some devices require MSI-X to be enabled before we can touch the
@@ -732,10 +732,8 @@ static int msix_capability_init(struct pci_dev *dev,
msix_program_entries(dev, entries);
 
ret = populate_msi_sysfs(dev);
-   if (ret) {
-   ret = 0;
-   goto error;
-   }
+   if (ret)
+   goto out_free;
 
/* Set MSI-X enabled bits and unmask the function */
pci_intx_for_msi(dev, 0);
@@ -746,7 +744,7 @@ static int msix_capability_init(struct pci_dev *dev,
 
return 0;
 
-error:
+out_avail:
if (ret < 0) {
/*
 * If we had some success, report the number of irqs
@@ -763,6 +761,7 @@ error:
ret = avail;
}
 
+out_free:
free_msi_irqs(dev);
 
return ret;
-- 
2.1.3

--
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/