--- /dev/null
+From stable-bounces@linux.kernel.org Sat May 24 16:56:28 2008
+Date: Sat, 24 May 2008 17:40:11 GMT
+Message-Id: <200805241740.m4OHeBZZ021298@hera.kernel.org>
+From: jejb@kernel.org
+To: jejb@kernel.org, stable@kernel.org
+Subject: brd: don't show ramdisks in /proc/partitions
+
+From: Marcin Krol <hawk@pld-linux.org>
+
+upstream commit: 53978d0a7a27eb036b9bf33c4caa06257a9dbed7
+
+In 2.6.25, ramdisk devices show up in /proc/partitions, which is a
+behaviour change from the old rd.c. Add GENHD_FL_SUPPRESS_PARTITION_INFO,
+which was present in rd.c.
+
+All kernels prior to 2.6.25 weren't displaying ramdisks in
+/proc/partitions. Since there are many userspace tools using information
+from /proc/partitions some of them may now behave incorrectly (I didn't
+tested any though). For example before 2.6.25 /proc/partitions was empty
+if no block devices like hard disks and such were detected by kernel. Now
+all 16 ramdisks are always visible there. Some software may rely on such
+information (I mean, on empty /proc/partitions).
+
+There was quite similar situation back in 2004, and ramdisks were excluded
+back from displaying. Thats why I called this a regression (maybe a bit
+unfortunate). See this patch for info:
+http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3-rc2/2.6.3-rc2-mm1/broken-out/nbd-proc-partitions-fix.patch
+
+I also think that someone somewhere (long time ago) excluded ramdisks from
+/proc/partitions for good reasons. It is possible that now such new
+"feature" is harmless, but I think there are more chances that someone
+will say "hey, /proc/partitions has changed, now my software doesn't work"
+then "hey where did my new 2.6.25 feature go". nbd devices are also
+excluded, maybe for very same (unknown to me) reasons.
+
+Signed-off-by: Marcin Krol <hawk@pld-linux.org>
+Signed-off-by: Nick Piggin <npiggin@suse.de>
+Cc: <stable@kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Chris Wright <chrisw@sous-sol.org>
+---
+ drivers/block/brd.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/block/brd.c
++++ b/drivers/block/brd.c
+@@ -442,6 +442,7 @@ static struct brd_device *brd_alloc(int
+ disk->fops = &brd_fops;
+ disk->private_data = brd;
+ disk->queue = brd->brd_queue;
++ disk->flags |= GENHD_FL_SUPPRESS_PARTITION_INFO;
+ sprintf(disk->disk_name, "ram%d", i);
+ set_capacity(disk, rd_size * 2);
+
--- /dev/null
+From stable-bounces@linux.kernel.org Sat May 24 16:54:52 2008
+Date: Sat, 24 May 2008 17:40:10 GMT
+Message-Id: <200805241740.m4OHeAYC021268@hera.kernel.org>
+From: jejb@kernel.org
+To: jejb@kernel.org, stable@kernel.org
+Subject: cgroups: remove node_ prefix_from ns subsystem
+
+From: Cedric Le Goater <clg@fr.ibm.com>
+
+upstream commit: 5c02b575780d0d785815a1e7b79a98edddee895a
+
+This is a slight change in the namespace cgroup subsystem api.
+
+The change is that previously when cgroup_clone() was called (currently
+only from the unshare path in ns_proxy cgroup, you'd get a new group named
+"node_$pid" whereas now you'll get a group named after just your pid.)
+
+The only users who would notice it are those who are using the ns_proxy
+cgroup subsystem to auto-create cgroups when namespaces are unshared -
+something of an experimental feature, which I think really needs more
+complete container/namespace support in order to be useful. I suspect the
+only users are Cedric and Serge, or maybe a few others on
+containers@lists.linux-foundation.org. And in fact it would only be
+noticed by the users who make the assumption about how the name is
+generated, rather than getting it from the /proc/<pid>/cgroups file for
+the process in question.
+
+Whether the change is actually needed or not I'm fairly agnostic on, but I
+guess it is more elegant to just use the pid as the new group name rather
+than adding a fairly arbitrary "node_" prefix on the front.
+
+[menage@google.com: provided changelog]
+Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
+Cc: "Paul Menage" <menage@google.com>
+Cc: "Serge E. Hallyn" <serue@us.ibm.com>
+Cc: <stable@kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Chris Wright <chrisw@sous-sol.org>
+---
+ kernel/cgroup.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/cgroup.c
++++ b/kernel/cgroup.c
+@@ -2808,7 +2808,7 @@ int cgroup_clone(struct task_struct *tsk
+ cg = tsk->cgroups;
+ parent = task_cgroup(tsk, subsys->subsys_id);
+
+- snprintf(nodename, MAX_CGROUP_TYPE_NAMELEN, "node_%d", tsk->pid);
++ snprintf(nodename, MAX_CGROUP_TYPE_NAMELEN, "%d", tsk->pid);
+
+ /* Pin the hierarchy */
+ atomic_inc(&parent->root->sb->s_active);
--- /dev/null
+From stable-bounces@linux.kernel.org Sat May 24 16:59:24 2008
+Date: Sat, 24 May 2008 17:40:21 GMT
+Message-Id: <200805241740.m4OHeL6J021449@hera.kernel.org>
+From: jejb@kernel.org
+To: jejb@kernel.org, stable@kernel.org
+Subject: IPoIB: Test for NULL broadcast object in ipiob_mcast_join_finish()
+
+From: Jack Morgenstein <jackm@dev.mellanox.co.il>
+
+upstream commit: e1d50dce5af77cb6d33555af70e2b8748dd84009
+
+We saw a kernel oops in our regression testing when a multicast "join
+finish" occurred just after the interface was -- this is
+<https://bugs.openfabrics.org/show_bug.cgi?id=1040>. The test
+randomly causes the HCA physical port to go down then up.
+
+The cause of this is that ipoib_mcast_join_finish() processing happen
+just after ipoib_mcast_dev_flush() was invoked (in which case the
+broadcast pointer is NULL). This patch tests for and handles the case
+where priv->broadcast is NULL.
+
+Cc: <stable@kernel.org>
+Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
+Signed-off-by: Roland Dreier <rolandd@cisco.com>
+Signed-off-by: Chris Wright <chrisw@sous-sol.org>
+---
+ drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
++++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+@@ -194,7 +194,13 @@ static int ipoib_mcast_join_finish(struc
+ /* Set the cached Q_Key before we attach if it's the broadcast group */
+ if (!memcmp(mcast->mcmember.mgid.raw, priv->dev->broadcast + 4,
+ sizeof (union ib_gid))) {
++ spin_lock_irq(&priv->lock);
++ if (!priv->broadcast) {
++ spin_unlock_irq(&priv->lock);
++ return -EAGAIN;
++ }
+ priv->qkey = be32_to_cpu(priv->broadcast->mcmember.qkey);
++ spin_unlock_irq(&priv->lock);
+ priv->tx_wr.wr.ud.remote_qkey = priv->qkey;
+ }
+
cifs-fix-unc-path-prefix-on-queryunixpathinfo-to-have-correct-slash.patch
usb-add-telit-hdspa-uc864-e-modem-to-option-driver.patch
usb-serial-use-ftdi_sio-driver-for-ratoc-rex-usb60f.patch
+cgroups-remove-node_-prefix_from-ns-subsystem.patch
+brd-don-t-show-ramdisks-in-proc-partitions.patch
+types.h-don-t-expose-struct-ustat-to-userspace.patch
+x86-don-t-read-maxlvt-before-checking-if-apic-is-mapped.patch
+ipoib-test-for-null-broadcast-object-in-ipiob_mcast_join_finish.patch
+x86-fix-setup-of-cyc2ns-in-tsc_64.c.patch
+x86-if-we-cannot-calibrate-the-tsc-we-panic.patch
+x86-distangle-user-disabled-tsc-from-unstable.patch
+x86-disable-tsc-for-sched_clock-when-calibration-failed.patch
--- /dev/null
+From stable-bounces@linux.kernel.org Sat May 24 16:57:35 2008
+Date: Sat, 24 May 2008 17:40:14 GMT
+Message-Id: <200805241740.m4OHeEN1021336@hera.kernel.org>
+From: jejb@kernel.org
+To: jejb@kernel.org, stable@kernel.org
+Subject: types.h: don't expose struct ustat to userspace
+
+From: maximilian attems <max@stro.at>
+
+upstream commit: 6c7c6afbb8c0e60d32a563cae7c6889211e9d9d8
+
+<linux/types.h> can't be used together with <sys/ustat.h> because they
+both define struct ustat:
+
+ $ cat test.c
+ #include <sys/ustat.h>
+ #include <linux/types.h>
+ $ gcc -c test.c
+ In file included from test.c:2:
+ /usr/include/linux/types.h:165: error: redefinition of 'struct ustat'
+
+has been reported a while ago to debian, but seems to have been
+lost in cat fighting: http://bugs.debian.org/429064
+
+Signed-off-by: maximilian attems <max@stro.at>
+Cc: <stable@kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Chris Wright <chrisw@sous-sol.org>
+---
+ include/linux/types.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/include/linux/types.h
++++ b/include/linux/types.h
+@@ -197,8 +197,6 @@ typedef u64 resource_size_t;
+ typedef u32 resource_size_t;
+ #endif
+
+-#endif /* __KERNEL__ */
+-
+ struct ustat {
+ __kernel_daddr_t f_tfree;
+ __kernel_ino_t f_tinode;
+@@ -206,4 +204,6 @@ struct ustat {
+ char f_fpack[6];
+ };
+
++#endif /* __KERNEL__ */
++
+ #endif /* _LINUX_TYPES_H */
--- /dev/null
+From stable-bounces@linux.kernel.org Sat May 24 16:58:54 2008
+Date: Sat, 24 May 2008 17:40:17 GMT
+Message-Id: <200805241740.m4OHeHDH021393@hera.kernel.org>
+From: jejb@kernel.org
+To: jejb@kernel.org, stable@kernel.org
+Subject: x86: disable TSC for sched_clock() when calibration failed
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+upstream commit: 74dc51a3de06aa516e3b9fdc4017b2aeb38bf44b
+
+When the TSC calibration fails then TSC is still used in
+sched_clock(). Disable it completely in that case.
+
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@kernel.org
+Signed-off-by: Chris Wright <chrisw@sous-sol.org>
+---
+ arch/x86/kernel/tsc_32.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/arch/x86/kernel/tsc_32.c
++++ b/arch/x86/kernel/tsc_32.c
+@@ -401,6 +401,11 @@ void __init tsc_init(void)
+
+ if (!cpu_khz) {
+ mark_tsc_unstable("could not calculate TSC khz");
++ /*
++ * We need to disable the TSC completely in this case
++ * to prevent sched_clock() from using it.
++ */
++ tsc_disabled = 1;
+ return;
+ }
+
--- /dev/null
+From 9ccc906c97e34fd91dc6aaf5b69b52d824386910 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Tue, 13 May 2008 12:31:00 +0200
+Subject: x86: distangle user disabled TSC from unstable
+
+upstream commit: 9ccc906c97e34fd91dc6aaf5b69b52d824386910
+
+tsc_enabled is set to 0 from the command line switch "notsc" and from
+the mark_tsc_unstable code. Seperate those functionalities and replace
+tsc_enable with tsc_disable. This makes also the native_sched_clock()
+decision when to use TSC understandable.
+
+Preparatory patch to solve the sched_clock() issue on 32 bit.
+
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Chris Wright <chrisw@sous-sol.org>
+---
+ arch/x86/kernel/tsc_32.c | 20 ++++++++++----------
+ 1 file changed, 10 insertions(+), 10 deletions(-)
+
+--- a/arch/x86/kernel/tsc_32.c
++++ b/arch/x86/kernel/tsc_32.c
+@@ -14,7 +14,7 @@
+
+ #include "mach_timer.h"
+
+-static int tsc_enabled;
++static int tsc_disabled;
+
+ /*
+ * On some systems the TSC frequency does not
+@@ -28,8 +28,8 @@ EXPORT_SYMBOL_GPL(tsc_khz);
+ static int __init tsc_setup(char *str)
+ {
+ printk(KERN_WARNING "notsc: Kernel compiled with CONFIG_X86_TSC, "
+- "cannot disable TSC completely.\n");
+- mark_tsc_unstable("user disabled TSC");
++ "cannot disable TSC completely.\n");
++ tsc_disabled = 1;
+ return 1;
+ }
+ #else
+@@ -121,7 +121,7 @@ unsigned long long native_sched_clock(vo
+ * very important for it to be as fast as the platform
+ * can achive it. )
+ */
+- if (unlikely(!tsc_enabled && !tsc_unstable))
++ if (unlikely(tsc_disabled))
+ /* No locking but a rare wrong value is not a big deal: */
+ return (jiffies_64 - INITIAL_JIFFIES) * (1000000000 / HZ);
+
+@@ -310,7 +310,6 @@ void mark_tsc_unstable(char *reason)
+ {
+ if (!tsc_unstable) {
+ tsc_unstable = 1;
+- tsc_enabled = 0;
+ printk("Marking TSC unstable due to: %s.\n", reason);
+ /* Can be called before registration */
+ if (clocksource_tsc.mult)
+@@ -324,7 +323,7 @@ EXPORT_SYMBOL_GPL(mark_tsc_unstable);
+ static int __init dmi_mark_tsc_unstable(const struct dmi_system_id *d)
+ {
+ printk(KERN_NOTICE "%s detected: marking TSC unstable.\n",
+- d->ident);
++ d->ident);
+ tsc_unstable = 1;
+ return 0;
+ }
+@@ -391,8 +390,11 @@ void __init tsc_init(void)
+ {
+ int cpu;
+
+- if (!cpu_has_tsc)
++ if (!cpu_has_tsc || tsc_disabled) {
++ /* Disable the TSC in case of !cpu_has_tsc */
++ tsc_disabled = 1;
+ return;
++ }
+
+ cpu_khz = calculate_cpu_khz();
+ tsc_khz = cpu_khz;
+@@ -429,8 +431,6 @@ void __init tsc_init(void)
+ if (check_tsc_unstable()) {
+ clocksource_tsc.rating = 0;
+ clocksource_tsc.flags &= ~CLOCK_SOURCE_IS_CONTINUOUS;
+- } else
+- tsc_enabled = 1;
+-
++ }
+ clocksource_register(&clocksource_tsc);
+ }
--- /dev/null
+From stable-bounces@linux.kernel.org Sat May 24 16:58:15 2008
+Date: Sat, 24 May 2008 17:40:16 GMT
+Message-Id: <200805241740.m4OHeGhc021380@hera.kernel.org>
+From: jejb@kernel.org
+To: jejb@kernel.org, stable@kernel.org
+Subject: x86: don't read maxlvt before checking if APIC is mapped
+
+From: Chuck Ebbert <cebbert@redhat.com>
+
+upstream commit: 2584a82deed7196f48066f1b1a7fad4ec5bea961
+
+A check for unmapped apic was added before reading maxlvt but the early
+read of maxlvt wasn't removed.
+
+Signed-off-by: Chuck Ebbert <cebbert@redhat.com>
+Cc: Andi Kleen <ak@suse.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Chris Wright <chrisw@sous-sol.org>
+---
+ arch/x86/kernel/apic_64.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/apic_64.c
++++ b/arch/x86/kernel/apic_64.c
+@@ -524,7 +524,7 @@ int setup_profiling_timer(unsigned int m
+ */
+ void clear_local_APIC(void)
+ {
+- int maxlvt = lapic_get_maxlvt();
++ int maxlvt;
+ u32 v;
+
+ /* APIC hasn't been mapped yet */
--- /dev/null
+From stable-bounces@linux.kernel.org Sat May 24 17:01:03 2008
+Date: Sat, 24 May 2008 17:40:18 GMT
+Message-Id: <200805241740.m4OHeIAC021412@hera.kernel.org>
+From: jejb@kernel.org
+To: jejb@kernel.org, stable@kernel.org
+Subject: x86: fix setup of cyc2ns in tsc_64.c
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+upstream commit: b6db80ee1331e7beaeb91b4b3d946dd16c72e388
+
+When the TSC is calibrated against the PIT due to the nonavailability
+of PMTIMER/HPET or due to SMI interference then the setup of the per
+CPU cyc2ns variables is skipped. This is unlikely to happen but it
+would definitely render sched_clock() unusable.
+
+This was introduced with commit 53d517cdbaac704352b3d0c10fecb99e0b54572e
+
+ x86: scale cyc_2_nsec according to CPU frequency
+
+Update the per CPU cyc2ns variables in all exit pathes of tsc_calibrate.
+
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@kernel.org
+Signed-off-by: Chris Wright <chrisw@sous-sol.org>
+---
+ arch/x86/kernel/tsc_64.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/tsc_64.c
++++ b/arch/x86/kernel/tsc_64.c
+@@ -227,14 +227,14 @@ void __init tsc_calibrate(void)
+ /* hpet or pmtimer available ? */
+ if (!hpet && !pm1 && !pm2) {
+ printk(KERN_INFO "TSC calibrated against PIT\n");
+- return;
++ goto out;
+ }
+
+ /* Check, whether the sampling was disturbed by an SMI */
+ if (tsc1 == ULONG_MAX || tsc2 == ULONG_MAX) {
+ printk(KERN_WARNING "TSC calibration disturbed by SMI, "
+ "using PIT calibration result\n");
+- return;
++ goto out;
+ }
+
+ tsc2 = (tsc2 - tsc1) * 1000000L;
+@@ -255,6 +255,7 @@ void __init tsc_calibrate(void)
+
+ tsc_khz = tsc2 / tsc1;
+
++out:
+ for_each_possible_cpu(cpu)
+ set_cyc2ns_scale(tsc_khz, cpu);
+ }
--- /dev/null
+From 3c2047cd32b1a8c782d7efab72707e7daa251625 Mon Sep 17 00:00:00 2001
+From: Rusty Russell <rusty@rustcorp.com.au>
+Date: Tue, 4 Mar 2008 23:07:50 +1100
+Subject: x86: if we cannot calibrate the TSC, we panic.
+
+upstream commit: 3c2047cd32b1a8c782d7efab72707e7daa251625
+
+The current tsc_init() clears the TSC feature bit if the TSC khz
+cannot be calculated, causing us to panic in
+arch/x86/kernel/cpu/bugs.c check_config(). We should simply mark it
+unstable.
+
+Frankly, someone should take an axe to this code. mark_tsc_unstable()
+not only marks it unstable, but sets tsc_enabled to 0, which seems
+redundant but is actually important here because means it won't be
+used by sched_clock() either. Perhaps a tristate enum "UNUSABLE,
+UNSTABLE, OK" would be clearer, and separate mark_tsc_unstable() and
+mark_tsc_broken() functions?
+
+Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
+Signed-off-by: Ingo Molnar <mingo@elte.hu>
+Signed-off-by: Chris Wright <chrisw@sous-sol.org>
+---
+ arch/x86/kernel/tsc_32.c | 13 +++++--------
+ 1 file changed, 5 insertions(+), 8 deletions(-)
+
+--- a/arch/x86/kernel/tsc_32.c
++++ b/arch/x86/kernel/tsc_32.c
+@@ -392,13 +392,15 @@ void __init tsc_init(void)
+ int cpu;
+
+ if (!cpu_has_tsc)
+- goto out_no_tsc;
++ return;
+
+ cpu_khz = calculate_cpu_khz();
+ tsc_khz = cpu_khz;
+
+- if (!cpu_khz)
+- goto out_no_tsc;
++ if (!cpu_khz) {
++ mark_tsc_unstable("could not calculate TSC khz");
++ return;
++ }
+
+ printk("Detected %lu.%03lu MHz processor.\n",
+ (unsigned long)cpu_khz / 1000,
+@@ -431,9 +433,4 @@ void __init tsc_init(void)
+ tsc_enabled = 1;
+
+ clocksource_register(&clocksource_tsc);
+-
+- return;
+-
+-out_no_tsc:
+- setup_clear_cpu_cap(X86_FEATURE_TSC);
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
