From 41f8ad76362e7aefe3a03949c43e23102dae6e0b Mon Sep 17 00:00:00 2001 From: Boaz Harrosh Date: Wed, 25 Jan 2012 21:42:58 +0200 Subject: [PATCH 1/6] [SCSI] osd_uld: Bump MAX_OSD_DEVICES from 64 to 1,048,576 It used to be that minors where 8 bit. But now they are actually 20 bit. So the fix is simplicity itself. I've tested with 300 devices and all user-mode utils work just fine. I have also mechanically added 10,000 to the ida (so devices are /dev/osd10000, /dev/osd10001 ...) and was able to mkfs an exofs filesystem and access osds from user-mode. All the open-osd user-mode code uses the same library to access devices through their symbolic names in /dev/osdX so I'd say it's pretty safe. (Well tested) This patch is very important because some of the systems that will be deploying the 3.2 pnfs-objects code are larger than 64 OSDs and will stop to work properly when reaching that number. CC: Stable Signed-off-by: Boaz Harrosh Signed-off-by: James Bottomley --- drivers/scsi/osd/osd_uld.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/osd/osd_uld.c b/drivers/scsi/osd/osd_uld.c index b31a8e3841d7..d4ed9eb52657 100644 --- a/drivers/scsi/osd/osd_uld.c +++ b/drivers/scsi/osd/osd_uld.c @@ -69,10 +69,10 @@ #ifndef SCSI_OSD_MAJOR # define SCSI_OSD_MAJOR 260 #endif -#define SCSI_OSD_MAX_MINOR 64 +#define SCSI_OSD_MAX_MINOR MINORMASK static const char osd_name[] = "osd"; -static const char *osd_version_string = "open-osd 0.2.0"; +static const char *osd_version_string = "open-osd 0.2.1"; MODULE_AUTHOR("Boaz Harrosh "); MODULE_DESCRIPTION("open-osd Upper-Layer-Driver osd.ko"); From 97a29d59fc222b36bac3ee3a8ae994f65bf7ffdf Mon Sep 17 00:00:00 2001 From: James Bottomley Date: Mon, 30 Jan 2012 10:40:47 -0600 Subject: [PATCH 2/6] [PARISC] fix compile break caused by iomap: make IOPORT/PCI mapping functions conditional The problem in commit fea80311a939a746533a6d7e7c3183729d6a3faf Author: Randy Dunlap Date: Sun Jul 24 11:39:14 2011 -0700 iomap: make IOPORT/PCI mapping functions conditional is that if your architecture supplies pci_iomap/pci_iounmap, it expects always to supply them. Adding empty body defitions in the !CONFIG_PCI case, which is what this patch does, breaks the parisc compile because the functions become doubly defined. It took us a while to spot this, because we don't actually build !CONFIG_PCI very often (only if someone is brave enough to test the snake/asp machines). Since the note in the commit log says this is to fix a CONFIG_GENERIC_IOMAP issue (which it does because CONFIG_GENERIC_IOMAP supplies pci_iounmap only if CONFIG_PCI is set), there should actually have been a condition upon this. This should make sure no other architecture's !CONFIG_PCI compile breaks in the same way as parisc. The fix had to be updated to take account of the GENERIC_PCI_IOMAP separation. Reported-by: Rolf Eike Beer Signed-off-by: James Bottomley --- include/asm-generic/iomap.h | 2 +- include/asm-generic/pci_iomap.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h index 8a3d4fde2604..6afd7d6a9899 100644 --- a/include/asm-generic/iomap.h +++ b/include/asm-generic/iomap.h @@ -70,7 +70,7 @@ extern void ioport_unmap(void __iomem *); /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */ struct pci_dev; extern void pci_iounmap(struct pci_dev *dev, void __iomem *); -#else +#elif defined(CONFIG_GENERIC_IOMAP) struct pci_dev; static inline void pci_iounmap(struct pci_dev *dev, void __iomem *addr) { } diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h index e58fcf891370..ce37349860fe 100644 --- a/include/asm-generic/pci_iomap.h +++ b/include/asm-generic/pci_iomap.h @@ -25,7 +25,7 @@ extern void __iomem *__pci_ioport_map(struct pci_dev *dev, unsigned long port, #define __pci_ioport_map(dev, port, nr) ioport_map((port), (nr)) #endif -#else +#elif defined(CONFIG_GENERIC_PCI_IOMAP) static inline void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max) { return NULL; From 650275dbfb2f4c12bc91420ad5a99f955eabec98 Mon Sep 17 00:00:00 2001 From: Cong Wang Date: Fri, 3 Feb 2012 15:34:16 +0800 Subject: [PATCH 3/6] [PARISC] include in drivers/parisc/iommu-helpers.h drivers/parisc/iommu-helpers.h:62: error: implicit declaration of function 'prefetchw' make[3]: *** [drivers/parisc/sba_iommu.o] Error 1 drivers/parisc/iommu-helpers.h needs to #include where prefetchw is declared. Signed-off-by: WANG Cong Signed-off-by: James Bottomley --- drivers/parisc/iommu-helpers.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/parisc/iommu-helpers.h b/drivers/parisc/iommu-helpers.h index a9c46cc2db37..8c33491b21fe 100644 --- a/drivers/parisc/iommu-helpers.h +++ b/drivers/parisc/iommu-helpers.h @@ -1,3 +1,5 @@ +#include + /** * iommu_fill_pdir - Insert coalesced scatter/gather chunks into the I/O Pdir. * @ioc: The I/O Controller. From aabb70dc23799e09d69d528756471d854f993136 Mon Sep 17 00:00:00 2001 From: James Bottomley Date: Mon, 27 Feb 2012 21:41:05 +0000 Subject: [PATCH 4/6] [PARISC] don't unconditionally override CROSS_COMPILE for 64 bit. The user may wish to set their own value (for real cross compiles). Since the top level Makefile initialises CROSS_COMPILE to empty by default, we must check it for being empty (rather than for being defined) before we override. Reported-by: Paul Gortmaker Signed-off-by: James Bottomley --- arch/parisc/Makefile | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile index 55cca1dac431..19ab7b2ea1cd 100644 --- a/arch/parisc/Makefile +++ b/arch/parisc/Makefile @@ -31,7 +31,11 @@ ifdef CONFIG_64BIT UTS_MACHINE := parisc64 CHECKFLAGS += -D__LP64__=1 -m64 WIDTH := 64 + +# FIXME: if no default set, should really try to locate dynamically +ifeq ($(CROSS_COMPILE),) CROSS_COMPILE := hppa64-linux-gnu- +endif else # 32-bit WIDTH := endif From 192cfd58774b4d17b2fe8bdc77d89c2ef4e0591d Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Sat, 3 Mar 2012 17:08:09 -0800 Subject: [PATCH 5/6] Linux 3.3-rc6 --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index b61a9638b6fc..66d13c917bc7 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 3 PATCHLEVEL = 3 SUBLEVEL = 0 -EXTRAVERSION = -rc5 +EXTRAVERSION = -rc6 NAME = Saber-toothed Squirrel # *DOCUMENTATION* From b11e3d782b9c065b3b2fb543bfb0d97801822dc0 Mon Sep 17 00:00:00 2001 From: "Srivatsa S. Bhat" Date: Wed, 7 Mar 2012 11:44:29 +0100 Subject: [PATCH 6/6] x86, mce: Fix rcu splat in drain_mce_log_buffer() While booting, the following message is seen: [ 21.665087] =============================== [ 21.669439] [ INFO: suspicious RCU usage. ] [ 21.673798] 3.2.0-0.0.0.28.36b5ec9-default #2 Not tainted [ 21.681353] ------------------------------- [ 21.685864] arch/x86/kernel/cpu/mcheck/mce.c:194 suspicious rcu_dereference_index_check() usage! [ 21.695013] [ 21.695014] other info that might help us debug this: [ 21.695016] [ 21.703488] [ 21.703489] rcu_scheduler_active = 1, debug_locks = 1 [ 21.710426] 3 locks held by modprobe/2139: [ 21.714754] #0: (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x53/0xa0 [ 21.725020] #1: [ 21.725323] ioatdma: Intel(R) QuickData Technology Driver 4.00 [ 21.733206] (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x61/0xa0 [ 21.743015] #2: (i7core_edac_lock){+.+.+.}, at: [] i7core_probe+0x1f/0x5c0 [i7core_edac] [ 21.753708] [ 21.753709] stack backtrace: [ 21.758429] Pid: 2139, comm: modprobe Not tainted 3.2.0-0.0.0.28.36b5ec9-default #2 [ 21.768253] Call Trace: [ 21.770838] [] lockdep_rcu_suspicious+0xcd/0x100 [ 21.777366] [] drain_mcelog_buffer+0x191/0x1b0 [ 21.783715] [] mce_register_decode_chain+0x18/0x20 [ 21.790430] [] i7core_register_mci+0x2fb/0x3e4 [i7core_edac] [ 21.798003] [] i7core_probe+0xd4/0x5c0 [i7core_edac] [ 21.804809] [] local_pci_probe+0x5b/0xe0 [ 21.810631] [] __pci_device_probe+0xd9/0xe0 [ 21.816650] [] ? get_device+0x14/0x20 [ 21.822178] [] pci_device_probe+0x36/0x60 [ 21.828061] [] really_probe+0x7a/0x2b0 [ 21.833676] [] driver_probe_device+0x63/0xc0 [ 21.839868] [] __driver_attach+0x9b/0xa0 [ 21.845718] [] ? driver_probe_device+0xc0/0xc0 [ 21.852027] [] bus_for_each_dev+0x68/0x90 [ 21.857876] [] driver_attach+0x1c/0x20 [ 21.863462] [] bus_add_driver+0x16d/0x2b0 [ 21.869377] [] driver_register+0x7c/0x160 [ 21.875220] [] __pci_register_driver+0x6a/0xf0 [ 21.881494] [] ? 0xffffffffa01fdfff [ 21.886846] [] i7core_init+0x47/0x1000 [i7core_edac] [ 21.893737] [] do_one_initcall+0x3e/0x180 [ 21.899670] [] sys_init_module+0xc5/0x220 [ 21.905542] [] system_call_fastpath+0x16/0x1b Fix this by using ACCESS_ONCE() instead of rcu_dereference_check_mce() over mcelog.next. Since the access to each entry is controlled by the ->finished field, ACCESS_ONCE() should work just fine. An rcu_dereference is unnecessary here. Signed-off-by: Srivatsa S. Bhat Suggested-by: Paul E. McKenney Cc: Tony Luck Signed-off-by: Borislav Petkov --- arch/x86/kernel/cpu/mcheck/mce.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c index 5a11ae2e9e91..db590aff874c 100644 --- a/arch/x86/kernel/cpu/mcheck/mce.c +++ b/arch/x86/kernel/cpu/mcheck/mce.c @@ -191,7 +191,7 @@ static void drain_mcelog_buffer(void) { unsigned int next, i, prev = 0; - next = rcu_dereference_check_mce(mcelog.next); + next = ACCESS_ONCE(mcelog.next); do { struct mce *m;