Re: [PATCH] rtlwifi: rtl8192cu: Fix NULL dereference BUG when using new_id
On Wed, 2013-02-06 at 01:16 +, Ben Hutchings wrote: I don't know why USB differs from PCI, but we do need the dynamic ID here as there are always new IDs being issued. One of the criteria for adding the ID to the table is that it works OK with dynamic addition. These devices are frequently reported by users that do not have the skills to build their own kernel. But since there is no way to set the driver_info for a new USB ID (again, unlike PCI), your change will reject all dynamic IDs. (And in any case, if the USB core were changed to allow setting driver_info, userland would have difficulty providing a valid pointer!) It looks like the driver_info is really driver-specific data used to share a probe function between multiple drivers. But you could add per-driver probe functions that pass the correct rtl_hal_cfg as an extra argument to rtl_usb_probe(), and then dynamic IDs should work. Some (PCI?) drivers had/have numbers instead of pointers, so userland can provide a number and it then looks up the pointer in an array. That's only slightly indirected but makes new_id more useful in that case. johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH stable-3.0] mac80211: synchronize scan off/on-channel and PS states
Hello Stanislaw and Johannes,
This is a back-port patch for stable-3.0 that makes sure all the
callers of ieee80211_offchannel_stop_vifs() and
ieee80211_offchannel_return() having offchannel_ps_disable removed,
and the rest is in-line with the stable-3.7 changes. It can be
applied and built successfully. Could you help ACK/NAK this?
Regards,
CAI Qian
From aacde9ee45225f7e0b90960f479aef83c66bfdc0 Mon Sep 17 00:00:00 2001
From: Stanislaw Gruszka sgrus...@redhat.com
Date: Thu, 20 Dec 2012 14:41:18 +0100
Subject: [PATCH] mac80211: synchronize scan off/on-channel and PS states
Since:
commit b23b025fe246f3acc2988eb6d400df34c27cb8ae
Author: Ben Greear gree...@candelatech.com
Date: Fri Feb 4 11:54:17 2011 -0800
mac80211: Optimize scans on current operating channel.
we do not disable PS while going back to operational channel (on
ieee80211_scan_state_suspend) and deffer that until scan finish.
But since we are allowed to send frames, we can send a frame to AP
without PM bit set, so disable PS on AP side. Then when we switch
to off-channel (in ieee80211_scan_state_resume) we do not enable PS.
Hence we are off-channel with PS disabled, frames are not buffered
by AP.
To fix remove offchannel_ps_disable argument and always enable PS when
going off-channel and disable it when going on-channel, like it was
before.
Cc: stable@vger.kernel.org # 2.6.39+
Signed-off-by: Stanislaw Gruszka sgrus...@redhat.com
Tested-by: Seth Forshee seth.fors...@canonical.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
Signed-off-by: CAI Qian caiq...@redhat.com
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 3fdac77..62b86f0 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1169,11 +1169,9 @@ void ieee80211_sched_scan_stopped_work(struct
work_struct *work);
bool ieee80211_cfg_on_oper_channel(struct ieee80211_local *local);
void ieee80211_offchannel_enable_all_ps(struct ieee80211_local *local,
bool tell_ap);
-void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local,
- bool offchannel_ps_enable);
+void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local);
void ieee80211_offchannel_return(struct ieee80211_local *local,
-bool enable_beaconing,
-bool offchannel_ps_disable);
+bool enable_beaconing);
void ieee80211_hw_roc_setup(struct ieee80211_local *local);
/* interface handling */
diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c
index c55eb9d..ecc4922 100644
--- a/net/mac80211/offchannel.c
+++ b/net/mac80211/offchannel.c
@@ -102,8 +102,7 @@ static void ieee80211_offchannel_ps_disable(struct
ieee80211_sub_if_data *sdata)
ieee80211_sta_reset_conn_monitor(sdata);
}
-void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local,
- bool offchannel_ps_enable)
+void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local)
{
struct ieee80211_sub_if_data *sdata;
@@ -128,8 +127,7 @@ void ieee80211_offchannel_stop_vifs(struct ieee80211_local
*local,
if (sdata-vif.type != NL80211_IFTYPE_MONITOR) {
netif_tx_stop_all_queues(sdata-dev);
- if (offchannel_ps_enable
- (sdata-vif.type == NL80211_IFTYPE_STATION)
+ if (sdata-vif.type == NL80211_IFTYPE_STATION
sdata-u.mgd.associated)
ieee80211_offchannel_ps_enable(sdata, true);
}
@@ -155,8 +153,7 @@ void ieee80211_offchannel_enable_all_ps(struct
ieee80211_local *local,
}
void ieee80211_offchannel_return(struct ieee80211_local *local,
-bool enable_beaconing,
-bool offchannel_ps_disable)
+bool enable_beaconing)
{
struct ieee80211_sub_if_data *sdata;
@@ -166,11 +163,9 @@ void ieee80211_offchannel_return(struct ieee80211_local
*local,
continue;
/* Tell AP we're back */
- if (offchannel_ps_disable
- sdata-vif.type == NL80211_IFTYPE_STATION) {
- if (sdata-u.mgd.associated)
- ieee80211_offchannel_ps_disable(sdata);
- }
+ if (sdata-vif.type == NL80211_IFTYPE_STATION
+ sdata-u.mgd.associated)
+ ieee80211_offchannel_ps_disable(sdata);
if (sdata-vif.type != NL80211_IFTYPE_MONITOR) {
clear_bit(SDATA_STATE_OFFCHANNEL, sdata-state);
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index 669d2e3..7c75741 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -314,7 +314,7 @@ static void __ieee80211_scan_completed(struct ieee80211_hw
[PATCH stable-3.7] ath9k_hw: fix calibration issues on chainmask that don't include chain 0
Hello John and Felix,
This is a back-port patch that just fixed the context to apply to
stable-3.7. Can you please help ACK/NAK it?
Regards,
CAI Qian
From 4a8f199508d79ff8a7d1e22f47b912baaf225336 Mon Sep 17 00:00:00 2001
From: Felix Fietkau n...@openwrt.org
Date: Sun, 20 Jan 2013 21:55:20 +0100
Subject: [PATCH] ath9k_hw: fix calibration issues on chainmask that don't
include chain 0
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau n...@openwrt.org
Signed-off-by: John W. Linville linvi...@tuxdriver.com
Signed-off-by: CAI Qian caiq...@redhat.com
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
index 84b558d..678854a 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
@@ -903,6 +903,8 @@ static bool ar9003_hw_init_cal(struct ath_hw *ah,
AR_PHY_CL_TAB_1,
AR_PHY_CL_TAB_2 };
+ ar9003_hw_set_chain_masks(ah, ah-caps.rx_chainmask,
ah-caps.tx_chainmask);
+
if (rtt) {
if (!ar9003_hw_rtt_restore(ah, chan))
run_rtt_cal = true;
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 8a38ff2..6784986 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -586,7 +586,7 @@ static void ar9003_hw_init_bb(struct ath_hw *ah,
ath9k_hw_synth_delay(ah, chan, synthDelay);
}
-static void ar9003_hw_set_chain_masks(struct ath_hw *ah, u8 rx, u8 tx)
+void ar9003_hw_set_chain_masks(struct ath_hw *ah, u8 rx, u8 tx)
{
if (ah-caps.tx_chainmask == 5 || ah-caps.rx_chainmask == 5)
REG_SET_BIT(ah, AR_PHY_ANALOG_SWAP,
diff --git a/drivers/net/wireless/ath/ath9k/hw.h
b/drivers/net/wireless/ath/ath9k/hw.h
index dbc1b7a..b68aaf5 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -1063,6 +1063,7 @@ int ar9003_paprd_create_curve(struct ath_hw *ah,
int ar9003_paprd_setup_gain_table(struct ath_hw *ah, int chain);
int ar9003_paprd_init_table(struct ath_hw *ah);
bool ar9003_paprd_is_done(struct ath_hw *ah);
+void ar9003_hw_set_chain_masks(struct ath_hw *ah, u8 rx, u8 tx);
/* Hardware family op attach helpers */
void ar5008_hw_attach_phy_ops(struct ath_hw *ah);
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH stable-3.4] ath9k_hw: fix calibration issues on chainmask that don't
John, Felix, context fix only, and also need an ACK/NAK for stable-3.4. :)
Regards,
CAI Qian
From 4a8f199508d79ff8a7d1e22f47b912baaf225336 Mon Sep 17 00:00:00 2001
From: Felix Fietkau n...@openwrt.org
Date: Sun, 20 Jan 2013 21:55:20 +0100
Subject: [PATCH] ath9k_hw: fix calibration issues on chainmask that don't
include chain 0
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau n...@openwrt.org
Signed-off-by: John W. Linville linvi...@tuxdriver.com
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
index 63089cc..9284bca 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
@@ -938,6 +938,8 @@ static bool ar9003_hw_init_cal(struct ath_hw *ah,
AR_PHY_CL_TAB_1,
AR_PHY_CL_TAB_2 };
+ar9003_hw_set_chain_masks(ah, ah-caps.rx_chainmask,
ah-caps.tx_chainmask);
+
if (rtt) {
if (!ar9003_hw_rtt_restore(ah, chan))
run_rtt_cal = true;
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 600aca9..f86ee0c 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -543,7 +543,7 @@ static void ar9003_hw_init_bb(struct ath_hw *ah,
udelay(synthDelay + BASE_ACTIVATE_DELAY);
}
-static void ar9003_hw_set_chain_masks(struct ath_hw *ah, u8 rx, u8 tx)
+void ar9003_hw_set_chain_masks(struct ath_hw *ah, u8 rx, u8 tx)
{
switch (rx) {
case 0x5:
diff --git a/drivers/net/wireless/ath/ath9k/hw.h
b/drivers/net/wireless/ath/ath9k/hw.h
index f8e1fbb..d5c5dca 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -1014,6 +1014,7 @@ int ar9003_paprd_setup_gain_table(struct ath_hw *ah, int
chain);
int ar9003_paprd_init_table(struct ath_hw *ah);
bool ar9003_paprd_is_done(struct ath_hw *ah);
void ar9003_hw_set_paprd_txdesc(struct ath_hw *ah, void *ds, u8 chains);
+void ar9003_hw_set_chain_masks(struct ath_hw *ah, u8 rx, u8 tx);
/* Hardware family op attach helpers */
void ar5008_hw_attach_phy_ops(struct ath_hw *ah);
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] drm/i915: Restore GTT domain tracking of unbound objects upon resume
In order for the objects to be coherent in uncached memory (as they are presumed to be on the unbound list) we need to clflush them because experience dictates that the CPU caches will be dirtied across hibernation. Cc: stable@vger.kernel.org Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk --- drivers/gpu/drm/i915/i915_gem_gtt.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index bdaca3f..368c821 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -404,6 +404,9 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev) i915_gem_gtt_bind_object(obj, obj-cache_level); } + list_for_each_entry(obj, dev_priv-mm.unbound_list, gtt_list) + i915_gem_clflush_object(obj); + i915_gem_chipset_flush(dev); } -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Restore GTT domain tracking of unbound objects upon resume
On Wed, Feb 06, 2013 at 09:31:20AM +, Chris Wilson wrote: In order for the objects to be coherent in uncached memory (as they are presumed to be on the unbound list) we need to clflush them because experience dictates that the CPU caches will be dirtied across hibernation. Cc: stable@vger.kernel.org Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk I think this change will freak out Jesse, since it'll kill resume time when we clflush a few GB of memory. So could you throw another patch on top of this series (maybe after the unbound dropping) which calls restore_gtt only when thawing from hibernate, but not when resuming? --- drivers/gpu/drm/i915/i915_gem_gtt.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index bdaca3f..368c821 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -404,6 +404,9 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev) i915_gem_gtt_bind_object(obj, obj-cache_level); } + list_for_each_entry(obj, dev_priv-mm.unbound_list, gtt_list) + i915_gem_clflush_object(obj); + i915_gem_chipset_flush(dev); } -- 1.7.10.4 ___ Intel-gfx mailing list intel-...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/93] xen: Fix stack corruption in xen_failsafe_callback for 32bit PVOPS guests.
At stated before I'm the author of this patch. Please change the From: to From: Frediano Ziglio frediano.zig...@citrix.com Frediano On Tue, 2013-02-05 at 20:06 -0200, Herton Ronaldo Krzesinski wrote: 3.5.7.5 -stable review patch. If anyone has any objections, please let me know. -- From: Andrew Cooper andrew.coop...@citrix.com commit 9174adbee4a9a49d0139f5d71969852b36720809 upstream. This fixes CVE-2013-0190 / XSA-40 There has been an error on the xen_failsafe_callback path for failed iret, which causes the stack pointer to be wrong when entering the iret_exc error path. This can result in the kernel crashing. In the classic kernel case, the relevant code looked a little like: popl %eax # Error code from hypervisor jz 5f addl $16,%esp jmp iret_exc # Hypervisor said iret fault 5: addl $16,%esp # Hypervisor said segment selector fault Here, there are two identical addls on either option of a branch which appears to have been optimised by hoisting it above the jz, and converting it to an lea, which leaves the flags register unaffected. In the PVOPS case, the code looks like: popl_cfi %eax # Error from the hypervisor lea 16(%esp),%esp # Add $16 before choosing fault path CFI_ADJUST_CFA_OFFSET -16 jz 5f addl $16,%esp # Incorrectly adjust %esp again jmp iret_exc It is possible unprivileged userspace applications to cause this behaviour, for example by loading an LDT code selector, then changing the code selector to be not-present. At this point, there is a race condition where it is possible for the hypervisor to return back to userspace from an interrupt, fault on its own iret, and inject a failsafe_callback into the kernel. This bug has been present since the introduction of Xen PVOPS support in commit 5ead97c84 (xen: Core Xen implementation), in 2.6.23. Signed-off-by: Frediano Ziglio frediano.zig...@citrix.com Signed-off-by: Andrew Cooper andrew.coop...@citrix.com Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com Signed-off-by: Herton Ronaldo Krzesinski herton.krzesin...@canonical.com --- arch/x86/kernel/entry_32.S |1 - 1 file changed, 1 deletion(-) diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S index 8f8e8ee..2a6919e 100644 --- a/arch/x86/kernel/entry_32.S +++ b/arch/x86/kernel/entry_32.S @@ -1065,7 +1065,6 @@ ENTRY(xen_failsafe_callback) lea 16(%esp),%esp CFI_ADJUST_CFA_OFFSET -16 jz 5f - addl $16,%esp jmp iret_exc 5: pushl_cfi $-1 /* orig_ax = -1 = not a system call */ SAVE_ALL
[PATCH] drm/i915: write backlight harder
770c12312ad617172b1a65b911d3e6564fc5aca8 is the first bad commit
commit 770c12312ad617172b1a65b911d3e6564fc5aca8
Author: Takashi Iwai ti...@suse.de
Date: Sat Aug 11 08:56:42 2012 +0200
drm/i915: Fix blank panel at reopening lid
changed the register write sequence for restoring the backlight, which
helped prevent non-working backlights on some machines. Turns out that
the original sequence was the right thing to do for a different set of
machines. Worse, setting the backlight level _after_ enabling it seems
to reset it somehow. So we need to make that one conditional upon the
backlight having been reset to zero, and add the old one back.
Cargo-culting at it's best, but it seems to work.
Cc: stable@vger.kernel.org
Cc: Takashi Iwai ti...@suse.de
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_panel.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index bee8cb6..a3730e0 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -321,6 +321,9 @@ void intel_panel_enable_backlight(struct drm_device *dev,
if (dev_priv-backlight_level == 0)
dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
+ dev_priv-backlight_enabled = true;
+ intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
+
if (INTEL_INFO(dev)-gen = 4) {
uint32_t reg, tmp;
@@ -356,12 +359,12 @@ void intel_panel_enable_backlight(struct drm_device *dev,
}
set_level:
- /* Call below after setting BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1.
-* BLC_PWM_CPU_CTL may be cleared to zero automatically when these
-* registers are set.
+ /* Check the current backlight level and try to set again if it's zero.
+* On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically
+* when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written.
*/
- dev_priv-backlight_enabled = true;
- intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
+ if (!intel_panel_get_backlight(dev))
+ intel_panel_actually_set_backlight(dev,
dev_priv-backlight_level);
}
static void intel_panel_init_backlight(struct drm_device *dev)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/62] block: fix synchronization and limit check in blk_alloc_devt()
On Sat, Feb 02 2013, Tejun Heo wrote: idr allocation in blk_alloc_devt() wasn't synchronized against lookup and removal, and its limit check was off by one - 1 MINORBITS is the number of minors allowed, not the maximum allowed minor. Add locking and rename MAX_EXT_DEVT to NR_EXT_DEVT and fix limit checking. Signed-off-by: Tejun Heo t...@kernel.org Cc: Jens Axboe ax...@kernel.dk Cc: stable@vger.kernel.org Acked-by: Jens Axboe ax...@kernel.dk -- Jens Axboe -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/i915: write backlight harder
At Wed, 6 Feb 2013 11:24:41 +0100,
Daniel Vetter wrote:
770c12312ad617172b1a65b911d3e6564fc5aca8 is the first bad commit
commit 770c12312ad617172b1a65b911d3e6564fc5aca8
Author: Takashi Iwai ti...@suse.de
Date: Sat Aug 11 08:56:42 2012 +0200
drm/i915: Fix blank panel at reopening lid
changed the register write sequence for restoring the backlight, which
helped prevent non-working backlights on some machines. Turns out that
the original sequence was the right thing to do for a different set of
machines. Worse, setting the backlight level _after_ enabling it seems
to reset it somehow. So we need to make that one conditional upon the
backlight having been reset to zero, and add the old one back.
Cargo-culting at it's best, but it seems to work.
Cc: stable@vger.kernel.org
Cc: Takashi Iwai ti...@suse.de
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Feel free to take:
Acked-by: Takashi Iwai ti...@suse.de
thanks,
Takashi
---
drivers/gpu/drm/i915/intel_panel.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index bee8cb6..a3730e0 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -321,6 +321,9 @@ void intel_panel_enable_backlight(struct drm_device *dev,
if (dev_priv-backlight_level == 0)
dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
+ dev_priv-backlight_enabled = true;
+ intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
+
if (INTEL_INFO(dev)-gen = 4) {
uint32_t reg, tmp;
@@ -356,12 +359,12 @@ void intel_panel_enable_backlight(struct drm_device
*dev,
}
set_level:
- /* Call below after setting BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1.
- * BLC_PWM_CPU_CTL may be cleared to zero automatically when these
- * registers are set.
+ /* Check the current backlight level and try to set again if it's zero.
+ * On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically
+ * when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written.
*/
- dev_priv-backlight_enabled = true;
- intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
+ if (!intel_panel_get_backlight(dev))
+ intel_panel_actually_set_backlight(dev,
dev_priv-backlight_level);
}
static void intel_panel_init_backlight(struct drm_device *dev)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH stable-3.0] mac80211: synchronize scan off/on-channel and PS states
Hi On Wed, Feb 06, 2013 at 04:28:20AM -0500, CAI Qian wrote: Hello Stanislaw and Johannes, This is a back-port patch for stable-3.0 that makes sure all the callers of ieee80211_offchannel_stop_vifs() and ieee80211_offchannel_return() having offchannel_ps_disable removed, and the rest is in-line with the stable-3.7 changes. It can be applied and built successfully. Could you help ACK/NAK this? Did you test the patch? I'm not enthusiast of applying modified patches without testing. Otherwise patch _looks_ fine. Stanislaw -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Intel-gfx] [PATCH] drm/i915: write backlight harder
On Wed, 06 Feb 2013, Daniel Vetter daniel.vet...@ffwll.ch wrote:
770c12312ad617172b1a65b911d3e6564fc5aca8 is the first bad commit
commit 770c12312ad617172b1a65b911d3e6564fc5aca8
Author: Takashi Iwai ti...@suse.de
Date: Sat Aug 11 08:56:42 2012 +0200
drm/i915: Fix blank panel at reopening lid
changed the register write sequence for restoring the backlight, which
helped prevent non-working backlights on some machines. Turns out that
the original sequence was the right thing to do for a different set of
machines. Worse, setting the backlight level _after_ enabling it seems
to reset it somehow. So we need to make that one conditional upon the
backlight having been reset to zero, and add the old one back.
Cargo-culting at it's best, but it seems to work.
Cc: stable@vger.kernel.org
Cc: Takashi Iwai ti...@suse.de
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_panel.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index bee8cb6..a3730e0 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -321,6 +321,9 @@ void intel_panel_enable_backlight(struct drm_device *dev,
if (dev_priv-backlight_level == 0)
dev_priv-backlight_level = intel_panel_get_max_backlight(dev);
+ dev_priv-backlight_enabled = true;
+ intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
+
if (INTEL_INFO(dev)-gen = 4) {
uint32_t reg, tmp;
@@ -356,12 +359,12 @@ void intel_panel_enable_backlight(struct drm_device
*dev,
}
set_level:
- /* Call below after setting BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1.
- * BLC_PWM_CPU_CTL may be cleared to zero automatically when these
- * registers are set.
+ /* Check the current backlight level and try to set again if it's zero.
+ * On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically
+ * when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written.
*/
- dev_priv-backlight_enabled = true;
- intel_panel_actually_set_backlight(dev, dev_priv-backlight_level);
+ if (!intel_panel_get_backlight(dev))
+ intel_panel_actually_set_backlight(dev,
dev_priv-backlight_level);
Given how much pain the backlight keeps giving us, do you think we would
benefit from sticking a DRM_DEBUG_DRIVER in the if block there?
Either way, with a heavy *sigh*,
Reviewed-by: Jani Nikula jani.nik...@intel.com
}
static void intel_panel_init_backlight(struct drm_device *dev)
--
1.7.10.4
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 1/1] Drivers: scsi: storvsc: Initialize the sglist
Properly initialize scatterlist before using it.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: stable@vger.kernel.org
---
drivers/scsi/storvsc_drv.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 270b3cf..5ada1d0 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -467,6 +467,7 @@ static struct scatterlist *create_bounce_buffer(struct
scatterlist *sgl,
if (!bounce_sgl)
return NULL;
+ sg_init_table(bounce_sgl, num_pages);
for (i = 0; i num_pages; i++) {
page_buf = alloc_page(GFP_ATOMIC);
if (!page_buf)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/93] xen: Fix stack corruption in xen_failsafe_callback for 32bit PVOPS guests.
On Wed, Feb 06, 2013 at 10:18:54AM +, Frediano Ziglio wrote: At stated before I'm the author of this patch. Please change the From: to From: Frediano Ziglio frediano.zig...@citrix.com Frediano I fixed this in my tree now. But note that the real problem is that this got submitted, included and pushed in mainline with the wrong author, and that's not going to be fixed, since would involve rebasing/rewriting the history there. I just cherry-picked the commit as is from mainline (Linus tree). On Tue, 2013-02-05 at 20:06 -0200, Herton Ronaldo Krzesinski wrote: 3.5.7.5 -stable review patch. If anyone has any objections, please let me know. -- From: Andrew Cooper andrew.coop...@citrix.com commit 9174adbee4a9a49d0139f5d71969852b36720809 upstream. This fixes CVE-2013-0190 / XSA-40 There has been an error on the xen_failsafe_callback path for failed iret, which causes the stack pointer to be wrong when entering the iret_exc error path. This can result in the kernel crashing. In the classic kernel case, the relevant code looked a little like: popl %eax # Error code from hypervisor jz 5f addl $16,%esp jmp iret_exc # Hypervisor said iret fault 5: addl $16,%esp # Hypervisor said segment selector fault Here, there are two identical addls on either option of a branch which appears to have been optimised by hoisting it above the jz, and converting it to an lea, which leaves the flags register unaffected. In the PVOPS case, the code looks like: popl_cfi %eax # Error from the hypervisor lea 16(%esp),%esp # Add $16 before choosing fault path CFI_ADJUST_CFA_OFFSET -16 jz 5f addl $16,%esp # Incorrectly adjust %esp again jmp iret_exc It is possible unprivileged userspace applications to cause this behaviour, for example by loading an LDT code selector, then changing the code selector to be not-present. At this point, there is a race condition where it is possible for the hypervisor to return back to userspace from an interrupt, fault on its own iret, and inject a failsafe_callback into the kernel. This bug has been present since the introduction of Xen PVOPS support in commit 5ead97c84 (xen: Core Xen implementation), in 2.6.23. Signed-off-by: Frediano Ziglio frediano.zig...@citrix.com Signed-off-by: Andrew Cooper andrew.coop...@citrix.com Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com Signed-off-by: Herton Ronaldo Krzesinski herton.krzesin...@canonical.com --- arch/x86/kernel/entry_32.S |1 - 1 file changed, 1 deletion(-) diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S index 8f8e8ee..2a6919e 100644 --- a/arch/x86/kernel/entry_32.S +++ b/arch/x86/kernel/entry_32.S @@ -1065,7 +1065,6 @@ ENTRY(xen_failsafe_callback) lea 16(%esp),%esp CFI_ADJUST_CFA_OFFSET -16 jz 5f - addl $16,%esp jmp iret_exc 5: pushl_cfi $-1 /* orig_ax = -1 = not a system call */ SAVE_ALL -- []'s Herton -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Linux 3.2.38
I'm announcing the release of the 3.2.38 kernel. All users of the 3.2 kernel series should upgrade. The updated 3.2.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.2.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git Ben. Makefile |2 +- arch/arm/kernel/head.S |3 + arch/arm/mach-pxa/include/mach/mfp-pxa27x.h|3 + arch/arm/mach-pxa/pxa27x.c |4 +- arch/arm/mm/dma-mapping.c | 18 +-- arch/arm/vfp/entry.S |6 +- arch/arm/vfp/vfphw.S |4 +- arch/powerpc/kvm/emulate.c |2 + arch/s390/include/asm/timex.h | 28 + arch/s390/kernel/time.c|2 +- arch/s390/kvm/interrupt.c |2 +- arch/sh/include/asm/elf.h |4 +- arch/x86/include/asm/efi.h |1 + arch/x86/include/asm/traps.h | 25 arch/x86/kernel/entry_32.S |1 - arch/x86/kernel/irqinit.c |2 +- arch/x86/kernel/msr.c |3 + arch/x86/kernel/reboot.c |2 +- arch/x86/kernel/setup.c| 103 +++-- arch/x86/kernel/traps.c| 120 +++- arch/x86/platform/efi/efi.c| 38 ++- arch/x86/platform/efi/efi_64.c | 22 +++- drivers/acpi/osl.c |2 +- drivers/acpi/processor_idle.c |4 + drivers/ata/ahci.c |5 +- drivers/block/drbd/drbd_req.c |1 + drivers/block/virtio_blk.c |7 +- drivers/dma/ioat/dma_v3.c |2 +- drivers/edac/edac_pci_sysfs.c |2 +- drivers/firmware/dmi_scan.c| 80 ++--- drivers/firmware/efivars.c |4 +- drivers/firmware/iscsi_ibft_find.c |2 +- drivers/gpu/drm/i915/i915_debugfs.c|2 + drivers/gpu/drm/i915/i915_gem.c|7 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 21 drivers/gpu/drm/i915/i915_reg.h|6 +- drivers/gpu/drm/i915/intel_display.c |4 + drivers/gpu/drm/i915/intel_lvds.c |8 -- drivers/gpu/drm/i915/intel_ringbuffer.c| 23 +++- drivers/gpu/drm/radeon/radeon_cs.c |2 + drivers/gpu/drm/radeon/radeon_device.c |3 +- drivers/gpu/drm/radeon/radeon_legacy_encoders.c|8 ++ drivers/idle/intel_idle.c |7 +- drivers/iommu/amd_iommu_init.c | 34 ++ drivers/iommu/intel-iommu.c| 52 - drivers/net/can/c_can/c_can.c |4 +- drivers/net/can/pch_can.c |2 +- drivers/net/can/ti_hecc.c |4 +- drivers/net/ethernet/intel/igb/igb_main.c | 22 +++- drivers/net/wireless/ath/ath9k/ar9003_calib.c |2 + drivers/net/wireless/ath/ath9k/ar9003_phy.c| 29 ++--- drivers/net/wireless/ath/ath9k/beacon.c|1 + drivers/net/wireless/ath/ath9k/htc_hst.c |2 + drivers/net/wireless/ath/ath9k/hw.h|1 + drivers/net/wireless/ath/ath9k/recv.c | 10 +- .../net/wireless/brcm80211/brcmsmac/mac80211_if.c |7 +- drivers/net/wireless/mwifiex/pcie.c|2 +- drivers/net/wireless/mwifiex/sta_ioctl.c | 29 +++-- drivers/pci/hotplug/pciehp.h |3 +- drivers/pci/hotplug/pciehp_core.c | 20 +--- drivers/pci/hotplug/pciehp_ctrl.c |8 +- drivers/pci/hotplug/pciehp_hpc.c | 12 +- drivers/pci/hotplug/shpchp.h |3 +- drivers/pci/hotplug/shpchp_core.c | 36 +++--- drivers/pci/hotplug/shpchp_ctrl.c |6 +- drivers/pci/pcie/aer/aerdrv_core.c |1 + drivers/pci/pcie/aspm.c|3 + drivers/platform/x86/ibm_rtl.c |2 +- drivers/platform/x86/samsung-laptop.c |4 + drivers/regulator/max8997.c| 36 +++--- drivers/regulator/max8998.c|2 +- drivers/scsi/isci/init.c |2 +- drivers/scsi/sd.c | 13 ++-
Re: [PATCH stable-3.4] ath9k_hw: fix calibration issues on chainmask that don't
Seems fine to me...
Acked-by: John W. Linville linvi...@tuxdriver.com
On Wed, Feb 06, 2013 at 04:31:00AM -0500, CAI Qian wrote:
John, Felix, context fix only, and also need an ACK/NAK for stable-3.4. :)
Regards,
CAI Qian
From 4a8f199508d79ff8a7d1e22f47b912baaf225336 Mon Sep 17 00:00:00 2001
From: Felix Fietkau n...@openwrt.org
Date: Sun, 20 Jan 2013 21:55:20 +0100
Subject: [PATCH] ath9k_hw: fix calibration issues on chainmask that don't
include chain 0
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau n...@openwrt.org
Signed-off-by: John W. Linville linvi...@tuxdriver.com
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
index 63089cc..9284bca 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
@@ -938,6 +938,8 @@ static bool ar9003_hw_init_cal(struct ath_hw *ah,
AR_PHY_CL_TAB_1,
AR_PHY_CL_TAB_2 };
+ar9003_hw_set_chain_masks(ah, ah-caps.rx_chainmask,
ah-caps.tx_chainmask);
+
if (rtt) {
if (!ar9003_hw_rtt_restore(ah, chan))
run_rtt_cal = true;
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 600aca9..f86ee0c 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -543,7 +543,7 @@ static void ar9003_hw_init_bb(struct ath_hw *ah,
udelay(synthDelay + BASE_ACTIVATE_DELAY);
}
-static void ar9003_hw_set_chain_masks(struct ath_hw *ah, u8 rx, u8 tx)
+void ar9003_hw_set_chain_masks(struct ath_hw *ah, u8 rx, u8 tx)
{
switch (rx) {
case 0x5:
diff --git a/drivers/net/wireless/ath/ath9k/hw.h
b/drivers/net/wireless/ath/ath9k/hw.h
index f8e1fbb..d5c5dca 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -1014,6 +1014,7 @@ int ar9003_paprd_setup_gain_table(struct ath_hw *ah,
int chain);
int ar9003_paprd_init_table(struct ath_hw *ah);
bool ar9003_paprd_is_done(struct ath_hw *ah);
void ar9003_hw_set_paprd_txdesc(struct ath_hw *ah, void *ds, u8 chains);
+void ar9003_hw_set_chain_masks(struct ath_hw *ah, u8 rx, u8 tx);
/* Hardware family op attach helpers */
void ar5008_hw_attach_phy_ops(struct ath_hw *ah);
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cgroup: do not duplicate put_css_set
On Wed, Feb 06, 2013 at 07:16:28PM +0400, Maxim Uvarov wrote: linux-3.0.y has put_css_set a litte bit down in the code, this should not be duplicated. Signed-off-by: Maxim Uvarov maxim.uva...@oracle.com --- kernel/cgroup.c | 1 - 1 file changed, 1 deletion(-) formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] rtlwifi: rtl8192cu: Fix NULL dereference BUG when using new_id
When the new_id entry in /sysfs is used for a foreign USB device, rtlwifi
BUGS with a NULL pointer dereference because the per-driver configuration
data is not available. The probe function has been restructured as
suggested by Ben Hutchings bhutchi...@solarflare.com.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
Cc: Stable stable@vger.kernel.org
---
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 8 +++-
drivers/net/wireless/rtlwifi/usb.c | 5 +++--
drivers/net/wireless/rtlwifi/usb.h | 3 ++-
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
index d9e659f..577c0dc 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -363,9 +363,15 @@ static struct usb_device_id rtl8192c_usb_ids[] = {
MODULE_DEVICE_TABLE(usb, rtl8192c_usb_ids);
+static int rtl8192cu_probe(struct usb_interface *intf,
+ const struct usb_device_id *id)
+{
+ return rtl_usb_probe(intf, id, rtl92cu_hal_cfg);
+}
+
static struct usb_driver rtl8192cu_driver = {
.name = rtl8192cu,
- .probe = rtl_usb_probe,
+ .probe = rtl8192cu_probe,
.disconnect = rtl_usb_disconnect,
.id_table = rtl8192c_usb_ids,
diff --git a/drivers/net/wireless/rtlwifi/usb.c
b/drivers/net/wireless/rtlwifi/usb.c
index d42bbe2..476eaef 100644
--- a/drivers/net/wireless/rtlwifi/usb.c
+++ b/drivers/net/wireless/rtlwifi/usb.c
@@ -937,7 +937,8 @@ static struct rtl_intf_ops rtl_usb_ops = {
};
int rtl_usb_probe(struct usb_interface *intf,
- const struct usb_device_id *id)
+ const struct usb_device_id *id,
+ struct rtl_hal_cfg *rtl_hal_cfg)
{
int err;
struct ieee80211_hw *hw = NULL;
@@ -972,7 +973,7 @@ int rtl_usb_probe(struct usb_interface *intf,
usb_set_intfdata(intf, hw);
/* init cfg intf_ops */
rtlpriv-rtlhal.interface = INTF_USB;
- rtlpriv-cfg = (struct rtl_hal_cfg *)(id-driver_info);
+ rtlpriv-cfg = rtl_hal_cfg;
rtlpriv-intf_ops = rtl_usb_ops;
rtl_dbgp_flag_init(hw);
/* Init IO handler */
diff --git a/drivers/net/wireless/rtlwifi/usb.h
b/drivers/net/wireless/rtlwifi/usb.h
index 5235136..fb986f9 100644
--- a/drivers/net/wireless/rtlwifi/usb.h
+++ b/drivers/net/wireless/rtlwifi/usb.h
@@ -157,7 +157,8 @@ struct rtl_usb_priv {
int rtl_usb_probe(struct usb_interface *intf,
- const struct usb_device_id *id);
+ const struct usb_device_id *id,
+ struct rtl_hal_cfg *rtl92cu_hal_cfg);
void rtl_usb_disconnect(struct usb_interface *intf);
int rtl_usb_suspend(struct usb_interface *pusb_intf, pm_message_t message);
int rtl_usb_resume(struct usb_interface *pusb_intf);
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/77] idr: fix a subtle bug in idr_get_next()
The iteration logic of idr_get_next() is borrowed mostly verbatim from
idr_for_each(). It walks down the tree looking for the slot matching
the current ID. If the matching slot is not found, the ID is
incremented by the distance of single slot at the given level and
repeats.
The implementation assumes that during the whole iteration id is
aligned to the layer boundaries of the level closest to the leaf,
which is true for all iterations starting from zero or an existing
element and thus is fine for idr_for_each().
However, idr_get_next() may be given any point and if the starting id
hits in the middle of a non-existent layer, increment to the next
layer will end up skipping the same offset into it. For example, an
IDR with IDs filled between [64, 127] would look like the following.
[ 0 64 ... ]
// |
||
NULL[ 64 ... 127 ]
If idr_get_next() is called with 63 as the starting point, it will try
to follow down the pointer from 0. As it is NULL, it will then try to
proceed to the next slot in the same level by adding the slot distance
at that level which is 64 - making the next try 127. It goes around
the loop and finds and returns 127 skipping [64, 126].
Note that this bug also triggers in idr_for_each_entry() loop which
deletes during iteration as deletions can make layers go away leaving
the iteration with unaligned ID into missing layers.
Fix it by ensuring proceeding to the next slot doesn't carry over the
unaligned offset - ie. use round_up(id + 1, slot_distance) instead of
id += slot_distance.
Signed-off-by: Tejun Heo t...@kernel.org
Reported-by: David Teigland teigl...@redhat.com
Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Cc: stable@vger.kernel.org
---
lib/idr.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/lib/idr.c b/lib/idr.c
index 6482390..ca5aa00 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -625,7 +625,14 @@ void *idr_get_next(struct idr *idp, int *nextidp)
return p;
}
- id += 1 n;
+ /*
+* Proceed to the next layer at the current level. Unlike
+* idr_for_each(), @id isn't guaranteed to be aligned to
+* layer boundary at this point and adding 1 n may
+* incorrectly skip IDs. Make sure we jump to the
+* beginning of the next layer using round_up().
+*/
+ id = round_up(id + 1, 1 n);
while (n fls(id)) {
n += IDR_BITS;
p = *--paa;
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 28/77] firewire: add minor number range check to fw_device_init()
fw_device_init() didn't check whether the allocated minor number isn't
too large. Fail if it goes overflows MINORBITS.
Signed-off-by: Tejun Heo t...@kernel.org
Suggested-by: Stefan Richter stef...@s5r6.in-berlin.de
Acked-by: Stefan Richter stef...@s5r6.in-berlin.de
Cc: stable@vger.kernel.org
---
drivers/firewire/core-device.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/firewire/core-device.c b/drivers/firewire/core-device.c
index 3873d53..af3e8aa 100644
--- a/drivers/firewire/core-device.c
+++ b/drivers/firewire/core-device.c
@@ -1020,6 +1020,10 @@ static void fw_device_init(struct work_struct *work)
ret = idr_pre_get(fw_device_idr, GFP_KERNEL) ?
idr_get_new(fw_device_idr, device, minor) :
-ENOMEM;
+ if (minor = 1 MINORBITS) {
+ idr_remove(fw_device_idr, minor);
+ minor = -ENOSPC;
+ }
up_write(fw_device_rwsem);
if (ret 0)
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 21/77] block: fix synchronization and limit check in blk_alloc_devt()
idr allocation in blk_alloc_devt() wasn't synchronized against lookup
and removal, and its limit check was off by one - 1 MINORBITS is
the number of minors allowed, not the maximum allowed minor.
Add locking and rename MAX_EXT_DEVT to NR_EXT_DEVT and fix limit
checking.
Signed-off-by: Tejun Heo t...@kernel.org
Acked-by: Jens Axboe ax...@kernel.dk
Cc: stable@vger.kernel.org
---
block/genhd.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/block/genhd.c b/block/genhd.c
index 2eb64a3..b1f34d0 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -26,7 +26,7 @@ static DEFINE_MUTEX(block_class_lock);
struct kobject *block_depr;
/* for extended dynamic devt allocation, currently only one major is used */
-#define MAX_EXT_DEVT (1 MINORBITS)
+#define NR_EXT_DEVT(1 MINORBITS)
/* For extended devt allocation. ext_devt_mutex prevents look up
* results from going away underneath its user.
@@ -423,17 +423,18 @@ int blk_alloc_devt(struct hd_struct *part, dev_t *devt)
do {
if (!idr_pre_get(ext_devt_idr, GFP_KERNEL))
return -ENOMEM;
+ mutex_lock(ext_devt_mutex);
rc = idr_get_new(ext_devt_idr, part, idx);
+ if (!rc idx = NR_EXT_DEVT) {
+ idr_remove(ext_devt_idr, idx);
+ rc = -EBUSY;
+ }
+ mutex_unlock(ext_devt_mutex);
} while (rc == -EAGAIN);
if (rc)
return rc;
- if (idx MAX_EXT_DEVT) {
- idr_remove(ext_devt_idr, idx);
- return -EBUSY;
- }
-
*devt = MKDEV(BLOCK_EXT_MAJOR, blk_mangle_minor(idx));
return 0;
}
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cgroup: do not duplicate put_css_set
On Wed, Feb 06, 2013 at 09:43:38AM -0800, Greg KH wrote: On Wed, Feb 06, 2013 at 07:16:28PM +0400, Maxim Uvarov wrote: linux-3.0.y has put_css_set a litte bit down in the code, this should not be duplicated. Signed-off-by: Maxim Uvarov maxim.uva...@oracle.com --- kernel/cgroup.c | 1 - 1 file changed, 1 deletion(-) formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter Greg, it sounds like this is specific to 3.0.y and not needed in mainline. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
+ mm-dont-overwrite-mm-def_flags-in-do_mlockall.patch added to -mm tree
The patch titled
Subject: mm: don't overwrite mm-def_flags in do_mlockall()
has been added to the -mm tree. Its filename is
mm-dont-overwrite-mm-def_flags-in-do_mlockall.patch
Before you just go and hit reply, please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
--
From: Gerald Schaefer gerald.schae...@de.ibm.com
Subject: mm: don't overwrite mm-def_flags in do_mlockall()
With commit 8e72033 thp: make MADV_HUGEPAGE check for mm-def_flags
the VM_NOHUGEPAGE flag may be set on s390 in mm-def_flags for certain
processes, to prevent future thp mappings. This would be overwritten
by do_mlockall(), which sets it back to 0 with an optional VM_LOCKED
flag set.
To fix this, instead of overwriting mm-def_flags in do_mlockall(),
only the VM_LOCKED flag should be set or cleared.
Signed-off-by: Gerald Schaefer gerald.schae...@de.ibm.com
Reported-by: Vivek Goyal vgo...@redhat.com
Cc: Andrea Arcangeli aarca...@redhat.com
Cc: Hugh Dickins hu...@google.com
Cc: Martin Schwidefsky schwidef...@de.ibm.com
Cc: Heiko Carstens heiko.carst...@de.ibm.com
Cc: stable@vger.kernel.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
mm/mlock.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff -puN mm/mlock.c~mm-dont-overwrite-mm-def_flags-in-do_mlockall mm/mlock.c
--- a/mm/mlock.c~mm-dont-overwrite-mm-def_flags-in-do_mlockall
+++ a/mm/mlock.c
@@ -517,11 +517,11 @@ SYSCALL_DEFINE2(munlock, unsigned long,
static int do_mlockall(int flags)
{
struct vm_area_struct * vma, * prev = NULL;
- unsigned int def_flags = 0;
if (flags MCL_FUTURE)
- def_flags = VM_LOCKED;
- current-mm-def_flags = def_flags;
+ current-mm-def_flags |= VM_LOCKED;
+ else
+ current-mm-def_flags = ~VM_LOCKED;
if (flags == MCL_FUTURE)
goto out;
_
Patches currently in -mm which might be from gerald.schae...@de.ibm.com are
mm-dont-overwrite-mm-def_flags-in-do_mlockall.patch
linux-next.patch
ksm-allow-trees-per-numa-node.patch
ksm-add-sysfs-abi-documentation.patch
ksm-trivial-tidyups.patch
ksm-reorganize-ksm_check_stable_tree.patch
ksm-get_ksm_page-locked.patch
ksm-remove-old-stable-nodes-more-thoroughly.patch
ksm-make-ksm-page-migration-possible.patch
ksm-make-merge_across_nodes-migration-safe.patch
ksm-enable-ksm-page-migration.patch
mm-remove-offlining-arg-to-migrate_pages.patch
ksm-stop-hotremove-lockdep-warning.patch
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cgroup: do not duplicate put_css_set
On Wed, Feb 06, 2013 at 08:31:32PM +, Ben Hutchings wrote: On Wed, Feb 06, 2013 at 09:43:38AM -0800, Greg KH wrote: On Wed, Feb 06, 2013 at 07:16:28PM +0400, Maxim Uvarov wrote: linux-3.0.y has put_css_set a litte bit down in the code, this should not be duplicated. Signed-off-by: Maxim Uvarov maxim.uva...@oracle.com --- kernel/cgroup.c | 1 - 1 file changed, 1 deletion(-) formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter Greg, it sounds like this is specific to 3.0.y and not needed in mainline. Ok, then that needs to be stated up front, and I need the ack from the maintainer of the code. Maxim, can you do that? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/77] block: fix synchronization and limit check in blk_alloc_devt()
On Wed, 6 Feb 2013 11:39:53 -0800
Tejun Heo t...@kernel.org wrote:
idr allocation in blk_alloc_devt() wasn't synchronized against lookup
and removal, and its limit check was off by one - 1 MINORBITS is
the number of minors allowed, not the maximum allowed minor.
Add locking and rename MAX_EXT_DEVT to NR_EXT_DEVT and fix limit
checking.
...
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -26,7 +26,7 @@ static DEFINE_MUTEX(block_class_lock);
struct kobject *block_depr;
/* for extended dynamic devt allocation, currently only one major is used */
-#define MAX_EXT_DEVT (1 MINORBITS)
+#define NR_EXT_DEVT (1 MINORBITS)
/* For extended devt allocation. ext_devt_mutex prevents look up
* results from going away underneath its user.
@@ -423,17 +423,18 @@ int blk_alloc_devt(struct hd_struct *part, dev_t *devt)
do {
if (!idr_pre_get(ext_devt_idr, GFP_KERNEL))
return -ENOMEM;
+ mutex_lock(ext_devt_mutex);
rc = idr_get_new(ext_devt_idr, part, idx);
+ if (!rc idx = NR_EXT_DEVT) {
+ idr_remove(ext_devt_idr, idx);
+ rc = -EBUSY;
+ }
+ mutex_unlock(ext_devt_mutex);
} while (rc == -EAGAIN);
if (rc)
return rc;
- if (idx MAX_EXT_DEVT) {
- idr_remove(ext_devt_idr, idx);
- return -EBUSY;
- }
-
*devt = MKDEV(BLOCK_EXT_MAJOR, blk_mangle_minor(idx));
return 0;
}
This gets all tangled up with
http://ozlabs.org/~akpm/mmotm/broken-out/block-fix-ext_devt_idr-handling.patch,
which appears to solve the same issue.
What to do?
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/77] block: fix synchronization and limit check in blk_alloc_devt()
Hello, Andrew. On Wed, Feb 06, 2013 at 02:24:22PM -0800, Andrew Morton wrote: This gets all tangled up with http://ozlabs.org/~akpm/mmotm/broken-out/block-fix-ext_devt_idr-handling.patch, which appears to solve the same issue. What to do? Can you please drop 21 and 22? Everything else shouldn't be affected and we can sort these out later. The actual deprecation patch is held off for now anyway. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/77] block: fix synchronization and limit check in blk_alloc_devt()
On Wed, 6 Feb 2013 14:27:55 -0800 Tejun Heo t...@kernel.org wrote: Hello, Andrew. On Wed, Feb 06, 2013 at 02:24:22PM -0800, Andrew Morton wrote: This gets all tangled up with http://ozlabs.org/~akpm/mmotm/broken-out/block-fix-ext_devt_idr-handling.patch, which appears to solve the same issue. What to do? Can you please drop 21 and 22? Everything else shouldn't be affected and we can sort these out later. The actual deprecation patch is held off for now anyway. hm, I could. Instead I merged your patch on top of Tomas's and marked Tomas's patch for -stable as well. Sound OK? -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/77] block: fix synchronization and limit check in blk_alloc_devt()
Hello, On Wed, Feb 6, 2013 at 2:32 PM, Andrew Morton a...@linux-foundation.org wrote: Can you please drop 21 and 22? Everything else shouldn't be affected and we can sort these out later. The actual deprecation patch is held off for now anyway. hm, I could. Instead I merged your patch on top of Tomas's and marked Tomas's patch for -stable as well. Sound OK? Sure, less work for me. :) -- tejun -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
+ firewire-add-minor-number-range-check-to-fw_device_init.patch added to -mm tree
The patch titled
Subject: firewire: add minor number range check to fw_device_init()
has been added to the -mm tree. Its filename is
firewire-add-minor-number-range-check-to-fw_device_init.patch
Before you just go and hit reply, please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
--
From: Tejun Heo t...@kernel.org
Subject: firewire: add minor number range check to fw_device_init()
fw_device_init() didn't check whether the allocated minor number isn't
too large. Fail if it goes overflows MINORBITS.
Signed-off-by: Tejun Heo t...@kernel.org
Suggested-by: Stefan Richter stef...@s5r6.in-berlin.de
Acked-by: Stefan Richter stef...@s5r6.in-berlin.de
Cc: stable@vger.kernel.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/firewire/core-device.c |4
1 file changed, 4 insertions(+)
diff -puN
drivers/firewire/core-device.c~firewire-add-minor-number-range-check-to-fw_device_init
drivers/firewire/core-device.c
---
a/drivers/firewire/core-device.c~firewire-add-minor-number-range-check-to-fw_device_init
+++ a/drivers/firewire/core-device.c
@@ -1020,6 +1020,10 @@ static void fw_device_init(struct work_s
ret = idr_pre_get(fw_device_idr, GFP_KERNEL) ?
idr_get_new(fw_device_idr, device, minor) :
-ENOMEM;
+ if (minor = 1 MINORBITS) {
+ idr_remove(fw_device_idr, minor);
+ minor = -ENOSPC;
+ }
up_write(fw_device_rwsem);
if (ret 0)
_
Patches currently in -mm which might be from t...@kernel.org are
linux-next.patch
cfq-fix-lock-imbalance-with-failed-allocations.patch
block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
memcg-do-not-create-memsw-files-if-swap-accounting-is-disabled.patch
memcg-clean-up-swap-accounting-initialization-code.patch
memcg-prevent-changes-to-move_charge_at_immigrate-during-task-attach.patch
memcg-split-part-of-memcg-creation-to-css_online.patch
memcg-fast-hierarchy-aware-child-test.patch
memcg-fast-hierarchy-aware-child-test-fix.patch
memcg-replace-cgroup_lock-with-memcg-specific-memcg_lock.patch
memcg-increment-static-branch-right-after-limit-set.patch
memcg-avoid-dangling-reference-count-in-creation-failure.patch
idr-fix-a-subtle-bug-in-idr_get_next.patch
idr-make-idr_destroy-imply-idr_remove_all.patch
atm-nicstar-dont-use-idr_remove_all.patch
block-loop-dont-use-idr_remove_all.patch
firewire-dont-use-idr_remove_all.patch
drm-dont-use-idr_remove_all.patch
dm-dont-use-idr_remove_all.patch
remoteproc-dont-use-idr_remove_all.patch
rpmsg-dont-use-idr_remove_all.patch
dlm-use-idr_for_each_entry-in-recover_idr_clear-error-path.patch
dlm-dont-use-idr_remove_all.patch
nfs-idr_destroy-no-longer-needs-idr_remove_all.patch
inotify-dont-use-idr_remove_all.patch
cgroup-dont-use-idr_remove_all.patch
idr-deprecate-idr_remove_all.patch
idr-cosmetic-updates-to-struct-initializer-definitions.patch
idr-relocate-idr_for_each_entry-and-reorganize-id_get_new.patch
idr-remove-_idr_rc_to_errno-hack.patch
idr-refactor-idr_get_new_above.patch
idr-implement-idr_preload-and-idr_alloc.patch
block-fix-synchronization-and-limit-check-in-blk_alloc_devt.patch
block-convert-to-idr_alloc.patch
block-loop-convert-to-idr_alloc.patch
atm-nicstar-convert-to-idr_alloc.patch
drbd-convert-to-idr_alloc.patch
dca-convert-to-idr_alloc.patch
dmaengine-convert-to-idr_alloc.patch
firewire-add-minor-number-range-check-to-fw_device_init.patch
firewire-convert-to-idr_alloc.patch
gpio-convert-to-idr_alloc.patch
drm-convert-to-idr_alloc.patch
drm-exynos-convert-to-idr_alloc.patch
drm-i915-convert-to-idr_alloc.patch
drm-sis-convert-to-idr_alloc.patch
drm-via-convert-to-idr_alloc.patch
drm-vmwgfx-convert-to-idr_alloc.patch
i2c-convert-to-idr_alloc.patch
ib-core-convert-to-idr_alloc.patch
ib-amso1100-convert-to-idr_alloc.patch
ib-cxgb3-convert-to-idr_alloc.patch
ib-cxgb4-convert-to-idr_alloc.patch
ib-ehca-convert-to-idr_alloc.patch
ib-ipath-convert-to-idr_alloc.patch
ib-mlx4-convert-to-idr_alloc.patch
ib-ocrdma-convert-to-idr_alloc.patch
ib-qib-convert-to-idr_alloc.patch
dm-convert-to-idr_alloc.patch
memstick-convert-to-idr_alloc.patch
mfd-convert-to-idr_alloc.patch
misc-c2port-convert-to-idr_alloc.patch
misc-tifm_core-convert-to-idr_alloc.patch
mmc-convert-to-idr_alloc.patch
mtd-convert-to-idr_alloc.patch
macvtap-convert-to-idr_alloc.patch
ppp-convert-to-idr_alloc.patch
power-convert-to-idr_alloc.patch
pps-convert-to-idr_alloc.patch
remoteproc-convert-to-idr_alloc.patch
rpmsg-convert-to-idr_alloc.patch
scsi-bfa-convert-to-idr_alloc.patch
scsi-convert-to-idr_alloc.patch
+ idr-fix-a-subtle-bug-in-idr_get_next.patch added to -mm tree
The patch titled
Subject: idr: fix a subtle bug in idr_get_next()
has been added to the -mm tree. Its filename is
idr-fix-a-subtle-bug-in-idr_get_next.patch
Before you just go and hit reply, please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
--
From: Tejun Heo t...@kernel.org
Subject: idr: fix a subtle bug in idr_get_next()
The iteration logic of idr_get_next() is borrowed mostly verbatim from
idr_for_each(). It walks down the tree looking for the slot matching
the current ID. If the matching slot is not found, the ID is
incremented by the distance of single slot at the given level and
repeats.
The implementation assumes that during the whole iteration id is
aligned to the layer boundaries of the level closest to the leaf,
which is true for all iterations starting from zero or an existing
element and thus is fine for idr_for_each().
However, idr_get_next() may be given any point and if the starting id
hits in the middle of a non-existent layer, increment to the next
layer will end up skipping the same offset into it. For example, an
IDR with IDs filled between [64, 127] would look like the following.
[ 0 64 ... ]
// |
||
NULL[ 64 ... 127 ]
If idr_get_next() is called with 63 as the starting point, it will try
to follow down the pointer from 0. As it is NULL, it will then try to
proceed to the next slot in the same level by adding the slot distance
at that level which is 64 - making the next try 127. It goes around
the loop and finds and returns 127 skipping [64, 126].
Note that this bug also triggers in idr_for_each_entry() loop which
deletes during iteration as deletions can make layers go away leaving
the iteration with unaligned ID into missing layers.
Fix it by ensuring proceeding to the next slot doesn't carry over the
unaligned offset - ie. use round_up(id + 1, slot_distance) instead of
id += slot_distance.
Signed-off-by: Tejun Heo t...@kernel.org
Reported-by: David Teigland teigl...@redhat.com
Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Cc: stable@vger.kernel.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
lib/idr.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff -puN lib/idr.c~idr-fix-a-subtle-bug-in-idr_get_next lib/idr.c
--- a/lib/idr.c~idr-fix-a-subtle-bug-in-idr_get_next
+++ a/lib/idr.c
@@ -625,7 +625,14 @@ void *idr_get_next(struct idr *idp, int
return p;
}
- id += 1 n;
+ /*
+* Proceed to the next layer at the current level. Unlike
+* idr_for_each(), @id isn't guaranteed to be aligned to
+* layer boundary at this point and adding 1 n may
+* incorrectly skip IDs. Make sure we jump to the
+* beginning of the next layer using round_up().
+*/
+ id = round_up(id + 1, 1 n);
while (n fls(id)) {
n += IDR_BITS;
p = *--paa;
_
Patches currently in -mm which might be from t...@kernel.org are
linux-next.patch
cfq-fix-lock-imbalance-with-failed-allocations.patch
block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
memcg-do-not-create-memsw-files-if-swap-accounting-is-disabled.patch
memcg-clean-up-swap-accounting-initialization-code.patch
memcg-prevent-changes-to-move_charge_at_immigrate-during-task-attach.patch
memcg-split-part-of-memcg-creation-to-css_online.patch
memcg-fast-hierarchy-aware-child-test.patch
memcg-fast-hierarchy-aware-child-test-fix.patch
memcg-replace-cgroup_lock-with-memcg-specific-memcg_lock.patch
memcg-increment-static-branch-right-after-limit-set.patch
memcg-avoid-dangling-reference-count-in-creation-failure.patch
idr-fix-a-subtle-bug-in-idr_get_next.patch
idr-make-idr_destroy-imply-idr_remove_all.patch
atm-nicstar-dont-use-idr_remove_all.patch
block-loop-dont-use-idr_remove_all.patch
firewire-dont-use-idr_remove_all.patch
drm-dont-use-idr_remove_all.patch
dm-dont-use-idr_remove_all.patch
remoteproc-dont-use-idr_remove_all.patch
rpmsg-dont-use-idr_remove_all.patch
dlm-use-idr_for_each_entry-in-recover_idr_clear-error-path.patch
dlm-dont-use-idr_remove_all.patch
nfs-idr_destroy-no-longer-needs-idr_remove_all.patch
inotify-dont-use-idr_remove_all.patch
cgroup-dont-use-idr_remove_all.patch
idr-deprecate-idr_remove_all.patch
idr-cosmetic-updates-to-struct-initializer-definitions.patch
idr-relocate-idr_for_each_entry-and-reorganize-id_get_new.patch
idr-remove-_idr_rc_to_errno-hack.patch
+ block-fix-synchronization-and-limit-check-in-blk_alloc_devt.patch added to -mm tree
The patch titled
Subject: block: fix synchronization and limit check in blk_alloc_devt()
has been added to the -mm tree. Its filename is
block-fix-synchronization-and-limit-check-in-blk_alloc_devt.patch
Before you just go and hit reply, please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
--
From: Tejun Heo t...@kernel.org
Subject: block: fix synchronization and limit check in blk_alloc_devt()
idr allocation in blk_alloc_devt() wasn't synchronized against lookup
and removal, and its limit check was off by one - 1 MINORBITS is
the number of minors allowed, not the maximum allowed minor.
Add locking and rename MAX_EXT_DEVT to NR_EXT_DEVT and fix limit
checking.
Signed-off-by: Tejun Heo t...@kernel.org
Acked-by: Jens Axboe ax...@kernel.dk
Cc: stable@vger.kernel.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
block/genhd.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff -puN
block/genhd.c~block-fix-synchronization-and-limit-check-in-blk_alloc_devt
block/genhd.c
--- a/block/genhd.c~block-fix-synchronization-and-limit-check-in-blk_alloc_devt
+++ a/block/genhd.c
@@ -26,7 +26,7 @@ static DEFINE_MUTEX(block_class_lock);
struct kobject *block_depr;
/* for extended dynamic devt allocation, currently only one major is used */
-#define MAX_EXT_DEVT (1 MINORBITS)
+#define NR_EXT_DEVT(1 MINORBITS)
/* For extended devt allocation. ext_devt_mutex prevents look up
* results from going away underneath its user.
@@ -425,19 +425,16 @@ int blk_alloc_devt(struct hd_struct *par
return -ENOMEM;
mutex_lock(ext_devt_mutex);
rc = idr_get_new(ext_devt_idr, part, idx);
+ if (!rc idx = NR_EXT_DEVT) {
+ idr_remove(ext_devt_idr, idx);
+ rc = -EBUSY;
+ }
mutex_unlock(ext_devt_mutex);
} while (rc == -EAGAIN);
if (rc)
return rc;
- if (idx MAX_EXT_DEVT) {
- mutex_lock(ext_devt_mutex);
- idr_remove(ext_devt_idr, idx);
- mutex_unlock(ext_devt_mutex);
- return -EBUSY;
- }
-
*devt = MKDEV(BLOCK_EXT_MAJOR, blk_mangle_minor(idx));
return 0;
}
_
Patches currently in -mm which might be from t...@kernel.org are
linux-next.patch
cfq-fix-lock-imbalance-with-failed-allocations.patch
block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
memcg-do-not-create-memsw-files-if-swap-accounting-is-disabled.patch
memcg-clean-up-swap-accounting-initialization-code.patch
memcg-prevent-changes-to-move_charge_at_immigrate-during-task-attach.patch
memcg-split-part-of-memcg-creation-to-css_online.patch
memcg-fast-hierarchy-aware-child-test.patch
memcg-fast-hierarchy-aware-child-test-fix.patch
memcg-replace-cgroup_lock-with-memcg-specific-memcg_lock.patch
memcg-increment-static-branch-right-after-limit-set.patch
memcg-avoid-dangling-reference-count-in-creation-failure.patch
idr-fix-a-subtle-bug-in-idr_get_next.patch
idr-make-idr_destroy-imply-idr_remove_all.patch
atm-nicstar-dont-use-idr_remove_all.patch
block-loop-dont-use-idr_remove_all.patch
firewire-dont-use-idr_remove_all.patch
drm-dont-use-idr_remove_all.patch
dm-dont-use-idr_remove_all.patch
remoteproc-dont-use-idr_remove_all.patch
rpmsg-dont-use-idr_remove_all.patch
dlm-use-idr_for_each_entry-in-recover_idr_clear-error-path.patch
dlm-dont-use-idr_remove_all.patch
nfs-idr_destroy-no-longer-needs-idr_remove_all.patch
inotify-dont-use-idr_remove_all.patch
cgroup-dont-use-idr_remove_all.patch
idr-deprecate-idr_remove_all.patch
idr-cosmetic-updates-to-struct-initializer-definitions.patch
idr-relocate-idr_for_each_entry-and-reorganize-id_get_new.patch
idr-remove-_idr_rc_to_errno-hack.patch
idr-refactor-idr_get_new_above.patch
idr-implement-idr_preload-and-idr_alloc.patch
block-fix-synchronization-and-limit-check-in-blk_alloc_devt.patch
block-convert-to-idr_alloc.patch
block-loop-convert-to-idr_alloc.patch
atm-nicstar-convert-to-idr_alloc.patch
drbd-convert-to-idr_alloc.patch
dca-convert-to-idr_alloc.patch
dmaengine-convert-to-idr_alloc.patch
firewire-add-minor-number-range-check-to-fw_device_init.patch
firewire-convert-to-idr_alloc.patch
gpio-convert-to-idr_alloc.patch
drm-convert-to-idr_alloc.patch
drm-exynos-convert-to-idr_alloc.patch
drm-i915-convert-to-idr_alloc.patch
drm-sis-convert-to-idr_alloc.patch
drm-via-convert-to-idr_alloc.patch
drm-vmwgfx-convert-to-idr_alloc.patch
i2c-convert-to-idr_alloc.patch
ib-core-convert-to-idr_alloc.patch
Re: [PATCH] virtio_console: Don't access uninitialized data.
Greg KH gre...@linuxfoundation.org writes: On Wed, Feb 06, 2013 at 10:38:36AM +1030, Rusty Russell wrote: Amit Shah amit.s...@redhat.com writes: On (Mon) 04 Feb 2013 [10:09:05], Rusty Russell wrote: Amit Shah amit.s...@redhat.com writes: On (Thu) 17 Jan 2013 [13:21:32], sjur.brandel...@stericsson.com wrote: From: Sjur Brændeland sjur.brandel...@stericsson.com Don't access uninitialized work-queue when removing device. The work queue is initialized only if the device multi-queue. So don't call cancel_work unless this is a multi-queue device. This fixes the following panic: [snip] Signed-off-by: Sjur Brændeland sjur.brandel...@stericsson.com Acked-by: Amit Shah amit.s...@redhat.com This fix is intended of v3.8. Should also be CC'ed to stable@ ... I've already sent it to Linus. Sjur said: This fix is intended of v3.8.. If it needs to be in -stable, please tell me and I'll fwd it manually. This can result in a panic when removing the device or module (when not using multiport). I'd vote for submitting to stable. Amit OK stable, please cherry-pick from Linus' tree: commit b26ada9abe26290b1dcd06075935b977548c50db Author: Sjur Brændeland sjur.brandel...@stericsson.com Date: Tue Jan 22 09:50:26 2013 +1030 virtio_console: Don't access uninitialized data. $ git show b26ada9abe26290b1dcd06075935b977548c50db fatal: bad object b26ada9abe26290b1dcd06075935b977548c50db What am I missing here? My mistake, Linus has not pulled this. I have added CC:stable, and will request now. Sorry for the noise, Rusty. -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IO_PAGE_FAULTs on unity mapped regions during amd_iommu_init() in Linux 3.4
On Wed, 2013-02-06 at 13:12 +0100, Joerg Roedel wrote: On Tue, Feb 05, 2013 at 06:57:21AM -0700, Shuah Khan wrote: Thanks much. I will hang on to this test system for testing your fix. Okay, here is the simple fix for v3.8-rc6. I guess it is not straighforward to port it to v3.4, but it should be doable. From 2ecf57c85e67e0243b36b787d0490c0b47202ba8 Mon Sep 17 00:00:00 2001 From: Joerg Roedel j...@8bytes.org Date: Wed, 6 Feb 2013 12:55:23 +0100 Subject: [PATCH] iommu/amd: Initialize device table after dma_ops When dma_ops are initialized the unity mappings are created. The init_device_table_dma() function makes sure DMA from all devices is blocked by default. This opens a short window in time where DMA to unity mapped regions is blocked by the IOMMU. Make sure this does not happen by initializing the device table after dma_ops. Signed-off-by: Joerg Roedel j...@8bytes.org Joerg, I tested your patch on 3.8. I was able to reproduce the problem and then apply your patch to verify that the problem is fixed. This patch applies cleanly to 3.7.6, however I could not reproduce the problem on 3.7.6 without the patch. But the window exists on 3.7 as well. Your patch can be applied to 3.7.6 as is. I back-ported the patch to 3.4 and 3.0 and tested. I am sending those patches after this email. On 3.4.29 and 3.0.62 I was able to reproduce the problem and then applied the back-ported patch to verify that the problem is fixed. Thanks again for the fix. -- Shuah -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] amd_iommu: IO_PAGE_FAULTs on unity mapped regions during amd_iommu_init()
When dma_ops are initialized the unity mappings are created. The
init_device_table_dma() function makes sure DMA from all devices is
blocked by default. This opens a short window in time where DMA to
unity mapped regions is blocked by the IOMMU. Make sure this does not
happen by initializing the device table after dma_ops.
Signed-off-by: Shuah Khan shuah.k...@hp.com
CC: stable@vger.kernel.org 3.4
---
drivers/iommu/amd_iommu_init.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index ef0ae93..b573f80 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -1572,8 +1572,6 @@ int __init amd_iommu_init_hardware(void)
if (amd_iommu_pd_alloc_bitmap == NULL)
goto free;
- /* init the device table */
- init_device_table();
/*
* let all alias entries point to itself
@@ -1655,6 +1653,7 @@ out:
*/
static int __init amd_iommu_init(void)
{
+ struct amd_iommu *iommu;
int ret = 0;
ret = amd_iommu_init_hardware();
@@ -1673,6 +1672,12 @@ static int __init amd_iommu_init(void)
if (ret)
goto free;
+ /* init the device table */
+ init_device_table();
+
+ for_each_iommu(iommu)
+ iommu_flush_all_caches(iommu);
+
amd_iommu_init_api();
x86_platform.iommu_shutdown = disable_iommus;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] amd_iommu: IO_PAGE_FAULTs on unity mapped regions during amd_iommu_init()
When dma_ops are initialized the unity mappings are created. The
init_device_table_dma() function makes sure DMA from all devices is
blocked by default. This opens a short window in time where DMA to
unity mapped regions is blocked by the IOMMU. Make sure this does not
happen by initializing the device table after dma_ops.
Reference: http://www.gossamer-threads.com/lists/linux/kernel/1670769
Signed-off-by: Shuah Khan shuah.k...@hp.com
CC: stable@vger.kernel.org 3.0
---
arch/x86/kernel/amd_iommu_init.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/amd_iommu_init.c b/arch/x86/kernel/amd_iommu_init.c
index 33df6e8..d86aa3f 100644
--- a/arch/x86/kernel/amd_iommu_init.c
+++ b/arch/x86/kernel/amd_iommu_init.c
@@ -1363,6 +1363,7 @@ static struct syscore_ops amd_iommu_syscore_ops = {
*/
static int __init amd_iommu_init(void)
{
+ struct amd_iommu *iommu;
int i, ret = 0;
/*
@@ -1411,9 +1412,6 @@ static int __init amd_iommu_init(void)
if (amd_iommu_pd_alloc_bitmap == NULL)
goto free;
- /* init the device table */
- init_device_table();
-
/*
* let all alias entries point to itself
*/
@@ -1463,6 +1461,12 @@ static int __init amd_iommu_init(void)
if (ret)
goto free_disable;
+ /* init the device table */
+ init_device_table();
+
+ for_each_iommu(iommu)
+ iommu_flush_all_caches(iommu);
+
amd_iommu_init_api();
amd_iommu_init_notifier();
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cgroup: do not duplicate put_css_set
CC: Tejun 于 2013/2/6 23:16, Maxim Uvarov wrote: linux-3.0.y has put_css_set a litte bit down in the code, this should not be duplicated. Why do you want to make this change? Have you encountered some kernel bug that relates to cgroup? Signed-off-by: Maxim Uvarov maxim.uva...@oracle.com NAck --- kernel/cgroup.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index 1749dcd..2a08524 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -1777,7 +1777,6 @@ static int cgroup_task_migrate(struct cgroup *cgrp, struct cgroup *oldcgrp, return -ENOMEM; } } - put_css_set(oldcg); This put_css_set() is paired with the code a little above: task_lock(tsk); oldcg = tsk-cgroups; get_css_set(oldcg); task_unlock(tsk); It was added by this commit: commit 77efecd9e0526327548152df715ab8644ecb5ba0 Author: Lai Jiangshan la...@cn.fujitsu.com Date: Wed Jan 7 18:07:39 2009 -0800 cgroups: call find_css_set() safely in cgroup_attach_task() And the put_css_set() at the end of this function is to really drop the ref to tsk-cgroups, as tsk-cgroups will point to @newcg, so @oldcg should be de-referenced. But yeah the comment above the second put_css_set() is confusing: /* * We just gained a reference on oldcg by taking it from the task ... * ... */ I'll fix the comment for mainline. /* if PF_EXITING is set, the tsk-cgroups pointer is no longer safe. */ task_lock(tsk); -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
