[GIT PULL] ARM: soc: late platform updates
Hi Linus, This branch contains late updates to OMAP and Marvell platforms (kirkwood, dove, mvebu) that came in after we had done the big multiplatform merges, so they were kept separate from the rest, and not separated into the traditional topics of cleanup/driver/platform features. They have been included in linux-next: kirkwood since -rc7, OMAP since right when the merge window opened. There will be trivial add/add merge conflicts in drivers/pinctrl/Makefile and Kconfig. For OMAP, the updates are: - Runtime PM conversions for the GPMC and RNG IP blocks - Preparation patches for the OMAP common clock framework conversion - clkdev alias additions required by other drivers - Performance Monitoring Unit (PMU) support for OMAP2, 3, and non-4430 OMAP4 - OMAP hwmod code and data improvements - Preparation patches for the IOMMU runtime PM conversion - Preparation patches for OMAP4 full-chip retention support For Kirkwood/Dove/mvebu: - New driver for "address decoder controller" for mvebu, which is a piece of hardware that configures addressable devices and peripherals. First user is the boot rom aperture on armada XP since it is needed for SMP support. - New device tree bindings for peripherals such as gpio-fan, iconnect nand, mv_cesa and the above address decoder controller. - Some defconfig updates, mostly to enable new DT boards and a few drivers. - New drivers using the pincontrol subsystem for dove, kirkwood and mvebu - New clean gpio driver for mvebu The following changes since commit 8b2d65066100b8df10c6e7805e61751b966045d7: Merge branch 'next/defconfig' into HEAD are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/soc-late for you to fetch changes up to 54d69df5849ec2e660aa12ac75562618c10fb499: Merge branch 'late/kirkwood' into late/soc Afzal Mohammed (3): ARM: OMAP2/3: hwmod data: add gpmc ARM: OMAP2+: gpmc: Adapt to HWMOD ARM: OMAP2+: gpmc: minimal driver support Alan M Butler (1): ARM: Kirkwood: Iomega ix2-200 DT support Andrew Lunn (1): Crypto: CESA: Add support for DT based instantiation. AnilKumar Ch (1): ARM: OMAP2+: AM33XX: clock data: Add clkdev alias for cpu0 Arnaud Patard (2): ARM: Kirkwood: Describe iconnect keys in DT. ARM: Kirkwood: Describe iconnect nand in DT. Benoit Cousson (1): ARM: OMAP4: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs entries Igor Grinberg (1): ARM: OMAP: hwmod code: remove unused hwmod function prototypes Jamie Lentin (3): hwmon: Add devicetree bindings to gpio-fan ARM: kirkwood: Use devicetree to define DNS-32[05] fan ARM: kirkwood: Trim excess #includes in board-dnskw.c Jason Cooper (2): ARM: Kirkwood: update defconfig ARM: Kirkwood: add DT boards to defconfig Jon Hunter (7): ARM: OMAP2420: Cosmetic fix for timer clock aliases ARM: OMAP4: Add timer clock aliases for device-tree ARM: OMAP: Add a timer attribute for timers that can interrupt the DSP ARM: OMAP3: hwmod data: Add debugss HWMOD data ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD ARM: OMAP2+: PMU: Add runtime PM support ARM: OMAP4460/4470: PMU: Enable PMU for OMAP4460/70 Kishon Vijay Abraham I (1): ARM: OMAP4: hwmod data: make *phy_48m* as the main_clk of ocp2scp Michael Jones (1): ARM: OMAP3: clock data: remove obsolete comment Mike Turquette (1): ARM: OMAP4: cm: add bitfield width values Ming Lei (1): ARM: OMAP4430: PMU: prepare to create PMU device via HWMOD Olof Johansson (12): Merge branch 'next/cleanup' into late/kirkwood Merge branch 'next/multiplatform' into late/kirkwood Merge branch 'kirkwood/boards' of git://git.infradead.org/users/jcooper/linux into late/kirkwood Merge branch 'kirkwood/defconfig' of git://git.infradead.org/users/jcooper/linux into late/kirkwood Merge branch 'kirkwood/dt' of git://git.infradead.org/users/jcooper/linux into late/kirkwood Merge branch 'kirkwood/cleanup' of git://git.infradead.org/users/jcooper/linux into late/kirkwood Merge branch 'kirkwood/addr_decode' of git://git.infradead.org/users/jcooper/linux into late/kirkwood Merge branch 'kirkwood/drivers' of git://git.infradead.org/users/jcooper/linux into late/kirkwood ARM: kirkwood: move new dtbs to common Makefile ARM: kirkwood: dockstar: fix header include Merge tag 'omap-devel-late-for-v3.7' of git://git.kernel.org/.../tmlind/linux-omap into late/soc Merge branch 'late/kirkwood' into late/soc Omar Ramirez Luna (5): ARM: OMAP2+: omap_device: expose hwmod assert/deassert to omap devices ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled ARM: OMAP: hwmod: revise deassert sequence ARM: OMAP: iommu: fix
linux-next: manual merge of the arm-soc tree with the arm64 tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm64/include/asm/unistd32.h between commit cce72b4219ee ("arm64:
Use the generic compat_sys_sendfile() implementation") from the arm64
tree and commit 890139529d45 ("UAPI: Fix the guards on various
asm/unistd.h files") from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm64/include/asm/unistd32.h
index ec61180,3ba1f1a..000
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@@ -754,6 -752,3 +752,4 @@@ __SYSCALL(__NR_syncfs, sys_syncfs
#define __ARCH_WANT_SYS_SIGPENDING
#define __ARCH_WANT_SYS_SIGPROCMASK
#define __ARCH_WANT_COMPAT_SYS_RT_SIGSUSPEND
+#define __ARCH_WANT_COMPAT_SYS_SENDFILE
-
- #endif /* __ASM_UNISTD32_H */
pgpnRnjv2XcLU.pgp
Description: PGP signature
Re: [PATCH] CPU hotplug, debug: Detect imbalance between get_online_cpus() and put_online_cpus()
2012/10/04 15:16, Srivatsa S. Bhat wrote:
On 10/04/2012 02:43 AM, Andrew Morton wrote:
On Wed, 03 Oct 2012 18:23:09 +0530
"Srivatsa S. Bhat" wrote:
The synchronization between CPU hotplug readers and writers is achieved by
means of refcounting, safe-guarded by the cpu_hotplug.lock.
get_online_cpus() increments the refcount, whereas put_online_cpus() decrements
it. If we ever hit an imbalance between the two, we end up compromising the
guarantees of the hotplug synchronization i.e, for example, an extra call to
put_online_cpus() can end up allowing a hotplug reader to execute concurrently
with
a hotplug writer. So, add a BUG_ON() in put_online_cpus() to detect such cases
where the refcount can go negative.
Signed-off-by: Srivatsa S. Bhat
---
kernel/cpu.c |1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index f560598..00d29bc 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -80,6 +80,7 @@ void put_online_cpus(void)
if (cpu_hotplug.active_writer == current)
return;
mutex_lock(_hotplug.lock);
+ BUG_ON(cpu_hotplug.refcount == 0);
if (!--cpu_hotplug.refcount && unlikely(cpu_hotplug.active_writer))
wake_up_process(cpu_hotplug.active_writer);
mutex_unlock(_hotplug.lock);
I think calling BUG() here is a bit harsh. We should only do that if
there's a risk to proceeding: a risk of data loss, a reduced ability to
analyse the underlying bug, etc.
But a cpu-hotplug locking imbalance is a really really really minor
problem! So how about we emit a warning then try to fix things up?
That would be better indeed, thanks!
This should increase the chance that the machine will keep running and
so will increase the chance that a user will be able to report the bug
to us.
Yep, sounds good.
---
a/kernel/cpu.c~cpu-hotplug-debug-detect-imbalance-between-get_online_cpus-and-put_online_cpus-fix
+++ a/kernel/cpu.c
@@ -80,9 +80,12 @@ void put_online_cpus(void)
if (cpu_hotplug.active_writer == current)
return;
mutex_lock(_hotplug.lock);
- BUG_ON(cpu_hotplug.refcount == 0);
- if (!--cpu_hotplug.refcount && unlikely(cpu_hotplug.active_writer))
- wake_up_process(cpu_hotplug.active_writer);
+ if (!--cpu_hotplug.refcount) {
This won't catch it. We'll enter this 'if' condition only when
cpu_hotplug.refcount was
decremented to zero. We'll miss out the case when it went negative (which we
intended to detect).
+ if (WARN_ON(cpu_hotplug.refcount == -1))
+ cpu_hotplug.refcount++; /* try to fix things up */
+ if (unlikely(cpu_hotplug.active_writer))
+ wake_up_process(cpu_hotplug.active_writer);
+ }
mutex_unlock(_hotplug.lock);
}
So how about something like below:
-->
From: Srivatsa S. Bhat
Subject: [PATCH] CPU hotplug, debug: Detect imbalance between get_online_cpus()
and put_online_cpus()
The synchronization between CPU hotplug readers and writers is achieved by
means of refcounting, safe-guarded by the cpu_hotplug.lock.
get_online_cpus() increments the refcount, whereas put_online_cpus() decrements
it. If we ever hit an imbalance between the two, we end up compromising the
guarantees of the hotplug synchronization i.e, for example, an extra call to
put_online_cpus() can end up allowing a hotplug reader to execute concurrently
with
a hotplug writer. So, add a WARN_ON() in put_online_cpus() to detect such cases
where the refcount can go negative, and also attempt to fix it up, so that we
can
continue to run.
Signed-off-by: Srivatsa S. Bhat
---
Looks good to me.
Reviewed-by: Yasuaki Ishimatsu
kernel/cpu.c |4
1 file changed, 4 insertions(+)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index f560598..42bd331 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -80,6 +80,10 @@ void put_online_cpus(void)
if (cpu_hotplug.active_writer == current)
return;
mutex_lock(_hotplug.lock);
+
+ if (WARN_ON(!cpu_hotplug.refcount))
+ cpu_hotplug.refcount++; /* try to fix things up */
+
if (!--cpu_hotplug.refcount && unlikely(cpu_hotplug.active_writer))
wake_up_process(cpu_hotplug.active_writer);
mutex_unlock(_hotplug.lock);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] linux-pstore.git
Hello Linus, Please also pull a few pstore updates, The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://git.infradead.org/users/cbou/linux-pstore.git tags/for-v3.7 for you to fetch changes up to 80c9d03c22f13a17df67b4b99a83ed5e9acf6093: pstore: Avoid recursive spinlocks in the oops_in_progress case (2012-09-20 17:04:50 -0700) 1. We no longer ad-hoc to the function tracer "high level" infrastructure and no longer use its debugfs knobs. The change slightly touches kernel/trace directory, but it got the needed ack from Steven Rostedt: http://lkml.org/lkml/2012/8/21/688 2. Added maintainers entry; 3. A bunch of fixes, nothing special. Anton Vorontsov (4): pstore/ram: Fix possible NULL dereference pstore/ram: Mark ramoops_pstore_write_buf() as notrace MAINTAINERS: Add pstore maintainers pstore/ftrace: Convert to its own enable/disable debugfs knob Chuansheng Liu (1): pstore: Avoid recursive spinlocks in the oops_in_progress case Jovi Zhang (1): pstore/ram: Add missing platform_device_unregister Randy Dunlap (1): pstore/ram: Fix printk format warning Documentation/ramoops.txt | 4 +- MAINTAINERS| 12 + fs/pstore/Kconfig | 1 + fs/pstore/ftrace.c | 96 +++- fs/pstore/internal.h | 6 +++ fs/pstore/platform.c | 9 +++- fs/pstore/ram.c| 28 ++- include/linux/pstore.h | 8 --- kernel/trace/trace_functions.c | 15 +- 9 files changed, 139 insertions(+), 40 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] battery-2.6.git
Hello Linus, Here are some battery tree updates for 3.7... The following changes since commit 0848c94fb4a5cc213a7fb0fb3a5721ad6e16f096: mfd: core: Push irqdomain mapping out into devices (2012-09-15 23:22:04 +0200) are available in the git repository at: git://git.infradead.org/battery-2.6.git tags/for-v3.7 for you to fetch changes up to 18766f0936d444fd7ff2e0064bd6e69a89d5c6fc: Merge with upstream to accommodate with MFD changes (2012-09-24 19:12:01 -0700) 1. New drivers: - Marvell 88pm860x charger and battery drivers; - Texas Instruments LP8788 charger driver; 2. Two new power supply properties: whether a battery is authentic, and chargers' maximal currents and voltages; 3. A lot of TI LP8727 Charger cleanups; 4. New features for Charger Manager, mainly now we can disable specific regulators; 5. Random fixes and cleanups for other drivers. Anton Vorontsov (5): da9052-battery: Fix da9052_determine_vc_tbl_index's return value da9030_battery: Don't use 0 as NULL charger-manager: Fix struct charger_desc's misleading comment 88pm860x_battery and charger: Fix a few post-merge issues Merge with upstream to accommodate with MFD changes Axel Lin (1): power_supply: Remove broken mark for da9052-battery Chanwoo Choi (5): charger-manager: Disable regulator when charger cable is detached charger-manager: Use replacement variable to check state of battery charger-manager: Check fully charged state of battery periodically charger-manager: Support limit of maximum possible charger-manager: Add support sysfs entry for charger Dan Carpenter (1): da9052-battery: Don't free IRQ that wasn't requested Devendra Naga (3): lp8727_charger: Unregister power supply at error path of lp8727_register_psy ds2781_battery: Convert to module_platform_driver ds2781_battery: Replace call to kzalloc with devm_kzalloc Fengguang Wu (2): lp8727_charger: Use IRQF_ONESHOT twl4030_charger: Use IRQF_ONESHOT Il Han (1): twl4030_charger: It would be better not to use the 0b-prefix Jett.Zhou (1): power_supply: Enable battery-charger for 88pm860x Julia Lawall (5): ab8500_charger: Fix error return code wm97xx_battery: Fix error return code ab8500_btemp: Fix error return code ab8500_fg: Fix error return code bq27x00_battery: Fix error return code Kim, Milo (23): power_supply: Add new lp8788 charger driver lp8727_charger: Use devm_kzalloc() lp8727_charger: Cleanup _probe() and _remove() lp8727_charger: Fix buggy code of NULL pdata lp8727_charger: Add configurable debouce timer lp8727_charger: Remove unnecessary workqueue thread lp8727_charger: Clean up the interrupt handler lp8727_charger: Clear interrrupts at inital time lp8727_charger: Fix code for getting battery temp lp8727_charger: Use the definition rather than enum lp8727_charger: Clean up lp8727 definitions lp8727_charger: Use specific definition lp8727_charger: Clean up lp8727_is_charger_attached() lp8727_charger: Make lp8727_init_device() shorter lp8727_charger: Make lp8727_ctrl_switch() inline lp8727_charger: Make lp8727_charger_get_propery() simpler lp8727_charger: Return if the battery is discharging lp8727_charger: Clean up lp8727_charger_changed() lp8727_charger: Make some cosmetic changes in lp8727_delayed_func() lp8727_charger: Fix a typo - chg_parm to chg_param lp8727_charger: Add description in the private data lp8727_charger: Fix checkpatch warning lp8727_charger: More pure cosmetic improvements Olof Johansson (1): sbs-battery: Probe should try talking to the device Paul Parsons (2): pda_power: Fix ac_draw usage before it being set pda_power: Remove ac_draw_failed goto and label Ramakrishna Pallala (3): power_supply: Add new power supply AUTHENTIC property power_supply: Add new power supply properties CHARGE_CURRENT/VOLTAGE_MAX smb347-charger: Fix battery status reporting logic for charger faults Documentation/power/power_supply_class.txt |7 + drivers/mfd/88pm860x-core.c| 22 +- drivers/power/88pm860x_battery.c | 1041 ++ drivers/power/88pm860x_charger.c | 746 drivers/power/Kconfig | 20 +- drivers/power/Makefile |3 + drivers/power/ab8500_btemp.c |1 + drivers/power/ab8500_charger.c |1 + drivers/power/ab8500_fg.c |1 + drivers/power/bq27x00_battery.c|3 +- drivers/power/charger-manager.c| 434 - drivers/power/da9030_battery.c |4 +- drivers/power/da9052-battery.c
[PATCH] net: Fix skb_under_panic oops in neigh_resolve_output
From: Ramesh Nagappa
The retry loop in neigh_resolve_output() and neigh_connected_output()
call dev_hard_header() with out reseting the skb to network_header.
This causes the retry to fail with skb_under_panic. The fix is to
reset the network_header within the retry loop.
Signed-off-by: Ramesh Nagappa
Reviewed-by: Shawn Lu
Reviewed-by: Robert Coulson
Reviewed-by: Billie Alsup
---
net/core/neighbour.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 117afaf..f50c542 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1313,6 +1313,7 @@ int neigh_resolve_output(struct neighbour *neigh, struct
sk_buff *skb)
do {
seq = read_seqbegin(>ha_lock);
+ __skb_pull(skb, skb_network_offset(skb));
err = dev_hard_header(skb, dev, ntohs(skb->protocol),
neigh->ha, NULL, skb->len);
} while (read_seqretry(>ha_lock, seq));
@@ -1342,10 +1343,9 @@ int neigh_connected_output(struct neighbour *neigh,
struct sk_buff *skb)
unsigned int seq;
int err;
- __skb_pull(skb, skb_network_offset(skb));
-
do {
seq = read_seqbegin(>ha_lock);
+ __skb_pull(skb, skb_network_offset(skb));
err = dev_hard_header(skb, dev, ntohs(skb->protocol),
neigh->ha, NULL, skb->len);
} while (read_seqretry(>ha_lock, seq));
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the kvm-ppc tree with Linus' tree
Hi Alexander,
Today's linux-next merge of the kvm-ppc tree got a conflict in
include/linux/kvm.h between commit 7a84428af7ca ("KVM: Add resampling
irqfds for level triggered interrupts") from Linus' tree and commit
2b3ac3d5956c ("KVM: PPC: booke: Add watchdog emulation") from the kvm-ppc
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/linux/kvm.h
index 0a6d6ba,99c3c50..000
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@@ -625,7 -628,7 +628,8 @@@ struct kvm_ppc_smmu_info
#ifdef __KVM_HAVE_READONLY_MEM
#define KVM_CAP_READONLY_MEM 81
#endif
-#define KVM_CAP_PPC_BOOKE_WATCHDOG 82
+#define KVM_CAP_IRQFD_RESAMPLE 82
++#define KVM_CAP_PPC_BOOKE_WATCHDOG 83
#ifdef KVM_CAP_IRQ_ROUTING
pgpdL1YXaWXrY.pgp
Description: PGP signature
[PATCH 10/10] memory-hotplug : remove sysfs file of node
From: Wen Congyang
This patch introduces a new function try_offline_node() to
remove sysfs file of node when all memory sections of this
node are removed. If some memory sections of this node are
not removed, this function does nothing.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Yasuaki Ishimatsu
Signed-off-by: Wen Congyang
---
mm/memory_hotplug.c | 54
1 file changed, 54 insertions(+)
Index: linux-3.6/mm/memory_hotplug.c
===
--- linux-3.6.orig/mm/memory_hotplug.c 2012-10-04 18:30:31.767709165 +0900
+++ linux-3.6/mm/memory_hotplug.c 2012-10-04 18:32:46.907842637 +0900
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
@@ -1276,6 +1277,57 @@ int offline_memory(u64 start, u64 size)
return 0;
}
+static int check_cpu_on_node(void *data)
+{
+ struct pglist_data *pgdat = data;
+ int cpu;
+
+ for_each_online_cpu(cpu) {
+ if (cpu_to_node(cpu) == pgdat->node_id)
+ /*
+* the cpu on this node is onlined, and we can't
+* offline this node.
+*/
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
+/* offline the node if all memory sections of this node are removed */
+static void try_offline_node(int nid)
+{
+ unsigned long start_pfn = NODE_DATA(nid)->node_start_pfn;
+ unsigned long end_pfn = start_pfn + NODE_DATA(nid)->node_spanned_pages;
+ unsigned long pfn;
+
+ for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
+ unsigned long section_nr = pfn_to_section_nr(pfn);
+
+ if (!present_section_nr(section_nr))
+ continue;
+
+ if (pfn_to_nid(pfn) != nid)
+ continue;
+
+ /*
+* some memory sections of this node are not removed, and we
+* can't offline node now.
+*/
+ return;
+ }
+
+ if (stop_machine(check_cpu_on_node, NODE_DATA(nid), NULL))
+ return;
+
+ /*
+* all memory sections of this node are removed, we can offline this
+* node now.
+*/
+ node_set_offline(nid);
+ unregister_one_node(nid);
+}
+
int __ref remove_memory(int nid, u64 start, u64 size)
{
int ret = 0;
@@ -1296,6 +1348,8 @@ int __ref remove_memory(int nid, u64 sta
firmware_map_remove(start, start + size, "System RAM");
arch_remove_memory(start, size);
+
+ try_offline_node(nid);
out:
unlock_memory_hotplug();
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/10] memory-hotplug : memory_hotplug: clear zone when removing the memory
When a memory is added, we update zone's and pgdat's start_pfn and
spanned_pages in the function __add_zone(). So we should revert them
when the memory is removed.
The patch adds a new function __remove_zone() to do this.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
Signed-off-by: Yasuaki Ishimatsu
Signed-off-by: Wen Congyang
---
mm/memory_hotplug.c | 207
1 file changed, 207 insertions(+)
Index: linux-3.6/mm/memory_hotplug.c
===
--- linux-3.6.orig/mm/memory_hotplug.c 2012-10-04 18:30:21.182698427 +0900
+++ linux-3.6/mm/memory_hotplug.c 2012-10-04 18:30:31.767709165 +0900
@@ -312,10 +312,213 @@ static int __meminit __add_section(int n
return register_new_memory(nid, __pfn_to_section(phys_start_pfn));
}
+/* find the smallest valid pfn in the range [start_pfn, end_pfn) */
+static int find_smallest_section_pfn(int nid, struct zone *zone,
+unsigned long start_pfn,
+unsigned long end_pfn)
+{
+ struct mem_section *ms;
+
+ for (; start_pfn < end_pfn; start_pfn += PAGES_PER_SECTION) {
+ ms = __pfn_to_section(start_pfn);
+
+ if (unlikely(!valid_section(ms)))
+ continue;
+
+ if (unlikely(pfn_to_nid(start_pfn)) != nid)
+ continue;
+
+ if (zone && zone != page_zone(pfn_to_page(start_pfn)))
+ continue;
+
+ return start_pfn;
+ }
+
+ return 0;
+}
+
+/* find the biggest valid pfn in the range [start_pfn, end_pfn). */
+static int find_biggest_section_pfn(int nid, struct zone *zone,
+ unsigned long start_pfn,
+ unsigned long end_pfn)
+{
+ struct mem_section *ms;
+ unsigned long pfn;
+
+ /* pfn is the end pfn of a memory section. */
+ pfn = end_pfn - 1;
+ for (; pfn >= start_pfn; pfn -= PAGES_PER_SECTION) {
+ ms = __pfn_to_section(pfn);
+
+ if (unlikely(!valid_section(ms)))
+ continue;
+
+ if (unlikely(pfn_to_nid(pfn)) != nid)
+ continue;
+
+ if (zone && zone != page_zone(pfn_to_page(pfn)))
+ continue;
+
+ return pfn;
+ }
+
+ return 0;
+}
+
+static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
+unsigned long end_pfn)
+{
+ unsigned long zone_start_pfn = zone->zone_start_pfn;
+ unsigned long zone_end_pfn = zone->zone_start_pfn + zone->spanned_pages;
+ unsigned long pfn;
+ struct mem_section *ms;
+ int nid = zone_to_nid(zone);
+
+ zone_span_writelock(zone);
+ if (zone_start_pfn == start_pfn) {
+ /*
+* If the section is smallest section in the zone, it need
+* shrink zone->zone_start_pfn and zone->zone_spanned_pages.
+* In this case, we find second smallest valid mem_section
+* for shrinking zone.
+*/
+ pfn = find_smallest_section_pfn(nid, zone, end_pfn,
+ zone_end_pfn);
+ if (pfn) {
+ zone->zone_start_pfn = pfn;
+ zone->spanned_pages = zone_end_pfn - pfn;
+ }
+ } else if (zone_end_pfn == end_pfn) {
+ /*
+* If the section is biggest section in the zone, it need
+* shrink zone->spanned_pages.
+* In this case, we find second biggest valid mem_section for
+* shrinking zone.
+*/
+ pfn = find_biggest_section_pfn(nid, zone, zone_start_pfn,
+ start_pfn);
+ if (pfn)
+ zone->spanned_pages = pfn - zone_start_pfn + 1;
+ }
+
+ /*
+* The section is not biggest or smallest mem_section in the zone, it
+* only creates a hole in the zone. So in this case, we need not
+* change the zone. But perhaps, the zone has only hole data. Thus
+* it check the zone has only hole or not.
+*/
+ pfn = zone_start_pfn;
+ for (; pfn < zone_end_pfn; pfn += PAGES_PER_SECTION) {
+ ms = __pfn_to_section(pfn);
+
+ if (unlikely(!valid_section(ms)))
+ continue;
+
+ if (page_zone(pfn_to_page(pfn)) != zone)
+ continue;
+
+/* If the section is current section, it continues the loop */
+ if (start_pfn == pfn)
+ continue;
+
+ /* If we find valid section, we have
[PATCH 8/10] memory-hotplug : remove page table of x86_64 architecture
From: Wen Congyang
For hot removing memory, we sholud remove page table about the memory.
So the patch searches a page table about the removed memory, and clear
page table.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Yasuaki Ishimatsu
Signed-off-by: Wen Congyang
---
arch/x86/include/asm/pgtable_types.h |1
arch/x86/mm/init_64.c| 147 +++
arch/x86/mm/pageattr.c | 47 +--
3 files changed, 173 insertions(+), 22 deletions(-)
Index: linux-3.6/arch/x86/mm/init_64.c
===
--- linux-3.6.orig/arch/x86/mm/init_64.c2012-10-04 18:30:21.171698416
+0900
+++ linux-3.6/arch/x86/mm/init_64.c 2012-10-04 18:30:27.317704652 +0900
@@ -675,6 +675,151 @@ int arch_add_memory(int nid, u64 start,
}
EXPORT_SYMBOL_GPL(arch_add_memory);
+static void __meminit
+phys_pte_remove(pte_t *pte_page, unsigned long addr, unsigned long end)
+{
+ unsigned pages = 0;
+ int i = pte_index(addr);
+
+ pte_t *pte = pte_page + pte_index(addr);
+
+ for (; i < PTRS_PER_PTE; i++, addr += PAGE_SIZE, pte++) {
+
+ if (addr >= end)
+ break;
+
+ if (!pte_present(*pte))
+ continue;
+
+ pages++;
+ set_pte(pte, __pte(0));
+ }
+
+ update_page_count(PG_LEVEL_4K, -pages);
+}
+
+static void __meminit
+phys_pmd_remove(pmd_t *pmd_page, unsigned long addr, unsigned long end)
+{
+ unsigned long pages = 0, next;
+ int i = pmd_index(addr);
+
+ for (; i < PTRS_PER_PMD; i++, addr = next) {
+ unsigned long pte_phys;
+ pmd_t *pmd = pmd_page + pmd_index(addr);
+ pte_t *pte;
+
+ if (addr >= end)
+ break;
+
+ next = (addr & PMD_MASK) + PMD_SIZE;
+
+ if (!pmd_present(*pmd))
+ continue;
+
+ if (pmd_large(*pmd)) {
+ if ((addr & ~PMD_MASK) == 0 && next <= end) {
+ set_pmd(pmd, __pmd(0));
+ pages++;
+ continue;
+ }
+
+ /*
+* We use 2M page, but we need to remove part of them,
+* so split 2M page to 4K page.
+*/
+ pte = alloc_low_page(_phys);
+ __split_large_page((pte_t *)pmd, addr, pte);
+
+ spin_lock(_mm.page_table_lock);
+ pmd_populate_kernel(_mm, pmd, __va(pte_phys));
+ spin_unlock(_mm.page_table_lock);
+ }
+
+ spin_lock(_mm.page_table_lock);
+ pte = map_low_page((pte_t *)pmd_page_vaddr(*pmd));
+ phys_pte_remove(pte, addr, end);
+ unmap_low_page(pte);
+ spin_unlock(_mm.page_table_lock);
+ }
+ update_page_count(PG_LEVEL_2M, -pages);
+}
+
+static void __meminit
+phys_pud_remove(pud_t *pud_page, unsigned long addr, unsigned long end)
+{
+ unsigned long pages = 0, next;
+ int i = pud_index(addr);
+
+ for (; i < PTRS_PER_PUD; i++, addr = next) {
+ unsigned long pmd_phys;
+ pud_t *pud = pud_page + pud_index(addr);
+ pmd_t *pmd;
+
+ if (addr >= end)
+ break;
+
+ next = (addr & PUD_MASK) + PUD_SIZE;
+
+ if (!pud_present(*pud))
+ continue;
+
+ if (pud_large(*pud)) {
+ if ((addr & ~PUD_MASK) == 0 && next <= end) {
+ set_pud(pud, __pud(0));
+ pages++;
+ continue;
+ }
+
+ /*
+* We use 1G page, but we need to remove part of them,
+* so split 1G page to 2M page.
+*/
+ pmd = alloc_low_page(_phys);
+ __split_large_page((pte_t *)pud, addr, (pte_t *)pmd);
+
+ spin_lock(_mm.page_table_lock);
+ pud_populate(_mm, pud, __va(pmd_phys));
+ spin_unlock(_mm.page_table_lock);
+ }
+
+ pmd = map_low_page(pmd_offset(pud, 0));
+ phys_pmd_remove(pmd, addr, end);
+ unmap_low_page(pmd);
+ __flush_tlb_all();
+ }
+ __flush_tlb_all();
+
+ update_page_count(PG_LEVEL_1G, -pages);
+}
+
+void __meminit
+kernel_physical_mapping_remove(unsigned long start, unsigned long end)
+{
+ unsigned long next;
+
+ start = (unsigned long)__va(start);
+ end = (unsigned
[PATCH 7/10] memory-hotplug : remove memmap of sparse-vmemmap
All pages of virtual mapping in removed memory cannot be freed, since some pages
used as PGD/PUD includes not only removed memory but also other memory. So the
patch checks whether page can be freed or not.
How to check whether page can be freed or not?
1. When removing memory, the page structs of the revmoved memory are filled
with 0FD.
2. All page structs are filled with 0xFD on PT/PMD, PT/PMD can be cleared.
In this case, the page used as PT/PMD can be freed.
Applying patch, __remove_section() of CONFIG_SPARSEMEM_VMEMMAP is integrated
into one. So __remove_section() of CONFIG_SPARSEMEM_VMEMMAP is deleted.
Note: vmemmap_kfree() and vmemmap_free_bootmem() are not implemented for ia64,
ppc, s390, and sparc.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Wen Congyang
Signed-off-by: Yasuaki Ishimatsu
---
arch/ia64/mm/discontig.c |8 +++
arch/powerpc/mm/init_64.c |8 +++
arch/s390/mm/vmem.c |8 +++
arch/sparc/mm/init_64.c |8 +++
arch/x86/mm/init_64.c | 119 ++
include/linux/mm.h|2
mm/memory_hotplug.c | 17 --
mm/sparse.c |5 +
8 files changed, 158 insertions(+), 17 deletions(-)
Index: linux-3.6/arch/ia64/mm/discontig.c
===
--- linux-3.6.orig/arch/ia64/mm/discontig.c 2012-10-04 18:30:15.475692638
+0900
+++ linux-3.6/arch/ia64/mm/discontig.c 2012-10-04 18:30:21.145698389 +0900
@@ -823,6 +823,14 @@ int __meminit vmemmap_populate(struct pa
return vmemmap_populate_basepages(start_page, size, node);
}
+void vmemmap_kfree(struct page *memmap, unsigned long nr_pages)
+{
+}
+
+void vmemmap_free_bootmem(struct page *memmap, unsigned long nr_pages)
+{
+}
+
void register_page_bootmem_memmap(unsigned long section_nr,
struct page *start_page, unsigned long size)
{
Index: linux-3.6/arch/powerpc/mm/init_64.c
===
--- linux-3.6.orig/arch/powerpc/mm/init_64.c2012-10-04 18:30:15.494692657
+0900
+++ linux-3.6/arch/powerpc/mm/init_64.c 2012-10-04 18:30:21.150698394 +0900
@@ -299,6 +299,14 @@ int __meminit vmemmap_populate(struct pa
return 0;
}
+void vmemmap_kfree(struct page *memmap, unsigned long nr_pages)
+{
+}
+
+void vmemmap_free_bootmem(struct page *memmap, unsigned long nr_pages)
+{
+}
+
void register_page_bootmem_memmap(unsigned long section_nr,
struct page *start_page, unsigned long size)
{
Index: linux-3.6/arch/s390/mm/vmem.c
===
--- linux-3.6.orig/arch/s390/mm/vmem.c 2012-10-04 18:30:15.506692670 +0900
+++ linux-3.6/arch/s390/mm/vmem.c 2012-10-04 18:30:21.157698401 +0900
@@ -227,6 +227,14 @@ out:
return ret;
}
+void vmemmap_kfree(struct page *memmap, unsigned long nr_pages)
+{
+}
+
+void vmemmap_free_bootmem(struct page *memmap, unsigned long nr_pages)
+{
+}
+
void register_page_bootmem_memmap(unsigned long section_nr,
struct page *start_page, unsigned long size)
{
Index: linux-3.6/arch/sparc/mm/init_64.c
===
--- linux-3.6.orig/arch/sparc/mm/init_64.c 2012-10-04 18:30:15.512692676
+0900
+++ linux-3.6/arch/sparc/mm/init_64.c 2012-10-04 18:30:21.163698408 +0900
@@ -2078,6 +2078,14 @@ void __meminit vmemmap_populate_print_la
}
}
+void vmemmap_kfree(struct page *memmap, unsigned long nr_pages)
+{
+}
+
+void vmemmap_free_bootmem(struct page *memmap, unsigned long nr_pages)
+{
+}
+
void register_page_bootmem_memmap(unsigned long section_nr,
struct page *start_page, unsigned long size)
{
Index: linux-3.6/arch/x86/mm/init_64.c
===
--- linux-3.6.orig/arch/x86/mm/init_64.c2012-10-04 18:30:15.517692681
+0900
+++ linux-3.6/arch/x86/mm/init_64.c 2012-10-04 18:30:21.171698416 +0900
@@ -993,6 +993,125 @@ vmemmap_populate(struct page *start_page
return 0;
}
+#define PAGE_INUSE 0xFD
+
+unsigned long find_and_clear_pte_page(unsigned long addr, unsigned long end,
+ struct page **pp, int *page_size)
+{
+ pgd_t *pgd;
+ pud_t *pud;
+ pmd_t *pmd;
+ pte_t *pte;
+ void *page_addr;
+ unsigned long next;
+
+ *pp = NULL;
+
+ pgd = pgd_offset_k(addr);
+ if (pgd_none(*pgd))
+ return pgd_addr_end(addr, end);
+
+ pud = pud_offset(pgd, addr);
+ if (pud_none(*pud))
+ return pud_addr_end(addr, end);
+
+ if (!cpu_has_pse) {
+ next = (addr + PAGE_SIZE) & PAGE_MASK;
+ pmd = pmd_offset(pud, addr);
+ if (pmd_none(*pmd))
+
[PATCH 6/10] memory-hotplug : implement register_page_bootmem_info_section of sparse-vmemmap
For removing memmap region of sparse-vmemmap which is allocated bootmem,
memmap region of sparse-vmemmap needs to be registered by get_page_bootmem().
So the patch searches pages of virtual mapping and registers the pages by
get_page_bootmem().
Note: register_page_bootmem_memmap() is not implemented for ia64, ppc, s390,
and sparc.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
Signed-off-by: Wen Congyang
Signed-off-by: Yasuaki Ishimatsu
---
arch/ia64/mm/discontig.c |6
arch/powerpc/mm/init_64.c |6
arch/s390/mm/vmem.c|6
arch/sparc/mm/init_64.c|6
arch/x86/mm/init_64.c | 52 +
include/linux/memory_hotplug.h | 11 +---
include/linux/mm.h |3 +-
mm/memory_hotplug.c| 37 ++---
8 files changed, 113 insertions(+), 14 deletions(-)
Index: linux-3.6/include/linux/memory_hotplug.h
===
--- linux-3.6.orig/include/linux/memory_hotplug.h 2012-10-04
17:15:03.029828127 +0900
+++ linux-3.6/include/linux/memory_hotplug.h2012-10-04 17:15:59.010833688
+0900
@@ -163,17 +163,10 @@ static inline void arch_refresh_nodedata
#endif /* CONFIG_NUMA */
#endif /* CONFIG_HAVE_ARCH_NODEDATA_EXTENSION */
-#ifdef CONFIG_SPARSEMEM_VMEMMAP
-static inline void register_page_bootmem_info_node(struct pglist_data *pgdat)
-{
-}
-static inline void put_page_bootmem(struct page *page)
-{
-}
-#else
extern void register_page_bootmem_info_node(struct pglist_data *pgdat);
extern void put_page_bootmem(struct page *page);
-#endif
+extern void get_page_bootmem(unsigned long ingo, struct page *page,
+unsigned long type);
/*
* Lock for memory hotplug guarantees 1) all callbacks for memory hotplug
Index: linux-3.6/mm/memory_hotplug.c
===
--- linux-3.6.orig/mm/memory_hotplug.c 2012-10-04 17:15:27.213831361 +0900
+++ linux-3.6/mm/memory_hotplug.c 2012-10-04 17:37:00.176401540 +0900
@@ -91,9 +91,8 @@ static void release_memory_resource(stru
}
#ifdef CONFIG_MEMORY_HOTPLUG_SPARSE
-#ifndef CONFIG_SPARSEMEM_VMEMMAP
-static void get_page_bootmem(unsigned long info, struct page *page,
-unsigned long type)
+void get_page_bootmem(unsigned long info, struct page *page,
+ unsigned long type)
{
unsigned long page_type;
@@ -127,6 +126,7 @@ void __ref put_page_bootmem(struct page
}
+#ifndef CONFIG_SPARSEMEM_VMEMMAP
static void register_page_bootmem_info_section(unsigned long start_pfn)
{
unsigned long *usemap, mapsize, section_nr, i;
@@ -160,6 +160,36 @@ static void register_page_bootmem_info_s
get_page_bootmem(section_nr, page, MIX_SECTION_INFO);
}
+#else
+static void register_page_bootmem_info_section(unsigned long start_pfn)
+{
+ unsigned long *usemap, mapsize, section_nr, i;
+ struct mem_section *ms;
+ struct page *page, *memmap;
+
+ if (!pfn_valid(start_pfn))
+ return;
+
+ section_nr = pfn_to_section_nr(start_pfn);
+ ms = __nr_to_section(section_nr);
+
+ memmap = sparse_decode_mem_map(ms->section_mem_map, section_nr);
+
+ page = virt_to_page(memmap);
+ mapsize = sizeof(struct page) * PAGES_PER_SECTION;
+ mapsize = PAGE_ALIGN(mapsize) >> PAGE_SHIFT;
+
+ register_page_bootmem_memmap(section_nr, memmap, PAGES_PER_SECTION);
+
+ usemap = __nr_to_section(section_nr)->pageblock_flags;
+ page = virt_to_page(usemap);
+
+ mapsize = PAGE_ALIGN(usemap_size()) >> PAGE_SHIFT;
+
+ for (i = 0; i < mapsize; i++, page++)
+ get_page_bootmem(section_nr, page, MIX_SECTION_INFO);
+}
+#endif
void register_page_bootmem_info_node(struct pglist_data *pgdat)
{
@@ -202,7 +232,6 @@ void register_page_bootmem_info_node(str
register_page_bootmem_info_section(pfn);
}
}
-#endif /* !CONFIG_SPARSEMEM_VMEMMAP */
static void grow_zone_span(struct zone *zone, unsigned long start_pfn,
unsigned long end_pfn)
Index: linux-3.6/arch/ia64/mm/discontig.c
===
--- linux-3.6.orig/arch/ia64/mm/discontig.c 2012-10-01 08:47:46.0
+0900
+++ linux-3.6/arch/ia64/mm/discontig.c 2012-10-04 17:15:59.209833459 +0900
@@ -822,4 +822,10 @@ int __meminit vmemmap_populate(struct pa
{
return vmemmap_populate_basepages(start_page, size, node);
}
+
+void register_page_bootmem_memmap(unsigned long section_nr,
+ struct page *start_page, unsigned long size)
+{
+ /* TODO */
+}
#endif
Index: linux-3.6/arch/powerpc/mm/init_64.c
[PATCH 5/10] memory-hotplug : memory-hotplug: check page type in get_page_bootmem
The function get_page_bootmem() may be called more than one time to the same
page. There is no need to set page's type, private if the function is not
the first time called to the page.
Note: the patch is just optimization and does not fix any problem.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Wen Congyang
Signed-off-by: Yasuaki Ishimatsu
---
mm/memory_hotplug.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
Index: linux-3.6/mm/memory_hotplug.c
===
--- linux-3.6.orig/mm/memory_hotplug.c 2012-10-04 18:29:58.284676075 +0900
+++ linux-3.6/mm/memory_hotplug.c 2012-10-04 18:30:03.454680542 +0900
@@ -95,10 +95,17 @@ static void release_memory_resource(stru
static void get_page_bootmem(unsigned long info, struct page *page,
unsigned long type)
{
- page->lru.next = (struct list_head *) type;
- SetPagePrivate(page);
- set_page_private(page, info);
- atomic_inc(>_count);
+ unsigned long page_type;
+
+ page_type = (unsigned long)page->lru.next;
+ if (page_type < MEMORY_HOTPLUG_MIN_BOOTMEM_TYPE ||
+ page_type > MEMORY_HOTPLUG_MAX_BOOTMEM_TYPE){
+ page->lru.next = (struct list_head *)type;
+ SetPagePrivate(page);
+ set_page_private(page, info);
+ atomic_inc(>_count);
+ } else
+ atomic_inc(>_count);
}
/* reference to __meminit __free_pages_bootmem is valid
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/10] memory-hotplug : unregister memory section on SPARSEMEM_VMEMMAP
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Wen Congyang
Signed-off-by: Yasuaki Ishimatsu
---
mm/memory_hotplug.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
Index: linux-3.6/mm/memory_hotplug.c
===
--- linux-3.6.orig/mm/memory_hotplug.c 2012-10-04 18:29:50.577668254 +0900
+++ linux-3.6/mm/memory_hotplug.c 2012-10-04 18:29:58.284676075 +0900
@@ -279,11 +279,14 @@ static int __meminit __add_section(int n
#ifdef CONFIG_SPARSEMEM_VMEMMAP
static int __remove_section(struct zone *zone, struct mem_section *ms)
{
- /*
-* XXX: Freeing memmap with vmemmap is not implement yet.
-* This should be removed later.
-*/
- return -EBUSY;
+ int ret = -EINVAL;
+
+ if (!valid_section(ms))
+ return ret;
+
+ ret = unregister_memory_section(ms);
+
+ return ret;
}
#else
static int __remove_section(struct zone *zone, struct mem_section *ms)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/10] memory-hotplug : introduce new function arch_remove_memory() for removing page table depends on architecture
From: Wen Congyang
For removing memory, we need to remove page table. But it depends
on architecture. So the patch introduce arch_remove_memory() for
removing page table. Now it only calls __remove_pages().
Note: __remove_pages() for some archtecuture is not implemented
(I don't know how to implement it for s390).
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Yasuaki Ishimatsu
Signed-off-by: Wen Congyang
---
arch/ia64/mm/init.c| 18 ++
arch/powerpc/mm/mem.c | 12
arch/s390/mm/init.c| 12
arch/sh/mm/init.c | 17 +
arch/tile/mm/init.c|8
arch/x86/mm/init_32.c | 12
arch/x86/mm/init_64.c | 15 +++
include/linux/memory_hotplug.h |1 +
mm/memory_hotplug.c|1 +
9 files changed, 96 insertions(+)
Index: linux-3.6/arch/ia64/mm/init.c
===
--- linux-3.6.orig/arch/ia64/mm/init.c 2012-10-04 18:27:03.082498276 +0900
+++ linux-3.6/arch/ia64/mm/init.c 2012-10-04 18:28:50.087606867 +0900
@@ -688,6 +688,24 @@ int arch_add_memory(int nid, u64 start,
return ret;
}
+
+#ifdef CONFIG_MEMORY_HOTREMOVE
+int arch_remove_memory(u64 start, u64 size)
+{
+ unsigned long start_pfn = start >> PAGE_SHIFT;
+ unsigned long nr_pages = size >> PAGE_SHIFT;
+ struct zone *zone;
+ int ret;
+
+ zone = page_zone(pfn_to_page(start_pfn));
+ ret = __remove_pages(zone, start_pfn, nr_pages);
+ if (ret)
+ pr_warn("%s: Problem encountered in __remove_pages() as"
+ " ret=%d\n", __func__, ret);
+
+ return ret;
+}
+#endif
#endif
/*
Index: linux-3.6/arch/powerpc/mm/mem.c
===
--- linux-3.6.orig/arch/powerpc/mm/mem.c2012-10-04 18:27:03.084498278
+0900
+++ linux-3.6/arch/powerpc/mm/mem.c 2012-10-04 18:28:50.094606874 +0900
@@ -133,6 +133,18 @@ int arch_add_memory(int nid, u64 start,
return __add_pages(nid, zone, start_pfn, nr_pages);
}
+
+#ifdef CONFIG_MEMORY_HOTREMOVE
+int arch_remove_memory(u64 start, u64 size)
+{
+ unsigned long start_pfn = start >> PAGE_SHIFT;
+ unsigned long nr_pages = size >> PAGE_SHIFT;
+ struct zone *zone;
+
+ zone = page_zone(pfn_to_page(start_pfn));
+ return __remove_pages(zone, start_pfn, nr_pages);
+}
+#endif
#endif /* CONFIG_MEMORY_HOTPLUG */
/*
Index: linux-3.6/arch/s390/mm/init.c
===
--- linux-3.6.orig/arch/s390/mm/init.c 2012-10-04 18:27:03.080498274 +0900
+++ linux-3.6/arch/s390/mm/init.c 2012-10-04 18:28:50.104606884 +0900
@@ -257,4 +257,16 @@ int arch_add_memory(int nid, u64 start,
vmem_remove_mapping(start, size);
return rc;
}
+
+#ifdef CONFIG_MEMORY_HOTREMOVE
+int arch_remove_memory(u64 start, u64 size)
+{
+ /*
+* There is no hardware or firmware interface which could trigger a
+* hot memory remove on s390. So there is nothing that needs to be
+* implemented.
+*/
+ return -EBUSY;
+}
+#endif
#endif /* CONFIG_MEMORY_HOTPLUG */
Index: linux-3.6/arch/sh/mm/init.c
===
--- linux-3.6.orig/arch/sh/mm/init.c2012-10-04 18:27:03.091498285 +0900
+++ linux-3.6/arch/sh/mm/init.c 2012-10-04 18:28:50.116606897 +0900
@@ -558,4 +558,21 @@ int memory_add_physaddr_to_nid(u64 addr)
EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
#endif
+#ifdef CONFIG_MEMORY_HOTREMOVE
+int arch_remove_memory(u64 start, u64 size)
+{
+ unsigned long start_pfn = start >> PAGE_SHIFT;
+ unsigned long nr_pages = size >> PAGE_SHIFT;
+ struct zone *zone;
+ int ret;
+
+ zone = page_zone(pfn_to_page(start_pfn));
+ ret = __remove_pages(zone, start_pfn, nr_pages);
+ if (unlikely(ret))
+ pr_warn("%s: Failed, __remove_pages() == %d\n", __func__,
+ ret);
+
+ return ret;
+}
+#endif
#endif /* CONFIG_MEMORY_HOTPLUG */
Index: linux-3.6/arch/tile/mm/init.c
===
--- linux-3.6.orig/arch/tile/mm/init.c 2012-10-04 18:27:03.078498272 +0900
+++ linux-3.6/arch/tile/mm/init.c 2012-10-04 18:28:50.122606903 +0900
@@ -935,6 +935,14 @@ int remove_memory(u64 start, u64 size)
{
return -EINVAL;
}
+
+#ifdef CONFIG_MEMORY_HOTREMOVE
+int arch_remove_memory(u64 start, u64 size)
+{
+ /* TODO */
+ return -EBUSY;
+}
+#endif
#endif
struct kmem_cache *pgd_cache;
Index: linux-3.6/arch/x86/mm/init_32.c
===
---
[PATCH 2/10] memory-hotplug : remove /sys/firmware/memmap/X sysfs
When (hot)adding memory into system, /sys/firmware/memmap/X/{end, start, type}
sysfs files are created. But there is no code to remove these files. The patch
implements the function to remove them.
Note : The code does not free firmware_map_entry since there is no way to free
memory which is allocated by bootmem.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
Signed-off-by: Wen Congyang
Signed-off-by: Yasuaki Ishimatsu
---
drivers/firmware/memmap.c| 98 ++-
include/linux/firmware-map.h |6 ++
mm/memory_hotplug.c |7 ++-
3 files changed, 108 insertions(+), 3 deletions(-)
Index: linux-3.6/drivers/firmware/memmap.c
===
--- linux-3.6.orig/drivers/firmware/memmap.c2012-10-04 18:27:05.195500420
+0900
+++ linux-3.6/drivers/firmware/memmap.c 2012-10-04 18:27:18.901514330 +0900
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
/*
* Data types
--
@@ -41,6 +42,7 @@ struct firmware_map_entry {
const char *type; /* type of the memory range */
struct list_headlist; /* entry for the linked list */
struct kobject kobj; /* kobject for each entry */
+ unsigned intbootmem:1; /* allocated from bootmem */
};
/*
@@ -79,7 +81,26 @@ static const struct sysfs_ops memmap_att
.show = memmap_attr_show,
};
+
+static inline struct firmware_map_entry *
+to_memmap_entry(struct kobject *kobj)
+{
+ return container_of(kobj, struct firmware_map_entry, kobj);
+}
+
+static void release_firmware_map_entry(struct kobject *kobj)
+{
+ struct firmware_map_entry *entry = to_memmap_entry(kobj);
+
+ if (entry->bootmem)
+ /* There is no way to free memory allocated from bootmem */
+ return;
+
+ kfree(entry);
+}
+
static struct kobj_type memmap_ktype = {
+ .release= release_firmware_map_entry,
.sysfs_ops = _attr_ops,
.default_attrs = def_attrs,
};
@@ -94,6 +115,7 @@ static struct kobj_type memmap_ktype = {
* in firmware initialisation code in one single thread of execution.
*/
static LIST_HEAD(map_entries);
+static DEFINE_SPINLOCK(map_entries_lock);
/**
* firmware_map_add_entry() - Does the real work to add a firmware memmap
entry.
@@ -118,11 +140,25 @@ static int firmware_map_add_entry(u64 st
INIT_LIST_HEAD(>list);
kobject_init(>kobj, _ktype);
+ spin_lock(_entries_lock);
list_add_tail(>list, _entries);
+ spin_unlock(_entries_lock);
return 0;
}
+/**
+ * firmware_map_remove_entry() - Does the real work to remove a firmware
+ * memmap entry.
+ * @entry: removed entry.
+ **/
+static inline void firmware_map_remove_entry(struct firmware_map_entry *entry)
+{
+ spin_lock(_entries_lock);
+ list_del(>list);
+ spin_unlock(_entries_lock);
+}
+
/*
* Add memmap entry on sysfs
*/
@@ -144,6 +180,35 @@ static int add_sysfs_fw_map_entry(struct
return 0;
}
+/*
+ * Remove memmap entry on sysfs
+ */
+static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
+{
+ kobject_put(>kobj);
+}
+
+/*
+ * Search memmap entry
+ */
+
+static struct firmware_map_entry * __meminit
+firmware_map_find_entry(u64 start, u64 end, const char *type)
+{
+ struct firmware_map_entry *entry;
+
+ spin_lock(_entries_lock);
+ list_for_each_entry(entry, _entries, list)
+ if ((entry->start == start) && (entry->end == end) &&
+ (!strcmp(entry->type, type))) {
+ spin_unlock(_entries_lock);
+ return entry;
+ }
+
+ spin_unlock(_entries_lock);
+ return NULL;
+}
+
/**
* firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
* memory hotplug.
@@ -193,9 +258,36 @@ int __init firmware_map_add_early(u64 st
if (WARN_ON(!entry))
return -ENOMEM;
+ entry->bootmem = 1;
return firmware_map_add_entry(start, end, type, entry);
}
+/**
+ * firmware_map_remove() - remove a firmware mapping entry
+ * @start: Start of the memory range.
+ * @end: End of the memory range.
+ * @type: Type of the memory range.
+ *
+ * removes a firmware mapping entry.
+ *
+ * Returns 0 on success, or -EINVAL if no entry.
+ **/
+int __meminit firmware_map_remove(u64 start, u64 end, const char *type)
+{
+ struct firmware_map_entry *entry;
+
+ entry = firmware_map_find_entry(start, end - 1, type);
+ if (!entry)
+ return -EINVAL;
+
+ firmware_map_remove_entry(entry);
+
+ /* remove the memmap entry */
+ remove_sysfs_fw_map_entry(entry);
+
+ return 0;
+}
+
/*
* Sysfs functions
[PATCH 1/10] memory-hotplug : check whether memory is offline or not when removing memory
When calling remove_memory(), the memory should be offline. If the function
is used to online memory, kernel panic may occur.
So the patch checks whether memory is offline or not.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
Signed-off-by: Wen Congyang
Signed-off-by: Yasuaki Ishimatsu
---
drivers/base/memory.c | 39 +++
include/linux/memory.h |5 +
mm/memory_hotplug.c| 17 +++--
3 files changed, 59 insertions(+), 2 deletions(-)
Index: linux-3.6/drivers/base/memory.c
===
--- linux-3.6.orig/drivers/base/memory.c2012-10-04 14:22:57.0
+0900
+++ linux-3.6/drivers/base/memory.c 2012-10-04 14:45:46.653585860 +0900
@@ -70,6 +70,45 @@ void unregister_memory_isolate_notifier(
}
EXPORT_SYMBOL(unregister_memory_isolate_notifier);
+bool is_memblk_offline(unsigned long start, unsigned long size)
+{
+ struct memory_block *mem = NULL;
+ struct mem_section *section;
+ unsigned long start_pfn, end_pfn;
+ unsigned long pfn, section_nr;
+
+ start_pfn = PFN_DOWN(start);
+ end_pfn = PFN_UP(start + size);
+
+ for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
+ section_nr = pfn_to_section_nr(pfn);
+ if (!present_section_nr(section_nr))
+ continue;
+
+ section = __nr_to_section(section_nr);
+ /* same memblock? */
+ if (mem)
+ if ((section_nr >= mem->start_section_nr) &&
+ (section_nr <= mem->end_section_nr))
+ continue;
+
+ mem = find_memory_block_hinted(section, mem);
+ if (!mem)
+ continue;
+ if (mem->state == MEM_OFFLINE)
+ continue;
+
+ kobject_put(>dev.kobj);
+ return false;
+ }
+
+ if (mem)
+ kobject_put(>dev.kobj);
+
+ return true;
+}
+EXPORT_SYMBOL(is_memblk_offline);
+
/*
* register_memory - Setup a sysfs device for a memory block
*/
Index: linux-3.6/include/linux/memory.h
===
--- linux-3.6.orig/include/linux/memory.h 2012-10-02 18:00:22.0
+0900
+++ linux-3.6/include/linux/memory.h2012-10-04 14:44:40.902581028 +0900
@@ -106,6 +106,10 @@ static inline int memory_isolate_notify(
{
return 0;
}
+static inline bool is_memblk_offline(unsigned long start, unsigned long size)
+{
+ return false;
+}
#else
extern int register_memory_notifier(struct notifier_block *nb);
extern void unregister_memory_notifier(struct notifier_block *nb);
@@ -120,6 +124,7 @@ extern int memory_isolate_notify(unsigne
extern struct memory_block *find_memory_block_hinted(struct mem_section *,
struct memory_block *);
extern struct memory_block *find_memory_block(struct mem_section *);
+extern bool is_memblk_offline(unsigned long start, unsigned long size);
#define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTION
[PATCH 0/10] memory-hotplug: hot-remove physical memory
The patch-set was divided from following thread's patch-set.
https://lkml.org/lkml/2012/9/5/201
If you want to know the reason, please read following thread.
https://lkml.org/lkml/2012/10/2/83
The patch-set has only the function of kernel core side for physical
memory hot remove. So if you use the patch, please apply following
patches.
- bug fix for memory hot remove
https://lkml.org/lkml/2012/9/27/39
https://lkml.org/lkml/2012/10/2/83
http://www.spinics.net/lists/linux-mm/msg42982.html
- acpi framework
https://lkml.org/lkml/2012/10/3/126
https://lkml.org/lkml/2012/10/3/641
The patches can free/remove the following things:
- /sys/firmware/memmap/X/{end, start, type} : [PATCH 2/10]
- mem_section and related sysfs files : [PATCH 3-4/10]
- memmap of sparse-vmemmap : [PATCH 5-7/10]
- page table of removed memory : [RFC PATCH 8/10]
- node and related sysfs files : [RFC PATCH 9-10/10]
* [PATCH 1/10] checks whether the memory can be removed or not.
If you find lack of function for physical memory hot-remove, please let me
know.
How to test this patchset?
1. apply this patchset and build the kernel. MEMORY_HOTPLUG, MEMORY_HOTREMOVE,
ACPI_HOTPLUG_MEMORY must be selected.
2. load the module acpi_memhotplug
3. hotplug the memory device(it depends on your hardware)
You will see the memory device under the directory /sys/bus/acpi/devices/.
Its name is PNP0C80:XX.
4. online/offline pages provided by this memory device
You can write online/offline to /sys/devices/system/memory/memoryX/state to
online/offline pages provided by this memory device
5. hotremove the memory device
You can hotremove the memory device by the hardware, or writing 1 to
/sys/bus/acpi/devices/PNP0C80:XX/eject.
Note: if the memory provided by the memory device is used by the kernel, it
can't be offlined. It is not a bug.
Known problems:
1. memory can't be offlined when CONFIG_MEMCG is selected.
For example: there is a memory device on node 1. The address range
is [1G, 1.5G). You will find 4 new directories memory8, memory9, memory10,
and memory11 under the directory /sys/devices/system/memory/.
If CONFIG_MEMCG is selected, we will allocate memory to store page cgroup
when we online pages. When we online memory8, the memory stored page cgroup
is not provided by this memory device. But when we online memory9, the memory
stored page cgroup may be provided by memory8. So we can't offline memory8
now. We should offline the memory in the reversed order.
When the memory device is hotremoved, we will auto offline memory provided
by this memory device. But we don't know which memory is onlined first, so
offlining memory may fail. In such case, you should offline the memory by
hand before hotremoving the memory device.
2. hotremoving memory device may cause kernel panicked
This bug will be fixed by Liu Jiang's patch:
https://lkml.org/lkml/2012/7/3/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/
[GIT PULL] please pull infiniband.git
Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git tags/rdma-for-linus Second batch of changes for the 3.7 merge window: - Late-breaking fix for IPoIB on mlx4 SR-IOV VFs. - Fix for IPoIB build breakage with CONFIG_INFINIBAND_IPOIB_CM=n (new netlink config changes are to blame). - Make sure retry count values are in range in RDMA CM. - A few nes hardware driver fixes and cleanups. - Have iSER initiator use >1 interrupt vectors if available. Alex Tabachnik (1): IB/iser: Add more RX CQs to scale out processing of SCSI responses Jack Morgenstein (1): mlx4_core: Adjust flow steering attach wrapper so that IB works on SR-IOV VFs Roland Dreier (2): IPoIB: Fix build with CONFIG_INFINIBAND_IPOIB_CM=n Merge branches 'cma', 'ipoib', 'iser', 'mlx4' and 'nes' into for-next Sean Hefty (1): RDMA/cma: Check that retry count values are in range Tatyana Nikolova (4): RDMA/nes: Add missing break to switch. RDMA/nes: Remove unnecessary if-else statement RDMA/nes: Remove unused module parameter "send_first" RDMA/nes: Bump the version number of nes driver drivers/infiniband/core/cma.c |6 +- drivers/infiniband/hw/nes/nes.c|5 - drivers/infiniband/hw/nes/nes.h|3 +- drivers/infiniband/hw/nes/nes_verbs.c | 16 +-- drivers/infiniband/ulp/ipoib/ipoib.h |4 +- drivers/infiniband/ulp/ipoib/ipoib_cm.c| 31 - drivers/infiniband/ulp/ipoib/ipoib_main.c | 31 + drivers/infiniband/ulp/iser/iscsi_iser.h | 17 ++- drivers/infiniband/ulp/iser/iser_verbs.c | 130 ++-- .../net/ethernet/mellanox/mlx4/resource_tracker.c |2 + 10 files changed, 146 insertions(+), 99 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the input tree
Hi Dmitry,
After merging the input tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/input/tablet/wacom_sys.c: In function 'wacom_get_sibling':
drivers/input/tablet/wacom_sys.c:643:23: error: 'struct usb_device' has no
member named 'children'
Caused by commit 316f18bba311 ("Input: wacom - handle split-sensor
devices with internal hubs") interacting with commit ff823c79a5c3 ("usb:
move children to struct usb_port") that is now in Linus' tree.
I have used the input tree from next-20121004 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpTRrH0KwyGF.pgp
Description: PGP signature
Re: Seems like "sched: Add missing call to calc_load_exit_idle()" should be reverted in 3.5 branch
Peter Zijlstra wrote:
> I can't find wtf went wrong either, the initial patch 5167e8d5417bf5c
> contains both hunks, but in that case the fixup 749c8814f0 doesn't make
> sense, not can I find anything in merge commits using:
>
> git log -S calc_load_exit_idle kernel/time/tick-sched.c
git log -m -p --first-parent -Scalc_load_exit_idle -- kernel/time/tick-sched.c
finds 3992c0321258 ("Merge branch 'timers-core-for-linus'",
2012-07-22), which seems to have mismerged 2ac0d98fd624 ("nohz: Make
nohz API agnostic against idle ticks cputime accounting").
Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 14/24] USB: ohci: merge ohci_finish_controller_resume with ohci_resume
On Friday, October 05, 2012 12:18 AM Florian Fainelli wrote
>
> Merge ohci_finish_controller_resume with ohci_resume as suggested by Alan
> Stern. Since ohci_finish_controller_resume no longer exists, update the
> various OHCI drivers to call ohci_resume() instead. Some drivers used to set
> themselves the bit HCD_FLAG_HW_ACCESSIBLE, which is now handled by
> ohci_resume().
>
> Signed-off-by: Florian Fainelli
For drivers/usb/host/ohci-exynos.c, it looks good.
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/usb/host/ohci-at91.c |2 +-
> drivers/usb/host/ohci-ep93xx.c |2 +-
> drivers/usb/host/ohci-exynos.c |5 +
> drivers/usb/host/ohci-hcd.c | 41 +++--
> drivers/usb/host/ohci-hub.c | 42
> --
> drivers/usb/host/ohci-omap.c |2 +-
> drivers/usb/host/ohci-platform.c |2 +-
> drivers/usb/host/ohci-pxa27x.c |2 +-
> drivers/usb/host/ohci-s3c2410.c |3 +--
> drivers/usb/host/ohci-spear.c|2 +-
> drivers/usb/host/ohci-tmio.c |2 +-
> 11 files changed, 48 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
> index 0bf72f9..908d84a 100644
> --- a/drivers/usb/host/ohci-at91.c
> +++ b/drivers/usb/host/ohci-at91.c
> @@ -705,7 +705,7 @@ static int ohci_hcd_at91_drv_resume(struct
> platform_device *pdev)
> if (!clocked)
> at91_start_clock();
>
> - ohci_finish_controller_resume(hcd);
> + ohci_resume(hcd, false);
> return 0;
> }
> #else
> diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
> index dbfbd1d..a982f04 100644
> --- a/drivers/usb/host/ohci-ep93xx.c
> +++ b/drivers/usb/host/ohci-ep93xx.c
> @@ -194,7 +194,7 @@ static int ohci_hcd_ep93xx_drv_resume(struct
> platform_device *pdev)
>
> ep93xx_start_hc(>dev);
>
> - ohci_finish_controller_resume(hcd);
> + ohci_resume(hcd, false);
> return 0;
> }
> #endif
> diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
> index fc3091b..53c5a989 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -252,10 +252,7 @@ static int exynos_ohci_resume(struct device *dev)
> if (pdata && pdata->phy_init)
> pdata->phy_init(pdev, S5P_USB_PHY_HOST);
>
> - /* Mark hardware accessible again as we are out of D3 state by now */
> - set_bit(HCD_FLAG_HW_ACCESSIBLE, >flags);
> -
> - ohci_finish_controller_resume(hcd);
> + ohci_resume(hcd, false);
>
> return 0;
> }
> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index 5d30992..568bdb3 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -1003,13 +1003,50 @@ static int __maybe_unused ohci_suspend(struct usb_hcd
> *hcd, bool do_wakeup)
>
> static int __maybe_unused ohci_resume(struct usb_hcd *hcd, bool hibernated)
> {
> + struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> + int port;
> + boolneed_reinit = false;
> +
> set_bit(HCD_FLAG_HW_ACCESSIBLE, >flags);
>
> /* Make sure resume from hibernation re-enumerates everything */
> if (hibernated)
> - ohci_usb_reset(hcd_to_ohci(hcd));
> + ohci_usb_reset(ohci);
> +
> + /* See if the controller is already running or has been reset */
> + ohci->hc_control = ohci_readl(ohci, >regs->control);
> + if (ohci->hc_control & (OHCI_CTRL_IR | OHCI_SCHED_ENABLES)) {
> + need_reinit = true;
> + } else {
> + switch (ohci->hc_control & OHCI_CTRL_HCFS) {
> + case OHCI_USB_OPER:
> + case OHCI_USB_RESET:
> + need_reinit = true;
> + }
> + }
> +
> + /* If needed, reinitialize and suspend the root hub */
> + if (need_reinit) {
> + spin_lock_irq(>lock);
> + ohci_rh_resume(ohci);
> + ohci_rh_suspend(ohci, 0);
> + spin_unlock_irq(>lock);
> + }
> +
> + /* Normally just turn on port power and enable interrupts */
> + else {
> + ohci_dbg(ohci, "powerup ports\n");
> + for (port = 0; port < ohci->num_ports; port++)
> + ohci_writel(ohci, RH_PS_PPS,
> + >regs->roothub.portstatus[port]);
> +
> + ohci_writel(ohci, OHCI_INTR_MIE, >regs->intrenable);
> + ohci_readl(ohci, >regs->intrenable);
> + msleep(20);
> + }
> +
> + usb_hcd_resume_root_hub(hcd);
>
> - ohci_finish_controller_resume(hcd);
> return 0;
> }
>
> diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c
> index 2f3619e..db09dae 100644
> --- a/drivers/usb/host/ohci-hub.c
> +++ b/drivers/usb/host/ohci-hub.c
> @@ -316,48 +316,6 @@ static int ohci_bus_resume (struct usb_hcd *hcd)
> return rc;
Re: The 10ms averager in fair.c + granularity
Hello, Uwaysi, Uwaysi Bin Kareem paradoxuncreated.com> writes: > > Ok at 100hz, granularity seems to work as expected. Actually 1000hz for > desktop seems to be a myth. I have less jitter with 100hz. Very nice. I > think jitter is 99.99% eliminated from doom 3 now. > > Peace Be With You! > I think for some real credibility you'd have to come up with a (synthetic) benchmark that clearly demonstrates this problem... /This/ seems to be the /real/ problem here: how do you measure generic jitter? In hard figures, not just 'theoretically'. And no, the subjective 'I can feel it' doesn't work, as everybody has a different perception of 'jitter', especially in opengl Maybe try to match the 'filter' avg timing to your gfx screen refresh rate? (15ms for 60Hz, you get the idea?) and tell us how that works? Lukasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Seems like "sched: Add missing call to calc_load_exit_idle()" should be reverted in 3.5 branch
My opinion: The original patch "sched/nohz: Rewrite and fix load-avg computation -- again" is designed for 3.5-branch and calc_load_exit_idle() is called directly in tick_nohz_idle_exit(). So, the patch can be fully applied in 3.5 and doesn't need to fix (Add the missing call), but not fully applied in 3.6 (because code splitted) and need to fix. > On Thu, Oct 04, 2012 at 08:31:59PM +0200, Peter Zijlstra wrote: >> On Thu, 2012-10-04 at 10:46 -0700, Greg Kroah-Hartman wrote: >> > On Thu, Oct 04, 2012 at 12:11:01PM +0800, Huacai Chen wrote: >> > > Hi, Greg >> > > >> > > I found that Linux-3.5.5 accept this commit "sched: Add missing call >> > > to calc_load_exit_idle()" but I think this isn't needed. Because >> > > "5167e8d5417b sched/nohz: Rewrite and fix load-avg computation -- >> > > again not fully applied" is true for 3.6 branch, but not for 3.5 >> > > branch. >> > >> > But 5167e8d5417b is in 3.5, so shouldn't this commit still be >> necessary? >> > >> > > In 3.5 branch, calc_load_exit_idle() is already called in >> > > tick_nohz_idle_exit(), it doesn't need to be called at >> > > tick_nohz_update_jiffies() again. In 3.6 branch, some code of >> > > tick_nohz_idle_exit() is splitted to tick_nohz_restart_sched_tick() >> > > and calc_load_exit_idle() is missing by accident, so commit "sched: >> > > Add missing call to calc_load_exit_idle()" is needed. >> > >> > So this really should be dropped from 3.5? Charles, Peter, Ingo, any >> > thoughts here? >> >> Bah, lots of code movement there recently.. let me try and untangle all >> that afresh.. /me checks out v3.5.5. >> >> OK, assuming ->tick_stopped means what the label says, then we only want >> to call calc_load_enter_idle() when it flips to 1 and >> calc_load_exit_idle() when it flips back to 0, such that when an actual >> tick happens its got correct state. >> >> Now the actual patch "5167e8d5417b sched/nohz: Rewrite and fix load-avg >> computation -- again not fully applied" modifies >> tick_nohz_restart_sched_tick() which doesn't appear to exist in v3.5.5 >> and the patch fobbed it into tick_nohz_update_jiffies() which is called >> from interrupt entry when nohz-idle so that the interrupt (and possible >> tailing softirq) see a valid jiffies count. >> >> However, since we don't restart the tick, we won't be sampling load muck >> and calling calc_load_exit_idle() from there is bound to confuse state. >> >> I hope.. damn this code ;-) >> >> I can't find wtf went wrong either, the initial patch 5167e8d5417bf5c >> contains both hunks, but in that case the fixup 749c8814f0 doesn't make >> sense, not can I find anything in merge commits using: >> >> git log -S calc_load_exit_idle kernel/time/tick-sched.c >> >> /me puzzled > > I'm puzzled as well. Any ideas if I should do anything here or not? > > greg k-h > -- 江苏中科梦兰电子科技有限公司 软件部 陈华才 E-mail: che...@lemote.com Web: http://www.lemote.com/ Add: 江苏省常熟市虞山镇梦兰工业园 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] dma-debug: New interfaces to debug dma mapping errors
A recent dma mapping error analysis effort showed that a large percentage of dma_map_single() and dma_map_page() returns are not checked for mapping errors. Reference: http://linuxdriverproject.org/mediawiki/index.php/DMA_Mapping_Error_Analysis Adding support for tracking dma mapping and unmapping errors to help assess the following: When do dma mapping errors get detected? How often do these errors occur? Why don't we see failures related to missing dma mapping error checks? Are they silent failures? Patch v4: Addresses extra tab review comments from Patch v3. Patch v3: Addresses review and design comments from Patch v2. Patch v2: Addressed design issues from Patch v1. Enhance dma-debug infrastructure to track dma mapping, and unmapping errors. map_errors: (system wide counter) Total number of dma mapping errors returned by the dma mapping interfaces, in response to mapping requests from all devices in the system. map_errors_not_checked: (system wide counter) Total number of dma mapping errors devices failed to check before using the returned address. unmap_errors: (system wide counter) Total number of times devices tried to unmap or free an invalid dma address. map_err_type: (new field added to dma_debug_entry structure) New field to maintain dma mapping error check status. This error type is applicable to the dma map page and dma map single entries tracked by dma-debug api. This status indicates whether or not a good mapping is checked by the device before its use. dma_map_single() and dma_map_page() could fail to create a mapping in some cases, and drivers are expected to call dma_mapping_error() to check for errors. Please note that this is not counter. Enhancements to dma-debug api are made to add new debugfs interfaces to report total dma errors, dma errors that are not checked, and unmap errors for the entire system. Please note that these are system wide counters for all devices in the system. The following new dma-debug interface is added: debug_dma_mapping_error(struct device *dev, dma_addr_t dma_addr) Sets dma map error checked status for the dma map entry if one is found. Decrements the system wide dma_map_errors_not_checked counter that is incremented by debug_dma_map_page() when it checks for mapping error before adding it to the dma debug entry table. New dma-debug internal interface: check_mapping_error(struct device *dev, dma_addr_t dma_addr) Calling dma_mapping_error() from dma-debug api will result in dma mapping check when it shouldn't. This internal routine checks dma mapping error without any debug checks. The following existing dma-debug api are changed to support this feature: debug_dma_map_page() Increments dma_map_errors and dma_map_errors_not_checked errors totals for the system, dma-debug api keeps track of, when dma_addr is invalid. This routine now calls internal check_mapping_error() interface to avoid doing dma mapping debug checks from dma-debug internal mapping error checks. check_unmap() This is an existing internal routines that checks for various mapping errors. Changed to increment system wide dma_unmap_errors, when a device requests an invalid address to be unmapped. This routine now calls internal check_mapping_error() interface to avoid doing dma mapping debug checks from dma-debug internal mapping error checks. Changed arch/x86/include/asm/dma-mapping.h to call debug_dma_mapping_error() to validate these new interfaces on x86_64. Other architectures will be changed in a subsequent patch. Tested: Intel iommu and swiotlb (iommu=soft) on x86-64 with CONFIG_DMA_API_DEBUG enabled and disabled. Signed-off-by: Shuah Khan Reviewed-by: Konrad Rzeszutek Wilk --- Documentation/DMA-API.txt | 13 + arch/x86/include/asm/dma-mapping.h |1 + include/linux/dma-debug.h |7 +++ lib/dma-debug.c| 110 ++-- 4 files changed, 127 insertions(+), 4 deletions(-) diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 66bd97a..886aaf9 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -638,6 +638,19 @@ this directory the following files can currently be found: dma-api/error_count This file is read-only and shows the total numbers of errors found. + dma-api/map_errors This file is read-only and shows the total + number of dma mapping errors detected. + + dma-api/map_errors_not_checked + This file is read-only and shows the total + number of dma mapping errors, device drivers + failed to check prior to using the returned + address. + + dma-api/unmap_errors + This
Re: [PATCH] ARM: Push selects for TWD/SCU into machine entries
On Thu, Oct 04, 2012 at 01:50:44AM -0700, Stephen Boyd wrote: > The TWD and SCU configs are selected by default as long as > SCORPIONMP is false and/or MCT is false. Implementing the logic > this way certainly saves lines in the Kconfig but it precludes > those machines which select SCORPIONMP or MCT from participating > in the single zImage effort because when those machines are > combined with other SMP capable machines the TWD and SCU are no > longer selected. > > Push the select out to the machine entries so that we can compile > these machines together and still select the appropriate configs. > > Signed-off-by: Stephen Boyd > Cc: David Brown > Cc: Kukjin Kim > Cc: Linus Walleij > Cc: Pawel Moll > Cc: Rob Herring > Cc: Russell King > Cc: Sascha Hauer > Cc: Shiraz Hashim > Cc: Simon Horman > Cc: Srinidhi Kasagar > Cc: Stephen Warren > Cc: Tony Lindgren > Cc: Viresh Kumar > --- The shmobile portion of this change seems fine to me. Acked-by: Simon Horman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Push selects for TWD/SCU into machine entries
On Thu, Oct 04, 2012 at 02:41:46PM +0530, Santosh Shilimkar wrote: > On Thursday 04 October 2012 02:20 PM, Stephen Boyd wrote: > >The TWD and SCU configs are selected by default as long as > >SCORPIONMP is false and/or MCT is false. Implementing the logic > >this way certainly saves lines in the Kconfig but it precludes > >those machines which select SCORPIONMP or MCT from participating > >in the single zImage effort because when those machines are > >combined with other SMP capable machines the TWD and SCU are no > >longer selected. > > > >Push the select out to the machine entries so that we can compile > >these machines together and still select the appropriate configs. > > > >Signed-off-by: Stephen Boyd > >Cc: David Brown > >Cc: Kukjin Kim > >Cc: Linus Walleij > >Cc: Pawel Moll > >Cc: Rob Herring > >Cc: Russell King > >Cc: Sascha Hauer > >Cc: Shiraz Hashim > >Cc: Simon Horman > >Cc: Srinidhi Kasagar > >Cc: Stephen Warren > >Cc: Tony Lindgren > >Cc: Viresh Kumar > >--- > > > >Does OMAP5 need to select TWD? I suspect not if it uses the > >architected timers. > > > Nope. OMAP5 don't use TWD. Infact the external SCU is also used > for A9 SOCs. You might want to check other A15 SOCS for SCU as > well. In that case I am a bit confused by the following result: # git checkout v3.6 # ARCH=arm make omap2plus_defconfig # grep '(SOC_OMAP5|_SCU|_TWD|CONFIG_SMP|CONFIG_LOCAL_TIMERS)=' .config CONFIG_SOC_OMAP5=y CONFIG_SMP=y CONFIG_HAVE_ARM_SCU=y CONFIG_HAVE_ARM_TWD=y CONFIG_LOCAL_TIMERS=y -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] memory-hotplug: add node_device_release
Hi Kosaki-san, 2012/10/02 3:12, KOSAKI Motohiro wrote: On Mon, Oct 1, 2012 at 2:54 AM, Yasuaki Ishimatsu wrote: Hi Kosaki-san, 2012/09/29 7:19, KOSAKI Motohiro wrote: I don't understand it. How can we get rid of the warning? See cpu_device_release() for example. If we implement a function like cpu_device_release(), the warning disappears. But the comment says in the function "Never copy this way...". So I think it is illegal way. What does "illegal" mean? The "illegal" means the code should not be mimicked. You still haven't explain any benefit of your code. If there is zero benefit, just kill it. I believe everybody think so. Again, Which benefit do you have? The patch has a benefit to delets a warning message. Why do we need this node_device_release() implementation? I think that this is a manner of releasing object related kobject. No. Usually we never call memset() from release callback. What we want to release is a part of array, not a pointer. Therefore, there is only this way instead of kfree(). Why? Before your patch, we don't have memset() and did work it. If we does not apply the patch, a warning message is shown. So I think it did not work well. I can't understand what mean "only way". For deleting a warning message, I created a node_device_release(). In the manner of releasing kobject, the function frees a object related to the kobject. So most functions calls kfree() for releasing it. In node_device_release(), we need to free a node struct. If the node struct is pointer, I can free it by kfree. But the node struct is a part of node_devices[] array. I cannot free it. So I filled the node struct with 0. But you think it is not good. Do you have a good solution? Do nothing. just add empty release function and kill a warning. Obviously do nothing can't make any performance drop nor any side effect. meaningless memset() is just silly from point of cache pollution view. I have the reason to have to fill the node struct with 0 by memset. The node is a part of node struct array (node_devices[]). If we add empty release function for suppressing warning, some data remains in the node struct after hot removing memory. So if we re-hot adds the memory, the node struct is reused by register_onde_node(). But the node struct has some data, because it was not initialized with 0. As a result, more waning is shown by the remained data at hot addinig memory as follows: [ 374.037710] kobject (82c15718): tried to init an initialized object, something is seriously wrong. [ 374.153169] Pid: 4, comm: kworker/0:0 Tainted: GW3.6.0 #5 [ 374.230279] Call Trace: [ 374.259647] [] kobject_init+0x89/0xa0 [ 374.323286] [] device_initialize+0x2c/0xc0 [ 374.392086] [] device_register+0x16/0x30 [ 374.458856] [] register_node+0x25/0xe0 [ 374.523434] [] register_one_node+0x67/0x140 [ 374.593306] [] add_memory+0x100/0x1f0 [ 374.656961] [] acpi_memory_enable_device+0x92/0xdf [acpi_memhotplug] [ 374.752811] [] acpi_memory_device_add+0x10d/0x116 [acpi_memhotplug] [ 374.847622] [] acpi_device_probe+0x50/0x18a [ 374.917504] [] ? sysfs_create_link+0x13/0x20 [ 374.988426] [] really_probe+0x6c/0x320 [ 375.053061] [] driver_probe_device+0x47/0xa0 [ 375.123922] [] ? __driver_attach+0xb0/0xb0 [ 375.192709] [] ? __driver_attach+0xb0/0xb0 [ 375.261494] [] __device_attach+0x53/0x60 [ 375.328206] [] bus_for_each_drv+0x6c/0xa0 [ 375.395950] [] device_attach+0xa8/0xc0 [ 375.460578] [] bus_probe_device+0xb0/0xe0 [ 375.528318] [] device_add+0x301/0x570 [ 375.591883] [] device_register+0x1e/0x30 [ 375.658568] [] acpi_device_register+0x1af/0x2bf [ 375.732590] [] acpi_add_single_object+0x1df/0x2b9 [ 375.808640] [] ? acpi_ut_release_mutex+0xac/0xb5 [ 375.883646] [] acpi_bus_check_add+0x10b/0x166 [ 375.955529] [] ? trace_hardirqs_on+0xd/0x10 [ 376.025327] [] ? up+0x2f/0x50 [ 376.080639] [] ? acpi_os_signal_semaphore+0x6b/0x74 [ 376.158792] [] acpi_ns_walk_namespace+0xbe/0x17d [ 376.233854] [] ? acpi_add_single_object+0x2b9/0x2b9 [ 376.312012] [] ? acpi_add_single_object+0x2b9/0x2b9 [ 376.390162] [] acpi_walk_namespace+0x8a/0xc4 [ 376.461051] [] acpi_bus_scan+0x5b/0x7c [ 376.525707] [] acpi_bus_add+0x2a/0x2c [ 376.589344] [] container_notify_cb+0x103/0x18d [ 376.662309] [] acpi_ev_notify_dispatch+0x41/0x5f [ 376.737386] [] acpi_os_execute_deferred+0x27/0x34 [ 376.813507] [] process_one_work+0x219/0x680 [ 376.883357] [] ? process_one_work+0x1b8/0x680 [ 376.955312] [] ? acpi_os_wait_events_complete+0x23/0x23 [ 377.037615] [] worker_thread+0x12e/0x320 [ 377.104365] [] ? manage_workers+0x190/0x190 [ 377.174274] [] kthread+0xc6/0xd0 [ 377.232697] [] kernel_thread_helper+0x4/0x10 [ 377.303588] [] ? retint_restore_args+0x13/0x13 [ 377.376550] [] ? __init_kthread_worker+0x70/0x70 [ 377.451591] [] ? gs_change+0x13/0x13 [ 377.514247] [ cut here ] [ 377.569481]
Re: [PATCH] fs: handle failed audit_log_start properly
On Thu, Oct 04, 2012 at 07:57:31PM -0400, Sasha Levin wrote:
> audit_log_start() may return NULL, this is unchecked by the caller in
> audit_log_link_denied() and could cause a NULL ptr deref.
>
> Introduced by commit a51d9eaa ("fs: add link restriction audit reporting").
Again, -stable fodder. Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: prevent use after free in auditing when symlink following was denied
On Thu, Oct 04, 2012 at 07:56:40PM -0400, Sasha Levin wrote: > Commit "fs: add link restriction audit reporting" has added auditing of failed > attempts to follow symlinks. Unfortunately, the auditing was being done after > the struct path structure was released earlier. Applied, and it's -stable fodder as well. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Disintegrate UAPI for avr32
Hi David, On Thu, Oct 4, 2012 at 12:51 PM, David Howells wrote: > Can you merge the following branch into the avr32 tree please. I don't really have an avr32 tree anymore. Can you ask Linus to pull this directly? Havard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: kernel BUG at fs/buffer.c:3205
On Wed 03-10-12 00:03:13, Jochen Katz wrote: > Hi, > > there is currently a thread "kernel BUG at fs/buffer.c:3205 (stable 3.5.3)" > on this list. > > I have reached the same BUG_ON(), but in an older kernel and with a different > environment, so maybe the following information is helpfull. > > - Kernel is from openSUSE 12.2: kernel-desktop-3.4.6-2.10.1.x86_64 > - I have no SSD and no USB 3.0 > - The BUG occured when updating DVD ISOs with jigdo on an ext4 partition (old > and new ISOs are on the same partition). > - No fglrx module, but unfortunately a nvidia module I had a look but unfortunately register or stack content doesn't tell us what was in the buffer_head. So unless this is reproducible, I'm afraid we cannot do much. Honza > > [ 9485.931360] kernel BUG at > /home/abuild/rpmbuild/BUILD/kernel-desktop-3.4.6/linux-3.4/fs/buffer.c:3205! > [ 9485.931362] invalid opcode: [#1] PREEMPT SMP > [ 9485.931365] CPU 1 > [ 9485.931366] Modules linked in: nls_utf8 loop fuse ip6table_filter > ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables bridge stp > cpufreq_conservative cpufreq_userspace cpufreq_powersave raid456 > async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx > stv0299 ves1x93 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep > dvb_ttpci snd_pcm nvidia(PO) dvb_core sr_mod saa7146_vv raid1 cdrom snd_seq > snd_timer sg acpi_cpufreq mperf firewire_ohci pcspkr iTCO_wdt videodev > saa7146 videobuf_dma_sg videobuf_core firewire_core atl1 ttpci_eeprom > iTCO_vendor_support crc_itu_t i2c_i801 snd_seq_device snd soundcore > snd_page_alloc kvm_intel kvm coretemp asus_atk0110 button microcode autofs4 > btrfs zlib_deflate crc32c libcrc32c processor thermal_sys scsi_dh_rdac > scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh ata_generic ata_piix > pata_jmicron > [ 9485.931407] > [ 9485.931409] Pid: 32, comm: kswapd0 Tainted: P O > 3.4.6-2.10-desktop #1 System manufacturer P5K/P5K > [ 9485.931412] RIP: 0010:[] [] > free_buffer_head+0x6f/0x80 > [ 9485.931419] RSP: 0018:8802218e7a08 EFLAGS: 00010287 > [ 9485.931420] RAX: 880002e3aba0 RBX: 880002e3ab58 RCX: > > [ 9485.931422] RDX: RSI: 1000 RDI: > 880002e3ab58 > [ 9485.931423] RBP: 0001 R08: 0001 R09: > 02750d83 > [ 9485.931425] R10: 0001 R11: dead00100100 R12: > 8800822afe08 > [ 9485.931427] R13: ea0002847598 R14: 8802218e7ae0 R15: > ea0002847578 > [ 9485.931428] FS: () GS:88022fc8() > knlGS: > [ 9485.931430] CS: 0010 DS: ES: CR0: 8005003b > [ 9485.931432] CR2: 02ecda18 CR3: 00021ab5a000 CR4: > 07e0 > [ 9485.931434] DR0: DR1: DR2: > > [ 9485.931435] DR3: DR6: 0ff0 DR7: > 0400 > [ 9485.931437] Process kswapd0 (pid: 32, threadinfo 8802218e6000, task > 8802218e4840) > [ 9485.931438] Stack: > [ 9485.931439] 8118c539 8802218e7dd8 880002e3ab58 > 8802218e7bd0 > [ 9485.931443] 8802218e7dd8 8802218e7ad0 8eb7 > 88022fc8fae8 > [ 9485.931445] 88020001 8800822afd80 ea01 > > [ 9485.931448] Call Trace: > [ 9485.931456] [] try_to_free_buffers+0x79/0xc0 > [ 9485.931460] [] shrink_page_list+0x5d7/0x940 > [ 9485.931465] [] shrink_inactive_list+0x182/0x4f0 > [ 9485.931468] [] shrink_mem_cgroup_zone+0x3b2/0x520 > [ 9485.931472] [] shrink_zone+0x70/0x90 > [ 9485.931475] [] balance_pgdat+0x509/0x710 > [ 9485.931478] [] kswapd+0x159/0x3c0 > [ 9485.931482] [] kthread+0x85/0x90 > [ 9485.931486] [] kernel_thread_helper+0x4/0x10 > [ 9485.931489] Code: ff 0f 00 00 7e 05 e8 71 f5 ff ff 65 48 8b 04 25 70 b8 00 > 00 83 a8 44 e0 ff ff 01 48 8b 80 38 e0 ff ff a8 08 75 07 48 83 c4 08 c3 <0f> > 0b 5a e9 d9 e2 3f 00 66 0f 1f 84 00 00 00 00 00 41 54 55 53 > [ 9485.931512] RIP [] free_buffer_head+0x6f/0x80 > [ 9485.931514] RSP > > Regards, > Jochen > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: prevent use after free in auditing when symlink following was denied
On Thu, Oct 04, 2012 at 07:56:40PM -0400, Sasha Levin wrote: > Commit "fs: add link restriction audit reporting" has added auditing of failed > attempts to follow symlinks. Unfortunately, the auditing was being done after > the struct path structure was released earlier. > > Signed-off-by: Sasha Levin Thanks for catching that! Cc: sta...@vger.kernel.org Acked-by: Kees Cook -- Kees Cook@outflux.net -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] MAINTAINERS: Add myself as the SWIOTLB maintainer.
On 10/04/2012 08:49 AM, Konrad Rzeszutek Wilk wrote: Now that I've an IA64 box on top of the other boxes (IBM with Calgary-X, Intel VT-d, AMD Vi, and AMD GART - that can use SWIOTLB as fallback) I can reliably do regression testing. CC: FUJITA Tomonori Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Andrew Morton CC: Tony Luck Signed-off-by: Konrad Rzeszutek Wilk --- MAINTAINERS |8 1 files changed, 8 insertions(+), 0 deletions(-) Acked-by: "H. Peter Anvin" -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 19/20] drivers/net/ethernet/marvell/skge.c: fix error return code
On Thu, 2012-10-04 at 14:54 -0400, David Miller wrote: > From: Peter Senna Tschudin > > On Thu, Oct 4, 2012 at 8:23 PM, David Miller wrote: > >> We want to know the implications of the bug being fixed. > >> Does it potentially cause an OOPS? Bad reference counting and thus > >> potential leaks or early frees? > >> > >> You have to analyze the implications and ramifications of the bug > >> being fixed. We need that information. You are asking for deeper level analysis that may not be reasonably possible from the robotic patch fixed by a robotic piece of a bit of code correction via a static analysis. > >> It's just "bad error code, this is the script that fixed it, kthx, > >> bye" which is pretty much useless for anaylsis. Which may be all but impossible but for the handful of folks that know all the gory/intimate details of the original bit of code. > What does it potentially cause the caller to do? Will it potentially > treat an error as a success and as a result register an object > illegally? > > Real analysis please. The text you provided above is basically still > robotic and could be used to describe any error code return fix. Right, it's useful to attempt but may be infeasible in practice. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging/comedi: Use dev_ printks in drivers/adl_pci8164.c
fixed below checkpatch warning. - WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ... Signed-off-by: YAMANE Toshiaki --- drivers/staging/comedi/drivers/adl_pci8164.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/staging/comedi/drivers/adl_pci8164.c b/drivers/staging/comedi/drivers/adl_pci8164.c index 05e06e7..6dbe465 100644 --- a/drivers/staging/comedi/drivers/adl_pci8164.c +++ b/drivers/staging/comedi/drivers/adl_pci8164.c @@ -89,9 +89,9 @@ static void adl_pci8164_insn_read(struct comedi_device *dev, } data[0] = inw(dev->iobase + axis_reg + offset); - printk(KERN_DEBUG "comedi: pci8164 %s read -> " - "%04X:%04X on axis %s\n", - action, data[0], data[1], axisname); + dev_dbg(dev->class_dev, + "comedi: pci8164 %s read -> %04X:%04X on axis %s\n", + action, data[0], data[1], axisname); } static int adl_pci8164_insn_read_msts(struct comedi_device *dev, @@ -170,9 +170,9 @@ static void adl_pci8164_insn_out(struct comedi_device *dev, outw(data[0], dev->iobase + axis_reg + offset); - printk(KERN_DEBUG "comedi: pci8164 %s write -> " - "%04X:%04X on axis %s\n", - action, data[0], data[1], axisname); + dev_dbg(dev->class_dev, + "comedi: pci8164 %s write -> %04X:%04X on axis %s\n", + action, data[0], data[1], axisname); } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging/comedi: Use dev_ printks in drivers/me_daq.c
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...
to printk(KERN_ERR ...
- WARNING: quoted string split across lines
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/comedi/drivers/me_daq.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/comedi/drivers/me_daq.c
b/drivers/staging/comedi/drivers/me_daq.c
index 2ce0b14..0d85729 100644
--- a/drivers/staging/comedi/drivers/me_daq.c
+++ b/drivers/staging/comedi/drivers/me_daq.c
@@ -384,8 +384,8 @@ static int me_ai_insn_read(struct comedi_device *dev,
(readw(dev_private->me_regbase +
ME_READ_AD_FIFO) ^ 0x800) & 0x0FFF;
} else {
- printk(KERN_ERR "comedi%d: Cannot get single value\n",
- dev->minor);
+ dev_err(dev->class_dev, "comedi%d: Cannot get single value\n",
+ dev->minor);
return -EIO;
}
@@ -566,8 +566,8 @@ static int me2600_xilinx_download(struct comedi_device *dev,
if (value & 0x20) {
/* Disable interrupt */
writel(0x00, dev_private->plx_regbase + PLX_INTCSR);
- printk(KERN_ERR "comedi%d: Xilinx download failed\n",
- dev->minor);
+ dev_err(dev->class_dev, "comedi%d: Xilinx download failed\n",
+ dev->minor);
return -EIO;
}
@@ -654,8 +654,9 @@ static int me_attach_pci(struct comedi_device *dev, struct
pci_dev *pcidev)
/* Enable PCI device and request PCI regions */
if (comedi_pci_enable(pcidev, dev->board_name) < 0) {
- printk(KERN_ERR "comedi%d: Failed to enable PCI device and "
- "request regions\n", dev->minor);
+ dev_err(dev->class_dev,
+ "comedi%d: Failed to enable PCI device and request
regions\n",
+ dev->minor);
return -EIO;
}
@@ -666,7 +667,8 @@ static int me_attach_pci(struct comedi_device *dev, struct
pci_dev *pcidev)
ioremap(plx_regbase_tmp, plx_regbase_size_tmp);
dev_private->plx_regbase_size = plx_regbase_size_tmp;
if (!dev_private->plx_regbase) {
- printk("comedi%d: Failed to remap I/O memory\n", dev->minor);
+ dev_err(dev->class_dev,
+ "comedi%d: Failed to remap I/O memory\n", dev->minor);
return -ENOMEM;
}
@@ -676,11 +678,13 @@ static int me_attach_pci(struct comedi_device *dev,
struct pci_dev *pcidev)
swap_regbase_size_tmp = pci_resource_len(pcidev, 5);
if (!swap_regbase_tmp)
- printk(KERN_ERR "comedi%d: Swap not present\n", dev->minor);
+ dev_err(dev->class_dev,
+ "comedi%d: Swap not present\n", dev->minor);
/*-- Workaround start ---*/
if (plx_regbase_tmp & 0x0080) {
- printk(KERN_ERR "comedi%d: PLX-Bug detected\n", dev->minor);
+ dev_err(dev->class_dev,
+ "comedi%d: PLX-Bug detected\n", dev->minor);
if (swap_regbase_tmp) {
regbase_tmp = plx_regbase_tmp;
@@ -716,8 +720,8 @@ static int me_attach_pci(struct comedi_device *dev, struct
pci_dev *pcidev)
dev_private->me_regbase_size = me_regbase_size_tmp;
dev_private->me_regbase = ioremap(me_regbase_tmp, me_regbase_size_tmp);
if (!dev_private->me_regbase) {
- printk(KERN_ERR "comedi%d: Failed to remap I/O memory\n",
- dev->minor);
+ dev_err(dev->class_dev,
+ "comedi%d: Failed to remap I/O memory\n", dev->minor);
return -ENOMEM;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging/comedi: Use dev_ printks in kcomedilib/kcomedilib_main.c
fixed below checkpatch warning.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...
to printk(KERN_ERR ...
Signed-off-by: YAMANE Toshiaki
---
.../staging/comedi/kcomedilib/kcomedilib_main.c|5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/kcomedilib/kcomedilib_main.c
b/drivers/staging/comedi/kcomedilib/kcomedilib_main.c
index 3f20ea5..944ba9d 100644
--- a/drivers/staging/comedi/kcomedilib/kcomedilib_main.c
+++ b/drivers/staging/comedi/kcomedilib/kcomedilib_main.c
@@ -95,7 +95,8 @@ static int comedi_do_insn(struct comedi_device *dev,
s = >subdevices[insn->subdev];
if (s->type == COMEDI_SUBD_UNUSED) {
- printk(KERN_ERR "%d not useable subdevice\n", insn->subdev);
+ dev_err(dev->class_dev,
+ "%d not useable subdevice\n", insn->subdev);
ret = -EIO;
goto error;
}
@@ -104,7 +105,7 @@ static int comedi_do_insn(struct comedi_device *dev,
ret = comedi_check_chanlist(s, 1, >chanspec);
if (ret < 0) {
- printk(KERN_ERR "bad chanspec\n");
+ dev_err(dev->class_dev, "bad chanspec\n");
ret = -EINVAL;
goto error;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net, TTY: initialize tty->driver_data before usage
Commit 9c650ffc ("TTY: ircomm_tty, add tty install") split _open() to
_install() and _open(). It also moved the initialization of driver_data
out of open(), but never added it to install() - causing a NULL ptr
deref whenever the driver was used.
Signed-off-by: Sasha Levin
---
net/irda/ircomm/ircomm_tty.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/irda/ircomm/ircomm_tty.c b/net/irda/ircomm/ircomm_tty.c
index 95a3a7a..496ce2c 100644
--- a/net/irda/ircomm/ircomm_tty.c
+++ b/net/irda/ircomm/ircomm_tty.c
@@ -421,6 +421,8 @@ static int ircomm_tty_install(struct tty_driver *driver,
struct tty_struct *tty)
hashbin_insert(ircomm_tty, (irda_queue_t *) self, line, NULL);
}
+ tty->driver_data = self;
+
return tty_port_install(>port, driver, tty);
}
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net, bluetooth: don't attempt to free a channel that wasn't created
We may currently attempt to free a channel which wasn't created due to
an error in the initialization path, this would cause a NULL ptr deref.
Introduced in commit 61d6ef3e ("Bluetooth: Make better use of l2cap_chan
reference counting").
Signed-off-by: Sasha Levin
---
net/bluetooth/l2cap_sock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 083f2bf..66c295a 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -1083,7 +1083,8 @@ static void l2cap_sock_destruct(struct sock *sk)
{
BT_DBG("sk %p", sk);
- l2cap_chan_put(l2cap_pi(sk)->chan);
+ if (l2cap_pi(sk)->chan)
+ l2cap_chan_put(l2cap_pi(sk)->chan);
if (l2cap_pi(sk)->rx_busy_skb) {
kfree_skb(l2cap_pi(sk)->rx_busy_skb);
l2cap_pi(sk)->rx_busy_skb = NULL;
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fs: handle failed audit_log_start properly
audit_log_start() may return NULL, this is unchecked by the caller in
audit_log_link_denied() and could cause a NULL ptr deref.
Introduced by commit a51d9eaa ("fs: add link restriction audit reporting").
Signed-off-by: Sasha Levin
---
kernel/audit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/audit.c b/kernel/audit.c
index 4d0ceed..40414e9 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1440,6 +1440,8 @@ void audit_log_link_denied(const char *operation, struct
path *link)
ab = audit_log_start(current->audit_context, GFP_KERNEL,
AUDIT_ANOM_LINK);
+ if (!ab)
+ return;
audit_log_format(ab, "op=%s action=denied", operation);
audit_log_format(ab, " pid=%d comm=", current->pid);
audit_log_untrustedstring(ab, current->comm);
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fs: prevent use after free in auditing when symlink following was denied
Commit "fs: add link restriction audit reporting" has added auditing of failed
attempts to follow symlinks. Unfortunately, the auditing was being done after
the struct path structure was released earlier.
Signed-off-by: Sasha Levin
---
fs/namei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/namei.c b/fs/namei.c
index aa30d19..6d47fac 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -692,9 +692,9 @@ static inline int may_follow_link(struct path *link, struct
nameidata *nd)
if (uid_eq(parent->i_uid, inode->i_uid))
return 0;
+ audit_log_link_denied("follow_link", link);
path_put_conditional(link, nd);
path_put(>path);
- audit_log_link_denied("follow_link", link);
return -EACCES;
}
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] UAPI disintegration fixes
Hi Linus, Could you pull this branch please? There are three main parts: (1) I found I needed some more fixups in the wake of testing Arm64 (some asm/unistd.h files had weird guards that caused problems - mostly in arches for which I don't have a compiler) and some __KERNEL__ splitting needed to take place in Arm64. (2) I found that c6x was missing some __KERNEL__ guards in its asm/signal.h. Mark Salter pointed me at a tree with a patch to remove that file entirely and use the asm-generic variant instead. (3) Lastly, m68k turned out to have a header installation problem due to it lacking a kvm_para.h file. The conditional installation bits for linux/kvm_para.h, linux/kvm.h and linux/a.out.h weren't very well specified - and didn't work if an arch didn't have the asm/ version of that file, but there *was* an asm-generic/ version. It seems the "ifneq $((wildcard ...),)" for each of those three headers in include/kernel/Kbuild is invoked twice during header installation, and the second time it matches on the just installed asm-generic/kvm_para.h file and thus incorrectly installs linux/kvm_para.h as well. Most arches actually have an asm/kvm_para.h, so this wasn't detectable in those. David --- The following changes since commit 612a9aab56a93533e76e3ad91642db7033e03b69: Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux (2012-10-03 23:29:23 -0700) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git uapi-prep for you to fetch changes up to f3dfd599af993385b40fc7a1c947afc12729bc4d: UAPI: Fix conditional header installation handling (notably kvm_para.h on m68k) (2012-10-04 18:16:47 +0100) (from the branch description for uapi-prep local branch) clone of "master" David Howells (4): UAPI: Fix the guards on various asm/unistd.h files UAPI: Split compound conditionals containing __KERNEL__ in Arm64 Merge remote-tracking branch 'c6x/for-linux-next' into uapi-prep UAPI: Fix conditional header installation handling (notably kvm_para.h on m68k) Mark Salter (2): c6x: make dsk6455 the default config c6x: remove c6x signal.h arch/arm64/include/asm/hwcap.h | 4 +++- arch/arm64/include/asm/stat.h | 4 +++- arch/arm64/include/asm/unistd.h | 8 +++- arch/arm64/include/asm/unistd32.h | 4 arch/c6x/Makefile | 2 ++ arch/c6x/include/asm/Kbuild | 1 + arch/c6x/include/asm/signal.h | 17 - arch/c6x/include/asm/unistd.h | 4 arch/hexagon/include/asm/unistd.h | 5 - arch/openrisc/include/asm/unistd.h | 5 - arch/score/include/asm/unistd.h | 5 - arch/tile/include/asm/unistd.h | 5 - arch/unicore32/include/asm/unistd.h | 4 include/asm-generic/unistd.h| 4 include/linux/Kbuild| 9 +++-- 15 files changed, 15 insertions(+), 66 deletions(-) delete mode 100644 arch/c6x/include/asm/signal.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 133/180] cciss: fix incorrect scsi status reporting
On Thu, Oct 04, 2012 at 11:49:50PM +0100, Ben Hutchings wrote:
> On Tue, Oct 02, 2012 at 12:54:10AM +0200, Willy Tarreau wrote:
> > 2.6.32-longterm review patch. If anyone has any objections, please let me
> > know.
> >
> > --
> >
> > From: Stephen M. Cameron
> >
> > commit b0cf0b118c90477d1a6811f2cd2307f6a5578362 upstream.
> >
> > Delete code which sets SCSI status incorrectly as it's already been set
> > correctly above this incorrect code. The bug was introduced in 2009 by
> > commit b0e15f6db111 ("cciss: fix typo that causes scsi status to be
> > lost.")
>
> That commit was in 2.6.33 and it changed the '<' to '<<'. It hasn't
> been backported to 2.6.32.y.
But apparently the status was already incorrect before the first patch
which tried to fix it first. I based myself on the comment from this
patch which says "it's already been set correctly above this incorrect code".
Above we find this :
cmd->result = (DID_OK << 16); /* host byte */
cmd->result |= (COMMAND_COMPLETE << 8); /* msg byte */
/* cmd->result |= (GOOD < 1); *//* status byte */
cmd->result |= (ei->ScsiStatus);
If such a status is valid, then I conclude that both the following forms
from the two previous versions are incorrect :
- cmd->result |= (ei->ScsiStatus < 1);
+ cmd->result |= (ei->ScsiStatus << 1);
Hence I preferred to backport the fix and have the same code as in mainline
and newer versions which nobody has yet complained about.
> > - cmd->result |= (ei->ScsiStatus < 1);
> [...]
>
> Unless ei->ScsiStatus can be negative (it is declared as int, but
> I don't think it's actually meant to be negative), this statement
> is a no-op.
Hmmm I disagree here, the code above does exactly the same thing as :
cmd->result |= !ei->ScsiStatus;
Which looks kind of strange to me after doing the exact opposite above,
since the result is that the lowest bit of cmd->result will always be
forced to 1 whatever ScsiStatus between 0 and 1. This might be what the
original patch author meant with "fix typo that causes scsi status to
be lost".
So I'd rather keep this fix.
Regards,
Willy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 147/180] udf: Fortify loading of sparing table
On Fri, Oct 05, 2012 at 12:15:57AM +0100, Ben Hutchings wrote: > On Tue, Oct 02, 2012 at 12:54:24AM +0200, Willy Tarreau wrote: > > 2.6.32-longterm review patch. If anyone has any objections, please let me > > know. > > > > -- > > > > From: Jan Kara > > > > commit 1df2ae31c724e57be9d7ac00d78db8a5dabdd050 upstream. > > > > Add sanity checks when loading sparing table from disk to avoid accessing > > unallocated memory or writing to it. > [...] > > It looks like commit 68766a2edcd5cd744262a70a2f67a320ac944760 should > be added after this. Thanks, queued! Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: add TS-5500 DIO headers support
Hi, Grant, Linus, any feedback? Thanks, Vivien On Wed, 2012-09-26 at 11:37 -0400, Vivien Didelot wrote: > > +config GPIO_TS5500 > > + tristate "TS-5500 DIO Headers" > > + depends on TS5500 > > + help > > + This driver supports the 3 Digital I/O headers of the > Technologic > > + Systems TS-5500 platform: DIO1, DIO2, and the LCD port which > may be > > + used as a DIO header. > > I moved the GPIO_TS5500 entry at the good place in the "Memory mapped > GPIO drivers" section. But I'm still worried about select/depends on. > I removed the TS5500 symbol dependency, which is not defined yet (will > be done in the future board support patch). Does the following entry > seem good? > > config GPIO_TS5500 > tristate "TS-5500 DIO Headers support" > help > This driver supports the 3 Digital I/O headers of the > Technologic Systems TS-5500 platform: DIO1, DIO2, and > the > LCD port which may be used as a DIO header. > > Regards, > Vivien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 147/180] udf: Fortify loading of sparing table
On Tue, Oct 02, 2012 at 12:54:24AM +0200, Willy Tarreau wrote: > 2.6.32-longterm review patch. If anyone has any objections, please let me > know. > > -- > > From: Jan Kara > > commit 1df2ae31c724e57be9d7ac00d78db8a5dabdd050 upstream. > > Add sanity checks when loading sparing table from disk to avoid accessing > unallocated memory or writing to it. [...] It looks like commit 68766a2edcd5cd744262a70a2f67a320ac944760 should be added after this. 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 linux-kernel" in the body of a message to majord...@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] usb: gadget: ncm: correct endianess conversion
Signed-off-by: Dmytro Milinevskyy --- drivers/usb/gadget/f_ncm.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/usb/gadget/f_ncm.c b/drivers/usb/gadget/f_ncm.c index b651b52..fce45ab 100644 --- a/drivers/usb/gadget/f_ncm.c +++ b/drivers/usb/gadget/f_ncm.c @@ -869,11 +869,11 @@ static struct sk_buff *ncm_wrap_ntb(struct gether *port, struct sk_buff *skb2; int ncb_len = 0; __le16 *tmp; - int div = ntb_parameters.wNdpInDivisor; - int rem = ntb_parameters.wNdpInPayloadRemainder; - int pad; - int ndp_align = ntb_parameters.wNdpInAlignment; - int ndp_pad; + int div = le16_to_cpu(ntb_parameters.wNdpInDivisor); + int rem = le16_to_cpu(ntb_parameters.wNdpInPayloadRemainder); + int pad; + int ndp_align = le16_to_cpu(ntb_parameters.wNdpInAlignment); + int ndp_pad; unsignedmax_size = ncm->port.fixed_in_len; struct ndp_parser_opts *opts = ncm->parser_opts; unsignedcrc_len = ncm->is_crc ? sizeof(uint32_t) : 0; -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
virtio build breakage.
After linking, I see this.. ERROR: "virtqueue_kick" [net/9p/9pnet_virtio.ko] undefined! ERROR: "virtqueue_get_buf" [net/9p/9pnet_virtio.ko] undefined! ERROR: "virtqueue_add_buf" [net/9p/9pnet_virtio.ko] undefined! ERROR: "virtqueue_notify" [drivers/scsi/virtio_scsi.ko] undefined! ERROR: "virtqueue_kick_prepare" [drivers/scsi/virtio_scsi.ko] undefined! ERROR: "virtqueue_kick" [drivers/scsi/virtio_scsi.ko] undefined! ERROR: "virtqueue_add_buf" [drivers/scsi/virtio_scsi.ko] undefined! ERROR: "virtqueue_enable_cb" [drivers/scsi/virtio_scsi.ko] undefined! ERROR: "virtqueue_get_buf" [drivers/scsi/virtio_scsi.ko] undefined! ERROR: "virtqueue_disable_cb" [drivers/scsi/virtio_scsi.ko] undefined! ERROR: "vring_del_virtqueue" [drivers/remoteproc/remoteproc.ko] undefined! ERROR: "vring_new_virtqueue" [drivers/remoteproc/remoteproc.ko] undefined! ERROR: "vring_interrupt" [drivers/remoteproc/remoteproc.ko] undefined! ERROR: "vring_transport_features" [drivers/remoteproc/remoteproc.ko] undefined! ERROR: "virtqueue_enable_cb_delayed" [drivers/net/virtio_net.ko] undefined! ERROR: "virtqueue_enable_cb" [drivers/net/virtio_net.ko] undefined! ERROR: "virtqueue_kick" [drivers/net/virtio_net.ko] undefined! ERROR: "virtqueue_add_buf" [drivers/net/virtio_net.ko] undefined! ERROR: "virtqueue_disable_cb" [drivers/net/virtio_net.ko] undefined! ERROR: "virtqueue_get_buf" [drivers/net/virtio_net.ko] undefined! ERROR: "virtqueue_detach_unused_buf" [drivers/net/virtio_net.ko] undefined! ERROR: "virtqueue_get_vring_size" [drivers/net/virtio_net.ko] undefined! ERROR: "virtqueue_disable_cb" [drivers/char/virtio_console.ko] undefined! ERROR: "virtqueue_detach_unused_buf" [drivers/char/virtio_console.ko] undefined! ERROR: "virtqueue_kick" [drivers/char/virtio_console.ko] undefined! ERROR: "virtqueue_add_buf" [drivers/char/virtio_console.ko] undefined! ERROR: "virtqueue_get_buf" [drivers/char/virtio_console.ko] undefined! ERROR: "virtqueue_kick" [drivers/char/hw_random/virtio-rng.ko] undefined! ERROR: "virtqueue_add_buf" [drivers/char/hw_random/virtio-rng.ko] undefined! ERROR: "virtqueue_get_buf" [drivers/char/hw_random/virtio-rng.ko] undefined! ERROR: "virtqueue_kick" [drivers/block/virtio_blk.ko] undefined! ERROR: "virtqueue_add_buf" [drivers/block/virtio_blk.ko] undefined! ERROR: "virtqueue_get_buf" [drivers/block/virtio_blk.ko] undefined! config is at http://fpaste.org/svfL/raw Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 133/180] cciss: fix incorrect scsi status reporting
On Tue, Oct 02, 2012 at 12:54:10AM +0200, Willy Tarreau wrote:
> 2.6.32-longterm review patch. If anyone has any objections, please let me
> know.
>
> --
>
> From: Stephen M. Cameron
>
> commit b0cf0b118c90477d1a6811f2cd2307f6a5578362 upstream.
>
> Delete code which sets SCSI status incorrectly as it's already been set
> correctly above this incorrect code. The bug was introduced in 2009 by
> commit b0e15f6db111 ("cciss: fix typo that causes scsi status to be
> lost.")
That commit was in 2.6.33 and it changed the '<' to '<<'. It hasn't
been backported to 2.6.32.y.
[...]
> diff --git a/drivers/block/cciss_scsi.c b/drivers/block/cciss_scsi.c
> index 3315268..ad8e592 100644
> --- a/drivers/block/cciss_scsi.c
> +++ b/drivers/block/cciss_scsi.c
> @@ -747,17 +747,7 @@ complete_scsi_command( CommandList_struct *cp, int
> timeout, __u32 tag)
> {
> case CMD_TARGET_STATUS:
> /* Pass it up to the upper layers... */
> - if( ei->ScsiStatus)
> - {
> -#if 0
> - printk(KERN_WARNING "cciss: cmd %p "
> - "has SCSI Status = %x\n",
> - cp,
> - ei->ScsiStatus);
> -#endif
> - cmd->result |= (ei->ScsiStatus < 1);
[...]
Unless ei->ScsiStatus can be negative (it is declared as int, but
I don't think it's actually meant to be negative), this statement
is a no-op. (It was present for the entire life of this driver up
until 2.6.33, so I suspect that is the case.) So this backported
patch is unnecessary cleanup, not a bug fix.
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 linux-kernel" in
the body of a message to majord...@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: RNG: is it possible to spoil /dev/random by seeding it from (evil) TRNGs
On Thu, Oct 04, 2012 at 03:32:35PM +0200, Christoph Anton Mitterer wrote: > > When seeding the kernels entropy cache (which is then ultimately used > for /dev/random), e.g. by (semi-)TRNGs like haveged[0], > audio-entropyd[1], Simtec’s Entropy Key[2] or friends... can one spoil > the randomness by that or is this impossible by design? It is impossible by design. Or specifically, /dev/random was designed so that it can be world-writeable, and an attacker can feed in any kind of input he or she wants, and it will not allow the attacker to know anything more about the state of the entropy pool than he or she knew before they started mixing inputs in. There are comments that go into more detail about the design in drivers/char/random.c. Credit for the design goes to Colin Plumb, who designed RNG in the original PGP 2.x implementation, BTW. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] ACPI: kill acpi_pci_root_start
On Thu, Oct 4, 2012 at 3:36 PM, Rafael J. Wysocki wrote: > On Thursday 04 of October 2012 15:01:21 Yinghai Lu wrote: >> during adding pci root bus hotplug, Bjorn found some unsafe searching >> that caused by pci_bus_add_devices. > > Do you have a link to a description of that problem? Maybe bjorn could expand it more. > >> pci devices are created during pci scan root, but until very late >> acpi_pci_root_start call pci_bus_add_devices. > > So you mean that pci_bus_add_devices() is called too late, right? yes. > >> To fill the gap, we need to move pci_bus_add_devices to acpi_pci_root_add >> at first. >> >> but after we move that there, pci device will be added to device tree, and it >> will try to bind with acpi devices that should be under acpi pci root, >> but are not >> created yet. because device_add for acpi_device for acpi pci root is done >> yet. >> it still calling the .add in the acpi_driver aka acpi_pci_root_add. > > Quite obviously, we haven't walked the ACPI namespace below the host bridge > object yet at that point. yes. > >> So I want to hold the driver attach for pci root acpi devices, and >> later attach it >> until pci devices created. >> >> booting path, all acpi devices get created, and attach driver for them >> one by one. > > I see. > > Your patches seem to affect all devices in the ACPI namespace added after > boot, though, not only host bridges. yes, but it still should be safe. > > And the problem seems to be that the scanning of the ACPI namespace and > configuring the host bridge are kind of independent operations now. What > we should do, actually, seems to be something like this: > > (1) Configure the host bridge when discovered (i.e. do what the current > acpi_pci_root_add() does. > (2) Parse the ACPI namespace under the host bridge (without binding ACPI > drivers to the struct acpi_device objects created in the process, > because they are known to correspond to PCI devices). > (3) Run pci_bus_add_devices() for the bridge. > > in one routine. problem is still there. if 1 still has acpi_pci_root_add and pci_acpi_scan_root that scan pci devices. what is need is we need to bind 1 and 3 together. or we could move pci_scan_root_scan from acpi_pci_root_add to acpi_pci_root_start? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PRJQUOTA case not handled in need_print_warning()
Hi, commit e8a3e4719b7ec19288c56f22623f537cb78885c1 Author: Eric W. Biederman Date: Sun Sep 16 01:11:45 2012 -0700 userns: Implement struct kqid causes this warning: fs/quota/dquot.c: In function ‘need_print_warning’: fs/quota/dquot.c:1158: warning: enumeration value ‘PRJQUOTA’ not handled in switch and it seems to be a valid one -- the switch in need_print_warning() contains neither 'default' nor PRJQUOTA case handler. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] ACPI: kill acpi_pci_root_start
On Thursday 04 of October 2012 15:01:21 Yinghai Lu wrote: > On Thu, Oct 4, 2012 at 2:53 PM, Rafael J. Wysocki wrote: > > On Thursday 04 of October 2012 14:31:46 Yinghai Lu wrote: > >> On Thu, Oct 4, 2012 at 2:23 PM, Rafael J. Wysocki wrote: > >> >> > >> >> At last we could remove all acpi_bus_start workaround. > >> > > >> > Do I understand correctly that you just want to prevent > >> > acpi_pci_root_driver > >> > from binding to the host bridge's struct acpi_device created while we're > >> > walking the ACPI namespace? > >> > >> yes, during hot add path. > > > > Why exactly do you want to prevent that from happening? > > > > during adding pci root bus hotplug, Bjorn found some unsafe searching > that caused by pci_bus_add_devices. Do you have a link to a description of that problem? > pci devices are created during pci scan root, but until very late > acpi_pci_root_start call pci_bus_add_devices. So you mean that pci_bus_add_devices() is called too late, right? > To fill the gap, we need to move pci_bus_add_devices to acpi_pci_root_add > at first. > > but after we move that there, pci device will be added to device tree, and it > will try to bind with acpi devices that should be under acpi pci root, > but are not > created yet. because device_add for acpi_device for acpi pci root is done yet. > it still calling the .add in the acpi_driver aka acpi_pci_root_add. Quite obviously, we haven't walked the ACPI namespace below the host bridge object yet at that point. > So I want to hold the driver attach for pci root acpi devices, and > later attach it > until pci devices created. > > booting path, all acpi devices get created, and attach driver for them > one by one. I see. Your patches seem to affect all devices in the ACPI namespace added after boot, though, not only host bridges. And the problem seems to be that the scanning of the ACPI namespace and configuring the host bridge are kind of independent operations now. What we should do, actually, seems to be something like this: (1) Configure the host bridge when discovered (i.e. do what the current acpi_pci_root_add() does. (2) Parse the ACPI namespace under the host bridge (without binding ACPI drivers to the struct acpi_device objects created in the process, because they are known to correspond to PCI devices). (3) Run pci_bus_add_devices() for the bridge. in one routine. What do you think? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] mmc: core: Add support for idle time BKOPS
Devices have various maintenance operations need to perform internally.
In order to reduce latencies during time critical operations like read
and write, it is better to execute maintenance operations in other
times - when the host is not being serviced. Such operations are called
Background operations (BKOPS).
The device notifies the status of the BKOPS need by updating BKOPS_STATUS
(EXT_CSD byte [246]).
According to the standard a host that supports BKOPS shall check the
status periodically and start background operations as needed, so that
the device has enough time for its maintenance operations.
This patch adds support for this periodic check of the BKOPS status.
Since foreground operations are of higher priority than background
operations the host will check the need for BKOPS when it is idle,
and in case of an incoming request the BKOPS operation will be
interrupted.
When the mmcqd thread is idle, a delayed work is created to check the
need for BKOPS. The time to start the delayed work is calculated based
on the host controller suspend timeout, in case it was set. If not, a
default time is used.
If BKOPS are required in level 1, which is non-blocking, there will be
polling of the card status to wait for the BKOPS completion and prevent
suspend that will interrupt the BKOPS.
If the card raised an exception, the need for urgent BKOPS (level 2/3)
will be checked immediately and if needed, the BKOPS will be performed
without waiting for the next idle time.
Signed-off-by: Maya Erez
Signed-off-by: Jaehoon Chung
---
This patch is based on the periodic BKOPS implementation in version 8 of
"support BKOPS feature for eMMC" patch.
The patch was modified to answer the following issues:
- In order to prevent a race condition between going into suspend and starting
BKOPS,
the suspend timeout of the host controller is taking into accound in
determination of the start time
of the delayed work
- Since mmc_start_bkops is called from two contexts now, mmc_claim_host was
moved to the beginning of the function
- Also, the check of doing_bkops should be protected when determing if an HPI
is needed due to the same reason.
- Starting and canceling the delayed work in each idle caused degradation of
iozone performance. Therefore,
the delayed work is not started on each idle. The amount of sectors changed
(written or discard) from the last
delayed work is the trigger for starting the delayed BKOPS work.
---
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 172a768..ed040d5 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -827,6 +827,9 @@ static int mmc_blk_issue_discard_rq(struct mmc_queue *mq,
struct request *req)
from = blk_rq_pos(req);
nr = blk_rq_sectors(req);
+ if (card->ext_csd.bkops_en)
+ card->bkops_info.sectors_changed += blk_rq_sectors(req);
+
if (mmc_can_discard(card))
arg = MMC_DISCARD_ARG;
else if (mmc_can_trim(card))
@@ -1268,6 +1271,9 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq,
struct request *rqc)
if (!rqc && !mq->mqrq_prev->req)
return 0;
+ if (rqc && (card->ext_csd.bkops_en) && (rq_data_dir(rqc) == WRITE))
+ card->bkops_info.sectors_changed += blk_rq_sectors(rqc);
+
do {
if (rqc) {
/*
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index e360a97..e96f5cf 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -51,6 +51,7 @@ static int mmc_queue_thread(void *d)
{
struct mmc_queue *mq = d;
struct request_queue *q = mq->queue;
+ struct mmc_card *card = mq->card;
current->flags |= PF_MEMALLOC;
@@ -66,6 +67,17 @@ static int mmc_queue_thread(void *d)
spin_unlock_irq(q->queue_lock);
if (req || mq->mqrq_prev->req) {
+ /*
+* If this is the first request, BKOPs might be in
+* progress and needs to be stopped before issuing the
+* request
+*/
+ if (card->ext_csd.bkops_en &&
+ card->bkops_info.started_delayed_bkops) {
+ card->bkops_info.started_delayed_bkops = false;
+ mmc_stop_bkops(card);
+ }
+
set_current_state(TASK_RUNNING);
mq->issue_fn(mq, req);
} else {
@@ -73,6 +85,7 @@ static int mmc_queue_thread(void *d)
set_current_state(TASK_RUNNING);
break;
}
+ mmc_start_delayed_bkops(card);
up(>thread_sem);
schedule();
down(>thread_sem);
diff --git a/drivers/mmc/core/core.c
Re: Re: 3.4.10 i915 [GM45] regression
On Tue, Oct 02, 2012 at 09:17:22AM +0200, Daniel Vetter wrote: > On Mon, Oct 1, 2012 at 11:56 PM, Andreas Sturmlechner > wrote: > >> Andreas, can you please check whether 3.5.x works for you, just to > >> make sure that this particular elephant is only wreaking havoc in 3.4 > >> and earlier? > > > > I've been using 3.5 all the time since .0, I never had any trouble there - > > a few reboots just now with a vanilla 3.5.4 image were > > successful as expected. Meanwhile I have upgraded to 3.6, zero issues as > > well. > > So 3.5 and later really don't seem to have any issue with this patch. > I'm as puzzled as ever. Thanks for testing this again. I forgot to revert this for 3.4, I'll do so in the next 3.4-stable release after this one, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Seems like "sched: Add missing call to calc_load_exit_idle()" should be reverted in 3.5 branch
On Thu, Oct 04, 2012 at 08:31:59PM +0200, Peter Zijlstra wrote: > On Thu, 2012-10-04 at 10:46 -0700, Greg Kroah-Hartman wrote: > > On Thu, Oct 04, 2012 at 12:11:01PM +0800, Huacai Chen wrote: > > > Hi, Greg > > > > > > I found that Linux-3.5.5 accept this commit "sched: Add missing call > > > to calc_load_exit_idle()" but I think this isn't needed. Because > > > "5167e8d5417b sched/nohz: Rewrite and fix load-avg computation -- > > > again not fully applied" is true for 3.6 branch, but not for 3.5 > > > branch. > > > > But 5167e8d5417b is in 3.5, so shouldn't this commit still be necessary? > > > > > In 3.5 branch, calc_load_exit_idle() is already called in > > > tick_nohz_idle_exit(), it doesn't need to be called at > > > tick_nohz_update_jiffies() again. In 3.6 branch, some code of > > > tick_nohz_idle_exit() is splitted to tick_nohz_restart_sched_tick() > > > and calc_load_exit_idle() is missing by accident, so commit "sched: > > > Add missing call to calc_load_exit_idle()" is needed. > > > > So this really should be dropped from 3.5? Charles, Peter, Ingo, any > > thoughts here? > > Bah, lots of code movement there recently.. let me try and untangle all > that afresh.. /me checks out v3.5.5. > > OK, assuming ->tick_stopped means what the label says, then we only want > to call calc_load_enter_idle() when it flips to 1 and > calc_load_exit_idle() when it flips back to 0, such that when an actual > tick happens its got correct state. > > Now the actual patch "5167e8d5417b sched/nohz: Rewrite and fix load-avg > computation -- again not fully applied" modifies > tick_nohz_restart_sched_tick() which doesn't appear to exist in v3.5.5 > and the patch fobbed it into tick_nohz_update_jiffies() which is called > from interrupt entry when nohz-idle so that the interrupt (and possible > tailing softirq) see a valid jiffies count. > > However, since we don't restart the tick, we won't be sampling load muck > and calling calc_load_exit_idle() from there is bound to confuse state. > > I hope.. damn this code ;-) > > I can't find wtf went wrong either, the initial patch 5167e8d5417bf5c > contains both hunks, but in that case the fixup 749c8814f0 doesn't make > sense, not can I find anything in merge commits using: > > git log -S calc_load_exit_idle kernel/time/tick-sched.c > > /me puzzled I'm puzzled as well. Any ideas if I should do anything here or not? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] SLAB changes for v3.7-rc0
On Thu, 4 Oct 2012, Pekka Enberg wrote: > Hi Linus, > > Please pull the latest SLAB tree from: > > git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git > slab/for-linus > > New and noteworthy: > > * More SLAB allocator unification patches from Christoph Lameter and > others. This paves the way for slab memcg patches that hopefully > will land in v3.8. > > * SLAB tracing improvements from Ezequiel Garcia. > > * Kernel tainting upon SLAB corruption from Dave Jones. > > * Miscellanous SLAB allocator bug fixes and improvements from various > people. Pekka, what are your plans with https://lkml.org/lkml/2012/10/3/285 please? It'd be nice to have it in Linus' tree reasonably soon, otherwise we'll be receiving false positive lockdep reports over and over again. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v3] dma-debug: New interfaces to debug dma mapping errors
On Thu, 2012-10-04 at 13:38 -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Oct 03, 2012 at 08:55:59AM -0600, Shuah Khan wrote: > > A recent dma mapping error analysis effort showed that a large percentage > > of dma_map_single() and dma_map_page() returns are not checked for mapping > > errors. > > > > Reference: > > http://linuxdriverproject.org/mediawiki/index.php/DMA_Mapping_Error_Analysis > > > > Adding support for tracking dma mapping and unmapping errors to help assess > > the following: > > > > When do dma mapping errors get detected? > > How often do these errors occur? > > Why don't we see failures related to missing dma mapping error checks? > > Are they silent failures? > > > > Patch v3: Addresses review and design comments from Patch v2. > > Patch v2: Addressed design issues from Patch v1. > > > > Enhance dma-debug infrastructure to track dma mapping, and unmapping errors. > > > > map_errors: (system wide counter) > > Total number of dma mapping errors returned by the dma mapping interfaces, > > in response to mapping requests from all devices in the system. > > map_errors_not_checked: (system wide counter) > > Total number of dma mapping errors devices failed to check before using > > the returned address. > > unmap_errors: (system wide counter) > > Total number of times devices tried to unmap or free an invalid dma > > address. > > map_err_type: (new field added to dma_debug_entry structure) > > New field to maintain dma mapping error check status. This error type > > is applicable to the dma map page and dma map single entries tracked by > > dma-debug api. This status indicates whether or not a good mapping is > > checked by the device before its use. dma_map_single() and dma_map_page() > > could fail to create a mapping in some cases, and drivers are expected to > > call dma_mapping_error() to check for errors. Please note that this is not > > counter. > > > > Enhancements to dma-debug api are made to add new debugfs interfaces to > > report total dma errors, dma errors that are not checked, and unmap errors > > for the entire system. Please note that these are system wide counters for > > all devices in the system. > > > > The following new dma-debug interface is added: > > > > debug_dma_mapping_error(struct device *dev, dma_addr_t dma_addr) > > Sets dma map error checked status for the dma map entry if one is > > found. Decrements the system wide dma_map_errors_not_checked counter > > that is incremented by debug_dma_map_page() when it checks for > > mapping error before adding it to the dma debug entry table. > > > > New dma-debug internal interface: > > check_mapping_error(struct device *dev, dma_addr_t dma_addr) > > Calling dma_mapping_error() from dma-debug api will result in dma mapping > > check when it shouldn't. This internal routine checks dma mapping error > > without any debug checks. > > > > The following existing dma-debug api are changed to support this feature: > > debug_dma_map_page() > > Increments dma_map_errors and dma_map_errors_not_checked errors totals > > for the system, dma-debug api keeps track of, when dma_addr is invalid. > > This routine now calls internal check_mapping_error() interface to > > avoid doing dma mapping debug checks from dma-debug internal mapping > > error checks. > > check_unmap() > > This is an existing internal routines that checks for various mapping > > errors. Changed to increment system wide dma_unmap_errors, when a > > device requests an invalid address to be unmapped. This routine now > > calls internal check_mapping_error() interface to avoid doing dma > > mapping debug checks from dma-debug internal mapping error checks. > > > > Changed arch/x86/include/asm/dma-mapping.h to call debug_dma_mapping_error() > > to validate these new interfaces on x86_64. Other architectures will be > > changed in a subsequent patch. > > > > Tested: Intel iommu and swiotlb (iommu=soft) on x86-64 with > > CONFIG_DMA_API_DEBUG enabled and disabled. > > > > Signed-off-by: Shuah Khan > > --- > > Documentation/DMA-API.txt | 13 > > arch/x86/include/asm/dma-mapping.h |1 + > > include/linux/dma-debug.h |7 ++ > > lib/dma-debug.c| 128 > > > > 4 files changed, 136 insertions(+), 13 deletions(-) > > > > diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt > > index 66bd97a..886aaf9 100644 > > --- a/Documentation/DMA-API.txt > > +++ b/Documentation/DMA-API.txt > > @@ -638,6 +638,19 @@ this directory the following files can currently be > > found: > > dma-api/error_count This file is read-only and shows the total > > numbers of errors found. > > > > + dma-api/map_errors This file is read-only and shows the total > > + number of dma mapping errors detected. > > + > > +
[ 04/56] USB: option: blacklist QMI interface on ZTE MF683
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Bjørn Mork
commit 160c9425ac52cb30502be2d9c5e848cec91bb115 upstream.
Interface #5 on ZTE MF683 is a QMI/wwan interface.
Signed-off-by: Bjørn Mork
Cc: Shawn J. Goff
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/option.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -870,7 +870,8 @@ static const struct usb_device_id option
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0153, 0xff, 0xff,
0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0155, 0xff, 0xff,
0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0156, 0xff, 0xff,
0xff) },
- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0157, 0xff, 0xff,
0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0157, 0xff, 0xff,
0xff),
+ .driver_info = (kernel_ulong_t)_intf5_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0158, 0xff, 0xff,
0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0159, 0xff, 0xff,
0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0161, 0xff, 0xff,
0xff) },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 08/56] usb: host: xhci: Fix Null pointer dereferencing with 71c731a for non-x86 systems
3.6-stable review patch. If anyone has any objections, please let me know. -- From: Vivek Gautam commit 457a73d346187c2cc5d599072f38676f18f130e0 upstream. In 71c731a: usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware when extracting DMI strings (vendor or product_name) to mark them as quirk we may get NULL pointer in case of non-x86 systems which won't define CONFIG_DMI. Hence susbsequent strstr() calls crash while driver probing. So, returning 'false' here in case we get a NULL vendor or product_name. This is tested with ARM (exynos) system. This patch should be backported to stable kernels as old as 3.6, that contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" Signed-off-by: Vivek Gautam Signed-off-by: Sarah Sharp Reported-by: Sebastian Gottschall (DD-WRT) Signed-off-by: Greg Kroah-Hartman --- drivers/usb/host/xhci.c |2 ++ 1 file changed, 2 insertions(+) --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -470,6 +470,8 @@ static bool compliance_mode_recovery_tim dmi_product_name = dmi_get_system_info(DMI_PRODUCT_NAME); dmi_sys_vendor = dmi_get_system_info(DMI_SYS_VENDOR); + if (!dmi_product_name || !dmi_sys_vendor) + return false; if (!(strstr(dmi_sys_vendor, "Hewlett-Packard"))) return false; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 10/56] staging: speakup_soft: Fix reading of init string
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
commit 40fe4f89671fb3c7ded94190fb267402a38b0261 upstream.
softsynth_read() reads a character at a time from the init string;
when it finds the null terminator it sets the initialized flag but
then repeats the last character.
Additionally, if the read() buffer is not big enough for the init
string, the next read() will start reading from the beginning again.
So the caller may never progress to reading anything else.
Replace the simple initialized flag with the current position in
the init string, carried over between calls. Switch to reading
real data once this reaches the null terminator.
(This assumes that the length of the init string can't change, which
seems to be the case. Really, the string and position belong together
in a per-file private struct.)
Tested-by: Samuel Thibault
Signed-off-by: Ben Hutchings
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/speakup/speakup_soft.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
--- a/drivers/staging/speakup/speakup_soft.c
+++ b/drivers/staging/speakup/speakup_soft.c
@@ -40,7 +40,7 @@ static int softsynth_is_alive(struct spk
static unsigned char get_index(void);
static struct miscdevice synth_device;
-static int initialized;
+static int init_pos;
static int misc_registered;
static struct var_t vars[] = {
@@ -194,7 +194,7 @@ static int softsynth_close(struct inode
unsigned long flags;
spk_lock(flags);
synth_soft.alive = 0;
- initialized = 0;
+ init_pos = 0;
spk_unlock(flags);
/* Make sure we let applications go before leaving */
speakup_start_ttys();
@@ -239,13 +239,8 @@ static ssize_t softsynth_read(struct fil
ch = '\x18';
} else if (synth_buffer_empty()) {
break;
- } else if (!initialized) {
- if (*init) {
- ch = *init;
- init++;
- } else {
- initialized = 1;
- }
+ } else if (init[init_pos]) {
+ ch = init[init_pos++];
} else {
ch = synth_buffer_getc();
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 12/56] staging: r8712u: Do not queue cloned skb
3.6-stable review patch. If anyone has any objections, please let me know. -- From: Larry Finger commit fa16e5ea25d7dd83f663f333e70713aa2fa5dffe upstream. Some post-3.4 kernels have a problem when a cloned skb is used in the RX path. This patch handles one such case for r8712u. The patch was suggested by Eric Dumazet. Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman --- drivers/staging/rtl8712/rtl8712_recv.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/staging/rtl8712/rtl8712_recv.c +++ b/drivers/staging/rtl8712/rtl8712_recv.c @@ -1127,6 +1127,9 @@ static void recv_tasklet(void *priv) recvbuf2recvframe(padapter, pskb); skb_reset_tail_pointer(pskb); pskb->len = 0; - skb_queue_tail(>free_recv_skb_queue, pskb); + if (!skb_cloned(pskb)) + skb_queue_tail(>free_recv_skb_queue, pskb); + else + consume_skb(pskb); } } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v3] dma-debug: New interfaces to debug dma mapping errors
On Thu, 2012-10-04 at 10:01 -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Oct 03, 2012 at 02:45:11PM -0700, Andrew Morton wrote: > > On Wed, 03 Oct 2012 08:55:59 -0600 > > Shuah Khan wrote: > > > > > A recent dma mapping error analysis effort showed that a large percentage > > > of dma_map_single() and dma_map_page() returns are not checked for mapping > > > errors. > > > > > > Reference: > > > http://linuxdriverproject.org/mediawiki/index.php/DMA_Mapping_Error_Analysis > > > > > > Adding support for tracking dma mapping and unmapping errors to help > > > assess > > > the following: > > > > > > When do dma mapping errors get detected? > > > How often do these errors occur? > > > Why don't we see failures related to missing dma mapping error checks? > > > Are they silent failures? > > > > This seems to be a strange way of addressing kernel programming errors. > > Instead of fixing them up, we generate lots of statistics about how > > often they happen! > > And by using this we can fix the drivers. Sorry I was out sick for a bit and catching up. Several drivers are missing checks for mapping errors and in several cases in addition to missing mapping error checks, drivers are not doing unmap as they should. Is is very likely the result of cut and paste as you pointed out. After the analysis, I realized it is worth while spending time to provide debug infrastructure driver writers can use to find problems and continue to use it when new mapping code gets added to an existing driver and/or a new driver is written. > > > > Would it not be better to find and fix the buggy code sites? A > > coccinelle script wold probably help here. > > That is the end goal (fixing the buggy code sites). Shuah has > identified the bad culprits. I compiled a list and documented it for review. We have to start fixing them. > > > > > And let's also look at *why* we keep doing this. Partly it's because > > these things are self-propagating - people copy-n-paste bad code so we > > get more bad code. > > > And this patch will now tell the poor engineers that write new code that > they pasted bad code. > > > > > > > Another reason surely is the poor documentation. Suppose our diligent > > programmer goes to the dma_map_single() definition site: > > > > #define dma_map_single(d, a, s, r) dma_map_single_attrs(d, a, s, r, NULL) > > > > No documentation at all. Because it's a stupid macro it doesn't even > > give the types and names of the arguments or the type of the return > > value. > > > > So he goes to dma_map_single_attrs() and finds that is altogether > > undocmented. > > > > So he goes into Documentation/DMA-API-HOWTO.txt, searches for > > "dma_map_single" and finds > > > > : To map a single region, you do: > > : > > : struct device *dev = _dev->dev; > > : dma_addr_t dma_handle; > > : void *addr = buffer->ptr; > > : size_t size = buffer->len; > > : > > : dma_handle = dma_map_single(dev, addr, size, direction); > > : > > : and to unmap it: > > : > > : dma_unmap_single(dev, dma_handle, size, direction); > > > > > > So it is hardly surprising that we keep screwing this up! > > Right, so that should be also modified (Thank you for looking at that)! > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 18/56] TTY: ttyprintk, dont touch behind tty->write_buf
3.6-stable review patch. If anyone has any objections, please let me know. -- From: Jiri Slaby commit ee8b593affdf893012e57f4c54a21984d1b0d92e upstream. If a user provides a buffer larger than a tty->write_buf chunk and passes '\r' at the end of the buffer, we touch an out-of-bound memory. Add a check there to prevent this. Signed-off-by: Jiri Slaby Cc: Samo Pogacnik Signed-off-by: Greg Kroah-Hartman --- drivers/char/ttyprintk.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/char/ttyprintk.c +++ b/drivers/char/ttyprintk.c @@ -67,7 +67,7 @@ static int tpk_printk(const unsigned cha tmp[tpk_curr + 1] = '\0'; printk(KERN_INFO "%s%s", tpk_tag, tmp); tpk_curr = 0; - if (buf[i + 1] == '\n') + if ((i + 1) < count && buf[i + 1] == '\n') i++; break; case '\n': -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 19/56] serial: omap: fix software flow control
3.6-stable review patch. If anyone has any objections, please let me know. -- From: Vikram Pandita commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 upstream. Software flow control register bits were not defined correctly. Also clarify the IXON and IXOFF logic to reflect what userspace wants. Tested-by: Shubhrajyoti D Signed-off-by: Vikram Pandita Signed-off-by: Shubhrajyoti D Acked-by: Tony Lindgren Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman --- arch/arm/plat-omap/include/plat/omap-serial.h |4 ++-- drivers/tty/serial/omap-serial.c | 12 ++-- 2 files changed, 8 insertions(+), 8 deletions(-) --- a/arch/arm/plat-omap/include/plat/omap-serial.h +++ b/arch/arm/plat-omap/include/plat/omap-serial.h @@ -42,10 +42,10 @@ #define OMAP_UART_WER_MOD_WKUP 0X7F /* Enable XON/XOFF flow control on output */ -#define OMAP_UART_SW_TX0x04 +#define OMAP_UART_SW_TX0x8 /* Enable XON/XOFF flow control on input */ -#define OMAP_UART_SW_RX0x04 +#define OMAP_UART_SW_RX0x2 #define OMAP_UART_SYSC_RESET 0X07 #define OMAP_UART_TCR_TRIG 0X0F --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -667,19 +667,19 @@ serial_omap_configure_xonxoff /* * IXON Flag: -* Enable XON/XOFF flow control on output. -* Transmit XON1, XOFF1 +* Flow control for OMAP.TX +* OMAP.RX should listen for XON/XOFF */ if (termios->c_iflag & IXON) - up->efr |= OMAP_UART_SW_TX; + up->efr |= OMAP_UART_SW_RX; /* * IXOFF Flag: -* Enable XON/XOFF flow control on input. -* Receiver compares XON1, XOFF1. +* Flow control for OMAP.RX +* OMAP.TX should send XON/XOFF */ if (termios->c_iflag & IXOFF) - up->efr |= OMAP_UART_SW_RX; + up->efr |= OMAP_UART_SW_TX; serial_out(up, UART_EFR, up->efr | UART_EFR_ECB); serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 20/56] serial: pl011: handle corruption at high clock speeds
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Walleij
commit c5dd553b9fd069892c9e2de734f4f604e280fa7a upstream.
This works around a few glitches in the ST version of the PL011
serial driver when using very high baud rates, as we do in the
Ux500: 3, 3.25, 4 and 4.05 Mbps.
Problem Observed/rootcause:
When using high baud-rates, and the baudrate*8 is getting close to
the provided clock frequency (so a division factor close to 1), when
using bursts of characters (so they are abutted), then it seems as if
there is not enough time to detect the beginning of the start-bit which
is a timing reference for the entire character, and thus the sampling
moment of character bits is moving towards the end of each bit, instead
of the middle.
Fix:
Increase slightly the RX baud rate of the UART above the theoretical
baudrate by 5%. This will definitely give more margin time to the
UART_RX to correctly sample the data at the middle of the bit period.
Also fix the ages old copy-paste error in the very stressed comment,
it's referencing the registers used in the PL010 driver rather than
the PL011 ones.
Signed-off-by: Guillaume Jaunet
Signed-off-by: Christophe Arnal
Signed-off-by: Matthias Locher
Signed-off-by: Rajanikanth HV
Cc: Bibek Basu
Cc: Par-Gunnar Hjalmdahl
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
---
drivers/tty/serial/amba-pl011.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1603,13 +1603,26 @@ pl011_set_termios(struct uart_port *port
old_cr &= ~ST_UART011_CR_OVSFACT;
}
+ /*
+* Workaround for the ST Micro oversampling variants to
+* increase the bitrate slightly, by lowering the divisor,
+* to avoid delayed sampling of start bit at high speeds,
+* else we see data corruption.
+*/
+ if (uap->vendor->oversampling) {
+ if ((baud >= 300) && (baud < 325) && (quot > 1))
+ quot -= 1;
+ else if ((baud > 325) && (quot > 2))
+ quot -= 2;
+ }
/* Set baud rate */
writew(quot & 0x3f, port->membase + UART011_FBRD);
writew(quot >> 6, port->membase + UART011_IBRD);
/*
* --v--v--v--v-
-* NOTE: MUST BE WRITTEN AFTER UARTLCR_M & UARTLCR_L
+* NOTE: lcrh_tx and lcrh_rx MUST BE WRITTEN AFTER
+* UART011_FBRD & UART011_IBRD.
* --^--^--^--^-
*/
writew(lcr_h, port->membase + uap->lcrh_rx);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 14/56] staging: comedi: jr3_pci: fix iomem dereference
3.6-stable review patch. If anyone has any objections, please let me know. -- From: Ian Abbott commit e1878957b4676a17cf398f7f5723b365e9a2ca48 upstream. Correct a direct dereference of I/O memory to use an appropriate I/O memory access function. Note that the pointer being dereferenced is not currently tagged with `__iomem` but I plan to correct that for 3.7. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman --- drivers/staging/comedi/drivers/jr3_pci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/staging/comedi/drivers/jr3_pci.c +++ b/drivers/staging/comedi/drivers/jr3_pci.c @@ -884,7 +884,7 @@ static int jr3_pci_attach(struct comedi_ } /* Reset DSP card */ - devpriv->iobase->channel[0].reset = 0; + writel(0, >iobase->channel[0].reset); result = comedi_load_firmware(dev, "jr3pci.idm", jr3_download_firmware); dev_dbg(dev->class_dev, "Firmare load %d\n", result); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 25/56] b43legacy: Fix crash on unload when firmware not available
3.6-stable review patch. If anyone has any objections, please let me know. -- From: Larry Finger commit 2d838bb608e2d1f6cb4280e76748cb812dc822e7 upstream. When b43legacy is loaded without the firmware being available, a following unload generates a kernel NULL pointer dereference BUG as follows: [ 214.330789] BUG: unable to handle kernel NULL pointer dereference at 004c [ 214.330997] IP: [] drain_workqueue+0x15/0x170 [ 214.331179] *pde = [ 214.331311] Oops: [#1] SMP [ 214.331471] Modules linked in: b43legacy(-) ssb pcmcia mac80211 cfg80211 af_packet mperf arc4 ppdev sr_mod cdrom sg shpchp yenta_socket pcmcia_rsrc pci_hotplug pcmcia_core battery parport_pc parport floppy container ac button edd autofs4 ohci_hcd ehci_hcd usbcore usb_common thermal processor scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh fan thermal_sys hwmon ata_generic pata_ali libata [last unloaded: cfg80211] [ 214.333421] Pid: 3639, comm: modprobe Not tainted 3.6.0-rc6-wl+ #163 Source Technology VIC 9921/ALI Based Notebook [ 214.333580] EIP: 0060:[] EFLAGS: 00010246 CPU: 0 [ 214.333687] EIP is at drain_workqueue+0x15/0x170 [ 214.333788] EAX: c162ac40 EBX: cdfb8360 ECX: 002a EDX: 2a2a [ 214.333890] ESI: EDI: EBP: cd767e7c ESP: cd767e5c [ 214.333957] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 214.333957] CR0: 8005003b CR2: 004c CR3: 0c96a000 CR4: 0090 [ 214.333957] DR0: DR1: DR2: DR3: [ 214.333957] DR6: 0ff0 DR7: 0400 [ 214.333957] Process modprobe (pid: 3639, ti=cd766000 task=cf802e90 task.ti=cd766000) [ 214.333957] Stack: [ 214.333957] 0292 cd767e74 c12c5e09 0296 0296 cdfb8360 cdfb9220 [ 214.333957] cd767e90 c104c4fd cdfb8360 cdfb9220 cd682800 cd767ea4 d0c10184 cd682800 [ 214.333957] cd767ea4 cba31064 cd767eb8 d0867908 cba31064 d087e09c cd96f034 cd767ec4 [ 214.333957] Call Trace: [ 214.333957] [] ? skb_dequeue+0x49/0x60 [ 214.333957] [] destroy_workqueue+0xd/0x150 [ 214.333957] [] ieee80211_unregister_hw+0xc4/0x100 [mac80211] [ 214.333957] [] b43legacy_remove+0x78/0x80 [b43legacy] [ 214.333957] [] ssb_device_remove+0x1d/0x30 [ssb] [ 214.333957] [] __device_release_driver+0x5a/0xb0 [ 214.333957] [] driver_detach+0x87/0x90 [ 214.333957] [] bus_remove_driver+0x6c/0xe0 [ 214.333957] [] driver_unregister+0x40/0x70 [ 214.333957] [] ssb_driver_unregister+0xb/0x10 [ssb] [ 214.333957] [] b43legacy_exit+0xd/0xf [b43legacy] [ 214.333957] [] sys_delete_module+0x14e/0x2b0 [ 214.333957] [] ? vfs_write+0xf7/0x150 [ 214.333957] [] ? tty_write_lock+0x50/0x50 [ 214.333957] [] ? sys_write+0x38/0x70 [ 214.333957] [] syscall_call+0x7/0xb [ 214.333957] Code: bc 27 00 00 00 00 a1 74 61 56 c1 55 89 e5 e8 a3 fc ff ff 5d c3 90 55 89 e5 57 56 89 c6 53 b8 40 ac 62 c1 83 ec 14 e8 bb b7 34 00 <8b> 46 4c 8d 50 01 85 c0 89 56 4c 75 03 83 0e 40 80 05 40 ac 62 [ 214.333957] EIP: [] drain_workqueue+0x15/0x170 SS:ESP 0068:cd767e5c [ 214.333957] CR2: 004c [ 214.341110] ---[ end trace c7e90ec026d875a6 ]---Index: wireless-testing/drivers/net/wireless/b43legacy/main.c The problem is fixed by making certain that the ucode pointer is not NULL before deregistering the driver in mac80211. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman --- drivers/net/wireless/b43legacy/main.c |2 ++ 1 file changed, 2 insertions(+) --- a/drivers/net/wireless/b43legacy/main.c +++ b/drivers/net/wireless/b43legacy/main.c @@ -3894,6 +3894,8 @@ static void b43legacy_remove(struct ssb_ cancel_work_sync(>firmware_load); B43legacy_WARN_ON(!wl); + if (!wldev->fw.ucode) + return; /* NULL if fw never loaded */ if (wl->current_dev == wldev) ieee80211_unregister_hw(wl->hw); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 26/56] firmware: Add missing attributes to EFI variable attribute print out from sysfs
3.6-stable review patch. If anyone has any objections, please let me know. -- From: Khalid Aziz commit 7083909023bbe29b3176e92d2d089def1aa7aa1e upstream. Some of the EFI variable attributes are missing from print out from /sys/firmware/efi/vars/*/attributes. This patch adds those in. It also updates code to use pre-defined constants for masking current value of attributes. Signed-off-by: Khalid Aziz Reviewed-by: Kees Cook Acked-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman --- drivers/firmware/efivars.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) --- a/drivers/firmware/efivars.c +++ b/drivers/firmware/efivars.c @@ -435,12 +435,23 @@ efivar_attr_read(struct efivar_entry *en if (status != EFI_SUCCESS) return -EIO; - if (var->Attributes & 0x1) + if (var->Attributes & EFI_VARIABLE_NON_VOLATILE) str += sprintf(str, "EFI_VARIABLE_NON_VOLATILE\n"); - if (var->Attributes & 0x2) + if (var->Attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS) str += sprintf(str, "EFI_VARIABLE_BOOTSERVICE_ACCESS\n"); - if (var->Attributes & 0x4) + if (var->Attributes & EFI_VARIABLE_RUNTIME_ACCESS) str += sprintf(str, "EFI_VARIABLE_RUNTIME_ACCESS\n"); + if (var->Attributes & EFI_VARIABLE_HARDWARE_ERROR_RECORD) + str += sprintf(str, "EFI_VARIABLE_HARDWARE_ERROR_RECORD\n"); + if (var->Attributes & EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS) + str += sprintf(str, + "EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS\n"); + if (var->Attributes & + EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS) + str += sprintf(str, + "EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS\n"); + if (var->Attributes & EFI_VARIABLE_APPEND_WRITE) + str += sprintf(str, "EFI_VARIABLE_APPEND_WRITE\n"); return str - buf; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm: thp: Set the accessed flag for old pages on access fault.
On Tue, Oct 02, 2012 at 05:59:11PM +0100, Will Deacon wrote: > On x86 memory accesses to pages without the ACCESSED flag set result in the > ACCESSED flag being set automatically. With the ARM architecture a page access > fault is raised instead (and it will continue to be raised until the ACCESSED > flag is set for the appropriate PTE/PMD). > > For normal memory pages, handle_pte_fault will call pte_mkyoung (effectively > setting the ACCESSED flag). For transparent huge pages, pmd_mkyoung will only > be called for a write fault. > > This patch ensures that faults on transparent hugepages which do not result > in a CoW update the access flags for the faulting pmd. > > Cc: Andrea Arcangeli > Cc: Chris Metcalf > Signed-off-by: Steve Capper > Signed-off-by: Will Deacon Acked-by: Kirill A. Shutemov -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 32/56] Increase XHCI suspend timeout to 16ms
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Michael Spang
commit a6e097dfdfd189b6929af6efa1d289af61858386 upstream.
The Intel XHCI specification says that after clearing the run/stop bit
the controller may take up to 16ms to halt. We've seen a device take
14ms, which with the current timeout of 10ms causes the kernel to
abort the suspend. Increasing the timeout to the recommended value
fixes the problem.
This patch should be backported to kernels as old as 2.6.37, that
contain the commit 5535b1d5f8885695c6ded783c692e3c0d0eda8ca "USB: xHCI:
PCI power management implementation".
Signed-off-by: Michael Spang
Signed-off-by: Sarah Sharp
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/xhci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -890,7 +890,7 @@ int xhci_suspend(struct xhci_hcd *xhci)
command &= ~CMD_RUN;
xhci_writel(xhci, command, >op_regs->command);
if (handshake(xhci, >op_regs->status,
- STS_HALT, STS_HALT, 100*100)) {
+ STS_HALT, STS_HALT, XHCI_MAX_HALT_USEC)) {
xhci_warn(xhci, "WARN: xHC CMD_RUN timeout\n");
spin_unlock_irq(>lock);
return -ETIMEDOUT;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 33/56] HID: keep dev_rdesc unmodified and use it for comparisons
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Kevin Daughtridge
commit 86e6b77eb7cf9ca2e9c7092b4dfd588f0a3307b6 upstream.
The dev_rdesc member of the hid_device structure is meant to store the original
report descriptor received from the device, but it is currently passed to any
report_fixup method before it is copied to the rdesc member. This patch uses a
temporary buffer to shield dev_rdesc from the side effects of many HID drivers'
report_fixup implementations.
usbhid's hid_post_reset checks the report descriptor currently returned by the
device against a descriptor that may have been modified by a driver's
report_fixup method. That leaves some devices nonfunctional after a resume, with
a "reset_resume error 1" reported. This patch checks the new descriptor against
the unmodified dev_rdesc instead and uses the original, instead of modified,
report size.
BugLink: http://bugs.launchpad.net/bugs/1049623
Signed-off-by: Kevin Daughtridge
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman
---
drivers/hid/hid-core.c| 16 +---
drivers/hid/usbhid/hid-core.c |6 +++---
2 files changed, 16 insertions(+), 6 deletions(-)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -757,6 +757,7 @@ int hid_open_report(struct hid_device *d
struct hid_item item;
unsigned int size;
__u8 *start;
+ __u8 *buf;
__u8 *end;
int ret;
static int (*dispatch_type[])(struct hid_parser *parser,
@@ -775,12 +776,21 @@ int hid_open_report(struct hid_device *d
return -ENODEV;
size = device->dev_rsize;
+ buf = kmemdup(start, size, GFP_KERNEL);
+ if (buf == NULL)
+ return -ENOMEM;
+
if (device->driver->report_fixup)
- start = device->driver->report_fixup(device, start, );
+ start = device->driver->report_fixup(device, buf, );
+ else
+ start = buf;
- device->rdesc = kmemdup(start, size, GFP_KERNEL);
- if (device->rdesc == NULL)
+ start = kmemdup(start, size, GFP_KERNEL);
+ kfree(buf);
+ if (start == NULL)
return -ENOMEM;
+
+ device->rdesc = start;
device->rsize = size;
parser = vzalloc(sizeof(struct hid_parser));
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -1415,20 +1415,20 @@ static int hid_post_reset(struct usb_int
* configuration descriptors passed, we already know that
* the size of the HID report descriptor has not changed.
*/
- rdesc = kmalloc(hid->rsize, GFP_KERNEL);
+ rdesc = kmalloc(hid->dev_rsize, GFP_KERNEL);
if (!rdesc) {
dbg_hid("couldn't allocate rdesc memory (post_reset)\n");
return 1;
}
status = hid_get_class_descriptor(dev,
interface->desc.bInterfaceNumber,
- HID_DT_REPORT, rdesc, hid->rsize);
+ HID_DT_REPORT, rdesc, hid->dev_rsize);
if (status < 0) {
dbg_hid("reading report descriptor failed (post_reset)\n");
kfree(rdesc);
return 1;
}
- status = memcmp(rdesc, hid->rdesc, hid->rsize);
+ status = memcmp(rdesc, hid->dev_rdesc, hid->dev_rsize);
kfree(rdesc);
if (status != 0) {
dbg_hid("report descriptor changed\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 35/56] xen/pciback: Restore the PCI config space after an FLR.
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Konrad Rzeszutek Wilk
commit c341ca45ce56143804ef5a8f4db753e554e640b4 upstream.
When we do an FLR, or D0->D3_hot we may lose the BARs as the
device has turned itself off (and on). This means the device cannot
function unless the pci_restore_state is called - which it is
when the PCI device is unbound from the Xen PCI backend driver.
For PV guests it ends up calling pci_enable_device / pci_enable_msi[x]
which does the proper steps
That however is not happening if a HVM guest is run as QEMU
deals with PCI configuration space. QEMU also requires that the
device be "parked" under the ownership of a pci-stub driver to
guarantee that the PCI device is not being used. Hence we
follow the same incantation as pci_reset_function does - by
doing an FLR, then restoring the PCI configuration space.
The result of this patch is that when you run lspci, you get
now this:
- Region 0: [virtual] Memory at fe8c (32-bit, non-prefetchable)
[size=128K]
- Region 1: [virtual] Memory at fe80 (32-bit, non-prefetchable)
[size=512K]
+ Region 0: Memory at fe8c (32-bit, non-prefetchable) [size=128K]
+ Region 1: Memory at fe80 (32-bit, non-prefetchable) [size=512K]
Region 2: I/O ports at c000 [size=32]
- Region 3: [virtual] Memory at fe8e (32-bit, non-prefetchable)
[size=16K]
+ Region 3: Memory at fe8e (32-bit, non-prefetchable) [size=16K]
The [virtual] means that lspci read those entries from SysFS but when
it read them from the device it got a different value (0xfff).
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Greg Kroah-Hartman
---
drivers/xen/xen-pciback/pci_stub.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -362,6 +362,7 @@ static int __devinit pcistub_init_device
else {
dev_dbg(>dev, "reseting (FLR, D3, etc) the device\n");
__pci_reset_function_locked(dev);
+ pci_restore_state(dev);
}
/* Now disable the device (this also ensures some private device
* data is setup before we export)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 29/56] xHCI: add aborting command ring function
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Elric Fu
commit b92cc66c047ff7cf587b318fe377061a353c120f upstream.
Software have to abort command ring and cancel command
when a command is failed or hang. Otherwise, the command
ring will hang up and can't handle the others. An example
of a command that may hang is the Address Device Command,
because waiting for a SET_ADDRESS request to be acknowledged
by a USB device is outside of the xHC's ability to control.
To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci.
Sarah: Fixed missing newline on "Have the command ring been stopped?"
debugging statement.
This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.
Signed-off-by: Elric Fu
Signed-off-by: Sarah Sharp
Tested-by: Miroslav Sabljic
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/xhci-mem.c |7 ++
drivers/usb/host/xhci-ring.c | 108 +++
drivers/usb/host/xhci.c |2
drivers/usb/host/xhci.h | 12
4 files changed, 128 insertions(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1772,6 +1772,7 @@ void xhci_mem_cleanup(struct xhci_hcd *x
{
struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
struct dev_info *dev_info, *next;
+ struct xhci_cd *cur_cd, *next_cd;
unsigned long flags;
int size;
int i, j, num_ports;
@@ -1795,6 +1796,11 @@ void xhci_mem_cleanup(struct xhci_hcd *x
xhci_ring_free(xhci, xhci->cmd_ring);
xhci->cmd_ring = NULL;
xhci_dbg(xhci, "Freed command ring\n");
+ list_for_each_entry_safe(cur_cd, next_cd,
+ >cancel_cmd_list, cancel_cmd_list) {
+ list_del(_cd->cancel_cmd_list);
+ kfree(cur_cd);
+ }
for (i = 1; i < MAX_HC_SLOTS; ++i)
xhci_free_virt_device(xhci, i);
@@ -2340,6 +2346,7 @@ int xhci_mem_init(struct xhci_hcd *xhci,
xhci->cmd_ring = xhci_ring_alloc(xhci, 1, 1, TYPE_COMMAND, flags);
if (!xhci->cmd_ring)
goto fail;
+ INIT_LIST_HEAD(>cancel_cmd_list);
xhci_dbg(xhci, "Allocated command ring at %p\n", xhci->cmd_ring);
xhci_dbg(xhci, "First segment DMA is 0x%llx\n",
(unsigned long long)xhci->cmd_ring->first_seg->dma);
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -289,6 +289,114 @@ void xhci_ring_cmd_db(struct xhci_hcd *x
xhci_readl(xhci, >dba->doorbell[0]);
}
+static int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
+{
+ u64 temp_64;
+ int ret;
+
+ xhci_dbg(xhci, "Abort command ring\n");
+
+ if (!(xhci->cmd_ring_state & CMD_RING_STATE_RUNNING)) {
+ xhci_dbg(xhci, "The command ring isn't running, "
+ "Have the command ring been stopped?\n");
+ return 0;
+ }
+
+ temp_64 = xhci_read_64(xhci, >op_regs->cmd_ring);
+ if (!(temp_64 & CMD_RING_RUNNING)) {
+ xhci_dbg(xhci, "Command ring had been stopped\n");
+ return 0;
+ }
+ xhci->cmd_ring_state = CMD_RING_STATE_ABORTED;
+ xhci_write_64(xhci, temp_64 | CMD_RING_ABORT,
+ >op_regs->cmd_ring);
+
+ /* Section 4.6.1.2 of xHCI 1.0 spec says software should
+* time the completion od all xHCI commands, including
+* the Command Abort operation. If software doesn't see
+* CRR negated in a timely manner (e.g. longer than 5
+* seconds), then it should assume that the there are
+* larger problems with the xHC and assert HCRST.
+*/
+ ret = handshake(xhci, >op_regs->cmd_ring,
+ CMD_RING_RUNNING, 0, 5 * 1000 * 1000);
+ if (ret < 0) {
+ xhci_err(xhci, "Stopped the command ring failed, "
+ "maybe the host is dead\n");
+ xhci->xhc_state |= XHCI_STATE_DYING;
+ xhci_quiesce(xhci);
+ xhci_halt(xhci);
+ return -ESHUTDOWN;
+ }
+
+ return 0;
+}
+
+static int xhci_queue_cd(struct xhci_hcd *xhci,
+ struct xhci_command *command,
+ union xhci_trb *cmd_trb)
+{
+ struct xhci_cd *cd;
+ cd = kzalloc(sizeof(struct xhci_cd), GFP_ATOMIC);
+ if (!cd)
+ return -ENOMEM;
+ INIT_LIST_HEAD(>cancel_cmd_list);
+
+ cd->command = command;
+ cd->cmd_trb = cmd_trb;
+ list_add_tail(>cancel_cmd_list, >cancel_cmd_list);
+
+ return 0;
+}
+
+/*
+ *
[ 41/56] UBI: fix autoresize handling in R/O mode
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Artem Bityutskiy
commit abb3e01103eb4e2ea5c15e6fedbc74e08bd4cc2b upstream.
Currently UBI fails in autoresize when it is in R/O mode (e.g., because the
underlying MTD device is R/O). This patch fixes the issue - we just skip
autoresize and print a warning.
Reported-by: Pali Rohár
Signed-off-by: Artem Bityutskiy
Signed-off-by: Greg Kroah-Hartman
---
drivers/mtd/ubi/build.c |5 +
1 file changed, 5 insertions(+)
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -759,6 +759,11 @@ static int autoresize(struct ubi_device
struct ubi_volume *vol = ubi->volumes[vol_id];
int err, old_reserved_pebs = vol->reserved_pebs;
+ if (ubi->ro_mode) {
+ ubi_warn("skip auto-resize because of R/O mode");
+ return 0;
+ }
+
/*
* Clear the auto-resize flag in the volume in-memory copy of the
* volume table, and 'ubi_resize_volume()' will propagate this change
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 34/56] ath9k: Disable ASPM only for AR9285
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Sujith Manoharan
commit 046b6802c8d3c8a57448485513bf7291633e0fa3 upstream.
Currently, ASPM is disabled for all WLAN+BT combo chipsets
when BTCOEX is enabled. This is incorrect since the workaround
is required only for WB195, which is a AR9285+AR3011 combo
solution. Fix this by checking for the HW version when enabling
the workaround.
Signed-off-by: Sujith Manoharan
Tested-by: Paul Stewart
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/ath/ath9k/pci.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -127,8 +127,9 @@ static void ath_pci_aspm_init(struct ath
if (!parent)
return;
- if (ath9k_hw_get_btcoex_scheme(ah) != ATH_BTCOEX_CFG_NONE) {
- /* Bluetooth coexistance requires disabling ASPM. */
+ if ((ath9k_hw_get_btcoex_scheme(ah) != ATH_BTCOEX_CFG_NONE) &&
+ (AR_SREV_9285(ah))) {
+ /* Bluetooth coexistance requires disabling ASPM for AR9285. */
pci_read_config_byte(pdev, pos + PCI_EXP_LNKCTL, );
aspm &= ~(PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1);
pci_write_config_byte(pdev, pos + PCI_EXP_LNKCTL, aspm);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 28/56] xHCI: add cmd_ring_state
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Elric Fu
commit c181bc5b5d5c79b71203cd10cef97f802fb6f9c1 upstream.
Adding cmd_ring_state for command ring. It helps to verify
the current command ring state for controlling the command
ring operations.
This patch should be backported to kernels as old as 3.0. The commit
7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an assertion to
check for virt_dev=0 bug." papers over the NULL pointer dereference that
I now believe is related to a timed out Set Address command. This (and
the four patches that follow it) contain the real fix that also allows
VIA USB 3.0 hubs to consistently re-enumerate during the plug/unplug
stress tests.
Signed-off-by: Elric Fu
Signed-off-by: Sarah Sharp
Tested-by: Miroslav Sabljic
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/xhci-ring.c |3 +++
drivers/usb/host/xhci.c |6 --
drivers/usb/host/xhci.h |4
3 files changed, 11 insertions(+), 2 deletions(-)
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -280,6 +280,9 @@ static inline int room_on_ring(struct xh
/* Ring the host controller doorbell after placing a command on the ring */
void xhci_ring_cmd_db(struct xhci_hcd *xhci)
{
+ if (!(xhci->cmd_ring_state & CMD_RING_STATE_RUNNING))
+ return;
+
xhci_dbg(xhci, "// Ding dong!\n");
xhci_writel(xhci, DB_VALUE_HOST, >dba->doorbell[0]);
/* Flush PCI posted writes */
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -105,9 +105,10 @@ int xhci_halt(struct xhci_hcd *xhci)
ret = handshake(xhci, >op_regs->status,
STS_HALT, STS_HALT, XHCI_MAX_HALT_USEC);
- if (!ret)
+ if (!ret) {
xhci->xhc_state |= XHCI_STATE_HALTED;
- else
+ xhci->cmd_ring_state = CMD_RING_STATE_STOPPED;
+ } else
xhci_warn(xhci, "Host not halted after %u microseconds.\n",
XHCI_MAX_HALT_USEC);
return ret;
@@ -583,6 +584,7 @@ static int xhci_run_finished(struct xhci
return -ENODEV;
}
xhci->shared_hcd->state = HC_STATE_RUNNING;
+ xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
if (xhci->quirks & XHCI_NEC_HOST)
xhci_ring_cmd_db(xhci);
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1421,6 +1421,10 @@ struct xhci_hcd {
/* data structures */
struct xhci_device_context_array *dcbaa;
struct xhci_ring*cmd_ring;
+ unsigned intcmd_ring_state;
+#define CMD_RING_STATE_RUNNING (1 << 0)
+#define CMD_RING_STATE_ABORTED (1 << 1)
+#define CMD_RING_STATE_STOPPED (1 << 2)
unsigned intcmd_ring_reserved_trbs;
struct xhci_ring*event_ring;
struct xhci_ersterst;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 30/56] xHCI: cancel command after command timeout
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Elric Fu
commit 6e4468b9a0793dfb53eb80d9fe52c739b13b27fd upstream.
The patch is used to cancel command when the command isn't
acknowledged and a timeout occurs.
This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.
Signed-off-by: Elric Fu
Signed-off-by: Sarah Sharp
Tested-by: Miroslav Sabljic
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/xhci.c | 26 +++---
drivers/usb/host/xhci.h |3 +++
2 files changed, 22 insertions(+), 7 deletions(-)
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2525,6 +2525,7 @@ static int xhci_configure_endpoint(struc
struct completion *cmd_completion;
u32 *cmd_status;
struct xhci_virt_device *virt_dev;
+ union xhci_trb *cmd_trb;
spin_lock_irqsave(>lock, flags);
virt_dev = xhci->devs[udev->slot_id];
@@ -2570,6 +2571,7 @@ static int xhci_configure_endpoint(struc
}
init_completion(cmd_completion);
+ cmd_trb = xhci->cmd_ring->dequeue;
if (!ctx_change)
ret = xhci_queue_configure_endpoint(xhci, in_ctx->dma,
udev->slot_id, must_succeed);
@@ -2591,14 +2593,17 @@ static int xhci_configure_endpoint(struc
/* Wait for the configure endpoint command to complete */
timeleft = wait_for_completion_interruptible_timeout(
cmd_completion,
- USB_CTRL_SET_TIMEOUT);
+ XHCI_CMD_DEFAULT_TIMEOUT);
if (timeleft <= 0) {
xhci_warn(xhci, "%s while waiting for %s command\n",
timeleft == 0 ? "Timeout" : "Signal",
ctx_change == 0 ?
"configure endpoint" :
"evaluate context");
- /* FIXME cancel the configure endpoint command */
+ /* cancel the configure endpoint command */
+ ret = xhci_cancel_cmd(xhci, command, cmd_trb);
+ if (ret < 0)
+ return ret;
return -ETIME;
}
@@ -3547,8 +3552,10 @@ int xhci_alloc_dev(struct usb_hcd *hcd,
unsigned long flags;
int timeleft;
int ret;
+ union xhci_trb *cmd_trb;
spin_lock_irqsave(>lock, flags);
+ cmd_trb = xhci->cmd_ring->dequeue;
ret = xhci_queue_slot_control(xhci, TRB_ENABLE_SLOT, 0);
if (ret) {
spin_unlock_irqrestore(>lock, flags);
@@ -3560,12 +3567,12 @@ int xhci_alloc_dev(struct usb_hcd *hcd,
/* XXX: how much time for xHC slot assignment? */
timeleft = wait_for_completion_interruptible_timeout(>addr_dev,
- USB_CTRL_SET_TIMEOUT);
+ XHCI_CMD_DEFAULT_TIMEOUT);
if (timeleft <= 0) {
xhci_warn(xhci, "%s while waiting for a slot\n",
timeleft == 0 ? "Timeout" : "Signal");
- /* FIXME cancel the enable slot request */
- return 0;
+ /* cancel the enable slot request */
+ return xhci_cancel_cmd(xhci, NULL, cmd_trb);
}
if (!xhci->slot_id) {
@@ -3626,6 +3633,7 @@ int xhci_address_device(struct usb_hcd *
struct xhci_slot_ctx *slot_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
u64 temp_64;
+ union xhci_trb *cmd_trb;
if (!udev->slot_id) {
xhci_dbg(xhci, "Bad Slot ID %d\n", udev->slot_id);
@@ -3664,6 +3672,7 @@ int xhci_address_device(struct usb_hcd *
xhci_dbg_ctx(xhci, virt_dev->in_ctx, 2);
spin_lock_irqsave(>lock, flags);
+ cmd_trb = xhci->cmd_ring->dequeue;
ret = xhci_queue_address_device(xhci, virt_dev->in_ctx->dma,
udev->slot_id);
if (ret) {
@@ -3676,7 +3685,7 @@ int xhci_address_device(struct usb_hcd *
/* ctrl tx can take up to 5 sec; XXX: need more time for xHC? */
timeleft = wait_for_completion_interruptible_timeout(>addr_dev,
- USB_CTRL_SET_TIMEOUT);
+ XHCI_CMD_DEFAULT_TIMEOUT);
/* FIXME: From section 4.3.4: "Software shall be responsible for timing
* the SetAddress() "recovery interval" required by USB and aborting the
* command on a timeout.
@@ -3684,7 +3693,10 @@ int xhci_address_device(struct usb_hcd *
if (timeleft <= 0) {
xhci_warn(xhci, "%s while waiting for address device command\n",
timeleft == 0 ? "Timeout" : "Signal");
- /*
[ 23/56] tools/hv: Fix exit() error code
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
commit 6bb22fea25624ab593eee376fa5fb82d1b13f45a upstream.
Linux native exit codes are 8-bit unsigned values. exit(-1) results
in an exit code of 255, which is usually reserved for shells reporting
'command not found'. Use the portable value EXIT_FAILURE. (Not that
this matters much for a daemon.)
Signed-off-by: Ben Hutchings
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman
---
tools/hv/hv_kvp_daemon.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -106,7 +106,7 @@ static void kvp_acquire_lock(int pool)
if (fcntl(kvp_file_info[pool].fd, F_SETLKW, ) == -1) {
syslog(LOG_ERR, "Failed to acquire the lock pool: %d", pool);
- exit(-1);
+ exit(EXIT_FAILURE);
}
}
@@ -118,7 +118,7 @@ static void kvp_release_lock(int pool)
if (fcntl(kvp_file_info[pool].fd, F_SETLK, ) == -1) {
perror("fcntl");
syslog(LOG_ERR, "Failed to release the lock pool: %d", pool);
- exit(-1);
+ exit(EXIT_FAILURE);
}
}
@@ -137,7 +137,7 @@ static void kvp_update_file(int pool)
if (!filep) {
kvp_release_lock(pool);
syslog(LOG_ERR, "Failed to open file, pool: %d", pool);
- exit(-1);
+ exit(EXIT_FAILURE);
}
bytes_written = fwrite(kvp_file_info[pool].records,
@@ -163,7 +163,7 @@ static void kvp_update_mem_state(int poo
if (!filep) {
kvp_release_lock(pool);
syslog(LOG_ERR, "Failed to open file, pool: %d", pool);
- exit(-1);
+ exit(EXIT_FAILURE);
}
while (!feof(filep)) {
readp = [records_read];
@@ -180,7 +180,7 @@ static void kvp_update_mem_state(int poo
if (record == NULL) {
syslog(LOG_ERR, "malloc failed");
- exit(-1);
+ exit(EXIT_FAILURE);
}
continue;
}
@@ -209,7 +209,7 @@ static int kvp_file_init(void)
if (access("/var/opt/hyperv", F_OK)) {
if (mkdir("/var/opt/hyperv", S_IRUSR | S_IWUSR | S_IROTH)) {
syslog(LOG_ERR, " Failed to create /var/opt/hyperv");
- exit(-1);
+ exit(EXIT_FAILURE);
}
}
@@ -658,13 +658,13 @@ int main(void)
if (kvp_file_init()) {
syslog(LOG_ERR, "Failed to initialize the pools");
- exit(-1);
+ exit(EXIT_FAILURE);
}
fd = socket(AF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR);
if (fd < 0) {
syslog(LOG_ERR, "netlink socket creation failed; error:%d", fd);
- exit(-1);
+ exit(EXIT_FAILURE);
}
addr.nl_family = AF_NETLINK;
addr.nl_pad = 0;
@@ -676,7 +676,7 @@ int main(void)
if (error < 0) {
syslog(LOG_ERR, "bind failed; error:%d", error);
close(fd);
- exit(-1);
+ exit(EXIT_FAILURE);
}
sock_opt = addr.nl_groups;
setsockopt(fd, 270, 1, _opt, sizeof(sock_opt));
@@ -696,7 +696,7 @@ int main(void)
if (len < 0) {
syslog(LOG_ERR, "netlink_send failed; error:%d", len);
close(fd);
- exit(-1);
+ exit(EXIT_FAILURE);
}
pfd.fd = fd;
@@ -864,7 +864,7 @@ kvp_done:
len = netlink_send(fd, incoming_cn_msg);
if (len < 0) {
syslog(LOG_ERR, "net_link send failed; error:%d", len);
- exit(-1);
+ exit(EXIT_FAILURE);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 24/56] tools/hv: Check for read/write errors
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
commit 436473bc2173499ae274d0f50111d1e355006caf upstream.
hv_kvp_daemon currently does not check whether fread() or fwrite()
succeed. Add the necessary checks. Also, remove the incorrect use of
feof() before fread().
Signed-off-by: Ben Hutchings
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman
---
tools/hv/hv_kvp_daemon.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -144,7 +144,12 @@ static void kvp_update_file(int pool)
sizeof(struct kvp_record),
kvp_file_info[pool].num_records, filep);
- fclose(filep);
+ if (ferror(filep) || fclose(filep)) {
+ kvp_release_lock(pool);
+ syslog(LOG_ERR, "Failed to write file, pool: %d", pool);
+ exit(EXIT_FAILURE);
+ }
+
kvp_release_lock(pool);
}
@@ -165,12 +170,17 @@ static void kvp_update_mem_state(int poo
syslog(LOG_ERR, "Failed to open file, pool: %d", pool);
exit(EXIT_FAILURE);
}
- while (!feof(filep)) {
+ for (;;) {
readp = [records_read];
records_read += fread(readp, sizeof(struct kvp_record),
ENTRIES_PER_BLOCK * num_blocks,
filep);
+ if (ferror(filep)) {
+ syslog(LOG_ERR, "Failed to read file, pool: %d", pool);
+ exit(EXIT_FAILURE);
+ }
+
if (!feof(filep)) {
/*
* We have more data to read.
@@ -233,12 +243,18 @@ static int kvp_file_init(void)
fclose(filep);
return 1;
}
- while (!feof(filep)) {
+ for (;;) {
readp = [records_read];
records_read += fread(readp, sizeof(struct kvp_record),
ENTRIES_PER_BLOCK,
filep);
+ if (ferror(filep)) {
+ syslog(LOG_ERR, "Failed to read file, pool: %d",
+ i);
+ exit(EXIT_FAILURE);
+ }
+
if (!feof(filep)) {
/*
* We have more data to read.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 16/56] staging: comedi: fix memory leak for saved channel list
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Ian Abbott
commit c8cad4c89ee3b15935c532210ae6ebb5c0a2734d upstream.
When `do_cmd_ioctl()` allocates memory for the kernel copy of a channel
list, it frees any previously allocated channel list in
`async->cmd.chanlist` and replaces it with the new one. However, if the
device is ever removed (or "detached") the cleanup code in
`cleanup_device()` in "drivers.c" does not free this memory so it is
lost.
A sensible place to free the kernel copy of the channel list is in
`do_become_nonbusy()` as at that point the comedi asynchronous command
associated with the channel list is no longer valid. Free the channel
list in `do_become_nonbusy()` instead of `do_cmd_ioctl()` and clear the
pointer to prevent it being freed more than once.
Note that `cleanup_device()` could be called at an inappropriate time
while the comedi device is open, but that's a separate bug not related
to this this patch.
Signed-off-by: Ian Abbott
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/comedi/comedi_fops.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -1196,7 +1196,6 @@ static int do_cmd_ioctl(struct comedi_de
goto cleanup;
}
- kfree(async->cmd.chanlist);
async->cmd = user_cmd;
async->cmd.data = NULL;
/* load channel/gain list */
@@ -2033,6 +2032,8 @@ void do_become_nonbusy(struct comedi_dev
if (async) {
comedi_reset_async_buf(async);
async->inttrig = NULL;
+ kfree(async->cmd.chanlist);
+ async->cmd.chanlist = NULL;
} else {
printk(KERN_ERR
"BUG: (?) do_become_nonbusy called with async=0\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 07/56] USB: qcaux: add Pantech vendor class match
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Bjørn Mork
commit c638eb2872b3af079501e7ee44cbb8a5cce9b4b5 upstream.
The three Pantech devices UML190 (106c:3716), UML290 (106c:3718) and
P4200 (106c:3721) all use the same subclasses to identify vendor
specific functions. Replace the existing device specific entries
with generic vendor matching, adding support for the P4200.
Signed-off-by: Bjørn Mork
Cc: Thomas Schäfer
Acked-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/qcaux.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
--- a/drivers/usb/serial/qcaux.c
+++ b/drivers/usb/serial/qcaux.c
@@ -36,8 +36,6 @@
#define UTSTARCOM_PRODUCT_UM175_V1 0x3712
#define UTSTARCOM_PRODUCT_UM175_V2 0x3714
#define UTSTARCOM_PRODUCT_UM175_ALLTEL 0x3715
-#define PANTECH_PRODUCT_UML190_VZW 0x3716
-#define PANTECH_PRODUCT_UML290_VZW 0x3718
/* CMOTECH devices */
#define CMOTECH_VENDOR_ID 0x16d8
@@ -68,11 +66,9 @@ static struct usb_device_id id_table[] =
{ USB_DEVICE_AND_INTERFACE_INFO(LG_VENDOR_ID, LG_PRODUCT_VX4400_6000,
0xff, 0xff, 0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(SANYO_VENDOR_ID,
SANYO_PRODUCT_KATANA_LX, 0xff, 0xff, 0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID,
SAMSUNG_PRODUCT_U520, 0xff, 0x00, 0x00) },
- { USB_DEVICE_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID,
PANTECH_PRODUCT_UML190_VZW, 0xff, 0xff, 0xff) },
- { USB_DEVICE_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID,
PANTECH_PRODUCT_UML190_VZW, 0xff, 0xfe, 0xff) },
- { USB_DEVICE_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID,
PANTECH_PRODUCT_UML290_VZW, 0xff, 0xfd, 0xff) }, /* NMEA */
- { USB_DEVICE_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID,
PANTECH_PRODUCT_UML290_VZW, 0xff, 0xfe, 0xff) }, /* WMC */
- { USB_DEVICE_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID,
PANTECH_PRODUCT_UML290_VZW, 0xff, 0xff, 0xff) }, /* DIAG */
+ { USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xfd, 0xff)
}, /* NMEA */
+ { USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xfe, 0xff)
}, /* WMC */
+ { USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xff, 0xff)
}, /* DIAG */
{ },
};
MODULE_DEVICE_TABLE(usb, id_table);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 11/56] tty: keyboard.c: Remove locking from vt_get_leds.
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Christopher Brannon
commit 157a4b311c45c9aba75a990464d9680867dc8805 upstream.
There are three call sites for this function, and all three
are called within a keyboard handler.
kbd_event_lock is already held within keyboard handlers,
so attempting to lock it in vt_get_leds causes deadlock.
Signed-off-by: Christopher Brannon
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman
---
drivers/tty/vt/keyboard.c |3 ---
1 file changed, 3 deletions(-)
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -1049,13 +1049,10 @@ static int kbd_update_leds_helper(struct
*/
int vt_get_leds(int console, int flag)
{
- unsigned long flags;
struct kbd_struct * kbd = kbd_table + console;
int ret;
- spin_lock_irqsave(_event_lock, flags);
ret = vc_kbd_led(kbd, flag);
- spin_unlock_irqrestore(_event_lock, flags);
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 40/56] n_gsm: memory leak in uplink error path
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Russ Gorby
commit 88ed2a60610974443335c924d7cb8e5dcf9dbdc1 upstream.
Uplink (TX) network data will go through gsm_dlci_data_output_framed
there is a bug where if memory allocation fails, the skb which
has already been pulled off the list will be lost.
In addition TX skbs were being processed in LIFO order
Fixed the memory leak, and changed to FIFO order processing
Signed-off-by: Russ Gorby
Tested-by: Kappel, LaurentX
Signed-off-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman
---
drivers/tty/n_gsm.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -875,7 +875,7 @@ static int gsm_dlci_data_output_framed(s
/* dlci->skb is locked by tx_lock */
if (dlci->skb == NULL) {
- dlci->skb = skb_dequeue(>skb_list);
+ dlci->skb = skb_dequeue_tail(>skb_list);
if (dlci->skb == NULL)
return 0;
first = 1;
@@ -899,8 +899,11 @@ static int gsm_dlci_data_output_framed(s
/* FIXME: need a timer or something to kick this so it can't
get stuck with no work outstanding and no buffer free */
- if (msg == NULL)
+ if (msg == NULL) {
+ skb_queue_tail(>skb_list, dlci->skb);
+ dlci->skb = NULL;
return -ENOMEM;
+ }
dp = msg->data;
if (dlci->adaption == 4) { /* Interruptible framed (Packetised Data) */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Disintegrate UAPI for x86
On 10/04/2012 12:51 PM, David Howells wrote: Can you merge the following branch into the x86 tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Note that there are some fixup patches which are at the base of the branch aimed at you, plus all arches get the asm-generic branch merged in too. The following changes since commit 612a9aab56a93533e76e3ad91642db7033e03b69: Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux (2012-10-03 23:29:23 -0700) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git disintegrate-x86 for you to fetch changes up to c64630429a9d37a248c6b06a738fad838f2f5e37: UAPI: (Scripted) Disintegrate arch/x86/include/asm (2012-10-04 18:21:45 +0100) That branch does have generic patches which are not yet in upstream. I presume that is intentional. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RFC] media: v4l2-ctrl: Add digital gain controls
Hi Prabhakar,
Thanks for the patch.
On Monday 01 October 2012 19:33:39 Prabhakar wrote:
> From: Lad, Prabhakar
>
> add support for per color component digital gain controls
> and also their corresponding offset.
>
> Signed-off-by: Lad, Prabhakar
> Signed-off-by: Manjunath Hadli
> Cc: Sakari Ailus
> Cc: Laurent Pinchart
> Cc: Guennadi Liakhovetski
> Cc: Sylwester Nawrocki
> Cc: Hans Verkuil
> Cc: Hans de Goede hdego...@redhat.com
> Cc: Chris MacGregor ch...@cybermato.com
> Cc: Rob Landley
> Cc: Mauro Carvalho Chehab
> ---
> Documentation/DocBook/media/v4l/controls.xml | 54 +++
> drivers/media/v4l2-core/v4l2-ctrls.c | 11 +
> include/linux/v4l2-controls.h| 11 +
> 3 files changed, 76 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/DocBook/media/v4l/controls.xml
> b/Documentation/DocBook/media/v4l/controls.xml index a84a08c..9bf54f3
> 100644
> --- a/Documentation/DocBook/media/v4l/controls.xml
> +++ b/Documentation/DocBook/media/v4l/controls.xml
> @@ -4277,6 +4277,60 @@ interface and may change in the future.
> specific test patterns can be used to test if a device is working
> properly.
>
> +
> + V4L2_CID_GAIN_RED
> + integer
> +
> +
> + spanname="id">V4L2_CID_GAIN_GREEN_RED +
> integer
> +
> +
> + spanname="id">V4L2_CID_GAIN_GREEN_BLUE +
> integer
> +
> +
> + V4L2_CID_GAIN_BLUE
> + integer
> +
> +
> + spanname="id">V4L2_CID_GAIN_GREEN
> + integer
> +
> +
> + Some capture/sensor devices have
> + the capability to set per color component digital gain
values.
> +
> +
> + V4L2_CID_GAIN_OFFSET
> + integer
> +
> +
> + V4L2_CID_BLUE_OFFSET
> + integer
> +
> +
> + spanname="id">V4L2_CID_RED_OFFSET
> + integer
> +
> +
> + spanname="id">V4L2_CID_GREEN_OFFSET +
> integer
> +
> +
> + spanname="id">V4L2_CID_GREEN_RED_OFFSET +
>
> integer
> +
> +
> + spanname="id">V4L2_CID_GREEN_BLUE_OFFSET +
>
> integer
> +
> +
> + Some capture/sensor devices have the
> + capability to set per color component digital gain offset values.
> + V4L2_CID_GAIN_OFFSET is the global gain offset and the rest are per
> + color component gain offsets.
> +
>
>
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c index 93cd0a4..02cc1d2 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -750,6 +750,17 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_LINK_FREQ:return "Link Frequency";
> case V4L2_CID_PIXEL_RATE: return "Pixel Rate";
> case V4L2_CID_TEST_PATTERN: return "Test Pattern";
> + case V4L2_CID_GAIN_RED: return "Digital Gain Red";
> + case V4L2_CID_GAIN_GREEN_RED: return "Digital Gain Green Red";
> + case V4L2_CID_GAIN_GREEN_BLUE: return "Digital Gain Green
> Blue";
> + case V4L2_CID_GAIN_BLUE:return "Digital Gain Blue";
> + case V4L2_CID_GAIN_GREEN: return "Digital Gain Green";
> + case V4L2_CID_GAIN_OFFSET: return "Digital Gain Offset";
> + case V4L2_CID_BLUE_OFFSET: return "Digital Gain Blue
> Offset";
> + case V4L2_CID_RED_OFFSET: return "Digital Gain Red
> Offset";
> + case V4L2_CID_GREEN_OFFSET: return "Digital Gain Green
> Offset";
> + case V4L2_CID_GREEN_RED_OFFSET: return "Digital Gain Green Red
Offset";
> + case V4L2_CID_GREEN_BLUE_OFFSET:return "Digital Gain Green Blue
Offset";
I would remove the mention of "Digital" here, as those controls can be used
for analog gains as well. Same above in the documentation.
> /* DV controls */
> case V4L2_CID_DV_CLASS: return "Digital Video Controls";
> diff --git a/include/linux/v4l2-controls.h b/include/linux/v4l2-controls.h
> index e1b3680..087596d 100644
> --- a/include/linux/v4l2-controls.h
> +++ b/include/linux/v4l2-controls.h
> @@ -758,5 +758,16 @@ enum v4l2_jpeg_chroma_subsampling {
> #define V4L2_CID_LINK_FREQ (V4L2_CID_IMAGE_PROC_CLASS_BASE
> + 1)
> #define V4L2_CID_PIXEL_RATE (V4L2_CID_IMAGE_PROC_CLASS_BASE
> + 2)
> #define V4L2_CID_TEST_PATTERN
> (V4L2_CID_IMAGE_PROC_CLASS_BASE +
3)
> +#define V4L2_CID_GAIN_RED(V4L2_CID_IMAGE_PROC_CLASS_BASE
> + 4)
> +#define V4L2_CID_GAIN_GREEN_RED
> (V4L2_CID_IMAGE_PROC_CLASS_BASE +
5)
> +#define V4L2_CID_GAIN_GREEN_BLUE
[ 42/56] UBI: erase free PEB with bitflip in EC header
3.6-stable review patch. If anyone has any objections, please let me know. -- From: Matthieu CASTET commit 193819cf2e6e395b1e1be2d36785dc5563a6edca upstream. Without this patch, these PEB are not scrubbed until we put data in them. Bitflip can accumulate latter and we can loose the EC header (but VID header should be intact and allow to recover data). Signed-off-by: Matthieu Castet Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman --- drivers/mtd/ubi/attach.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/mtd/ubi/attach.c +++ b/drivers/mtd/ubi/attach.c @@ -975,7 +975,7 @@ static int scan_peb(struct ubi_device *u return err; goto adjust_mean_ec; case UBI_IO_FF: - if (ec_err) + if (ec_err || bitflips) err = add_to_list(ai, pnum, UBI_UNKNOWN, UBI_UNKNOWN, ec, 1, >erase); else -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 44/56] SCSI: ibmvscsi: Fix host config length field overflow
3.6-stable review patch. If anyone has any objections, please let me know. -- From: Benjamin Herrenschmidt commit 225c56960fcafeccc2b6304f96cd3f0dbf42a16a upstream. The length field in the host config packet is only 16-bit long, so passing it 0x1 (64K which is our standard PAGE_SIZE) doesn't work and result in an empty config from the server. Signed-off-by: Benjamin Herrenschmidt Acked-by: Robert Jennings Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman --- drivers/scsi/ibmvscsi/ibmvscsi.c |3 +++ 1 file changed, 3 insertions(+) --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -1541,6 +1541,9 @@ static int ibmvscsi_do_host_config(struc host_config = _struct->iu.mad.host_config; + /* The transport length field is only 16-bit */ + length = min(0x, length); + /* Set up a lun reset SRP command */ memset(host_config, 0x00, sizeof(*host_config)); host_config->common.type = VIOSRP_HOST_CONFIG_TYPE; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 48/56] remoteproc: select VIRTIO to avoid build breakage
3.6-stable review patch. If anyone has any objections, please let me know. -- From: Ohad Ben-Cohen commit 2ed6d29c725c4aead510b5c23f563795b265acf5 upstream. drivers/built-in.o: In function `rproc_virtio_finalize_features': remoteproc_virtio.c:(.text+0x2f9a02): undefined reference to `vring_transport_features' drivers/built-in.o: In function `rproc_virtio_del_vqs': remoteproc_virtio.c:(.text+0x2f9a74): undefined reference to `vring_del_virtqueue' drivers/built-in.o: In function `rproc_virtio_find_vqs': remoteproc_virtio.c:(.text+0x2f9c44): undefined reference to `vring_new_virtqueue' drivers/built-in.o: In function `rproc_add_virtio_dev': (.text+0x2f9e2c): undefined reference to `register_virtio_device' drivers/built-in.o: In function `rproc_vq_interrupt': (.text+0x2f9db7): undefined reference to `vring_interrupt' drivers/built-in.o: In function `rproc_remove_virtio_dev': (.text+0x2f9e9f): undefined reference to `unregister_virtio_device' Reported-by: Randy Dunlap Signed-off-by: Ohad Ben-Cohen Signed-off-by: Greg Kroah-Hartman --- drivers/remoteproc/Kconfig |1 + 1 file changed, 1 insertion(+) --- a/drivers/remoteproc/Kconfig +++ b/drivers/remoteproc/Kconfig @@ -5,6 +5,7 @@ config REMOTEPROC tristate depends on EXPERIMENTAL select FW_CONFIG + select VIRTIO config OMAP_REMOTEPROC tristate "OMAP remoteproc support" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 51/56] IB/srp: Fix use-after-free in srp_reset_req()
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Bart Van Assche
commit 9b796d06d5d1b1e85ae2316a283ea11dd739ef96 upstream.
srp_free_req() uses the scsi_cmnd structure contents to unmap
buffers, so we must invoke srp_free_req() before we release
ownership of that structure.
Signed-off-by: Bart Van Assche
Acked-by: David Dillow
Signed-off-by: Roland Dreier
Signed-off-by: Greg Kroah-Hartman
---
drivers/infiniband/ulp/srp/ib_srp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -638,9 +638,9 @@ static void srp_reset_req(struct srp_tar
struct scsi_cmnd *scmnd = srp_claim_req(target, req, NULL);
if (scmnd) {
+ srp_free_req(target, req, scmnd, 0);
scmnd->result = DID_RESET << 16;
scmnd->scsi_done(scmnd);
- srp_free_req(target, req, scmnd, 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/
[ 52/56] IB/srp: Avoid having aborted requests hang
3.6-stable review patch. If anyone has any objections, please let me know. -- From: Bart Van Assche commit d8536670916a685df116b5c2cb256573fd25e4e3 upstream. We need to call scsi_done() for commands after we abort them. Signed-off-by: Bart Van Assche Acked-by: David Dillow Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman --- drivers/infiniband/ulp/srp/ib_srp.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/infiniband/ulp/srp/ib_srp.c +++ b/drivers/infiniband/ulp/srp/ib_srp.c @@ -1687,6 +1687,7 @@ static int srp_abort(struct scsi_cmnd *s SRP_TSK_ABORT_TASK); srp_free_req(target, req, scmnd, 0); scmnd->result = DID_ABORT << 16; + scmnd->scsi_done(scmnd); return SUCCESS; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 54/56] isci: fix isci_pci_probe() generates warning on efi failure path
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Williams
commit 6d70a74ffd616073a68ae0974d98819bfa8e6da6 upstream.
The oem parameter image embedded in the efi variable is at an offset
from the start of the variable. However, in the failure path we try to
free the 'orom' pointer which is only valid when the paramaters are
being read from the legacy option-rom space.
Since failure to load the oem parameters is unlikely and we keep the
memory around in the success case just defer all de-allocation to devm.
Reported-by: Don Morris
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/isci/init.c |1 -
drivers/scsi/isci/probe_roms.c |1 -
2 files changed, 2 deletions(-)
--- a/drivers/scsi/isci/init.c
+++ b/drivers/scsi/isci/init.c
@@ -644,7 +644,6 @@ static int __devinit isci_pci_probe(stru
orom->hdr.version)) {
dev_warn(>dev,
"[%d]: invalid oem parameters detected,
falling back to firmware\n", i);
- devm_kfree(>dev, orom);
orom = NULL;
break;
}
--- a/drivers/scsi/isci/probe_roms.c
+++ b/drivers/scsi/isci/probe_roms.c
@@ -104,7 +104,6 @@ struct isci_orom *isci_request_oprom(str
if (i >= len) {
dev_err(>dev, "oprom parse error\n");
- devm_kfree(>dev, rom);
rom = NULL;
}
pci_unmap_biosrom(oprom);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 56/56] SCSI: scsi_dh_alua: Enable STPG for unavailable ports
3.6-stable review patch. If anyone has any objections, please let me know. -- From: Bart Van Assche commit e47f8976d8e573928824a06748f7bc82c58d747f upstream. A quote from SPC-4: "While in the unavailable primary target port asymmetric access state, the device server shall support those of the following commands that it supports while in the active/optimized state: [ ... ] d) SET TARGET PORT GROUPS; [ ... ]". Hence enable sending STPG to a target port group that is in the unavailable state. Signed-off-by: Bart Van Assche Reviewed-by: Mike Christie Acked-by: Hannes Reinecke Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman --- drivers/scsi/device_handler/scsi_dh_alua.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/scsi/device_handler/scsi_dh_alua.c +++ b/drivers/scsi/device_handler/scsi_dh_alua.c @@ -641,8 +641,7 @@ static int alua_rtpg(struct scsi_device h->state = TPGS_STATE_STANDBY; break; case TPGS_STATE_OFFLINE: - case TPGS_STATE_UNAVAILABLE: - /* Path unusable for unavailable/offline */ + /* Path unusable */ err = SCSI_DH_DEV_OFFLINED; break; default: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 02/58] dm mpath: only retry ioctl when no paths if queue_if_no_path set
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Mike Snitzer
commit 7ba10aa6fbac7158a50bec142132b04bc480bb29 upstream.
When there are no paths and multipath receives an ioctl, it waits until
a path becomes available. This behaviour is incorrect if the
"queue_if_no_path" setting was not specified, as then the ioctl should
be rejected immediately, which this patch now does.
commit 35991652b ("dm mpath: allow ioctls to trigger pg init") should
have checked if queue_if_no_path was configured before queueing IO.
Checking for the queue_if_no_path feature, like is done in map_io(),
allows the following table load to work without blocking in the
multipath_ioctl retry loop:
echo "0 1024 multipath 0 0 0 0" | dmsetup create mpath_nodevs
Without this fix the multipath_ioctl will block with the following stack
trace:
blkid D 0002 0 23936 1 0x
8802b89e5cd8 0082 8802b89e5fd8 00012440
8802b89e4010 00012440 00012440 00012440
8802b89e5fd8 00012440 88030c2aab30 880325794040
Call Trace:
[] schedule+0x29/0x70
[] schedule_timeout+0x182/0x2e0
[] ? lock_timer_base+0x70/0x70
[] schedule_timeout_uninterruptible+0x1e/0x20
[] msleep+0x20/0x30
[] multipath_ioctl+0x109/0x170 [dm_multipath]
[] dm_blk_ioctl+0xbc/0xd0 [dm_mod]
[] __blkdev_driver_ioctl+0x28/0x30
[] blkdev_ioctl+0xce/0x730
[] block_ioctl+0x3c/0x40
[] do_vfs_ioctl+0x8c/0x340
[] ? sys_newfstat+0x33/0x40
[] sys_ioctl+0xa1/0xb0
[] system_call_fastpath+0x16/0x1b
Signed-off-by: Mike Snitzer
Acked-by: Mikulas Patocka
Signed-off-by: Alasdair G Kergon
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/dm-mpath.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -1520,6 +1520,7 @@ static int multipath_ioctl(struct dm_tar
unsigned long arg)
{
struct multipath *m = ti->private;
+ struct pgpath *pgpath;
struct block_device *bdev;
fmode_t mode;
unsigned long flags;
@@ -1535,12 +1536,14 @@ again:
if (!m->current_pgpath)
__choose_pgpath(m, 0);
- if (m->current_pgpath) {
- bdev = m->current_pgpath->path.dev->bdev;
- mode = m->current_pgpath->path.dev->mode;
+ pgpath = m->current_pgpath;
+
+ if (pgpath) {
+ bdev = pgpath->path.dev->bdev;
+ mode = pgpath->path.dev->mode;
}
- if (m->queue_io)
+ if ((pgpath && m->queue_io) || (!pgpath && m->queue_if_no_path))
r = -EAGAIN;
else if (!bdev)
r = -EIO;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 03/58] dm: handle requests beyond end of device instead of using BUG_ON
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Mike Snitzer
commit ba1cbad93dd47223b1f3b8edd50dd9ef2abcb2ed upstream.
The access beyond the end of device BUG_ON that was introduced to
dm_request_fn via commit 29e4013de7ad950280e4b2208 ("dm: implement
REQ_FLUSH/FUA support for request-based dm") was an overly
drastic (but simple) response to this situation.
I have received a report that this BUG_ON was hit and now think
it would be better to use dm_kill_unmapped_request() to fail the clone
and original request with -EIO.
map_request() will assign the valid target returned by
dm_table_find_target to tio->ti. But when the target
isn't valid tio->ti is never assigned (because map_request isn't
called); so add a check for tio->ti != NULL to dm_done().
Reported-by: Mike Christie
Signed-off-by: Mike Snitzer
Signed-off-by: Jun'ichi Nomura
Signed-off-by: Alasdair G Kergon
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/dm.c | 56 ++--
1 file changed, 38 insertions(+), 18 deletions(-)
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -865,10 +865,14 @@ static void dm_done(struct request *clon
{
int r = error;
struct dm_rq_target_io *tio = clone->end_io_data;
- dm_request_endio_fn rq_end_io = tio->ti->type->rq_end_io;
+ dm_request_endio_fn rq_end_io = NULL;
- if (mapped && rq_end_io)
- r = rq_end_io(tio->ti, clone, error, >info);
+ if (tio->ti) {
+ rq_end_io = tio->ti->type->rq_end_io;
+
+ if (mapped && rq_end_io)
+ r = rq_end_io(tio->ti, clone, error, >info);
+ }
if (r <= 0)
/* The target wants to complete the I/O */
@@ -1566,15 +1570,6 @@ static int map_request(struct dm_target
int r, requeued = 0;
struct dm_rq_target_io *tio = clone->end_io_data;
- /*
-* Hold the md reference here for the in-flight I/O.
-* We can't rely on the reference count by device opener,
-* because the device may be closed during the request completion
-* when all bios are completed.
-* See the comment in rq_completed() too.
-*/
- dm_get(md);
-
tio->ti = ti;
r = ti->type->map_rq(ti, clone, >info);
switch (r) {
@@ -1606,6 +1601,26 @@ static int map_request(struct dm_target
return requeued;
}
+static struct request *dm_start_request(struct mapped_device *md, struct
request *orig)
+{
+ struct request *clone;
+
+ blk_start_request(orig);
+ clone = orig->special;
+ atomic_inc(>pending[rq_data_dir(clone)]);
+
+ /*
+* Hold the md reference here for the in-flight I/O.
+* We can't rely on the reference count by device opener,
+* because the device may be closed during the request completion
+* when all bios are completed.
+* See the comment in rq_completed() too.
+*/
+ dm_get(md);
+
+ return clone;
+}
+
/*
* q->request_fn for request-based dm.
* Called with the queue lock held.
@@ -1635,14 +1650,21 @@ static void dm_request_fn(struct request
pos = blk_rq_pos(rq);
ti = dm_table_find_target(map, pos);
- BUG_ON(!dm_target_is_valid(ti));
+ if (!dm_target_is_valid(ti)) {
+ /*
+* Must perform setup, that dm_done() requires,
+* before calling dm_kill_unmapped_request
+*/
+ DMERR_LIMIT("request attempted access beyond the end of
device");
+ clone = dm_start_request(md, rq);
+ dm_kill_unmapped_request(clone, -EIO);
+ continue;
+ }
if (ti->type->busy && ti->type->busy(ti))
goto delay_and_out;
- blk_start_request(rq);
- clone = rq->special;
- atomic_inc(>pending[rq_data_dir(clone)]);
+ clone = dm_start_request(md, rq);
spin_unlock(q->queue_lock);
if (map_request(ti, clone, md))
@@ -1662,8 +1684,6 @@ delay_and_out:
blk_delay_queue(q, HZ / 10);
out:
dm_table_put(map);
-
- return;
}
int dm_underlying_device_busy(struct request_queue *q)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 01/58] vfs: dcache: fix deadlock in tree traversal
3.5-stable review patch. If anyone has any objections, please let me know. -- From: Miklos Szeredi commit 8110e16d42d587997bcaee0c864179e6d93603fe upstream. IBM reported a deadlock in select_parent(). This was found to be caused by taking rename_lock when already locked when restarting the tree traversal. There are two cases when the traversal needs to be restarted: 1) concurrent d_move(); this can only happen when not already locked, since taking rename_lock protects against concurrent d_move(). 2) racing with final d_put() on child just at the moment of ascending to parent; rename_lock doesn't protect against this rare race, so it can happen when already locked. Because of case 2, we need to be able to handle restarting the traversal when rename_lock is already held. This patch fixes all three callers of try_to_ascend(). IBM reported that the deadlock is gone with this patch. [ I rewrote the patch to be smaller and just do the "goto again" if the lock was already held, but credit goes to Miklos for the real work. - Linus ] Signed-off-by: Miklos Szeredi Cc: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- fs/dcache.c |6 ++ 1 file changed, 6 insertions(+) --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1132,6 +1132,8 @@ positive: return 1; rename_retry: + if (locked) + goto again; locked = 1; write_seqlock(_lock); goto again; @@ -1234,6 +1236,8 @@ out: rename_retry: if (found) return found; + if (locked) + goto again; locked = 1; write_seqlock(_lock); goto again; @@ -3031,6 +3035,8 @@ resume: return; rename_retry: + if (locked) + goto again; locked = 1; write_seqlock(_lock); goto again; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 07/58] usb: gadget: initialize the strings in tcm_usb_gadget properly
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
commit 18786da4853017d983ff6911648543ca617c12d1 upstream.
I have no idea what I've been thinking while I was doing this in the first
place. Now the strings are initialized properly and reported by lsusb.
Acked-by: Michal Nazarewicz
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/gadget/tcm_usb_gadget.c | 33 -
drivers/usb/gadget/tcm_usb_gadget.h | 14 --
2 files changed, 28 insertions(+), 19 deletions(-)
--- a/drivers/usb/gadget/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/tcm_usb_gadget.c
@@ -1983,7 +1983,6 @@ static struct usb_interface_descriptor b
.bInterfaceClass = USB_CLASS_MASS_STORAGE,
.bInterfaceSubClass = USB_SC_SCSI,
.bInterfaceProtocol = USB_PR_BULK,
- .iInterface = USB_G_STR_INT_UAS,
};
static struct usb_interface_descriptor uasp_intf_desc = {
@@ -1994,7 +1993,6 @@ static struct usb_interface_descriptor u
.bInterfaceClass = USB_CLASS_MASS_STORAGE,
.bInterfaceSubClass = USB_SC_SCSI,
.bInterfaceProtocol = USB_PR_UAS,
- .iInterface = USB_G_STR_INT_BBB,
};
static struct usb_endpoint_descriptor uasp_bi_desc = {
@@ -2215,20 +2213,16 @@ static struct usb_device_descriptor usbg
.bDeviceClass = USB_CLASS_PER_INTERFACE,
.idVendor = cpu_to_le16(UAS_VENDOR_ID),
.idProduct =cpu_to_le16(UAS_PRODUCT_ID),
- .iManufacturer =USB_G_STR_MANUFACTOR,
- .iProduct = USB_G_STR_PRODUCT,
- .iSerialNumber =USB_G_STR_SERIAL,
-
.bNumConfigurations = 1,
};
static struct usb_string usbg_us_strings[] = {
- { USB_G_STR_MANUFACTOR, "Target Manufactor"},
- { USB_G_STR_PRODUCT,"Target Product"},
- { USB_G_STR_SERIAL, "0001"},
- { USB_G_STR_CONFIG, "default config"},
- { USB_G_STR_INT_UAS,"USB Attached SCSI"},
- { USB_G_STR_INT_BBB,"Bulk Only Transport"},
+ [USB_G_STR_MANUFACTOR].s= "Target Manufactor",
+ [USB_G_STR_PRODUCT].s = "Target Product",
+ [USB_G_STR_SERIAL].s= "0001",
+ [USB_G_STR_CONFIG].s= "default config",
+ [USB_G_STR_INT_UAS].s = "USB Attached SCSI",
+ [USB_G_STR_INT_BBB].s = "Bulk Only Transport",
{ },
};
@@ -2250,7 +2244,6 @@ static int guas_unbind(struct usb_compos
static struct usb_configuration usbg_config_driver = {
.label = "Linux Target",
.bConfigurationValue= 1,
- .iConfiguration = USB_G_STR_CONFIG,
.bmAttributes = USB_CONFIG_ATT_SELFPOWER,
};
@@ -2423,6 +2416,9 @@ static int usbg_cfg_bind(struct usb_conf
fu->function.disable = usbg_disable;
fu->tpg = the_only_tpg_I_currently_have;
+ bot_intf_desc.iInterface = usbg_us_strings[USB_G_STR_INT_BBB].id;
+ uasp_intf_desc.iInterface = usbg_us_strings[USB_G_STR_INT_UAS].id;
+
ret = usb_add_function(c, >function);
if (ret)
goto err;
@@ -2437,6 +2433,17 @@ static int usb_target_bind(struct usb_co
{
int ret;
+ ret = usb_string_ids_tab(cdev, usbg_us_strings);
+ if (ret)
+ return ret;
+
+ usbg_device_desc.iManufacturer =
+ usbg_us_strings[USB_G_STR_MANUFACTOR].id;
+ usbg_device_desc.iProduct = usbg_us_strings[USB_G_STR_PRODUCT].id;
+ usbg_device_desc.iSerialNumber = usbg_us_strings[USB_G_STR_SERIAL].id;
+ usbg_config_driver.iConfiguration =
+ usbg_us_strings[USB_G_STR_CONFIG].id;
+
ret = usb_add_config(cdev, _config_driver,
usbg_cfg_bind);
return 0;
--- a/drivers/usb/gadget/tcm_usb_gadget.h
+++ b/drivers/usb/gadget/tcm_usb_gadget.h
@@ -16,12 +16,14 @@
#define UASP_SS_EP_COMP_LOG_STREAMS 4
#define UASP_SS_EP_COMP_NUM_STREAMS (1 << UASP_SS_EP_COMP_LOG_STREAMS)
-#define USB_G_STR_MANUFACTOR1
-#define USB_G_STR_PRODUCT 2
-#define USB_G_STR_SERIAL3
-#define USB_G_STR_CONFIG4
-#define USB_G_STR_INT_UAS 5
-#define USB_G_STR_INT_BBB 6
+enum {
+ USB_G_STR_MANUFACTOR,
+ USB_G_STR_PRODUCT,
+ USB_G_STR_SERIAL,
+ USB_G_STR_CONFIG,
+ USB_G_STR_INT_UAS,
+ USB_G_STR_INT_BBB,
+};
#define USB_G_ALT_INT_BBB 0
#define USB_G_ALT_INT_UAS 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/
[ 09/58] USB: ftdi_sio: add TIAO USB Multi-Protocol Adapter (TUMPA) support
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Antonio Ospite
commit 54575b05af36959dfb6a49a3e9ca0c2b456b7126 upstream.
TIAO/DIYGADGET USB Multi-Protocol Adapter (TUMPA) is an FTDI FT2232H
based device which provides an easily accessible JTAG, SPI, I2C, serial
breakout.
http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
http://www.tiaowiki.com/w/TIAO_USB_Multi_Protocol_Adapter_User%27s_Manual
FTDI FT2232H provides two serial channels (A and B), but on the TUMPA
channel A is dedicated to JTAG/SPI while channel B can be used for
UART/RS-232: use the ftdi_jtag_quirk to expose only channel B as
a usb-serial interface to userspace.
Signed-off-by: Antonio Ospite
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/ftdi_sio.c |2 ++
drivers/usb/serial/ftdi_sio_ids.h |5 +
2 files changed, 7 insertions(+)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -584,6 +584,8 @@ static struct usb_device_id id_table_com
{ USB_DEVICE(FTDI_VID, FTDI_IBS_PEDO_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_IBS_PROD_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_TAVIR_STK500_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_TIAO_UMPA_PID),
+ .driver_info = (kernel_ulong_t)_jtag_quirk },
/*
* ELV devices:
*/
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -517,6 +517,11 @@
*/
#define FTDI_TAVIR_STK500_PID 0xFA33 /* STK500 AVR programmer */
+/*
+ * TIAO product ids (FTDI_VID)
+ * http://www.tiaowiki.com/w/Main_Page
+ */
+#define FTDI_TIAO_UMPA_PID 0x8a98 /* TIAO/DIYGADGET USB Multi-Protocol
Adapter */
//
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 11/58] usb: host: xhci: Fix Null pointer dereferencing with 71c731a for non-x86 systems
3.5-stable review patch. If anyone has any objections, please let me know. -- From: Vivek Gautam commit 457a73d346187c2cc5d599072f38676f18f130e0 upstream. In 71c731a: usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware when extracting DMI strings (vendor or product_name) to mark them as quirk we may get NULL pointer in case of non-x86 systems which won't define CONFIG_DMI. Hence susbsequent strstr() calls crash while driver probing. So, returning 'false' here in case we get a NULL vendor or product_name. This is tested with ARM (exynos) system. This patch should be backported to stable kernels as old as 3.6, that contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" Signed-off-by: Vivek Gautam Signed-off-by: Sarah Sharp Reported-by: Sebastian Gottschall (DD-WRT) Signed-off-by: Greg Kroah-Hartman --- drivers/usb/host/xhci.c |2 ++ 1 file changed, 2 insertions(+) --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -470,6 +470,8 @@ static bool compliance_mode_recovery_tim dmi_product_name = dmi_get_system_info(DMI_PRODUCT_NAME); dmi_sys_vendor = dmi_get_system_info(DMI_SYS_VENDOR); + if (!dmi_product_name || !dmi_sys_vendor) + return false; if (!(strstr(dmi_sys_vendor, "Hewlett-Packard"))) return false; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
