Re: [PATCH v10 4/8] ata: libahci: allow to use multiple PHYs
Hi,
Antoine Ténart wrote:
> The current implementation of the libahci does not allow to use multiple
> PHYs. This patch adds the support of multiple PHYs by the libahci while
> keeping the old bindings valid for device tree compatibility.
>
> This introduce a new way of defining SATA ports in the device tree, with
> one port per sub-node. This as the advantage of allowing a per port
> configuration. Because some ports may be accessible but disabled in the
> device tree, the port_map mask is computed automatically when using
> this.
>
> Signed-off-by: Antoine Ténart
> ---
> drivers/ata/ahci.h | 3 +-
> drivers/ata/libahci_platform.c | 179
> -
> 2 files changed, 142 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
> index cb8d58926851..b0ea7b077d6e 100644
> --- a/drivers/ata/ahci.h
> +++ b/drivers/ata/ahci.h
> @@ -332,7 +332,8 @@ struct ahci_host_priv {
> boolgot_runtime_pm; /* Did we do pm_runtime_get? */
> struct clk *clks[AHCI_MAX_CLKS]; /* Optional */
> struct regulator*target_pwr;/* Optional */
> - struct phy *phy; /* If platform uses phy */
> + struct phy **phys; /* If platform uses phys */
> + unsignednphys; /* Number of phys */
> void*plat_data; /* Other platform data */
> /*
>* Optional ahci_start_engine override, if not set this gets set to the
> diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> index db9b90d876dd..2c2439b4101d 100644
> --- a/drivers/ata/libahci_platform.c
> +++ b/drivers/ata/libahci_platform.c
> @@ -39,6 +39,61 @@ static struct scsi_host_template ahci_platform_sht = {
> };
>
> /**
> + * ahci_platform_enable_phys - Enable PHYs
> + * @hpriv: host private area to store config values
> + *
> + * This function enables all the PHYs found in hpriv->phys, if any.
> + * If a PHY fails to be enabled, it disables all the PHYs already
> + * enabled in reverse order and returns an error.
> + *
> + * RETURNS:
> + * 0 on success otherwise a negative error code
> + */
> +int ahci_platform_enable_phys(struct ahci_host_priv *hpriv)
> +{
> + int i, rc = 0;
> +
You shouldn't have to initialize rc here, or does your gcc falsely
complain about an uninitialized variable if you don't?
> + for (i = 0; i < hpriv->nphys; i++) {
> + rc = phy_init(hpriv->phys[i]);
> + if (rc)
> + goto disable_phys;
> +
> + rc = phy_power_on(hpriv->phys[i]);
> + if (rc) {
> + phy_exit(hpriv->phys[i]);
> + goto disable_phys;
> + }
> + }
> +
> + return 0;
> +
> +disable_phys:
> + while (--i >= 0) {
> + phy_power_off(hpriv->phys[i]);
> + phy_exit(hpriv->phys[i]);
> + }
> + return rc;
> +}
Lothar Waßmann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 044/170] powerpc/perf: Ensure all EBB register state is cleared on fork()
From: Michael Ellerman
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 3df48c981d5a9610e02e9270b1bc4274fb536710 upstream.
In commit 330a1eb "Core EBB support for 64-bit book3s" I messed up
clear_task_ebb(). It clears some but not all of the task's Event Based
Branch (EBB) registers when we duplicate a task struct.
That allows a child task to observe the EBBHR & EBBRR of its parent,
which it should not be able to do.
Fix it by clearing EBBHR & EBBRR.
Signed-off-by: Michael Ellerman
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Jiri Slaby
---
arch/powerpc/include/asm/switch_to.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/switch_to.h
b/arch/powerpc/include/asm/switch_to.h
index 2be5618cdec6..06d63a3c1a88 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -85,6 +85,8 @@ static inline void clear_task_ebb(struct task_struct *t)
{
#ifdef CONFIG_PPC_BOOK3S_64
/* EBB perf events are not inherited, so clear all EBB state. */
+t->thread.ebbrr = 0;
+t->thread.ebbhr = 0;
t->thread.bescr = 0;
t->thread.mmcr2 = 0;
t->thread.mmcr0 = 0;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 010/170] iscsi-target: Explicily clear login response PDU in exception path
From: Nicholas Bellinger 3.12-stable review patch. If anyone has any objections, please let me know. === commit 683497566d48f86e04d026de1ee658dd74fc1077 upstream. This patch adds a explicit memset to the login response PDU exception path in iscsit_tx_login_rsp(). This addresses a regression bug introduced in commit baa4d64b where the initiator would end up not receiving the login response and associated status class + detail, before closing the login connection. Reported-by: Christophe Vu-Brugier Tested-by: Christophe Vu-Brugier Signed-off-by: Nicholas Bellinger Signed-off-by: Jiri Slaby --- drivers/target/iscsi/iscsi_target_util.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/target/iscsi/iscsi_target_util.c b/drivers/target/iscsi/iscsi_target_util.c index 1039de499bc6..658c9c77ec04 100644 --- a/drivers/target/iscsi/iscsi_target_util.c +++ b/drivers/target/iscsi/iscsi_target_util.c @@ -1294,6 +1294,8 @@ int iscsit_tx_login_rsp(struct iscsi_conn *conn, u8 status_class, u8 status_deta login->login_failed = 1; iscsit_collect_login_stats(conn, status_class, status_detail); + memset(>rsp[0], 0, ISCSI_HDR_LEN); + hdr = (struct iscsi_login_rsp *)>rsp[0]; hdr->opcode = ISCSI_OP_LOGIN_RSP; hdr->status_class = status_class; -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 081/170] drm/radeon/dp: fix lane/clock setup for dp 1.2 capable devices
From: Alex Deucher
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 3b6d9fd23e015b5397c438fd3cd74147d2c805b6 upstream.
Only DCE5+ asics support DP 1.2.
Noticed by ArtForz on IRC.
Signed-off-by: Alex Deucher
Signed-off-by: Jiri Slaby
---
drivers/gpu/drm/radeon/atombios_dp.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index 00885417..4601969be373 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -384,6 +384,19 @@ static int dp_get_max_dp_pix_clock(int link_rate,
/* radeon specific DP functions */
+static int radeon_dp_get_max_link_rate(struct drm_connector *connector,
+ u8 dpcd[DP_DPCD_SIZE])
+{
+ int max_link_rate;
+
+ if (radeon_connector_is_dp12_capable(connector))
+ max_link_rate = min(drm_dp_max_link_rate(dpcd), 54);
+ else
+ max_link_rate = min(drm_dp_max_link_rate(dpcd), 27);
+
+ return max_link_rate;
+}
+
/* First get the min lane# when low rate is used according to pixel clock
* (prefer low rate), second check max lane# supported by DP panel,
* if the max lane# < low rate lane# then use max lane# instead.
@@ -393,7 +406,7 @@ static int radeon_dp_get_dp_lane_number(struct
drm_connector *connector,
int pix_clock)
{
int bpp = convert_bpc_to_bpp(radeon_get_monitor_bpc(connector));
- int max_link_rate = drm_dp_max_link_rate(dpcd);
+ int max_link_rate = radeon_dp_get_max_link_rate(connector, dpcd);
int max_lane_num = drm_dp_max_lane_count(dpcd);
int lane_num;
int max_dp_pix_clock;
@@ -431,7 +444,7 @@ static int radeon_dp_get_dp_link_clock(struct drm_connector
*connector,
return 54;
}
- return drm_dp_max_link_rate(dpcd);
+ return radeon_dp_get_max_link_rate(connector, dpcd);
}
static u8 radeon_dp_encoder_service(struct radeon_device *rdev,
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 162/170] drm/radeon: fix typo in ci_stop_dpm()
From: Alex Deucher 3.12-stable review patch. If anyone has any objections, please let me know. === commit ed96377132e564d797c48a5490fd46bed01c4273 upstream. Need to use the RREG32_SMC() accessor since the register is an smc indirect index. Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby --- drivers/gpu/drm/radeon/ci_dpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c index 79682ff51b63..78e25d2e2fc4 100644 --- a/drivers/gpu/drm/radeon/ci_dpm.c +++ b/drivers/gpu/drm/radeon/ci_dpm.c @@ -1130,7 +1130,7 @@ static int ci_stop_dpm(struct radeon_device *rdev) tmp &= ~GLOBAL_PWRMGT_EN; WREG32_SMC(GENERAL_PWRMGT, tmp); - tmp = RREG32(SCLK_PWRMGT_CNTL); + tmp = RREG32_SMC(SCLK_PWRMGT_CNTL); tmp &= ~DYNAMIC_PM_EN; WREG32_SMC(SCLK_PWRMGT_CNTL, tmp); -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 017/170] mtip32xx: Increase timeout for STANDBY IMMEDIATE command
From: Asai Thambi S P
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 670a641420a3d9586eebe7429dfeec4e7ed447aa upstream.
Increased timeout for STANDBY IMMEDIATE command to 2 minutes.
Signed-off-by: Selvan Mani
Signed-off-by: Asai Thambi S P
Signed-off-by: Jens Axboe
Signed-off-by: Jiri Slaby
---
drivers/block/mtip32xx/mtip32xx.c | 66 +--
1 file changed, 35 insertions(+), 31 deletions(-)
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index 2e98df1a5c93..6fc6beb86493 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -1493,6 +1493,37 @@ static inline void ata_swap_string(u16 *buf, unsigned
int len)
be16_to_cpus([i]);
}
+static void mtip_set_timeout(struct driver_data *dd,
+ struct host_to_dev_fis *fis,
+ unsigned int *timeout, u8 erasemode)
+{
+ switch (fis->command) {
+ case ATA_CMD_DOWNLOAD_MICRO:
+ *timeout = 12; /* 2 minutes */
+ break;
+ case ATA_CMD_SEC_ERASE_UNIT:
+ case 0xFC:
+ if (erasemode)
+ *timeout = ((*(dd->port->identify + 90) * 2) * 6);
+ else
+ *timeout = ((*(dd->port->identify + 89) * 2) * 6);
+ break;
+ case ATA_CMD_STANDBYNOW1:
+ *timeout = 12; /* 2 minutes */
+ break;
+ case 0xF7:
+ case 0xFA:
+ *timeout = 6; /* 60 seconds */
+ break;
+ case ATA_CMD_SMART:
+ *timeout = 15000; /* 15 seconds */
+ break;
+ default:
+ *timeout = MTIP_IOCTL_COMMAND_TIMEOUT_MS;
+ break;
+ }
+}
+
/*
* Request the device identity information.
*
@@ -1602,6 +1633,7 @@ static int mtip_standby_immediate(struct mtip_port *port)
int rv;
struct host_to_dev_fis fis;
unsigned long start;
+ unsigned int timeout;
/* Build the FIS. */
memset(, 0, sizeof(struct host_to_dev_fis));
@@ -1609,6 +1641,8 @@ static int mtip_standby_immediate(struct mtip_port *port)
fis.opts= 1 << 7;
fis.command = ATA_CMD_STANDBYNOW1;
+ mtip_set_timeout(port->dd, , , 0);
+
start = jiffies;
rv = mtip_exec_internal_command(port,
,
@@ -1617,7 +1651,7 @@ static int mtip_standby_immediate(struct mtip_port *port)
0,
0,
GFP_ATOMIC,
- 15000);
+ timeout);
dbg_printk(MTIP_DRV_NAME "Time taken to complete standby cmd: %d ms\n",
jiffies_to_msecs(jiffies - start));
if (rv)
@@ -2156,36 +2190,6 @@ static unsigned int implicit_sector(unsigned char
command,
}
return rv;
}
-static void mtip_set_timeout(struct driver_data *dd,
- struct host_to_dev_fis *fis,
- unsigned int *timeout, u8 erasemode)
-{
- switch (fis->command) {
- case ATA_CMD_DOWNLOAD_MICRO:
- *timeout = 12; /* 2 minutes */
- break;
- case ATA_CMD_SEC_ERASE_UNIT:
- case 0xFC:
- if (erasemode)
- *timeout = ((*(dd->port->identify + 90) * 2) * 6);
- else
- *timeout = ((*(dd->port->identify + 89) * 2) * 6);
- break;
- case ATA_CMD_STANDBYNOW1:
- *timeout = 12; /* 2 minutes */
- break;
- case 0xF7:
- case 0xFA:
- *timeout = 6; /* 60 seconds */
- break;
- case ATA_CMD_SMART:
- *timeout = 15000; /* 15 seconds */
- break;
- default:
- *timeout = MTIP_IOCTL_COMMAND_TIMEOUT_MS;
- break;
- }
-}
/*
* Executes a taskfile
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 061/170] virtio-scsi: avoid cancelling uninitialized work items
From: Paolo Bonzini
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit cdda0e5acbb78f7b777049f8c27899e5c5bb368f upstream.
Calling the workqueue interface on uninitialized work items isn't a
good idea even if they're zeroed. It's not failing catastrophically only
through happy accidents.
Signed-off-by: Paolo Bonzini
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Christoph Hellwig
Signed-off-by: Jiri Slaby
---
drivers/scsi/virtio_scsi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 95a5d73e675c..57c39e1e6681 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -288,6 +288,8 @@ static void virtscsi_ctrl_done(struct virtqueue *vq)
virtscsi_vq_done(vscsi, >ctrl_vq, virtscsi_complete_free);
};
+static void virtscsi_handle_event(struct work_struct *work);
+
static int virtscsi_kick_event(struct virtio_scsi *vscsi,
struct virtio_scsi_event_node *event_node)
{
@@ -295,6 +297,7 @@ static int virtscsi_kick_event(struct virtio_scsi *vscsi,
struct scatterlist sg;
unsigned long flags;
+ INIT_WORK(_node->work, virtscsi_handle_event);
sg_init_one(, _node->event, sizeof(struct virtio_scsi_event));
spin_lock_irqsave(>event_vq.vq_lock, flags);
@@ -412,7 +415,6 @@ static void virtscsi_complete_event(struct virtio_scsi
*vscsi, void *buf)
{
struct virtio_scsi_event_node *event_node = buf;
- INIT_WORK(_node->work, virtscsi_handle_event);
schedule_work(_node->work);
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 004/170] rtmutex: Fix deadlock detector for real
From: Thomas Gleixner
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 397335f004f41e5fcf7a795e94eb3ab83411a17c upstream.
The current deadlock detection logic does not work reliably due to the
following early exit path:
/*
* Drop out, when the task has no waiters. Note,
* top_waiter can be NULL, when we are in the deboosting
* mode!
*/
if (top_waiter && (!task_has_pi_waiters(task) ||
top_waiter != task_top_pi_waiter(task)))
goto out_unlock_pi;
So this not only exits when the task has no waiters, it also exits
unconditionally when the current waiter is not the top priority waiter
of the task.
So in a nested locking scenario, it might abort the lock chain walk
and therefor miss a potential deadlock.
Simple fix: Continue the chain walk, when deadlock detection is
enabled.
We also avoid the whole enqueue, if we detect the deadlock right away
(A-A). It's an optimization, but also prevents that another waiter who
comes in after the detection and before the task has undone the damage
observes the situation and detects the deadlock and returns
-EDEADLOCK, which is wrong as the other task is not in a deadlock
situation.
Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Reviewed-by: Steven Rostedt
Cc: Lai Jiangshan
Link: http://lkml.kernel.org/r/20140522031949.725272...@linutronix.de
Signed-off-by: Thomas Gleixner
Signed-off-by: Mike Galbraith
Signed-off-by: Jiri Slaby
---
kernel/rtmutex.c | 32
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
index 0dd6aec1cb6a..16d5356ce45b 100644
--- a/kernel/rtmutex.c
+++ b/kernel/rtmutex.c
@@ -225,9 +225,16 @@ static int rt_mutex_adjust_prio_chain(struct task_struct
*task,
* top_waiter can be NULL, when we are in the deboosting
* mode!
*/
- if (top_waiter && (!task_has_pi_waiters(task) ||
- top_waiter != task_top_pi_waiter(task)))
- goto out_unlock_pi;
+ if (top_waiter) {
+ if (!task_has_pi_waiters(task))
+ goto out_unlock_pi;
+ /*
+* If deadlock detection is off, we stop here if we
+* are not the top pi waiter of the task.
+*/
+ if (!detect_deadlock && top_waiter != task_top_pi_waiter(task))
+ goto out_unlock_pi;
+ }
/*
* When deadlock detection is off then we check, if further
@@ -243,7 +250,12 @@ static int rt_mutex_adjust_prio_chain(struct task_struct
*task,
goto retry;
}
- /* Deadlock detection */
+ /*
+* Deadlock detection. If the lock is the same as the original
+* lock which caused us to walk the lock chain or if the
+* current lock is owned by the task which initiated the chain
+* walk, we detected a deadlock.
+*/
if (lock == orig_lock || rt_mutex_owner(lock) == top_task) {
debug_rt_mutex_deadlock(deadlock_detect, orig_waiter, lock);
raw_spin_unlock(>wait_lock);
@@ -412,6 +424,18 @@ static int task_blocks_on_rt_mutex(struct rt_mutex *lock,
unsigned long flags;
int chain_walk = 0, res;
+ /*
+* Early deadlock detection. We really don't want the task to
+* enqueue on itself just to untangle the mess later. It's not
+* only an optimization. We drop the locks, so another waiter
+* can come in before the chain walk detects the deadlock. So
+* the other will detect the deadlock and return -EDEADLOCK,
+* which is wrong, as the other waiter is not in a deadlock
+* situation.
+*/
+ if (detect_deadlock && owner == task)
+ return -EDEADLK;
+
raw_spin_lock_irqsave(>pi_lock, flags);
__rt_mutex_adjust_prio(task);
waiter->task = task;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 158/170] ext4: clarify ext4_error message in ext4_mb_generate_buddy_error()
From: Theodore Ts'o
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 94d4c066a4ff170a2671b1a9b153febbf36796f6 upstream.
We are spending a lot of time explaining to users what this error
means. Let's try to improve the message to avoid this problem.
Signed-off-by: Theodore Ts'o
Signed-off-by: Jiri Slaby
---
fs/ext4/mballoc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 08ddfdac955c..502f0fd71470 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -751,8 +751,8 @@ void ext4_mb_generate_buddy(struct super_block *sb,
if (free != grp->bb_free) {
ext4_grp_locked_error(sb, group, 0, 0,
- "%u clusters in bitmap, %u in gd; "
- "block bitmap corrupt.",
+ "block bitmap and bg descriptor "
+ "inconsistent: %u vs %u free clusters",
free, grp->bb_free);
/*
* If we intend to continue, we consider group descriptor
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 117/170] md: flush writes before starting a recovery.
From: NeilBrown
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 133d4527eab8d199a62eee6bd433f0776842df2e upstream.
When we write to a degraded array which has a bitmap, we
make sure the relevant bit in the bitmap remains set when
the write completes (so a 're-add' can quickly rebuilt a
temporarily-missing device).
If, immediately after such a write starts, we incorporate a spare,
commence recovery, and skip over the region where the write is
happening (because the 'needs recovery' flag isn't set yet),
then that write will not get to the new device.
Once the recovery finishes the new device will be trusted, but will
have incorrect data, leading to possible corruption.
We cannot set the 'needs recovery' flag when we start the write as we
do not know easily if the write will be "degraded" or not. That
depends on details of the particular raid level and particular write
request.
This patch fixes a corruption issue of long standing and so it
suitable for any -stable kernel. It applied correctly to 3.0 at
least and will minor editing to earlier kernels.
Reported-by: Bill
Tested-by: Bill
Link: http://lkml.kernel.org/r/53a518bb.60...@sbcglobal.net
Signed-off-by: NeilBrown
Signed-off-by: Jiri Slaby
---
drivers/md/md.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index c98e681fc9fc..bf030d4b09a7 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -7484,6 +7484,19 @@ void md_do_sync(struct md_thread *thread)
rdev->recovery_offset < j)
j = rdev->recovery_offset;
rcu_read_unlock();
+
+ /* If there is a bitmap, we need to make sure all
+* writes that started before we added a spare
+* complete before we start doing a recovery.
+* Otherwise the write might complete and (via
+* bitmap_endwrite) set a bit in the bitmap after the
+* recovery has checked that bit and skipped that
+* region.
+*/
+ if (mddev->bitmap) {
+ mddev->pers->quiesce(mddev, 1);
+ mddev->pers->quiesce(mddev, 0);
+ }
}
printk(KERN_INFO "md: %s of RAID array %s\n", desc, mdname(mddev));
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 045/170] powerpc: fix typo 'CONFIG_PPC_CPU'
From: Paul Bolle
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit b69a1da94f3d1589d1942b5d1b384d8cfaac4500 upstream.
Commit cd64d1697cf0 ("powerpc: mtmsrd not defined") added a check for
CONFIG_PPC_CPU were a check for CONFIG_PPC_FPU was clearly intended.
Fixes: cd64d1697cf0 ("powerpc: mtmsrd not defined")
Signed-off-by: Paul Bolle
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Jiri Slaby
---
arch/powerpc/lib/sstep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index b1faa1593c90..aec4dbf5a5cc 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1397,7 +1397,7 @@ int __kprobes emulate_step(struct pt_regs *regs, unsigned
int instr)
regs->gpr[rd] = byterev_4(val);
goto ldst_done;
-#ifdef CONFIG_PPC_CPU
+#ifdef CONFIG_PPC_FPU
case 535: /* lfsx */
case 567: /* lfsux */
if (!(regs->msr & MSR_FP))
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 137/170] hwmon: (emc2103) Clamp limits instead of bailing out
From: Guenter Roeck
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit f6c2dd20108c35e30e2c1f3c6142d189451a626b upstream.
It is customary to clamp limits instead of bailing out with an error
if a configured limit is out of the range supported by the driver.
This simplifies limit configuration, since the user will not typically
know chip and/or driver specific limits.
Reviewed-by: Jean Delvare
Signed-off-by: Guenter Roeck
Signed-off-by: Jiri Slaby
---
drivers/hwmon/emc2103.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/hwmon/emc2103.c b/drivers/hwmon/emc2103.c
index 2c137b26acb4..5790246a7e1d 100644
--- a/drivers/hwmon/emc2103.c
+++ b/drivers/hwmon/emc2103.c
@@ -250,9 +250,7 @@ static ssize_t set_temp_min(struct device *dev, struct
device_attribute *da,
if (result < 0)
return result;
- val = DIV_ROUND_CLOSEST(val, 1000);
- if ((val < -63) || (val > 127))
- return -EINVAL;
+ val = clamp_val(DIV_ROUND_CLOSEST(val, 1000), -63, 127);
mutex_lock(>update_lock);
data->temp_min[nr] = val;
@@ -274,9 +272,7 @@ static ssize_t set_temp_max(struct device *dev, struct
device_attribute *da,
if (result < 0)
return result;
- val = DIV_ROUND_CLOSEST(val, 1000);
- if ((val < -63) || (val > 127))
- return -EINVAL;
+ val = clamp_val(DIV_ROUND_CLOSEST(val, 1000), -63, 127);
mutex_lock(>update_lock);
data->temp_max[nr] = val;
@@ -390,15 +386,14 @@ static ssize_t set_fan_target(struct device *dev, struct
device_attribute *da,
{
struct emc2103_data *data = emc2103_update_device(dev);
struct i2c_client *client = to_i2c_client(dev);
- long rpm_target;
+ unsigned long rpm_target;
- int result = kstrtol(buf, 10, _target);
+ int result = kstrtoul(buf, 10, _target);
if (result < 0)
return result;
/* Datasheet states 16384 as maximum RPM target (table 3.2) */
- if ((rpm_target < 0) || (rpm_target > 16384))
- return -EINVAL;
+ rpm_target = clamp_val(rpm_target, 0, 16384);
mutex_lock(>update_lock);
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 104/170] arm64: Bug fix in stack alignment exception
From: ChiaHao 3.12-stable review patch. If anyone has any objections, please let me know. === commit 3906c2b53cd23c2ae03e6ce41432c8e7f0a3cbbb upstream. The value of ESR has been stored into x1, and should be directly pass to do_sp_pc_abort function, "MOV x1, x25" is an extra operation and do_sp_pc_abort will get the wrong value of ESR. Signed-off-by: ChiaHao Signed-off-by: Catalin Marinas Cc: Signed-off-by: Jiri Slaby --- arch/arm64/kernel/entry.S | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index 3881fd115ebb..028a1b91e2b3 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -275,7 +275,6 @@ el1_sp_pc: * Stack or PC alignment exception handling */ mrs x0, far_el1 - mov x1, x25 mov x2, sp b do_sp_pc_abort el1_undef: -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 047/170] powerpc: Add AT_HWCAP2 to indicate V.CRYPTO category support
From: Benjamin Herrenschmidt 3.12-stable review patch. If anyone has any objections, please let me know. === commit dd58a092c4202f2bd490adab7285b3ff77f8e467 upstream. The Vector Crypto category instructions are supported by current POWER8 chips, advertise them to userspace using a specific bit to properly differentiate with chips of the same architecture level that might not have them. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Jiri Slaby --- arch/powerpc/include/uapi/asm/cputable.h | 1 + arch/powerpc/kernel/cputable.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/uapi/asm/cputable.h b/arch/powerpc/include/uapi/asm/cputable.h index 5b7657959faa..de2c0e4ee1aa 100644 --- a/arch/powerpc/include/uapi/asm/cputable.h +++ b/arch/powerpc/include/uapi/asm/cputable.h @@ -41,5 +41,6 @@ #define PPC_FEATURE2_EBB 0x1000 #define PPC_FEATURE2_ISEL 0x0800 #define PPC_FEATURE2_TAR 0x0400 +#define PPC_FEATURE2_VEC_CRYPTO0x0200 #endif /* _UAPI__ASM_POWERPC_CPUTABLE_H */ diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c index 597d954e5860..c5d3d023363a 100644 --- a/arch/powerpc/kernel/cputable.c +++ b/arch/powerpc/kernel/cputable.c @@ -105,7 +105,8 @@ extern void __restore_cpu_e6500(void); PPC_FEATURE_PSERIES_PERFMON_COMPAT) #define COMMON_USER2_POWER8(PPC_FEATURE2_ARCH_2_07 | \ PPC_FEATURE2_HTM_COMP | PPC_FEATURE2_DSCR | \ -PPC_FEATURE2_ISEL | PPC_FEATURE2_TAR) +PPC_FEATURE2_ISEL | PPC_FEATURE2_TAR | \ +PPC_FEATURE2_VEC_CRYPTO) #define COMMON_USER_PA6T (COMMON_USER_PPC64 | PPC_FEATURE_PA6T |\ PPC_FEATURE_TRUE_LE | \ PPC_FEATURE_HAS_ALTIVEC_COMP) -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 147/170] powerpc/perf: Clear MMCR2 when enabling PMU
From: Joel Stanley
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit b50a6c584bb47b370f84bfd746770c0bbe7129b7 upstream.
On POWER8 when switching to a KVM guest we set bits in MMCR2 to freeze
the PMU counters. Aside from on boot they are then never reset,
resulting in stuck perf counters for any user in the guest or host.
We now set MMCR2 to 0 whenever enabling the PMU, which provides a sane
state for perf to use the PMU counters under either the guest or the
host.
This was manifesting as a bug with ppc64_cpu --frequency:
$ sudo ppc64_cpu --frequency
WARNING: couldn't run on cpu 0
WARNING: couldn't run on cpu 8
...
WARNING: couldn't run on cpu 144
WARNING: couldn't run on cpu 152
min:18446744073.710 GHz (cpu -1)
max:0.000 GHz (cpu -1)
avg:0.000 GHz
The command uses a perf counter to measure CPU cycles over a fixed
amount of time, in order to approximate the frequency of the machine.
The counters were returning zero once a guest was started, regardless of
weather it was still running or had been shut down.
By dumping the value of MMCR2, it was observed that once a guest is
running MMCR2 is set to 1s - which stops counters from running:
$ sudo sh -c 'echo p > /proc/sysrq-trigger'
CPU: 0 PMU registers, ppmu = POWER8 n_counters = 6
PMC1: 5b635e38 PMC2: PMC3: PMC4:
PMC5: 1bf5a646 PMC6: 5793d378 PMC7: deadbeef PMC8: deadbeef
MMCR0: 8000 MMCR1: 1e00 MMCRA: 0400
MMCR2: fc00 EBBHR:
EBBRR: BESCR:
SIAR: 000a51cc SDAR: cfc4 SIER: 0100
This is done unconditionally in book3s_hv_interrupts.S upon entering the
guest, and the original value is only save/restored if the host has
indicated it was using the PMU. This is okay, however the user of the
PMU needs to ensure that it is in a defined state when it starts using
it.
Fixes: e05b9b9e5c10 ("powerpc/perf: Power8 PMU support")
Signed-off-by: Joel Stanley
Acked-by: Michael Ellerman
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Jiri Slaby
---
arch/powerpc/perf/core-book3s.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 53cf36206ec6..57a8ff90ed60 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1164,6 +1164,9 @@ static void power_pmu_enable(struct pmu *pmu)
mb();
write_mmcr0(cpuhw, mmcr0);
+ if (ppmu->flags & PPMU_ARCH_207S)
+ mtspr(SPRN_MMCR2, 0);
+
/*
* Enable instruction sampling if necessary
*/
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 126/170] mm: fix crashes from mbind() merging vmas
From: Hugh Dickins
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit d05f0cdcbe6388723f1900c549b4850360545201 upstream.
In v2.6.34 commit 9d8cebd4bcd7 ("mm: fix mbind vma merge problem")
introduced vma merging to mbind(), but it should have also changed the
convention of passing start vma from queue_pages_range() (formerly
check_range()) to new_vma_page(): vma merging may have already freed
that structure, resulting in BUG at mm/mempolicy.c:1738 and probably
worse crashes.
Fixes: 9d8cebd4bcd7 ("mm: fix mbind vma merge problem")
Reported-by: Naoya Horiguchi
Tested-by: Naoya Horiguchi
Signed-off-by: Hugh Dickins
Acked-by: Christoph Lameter
Cc: KOSAKI Motohiro
Cc: Minchan Kim
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Jiri Slaby
---
mm/mempolicy.c | 46 --
1 file changed, 20 insertions(+), 26 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index a005cc9f6f18..945316989352 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -653,19 +653,18 @@ static unsigned long change_prot_numa(struct
vm_area_struct *vma,
* @nodes and @flags,) it's isolated and queued to the pagelist which is
* passed via @private.)
*/
-static struct vm_area_struct *
+static int
queue_pages_range(struct mm_struct *mm, unsigned long start, unsigned long end,
const nodemask_t *nodes, unsigned long flags, void *private)
{
- int err;
- struct vm_area_struct *first, *vma, *prev;
-
+ int err = 0;
+ struct vm_area_struct *vma, *prev;
- first = find_vma(mm, start);
- if (!first)
- return ERR_PTR(-EFAULT);
+ vma = find_vma(mm, start);
+ if (!vma)
+ return -EFAULT;
prev = NULL;
- for (vma = first; vma && vma->vm_start < end; vma = vma->vm_next) {
+ for (; vma && vma->vm_start < end; vma = vma->vm_next) {
unsigned long endvma = vma->vm_end;
if (endvma > end)
@@ -675,9 +674,9 @@ queue_pages_range(struct mm_struct *mm, unsigned long
start, unsigned long end,
if (!(flags & MPOL_MF_DISCONTIG_OK)) {
if (!vma->vm_next && vma->vm_end < end)
- return ERR_PTR(-EFAULT);
+ return -EFAULT;
if (prev && prev->vm_end < vma->vm_start)
- return ERR_PTR(-EFAULT);
+ return -EFAULT;
}
if (flags & MPOL_MF_LAZY) {
@@ -691,15 +690,13 @@ queue_pages_range(struct mm_struct *mm, unsigned long
start, unsigned long end,
err = queue_pages_pgd_range(vma, start, endvma, nodes,
flags, private);
- if (err) {
- first = ERR_PTR(err);
+ if (err)
break;
- }
}
next:
prev = vma;
}
- return first;
+ return err;
}
/*
@@ -1184,16 +1181,17 @@ out:
/*
* Allocate a new page for page migration based on vma policy.
- * Start assuming that page is mapped by vma pointed to by @private.
+ * Start by assuming the page is mapped by the same vma as contains @start.
* Search forward from there, if not. N.B., this assumes that the
* list of pages handed to migrate_pages()--which is how we get here--
* is in virtual address order.
*/
-static struct page *new_vma_page(struct page *page, unsigned long private, int
**x)
+static struct page *new_page(struct page *page, unsigned long start, int **x)
{
- struct vm_area_struct *vma = (struct vm_area_struct *)private;
+ struct vm_area_struct *vma;
unsigned long uninitialized_var(address);
+ vma = find_vma(current->mm, start);
while (vma) {
address = page_address_in_vma(page, vma);
if (address != -EFAULT)
@@ -1223,7 +1221,7 @@ int do_migrate_pages(struct mm_struct *mm, const
nodemask_t *from,
return -ENOSYS;
}
-static struct page *new_vma_page(struct page *page, unsigned long private, int
**x)
+static struct page *new_page(struct page *page, unsigned long start, int **x)
{
return NULL;
}
@@ -1233,7 +1231,6 @@ static long do_mbind(unsigned long start, unsigned long
len,
unsigned short mode, unsigned short mode_flags,
nodemask_t *nmask, unsigned long flags)
{
- struct vm_area_struct *vma;
struct mm_struct *mm = current->mm;
struct mempolicy *new;
unsigned long end;
@@ -1299,11 +1296,9 @@ static long do_mbind(unsigned long start, unsigned long
len,
if (err)
goto mpol_out;
- vma = queue_pages_range(mm, start, end, nmask,
+ err = queue_pages_range(mm, start, end, nmask,
[PATCH 3.12 007/170] rtmutex: Plug slow unlock race
From: Thomas Gleixner
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 27e35715df54cbc4f2d044f681802ae30479e7fb upstream.
When the rtmutex fast path is enabled the slow unlock function can
create the following situation:
spin_lock(foo->m->wait_lock);
foo->m->owner = NULL;
rt_mutex_lock(foo->m); <-- fast path
free = atomic_dec_and_test(foo->refcnt);
rt_mutex_unlock(foo->m); <-- fast path
if (free)
kfree(foo);
spin_unlock(foo->m->wait_lock); <--- Use after free.
Plug the race by changing the slow unlock to the following scheme:
while (!rt_mutex_has_waiters(m)) {
/* Clear the waiters bit in m->owner */
clear_rt_mutex_waiters(m);
owner = rt_mutex_owner(m);
spin_unlock(m->wait_lock);
if (cmpxchg(m->owner, owner, 0) == owner)
return;
spin_lock(m->wait_lock);
}
So in case of a new waiter incoming while the owner tries the slow
path unlock we have two situations:
unlock(wait_lock);
lock(wait_lock);
cmpxchg(p, owner, 0) == owner
mark_rt_mutex_waiters(lock);
acquire(lock);
Or:
unlock(wait_lock);
lock(wait_lock);
mark_rt_mutex_waiters(lock);
cmpxchg(p, owner, 0) != owner
enqueue_waiter();
unlock(wait_lock);
lock(wait_lock);
wakeup_next waiter();
unlock(wait_lock);
lock(wait_lock);
acquire(lock);
If the fast path is disabled, then the simple
m->owner = NULL;
unlock(m->wait_lock);
is sufficient as all access to m->owner is serialized via
m->wait_lock;
Also document and clarify the wakeup_next_waiter function as suggested
by Oleg Nesterov.
Reported-by: Steven Rostedt
Signed-off-by: Thomas Gleixner
Reviewed-by: Steven Rostedt
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20140611183852.937945...@linutronix.de
Signed-off-by: Thomas Gleixner
Signed-off-by: Mike Galbraith
Signed-off-by: Jiri Slaby
---
kernel/rtmutex.c | 115 ---
1 file changed, 109 insertions(+), 6 deletions(-)
diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
index ff24a43f192f..51a83343df68 100644
--- a/kernel/rtmutex.c
+++ b/kernel/rtmutex.c
@@ -82,6 +82,47 @@ static inline void mark_rt_mutex_waiters(struct rt_mutex
*lock)
owner = *p;
} while (cmpxchg(p, owner, owner | RT_MUTEX_HAS_WAITERS) != owner);
}
+
+/*
+ * Safe fastpath aware unlock:
+ * 1) Clear the waiters bit
+ * 2) Drop lock->wait_lock
+ * 3) Try to unlock the lock with cmpxchg
+ */
+static inline bool unlock_rt_mutex_safe(struct rt_mutex *lock)
+ __releases(lock->wait_lock)
+{
+ struct task_struct *owner = rt_mutex_owner(lock);
+
+ clear_rt_mutex_waiters(lock);
+ raw_spin_unlock(>wait_lock);
+ /*
+* If a new waiter comes in between the unlock and the cmpxchg
+* we have two situations:
+*
+* unlock(wait_lock);
+* lock(wait_lock);
+* cmpxchg(p, owner, 0) == owner
+* mark_rt_mutex_waiters(lock);
+* acquire(lock);
+* or:
+*
+* unlock(wait_lock);
+* lock(wait_lock);
+* mark_rt_mutex_waiters(lock);
+*
+* cmpxchg(p, owner, 0) != owner
+* enqueue_waiter();
+* unlock(wait_lock);
+* lock(wait_lock);
+* wake waiter();
+* unlock(wait_lock);
+* lock(wait_lock);
+* acquire(lock);
+*/
+ return rt_mutex_cmpxchg(lock, owner, NULL);
+}
+
#else
# define rt_mutex_cmpxchg(l,c,n) (0)
static inline void mark_rt_mutex_waiters(struct rt_mutex *lock)
@@ -89,6 +130,17 @@ static inline void mark_rt_mutex_waiters(struct rt_mutex
*lock)
lock->owner = (struct task_struct *)
((unsigned long)lock->owner | RT_MUTEX_HAS_WAITERS);
}
+
+/*
+ * Simple slow path only version: lock->owner is protected by lock->wait_lock.
+ */
+static inline bool unlock_rt_mutex_safe(struct rt_mutex *lock)
+ __releases(lock->wait_lock)
+{
+ lock->owner = NULL;
+ raw_spin_unlock(>wait_lock);
+ return true;
+}
#endif
/*
@@ -536,7 +588,8 @@ static int
[PATCH 3.12 018/170] mtip32xx: Remove dfs_parent after pci unregister
From: Asai Thambi S P
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit af5ded8ccf21627f9614afc03b356712666ed225 upstream.
In module exit, dfs_parent and it's subtree were removed before
unregistering with pci. When debugfs entry for each device is attempted
to remove in pci_remove() context, they don't exist, as dfs_parent and
its children were already ripped apart.
Modified to first unregister with pci and then remove dfs_parent.
Signed-off-by: Asai Thambi S P
Signed-off-by: Jens Axboe
Signed-off-by: Jiri Slaby
---
drivers/block/mtip32xx/mtip32xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index 6fc6beb86493..560227b817fe 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -4785,13 +4785,13 @@ static int __init mtip_init(void)
*/
static void __exit mtip_exit(void)
{
- debugfs_remove_recursive(dfs_parent);
-
/* Release the allocated major block device number. */
unregister_blkdev(mtip_major, MTIP_DRV_NAME);
/* Unregister the PCI driver. */
pci_unregister_driver(_pci_driver);
+
+ debugfs_remove_recursive(dfs_parent);
}
MODULE_AUTHOR("Micron Technology, Inc");
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 156/170] ext4: fix unjournalled bg descriptor while initializing inode bitmap
From: Theodore Ts'o
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 61c219f5814277ecb71d64cb30297028d6665979 upstream.
The first time that we allocate from an uninitialized inode allocation
bitmap, if the block allocation bitmap is also uninitalized, we need
to get write access to the block group descriptor before we start
modifying the block group descriptor flags and updating the free block
count, etc. Otherwise, there is the potential of a bad journal
checksum (if journal checksums are enabled), and of the file system
becoming inconsistent if we crash at exactly the wrong time.
Signed-off-by: Theodore Ts'o
Signed-off-by: Jiri Slaby
---
fs/ext4/ialloc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 137193ff389b..5b5971c20af1 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -851,6 +851,13 @@ got:
goto out;
}
+ BUFFER_TRACE(group_desc_bh, "get_write_access");
+ err = ext4_journal_get_write_access(handle, group_desc_bh);
+ if (err) {
+ ext4_std_error(sb, err);
+ goto out;
+ }
+
/* We may have to initialize the block bitmap if it isn't already */
if (ext4_has_group_desc_csum(sb) &&
gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
@@ -887,13 +894,6 @@ got:
}
}
- BUFFER_TRACE(group_desc_bh, "get_write_access");
- err = ext4_journal_get_write_access(handle, group_desc_bh);
- if (err) {
- ext4_std_error(sb, err);
- goto out;
- }
-
/* Update the relevant bg descriptor fields */
if (ext4_has_group_desc_csum(sb)) {
int free;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 095/170] hwmon: (ina2xx) Cast to s16 on shunt and current regs
From: Fabio Baltieri
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit c0214f98943b1fe43f7be61b7782b0c8f0836f28 upstream.
All devices supported by ina2xx are bidirectional and report the
measured shunt voltage and power values as a signed 16 bit, but the
current driver implementation caches all registers as u16, leading
to an incorrect sign extension when reporting to userspace in
ina2xx_get_value().
This patch fixes the problem by casting the signed registers to s16.
Tested on an INA219.
Signed-off-by: Fabio Baltieri
Signed-off-by: Guenter Roeck
Signed-off-by: Jiri Slaby
---
drivers/hwmon/ina2xx.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index 70a39a8ac016..554f5c3fe5c4 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -148,7 +148,8 @@ static int ina2xx_get_value(struct ina2xx_data *data, u8
reg)
switch (reg) {
case INA2XX_SHUNT_VOLTAGE:
- val = DIV_ROUND_CLOSEST(data->regs[reg],
+ /* signed register */
+ val = DIV_ROUND_CLOSEST((s16)data->regs[reg],
data->config->shunt_div);
break;
case INA2XX_BUS_VOLTAGE:
@@ -160,8 +161,8 @@ static int ina2xx_get_value(struct ina2xx_data *data, u8
reg)
val = data->regs[reg] * data->config->power_lsb;
break;
case INA2XX_CURRENT:
- /* LSB=1mA (selected). Is in mA */
- val = data->regs[reg];
+ /* signed register, LSB=1mA (selected), in mA */
+ val = (s16)data->regs[reg];
break;
default:
/* programmer goofed */
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 005/170] rtmutex: Detect changes in the pi lock chain
From: Thomas Gleixner
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 82084984383babe728e6e3c9a8e5c46278091315 upstream.
When we walk the lock chain, we drop all locks after each step. So the
lock chain can change under us before we reacquire the locks. That's
harmless in principle as we just follow the wrong lock path. But it
can lead to a false positive in the dead lock detection logic:
T0 holds L0
T0 blocks on L1 held by T1
T1 blocks on L2 held by T2
T2 blocks on L3 held by T3
T4 blocks on L4 held by T4
Now we walk the chain
lock T1 -> lock L2 -> adjust L2 -> unlock T1 ->
lock T2 -> adjust T2 -> drop locks
T2 times out and blocks on L0
Now we continue:
lock T2 -> lock L0 -> deadlock detected, but it's not a deadlock at all.
Brad tried to work around that in the deadlock detection logic itself,
but the more I looked at it the less I liked it, because it's crystal
ball magic after the fact.
We actually can detect a chain change very simple:
lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 ->
next_lock = T2->pi_blocked_on->lock;
drop locks
T2 times out and blocks on L0
Now we continue:
lock T2 ->
if (next_lock != T2->pi_blocked_on->lock)
return;
So if we detect that T2 is now blocked on a different lock we stop the
chain walk. That's also correct in the following scenario:
lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 ->
next_lock = T2->pi_blocked_on->lock;
drop locks
T3 times out and drops L3
T2 acquires L3 and blocks on L4 now
Now we continue:
lock T2 ->
if (next_lock != T2->pi_blocked_on->lock)
return;
We don't have to follow up the chain at that point, because T2
propagated our priority up to T4 already.
[ Folded a cleanup patch from peterz ]
Signed-off-by: Thomas Gleixner
Reported-by: Brad Mouring
Cc: Steven Rostedt
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20140605152801.930031...@linutronix.de
Signed-off-by: Mike Galbraith
Signed-off-by: Jiri Slaby
---
kernel/rtmutex.c | 95 ++--
1 file changed, 71 insertions(+), 24 deletions(-)
diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
index 16d5356ce45b..c343cc9702af 100644
--- a/kernel/rtmutex.c
+++ b/kernel/rtmutex.c
@@ -142,27 +142,36 @@ static void rt_mutex_adjust_prio(struct task_struct *task)
*/
int max_lock_depth = 1024;
+static inline struct rt_mutex *task_blocked_on_lock(struct task_struct *p)
+{
+ return p->pi_blocked_on ? p->pi_blocked_on->lock : NULL;
+}
+
/*
* Adjust the priority chain. Also used for deadlock detection.
* Decreases task's usage by one - may thus free the task.
*
- * @task: the task owning the mutex (owner) for which a chain walk is probably
- * needed
+ * @task: the task owning the mutex (owner) for which a chain walk is
+ * probably needed
* @deadlock_detect: do we have to carry out deadlock detection?
- * @orig_lock: the mutex (can be NULL if we are walking the chain to recheck
- *things for a task that has just got its priority adjusted, and
- *is waiting on a mutex)
+ * @orig_lock: the mutex (can be NULL if we are walking the chain to recheck
+ * things for a task that has just got its priority adjusted, and
+ * is waiting on a mutex)
+ * @next_lock: the mutex on which the owner of @orig_lock was blocked before
+ * we dropped its pi_lock. Is never dereferenced, only used for
+ * comparison to detect lock chain changes.
* @orig_waiter: rt_mutex_waiter struct for the task that has just donated
- * its priority to the mutex owner (can be NULL in the case
- * depicted above or if the top waiter is gone away and we are
- * actually deboosting the owner)
- * @top_task: the current top waiter
+ * its priority to the mutex owner (can be NULL in the case
+ * depicted above or if the top waiter is gone away and we are
+ * actually deboosting the owner)
+ * @top_task: the current top waiter
*
* Returns 0 or -EDEADLK.
*/
static int rt_mutex_adjust_prio_chain(struct task_struct *task,
int deadlock_detect,
struct rt_mutex *orig_lock,
+ struct rt_mutex *next_lock,
struct rt_mutex_waiter *orig_waiter,
struct task_struct *top_task)
{
@@ -221,6 +230,18 @@ static int rt_mutex_adjust_prio_chain(struct task_struct
*task,
goto out_unlock_pi;
/*
+* We dropped all locks after taking a refcount on @task, so
+* the task might have moved on in the lock chain or even left
+* the chain completely and blocks now on an unrelated lock or
+* on @orig_lock.
+*
+*
[PATCH 3.12 123/170] ALSA: usb-audio: Suppress repetitive debug messages from retire_playback_urb()
From: Tim Gardner 3.12-stable review patch. If anyone has any objections, please let me know. === commit a5065eb6da55b226661456e6a7435f605df98111 upstream. BugLink: http://bugs.launchpad.net/bugs/1305133 Malfunctioning or slow devices can cause a flood of dmesg SPAM. I've ignored checkpatch.pl complaints about the use of printk_ratelimit() in favour of prior art in sound/usb/pcm.c. WARNING: Prefer printk_ratelimited or pr__ratelimited to printk_ratelimit + if (printk_ratelimit() && Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Eldad Zack Cc: Daniel Mack Cc: Clemens Ladisch Signed-off-by: Tim Gardner Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby --- sound/usb/pcm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index b375d58871e7..d59e0c1a3e20 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -1491,7 +1491,8 @@ static void retire_playback_urb(struct snd_usb_substream *subs, * The error should be lower than 2ms since the estimate relies * on two reads of a counter updated every ms. */ - if (abs(est_delay - subs->last_delay) * 1000 > runtime->rate * 2) + if (printk_ratelimit() && + abs(est_delay - subs->last_delay) * 1000 > runtime->rate * 2) snd_printk(KERN_DEBUG "delay: estimated %d, actual %d\n", est_delay, subs->last_delay); -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 143/170] ACPI / EC: Remove duplicated ec_wait_ibf0() waiter
From: Lv Zheng
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 9b80f0f73ae1583c22325ede341c74195847618c upstream.
After we've added the first command byte write into advance_transaction(),
the IBF=0 waiter is duplicated with the command completion waiter
implemented in the ec_poll() because:
If IBF=1 blocked the first command byte write invoked in the task
context ec_poll(), it would be kicked off upon IBF=0 interrupt or timed
out and retried again in the task context.
Remove this seperate and duplicate IBF=0 waiter. By doing so we can
reduce the overall number of times to access the EC_SC(R) status
register.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams
Reported-and-tested-by: Hans de Goede
Reported-by: Barton Xu
Tested-by: Steffen Weber
Tested-by: Arthur Chen
Signed-off-by: Lv Zheng
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jiri Slaby
---
drivers/acpi/ec.c | 27 +--
1 file changed, 1 insertion(+), 26 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 6e091a96d023..7b52a724a0dd 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -288,23 +288,6 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec *ec,
return ret;
}
-static int ec_check_ibf0(struct acpi_ec *ec)
-{
- u8 status = acpi_ec_read_status(ec);
- return (status & ACPI_EC_FLAG_IBF) == 0;
-}
-
-static int ec_wait_ibf0(struct acpi_ec *ec)
-{
- unsigned long delay = jiffies + msecs_to_jiffies(ec_delay);
- /* interrupt wait manually if GPE mode is not active */
- while (time_before(jiffies, delay))
- if (wait_event_timeout(ec->wait, ec_check_ibf0(ec),
- msecs_to_jiffies(1)))
- return 0;
- return -ETIME;
-}
-
static int acpi_ec_transaction(struct acpi_ec *ec, struct transaction *t)
{
int status;
@@ -325,12 +308,6 @@ static int acpi_ec_transaction(struct acpi_ec *ec, struct
transaction *t)
goto unlock;
}
}
- if (ec_wait_ibf0(ec)) {
- pr_err(PREFIX "input buffer is not empty, "
- "aborting transaction\n");
- status = -ETIME;
- goto end;
- }
pr_debug(PREFIX "transaction start (cmd=0x%02x, addr=0x%02x)\n",
t->command, t->wdata ? t->wdata[0] : 0);
/* disable GPE during transaction if storm is detected */
@@ -354,7 +331,6 @@ static int acpi_ec_transaction(struct acpi_ec *ec, struct
transaction *t)
set_bit(EC_FLAGS_GPE_STORM, >flags);
}
pr_debug(PREFIX "transaction end\n");
-end:
if (ec->global_lock)
acpi_release_global_lock(glk);
unlock:
@@ -680,8 +656,7 @@ static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
spin_lock_irqsave(>lock, flags);
advance_transaction(ec);
spin_unlock_irqrestore(>lock, flags);
- if (ec_transaction_completed(ec) &&
- (acpi_ec_read_status(ec) & ACPI_EC_FLAG_IBF) == 0) {
+ if (ec_transaction_completed(ec)) {
wake_up(>wait);
ec_check_sci(ec, acpi_ec_read_status(ec));
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 053/170] ptrace,x86: force IRET path after a ptrace_stop()
From: Tejun Heo
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit b9cd18de4db3c9ffa7e17b0dc0ca99ed5aa4d43a upstream.
The 'sysret' fastpath does not correctly restore even all regular
registers, much less any segment registers or reflags values. That is
very much part of why it's faster than 'iret'.
Normally that isn't a problem, because the normal ptrace() interface
catches the process using the signal handler infrastructure, which
always returns with an iret.
However, some paths can get caught using ptrace_event() instead of the
signal path, and for those we need to make sure that we aren't going to
return to user space using 'sysret'. Otherwise the modifications that
may have been done to the register set by the tracer wouldn't
necessarily take effect.
Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from
arch_ptrace_stop_needed() which is invoked from ptrace_stop().
Signed-off-by: Tejun Heo
Reported-by: Andy Lutomirski
Acked-by: Oleg Nesterov
Suggested-by: Linus Torvalds
Signed-off-by: Linus Torvalds
Signed-off-by: Jiri Slaby
---
arch/x86/include/asm/ptrace.h | 16
include/linux/ptrace.h| 3 +++
2 files changed, 19 insertions(+)
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 942a08623a1a..68e9f007cd4a 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -232,6 +232,22 @@ static inline unsigned long
regs_get_kernel_stack_nth(struct pt_regs *regs,
#define ARCH_HAS_USER_SINGLE_STEP_INFO
+/*
+ * When hitting ptrace_stop(), we cannot return using SYSRET because
+ * that does not restore the full CPU state, only a minimal set. The
+ * ptracer can change arbitrary register values, which is usually okay
+ * because the usual ptrace stops run off the signal delivery path which
+ * forces IRET; however, ptrace_event() stops happen in arbitrary places
+ * in the kernel and don't force IRET path.
+ *
+ * So force IRET path after a ptrace stop.
+ */
+#define arch_ptrace_stop_needed(code, info)\
+({ \
+ set_thread_flag(TIF_NOTIFY_RESUME); \
+ false; \
+})
+
struct user_desc;
extern int do_get_thread_area(struct task_struct *p, int idx,
struct user_desc __user *info);
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 077904c8b70d..cc79eff4a1ad 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -334,6 +334,9 @@ static inline void user_single_step_siginfo(struct
task_struct *tsk,
* calling arch_ptrace_stop() when it would be superfluous. For example,
* if the thread has not been back to user mode since the last stop, the
* thread state might indicate that nothing needs to be done.
+ *
+ * This is guaranteed to be invoked once before a task stops for ptrace and
+ * may include arch-specific operations necessary prior to a ptrace stop.
*/
#define arch_ptrace_stop_needed(code, info)(0)
#endif
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 051/170] MIPS: KVM: Fix memory leak on VCPU
From: Deng-Cheng Zhu 3.12-stable review patch. If anyone has any objections, please let me know. === commit 8c9eb041cf76038eb3b62ee259607eec9b89f48d upstream. kvm_arch_vcpu_free() is called in 2 code paths: 1) kvm_vm_ioctl() kvm_vm_ioctl_create_vcpu() kvm_arch_vcpu_destroy() kvm_arch_vcpu_free() 2) kvm_put_kvm() kvm_destroy_vm() kvm_arch_destroy_vm() kvm_mips_free_vcpus() kvm_arch_vcpu_free() Neither of the paths handles VCPU free. We need to do it in kvm_arch_vcpu_free() corresponding to the memory allocation in kvm_arch_vcpu_create(). Signed-off-by: Deng-Cheng Zhu Reviewed-by: James Hogan Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby --- arch/mips/kvm/kvm_mips.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/mips/kvm/kvm_mips.c b/arch/mips/kvm/kvm_mips.c index 8b900e987338..3f3e5b2b2f38 100644 --- a/arch/mips/kvm/kvm_mips.c +++ b/arch/mips/kvm/kvm_mips.c @@ -388,6 +388,7 @@ void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu) kfree(vcpu->arch.guest_ebase); kfree(vcpu->arch.kseg0_commpage); + kfree(vcpu); } void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu) -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 040/170] powerpc/mm: Check paca psize is up to date for huge mappings
From: Michael Ellerman
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 09567e7fd44291bfc08accfdd67ad8f467842332 upstream.
We have a bug in our hugepage handling which exhibits as an infinite
loop of hash faults. If the fault is being taken in the kernel it will
typically trigger the softlockup detector, or the RCU stall detector.
The bug is as follows:
1. mmap(0xa000, ..., MAP_FIXED | MAP_HUGE_TLB | MAP_ANONYMOUS ..)
2. Slice code converts the slice psize to 16M.
3. The code on lines 539-540 of slice.c in slice_get_unmapped_area()
synchronises the mm->context with the paca->context. So the paca slice
mask is updated to include the 16M slice.
3. Either:
* mmap() fails because there are no huge pages available.
* mmap() succeeds and the mapping is then munmapped.
In both cases the slice psize remains at 16M in both the paca & mm.
4. mmap(0xa000, ..., MAP_FIXED | MAP_ANONYMOUS ..)
5. The slice psize is converted back to 64K. Because of the check on line 539
of slice.c we DO NOT update the paca->context. The paca slice mask is now
out of sync with the mm slice mask.
6. User/kernel accesses 0xa000.
7. The SLB miss handler slb_allocate_realmode() **uses the paca slice mask**
to create an SLB entry and inserts it in the SLB.
18. With the 16M SLB entry in place the hardware does a hash lookup, no entry
is found so a data access exception is generated.
19. The data access handler calls do_page_fault() -> handle_mm_fault().
10. __handle_mm_fault() creates a THP mapping with do_huge_pmd_anonymous_page().
11. The hardware retries the access, there is still nothing in the hash table
so once again a data access exception is generated.
12. hash_page() calls into __hash_page_thp() and inserts a mapping in the
hash. Although the THP mapping maps 16M the hashing is done using 64K
as the segment page size.
13. hash_page() returns immediately after calling __hash_page_thp(), skipping
over the code at line 1125. Resulting in the mismatch between the
paca->context and mm->context not being detected.
14. The hardware retries the access, the hash it generates using the 16M
SLB entry does NOT match the hash we inserted.
15. We take another data access and go into __hash_page_thp().
16. We see a valid entry in the hpte_slot_array and so we call updatepp()
which succeeds.
17. Goto 14.
We could fix this in two ways. The first would be to remove or modify
the check on line 539 of slice.c.
The second option is to cause the check of paca psize in hash_page() on
line 1125 to also be done for THP pages.
We prefer the latter, because the check & update of the paca psize is
not done until we know it's necessary. It's also done only on the
current cpu, so we don't need to IPI all other cpus.
Without further rearranging the code, the simplest fix is to pull out
the code that checks paca psize and call it in two places. Firstly for
THP/hugetlb, and secondly for other mappings as before.
Thanks to Dave Jones for trinity, which originally found this bug.
Signed-off-by: Michael Ellerman
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Jiri Slaby
---
arch/powerpc/mm/hash_utils_64.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index bde8b5589755..503a5d005622 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -947,6 +947,22 @@ void hash_failure_debug(unsigned long ea, unsigned long
access,
trap, vsid, ssize, psize, lpsize, pte);
}
+static void check_paca_psize(unsigned long ea, struct mm_struct *mm,
+int psize, bool user_region)
+{
+ if (user_region) {
+ if (psize != get_paca_psize(ea)) {
+ get_paca()->context = mm->context;
+ slb_flush_and_rebolt();
+ }
+ } else if (get_paca()->vmalloc_sllp !=
+ mmu_psize_defs[mmu_vmalloc_psize].sllp) {
+ get_paca()->vmalloc_sllp =
+ mmu_psize_defs[mmu_vmalloc_psize].sllp;
+ slb_vmalloc_update();
+ }
+}
+
/* Result code is:
* 0 - handled
* 1 - normal page fault
@@ -1068,6 +1084,8 @@ int hash_page(unsigned long ea, unsigned long access,
unsigned long trap)
WARN_ON(1);
}
#endif
+ check_paca_psize(ea, mm, psize, user_region);
+
goto bail;
}
@@ -1108,17 +1126,8 @@ int hash_page(unsigned long ea, unsigned long access,
unsigned long trap)
#endif
}
}
- if (user_region) {
- if (psize != get_paca_psize(ea)) {
- get_paca()->context = mm->context;
- slb_flush_and_rebolt();
- }
- } else if
[PATCH 3.12 112/170] KVM: x86: preserve the high 32-bits of the PAT register
From: Paolo Bonzini
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 7cb060a91c0efc5ff94f83c6df3ed705e143cdb9 upstream.
KVM does not really do much with the PAT, so this went unnoticed for a
long time. It is exposed however if you try to do rdmsr on the PAT
register.
Reported-by: Valentine Sinitsyn
Signed-off-by: Paolo Bonzini
Signed-off-by: Jiri Slaby
---
arch/x86/include/asm/kvm_host.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 792206c8e555..694851592399 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -455,7 +455,7 @@ struct kvm_vcpu_arch {
bool nmi_injected;/* Trying to inject an NMI this entry */
struct mtrr_state_type mtrr_state;
- u32 pat;
+ u64 pat;
int switch_db_regs;
unsigned long db[KVM_NR_DB_REGS];
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 080/170] drm/radeon: fix typo in radeon_connector_is_dp12_capable()
From: Alex Deucher
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit af5d36539dfe043f1cf0f8b7334d6bb12cd14e75 upstream.
We were checking the ext clock rather than the display clock.
Noticed by ArtForz on IRC.
Signed-off-by: Alex Deucher
Signed-off-by: Jiri Slaby
---
drivers/gpu/drm/radeon/radeon_connectors.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 64565732cb98..fe90b3e28d88 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1360,7 +1360,7 @@ bool radeon_connector_is_dp12_capable(struct
drm_connector *connector)
struct radeon_device *rdev = dev->dev_private;
if (ASIC_IS_DCE5(rdev) &&
- (rdev->clock.dp_extclk >= 53900) &&
+ (rdev->clock.default_dispclk >= 53900) &&
radeon_connector_encoder_is_hbr2(connector)) {
return true;
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 036/170] NFS: Don't declare inode uptodate unless all attributes were checked
From: Trond Myklebust
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 43b6535e717d2f656f71d9bd16022136b781c934 upstream.
Fix a bug, whereby nfs_update_inode() was declaring the inode to be
up to date despite not having checked all the attributes.
The bug occurs because the temporary variable in which we cache
the validity information is 'sanitised' before reapplying to
nfsi->cache_validity.
Reported-by: Kinglong Mee
Signed-off-by: Trond Myklebust
Signed-off-by: Jiri Slaby
---
fs/nfs/inode.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index fdeeb28f287b..7f5799d098fd 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -1540,18 +1540,20 @@ static int nfs_update_inode(struct inode *inode, struct
nfs_fattr *fattr)
inode->i_version = fattr->change_attr;
}
} else if (server->caps & NFS_CAP_CHANGE_ATTR)
- invalid |= save_cache_validity;
+ nfsi->cache_validity |= save_cache_validity;
if (fattr->valid & NFS_ATTR_FATTR_MTIME) {
memcpy(>i_mtime, >mtime, sizeof(inode->i_mtime));
} else if (server->caps & NFS_CAP_MTIME)
- invalid |= save_cache_validity & (NFS_INO_INVALID_ATTR
+ nfsi->cache_validity |= save_cache_validity &
+ (NFS_INO_INVALID_ATTR
| NFS_INO_REVAL_FORCED);
if (fattr->valid & NFS_ATTR_FATTR_CTIME) {
memcpy(>i_ctime, >ctime, sizeof(inode->i_ctime));
} else if (server->caps & NFS_CAP_CTIME)
- invalid |= save_cache_validity & (NFS_INO_INVALID_ATTR
+ nfsi->cache_validity |= save_cache_validity &
+ (NFS_INO_INVALID_ATTR
| NFS_INO_REVAL_FORCED);
/* Check if our cached file size is stale */
@@ -1574,7 +1576,8 @@ static int nfs_update_inode(struct inode *inode, struct
nfs_fattr *fattr)
(long long)new_isize);
}
} else
- invalid |= save_cache_validity & (NFS_INO_INVALID_ATTR
+ nfsi->cache_validity |= save_cache_validity &
+ (NFS_INO_INVALID_ATTR
| NFS_INO_REVAL_PAGECACHE
| NFS_INO_REVAL_FORCED);
@@ -1582,7 +1585,8 @@ static int nfs_update_inode(struct inode *inode, struct
nfs_fattr *fattr)
if (fattr->valid & NFS_ATTR_FATTR_ATIME)
memcpy(>i_atime, >atime, sizeof(inode->i_atime));
else if (server->caps & NFS_CAP_ATIME)
- invalid |= save_cache_validity & (NFS_INO_INVALID_ATIME
+ nfsi->cache_validity |= save_cache_validity &
+ (NFS_INO_INVALID_ATIME
| NFS_INO_REVAL_FORCED);
if (fattr->valid & NFS_ATTR_FATTR_MODE) {
@@ -1593,7 +1597,8 @@ static int nfs_update_inode(struct inode *inode, struct
nfs_fattr *fattr)
invalid |=
NFS_INO_INVALID_ATTR|NFS_INO_INVALID_ACCESS|NFS_INO_INVALID_ACL;
}
} else if (server->caps & NFS_CAP_MODE)
- invalid |= save_cache_validity & (NFS_INO_INVALID_ATTR
+ nfsi->cache_validity |= save_cache_validity &
+ (NFS_INO_INVALID_ATTR
| NFS_INO_INVALID_ACCESS
| NFS_INO_INVALID_ACL
| NFS_INO_REVAL_FORCED);
@@ -1604,7 +1609,8 @@ static int nfs_update_inode(struct inode *inode, struct
nfs_fattr *fattr)
inode->i_uid = fattr->uid;
}
} else if (server->caps & NFS_CAP_OWNER)
- invalid |= save_cache_validity & (NFS_INO_INVALID_ATTR
+ nfsi->cache_validity |= save_cache_validity &
+ (NFS_INO_INVALID_ATTR
| NFS_INO_INVALID_ACCESS
| NFS_INO_INVALID_ACL
| NFS_INO_REVAL_FORCED);
@@ -1615,7 +1621,8 @@ static int nfs_update_inode(struct inode *inode, struct
nfs_fattr *fattr)
inode->i_gid = fattr->gid;
}
} else if (server->caps & NFS_CAP_OWNER_GROUP)
- invalid |= save_cache_validity & (NFS_INO_INVALID_ATTR
+ nfsi->cache_validity |= save_cache_validity &
+ (NFS_INO_INVALID_ATTR
| NFS_INO_INVALID_ACCESS
| NFS_INO_INVALID_ACL
| NFS_INO_REVAL_FORCED);
@@ -1628,7 +1635,8 @@ static int nfs_update_inode(struct inode *inode, struct
nfs_fattr *fattr)
set_nlink(inode, fattr->nlink);
}
} else if
Re: WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69 kmem_cache_create+0x1a9/0x330()
Slab warns, because the name of the cache being created contains spaces.
The "bad" cache is created by scsi_get_host_cmd_pool. Its name
(pool->cmd_name) is initialized by scsi_alloc_host_cmd_pool as follows:
pool->cmd_name = kasprintf(GFP_KERNEL, "%s_cmd", hostt->name);
So, if hostt->name contains spaces, the cache name will also contain
spaces and we'll get the warning. And hostt->name can contain spaces,
e.g. virtscsi_host_template_single.name="Virtio SCSI HBA".
The issue was introduced by commit 89d9a567952ba ("[SCSI] add support
for per-host cmd pools"). It can be fixed e.g. by substituting spaces
with underscores in cache names.
Adding the patch author and reviewers to Cc.
On Fri, Jul 18, 2014 at 12:57:25PM +0200, poma wrote:
>
> I guess someone working over the summertime. :)
>
> [ cut here ]
> WARNING: CPU: 1 PID: 495 at mm/slab_common.c:69
> kmem_cache_create+0x1a9/0x330()
> Modules linked in: virtio_net virtio_scsi(+) drm virtio_pci i2c_core
> virtio_ring ata_generic pata_acpi virtio sunrpc dm_crypt dm_round_robin
> linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor xor
> async_tx raid6_pq raid1 raid0 iscsi_ibft iscsi_boot_sysfs floppy iscsi_tcp
> libiscsi_tcp libiscsi scsi_transport_iscsi squashfs cramfs edd dm_multipath
> CPU: 1 PID: 495 Comm: systemd-udevd Not tainted
> 3.16.0-0.rc5.git0.1.fc21.x86_64 #1
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> bfd3b05a 88007f55fa40 8171b4e3
> 88007f55fa78 8108f30d 880079175d40
> 88007f55ffd8 81c6de08 88007f55ffd8 88007f55ffd8
> Call Trace:
> [] dump_stack+0x45/0x56
> [] warn_slowpath_common+0x7d/0xa0
> [] warn_slowpath_null+0x1a/0x20
> [] kmem_cache_create+0x1a9/0x330
> [] scsi_setup_command_freelist+0x120/0x270
> [] scsi_add_host_with_dma+0x60/0x2b0
> [] virtscsi_probe+0x269/0x2af [virtio_scsi]
> [] ? vp_reset+0x90/0x90 [virtio_pci]
> [] virtio_dev_probe+0xe9/0x160 [virtio]
> [] driver_probe_device+0xa3/0x400
> [] __driver_attach+0x8b/0x90
> [] ? __device_attach+0x40/0x40
> [] bus_for_each_dev+0x73/0xc0
> [] driver_attach+0x1e/0x20
> [] bus_add_driver+0x180/0x250
> [] ? 0xa017
> [] driver_register+0x64/0xf0
> [] register_virtio_driver+0x20/0x40 [virtio]
> [] init+0x85/0x1000 [virtio_scsi]
> [] do_one_initcall+0xd8/0x210
> [] ? __vunmap+0xa2/0x100
> [] load_module+0x2061/0x2600
> [] ? store_uevent+0x70/0x70
> [] SyS_init_module+0xcd/0x120
> [] system_call_fastpath+0x16/0x1b
> ---[ end trace 64d7cf025fd3bf4a ]---
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1121092
>
>
> poma
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 032/170] IB/umad: Fix use-after-free on close
From: Bart Van Assche
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 60e1751cb52cc6d1ae04b6bd3c2b96e770b5823f upstream.
Avoid that closing /dev/infiniband/umad or /dev/infiniband/issm
triggers a use-after-free. __fput() invokes f_op->release() before it
invokes cdev_put(). Make sure that the ib_umad_device structure is
freed by the cdev_put() call instead of f_op->release(). This avoids
that changing the port mode from IB into Ethernet and back to IB
followed by restarting opensmd triggers the following kernel oops:
general protection fault: [#1] PREEMPT SMP
RIP: 0010:[] [] module_put+0x2c/0x170
Call Trace:
[] cdev_put+0x20/0x30
[] __fput+0x1ae/0x1f0
[] fput+0xe/0x10
[] task_work_run+0xac/0xe0
[] do_notify_resume+0x9f/0xc0
[] int_signal+0x12/0x17
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=75051
Signed-off-by: Bart Van Assche
Reviewed-by: Yann Droneaud
Signed-off-by: Roland Dreier
Signed-off-by: Jiri Slaby
---
drivers/infiniband/core/user_mad.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/infiniband/core/user_mad.c
b/drivers/infiniband/core/user_mad.c
index 9bdf576cd4ab..1acb99100556 100644
--- a/drivers/infiniband/core/user_mad.c
+++ b/drivers/infiniband/core/user_mad.c
@@ -98,7 +98,7 @@ struct ib_umad_port {
struct ib_umad_device {
int start_port, end_port;
- struct kref ref;
+ struct kobject kobj;
struct ib_umad_port port[0];
};
@@ -134,14 +134,18 @@ static DECLARE_BITMAP(dev_map, IB_UMAD_MAX_PORTS);
static void ib_umad_add_one(struct ib_device *device);
static void ib_umad_remove_one(struct ib_device *device);
-static void ib_umad_release_dev(struct kref *ref)
+static void ib_umad_release_dev(struct kobject *kobj)
{
struct ib_umad_device *dev =
- container_of(ref, struct ib_umad_device, ref);
+ container_of(kobj, struct ib_umad_device, kobj);
kfree(dev);
}
+static struct kobj_type ib_umad_dev_ktype = {
+ .release = ib_umad_release_dev,
+};
+
static int hdr_size(struct ib_umad_file *file)
{
return file->use_pkey_index ? sizeof (struct ib_user_mad_hdr) :
@@ -812,7 +816,7 @@ static int ib_umad_open(struct inode *inode, struct file
*filp)
goto out;
}
- kref_get(>umad_dev->ref);
+ kobject_get(>umad_dev->kobj);
out:
mutex_unlock(>file_mutex);
@@ -851,7 +855,7 @@ static int ib_umad_close(struct inode *inode, struct file
*filp)
mutex_unlock(>port->file_mutex);
kfree(file);
- kref_put(>ref, ib_umad_release_dev);
+ kobject_put(>kobj);
return 0;
}
@@ -902,7 +906,7 @@ static int ib_umad_sm_open(struct inode *inode, struct file
*filp)
if (ret)
goto err_clr_sm_cap;
- kref_get(>umad_dev->ref);
+ kobject_get(>umad_dev->kobj);
return 0;
@@ -932,7 +936,7 @@ static int ib_umad_sm_close(struct inode *inode, struct
file *filp)
up(>sm_sem);
- kref_put(>umad_dev->ref, ib_umad_release_dev);
+ kobject_put(>umad_dev->kobj);
return ret;
}
@@ -1000,6 +1004,7 @@ static int find_overflow_devnum(void)
}
static int ib_umad_init_port(struct ib_device *device, int port_num,
+struct ib_umad_device *umad_dev,
struct ib_umad_port *port)
{
int devnum;
@@ -1032,6 +1037,7 @@ static int ib_umad_init_port(struct ib_device *device,
int port_num,
cdev_init(>cdev, _fops);
port->cdev.owner = THIS_MODULE;
+ port->cdev.kobj.parent = _dev->kobj;
kobject_set_name(>cdev.kobj, "umad%d", port->dev_num);
if (cdev_add(>cdev, base, 1))
goto err_cdev;
@@ -1050,6 +1056,7 @@ static int ib_umad_init_port(struct ib_device *device,
int port_num,
base += IB_UMAD_MAX_PORTS;
cdev_init(>sm_cdev, _sm_fops);
port->sm_cdev.owner = THIS_MODULE;
+ port->sm_cdev.kobj.parent = _dev->kobj;
kobject_set_name(>sm_cdev.kobj, "issm%d", port->dev_num);
if (cdev_add(>sm_cdev, base, 1))
goto err_sm_cdev;
@@ -1143,7 +1150,7 @@ static void ib_umad_add_one(struct ib_device *device)
if (!umad_dev)
return;
- kref_init(_dev->ref);
+ kobject_init(_dev->kobj, _umad_dev_ktype);
umad_dev->start_port = s;
umad_dev->end_port = e;
@@ -1151,7 +1158,8 @@ static void ib_umad_add_one(struct ib_device *device)
for (i = s; i <= e; ++i) {
umad_dev->port[i - s].umad_dev = umad_dev;
- if (ib_umad_init_port(device, i, _dev->port[i - s]))
+ if (ib_umad_init_port(device, i, umad_dev,
+ _dev->port[i - s]))
goto err;
}
@@ -1163,7 +1171,7 @@
[PATCH 3.12 107/170] CIFS: fix mount failure with broken pathnames when smb3 mount with mapchars option
From: Steve French
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit ce36d9ab3bab06b7b5522f5c8b68fac231b76ffb upstream.
When we SMB3 mounted with mapchars (to allow reserved characters : \ / > < * ?
via the Unicode Windows to POSIX remap range) empty paths
(eg when we open "" to query the root of the SMB3 directory on mount) were not
null terminated so we sent garbarge as a path name on empty paths which caused
SMB2/SMB2.1/SMB3 mounts to fail when mapchars was specified. mapchars is
particularly important since Unix Extensions for SMB3 are not supported (yet)
Signed-off-by: Steve French
Reviewed-by: David Disseldorp
Signed-off-by: Jiri Slaby
---
fs/cifs/cifs_unicode.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/cifs/cifs_unicode.c b/fs/cifs/cifs_unicode.c
index 0227b45ef00a..15e9505aa35f 100644
--- a/fs/cifs/cifs_unicode.c
+++ b/fs/cifs/cifs_unicode.c
@@ -290,7 +290,8 @@ int
cifsConvertToUTF16(__le16 *target, const char *source, int srclen,
const struct nls_table *cp, int mapChars)
{
- int i, j, charlen;
+ int i, charlen;
+ int j = 0;
char src_char;
__le16 dst_char;
wchar_t tmp;
@@ -298,12 +299,11 @@ cifsConvertToUTF16(__le16 *target, const char *source,
int srclen,
if (!mapChars)
return cifs_strtoUTF16(target, source, PATH_MAX, cp);
- for (i = 0, j = 0; i < srclen; j++) {
+ for (i = 0; i < srclen; j++) {
src_char = source[i];
charlen = 1;
switch (src_char) {
case 0:
- put_unaligned(0, [j]);
goto ctoUTF16_out;
case ':':
dst_char = cpu_to_le16(UNI_COLON);
@@ -350,6 +350,7 @@ cifsConvertToUTF16(__le16 *target, const char *source, int
srclen,
}
ctoUTF16_out:
+ put_unaligned(0, [j]); /* Null terminate target unicode string */
return j;
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqchip: gic: Fix core ID calculation when topology is read from DT
On Thu, Jul 17, 2014 at 05:23:44PM +0200, Tomasz Figa wrote: > Certain GIC implementation, namely those found on earlier, single > cluster, Exynos SoCs, have registers mapped without per-CPU banking, > which means that the driver needs to use different offset for each CPU. > > Currently the driver calculates the offset by multiplying value returned > by cpu_logical_map() by CPU offset parsed from DT. This is correct when > CPU topology is not specified in DT and aforementioned function returns > core ID alone. However when DT contains CPU topology, the function > changes to return cluster ID as well, which is non-zero on mentioned > SoCs and so breaks the calculation in GIC driver. > > This patch fixes this by masking out cluster ID in CPU offset > calculation so that only core ID is considered. Multi-cluster Exynos > SoCs already have banked GIC implementations, so this simple fix should > be enough. > > Reported-by: Lorenzo Pieralisi > Reported-by: Bartlomiej Zolnierkiewicz > Signed-off-by: Tomasz Figa > --- > drivers/irqchip/irq-gic.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c > index ddee133..5c15a09 100644 > --- a/drivers/irqchip/irq-gic.c > +++ b/drivers/irqchip/irq-gic.c > @@ -40,6 +40,7 @@ > #include > #include Applied to irqchip/urgent and Cc'd to stable for v3.3+ thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 067/170] usb: option: add/modify Olivetti Olicard modems
From: Bjørn Mork
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit b0ebef36e93703e59003ad6a1a20227e47714417 upstream.
Adding a couple of Olivetti modems and blacklisting the net
function on a couple which are already supported.
Reported-by: Lars Melin
Signed-off-by: Bjørn Mork
Signed-off-by: Johan Hovold
Signed-off-by: Jiri Slaby
---
drivers/usb/serial/option.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 909bb77544b5..e25e8ca09fe2 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -375,8 +375,12 @@ static void option_instat_callback(struct urb *urb);
/* Olivetti products */
#define OLIVETTI_VENDOR_ID 0x0b3c
#define OLIVETTI_PRODUCT_OLICARD1000xc000
+#define OLIVETTI_PRODUCT_OLICARD1200xc001
+#define OLIVETTI_PRODUCT_OLICARD1400xc002
#define OLIVETTI_PRODUCT_OLICARD1450xc003
+#define OLIVETTI_PRODUCT_OLICARD1550xc004
#define OLIVETTI_PRODUCT_OLICARD2000xc005
+#define OLIVETTI_PRODUCT_OLICARD1600xc00a
#define OLIVETTI_PRODUCT_OLICARD5000xc00b
/* Celot products */
@@ -1615,15 +1619,21 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(SIEMENS_VENDOR_ID, CINTERION_PRODUCT_HC25_MDMNET) },
{ USB_DEVICE(SIEMENS_VENDOR_ID, CINTERION_PRODUCT_HC28_MDM) }, /* HC28
enumerates with Siemens or Cinterion VID depending on FW revision */
{ USB_DEVICE(SIEMENS_VENDOR_ID, CINTERION_PRODUCT_HC28_MDMNET) },
-
- { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD100) },
+ { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD100),
+ .driver_info = (kernel_ulong_t)_intf4_blacklist },
+ { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD120),
+ .driver_info = (kernel_ulong_t)_intf4_blacklist },
+ { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD140),
+ .driver_info = (kernel_ulong_t)_intf4_blacklist },
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD145) },
+ { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD155),
+ .driver_info = (kernel_ulong_t)_intf6_blacklist },
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD200),
- .driver_info = (kernel_ulong_t)_intf6_blacklist
- },
+ .driver_info = (kernel_ulong_t)_intf6_blacklist },
+ { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD160),
+ .driver_info = (kernel_ulong_t)_intf6_blacklist },
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD500),
- .driver_info = (kernel_ulong_t)_intf4_blacklist
- },
+ .driver_info = (kernel_ulong_t)_intf4_blacklist },
{ USB_DEVICE(CELOT_VENDOR_ID, CELOT_PRODUCT_CT680M) }, /* CT-650 CDMA
450 1xEVDO modem */
{ USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID,
SAMSUNG_PRODUCT_GT_B3730, USB_CLASS_CDC_DATA, 0x00, 0x00) }, /* Samsung
GT-B3730 LTE USB modem.*/
{ USB_DEVICE(YUGA_VENDOR_ID, YUGA_PRODUCT_CEM600) },
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 024/170] watchdog: ath79_wdt: avoid spurious restarts on AR934x
From: Gabor Juhos
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 23afeb613ec0e10aecfae7838a14d485db62ac52 upstream.
On some AR934x based systems, where the frequency of
the AHB bus is relatively high, the built-in watchdog
causes a spurious restart when it gets enabled.
The possible cause of these restarts is that the timeout
value written into the TIMER register does not reaches
the hardware in time.
Add an explicit delay into the ath79_wdt_enable function
to avoid the spurious restarts.
Signed-off-by: Gabor Juhos
Reviewed-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
Signed-off-by: Jiri Slaby
---
drivers/watchdog/ath79_wdt.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/watchdog/ath79_wdt.c b/drivers/watchdog/ath79_wdt.c
index 37cb09b27b63..c97a47ca8971 100644
--- a/drivers/watchdog/ath79_wdt.c
+++ b/drivers/watchdog/ath79_wdt.c
@@ -20,6 +20,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include
+#include
#include
#include
#include
@@ -91,6 +92,15 @@ static inline void ath79_wdt_keepalive(void)
static inline void ath79_wdt_enable(void)
{
ath79_wdt_keepalive();
+
+ /*
+* Updating the TIMER register requires a few microseconds
+* on the AR934x SoCs at least. Use a small delay to ensure
+* that the TIMER register is updated within the hardware
+* before enabling the watchdog.
+*/
+ udelay(2);
+
ath79_wdt_wr(WDOG_REG_CTRL, WDOG_CTRL_ACTION_FCR);
/* flush write */
ath79_wdt_rr(WDOG_REG_CTRL);
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 096/170] mac80211: fix IBSS join by initializing last_scan_completed
From: Krzysztof Hałasa 3.12-stable review patch. If anyone has any objections, please let me know. === commit c7d37a66e345df2fdf1aa7b2c9a6d3d53846ca5b upstream. Without this fix, freshly rebooted Linux creates a new IBSS instead of joining an existing one. Only when jiffies counter overflows after 5 minutes the IBSS can be successfully joined. Signed-off-by: Krzysztof Hałasa [edit commit message slightly] Signed-off-by: Johannes Berg Signed-off-by: Jiri Slaby --- net/mac80211/ibss.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c index a12afe77bb26..f69cac4bf39f 100644 --- a/net/mac80211/ibss.c +++ b/net/mac80211/ibss.c @@ -1203,6 +1203,7 @@ int ieee80211_ibss_join(struct ieee80211_sub_if_data *sdata, sdata->u.ibss.privacy = params->privacy; sdata->u.ibss.control_port = params->control_port; sdata->u.ibss.basic_rates = params->basic_rates; + sdata->u.ibss.last_scan_completed = jiffies; /* fix basic_rates if channel does not support these rates */ rate_flags = ieee80211_chandef_rate_flags(>chandef); -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 145/170] powerpc/perf: Never program book3s PMCs with values >= 0x80000000
From: Anton Blanchard
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit f56029410a13cae3652d1f34788045c40a13ffc7 upstream.
We are seeing a lot of PMU warnings on POWER8:
Can't find PMC that caused IRQ
Looking closer, the active PMC is 0 at this point and we took a PMU
exception on the transition from negative to 0. Some versions of POWER8
have an issue where they edge detect and not level detect PMC overflows.
A number of places program the PMC with (0x8000 - period_left),
where period_left can be negative. We can either fix all of these or
just ensure that period_left is always >= 1.
This patch takes the second option.
Signed-off-by: Anton Blanchard
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Jiri Slaby
---
arch/powerpc/perf/core-book3s.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 29b89e863d7c..023f5adf27b8 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -851,7 +851,22 @@ static void power_pmu_read(struct perf_event *event)
} while (local64_cmpxchg(>hw.prev_count, prev, val) != prev);
local64_add(delta, >count);
- local64_sub(delta, >hw.period_left);
+
+ /*
+* A number of places program the PMC with (0x8000 - period_left).
+* We never want period_left to be less than 1 because we will program
+* the PMC with a value >= 0x8 and an edge detected PMC will
+* roll around to 0 before taking an exception. We have seen this
+* on POWER8.
+*
+* To fix this, clamp the minimum value of period_left to 1.
+*/
+ do {
+ prev = local64_read(>hw.period_left);
+ val = prev - delta;
+ if (val < 1)
+ val = 1;
+ } while (local64_cmpxchg(>hw.period_left, prev, val) != prev);
}
/*
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 033/170] SUNRPC: Fix a module reference leak in svc_handle_xprt
From: Trond Myklebust
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit c789102c20bbbdda6831a273e046715be9d6af79 upstream.
If the accept() call fails, we need to put the module reference.
Signed-off-by: Trond Myklebust
Signed-off-by: J. Bruce Fields
Signed-off-by: Jiri Slaby
---
net/sunrpc/svc_xprt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
index 80a6640f329b..b9aad4723a9d 100644
--- a/net/sunrpc/svc_xprt.c
+++ b/net/sunrpc/svc_xprt.c
@@ -730,6 +730,8 @@ static int svc_handle_xprt(struct svc_rqst *rqstp, struct
svc_xprt *xprt)
newxpt = xprt->xpt_ops->xpo_accept(xprt);
if (newxpt)
svc_add_new_temp_xprt(serv, newxpt);
+ else
+ module_put(xprt->xpt_class->xcl_owner);
} else if (xprt->xpt_ops->xpo_has_wspace(xprt)) {
/* XPT_DATA|XPT_DEFERRED case: */
dprintk("svc: server %p, pool %u, transport %p, inuse=%d\n",
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 070/170] usb: musb: Fix panic upon musb_am335x module removal
From: Ezequiel Garcia 3.12-stable review patch. If anyone has any objections, please let me know. === commit 7adb5c876e9c0677078a1e1094c6eafd29c30b74 upstream. At probe time, the musb_am335x driver register its childs by calling of_platform_populate(), which registers all childs in the devicetree hierarchy recursively. On the other side, the driver's remove() function uses of_device_unregister() to remove each child of musb_am335x's. However, when musb_dsps is loaded, its devices are attached to the musb_am335x device as musb_am335x childs. Hence, musb_am335x remove() will attempt to unregister the devices registered by musb_dsps, which produces a kernel panic. In other words, the childs in the "struct device" hierarchy are not the same as the childs in the "devicetree" hierarchy. Ideally, we should enforce the removal of the devices registered by musb_am335x *only*, instead of all its child devices. However, because of the recursive nature of of_platform_populate, this doesn't seem possible. Therefore, as the only solution at hand, this commit disables musb_am335x driver removal capability, preventing it from being ever removed. This was originally suggested by Sebastian Siewior: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg104946.html And for reference, here's the panic upon module removal: musb-hdrc musb-hdrc.0.auto: remove, state 4 usb usb1: USB disconnect, device number 1 musb-hdrc musb-hdrc.0.auto: USB bus 1 deregistered Unable to handle kernel NULL pointer dereference at virtual address 008c pgd = de11c000 [008c] *pgd=9e174831, *pte=, *ppte= Internal error: Oops: 17 [#1] ARM Modules linked in: musb_am335x(-) musb_dsps musb_hdrc usbcore usb_common CPU: 0 PID: 623 Comm: modprobe Not tainted 3.15.0-rc4-1-g24efd13 #69 task: de1b7500 ti: de122000 task.ti: de122000 PC is at am335x_shutdown+0x10/0x28 LR is at am335x_shutdown+0xc/0x28 pc : []lr : []psr: a013 sp : de123df8 ip : 0004 fp : 00028f00 r10: r9 : de122000 r8 : c000e6c4 r7 : de0e3c10 r6 : de0e3800 r5 : de624010 r4 : de1ec750 r3 : de0e3810 r2 : r1 : 0001 r0 : Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 9e11c019 DAC: 0015 Process modprobe (pid: 623, stack limit = 0xde122240) Stack: (0xde123df8 to 0xde124000) 3de0: de0e3810 bf054488 3e00: bf05444c de624010 6013 bf043650 12fc de624010 de0e3810 bf043a20 3e20: de0e3810 bf04b240 c0635b88 c02ca37c c02ca364 c02c8db0 de1b7500 de0e3844 3e40: de0e3810 c02c8e28 c0635b88 de02824c de0e3810 c02c884c de0e3800 de0e3810 3e60: de0e3818 c02c5b20 bf05417c de0e3800 de0e3800 c0635b88 de0f2410 c02ca838 3e80: bf05417c de0e3800 bf055438 c02ca8cc de0e3c10 bf054194 de0e3c10 c02ca37c 3ea0: c02ca364 c02c8db0 de1b7500 de0e3c44 de0e3c10 c02c8e28 c0635b88 de02824c 3ec0: de0e3c10 c02c884c de0e3c10 de0e3c10 de0e3c18 c02c5b20 de0e3c10 de0e3c10 3ee0: bf059000 a013 c02c5bc0 bf05900c de0e3c10 c02c5c48 3f00: de0dd0c0 de1ec970 de0f2410 bf05929c de0f2444 bf05902c de0f2410 c02ca37c 3f20: c02ca364 c02c8db0 bf05929c de0f2410 bf05929c c02c94c8 bf05929c 3f40: 0800 c02c8ab4 bf0592e0 c007fc40 c00dd820 6273756d 336d615f 00783533 3f60: c064a0ac de1b7500 de122000 de1b7500 c000e590 0001 c000e6c4 c0060160 3f80: 00028e70 00028e70 00028ea4 0081 6010 00028e70 00028e70 00028ea4 3fa0: 0081 c000e500 00028e70 00028e70 00028ea4 0800 becb59f8 00027608 3fc0: 00028e70 00028e70 00028ea4 0081 0001 0001 00028f00 3fe0: b6e6b6f0 becb59d4 000160e8 b6e6b6fc 6010 00028ea4 [] (am335x_shutdown) from [] (dsps_musb_exit+0x3c/0x4c [musb_dsps]) [] (dsps_musb_exit [musb_dsps]) from [] (musb_shutdown+0x80/0x90 [musb_hdrc]) [] (musb_shutdown [musb_hdrc]) from [] (musb_remove+0x24/0x68 [musb_hdrc]) [] (musb_remove [musb_hdrc]) from [] (platform_drv_remove+0x18/0x1c) [] (platform_drv_remove) from [] (__device_release_driver+0x70/0xc8) [] (__device_release_driver) from [] (device_release_driver+0x20/0x2c) [] (device_release_driver) from [] (bus_remove_device+0xdc/0x10c) [] (bus_remove_device) from [] (device_del+0x104/0x198) [] (device_del) from [] (platform_device_del+0x14/0x9c) [] (platform_device_del) from [] (platform_device_unregister+0xc/0x20) [] (platform_device_unregister) from [] (dsps_remove+0x18/0x38 [musb_dsps]) [] (dsps_remove [musb_dsps]) from [] (platform_drv_remove+0x18/0x1c) [] (platform_drv_remove) from [] (__device_release_driver+0x70/0xc8) [] (__device_release_driver) from [] (device_release_driver+0x20/0x2c) [] (device_release_driver) from [] (bus_remove_device+0xdc/0x10c) [] (bus_remove_device) from [] (device_del+0x104/0x198) [] (device_del) from [] (device_unregister+0xc/0x20) [] (device_unregister) from [] (of_remove_populated_child+0xc/0x14 [musb_am335x]) [] (of_remove_populated_child [musb_am335x]) from []
[PATCH 3.12 078/170] vgaswitcheroo: switch the mux to the igp on power down when runpm is enabled
From: Alex Deucher 3.12-stable review patch. If anyone has any objections, please let me know. === commit f2bc561610962693be61425cf913778586d8f9c1 upstream. Avoids blank screens on muxed systems when runpm is active. bug: https://bugs.freedesktop.org/show_bug.cgi?id=75917 Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby --- drivers/gpu/vga/vga_switcheroo.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c index ec0ae2d1686a..6866448083b2 100644 --- a/drivers/gpu/vga/vga_switcheroo.c +++ b/drivers/gpu/vga/vga_switcheroo.c @@ -623,7 +623,8 @@ static int vga_switcheroo_runtime_suspend(struct device *dev) ret = dev->bus->pm->runtime_suspend(dev); if (ret) return ret; - + if (vgasr_priv.handler->switchto) + vgasr_priv.handler->switchto(VGA_SWITCHEROO_IGD); vga_switcheroo_power_switch(pdev, VGA_SWITCHEROO_OFF); return 0; } -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 169/170] x86, ioremap: Speed up check for RAM pages
From: Roland Dreier
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit c81c8a1eeede61e92a15103748c23d100880cc8a upstream.
In __ioremap_caller() (the guts of ioremap), we loop over the range of
pfns being remapped and checks each one individually with page_is_ram().
For large ioremaps, this can be very slow. For example, we have a
device with a 256 GiB PCI BAR, and ioremapping this BAR can take 20+
seconds -- sometimes long enough to trigger the soft lockup detector!
Internally, page_is_ram() calls walk_system_ram_range() on a single
page. Instead, we can make a single call to walk_system_ram_range()
from __ioremap_caller(), and do our further checks only for any RAM
pages that we find. For the common case of MMIO, this saves an enormous
amount of work, since the range being ioremapped doesn't intersect
system RAM at all.
With this change, ioremap on our 256 GiB BAR takes less than 1 second.
Signed-off-by: Roland Dreier
Link:
http://lkml.kernel.org/r/1399054721-1331-1-git-send-email-rol...@kernel.org
Signed-off-by: H. Peter Anvin
Signed-off-by: Jiri Slaby
---
arch/x86/mm/ioremap.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 799580cabc78..94bd24771812 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -50,6 +50,21 @@ int ioremap_change_attr(unsigned long vaddr, unsigned long
size,
return err;
}
+static int __ioremap_check_ram(unsigned long start_pfn, unsigned long nr_pages,
+ void *arg)
+{
+ unsigned long i;
+
+ for (i = 0; i < nr_pages; ++i)
+ if (pfn_valid(start_pfn + i) &&
+ !PageReserved(pfn_to_page(start_pfn + i)))
+ return 1;
+
+ WARN_ONCE(1, "ioremap on RAM pfn 0x%lx\n", start_pfn);
+
+ return 0;
+}
+
/*
* Remap an arbitrary physical address space into the kernel virtual
* address space. Needed when the kernel wants to access high addresses
@@ -93,14 +108,11 @@ static void __iomem *__ioremap_caller(resource_size_t
phys_addr,
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
+ pfn = phys_addr >> PAGE_SHIFT;
last_pfn = last_addr >> PAGE_SHIFT;
- for (pfn = phys_addr >> PAGE_SHIFT; pfn <= last_pfn; pfn++) {
- int is_ram = page_is_ram(pfn);
-
- if (is_ram && pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn)))
- return NULL;
- WARN_ON_ONCE(is_ram);
- }
+ if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
+ __ioremap_check_ram) == 1)
+ return NULL;
/*
* Mappings have to be page-aligned
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 128/170] USB: cp210x: add support for Corsair usb dongle
From: Andras Kovacs
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit b9326057a3d8447f5d2e74a7b521ccf21add2ec0 upstream.
Corsair USB Dongles are shipped with Corsair AXi series PSUs.
These are cp210x serial usb devices, so make driver detect these.
I have a program, that can get information from these PSUs.
Tested with 2 different dongles shipped with Corsair AX860i and
AX1200i units.
Signed-off-by: Andras Kovacs
Signed-off-by: Johan Hovold
Signed-off-by: Jiri Slaby
---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 71873cafb9d3..1db213a6e843 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -153,6 +153,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */
{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
{ USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */
+ { USB_DEVICE(0x1B1C, 0x1C00) }, /* Corsair USB Dongle */
{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
{ USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */
{ USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 029/170] IB/ipath: Translate legacy diagpkt into newer extended diagpkt
From: Dennis Dalessandro
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 7e6d3e5c70f13874fb06e6b67696ed90ce79bd48 upstream.
This patch addresses an issue where the legacy diagpacket is sent in
from the user, but the driver operates on only the extended
diagpkt. This patch specifically initializes the extended diagpkt
based on the legacy packet.
Reported-by: Rickard Strandqvist
Reviewed-by: Mike Marciniszyn
Signed-off-by: Dennis Dalessandro
Signed-off-by: Roland Dreier
Signed-off-by: Jiri Slaby
---
drivers/infiniband/hw/ipath/ipath_diag.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/infiniband/hw/ipath/ipath_diag.c
b/drivers/infiniband/hw/ipath/ipath_diag.c
index e2f9a51f4a38..45802e97332e 100644
--- a/drivers/infiniband/hw/ipath/ipath_diag.c
+++ b/drivers/infiniband/hw/ipath/ipath_diag.c
@@ -346,6 +346,10 @@ static ssize_t ipath_diagpkt_write(struct file *fp,
ret = -EFAULT;
goto bail;
}
+ dp.len = odp.len;
+ dp.unit = odp.unit;
+ dp.data = odp.data;
+ dp.pbc_wd = 0;
} else {
ret = -EINVAL;
goto bail;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 125/170] sym53c8xx_2: Set DID_REQUEUE return code when aborting squeue
From: Mikulas Patocka
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit fd1232b214af43a973443aec6a2808f16ee5bf70 upstream.
This patch fixes I/O errors with the sym53c8xx_2 driver when the disk
returns QUEUE FULL status.
When the controller encounters an error (including QUEUE FULL or BUSY
status), it aborts all not yet submitted requests in the function
sym_dequeue_from_squeue.
This function aborts them with DID_SOFT_ERROR.
If the disk has full tag queue, the request that caused the overflow is
aborted with QUEUE FULL status (and the scsi midlayer properly retries
it until it is accepted by the disk), but the sym53c8xx_2 driver aborts
the following requests with DID_SOFT_ERROR --- for them, the midlayer
does just a few retries and then signals the error up to sd.
The result is that disk returning QUEUE FULL causes request failures.
The error was reproduced on 53c895 with COMPAQ BD03685A24 disk
(rebranded ST336607LC) with command queue 48 or 64 tags. The disk has
64 tags, but under some access patterns it return QUEUE FULL when there
are less than 64 pending tags. The SCSI specification allows returning
QUEUE FULL anytime and it is up to the host to retry.
Signed-off-by: Mikulas Patocka
Cc: Matthew Wilcox
Cc: James Bottomley
Signed-off-by: Linus Torvalds
Signed-off-by: Jiri Slaby
---
drivers/scsi/sym53c8xx_2/sym_hipd.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/scsi/sym53c8xx_2/sym_hipd.c
b/drivers/scsi/sym53c8xx_2/sym_hipd.c
index d92fe4037e94..6b349e301869 100644
--- a/drivers/scsi/sym53c8xx_2/sym_hipd.c
+++ b/drivers/scsi/sym53c8xx_2/sym_hipd.c
@@ -3000,7 +3000,11 @@ sym_dequeue_from_squeue(struct sym_hcb *np, int i, int
target, int lun, int task
if ((target == -1 || cp->target == target) &&
(lun== -1 || cp->lun== lun)&&
(task == -1 || cp->tag== task)) {
+#ifdef SYM_OPT_HANDLE_DEVICE_QUEUEING
sym_set_cam_status(cp->cmd, DID_SOFT_ERROR);
+#else
+ sym_set_cam_status(cp->cmd, DID_REQUEUE);
+#endif
sym_remque(>link_ccbq);
sym_insque_tail(>link_ccbq, >comp_ccbq);
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 144/170] ACPI / EC: Fix race condition in ec_transaction_completed()
From: Lv Zheng
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit c0d653412fc8450370167a3268b78fc772ff9c87 upstream.
There is a race condition in ec_transaction_completed().
When ec_transaction_completed() is called in the GPE handler, it could
return true because of (ec->curr == NULL). Then the wake_up() invocation
could complete the next command unexpectedly since there is no lock between
the 2 invocations. With the previous cleanup, the IBF=0 waiter race need
not be handled any more. It's now safe to return a flag from
advance_condition() to indicate the requirement of wakeup, the flag is
returned from a locked context.
The ec_transaction_completed() is now only invoked by the ec_poll() where
the ec->curr is ensured to be different from NULL.
After cleaning up, the EVT_SCI=1 check should be moved out of the wakeup
condition so that an EVT_SCI raised with (ec->curr == NULL) can trigger a
QR_SC command.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams
Reported-and-tested-by: Hans de Goede
Reported-by: Barton Xu
Tested-by: Steffen Weber
Tested-by: Arthur Chen
Signed-off-by: Lv Zheng
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jiri Slaby
---
drivers/acpi/ec.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 7b52a724a0dd..7171d52e12ca 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -165,16 +165,17 @@ static int ec_transaction_completed(struct acpi_ec *ec)
unsigned long flags;
int ret = 0;
spin_lock_irqsave(>lock, flags);
- if (!ec->curr || (ec->curr->flags & ACPI_EC_COMMAND_COMPLETE))
+ if (ec->curr && (ec->curr->flags & ACPI_EC_COMMAND_COMPLETE))
ret = 1;
spin_unlock_irqrestore(>lock, flags);
return ret;
}
-static void advance_transaction(struct acpi_ec *ec)
+static bool advance_transaction(struct acpi_ec *ec)
{
struct transaction *t;
u8 status;
+ bool wakeup = false;
pr_debug("= %s =\n", in_interrupt() ? "IRQ" : "TASK");
status = acpi_ec_read_status(ec);
@@ -190,21 +191,25 @@ static void advance_transaction(struct acpi_ec *ec)
} else if (t->rlen > t->ri) {
if ((status & ACPI_EC_FLAG_OBF) == 1) {
t->rdata[t->ri++] = acpi_ec_read_data(ec);
- if (t->rlen == t->ri)
+ if (t->rlen == t->ri) {
t->flags |= ACPI_EC_COMMAND_COMPLETE;
+ wakeup = true;
+ }
} else
goto err;
} else if (t->wlen == t->wi &&
- (status & ACPI_EC_FLAG_IBF) == 0)
+ (status & ACPI_EC_FLAG_IBF) == 0) {
t->flags |= ACPI_EC_COMMAND_COMPLETE;
- return;
+ wakeup = true;
+ }
+ return wakeup;
} else {
if ((status & ACPI_EC_FLAG_IBF) == 0) {
acpi_ec_write_cmd(ec, t->command);
t->flags |= ACPI_EC_COMMAND_POLL;
} else
goto err;
- return;
+ return wakeup;
}
err:
/*
@@ -215,13 +220,14 @@ err:
if (in_interrupt() && t)
++t->irq_count;
}
+ return wakeup;
}
static void start_transaction(struct acpi_ec *ec)
{
ec->curr->irq_count = ec->curr->wi = ec->curr->ri = 0;
ec->curr->flags = 0;
- advance_transaction(ec);
+ (void)advance_transaction(ec);
}
static int acpi_ec_sync_query(struct acpi_ec *ec, u8 *data);
@@ -255,7 +261,7 @@ static int ec_poll(struct acpi_ec *ec)
return 0;
}
spin_lock_irqsave(>lock, flags);
- advance_transaction(ec);
+ (void)advance_transaction(ec);
spin_unlock_irqrestore(>lock, flags);
} while (time_before(jiffies, delay));
pr_debug(PREFIX "controller reset, restart transaction\n");
@@ -654,12 +660,10 @@ static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
struct acpi_ec *ec = data;
spin_lock_irqsave(>lock, flags);
- advance_transaction(ec);
- spin_unlock_irqrestore(>lock, flags);
- if (ec_transaction_completed(ec)) {
+ if (advance_transaction(ec))
wake_up(>wait);
- ec_check_sci(ec, acpi_ec_read_status(ec));
- }
+
[PATCH 3.12 149/170] crypto: sha512_ssse3 - fix byte count to bit count conversion
From: Jussi Kivilinna 3.12-stable review patch. If anyone has any objections, please let me know. === commit cfe82d4f45c7cc39332a2be7c4c1d3bf279bbd3d upstream. Byte-to-bit-count computation is only partly converted to big-endian and is mixing in CPU-endian values. Problem was noticed by sparce with warning: CHECK arch/x86/crypto/sha512_ssse3_glue.c arch/x86/crypto/sha512_ssse3_glue.c:144:19: warning: restricted __be64 degrades to integer arch/x86/crypto/sha512_ssse3_glue.c:144:17: warning: incorrect type in assignment (different base types) arch/x86/crypto/sha512_ssse3_glue.c:144:17:expected restricted __be64 arch/x86/crypto/sha512_ssse3_glue.c:144:17:got unsigned long long Signed-off-by: Jussi Kivilinna Acked-by: Tim Chen Signed-off-by: Herbert Xu Signed-off-by: Jiri Slaby --- arch/x86/crypto/sha512_ssse3_glue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/crypto/sha512_ssse3_glue.c b/arch/x86/crypto/sha512_ssse3_glue.c index f30cd10293f0..8626b03e83b7 100644 --- a/arch/x86/crypto/sha512_ssse3_glue.c +++ b/arch/x86/crypto/sha512_ssse3_glue.c @@ -141,7 +141,7 @@ static int sha512_ssse3_final(struct shash_desc *desc, u8 *out) /* save number of bits */ bits[1] = cpu_to_be64(sctx->count[0] << 3); - bits[0] = cpu_to_be64(sctx->count[1] << 3) | sctx->count[0] >> 61; + bits[0] = cpu_to_be64(sctx->count[1] << 3 | sctx->count[0] >> 61); /* Pad out to 112 mod 128 and append length */ index = sctx->count[0] & 0x7f; -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 141/170] ACPI / EC: Avoid race condition related to advance_transaction()
From: Lv Zheng
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 66b42b78bc1e816f92b662ec89195e4199e1 upstream.
The advance_transaction() will be invoked from the IRQ context GPE handler
and the task context ec_poll(). The handling of this function is locked so
that the EC state machine are ensured to be advanced sequentially.
But there is a problem. Before invoking advance_transaction(), EC_SC(R) is
read. Then for advance_transaction(), there could be race condition around
the lock from both contexts. The first one reading the register could fail
this race and when it passes the stale register value to the state machine
advancement code, the hardware condition is totally different from when
the register is read. And the hardware accesses determined from the wrong
hardware status can break the EC state machine. And there could be cases
that the functionalities of the platform firmware are seriously affected.
For example:
1. When 2 EC_DATA(W) writes compete the IBF=0, the 2nd EC_DATA(W) write may
be invalid due to IBF=1 after the 1st EC_DATA(W) write. Then the
hardware will either refuse to respond a next EC_SC(W) write of the next
command or discard the current WR_EC command when it receives a EC_SC(W)
write of the next command.
2. When 1 EC_SC(W) write and 1 EC_DATA(W) write compete the IBF=0, the
EC_DATA(W) write may be invalid due to IBF=1 after the EC_SC(W) write.
The next EC_DATA(R) could never be responded by the hardware. This is
the root cause of the reported issue.
Fix this issue by moving the EC_SC(R) access into the lock so that we can
ensure that the state machine is advanced consistently.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams
Reported-and-tested-by: Hans de Goede
Reported-by: Barton Xu
Tested-by: Steffen Weber
Tested-by: Arthur Chen
Signed-off-by: Lv Zheng
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jiri Slaby
---
drivers/acpi/ec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 51b700838f64..f8757316d309 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -175,12 +175,15 @@ static void start_transaction(struct acpi_ec *ec)
acpi_ec_write_cmd(ec, ec->curr->command);
}
-static void advance_transaction(struct acpi_ec *ec, u8 status)
+static void advance_transaction(struct acpi_ec *ec)
{
unsigned long flags;
struct transaction *t;
+ u8 status;
spin_lock_irqsave(>lock, flags);
+ pr_debug("= %s =\n", in_interrupt() ? "IRQ" : "TASK");
+ status = acpi_ec_read_status(ec);
t = ec->curr;
if (!t)
goto unlock;
@@ -243,7 +246,7 @@ static int ec_poll(struct acpi_ec *ec)
msecs_to_jiffies(1)))
return 0;
}
- advance_transaction(ec, acpi_ec_read_status(ec));
+ advance_transaction(ec);
} while (time_before(jiffies, delay));
pr_debug(PREFIX "controller reset, restart transaction\n");
spin_lock_irqsave(>lock, flags);
@@ -662,11 +665,8 @@ static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
u32 gpe_number, void *data)
{
struct acpi_ec *ec = data;
- u8 status = acpi_ec_read_status(ec);
-
- pr_debug(PREFIX "~~~> interrupt, status:0x%02x\n", status);
- advance_transaction(ec, status);
+ advance_transaction(ec);
if (ec_transaction_done(ec) &&
(acpi_ec_read_status(ec) & ACPI_EC_FLAG_IBF) == 0) {
wake_up(>wait);
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 139/170] hwmon: (adm1029) Ensure the fan_div cache is updated in set_fan_div
From: Axel Lin 3.12-stable review patch. If anyone has any objections, please let me know. === commit 1035a9e3e9c76b64a860a774f5b867d28d34acc2 upstream. Writing to fanX_div does not clear the cache. As a result, reading from fanX_div may return the old value for up to two seconds after writing a new value. This patch ensures the fan_div cache is updated in set_fan_div(). Reported-by: Guenter Roeck Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Jiri Slaby --- drivers/hwmon/adm1029.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/hwmon/adm1029.c b/drivers/hwmon/adm1029.c index 9ee5e066423b..39441e5d922c 100644 --- a/drivers/hwmon/adm1029.c +++ b/drivers/hwmon/adm1029.c @@ -232,6 +232,9 @@ static ssize_t set_fan_div(struct device *dev, /* Update the value */ reg = (reg & 0x3F) | (val << 6); + /* Update the cache */ + data->fan_div[attr->index] = reg; + /* Write value */ i2c_smbus_write_byte_data(client, ADM1029_REG_FAN_DIV[attr->index], reg); -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 003/170] netfilter: nf_nat: fix oops on netns removal
From: Florian Westphal
3.12-stable review patch. If anyone has any objections, please let me know.
===
[ Upstream commit 945b2b2d259d1a4364a2799e80e8ff32f8c6ee6f ]
Quoting Samu Kallio:
Basically what's happening is, during netns cleanup,
nf_nat_net_exit gets called before ipv4_net_exit. As I understand
it, nf_nat_net_exit is supposed to kill any conntrack entries which
have NAT context (through nf_ct_iterate_cleanup), but for some
reason this doesn't happen (perhaps something else is still holding
refs to those entries?).
When ipv4_net_exit is called, conntrack entries (including those
with NAT context) are cleaned up, but the
nat_bysource hashtable is long gone - freed in nf_nat_net_exit. The
bug happens when attempting to free a conntrack entry whose NAT hash
'prev' field points to a slot in the freed hash table (head for that
bin).
We ignore conntracks with null nat bindings. But this is wrong,
as these are in bysource hash table as well.
Restore nat-cleaning for the netns-is-being-removed case.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=65191
Cc: # 3.15.x
Cc: # 3.14.x
Cc: # 3.12.x
Cc: # 3.10.x
Fixes: c2d421e1718 ('netfilter: nf_nat: fix race when unloading protocol
modules')
Reported-by: Samu Kallio
Debugged-by: Samu Kallio
Signed-off-by: Florian Westphal
Tested-by: Samu Kallio
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Jiri Slaby
---
net/netfilter/nf_nat_core.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
index 6f0f4f7f68a5..13deb61737f8 100644
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -491,6 +491,39 @@ static int nf_nat_proto_remove(struct nf_conn *i, void
*data)
return i->status & IPS_NAT_MASK ? 1 : 0;
}
+static int nf_nat_proto_clean(struct nf_conn *ct, void *data)
+{
+ struct nf_conn_nat *nat = nfct_nat(ct);
+
+ if (nf_nat_proto_remove(ct, data))
+ return 1;
+
+ if (!nat || !nat->ct)
+ return 0;
+
+ /* This netns is being destroyed, and conntrack has nat null binding.
+* Remove it from bysource hash, as the table will be freed soon.
+*
+* Else, when the conntrack is destoyed, nf_nat_cleanup_conntrack()
+* will delete entry from already-freed table.
+*/
+ if (!del_timer(>timeout))
+ return 1;
+
+ spin_lock_bh(_nat_lock);
+ hlist_del_rcu(>bysource);
+ ct->status &= ~IPS_NAT_DONE_MASK;
+ nat->ct = NULL;
+ spin_unlock_bh(_nat_lock);
+
+ add_timer(>timeout);
+
+ /* don't delete conntrack. Although that would make things a lot
+* simpler, we'd end up flushing all conntracks on nat rmmod.
+*/
+ return 0;
+}
+
static void nf_nat_l4proto_clean(u8 l3proto, u8 l4proto)
{
struct nf_nat_proto_clean clean = {
@@ -753,7 +786,7 @@ static void __net_exit nf_nat_net_exit(struct net *net)
{
struct nf_nat_proto_clean clean = {};
- nf_ct_iterate_cleanup(net, _nat_proto_remove, , 0, 0);
+ nf_ct_iterate_cleanup(net, nf_nat_proto_clean, , 0, 0);
synchronize_rcu();
nf_ct_free_hashtable(net->ct.nat_bysource, net->ct.nat_htable_size);
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 065/170] xhci: Fix runtime suspended xhci from blocking system suspend.
From: "Wang, Yu"
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit d6236f6d1d885aa19d1cd7317346fe795227a3cc upstream.
The system suspend flow as following:
1, Freeze all user processes and kenrel threads.
2, Try to suspend all devices.
2.1, If pci device is in RPM suspended state, then pci driver will try
to resume it to RPM active state in the prepare stage.
2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two
workqueue items to resume usb2 roothub devices.
2.3, Call suspend callbacks of devices.
2.3.1, All suspend callbacks of all hcd's children, including
roothub devices are called.
2.3.2, Finally, hcd_pci_suspend callback is called.
Due to workqueue threads were already frozen in step 1, the workqueue
items can't be scheduled, and the roothub devices can't be resumed in
this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in
usb_hcd_resume_root_hub won't be cleared. Finally,
hcd_pci_suspend will return -EBUSY, and system suspend fails.
The reason why this issue doesn't show up very often is due to that
choose_wakeup will be called in step 2.3.1. In step 2.3.1, if
udev->do_remote_wakeup is not equal to device_may_wakeup(>dev), then
udev will resume to RPM active for changing the wakeup settings. This
has been a lucky hit which hides this issue.
For some special xHCI controllers which have no USB2 port, then roothub
will not match hub driver due to probe failed. Then its
do_remote_wakeup will be set to zero, and we won't be as lucky.
xhci driver doesn't need to resume roothub devices everytime like in
the above case. It's only needed when there are pending event TRBs.
This patch should be back-ported to kernels as old as 3.2, that
contains the commit f69e3120df82391a0ee8118e0a156239a06b2afb
"USB: XHCI: resume root hubs when the controller resumes"
Signed-off-by: Wang, Yu
Acked-by: Alan Stern
[use readl() instead of removed xhci_readl(), reword commit message -Mathias]
Signed-off-by: Mathias Nyman
Signed-off-by: Jiri Slaby
---
drivers/usb/host/xhci.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 01aa4c9fa558..e3d12f164430 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -926,7 +926,7 @@ int xhci_suspend(struct xhci_hcd *xhci)
*/
int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
{
- u32 command, temp = 0;
+ u32 command, temp = 0, status;
struct usb_hcd *hcd = xhci_to_hcd(xhci);
struct usb_hcd *secondary_hcd;
int retval = 0;
@@ -1045,8 +1045,12 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
done:
if (retval == 0) {
- usb_hcd_resume_root_hub(hcd);
- usb_hcd_resume_root_hub(xhci->shared_hcd);
+ /* Resume root hubs only when have pending events. */
+ status = readl(>op_regs->status);
+ if (status & STS_EINT) {
+ usb_hcd_resume_root_hub(hcd);
+ usb_hcd_resume_root_hub(xhci->shared_hcd);
+ }
}
/*
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 094/170] rbd: handle parent_overlap on writes correctly
From: Ilya Dryomov
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 9638556a276125553549fdfe349c464481ec2f39 upstream.
The following check in rbd_img_obj_request_submit()
rbd_dev->parent_overlap <= obj_request->img_offset
allows the fall through to the non-layered write case even if both
parent_overlap and obj_request->img_offset belong to the same RADOS
object. This leads to data corruption, because the area to the left of
parent_overlap ends up unconditionally zero-filled instead of being
populated with parent data. Suppose we want to write 1M to offset 6M
of image bar, which is a clone of foo@snap; object_size is 4M,
parent_overlap is 5M:
rbd_data..0001
-|--|
| should be copyup'ed | should be zeroed out | write ...
-|--|
4M5M 6M
parent_overlapobj_request->img_offset
4..5M should be copyup'ed from foo, yet it is zero-filled, just like
5..6M is.
Given that the only striping mode kernel client currently supports is
chunking (i.e. stripe_unit == object_size, stripe_count == 1), round
parent_overlap up to the next object boundary for the purposes of the
overlap check.
Signed-off-by: Ilya Dryomov
Reviewed-by: Josh Durgin
Signed-off-by: Jiri Slaby
---
drivers/block/rbd.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index af7b44ffd190..aeeb62e0981a 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -1379,6 +1379,14 @@ static bool obj_request_exists_test(struct
rbd_obj_request *obj_request)
return test_bit(OBJ_REQ_EXISTS, _request->flags) != 0;
}
+static bool obj_request_overlaps_parent(struct rbd_obj_request *obj_request)
+{
+ struct rbd_device *rbd_dev = obj_request->img_request->rbd_dev;
+
+ return obj_request->img_offset <
+ round_up(rbd_dev->parent_overlap, rbd_obj_bytes(_dev->header));
+}
+
static void rbd_obj_request_get(struct rbd_obj_request *obj_request)
{
dout("%s: obj %p (was %d)\n", __func__, obj_request,
@@ -2675,7 +2683,7 @@ static int rbd_img_obj_request_submit(struct
rbd_obj_request *obj_request)
*/
if (!img_request_write_test(img_request) ||
!img_request_layered_test(img_request) ||
- rbd_dev->parent_overlap <= obj_request->img_offset ||
+ !obj_request_overlaps_parent(obj_request) ||
((known = obj_request_known_test(obj_request)) &&
obj_request_exists_test(obj_request))) {
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 074/170] rt2x00: disable TKIP on USB
From: Stanislaw Gruszka 3.12-stable review patch. If anyone has any objections, please let me know. === commit 8edcb0ba0d56f5914eef11eda6db8bfe74eb9ca8 upstream. On USB we can not get atomically TKIP key. We have to disable support for TKIP acceleration on USB hardware to avoid bug as showed bellow. [ 860.827243] BUG: scheduling while atomic: hostapd/3397/0x0002 [ 860.827280] Call Trace: [ 860.827282] [] dump_stack+0x4d/0x66 [ 860.827284] [] __schedule_bug+0x47/0x55 [ 860.827285] [] __schedule+0x733/0x7b0 [ 860.827287] [] schedule+0x29/0x70 [ 860.827289] [] schedule_timeout+0x15a/0x2b0 [ 860.827291] [] ? ftrace_raw_event_tick_stop+0xc0/0xc0 [ 860.827294] [] ? __module_text_address+0x12/0x70 [ 860.827296] [] wait_for_completion_timeout+0xb3/0x140 [ 860.827298] [] ? wake_up_state+0x20/0x20 [ 860.827301] [] usb_start_wait_urb+0x7d/0x150 [ 860.827303] [] usb_control_msg+0xc5/0x110 [ 860.827305] [] rt2x00usb_vendor_request+0xc6/0x160 [rt2x00usb] [ 860.827307] [] rt2x00usb_vendor_req_buff_lock+0x75/0x150 [rt2x00usb] [ 860.827309] [] rt2x00usb_vendor_request_buff+0xa3/0xe0 [rt2x00usb] [ 860.827311] [] rt2x00usb_register_multiread+0x33/0x40 [rt2800usb] [ 860.827314] [] rt2800_get_tkip_seq+0x39/0x50 [rt2800lib] [ 860.827321] [] ieee80211_get_key+0x218/0x2a0 [mac80211] [ 860.827322] [] ? __nlmsg_put+0x6c/0x80 [ 860.827329] [] nl80211_get_key+0x22e/0x360 [cfg80211] Reported-and-tested-by: Peter Wu Reported-and-tested-by: Pontus Fuchs Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Jiri Slaby --- drivers/net/wireless/rt2x00/rt2x00mac.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/rt2x00/rt2x00mac.c b/drivers/net/wireless/rt2x00/rt2x00mac.c index 2b724fc4e306..c03748dafd49 100644 --- a/drivers/net/wireless/rt2x00/rt2x00mac.c +++ b/drivers/net/wireless/rt2x00/rt2x00mac.c @@ -489,6 +489,8 @@ int rt2x00mac_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd, crypto.cipher = rt2x00crypto_key_to_cipher(key); if (crypto.cipher == CIPHER_NONE) return -EOPNOTSUPP; + if (crypto.cipher == CIPHER_TKIP && rt2x00_is_usb(rt2x00dev)) + return -EOPNOTSUPP; crypto.cmd = cmd; -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 011/170] iscsi-target: fix iscsit_del_np deadlock on unload
From: Mikulas Patocka
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 81a9c5e72bdf7109a65102ca61d8cbd722cf4021 upstream.
On uniprocessor preemptible kernel, target core deadlocks on unload. The
following events happen:
* iscsit_del_np is called
* it calls send_sig(SIGINT, np->np_thread, 1);
* the scheduler switches to the np_thread
* the np_thread is woken up, it sees that kthread_should_stop() returns
false, so it doesn't terminate
* the np_thread clears signals with flush_signals(current); and goes back
to sleep in iscsit_accept_np
* the scheduler switches back to iscsit_del_np
* iscsit_del_np calls kthread_stop(np->np_thread);
* the np_thread is waiting in iscsit_accept_np and it doesn't respond to
kthread_stop
The deadlock could be resolved if the administrator sends SIGINT signal to
the np_thread with killall -INT iscsi_np
The reproducible deadlock was introduced in commit
db6077fd0b7dd41dc6ff18329cec979379071f87, but the thread-stopping code was
racy even before.
This patch fixes the problem. Using kthread_should_stop to stop the
np_thread is unreliable, so we test np_thread_state instead. If
np_thread_state equals ISCSI_NP_THREAD_SHUTDOWN, the thread exits.
Signed-off-by: Mikulas Patocka
Signed-off-by: Nicholas Bellinger
Signed-off-by: Jiri Slaby
---
drivers/target/iscsi/iscsi_target_login.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target_login.c
b/drivers/target/iscsi/iscsi_target_login.c
index f140a0eac985..8d44bec42e95 100644
--- a/drivers/target/iscsi/iscsi_target_login.c
+++ b/drivers/target/iscsi/iscsi_target_login.c
@@ -1198,7 +1198,7 @@ old_sess_out:
static int __iscsi_target_login_thread(struct iscsi_np *np)
{
u8 *buffer, zero_tsih = 0;
- int ret = 0, rc, stop;
+ int ret = 0, rc;
struct iscsi_conn *conn = NULL;
struct iscsi_login *login;
struct iscsi_portal_group *tpg = NULL;
@@ -1212,6 +1212,9 @@ static int __iscsi_target_login_thread(struct iscsi_np
*np)
if (np->np_thread_state == ISCSI_NP_THREAD_RESET) {
np->np_thread_state = ISCSI_NP_THREAD_ACTIVE;
complete(>np_restart_comp);
+ } else if (np->np_thread_state == ISCSI_NP_THREAD_SHUTDOWN) {
+ spin_unlock_bh(>np_thread_lock);
+ goto exit;
} else {
np->np_thread_state = ISCSI_NP_THREAD_ACTIVE;
}
@@ -1404,10 +1407,8 @@ old_sess_out:
}
out:
- stop = kthread_should_stop();
- /* Wait for another socket.. */
- if (!stop)
- return 1;
+ return 1;
+
exit:
iscsi_stop_login_thread_timer(np);
spin_lock_bh(>np_thread_lock);
@@ -1424,7 +1425,7 @@ int iscsi_target_login_thread(void *arg)
allow_signal(SIGINT);
- while (!kthread_should_stop()) {
+ while (1) {
ret = __iscsi_target_login_thread(np);
/*
* We break and exit here unless another sock_accept() call
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 069/170] usb: musb: Ensure that cppi41 timer gets armed on premature DMA TX irq
From: Thomas Gleixner
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit c58d80f523ffc15ef4d062fc7aeb03793fe39701 upstream.
Some TI chips raise the DMA complete interrupt before the actual
transfer has been completed. The code tries to busy wait for a few
microseconds and if that fails it arms an hrtimer to recheck. So far
so good, but that has the following issue:
CPU 0 CPU1
start_next_transfer(RQ1);
DMA interrupt
if (premature_irq(RQ1))
if (!hrtimer_active(timer))
hrtimer_start(timer);
hrtimer expires
timer->state = CALLBACK_RUNNING;
timer->fn()
cppi41_recheck_tx_req()
complete_request(RQ1);
if (requests_pending())
start_next_transfer(RQ2);
DMA interrupt
if (premature_irq(RQ2))
if (!hrtimer_active(timer))
hrtimer_start(timer);
timer->state = INACTIVE;
The premature interrupt of request2 on CPU1 does not arm the timer and
therefor the request completion never happens because it checks for
!hrtimer_active(). hrtimer_active() evaluates:
timer->state != HRTIMER_STATE_INACTIVE
which of course evaluates to true in the above case as timer->state is
CALLBACK_RUNNING.
That's clearly documented:
* A timer is active, when it is enqueued into the rbtree or the
* callback function is running or it's in the state of being migrated
* to another cpu.
But that's not what the code wants to check. The code wants to check
whether the timer is queued, i.e. whether its armed and waiting for
expiry.
We have a helper function for this: hrtimer_is_queued(). This
evaluates:
timer->state & HRTIMER_STATE_QUEUED
So in the above case this evaluates to false and therefor forces the
DMA interrupt on CPU1 to call hrtimer_start().
Use hrtimer_is_queued() instead of hrtimer_active() and evrything is
good.
Reported-by: Torben Hohn
Signed-off-by: Thomas Gleixner
Signed-off-by: Felipe Balbi
Signed-off-by: Jiri Slaby
---
drivers/usb/musb/musb_cppi41.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index 0c593afc3185..cc319305c022 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -266,7 +266,7 @@ static void cppi41_dma_callback(void *private_data)
}
list_add_tail(_channel->tx_check,
>early_tx_list);
- if (!hrtimer_active(>early_tx)) {
+ if (!hrtimer_is_queued(>early_tx)) {
hrtimer_start_range_ns(>early_tx,
ktime_set(0, 140 * NSEC_PER_USEC),
40 * NSEC_PER_USEC,
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 085/170] drm/radeon/dpm: fix vddci setup typo on cayman
From: Alex Deucher 3.12-stable review patch. If anyone has any objections, please let me know. === commit b0880e87c1fd038b84498944f52e52c3e86ebe59 upstream. We were using the vddc mask rather than the vddci mask. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=79071 May also fix: https://bugs.freedesktop.org/show_bug.cgi?id=69723 Noticed by: Dieter Nützel Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby --- drivers/gpu/drm/radeon/ni_dpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/ni_dpm.c b/drivers/gpu/drm/radeon/ni_dpm.c index db0fa617e2f5..85f36e702595 100644 --- a/drivers/gpu/drm/radeon/ni_dpm.c +++ b/drivers/gpu/drm/radeon/ni_dpm.c @@ -1319,7 +1319,7 @@ static void ni_populate_smc_voltage_tables(struct radeon_device *rdev, table->voltageMaskTable.highMask[NISLANDS_SMC_VOLTAGEMASK_VDDCI] = 0; table->voltageMaskTable.lowMask[NISLANDS_SMC_VOLTAGEMASK_VDDCI] = - cpu_to_be32(eg_pi->vddc_voltage_table.mask_low); + cpu_to_be32(eg_pi->vddci_voltage_table.mask_low); } } -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 134/170] workqueue: zero cpumask of wq_numa_possible_cpumask on init
From: Yasuaki Ishimatsu
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 5a6024f1604eef119cf3a6fa413fe0261a81a8f3 upstream.
When hot-adding and onlining CPU, kernel panic occurs, showing following
call trace.
BUG: unable to handle kernel paging request at 1d08
IP: [] __alloc_pages_nodemask+0x9d/0xb10
PGD 0
Oops: [#1] SMP
...
Call Trace:
[] ? cpumask_next_and+0x35/0x50
[] ? find_busiest_group+0x113/0x8f0
[] ? deactivate_slab+0x349/0x3c0
[] new_slab+0x91/0x300
[] __slab_alloc+0x2bb/0x482
[] ? copy_process.part.25+0xfc/0x14c0
[] ? load_balance+0x218/0x890
[] ? sched_clock+0x9/0x10
[] ? trace_clock_local+0x9/0x10
[] kmem_cache_alloc_node+0x8c/0x200
[] copy_process.part.25+0xfc/0x14c0
[] ? trace_buffer_unlock_commit+0x4d/0x60
[] ? kthread_create_on_node+0x140/0x140
[] do_fork+0xbc/0x360
[] kernel_thread+0x26/0x30
[] kthreadd+0x2c2/0x300
[] ? kthread_create_on_cpu+0x60/0x60
[] ret_from_fork+0x7c/0xb0
[] ? kthread_create_on_cpu+0x60/0x60
In my investigation, I found the root cause is wq_numa_possible_cpumask.
All entries of wq_numa_possible_cpumask is allocated by
alloc_cpumask_var_node(). And these entries are used without initializing.
So these entries have wrong value.
When hot-adding and onlining CPU, wq_update_unbound_numa() is called.
wq_update_unbound_numa() calls alloc_unbound_pwq(). And alloc_unbound_pwq()
calls get_unbound_pool(). In get_unbound_pool(), worker_pool->node is set
as follow:
3592 /* if cpumask is contained inside a NUMA node, we belong to that
node */
3593 if (wq_numa_enabled) {
3594 for_each_node(node) {
3595 if (cpumask_subset(pool->attrs->cpumask,
3596
wq_numa_possible_cpumask[node])) {
3597 pool->node = node;
3598 break;
3599 }
3600 }
3601 }
But wq_numa_possible_cpumask[node] does not have correct cpumask. So, wrong
node is selected. As a result, kernel panic occurs.
By this patch, all entries of wq_numa_possible_cpumask are allocated by
zalloc_cpumask_var_node to initialize them. And the panic disappeared.
Signed-off-by: Yasuaki Ishimatsu
Reviewed-by: Lai Jiangshan
Signed-off-by: Tejun Heo
Fixes: bce903809ab3 ("workqueue: add wq_numa_tbl_len and
wq_numa_possible_cpumask[]")
Signed-off-by: Jiri Slaby
---
kernel/workqueue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index e0b695893579..3fafbbb31927 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -5029,7 +5029,7 @@ static void __init wq_numa_init(void)
BUG_ON(!tbl);
for_each_node(node)
- BUG_ON(!alloc_cpumask_var_node([node], GFP_KERNEL,
+ BUG_ON(!zalloc_cpumask_var_node([node], GFP_KERNEL,
node_online(node) ? node : NUMA_NO_NODE));
for_each_possible_cpu(cpu) {
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 063/170] virtio-scsi: fix various bad behavior on aborted requests
From: Paolo Bonzini
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 8faeb529b2dabb9df691d614dda18910a43d05c9 upstream.
Even though the virtio-scsi spec guarantees that all requests related
to the TMF will have been completed by the time the TMF itself completes,
the request queue's callback might not have run yet. This causes requests
to be completed more than once, and as a result triggers a variety of
BUGs or oopses.
Signed-off-by: Paolo Bonzini
Reviewed-by: Venkatesh Srinivas
Signed-off-by: Christoph Hellwig
Signed-off-by: Jiri Slaby
---
drivers/scsi/virtio_scsi.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 57c39e1e6681..11f5326f449f 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -270,6 +270,16 @@ static void virtscsi_req_done(struct virtqueue *vq)
virtscsi_vq_done(vscsi, req_vq, virtscsi_complete_cmd);
};
+static void virtscsi_poll_requests(struct virtio_scsi *vscsi)
+{
+ int i, num_vqs;
+
+ num_vqs = vscsi->num_queues;
+ for (i = 0; i < num_vqs; i++)
+ virtscsi_vq_done(vscsi, >req_vqs[i],
+virtscsi_complete_cmd);
+}
+
static void virtscsi_complete_free(struct virtio_scsi *vscsi, void *buf)
{
struct virtio_scsi_cmd *cmd = buf;
@@ -604,6 +614,18 @@ static int virtscsi_tmf(struct virtio_scsi *vscsi, struct
virtio_scsi_cmd *cmd)
cmd->resp.tmf.response == VIRTIO_SCSI_S_FUNCTION_SUCCEEDED)
ret = SUCCESS;
+ /*
+* The spec guarantees that all requests related to the TMF have
+* been completed, but the callback might not have run yet if
+* we're using independent interrupts (e.g. MSI). Poll the
+* virtqueues once.
+*
+* In the abort case, sc->scsi_done will do nothing, because
+* the block layer must have detected a timeout and as a result
+* REQ_ATOM_COMPLETE has been set.
+*/
+ virtscsi_poll_requests(vscsi);
+
out:
mempool_free(cmd, virtscsi_cmd_pool);
return ret;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 079/170] drm/radeon: only apply hdmi bpc pll flags when encoder mode is hdmi
From: Alex Deucher
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 7d5ab3009a8ca777174f6f469277b3922d56fd4b upstream.
May fix display issues with non-HDMI displays.
Signed-off-by: Alex Deucher
Signed-off-by: Jiri Slaby
---
drivers/gpu/drm/radeon/atombios_crtc.c | 48 ++
1 file changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index dcb652a6f924..ba8742ab85ee 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -859,14 +859,16 @@ static void atombios_crtc_program_pll(struct drm_crtc
*crtc,
args.v5.ucMiscInfo = 0; /* HDMI depth, etc. */
if (ss_enabled && (ss->type & ATOM_EXTERNAL_SS_MASK))
args.v5.ucMiscInfo |=
PIXEL_CLOCK_V5_MISC_REF_DIV_SRC;
- switch (bpc) {
- case 8:
- default:
- args.v5.ucMiscInfo |=
PIXEL_CLOCK_V5_MISC_HDMI_24BPP;
- break;
- case 10:
- args.v5.ucMiscInfo |=
PIXEL_CLOCK_V5_MISC_HDMI_30BPP;
- break;
+ if (encoder_mode == ATOM_ENCODER_MODE_HDMI) {
+ switch (bpc) {
+ case 8:
+ default:
+ args.v5.ucMiscInfo |=
PIXEL_CLOCK_V5_MISC_HDMI_24BPP;
+ break;
+ case 10:
+ args.v5.ucMiscInfo |=
PIXEL_CLOCK_V5_MISC_HDMI_30BPP;
+ break;
+ }
}
args.v5.ucTransmitterID = encoder_id;
args.v5.ucEncoderMode = encoder_mode;
@@ -881,20 +883,22 @@ static void atombios_crtc_program_pll(struct drm_crtc
*crtc,
args.v6.ucMiscInfo = 0; /* HDMI depth, etc. */
if (ss_enabled && (ss->type & ATOM_EXTERNAL_SS_MASK))
args.v6.ucMiscInfo |=
PIXEL_CLOCK_V6_MISC_REF_DIV_SRC;
- switch (bpc) {
- case 8:
- default:
- args.v6.ucMiscInfo |=
PIXEL_CLOCK_V6_MISC_HDMI_24BPP;
- break;
- case 10:
- args.v6.ucMiscInfo |=
PIXEL_CLOCK_V6_MISC_HDMI_30BPP;
- break;
- case 12:
- args.v6.ucMiscInfo |=
PIXEL_CLOCK_V6_MISC_HDMI_36BPP;
- break;
- case 16:
- args.v6.ucMiscInfo |=
PIXEL_CLOCK_V6_MISC_HDMI_48BPP;
- break;
+ if (encoder_mode == ATOM_ENCODER_MODE_HDMI) {
+ switch (bpc) {
+ case 8:
+ default:
+ args.v6.ucMiscInfo |=
PIXEL_CLOCK_V6_MISC_HDMI_24BPP;
+ break;
+ case 10:
+ args.v6.ucMiscInfo |=
PIXEL_CLOCK_V6_MISC_HDMI_30BPP;
+ break;
+ case 12:
+ args.v6.ucMiscInfo |=
PIXEL_CLOCK_V6_MISC_HDMI_36BPP;
+ break;
+ case 16:
+ args.v6.ucMiscInfo |=
PIXEL_CLOCK_V6_MISC_HDMI_48BPP;
+ break;
+ }
}
args.v6.ucTransmitterID = encoder_id;
args.v6.ucEncoderMode = encoder_mode;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 006/170] rtmutex: Handle deadlock detection smarter
From: Thomas Gleixner
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 3d5c9340d1949733eb37616abd15db36aef9a57c upstream.
Even in the case when deadlock detection is not requested by the
caller, we can detect deadlocks. Right now the code stops the lock
chain walk and keeps the waiter enqueued, even on itself. Silly not to
yell when such a scenario is detected and to keep the waiter enqueued.
Return -EDEADLK unconditionally and handle it at the call sites.
The futex calls return -EDEADLK. The non futex ones dequeue the
waiter, throw a warning and put the task into a schedule loop.
Tagged for stable as it makes the code more robust.
Signed-off-by: Thomas Gleixner
Cc: Steven Rostedt
Cc: Peter Zijlstra
Cc: Brad Mouring
Link: http://lkml.kernel.org/r/20140605152801.836501...@linutronix.de
Signed-off-by: Thomas Gleixner
Signed-off-by: Mike Galbraith
Signed-off-by: Jiri Slaby
---
kernel/rtmutex-debug.h | 5 +
kernel/rtmutex.c | 33 -
kernel/rtmutex.h | 5 +
3 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/kernel/rtmutex-debug.h b/kernel/rtmutex-debug.h
index 14193d596d78..ab29b6a22669 100644
--- a/kernel/rtmutex-debug.h
+++ b/kernel/rtmutex-debug.h
@@ -31,3 +31,8 @@ static inline int debug_rt_mutex_detect_deadlock(struct
rt_mutex_waiter *waiter,
{
return (waiter != NULL);
}
+
+static inline void rt_mutex_print_deadlock(struct rt_mutex_waiter *w)
+{
+ debug_rt_mutex_print_deadlock(w);
+}
diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
index c343cc9702af..ff24a43f192f 100644
--- a/kernel/rtmutex.c
+++ b/kernel/rtmutex.c
@@ -205,7 +205,7 @@ static int rt_mutex_adjust_prio_chain(struct task_struct
*task,
}
put_task_struct(task);
- return deadlock_detect ? -EDEADLK : 0;
+ return -EDEADLK;
}
retry:
/*
@@ -280,7 +280,7 @@ static int rt_mutex_adjust_prio_chain(struct task_struct
*task,
if (lock == orig_lock || rt_mutex_owner(lock) == top_task) {
debug_rt_mutex_deadlock(deadlock_detect, orig_waiter, lock);
raw_spin_unlock(>wait_lock);
- ret = deadlock_detect ? -EDEADLK : 0;
+ ret = -EDEADLK;
goto out_unlock_pi;
}
@@ -470,7 +470,7 @@ static int task_blocks_on_rt_mutex(struct rt_mutex *lock,
* which is wrong, as the other waiter is not in a deadlock
* situation.
*/
- if (detect_deadlock && owner == task)
+ if (owner == task)
return -EDEADLK;
raw_spin_lock_irqsave(>pi_lock, flags);
@@ -697,6 +697,26 @@ __rt_mutex_slowlock(struct rt_mutex *lock, int state,
return ret;
}
+static void rt_mutex_handle_deadlock(int res, int detect_deadlock,
+struct rt_mutex_waiter *w)
+{
+ /*
+* If the result is not -EDEADLOCK or the caller requested
+* deadlock detection, nothing to do here.
+*/
+ if (res != -EDEADLOCK || detect_deadlock)
+ return;
+
+ /*
+* Yell lowdly and stop the task right here.
+*/
+ rt_mutex_print_deadlock(w);
+ while (1) {
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule();
+ }
+}
+
/*
* Slow path lock function:
*/
@@ -734,8 +754,10 @@ rt_mutex_slowlock(struct rt_mutex *lock, int state,
set_current_state(TASK_RUNNING);
- if (unlikely(ret))
+ if (unlikely(ret)) {
remove_waiter(lock, );
+ rt_mutex_handle_deadlock(ret, detect_deadlock, );
+ }
/*
* try_to_take_rt_mutex() sets the waiter bit
@@ -1043,7 +1065,8 @@ int rt_mutex_start_proxy_lock(struct rt_mutex *lock,
return 1;
}
- ret = task_blocks_on_rt_mutex(lock, waiter, task, detect_deadlock);
+ /* We enforce deadlock detection for futexes */
+ ret = task_blocks_on_rt_mutex(lock, waiter, task, 1);
if (ret && !rt_mutex_owner(lock)) {
/*
diff --git a/kernel/rtmutex.h b/kernel/rtmutex.h
index a1a1dd06421d..f6a1f3c133b1 100644
--- a/kernel/rtmutex.h
+++ b/kernel/rtmutex.h
@@ -24,3 +24,8 @@
#define debug_rt_mutex_print_deadlock(w) do { } while (0)
#define debug_rt_mutex_detect_deadlock(w,d)(d)
#define debug_rt_mutex_reset_waiter(w) do { } while (0)
+
+static inline void rt_mutex_print_deadlock(struct rt_mutex_waiter *w)
+{
+ WARN(1, "rtmutex deadlock detected\n");
+}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 166/170] DMA, CMA: fix possible memory leak
From: Joonsoo Kim
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit fe8eea4f4a3f299ef83ed090d5354698ebe4fda8 upstream.
We should free memory for bitmap when we find zone mismatch, otherwise
this memory will leak.
Additionally, I copy code comment from PPC KVM's CMA code to inform why
we need to check zone mis-match.
Signed-off-by: Joonsoo Kim
Acked-by: Zhang Yanfei
Reviewed-by: Michal Nazarewicz
Reviewed-by: Aneesh Kumar K.V
Acked-by: Minchan Kim
Cc: "Aneesh Kumar K.V"
Cc: Marek Szyprowski
Cc: Michal Nazarewicz
Cc: Paolo Bonzini
Cc: Gleb Natapov
Cc: Alexander Graf
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Jiri Slaby
---
drivers/base/dma-contiguous.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 99802d6f3c60..e057744150ea 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -155,13 +155,23 @@ static int __init cma_activate_area(struct cma *cma)
base_pfn = pfn;
for (j = pageblock_nr_pages; j; --j, pfn++) {
WARN_ON_ONCE(!pfn_valid(pfn));
+ /*
+* alloc_contig_range requires the pfn range
+* specified to be in the same zone. Make this
+* simple by forcing the entire CMA resv range
+* to be in the same zone.
+*/
if (page_zone(pfn_to_page(pfn)) != zone)
- return -EINVAL;
+ goto err;
}
init_cma_reserved_pageblock(pfn_to_page(base_pfn));
} while (--i);
return 0;
+
+err:
+ kfree(cma->bitmap);
+ return -EINVAL;
}
static struct cma cma_areas[MAX_CMA_AREAS];
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 157/170] ext4: clarify error count warning messages
From: Theodore Ts'o
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit ae0f78de2c43b6fadd007c231a352b13b5be8ed2 upstream.
Make it clear that values printed are times, and that it is error
since last fsck. Also add note about fsck version required.
Signed-off-by: Pavel Machek
Signed-off-by: Theodore Ts'o
Reviewed-by: Andreas Dilger
Signed-off-by: Jiri Slaby
---
fs/ext4/super.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index d9711dc42164..a8b886851ff6 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -2762,10 +2762,11 @@ static void print_daily_error_info(unsigned long arg)
es = sbi->s_es;
if (es->s_error_count)
- ext4_msg(sb, KERN_NOTICE, "error count: %u",
+ /* fsck newer than v1.41.13 is needed to clean this condition.
*/
+ ext4_msg(sb, KERN_NOTICE, "error count since last fsck: %u",
le32_to_cpu(es->s_error_count));
if (es->s_first_error_time) {
- printk(KERN_NOTICE "EXT4-fs (%s): initial error at %u: %.*s:%d",
+ printk(KERN_NOTICE "EXT4-fs (%s): initial error at time %u:
%.*s:%d",
sb->s_id, le32_to_cpu(es->s_first_error_time),
(int) sizeof(es->s_first_error_func),
es->s_first_error_func,
@@ -2779,7 +2780,7 @@ static void print_daily_error_info(unsigned long arg)
printk("\n");
}
if (es->s_last_error_time) {
- printk(KERN_NOTICE "EXT4-fs (%s): last error at %u: %.*s:%d",
+ printk(KERN_NOTICE "EXT4-fs (%s): last error at time %u:
%.*s:%d",
sb->s_id, le32_to_cpu(es->s_last_error_time),
(int) sizeof(es->s_last_error_func),
es->s_last_error_func,
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 089/170] Bluetooth: Fix indicating discovery state when canceling inquiry
From: Johan Hedberg 3.12-stable review patch. If anyone has any objections, please let me know. === commit 50143a433b70e3145bcf8a4a4e54f0c11bdee32b upstream. When inquiry is canceled through the HCI_Cancel_Inquiry command there is no Inquiry Complete event generated. Instead, all we get is the command complete for the HCI_Inquiry_Cancel command. This means that we must call the hci_discovery_set_state() function from the respective command complete handler in order to ensure that user space knows the correct discovery state. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Jiri Slaby --- net/bluetooth/hci_event.c | 4 1 file changed, 4 insertions(+) diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index b093ef858e1f..729f516ecd63 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -47,6 +47,10 @@ static void hci_cc_inquiry_cancel(struct hci_dev *hdev, struct sk_buff *skb) smp_mb__after_clear_bit(); /* wake_up_bit advises about this barrier */ wake_up_bit(>flags, HCI_INQUIRY); + hci_dev_lock(hdev); + hci_discovery_set_state(hdev, DISCOVERY_STOPPED); + hci_dev_unlock(hdev); + hci_conn_check_pending(hdev); } -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 101/170] mm, pcp: allow restoring percpu_pagelist_fraction default
From: David Rientjes
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 7cd2b0a34ab8e4db971920eef8982f985441adfb upstream.
Oleg reports a division by zero error on zero-length write() to the
percpu_pagelist_fraction sysctl:
divide error: [#1] SMP DEBUG_PAGEALLOC
CPU: 1 PID: 9142 Comm: badarea_io Not tainted 3.15.0-rc2-vm-nfs+ #19
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
task: 8800d5aeb6e0 ti: 8800d87a2000 task.ti: 8800d87a2000
RIP: 0010: percpu_pagelist_fraction_sysctl_handler+0x84/0x120
RSP: 0018:8800d87a3e78 EFLAGS: 00010246
RAX: 0f89 RBX: 88011f7fd000 RCX:
RDX: RSI: 0001 RDI: 0010
RBP: 8800d87a3e98 R08: 81d002c8 R09: 8800d87a3f50
R10: 000b R11: 0246 R12: 0060
R13: 81c3c3e0 R14: 81cfddf8 R15: 8801193b0800
FS: 7f614f1e9740() GS:88011f44() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 7f614f1fa000 CR3: d9291000 CR4: 06e0
Call Trace:
proc_sys_call_handler+0xb3/0xc0
proc_sys_write+0x14/0x20
vfs_write+0xba/0x1e0
SyS_write+0x46/0xb0
tracesys+0xe1/0xe6
However, if the percpu_pagelist_fraction sysctl is set by the user, it
is also impossible to restore it to the kernel default since the user
cannot write 0 to the sysctl.
This patch allows the user to write 0 to restore the default behavior.
It still requires a fraction equal to or larger than 8, however, as
stated by the documentation for sanity. If a value in the range [1, 7]
is written, the sysctl will return EINVAL.
This successfully solves the divide by zero issue at the same time.
Signed-off-by: David Rientjes
Reported-by: Oleg Drokin
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Jiri Slaby
---
Documentation/sysctl/vm.txt | 3 ++-
kernel/sysctl.c | 3 +--
mm/page_alloc.c | 40
3 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 79a797eb3e87..138fe437bba0 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -664,7 +664,8 @@ The batch value of each per cpu pagelist is also updated as
a result. It is
set to pcp->high/4. The upper limit of batch is (PAGE_SHIFT * 8)
The initial value is zero. Kernel does not use this value at boot time to set
-the high water marks for each per cpu page list.
+the high water marks for each per cpu page list. If the user writes '0' to
this
+sysctl, it will revert to this default behavior.
==
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 2a9db916c3f5..167741003616 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -138,7 +138,6 @@ static unsigned long dirty_bytes_min = 2 * PAGE_SIZE;
/* this is needed for the proc_dointvec_minmax for [fs_]overflow UID and GID */
static int maxolduid = 65535;
static int minolduid;
-static int min_percpu_pagelist_fract = 8;
static int ngroups_max = NGROUPS_MAX;
static const int cap_last_cap = CAP_LAST_CAP;
@@ -1287,7 +1286,7 @@ static struct ctl_table vm_table[] = {
.maxlen = sizeof(percpu_pagelist_fraction),
.mode = 0644,
.proc_handler = percpu_pagelist_fraction_sysctl_handler,
- .extra1 = _percpu_pagelist_fract,
+ .extra1 = ,
},
#ifdef CONFIG_MMU
{
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a6bf980f5dd0..83aaa49bcba7 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -69,6 +69,7 @@
/* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */
static DEFINE_MUTEX(pcp_batch_high_lock);
+#define MIN_PERCPU_PAGELIST_FRACTION (8)
#ifdef CONFIG_USE_PERCPU_NUMA_NODE_ID
DEFINE_PER_CPU(int, numa_node);
@@ -4079,7 +4080,7 @@ static void __meminit zone_init_free_lists(struct zone
*zone)
memmap_init_zone((size), (nid), (zone), (start_pfn), MEMMAP_EARLY)
#endif
-static int __meminit zone_batchsize(struct zone *zone)
+static int zone_batchsize(struct zone *zone)
{
#ifdef CONFIG_MMU
int batch;
@@ -4195,8 +4196,8 @@ static void pageset_set_high(struct per_cpu_pageset *p,
pageset_update(>pcp, high, batch);
}
-static void __meminit pageset_set_high_and_batch(struct zone *zone,
- struct per_cpu_pageset *pcp)
+static void pageset_set_high_and_batch(struct zone *zone,
+ struct per_cpu_pageset *pcp)
{
if (percpu_pagelist_fraction)
pageset_set_high(pcp,
@@ -5789,23 +5790,38 @@ int percpu_pagelist_fraction_sysctl_handler(ctl_table
*table, int write,
void
[PATCH 3.12 013/170] Input: elantech - don't set bit 1 of reg_10 when the no_hw_res quirk is set
From: Hans de Goede
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit fb4f8f568a9def02240ef9bf7aabd246dc63a081 upstream.
The touchpad on the GIGABYTE U2442 not only stops communicating when we try
to set bit 3 (enable real hardware resolution) of reg_10, but on some BIOS
versions also when we set bit 1 (enable two finger mode auto correct).
I've asked the original reporter of:
https://bugzilla.kernel.org/show_bug.cgi?id=61151
To check that not setting bit 1 does not lead to any adverse effects on his
model / BIOS revision, and it does not, so this commit fixes the touchpad
not working on these versions by simply never setting bit 1 for laptop
models with the no_hw_res quirk.
Reported-and-tested-by: James Lademann
Tested-by: Philipp Wolfer
Signed-off-by: Hans de Goede
Signed-off-by: Dmitry Torokhov
Signed-off-by: Jiri Slaby
---
drivers/input/mouse/elantech.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 360e46b200de..233516aff595 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -849,7 +849,7 @@ static int elantech_set_absolute_mode(struct psmouse
*psmouse)
if (etd->set_hw_resolution)
etd->reg_10 = 0x0b;
else
- etd->reg_10 = 0x03;
+ etd->reg_10 = 0x01;
if (elantech_write_reg(psmouse, 0x10, etd->reg_10))
rc = -1;
@@ -1350,7 +1350,8 @@ static int elantech_reconnect(struct psmouse *psmouse)
}
/*
- * Some hw_version 3 models go into error state when we try to set bit 3 of r10
+ * Some hw_version 3 models go into error state when we try to set
+ * bit 3 and/or bit 1 of r10.
*/
static const struct dmi_system_id no_hw_res_dmi_table[] = {
#if defined(CONFIG_DMI) && defined(CONFIG_X86)
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 031/170] IB/umad: Fix error handling
From: Bart Van Assche
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 8ec0a0e6b58218bdc1db91dd70ebfcd6ad8dd6cd upstream.
Avoid leaking a kref count in ib_umad_open() if port->ib_dev == NULL
or if nonseekable_open() fails.
Avoid leaking a kref count, that sm_sem is kept down and also that the
IB_PORT_SM capability mask is not cleared in ib_umad_sm_open() if
nonseekable_open() fails.
Since container_of() never returns NULL, remove the code that tests
whether container_of() returns NULL.
Moving the kref_get() call from the start of ib_umad_*open() to the
end is safe since it is the responsibility of the caller of these
functions to ensure that the cdev pointer remains valid until at least
when these functions return.
Signed-off-by: Bart Van Assche
[ydrone...@opteya.com: rework a bit to reduce the amount of code changed]
Signed-off-by: Yann Droneaud
[ nonseekable_open() can't actually fail, but - Roland ]
Signed-off-by: Roland Dreier
Signed-off-by: Jiri Slaby
---
drivers/infiniband/core/user_mad.c | 49 +-
1 file changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/infiniband/core/user_mad.c
b/drivers/infiniband/core/user_mad.c
index f0d588f8859e..9bdf576cd4ab 100644
--- a/drivers/infiniband/core/user_mad.c
+++ b/drivers/infiniband/core/user_mad.c
@@ -780,27 +780,19 @@ static int ib_umad_open(struct inode *inode, struct file
*filp)
{
struct ib_umad_port *port;
struct ib_umad_file *file;
- int ret;
+ int ret = -ENXIO;
port = container_of(inode->i_cdev, struct ib_umad_port, cdev);
- if (port)
- kref_get(>umad_dev->ref);
- else
- return -ENXIO;
mutex_lock(>file_mutex);
- if (!port->ib_dev) {
- ret = -ENXIO;
+ if (!port->ib_dev)
goto out;
- }
+ ret = -ENOMEM;
file = kzalloc(sizeof *file, GFP_KERNEL);
- if (!file) {
- kref_put(>umad_dev->ref, ib_umad_release_dev);
- ret = -ENOMEM;
+ if (!file)
goto out;
- }
mutex_init(>mutex);
spin_lock_init(>send_lock);
@@ -814,6 +806,13 @@ static int ib_umad_open(struct inode *inode, struct file
*filp)
list_add_tail(>port_list, >file_list);
ret = nonseekable_open(inode, filp);
+ if (ret) {
+ list_del(>port_list);
+ kfree(file);
+ goto out;
+ }
+
+ kref_get(>umad_dev->ref);
out:
mutex_unlock(>file_mutex);
@@ -880,10 +879,6 @@ static int ib_umad_sm_open(struct inode *inode, struct
file *filp)
int ret;
port = container_of(inode->i_cdev, struct ib_umad_port, sm_cdev);
- if (port)
- kref_get(>umad_dev->ref);
- else
- return -ENXIO;
if (filp->f_flags & O_NONBLOCK) {
if (down_trylock(>sm_sem)) {
@@ -898,17 +893,27 @@ static int ib_umad_sm_open(struct inode *inode, struct
file *filp)
}
ret = ib_modify_port(port->ib_dev, port->port_num, 0, );
- if (ret) {
- up(>sm_sem);
- goto fail;
- }
+ if (ret)
+ goto err_up_sem;
filp->private_data = port;
- return nonseekable_open(inode, filp);
+ ret = nonseekable_open(inode, filp);
+ if (ret)
+ goto err_clr_sm_cap;
+
+ kref_get(>umad_dev->ref);
+
+ return 0;
+
+err_clr_sm_cap:
+ swap(props.set_port_cap_mask, props.clr_port_cap_mask);
+ ib_modify_port(port->ib_dev, port->port_num, 0, );
+
+err_up_sem:
+ up(>sm_sem);
fail:
- kref_put(>umad_dev->ref, ib_umad_release_dev);
return ret;
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 090/170] Bluetooth: Fix locking of hdev when calling into SMP code
From: Johan Hedberg
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit c73f94b8c093a615ce80eabbde0ac6eb9abfe31a upstream.
The SMP code expects hdev to be unlocked since e.g. crypto functions
will try to (re)lock it. Therefore, we need to release the lock before
calling into smp.c from mgmt.c. Without this we risk a deadlock whenever
the smp_user_confirm_reply() function is called.
Signed-off-by: Johan Hedberg
Tested-by: Lukasz Rymanowski
Signed-off-by: Marcel Holtmann
Signed-off-by: Jiri Slaby
---
net/bluetooth/mgmt.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index fedc5399d465..211fffb5dca8 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -2319,8 +2319,13 @@ static int user_pairing_resp(struct sock *sk, struct
hci_dev *hdev,
}
if (addr->type == BDADDR_LE_PUBLIC || addr->type == BDADDR_LE_RANDOM) {
- /* Continue with pairing via SMP */
+ /* Continue with pairing via SMP. The hdev lock must be
+* released as SMP may try to recquire it for crypto
+* purposes.
+*/
+ hci_dev_unlock(hdev);
err = smp_user_confirm_reply(conn, mgmt_op, passkey);
+ hci_dev_lock(hdev);
if (!err)
err = cmd_complete(sk, hdev->id, mgmt_op,
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 122/170] mmc: rtsx: add R1-no-CRC mmc command type handle
From: Micky Ching
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 5027251eced6e34315a52bd841279df957f627bb upstream.
a27fbf2f067b0cd ("mmc: add ignorance case for CMD13 CRC error") produced
a cmd.flags unhandled in realtek pci host driver. This will make MMC
card fail to initialize, this patch is used to handle the new cmd.flags
condition and MMC card can be used.
Signed-off-by: Micky Ching
Signed-off-by: Ulf Hansson
Signed-off-by: Chris Ball
Signed-off-by: Jiri Slaby
---
drivers/mmc/host/rtsx_pci_sdmmc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 375a880e0c5f..54e8ba45c3ad 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -246,6 +246,9 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc
*host,
case MMC_RSP_R1:
rsp_type = SD_RSP_TYPE_R1;
break;
+ case MMC_RSP_R1 & ~MMC_RSP_CRC:
+ rsp_type = SD_RSP_TYPE_R1 | SD_NO_CHECK_CRC7;
+ break;
case MMC_RSP_R1B:
rsp_type = SD_RSP_TYPE_R1b;
break;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 115/170] tools: ffs-test: fix header values endianess
From: Michal Nazarewicz
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit f35f71244da6e51db4e1f2c7e318581f498ececf upstream.
It appears that no one ever run ffs-test on a big-endian machine,
since it used cpu-endianess for fs_count and hs_count fields which
should be in little-endian format. Fix by wrapping the numbers in
cpu_to_le32.
Signed-off-by: Michal Nazarewicz
Signed-off-by: Felipe Balbi
Signed-off-by: Jiri Slaby
---
tools/usb/ffs-test.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/usb/ffs-test.c b/tools/usb/ffs-test.c
index fe1e66b6ef40..a87e99f37c52 100644
--- a/tools/usb/ffs-test.c
+++ b/tools/usb/ffs-test.c
@@ -116,8 +116,8 @@ static const struct {
.header = {
.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC),
.length = cpu_to_le32(sizeof descriptors),
- .fs_count = 3,
- .hs_count = 3,
+ .fs_count = cpu_to_le32(3),
+ .hs_count = cpu_to_le32(3),
},
.fs_descs = {
.intf = {
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 054/170] lz4: add overrun checks to lz4_uncompress_unknownoutputsize()
From: Greg Kroah-Hartman
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 4a3a99045177369700c60d074c0e525e8093b0fc upstream.
Jan points out that I forgot to make the needed fixes to the
lz4_uncompress_unknownoutputsize() function to mirror the changes done
in lz4_decompress() with regards to potential pointer overflows.
The only in-kernel user of this function is the zram code, which only
takes data from a valid compressed buffer that it made itself, so it's
not a big issue. But due to external kernel modules using this
function, it's better to be safe here.
Reported-by: Jan Beulich
Cc: "Don A. Bailey"
Signed-off-by: Jiri Slaby
---
lib/lz4/lz4_decompress.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
index b74da447e81e..7a85967060a5 100644
--- a/lib/lz4/lz4_decompress.c
+++ b/lib/lz4/lz4_decompress.c
@@ -192,6 +192,8 @@ static int lz4_uncompress_unknownoutputsize(const char
*source, char *dest,
int s = 255;
while ((ip < iend) && (s == 255)) {
s = *ip++;
+ if (unlikely(length > (size_t)(length + s)))
+ goto _output_error;
length += s;
}
}
@@ -232,6 +234,8 @@ static int lz4_uncompress_unknownoutputsize(const char
*source, char *dest,
if (length == ML_MASK) {
while (ip < iend) {
int s = *ip++;
+ if (unlikely(length > (size_t)(length + s)))
+ goto _output_error;
length += s;
if (s == 255)
continue;
@@ -284,7 +288,7 @@ static int lz4_uncompress_unknownoutputsize(const char
*source, char *dest,
/* write overflow error detected */
_output_error:
- return (int) (-(((char *) ip) - source));
+ return -1;
}
int lz4_decompress(const unsigned char *src, size_t *src_len,
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 135/170] thermal: hwmon: Make the check for critical temp valid consistent
From: Aaron Lu
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit e8db5d6736a712a3e2280c0e31f4b301d85172d8 upstream.
On 05/21/2014 04:22 PM, Aaron Lu wrote:
> On 05/21/2014 01:57 PM, Kui Zhang wrote:
>> Hello,
>>
>> I get following error when rmmod thermal.
>>
>> rmmod thermal
>> Killed
While dealing with this problem, I found another problem that also
results in a kernel crash on thermal module removal:
From: Aaron Lu
Date: Wed, 21 May 2014 16:05:38 +0800
Subject: thermal: hwmon: Make the check for critical temp valid consistent
We used the tz->ops->get_crit_temp && !tz->ops->get_crit_temp(tz, temp)
to decide if we need to create the temp_crit attribute file but we just
check if tz->ops->get_crit_temp exists to decide if we need to remove
that attribute file. Some ACPI thermal zone doesn't have a valid critical
trip point and that would result in removing a non-existent device file
on thermal module unload.
Signed-off-by: Aaron Lu
Signed-off-by: Zhang Rui
Signed-off-by: Jiri Slaby
---
drivers/thermal/thermal_hwmon.c | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
index fdb07199d9c2..1967bee4f076 100644
--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -140,6 +140,12 @@ thermal_hwmon_lookup_temp(const struct
thermal_hwmon_device *hwmon,
return NULL;
}
+static bool thermal_zone_crit_temp_valid(struct thermal_zone_device *tz)
+{
+ unsigned long temp;
+ return tz->ops->get_crit_temp && !tz->ops->get_crit_temp(tz, );
+}
+
int thermal_add_hwmon_sysfs(struct thermal_zone_device *tz)
{
struct thermal_hwmon_device *hwmon;
@@ -189,21 +195,18 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device
*tz)
if (result)
goto free_temp_mem;
- if (tz->ops->get_crit_temp) {
- unsigned long temperature;
- if (!tz->ops->get_crit_temp(tz, )) {
- snprintf(temp->temp_crit.name,
-sizeof(temp->temp_crit.name),
+ if (thermal_zone_crit_temp_valid(tz)) {
+ snprintf(temp->temp_crit.name,
+ sizeof(temp->temp_crit.name),
"temp%d_crit", hwmon->count);
- temp->temp_crit.attr.attr.name = temp->temp_crit.name;
- temp->temp_crit.attr.attr.mode = 0444;
- temp->temp_crit.attr.show = temp_crit_show;
- sysfs_attr_init(>temp_crit.attr.attr);
- result = device_create_file(hwmon->device,
- >temp_crit.attr);
- if (result)
- goto unregister_input;
- }
+ temp->temp_crit.attr.attr.name = temp->temp_crit.name;
+ temp->temp_crit.attr.attr.mode = 0444;
+ temp->temp_crit.attr.show = temp_crit_show;
+ sysfs_attr_init(>temp_crit.attr.attr);
+ result = device_create_file(hwmon->device,
+ >temp_crit.attr);
+ if (result)
+ goto unregister_input;
}
mutex_lock(_hwmon_list_lock);
@@ -250,7 +253,7 @@ void thermal_remove_hwmon_sysfs(struct thermal_zone_device
*tz)
}
device_remove_file(hwmon->device, >temp_input.attr);
- if (tz->ops->get_crit_temp)
+ if (thermal_zone_crit_temp_valid(tz))
device_remove_file(hwmon->device, >temp_crit.attr);
mutex_lock(_hwmon_list_lock);
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 136/170] hwmon: (amc6821) Fix permissions for temp2_input
From: Axel Lin 3.12-stable review patch. If anyone has any objections, please let me know. === commit df86754b746e9a0ff6f863f690b1c01d408e3cdc upstream. temp2_input should not be writable, fix it. Reported-by: Guenter Roeck Signed-off-by: Axel Lin Signed-off-by: Guenter Roeck Signed-off-by: Jiri Slaby --- drivers/hwmon/amc6821.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwmon/amc6821.c b/drivers/hwmon/amc6821.c index eea817296513..9f2be3dd28f3 100644 --- a/drivers/hwmon/amc6821.c +++ b/drivers/hwmon/amc6821.c @@ -704,7 +704,7 @@ static SENSOR_DEVICE_ATTR(temp1_max_alarm, S_IRUGO, get_temp_alarm, NULL, IDX_TEMP1_MAX); static SENSOR_DEVICE_ATTR(temp1_crit_alarm, S_IRUGO, get_temp_alarm, NULL, IDX_TEMP1_CRIT); -static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO | S_IWUSR, +static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, get_temp, NULL, IDX_TEMP2_INPUT); static SENSOR_DEVICE_ATTR(temp2_min, S_IRUGO | S_IWUSR, get_temp, set_temp, IDX_TEMP2_MIN); -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 035/170] nfsd: getattr for FATTR4_WORD0_FILES_AVAIL needs the statfs buffer
From: Christoph Hellwig
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 12337901d654415d9f764b5f5ba50052e9700f37 upstream.
Note nobody's ever noticed because the typical client probably never
requests FILES_AVAIL without also requesting something else on the list.
Signed-off-by: Christoph Hellwig
Signed-off-by: J. Bruce Fields
Signed-off-by: Jiri Slaby
---
fs/nfsd/nfs4xdr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
index 4ab5ff492ca1..8fb749d7bbe6 100644
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -2113,8 +2113,8 @@ nfsd4_encode_fattr(struct svc_fh *fhp, struct svc_export
*exp,
err = vfs_getattr(, );
if (err)
goto out_nfserr;
- if ((bmval0 & (FATTR4_WORD0_FILES_FREE | FATTR4_WORD0_FILES_TOTAL |
- FATTR4_WORD0_MAXNAME)) ||
+ if ((bmval0 & (FATTR4_WORD0_FILES_AVAIL | FATTR4_WORD0_FILES_FREE |
+ FATTR4_WORD0_FILES_TOTAL | FATTR4_WORD0_MAXNAME)) ||
(bmval1 & (FATTR4_WORD1_SPACE_AVAIL | FATTR4_WORD1_SPACE_FREE |
FATTR4_WORD1_SPACE_TOTAL))) {
err = vfs_statfs(, );
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 073/170] usb: gadget: f_fs: fix NULL pointer dereference when there are no strings
From: Michal Nazarewicz
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit f0688c8b81d2ea239c3fb0b848f623b579238d99 upstream.
If the descriptors do not need any strings and user space sends empty
set of strings, the ffs->stringtabs field remains NULL. Thus
*ffs->stringtabs in functionfs_bind leads to a NULL pointer
dereferenece.
The bug was introduced by commit [fd7c9a007f: “use usb_string_ids_n()”].
While at it, remove double initialisation of lang local variable in
that function.
ffs->strings_count does not need to be checked in any way since in
the above scenario it will remain zero and usb_string_ids_n() is
a no-operation when colled with 0 argument.
Signed-off-by: Michal Nazarewicz
Signed-off-by: Felipe Balbi
Signed-off-by: Jiri Slaby
---
drivers/usb/gadget/f_fs.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 44cf775a8627..c3067f4f213a 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -1389,11 +1389,13 @@ static int functionfs_bind(struct ffs_data *ffs, struct
usb_composite_dev *cdev)
ffs->ep0req->context = ffs;
lang = ffs->stringtabs;
- for (lang = ffs->stringtabs; *lang; ++lang) {
- struct usb_string *str = (*lang)->strings;
- int id = first_id;
- for (; str->s; ++id, ++str)
- str->id = id;
+ if (lang) {
+ for (; *lang; ++lang) {
+ struct usb_string *str = (*lang)->strings;
+ int id = first_id;
+ for (; str->s; ++id, ++str)
+ str->id = id;
+ }
}
ffs->gadget = cdev->gadget;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 086/170] drm/radeon/cik: fix typo in EOP packet
From: Alex Deucher 3.12-stable review patch. If anyone has any objections, please let me know. === commit b397207b7475afa9df2f94541f978100ff1ea47e upstream. Volatile bit was in the wrong location. This bit is not used at the moment. Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby --- drivers/gpu/drm/radeon/cikd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h index 70e88498a1fd..9c8ef204a3cb 100644 --- a/drivers/gpu/drm/radeon/cikd.h +++ b/drivers/gpu/drm/radeon/cikd.h @@ -1695,12 +1695,12 @@ #defineEOP_TC_WB_ACTION_EN (1 << 15) /* L2 */ #defineEOP_TCL1_ACTION_EN (1 << 16) #defineEOP_TC_ACTION_EN(1 << 17) /* L2 */ +#defineEOP_TCL2_VOLATILE (1 << 24) #defineEOP_CACHE_POLICY(x) ((x) << 25) /* 0 - LRU * 1 - Stream * 2 - Bypass */ -#defineEOP_TCL2_VOLATILE (1 << 27) #defineDATA_SEL(x) ((x) << 29) /* 0 - discard * 1 - send low 32bit data -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 151/170] clk: spear3xx: Use proper control register offset
From: Thomas Gleixner
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 15ebb05248d025534773c9ef64915bd888f04e4b upstream.
The control register is at offset 0x10, not 0x0. This is wreckaged
since commit 5df33a62c (SPEAr: Switch to common clock framework).
Signed-off-by: Thomas Gleixner
Acked-by: Viresh Kumar
Signed-off-by: Mike Turquette
Signed-off-by: Jiri Slaby
---
drivers/clk/spear/spear3xx_clock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/spear/spear3xx_clock.c
b/drivers/clk/spear/spear3xx_clock.c
index c2d204315546..125eba86c844 100644
--- a/drivers/clk/spear/spear3xx_clock.c
+++ b/drivers/clk/spear/spear3xx_clock.c
@@ -211,7 +211,7 @@ static inline void spear310_clk_init(void) { }
/* array of all spear 320 clock lookups */
#ifdef CONFIG_MACH_SPEAR320
-#define SPEAR320_CONTROL_REG (soc_config_base + 0x)
+#define SPEAR320_CONTROL_REG (soc_config_base + 0x0010)
#define SPEAR320_EXT_CTRL_REG (soc_config_base + 0x0018)
#define SPEAR320_UARTX_PCLK_MASK0x1
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 077/170] mtd: nand: omap: fix BCHx ecc.correct to return detected bit-flips in erased-page
From: pekon gupta 3.12-stable review patch. If anyone has any objections, please let me know. === commit f306e8c3b667632952f1a4a74ffb910bbc06255f upstream. fixes: commit 62116e5171e00f85a8d53f76e45b84423c89ff34 mtd: nand: omap2: Support for hardware BCH error correction. In omap_elm_correct_data(), if bitflip_count in an erased-page is within the correctable limit (< ecc.strength), then it is not indicated back to the caller ecc->read_page(). This mis-guides upper layers like MTD and UBIFS layer to assume erased-page as perfectly clean and use it for writing even if actual bitflip_count was dangerously high (bitflip_count > mtd->bitflip_threshold). This patch fixes this above issue, by returning 'stats' to caller ecc->read_page() under all scenarios. Reported-by: Brian Norris Signed-off-by: Pekon Gupta Signed-off-by: Brian Norris Signed-off-by: Jiri Slaby --- drivers/mtd/nand/omap2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 4ecf0e5fd484..0332d0b2d73a 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -1463,7 +1463,7 @@ static int omap_elm_correct_data(struct mtd_info *mtd, u_char *data, /* Check if any error reported */ if (!is_error_reported) - return 0; + return stat; /* Decode BCH error using ELM module */ elm_decode_bch_error_page(info->elm_dev, ecc_vec, err_vec); -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID: rmi: only bind the hid-rmi driver to the mouse interface of composite USB devices
On Jul 17 2014 or thereabouts, Andrew Duggan wrote: > On composite HID devices there may be multiple HID devices on separate > interfaces, but hid-rmi > should only bind to the mouse interface. One example is the Dell Venue 11 > Pro's keyboard dock > which contains a composite USB device with a HID touchpad and HID keyboard on > separate intefaces. > Since the USB Vendor ID is Synaptic's, hid-core is currently trying to bind > hid-rmi to all\of > the HID devices. This patch ensures that hid-rmi only binds to the mouse > interface. > > related bug: > https://bugzilla.kernel.org/show_bug.cgi?id=80091 > > Signed-off-by: Andrew Duggan > --- As mentioned in a private mail, Andrew told me that for now, each touchpad using hid-rmi he has seen are using the boot mouse protocol, so this patch will give us some space and will not break existing current setups. Reviewed-by: Benjamin Tissoires Cheers, Benjamin > drivers/hid/hid-core.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c > index 8ed66fd..f10e768 100644 > --- a/drivers/hid/hid-core.c > +++ b/drivers/hid/hid-core.c > @@ -783,7 +783,9 @@ static int hid_scan_report(struct hid_device *hid) > * Vendor specific handlings > */ > if ((hid->vendor == USB_VENDOR_ID_SYNAPTICS) && > - (hid->group == HID_GROUP_GENERIC)) > + (hid->group == HID_GROUP_GENERIC) && > + /* only bind to the mouse interface of composite USB devices */ > + (hid->bus != BUS_USB || hid->type == HID_TYPE_USBMOUSE)) > /* hid-rmi should take care of them, not hid-generic */ > hid->group = HID_GROUP_RMI; > > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 055/170] Documentation/SubmittingPatches: describe the Fixes: tag
From: Jacob Keller
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 8401aa1f59975c03eeebd3ac6d264cbdfe9af5de upstream.
Update the SubmittingPatches process to include howto about the new
'Fixes:' tag to be used when a patch fixes an issue in a previous commit
(found by git-bisect for example).
Signed-off-by: Jacob Keller
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
Cc: Randy Dunlap
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Jiri Slaby
---
Documentation/SubmittingPatches | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 26b1e31d5a13..1ec219a14904 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -119,6 +119,20 @@ Example:
platform_set_drvdata(), but left the variable "dev" unused,
delete it.
+If your patch fixes a bug in a specific commit, e.g. you found an issue using
+git-bisect, please use the 'Fixes:' tag with the first 12 characters of the
+SHA-1 ID, and the one line summary.
+Example:
+
+ Fixes: e21d2170f366 ("video: remove unnecessary platform_set_drvdata()")
+
+The following git-config settings can be used to add a pretty format for
+outputting the above style in the git log or git show commands
+
+ [core]
+ abbrev = 12
+ [pretty]
+ fixes = Fixes: %h (\"%s\")
3) Separate your changes.
@@ -430,7 +444,7 @@ person it names. This tag documents that potentially
interested parties
have been included in the discussion
-14) Using Reported-by:, Tested-by:, Reviewed-by: and Suggested-by:
+14) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
If this patch fixes a problem reported by somebody else, consider adding a
Reported-by: tag to credit the reporter for their contribution. Please
@@ -485,6 +499,12 @@ idea was not posted in a public forum. That said, if we
diligently credit our
idea reporters, they will, hopefully, be inspired to help us again in the
future.
+A Fixes: tag indicates that the patch fixes an issue in a previous commit. It
+is used to make it easy to determine where a bug originated, which can help
+review a bug fix. This tag also assists the stable kernel team in determining
+which stable kernel versions should receive your fix. This is the preferred
+method for indicating a bug fixed by the patch. See #2 above for more details.
+
15) The canonical patch format
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 153/170] Drivers: hv: vmbus: Fix a bug in the channel callback dispatch code
From: "K. Y. Srinivasan"
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit affb1aff300ddee54df307812b38f166e8a865ef upstream.
Starting with Win8, we have implemented several optimizations to improve the
scalability and performance of the VMBUS transport between the Host and the
Guest. Some of the non-performance critical services cannot leverage these
optimization since they only read and process one message at a time.
Make adjustments to the callback dispatch code to account for the way
non-performance critical drivers handle reading of the channel.
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Jiri Slaby
---
drivers/hv/connection.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index 8dd98d4fc124..59ef4e7afdd7 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -320,9 +320,13 @@ static void process_chn_event(u32 relid)
*/
do {
- hv_begin_read(>inbound);
+ if (read_state)
+ hv_begin_read(>inbound);
channel->onchannel_callback(arg);
- bytes_to_read = hv_end_read(>inbound);
+ if (read_state)
+ bytes_to_read = hv_end_read(>inbound);
+ else
+ bytes_to_read = 0;
} while (read_state && (bytes_to_read != 0));
} else {
pr_err("no channel callback for relid - %u\n", relid);
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 059/170] ibmvscsi: Abort init sequence during error recovery
From: Brian King 3.12-stable review patch. If anyone has any objections, please let me know. === commit 9ee755974bea2f9880e517ec985dc9dede1b3a36 upstream. If a CRQ reset is triggered for some reason while in the middle of performing VSCSI adapter initialization, we don't want to call the done function for the initialization MAD commands as this will only result in two threads attempting initialization at the same time, resulting in failures. Signed-off-by: Brian King Acked-by: Nathan Fontenot Signed-off-by: Christoph Hellwig Signed-off-by: Jiri Slaby --- drivers/scsi/ibmvscsi/ibmvscsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c index fa764406df68..c3d4991411b2 100644 --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -797,7 +797,8 @@ static void purge_requests(struct ibmvscsi_host_data *hostdata, int error_code) evt->hostdata->dev); if (evt->cmnd_done) evt->cmnd_done(evt->cmnd); - } else if (evt->done) + } else if (evt->done && evt->crq.format != VIOSRP_MAD_FORMAT && + evt->iu.srp.login_req.opcode != SRP_LOGIN_REQ) evt->done(evt); free_event_struct(>hostdata->pool, evt); spin_lock_irqsave(hostdata->host->host_lock, flags); -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 088/170] Bluetooth: Fix SSP acceptor just-works confirmation without MITM
From: Johan Hedberg
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit ba15a58b179ed76a7e887177f2b06de12c58ec8f upstream.
>From the Bluetooth Core Specification 4.1 page 1958:
"if both devices have set the Authentication_Requirements parameter to
one of the MITM Protection Not Required options, authentication stage 1
shall function as if both devices set their IO capabilities to
DisplayOnly (e.g., Numeric comparison with automatic confirmation on
both devices)"
So far our implementation has done user confirmation for all just-works
cases regardless of the MITM requirements, however following the
specification to the word means that we should not be doing confirmation
when neither side has the MITM flag set.
Signed-off-by: Johan Hedberg
Tested-by: Szymon Janc
Signed-off-by: Marcel Holtmann
Signed-off-by: Jiri Slaby
---
net/bluetooth/hci_event.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 2eeb6643d78a..b093ef858e1f 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -3164,8 +3164,11 @@ static void hci_user_confirm_request_evt(struct hci_dev
*hdev,
/* If we're not the initiators request authorization to
* proceed from user space (mgmt_user_confirm with
-* confirm_hint set to 1). */
- if (!test_bit(HCI_CONN_AUTH_PEND, >flags)) {
+* confirm_hint set to 1). The exception is if neither
+* side had MITM in which case we do auto-accept.
+*/
+ if (!test_bit(HCI_CONN_AUTH_PEND, >flags) &&
+ (loc_mitm || rem_mitm)) {
BT_DBG("Confirming auto-accept as acceptor");
confirm_hint = 1;
goto confirm;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 052/170] ipvs: Fix panic due to non-linear skb
From: Peter Christensen
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit f44a5f45f544561302e855e7bd104e5f506ec01b upstream.
Receiving a ICMP response to an IPIP packet in a non-linear skb could
cause a kernel panic in __skb_pull.
The problem was introduced in
commit f2edb9f7706dcb2c0d9a362b2ba849efe3a97f5e ("ipvs: implement
passive PMTUD for IPIP packets").
Signed-off-by: Peter Christensen
Acked-by: Julian Anastasov
Signed-off-by: Simon Horman
Signed-off-by: Jiri Slaby
---
net/netfilter/ipvs/ip_vs_core.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 3581736446d5..e2d38e5318d4 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -1392,15 +1392,19 @@ ip_vs_in_icmp(struct sk_buff *skb, int *related,
unsigned int hooknum)
if (ipip) {
__be32 info = ic->un.gateway;
+ __u8 type = ic->type;
+ __u8 code = ic->code;
/* Update the MTU */
if (ic->type == ICMP_DEST_UNREACH &&
ic->code == ICMP_FRAG_NEEDED) {
struct ip_vs_dest *dest = cp->dest;
u32 mtu = ntohs(ic->un.frag.mtu);
+ __be16 frag_off = cih->frag_off;
/* Strip outer IP and ICMP, go to IPIP header */
- __skb_pull(skb, ihl + sizeof(_icmph));
+ if (pskb_pull(skb, ihl + sizeof(_icmph)) == NULL)
+ goto ignore_ipip;
offset2 -= ihl + sizeof(_icmph);
skb_reset_network_header(skb);
IP_VS_DBG(12, "ICMP for IPIP %pI4->%pI4: mtu=%u\n",
@@ -1408,7 +1412,7 @@ ip_vs_in_icmp(struct sk_buff *skb, int *related, unsigned
int hooknum)
ipv4_update_pmtu(skb, dev_net(skb->dev),
mtu, 0, 0, 0, 0);
/* Client uses PMTUD? */
- if (!(cih->frag_off & htons(IP_DF)))
+ if (!(frag_off & htons(IP_DF)))
goto ignore_ipip;
/* Prefer the resulting PMTU */
if (dest) {
@@ -1427,12 +1431,13 @@ ip_vs_in_icmp(struct sk_buff *skb, int *related,
unsigned int hooknum)
/* Strip outer IP, ICMP and IPIP, go to IP header of
* original request.
*/
- __skb_pull(skb, offset2);
+ if (pskb_pull(skb, offset2) == NULL)
+ goto ignore_ipip;
skb_reset_network_header(skb);
IP_VS_DBG(12, "Sending ICMP for %pI4->%pI4: t=%u, c=%u, i=%u\n",
_hdr(skb)->saddr, _hdr(skb)->daddr,
- ic->type, ic->code, ntohl(info));
- icmp_send(skb, ic->type, ic->code, info);
+ type, code, ntohl(info));
+ icmp_send(skb, type, code, info);
/* ICMP can be shorter but anyways, account it */
ip_vs_out_stats(cp, skb);
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c
On Fri, Jul 18, 2014 at 12:16:33 +0200, Peter Zijlstra wrote: So it looks like the actual domain tree is broken, and not what we assumed it was. Could I bother you to run with the below instead? It should also print out the sched domain masks so we don't need to guess about them. The full dmesg output is at: https://bugzilla.kernel.org/attachment.cgi?id=143381 (make sure you have CONFIG_SCHED_DEBUG=y otherwise it will not build) I also booted with early printk=keepsched_debug as requested by Dietmar. can you make that: sched_debug ? I think I've fixed that. I think the part you are most interested in contains the following: [0.252280] smpboot: Total of 4 processors activated (21438.11 BogoMIPS) [0.253058] __sdt_alloc: allocated f255b020 with cpus: [0.253146] __sdt_alloc: allocated f255b0e0 with cpus: [0.253227] __sdt_alloc: allocated f255b120 with cpus: [0.253308] __sdt_alloc: allocated f255b160 with cpus: [0.253390] __sdt_alloc: allocated f255b1a0 with cpus: [0.253471] __sdt_alloc: allocated f255b1e0 with cpus: [0.253551] __sdt_alloc: allocated f255b220 with cpus: [0.253632] __sdt_alloc: allocated f255b260 with cpus: [0.254009] __sdt_alloc: allocated f255b2a0 with cpus: [0.254092] __sdt_alloc: allocated f255b2e0 with cpus: [0.254181] __sdt_alloc: allocated f255b320 with cpus: [0.254262] __sdt_alloc: allocated f255b360 with cpus: [0.254350] build_sched_domain: cpu: 0 level: SMT cpu_map: 0-3 tl->mask: 0,2 [0.254433] build_sched_domain: cpu: 0 level: MC cpu_map: 0-3 tl->mask: 0 [0.254516] build_sched_domain: cpu: 0 level: DIE cpu_map: 0-3 tl->mask: 0-3 [0.254600] build_sched_domain: cpu: 1 level: SMT cpu_map: 0-3 tl->mask: 1,3 [0.254683] build_sched_domain: cpu: 1 level: MC cpu_map: 0-3 tl->mask: 1 [0.254766] build_sched_domain: cpu: 1 level: DIE cpu_map: 0-3 tl->mask: 0-3 [0.254850] build_sched_domain: cpu: 2 level: SMT cpu_map: 0-3 tl->mask: 0,2 [0.254932] build_sched_domain: cpu: 2 level: MC cpu_map: 0-3 tl->mask: 2 [0.255005] build_sched_domain: cpu: 2 level: DIE cpu_map: 0-3 tl->mask: 0-3 [0.255091] build_sched_domain: cpu: 3 level: SMT cpu_map: 0-3 tl->mask: 1,3 [0.255176] build_sched_domain: cpu: 3 level: MC cpu_map: 0-3 tl->mask: 3 [0.255260] build_sched_domain: cpu: 3 level: DIE cpu_map: 0-3 tl->mask: 0-3 [0.256006] build_sched_groups: got group f255b020 with cpus: [0.256089] build_sched_groups: got group f255b120 with cpus: [0.256171] build_sched_groups: got group f255b1a0 with cpus: [0.256252] build_sched_groups: got group f255b2a0 with cpus: [0.256333] build_sched_groups: got group f255b2e0 with cpus: [0.256414] build_sched_groups: got group f255b320 with cpus: [0.256495] build_sched_groups: got group f255b360 with cpus: [0.256576] build_sched_groups: got group f255b0e0 with cpus: [0.256657] build_sched_groups: got group f255b160 with cpus: [0.256740] build_sched_groups: got group f255b1e0 with cpus: [0.256821] build_sched_groups: FAIL [0.257004] build_sched_groups: got group f255b1a0 with cpus: 0 [0.257087] build_sched_groups: FAIL [0.257167] build_sched_groups: got group f255b1e0 with cpus: 1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 057/170] tracing: Fix syscall_*regfunc() vs copy_process() race
From: Oleg Nesterov
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 4af4206be2bd1933cae20c2b6fb2058dbc887f7c upstream.
syscall_regfunc() and syscall_unregfunc() should set/clear
TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race
with copy_process() and miss the new child which was not added to
the process/thread lists yet.
Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT
under tasklist.
Link: http://lkml.kernel.org/p/20140413185854.gb20...@redhat.com
Fixes: a871bd33a6c0 "tracing: Add syscall tracepoints"
Acked-by: Frederic Weisbecker
Acked-by: Paul E. McKenney
Signed-off-by: Oleg Nesterov
Signed-off-by: Steven Rostedt
Signed-off-by: Jiri Slaby
---
include/trace/syscall.h | 15 +++
kernel/fork.c | 2 ++
2 files changed, 17 insertions(+)
diff --git a/include/trace/syscall.h b/include/trace/syscall.h
index fed853f3d7aa..9674145e2f6a 100644
--- a/include/trace/syscall.h
+++ b/include/trace/syscall.h
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
@@ -32,4 +33,18 @@ struct syscall_metadata {
struct ftrace_event_call *exit_event;
};
+#if defined(CONFIG_TRACEPOINTS) && defined(CONFIG_HAVE_SYSCALL_TRACEPOINTS)
+static inline void syscall_tracepoint_update(struct task_struct *p)
+{
+ if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
+ set_tsk_thread_flag(p, TIF_SYSCALL_TRACEPOINT);
+ else
+ clear_tsk_thread_flag(p, TIF_SYSCALL_TRACEPOINT);
+}
+#else
+static inline void syscall_tracepoint_update(struct task_struct *p)
+{
+}
+#endif
+
#endif /* _TRACE_SYSCALL_H */
diff --git a/kernel/fork.c b/kernel/fork.c
index c873bd081e09..143962949bed 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1490,7 +1490,9 @@ static struct task_struct *copy_process(unsigned long
clone_flags,
total_forks++;
spin_unlock(>sighand->siglock);
+ syscall_tracepoint_update(p);
write_unlock_irq(_lock);
+
proc_fork_connector(p);
cgroup_post_fork(p);
if (clone_flags & CLONE_THREAD)
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/15] block copy: initial XCOPY offload support
On 07/15/2014 09:34 PM, Mikulas Patocka wrote:
> This is Martin Petersen's xcopy patch
> (https://git.kernel.org/cgit/linux/kernel/git/mkp/linux.git/commit/?h=xcopy=0bdeed274e16b3038a851552188512071974eea8)
> with some bug fixes, ported to the current kernel.
>
> This patch makes it possible to use the SCSI XCOPY command.
>
> We create a bio that has REQ_COPY flag in bi_rw and a bi_copy structure
> that defines the source device. The target device is defined in the
> bi_bdev and bi_iter.bi_sector.
>
> There is a new BLKCOPY ioctl that makes it possible to use XCOPY from
> userspace. The ioctl argument is a pointer to an array of four uint64_t
> values.
>
> The first value is a source byte offset, the second value is a destination
> byte offset, the third value is byte length. The forth value is written by
> the kernel and it represents the number of bytes that the kernel actually
> copied.
>
> Signed-off-by: Martin K. Petersen
> Signed-off-by: Mikulas Patocka
>
> ---
> Documentation/ABI/testing/sysfs-block |9 +
> block/bio.c |2
> block/blk-core.c |5
> block/blk-lib.c | 95
> block/blk-merge.c |7
> block/blk-settings.c | 13 +
> block/blk-sysfs.c | 10 +
> block/compat_ioctl.c |1
> block/ioctl.c | 49 ++
> drivers/scsi/scsi.c | 57 +++
> drivers/scsi/sd.c | 263
> +-
> drivers/scsi/sd.h |4
> include/linux/bio.h |9 -
> include/linux/blk_types.h | 15 +
> include/linux/blkdev.h| 15 +
> include/scsi/scsi_device.h|3
> include/uapi/linux/fs.h |1
> 17 files changed, 545 insertions(+), 13 deletions(-)
>
> Index: linux-3.16-rc5/Documentation/ABI/testing/sysfs-block
> ===
> --- linux-3.16-rc5.orig/Documentation/ABI/testing/sysfs-block 2014-07-14
> 15:17:07.0 +0200
> +++ linux-3.16-rc5/Documentation/ABI/testing/sysfs-block 2014-07-14
> 16:26:44.0 +0200
> @@ -220,3 +220,12 @@ Description:
> write_same_max_bytes is 0, write same is not supported
> by the device.
>
> +
> +What:/sys/block//queue/copy_max_bytes
> +Date:January 2014
> +Contact: Martin K. Petersen
> +Description:
> + Devices that support copy offloading will set this value
> + to indicate the maximum buffer size in bytes that can be
> + copied in one operation. If the copy_max_bytes is 0 the
> + device does not support copy offload.
> Index: linux-3.16-rc5/block/blk-core.c
> ===
> --- linux-3.16-rc5.orig/block/blk-core.c 2014-07-14 16:26:22.0
> +0200
> +++ linux-3.16-rc5/block/blk-core.c 2014-07-14 16:26:44.0 +0200
> @@ -1831,6 +1831,11 @@ generic_make_request_checks(struct bio *
> goto end_io;
> }
>
> + if (bio->bi_rw & REQ_COPY && !bdev_copy_offload(bio->bi_bdev)) {
> + err = -EOPNOTSUPP;
> + goto end_io;
> + }
> +
> /*
>* Various block parts want %current->io_context and lazy ioc
>* allocation ends up trading a lot of pain for a small amount of
> Index: linux-3.16-rc5/block/blk-lib.c
> ===
> --- linux-3.16-rc5.orig/block/blk-lib.c 2014-07-14 16:26:40.0
> +0200
> +++ linux-3.16-rc5/block/blk-lib.c2014-07-14 16:32:21.0 +0200
> @@ -304,3 +304,98 @@ int blkdev_issue_zeroout(struct block_de
> return __blkdev_issue_zeroout(bdev, sector, nr_sects, gfp_mask);
> }
> EXPORT_SYMBOL(blkdev_issue_zeroout);
> +
> +/**
> + * blkdev_issue_copy - queue a copy same operation
> + * @src_bdev:source blockdev
> + * @src_sector: source sector
> + * @dst_bdev:destination blockdev
> + * @dst_sector: destination sector
> + * @nr_sects:number of sectors to copy
> + * @gfp_mask:memory allocation flags (for bio_alloc)
> + *
> + * Description:
> + *Copy a block range from source device to target device.
> + */
> +int blkdev_issue_copy(struct block_device *src_bdev, sector_t src_sector,
> + struct block_device *dst_bdev, sector_t dst_sector,
> + unsigned int nr_sects, gfp_t gfp_mask)
> +{
> + DECLARE_COMPLETION_ONSTACK(wait);
> + struct request_queue *sq = bdev_get_queue(src_bdev);
> + struct request_queue *dq = bdev_get_queue(dst_bdev);
> + unsigned int max_copy_sectors;
> + struct bio_batch bb;
> + int ret = 0;
> +
> + if (!sq || !dq)
> + return -ENXIO;
> +
> + max_copy_sectors =
[PATCH 3.12 105/170] net: allwinner: emac: Add missing free_irq
From: Maxime Ripard
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit b91113282bf44df46aba374a0b8f88a75bfd4b3f upstream.
If the mdio probe function fails in emac_open, the interrupt we just requested
isn't freed. If emac_open is called again, for example because we try to set up
the interface again, the kernel will oops because the interrupt wasn't properly
released.
Signed-off-by: Maxime Ripard
Signed-off-by: David S. Miller
Signed-off-by: Jiri Slaby
---
drivers/net/ethernet/allwinner/sun4i-emac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c
b/drivers/net/ethernet/allwinner/sun4i-emac.c
index 46dfb1378c17..81576c6c31e0 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -726,6 +726,7 @@ static int emac_open(struct net_device *dev)
ret = emac_mdio_probe(dev);
if (ret < 0) {
+ free_irq(dev->irq, dev);
netdev_err(dev, "cannot probe MDIO bus\n");
return ret;
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] HID: rmi: check that report ids exist in the report_id_hash before accessing their size
On Jul 17 2014 or thereabouts, Andrew Duggan wrote:
> It is possible that the hid-rmi driver could get loaded onto a device which
> does not have the
> expected report ids. This should not happen because it would indicate that
> the hid-rmi driver is
> not compatible with that device. However, if it does happen it should return
> an error from probe
> instead of dereferencing a null pointer.
>
> related bug:
> https://bugzilla.kernel.org/show_bug.cgi?id=80091
>
> Signed-off-by: Andrew Duggan
> ---
> Added hid_err messages as suggested by Benjamin. This fixes the null pointer
> dereference from
> bug 80091 while the next patch addresses the binding issue in hid-core.
Reviewed-by: Benjamin Tissoires
Cheers,
Benjamin
>
> drivers/hid/hid-rmi.c | 28 ++--
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> index 3221a95..260be7a 100644
> --- a/drivers/hid/hid-rmi.c
> +++ b/drivers/hid/hid-rmi.c
> @@ -848,6 +848,8 @@ static int rmi_probe(struct hid_device *hdev, const
> struct hid_device_id *id)
> struct rmi_data *data = NULL;
> int ret;
> size_t alloc_size;
> + struct hid_report *input_report;
> + struct hid_report *output_report;
>
> data = devm_kzalloc(>dev, sizeof(struct rmi_data), GFP_KERNEL);
> if (!data)
> @@ -866,12 +868,26 @@ static int rmi_probe(struct hid_device *hdev, const
> struct hid_device_id *id)
> return ret;
> }
>
> - data->input_report_size = (hdev->report_enum[HID_INPUT_REPORT]
> - .report_id_hash[RMI_ATTN_REPORT_ID]->size >> 3)
> - + 1 /* report id */;
> - data->output_report_size = (hdev->report_enum[HID_OUTPUT_REPORT]
> - .report_id_hash[RMI_WRITE_REPORT_ID]->size >> 3)
> - + 1 /* report id */;
> + input_report = hdev->report_enum[HID_INPUT_REPORT]
> + .report_id_hash[RMI_ATTN_REPORT_ID];
> + if (!input_report) {
> + hid_err(hdev, "device does not have expected input report\n");
> + ret = -ENODEV;
> + return ret;
> + }
> +
> + data->input_report_size = (input_report->size >> 3) + 1 /* report id */;
> +
> + output_report = hdev->report_enum[HID_OUTPUT_REPORT]
> + .report_id_hash[RMI_WRITE_REPORT_ID];
> + if (!output_report) {
> + hid_err(hdev, "device does not have expected output report\n");
> + ret = -ENODEV;
> + return ret;
> + }
> +
> + data->output_report_size = (output_report->size >> 3)
> + + 1 /* report id */;
>
> alloc_size = data->output_report_size + data->input_report_size;
>
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 160/170] ext4: fix a potential deadlock in __ext4_es_shrink()
From: Theodore Ts'o
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 3f1f9b851311a76226140b55b1ea22111234a7c2 upstream.
This fixes the following lockdep complaint:
[ INFO: possible circular locking dependency detected ]
3.16.0-rc2-mm1+ #7 Tainted: G O
---
kworker/u24:0/4356 is trying to acquire lock:
(&(>s_es_lru_lock)->rlock){+.+.-.}, at: []
__ext4_es_shrink+0x4f/0x2e0
but task is already holding lock:
(>i_es_lock){-.}, at: []
ext4_es_insert_extent+0x71/0x180
which lock already depends on the new lock.
Possible unsafe locking scenario:
CPU0CPU1
lock(>i_es_lock);
lock(&(>s_es_lru_lock)->rlock);
lock(>i_es_lock);
lock(&(>s_es_lru_lock)->rlock);
*** DEADLOCK ***
6 locks held by kworker/u24:0/4356:
#0: ("writeback"){.+.+.+}, at: []
process_one_work+0x180/0x560
#1: ((&(>dwork)->work)){+.+.+.}, at: []
process_one_work+0x180/0x560
#2: (>s_umount_key#22){++}, at: []
grab_super_passive+0x44/0x90
#3: (jbd2_handle){+.+...}, at: []
start_this_handle+0x189/0x5f0
#4: (>i_data_sem){..}, at: []
ext4_map_blocks+0x132/0x550
#5: (>i_es_lock){-.}, at: []
ext4_es_insert_extent+0x71/0x180
stack backtrace:
CPU: 0 PID: 4356 Comm: kworker/u24:0 Tainted: G O 3.16.0-rc2-mm1+ #7
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Workqueue: writeback bdi_writeback_workfn (flush-253:0)
8213dce0 880014b07538 815df0bb 0007
8213e040 880014b07588 815db3dd 880014b07568
880014b07610 88003b868930 88003b868908 88003b868930
Call Trace:
[] dump_stack+0x4e/0x68
[] print_circular_bug+0x1fb/0x20c
[] __lock_acquire+0x163e/0x1d00
[] ? retint_restore_args+0xe/0xe
[] ? __slab_alloc+0x4a8/0x4ce
[] ? __ext4_es_shrink+0x4f/0x2e0
[] lock_acquire+0x87/0x120
[] ? __ext4_es_shrink+0x4f/0x2e0
[] ? ext4_es_free_extent+0x5d/0x70
[] _raw_spin_lock+0x39/0x50
[] ? __ext4_es_shrink+0x4f/0x2e0
[] ? kmem_cache_alloc+0x18b/0x1a0
[] __ext4_es_shrink+0x4f/0x2e0
[] ext4_es_insert_extent+0xc8/0x180
[] ext4_map_blocks+0x1c4/0x550
[] ext4_writepages+0x6d4/0xd00
...
Reported-by: Minchan Kim
Signed-off-by: Theodore Ts'o
Reported-by: Minchan Kim
Cc: Zheng Liu
Signed-off-by: Jiri Slaby
---
fs/ext4/extents_status.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c
index 3981ff783950..171b9fa0f27a 100644
--- a/fs/ext4/extents_status.c
+++ b/fs/ext4/extents_status.c
@@ -962,10 +962,10 @@ retry:
continue;
}
- if (ei->i_es_lru_nr == 0 || ei == locked_ei)
+ if (ei->i_es_lru_nr == 0 || ei == locked_ei ||
+ !write_trylock(>i_es_lock))
continue;
- write_lock(>i_es_lock);
shrunk = __es_try_to_reclaim_extents(ei, nr_to_scan);
if (ei->i_es_lru_nr == 0)
list_del_init(>i_es_lru);
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 060/170] ibmvscsi: Add memory barriers for send / receive
From: Brian King
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 7114aae02742d6b5c5a0d39a41deb61d415d3717 upstream.
Add a memory barrier prior to sending a new command to the VIOS
to ensure the VIOS does not receive stale data in the command buffer.
Also add a memory barrier when processing the CRQ for completed commands.
Signed-off-by: Brian King
Acked-by: Nathan Fontenot
Signed-off-by: Christoph Hellwig
Signed-off-by: Jiri Slaby
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index c3d4991411b2..c5bb0e0a36b9 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -185,6 +185,11 @@ static struct viosrp_crq *crq_queue_next_crq(struct
crq_queue *queue)
if (crq->valid & 0x80) {
if (++queue->cur == queue->size)
queue->cur = 0;
+
+ /* Ensure the read of the valid bit occurs before reading any
+* other bits of the CRQ entry
+*/
+ rmb();
} else
crq = NULL;
spin_unlock_irqrestore(>lock, flags);
@@ -203,6 +208,11 @@ static int ibmvscsi_send_crq(struct ibmvscsi_host_data
*hostdata,
{
struct vio_dev *vdev = to_vio_dev(hostdata->dev);
+ /*
+* Ensure the command buffer is flushed to memory before handing it
+* over to the VIOS to prevent it from fetching any stale data.
+*/
+ mb();
return plpar_hcall_norets(H_SEND_CRQ, vdev->unit_address, word1, word2);
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 043/170] powerpc: fix typo 'CONFIG_PMAC'
From: Paul Bolle
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 6e0fdf9af216887e0032c19d276889aad41cad00 upstream.
Commit b0d278b7d3ae ("powerpc/perf_event: Reduce latency of calling
perf_event_do_pending") added a check for CONFIG_PMAC were a check for
CONFIG_PPC_PMAC was clearly intended.
Fixes: b0d278b7d3ae ("powerpc/perf_event: Reduce latency of calling
perf_event_do_pending")
Signed-off-by: Paul Bolle
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Jiri Slaby
---
arch/powerpc/kernel/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index b3b144121cc9..62e7f22e57d5 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -512,7 +512,7 @@ void timer_interrupt(struct pt_regs * regs)
__get_cpu_var(irq_stat).timer_irqs++;
-#if defined(CONFIG_PPC32) && defined(CONFIG_PMAC)
+#if defined(CONFIG_PPC32) && defined(CONFIG_PPC_PMAC)
if (atomic_read(_n_lost_interrupts) != 0)
do_IRQ(regs);
#endif
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 062/170] scsi_error: fix invalid setting of host byte
From: Ulrich Obergfell 3.12-stable review patch. If anyone has any objections, please let me know. === commit 8922a908908ff947f1f211e07e2e97f1169ad3cb upstream. After scsi_try_to_abort_cmd returns, the eh_abort_handler may have already found that the command has completed in the device, causing the host_byte to be nonzero (e.g. it could be DID_ABORT). When this happens, ORing DID_TIME_OUT into the host byte will corrupt the result field and initiate an unwanted command retry. Fix this by using set_host_byte instead, following the model of commit 2082ebc45af9c9c648383b8cde0dc1948eadbf31. Signed-off-by: Ulrich Obergfell [Fix all instances according to review comments. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Christoph Hellwig Reviewed-by: Ewan D. Milne Reviewed-by: Hannes Reinecke Signed-off-by: Jiri Slaby --- drivers/scsi/scsi_error.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index 83e591b60193..9ba3642cb19e 100644 --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -143,7 +143,7 @@ enum blk_eh_timer_return scsi_times_out(struct request *req) else if (host->hostt->eh_timed_out) rtn = host->hostt->eh_timed_out(scmd); - scmd->result |= DID_TIME_OUT << 16; + set_host_byte(scmd, DID_TIME_OUT); if (unlikely(rtn == BLK_EH_NOT_HANDLED && !scsi_eh_scmd_add(scmd, SCSI_EH_CANCEL_CMD))) -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 050/170] MIPS: KVM: Remove redundant NULL checks before kfree()
From: James Hogan
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit c6c0a6637f9da54f9472144d44f71cf847f92e20 upstream.
The kfree() function already NULL checks the parameter so remove the
redundant NULL checks before kfree() calls in arch/mips/kvm/.
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Gleb Natapov
Cc: k...@vger.kernel.org
Cc: Ralf Baechle
Cc: linux-m...@linux-mips.org
Cc: Sanjay Lal
Signed-off-by: Paolo Bonzini
Signed-off-by: Jiri Slaby
---
arch/mips/kvm/kvm_mips.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/mips/kvm/kvm_mips.c b/arch/mips/kvm/kvm_mips.c
index b31153969946..8b900e987338 100644
--- a/arch/mips/kvm/kvm_mips.c
+++ b/arch/mips/kvm/kvm_mips.c
@@ -149,9 +149,7 @@ void kvm_mips_free_vcpus(struct kvm *kvm)
if (kvm->arch.guest_pmap[i] != KVM_INVALID_PAGE)
kvm_mips_release_pfn_clean(kvm->arch.guest_pmap[i]);
}
-
- if (kvm->arch.guest_pmap)
- kfree(kvm->arch.guest_pmap);
+ kfree(kvm->arch.guest_pmap);
kvm_for_each_vcpu(i, vcpu, kvm) {
kvm_arch_vcpu_free(vcpu);
@@ -388,12 +386,8 @@ void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
kvm_mips_dump_stats(vcpu);
- if (vcpu->arch.guest_ebase)
- kfree(vcpu->arch.guest_ebase);
-
- if (vcpu->arch.kseg0_commpage)
- kfree(vcpu->arch.kseg0_commpage);
-
+ kfree(vcpu->arch.guest_ebase);
+ kfree(vcpu->arch.kseg0_commpage);
}
void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 084/170] drm/radeon/dpm: fix typo in vddci setup for eg/btc
From: Alex Deucher 3.12-stable review patch. If anyone has any objections, please let me know. === commit e07929810f0a19ddd756558290c7d72827cbfcd9 upstream. We were using the vddc mask rather than the vddci mask. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=79071 Possibly also fixes: https://bugzilla.kernel.org/show_bug.cgi?id=68571 Noticed-by: Jonathan Howard Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby --- drivers/gpu/drm/radeon/cypress_dpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/cypress_dpm.c b/drivers/gpu/drm/radeon/cypress_dpm.c index 91bb470de0a3..7143783fb237 100644 --- a/drivers/gpu/drm/radeon/cypress_dpm.c +++ b/drivers/gpu/drm/radeon/cypress_dpm.c @@ -1549,7 +1549,7 @@ int cypress_populate_smc_voltage_tables(struct radeon_device *rdev, table->voltageMaskTable.highMask[RV770_SMC_VOLTAGEMASK_VDDCI] = 0; table->voltageMaskTable.lowMask[RV770_SMC_VOLTAGEMASK_VDDCI] = - cpu_to_be32(eg_pi->vddc_voltage_table.mask_low); + cpu_to_be32(eg_pi->vddci_voltage_table.mask_low); } return 0; -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 039/170] powerpc/pseries: Fix overwritten PE state
From: Gavin Shan
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 54f112a3837d4e7532bbedbbbf27c0de277be510 upstream.
In pseries_eeh_get_state(), EEH_STATE_UNAVAILABLE is always
overwritten by EEH_STATE_NOT_SUPPORT because of the missed
"break" there. The patch fixes the issue.
Reported-by: Joe Perches
Signed-off-by: Gavin Shan
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Jiri Slaby
---
arch/powerpc/platforms/pseries/eeh_pseries.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c
b/arch/powerpc/platforms/pseries/eeh_pseries.c
index 7fbc25b1813f..74448701b636 100644
--- a/arch/powerpc/platforms/pseries/eeh_pseries.c
+++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
@@ -461,6 +461,7 @@ static int pseries_eeh_get_state(struct eeh_pe *pe, int
*state)
} else {
result = EEH_STATE_NOT_SUPPORT;
}
+ break;
default:
result = EEH_STATE_NOT_SUPPORT;
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 118/170] irqchip: spear_shirq: Fix interrupt offset
From: Thomas Gleixner
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 4f4366033945419b0c52118c29d3057d7c558765 upstream.
The ras3 block on spear320 claims to have 3 interrupts. In fact it has
one and 6 reserved interrupts. Account the 6 reserved to this block so
it has 7 interrupts total. That matches the datasheet and the device
tree entries.
Broken since commit 80515a5a(ARM: SPEAr3xx: shirq: simplify and move
the shared irq multiplexor to DT). Testing is overrated
Signed-off-by: Thomas Gleixner
Link: https://lkml.kernel.org/r/20140619212712.872379...@linutronix.de
Fixes: 80515a5a2e3c ('ARM: SPEAr3xx: shirq: simplify and move the shared irq
multiplexor to DT')
Acked-by: Viresh Kumar
Signed-off-by: Jason Cooper
Signed-off-by: Jiri Slaby
---
drivers/irqchip/spear-shirq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/spear-shirq.c b/drivers/irqchip/spear-shirq.c
index 8527743b5cef..391b9cea73ed 100644
--- a/drivers/irqchip/spear-shirq.c
+++ b/drivers/irqchip/spear-shirq.c
@@ -125,7 +125,7 @@ static struct spear_shirq spear320_shirq_ras2 = {
};
static struct spear_shirq spear320_shirq_ras3 = {
- .irq_nr = 3,
+ .irq_nr = 7,
.irq_bit_off = 0,
.invalid_irq = 1,
.regs = {
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 130/170] USB: serial: ftdi_sio: Add Infineon Triboard
From: Michal Sojka
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit d8279a40e50ad55539780aa617a32a53d7f0953e upstream.
This adds support for Infineon TriBoard TC1798 [1]. Only interface 1
is used as serial line (see [2], Figure 8-6).
[1]
http://www.infineon.com/cms/de/product/microcontroller/development-tools-software-and-kits/tricore-tm-development-tools-software-and-kits/starterkits-and-evaluation-boards/starter-kit-tc1798/channel.html?channel=db3a304333b8a7ca0133cfa3d73e4268
[2]
http://www.infineon.com/dgdl/TriBoardManual-TC1798-V10.pdf?folderId=db3a304412b407950112b409ae7c0343=db3a304333b8a7ca0133cfae99fe426a
Signed-off-by: Michal Sojka
Cc: Johan Hovold
Signed-off-by: Jiri Slaby
---
drivers/usb/serial/ftdi_sio.c | 2 ++
drivers/usb/serial/ftdi_sio_ids.h | 6 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 399fe9fa4db0..e0bf8ee1f976 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -946,6 +946,8 @@ static struct usb_device_id id_table_combined [] = {
{ USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_2_PID) },
{ USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_3_PID) },
{ USB_DEVICE(BRAINBOXES_VID, BRAINBOXES_US_842_4_PID) },
+ /* Infineon Devices */
+ { USB_DEVICE_INTERFACE_NUMBER(INFINEON_VID, INFINEON_TRIBOARD_PID, 1) },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index 106cc16cc6ed..c4777bc6aee0 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -584,6 +584,12 @@
#define RATOC_PRODUCT_ID_USB60F0xb020
/*
+ * Infineon Technologies
+ */
+#define INFINEON_VID 0x058b
+#define INFINEON_TRIBOARD_PID 0x0028 /* DAS JTAG TriBoard TC1798 V1.0 */
+
+/*
* Acton Research Corp.
*/
#define ACTON_VID 0x0647 /* Vendor ID */
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.12 091/170] Bluetooth: Allow change security level on ATT_CID in slave role
From: Marcin Kraglak
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 92d1372e1a9fec00e146b74e8b9ad7a385b9b37f upstream.
Kernel supports SMP Security Request so don't block increasing security
when we are slave.
Signed-off-by: Marcin Kraglak
Acked-by: Johan Hedberg
Signed-off-by: Marcel Holtmann
Signed-off-by: Jiri Slaby
---
net/bluetooth/l2cap_sock.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 07c9aea21244..a3a81d96314b 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -631,11 +631,6 @@ static int l2cap_sock_setsockopt(struct socket *sock, int
level, int optname,
/*change security for LE channels */
if (chan->scid == L2CAP_CID_ATT) {
- if (!conn->hcon->out) {
- err = -EINVAL;
- break;
- }
-
if (smp_conn_security(conn->hcon, sec.level))
break;
sk->sk_state = BT_CONFIG;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] clk: samsung: exynos4x12: Enable ARMCLK down feature
Hi Krzysztof,
On 18.07.2014 11:53, Krzysztof Kozlowski wrote:
> Enable ARMCLK down and up features on Exynos4212 and 4412 SoCs. The
> frequency of ARMCLK will be reduced upon entering idle mode (WFI or
> WFE). Additionally upon exiting from idle mode the divider for ARMCLK
> will be brought back to 1.
>
> These are exactly the same settings as for Exynos5250
> (clk-exynos5250.c), except of Exynos4412 where ARMCLK down is enabled
> for all 4 cores.
Could you add a sentence or two about the purpose of this change? E.g.
what it improves, in what conditions, etc.
>
> Tested on Trats2 board (Exynos4412) and Samsung Gear 1 (Exynos4212).
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/clk/samsung/clk-exynos4.c | 53
> +++
> 1 file changed, 53 insertions(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos4.c
> b/drivers/clk/samsung/clk-exynos4.c
> index 7f4a473a7ad7..b8ea37b23984 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -114,11 +114,34 @@
> #define DIV_CPU1 0x14504
> #define GATE_SCLK_CPU0x14800
> #define GATE_IP_CPU 0x14900
> +#define PWR_CTRL10x15020
> +#define PWR_CTRL20x15024
I guess these registers should be also added to save/restore list below
in this driver.
> #define E4X12_DIV_ISP0 0x18300
> #define E4X12_DIV_ISP1 0x18304
> #define E4X12_GATE_ISP0 0x18800
> #define E4X12_GATE_ISP1 0x18804
>
> +/* Below definitions are used for PWR_CTRL settings */
> +#define PWR_CTRL1_CORE2_DOWN_RATIO (7 << 28)
> +#define PWR_CTRL1_CORE1_DOWN_RATIO (7 << 16)
I think these macros could be defined to take the ratio as its argument,
e.g.
#define PWR_CTRL1_CORE2_DOWN_RATIO(x) ((x) << 28)
> +#define PWR_CTRL1_DIV2_DOWN_EN (1 << 9)
> +#define PWR_CTRL1_DIV1_DOWN_EN (1 << 8)
> +#define PWR_CTRL1_USE_CORE3_WFE (1 << 7)
> +#define PWR_CTRL1_USE_CORE2_WFE (1 << 6)
> +#define PWR_CTRL1_USE_CORE1_WFE (1 << 5)
> +#define PWR_CTRL1_USE_CORE0_WFE (1 << 4)
> +#define PWR_CTRL1_USE_CORE3_WFI (1 << 3)
> +#define PWR_CTRL1_USE_CORE2_WFI (1 << 2)
> +#define PWR_CTRL1_USE_CORE1_WFI (1 << 1)
> +#define PWR_CTRL1_USE_CORE0_WFI (1 << 0)
> +
> +#define PWR_CTRL2_DIV2_UP_EN (1 << 25)
> +#define PWR_CTRL2_DIV1_UP_EN (1 << 24)
> +#define PWR_CTRL2_DUR_STANDBY2_VAL (1 << 16)
> +#define PWR_CTRL2_DUR_STANDBY1_VAL (1 << 8)
These two too.
> +#define PWR_CTRL2_CORE2_UP_RATIO (1 << 4)
> +#define PWR_CTRL2_CORE1_UP_RATIO (1 << 0)
These two as well.
> +
> /* the exynos4 soc type */
> enum exynos4_soc {
> EXYNOS4210,
> @@ -1164,6 +1187,34 @@ static struct samsung_pll_clock
> exynos4x12_plls[nr_plls] __initdata = {
> VPLL_LOCK, VPLL_CON0, NULL),
> };
>
> +static void __init exynos4_core_down_clock(void)
> +{
> + unsigned int tmp;
> +
> + /*
> + * Enable arm clock down (in idle) and set arm divider
> + * ratios in WFI/WFE state.
> + */
> + tmp = (PWR_CTRL1_CORE2_DOWN_RATIO | PWR_CTRL1_CORE1_DOWN_RATIO |
> + PWR_CTRL1_DIV2_DOWN_EN | PWR_CTRL1_DIV1_DOWN_EN |
> + PWR_CTRL1_USE_CORE1_WFE | PWR_CTRL1_USE_CORE0_WFE |
> + PWR_CTRL1_USE_CORE1_WFI | PWR_CTRL1_USE_CORE0_WFI);
> + if (of_machine_is_compatible("samsung,exynos4412"))
Maybe you could use num_possible_cpus() here instead?
> + tmp |= PWR_CTRL1_USE_CORE3_WFE | PWR_CTRL1_USE_CORE2_WFE |
> +PWR_CTRL1_USE_CORE3_WFI | PWR_CTRL1_USE_CORE2_WFI;
> + __raw_writel(tmp, reg_base + PWR_CTRL1);
> +
> + /*
> + * Enable arm clock up (on exiting idle). Set arm divider
> + * ratios when not in idle along with the standby duration
> + * ratios.
> + */
> + tmp = (PWR_CTRL2_DIV2_UP_EN | PWR_CTRL2_DIV1_UP_EN |
> + PWR_CTRL2_DUR_STANDBY2_VAL | PWR_CTRL2_DUR_STANDBY1_VAL |
> + PWR_CTRL2_CORE2_UP_RATIO | PWR_CTRL2_CORE1_UP_RATIO);
> + __raw_writel(tmp, reg_base + PWR_CTRL2);
Do we need the clock up feature at all? The values you set seem to
configure both dividers to 2 (resulting in arm_clk = apll / 4) for a
very short period of time (16 ticks of some, unfortunately unspecified,
clock) between wake-up and setting the frequency back to normal.
Moreover, for certain settings (div_core * div_core2 set to > 4 by
cpufreq) this might cause issues with activating higher frequency than
current voltage allows.
I believe the same comments apply for patch 2/2 as well.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: [PATCH] irqchip: add keystone irq controller ip driver
Grygorii,
On Mon, Jul 14, 2014 at 06:27:57PM +0300, Grygorii Strashko wrote:
> On Keystone SOCs, DSP cores can send interrupts to ARM
> host using the IRQ controller IP. It provides 28 IRQ
> signals to ARM. The IRQ handler running on HOST OS can
> identify DSP signal source by analyzing SRCCx bits in
> IPCARx registers. This is one of the component used by
> the IPC mechanism used on Keystone SOCs.
>
> Signed-off-by: Grygorii Strashko
> ---
> .../interrupt-controller/ti,keystone-irq.txt | 36 +++
> drivers/irqchip/Kconfig|7 +
> drivers/irqchip/Makefile |1 +
> drivers/irqchip/irq-keystone.c | 235
>
> 4 files changed, 279 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.txt
> create mode 100644 drivers/irqchip/irq-keystone.c
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.txt
> b/Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.txt
> new file mode 100644
> index 000..68d27b7
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.txt
> @@ -0,0 +1,36 @@
> +Keystone 2 IRQ controller IP
> +
> +On Keystone SOCs, DSP cores can send interrupts to ARM
> +host using the IRQ controller IP. It provides 28 IRQ signals to ARM.
> +The IRQ handler running on HOST OS can identify DSP signal source by
> +analyzing SRCCx bits in IPCARx registers. This is one of the component
> +used by the IPC mechanism used on Keystone SOCs.
> +
> +Required Properties:
> +- compatible: should be "ti,keystone-irq"
> +- ti,syscon-dev: phandle and offset pair. The phandle to syscon used to
> + access device control registers and the offset inside
> + device control registers range.
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode interrupt
> + source should be 1.
> +- interrupts: interrupt reference to primary interrupt controller
> +
> +Please refer to interrupts.txt in this directory for details of the common
> +Interrupt Controllers bindings used by client devices.
> +
> +Example:
> + kirq0: keystone_irq0@026202a0 {
> + compatible = "ti,keystone-irq";
> + ti,syscon-dev = < 0x2a0>;
> + interrupts = ;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> +
> + dsp0: dsp0 {
> + compatible = "linux,rproc-user";
> + ...
> + interrupt-parent = <>;
> + interrupts = <10 2>;
> + };
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index bbb746e..7f413c4 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -91,3 +91,10 @@ config IRQ_CROSSBAR
> The primary irqchip invokes the crossbar's callback which inturn
> allocates
> a free irq and configures the IP. Thus the peripheral interrupts are
> routed to one of the free irqchip interrupt lines.
> +
> +config KEYSTONE_IRQ
> + tristate "Keystone 2 IRQ controller IP"
> + depends on ARCH_KEYSTONE
> + help
> + Support for Texas Instruments Keystone 2 IRQ controller IP which
> + is part of the Keystone 2 IPC mechanism
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 62a13e5..7d0636b 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -30,3 +30,4 @@ obj-$(CONFIG_XTENSA)+=
> irq-xtensa-pic.o
> obj-$(CONFIG_XTENSA_MX) += irq-xtensa-mx.o
> obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
> obj-$(CONFIG_BRCMSTB_L2_IRQ) += irq-brcmstb-l2.o
> +obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
> diff --git a/drivers/irqchip/irq-keystone.c b/drivers/irqchip/irq-keystone.c
> new file mode 100644
> index 000..309ef74
> --- /dev/null
> +++ b/drivers/irqchip/irq-keystone.c
> @@ -0,0 +1,235 @@
> +/*
> + * Texas Instruments Keystone IRQ controller IP driver
> + *
> + * Copyright (C) 2014 Texas Instruments, Inc.
> + * Author: Sajesh Kumar Saran
> + * Grygorii Strashko
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "irqchip.h"
> +
> +
[PATCH RFC] sched/core: Make idle_cpu return 0 if doing softirq work
The current implementation of idle_cpu only considers tasks that might be in the CPU's runqueue. If there's nothing in the specified CPU's runqueue, it will return 1. But if the CPU is doing work in the softirq context, it is wrong for idle_cpu to return 1. This patch makes it return 0. I observed this to be a problem with a device driver kicking a kthread by executing wake_up from softirq context. The Completely Fair Scheduler's select_task_rq_fair was looking for an "idle sibling" of the CPU executing it by calling select_idle_sibling, passing the executing CPU as the 'target' parameter. The first thing that select_idle_sibling does is to check whether the 'target' CPU is idle, using idle_cpu, and to return that CPU if so. Despite the executing CPU being busy in softirq context, idle_cpu was returning 1, meaning that the scheduler would consistently try to run the kthread on the same CPU as the kick came from. Given that the softirq work was on-going, this led to a multi-millisecond delay before the scheduler eventually realised it should migrate the kthread to a different CPU. A solution to this problem would be to make idle_cpu return 0 when the CPU is running in softirq context. I haven't got a patch for that because I couldn't find an easy way of querying whether an arbitrary CPU is doing this. (Perhaps I should look at the per-CPU softirq_work_list[]...?) Instead, the following patch is a partial solution, only handling the case when the currently-executing CPU is in softirq context. This was sufficient to solve the problem I observed. Signed-off-by: Jonathan Davies --- kernel/sched/core.c | 4 1 file changed, 4 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 7bc599d..4ee58c4 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -3169,6 +3169,10 @@ int idle_cpu(int cpu) return 0; #endif + /* When the current CPU is in softirq context, count it as non-idle */ + if (cpu == smp_processor_id() && in_softirq()) + return 0; + return 1; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
