login
Search
This is the start of the stable review cycle for the 2.6.25.4 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it. These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email stable@kernel.org to add your name to the list. If you want to be off the reviewer list, also email us. Responses should be made by May 15, 20:00:00 UTC. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.25.4-rc1.gz and the diffstat can be found below. thanks, the -stable release team Makefile | 2 arch/sparc/kernel/entry.S | 2 arch/sparc/kernel/process.c | 25 +- arch/sparc/kernel/ptrace.c | 6 arch/sparc/kernel/rtrap.S | 11 - arch/sparc/kernel/signal.c | 84 ++++---- arch/sparc/kernel/sys_sparc.c | 48 ---- arch/sparc64/kernel/etrap.S | 7 arch/sparc64/kernel/irq.c | 3 arch/sparc64/kernel/pci.c | 130 +++--------- arch/sparc64/kernel/pci_common.c | 6 arch/sparc64/kernel/pci_impl.h | 9 arch/sparc64/kernel/process.c | 18 + arch/sparc64/kernel/ptrace.c | 16 + arch/sparc64/kernel/rtrap.S | 1 arch/sparc64/kernel/signal.c | 88 ++++---- arch/sparc64/kernel/signal32.c | 48 +++- arch/sparc64/kernel/sys_sparc.c | 40 --- arch/sparc64/kernel/sys_sparc32.c | 33 --- ...
2.6.25-stable review patch. If anyone has any objections, please let us know.
------------------
From: Albert Comerma <albert.comerma@gmail.com>
patch 6ca8f0b97473dcef3a754bab5239dcfcdd00b244 upstream
This patch introduces support for dvb-t for the following DiBcom based cards:
- Terratec Cinergy HT USB XE (USB-ID: 0ccd:0058)
- Terratec Cinergy HT Express (USB-ID: 0ccd:0060)
- Pinnacle 320CX (USB-ID: 2304:022e)
- Pinnacle PCTV72e (USB-ID: 2304:0236)
- Pinnacle PCTV73e (USB-ID: 2304:0237)
- Yuan EC372S (USB-ID: 1164:1edc)
Signed-off-by: Hans-Frieder Vogt <hfvogt@gmx.net>
Signed-off-by: Felix Apitzsch <F.Apitzsch@soz.uni-frankfurt.de>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Albert Comerma <albert.comerma@gmail.com>
Signed-off-by: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Michel Morisot <mmorisot.abonnement@belcenter.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/media/dvb/dvb-usb/dib0700_devices.c | 259 ++++++++++++++++++++++++----
drivers/media/dvb/dvb-usb/dvb-usb-ids.h | 9
2 files changed, 238 insertions(+), 30 deletions(-)
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -13,6 +13,7 @@
#include "dib7000p.h"
#include "mt2060.h"
#include "mt2266.h"
+#include "tuner-xc2028.h"
#include "dib0070.h"
static int force_lna_activation;
@@ -297,6 +298,149 @@ static int stk7700d_tuner_attach(struct
&stk7700d_mt2266_config[adap->id]) == NULL ? -ENODEV : 0;;
}
+/* STK7700-PH: Digital/Analog Hybrid Tuner, e.h. Cinergy HT USB HE */
+struct dibx000_agc_config xc3028_agc_config = {
+ BAND_VHF | BAND_UHF, /* band_caps */
+
+ /* P_agc_use_sd_mod1=0, P_agc_use_sd_mod2=0, P_agc_freq_pwm_div=0,
+ * P_agc_inv_pwm1=0, P_agc_inv_pwm2=0, P_agc_inh_dc_rv_est=0,
+ * P_agc_time_est=3, P_agc_freeze=0, P_agc_nb_est=2, P_agc_write=0 */
+ (0 << 15) | (0 << 14) | (0 << 11) | (0 << 10) | (0 << 9) | ...This patch is entirely inappropriate for -stable Who sent this in? I usually send in the v4l-dvb backports for -stable, and this was never in my queue, not to mention that it doesn't qualify, based on the -stable rules. Regards, Mike Krufky --
It is much larger than a 100 line patch. I know that this is not a _strict_ requirement, but upon closer inspection, I see that the majority of this is codingstyle cleanup. The codingstyle cleanups should have been removed from this patch before backporting to The patch is fine, and there is nothing wrong with it. The only problem is that all of the cosmetic cleanups are unnecessary, and they have caused the patch to appear like a larger change than it actually is. I thought it was important for patches going in to -stable to be "obviously correct". All of the cleanups remove the "obvious correctness" from this patch, and introduce the chance of a typo somewhere. This is all the result of checkpatch.pl -- now it is run before any commit occurs to the v4l-dvb mercurial repository, causing people to merge codingstyle cleanups into actual changesets. This makes review more difficult. I always believe that separate changes should appear in separate patches. Had this patch been the simple ID addition & config struct additions, this discussion would never have occurred. I withdraw my complaint, but I recommend that the "codingstyle cleanup" hunks from the patch should be dropped. Of the 30 deletions, only two of them are valid: - .num_device_descs = 1, + .num_device_descs = 2, and - .num_device_descs = 6, + .num_device_descs = 8, Regards, Mike --
Yes, it does make it appear that way, but it is much simpler to just take the exact same upstream patch for something like this than to have to pick and choose it by hand. It reduces the potential for error and I'm lazy :) thanks, greg k-h --
2.6.25-stable review patch. If anyone has any objections, please let us know. ------------------ From: Samuel Thibault <samuel.thibault@ens-lyon.org> commit c1236d31a1b9fc018b85e15a3e58e3601ddc90ae upstream For e.g. proper TTY canonical support, IUTF8 termios flag has to be set as appropriate. Linux used to not care about setting that flag for VT TTYs. This patch fixes that by activating it according to the current mode of the VT, and sets the default value according to the vt.default_utf8 parameter. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/char/vt.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/char/vt.c +++ b/drivers/char/vt.c @@ -2723,6 +2723,10 @@ static int con_open(struct tty_struct *t tty->winsize.ws_row = vc_cons[currcons].d->vc_rows; tty->winsize.ws_col = vc_cons[currcons].d->vc_cols; } + if (vc->vc_utf) + tty->termios->c_iflag |= IUTF8; + else + tty->termios->c_iflag &= ~IUTF8; release_console_sem(); vcs_make_sysfs(tty); return ret; @@ -2899,6 +2903,8 @@ int __init vty_init(void) console_driver->minor_start = 1; console_driver->type = TTY_DRIVER_TYPE_CONSOLE; console_driver->init_termios = tty_std_termios; + if (default_utf8) + console_driver->init_termios.c_iflag |= IUTF8; console_driver->flags = TTY_DRIVER_REAL_RAW | TTY_DRIVER_RESET_TERMIOS; tty_set_operations(console_driver, &con_ops); if (tty_register_driver(console_driver)) -- --
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
commit 55d7b68996a5064f011d681bca412b6281d2f711 upstream
I noticed that
static void uart_flush_buffer(struct tty_struct *tty)
{
struct uart_state *state = tty->driver_data;
struct uart_port *port = state->port;
unsigned long flags;
/*
* This means you called this function _after_ the port was
* closed. No cookie for you.
*/
if (!state || !state->info) {
WARN_ON(1);
return;
}
is too late for checking state != NULL.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/serial/serial_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -535,7 +535,7 @@ static int uart_chars_in_buffer(struct t
static void uart_flush_buffer(struct tty_struct *tty)
{
struct uart_state *state = tty->driver_data;
- struct uart_port *port = state->port;
+ struct uart_port *port;
unsigned long flags;
/*
@@ -547,6 +547,7 @@ static void uart_flush_buffer(struct tty
return;
}
+ port = state->port;
pr_debug("uart_flush_buffer(%d) called\n", tty->index);
spin_lock_irqsave(&port->lock, flags);
--
--
2.6.25-stable review patch. If anyone has any objections, please let us know. ------------------ From: Alan Stern <stern@rowland.harvard.edu> commit 43bbb7e015c4380064796c5868b536437b165615 in upstream Drivers in the ohci-hcd family should perform certain tasks whenever their controller device is resumed. These include checking for loss of power during suspend, turning on port power, and enabling interrupt requests. Until now these jobs have been carried out when the root hub is resumed, not when the controller is. Many drivers work around the resulting awkwardness by automatically resuming their root hub whenever the controller is resumed. But this is wasteful and unnecessary. In 2.6.25, ohci-pci doesn't even do that. After waking up from hibernation, it simply leaves the controller in a RESET state, which is useless. To simplify the situation, this patch (as1066b) adds a new core routine, ohci_finish_controller_resume(), which can be used by all the OHCI-variant drivers. They can call the new routine instead of resuming their root hubs. And ohci-pci.c can call it instead of using its own special-purpose handler. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/usb/host/ohci-at91.c | 1 drivers/usb/host/ohci-ep93xx.c | 2 - drivers/usb/host/ohci-hub.c | 43 +++++++++++++++++++++++++++++++++++++++++ drivers/usb/host/ohci-omap.c | 2 - drivers/usb/host/ohci-pci.c | 43 ----------------------------------------- drivers/usb/host/ohci-pxa27x.c | 3 -- drivers/usb/host/ohci-sm501.c | 2 - drivers/usb/host/ohci-ssb.c | 1 8 files changed, 50 insertions(+), 47 deletions(-) --- a/drivers/usb/host/ohci-at91.c +++ b/drivers/usb/host/ohci-at91.c @@ -348,6 +348,7 @@ static int ohci_hcd_at91_drv_resume(stru if (!clocked) at91_start_clock(); + ohci_finish_controller_resume(hcd); return 0; } #else --- a/drivers/usb/host/ohci-ep93xx.c +++ ...
2.6.25-stable review patch. If anyone has any objections, please let us know. ------------------ From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> [ Upstream commit: 27a27a2158f4fe56a29458449e880a52ddee3dc4 ] Flowlabel text format was not correct and thus ambiguous. For example, 0x00123 or 0x01203 are formatted as 0x123. This is not what audit tools want. Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- net/xfrm/xfrm_state.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/xfrm/xfrm_state.c +++ b/net/xfrm/xfrm_state.c @@ -2093,7 +2093,7 @@ static void xfrm_audit_helper_pktinfo(st iph6 = ipv6_hdr(skb); audit_log_format(audit_buf, " src=" NIP6_FMT " dst=" NIP6_FMT - " flowlbl=0x%x%x%x", + " flowlbl=0x%x%02x%02x", NIP6(iph6->saddr), NIP6(iph6->daddr), iph6->flow_lbl[0] & 0x0f, -- --
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Robert Reif <reif@earthlink.net>
[ Upstream commit: 227739bf4c110bbd02d0c0f13b272c32de406e4c ]
I have a sparcstation 20 clone with a lot of on board serial ports.
The serial core code assumes that uarts are assigned contiguously
and that may not be the case when there are multiple zs devices
present. This patch insures that uart chips are placed in front of
keyboard/mouse chips in the port table.
ffd37420: ttyS0 at MMIO 0xf1100000 (irq = 44) is a zs (ESCC)
Console: ttyS0 (SunZilog zs0)
console [ttyS0] enabled
ffd37420: ttyS1 at MMIO 0xf1100004 (irq = 44) is a zs (ESCC)
ffd37500: Keyboard at MMIO 0xf1000000 (irq = 44) is a zs
ffd37500: Mouse at MMIO 0xf1000004 (irq = 44) is a zs
ffd3c5c0: ttyS2 at MMIO 0xf1100008 (irq = 44) is a zs (ESCC)
ffd3c5c0: ttyS3 at MMIO 0xf110000c (irq = 44) is a zs (ESCC)
ffd3c6a0: ttyS4 at MMIO 0xf1100010 (irq = 44) is a zs (ESCC)
ffd3c6a0: ttyS5 at MMIO 0xf1100014 (irq = 44) is a zs (ESCC)
ffd3c780: ttyS6 at MMIO 0xf1100018 (irq = 44) is a zs (ESCC)
ffd3c780: ttyS7 at MMIO 0xf110001c (irq = 44) is a zs (ESCC)
Signed-off-by: Robert Reif <reif@earthlink.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/serial/sunzilog.c | 30 +++++++++++++++++-------------
1 file changed, 17 insertions(+), 13 deletions(-)
--- a/drivers/serial/sunzilog.c
+++ b/drivers/serial/sunzilog.c
@@ -1015,6 +1015,7 @@ static struct uart_ops sunzilog_pops = {
.verify_port = sunzilog_verify_port,
};
+static int uart_chip_count;
static struct uart_sunzilog_port *sunzilog_port_table;
static struct zilog_layout __iomem **sunzilog_chip_regs;
@@ -1350,16 +1351,22 @@ static int zilog_irq = -1;
static int __devinit zs_probe(struct of_device *op, const struct of_device_id *match)
{
- static int inst;
+ static int kbm_inst, uart_inst;
+ int inst;
struct uart_sunzilog_port ...2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: David S. Miller <davem@davemloft.net>
[ Upstream commit: dc5dc7e6d71ca9fd1ea01a1418150af3b2937489 ]
We need to be more liberal about the alignment of the buffer given to
us by sigaltstack(). The user should not need to be mindful of all of
the alignment constraints we have for the stack frame.
This mirrors how we handle this situation in clone() as well.
Also, we align the stack even in non-SA_ONSTACK cases so that signals
due to bad stack alignment can be delivered properly. This makes such
errors easier to debug and recover from.
Finally, add the sanity check x86 has to make sure we won't overflow
the signal stack.
This fixes glibc testcases nptl/tst-cancel20.c and
nptl/tst-cancelx20.c
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/sparc/kernel/signal.c | 20 +++++++++++++++++---
arch/sparc64/kernel/signal.c | 21 +++++++++++++++++----
arch/sparc64/kernel/signal32.c | 18 +++++++++++++++++-
3 files changed, 51 insertions(+), 8 deletions(-)
--- a/arch/sparc64/kernel/signal32.c
+++ b/arch/sparc64/kernel/signal32.c
@@ -497,11 +497,27 @@ static void __user *get_sigframe(struct
regs->u_regs[UREG_FP] &= 0x00000000ffffffffUL;
sp = regs->u_regs[UREG_FP];
+ /*
+ * If we are on the alternate signal stack and would overflow it, don't.
+ * Return an always-bogus address instead so we will die with SIGSEGV.
+ */
+ if (on_sig_stack(sp) && !likely(on_sig_stack(sp - framesize)))
+ return (void __user *) -1L;
+
/* This is the X/Open sanctioned signal stack switching. */
if (sa->sa_flags & SA_ONSTACK) {
- if (!on_sig_stack(sp) && !((current->sas_ss_sp + current->sas_ss_size) & 7))
+ if (sas_ss_flags(sp) == 0)
sp = current->sas_ss_sp + current->sas_ss_size;
}
+
+ /* Always align the stack frame. This handles two cases. First,
+ * sigaltstack need not be ...2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: David S. Miller <davem@davemloft.net>
[ Upstream commit: 1e38c126c9252b612697e34f43b1b3371c8ee31d ]
We clobber %i1 as well as %i0 for these system calls,
because they give two return values.
Therefore, on error, we have to restore %i1 properly
or else the restart explodes since it uses the wrong
arguments.
This fixes glibc's nptl/tst-eintr1.c testcase.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/sparc/kernel/process.c | 20 ++++++++++++++++----
arch/sparc64/kernel/process.c | 18 +++++++++++++++---
2 files changed, 31 insertions(+), 7 deletions(-)
--- a/arch/sparc64/kernel/process.c
+++ b/arch/sparc64/kernel/process.c
@@ -507,6 +507,8 @@ asmlinkage long sparc_do_fork(unsigned l
unsigned long stack_size)
{
int __user *parent_tid_ptr, *child_tid_ptr;
+ unsigned long orig_i1 = regs->u_regs[UREG_I1];
+ long ret;
#ifdef CONFIG_COMPAT
if (test_thread_flag(TIF_32BIT)) {
@@ -519,9 +521,19 @@ asmlinkage long sparc_do_fork(unsigned l
child_tid_ptr = (int __user *) regs->u_regs[UREG_I4];
}
- return do_fork(clone_flags, stack_start,
- regs, stack_size,
- parent_tid_ptr, child_tid_ptr);
+ ret = do_fork(clone_flags, stack_start,
+ regs, stack_size,
+ parent_tid_ptr, child_tid_ptr);
+
+ /* If we get an error and potentially restart the system
+ * call, we're screwed because copy_thread() clobbered
+ * the parent's %o1. So detect that case and restore it
+ * here.
+ */
+ if ((unsigned long)ret >= -ERESTART_RESTARTBLOCK)
+ regs->u_regs[UREG_I1] = orig_i1;
+
+ return ret;
}
/* Copy a Sparc thread. The fork() return value conventions
--- a/arch/sparc/kernel/process.c
+++ b/arch/sparc/kernel/process.c
@@ -421,14 +421,26 @@ asmlinkage int sparc_do_fork(unsigned lo
unsigned long ...2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: David S. Miller <davem@davemloft.net>
[ Upstream commit: 86d8337618e69573b5ccd3553f800944e843cae7 ]
It just creates confusion, errors, and bugs.
For one thing, this can cause dup sysfs or procfs nodes to get
created:
[ 1.198015] proc_dir_entry '00.0' already registered
[ 1.198036] Call Trace:
[ 1.198052] [00000000004f2534] create_proc_entry+0x7c/0x98
[ 1.198092] [00000000005719e4] pci_proc_attach_device+0xa4/0xd4
[ 1.198126] [00000000007d991c] pci_proc_init+0x64/0x88
[ 1.198158] [00000000007c62a4] kernel_init+0x190/0x330
[ 1.198183] [0000000000426cf8] kernel_thread+0x38/0x48
[ 1.198210] [00000000006a0d90] rest_init+0x18/0x5c
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/sparc64/kernel/pci.c | 130 +++++++++------------------------------
arch/sparc64/kernel/pci_common.c | 6 -
arch/sparc64/kernel/pci_impl.h | 9 --
3 files changed, 33 insertions(+), 112 deletions(-)
--- a/arch/sparc64/kernel/pci.c
+++ b/arch/sparc64/kernel/pci.c
@@ -351,8 +351,7 @@ static void pci_parse_of_addrs(struct of
struct pci_dev *of_create_pci_dev(struct pci_pbm_info *pbm,
struct device_node *node,
- struct pci_bus *bus, int devfn,
- int host_controller)
+ struct pci_bus *bus, int devfn)
{
struct dev_archdata *sd;
struct pci_dev *dev;
@@ -389,43 +388,28 @@ struct pci_dev *of_create_pci_dev(struct
dev->devfn = devfn;
dev->multifunction = 0; /* maybe a lie? */
- if (host_controller) {
- if (tlb_type != hypervisor) {
- pci_read_config_word(dev, PCI_VENDOR_ID,
- &dev->vendor);
- pci_read_config_word(dev, PCI_DEVICE_ID,
- &dev->device);
- } else {
- dev->vendor = PCI_VENDOR_ID_SUN;
- dev->device = 0x80f0;
- }
- dev->cfg_size = 256;
- dev->class = PCI_CLASS_BRIDGE_HOST << ...2.6.25-stable review patch. If anyone has any objections, please let us know. ------------------ From: David S. Miller <davem@davemloft.net> [ Upstream commit: 92aa3573c9cd58fe0bcd1c52c9fd8f5708785917 ] Kernel bugzilla 10273 As reported by Jos van der Ende, ever since commit 5a606b72a4309a656cd1a19ad137dc5557c4b8ea ("[SPARC64]: Do not ACK an INO if it is disabled or inprogress.") sun4u interrupts can get stuck. What this changset did was add the following conditional to the various IRQ chip ->enable() handlers on sparc64: if (unlikely(desc->status & (IRQ_DISABLED|IRQ_INPROGRESS))) return; which is correct, however it means that special care is needed in the ->enable() method. Specifically we must put the interrupt into IDLE state during an enable, or else it might never be sent out again. Setting the INO interrupt state to IDLE resets the state machine, the interrupt input to the INO is retested by the hardware, and if an interrupt is being signalled by the device, the INO moves back into TRANSMIT state, and an interrupt vector is sent to the cpu. The two sun4v IRQ chip handlers were already doing this properly, only sun4u got it wrong. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- arch/sparc64/kernel/irq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/sparc64/kernel/irq.c +++ b/arch/sparc64/kernel/irq.c @@ -1,6 +1,6 @@ /* irq.c: UltraSparc IRQ handling/init/registry. * - * Copyright (C) 1997, 2007 David S. Miller (davem@davemloft.net) + * Copyright (C) 1997, 2007, 2008 David S. Miller (davem@davemloft.net) * Copyright (C) 1998 Eddie C. Dost (ecd@skynet.be) * Copyright (C) 1998 Jakub Jelinek (jj@ultra.linux.cz) */ @@ -308,6 +308,7 @@ static void sun4u_irq_enable(unsigned in IMAP_AID_SAFARI | IMAP_NID_SAFARI); val |= tid | IMAP_VALID; upa_writeq(val, imap); + upa_writeq(ICLR_IDLE, data->iclr); } } -- --
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: David S. Miller <davem@davemloft.net>
[ Upstream commit: 020cfb05f2c594c778537159bd45ea5efb0c5e0d ]
Second and third arguments were swapped for whatever reason.
Reported by Tom Callaway.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/sparc64/kernel/sys_sparc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/sparc64/kernel/sys_sparc.c
+++ b/arch/sparc64/kernel/sys_sparc.c
@@ -454,8 +454,8 @@ asmlinkage long sys_ipc(unsigned int cal
err = sys_semget(first, (int)second, (int)third);
goto out;
case SEMCTL: {
- err = sys_semctl(first, third,
- (int)second | IPC_64,
+ err = sys_semctl(first, second,
+ (int)third | IPC_64,
(union semun) ptr);
goto out;
}
--
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: David S. Miller <davem@davemloft.net>
[ Upstream commit: b53e5216e5f73330bffae93b42dceb94e361f4c0 ]
They were all "serial" so if multiple of these drivers registered,
we'd trigger sysfs directory creation errors:
[ 1.695793] proc_dir_entry 'serial' already registered
[ 1.695839] Call Trace:
[ 1.831891] [00000000004f2534] create_proc_entry+0x7c/0x98
[ 1.833608] [00000000004f3a58] proc_tty_register_driver+0x40/0x70
[ 1.833663] [0000000000594700] tty_register_driver+0x1fc/0x208
[ 1.835371] [00000000005aade4] uart_register_driver+0x134/0x16c
[ 1.841762] [00000000005ac274] sunserial_register_minors+0x34/0x68
[ 1.841818] [00000000007db2a4] sunsu_init+0xf8/0x150
[ 1.867697] [00000000007c62a4] kernel_init+0x190/0x330
[ 1.939147] [0000000000426cf8] kernel_thread+0x38/0x48
[ 1.939198] [00000000006a0d90] rest_init+0x18/0x5c
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/serial/sunhv.c | 2 +-
drivers/serial/sunsab.c | 2 +-
drivers/serial/sunsu.c | 2 +-
drivers/serial/sunzilog.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/serial/sunhv.c
+++ b/drivers/serial/sunhv.c
@@ -392,7 +392,7 @@ static struct uart_ops sunhv_pops = {
static struct uart_driver sunhv_reg = {
.owner = THIS_MODULE,
- .driver_name = "serial",
+ .driver_name = "sunhv",
.dev_name = "ttyS",
.major = TTY_MAJOR,
};
--- a/drivers/serial/sunsab.c
+++ b/drivers/serial/sunsab.c
@@ -826,7 +826,7 @@ static struct uart_ops sunsab_pops = {
static struct uart_driver sunsab_reg = {
.owner = THIS_MODULE,
- .driver_name = "serial",
+ .driver_name = "sunsab",
.dev_name = "ttyS",
.major = TTY_MAJOR,
};
--- a/drivers/serial/sunsu.c
+++ b/drivers/serial/sunsu.c
@@ -1173,7 +1173,7 @@ out:
static struct uart_driver ...2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Jarek Poplawski <jarkao2@gmail.com>
[ Upstream commit: 3ba08b00e0d8413d79be9cab8ec085ceb6ae6fd6 ]
There is lack of removing a class from the event queue while changing
from parent to leaf which can cause corruption of this rb tree. This
patch fixes a bug introduced by my patch: "sch_htb: turn intermediate
classes into leaves" commit: 160d5e10f87b1dc88fd9b84b31b1718e0fd76398.
Many thanks to Jan 'yanek' Bortl for finding a way to reproduce this
rare bug and narrowing the test case, which made possible proper
diagnosing.
This patch is recommended for all kernels starting from 2.6.20.
Reported-and-tested-by: Jan 'yanek' Bortl <yanek@ya.bofh.cz>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/sched/sch_htb.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -1197,12 +1197,16 @@ static inline int htb_parent_last_child(
return 1;
}
-static void htb_parent_to_leaf(struct htb_class *cl, struct Qdisc *new_q)
+static void htb_parent_to_leaf(struct htb_sched *q, struct htb_class *cl,
+ struct Qdisc *new_q)
{
struct htb_class *parent = cl->parent;
BUG_TRAP(!cl->level && cl->un.leaf.q && !cl->prio_activity);
+ if (parent->cmode != HTB_CAN_SEND)
+ htb_safe_rb_erase(&parent->pq_node, q->wait_pq + parent->level);
+
parent->level = 0;
memset(&parent->un.inner, 0, sizeof(parent->un.inner));
INIT_LIST_HEAD(&parent->un.leaf.drop_list);
@@ -1300,7 +1304,7 @@ static int htb_delete(struct Qdisc *sch,
htb_deactivate(q, cl);
if (last_child)
- htb_parent_to_leaf(cl, new_q);
+ htb_parent_to_leaf(q, cl, new_q);
if (--cl->refcnt == 0)
htb_destroy_class(sch, cl);
--
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Patrick McHardy <kaber@trash.net>
[ Upstream commit: 7312096454b6cd71267eaa3d0efb408e449e9ff3 ]
As noticed by Ben Greear, macvlan crashes the kernel when unloading the
module. The reason is that it tries to clean up the macvlan_port pointer
on the macvlan device itself instead of the underlying device. A non-NULL
pointer is taken as indication that the macvlan_handle_frame_hook is
valid, when receiving the next packet on the underlying device it tries
to call the NULL hook and crashes.
Clean up the macvlan_port on the correct device to fix this.
Signed-off-by; Patrick McHardy <kaber@trash.net>
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/macvlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -450,7 +450,7 @@ static void macvlan_dellink(struct net_d
unregister_netdevice(dev);
if (list_empty(&port->vlans))
- macvlan_port_destroy(dev);
+ macvlan_port_destroy(port->dev);
}
static struct rtnl_link_ops macvlan_link_ops __read_mostly = {
--
--
2.6.25-stable review patch. If anyone has any objections, please let us know. ------------------ From: Julian Anastasov <ja@ssi.bg> [ Upstream commit: 2ad17defd596ca7e8ba782d5fc6950ee0e99513c ] Fixes bug http://bugzilla.kernel.org/show_bug.cgi?id=10556 where conn templates with protocol=IPPROTO_IP can oops backup box. Result from ip_vs_proto_get() should be checked because protocol value can be invalid or unsupported in backup. But for valid message we should not fail for templates which use IPPROTO_IP. Also, add checks to validate message limits and connection state. Show state NONE for templates using IPPROTO_IP. Fix tested and confirmed by L0op8ack <l0op8ack@hotmail.com> Signed-off-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- include/net/ip_vs.h | 3 + net/ipv4/ipvs/ip_vs_proto.c | 2 - net/ipv4/ipvs/ip_vs_proto_ah.c | 1 net/ipv4/ipvs/ip_vs_proto_esp.c | 1 net/ipv4/ipvs/ip_vs_proto_tcp.c | 1 net/ipv4/ipvs/ip_vs_proto_udp.c | 1 net/ipv4/ipvs/ip_vs_sync.c | 80 +++++++++++++++++++++++++++++----------- 7 files changed, 66 insertions(+), 23 deletions(-) --- a/include/net/ip_vs.h +++ b/include/net/ip_vs.h @@ -405,7 +405,8 @@ struct sk_buff; struct ip_vs_protocol { struct ip_vs_protocol *next; char *name; - __u16 protocol; + u16 protocol; + u16 num_states; int dont_defrag; atomic_t appcnt; /* counter of proto app incs */ int *timeout_table; /* protocol timeout table */ --- a/net/ipv4/ipvs/ip_vs_proto_ah.c +++ b/net/ipv4/ipvs/ip_vs_proto_ah.c @@ -160,6 +160,7 @@ static void ah_exit(struct ip_vs_protoco struct ip_vs_protocol ip_vs_protocol_ah = { .name = "AH", .protocol = IPPROTO_AH, + .num_states = 1, .dont_defrag = 1, .init = ah_init, .exit = ah_exit, --- a/net/ipv4/ipvs/ip_vs_proto.c +++ b/net/ipv4/ipvs/ip_vs_proto.c @@ -148,7 +148,7 @@ const char * ...
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Chris Wright <chrisw@sous-sol.org>
[ Upstream commit: 19443178fbfbf40db15c86012fc37df1a44ab857 ]
dccp_feat_change() validates length and on error is returning 1.
This happens to work since call chain is checking for 0 == success,
but this is returned to userspace, so make it a real error value.
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/dccp/feat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/dccp/feat.c
+++ b/net/dccp/feat.c
@@ -32,7 +32,7 @@ int dccp_feat_change(struct dccp_minisoc
if (len > 3) {
DCCP_WARN("invalid length %d\n", len);
- return 1;
+ return -EINVAL;
}
/* XXX add further sanity checks */
--
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Oliver Hartkopp <oliver@hartkopp.net>
[ Upstream commit: c2ab7ac225e29006b7117d6a9fe8f3be8d98b0c2 ]
The tx packet counting and the local loopback of CAN frames should
only happen in the case that the CAN frame has been enqueued to the
netdevice tx queue successfully.
Thanks to Andre Naujoks <nautsch@gmail.com> for reporting this issue.
Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: Urs Thuermann <urs@isnogud.escape.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/can/af_can.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -208,6 +208,7 @@ static int can_create(struct net *net, s
*/
int can_send(struct sk_buff *skb, int loop)
{
+ struct sk_buff *newskb = NULL;
int err;
if (skb->dev->type != ARPHRD_CAN) {
@@ -244,8 +245,7 @@ int can_send(struct sk_buff *skb, int lo
* If the interface is not capable to do loopback
* itself, we do it here.
*/
- struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC);
-
+ newskb = skb_clone(skb, GFP_ATOMIC);
if (!newskb) {
kfree_skb(skb);
return -ENOMEM;
@@ -254,7 +254,6 @@ int can_send(struct sk_buff *skb, int lo
newskb->sk = skb->sk;
newskb->ip_summed = CHECKSUM_UNNECESSARY;
newskb->pkt_type = PACKET_BROADCAST;
- netif_rx(newskb);
}
} else {
/* indication for the CAN driver: no loopback required */
@@ -266,11 +265,20 @@ int can_send(struct sk_buff *skb, int lo
if (err > 0)
err = net_xmit_errno(err);
+ if (err) {
+ if (newskb)
+ kfree_skb(newskb);
+ return err;
+ }
+
+ if (newskb)
+ netif_rx(newskb);
+
/* update statistics */
can_stats.tx_frames++;
can_stats.tx_frames_delta++;
- return err;
+ return 0;
}
EXPORT_SYMBOL(can_send);
--
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Sam Ravnborg <sam@ravnborg.org>
commit b9b39bfba5b0de3418305f01cfa7bc55a16004e1 upstream
x86: use defconfigs from x86/configs/*
Daniel Drake <dsd@gentoo.org> reported:
In 2.6.23, if you unpacked a kernel source tarball and then
ran "make menuconfig" you'd be presented with this message:
# using defaults found in arch/i386/defconfig
and the default options would be set.
The same thing in 2.6.24 does not give you any "using defaults" message, and
the default config options within menuconfig are rather blank (e.g. no PCI
support). You can work around this by explicitly running "make defconfig"
before menuconfig, but it would be nice to have the behaviour the way it was
for 2.6.23 (and the way it still is for other archs).
Fixed by adding a x86 specific defconfig list to Kconfig.
Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=10470
Tested-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/x86/Kconfig | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -24,6 +24,18 @@ config X86
select HAVE_KRETPROBES
select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
+config DEFCONFIG_LIST
+ string
+ depends on X86_32
+ option defconfig_list
+ default "arch/x86/configs/i386_defconfig"
+
+config DEFCONFIG_LIST
+ string
+ depends on X86_64
+ option defconfig_list
+ default "arch/x86/configs/x86_64_defconfig"
+
config GENERIC_LOCKBREAK
def_bool n
--
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Philip Craig <philipc@snapgear.com>
[NETFILTER]: nf_conntrack: padding breaks conntrack hash on ARM
Upstream commit 443a70d50:
commit 0794935e "[NETFILTER]: nf_conntrack: optimize hash_conntrack()"
results in ARM platforms hashing uninitialised padding. This padding
doesn't exist on other architectures.
Fix this by replacing NF_CT_TUPLE_U_BLANK() with memset() to ensure
everything is initialised. There were only 4 bytes that
NF_CT_TUPLE_U_BLANK() wasn't clearing anyway (or 12 bytes on ARM).
Signed-off-by: Philip Craig <philipc@snapgear.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/net/netfilter/nf_conntrack_tuple.h | 10 ----------
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 2 +-
net/netfilter/nf_conntrack_core.c | 4 ++--
3 files changed, 3 insertions(+), 13 deletions(-)
--- a/include/net/netfilter/nf_conntrack_tuple.h
+++ b/include/net/netfilter/nf_conntrack_tuple.h
@@ -101,16 +101,6 @@ struct nf_conntrack_tuple_mask
} src;
};
-/* This is optimized opposed to a memset of the whole structure. Everything we
- * really care about is the source/destination unions */
-#define NF_CT_TUPLE_U_BLANK(tuple) \
- do { \
- (tuple)->src.u.all = 0; \
- (tuple)->dst.u.all = 0; \
- memset(&(tuple)->src.u3, 0, sizeof((tuple)->src.u3)); \
- memset(&(tuple)->dst.u3, 0, sizeof((tuple)->dst.u3)); \
- } while (0)
-
#ifdef __KERNEL__
#define NF_CT_DUMP_TUPLE(tp) \
--- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
@@ -305,7 +305,7 @@ getorigdst(struct sock *sk, int optval,
const struct nf_conntrack_tuple_hash *h;
...2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Arnaud Ebalard <arno@natisbad.org>
[NETFILTER]: {nfnetlink,ip,ip6}_queue: fix skb_over_panic when enlarging packets
From: Arnaud Ebalard <arno@natisbad.org>
Upstream commit 9a732ed6d:
While reinjecting *bigger* modified versions of IPv6 packets using
libnetfilter_queue, things work fine on a 2.6.24 kernel (2.6.22 too)
but I get the following on recents kernels (2.6.25, trace below is
against today's net-2.6 git tree):
skb_over_panic: text:c04fddb0 len:696 put:632 head:f7592c00 data:f7592c00 tail:0xf7592eb8 end:0xf7592e80 dev:eth0
------------[ cut here ]------------
invalid opcode: 0000 [#1] PREEMPT
Process sendd (pid: 3657, ti=f6014000 task=f77c31d0 task.ti=f6014000)
Stack: c071e638 c04fddb0 000002b8 00000278 f7592c00 f7592c00 f7592eb8 f7592e80
f763c000 f6bc5200 f7592c40 f6015c34 c04cdbfc f6bc5200 00000278 f6015c60
c04fddb0 00000020 f72a10c0 f751b420 00000001 0000000a 000002b8 c065582c
Call Trace:
[<c04fddb0>] ? nfqnl_recv_verdict+0x1c0/0x2e0
[<c04cdbfc>] ? skb_put+0x3c/0x40
[<c04fddb0>] ? nfqnl_recv_verdict+0x1c0/0x2e0
[<c04fd115>] ? nfnetlink_rcv_msg+0xf5/0x160
[<c04fd03e>] ? nfnetlink_rcv_msg+0x1e/0x160
[<c04fd020>] ? nfnetlink_rcv_msg+0x0/0x160
[<c04f8ed7>] ? netlink_rcv_skb+0x77/0xa0
[<c04fcefc>] ? nfnetlink_rcv+0x1c/0x30
[<c04f8c73>] ? netlink_unicast+0x243/0x2b0
[<c04cfaba>] ? memcpy_fromiovec+0x4a/0x70
[<c04f9406>] ? netlink_sendmsg+0x1c6/0x270
[<c04c8244>] ? sock_sendmsg+0xc4/0xf0
[<c011970d>] ? set_next_entity+0x1d/0x50
[<c0133a80>] ? autoremove_wake_function+0x0/0x40
[<c0118f9e>] ? __wake_up_common+0x3e/0x70
[<c0342fbf>] ? n_tty_receive_buf+0x34f/0x1280
[<c011d308>] ? __wake_up+0x68/0x70
[<c02cea47>] ? copy_from_user+0x37/0x70
[<c04cfd7c>] ? verify_iovec+0x2c/0x90
[<c04c837a>] ? sys_sendmsg+0x10a/0x230
[<c011967a>] ? __dequeue_entity+0x2a/0xa0
[<c011970d>] ? set_next_entity+0x1d/0x50
[<c0345397>] ? ...Hi,
Sorry for the noise, but for those who missed one of the latest post on
the topic on netdev, I should add that the bug is also in 2.6.24.4 (even
^^^^^^
i.e. read 2.6.24.x with x<4
Cheers,
a+
Sorry, yes, we are no longer doing 2.6.24-stable releases. thanks, greg k-h --
the fix will be available in 2.6.25.4 ? -- Gustavo Guillermo Pérez Compunauta uLinux www.compunauta.com --
Gustavo Guillermo Perez wrote: > El Martes, 13 de Mayo de 2008, Greg KH escribi
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Tejun Heo <htejun@gmail.com>
commit cb6716c879ecf49e2af344926c6a476821812061 upstream
On certain configurations (certain macbooks), even though all the
conditions for SIDPR access described in the datasheet are met,
actually reading those registers just returns 0 and have no effect on
write. Verify SIDPR is actually working before enabling it.
This is reported by Ryan Roth in bz#10512.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Ryan Roth <ryan.roth@ch2m.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/ata/ata_piix.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -1531,6 +1531,8 @@ static void __devinit piix_init_sidpr(st
{
struct pci_dev *pdev = to_pci_dev(host->dev);
struct piix_host_priv *hpriv = host->private_data;
+ struct ata_device *dev0 = &host->ports[0]->link.device[0];
+ u32 scontrol;
int i;
/* check for availability */
@@ -1549,6 +1551,29 @@ static void __devinit piix_init_sidpr(st
return;
hpriv->sidpr = pcim_iomap_table(pdev)[PIIX_SIDPR_BAR];
+
+ /* SCR access via SIDPR doesn't work on some configurations.
+ * Give it a test drive by inhibiting power save modes which
+ * we'll do anyway.
+ */
+ scontrol = piix_sidpr_read(dev0, SCR_CONTROL);
+
+ /* if IPM is already 3, SCR access is probably working. Don't
+ * un-inhibit power save modes as BIOS might have inhibited
+ * them for a reason.
+ */
+ if ((scontrol & 0xf00) != 0x300) {
+ scontrol |= 0x300;
+ piix_sidpr_write(dev0, SCR_CONTROL, scontrol);
+ scontrol = piix_sidpr_read(dev0, SCR_CONTROL);
+
+ if ((scontrol & 0xf00) != 0x300) {
+ dev_printk(KERN_INFO, host->dev, "SCR access via "
+ "SIDPR is available but doesn't work\n");
+ return;
+ }
+ }
+
host->ports[0]->ops = ...2.6.25-stable review patch. If anyone has any objections, please let us know. ------------------ From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> commit 5c3a121d52b30a1e53cdaa802fa1965fcd243164 upstream System topology on intel based system needs to be exported for non-numa case as well. All parts of asm-i386/topology.h has come under #ifdef CONFIG_NUMA after the merge to asm-x86/topology.h /sys/devices/system/cpu/cpu?/topology/* is populated based on ENABLE_TOPO_DEFINES The sysfs cpu topology is not being populated on my dual socket dual core xeon 5160 processor based (x86 32 bit) system. CONFIG_NUMA is not set in my case yet the topology is relevant and useful. irqbalance daemon application depends on topology to build the cpus and package list and it fails on Fedora9 beta since the sysfs topology was not being populated in the 2.6.25 kernel. I am not sure if it was intentional to not define ENABLE_TOPO_DEFINES for non-numa systems. This fix has been tested on the above mentioned dual core, dual socket system. Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- include/asm-x86/topology.h | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) --- a/include/asm-x86/topology.h +++ b/include/asm-x86/topology.h @@ -25,6 +25,16 @@ #ifndef _ASM_X86_TOPOLOGY_H #define _ASM_X86_TOPOLOGY_H +#ifdef CONFIG_X86_32 +# ifdef CONFIG_X86_HT +# define ENABLE_TOPO_DEFINES +# endif +#else +# ifdef CONFIG_SMP +# define ENABLE_TOPO_DEFINES +# endif +#endif + #ifdef CONFIG_NUMA #include <linux/cpumask.h> #include <asm/mpspec.h> @@ -112,10 +122,6 @@ extern unsigned long node_end_pfn[]; extern unsigned long node_remap_size[]; #define node_has_online_mem(nid) (node_start_pfn[nid] != node_end_pfn[nid]) -# ifdef CONFIG_X86_HT -# define ...
Hi Greg, This fix has been included in 2.6.26-rc2 and has been tested for correct topology information in the following system configurations: 32-bit Two socket dual core xeon 5160 processor system 32-bit Two socket quad core xeon E5450 processor system Tested-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> --
Thanks for the testing, sorry I didn't get to add you to the changelog, I got your response after I did the release :( greg k-h --
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Jean Delvare <khali@linux-fr.org>
commit c2fc54fcd340cbee47510aa84c346aab3440ba09 upstream
We had a report that running sensors-detect on a Sapphire AM2RD790
motherbord killed the CPU. While the exact cause is still unknown,
I'd rather play it safe and prevent any access to the SMBus on that
machine by not letting the i2c-piix4 driver attach to the SMBus host
device on that machine. Also blacklist a similar board made by DFI.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/i2c/busses/i2c-piix4.c | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -108,7 +108,27 @@ static unsigned short piix4_smba;
static struct pci_driver piix4_driver;
static struct i2c_adapter piix4_adapter;
-static struct dmi_system_id __devinitdata piix4_dmi_table[] = {
+static struct dmi_system_id __devinitdata piix4_dmi_blacklist[] = {
+ {
+ .ident = "Sapphire AM2RD790",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "SAPPHIRE Inc."),
+ DMI_MATCH(DMI_BOARD_NAME, "PC-AM2RD790"),
+ },
+ },
+ {
+ .ident = "DFI Lanparty UT 790FX",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "DFI Inc."),
+ DMI_MATCH(DMI_BOARD_NAME, "LP UT 790FX"),
+ },
+ },
+ { }
+};
+
+/* The IBM entry is in a separate table because we only check it
+ on Intel-based systems */
+static struct dmi_system_id __devinitdata piix4_dmi_ibm[] = {
{
.ident = "IBM",
.matches = { DMI_MATCH(DMI_SYS_VENDOR, "IBM"), },
@@ -123,8 +143,16 @@ static int __devinit piix4_setup(struct
dev_info(&PIIX4_dev->dev, "Found %s device\n", pci_name(PIIX4_dev));
+ /* On some motherboards, it was reported that accessing the SMBus
+ caused severe hardware problems */
+ if (dmi_check_system(piix4_dmi_blacklist)) ...Hello *,
I in creation of a new Enterprise building small ARM based portable
Computers and I make heavy use of I2C and 1-Wire...
Now I have gooten the following from the LKM:
------------------------ END OF REPLIED MESSAGE ------------------------
Hell, since I do not depend on LOW-BUDGET, I have never killed a CPU
even by SICK programming even my SuperSparc CPU survived.
Please can anyone advice me, about VERY VERY good Hardware design to
prevent its destruction by software Errors?
You can even send me examples of such broken Hardware...
Oh yes, since I am using exclusivly Debian GNU/Linux none of my project
will work with a well known proprietary OS and my hardware specs will be
entirely open even if I code the stuff my own (currently).
Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
--
Many (perhaps all) modern computers perform the final building process upon power up. This usually involves writing bits to some gate-arrays and performing hardware initializations with registers that disappear once the machine starts acting like a real PC. I wrote a BIOS for the AMD SC520 and most of the code involved "building" the machine. However, there was an unwritten rule that nothing could be done to hurt anything. There is only one CPU that I know of, the 56000 DSP, that can be configured with insane instructions that will hurt it. Nowadays, more power adjustment stuff is being put where it shouldn't be. A bad bit somewhere may cause a power supply to go out of regulation and burn out something (like the CPU). If you find something like this, the machine vendor should replace the machine and/or the machine should be black-listed. We can't have computers in which a random event such as an alpha-particle upset can actually hurt anything. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ **************************************************************** The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. --
Hello Dick,
Thank you for the answer...
Even if I use several times an I2C current Sink/Source converter
=66rom Dallas/Maxim the security is done by Hardware design...
So nobody will burn my Atmel ARM1176.
Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
------------------------ END OF REPLIED MESSAGE ------------------------
--=20
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
In this particular case, the CPU was apparently damaged as the result of accidental memory over-voltage. It is worth noting though that said CPU had gone through intensive overclocking session beforehand, and this might explain the death. Other CPUs are known to have gone through the same experience and are still working. So, to clear up any misunderstanding: the CPU damage did not occur because we used some odd CPU instruction sequence or anything like that. The damage came to the CPU from other hardware on the board. To be a bit more technical, the design mistake (I think) that was made by the designers of the motherboard in question, was to use an I2C/SMBus chip on a PC motherboard, which uses SMBus receive byte and SMBus send byte for control, and which lives at an I2C address which is very common amongst hardware monitoring chip. The 4th factor being, of course, that improperly programming the chip in question can result in hardware damage. If only 3 of these 4 factors had been present, most probably there would have been no issue in practice. But with all 4 factors, bad things just had to happen. And it's not just Linux, users had similar problems running hardware monitoring tools under Windows too. -- Jean Delvare --
Hello Jean,
Thank you for explanation.
OK, if I understand I2C right, there are more or less reserved addresses
for each type of chip if I understand it right, but I have only an
incomplete list of it. (gotten from the NXP website where the Tech-
Support is very helpful. Same for Dallas/Maxim)
Do you know, where I can get a full list of it?
Thanks, Greetings and nice Day
Michelle Konzack
Tamay Dogan Network
Debian GNU/Linux Consultant
------------------------ END OF REPLIED MESSAGE ------------------------
--=20
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
2.6.25-stable review patch. If anyone has any objections, please let us know. ------------------ From: David S. Miller <davem@davemloft.net> [ Upstream commit: 986bef854fab44012df678a5b51817d5274d3ca1 ] Forever we had a PTRACE_SUNOS_DETACH which was unconditionally recognized, regardless of the personality of the process. Unfortunately, this value is what ended up in the GLIBC sys/ptrace.h header file on sparc as PTRACE_DETACH and PT_DETACH. So continue to recognize this old value. Luckily, it doesn't conflict with anything we actually care about. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- arch/sparc/kernel/ptrace.c | 2 ++ arch/sparc64/kernel/ptrace.c | 4 ++++ include/asm-sparc/ptrace.h | 1 + include/asm-sparc64/ptrace.h | 1 + 4 files changed, 8 insertions(+) --- a/arch/sparc64/kernel/ptrace.c +++ b/arch/sparc64/kernel/ptrace.c @@ -944,6 +944,8 @@ long compat_arch_ptrace(struct task_stru break; default: + if (request == PTRACE_SPARC_DETACH) + request = PTRACE_DETACH; ret = compat_ptrace_request(child, request, addr, data); break; } @@ -1036,6 +1038,8 @@ long arch_ptrace(struct task_struct *chi break; default: + if (request == PTRACE_SPARC_DETACH) + request = PTRACE_DETACH; ret = ptrace_request(child, request, addr, data); break; } --- a/arch/sparc/kernel/ptrace.c +++ b/arch/sparc/kernel/ptrace.c @@ -441,6 +441,8 @@ long arch_ptrace(struct task_struct *chi break; default: + if (request == PTRACE_SPARC_DETACH) + request = PTRACE_DETACH; ret = ptrace_request(child, request, addr, data); break; } --- a/include/asm-sparc64/ptrace.h +++ b/include/asm-sparc64/ptrace.h @@ -263,6 +263,7 @@ extern void __show_regs(struct pt_regs * #define SF_XXARG 0x5c /* Stuff for the ptrace system call */ +#define PTRACE_SPARC_DETACH 11 #define PTRACE_GETREGS 12 #define PTRACE_SETREGS ...
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: David S. Miller <davem@davemloft.net>
Just like mmap, we need to validate address ranges regardless
of MAP_FIXED.
sparc{,64}_mmap_check()'s flag argument is unused, remove.
Based upon a report and preliminary patch by
Jan Lieskovsky <jlieskov@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/sparc/kernel/sys_sparc.c | 48 +++-----------------------------------
arch/sparc64/kernel/sys_sparc.c | 36 +++-------------------------
arch/sparc64/kernel/sys_sparc32.c | 33 +-------------------------
include/asm-sparc/mman.h | 5 +--
include/asm-sparc64/mman.h | 5 +--
5 files changed, 15 insertions(+), 112 deletions(-)
--- a/arch/sparc64/kernel/sys_sparc32.c
+++ b/arch/sparc64/kernel/sys_sparc32.c
@@ -906,44 +906,15 @@ asmlinkage unsigned long sys32_mremap(un
unsigned long old_len, unsigned long new_len,
unsigned long flags, u32 __new_addr)
{
- struct vm_area_struct *vma;
unsigned long ret = -EINVAL;
unsigned long new_addr = __new_addr;
- if (old_len > STACK_TOP32 || new_len > STACK_TOP32)
+ if (unlikely(sparc64_mmap_check(addr, old_len)))
goto out;
- if (addr > STACK_TOP32 - old_len)
+ if (unlikely(sparc64_mmap_check(new_addr, new_len)))
goto out;
down_write(&current->mm->mmap_sem);
- if (flags & MREMAP_FIXED) {
- if (new_addr > STACK_TOP32 - new_len)
- goto out_sem;
- } else if (addr > STACK_TOP32 - new_len) {
- unsigned long map_flags = 0;
- struct file *file = NULL;
-
- ret = -ENOMEM;
- if (!(flags & MREMAP_MAYMOVE))
- goto out_sem;
-
- vma = find_vma(current->mm, addr);
- if (vma) {
- if (vma->vm_flags & VM_SHARED)
- map_flags |= MAP_SHARED;
- file = vma->vm_file;
- }
-
- /* MREMAP_FIXED checked above. */
- new_addr = get_unmapped_area(file, addr, new_len,
- vma ? vma->vm_pgoff : ...Hmm. I don't have this one in my tree. Is it obsoleted by the other patches I do have, or what? If so, some comment about that would be nice. Linus --
Odd, I missed that. David, did you just forget to send this one? thanks, greg k-h --
From: Greg KH <gregkh@suse.de> I wanted to clear something else of my sparc tree before pushing it to Linus and I didn't get to that last night before passing out. I'll get it to him tonight. --
From: Linus Torvalds <torvalds@linux-foundation.org> It's pending, sorry I just didn't push it to you yet. --
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: David S. Miller <davem@davemloft.net>
[ This is a 2.6.25 backport of upstream changeset
28e6103665301ce60634e8a77f0b657c6cc099de with sparc32 build
fixes from Robert Reif ]
So, forever, we've had this ptrace_signal_deliver implementation
which tries to handle all of the nasties that can occur when the
debugger looks at a process about to take a signal. It's meant
to address all of these issues inside of the kernel so that the
debugger need not be mindful of such things.
Problem is, this doesn't work.
The idea was that we should do the syscall restart business first, so
that the debugger captures that state. Otherwise, if the debugger for
example saves the child's state, makes the child execute something
else, then restores the saved state, we won't handle the syscall
restart properly because we lose the "we're in a syscall" state.
The code here worked for most cases, but if the debugger actually
passes the signal through to the child unaltered, it's possible that
we would do a syscall restart when we shouldn't have.
In particular this breaks the case of debugging a process under a gdb
which is being debugged by yet another gdb. gdb uses sigsuspend
to wait for SIGCHLD of the inferior, but if gdb itself is being
debugged by a top-level gdb we get a ptrace_stop(). The top-level gdb
does a PTRACE_CONT with SIGCHLD to let the inferior gdb see the
signal. But ptrace_signal_deliver() assumed the debugger would cancel
out the signal and therefore did a syscall restart, because the return
error was ERESTARTNOHAND.
Fix this by simply making ptrace_signal_deliver() a nop, and providing
a way for the debugger to control system call restarting properly:
1) Report a "in syscall" software bit in regs->{tstate,psr}.
It is set early on in trap entry to a system call and is fully
visible to the debugger via ptrace() and regsets.
2) Test this bit right ...2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: David S. Miller <davem@davemloft.net>
[ Upstream commit: c07c6053c41f736711ed856aa377007078c7c396 ]
That bit isn't used on this platform.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
arch/sparc/kernel/process.c | 5 -----
1 file changed, 5 deletions(-)
--- a/arch/sparc/kernel/process.c
+++ b/arch/sparc/kernel/process.c
@@ -640,11 +640,6 @@ asmlinkage int sparc_execve(struct pt_re
(char __user * __user *)regs->u_regs[base + UREG_I2],
regs);
putname(filename);
- if (error == 0) {
- task_lock(current);
- current->ptrace &= ~PT_DTRACE;
- task_unlock(current);
- }
out:
return error;
}
--
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Leonardo Chiquitto <leonardo@iken.com.br>
commit 21ae1dd1d4948968ad2d923c5e104d38fb35b4e4 upstream
The following patch fixes a [probable] copy & paste mistake in
airprime.c. Instead of unlocking an acquired mutex, the actual
code tries to lock it again.
Signed-off-by: Leonardo Chiquitto <lchiquitto@novell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/usb/serial/airprime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/serial/airprime.c
+++ b/drivers/usb/serial/airprime.c
@@ -220,7 +220,7 @@ static void airprime_close(struct usb_se
mutex_lock(&port->serial->disc_mutex);
if (!port->serial->disconnected)
airprime_send_setup(port);
- mutex_lock(&port->serial->disc_mutex);
+ mutex_unlock(&port->serial->disc_mutex);
for (i = 0; i < NUM_READ_URBS; ++i) {
usb_kill_urb (priv->read_urbp[i]);
--
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Roel Kluin <12o3l@tiscali.nl>
commit cee60c377de6d9d10f0a2876794149bd79a15020 upstream.
'i' is unsigned.
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/r8169.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1705,18 +1705,18 @@ rtl8169_init_one(struct pci_dev *pdev, c
rtl8169_print_mac_version(tp);
- for (i = ARRAY_SIZE(rtl_chip_info) - 1; i >= 0; i--) {
+ for (i = 0; i < ARRAY_SIZE(rtl_chip_info); i++) {
if (tp->mac_version == rtl_chip_info[i].mac_version)
break;
}
- if (i < 0) {
+ if (i == ARRAY_SIZE(rtl_chip_info)) {
/* Unknown chip: assume array element #0, original RTL-8169 */
if (netif_msg_probe(tp)) {
dev_printk(KERN_DEBUG, &pdev->dev,
"unknown chip version, assuming %s\n",
rtl_chip_info[0].name);
}
- i++;
+ i = 0;
}
tp->chipset = i;
--
--
2.6.25-stable review patch. If anyone has any objections, please let us know. ------------------ From: Ivan Vecera <ivecera@redhat.com> commit 21e197f231343201368338603cb0909a13961bac upstream. r8169_get_mac_version crashes when it meets an unknown MAC due to tp->pci_dev not being set. Initialize it early. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/net/r8169.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/r8169.c +++ b/drivers/net/r8169.c @@ -1617,6 +1617,7 @@ rtl8169_init_one(struct pci_dev *pdev, c SET_NETDEV_DEV(dev, &pdev->dev); tp = netdev_priv(dev); tp->dev = dev; + tp->pci_dev = pdev; tp->msg_enable = netif_msg_init(debug.msg_enable, R8169_MSG_DEFAULT); /* enable device (incl. PCI PM wakeup and hotplug setup) */ @@ -1777,7 +1778,6 @@ rtl8169_init_one(struct pci_dev *pdev, c #endif tp->intr_mask = 0xffff; - tp->pci_dev = pdev; tp->mmio_addr = ioaddr; tp->align = cfg->align; tp->hw_start = cfg->hw_start; -- --
2.6.25-stable review patch. If anyone has any objections, please let us know. ------------------ From: Jeremy Higdon <jeremy@sgi.com> commit af5741c6de4f4a1d8608b0f00867c77cb7123635 upstream The qla1280 driver was ANDing the output value of mailbox register 0 with (1 << target-number) to determine whether to enable queueing on the target in question. But mailbox register 0 has the status code for the mailbox command (in this case, Set Target Parameters). Potential values are: /* * ISP mailbox command complete status codes */ So clearly that is in error. I can't think what the author of that line was looking for in a mailbox register, so I just eliminated the AND. flag is used later in the function, and I think that the later usage was also wrong, though it was used to set values that aren't used. Oh well, an overhaul of this driver is not what I want to do now -- just a bugfix. After the fix, I found that my disks were getting a queue depth of 255, which is far too many. Most SCSI disks are limited to 32 or 64. In any case, there's no point, queueing up a bunch of commands to the adapter that will just result in queue full or starve other targets from being issued commands due to running out of internal memory. So I dropped default queue depth to 32 (from which 1 is subtracted elsewhere, giving net of 31). I tested with a Seagate ST336753LC, and results look good, so I'm satisfied with this patch. Signed-off-by: Jeremy Higdon <jeremy@sgi.com> Acked-by: Jes Sorensen <jes@sgi.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/scsi/qla1280.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/scsi/qla1280.c +++ b/drivers/scsi/qla1280.c @@ -2012,7 +2012,7 @@ qla1280_set_defaults(struct scsi_qla_hos nv->bus[bus].config_2.req_ack_active_negation = 1; nv->bus[bus].config_2.data_line_active_negation = 1; ...
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Mike Christie <michaelc@cs.wisc.edu>
commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream
The following patch fixes a bug in the iscsi nop processing.
The target sends iscsi nops to ping the initiator and the
initiator has to send nops to reply and can send nops to
ping the target.
In 2.6.25 we moved the nop processing to the kernel to handle
problems when the userspace daemon is not up, but the target
is pinging us, and to handle when scsi commands timeout, but
the transport may be the cause (we can send a nop to check
the transport). When we added this code we added a bug where
if the transport timer wakes at the exact same time we are supposed to check
for a nop timeout we drop the session instead of checking the transport.
This patch checks if a iscsi ping is outstanding and if the ping has
timed out, to determine if we need to signal a connection problem.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/scsi/libiscsi.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -1353,19 +1353,20 @@ static void iscsi_check_transport_timeou
{
struct iscsi_conn *conn = (struct iscsi_conn *)data;
struct iscsi_session *session = conn->session;
- unsigned long timeout, next_timeout = 0, last_recv;
+ unsigned long recv_timeout, next_timeout = 0, last_recv;
spin_lock(&session->lock);
if (session->state != ISCSI_STATE_LOGGED_IN)
goto done;
- timeout = conn->recv_timeout;
- if (!timeout)
+ recv_timeout = conn->recv_timeout;
+ if (!recv_timeout)
goto done;
- timeout *= HZ;
+ recv_timeout *= HZ;
last_recv = conn->last_recv;
- if (time_before_eq(last_recv + timeout + (conn->ping_timeout * HZ),
+ if (conn->ping_mtask ...2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Mike Christie <michaelc@cs.wisc.edu>
commit c8611f975403dd20e6503aff8aded5dcb718f75b upstream
If the ping tmo is longer than the recv tmo then we could miss a window
where we were supposed to check the recv tmo. This happens because
the ping code will set the next timeout for the ping timeout, and if the
ping executes quickly there will be a long chunk of time before the
timer wakes up again.
This patch has the ping processing code kick off a recv
tmo check when getting a nop in response to our ping.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/scsi/libiscsi.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -635,7 +635,9 @@ static int __iscsi_complete_pdu(struct i
if (iscsi_recv_pdu(conn->cls_conn, hdr, data,
datalen))
rc = ISCSI_ERR_CONN_FAILED;
- }
+ } else
+ mod_timer(&conn->transport_timer,
+ jiffies + conn->recv_timeout);
iscsi_free_mgmt_task(conn, mtask);
break;
default:
@@ -1378,11 +1380,9 @@ static void iscsi_check_transport_timeou
}
if (time_before_eq(last_recv + recv_timeout, jiffies)) {
- if (time_before_eq(conn->last_ping, last_recv)) {
- /* send a ping to try to provoke some traffic */
- debug_scsi("Sending nopout as ping on conn %p\n", conn);
- iscsi_send_nopout(conn, NULL);
- }
+ /* send a ping to try to provoke some traffic */
+ debug_scsi("Sending nopout as ping on conn %p\n", conn);
+ iscsi_send_nopout(conn, NULL);
next_timeout = conn->last_ping + (conn->ping_timeout * HZ);
} else
next_timeout = last_recv + recv_timeout;
--
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: James Bottomley <James.Bottomley@HansenPartnership.com>
commit 64976a0387835a7ac61bbe2a99b27ccae34eac5d upstream
The problem is that the driver calls aha152x_release() under a
list_for_each_entry(). Unfortunately, aha152x_release() deletes from
the list in question. Fix this by using list_for_each_entry_safe().
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/scsi/aha152x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/scsi/aha152x.c
+++ b/drivers/scsi/aha152x.c
@@ -3919,9 +3919,9 @@ static int __init aha152x_init(void)
static void __exit aha152x_exit(void)
{
- struct aha152x_hostdata *hd;
+ struct aha152x_hostdata *hd, *tmp;
- list_for_each_entry(hd, &aha152x_host_list, host_list) {
+ list_for_each_entry_safe(hd, tmp, &aha152x_host_list, host_list) {
struct Scsi_Host *shost = container_of((void *)hd, struct Scsi_Host, hostdata);
aha152x_release(shost);
--
--
2.6.25-stable review patch. If anyone has any objections, please let us know. ------------------ From: James Bottomley <James.Bottomley@HansenPartnership.com> commit ad2fa42d044b98469449880474a9662fb689f7f9 upstream The driver is apparently returning 0 on failure and 1 on success. That's a bit unfortunate. Fix it by altering to -ENODEV and 0. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/scsi/aha152x.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/scsi/aha152x.c +++ b/drivers/scsi/aha152x.c @@ -3835,7 +3835,7 @@ static int __init aha152x_init(void) iounmap(p); } if (!ok && setup_count == 0) - return 0; + return -ENODEV; printk(KERN_INFO "aha152x: BIOS test: passed, "); #else @@ -3914,7 +3914,7 @@ static int __init aha152x_init(void) #endif } - return 1; + return 0; } static void __exit aha152x_exit(void) -- --
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Maciej W. Rozycki <macro@linux-mips.org>
commit 945185a69daa457c4c5e46e47f4afad7dcea734f upstream
Date: Mon, 12 May 2008 14:02:24 -0700
Subject: [patch 36/37] rtc: rtc_time_to_tm: use unsigned arithmetic
The input argument to rtc_time_to_tm() is unsigned as well as are members of
the output structure. However signed arithmetic is used within for
calculations leading to incorrect results for input values outside the signed
positive range. If this happens the time of day returned is out of range.
Found the problem when fiddling with the RTC and the driver where year was set
to an unexpectedly large value like 2070, e.g.:
rtc0: setting system clock to 2070-01-01 1193046:71582832:26 UTC (3155760954)
while it should be:
rtc0: setting system clock to 2070-01-01 00:15:54 UTC (3155760954)
Changing types to unsigned fixes the problem.
[akpm@linux-foundation.org: remove old-fashioned `register' keyword]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: David Brownell <david-b@pacbell.net>
Cc: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/rtc/rtc-lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/rtc/rtc-lib.c
+++ b/drivers/rtc/rtc-lib.c
@@ -51,7 +51,7 @@ EXPORT_SYMBOL(rtc_year_days);
*/
void rtc_time_to_tm(unsigned long time, struct rtc_time *tm)
{
- register int days, month, year;
+ unsigned int days, month, year;
days = time / 86400;
time -= days * 86400;
--
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Dan Williams <dan.j.williams@intel.com>
commit c8894419acf5e56851de9741c5047bebd78acd1f upstream
Date: Mon, 12 May 2008 14:02:12 -0700
Subject: [patch 37/37] md: fix raid5 'repair' operations
commit bd2ab67030e9116f1e4aae1289220255412b37fd "md: close a livelock window
in handle_parity_checks5" introduced a bug in handling 'repair' operations.
After a repair operation completes we clear the state bits tracking this
operation. However, they are cleared too early and this results in the code
deciding to re-run the parity check operation. Since we have done the repair
in memory the second check does not find a mismatch and thus does not do a
writeback.
Test results:
$ echo repair > /sys/block/md0/md/sync_action
$ cat /sys/block/md0/md/mismatch_cnt
51072
$ echo repair > /sys/block/md0/md/sync_action
$ cat /sys/block/md0/md/mismatch_cnt
0
(also fix incorrect indentation)
Tested-by: George Spelvin <linux@horizon.com>
Acked-by: NeilBrown <neilb@suse.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/md/raid5.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2354,8 +2354,8 @@ static void handle_parity_checks5(raid5_
/* complete a check operation */
if (test_and_clear_bit(STRIPE_OP_CHECK, &sh->ops.complete)) {
- clear_bit(STRIPE_OP_CHECK, &sh->ops.ack);
- clear_bit(STRIPE_OP_CHECK, &sh->ops.pending);
+ clear_bit(STRIPE_OP_CHECK, &sh->ops.ack);
+ clear_bit(STRIPE_OP_CHECK, &sh->ops.pending);
if (s->failed == 0) {
if (sh->ops.zero_sum_result == 0)
/* parity is correct (on disc,
@@ -2385,16 +2385,6 @@ static void handle_parity_checks5(raid5_
...