Re: [PATCH v3 3/3] Staging: rtl8188eu: Bool tests don't need comparisons
On Sun, 13 Sep 2015, Shraddha Barke wrote: > > > On Sat, Sep 12, 2015 at 11:07 PM, Julia Lawall > wrote: > > > On Sat, 12 Sep 2015, Shraddha Barke wrote: > > > This patch removes comparisons to true/false values on bool > variables. > > > > Changes in v3- > > Fix made manually > > > > Signed-off-by: Shraddha Barke > > --- > > drivers/staging/rtl8188eu/core/rtw_cmd.c | 12 > +-- > > drivers/staging/rtl8188eu/core/rtw_ioctl_set.c | 28 > +- > > 2 files changed, 20 insertions(+), 20 deletions(-) > > > > diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c > b/drivers/staging/rtl8188eu/core/rtw_cmd.c > > index 001a2f3..591ac5d 100644 > > --- a/drivers/staging/rtl8188eu/core/rtw_cmd.c > > +++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c > > @@ -272,7 +272,7 @@ u8 rtw_sitesurvey_cmd(struct adapter > *padapter, struct ndis_802_11_ssid *ssid, > > struct cmd_priv *pcmdpriv = >cmdpriv; > > struct mlme_priv *pmlmepriv = > >mlmepriv; > > > > - if (check_fwstate(pmlmepriv, _FW_LINKED) == true) > > + if (check_fwstate(pmlmepriv, _FW_LINKED)) > > rtw_lps_ctrl_wk_cmd(padapter, LPS_CTRL_SCAN, > 1); > > > > ph2c = kzalloc(sizeof(struct cmd_obj), GFP_ATOMIC); > > @@ -903,7 +903,7 @@ static void dynamic_chk_wk_hdl(struct > adapter *padapter, u8 *pbuf, int sz) > > pmlmepriv = &(padapter->mlmepriv); > > > > #ifdef CONFIG_88EU_AP_MODE > > - if (check_fwstate(pmlmepriv, WIFI_AP_STATE) == true) > > + if (check_fwstate(pmlmepriv, WIFI_AP_STATE)) > > expire_timeout_chk(padapter); > > #endif > > > > @@ -920,13 +920,13 @@ static void lps_ctrl_wk_hdl(struct > adapter *padapter, u8 lps_ctrl_type) > > u8 mstatus; > > > > > > - if ((check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) > == true) || > > - (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) == > true)) > > + if ((check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE)) > || > > + (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE))) > > You don't need to keep the parentheses. > > julia > > I don't see extra parentheses. Aren't all of them needed to improve > readability? You have basically ((foo(1,2,3)) || (foo(4,5,6))) I don't think that is more readable than (foo(1,2,3) || foo(4,5,6)) Actually, the parentheses weren't really needed before, but they are even less useful now. julia
Re: [PATCH] Input: ad714x: Convert to using managed resources
On Sat, Sep 12, 2015 at 11:52 PM, Dmitry Torokhov
wrote:
> On Sat, Sep 12, 2015 at 08:26:18PM +0530, Vaishali Thakkar wrote:
>> Use managed resource functions devm_request_threaded_irq,
>> devm_inpute_allocate_device and devm_kzalloc to simplify
>> error handling. Also, remove use of input_unregister_device
>> as input_register_device itself handles it and works as
>> resource managed function.
>>
>> To be compatible with the change, various gotos are replaced
>> with direct returns, and unneeded labels are dropped. With
>> these changes remove ad714x_remove and corresponding calls of
>> it as they are now redundant.
>>
>> Signed-off-by: Vaishali Thakkar
>> ---
>> Please note that this patch is having three lines over 80
>> characters as limiting them to 80 characters makes code
>> less readable.
>
> You can actually remove input[input_alloc] and that will allow you to
> stay witing 80 columnts. Does the following version still work for you?
Sure. This makes perfect sense. Thanks.
Can I send v2 of a patch with all changes you suggested or would you
like me to split this patch in 2 patches?
> Thanks.
>
> Input: ad714x - convert to using managed resources
>
> From: Vaishali Thakkar
>
> Use managed resource functions devm_request_threaded_irq,
> devm_inpute_allocate_device and devm_kzalloc to simplify error handling.
> Also, remove use of input_unregister_device as input_register_device itself
> handles it and works as resource managed function.
>
> To be compatible with the change, various gotos are replaced with direct
> returns, and unneeded labels are dropped. With these changes remove
> ad714x_remove and corresponding calls of it as they are now redundant.
>
> Signed-off-by: Vaishali Thakkar
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/input/misc/ad714x-i2c.c | 10 --
> drivers/input/misc/ad714x-spi.c | 10 --
> drivers/input/misc/ad714x.c | 214
> +++
> drivers/input/misc/ad714x.h |1
> 4 files changed, 82 insertions(+), 153 deletions(-)
>
> diff --git a/drivers/input/misc/ad714x-i2c.c b/drivers/input/misc/ad714x-i2c.c
> index 189bdc8..2f04773 100644
> --- a/drivers/input/misc/ad714x-i2c.c
> +++ b/drivers/input/misc/ad714x-i2c.c
> @@ -85,15 +85,6 @@ static int ad714x_i2c_probe(struct i2c_client *client,
> return 0;
> }
>
> -static int ad714x_i2c_remove(struct i2c_client *client)
> -{
> - struct ad714x_chip *chip = i2c_get_clientdata(client);
> -
> - ad714x_remove(chip);
> -
> - return 0;
> -}
> -
> static const struct i2c_device_id ad714x_id[] = {
> { "ad7142_captouch", 0 },
> { "ad7143_captouch", 0 },
> @@ -110,7 +101,6 @@ static struct i2c_driver ad714x_i2c_driver = {
> .pm = _i2c_pm,
> },
> .probe= ad714x_i2c_probe,
> - .remove = ad714x_i2c_remove,
> .id_table = ad714x_id,
> };
>
> diff --git a/drivers/input/misc/ad714x-spi.c b/drivers/input/misc/ad714x-spi.c
> index a79e50b..c8170f0 100644
> --- a/drivers/input/misc/ad714x-spi.c
> +++ b/drivers/input/misc/ad714x-spi.c
> @@ -101,15 +101,6 @@ static int ad714x_spi_probe(struct spi_device *spi)
> return 0;
> }
>
> -static int ad714x_spi_remove(struct spi_device *spi)
> -{
> - struct ad714x_chip *chip = spi_get_drvdata(spi);
> -
> - ad714x_remove(chip);
> -
> - return 0;
> -}
> -
> static struct spi_driver ad714x_spi_driver = {
> .driver = {
> .name = "ad714x_captouch",
> @@ -117,7 +108,6 @@ static struct spi_driver ad714x_spi_driver = {
> .pm = _spi_pm,
> },
> .probe = ad714x_spi_probe,
> - .remove = ad714x_spi_remove,
> };
>
> module_spi_driver(ad714x_spi_driver);
> diff --git a/drivers/input/misc/ad714x.c b/drivers/input/misc/ad714x.c
> index 7a61e9e..84b51dd 100644
> --- a/drivers/input/misc/ad714x.c
> +++ b/drivers/input/misc/ad714x.c
> @@ -960,13 +960,12 @@ static irqreturn_t ad714x_interrupt_thread(int irq,
> void *data)
> return IRQ_HANDLED;
> }
>
> -#define MAX_DEVICE_NUM 8
> struct ad714x_chip *ad714x_probe(struct device *dev, u16 bus_type, int irq,
> ad714x_read_t read, ad714x_write_t write)
> {
> - int i, alloc_idx;
> + int i;
> int error;
> - struct input_dev *input[MAX_DEVICE_NUM];
> + struct input_dev *input;
>
> struct ad714x_platform_data *plat_data = dev_get_platdata(dev);
> struct ad714x_chip *ad714x;
> @@ -982,25 +981,25 @@ struct ad714x_chip *ad714x_probe(struct device *dev,
> u16 bus_type, int irq,
> if (irq <= 0) {
> dev_err(dev, "IRQ not configured!\n");
> error = -EINVAL;
> - goto err_out;
> + return ERR_PTR(error);
> }
>
> if (dev_get_platdata(dev) == NULL) {
> dev_err(dev, "platform data for ad714x doesn't exist\n");
> error = -EINVAL;
> -
[PATCH] Staging: rtl8192u: Remove unnecessary printk
This patch removes the commented printk inside else block as
it is not needed.
Signed-off-by: Shraddha Barke
---
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index 051ec8c..7656e56 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -277,7 +277,6 @@ inline void softmac_mgmt_xmit(struct sk_buff *skb, struct
ieee80211_device *ieee
printk("%s():insert to waitqueue!\n",__func__);
skb_queue_tail(>skb_waitQ[tcb_desc->queue_index],
skb);
} else {
- //printk("TX packet!\n");
ieee->softmac_hard_start_xmit(skb, ieee->dev);
//dev_kfree_skb_any(skb);//edit by thomas
}
--
2.1.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/
[BUG] Kernel error when first driver unbind with empty MMC slot
During testing of these patches [PATCH] mmc: pxamci: fix card detect threaded interrupt [PATCH 1/3] dmaengine: virt-dma: don't always free descriptor upon completion I have found unrelated error. How to reproduce: 1) Remove any SD card 2) No CPLD initial power for card (in magician.c, probably irrelevant) 3) Boot into an initrd filesystem 4) Run command echo -n "pxa2xx-mci.0" > /sys/class/mmc_host/mmc0/device/driver/unbind 5) Error message will be printed: [ 97.877519] irq 39: nobody cared (try booting with the "irqpoll" option) [ 97.884283] CPU: 0 PID: 153 Comm: sh Not tainted 4.2.0-next-20150910-00015-g03de31f-dirty #16 [ 97.892757] Hardware name: HTC Magician [ 97.896726] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 97.904503] [] (show_stack) from [] (__report_bad_irq+0x24/0xb4) [ 97.912221] [] (__report_bad_irq) from [] (note_interrupt+0x250/0x2b4) [ 97.920452] [] (note_interrupt) from [] (handle_irq_event_percpu+0xa8/0x164) [ 97.929195] [] (handle_irq_event_percpu) from [] (handle_irq_event+0x2c/0x40) [ 97.938027] [] (handle_irq_event) from [] (handle_level_irq+0x94/0x118) [ 97.946342] [] (handle_level_irq) from [] (generic_handle_irq+0x20/0x30) [ 97.954739] [] (generic_handle_irq) from [] (__handle_domain_irq+0x4c/0xa4) [ 97.963395] [] (__handle_domain_irq) from [] (ichp_handle_irq+0x28/0x38) [ 97.971794] [] (ichp_handle_irq) from [] (__irq_svc+0x50/0x64) [ 97.979321] Exception stack(0xc23f1de0 to 0xc23f1e28) [ 97.984366] 1de0: c34030e0 0027 c3400220 fffa c34002d4 [ 97.992506] 1e00: 00d0 c15536c0 00ec 0116f2dc 0001 c23f1e34 c0043c48 c01a0504 [ 98.000633] 1e20: 2013 [ 98.004159] [] (__irq_svc) from [] (__radix_tree_lookup+0x60/0xcc) [ 98.012043] [] (__radix_tree_lookup) from [] (free_irq+0x10/0x88) [ 98.019895] [] (free_irq) from [] (pxamci_remove+0xa4/0x154) [ 98.027285] [] (pxamci_remove) from [] (platform_drv_remove+0x18/0x30) [ 98.035578] [] (platform_drv_remove) from [] (__device_release_driver+0x84/0x104) [ 98.044769] [] (__device_release_driver) from [] (device_release_driver+0x1c/0x28) [ 98.054034] [] (device_release_driver) from [] (unbind_store+0x58/0x90) [ 98.062346] [] (unbind_store) from [] (drv_attr_store+0x20/0x2c) [ 98.070103] [] (drv_attr_store) from [] (sysfs_kf_write+0x44/0x48) [ 98.077998] [] (sysfs_kf_write) from [] (kernfs_fop_write+0xec/0x1ac) [ 98.086171] [] (kernfs_fop_write) from [] (__vfs_write+0x2c/0xd8) [ 98.093980] [] (__vfs_write) from [] (vfs_write+0x94/0x150) [ 98.101260] [] (vfs_write) from [] (SyS_write+0x40/0x8c) [ 98.108284] [] (SyS_write) from [] (ret_fast_syscall+0x0/0x38) [ 98.115800] handlers: [ 98.118073] [] pxamci_irq [ 98.121559] Disabling IRQ #39 Error exists in versions before the dmaengine patches was created. Specifically: 1efdb5f0a9243ca8f3460a5ce1b407b06a021f02 Applying the DMA engine patches (list at the beginning of this mail) does not make any change to this bug behavior. Petr Cvek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] UV: NMI: simple dump failover if kdump fails
Subject: [PATCH 2/2] UV: NMI: simple dump failover if kdump fails
The ability to trigger a kdump using the system NMI command
was added by
commit 12ba6c990fab ("x86/UV: Add kdump to UV NMI handler")
Author: Mike Travis
Date: Mon Sep 23 16:25:03 2013 -0500
This is useful because when kdump is working the information gathered
is more informative than the original per CPU stack traces or "dump"
option. However a number of things can go wrong with kdump and then
the stack traces are more useful than nothing.
The two most common reasons for kdump to not be available are:
1) if a problem occurs during boot before the kdump service is
started, or
2) the kdump daemon failed to start.
In either case the call to crash_kexec() returns unexpectedly.
When this happens uv_nmi_kdump() also sets the uv_nmi_kexec_failed
flag which causes the slave CPU's to also return to the NMI handler.
Upon this unexpected return to the NMI handler, the NMI handler
will revert to the "dump" action which uses show_regs() to obtain
a process trace dump for all the CPU's.
Other minor changes:
The "dump" action now generates both the show_regs() stack trace
and show instruction pointer information. Whereas the "ips"
action only shows instruction pointers for non-idle CPU's. This
is more like an abbreviated "ps" display.
Change printk(KERN_DEFAULT...) --> pr_info()
Signed-off-by: George Beshers
Signed-off-by: Mike Travis
Cc: Russ Anderson
Cc: Dimitri Sivanich
Cc: Hedi Berriche
Cc: Alex Thorlton
Cc: Christoph Lameter
diff --git a/arch/x86/platform/uv/uv_nmi.c b/arch/x86/platform/uv/uv_nmi.c
index 5c9f63f..327f21c 100644
--- a/arch/x86/platform/uv/uv_nmi.c
+++ b/arch/x86/platform/uv/uv_nmi.c
@@ -376,38 +376,42 @@ static void uv_nmi_wait(int master)
atomic_read(_nmi_cpus_in_nmi), num_online_cpus());
}
+/* Dump Instruction Pointer header */
static void uv_nmi_dump_cpu_ip_hdr(void)
{
- printk(KERN_DEFAULT
- "\nUV: %4s %6s %-32s %s (Note: PID 0 not listed)\n",
+ pr_info("\nUV: %4s %6s %-32s %s (Note: PID 0 not listed)\n",
"CPU", "PID", "COMMAND", "IP");
}
+/* Dump Instruction Pointer info */
static void uv_nmi_dump_cpu_ip(int cpu, struct pt_regs *regs)
{
- printk(KERN_DEFAULT "UV: %4d %6d %-32.32s ",
- cpu, current->pid, current->comm);
-
+ pr_info("UV: %4d %6d %-32.32s ", cpu, current->pid, current->comm);
printk_address(regs->ip);
}
-/* Dump this cpu's state */
+/*
+ * Dump this CPU's state. If action was set to "kdump" and the crash_kexec
+ * failed, then we provide "dump" as an alternate action. Action "dump" now
+ * also includes the show "ips" (instruction pointers) action whereas the
+ * action "ips" only displays instruction pointers for the non-idle CPU's.
+ * This is an abbreviated form of the "ps" command.
+ */
static void uv_nmi_dump_state_cpu(int cpu, struct pt_regs *regs)
{
const char *dots = " . ";
- if (uv_nmi_action_is("ips")) {
- if (cpu == 0)
- uv_nmi_dump_cpu_ip_hdr();
+ if (cpu == 0)
+ uv_nmi_dump_cpu_ip_hdr();
- if (current->pid != 0)
- uv_nmi_dump_cpu_ip(cpu, regs);
+ if (current->pid != 0 || !uv_nmi_action_is("ips"))
+ uv_nmi_dump_cpu_ip(cpu, regs);
- } else if (uv_nmi_action_is("dump")) {
- printk(KERN_DEFAULT
- "UV:%sNMI process trace for CPU %d\n", dots, cpu);
+ if (uv_nmi_action_is("dump")) {
+ pr_info("UV:%sNMI process trace for CPU %d\n", dots, cpu);
show_regs(regs);
}
+
this_cpu_write(uv_cpu_nmi.state, UV_NMI_STATE_DUMP_DONE);
}
@@ -469,8 +473,7 @@ static void uv_nmi_dump_state(int cpu, struct pt_regs
*regs, int master)
uv_nmi_trigger_dump(tcpu);
}
if (ignored)
- printk(KERN_DEFAULT "UV: %d CPUs ignored NMI\n",
- ignored);
+ pr_alert("UV: %d CPUs ignored NMI\n", ignored);
console_loglevel = saved_console_loglevel;
pr_alert("UV: process trace complete\n");
@@ -492,8 +495,9 @@ static void uv_nmi_touch_watchdogs(void)
touch_nmi_watchdog();
}
-#if defined(CONFIG_KEXEC_CORE)
static atomic_t uv_nmi_kexec_failed;
+
+#if defined(CONFIG_KEXEC_CORE)
static void uv_nmi_kdump(int cpu, int master, struct pt_regs *regs)
{
/* Call crash to dump system state */
@@ -502,10 +506,9 @@ static void uv_nmi_kdump(int cpu, int master, struct
pt_regs *regs)
crash_kexec(regs);
pr_emerg("UV: crash_kexec unexpectedly returned, ");
+ atomic_set(_nmi_kexec_failed, 1);
if (!kexec_crash_image) {
pr_cont("crash kernel not loaded\n");
-
Re: [PATCH v2 09/16] PM / hibernate: Reserve hibernation key and erase footprints
On Wed, Sep 09, 2015 at 01:24:08PM +0100, Matt Fleming wrote:
> On Thu, 27 Aug, at 06:21:44PM, joeyli wrote:
> > On Fri, Aug 21, 2015 at 02:27:53PM +0100, Matt Fleming wrote:
> > > On Tue, 11 Aug, at 02:16:29PM, Lee, Chun-Yi wrote:
> > > > +static int __init init_hibernation_keys(void)
> > > > +{
> > > > + struct hibernation_keys *keys;
> > > > + int ret = 0;
> > > > +
> > > > + if (!keys_phys_addr)
> > > > + return -ENODEV;
> > > > +
> > > > + keys = early_memremap(keys_phys_addr, sizeof(struct
> > > > hibernation_keys));
> > > > +
> > > > + /* Copy hibernation keys to a allocated page */
> > > > + hibernation_keys = (struct hibernation_keys
> > > > *)get_zeroed_page(GFP_KERNEL);
> > > > + if (hibernation_keys) {
> > > > + *hibernation_keys = *keys;
> > > > + } else {
> > > > + pr_err("PM: Allocate hibernation keys page failed\n");
> > > > + ret = -ENOMEM;
> > > > + }
> > >
> > > It seems overkill to allocate an entire page for 28 bytes of data.
> > >
> >
> > Here to allocate an entire page because the basic unit is 'page' when
> > hibernation code checking saveable page that should included/excluded in
> > snapshot image.
> > Allocating an page to hibernation key can clearer to check the page should
> > excluded in snapshot image.
>
> Do other pieces of code do something similar, i.e. allocate an entire
> page because the hibernation code deals with pages? If so, it might be
> possible to lump all these pieces of data together into a single
> 'auxiliary' page.
>
> --
> Matt Fleming, Intel Open Source Technology Center
Thanks for your suggestions, I will lump all these data to into a single page
with the key. I want keep all the contents in the page only for hibernation's
usage but not to share with other subsystem in kernel, that's more safe to avoid
the key be accessed by with other code.
Thanks a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] UV: NMI: insert per_cpu accessor function on uv_hub_nmi.
UV: NMI: insert this_cpu_read accessor function on uv_hub_nmi.
On SGI UV systems a 'power nmi' command from the CMC causes
all processors to drop into uv_handle_nmi(). With the 4.0
kernel this results in
BUG: unable to handle kernel paging request
The bug is caused by the current code trying to use the PER_CPU
variable uv_cpu_nmi.hub without an appropriate accessor function.
That oversight occurred in
commit e16321709c82 ("uv: Replace __get_cpu_var")
Author: Christoph Lameter
Date: Sun Aug 17 12:30:41 2014 -0500
This patch inserts this_cpu_read() in the uv_hub_nmi macro restoring
the intended functionality.
Signed-off-by: George Beshers
Acked-by: Mike Travis
Cc: Russ Anderson
Cc: Dimitri Sivanich
Cc: Hedi Berriche
Cc: Alex Thorlton
Cc: Christoph Lameter
diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
index a00ad8f..ea707478 100644
--- a/arch/x86/include/asm/uv/uv_hub.h
+++ b/arch/x86/include/asm/uv/uv_hub.h
@@ -609,7 +609,7 @@ struct uv_cpu_nmi_s {
DECLARE_PER_CPU(struct uv_cpu_nmi_s, uv_cpu_nmi);
-#define uv_hub_nmi (uv_cpu_nmi.hub)
+#define uv_hub_nmi this_cpu_read(uv_cpu_nmi.hub)
#define uv_cpu_nmi_per(cpu)(per_cpu(uv_cpu_nmi, cpu))
#define uv_hub_nmi_per(cpu)(uv_cpu_nmi_per(cpu).hub)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] net: irda: pxaficp_ir: convert to readl and writel
Dne 12.9.2015 v 13:03 Robert Jarzmik napsal(a): > Petr Cvek writes: > > And it is true I have not tested the rootfs special case, where drivers > are not > yet initialized (and more specifically gpio and interrupt chip). Your > backtrace > should tell me if you fall into this category of issues ... but I > digress, this > has no link with pxaficp. Should I start new thread? (same bug can be present in the FICP too) >>> Yes, this pxamci bothers me, it deserves a thread. >> >> Will start soon. > And I think I see your problem now : > (a) there is a regression from the commit 8c8fe97b2b8a, for which the fix is > here: https://lkml.org/lkml/2015/9/6/112 > (b) for gpio expanders, another fix is here : > https://lkml.org/lkml/2015/9/12/62 > > The regression is on dmaengine, that's where the thread belongs I think, at > least if that fixes your issue. > Great now it finally boots. Thanks. Petr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 06/16] x86/efi: Generating random HMAC key for siging hibernate image
On Wed, Sep 09, 2015 at 01:15:45PM +0100, Matt Fleming wrote:
> On Thu, 27 Aug, at 05:04:52PM, joeyli wrote:
> >
> > The purpose of checking attribute of hibernation key variable is
> > in case someone created a key variable on runtime environment _before_
> > this kernel create boot service variable. That causes EFI stub may load
> > a key that from non-secure environment.
> >
> > That's why delete non-boot service variable and create new one here.
>
> I think bailing is more appropriate in that case, not deleting the
> variable. The environment is not what we expected it to be, so we
> shouldn't tamper with it.
>
> But I don't feel super strongly about this point. I just wanted to
> raise the question of whether it actually makes sense to delete the
> variable that we obviously didn't create or whether it makes more
> sense to refuse to verify hibernation images.
>
Thanks for you point out. But, I want keep this logic to avoid someone
create a runtime variable with the same name-SSID to confuse the key
generator in EFI stub.
> > > > diff --git a/arch/x86/include/asm/suspend.h
> > > > b/arch/x86/include/asm/suspend.h
> > > > index 2fab6c2..ab463c4 100644
> > > > --- a/arch/x86/include/asm/suspend.h
> > > > +++ b/arch/x86/include/asm/suspend.h
> > > > @@ -3,3 +3,12 @@
> > > > #else
> > > > # include
> > > > #endif
> > > > +
> > > > +#ifdef CONFIG_HIBERNATE_VERIFICATION
> > > > +#include
> > > > +
> > > > +struct hibernation_keys {
> > > > + unsigned long hkey_status;
> > > > + u8 hibernation_key[HIBERNATION_DIGEST_SIZE];
> > > > +};
> > > > +#endif
> > >
> > > Have you given any thought to how things are going to work if we
> > > change the hash function in the future, or provide a choice? That
> > > information doesn't appear anywhere in the above struct.
> > >
> >
> > Do you mean the hash function of signing hibernation image changed, so the
> > hibernation key also need to re-generate for new length?
>
> Yeah, that kind of thing.
>
> > I will add a field in struct to forward the length of hibernation key
> > variable.
> > In the future kernel can check the length to handle the change.
>
> Would it also make sense to explicitly record the hash function used
> as well as the length?
>
> --
> Matt Fleming, Intel Open Source Technology Center
The job of key generator in EFI stub is to generate appropriate length of key
for usage by later activities. It doesn't need to know how does kernel use
which kind of hash algorithm, so I think do not need record the hash function.
But, kernel should knows the exactly length of old key to decide if it needs to
use flag to trigger key regeneration process in EFI stub to create new key for
new length.
Only the other hand, the hash algorithm of hibernation was setted in kernel
compiler time even user can change it, so I think to forward the key length
from querying efi variable is enough, don't need write the hash algorithm to
EFI boot variable.
Thanks a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] mfd: s2mps11: Add manual shutdown method for Odroid XU3
Hi Lee,
You acked this patch. However finally it did not go through other tree
so maybe you could pick it up for 4.4?
If you want I could reabse and resend it.
Best regards,
Krzysztof
2015-08-11 19:09 GMT+09:00 Krzysztof Kozlowski :
>
> On Odroid XU3 board (with S2MPS11 PMIC) the PWRHOLD bit in CTRL1
> register must be manually set to 0 before initiating power off sequence.
>
> One of usual power down methods for Exynos based devices looks like:
> 1. PWRHOLD pin of PMIC is connected to PSHOLD of Exynos.
> 2. Exynos holds up this pin during system operation.
> 3. ACOKB pin of PMIC is pulled up to VBATT and optionally to pin in
>other device.
> 4. When PWRHOLD/PSHOLD goes low, the PMIC will turn off the power if
>ACOKB goes high.
>
> On Odroid XU3 family the difference is in (3) - the ACOKB is grounded.
> This means that PMIC must manually set PWRHOLD field to low and then
> wait for signal from Application Processor (the usual change in
> PWRHOLD/PSHOLD pin will actually cut off the power).
>
> The patch adds respective binding allowing Odroid XU3 device to be
> powered off.
>
> Signed-off-by: Krzysztof Kozlowski
> Reported-by: Anand Moon
> Tested-by: Anand Moon
> Reviewed-by: Javier Martinez Canillas
> Acked-by: Lee Jones
>
> ---
>
> Changes since v1:
> 1. Split bindings documentation to separate patch (suggested by Lee).
> 2. Fix additional empty line (suggested by Lee).
> 3. Add Anand's tested-by, Javier's reviewed-by and Lee's acked-by.
>
> Patch is losely based on patch in Hardkernel repository [0] and previous
> work of Anand Moon [1].
>
> [0]
> https://github.com/hardkernel/linux/commit/6897e62ba328bd1c8c095d918101863250cd73e7
> [1] http://www.spinics.net/lists/linux-samsung-soc/msg45959.html
> ---
> drivers/mfd/sec-core.c | 30 ++
> include/linux/mfd/samsung/core.h| 2 ++
> include/linux/mfd/samsung/s2mps11.h | 1 +
> 3 files changed, 33 insertions(+)
>
> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
> index d206a3e8fe87..2d1137a7a0ee 100644
> --- a/drivers/mfd/sec-core.c
> +++ b/drivers/mfd/sec-core.c
> @@ -278,6 +278,8 @@ static struct sec_platform_data
> *sec_pmic_i2c_parse_dt_pdata(
> * not parsed here.
> */
>
> + pd->manual_poweroff = of_property_read_bool(dev->of_node,
> +
> "samsung,s2mps11-acokb-ground");
> return pd;
> }
> #else
> @@ -440,6 +442,33 @@ static int sec_pmic_remove(struct i2c_client *i2c)
> return 0;
> }
>
> +static void sec_pmic_shutdown(struct i2c_client *i2c)
> +{
> + struct sec_pmic_dev *sec_pmic = i2c_get_clientdata(i2c);
> + unsigned int reg, mask;
> +
> + if (!sec_pmic->pdata->manual_poweroff)
> + return;
> +
> + switch (sec_pmic->device_type) {
> + case S2MPS11X:
> + reg = S2MPS11_REG_CTRL1;
> + mask = S2MPS11_CTRL1_PWRHOLD_MASK;
> + break;
> + default:
> + /*
> +* Currently only one board with S2MPS11 needs this, so just
> +* ignore the rest.
> +*/
> + dev_warn(sec_pmic->dev,
> + "Unsupported device %lu for manual power off\n",
> + sec_pmic->device_type);
> + return;
> + }
> +
> + regmap_update_bits(sec_pmic->regmap_pmic, reg, mask, 0);
> +}
> +
> #ifdef CONFIG_PM_SLEEP
> static int sec_pmic_suspend(struct device *dev)
> {
> @@ -491,6 +520,7 @@ static struct i2c_driver sec_pmic_driver = {
> },
> .probe = sec_pmic_probe,
> .remove = sec_pmic_remove,
> + .shutdown = sec_pmic_shutdown,
> .id_table = sec_pmic_id,
> };
>
> diff --git a/include/linux/mfd/samsung/core.h
> b/include/linux/mfd/samsung/core.h
> index 75115384f3fc..aa78957e092f 100644
> --- a/include/linux/mfd/samsung/core.h
> +++ b/include/linux/mfd/samsung/core.h
> @@ -132,6 +132,8 @@ struct sec_platform_data {
> int buck2_init;
> int buck3_init;
> int buck4_init;
> + /* Whether or not manually set PWRHOLD to low during shutdown. */
> + boolmanual_poweroff;
> };
>
> /**
> diff --git a/include/linux/mfd/samsung/s2mps11.h
> b/include/linux/mfd/samsung/s2mps11.h
> index 7981a9d77d3f..b288965e8101 100644
> --- a/include/linux/mfd/samsung/s2mps11.h
> +++ b/include/linux/mfd/samsung/s2mps11.h
> @@ -179,6 +179,7 @@ enum s2mps11_regulators {
> #define S2MPS11_BUCK_N_VOLTAGES (S2MPS11_BUCK_VSEL_MASK + 1)
> #define S2MPS11_RAMP_DELAY 25000 /* uV/us */
>
> +#define S2MPS11_CTRL1_PWRHOLD_MASK BIT(4)
>
> #define S2MPS11_BUCK2_RAMP_SHIFT 6
> #define S2MPS11_BUCK34_RAMP_SHIFT 4
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
mdadm unable to stop RAID device after disk failure
Hi all, I'm having some problems trying to work out how to get mdadm to restart a RAID array after a disk failure. It is refusing to close the array saying it's in use, and it's refusing to let me start the array again saying the devices are already part of another array: $ mdadm --manage /dev/md10 --stop mdadm: Cannot get exclusive access to /dev/md10:Perhaps a running process, mounted filesystem or active volume group? $ mdadm --manage /dev/md10 --fail $ mdadm --manage /dev/md10 --stop mdadm: Cannot get exclusive access to /dev/md10:Perhaps a running process, mounted filesystem or active volume group? $ cat /proc/mdstat Personalities : [raid0] md10 : active raid0 sde1[0] sdd1[1] 5860268032 blocks super 1.2 512k chunks Why is it still telling me the array is active after I have tried to mark it failed? If I try to specifically list one of the devices that make up the array, that doesn't work either: $ mdadm --manage /dev/md10 --fail /dev/sdd1 mdadm: Cannot find /dev/sdd1: No such file or directory This is because /dev/sdd doesn't exist anymore, as it's an external drive so when I replugged it it became /dev/sdf. The manpage says you can use the special word "detached" for this situation, but that doesn't work either: $ mdadm --manage /dev/md10 --fail detached mdadm: set device faulty failed for 8:65: Device or resource busy 8:65 corresponds to /dev/sde1, so it appears to get the right device but why is it busy? Isn't the point of --fail to simulate a drive failure, which could occur at any time, even if a drive is busy? The two disks (sdd and sde) reappeared as sdf and sdg after replugging, so I thought I could just create the array and ignore the old failed one: $ mdadm --assemble /dev/md11 /dev/sdf1 /dev/sdg1 mdadm: Found some drive for an array that is already active: /dev/md/10 mdadm: giving up. I'm not sure how it considers the drive part of an active array, when it's a different device. I guess it's matching serial numbers or something which is wrong in this case. Although it wouldn't be a problem if there was some way to remove the old array that is refusing to die! Is there any way to solve this problem, or do you just have to reboot a machine after a disk failure? Thanks, Adam. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: pxa: add resources to pxaficp_ir
Dne 12.9.2015 v 13:36 Robert Jarzmik napsal(a):
> Add io memory and dma requestor lines to the irda pxa device. This is
> part of the conversion of pxaficp_ir to dmaengine, and to shrink its
> adherence to 'mach' includes.
>
> Signed-off-by: Robert Jarzmik
> Cc: Petr Cvek
> ---
> arch/arm/mach-pxa/devices.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
> index 35434662dc7c..9592667453b0 100644
> --- a/arch/arm/mach-pxa/devices.c
> +++ b/arch/arm/mach-pxa/devices.c
> @@ -394,6 +394,26 @@ static struct resource pxa_ir_resources[] = {
> .end= IRQ_ICP,
> .flags = IORESOURCE_IRQ,
> },
> + [3] = {
> + .start = 0x4080,
> + .end= 0x4080001b,
> + .flags = IORESOURCE_MEM,
> + },
> + [4] = {
> + .start = 0x4070,
> + .end= 0x40700023,
> + .flags = IORESOURCE_MEM,
> + },
> + [5] = {
> + .start = 17,
> + .end= 17,
> + .flags = IORESOURCE_DMA,
> + },
> + [6] = {
> + .start = 18,
> + .end= 18,
> + .flags = IORESOURCE_DMA,
> + },
> };
>
> struct platform_device pxa_device_ficp = {
>
Tested-by: Petr Cvek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] net: irda: pxaficp_ir: convert to readl and writel
Dne 12.9.2015 v 13:45 Robert Jarzmik napsal(a): > Convert the pxa IRDA driver to readl and writel primitives, and remove > another set of direct registers access. This leaves only the DMA > registers access, which will be dealt with dmaengine conversion. > > Signed-off-by: Robert Jarzmik > --- > Since v1: modified __REG macro to cope with STIER, ST* registers > --- > drivers/net/irda/pxaficp_ir.c | 210 > +- > 1 file changed, 126 insertions(+), 84 deletions(-) > > diff --git a/drivers/net/irda/pxaficp_ir.c b/drivers/net/irda/pxaficp_ir.c > index b1794998c68e..4a2b3f71e4a8 100644 > --- a/drivers/net/irda/pxaficp_ir.c > +++ b/drivers/net/irda/pxaficp_ir.c > @@ -29,15 +29,16 @@ > > #include > #include > +#undef __REG > +#define __REG(x) ((x) & 0x) > #include What are future plans for the definitions in the mach/regs-uart.h ? Maybe it would be better to duplicate register definition in ficp source code (it seems that normal PXA UART driver does not use these ones). But random searches shows, that at least base address register: #define STUART STRBR #define STRBR __REG(0x4070) /* Receive Buffer Register (read only) */ is used in machine init source codes. I can look at it in the "near" future (if I don't forget :-D). In other case patchset works, as it has been tested for SIR part. Tested-by: Petr Cvek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
1 new photo on MyDailyFlog!
Hi! I would like you to come and see my latest photos on MyDailyFlog. Check out: http://www.mydailyflog.com/go/invite_register/saiprathap/22143969=89 Thanks! sai sadasivam ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ To unsubscribe of this type of email from MyDailyFlog in the future, please click below: http://www.mydailyflog.com/un/linux-kernel@vger.kernel.org=b0a7b7552dcee17e=16 Please do not reply directly to this email. Questions? Contact us - http://www.mydailyflog.com/go/contact_us MyDailyFlog, Refriendz Ltd. PO BOX 1184, Luton, Bedfordshire, LU1 9AT. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PULL] Documentation for 4.3
On Sat, Sep 12, 2015 at 10:25 AM, Jonathan Corbet wrote: > On Sat, 12 Sep 2015 01:59:34 -0300 > Diego Viola wrote: > >> I really wish the commit message instead said: >> >> "GTK+ is an initialism" >> >> Can't I change the commit message any longer? > > No, you need to consider it set in stone at this point. > > jon The commit message that I can't longer change ended up bothering more than the typo I fixed. How does one get over this? Diego -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 4.3-rc1 - merge window closed
So it's been fairly quiet today (which is normal: there tends to be a small rush of stuff on the last Friday of the merge window is closing, but weekends tend to calm down), and I decided that I'm not interested in catering to anything that comes in tomorrow, and I might as well just close the merge window and do the -rc1 release. I had expected 4.3 to be somewhat smaller after that pretty big 4.2, but it's not particularly small - pretty average in size, in fact. Everything looks fairly normal, in fact, with about 70% of the changes being drivers, 10% architecture updates, and the remaining 20% are spread out (filesystems, networking, tooling, documentation, mm and "core" kernel updates etc). On the driver side, the GPU drivers remain a noticeable chunk, partly because of the Nouveau updates that missed 4.2, so there's effectively two releases worth of updates there. But there's driver updates to pretty much all the other driver subsystems too. So there's networking drivers (wired and wireless), staging, media, crypto, pinctrl, you name it. The architecture updates are about half arm (devicetree updates are noticeable), with half being spread out (x86, mips, arm64, powerpc, s390). On the filesystem side, the bulk of the changes (in lines of code) is the removal of the ext3 filesystem (with ext4 remaining to support ext3 layouts - but the separate ext3 codebase is gone). But there are misc updates all over: f2fs, btrfs, nfs, xfs, ufs, gfs2, proc... As usual, the full log is much too big to post, so I'm appending my merge-log that gives you a flavor of who I pulled from and what the big picture changes are.. Go out and test, Linus --- Al Viro (1): vfs updates Alexandre Belloni (1): RTC updates Andrew Morton (4): patch-bomb second patch-bomb third patch-bomb fourth patch-bomb Bjorn Helgaas (1): PCI updates Bob Peterson (1): GFS2 updates Borislav Petkov (1): EDAC fixes Brian Norris (2): MTD updates more MTD updates Bruce Fields (1): nfsd updates Chris Mason (2): btrfs updates btrfs cleanups and fixes Chris Metcalf (1): tile updates Chris Zankel (1): xtensa updates Corey Minyard (1): IPMI updates Dan Williams (1): libnvdimm updates Darren Hart (1): x86 platform driver updates Dave Airlie (2): drm updates drm fixes Dave Chinner (1): xfs updates David Miller (2): networking updates networking fixes David Teigland (1): dlm updates David Vrabel (2): xen updates xen terminology fixes Dmitry Torokhov (2): input subsystem updates more input updates Doug Ledford (1): inifiniband/rdma updates Eric Biederman (1): user namespace updates Eric Van Hensbergen (1): 9p updates Geert Uytterhoeven (1): m68k updates Greg KH (6): char/misc driver patches driver core updates staging driver updates tty/serial driver updates USB updates tty driver reverts Greg Ungerer (1): m68k/colfire fixes Guenter Roeck (1): hwmon updates Helge Deller (1): parisc updates Herbert Xu (2): crypto updates crypto fix Ingo Molnar (19): RCU updates inlining tuning liblockdep fixes x86/kasan changes perf updates RAS updates scheduler updates scheduler fix NOHZ updates x86 asm changes x86 boot updates x86 build fixlet x86 init code fixlet x86 cpu updates x86 irq fixlet x86 mm updates x86 core platform updates locking and atomic updates perf fixes Jacek Anaszewski (1): LED updates Jaegeuk Kim (1): f2fs updates James Bottomley (2): first round of SCSI updates second round of SCSI updates James Hogan (1): metag updates James Morris (1): security subsystem updates Jan Kara (1): ext3 removal, quota & udf fixes Jassi Brar (1): mailbox updates Jens Axboe (4): core block updates block driver updates SG updates blk-cg updates Jesper Nilsson (1): CRIS updates Jiri Kosina (3): HID updates livepatching fix trivial tree updates Joerg Roedel (1): iommu updates for Jon Mason (1): NTB fixes Jonathan Corbet (1): documentation updates Kevin Hilman (1): late ARM SoC updates Lee Jones (2): MFD updates backlight updates Ley Foon Tan (1): nios2 updates Linus Walleij (2): GPIO updates pin control updates Mark Brown (3): regulator updates spi updates regmap updates Martin Schwidefsky (1): s390 updates Matt Turner (1): alpha update Mauro Carvalho Chehab (3): media updates edac updates media updates Michael Ellerman (1): powerpc updates Michael Tsirkin (1): virtio updates Michael Turquette (1): clk updates Michal Marek (3): core kbuild updates kconfig updates misc kbuild updates Michal Simek (1): microblaze update Mike Snitzer (1): device mapper update Mikulas Patocka (1): hpfs upddate Neil Brown (1): md updates Nicholas Bellinger (1): SCSI target updates Olof Johansson (7): ARM SoC non-urgent fixes ARM SoC cleanups ARM SoC platform updates ARM SoC driver updates
Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug()
On Sat, Sep 12, 2015 at 04:29:06PM -0700, Linus Torvalds wrote: > On Sat, Sep 12, 2015 at 4:00 PM, Chris Mason wrote: > > > > I did the plain revert as well, just to have a baseline. > > Ahh, I ended up not expecting you to get this done until after rc1 was > out, so I in the meantime just merged my fix instead rather than leave > the expected scheduling-while-atomic problem. Yeah, I wasn't sure I'd be able to do the runs, but it was a rainy afternoon and this was more fun than cleaning. Really glad something got in for rc1 either way. > > And just as well that you did a baseline, since apparently the numbers > are all over the map. I don't see how your hack and dave's original > can _possibly_ differ that much, but they clearly did on your xfs > test. So there's probably huge variance that depends on random > details. I don't think the XFS numbers can be trusted too much since it was basically bottlenecked behind that single pegged CPU. It was bouncing around and I couldn't quite track it down to a process name (or perf profile). The btrfs numbers were much more consistent, but your patch is still a win over plain 4.2. > > I'll leave things as they are until we have something that looks a bit > more believable ;) We can build from here, thanks Linus. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] fs-writeback: drop wb->list_lock during blk_finish_plug()
On Sat, Sep 12, 2015 at 4:00 PM, Chris Mason wrote: > > I did the plain revert as well, just to have a baseline. Ahh, I ended up not expecting you to get this done until after rc1 was out, so I in the meantime just merged my fix instead rather than leave the expected scheduling-while-atomic problem. And just as well that you did a baseline, since apparently the numbers are all over the map. I don't see how your hack and dave's original can _possibly_ differ that much, but they clearly did on your xfs test. So there's probably huge variance that depends on random details. I'll leave things as they are until we have something that looks a bit more believable ;) 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/
[PATCH 2.6.32 61/62] dmaengine: fix missing cnt in ?: in dmatest
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: "Dr. David Alan Gilbert"
Hi,
On the latest tree my compiler has started giving the warning:
drivers/dma/dmatest.c:575:28: warning: the omitted middle operand in ?: will
always be ?true?, suggest explicit middle operand [-Wparentheses]
The following patch fixes the missing middle clause with the same
fix that Nicolas Ferre used in the similar clauses.
(There seems to have been a race between him fixing that and
the extra clause going in a little later).
I don't actually know the dmatest code/structures, nor do I own
any hardware to test it on (assuming it needs a DMA engine);
but this patch builds, the existing code is almost certainly
wrong and the fix is the same as the corresponding lines above it.
(WTH is x=y?:z legal C anyway?)
Signed-off-by: Dr. David Alan Gilbert
Reported-by: Dan Carpenter
Reported-by: Paul Gortmaker
Acked-by: Nicolas Ferre
Signed-off-by: Dan Williams
(cherry picked from commit d07a74a546981a09ba490936645fbf0d1340b96c)
Signed-off-by: Willy Tarreau
---
drivers/dma/dmatest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index a32a4cf..d7c282a 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -552,7 +552,7 @@ static int dmatest_add_channel(struct dma_chan *chan)
}
if (dma_has_cap(DMA_PQ, dma_dev->cap_mask)) {
cnt = dmatest_add_threads(dtc, DMA_PQ);
- thread_count += cnt > 0 ?: 0;
+ thread_count += cnt > 0 ? cnt : 0;
}
pr_info("dmatest: Started %u threads using %s\n",
--
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 2.6.32 07/62] HID: fix a couple of off-by-ones
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Jiri Kosina
commit 4ab25786c87eb20857bbb715c3ae34ec8fd6a214 upstream.
There are a few very theoretical off-by-one bugs in report descriptor size
checking when performing a pre-parsing fixup. Fix those.
Reported-by: Ben Hawkes
Reviewed-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
[bwh: Backported to 2.6.32:
- Adjust context
- Drop change to a quirk in hid-lg.c that doesn't exist here]
Signed-off-by: Ben Hutchings
CVE-2014-3184
Signed-off-by: Willy Tarreau
---
drivers/hid/hid-cherry.c | 2 +-
drivers/hid/hid-kye.c | 2 +-
drivers/hid/hid-lg.c | 2 +-
drivers/hid/hid-monterey.c | 2 +-
drivers/hid/hid-petalynx.c | 2 +-
drivers/hid/hid-sunplus.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-cherry.c b/drivers/hid/hid-cherry.c
index 7e597d7..bfce74e 100644
--- a/drivers/hid/hid-cherry.c
+++ b/drivers/hid/hid-cherry.c
@@ -29,7 +29,7 @@
static void ch_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int rsize)
{
- if (rsize >= 17 && rdesc[11] == 0x3c && rdesc[12] == 0x02) {
+ if (rsize >= 18 && rdesc[11] == 0x3c && rdesc[12] == 0x02) {
dev_info(>dev, "fixing up Cherry Cymotion report "
"descriptor\n");
rdesc[11] = rdesc[16] = 0xff;
diff --git a/drivers/hid/hid-kye.c b/drivers/hid/hid-kye.c
index f887171..30f723b 100644
--- a/drivers/hid/hid-kye.c
+++ b/drivers/hid/hid-kye.c
@@ -26,7 +26,7 @@
static void kye_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int rsize)
{
- if (rsize >= 74 &&
+ if (rsize >= 75 &&
rdesc[61] == 0x05 && rdesc[62] == 0x08 &&
rdesc[63] == 0x19 && rdesc[64] == 0x08 &&
rdesc[65] == 0x29 && rdesc[66] == 0x0f &&
diff --git a/drivers/hid/hid-lg.c b/drivers/hid/hid-lg.c
index 0f870a3..6d34374 100644
--- a/drivers/hid/hid-lg.c
+++ b/drivers/hid/hid-lg.c
@@ -44,7 +44,7 @@ static void lg_report_fixup(struct hid_device *hdev, __u8
*rdesc,
{
unsigned long quirks = (unsigned long)hid_get_drvdata(hdev);
- if ((quirks & LG_RDESC) && rsize >= 90 && rdesc[83] == 0x26 &&
+ if ((quirks & LG_RDESC) && rsize >= 91 && rdesc[83] == 0x26 &&
rdesc[84] == 0x8c && rdesc[85] == 0x02) {
dev_info(>dev, "fixing up Logitech keyboard report "
"descriptor\n");
diff --git a/drivers/hid/hid-monterey.c b/drivers/hid/hid-monterey.c
index 2cd05aa..eaa2ac8 100644
--- a/drivers/hid/hid-monterey.c
+++ b/drivers/hid/hid-monterey.c
@@ -25,7 +25,7 @@
static void mr_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int rsize)
{
- if (rsize >= 30 && rdesc[29] == 0x05 && rdesc[30] == 0x09) {
+ if (rsize >= 31 && rdesc[29] == 0x05 && rdesc[30] == 0x09) {
dev_info(>dev, "fixing up button/consumer in HID report "
"descriptor\n");
rdesc[30] = 0x0c;
diff --git a/drivers/hid/hid-petalynx.c b/drivers/hid/hid-petalynx.c
index 500fbd0..38fa74d 100644
--- a/drivers/hid/hid-petalynx.c
+++ b/drivers/hid/hid-petalynx.c
@@ -26,7 +26,7 @@
static void pl_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int rsize)
{
- if (rsize >= 60 && rdesc[39] == 0x2a && rdesc[40] == 0xf5 &&
+ if (rsize >= 62 && rdesc[39] == 0x2a && rdesc[40] == 0xf5 &&
rdesc[41] == 0x00 && rdesc[59] == 0x26 &&
rdesc[60] == 0xf9 && rdesc[61] == 0x00) {
dev_info(>dev, "fixing up Petalynx Maxter Remote report "
diff --git a/drivers/hid/hid-sunplus.c b/drivers/hid/hid-sunplus.c
index 438107d..ac0d488 100644
--- a/drivers/hid/hid-sunplus.c
+++ b/drivers/hid/hid-sunplus.c
@@ -25,7 +25,7 @@
static void sp_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int rsize)
{
- if (rsize >= 107 && rdesc[104] == 0x26 && rdesc[105] == 0x80 &&
+ if (rsize >= 112 && rdesc[104] == 0x26 && rdesc[105] == 0x80 &&
rdesc[106] == 0x03) {
dev_info(>dev, "fixing up Sunplus Wireless Desktop "
"report descriptor\n");
--
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 2.6.32 01/62] pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not. The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset. This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.
This was fixed upstream by commits f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable. This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.
CVE-2015-1805
References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855
Signed-off-by: Ben Hutchings
(cherry picked from commit 75cf667b7fac08a7b21694adca7dff07361be68a)
Signed-off-by: Willy Tarreau
---
fs/pipe.c | 55 ---
1 file changed, 32 insertions(+), 23 deletions(-)
diff --git a/fs/pipe.c b/fs/pipe.c
index d0cc080..daa71ea 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -90,25 +90,27 @@ void pipe_wait(struct pipe_inode_info *pipe)
}
static int
-pipe_iov_copy_from_user(void *to, struct iovec *iov, unsigned long len,
- int atomic)
+pipe_iov_copy_from_user(void *addr, int *offset, struct iovec *iov,
+ size_t *remaining, int atomic)
{
unsigned long copy;
- while (len > 0) {
+ while (*remaining > 0) {
while (!iov->iov_len)
iov++;
- copy = min_t(unsigned long, len, iov->iov_len);
+ copy = min_t(unsigned long, *remaining, iov->iov_len);
if (atomic) {
- if (__copy_from_user_inatomic(to, iov->iov_base, copy))
+ if (__copy_from_user_inatomic(addr + *offset,
+ iov->iov_base, copy))
return -EFAULT;
} else {
- if (copy_from_user(to, iov->iov_base, copy))
+ if (copy_from_user(addr + *offset,
+ iov->iov_base, copy))
return -EFAULT;
}
- to += copy;
- len -= copy;
+ *offset += copy;
+ *remaining -= copy;
iov->iov_base += copy;
iov->iov_len -= copy;
}
@@ -116,25 +118,27 @@ pipe_iov_copy_from_user(void *to, struct iovec *iov,
unsigned long len,
}
static int
-pipe_iov_copy_to_user(struct iovec *iov, const void *from, unsigned long len,
- int atomic)
+pipe_iov_copy_to_user(struct iovec *iov, void *addr, int *offset,
+ size_t *remaining, int atomic)
{
unsigned long copy;
- while (len > 0) {
+ while (*remaining > 0) {
while (!iov->iov_len)
iov++;
- copy = min_t(unsigned long, len, iov->iov_len);
+ copy = min_t(unsigned long, *remaining, iov->iov_len);
if (atomic) {
- if (__copy_to_user_inatomic(iov->iov_base, from, copy))
+ if (__copy_to_user_inatomic(iov->iov_base,
+ addr + *offset, copy))
return -EFAULT;
} else {
- if (copy_to_user(iov->iov_base, from, copy))
+ if (copy_to_user(iov->iov_base,
+addr + *offset, copy))
return -EFAULT;
}
- from += copy;
- len -= copy;
+ *offset += copy;
+ *remaining -= copy;
iov->iov_base += copy;
iov->iov_len -= copy;
}
@@ -354,7 +358,7 @@ pipe_read(struct kiocb *iocb, const struct iovec *_iov,
struct pipe_buffer *buf = pipe->bufs + curbuf;
const struct pipe_buf_operations *ops = buf->ops;
void *addr;
- size_t chars = buf->len;
+ size_t chars = buf->len, remaining;
int error, atomic;
if (chars > total_len)
@@ -368,9 +372,11 @@ pipe_read(struct kiocb *iocb, const struct iovec *_iov,
}
atomic = !iov_fault_in_pages_write(iov, chars);
+ remaining = chars;
redo:
addr = ops->map(pipe, buf, atomic);
- error = pipe_iov_copy_to_user(iov, addr + buf->offset,
[PATCH 2.6.32 54/62] mm: avoid setting up anonymous pages into file mapping
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: "Kirill A. Shutemov"
commit 6b7339f4c31ad69c8e9c0b2859276e22cf72176d upstream.
Reading page fault handler code I've noticed that under right
circumstances kernel would map anonymous pages into file mappings: if
the VMA doesn't have vm_ops->fault() and the VMA wasn't fully populated
on ->mmap(), kernel would handle page fault to not populated pte with
do_anonymous_page().
Let's change page fault handler to use do_anonymous_page() only on
anonymous VMA (->vm_ops == NULL) and make sure that the VMA is not
shared.
For file mappings without vm_ops->fault() or shred VMA without vm_ops,
page fault on pte_none() entry would lead to SIGBUS.
Signed-off-by: Kirill A. Shutemov
Acked-by: Oleg Nesterov
Cc: Andrew Morton
Cc: Willy Tarreau
Signed-off-by: Linus Torvalds
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
(cherry picked from commit e2506476534cff7bb3697fbe0654fdefd101bc80)
Signed-off-by: Willy Tarreau
---
mm/memory.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 085b068..e36dee2 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2727,6 +2727,10 @@ static int do_anonymous_page(struct mm_struct *mm,
struct vm_area_struct *vma,
pte_unmap(page_table);
+ /* File mapping without ->vm_ops ? */
+ if (vma->vm_flags & VM_SHARED)
+ return VM_FAULT_SIGBUS;
+
/* Check if we need to add a guard page to the stack */
if (check_stack_guard_page(vma, address) < 0)
return VM_FAULT_SIGBUS;
@@ -2979,6 +2983,9 @@ static int do_linear_fault(struct mm_struct *mm, struct
vm_area_struct *vma,
- vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
pte_unmap(page_table);
+ /* The VMA was not fully populated on mmap() or missing VM_DONTEXPAND */
+ if (!vma->vm_ops->fault)
+ return VM_FAULT_SIGBUS;
return __do_fault(mm, vma, address, pmd, pgoff, flags, orig_pte);
}
@@ -3037,11 +3044,9 @@ static inline int handle_pte_fault(struct mm_struct *mm,
entry = *pte;
if (!pte_present(entry)) {
if (pte_none(entry)) {
- if (vma->vm_ops) {
- if (likely(vma->vm_ops->fault))
- return do_linear_fault(mm, vma, address,
+ if (vma->vm_ops)
+ return do_linear_fault(mm, vma, address,
pte, pmd, flags, entry);
- }
return do_anonymous_page(mm, vma, address,
pte, pmd, flags);
}
--
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 2.6.32 44/62] dmaengine: mv_xor: bug fix for racing condition in descriptors cleanup
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Lior Amsalem
commit 9136291f1dbc1d4d1cacd2840fb35f4f3ce16c46 upstream.
This patch fixes a bug in the XOR driver where the cleanup function can be
called and free descriptors that never been processed by the engine (which
result in data errors).
The cleanup function will free descriptors based on the ownership bit in
the descriptors.
Fixes: ff7b04796d98 ("dmaengine: DMA engine driver for Marvell XOR engine")
Signed-off-by: Lior Amsalem
Signed-off-by: Maxime Ripard
Reviewed-by: Ofer Heifetz
Signed-off-by: Vinod Koul
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
(cherry picked from commit 26aa1c6949dfef77d3aa77e4cb504ccfd8394ce9)
Signed-off-by: Willy Tarreau
---
drivers/dma/mv_xor.c | 72 +---
drivers/dma/mv_xor.h | 1 +
2 files changed, 47 insertions(+), 26 deletions(-)
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index 076d599..d9cc96d 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -387,7 +387,8 @@ static void __mv_xor_slot_cleanup(struct mv_xor_chan
*mv_chan)
dma_cookie_t cookie = 0;
int busy = mv_chan_is_busy(mv_chan);
u32 current_desc = mv_chan_get_current_desc(mv_chan);
- int seen_current = 0;
+ int current_cleaned = 0;
+ struct mv_xor_desc *hw_desc;
dev_dbg(mv_chan->device->common.dev, "%s %d\n", __func__, __LINE__);
dev_dbg(mv_chan->device->common.dev, "current_desc %x\n", current_desc);
@@ -399,38 +400,57 @@ static void __mv_xor_slot_cleanup(struct mv_xor_chan
*mv_chan)
list_for_each_entry_safe(iter, _iter, _chan->chain,
chain_node) {
- prefetch(_iter);
- prefetch(&_iter->async_tx);
- /* do not advance past the current descriptor loaded into the
-* hardware channel, subsequent descriptors are either in
-* process or have not been submitted
-*/
- if (seen_current)
- break;
+ /* clean finished descriptors */
+ hw_desc = iter->hw_desc;
+ if (hw_desc->status & XOR_DESC_SUCCESS) {
+ cookie = mv_xor_run_tx_complete_actions(iter, mv_chan,
+ cookie);
- /* stop the search if we reach the current descriptor and the
-* channel is busy
-*/
- if (iter->async_tx.phys == current_desc) {
- seen_current = 1;
- if (busy)
+ /* done processing desc, clean slot */
+ mv_xor_clean_slot(iter, mv_chan);
+
+ /* break if we did cleaned the current */
+ if (iter->async_tx.phys == current_desc) {
+ current_cleaned = 1;
+ break;
+ }
+ } else {
+ if (iter->async_tx.phys == current_desc) {
+ current_cleaned = 0;
break;
+ }
}
-
- cookie = mv_xor_run_tx_complete_actions(iter, mv_chan, cookie);
-
- if (mv_xor_clean_slot(iter, mv_chan))
- break;
}
if ((busy == 0) && !list_empty(_chan->chain)) {
- struct mv_xor_desc_slot *chain_head;
- chain_head = list_entry(mv_chan->chain.next,
- struct mv_xor_desc_slot,
- chain_node);
-
- mv_xor_start_new_chain(mv_chan, chain_head);
+ if (current_cleaned) {
+ /*
+* current descriptor cleaned and removed, run
+* from list head
+*/
+ iter = list_entry(mv_chan->chain.next,
+ struct mv_xor_desc_slot,
+ chain_node);
+ mv_xor_start_new_chain(mv_chan, iter);
+ } else {
+ if (!list_is_last(>chain_node, _chan->chain)) {
+ /*
+* descriptors are still waiting after
+* current, trigger them
+*/
+ iter = list_entry(iter->chain_node.next,
+ struct mv_xor_desc_slot,
+ chain_node);
+ mv_xor_start_new_chain(mv_chan, iter);
+ } else {
+ /*
+
[PATCH 2.6.32 05/62] netlink: fix possible spoofing from non-root processes
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Pablo Neira Ayuso
commit 20e1db19db5d6b9e4e83021595eab0dc8f107bef upstream.
Non-root user-space processes can send Netlink messages to other
processes that are well-known for being subscribed to Netlink
asynchronous notifications. This allows ilegitimate non-root
process to send forged messages to Netlink subscribers.
The userspace process usually verifies the legitimate origin in
two ways:
a) Socket credentials. If UID != 0, then the message comes from
some ilegitimate process and the message needs to be dropped.
b) Netlink portID. In general, portID == 0 means that the origin
of the messages comes from the kernel. Thus, discarding any
message not coming from the kernel.
However, ctnetlink sets the portID in event messages that has
been triggered by some user-space process, eg. conntrack utility.
So other processes subscribed to ctnetlink events, eg. conntrackd,
know that the event was triggered by some user-space action.
Neither of the two ways to discard ilegitimate messages coming
from non-root processes can help for ctnetlink.
This patch adds capability validation in case that dst_pid is set
in netlink_sendmsg(). This approach is aggressive since existing
applications using any Netlink bus to deliver messages between
two user-space processes will break. Note that the exception is
NETLINK_USERSOCK, since it is reserved for netlink-to-netlink
userspace communication.
Still, if anyone wants that his Netlink bus allows netlink-to-netlink
userspace, then they can set NL_NONROOT_SEND. However, by default,
I don't think it makes sense to allow to use NETLINK_ROUTE to
communicate two processes that are sending no matter what information
that is not related to link/neighbouring/routing. They should be using
NETLINK_USERSOCK instead for that.
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: David S. Miller
[bwh: Backported to 2.6.32:
- Adjust context
- NETLINK_USERSOCK does not exist, so drop that part]
Signed-off-by: Ben Hutchings
CVE-2012-6689
Signed-off-by: Willy Tarreau
---
net/netlink/af_netlink.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 39a6d5d..2235885 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1303,7 +1303,8 @@ static int netlink_sendmsg(struct kiocb *kiocb, struct
socket *sock,
return -EINVAL;
dst_pid = addr->nl_pid;
dst_group = ffs(addr->nl_groups);
- if (dst_group && !netlink_capable(sock, NL_NONROOT_SEND))
+ if ((dst_group || dst_pid) &&
+ !netlink_capable(sock, NL_NONROOT_SEND))
return -EPERM;
} else {
dst_pid = nlk->dst_pid;
--
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 2.6.32 55/62] s390/process: fix sfpc inline assembly
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Heiko Carstens
commit e47994dd44bcb4a77b4152bd0eada585934703c0 upstream.
The sfpc inline assembly within execve_tail() may incorrectly set bits
28-31 of the sfpc instruction to a value which is not zero.
These bits however are currently unused and therefore should be zero
so we won't get surprised if these bits will be used in the future.
Therefore remove the second operand from the inline assembly.
Signed-off-by: Heiko Carstens
Signed-off-by: Martin Schwidefsky
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
(cherry picked from commit b411a8a3b44d76e782ba4bc6893068f3f590fe8a)
Signed-off-by: Willy Tarreau
---
arch/s390/kernel/process.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/kernel/process.c b/arch/s390/kernel/process.c
index cea2855..0d3448d 100644
--- a/arch/s390/kernel/process.c
+++ b/arch/s390/kernel/process.c
@@ -261,7 +261,7 @@ asmlinkage void execve_tail(void)
{
current->thread.fp_regs.fpc = 0;
if (MACHINE_HAS_IEEE)
- asm volatile("sfpc %0,%0" : : "d" (0));
+ asm volatile("sfpc %0" : : "d" (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/
[PATCH 2.6.32 21/62] md/raid5: dont record new size if resize_stripes fails.
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: NeilBrown
commit 6e9eac2dcee5e19f125967dd2be3e36558c42fff upstream.
If any memory allocation in resize_stripes fails we will return
-ENOMEM, but in some cases we update conf->pool_size anyway.
This means that if we try again, the allocations will be assumed
to be larger than they are, and badness results.
So only update pool_size if there is no error.
This bug was introduced in 2.6.17 and the patch is suitable for
-stable.
Fixes: ad01c9e3752f ("[PATCH] md: Allow stripes to be expanded in preparation
for expanding an array")
Signed-off-by: NeilBrown
Signed-off-by: Ben Hutchings
(cherry picked from commit c20694a054e903745591f4f85b39ecbce4e58349)
Signed-off-by: Willy Tarreau
---
drivers/md/raid5.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 4d70eef..7eb8b46 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -1452,7 +1452,8 @@ static int resize_stripes(raid5_conf_t *conf, int newsize)
conf->slab_cache = sc;
conf->active_name = 1-conf->active_name;
- conf->pool_size = newsize;
+ if (!err)
+ conf->pool_size = newsize;
return err;
}
--
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 2.6.32 26/62] fs, omfs: add NULL terminator in the end up the token list
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Sasha Levin
commit dcbff39da3d815f08750552fdd04f96b51751129 upstream.
match_token() expects a NULL terminator at the end of the token list so
that it would know where to stop. Not having one causes it to overrun
to invalid memory.
In practice, passing a mount option that omfs didn't recognize would
sometimes panic the system.
Signed-off-by: Sasha Levin
Signed-off-by: Bob Copeland
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Ben Hutchings
(cherry picked from commit a5045e0fee1a7b2cf132afb94977d4c8d781bd04)
Signed-off-by: Willy Tarreau
---
fs/omfs/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/omfs/inode.c b/fs/omfs/inode.c
index f3b7c15..66c37eb 100644
--- a/fs/omfs/inode.c
+++ b/fs/omfs/inode.c
@@ -347,7 +347,7 @@ nomem:
}
enum {
- Opt_uid, Opt_gid, Opt_umask, Opt_dmask, Opt_fmask
+ Opt_uid, Opt_gid, Opt_umask, Opt_dmask, Opt_fmask, Opt_err
};
static const match_table_t tokens = {
@@ -356,6 +356,7 @@ static const match_table_t tokens = {
{Opt_umask, "umask=%o"},
{Opt_dmask, "dmask=%o"},
{Opt_fmask, "fmask=%o"},
+ {Opt_err, NULL},
};
static int parse_options(char *options, struct omfs_sb_info *sbi)
--
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 2.6.32 06/62] eCryptfs: Remove buggy and unnecessary write in file name decode routine
2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Michael Halcrow commit 942080643bce061c3dd9d5718d3b745dcb39a8bc upstream. Dmitry Chernenkov used KASAN to discover that eCryptfs writes past the end of the allocated buffer during encrypted filename decoding. This fix corrects the issue by getting rid of the unnecessary 0 write when the current bit offset is 2. Signed-off-by: Michael Halcrow Reported-by: Dmitry Chernenkov Suggested-by: Kees Cook Signed-off-by: Tyler Hicks Signed-off-by: Ben Hutchings CVE-2014-9683 Signed-off-by: Willy Tarreau --- fs/ecryptfs/crypto.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c index 7e164bb..cc57904 100644 --- a/fs/ecryptfs/crypto.c +++ b/fs/ecryptfs/crypto.c @@ -2088,7 +2088,6 @@ ecryptfs_decode_from_filename(unsigned char *dst, size_t *dst_size, break; case 2: dst[dst_byte_offset++] |= (src_byte); - dst[dst_byte_offset] = 0; current_bit_offset = 0; break; } -- 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 2.6.32 42/62] fixing infinite OPEN loop in 4.0 stateid recovery
2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Olga Kornievskaia commit e8d975e73e5fa05f983fbf2723120edcf68e0b38 upstream. Problem: When an operation like WRITE receives a BAD_STATEID, even though recovery code clears the RECLAIM_NOGRACE recovery flag before recovering the open state, because of clearing delegation state for the associated inode, nfs_inode_find_state_and_recover() gets called and it makes the same state with RECLAIM_NOGRACE flag again. As a results, when we restart looking over the open states, we end up in the infinite loop instead of breaking out in the next test of state flags. Solution: unset the RECLAIM_NOGRACE set because of calling of nfs_inode_find_state_and_recover() after returning from calling recover_open() function. Signed-off-by: Olga Kornievskaia Signed-off-by: Trond Myklebust [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings (cherry picked from commit ef8500b18fc4bb03286a93b6032d56ec7bcbfd15) Signed-off-by: Willy Tarreau --- fs/nfs/nfs4state.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c index 2a7f163..71ee6f6 100644 --- a/fs/nfs/nfs4state.c +++ b/fs/nfs/nfs4state.c @@ -929,6 +929,8 @@ restart: __func__); } nfs4_put_open_state(state); + clear_bit(NFS4CLNT_RECLAIM_NOGRACE, + >flags); goto restart; } } -- 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 2.6.32 03/62] crypto: testmgr - update LZO compression test vectors
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: "Markus F.X.J. Oberhumer"
Update the LZO compression test vectors according to the latest compressor
version.
Signed-off-by: Markus F.X.J. Oberhumer
(cherry picked from commit 0ec7382036922be063b515b2a3f1d6f7a607392c)
Cc: Ben Hutchings
Signed-off-by: Willy Tarreau
---
crypto/testmgr.h | 38 --
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 9963b18..2d87892 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -9237,38 +9237,40 @@ static struct pcomp_testvec zlib_decomp_tv_template[] =
{
static struct comp_testvec lzo_comp_tv_template[] = {
{
.inlen = 70,
- .outlen = 46,
+ .outlen = 57,
.input = "Join us now and share the software "
"Join us now and share the software ",
.output = "\x00\x0d\x4a\x6f\x69\x6e\x20\x75"
- "\x73\x20\x6e\x6f\x77\x20\x61\x6e"
- "\x64\x20\x73\x68\x61\x72\x65\x20"
- "\x74\x68\x65\x20\x73\x6f\x66\x74"
- "\x77\x70\x01\x01\x4a\x6f\x69\x6e"
- "\x3d\x88\x00\x11\x00\x00",
+ "\x73\x20\x6e\x6f\x77\x20\x61\x6e"
+ "\x64\x20\x73\x68\x61\x72\x65\x20"
+ "\x74\x68\x65\x20\x73\x6f\x66\x74"
+ "\x77\x70\x01\x32\x88\x00\x0c\x65"
+ "\x20\x74\x68\x65\x20\x73\x6f\x66"
+ "\x74\x77\x61\x72\x65\x20\x11\x00"
+ "\x00",
}, {
.inlen = 159,
- .outlen = 133,
+ .outlen = 131,
.input = "This document describes a compression method based
on the LZO "
"compression algorithm. This document defines the
application of "
"the LZO algorithm used in UBIFS.",
- .output = "\x00\x2b\x54\x68\x69\x73\x20\x64"
+ .output = "\x00\x2c\x54\x68\x69\x73\x20\x64"
"\x6f\x63\x75\x6d\x65\x6e\x74\x20"
"\x64\x65\x73\x63\x72\x69\x62\x65"
"\x73\x20\x61\x20\x63\x6f\x6d\x70"
"\x72\x65\x73\x73\x69\x6f\x6e\x20"
"\x6d\x65\x74\x68\x6f\x64\x20\x62"
"\x61\x73\x65\x64\x20\x6f\x6e\x20"
- "\x74\x68\x65\x20\x4c\x5a\x4f\x2b"
- "\x8c\x00\x0d\x61\x6c\x67\x6f\x72"
- "\x69\x74\x68\x6d\x2e\x20\x20\x54"
- "\x68\x69\x73\x2a\x54\x01\x02\x66"
- "\x69\x6e\x65\x73\x94\x06\x05\x61"
- "\x70\x70\x6c\x69\x63\x61\x74\x76"
- "\x0a\x6f\x66\x88\x02\x60\x09\x27"
- "\xf0\x00\x0c\x20\x75\x73\x65\x64"
- "\x20\x69\x6e\x20\x55\x42\x49\x46"
- "\x53\x2e\x11\x00\x00",
+ "\x74\x68\x65\x20\x4c\x5a\x4f\x20"
+ "\x2a\x8c\x00\x09\x61\x6c\x67\x6f"
+ "\x72\x69\x74\x68\x6d\x2e\x20\x20"
+ "\x2e\x54\x01\x03\x66\x69\x6e\x65"
+ "\x73\x20\x74\x06\x05\x61\x70\x70"
+ "\x6c\x69\x63\x61\x74\x76\x0a\x6f"
+ "\x66\x88\x02\x60\x09\x27\xf0\x00"
+ "\x0c\x20\x75\x73\x65\x64\x20\x69"
+ "\x6e\x20\x55\x42\x49\x46\x53\x2e"
+ "\x11\x00\x00",
},
};
--
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 2.6.32 43/62] SUNRPC: Fix a memory leak in the backchannel code
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit 88de6af24f2b48b06c514d3c3d0a8f22fafe30bd upstream.
req->rq_private_buf isn't initialised when xprt_setup_backchannel calls
xprt_free_allocation.
Fixes: fb7a0b9addbdb ("nfs41: New backchannel helper routines")
Signed-off-by: Trond Myklebust
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
(cherry picked from commit bd031759bcc0865938ecc52846a3f22f2a26ad8e)
Signed-off-by: Willy Tarreau
---
net/sunrpc/backchannel_rqst.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sunrpc/backchannel_rqst.c b/net/sunrpc/backchannel_rqst.c
index 553621f..b993a49 100644
--- a/net/sunrpc/backchannel_rqst.c
+++ b/net/sunrpc/backchannel_rqst.c
@@ -59,7 +59,7 @@ static void xprt_free_allocation(struct rpc_rqst *req)
dprintk("RPC:free allocations for req= %p\n", req);
BUG_ON(test_bit(RPC_BC_PA_IN_USE, >rq_bc_pa_state));
- xbufp = >rq_private_buf;
+ xbufp = >rq_rcv_buf;
free_page((unsigned long)xbufp->head[0].iov_base);
xbufp = >rq_snd_buf;
free_page((unsigned long)xbufp->head[0].iov_base);
--
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 2.6.32 13/62] Remove repeated loads blocksize
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit 79144954278d4bb5989f8b903adcac7a20ff2a5a upstream.
Store blocksize in a local variable in udf_fill_inode() since it is used
a lot of times.
Signed-off-by: Jan Kara
[bwh: Needed for the following fix. Backported to 2.6.32: adjust context.]
Signed-off-by: Ben Hutchings
Signed-off-by: Willy Tarreau
---
fs/udf/inode.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 7901ad7..26b7f31 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1157,6 +1157,7 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
int offset;
struct udf_sb_info *sbi = UDF_SB(inode->i_sb);
struct udf_inode_info *iinfo = UDF_I(inode);
+ int bs = inode->i_sb->s_blocksize;
fe = (struct fileEntry *)bh->b_data;
efe = (struct extendedFileEntry *)bh->b_data;
@@ -1177,41 +1178,38 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
if (fe->descTag.tagIdent == cpu_to_le16(TAG_IDENT_EFE)) {
iinfo->i_efe = 1;
iinfo->i_use = 0;
- if (udf_alloc_i_data(inode, inode->i_sb->s_blocksize -
+ if (udf_alloc_i_data(inode, bs -
sizeof(struct extendedFileEntry))) {
make_bad_inode(inode);
return;
}
memcpy(iinfo->i_ext.i_data,
bh->b_data + sizeof(struct extendedFileEntry),
- inode->i_sb->s_blocksize -
- sizeof(struct extendedFileEntry));
+ bs - sizeof(struct extendedFileEntry));
} else if (fe->descTag.tagIdent == cpu_to_le16(TAG_IDENT_FE)) {
iinfo->i_efe = 0;
iinfo->i_use = 0;
- if (udf_alloc_i_data(inode, inode->i_sb->s_blocksize -
- sizeof(struct fileEntry))) {
+ if (udf_alloc_i_data(inode, bs - sizeof(struct fileEntry))) {
make_bad_inode(inode);
return;
}
memcpy(iinfo->i_ext.i_data,
bh->b_data + sizeof(struct fileEntry),
- inode->i_sb->s_blocksize - sizeof(struct fileEntry));
+ bs - sizeof(struct fileEntry));
} else if (fe->descTag.tagIdent == cpu_to_le16(TAG_IDENT_USE)) {
iinfo->i_efe = 0;
iinfo->i_use = 1;
iinfo->i_lenAlloc = le32_to_cpu(
((struct unallocSpaceEntry *)bh->b_data)->
lengthAllocDescs);
- if (udf_alloc_i_data(inode, inode->i_sb->s_blocksize -
+ if (udf_alloc_i_data(inode, bs -
sizeof(struct unallocSpaceEntry))) {
make_bad_inode(inode);
return;
}
memcpy(iinfo->i_ext.i_data,
bh->b_data + sizeof(struct unallocSpaceEntry),
- inode->i_sb->s_blocksize -
- sizeof(struct unallocSpaceEntry));
+ bs - sizeof(struct unallocSpaceEntry));
return;
}
@@ -1297,8 +1295,7 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
return;
}
/* File in ICB has to fit in there... */
- if (inode->i_size > inode->i_sb->s_blocksize -
- udf_file_entry_alloc_offset(inode)) {
+ if (inode->i_size > bs - udf_file_entry_alloc_offset(inode)) {
make_bad_inode(inode);
return;
}
--
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 2.6.32 16/62] e1000: add dummy allocator to fix race condition between mtu change and netpoll
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Sabrina Dubroca
commit 08e8331654d1d7b2c58045e549005bc356aa7810 upstream.
There is a race condition between e1000_change_mtu's cleanups and
netpoll, when we change the MTU across jumbo size:
Changing MTU frees all the rx buffers:
e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings ->
e1000_clean_rx_ring
Then, close to the end of e1000_change_mtu:
pr_info -> ... -> netpoll_poll_dev -> e1000_clean ->
e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag
And when we come back to do the rest of the MTU change:
e1000_up -> e1000_configure -> e1000_configure_rx ->
e1000_alloc_jumbo_rx_buffers
alloc_jumbo finds the buffers already != NULL, since data (shared with
page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage,
or at least not what is expected when in jumbo state.
This results in an unusable adapter (packets don't get through), and a
NULL pointer dereference on the next call to e1000_clean_rx_ring
(other mtu change, link down, shutdown):
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] put_compound_page+0x7e/0x330
[...]
Call Trace:
[] put_page+0x55/0x60
[] e1000_clean_rx_ring+0x134/0x200
[] e1000_clean_all_rx_rings+0x45/0x60
[] e1000_down+0x1c0/0x1d0
[] ? deactivate_slab+0x7f0/0x840
[] e1000_change_mtu+0xdc/0x170
[] dev_set_mtu+0xa0/0x140
[] do_setlink+0x218/0xac0
[] ? nla_parse+0xb9/0x120
[] rtnl_newlink+0x6d0/0x890
[] ? kvm_clock_read+0x20/0x40
[] ? sched_clock_cpu+0xa8/0x100
[] rtnetlink_rcv_msg+0x92/0x260
By setting the allocator to a dummy version, netpoll can't mess up our
rx buffers. The allocator is set back to a sane value in
e1000_configure_rx.
Fixes: edbbb3ca1077 ("e1000: implement jumbo receive with partial descriptors")
Signed-off-by: Sabrina Dubroca
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
Signed-off-by: Ben Hutchings
(cherry picked from commit f655adbac3de7ce92b2b0f9ce2d426b55b600e38)
[wt: path is drivers/net/e1000/e1000_main.c in 2.6.32]
Signed-off-by: Willy Tarreau
---
drivers/net/e1000/e1000_main.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 4079a33..375d332 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -140,6 +140,11 @@ static bool e1000_clean_rx_irq(struct e1000_adapter
*adapter,
static bool e1000_clean_jumbo_rx_irq(struct e1000_adapter *adapter,
struct e1000_rx_ring *rx_ring,
int *work_done, int work_to_do);
+static void e1000_alloc_dummy_rx_buffers(struct e1000_adapter *adapter,
+struct e1000_rx_ring *rx_ring,
+int cleaned_count)
+{
+}
static void e1000_alloc_rx_buffers(struct e1000_adapter *adapter,
struct e1000_rx_ring *rx_ring,
int cleaned_count);
@@ -3154,8 +3159,11 @@ static int e1000_change_mtu(struct net_device *netdev,
int new_mtu)
msleep(1);
/* e1000_down has a dependency on max_frame_size */
hw->max_frame_size = max_frame;
- if (netif_running(netdev))
+ if (netif_running(netdev)) {
+ /* prevent buffers from being reallocated */
+ adapter->alloc_rx_buf = e1000_alloc_dummy_rx_buffers;
e1000_down(adapter);
+ }
/* NOTE: netdev_alloc_skb reserves 16 bytes, and typically NET_IP_ALIGN
* means we reserve 2 more, this pushes us to allocate from the next
--
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 2.6.32 17/62] powerpc: Fix missing L2 cache size in /sys/devices/system/cpu
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Dave Olson
commit f7e9e358362557c3aa2c1ec47490f29fe880a09e upstream.
This problem appears to have been introduced in 2.6.29 by commit
93197a36a9c1 "Rewrite sysfs processor cache info code".
This caused lscpu to error out on at least e500v2 devices, eg:
error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such
file or directory
Some embedded powerpc systems use cache-size in DTS for the unified L2
cache size, not d-cache-size, so we need to allow for both DTS names.
Added a new CACHE_TYPE_UNIFIED_D cache_type_info structure to handle
this.
Fixes: 93197a36a9c1 ("powerpc: Rewrite sysfs processor cache info code")
Signed-off-by: Dave Olson
Signed-off-by: Michael Ellerman
[bwh: Backported to 3.2:
- Adjust context
- Preserve __cpuinit attribute on cache_do_one_devnode_unified()]
Signed-off-by: Ben Hutchings
(cherry picked from commit d6de5ca93fd6425dcdb21cc341365991c0c444cc)
Signed-off-by: Willy Tarreau
---
arch/powerpc/kernel/cacheinfo.c | 43 -
1 file changed, 34 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index bb37b1d..ffab94b 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -61,12 +61,22 @@ struct cache_type_info {
};
/* These are used to index the cache_type_info array. */
-#define CACHE_TYPE_UNIFIED 0
-#define CACHE_TYPE_INSTRUCTION 1
-#define CACHE_TYPE_DATA2
+#define CACHE_TYPE_UNIFIED 0 /* cache-size, cache-block-size, etc. */
+#define CACHE_TYPE_UNIFIED_D 1 /* d-cache-size, d-cache-block-size, etc */
+#define CACHE_TYPE_INSTRUCTION 2
+#define CACHE_TYPE_DATA3
static const struct cache_type_info cache_type_info[] = {
{
+ /* Embedded systems that use cache-size, cache-block-size,
+* etc. for the Unified (typically L2) cache. */
+ .name= "Unified",
+ .size_prop = "cache-size",
+ .line_size_props = { "cache-line-size",
+"cache-block-size", },
+ .nr_sets_prop= "cache-sets",
+ },
+ {
/* PowerPC Processor binding says the [di]-cache-*
* must be equal on unified caches, so just use
* d-cache properties. */
@@ -292,7 +302,8 @@ static struct cache *cache_find_first_sibling(struct cache
*cache)
{
struct cache *iter;
- if (cache->type == CACHE_TYPE_UNIFIED)
+ if (cache->type == CACHE_TYPE_UNIFIED ||
+ cache->type == CACHE_TYPE_UNIFIED_D)
return cache;
list_for_each_entry(iter, _list, list)
@@ -323,15 +334,29 @@ static bool cache_node_is_unified(const struct
device_node *np)
return of_get_property(np, "cache-unified", NULL);
}
-static struct cache *__cpuinit cache_do_one_devnode_unified(struct device_node
*node, int level)
+/*
+ * Unified caches can have two different sets of tags. Most embedded
+ * use cache-size, etc. for the unified cache size, but open firmware systems
+ * use d-cache-size, etc. Check on initialization for which type we have, and
+ * return the appropriate structure type. Assume it's embedded if it isn't
+ * open firmware. If it's yet a 3rd type, then there will be missing entries
+ * in /sys/devices/system/cpu/cpu0/cache/index2/, and this code will need
+ * to be extended further.
+ */
+static int cache_is_unified_d(const struct device_node *np)
{
- struct cache *cache;
+ return of_get_property(np,
+ cache_type_info[CACHE_TYPE_UNIFIED_D].size_prop, NULL) ?
+ CACHE_TYPE_UNIFIED_D : CACHE_TYPE_UNIFIED;
+}
+/*
+ */
+static struct cache *__cpuinit cache_do_one_devnode_unified(struct device_node
*node, int level)
+{
pr_debug("creating L%d ucache for %s\n", level, node->full_name);
- cache = new_cache(CACHE_TYPE_UNIFIED, level, node);
-
- return cache;
+ return new_cache(cache_is_unified_d(node), level, node);
}
static struct cache *__cpuinit cache_do_one_devnode_split(struct device_node
*node, int level)
--
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 2.6.32 38/62] s5h1420: fix a buffer overflow when checking userspace params
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Mauro Carvalho Chehab
commit 12f4543f5d6811f864e6c4952eb27253c7466c02 upstream.
The maximum size for a DiSEqC command is 6, according to the
userspace API. However, the code allows to write up to 7 values:
drivers/media/dvb-frontends/s5h1420.c:193 s5h1420_send_master_cmd()
error: buffer overflow 'cmd->msg' 6 <= 7
Signed-off-by: Mauro Carvalho Chehab
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings
(cherry picked from commit 4bf124b5f179a9c169c57ef7cd3a74f239063ed1)
Signed-off-by: Willy Tarreau
---
drivers/media/dvb/frontends/s5h1420.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb/frontends/s5h1420.c
b/drivers/media/dvb/frontends/s5h1420.c
index 2e9fd28..6134578 100644
--- a/drivers/media/dvb/frontends/s5h1420.c
+++ b/drivers/media/dvb/frontends/s5h1420.c
@@ -180,7 +180,7 @@ static int s5h1420_send_master_cmd (struct dvb_frontend* fe,
int result = 0;
dprintk("enter %s\n", __func__);
- if (cmd->msg_len > 8)
+ if (cmd->msg_len > sizeof(cmd->msg))
return -EINVAL;
/* setup for DISEQC */
--
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 2.6.32 46/62] Disable write buffering on Toshiba ToPIC95
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Ryan Underwood
commit 2fb22a8042fe96b4220843f79241c116d90922c4 upstream.
Disable write buffering on the Toshiba ToPIC95 if it is enabled by
somebody (it is not supposed to be a power-on default according to
the datasheet). On the ToPIC95, practically no 32-bit Cardbus card
will work under heavy load without locking up the whole system if
this is left enabled. I tried about a dozen. It does not affect
16-bit cards. This is similar to the O2 bugs in early controller
revisions it seems.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55961
Signed-off-by: Ryan C. Underwood
Signed-off-by: Dominik Brodowski
Signed-off-by: Ben Hutchings
(cherry picked from commit 1e287196507c4272f7096ad4b4f10b1cf4b9d280)
Signed-off-by: Willy Tarreau
---
drivers/pcmcia/topic.h | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/pcmcia/topic.h b/drivers/pcmcia/topic.h
index edccfa5..998a2a2 100644
--- a/drivers/pcmcia/topic.h
+++ b/drivers/pcmcia/topic.h
@@ -104,6 +104,9 @@
#define TOPIC_EXCA_IF_CONTROL 0x3e/* 8 bit */
#define TOPIC_EXCA_IFC_33V_ENA 0x01
+#define TOPIC_PCI_CFG_PPBCN0x3e/* 16-bit */
+#define TOPIC_PCI_CFG_PPBCN_WBEN 0x0400
+
static void topic97_zoom_video(struct pcmcia_socket *sock, int onoff)
{
struct yenta_socket *socket = container_of(sock, struct yenta_socket,
socket);
@@ -143,6 +146,7 @@ static int topic97_override(struct yenta_socket *socket)
static int topic95_override(struct yenta_socket *socket)
{
u8 fctrl;
+ u16 ppbcn;
/* enable 3.3V support for 16bit cards */
fctrl = exca_readb(socket, TOPIC_EXCA_IF_CONTROL);
@@ -151,6 +155,18 @@ static int topic95_override(struct yenta_socket *socket)
/* tell yenta to use exca registers to power 16bit cards */
socket->flags |= YENTA_16BIT_POWER_EXCA | YENTA_16BIT_POWER_DF;
+ /* Disable write buffers to prevent lockups under load with numerous
+ Cardbus cards, observed on Tecra 500CDT and reported elsewhere on the
+ net. This is not a power-on default according to the datasheet
+ but some BIOSes seem to set it. */
+ if (pci_read_config_word(socket->dev, TOPIC_PCI_CFG_PPBCN, ) == 0
+ && socket->dev->revision <= 7
+ && (ppbcn & TOPIC_PCI_CFG_PPBCN_WBEN)) {
+ ppbcn &= ~TOPIC_PCI_CFG_PPBCN_WBEN;
+ pci_write_config_word(socket->dev, TOPIC_PCI_CFG_PPBCN, ppbcn);
+ dev_info(>dev->dev, "Disabled ToPIC95 Cardbus write
buffers.\n");
+ }
+
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/
[PATCH 2.6.32 12/62] udf: Check component length before reading it
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit e237ec37ec154564f8690c5bd1795339955eeef9 upstream.
Check that length specified in a component of a symlink fits in the
input buffer we are reading. Also properly ignore component length for
component types that do not use it. Otherwise we read memory after end
of buffer for corrupted udf image.
Reported-by: Carl Henrik Lunde
Signed-off-by: Jan Kara
Signed-off-by: Ben Hutchings
CVE-2014-9728, CVE-2014-9730
Signed-off-by: Willy Tarreau
---
fs/udf/symlink.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/fs/udf/symlink.c b/fs/udf/symlink.c
index 500c146..c45bb43 100644
--- a/fs/udf/symlink.c
+++ b/fs/udf/symlink.c
@@ -44,14 +44,17 @@ static int udf_pc_to_char(struct super_block *sb, char
*from,
tolen--;
while (elen < fromlen) {
pc = (struct pathComponent *)(from + elen);
+ elen += sizeof(struct pathComponent);
switch (pc->componentType) {
case 1:
/*
* Symlink points to some place which should be agreed
* upon between originator and receiver of the media.
Ignore.
*/
- if (pc->lengthComponentIdent > 0)
+ if (pc->lengthComponentIdent > 0) {
+ elen += pc->lengthComponentIdent;
break;
+ }
/* Fall through */
case 2:
if (tolen == 0)
@@ -76,6 +79,9 @@ static int udf_pc_to_char(struct super_block *sb, char *from,
/* that would be . - just ignore */
break;
case 5:
+ elen += pc->lengthComponentIdent;
+ if (elen > fromlen)
+ return -EIO;
comp_len = udf_get_filename(sb, pc->componentIdent,
pc->lengthComponentIdent,
p, tolen);
@@ -87,7 +93,6 @@ static int udf_pc_to_char(struct super_block *sb, char *from,
tolen--;
break;
}
- elen += sizeof(struct pathComponent) + pc->lengthComponentIdent;
}
if (p > to + 1)
p[-1] = '\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/
[PATCH 2.6.32 18/62] s390/hibernate: fix save and restore of kernel text section
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Heiko Carstens
commit d74419495633493c9cd3f2bbeb7f3529d0edded6 upstream.
Sebastian reported a crash caused by a jump label mismatch after resume.
This happens because we do not save the kernel text section during suspend
and therefore also do not restore it during resume, but use the kernel image
that restores the old system.
This means that after a suspend/resume cycle we lost all modifications done
to the kernel text section.
The reason for this is the pfn_is_nosave() function, which incorrectly
returns that read-only pages don't need to be saved. This is incorrect since
we mark the kernel text section read-only.
We still need to make sure to not save and restore pages contained within
NSS and DCSS segment.
To fix this add an extra case for the kernel text section and only save
those pages if they are not contained within an NSS segment.
Fixes the following crash (and the above bugs as well):
Jump label code mismatch at netif_receive_skb_internal+0x28/0xd0
Found:c0 04 00 00 00 00
Expected: c0 f4 00 00 00 11
New: c0 04 00 00 00 00
Kernel panic - not syncing: Corrupted kernel text
CPU: 0 PID: 9 Comm: migration/0 Not tainted 3.19.0-01975-gb1b096e70f23 #4
Call Trace:
[<00113972>] show_stack+0x72/0xf0
[<0081f15e>] dump_stack+0x6e/0x90
[<0081c4e8>] panic+0x108/0x2b0
[<0081be64>] jump_label_bug.isra.2+0x104/0x108
[<00112176>] __jump_label_transform+0x9e/0xd0
[<001121e6>] __sm_arch_jump_label_transform+0x3e/0x50
[<001d1136>] multi_cpu_stop+0x12e/0x170
[<001d1472>] cpu_stopper_thread+0xb2/0x168
[<0015d2ac>] smpboot_thread_fn+0x134/0x1b0
[<00158baa>] kthread+0x10a/0x110
[<00824a86>] kernel_thread_starter+0x6/0xc
Reported-and-tested-by: Sebastian Ott
Signed-off-by: Heiko Carstens
Signed-off-by: Martin Schwidefsky
[bwh: Backported to 3.2: add necessary #include directives]
Signed-off-by: Ben Hutchings
(cherry picked from commit 98b4a75c0792d281beb904911e2271d45c71511a)
Signed-off-by: Willy Tarreau
---
arch/s390/kernel/suspend.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/s390/kernel/suspend.c b/arch/s390/kernel/suspend.c
index cf9e5c6..f03c8df 100644
--- a/arch/s390/kernel/suspend.c
+++ b/arch/s390/kernel/suspend.c
@@ -7,6 +7,8 @@
*/
#include
+#include
+#include
#include
/*
@@ -18,6 +20,8 @@ int pfn_is_nosave(unsigned long pfn)
{
unsigned long nosave_begin_pfn = PFN_DOWN(__pa(&__nosave_begin));
unsigned long nosave_end_pfn = PFN_DOWN(__pa(&__nosave_end));
+ unsigned long eshared_pfn = PFN_DOWN(__pa(&_eshared)) - 1;
+ unsigned long stext_pfn = PFN_DOWN(__pa(&_stext));
/* Always save lowcore pages (LC protection might be enabled). */
if (pfn <= LC_PAGES)
@@ -25,6 +29,8 @@ int pfn_is_nosave(unsigned long pfn)
if (pfn >= nosave_begin_pfn && pfn < nosave_end_pfn)
return 1;
/* Skip memory holes and read-only pages (NSS, DCSS, ...). */
+ if (pfn >= stext_pfn && pfn <= eshared_pfn)
+ return ipl_info.type == IPL_TYPE_NSS ? 1 : 0;
if (tprot(PFN_PHYS(pfn)))
return 1;
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/
[PATCH 2.6.32 39/62] cx24116: fix a buffer overflow when checking userspace params
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Mauro Carvalho Chehab
commit 1fa2337a315a2448c5434f41e00d56b01a22283c upstream.
The maximum size for a DiSEqC command is 6, according to the
userspace API. However, the code allows to write up much more values:
drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg()
error: buffer overflow 'd->msg' 6 <= 23
Signed-off-by: Mauro Carvalho Chehab
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings
(cherry picked from commit 729c8c5e3700410e3436573abfa5b68e8d3c89d6)
Signed-off-by: Willy Tarreau
---
drivers/media/dvb/frontends/cx24116.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/frontends/cx24116.c
b/drivers/media/dvb/frontends/cx24116.c
index 2410d8b..b7d4847 100644
--- a/drivers/media/dvb/frontends/cx24116.c
+++ b/drivers/media/dvb/frontends/cx24116.c
@@ -950,6 +950,10 @@ static int cx24116_send_diseqc_msg(struct dvb_frontend *fe,
struct cx24116_state *state = fe->demodulator_priv;
int i, ret;
+ /* Validate length */
+ if (d->msg_len > sizeof(d->msg))
+return -EINVAL;
+
/* Dump DiSEqC message */
if (debug) {
printk(KERN_INFO "cx24116: %s(", __func__);
@@ -961,10 +965,6 @@ static int cx24116_send_diseqc_msg(struct dvb_frontend *fe,
printk(") toneburst=%d\n", toneburst);
}
- /* Validate length */
- if (d->msg_len > (CX24116_ARGLEN - CX24116_DISEQC_MSGOFS))
- return -EINVAL;
-
/* DiSEqC message */
for (i = 0; i < d->msg_len; i++)
state->dsec_cmd.args[CX24116_DISEQC_MSGOFS + i] = d->msg[i];
--
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 2.6.32 23/62] jbd2: fix r_count overflows leading to buffer overflow in journal recovery
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: "Darrick J. Wong"
commit e531d0bceb402e643a4499de40dd3fa39d8d2e43 upstream.
The journal revoke block recovery code does not check r_count for
sanity, which means that an evil value of r_count could result in
the kernel reading off the end of the revoke table and into whatever
garbage lies beyond. This could crash the kernel, so fix that.
However, in testing this fix, I discovered that the code to write
out the revoke tables also was not correctly checking to see if the
block was full -- the current offset check is fine so long as the
revoke table space size is a multiple of the record size, but this
is not true when either journal_csum_v[23] are set.
Signed-off-by: Darrick J. Wong
Signed-off-by: Theodore Ts'o
Reviewed-by: Jan Kara
[bwh: Backported to 3.2: journal checksumming is not supported, so only
the first fix is needed]
Signed-off-by: Ben Hutchings
(cherry picked from commit 2f6a2bcc01bc9ed73bfb4d698da94ed2a5fcb18c)
Signed-off-by: Willy Tarreau
---
fs/jbd2/recovery.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/jbd2/recovery.c b/fs/jbd2/recovery.c
index 7306328..59cc9c5 100644
--- a/fs/jbd2/recovery.c
+++ b/fs/jbd2/recovery.c
@@ -718,11 +718,16 @@ static int scan_revoke_records(journal_t *journal, struct
buffer_head *bh,
{
jbd2_journal_revoke_header_t *header;
int offset, max;
+ __u32 rcount;
int record_len = 4;
header = (jbd2_journal_revoke_header_t *) bh->b_data;
offset = sizeof(jbd2_journal_revoke_header_t);
- max = be32_to_cpu(header->r_count);
+ rcount = be32_to_cpu(header->r_count);
+
+ if (rcount > journal->j_blocksize)
+ return -EINVAL;
+ max = rcount;
if (JBD2_HAS_INCOMPAT_FEATURE(journal, JBD2_FEATURE_INCOMPAT_64BIT))
record_len = 8;
--
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 2.6.32 24/62] sd: Disable support for 256 byte/sector disks
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Mark Hounschell
commit 74856fbf441929918c49ff262ace9835048e4e6a upstream.
256 bytes per sector support has been broken since 2.6.X,
and no-one stepped up to fix this.
So disable support for it.
Signed-off-by: Mark Hounschell
Signed-off-by: Hannes Reinecke
Signed-off-by: James Bottomley
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
(cherry picked from commit fd6b72574fcdaee123768804d8f1ac28c2a5b3de)
Signed-off-by: Willy Tarreau
---
drivers/scsi/sd.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index a5b55fe..9202fc8 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1045,6 +1045,7 @@ static unsigned int sd_completed_bytes(struct scsi_cmnd
*scmd)
{
u64 start_lba = blk_rq_pos(scmd->request);
u64 end_lba = blk_rq_pos(scmd->request) + (scsi_bufflen(scmd) / 512);
+ u64 factor = scmd->device->sector_size / 512;
u64 bad_lba;
int info_valid;
/*
@@ -1066,16 +1067,9 @@ static unsigned int sd_completed_bytes(struct scsi_cmnd
*scmd)
if (scsi_bufflen(scmd) <= scmd->device->sector_size)
return 0;
- if (scmd->device->sector_size < 512) {
- /* only legitimate sector_size here is 256 */
- start_lba <<= 1;
- end_lba <<= 1;
- } else {
- /* be careful ... don't want any overflows */
- u64 factor = scmd->device->sector_size / 512;
- do_div(start_lba, factor);
- do_div(end_lba, factor);
- }
+ /* be careful ... don't want any overflows */
+ do_div(start_lba, factor);
+ do_div(end_lba, factor);
/* The bad lba was reported incorrectly, we have no idea where
* the error is.
@@ -1581,8 +1575,7 @@ got_data:
if (sector_size != 512 &&
sector_size != 1024 &&
sector_size != 2048 &&
- sector_size != 4096 &&
- sector_size != 256) {
+ sector_size != 4096) {
sd_printk(KERN_NOTICE, sdkp, "Unsupported sector size %d.\n",
sector_size);
/*
@@ -1631,8 +1624,6 @@ got_data:
sdkp->capacity <<= 2;
else if (sector_size == 1024)
sdkp->capacity <<= 1;
- else if (sector_size == 256)
- sdkp->capacity >>= 1;
blk_queue_physical_block_size(sdp->request_queue, sdkp->hw_sector_size);
sdkp->device->sector_size = sector_size;
--
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 2.6.32 48/62] ext4: call sync_blockdev() before invalidate_bdev() in put_super()
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o
commit 89d96a6f8e6491f24fc8f99fd6ae66820e85c6c1 upstream.
Normally all of the buffers will have been forced out to disk before
we call invalidate_bdev(), but there will be some cases, where a file
system operation was aborted due to an ext4_error(), where there may
still be some dirty buffers in the buffer cache for the device. So
try to force them out to memory before calling invalidate_bdev().
This fixes a warning triggered by generic/081:
WARNING: CPU: 1 PID: 3473 at /usr/projects/linux/ext4/fs/block_dev.c:56
__blkdev_put+0xb5/0x16f()
Signed-off-by: Theodore Ts'o
Signed-off-by: Ben Hutchings
(cherry picked from commit 5dedaea4936981382ec0d9833ad372ebd3d8af57)
Signed-off-by: Willy Tarreau
---
fs/ext4/super.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 108515f..045e7bf 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -652,6 +652,7 @@ static void ext4_put_super(struct super_block *sb)
dump_orphan_list(sb, sbi);
J_ASSERT(list_empty(>s_orphan));
+ sync_blockdev(sb->s_bdev);
invalidate_bdev(sb->s_bdev);
if (sbi->journal_bdev && sbi->journal_bdev != sb->s_bdev) {
/*
--
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 2.6.32 56/62] libata: increase the timeout when setting transfer mode
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Mikulas Patocka
commit d531be2ca2f27cca5f041b6a140504999144a617 upstream.
I have a ST4000DM000 disk. If Linux is booted while the disk is spun down,
the command that sets transfer mode causes the disk to spin up. The
spin-up takes longer than the default 5s timeout, so the command fails and
timeout is reported.
Fix this by increasing the timeout to 15s, which is enough for the disk to
spin up.
Signed-off-by: Mikulas Patocka
Signed-off-by: Tejun Heo
Signed-off-by: Ben Hutchings
(cherry picked from commit d6ded32444c070ce41ad0d64fce8957d18009d72)
Signed-off-by: Willy Tarreau
---
drivers/ata/libata-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index d4f7f99..a61b4c3 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4635,7 +4635,8 @@ static unsigned int ata_dev_set_xfermode(struct
ata_device *dev)
else /* In the ancient relic department - skip all of this */
return 0;
- err_mask = ata_exec_internal(dev, , NULL, DMA_NONE, NULL, 0, 0);
+ /* On some disks, this command causes spin-up, so we need longer
timeout */
+ err_mask = ata_exec_internal(dev, , NULL, DMA_NONE, NULL, 0, 15000);
DPRINTK("EXIT, err_mask=%x\n", err_mask);
return err_mask;
--
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 2.6.32 22/62] powerpc: Align TOC to 256 bytes
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Anton Blanchard
commit 5e95235ccd5442d4a4fe11ec4eb99ba1b7959368 upstream.
Recent toolchains force the TOC to be 256 byte aligned. We need
to enforce this alignment in our linker script, otherwise pointers
to our TOC variables (__toc_start, __prom_init_toc_start) could
be incorrect.
If they are bad, we die a few hundred instructions into boot.
Signed-off-by: Anton Blanchard
Signed-off-by: Michael Ellerman
Signed-off-by: Ben Hutchings
(cherry picked from commit 303241421684cdd2f9e931bc42b9de811320e7fd)
Signed-off-by: Willy Tarreau
---
arch/powerpc/kernel/vmlinux.lds.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index dcd01c8..5c2ac91 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -215,6 +215,7 @@ SECTIONS
*(.opd)
}
+ . = ALIGN(256);
.got : AT(ADDR(.got) - LOAD_OFFSET) {
__toc_start = .;
*(.got)
--
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 2.6.32 60/62] dccp: catch failed request_module call in dccp_probe init
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Wang Weidong
Check the return value of request_module during dccp_probe initialisation,
bail out if that call fails.
Signed-off-by: Gerrit Renker
Signed-off-by: Wang Weidong
Signed-off-by: David S. Miller
(cherry picked from commit 965cdea825693c821d200e38fac9402cde6dce6a)
Signed-off-by: Willy Tarreau
---
net/dccp/probe.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/net/dccp/probe.c b/net/dccp/probe.c
index 89f25cb..1610810 100644
--- a/net/dccp/probe.c
+++ b/net/dccp/probe.c
@@ -151,17 +151,6 @@ static const struct file_operations dccpprobe_fops = {
.read= dccpprobe_read,
};
-static __init int setup_jprobe(void)
-{
- int ret = register_jprobe(_send_probe);
-
- if (ret) {
- request_module("dccp");
- ret = register_jprobe(_send_probe);
- }
- return ret;
-}
-
static __init int dccpprobe_init(void)
{
int ret = -ENOMEM;
@@ -175,7 +164,13 @@ static __init int dccpprobe_init(void)
if (!proc_net_fops_create(_net, procname, S_IRUSR,
_fops))
goto err0;
- ret = setup_jprobe();
+ ret = register_jprobe(_send_probe);
+ if (ret) {
+ ret = request_module("dccp");
+ if (!ret)
+ ret = register_jprobe(_send_probe);
+ }
+
if (ret)
goto err1;
--
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 2.6.32 20/62] memstick: mspro_block: add missing curly braces
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
commit 13f6b191aaa11c7fd718d35a0c565f3c16bc1d99 upstream.
Using the indenting we can see the curly braces were obviously intended.
This is a static checker fix, but my guess is that we don't read enough
bytes, because we don't calculate "t_len" correctly.
Fixes: f1d82698029b ('memstick: use fully asynchronous request processing')
Signed-off-by: Dan Carpenter
Cc: Alex Dubov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Ben Hutchings
(cherry picked from commit 0fd0b9f448e1ff459ea4f718def61a197b15bb4c)
Signed-off-by: Willy Tarreau
---
drivers/memstick/core/mspro_block.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/memstick/core/mspro_block.c
b/drivers/memstick/core/mspro_block.c
index 46bd7e2..282348d 100644
--- a/drivers/memstick/core/mspro_block.c
+++ b/drivers/memstick/core/mspro_block.c
@@ -734,7 +734,7 @@ static int mspro_block_complete_req(struct memstick_dev
*card, int error)
if (error || (card->current_mrq.tpc == MSPRO_CMD_STOP)) {
if (msb->data_dir == READ) {
- for (cnt = 0; cnt < msb->current_seg; cnt++)
+ for (cnt = 0; cnt < msb->current_seg; cnt++) {
t_len += msb->req_sg[cnt].length
/ msb->page_size;
@@ -742,6 +742,7 @@ static int mspro_block_complete_req(struct memstick_dev
*card, int error)
t_len += msb->current_page - 1;
t_len *= msb->page_size;
+ }
}
} else
t_len = blk_rq_bytes(msb->block_req);
--
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 2.6.32 15/62] udp: fix behavior of wrong checksums
2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet commit beb39db59d14990e401e235faf66a6b9b31240b0 upstream. We have two problems in UDP stack related to bogus checksums : 1) We return -EAGAIN to application even if receive queue is not empty. This breaks applications using edge trigger epoll() 2) Under UDP flood, we can loop forever without yielding to other processes, potentially hanging the host, especially on non SMP. This patch is an attempt to make things better. We might in the future add extra support for rt applications wanting to better control time spent doing a recv() in a hostile environment. For example we could validate checksums before queuing packets in socket receive queue. Signed-off-by: Eric Dumazet Cc: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings CVE-2015-5364 Signed-off-by: Willy Tarreau --- net/ipv4/udp.c | 6 ++ net/ipv6/udp.c | 6 ++ 2 files changed, 4 insertions(+), 8 deletions(-) diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c index 0b2e07fb..3ae286b 100644 --- a/net/ipv4/udp.c +++ b/net/ipv4/udp.c @@ -1016,10 +1016,8 @@ csum_copy_err: UDP_INC_STATS_USER(sock_net(sk), UDP_MIB_INERRORS, is_udplite); release_sock(sk); - if (noblock) - return -EAGAIN; - - /* starting over for a new packet */ + /* starting over for a new packet, but check if we need to yield */ + cond_resched(); msg->msg_flags &= ~MSG_TRUNC; goto try_again; } diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c index d0367eb..0b023f3 100644 --- a/net/ipv6/udp.c +++ b/net/ipv6/udp.c @@ -301,10 +301,8 @@ csum_copy_err: } release_sock(sk); - if (noblock) - return -EAGAIN; - - /* starting over for a new packet */ + /* starting over for a new packet, but check if we need to yield */ + cond_resched(); msg->msg_flags &= ~MSG_TRUNC; goto try_again; } -- 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 2.6.32 57/62] x86/xen: Probe target addresses in set_aliased_prot() before the hypercall
2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Andy Lutomirski commit aa1acff356bbedfd03b544051f5b371746735d89 upstream. The update_va_mapping hypercall can fail if the VA isn't present in the guest's page tables. Under certain loads, this can result in an OOPS when the target address is in unpopulated vmap space. While we're at it, add comments to help explain what's going on. This isn't a great long-term fix. This code should probably be changed to use something like set_memory_ro. Signed-off-by: Andy Lutomirski Cc: Andrew Cooper Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: David Vrabel Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Sasha Levin Cc: Steven Rostedt Cc: Thomas Gleixner Cc: secur...@kernel.org Cc: xen-devel Link: http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.l...@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings (cherry picked from commit b48d6a721ba2cb475aea937c707f577aafa660a2) Signed-off-by: Willy Tarreau --- arch/x86/xen/enlighten.c | 40 1 file changed, 40 insertions(+) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 126a093..0bba7ac 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -277,6 +277,7 @@ static void set_aliased_prot(void *v, pgprot_t prot) pte_t pte; unsigned long pfn; struct page *page; + unsigned char dummy; ptep = lookup_address((unsigned long)v, ); BUG_ON(ptep == NULL); @@ -286,6 +287,32 @@ static void set_aliased_prot(void *v, pgprot_t prot) pte = pfn_pte(pfn, prot); + /* +* Careful: update_va_mapping() will fail if the virtual address +* we're poking isn't populated in the page tables. We don't +* need to worry about the direct map (that's always in the page +* tables), but we need to be careful about vmap space. In +* particular, the top level page table can lazily propagate +* entries between processes, so if we've switched mms since we +* vmapped the target in the first place, we might not have the +* top-level page table entry populated. +* +* We disable preemption because we want the same mm active when +* we probe the target and when we issue the hypercall. We'll +* have the same nominal mm, but if we're a kernel thread, lazy +* mm dropping could change our pgd. +* +* Out of an abundance of caution, this uses __get_user() to fault +* in the target address just in case there's some obscure case +* in which the target address isn't readable. +*/ + + preempt_disable(); + + pagefault_disable();/* Avoid warnings due to being atomic. */ + __get_user(dummy, (unsigned char __user __force *)v); + pagefault_enable(); + if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0)) BUG(); @@ -297,6 +324,8 @@ static void set_aliased_prot(void *v, pgprot_t prot) BUG(); } else kmap_flush_unused(); + + preempt_enable(); } static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries) @@ -304,6 +333,17 @@ static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries) const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE; int i; + /* +* We need to mark the all aliases of the LDT pages RO. We +* don't need to call vm_flush_aliases(), though, since that's +* only responsible for flushing aliases out the TLBs, not the +* page tables, and Xen will flush the TLB for us if needed. +* +* To avoid confusing future readers: none of this is necessary +* to load the LDT. The hypervisor only checks this when the +* LDT is faulted in due to subsequent descriptor access. +*/ + for(i = 0; i < entries; i += entries_per_page) set_aliased_prot(ldt + i, PAGE_KERNEL_RO); } -- 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 2.6.32 29/62] sctp: Fix race between OOTB responce and route removal
2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Alexander Sverdlin [ Upstream commit 29c4afc4e98f4dc0ea9df22c631841f9c220b944 ] There is NULL pointer dereference possible during statistics update if the route used for OOTB responce is removed at unfortunate time. If the route exists when we receive OOTB packet and we finally jump into sctp_packet_transmit() to send ABORT, but in the meantime route is removed under our feet, we take "no_route" path and try to update stats with IP_INC_STATS(sock_net(asoc->base.sk), ...). But sctp_ootb_pkt_new() used to prepare responce packet doesn't call sctp_transport_set_owner() and therefore there is no asoc associated with this packet. Probably temporary asoc just for OOTB responces is overkill, so just introduce a check like in all other places in sctp_packet_transmit(), where "asoc" is dereferenced. To reproduce this, one needs to 0. ensure that sctp module is loaded (otherwise ABORT is not generated) 1. remove default route on the machine 2. while true; do ip route del [interface-specific route] ip route add [interface-specific route] done 3. send enough OOTB packets (i.e. HB REQs) from another host to trigger ABORT responce On x86_64 the crash looks like this: BUG: unable to handle kernel NULL pointer dereference at 0020 IP: [] sctp_packet_transmit+0x63c/0x730 [sctp] PGD 0 Oops: [#1] PREEMPT SMP Modules linked in: ... CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O4.0.5-1-ARCH #1 Hardware name: ... task: 818124c0 ti: 8180 task.ti: 8180 RIP: 0010:[] [] sctp_packet_transmit+0x63c/0x730 [sctp] RSP: 0018:880127c037b8 EFLAGS: 00010296 RAX: RBX: RCX: 0015ff66b480 RDX: 0015ff66b400 RSI: 880127c17200 RDI: 880123403700 RBP: 880127c03888 R08: 00017200 R09: 814625af R10: ea00047e4680 R11: ff80 R12: 8800b0d38a28 R13: 8800b0d38a28 R14: 8800b3e88000 R15: a05f24e0 FS: () GS:880127c0() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0020 CR3: c855b000 CR4: 07f0 Stack: 880127c03910 8800b0d38a28 8189d240 88011f91b400 880127c03828 a05c94c5 8800baa1c520 0001 Call Trace: [] ? sctp_sf_tabort_8_4_8.isra.20+0x85/0x140 [sctp] [] ? sctp_transport_put+0x52/0x80 [sctp] [] sctp_do_sm+0xb8c/0x19a0 [sctp] [] ? trigger_load_balance+0x90/0x210 [] ? update_process_times+0x59/0x60 [] ? timerqueue_add+0x60/0xb0 [] ? enqueue_hrtimer+0x29/0xa0 [] ? read_tsc+0x9/0x10 [] ? put_page+0x55/0x60 [] ? clockevents_program_event+0x6d/0x100 [] ? skb_free_head+0x58/0x80 [] ? chksum_update+0x1b/0x27 [crc32c_generic] [] ? crypto_shash_update+0xce/0xf0 [] sctp_endpoint_bh_rcv+0x113/0x280 [sctp] [] sctp_inq_push+0x46/0x60 [sctp] [] sctp_rcv+0x880/0x910 [sctp] [] ? sctp_packet_transmit_chunk+0xb0/0xb0 [sctp] [] ? sctp_csum_update+0x20/0x20 [sctp] [] ? ip_route_input_noref+0x235/0xd30 [] ? ack_ioapic_level+0x7b/0x150 [] ip_local_deliver_finish+0xae/0x210 [] ip_local_deliver+0x35/0x90 [] ip_rcv_finish+0xf5/0x370 [] ip_rcv+0x2b8/0x3a0 [] __netif_receive_skb_core+0x763/0xa50 [] __netif_receive_skb+0x18/0x60 [] netif_receive_skb_internal+0x40/0xd0 [] napi_gro_receive+0xe8/0x120 [] rtl8169_poll+0x2da/0x660 [r8169] [] net_rx_action+0x21a/0x360 [] __do_softirq+0xe1/0x2d0 [] irq_exit+0xad/0xb0 [] do_IRQ+0x58/0xf0 [] common_interrupt+0x6d/0x6d [] ? hrtimer_start+0x18/0x20 [] ? sctp_transport_destroy_rcu+0x29/0x30 [sctp] [] ? mwait_idle+0x60/0xa0 [] arch_cpu_idle+0xf/0x20 [] cpu_startup_entry+0x3ec/0x480 [] rest_init+0x85/0x90 [] start_kernel+0x48b/0x4ac [] ? early_idt_handlers+0x120/0x120 [] x86_64_start_reservations+0x2a/0x2c [] x86_64_start_kernel+0x161/0x184 Code: 90 48 8b 80 b8 00 00 00 48 89 85 70 ff ff ff 48 83 bd 70 ff ff ff 00 0f 85 cd fa ff ff 48 89 df 31 db e8 18 63 e7 e0 48 8b 45 80 <48> 8b 40 20 48 8b 40 30 48 8b 80 68 01 00 00 65 48 ff 40 78 e9 RIP [] sctp_packet_transmit+0x63c/0x730 [sctp] RSP CR2: 0020 ---[ end trace 5aec7fd2dc983574 ]--- Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x0 from 0x8100 (relocation range: 0x8000-0x9fff) drm_kms_helper: panic occurred, switching back to text console ---[ end Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by: Alexander Sverdlin Acked-by: Neil Horman Acked-by: Marcelo Ricardo Leitner Acked-by: Vlad Yasevich Signed-off-by: David S. Miller [bwh: Backported to 3.2: sctp alway uses init_net] Signed-off-by: Ben Hutchings (cherry picked from commit 117b8a10fe0c434d9043267efd51f3ba3f3d359a) Signed-off-by: Willy Tarreau --- net/sctp/output.c | 4 +++- 1 file
[PATCH 2.6.32 34/62] MIPS: Fix race condition in lazy cache flushing.
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Lars Persson
commit 4d46a67a3eb827ccf1125959936fd51ba318dabc upstream.
The lazy cache flushing implemented in the MIPS kernel suffers from a
race condition that is exposed by do_set_pte() in mm/memory.c.
A pre-condition is a file-system that writes to the page from the CPU
in its readpage method and then calls flush_dcache_page(). One example
is ubifs. Another pre-condition is that the dcache flush is postponed
in __flush_dcache_page().
Upon a page fault for an executable mapping not existing in the
page-cache, the following will happen:
1. Write to the page
2. flush_dcache_page
3. flush_icache_page
4. set_pte_at
5. update_mmu_cache (commits the flush of a dcache-dirty page)
Between steps 4 and 5 another thread can hit the same page and it will
encounter a valid pte. Because the data still is in the L1 dcache the CPU
will fetch stale data from L2 into the icache and execute garbage.
This fix moves the commit of the cache flush to step 3 to close the
race window. It also reduces the amount of flushes on non-executable
mappings because we never enter __flush_dcache_page() for non-aliasing
CPUs.
Regressions can occur in drivers that mistakenly relies on the
flush_dcache_page() in get_user_pages() for DMA operations.
[r...@linux-mips.org: Folded in patch 9346 to fix highmem issue.]
Signed-off-by: Lars Persson
Cc: linux-m...@linux-mips.org
Cc: paul.bur...@imgtec.com
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/9346/
Patchwork: https://patchwork.linux-mips.org/patch/9738/
Signed-off-by: Ralf Baechle
Signed-off-by: Ben Hutchings
(cherry picked from commit 6bde6a3df0b4c8680d51c987d446b0ff2d6df0a6)
Signed-off-by: Willy Tarreau
---
arch/mips/include/asm/cacheflush.h | 38 +++---
arch/mips/mm/cache.c | 12
2 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/arch/mips/include/asm/cacheflush.h
b/arch/mips/include/asm/cacheflush.h
index 03b1d69..2211f24 100644
--- a/arch/mips/include/asm/cacheflush.h
+++ b/arch/mips/include/asm/cacheflush.h
@@ -29,6 +29,20 @@
* - flush_icache_all() flush the entire instruction cache
* - flush_data_cache_page() flushes a page from the data cache
*/
+
+ /*
+ * This flag is used to indicate that the page pointed to by a pte
+ * is dirty and requires cleaning before returning it to the user.
+ */
+#define PG_dcache_dirtyPG_arch_1
+
+#define Page_dcache_dirty(page)\
+ test_bit(PG_dcache_dirty, &(page)->flags)
+#define SetPageDcacheDirty(page) \
+ set_bit(PG_dcache_dirty, &(page)->flags)
+#define ClearPageDcacheDirty(page) \
+ clear_bit(PG_dcache_dirty, &(page)->flags)
+
extern void (*flush_cache_all)(void);
extern void (*__flush_cache_all)(void);
extern void (*flush_cache_mm)(struct mm_struct *mm);
@@ -37,12 +51,14 @@ extern void (*flush_cache_range)(struct vm_area_struct *vma,
unsigned long start, unsigned long end);
extern void (*flush_cache_page)(struct vm_area_struct *vma, unsigned long
page, unsigned long pfn);
extern void __flush_dcache_page(struct page *page);
+extern void __flush_icache_page(struct vm_area_struct *vma, struct page *page);
static inline void flush_dcache_page(struct page *page)
{
- if (cpu_has_dc_aliases || !cpu_has_ic_fills_f_dc)
+ if (cpu_has_dc_aliases)
__flush_dcache_page(page);
-
+ else if (!cpu_has_ic_fills_f_dc)
+ SetPageDcacheDirty(page);
}
#define flush_dcache_mmap_lock(mapping)do { } while (0)
@@ -60,6 +76,11 @@ static inline void flush_anon_page(struct vm_area_struct
*vma,
static inline void flush_icache_page(struct vm_area_struct *vma,
struct page *page)
{
+ if (!cpu_has_ic_fills_f_dc && (vma->vm_flags & VM_EXEC) &&
+ Page_dcache_dirty(page)) {
+ __flush_icache_page(vma, page);
+ ClearPageDcacheDirty(page);
+ }
}
extern void (*flush_icache_range)(unsigned long start, unsigned long end);
@@ -94,19 +115,6 @@ extern void (*flush_icache_all)(void);
extern void (*local_flush_data_cache_page)(void * addr);
extern void (*flush_data_cache_page)(unsigned long addr);
-/*
- * This flag is used to indicate that the page pointed to by a pte
- * is dirty and requires cleaning before returning it to the user.
- */
-#define PG_dcache_dirtyPG_arch_1
-
-#define Page_dcache_dirty(page)\
- test_bit(PG_dcache_dirty, &(page)->flags)
-#define SetPageDcacheDirty(page) \
- set_bit(PG_dcache_dirty, &(page)->flags)
-#define ClearPageDcacheDirty(page) \
- clear_bit(PG_dcache_dirty, &(page)->flags)
-
/* Run kernel code uncached, useful for cache probing functions. */
unsigned long run_uncached(void *func);
diff --git a/arch/mips/mm/cache.c
[PATCH 2.6.32 35/62] MIPS: Fix cpu_has_mips_r2_exec_hazard.
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Ralf Baechle
commit 9cdf30bd3bac697fc533988f44a117434a858f69 upstream.
Returns a non-zero value if the current processor implementation requires
an IHB instruction to deal with an instruction hazard as per MIPS R2
architecture specification, zero otherwise.
For a discussion, see http://patchwork.linux-mips.org/patch/9539/.
Signed-off-by: Ralf Baechle
[bwh: Backported to 3.2: trim the CPU type list]
Signed-off-by: Ben Hutchings
(cherry picked from commit 8feb2a714b3478b2cde5c576fd9f47ef44b60e8d)
Signed-off-by: Willy Tarreau
---
arch/mips/include/asm/cpu-features.h | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/cpu-features.h
b/arch/mips/include/asm/cpu-features.h
index 1f4df64..a3dbb59 100644
--- a/arch/mips/include/asm/cpu-features.h
+++ b/arch/mips/include/asm/cpu-features.h
@@ -150,8 +150,32 @@
#define cpu_has_mips_r (cpu_has_mips32r1 | cpu_has_mips32r2 | \
cpu_has_mips64r1 | cpu_has_mips64r2)
+/*
+ * cpu_has_mips_r2_exec_hazard - return if IHB is required on current processor
+ *
+ * Returns non-zero value if the current processor implementation requires
+ * an IHB instruction to deal with an instruction hazard as per MIPS R2
+ * architecture specification, zero otherwise.
+ */
#ifndef cpu_has_mips_r2_exec_hazard
-#define cpu_has_mips_r2_exec_hazard cpu_has_mips_r2
+#define cpu_has_mips_r2_exec_hazard\
+({ \
+ int __res; \
+ \
+ switch (current_cpu_type()) { \
+ case CPU_74K: \
+ case CPU_CAVIUM_OCTEON: \
+ case CPU_CAVIUM_OCTEON_PLUS:\
+ case CPU_CAVIUM_OCTEON2:\
+ __res = 0; \
+ break; \
+ \
+ default:\
+ __res = 1; \
+ } \
+ \
+ __res; \
+})
#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/
[PATCH 2.6.32 25/62] lguest: fix out-by-one error in address checking.
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Rusty Russell
commit 83a35114d0e4583e6b0ca39502e68b6a92e2910c upstream.
This bug has been there since day 1; addresses in the top guest physical
page weren't considered valid. You could map that page (the check in
check_gpte() is correct), but if a guest tried to put a pagetable there
we'd check that address manually when walking it, and kill the guest.
Signed-off-by: Rusty Russell
Signed-off-by: Linus Torvalds
Signed-off-by: Ben Hutchings
(cherry picked from commit a8f5259269671acb4f0bdb6e0a53974aa5b351ff)
Signed-off-by: Willy Tarreau
---
drivers/lguest/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/lguest/core.c b/drivers/lguest/core.c
index 8744d24..42ad32c 100644
--- a/drivers/lguest/core.c
+++ b/drivers/lguest/core.c
@@ -170,7 +170,7 @@ static void unmap_switcher(void)
bool lguest_address_ok(const struct lguest *lg,
unsigned long addr, unsigned long len)
{
- return (addr+len) / PAGE_SIZE < lg->pfn_limit && (addr+len >= addr);
+ return addr+len <= lg->pfn_limit * PAGE_SIZE && (addr+len >= addr);
}
/*
--
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 2.6.32 02/62] sg_start_req(): make sure that theres not too many elements in iovec
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Al Viro
commit 451a2886b6bf90e2fb378f7c46c655450fb96e81 upstream.
unfortunately, allowing an arbitrary 16bit value means a possibility of
overflow in the calculation of total number of pages in bio_map_user_iov() -
we rely on there being no more than PAGE_SIZE members of sum in the
first loop there. If that sum wraps around, we end up allocating
too small array of pointers to pages and it's easy to overflow it in
the second loop.
X-Coverup: TINC (and there's no lumber cartel either)
Signed-off-by: Al Viro
[bwh: s/MAX_UIOVEC/UIO_MAXIOV/. This was fixed upstream by commit
fdc81f45e9f5 ("sg_start_req(): use import_iovec()"), but we don't have
that function.]
Signed-off-by: Ben Hutchings
(cherry picked from commit 07213eed86c17c544bb10568fc04e49e03730ab7)
Signed-off-by: Willy Tarreau
---
drivers/scsi/sg.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 040f751..f51e531 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1662,6 +1662,9 @@ static int sg_start_req(Sg_request *srp, unsigned char
*cmd)
md->from_user = 0;
}
+ if (unlikely(iov_count > UIO_MAXIOV))
+ return -EINVAL;
+
if (iov_count) {
int len, size = sizeof(struct sg_iovec) * iov_count;
struct iovec *iov;
--
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: [PATCH 2.6.32 00/62] 2.6.32.68-longterm review
On Sun, Sep 13, 2015 at 12:56:06AM +0200, Willy Tarreau wrote: > Responses should be made by Sat Sep 19 00:56:05 CEST 2015. I really meant Fri Sep 18 09:00:00 CEST 2015, sorry the unedited message went out. Also, special thanks go to Ben Hutchings who provided me with a clean series of fixes ready to be applied to address the following CVEs : CVE-2011-5321 CVE-2012-6689 CVE-2014-3184 CVE-2014-9683 CVE-2014-9728 CVE-2014-9729 CVE-2014-9730 CVE-2014-9731 CVE-2015-1805 CVE-2015-4167 CVE-2015-5364 Most of the remaining patches were backported directly from latest 3.2 and a few others were just fixes for build warnings. Nothing really tricky here (at least I hope). Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.6.32 11/62] udf: Check path length when reading symlink
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit 0e5cc9a40ada6046e6bc3bdfcd0c0d7e4b706b14 upstream.
Symlink reading code does not check whether the resulting path fits into
the page provided by the generic code. This isn't as easy as just
checking the symlink size because of various encoding conversions we
perform on path. So we have to check whether there is still enough space
in the buffer on the fly.
Reported-by: Carl Henrik Lunde
Signed-off-by: Jan Kara
[bwh: Backported to 2.6.32: adjust context, indentation]
Signed-off-by: Ben Hutchings
CVE-2014-9731
Signed-off-by: Willy Tarreau
---
fs/udf/dir.c | 3 ++-
fs/udf/namei.c | 3 ++-
fs/udf/symlink.c | 31 ++-
fs/udf/udfdecl.h | 3 ++-
fs/udf/unicode.c | 28
5 files changed, 48 insertions(+), 20 deletions(-)
diff --git a/fs/udf/dir.c b/fs/udf/dir.c
index 61d9a76..1c551ea 100644
--- a/fs/udf/dir.c
+++ b/fs/udf/dir.c
@@ -164,7 +164,8 @@ static int do_udf_readdir(struct inode *dir, struct file
*filp,
struct kernel_lb_addr tloc =
lelb_to_cpu(cfi.icb.extLocation);
iblock = udf_get_lb_pblock(dir->i_sb, , 0);
- flen = udf_get_filename(dir->i_sb, nameptr, fname, lfi);
+ flen = udf_get_filename(dir->i_sb, nameptr, lfi, fname,
+ UDF_NAME_LEN);
dt_type = DT_UNKNOWN;
}
diff --git a/fs/udf/namei.c b/fs/udf/namei.c
index b754151..0a6eb3f 100644
--- a/fs/udf/namei.c
+++ b/fs/udf/namei.c
@@ -237,7 +237,8 @@ static struct fileIdentDesc *udf_find_entry(struct inode
*dir,
if (!lfi)
continue;
- flen = udf_get_filename(dir->i_sb, nameptr, fname, lfi);
+ flen = udf_get_filename(dir->i_sb, nameptr, lfi, fname,
+ UDF_NAME_LEN);
if (flen && udf_match(flen, fname, child->len, child->name))
goto out_ok;
}
diff --git a/fs/udf/symlink.c b/fs/udf/symlink.c
index 2d60484..500c146 100644
--- a/fs/udf/symlink.c
+++ b/fs/udf/symlink.c
@@ -32,13 +32,16 @@
#include
#include "udf_i.h"
-static void udf_pc_to_char(struct super_block *sb, char *from, int fromlen,
- char *to)
+static int udf_pc_to_char(struct super_block *sb, char *from,
+ int fromlen, char *to, int tolen)
{
struct pathComponent *pc;
int elen = 0;
+ int comp_len;
char *p = to;
+ /* Reserve one byte for terminating \0 */
+ tolen--;
while (elen < fromlen) {
pc = (struct pathComponent *)(from + elen);
switch (pc->componentType) {
@@ -51,22 +54,37 @@ static void udf_pc_to_char(struct super_block *sb, char
*from, int fromlen,
break;
/* Fall through */
case 2:
+ if (tolen == 0)
+ return -ENAMETOOLONG;
p = to;
*p++ = '/';
+ tolen--;
break;
case 3:
+ if (tolen < 3)
+ return -ENAMETOOLONG;
memcpy(p, "../", 3);
p += 3;
+ tolen -= 3;
break;
case 4:
+ if (tolen < 2)
+ return -ENAMETOOLONG;
memcpy(p, "./", 2);
p += 2;
+ tolen -= 2;
/* that would be . - just ignore */
break;
case 5:
- p += udf_get_filename(sb, pc->componentIdent, p,
- pc->lengthComponentIdent);
+ comp_len = udf_get_filename(sb, pc->componentIdent,
+ pc->lengthComponentIdent,
+ p, tolen);
+ p += comp_len;
+ tolen -= comp_len;
+ if (tolen == 0)
+ return -ENAMETOOLONG;
*p++ = '/';
+ tolen--;
break;
}
elen += sizeof(struct pathComponent) + pc->lengthComponentIdent;
@@ -75,6 +93,7 @@ static void udf_pc_to_char(struct super_block *sb, char
*from, int fromlen,
p[-1] = '\0';
else
p[0] = '\0';
+ return 0;
}
static int udf_symlink_filler(struct file *file, struct page *page)
@@ -107,8 +126,10 @@ static int udf_symlink_filler(struct file *file, struct
page *page)
[PATCH 2.6.32 36/62] MIPS: Octeon: Delete override of cpu_has_mips_r2_exec_hazard.
2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Ralf Baechle commit f05ff43355e6997c18f82ddcee370a6e5f8643ce upstream. This is no longer needed with the fixed, new and improved definition of cpu_has_mips_r2_exec_hazard in . For a discussion, see http://patchwork.linux-mips.org/patch/9539/. Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings (cherry picked from commit af2b0e8019d23d6db0ec339821aec23f6c19e367) Signed-off-by: Willy Tarreau --- arch/mips/include/asm/mach-cavium-octeon/cpu-feature-overrides.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/mips/include/asm/mach-cavium-octeon/cpu-feature-overrides.h b/arch/mips/include/asm/mach-cavium-octeon/cpu-feature-overrides.h index 425e708..c829fde 100644 --- a/arch/mips/include/asm/mach-cavium-octeon/cpu-feature-overrides.h +++ b/arch/mips/include/asm/mach-cavium-octeon/cpu-feature-overrides.h @@ -51,7 +51,6 @@ #define cpu_has_mips32r2 0 #define cpu_has_mips64r1 0 #define cpu_has_mips64r2 1 -#define cpu_has_mips_r2_exec_hazard 0 #define cpu_has_dsp0 #define cpu_has_mipsmt 0 #define cpu_has_userlocal 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/
[PATCH 2.6.32 19/62] ptrace: fix race between ptrace_resume() and wait_task_stopped()
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Oleg Nesterov
commit b72c186999e689cb0b055ab1c7b3cd8fffbeb5ed upstream.
ptrace_resume() is called when the tracee is still __TASK_TRACED. We set
tracee->exit_code and then wake_up_state() changes tracee->state. If the
tracer's sub-thread does wait() in between, task_stopped_code(ptrace => T)
wrongly looks like another report from tracee.
This confuses debugger, and since wait_task_stopped() clears ->exit_code
the tracee can miss a signal.
Test-case:
#include
#include
#include
#include
#include
#include
int pid;
void *waiter(void *arg)
{
int stat;
for (;;) {
assert(pid == wait());
assert(WIFSTOPPED(stat));
if (WSTOPSIG(stat) == SIGHUP)
continue;
assert(WSTOPSIG(stat) == SIGCONT);
printf("ERR! extra/wrong report:%x\n", stat);
}
}
int main(void)
{
pthread_t thread;
pid = fork();
if (!pid) {
assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
for (;;)
kill(getpid(), SIGHUP);
}
assert(pthread_create(, NULL, waiter, NULL) == 0);
for (;;)
ptrace(PTRACE_CONT, pid, 0, SIGCONT);
return 0;
}
Note for stable: the bug is very old, but without 9899d11f6544 "ptrace:
ensure arch_ptrace/ptrace_request can never race with SIGKILL" the fix
should use lock_task_sighand(child).
Signed-off-by: Oleg Nesterov
Reported-by: Pavel Labath
Tested-by: Pavel Labath
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Ben Hutchings
(cherry picked from commit e3f81ba2f0546f030fc234f7aade3016532c75b1)
Signed-off-by: Willy Tarreau
---
kernel/ptrace.c | 20
1 file changed, 20 insertions(+)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 4185220..03da336 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -516,6 +516,8 @@ static int ptrace_setsiginfo(struct task_struct *child,
const siginfo_t *info)
static int ptrace_resume(struct task_struct *child, long request, long data)
{
+ bool need_siglock;
+
if (!valid_signal(data))
return -EIO;
@@ -543,8 +545,26 @@ static int ptrace_resume(struct task_struct *child, long
request, long data)
user_disable_single_step(child);
}
+ /*
+* Change ->exit_code and ->state under siglock to avoid the race
+* with wait_task_stopped() in between; a non-zero ->exit_code will
+* wrongly look like another report from tracee.
+*
+* Note that we need siglock even if ->exit_code == data and/or this
+* status was not reported yet, the new status must not be cleared by
+* wait_task_stopped() after resume.
+*
+* If data == 0 we do not care if wait_task_stopped() reports the old
+* status and clears the code too; this can't race with the tracee, it
+* takes siglock after resume.
+*/
+ need_siglock = data && !thread_group_empty(current);
+ if (need_siglock)
+ spin_lock_irq(>sighand->siglock);
child->exit_code = data;
wake_up_state(child, __TASK_TRACED);
+ if (need_siglock)
+ spin_unlock_irq(>sighand->siglock);
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/
[PATCH 2.6.32 08/62] udf: Verify i_size when loading inode
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit e159332b9af4b04d882dbcfe1bb0117f0a6d4b58 upstream.
Verify that inode size is sane when loading inode with data stored in
ICB. Otherwise we may get confused later when working with the inode and
inode size is too big.
Reported-by: Carl Henrik Lunde
Signed-off-by: Jan Kara
[bwh: Backported to 2.6.32: on error, call make_bad_inode() then return]
Signed-off-by: Ben Hutchings
CVE-2014-9728, CVE-2014-9729
Signed-off-by: Willy Tarreau
---
fs/udf/inode.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 11c291e..7901ad7 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1286,6 +1286,24 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
iinfo->i_lenEAttr;
}
+ /* Sanity checks for files in ICB so that we don't get confused later */
+ if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
+ /*
+* For file in ICB data is stored in allocation descriptor
+* so sizes should match
+*/
+ if (iinfo->i_lenAlloc != inode->i_size) {
+ make_bad_inode(inode);
+ return;
+ }
+ /* File in ICB has to fit in there... */
+ if (inode->i_size > inode->i_sb->s_blocksize -
+ udf_file_entry_alloc_offset(inode)) {
+ make_bad_inode(inode);
+ return;
+ }
+ }
+
switch (fe->icbTag.fileType) {
case ICBTAG_FILE_TYPE_DIRECTORY:
inode->i_op = _dir_inode_operations;
--
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 2.6.32 52/62] tracing/filter: Do not allow infix to exceed end of string
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: "Steven Rostedt (Red Hat)"
commit 6b88f44e161b9ee2a803e5b2b1fbcf4e20e8b980 upstream.
While debugging a WARN_ON() for filtering, I found that it is possible
for the filter string to be referenced after its end. With the filter:
# echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter
The filter_parse() function can call infix_get_op() which calls
infix_advance() that updates the infix filter pointers for the cnt
and tail without checking if the filter is already at the end, which
will put the cnt to zero and the tail beyond the end. The loop then calls
infix_next() that has
ps->infix.cnt--;
return ps->infix.string[ps->infix.tail++];
The cnt will now be below zero, and the tail that is returned is
already passed the end of the filter string. So far the allocation
of the filter string usually has some buffer that is zeroed out, but
if the filter string is of the exact size of the allocated buffer
there's no guarantee that the charater after the nul terminating
character will be zero.
Luckily, only root can write to the filter.
Signed-off-by: Steven Rostedt
Signed-off-by: Ben Hutchings
(cherry picked from commit 7cc2315e7b9c148ee549d4cfbf68735a578b64db)
Signed-off-by: Willy Tarreau
---
kernel/trace/trace_events_filter.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index ab10a9f..c23d67b 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -752,6 +752,9 @@ static void parse_init(struct filter_parse_state *ps,
static char infix_next(struct filter_parse_state *ps)
{
+ if (!ps->infix.cnt)
+ return 0;
+
ps->infix.cnt--;
return ps->infix.string[ps->infix.tail++];
@@ -767,6 +770,9 @@ static char infix_peek(struct filter_parse_state *ps)
static void infix_advance(struct filter_parse_state *ps)
{
+ if (!ps->infix.cnt)
+ return;
+
ps->infix.cnt--;
ps->infix.tail++;
}
--
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 2.6.32 45/62] ext4: fix race between truncate and __ext4_journalled_writepage()
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o
commit bdf96838aea6a265f2ae6cbcfb12a778c84a0b8e upstream.
The commit cf108bca465d: "ext4: Invert the locking order of page_lock
and transaction start" caused __ext4_journalled_writepage() to drop
the page lock before the page was written back, as part of changing
the locking order to jbd2_journal_start -> page_lock. However, this
introduced a potential race if there was a truncate racing with the
data=journalled writeback mode.
Fix this by grabbing the page lock after starting the journal handle,
and then checking to see if page had gotten truncated out from under
us.
This fixes a number of different warnings or BUG_ON's when running
xfstests generic/086 in data=journalled mode, including:
jbd2_journal_dirty_metadata: vdc-8: bad jh for block 115643: transaction (ee3fe7
c0, 164), jh->b_transaction ( (null), 0), jh->b_next_transaction ( (null),
0), jlist 0
- and -
kernel BUG at /usr/projects/linux/ext4/fs/jbd2/transaction.c:2200!
...
Call Trace:
[] ? __ext4_journalled_invalidatepage+0x117/0x117
[] __ext4_journalled_invalidatepage+0x10f/0x117
[] ? __ext4_journalled_invalidatepage+0x117/0x117
[] ? lock_buffer+0x36/0x36
[] ext4_journalled_invalidatepage+0xd/0x22
[] do_invalidatepage+0x22/0x26
[] truncate_inode_page+0x5b/0x85
[] truncate_inode_pages_range+0x156/0x38c
[] truncate_inode_pages+0x11/0x15
[] truncate_pagecache+0x55/0x71
[] ext4_setattr+0x4a9/0x560
[] ? current_kernel_time+0x10/0x44
[] notify_change+0x1c7/0x2be
[] do_truncate+0x65/0x85
[] ? file_ra_state_init+0x12/0x29
- and -
WARNING: CPU: 1 PID: 1331 at /usr/projects/linux/ext4/fs/jbd2/transaction.c:1396
irty_metadata+0x14a/0x1ae()
...
Call Trace:
[] ? console_unlock+0x3a1/0x3ce
[] dump_stack+0x48/0x60
[] warn_slowpath_common+0x89/0xa0
[] ? jbd2_journal_dirty_metadata+0x14a/0x1ae
[] warn_slowpath_null+0x14/0x18
[] jbd2_journal_dirty_metadata+0x14a/0x1ae
[] __ext4_handle_dirty_metadata+0xd4/0x19d
[] write_end_fn+0x40/0x53
[] ext4_walk_page_buffers+0x4e/0x6a
[] ext4_writepage+0x354/0x3b8
[] ? mpage_release_unused_pages+0xd4/0xd4
[] ? wait_on_buffer+0x2c/0x2c
[] ? ext4_writepage+0x3b8/0x3b8
[] __writepage+0x10/0x2e
[] write_cache_pages+0x22d/0x32c
[] ? ext4_writepage+0x3b8/0x3b8
[] ext4_writepages+0x102/0x607
[] ? sched_clock_local+0x10/0x10e
[] ? __lock_is_held+0x2e/0x44
[] ? lock_is_held+0x43/0x51
[] do_writepages+0x1c/0x29
[] __writeback_single_inode+0xc3/0x545
[] writeback_sb_inodes+0x21f/0x36d
...
Signed-off-by: Theodore Ts'o
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
(cherry picked from commit b77ea3c2439c54f864487fb7a69007027c833bfb)
[wt: adjusted context since we're missing 441c850]
Signed-off-by: Willy Tarreau
---
fs/ext4/inode.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index babf448..90077ec 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -2670,13 +2670,27 @@ static int __ext4_journalled_writepage(struct page
*page,
page_bufs = page_buffers(page);
BUG_ON(!page_bufs);
walk_page_buffers(handle, page_bufs, 0, len, NULL, bget_one);
- /* As soon as we unlock the page, it can go away, but we have
-* references to buffers so we are safe */
+ /*
+* We need to release the page lock before we start the
+* journal, so grab a reference so the page won't disappear
+* out from under us.
+*/
+ get_page(page);
unlock_page(page);
handle = ext4_journal_start(inode, ext4_writepage_trans_blocks(inode));
if (IS_ERR(handle)) {
ret = PTR_ERR(handle);
+ put_page(page);
+ goto out_no_pagelock;
+ }
+
+ lock_page(page);
+ put_page(page);
+ if (page->mapping != mapping) {
+ /* The page got truncated from under us */
+ ext4_journal_stop(handle);
+ ret = 0;
goto out;
}
@@ -2694,6 +2708,8 @@ static int __ext4_journalled_writepage(struct page *page,
walk_page_buffers(handle, page_bufs, 0, len, NULL, bput_one);
ext4_set_inode_state(inode, EXT4_STATE_JDATA);
out:
+ unlock_page(page);
+out_no_pagelock:
return ret;
}
--
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 2.6.32 04/62] TTY: drop driver reference in tty_open fail path
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Jiri Slaby
commit c290f8358acaeffd8e0c551ddcc24d1206143376 upstream.
When tty_driver_lookup_tty fails in tty_open, we forget to drop a
reference to the tty driver. This was added by commit 4a2b5fddd5 (Move
tty lookup/reopen to caller).
Fix that by adding tty_driver_kref_put to the fail path.
I will refactor the code later. This is for the ease of backporting to
stable.
Introduced-in: v2.6.28-rc2
Signed-off-by: Jiri Slaby
Cc: Alan Cox
Acked-by: Sukadev Bhattiprolu
Signed-off-by: Greg Kroah-Hartman
[bwh: Backported to 2.6.32: adjust filename]
Signed-off-by: Ben Hutchings
CVE-2011-5321
Signed-off-by: Willy Tarreau
---
drivers/char/tty_io.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index cbdd1698..6c71534 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -1779,6 +1779,7 @@ got_driver:
if (IS_ERR(tty)) {
mutex_unlock(_mutex);
+ tty_driver_kref_put(driver);
return PTR_ERR(tty);
}
}
--
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 2.6.32 62/62] ipv6: Fix return of xfrm6_tunnel_rcv()
2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: "David S. Miller" Like ipv4, just return xfrm6_rcv_spi()'s return value directly. Signed-off-by: David S. Miller (cherry picked from commit 6ac3f6649223d916bbdf1e823926f8f3b34b5d99) Signed-off-by: Willy Tarreau --- net/ipv6/xfrm6_tunnel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv6/xfrm6_tunnel.c b/net/ipv6/xfrm6_tunnel.c index 48bb1e3..5980e6e 100644 --- a/net/ipv6/xfrm6_tunnel.c +++ b/net/ipv6/xfrm6_tunnel.c @@ -258,7 +258,7 @@ static int xfrm6_tunnel_rcv(struct sk_buff *skb) __be32 spi; spi = xfrm6_tunnel_spi_lookup((xfrm_address_t *)>saddr); - return xfrm6_rcv_spi(skb, IPPROTO_IPV6, spi) > 0 ? : 0; + return xfrm6_rcv_spi(skb, IPPROTO_IPV6, spi); } static int xfrm6_tunnel_err(struct sk_buff *skb, struct inet6_skb_parm *opt, -- 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 2.6.32 58/62] dccp: fix auto-loading of dccp(_probe)
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Gerrit Renker
This fixes commit (38ff3e6bb987ec583268da8eb22628293095d43b) ("dccp_probe:
Fix module load dependencies between dccp and dccp_probe", from 15 Jan).
It fixes the construction of the first argument of try_then_request_module(),
where only valid return codes from the first argument should be returned.
What we do now is assign the result of register_jprobe() to ret, without
the side effect of the comparison.
Acked-by: Gerrit Renker
Signed-off-by: Neil Horman
Signed-off-by: David S. Miller
(cherry picked from commit 1386be55e32a3c5d8ef4a2b243c530a7b664c02c)
Signed-off-by: Willy Tarreau
---
net/dccp/probe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/dccp/probe.c b/net/dccp/probe.c
index 4875998..3ba43b8 100644
--- a/net/dccp/probe.c
+++ b/net/dccp/probe.c
@@ -164,8 +164,8 @@ static __init int dccpprobe_init(void)
if (!proc_net_fops_create(_net, procname, S_IRUSR,
_fops))
goto err0;
- ret = try_then_request_module((register_jprobe(_send_probe) == 0),
- "dccp");
+ try_then_request_module((ret = register_jprobe(_send_probe)) == 0,
+ "dccp");
if (ret)
goto err1;
--
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 2.6.32 41/62] staging: vt6655: device_rx_srv check sk_buff is NULL
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Malcolm Priestley
commit b5eeed8cb6097c8ea660b6598d36fdbb94065a22 upstream.
There is a small chance that pRD->pRDInfo->skb could go NULL
while the interrupt is processing.
Put NULL check on loop to break out.
Signed-off-by: Malcolm Priestley
Signed-off-by: Greg Kroah-Hartman
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings
(cherry picked from commit 35ee488df7402c0549f8329dc20690cf7fe22492)
Signed-off-by: Willy Tarreau
---
drivers/staging/vt6655/device_main.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/vt6655/device_main.c
b/drivers/staging/vt6655/device_main.c
index 269d1e2..1680bed 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1605,6 +1605,10 @@ static int device_rx_srv(PSDevice pDevice, UINT uIdx) {
//DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO "pDevice->pCurrRD = %x, works =
%d\n", pRD, works);
if (works++>15)
break;
+
+if (!pRD->pRDInfo->skb)
+break;
+
if (device_receive_frame(pDevice, pRD)) {
if (!device_alloc_rx_buf(pDevice,pRD)) {
DBG_PRT(MSG_LEVEL_ERR, KERN_ERR
--
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 2.6.32 31/62] include/linux/sched.h: dont use task->pid/tgid in same_thread_group/has_group_leader_pid
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Oleg Nesterov
commit e1403b8edf669ff49bbdf602cc97fefa2760cb15 upstream.
task_struct->pid/tgid should go away.
1. Change same_thread_group() to use task->signal for comparison.
2. Change has_group_leader_pid(task) to compare task_pid(task) with
signal->leader_pid.
Signed-off-by: Oleg Nesterov
Cc: Michal Hocko
Cc: Sergey Dyasly
Reviewed-by: "Eric W. Biederman"
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Peter Zijlstra
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Ben Hutchings
Cc: Sheng Yong
(cherry picked from commit a7b4d51399316329b6a3d9eaeab224d83eeebe67)
Signed-off-by: Willy Tarreau
---
include/linux/sched.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 56e1771..33c1ec2 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2211,15 +2211,15 @@ extern bool current_is_single_threaded(void);
* all we care about is that we have a task with the appropriate
* pid, we don't actually care if we have the right task.
*/
-static inline int has_group_leader_pid(struct task_struct *p)
+static inline bool has_group_leader_pid(struct task_struct *p)
{
- return p->pid == p->tgid;
+ return task_pid(p) == p->signal->leader_pid;
}
static inline
-int same_thread_group(struct task_struct *p1, struct task_struct *p2)
+bool same_thread_group(struct task_struct *p1, struct task_struct *p2)
{
- return p1->tgid == p2->tgid;
+ return p1->signal == p2->signal;
}
static inline struct task_struct *next_thread(const struct task_struct *p)
--
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 2.6.32 09/62] udf: Verify symlink size before loading it
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit a1d47b262952a45aae62bd49cfaf33dd76c11a2c upstream.
UDF specification allows arbitrarily large symlinks. However we support
only symlinks at most one block large. Check the length of the symlink
so that we don't access memory beyond end of the symlink block.
Reported-by: Carl Henrik Lunde
Signed-off-by: Jan Kara
[bwh: Backported to 2.6.32: adjust context]
Signed-off-by: Ben Hutchings
CVE-2014-9728
Signed-off-by: Willy Tarreau
---
fs/udf/symlink.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/fs/udf/symlink.c b/fs/udf/symlink.c
index c3265e1..e28a902 100644
--- a/fs/udf/symlink.c
+++ b/fs/udf/symlink.c
@@ -76,10 +76,16 @@ static int udf_symlink_filler(struct file *file, struct
page *page)
struct inode *inode = page->mapping->host;
struct buffer_head *bh = NULL;
char *symlink;
- int err = -EIO;
+ int err;
char *p = kmap(page);
struct udf_inode_info *iinfo;
+ /* We don't support symlinks longer than one block */
+ if (inode->i_size > inode->i_sb->s_blocksize) {
+ err = -ENAMETOOLONG;
+ goto out_unmap;
+ }
+
lock_kernel();
iinfo = UDF_I(inode);
if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
@@ -87,8 +93,10 @@ static int udf_symlink_filler(struct file *file, struct page
*page)
} else {
bh = sb_bread(inode->i_sb, udf_block_map(inode, 0));
- if (!bh)
- goto out;
+ if (!bh) {
+ err = -EIO;
+ goto out_unlock_inode;
+ }
symlink = bh->b_data;
}
@@ -102,9 +110,10 @@ static int udf_symlink_filler(struct file *file, struct
page *page)
unlock_page(page);
return 0;
-out:
+out_unlock_inode:
unlock_kernel();
SetPageError(page);
+out_unmap:
kunmap(page);
unlock_page(page);
return err;
--
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 2.6.32 33/62] MIPS: Octeon: Remove udelay() causing huge IRQ latency
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Alexander Sverdlin
commit 73bf3c2a500b2db8ac966469591196bf55afb409 upstream.
udelay() in PCI/PCIe read/write callbacks cause 30ms IRQ latency on Octeon
platforms because these operations are called from PCI_OP_READ() and
PCI_OP_WRITE() under raw_spin_lock_irqsave().
Signed-off-by: Alexander Sverdlin
Cc: linux-m...@linux-mips.org
Cc: David Daney
Cc: Rob Herring
Cc: Jiri Kosina
Cc: Randy Dunlap
Cc: Masanari Iida
Cc: Bjorn Helgaas
Cc: Mathias
Patchwork: https://patchwork.linux-mips.org/patch/9576/
Signed-off-by: Ralf Baechle
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
(cherry picked from commit 53493d44a771a3155ee12b6ac668fb2543d21a7a)
Signed-off-by: Willy Tarreau
---
arch/mips/include/asm/octeon/pci-octeon.h | 3 ---
arch/mips/pci/pci-octeon.c| 6 --
arch/mips/pci/pcie-octeon.c | 3 ---
3 files changed, 12 deletions(-)
diff --git a/arch/mips/include/asm/octeon/pci-octeon.h
b/arch/mips/include/asm/octeon/pci-octeon.h
index 6ac5d3e..5eda9f0 100644
--- a/arch/mips/include/asm/octeon/pci-octeon.h
+++ b/arch/mips/include/asm/octeon/pci-octeon.h
@@ -11,9 +11,6 @@
#include
-/* Some PCI cards require delays when accessing config space. */
-#define PCI_CONFIG_SPACE_DELAY 1
-
/*
* pcibios_map_irq() is defined inside pci-octeon.c. All it does is
* call the Octeon specific version pointed to by this variable. This
diff --git a/arch/mips/pci/pci-octeon.c b/arch/mips/pci/pci-octeon.c
index 9cb0c80..dae7ff7 100644
--- a/arch/mips/pci/pci-octeon.c
+++ b/arch/mips/pci/pci-octeon.c
@@ -274,9 +274,6 @@ static int octeon_read_config(struct pci_bus *bus, unsigned
int devfn,
pci_addr.s.func = devfn & 0x7;
pci_addr.s.reg = reg;
-#if PCI_CONFIG_SPACE_DELAY
- udelay(PCI_CONFIG_SPACE_DELAY);
-#endif
switch (size) {
case 4:
*val = le32_to_cpu(cvmx_read64_uint32(pci_addr.u64));
@@ -311,9 +308,6 @@ static int octeon_write_config(struct pci_bus *bus,
unsigned int devfn,
pci_addr.s.func = devfn & 0x7;
pci_addr.s.reg = reg;
-#if PCI_CONFIG_SPACE_DELAY
- udelay(PCI_CONFIG_SPACE_DELAY);
-#endif
switch (size) {
case 4:
cvmx_write64_uint32(pci_addr.u64, cpu_to_le32(val));
diff --git a/arch/mips/pci/pcie-octeon.c b/arch/mips/pci/pcie-octeon.c
index 6aa5c54..97813f3 100644
--- a/arch/mips/pci/pcie-octeon.c
+++ b/arch/mips/pci/pcie-octeon.c
@@ -1192,9 +1192,6 @@ static inline int octeon_pcie_write_config(int pcie_port,
struct pci_bus *bus,
devfn & 0x7, reg, val);
return PCIBIOS_SUCCESSFUL;
}
-#if PCI_CONFIG_SPACE_DELAY
- udelay(PCI_CONFIG_SPACE_DELAY);
-#endif
return PCIBIOS_FUNC_NOT_SUPPORTED;
}
--
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 2.6.32 40/62] pktgen: adjust spacing in proc file interface output
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Jesper Dangaard Brouer
commit d079abd181950a44cdf31daafd1662388a6c4d2e upstream.
Too many spaces were introduced in commit 63adc6fb8ac0 ("pktgen: cleanup
checkpatch warnings"), thus misaligning "src_min:" to other columns.
Fixes: 63adc6fb8ac0 ("pktgen: cleanup checkpatch warnings")
Signed-off-by: Jesper Dangaard Brouer
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
(cherry picked from commit 7acdcce017318585ddb3eacd1d04610b62f181a5)
Signed-off-by: Willy Tarreau
---
net/core/pktgen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index f776b99..5b055af 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -560,7 +560,7 @@ static int pktgen_if_show(struct seq_file *seq, void *v)
" dst_min: %s dst_max: %s\n",
pkt_dev->dst_min, pkt_dev->dst_max);
seq_printf(seq,
- "src_min: %s src_max: %s\n",
+ " src_min: %s src_max: %s\n",
pkt_dev->src_min, pkt_dev->src_max);
}
--
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 2.6.32 30/62] x86/reboot: Fix a warning message triggered by stop_other_cpus()
2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Feng Tang commit 55c844a4dd16a4d1fdc0cf2a283ec631a02ec448 upstream. When rebooting our 24 CPU Westmere servers with 3.4-rc6, we always see this warning msg: Restarting system. machine restart [ cut here ] WARNING: at arch/x86/kernel/smp.c:125 native_smp_send_reschedule+0x74/0xa7() Hardware name: X8DTN Modules linked in: igb [last unloaded: scsi_wait_scan] Pid: 1, comm: systemd-shutdow Not tainted 3.4.0-rc6+ #22 Call Trace: [] warn_slowpath_common+0x7e/0x96 [] warn_slowpath_null+0x15/0x17 [] native_smp_send_reschedule+0x74/0xa7 [] trigger_load_balance+0x279/0x2a6 [] scheduler_tick+0xe0/0xe9 [] update_process_times+0x60/0x70 [] tick_sched_timer+0x68/0x92 [] __run_hrtimer+0xb3/0x13c [] ? tick_nohz_handler+0xd0/0xd0 [] hrtimer_interrupt+0xdb/0x198 [] smp_apic_timer_interrupt+0x81/0x94 [] apic_timer_interrupt+0x67/0x70 [] ? default_send_IPI_mask_allbutself_phys+0xb4/0xc4 [] physflat_send_IPI_allbutself+0x12/0x14 [] native_nmi_stop_other_cpus+0x8a/0xd6 [] native_machine_shutdown+0x50/0x67 [] machine_shutdown+0xa/0xc [] native_machine_restart+0x20/0x32 [] machine_restart+0xa/0xc [] kernel_restart+0x47/0x4c [] sys_reboot+0x13e/0x17c [] ? _raw_spin_unlock_bh+0x10/0x12 [] ? bdi_queue_work+0xcf/0xd8 [] ? __bdi_start_writeback+0xae/0xb7 [] ? iterate_supers+0xa3/0xb7 [] system_call_fastpath+0x16/0x1b ---[ end trace 320af5cb1cb60c5b ]--- The root cause seems to be the default_send_IPI_mask_allbutself_phys() takes quite some time (I measured it could be several ms) to complete sending NMIs to all the other 23 CPUs, and for HZ=250/1000 system, the time is long enough for a timer interrupt to happen, which will in turn trigger to kick load balance to a stopped CPU and cause this warning in native_smp_send_reschedule(). So disabling the local irq before stop_other_cpu() can fix this problem (tested 25 times reboot ok), and it is fine as there should be nobody caring the timer interrupt in such reboot stage. The latest 3.4 kernel slightly changes this behavior by sending REBOOT_VECTOR first and only send NMI_VECTOR if the REBOOT_VCTOR fails, and this patch is still needed to prevent the problem. Signed-off-by: Feng Tang Acked-by: Don Zickus Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20120530231541.4c13433a@feng-i7 Signed-off-by: Ingo Molnar [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Cc: Vinson Lee (cherry picked from commit ea475029e76a0b7fc6e96baf4d414079dec8a90a) Signed-off-by: Willy Tarreau --- arch/x86/kernel/reboot.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c index cf98100..93a933f 100644 --- a/arch/x86/kernel/reboot.c +++ b/arch/x86/kernel/reboot.c @@ -638,9 +638,12 @@ void native_machine_shutdown(void) /* Make certain I only run on the appropriate processor */ set_cpus_allowed_ptr(current, cpumask_of(reboot_cpu_id)); - /* O.K Now that I'm on the appropriate processor, -* stop all of the others. + /* +* O.K Now that I'm on the appropriate processor, stop all of the +* others. Also disable the local irq to not receive the per-cpu +* timer interrupt which may trigger scheduler's load balance. */ + local_irq_disable(); stop_other_cpus(); #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/
[PATCH 2.6.32 37/62] hrtimer: Allow concurrent hrtimer_start() for self restarting timers
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Peter Zijlstra
commit 5de2755c8c8b3a6b8414870e2c284914a2b42e4d upstream.
Because we drop cpu_base->lock around calling hrtimer::function, it is
possible for hrtimer_start() to come in between and enqueue the timer.
If hrtimer::function then returns HRTIMER_RESTART we'll hit the BUG_ON
because HRTIMER_STATE_ENQUEUED will be set.
Since the above is a perfectly valid scenario, remove the BUG_ON and
make the enqueue_hrtimer() call conditional on the timer not being
enqueued already.
NOTE: in that concurrent scenario its entirely common for both sites
to want to modify the hrtimer, since hrtimers don't provide
serialization themselves be sure to provide some such that the
hrtimer::function and the hrtimer_start() caller don't both try and
fudge the expiration state at the same time.
To that effect, add a WARN when someone tries to forward an already
enqueued timer, the most common way to change the expiry of self
restarting timers. Ideally we'd put the WARN in everything modifying
the expiry but most of that is inlines and we don't need the bloat.
Fixes: 2d44ae4d7135 ("hrtimer: clean up cpu->base locking tricks")
Signed-off-by: Peter Zijlstra (Intel)
Cc: Ben Segall
Cc: Roman Gushchin
Cc: Paul Turner
Link:
http://lkml.kernel.org/r/20150415113105.gt5...@twins.programming.kicks-ass.net
Signed-off-by: Thomas Gleixner
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings
(cherry picked from commit ba4a679df78ffd52405af90aae3f4481c6945d6d)
Signed-off-by: Willy Tarreau
---
kernel/hrtimer.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 2818422..db56532 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -803,6 +803,9 @@ u64 hrtimer_forward(struct hrtimer *timer, ktime_t now,
ktime_t interval)
if (delta.tv64 < 0)
return 0;
+ if (WARN_ON(timer->state & HRTIMER_STATE_ENQUEUED))
+ return 0;
+
if (interval.tv64 < timer->base->resolution.tv64)
interval.tv64 = timer->base->resolution.tv64;
@@ -1229,11 +1232,14 @@ static void __run_hrtimer(struct hrtimer *timer,
ktime_t *now)
* Note: We clear the CALLBACK bit after enqueue_hrtimer and
* we do not reprogramm the event hardware. Happens either in
* hrtimer_start_range_ns() or in hrtimer_interrupt()
+*
+* Note: Because we dropped the cpu_base->lock above,
+* hrtimer_start_range_ns() can have popped in and enqueued the timer
+* for us already.
*/
- if (restart != HRTIMER_NORESTART) {
- BUG_ON(timer->state != HRTIMER_STATE_CALLBACK);
+ if (restart != HRTIMER_NORESTART &&
+ !(timer->state & HRTIMER_STATE_ENQUEUED))
enqueue_hrtimer(timer, base);
- }
WARN_ON_ONCE(!(timer->state & HRTIMER_STATE_CALLBACK));
--
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 2.6.32 47/62] nfs: increase size of EXCHANGE_ID name string buffer
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Jeff Layton
commit 764ad8ba8cd4c6f836fca9378f8c5121aece0842 upstream.
The current buffer is much too small if you have a relatively long
hostname. Bring it up to the size of the one that SETCLIENTID has.
Reported-by: Michael Skralivetsky
Signed-off-by: Jeff Layton
Signed-off-by: Trond Myklebust
Signed-off-by: Ben Hutchings
(cherry picked from commit ef24842ca0c24ef7223a0853f7603b1afe7deb11)
Signed-off-by: Willy Tarreau
---
include/linux/nfs_xdr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/nfs_xdr.h b/include/linux/nfs_xdr.h
index 62f63fb..5c8f703 100644
--- a/include/linux/nfs_xdr.h
+++ b/include/linux/nfs_xdr.h
@@ -902,7 +902,7 @@ struct nfs_impl_id4 {
struct nfstime4 date;
};
-#define NFS4_EXCHANGE_ID_LEN (48)
+#define NFS4_EXCHANGE_ID_LEN (127)
struct nfs41_exchange_id_args {
struct nfs_client *client;
nfs4_verifier *verifier;
--
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 2.6.32 28/62] tracing: Have filter check for balanced ops
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Steven Rostedt
commit 2cf30dc180cea808077f003c5116388183e54f9e upstream.
When the following filter is used it causes a warning to trigger:
# cd /sys/kernel/debug/tracing
# echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
-bash: echo: write error: Invalid argument
# cat events/ext4/ext4_truncate_exit/filter
((dev==1)blocks==2)
^
parse_error: No error
[ cut here ]
WARNING: CPU: 2 PID: 1223 at kernel/trace/trace_events_filter.c:1640
replace_preds+0x3c5/0x990()
Modules linked in: bnep lockd grace bluetooth ...
CPU: 3 PID: 1223 Comm: bash Tainted: GW 4.1.0-rc3-test+ #450
Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05
05/07/2012
0668 8800c106bc98 816ed4f9 88011ead0cf0
8800c106bcd8 8107fb07 8136b46c
8800c7d81d48 8800d4c2bc00 8800d4d4f920 ffea
Call Trace:
[] dump_stack+0x4c/0x6e
[] warn_slowpath_common+0x97/0xe0
[] ? _kstrtoull+0x2c/0x80
[] warn_slowpath_null+0x1a/0x20
[] replace_preds+0x3c5/0x990
[] create_filter+0x82/0xb0
[] apply_event_filter+0xd4/0x180
[] event_filter_write+0x8f/0x120
[] __vfs_write+0x28/0xe0
[] ? __sb_start_write+0x53/0xf0
[] ? security_file_permission+0x30/0xc0
[] vfs_write+0xb8/0x1b0
[] SyS_write+0x4f/0xb0
[] system_call_fastpath+0x12/0x6a
---[ end trace e11028bd95818dcd ]---
Worse yet, reading the error message (the filter again) it says that
there was no error, when there clearly was. The issue is that the
code that checks the input does not check for balanced ops. That is,
having an op between a closed parenthesis and the next token.
This would only cause a warning, and fail out before doing any real
harm, but it should still not caues a warning, and the error reported
should work:
# cd /sys/kernel/debug/tracing
# echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
-bash: echo: write error: Invalid argument
# cat events/ext4/ext4_truncate_exit/filter
((dev==1)blocks==2)
^
parse_error: Meaningless filter expression
And give no kernel warning.
Link: http://lkml.kernel.org/r/20150615175025.7e809...@gandalf.local.home
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Reported-by: Vince Weaver
Tested-by: Vince Weaver
Signed-off-by: Steven Rostedt
[bwh: Backported to 3.2: drop the check for OP_NOT, which we don't have]
Signed-off-by: Ben Hutchings
(cherry picked from commit 9fa3f3e6f2a4f4797df5550a33ec5ac1088647e7)
Signed-off-by: Willy Tarreau
---
kernel/trace/trace_events_filter.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index 98a6cc5..098a1dc 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -1070,19 +1070,25 @@ static int check_preds(struct filter_parse_state *ps)
{
int n_normal_preds = 0, n_logical_preds = 0;
struct postfix_elt *elt;
+ int cnt = 0;
list_for_each_entry(elt, >postfix, list) {
- if (elt->op == OP_NONE)
+ if (elt->op == OP_NONE) {
+ cnt++;
continue;
+ }
if (elt->op == OP_AND || elt->op == OP_OR) {
n_logical_preds++;
+ cnt--;
continue;
}
+ cnt--;
n_normal_preds++;
+ WARN_ON_ONCE(cnt < 0);
}
- if (!n_normal_preds || n_logical_preds >= n_normal_preds) {
+ if (cnt != 1 || !n_normal_preds || n_logical_preds >= n_normal_preds) {
parse_error(ps, FILT_ERR_INVALID_FILTER, 0);
return -EINVAL;
}
--
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 2.6.32 51/62] tracing/filter: Do not WARN on operand count going below zero
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: "Steven Rostedt (Red Hat)"
commit b4875bbe7e68f139bd3383828ae8e994a0df6d28 upstream.
When testing the fix for the trace filter, I could not come up with
a scenario where the operand count goes below zero, so I added a
WARN_ON_ONCE(cnt < 0) to the logic. But there is legitimate case
that it can happen (although the filter would be wrong).
# echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter
That is, a single operation without any operands will hit the path
where the WARN_ON_ONCE() can trigger. Although this is harmless,
and the filter is reported as a error. But instead of spitting out
a warning to the kernel dmesg, just fail nicely and report it via
the proper channels.
Link: http://lkml.kernel.org/r/558c6082.90...@oracle.com
Reported-by: Vince Weaver
Reported-by: Sasha Levin
Signed-off-by: Steven Rostedt
Signed-off-by: Ben Hutchings
(cherry picked from commit b43dd35952747f563d0dec7aefb7570260f10353)
Signed-off-by: Willy Tarreau
---
kernel/trace/trace_events_filter.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index 098a1dc..ab10a9f 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -1085,7 +1085,9 @@ static int check_preds(struct filter_parse_state *ps)
}
cnt--;
n_normal_preds++;
- WARN_ON_ONCE(cnt < 0);
+ /* all ops should have operands */
+ if (cnt < 0)
+ break;
}
if (cnt != 1 || !n_normal_preds || n_logical_preds >= n_normal_preds) {
--
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 2.6.32 53/62] fuse: initialize fc->release before calling it
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Miklos Szeredi
commit 0ad0b3255a08020eaf50e34ef0d6df5bdf5e09ed upstream.
fc->release is called from fuse_conn_put() which was used in the error
cleanup before fc->release was initialized.
[Jeremiah Mahler : assign fc->release after calling
fuse_conn_init(fc) instead of before.]
Signed-off-by: Miklos Szeredi
Fixes: a325f9b92273 ("fuse: update fuse_conn_init() and separate out
fuse_conn_kill()")
Signed-off-by: Ben Hutchings
(cherry picked from commit 1a713f9828a6abd288ecc9eef0bbe5c56d0ffc0b)
Signed-off-by: Willy Tarreau
---
fs/fuse/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index c95186c..71b0cf0 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -970,6 +970,7 @@ static int fuse_fill_super(struct super_block *sb, void
*data, int silent)
goto err_fput;
fuse_conn_init(fc);
+ fc->release = fuse_free_conn;
fc->dev = sb->s_dev;
fc->sb = sb;
@@ -984,7 +985,6 @@ static int fuse_fill_super(struct super_block *sb, void
*data, int silent)
fc->dont_mask = 1;
sb->s_flags |= MS_POSIXACL;
- fc->release = fuse_free_conn;
fc->flags = d.flags;
fc->user_id = d.user_id;
fc->group_id = d.group_id;
--
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 2.6.32 50/62] mm: kmemleak: allow safe memory scanning during kmemleak disabling
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Catalin Marinas
commit c5f3b1a51a591c18c8b33983908e7fdda6ae417e upstream.
The kmemleak scanning thread can run for minutes. Callbacks like
kmemleak_free() are allowed during this time, the race being taken care
of by the object->lock spinlock. Such lock also prevents a memory block
from being freed or unmapped while it is being scanned by blocking the
kmemleak_free() -> ... -> __delete_object() function until the lock is
released in scan_object().
When a kmemleak error occurs (e.g. it fails to allocate its metadata),
kmemleak_enabled is set and __delete_object() is no longer called on
freed objects. If kmemleak_scan is running at the same time,
kmemleak_free() no longer waits for the object scanning to complete,
allowing the corresponding memory block to be freed or unmapped (in the
case of vfree()). This leads to kmemleak_scan potentially triggering a
page fault.
This patch separates the kmemleak_free() enabling/disabling from the
overall kmemleak_enabled nob so that we can defer the disabling of the
object freeing tracking until the scanning thread completed. The
kmemleak_free_part() is deliberately ignored by this patch since this is
only called during boot before the scanning thread started.
Signed-off-by: Catalin Marinas
Reported-by: Vignesh Radhakrishnan
Tested-by: Vignesh Radhakrishnan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
[bwh: Backported to 3.2:
- Adjust context
- Drop changes to kmemleak_free_percpu()]
Signed-off-by: Ben Hutchings
(cherry picked from commit 3bc68ffc5b43468537a2f0aa415f3b57f3b19d16)
Signed-off-by: Willy Tarreau
---
mm/kmemleak.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index c346660..e9bd6d5 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -191,6 +191,8 @@ static struct kmem_cache *scan_area_cache;
/* set if tracing memory operations is enabled */
static atomic_t kmemleak_enabled = ATOMIC_INIT(0);
+/* same as above but only for the kmemleak_free() callback */
+static int kmemleak_free_enabled;
/* set in the late_initcall if there were no errors */
static atomic_t kmemleak_initialized = ATOMIC_INIT(0);
/* enables or disables early logging of the memory operations */
@@ -870,7 +872,7 @@ void __ref kmemleak_free(const void *ptr)
{
pr_debug("%s(0x%p)\n", __func__, ptr);
- if (atomic_read(_enabled) && ptr && !IS_ERR(ptr))
+ if (kmemleak_free_enabled && ptr && !IS_ERR(ptr))
delete_object_full((unsigned long)ptr);
else if (atomic_read(_early_log))
log_early(KMEMLEAK_FREE, ptr, 0, 0, 0, 0);
@@ -1552,6 +1554,13 @@ static void kmemleak_do_cleanup(struct work_struct *work)
mutex_lock(_mutex);
stop_scan_thread();
+ /*
+* Once the scan thread has stopped, it is safe to no longer track
+* object freeing. Ordering of the scan thread stopping and the memory
+* accesses below is guaranteed by the kthread_stop() function.
+*/
+ kmemleak_free_enabled = 0;
+
rcu_read_lock();
list_for_each_entry_rcu(object, _list, object_list)
delete_object_full(object->pointer);
@@ -1578,6 +1587,8 @@ static void kmemleak_disable(void)
/* check whether it is too early for a kernel thread */
if (atomic_read(_initialized))
schedule_work(_work);
+ else
+ kmemleak_free_enabled = 0;
pr_info("Kernel memory leak detector disabled\n");
}
@@ -1617,6 +1628,7 @@ void __init kmemleak_init(void)
if (!atomic_read(_error)) {
atomic_set(_enabled, 1);
atomic_set(_early_log, 0);
+ kmemleak_free_enabled = 1;
}
local_irq_restore(flags);
--
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 2.6.32 49/62] NET: ROSE: Dont dereference NULL neighbour pointer.
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Ralf Baechle
commit d496f7842aada20c61e6044b3395383fa972872c upstream.
A ROSE socket doesn't necessarily always have a neighbour pointer so check
if the neighbour pointer is valid before dereferencing it.
Signed-off-by: Ralf Baechle
Tested-by: Bernard Pidoux
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
(cherry picked from commit 8bbe4f448c01949084ef404eded3622086f052a6)
Signed-off-by: Willy Tarreau
---
net/rose/af_rose.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/rose/af_rose.c b/net/rose/af_rose.c
index 7119ea6..4457e9a 100644
--- a/net/rose/af_rose.c
+++ b/net/rose/af_rose.c
@@ -194,7 +194,8 @@ static void rose_kill_by_device(struct net_device *dev)
if (rose->device == dev) {
rose_disconnect(s, ENETUNREACH, ROSE_OUT_OF_ORDER, 0);
- rose->neighbour->use--;
+ if (rose->neighbour)
+ rose->neighbour->use--;
rose->device = NULL;
}
}
--
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 2.6.32 32/62] __ptrace_may_access() should not deny sub-threads
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Mark Grondona
commit 73af963f9f3036dffed55c3a2898598186db1045 upstream.
__ptrace_may_access() checks get_dumpable/ptrace_has_cap/etc if task !=
current, this can can lead to surprising results.
For example, a sub-thread can't readlink("/proc/self/exe") if the
executable is not readable. setup_new_exec()->would_dump() notices that
inode_permission(MAY_READ) fails and then it does
set_dumpable(suid_dumpable). After that get_dumpable() fails.
(It is not clear why proc_pid_readlink() checks get_dumpable(), perhaps we
could add PTRACE_MODE_NODUMPABLE)
Change __ptrace_may_access() to use same_thread_group() instead of "task
== current". Any security check is pointless when the tasks share the
same ->mm.
Signed-off-by: Mark Grondona
Signed-off-by: Ben Woodard
Signed-off-by: Oleg Nesterov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Ben Hutchings
Cc: Sheng Yong
(cherry picked from commit f062bd6e420a064a19563b80c26d746b0262e404)
Signed-off-by: Willy Tarreau
---
kernel/ptrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 03da336..426b0c8 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -169,7 +169,7 @@ int __ptrace_may_access(struct task_struct *task, unsigned
int mode)
*/
int dumpable = 0;
/* Don't let security modules deny introspection */
- if (task == current)
+ if (same_thread_group(task, current))
return 0;
rcu_read_lock();
tcred = __task_cred(task);
--
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 2.6.32 14/62] udf: Check length of extended attributes and allocation descriptors
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit 23b133bdc452aa441fcb9b82cbf6dd05cfd342d0 upstream.
Check length of extended attributes and allocation descriptors when
loading inodes from disk. Otherwise corrupted filesystems could confuse
the code and make the kernel oops.
Reported-by: Carl Henrik Lunde
Signed-off-by: Jan Kara
[bwh: Backported to 2.6.32: use make_bad_inode() instead of returning error]
Signed-off-by: Ben Hutchings
CVE-2015-4167
Signed-off-by: Willy Tarreau
---
fs/udf/inode.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 26b7f31..b8d7a0e 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1284,6 +1284,19 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
iinfo->i_lenEAttr;
}
+ /*
+* Sanity check length of allocation descriptors and extended attrs to
+* avoid integer overflows
+*/
+ if (iinfo->i_lenEAttr > bs || iinfo->i_lenAlloc > bs) {
+ make_bad_inode(inode);
+ return;
+ }
+ /* Now do exact checks */
+ if (udf_file_entry_alloc_offset(inode) + iinfo->i_lenAlloc > bs) {
+ make_bad_inode(inode);
+ return;
+ }
/* Sanity checks for files in ICB so that we don't get confused later */
if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
/*
--
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 2.6.32 27/62] x86_64: Fix strnlen_user() to not touch memory after specified maximum
2.6.32-longterm review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
Inspired by commit f18c34e483ff ("lib: Fix strnlen_user() to not touch
memory after specified maximum") upstream. This version of
strnlen_user(), no longer present upstream, has a similar off-by-one
error.
Signed-off-by: Ben Hutchings
Cc: Jan Kara
(cherry picked from commit 4797489ce83a5f42d0b38089695a48d4a3d1ee0b)
Signed-off-by: Willy Tarreau
---
arch/x86/lib/usercopy_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/lib/usercopy_64.c b/arch/x86/lib/usercopy_64.c
index b7c2849..3428d91 100644
--- a/arch/x86/lib/usercopy_64.c
+++ b/arch/x86/lib/usercopy_64.c
@@ -113,7 +113,7 @@ long __strnlen_user(const char __user *s, long n)
char c;
while (1) {
- if (res>n)
+ if (res >= n)
return n+1;
if (__get_user(c, s))
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/
[PATCH 2.6.32 00/62] 2.6.32.68-longterm review
This is the start of the longterm review cycle for the 2.6.32.68 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. If anyone thinks some important patches are missing and should be added prior to the release, please report them quickly with their respective mainline commit IDs. Responses should be made by Sat Sep 19 00:56:05 CEST 2015. Anything received after that time might be too late. If someone wants a bit more time for a deeper review, please let me know. NOTE: 2.6.32 is approaching end of support. There will probably be one or maybe two other versions issued in the next 3-6 months, and that will be all, at least for me. Adding to this the time it can take to validate and deploy in some environments, it probably makes sense to start to think about switching to another longterm branch. 3.2 and 3.4 are good candidates for those seeking rock-solid versions. Longterm branches and their projected EOLs are listed here : https://www.kernel.org/category/releases.html The whole patch series can be found in one patch at : https://kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.32.68-rc1.gz The shortlog and diffstat are appended below. Thanks, Willy === Al Viro (1): sg_start_req(): make sure that there's not too many elements in iovec Alexander Sverdlin (2): sctp: Fix race between OOTB responce and route removal MIPS: Octeon: Remove udelay() causing huge IRQ latency Andy Lutomirski (1): x86/xen: Probe target addresses in set_aliased_prot() before the hypercall Anton Blanchard (1): powerpc: Align TOC to 256 bytes Ben Hutchings (2): pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic x86_64: Fix strnlen_user() to not touch memory after specified maximum Catalin Marinas (1): mm: kmemleak: allow safe memory scanning during kmemleak disabling Dan Carpenter (1): memstick: mspro_block: add missing curly braces Darrick J. Wong (1): jbd2: fix r_count overflows leading to buffer overflow in journal recovery Dave Olson (1): powerpc: Fix missing L2 cache size in /sys/devices/system/cpu David S. Miller (2): dccp: Fix compile warning in probe code. ipv6: Fix return of xfrm6_tunnel_rcv() Dr. David Alan Gilbert (1): dmaengine: fix missing 'cnt' in ?: in dmatest Eric Dumazet (1): udp: fix behavior of wrong checksums Feng Tang (1): x86/reboot: Fix a warning message triggered by stop_other_cpus() Gerrit Renker (1): dccp: fix auto-loading of dccp(_probe) Heiko Carstens (2): s390/hibernate: fix save and restore of kernel text section s390/process: fix sfpc inline assembly Jan Kara (7): udf: Verify i_size when loading inode udf: Verify symlink size before loading it udf: Treat symlink component of type 2 as / udf: Check path length when reading symlink udf: Check component length before reading it Remove repeated loads blocksize udf: Check length of extended attributes and allocation descriptors Jeff Layton (1): nfs: increase size of EXCHANGE_ID name string buffer Jesper Dangaard Brouer (1): pktgen: adjust spacing in proc file interface output Jiri Kosina (1): HID: fix a couple of off-by-ones Jiri Slaby (1): TTY: drop driver reference in tty_open fail path Kirill A. Shutemov (1): mm: avoid setting up anonymous pages into file mapping Lars Persson (1): MIPS: Fix race condition in lazy cache flushing. Lior Amsalem (1): dmaengine: mv_xor: bug fix for racing condition in descriptors cleanup Malcolm Priestley (1): staging: vt6655: device_rx_srv check sk_buff is NULL Mark Grondona (1): __ptrace_may_access() should not deny sub-threads Mark Hounschell (1): sd: Disable support for 256 byte/sector disks Markus F.X.J. Oberhumer (1): crypto: testmgr - update LZO compression test vectors Mauro Carvalho Chehab (2): s5h1420: fix a buffer overflow when checking userspace params cx24116: fix a buffer overflow when checking userspace params Michael Halcrow (1): eCryptfs: Remove buggy and unnecessary write in file name decode routine Miklos Szeredi (1): fuse: initialize fc->release before calling it Mikulas Patocka (1): libata: increase the timeout when setting transfer mode NeilBrown (1): md/raid5: don't record new size if resize_stripes fails. Oleg Nesterov (2): ptrace: fix race between ptrace_resume() and wait_task_stopped() include/linux/sched.h: don't use task->pid/tgid in same_thread_group/has_group_leader_pid Olga Kornievskaia (1): fixing infinite OPEN loop in 4.0 stateid recovery Pablo Neira Ayuso (1): netlink: fix possible spoofing from non-root processes
Re: [PATCH 4/6] hwrng: st: Add support for ST's HW Random Number Generator
On Fri, Sep 11, 2015 at 5:08 PM, Lee Jones wrote:
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + clk = devm_clk_get(>dev, NULL);
> + if (!clk)
> + return -EINVAL;
This should be:
if (IS_ERR(clk))
return PTR_ERR(clk);
> +
> + clk_prepare_enable(clk);
This may fail, so better check its return value and propagate it on error.
> +
> + ddata->ops.priv = (unsigned long)ddata;
> + ddata->ops.read = st_rng_read;
> + ddata->ops.name = pdev->name;
> + ddata->base = base;
> + ddata->clk = clk;
> +
> + dev_set_drvdata(>dev, ddata);
> +
> + ret = hwrng_register(>ops);
> + if (ret) {
> + dev_err(>dev, "Failed to register HW RNG\n");
> + return ret;
> + }
> +
> + dev_info(>dev, "Successfully registered HW RNG\n");
No need to put this info.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug()
On Fri, Sep 11, 2015 at 04:36:39PM -0700, Linus Torvalds wrote: > On Fri, Sep 11, 2015 at 4:16 PM, Chris Mason wrote: > > > > For 4.3 timeframes, what runs do you want to see numbers for: > > > > 1) revert > > 2) my hack > > 3) plug over multiple sbs (on different devices) > > 4) ? > > Just 2 or 3. > > I don't think the plain revert is all that interesting, and I think > the "anything else" is far too late for this merge window. I did the plain revert as well, just to have a baseline. This box is a little different from Dave's. Bare metal two socket box (E5-2660 v2 @ 2.20Ghz) with 144GB of ram. I have two pcie flash devices, one nvme and one fusionio, and I put a one FS on each device (two mounts total). The test created 1.6M files, 4K each. I used Dave's fs_mark command line, spread out over 16 directories from each mounted filesystem. In btrfs they are spread over subvolumes to cut down lock contention. I need to change around the dirty ratios more to smooth out the IO, and I had trouble with both XFS and btrfs getting runs that were not CPU bound. I included the time to run sync at the end of the run because the results were not very consistent without it. The XFS runs generally had one CPU pegged at 100%, and I think this is throwing off the results. On Monday I'll redo them with two (four?) filesystems per flash device, hopefully that'll break things up. The btrfs runs generally had all the CPUs pegged at 100%. I switched to mount -o nodatasum and squeezed out an extra 50K files/sec at much lower CPU utilization. wall time fs_mark files/secbytes written/sec XFS: baseline v4.2: 5m6s 118,578 272MB/s Dave's patch: 4m46s 151,421 294MB/s my hack:5m5s 150,714 275MB/s Linus plug: 5m15s 147,735 266MB/s Btrfs (nodatasum): baseline v4.2: 4m39s 242,643 313MB/s Dave's patch: 3m46s 252,452 389MB/s my hack:3m48s 257,924 379MB/s Linus plug: 3m58s 247,528 369MB/s Bottom line, not as conclusive as I'd like. My hack doesn't seem to hurt, but FS internals are consuming enough CPU that this lock just isn't showing up. Linus' plug patch is consistently slower, and I don't have a great explanation. My guesses: not keeping the flash pipelines full, or the imbalance between the different speed flash is averaging the overall result down, or its my kblockd vs explicit unplug handwaving from yesterday. So, next step is either more runs on flash or grab a box with a bunch of spindles. I'd rather do the spindle runs, I agree with Dave that his patch should help much more on actual drives. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] hwrng: st: Add support for ST's HW Random Number Generator
Hi Lee,
On 11 September 2015 at 21:08, Lee Jones wrote:
> Signed-off-by: Pankaj Dev
> Signed-off-by: Lee Jones
> ---
> drivers/char/hw_random/Kconfig | 10 +++
> drivers/char/hw_random/Makefile | 1 +
> drivers/char/hw_random/st-rng.c | 142
>
> 3 files changed, 153 insertions(+)
> create mode 100644 drivers/char/hw_random/st-rng.c
>
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index f48cf11..bb6cb77 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -346,6 +346,16 @@ config HW_RANDOM_MSM
>
> If unsure, say Y.
>
> +config HW_RANDOM_ST
> + tristate "ST Microelectronics HW Random Number Generator support"
> + depends on HW_RANDOM && ARCH_STI
> + ---help---
> + This driver provides kernel-side support for the Random Number
> + Generator hardware found on STi series of SoCs.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called st-rng.
> +
> config HW_RANDOM_XGENE
> tristate "APM X-Gene True Random Number Generator (TRNG) support"
> depends on HW_RANDOM && ARCH_XGENE
> diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
> index 055bb01..8bcfb45 100644
> --- a/drivers/char/hw_random/Makefile
> +++ b/drivers/char/hw_random/Makefile
> @@ -30,4 +30,5 @@ obj-$(CONFIG_HW_RANDOM_TPM) += tpm-rng.o
> obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o
> obj-$(CONFIG_HW_RANDOM_IPROC_RNG200) += iproc-rng200.o
> obj-$(CONFIG_HW_RANDOM_MSM) += msm-rng.o
> +obj-$(CONFIG_HW_RANDOM_ST) += st-rng.o
> obj-$(CONFIG_HW_RANDOM_XGENE) += xgene-rng.o
> diff --git a/drivers/char/hw_random/st-rng.c b/drivers/char/hw_random/st-rng.c
> new file mode 100644
> index 000..717a831
> --- /dev/null
> +++ b/drivers/char/hw_random/st-rng.c
> @@ -0,0 +1,142 @@
> +/*
> + * ST Random Number Generator Driver ST's Platforms
> + *
> + * Author: Pankaj Dev:
> + * Lee Jones
> + *
> + * Copyright (C) 2015 STMicroelectronics (R) Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Registers */
> +#define ST_RNG_STATUS_REG 0x20
> +#define ST_RNG_DATA_REG0x24
> +
> +/* Registers fields */
> +#define ST_RNG_STATUS_BAD_SEQUENCE BIT(0)
> +#define ST_RNG_STATUS_BAD_ALTERNANCE BIT(1)
> +#define ST_RNG_STATUS_FIFO_FULLBIT(5)
> +
> +#define ST_RNG_FIFO_SIZE 8
> +#define ST_RNG_SAMPLE_SIZE 2 /* 2 Byte (16bit) samples */
> +
> +/* Samples are available every 0.667us, which we round to 1us */
> +#define ST_RNG_FILL_FIFO_TIMEOUT (1 * (ST_RNG_FIFO_SIZE /
> ST_RNG_SAMPLE_SIZE))
> +
> +struct st_rng_data {
> + void __iomem*base;
> + struct clk *clk;
> + struct hwrngops;
> +};
> +
> +static int st_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
> +{
> + struct st_rng_data *ddata = (struct st_rng_data *)rng->priv;
> + u32 status;
> + int i;
> +
> + if (max < sizeof(u16))
> + return -EINVAL;
> +
> + /* Wait until FIFO is full - max 4uS*/
> + for (i = 0; i < ST_RNG_FILL_FIFO_TIMEOUT; i++) {
> + status = readl_relaxed(ddata->base + ST_RNG_STATUS_REG);
> + if (status & ST_RNG_STATUS_FIFO_FULL)
> + break;
> + udelay(1);
> + }
> +
> + if (i == ST_RNG_FILL_FIFO_TIMEOUT)
> + return 0;
> +
> + for (i = 0; i < ST_RNG_FIFO_SIZE && i < max; i += 2)
> + *(u16 *)(data + i) =
> + readl_relaxed(ddata->base + ST_RNG_DATA_REG);
Will this code always be called with max % 2 == 0? ...
I.e. will
st_rng_read(rng, data[5], 5, waitflg)
overflow an array?
> +
> + return i - 2; /* No of bytes read */
Really? Doesn't this return 0 on st_rng_read(rng, data[2], 2, waitflg);
> +}
> +
> +static int st_rng_probe(struct platform_device *pdev)
> +{
> + struct st_rng_data *ddata;
> + struct resource *res;
> + struct clk *clk;
> + void __iomem *base;
> + int ret;
> +
> + ddata = devm_kzalloc(>dev, sizeof(*ddata), GFP_KERNEL);
> + if (!ddata)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(base))
Are we leaking ddata here ? I.e. before its attached with set_drvdata?
> + return PTR_ERR(base);
> +
> + clk = devm_clk_get(>dev, NULL);
> + if (!clk)
And here ...
> + return -EINVAL;
> +
> + clk_prepare_enable(clk);
>
Re: Linux 4.3-rc1 build error on CentOS 5.11 "scripts/sign-file.c:23:25: fatal error: openssl/cms.h: No such file or directory"
On Fri, Sep 11, 2015 at 4:22 PM, Davidlohr Bueso wrote: > On Fri, 11 Sep 2015, Vinson Lee wrote: > >> Hi. >> >> With the latest Linux 4.3-rc1, I am hitting this build error on CentOS >> 5.11. >> >> HOSTCC scripts/sign-file >> scripts/sign-file.c:23:25: fatal error: openssl/cms.h: No such file or >> directory >> #include > > > fwiw/rant, I have run into kernel build issues recently due to lack of > openssl libs. > The solution is trivial, in my case just intalling my distros openssl-devel > package Though in this case it looks like the openssl-devel rpm for CentOS 5.11 doesn't provide a cms.h file. When I checked on a CentOS 7 system, installing the openssl-devel package did install cms.h in /usr/include/openssl. Maybe something didn't get backported to CentOS 5.11? -- Jim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] scripts/kernel-doc: Kernel-doc improvements
On Mon, 7 Sep 2015 17:01:58 -0300 Danilo Cesar Lemes de Paula wrote: > The following series contains: > * kernel-doc: markdown support and improvements. OK, I've spent a while looking this stuff over. I like the general idea, but I do have a couple of concerns. 1 Installing pandoc on a Fedora system wants to drag in 70(!) packages for 100MB of total stuff. Installing it on Arch is ... well ... enough to make you want to switch to Fedora. If we add a dependency on a tool this massive, people are going to complain, loudly. Have you looked at using something like cmark instead? I don't know the tool well, but it seems like it can do the job simply enough. It's focused, written in C, and doesn't drag in a diskful of Haskell stuff. There's lot of other converters out there too, I'm not tied to this one (though I think CommonMark deserves support), but I do think this question needs to be considered. 2 We're constructing an increasingly complicated document-processing mechanism with a lot of independently moving parts. What if we converted the whole document to markdown and dispensed with the XML part altogether? Making the source files simpler and dispensing with the xmlto requirement would be a big win, IMO. I will not make #2 be a precondition to getting some form of this work merged, but I would like to have a good answer for #1. Adding such a heavyweight dependency (even as an optional one) needs to have a pretty good story behind it. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)
On Wed, Sep 9, 2015 at 2:54 PM, Peter Zijlstra wrote: > On Wed, Sep 09, 2015 at 12:05:50PM +0200, Sedat Dilek wrote: >> I can boot into a CLANG v3.7 compiled Linux-kernel when lib/bitmap is >> compiled with GCC (here: v4.9). >> >> CONFIG_OPTIMIZE_INLINING has no effect on this. >> >> Attached are the single llvmlinux patch for AMD64 (x86_64), my >> kernel-config and 2 objdumps with bitmap.o file alltogether. > > I suggest you go tell the LLVM people their compiler is broken. It looks like an inline-optimization bug in CLANG when the compiler's optimization-level is higher than -O2. Level -O0 and -O1 are OK - I can boot in such Linux-kernel v4.2. With Level -Oz when CONFIG_CC_OPTIMIZE_FOR_SIZE=y (equivalent to GCC's -Os) the objdump looked sane but I cannot boot on bare metal. Re-compiling lib/bitmap with -O0 or -O1 is fine again. - Sedat - [1] http://lists.linuxfoundation.org/pipermail/llvmlinux/2015-September/001355.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/
from: james.leitch
Hi linux http://projectlifestories.org/mixture.php?beyond=m10x2wpkaxc1vps5 james.leitch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/7] soc: brcmstb: add PM suspend/resume support (S2/S3/S5)
Le 06/18/15 17:11, Brian Norris a écrit :
> Support S2, S3, and S5 through /sys/power/state ("standby" and "mem")
> and the poweroff code paths. See comments in pm.c for a few more details
> about these system suspend modes.
>
> Signed-off-by: Brian Norris
Applied to soc/next with an appropriate AFLAGS to force the assembler in
ARMv7-a mode for s2.S, thanks!
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sysfs.txt: mention that store method buffers are null-terminated
On Mon, 7 Sep 2015 19:06:14 +0200 ulfalizer.l...@gmail.com wrote: > Without knowing this, the use of sysfs_streq() becomes puzzling. > > The termination happens in kernfs_fop_write(). Applied to the docs tree. I moved it up a paragraph, though, since it better fits the flow of the document there. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/7] soc: add stubs for brcmstb SoC's
Le 06/18/15 17:11, Brian Norris a écrit : > Used on BCM7xxx Set-Top Box chips (e.g., BCM7445). > > Signed-off-by: Brian Norris Applied to soc/next, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] Fix some outdated pre-kernfs doc references
On Wed, 2 Sep 2015 14:34:51 +0200 ulfalizer.l...@gmail.com wrote: > sysfs-tagging.txt contains more outdated references (e.g., to various > kobj_ns_*() functions that no longer exist), but hopefully it should be in > a better shape than before. I'm new to sysfs internals in general. > > The configfs change is a guess that seemed reasonable. > > Ulf Magnusson (3): > sysfs.txt: fix pre-kernfs sysfs_dirent reference > sysfs-tagging.txt: fix pre-kernfs references So, I sure would have rather seen a patch that actually documents kernfs rather than just swapping a few names here and there, but so be it. I've applied these two to the docs tree, since they make things better than they were before. > configfs: fix pre-kernfs sysfs_dirent reference Not sure who handles configfs patches these days, but it's not me, so I've not done anything with this one. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.1 70/78] SCSI: Fix NULL pointer dereference in runtime PM
On Sat, Sep 12, 2015 at 01:37:02PM -0400, Alan Stern wrote: > On Fri, 11 Sep 2015, Greg Kroah-Hartman wrote: > > > 4.1-stable review patch. If anyone has any objections, please let me know. > > It turns out that this patch causes problems with the sr driver. A > reversion and alternate solution have already been submitted to James > Bottomley (http://marc.info/?l=linux-scsi=144185206825609=2). We > ought to hold off putting it into the -stable kernels. I prefer to take patches like this into a stable release, so as to spur the maintainer on to also get the fix into Linus's tree, which I don't see happening yet. I don't like diverging from what Linus has for obvious reasons. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] soc: brcmstb: add wake-timer driver
Le 06/18/15 17:11, Brian Norris a écrit : > Useful for waking the system from suspend after a specified period of > time. > > This IP could potentially be supported as an RTC driver (for use with > the 'rtcwake' utility), but it is not battery backed, so that's not a > great fit. Implement a custom sysfs interface instead. I would very much like to see this driver be implemented as a degenerate RTC driver because this sorts of maps pretty well to the "rtcwake" use mode, and this is a persistent clock source, and even a clock source as well (I would rather avoid going the MFD route to expose these 3 "functions" though). Thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/7] Documentation: dt: brcmstb: add waketimer documentation
Le 06/18/15 17:11, Brian Norris a écrit :
> Signed-off-by: Brian Norris
Although the binding looks good to me, I am not applying this one just
yet since we would want to merge the wake-timer driver and its binding
at the same time, thanks!
> ---
> .../bindings/soc/brcmstb/brcm,brcmstb-waketimer.txt | 20
>
> 1 file changed, 20 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/soc/brcmstb/brcm,brcmstb-waketimer.txt
>
> diff --git
> a/Documentation/devicetree/bindings/soc/brcmstb/brcm,brcmstb-waketimer.txt
> b/Documentation/devicetree/bindings/soc/brcmstb/brcm,brcmstb-waketimer.txt
> new file mode 100644
> index ..68c4329b6af0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/brcmstb/brcm,brcmstb-waketimer.txt
> @@ -0,0 +1,20 @@
> +* Broadcom STB Wake-up Timer
> +
> +The Broadcom STB wake-up timer provides a high-resolution timer, with the
> +ability to wake up the system from low-power suspend/standby modes.
> +
> +Required properties:
> +- compatible : should contain "brcm,brcmstb-waketimer"
> +- reg: the register start and length for the WKTMR block
> +- interrupts : The TIMER interrupt
> +- interrupt-parent: The phandle to the Always-On (AON) Power Management (PM)
> L2
> +interrupt controller node
> +
> +Example:
> +
> +waketimer@f0411580 {
> + compatible = "brcm,brcmstb-waketimer";
> + reg = <0xf0411580 0x14>;
> + interrupts = <0x3>;
> + interrupt-parent = <_pm_l2_intc>;
> +};
>
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] ARM: dts: brcmstb: add BCM7445 system PM DT nodes
Le 06/18/15 17:11, Brian Norris a écrit : > Need the aon_pm_l2_intc, aon-ctrl, waketimer, boot SRAM, and > memory_controller descriptions. > > Signed-off-by: Brian Norris Applied to devicetree/next sans the wake-timer node and the now duplicate aon_pm_l2_intc entry, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/7] Documentation: dt: brcmstb: add system PM bindings
Le 06/18/15 17:11, Brian Norris a écrit : > Signed-off-by: Brian Norris Applied to devicetree/next, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 6/7] ARM: brcmstb: mask GIC IRQs on suspend
Le 06/18/15 17:11, Brian Norris a écrit :
> Lazily-masked IRQs can cause system suspend problems (e.g., spurious
> wakeups from WFI), so we need to be sure non-wakeup GIC interrupts get
> masked, not just disabled, during system suspend.
>
> Signed-off-by: Brian Norris
Dropped this patch, no longer needed as of 4.3-rc0 with
aec89ef72ba6c94420f599dcb684ed66937cdacf ("irqchip/gic: Enable
SKIP_SET_WAKE and MASK_ON_SUSPEND")
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] compal-laptop: add charge control limit
Add charge control limit to the power supply subsystem of the Compal
platform driver.
This apparently was present in the original driver by Cezary Jackiewicz
at http://eko.one.pl/index.php?page=compal-laptop but it seems to have been
overlooked.
The Kconfig description is updated to reflect this addition. It now also
mentions the hwmon interface that was already present.
Signed-off-by: Roald Frederickx
---
drivers/platform/x86/Kconfig | 4 ++--
drivers/platform/x86/compal-laptop.c | 43 +++-
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index c69bb70..2f9026d 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -309,8 +309,8 @@ config COMPAL_LAPTOP
This is a driver for laptops built by Compal, and some models by
other brands (e.g. Dell, Toshiba).
- It adds support for rfkill, Bluetooth, WLAN and LCD brightness
- control.
+ It adds support for rfkill, Bluetooth, WLAN, LCD brightness, hwmon
+ and battery charging level control.
For a (possibly incomplete) list of supported laptops, please refer
to: Documentation/platform/x86-laptop-drivers.txt
diff --git a/drivers/platform/x86/compal-laptop.c
b/drivers/platform/x86/compal-laptop.c
index f2706d2..e1c2b6d 100644
--- a/drivers/platform/x86/compal-laptop.c
+++ b/drivers/platform/x86/compal-laptop.c
@@ -151,6 +151,8 @@
#define BAT_STATUS20xF1
#define BAT_STOP_CHARGE1 0xF2
#define BAT_STOP_CHARGE2 0xF3
+#define BAT_CHARGE_LIMIT 0x03
+#define BAT_CHARGE_LIMIT_MAX 100
#define BAT_S0_DISCHARGE (1 << 0)
#define BAT_S0_DISCHRG_CRITICAL(1 << 2)
@@ -601,6 +603,12 @@ static int bat_get_property(struct power_supply *psy,
case POWER_SUPPLY_PROP_CHARGE_NOW:
val->intval = ec_read_u16(BAT_CHARGE_NOW) * 1000;
break;
+ case POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT:
+ val->intval = ec_read_u8(BAT_CHARGE_LIMIT);
+ break;
+ case POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX:
+ val->intval = BAT_CHARGE_LIMIT_MAX;
+ break;
case POWER_SUPPLY_PROP_CAPACITY:
val->intval = ec_read_u8(BAT_CAPACITY);
break;
@@ -634,6 +642,36 @@ static int bat_get_property(struct power_supply *psy,
return 0;
}
+static int bat_set_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ const union power_supply_propval *val)
+{
+ int level;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT:
+ level = val->intval;
+ if (level < 0 || level > BAT_CHARGE_LIMIT_MAX)
+ return -EINVAL;
+ if (ec_write(BAT_CHARGE_LIMIT, level) < 0)
+ return -EIO;
+ break;
+ default:
+ break;
+ }
+ return 0;
+}
+
+static int bat_writeable_property(struct power_supply *psy,
+ enum power_supply_property psp)
+{
+ switch (psp) {
+ case POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT:
+ return 1;
+ default:
+ return 0;
+ }
+}
@@ -726,6 +764,8 @@ static enum power_supply_property compal_bat_properties[] =
{
POWER_SUPPLY_PROP_POWER_NOW,
POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
POWER_SUPPLY_PROP_CHARGE_NOW,
+ POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT,
+ POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
POWER_SUPPLY_PROP_CAPACITY,
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
POWER_SUPPLY_PROP_TEMP,
@@ -880,11 +920,12 @@ static const struct power_supply_desc psy_bat_desc = {
.properties = compal_bat_properties,
.num_properties = ARRAY_SIZE(compal_bat_properties),
.get_property = bat_get_property,
+ .set_property = bat_set_property,
+ .property_is_writeable = bat_writeable_property,
};
static void initialize_power_supply_data(struct compal_data *data)
{
-
ec_read_sequence(BAT_MANUFACTURER_NAME_ADDR,
data->bat_manufacturer_name,
BAT_MANUFACTURER_NAME_LEN);
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL]: CRIS changes for 4.3
Hi Linus!
Please pull the below tree for CRIS changes for 4.3.
Mostly removal of old cruft of which we can use a generic version,
or fixes for code not commonly run in the cris port,
but also additions to enable som good debug.
Thanks!
The following changes since commit 51e771c0d25b43d0f12b2c7c01939942becbbe28:
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input (2015-09-04 12:02:11
-0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris.git
tags/cris-for-4.3
for you to fetch changes up to 254a0f4135482dc02701562a38e10675a48c8ddf:
CRISv10: delete unused lib/dmacopy.c (2015-09-05 00:56:51 +0200)
CRIS changes for 4.3
Chen Gang (1):
CRIS: Wire up missing syscalls
Christophe Jaillet (1):
cris: arch-v32: gpio: Use kzalloc instead of kmalloc/memset
Jesper Nilsson (3):
CRISv32: ETRAX FS: Squash warnings in pinmux driver
CRISv32: Add GPIO driver to the default configs
CRISv32: Squash compile warnings for axisflashmap
Rabin Vincent (20):
CRISv32: add unreachable() to BUG()
CRISv32: allow CONFIG_DEBUG_BUGVERBOSE
CRIS: UAPI: fix ptrace.h
CRIS: don't make asm/elf.h depend on asm/user.h
CRIS: UAPI: fix elf.h export
CRIS: UAPI: use generic headers via Kbuild
CRIS: UAPI: use generic auxvec.h
CRIS: UAPI: use generic sockios.h
CRIS: UAPI: use generic sembuf.h
CRIS: UAPI: use generic socket.h
CRIS: UAPI: use generic msgbuf.h
CRIS: UAPI: use generic shmbuf.h
CRIS: UAPI: use generic types.h
CRISv32: add support for irqflags tracing
CRISv32: annotate irq enable in idle loop
CRIS: add STACKTRACE_SUPPORT
CRISv32: enable LOCKDEP_SUPPORT
CRIS: fix switch_mm() lockdep splat
CRISv10: delete unused lib/old_checksum.c
CRISv10: delete unused lib/dmacopy.c
arch/cris/Kconfig | 12 +++
arch/cris/arch-v10/kernel/entry.S |8 ++
arch/cris/arch-v10/lib/dmacopy.c | 42 -
arch/cris/arch-v10/lib/old_checksum.c | 86 --
arch/cris/arch-v32/drivers/Kconfig | 16 ++--
arch/cris/arch-v32/drivers/axisflashmap.c |9 +-
arch/cris/arch-v32/drivers/mach-a3/gpio.c |4 +-
arch/cris/arch-v32/drivers/mach-fs/gpio.c |3 +-
arch/cris/arch-v32/kernel/entry.S | 19
arch/cris/arch-v32/kernel/process.c|4 +-
arch/cris/arch-v32/kernel/signal.c |1 -
arch/cris/arch-v32/mach-fs/pinmux.c|8 +-
arch/cris/configs/artpec_3_defconfig |5 +-
arch/cris/configs/etraxfs_defconfig|1 +
arch/cris/include/arch-v32/arch/bug.h | 11 ++-
arch/cris/include/arch-v32/arch/irqflags.h |2 +-
arch/cris/include/asm/Kbuild | 17
arch/cris/include/asm/mmu_context.h|9 +-
arch/cris/include/asm/stacktrace.h |8 ++
arch/cris/include/asm/types.h | 12 ---
arch/cris/include/asm/unistd.h |2 +-
arch/cris/include/uapi/asm/Kbuild |5 ++
arch/cris/include/uapi/asm/auxvec.h|4 -
arch/cris/include/uapi/asm/bitsperlong.h |1 -
arch/cris/include/{ => uapi}/asm/elf.h |9 +-
.../{arch-v10/arch/elf.h => uapi/asm/elf_v10.h}|5 +-
.../{arch-v32/arch/elf.h => uapi/asm/elf_v32.h}|5 +-
arch/cris/include/uapi/asm/errno.h |6 --
arch/cris/include/uapi/asm/fcntl.h |1 -
arch/cris/include/uapi/asm/ioctl.h |1 -
arch/cris/include/uapi/asm/ipcbuf.h|1 -
arch/cris/include/uapi/asm/kvm_para.h |1 -
arch/cris/include/uapi/asm/mman.h |1 -
arch/cris/include/uapi/asm/msgbuf.h| 33 ---
arch/cris/include/uapi/asm/poll.h |1 -
arch/cris/include/uapi/asm/ptrace.h|6 +-
.../arch/ptrace.h => uapi/asm/ptrace_v10.h}|0
.../arch/ptrace.h => uapi/asm/ptrace_v32.h}|0
arch/cris/include/uapi/asm/resource.h |6 --
arch/cris/include/uapi/asm/sembuf.h| 25 --
arch/cris/include/uapi/asm/shmbuf.h| 42 -
arch/cris/include/uapi/asm/siginfo.h |6 --
arch/cris/include/uapi/asm/socket.h| 92
arch/cris/include/uapi/asm/sockios.h | 13 ---
arch/cris/include/uapi/asm/statfs.h|6 --
arch/cris/include/uapi/asm/types.h |1 -
arch/cris/include/uapi/asm/unistd.h|
Re: [PATCH v2 3/3] mtd: spi-nor: Add clear flag status register support
On Wed, Aug 26, 2015 at 12:48 PM, Jagan Teki wrote:
> The clear flag status register operation is required by Micron
> SPI-NOR chips, which support FSR. And if error bits of FSR
> have been set like protection, voltage, erase, and program,
> it must be cleared by executing clear FSR operation.
>
> Signed-off-by: Jagan Teki
> Cc: Hou Zhiqiang
> Cc: Mingkai.Hu
> Cc: David Woodhouse
> Cc: Brian Norris
> ---
> Changes for v2:
> - Write cfsr instead of reading it.
> - Return -EINVAL instead of -1
>
> drivers/mtd/spi-nor/spi-nor.c | 23 +++
> include/linux/mtd/spi-nor.h | 9 +
> 2 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index f954d03..0a77061 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -163,6 +163,18 @@ static inline int write_disable(struct spi_nor *nor)
> return nor->write_reg(nor, SPINOR_OP_WRDI, NULL, 0);
> }
>
> +/*
> + * The clear flag status register operation is required by Micron
> + * SPI-NOR chips, which support FSR. And if error bits of FSR
> + * have been set like protection, voltage, erase, and program,
> + * it must be cleared by executing clear FSR operation.
> + * Returns negative if error occurred.
> + */
> +static inline int write_cfsr(struct spi_nor *nor)
> +{
> + return nor->write_reg(nor, SPINOR_OP_WRCFSR, NULL, 0);
> +}
> +
> static inline struct spi_nor *mtd_to_spi_nor(struct mtd_info *mtd)
> {
> return mtd->priv;
> @@ -209,10 +221,13 @@ static inline int spi_nor_sr_ready(struct spi_nor *nor)
> static inline int spi_nor_fsr_ready(struct spi_nor *nor)
> {
> int fsr = read_fsr(nor);
> - if (fsr < 0)
> - return fsr;
While it's rather unlikely that read_fsr() will return -EBFONT (which
has neither of the FSR_ERR_MASK bits set), you should keep the check
for negative return value intact.
> - else
> - return fsr & FSR_READY;
> + if (fsr & FSR_ERR_MASK) {
Also the N25Q032 data sheet says that these bits are only valid if
FSR_READY is set. so you should bail out early if it isn't, and check
the error bits only if it is set.
> + pr_err("flag status(0x%x) error occured\n", fsr);
I suggest using a better error message than "flag status() error
occured" and maybe even decode the error bits, so it's obvious what
kind of error is there without looking at the #defines or a data
sheet. Not sure about a better wording though, "last operation failed
for the following reason:%s%s%s\n", fsr & FSR_ERR_PROT ? " PROT" :
"", fsr & ...
> + write_cfsr(nor);
I'm not sure if a is_ready() function should clear the error bits, and
rather the functions that can cause these to be set should be made
aware of it and checking them (and then cleaning them), but maybe that
would require a rewrite how some functions are done.
> + return -EINVAL;
Also I wonder if there are more appropriate error values here than
-EINVAL, e.g. -EPERM if FSR_ERR_PROT is set, else -EIO if
FSR_ERR_ERASE or FSR_ERR_PROG are set.
> + }
> +
> + return fsr & FSR_READY;
> }
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
