Skip to contentSkip to conversation

2.6.25.4 -stable review

PATCH In review Greg KH 11 participants 57 messages May 13, 2008 – May 16, 2008

Subsystems (27)
lore
Share & tools
lore

Greg KH

author
#0 lore raw

cover 2.6.25.4 -stable review

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 [email protected] 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 ---
 arch/x86/Kconfig                               |   12 +
 drivers/ata/ata_piix.c                         |   25 ++
 drivers/char/vt.c                              |    6 
 drivers/i2c/busses/i2c-piix4.c                 |   32 ++-
 drivers/md/raid5.c                             |   25 +-
 drivers/media/dvb/dvb-usb/dib0700_devices.c    |  259 ++++++++++++++++++++++---
 drivers/media/dvb/dvb-usb/dvb-usb-ids.h        |    9 
 drivers/net/macvlan.c                          |    2 
 drivers/net/r8169.c                            |    8 
 drivers/rtc/rtc-lib.c                          |    2 
 drivers/scsi/aha152x.c                         |    8 
 drivers/scsi/libiscsi.c                        |   29 +-
 drivers/scsi/qla1280.c                         |    4 
 drivers/serial/serial_core.c                   |    3 
 drivers/serial/sunhv.c                         |    2 
 drivers/serial/sunsab.c                        |    2 
 drivers/serial/sunsu.c                         |    2 
 drivers/serial/sunzilog.c                      |   32 +--
 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 
 drivers/usb/serial/airprime.c                  |    2 
 include/asm-sparc/mman.h                       |    5 
 include/asm-sparc/psr.h                        |    1 
 include/asm-sparc/ptrace.h                     |   13 +
 include/asm-sparc/signal.h                     |    8 
 include/asm-sparc64/mman.h                     |    5 
 include/asm-sparc64/psrcompat.h                |    2 
 include/asm-sparc64/pstate.h                   |    1 
 include/asm-sparc64/ptrace.h                   |   13 +
 include/asm-sparc64/signal.h                   |    8 
 include/asm-sparc64/ttable.h                   |    7 
 include/asm-x86/topology.h                     |   18 -
 include/net/ip_vs.h                            |    3 
 include/net/netfilter/nf_conntrack_tuple.h     |   10 
 net/can/af_can.c                               |   16 +
 net/dccp/feat.c                                |    2 
 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 +++++--
 net/ipv4/netfilter/ip_queue.c                  |    5 
 net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c |    2 
 net/ipv6/netfilter/ip6_queue.c                 |    5 
 net/netfilter/nf_conntrack_core.c              |    4 
 net/netfilter/nfnetlink_queue.c                |    5 
 net/sched/sch_htb.c                            |    8 
 net/xfrm/xfrm_state.c                          |    2 
 74 files changed, 808 insertions(+), 559 deletions(-)
author
#1 lore raw

PATCH 1/37 V4L/DVB (7473): PATCH for various Dibcom based devices

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------

From: Albert Comerma <[email protected]>

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)

---
 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(-)
drivers/media/dvb/dvb-usb/dib0700_devices.c +231 -28
@@ -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) | (0 << 8) |
+	(3 << 5) | (0 << 4) | (2 << 1) | (0 << 0), /* setup */
+
+	712,	/* inv_gain */
+	21,	/* time_stabiliz */
+
+	0,	/* alpha_level */
+	118,	/* thlock */
+
+	0,	/* wbd_inv */
+	2867,	/* wbd_ref */
+	0,	/* wbd_sel */
+	2,	/* wbd_alpha */
+
+	0,	/* agc1_max */
+	0,	/* agc1_min */
+	39718,	/* agc2_max */
+	9930,	/* agc2_min */
+	0,	/* agc1_pt1 */
+	0,	/* agc1_pt2 */
+	0,	/* agc1_pt3 */
+	0,	/* agc1_slope1 */
+	0,	/* agc1_slope2 */
+	0,	/* agc2_pt1 */
+	128,	/* agc2_pt2 */
+	29,	/* agc2_slope1 */
+	29,	/* agc2_slope2 */
+
+	17,	/* alpha_mant */
+	27,	/* alpha_exp */
+	23,	/* beta_mant */
+	51,	/* beta_exp */
+
+	1,	/* perform_agc_softsplit */
+};
+
+/* PLL Configuration for COFDM BW_MHz = 8.00 with external clock = 30.00 */
+struct dibx000_bandwidth_config xc3028_bw_config = {
+	60000, 30000, /* internal, sampling */
+	1, 8, 3, 1, 0, /* pll_cfg: prediv, ratio, range, reset, bypass */
+	0, 0, 1, 1, 0, /* misc: refdiv, bypclk_div, IO_CLK_en_core, ADClkSrc,
+			  modulo */
+	(3 << 14) | (1 << 12) | (524 << 0), /* sad_cfg: refsel, sel, freq_15k */
+	(1 << 25) | 5816102, /* ifreq = 5.200000 MHz */
+	20452225, /* timf */
+	30000000, /* xtal_hz */
+};
+
+static struct dib7000p_config stk7700ph_dib7700_xc3028_config = {
+	.output_mpeg2_in_188_bytes = 1,
+	.tuner_is_baseband = 1,
+
+	.agc_config_count = 1,
+	.agc = &xc3028_agc_config,
+	.bw  = &xc3028_bw_config,
+
+	.gpio_dir = DIB7000P_GPIO_DEFAULT_DIRECTIONS,
+	.gpio_val = DIB7000P_GPIO_DEFAULT_VALUES,
+	.gpio_pwm_pos = DIB7000P_GPIO_DEFAULT_PWM_POS,
+};
+
+static int stk7700ph_xc3028_callback(void *ptr, int command, int arg)
+{
+	struct dvb_usb_adapter *adap = ptr;
+
+	switch (command) {
+	case XC2028_TUNER_RESET:
+		/* Send the tuner in then out of reset */
+		dib7000p_set_gpio(adap->fe, 8, 0, 0); msleep(10);
+		dib7000p_set_gpio(adap->fe, 8, 0, 1);
+		break;
+	case XC2028_RESET_CLK:
+		break;
+	default:
+		err("%s: unknown command %d, arg %d\n", __func__,
+			command, arg);
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static struct xc2028_ctrl stk7700ph_xc3028_ctrl = {
+	.fname = XC2028_DEFAULT_FIRMWARE,
+	.max_len = 64,
+	.demod = XC3028_FE_DIBCOM52,
+};
+
+static struct xc2028_config stk7700ph_xc3028_config = {
+	.i2c_addr = 0x61,
+	.callback = stk7700ph_xc3028_callback,
+	.ctrl = &stk7700ph_xc3028_ctrl,
+};
+
+static int stk7700ph_frontend_attach(struct dvb_usb_adapter *adap)
+{
+	struct usb_device_descriptor *desc = &adap->dev->udev->descriptor;
+
+	if (desc->idVendor  == USB_VID_PINNACLE &&
+	    desc->idProduct == USB_PID_PINNACLE_EXPRESSCARD_320CX)
+	dib0700_set_gpio(adap->dev, GPIO6, GPIO_OUT, 0);
+	else
+	dib0700_set_gpio(adap->dev, GPIO6, GPIO_OUT, 1);
+	msleep(20);
+	dib0700_set_gpio(adap->dev, GPIO9, GPIO_OUT, 1);
+	dib0700_set_gpio(adap->dev, GPIO4, GPIO_OUT, 1);
+	dib0700_set_gpio(adap->dev, GPIO7, GPIO_OUT, 1);
+	dib0700_set_gpio(adap->dev, GPIO10, GPIO_OUT, 0);
+	msleep(10);
+	dib0700_set_gpio(adap->dev, GPIO10, GPIO_OUT, 1);
+	msleep(20);
+	dib0700_set_gpio(adap->dev, GPIO0, GPIO_OUT, 1);
+	msleep(10);
+
+	dib7000p_i2c_enumeration(&adap->dev->i2c_adap, 1, 18,
+		&stk7700ph_dib7700_xc3028_config);
+
+	adap->fe = dvb_attach(dib7000p_attach, &adap->dev->i2c_adap, 0x80,
+		&stk7700ph_dib7700_xc3028_config);
+
+	return adap->fe == NULL ? -ENODEV : 0;
+}
+
+static int stk7700ph_tuner_attach(struct dvb_usb_adapter *adap)
+{
+	struct i2c_adapter *tun_i2c;
+
+	tun_i2c = dib7000p_get_i2c_master(adap->fe,
+		DIBX000_I2C_INTERFACE_TUNER, 1);
+
+	stk7700ph_xc3028_config.i2c_adap = tun_i2c;
+	stk7700ph_xc3028_config.video_dev = adap;
+
+	return dvb_attach(xc2028_attach, adap->fe, &stk7700ph_xc3028_config)
+		== NULL ? -ENODEV : 0;
+}
+
 #define DEFAULT_RC_INTERVAL 150
 
 static u8 rc_request[] = { REQUEST_POLL_RC, 0 };
@@ -794,6 +938,10 @@ static struct dib7000p_config dib7070p_d
 /* STK7070P */
 static int stk7070p_frontend_attach(struct dvb_usb_adapter *adap)
 {
+	if (adap->dev->udev->descriptor.idVendor  == USB_VID_PINNACLE &&
+	adap->dev->udev->descriptor.idProduct == USB_PID_PINNACLE_PCTV72E)
+	dib0700_set_gpio(adap->dev, GPIO6, GPIO_OUT, 0);
+	else
 	dib0700_set_gpio(adap->dev, GPIO6, GPIO_OUT, 1);
 	msleep(10);
 	dib0700_set_gpio(adap->dev, GPIO9, GPIO_OUT, 1);
@@ -808,9 +956,11 @@ static int stk7070p_frontend_attach(stru
 	msleep(10);
 	dib0700_set_gpio(adap->dev, GPIO0, GPIO_OUT, 1);
 
-	dib7000p_i2c_enumeration(&adap->dev->i2c_adap, 1, 18, &dib7070p_dib7000p_config);
+	dib7000p_i2c_enumeration(&adap->dev->i2c_adap, 1, 18,
+		&dib7070p_dib7000p_config);
 
-	adap->fe = dvb_attach(dib7000p_attach, &adap->dev->i2c_adap, 0x80, &dib7070p_dib7000p_config);
+	adap->fe = dvb_attach(dib7000p_attach, &adap->dev->i2c_adap, 0x80,
+		&dib7070p_dib7000p_config);
 	return adap->fe == NULL ? -ENODEV : 0;
 }
 
@@ -878,34 +1028,41 @@ static int stk7070pd_frontend_attach1(st
 /* DVB-USB and USB stuff follows */
 struct usb_device_id dib0700_usb_id_table[] = {
 /* 0 */	{ USB_DEVICE(USB_VID_DIBCOM,    USB_PID_DIBCOM_STK7700P) },
-		{ USB_DEVICE(USB_VID_DIBCOM,    USB_PID_DIBCOM_STK7700P_PC) },
-
-		{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_NOVA_T_500) },
-		{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_NOVA_T_500_2) },
-		{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_NOVA_T_STICK) },
+	{ USB_DEVICE(USB_VID_DIBCOM,    USB_PID_DIBCOM_STK7700P_PC) },
+	{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_NOVA_T_500) },
+	{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_NOVA_T_500_2) },
+	{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_NOVA_T_STICK) },
 /* 5 */	{ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_VOLAR) },
-		{ USB_DEVICE(USB_VID_COMPRO,    USB_PID_COMPRO_VIDEOMATE_U500) },
-		{ USB_DEVICE(USB_VID_UNIWILL,   USB_PID_UNIWILL_STK7700P) },
-		{ USB_DEVICE(USB_VID_LEADTEK,   USB_PID_WINFAST_DTV_DONGLE_STK7700P) },
-		{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_NOVA_T_STICK_2) },
+	{ USB_DEVICE(USB_VID_COMPRO,    USB_PID_COMPRO_VIDEOMATE_U500) },
+	{ USB_DEVICE(USB_VID_UNIWILL,   USB_PID_UNIWILL_STK7700P) },
+	{ USB_DEVICE(USB_VID_LEADTEK,   USB_PID_WINFAST_DTV_DONGLE_STK7700P) },
+	{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_NOVA_T_STICK_2) },
 /* 10 */{ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_VOLAR_2) },
-		{ USB_DEVICE(USB_VID_PINNACLE,  USB_PID_PINNACLE_PCTV2000E) },
-		{ USB_DEVICE(USB_VID_TERRATEC,  USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY) },
-		{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_NOVA_TD_STICK) },
-		{ USB_DEVICE(USB_VID_DIBCOM,    USB_PID_DIBCOM_STK7700D) },
+	{ USB_DEVICE(USB_VID_PINNACLE,  USB_PID_PINNACLE_PCTV2000E) },
+	{ USB_DEVICE(USB_VID_TERRATEC,
+			USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY) },
+	{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_NOVA_TD_STICK) },
+	{ USB_DEVICE(USB_VID_DIBCOM,    USB_PID_DIBCOM_STK7700D) },
 /* 15 */{ USB_DEVICE(USB_VID_DIBCOM,    USB_PID_DIBCOM_STK7070P) },
-		{ USB_DEVICE(USB_VID_PINNACLE,  USB_PID_PINNACLE_PCTV_DVB_T_FLASH) },
-		{ USB_DEVICE(USB_VID_DIBCOM,    USB_PID_DIBCOM_STK7070PD) },
-		{ USB_DEVICE(USB_VID_PINNACLE,  USB_PID_PINNACLE_PCTV_DUAL_DIVERSITY_DVB_T) },
-		{ USB_DEVICE(USB_VID_COMPRO,    USB_PID_COMPRO_VIDEOMATE_U500_PC) },
+	{ USB_DEVICE(USB_VID_PINNACLE,  USB_PID_PINNACLE_PCTV_DVB_T_FLASH) },
+	{ USB_DEVICE(USB_VID_DIBCOM,    USB_PID_DIBCOM_STK7070PD) },
+	{ USB_DEVICE(USB_VID_PINNACLE,
+			USB_PID_PINNACLE_PCTV_DUAL_DIVERSITY_DVB_T) },
+	{ USB_DEVICE(USB_VID_COMPRO,    USB_PID_COMPRO_VIDEOMATE_U500_PC) },
 /* 20 */{ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_EXPRESS) },
-		{ USB_DEVICE(USB_VID_GIGABYTE,  USB_PID_GIGABYTE_U7000) },
-		{ USB_DEVICE(USB_VID_ULTIMA_ELECTRONIC, USB_PID_ARTEC_T14BR) },
-		{ USB_DEVICE(USB_VID_ASUS,      USB_PID_ASUS_U3000) },
-		{ USB_DEVICE(USB_VID_ASUS,      USB_PID_ASUS_U3100) },
-/* 25 */	{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_NOVA_T_STICK_3) },
-		{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_MYTV_T) },
-		{ 0 }		/* Terminating entry */
+	{ USB_DEVICE(USB_VID_GIGABYTE,  USB_PID_GIGABYTE_U7000) },
+	{ USB_DEVICE(USB_VID_ULTIMA_ELECTRONIC, USB_PID_ARTEC_T14BR) },
+	{ USB_DEVICE(USB_VID_ASUS,      USB_PID_ASUS_U3000) },
+	{ USB_DEVICE(USB_VID_ASUS,      USB_PID_ASUS_U3100) },
+/* 25 */{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_NOVA_T_STICK_3) },
+	{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_MYTV_T) },
+	{ USB_DEVICE(USB_VID_TERRATEC,  USB_PID_TERRATEC_CINERGY_HT_USB_XE) },
+	{ USB_DEVICE(USB_VID_PINNACLE,	USB_PID_PINNACLE_EXPRESSCARD_320CX) },
+	{ USB_DEVICE(USB_VID_PINNACLE,	USB_PID_PINNACLE_PCTV72E) },
+/* 30 */{ USB_DEVICE(USB_VID_PINNACLE,	USB_PID_PINNACLE_PCTV73E) },
+	{ USB_DEVICE(USB_VID_YUAN,	USB_PID_YUAN_EC372S) },
+	{ USB_DEVICE(USB_VID_TERRATEC,	USB_PID_TERRATEC_CINERGY_HT_EXPRESS) },
+	{ 0 }		/* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
 
@@ -1069,12 +1226,16 @@ struct dvb_usb_device_properties dib0700
 			},
 		},
 
-		.num_device_descs = 1,
+		.num_device_descs = 2,
 		.devices = {
 			{   "ASUS My Cinema U3000 Mini DVBT Tuner",
 				{ &dib0700_usb_id_table[23], NULL },
 				{ NULL },
 			},
+			{   "Yuan EC372S",
+				{ &dib0700_usb_id_table[31], NULL },
+				{ NULL },
+			}
 		}
 	}, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
 
@@ -1090,7 +1251,7 @@ struct dvb_usb_device_properties dib0700
 			},
 		},
 
-		.num_device_descs = 6,
+		.num_device_descs = 8,
 		.devices = {
 			{   "DiBcom STK7070P reference design",
 				{ &dib0700_usb_id_table[15], NULL },
@@ -1116,6 +1277,14 @@ struct dvb_usb_device_properties dib0700
 				{ &dib0700_usb_id_table[26], NULL },
 				{ NULL },
 			},
+			{   "Pinnacle PCTV 72e",
+				{ &dib0700_usb_id_table[29], NULL },
+				{ NULL },
+			},
+			{   "Pinnacle PCTV 73e",
+				{ &dib0700_usb_id_table[30], NULL },
+				{ NULL },
+			},
 		},
 
 		.rc_interval      = DEFAULT_RC_INTERVAL,
@@ -1155,6 +1324,40 @@ struct dvb_usb_device_properties dib0700
 				{ NULL },
 			}
 		}
+	}, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
+
+		.num_adapters = 1,
+		.adapter = {
+			{
+				.frontend_attach  = stk7700ph_frontend_attach,
+				.tuner_attach     = stk7700ph_tuner_attach,
+
+				DIB0700_DEFAULT_STREAMING_CONFIG(0x02),
+
+				.size_of_priv = sizeof(struct
+						dib0700_adapter_state),
+			},
+		},
+
+		.num_device_descs = 3,
+		.devices = {
+			{   "Terratec Cinergy HT USB XE",
+				{ &dib0700_usb_id_table[27], NULL },
+				{ NULL },
+			},
+			{   "Pinnacle Expresscard 320cx",
+				{ &dib0700_usb_id_table[28], NULL },
+				{ NULL },
+			},
+			{   "Terratec Cinergy HT Express",
+				{ &dib0700_usb_id_table[32], NULL },
+				{ NULL },
+			},
+		},
+		.rc_interval      = DEFAULT_RC_INTERVAL,
+		.rc_key_map       = dib0700_rc_keys,
+		.rc_key_map_size  = ARRAY_SIZE(dib0700_rc_keys),
+		.rc_query         = dib0700_rc_query
 	},
 };
 
drivers/media/dvb/dvb-usb/dvb-usb-ids.h +7 -2
@@ -46,8 +46,8 @@
 #define USB_VID_ULTIMA_ELECTRONIC		0x05d8
 #define USB_VID_UNIWILL				0x1584
 #define USB_VID_WIDEVIEW			0x14aa
-/* dom : pour gigabyte u7000 */
 #define USB_VID_GIGABYTE			0x1044
+#define USB_VID_YUAN				0x1164
 
 
 /* Product IDs */
@@ -135,9 +135,14 @@
 #define USB_PID_AVERMEDIA_VOLAR				0xa807
 #define USB_PID_AVERMEDIA_VOLAR_2			0xb808
 #define USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY	0x005a
+#define USB_PID_TERRATEC_CINERGY_HT_USB_XE		0x0058
+#define USB_PID_TERRATEC_CINERGY_HT_EXPRESS		0x0060
+#define USB_PID_PINNACLE_EXPRESSCARD_320CX		0x022e
 #define USB_PID_PINNACLE_PCTV2000E			0x022c
 #define USB_PID_PINNACLE_PCTV_DVB_T_FLASH		0x0228
 #define USB_PID_PINNACLE_PCTV_DUAL_DIVERSITY_DVB_T	0x0229
+#define USB_PID_PINNACLE_PCTV72E			0x0236
+#define USB_PID_PINNACLE_PCTV73E			0x0237
 #define USB_PID_PCTV_200E				0x020e
 #define USB_PID_PCTV_400E				0x020f
 #define USB_PID_PCTV_450E				0x0222
@@ -183,9 +188,9 @@
 #define USB_PID_OPERA1_WARM				0x3829
 #define USB_PID_LIFEVIEW_TV_WALKER_TWIN_COLD		0x0514
 #define USB_PID_LIFEVIEW_TV_WALKER_TWIN_WARM		0x0513
-/* dom pour gigabyte u7000 */
 #define USB_PID_GIGABYTE_U7000				0x7001
 #define USB_PID_ASUS_U3000				0x171f
 #define USB_PID_ASUS_U3100				0x173f
+#define  USB_PID_YUAN_EC372S				0x1edc
 
 #endif
#2 lore raw

Re: [patch 01/37] V4L/DVB (7473): PATCH for various Dibcom based devices

Quoted 26 lines · Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------

From: Albert Comerma <[email protected]>

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)

Quoted 4 lines

---

  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(-)

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

author
#3 lore raw

Re: [patch 01/37] V4L/DVB (7473): PATCH for various Dibcom based devices

Quoted 27 lines · Michael Krufky
Quoted 26 lines · Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------

From: Albert Comerma <[email protected]>

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)

Quoted 7 lines
Quoted 4 lines

---

  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(-)

This patch is entirely inappropriate for -stable

Why do you say that? It adds new device ids for devices to a driver, which is find for stable.

Quoted 1 line

Who sent this in?

I did.

Quoted 3 lines

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.

I think it does qualify and I've been asking for feedback about this for the past week to everyone on the signed-off-lines above with no real objections :)

openSUSE had a user that requested this patch be added as they had hardware that needed this patch to work properly on 2.6.25. As it only added device ids, I didn't see the problem with it.

Does it cause any problems that you can see?

thanks,

greg k-h

#4 lore raw

Re: [patch 01/37] V4L/DVB (7473): PATCH for various Dibcom based devices

Quoted 34 lines · Greg KH
Quoted 33 lines · Michael Krufky
Quoted 30 lines · Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------

From: Albert Comerma <[email protected]>

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)

---

  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(-)
Quoted 4 lines
Quoted 1 line

This patch is entirely inappropriate for -stable

Why do you say that? It adds new device ids for devices to a driver, which is find for stable.

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 -stable, in my opinion.

Quoted 8 lines
Quoted 3 lines

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.

I think it does qualify and I've been asking for feedback about this for the past week to everyone on the signed-off-lines above with no real objections :)

Quoted 5 lines

openSUSE had a user that requested this patch be added as they had hardware that needed this patch to work properly on 2.6.25. As it only added device ids, I didn't see the problem with it.

Does it cause any problems that you can see?

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

author
#5 lore raw

Re: [patch 01/37] V4L/DVB (7473): PATCH for various Dibcom based devices

Quoted 58 lines · Michael Krufky
Quoted 34 lines · Greg KH
Quoted 33 lines · Michael Krufky
Quoted 30 lines · Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------

From: Albert Comerma <[email protected]>

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)

---

  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(-)
Quoted 4 lines
Quoted 1 line

This patch is entirely inappropriate for -stable

Why do you say that? It adds new device ids for devices to a driver, which is find for stable.

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 -stable, in my opinion.

Quoted 12 lines
Quoted 3 lines

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.

I think it does qualify and I've been asking for feedback about this for the past week to everyone on the signed-off-lines above with no real objections :)

openSUSE had a user that requested this patch be added as they had hardware that needed this patch to work properly on 2.6.25. As it only added device ids, I didn't see the problem with it.

Quoted 7 lines
Quoted 1 line

Does it cause any problems that you can see?

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.

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

author
#6 lore raw

PATCH 2/37 vt: fix canonical input in UTF-8 mode

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Samuel Thibault <[email protected]>

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.

---
 drivers/char/vt.c |    6 ++++++
 1 file changed, 6 insertions(+)
drivers/char/vt.c +6 -0
@@ -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))
author
#7 lore raw

PATCH 3/37 serial: access after NULL check in uart_flush_buffer()

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Tetsuo Handa <[email protected]>

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.

---
 drivers/serial/serial_core.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/serial/serial_core.c +2 -1
@@ -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);
author
#8 lore raw

PATCH 4/37 OHCI: fix regression upon awakening from hibernation

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Alan Stern <[email protected]>

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.

---
 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(-)
drivers/usb/host/ohci-at91.c +1 -0
@@ -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
drivers/usb/host/ohci-ep93xx.c +1 -1
@@ -194,8 +194,8 @@ static int ohci_hcd_ep93xx_drv_resume(st
 
 	ep93xx_start_hc(&pdev->dev);
 	pdev->dev.power.power_state = PMSG_ON;
-	usb_hcd_resume_root_hub(hcd);
 
+	ohci_finish_controller_resume(hcd);
 	return 0;
 }
 #endif
drivers/usb/host/ohci-hub.c +43 -0

49 lines not on this page · raw message

drivers/usb/host/ohci-omap.c +1 -1
@@ -519,7 +519,7 @@ static int ohci_omap_resume(struct platf
 
 	omap_ohci_clock_power(1);
 	dev->dev.power.power_state = PMSG_ON;
-	usb_hcd_resume_root_hub(platform_get_drvdata(dev));
+	ohci_finish_controller_resume(hcd);
 	return 0;
 }
 
drivers/usb/host/ohci-pci.c +1 -42

56 lines not on this page · raw message

drivers/usb/host/ohci-pxa27x.c +1 -2
@@ -358,8 +358,7 @@ static int ohci_hcd_pxa27x_drv_resume(st
 		return status;
 
 	pdev->dev.power.power_state = PMSG_ON;
-	usb_hcd_resume_root_hub(hcd);
-
+	ohci_finish_controller_resume(hcd);
 	return 0;
 }
 #endif
drivers/usb/host/ohci-sm501.c +1 -1
@@ -239,7 +239,7 @@ static int ohci_sm501_resume(struct plat
 
 	sm501_unit_power(dev->parent, SM501_GATE_USB_HOST, 1);
 	dev->power.power_state = PMSG_ON;
-	usb_hcd_resume_root_hub(platform_get_drvdata(pdev));
+	ohci_finish_controller_resume(hcd);
 	return 0;
 }
 #endif
drivers/usb/host/ohci-ssb.c +1 -0
@@ -224,6 +224,7 @@ static int ssb_ohci_resume(struct ssb_de
 
 	ssb_device_enable(dev, ohcidev->enable_flags);
 
+	ohci_finish_controller_resume(hcd);
 	return 0;
 }
 
author
#9 lore raw

PATCH 5/37 XFRM: AUDIT: Fix flowlabel text format ambibuity.

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: YOSHIFUJI Hideaki <[email protected]>

[ 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.

---
 net/xfrm/xfrm_state.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/xfrm/xfrm_state.c +1 -1
@@ -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,
author
#10 lore raw

PATCH 6/37 sparc: sunzilog uart order

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Robert Reif <[email protected]>

[ 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)

---
 drivers/serial/sunzilog.c |   30 +++++++++++++++++-------------
 1 file changed, 17 insertions(+), 13 deletions(-)
drivers/serial/sunzilog.c +17 -13
@@ -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 *up;
 	struct zilog_layout __iomem *rp;
-	int keyboard_mouse;
+	int keyboard_mouse = 0;
 	int err;
 
-	keyboard_mouse = 0;
 	if (of_find_property(op->node, "keyboard", NULL))
 		keyboard_mouse = 1;
 
+	/* uarts must come before keyboards/mice */
+	if (keyboard_mouse)
+		inst = uart_chip_count + kbm_inst;
+	else
+		inst = uart_inst;
+
 	sunzilog_chip_regs[inst] = of_ioremap(&op->resource[0], 0,
 					      sizeof(struct zilog_layout),
 					      "zs");
@@ -1427,6 +1434,7 @@ static int __devinit zs_probe(struct of_
 				   rp, sizeof(struct zilog_layout));
 			return err;
 		}
+		uart_inst++;
 	} else {
 		printk(KERN_INFO "%s: Keyboard at MMIO 0x%llx (irq = %d) "
 		       "is a %s\n",
@@ -1438,12 +1446,11 @@ static int __devinit zs_probe(struct of_
 		       op->dev.bus_id,
 		       (unsigned long long) up[1].port.mapbase,
 		       op->irqs[0], sunzilog_type(&up[1].port));
+		kbm_inst++;
 	}
 
 	dev_set_drvdata(&op->dev, &up[0]);
 
-	inst++;
-
 	return 0;
 }
 
@@ -1491,28 +1498,25 @@ static struct of_platform_driver zs_driv
 static int __init sunzilog_init(void)
 {
 	struct device_node *dp;
-	int err, uart_count;
-	int num_keybms;
+	int err;
+	int num_keybms = 0;
 	int num_sunzilog = 0;
 
-	num_keybms = 0;
 	for_each_node_by_name(dp, "zs") {
 		num_sunzilog++;
 		if (of_find_property(dp, "keyboard", NULL))
 			num_keybms++;
 	}
 
-	uart_count = 0;
 	if (num_sunzilog) {
-		int uart_count;
-
 		err = sunzilog_alloc_tables(num_sunzilog);
 		if (err)
 			goto out;
 
-		uart_count = (num_sunzilog * 2) - (2 * num_keybms);
+		uart_chip_count = num_sunzilog - num_keybms;
 
-		err = sunserial_register_minors(&sunzilog_reg, uart_count);
+		err = sunserial_register_minors(&sunzilog_reg,
+						uart_chip_count * 2);
 		if (err)
 			goto out_free_tables;
 	}
author
#11 lore raw

PATCH 7/37 sparc: Fix SA_ONSTACK signal handling.

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: David S. Miller <[email protected]>

[ 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

---
 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(-)
arch/sparc64/kernel/signal32.c +17 -1
@@ -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 mindful of platform specific stack
+	 * alignment.  Second, if we took this signal because the stack
+	 * is not aligned properly, we'd like to take the signal cleanly
+	 * and report that.
+	 */
+	sp &= ~7UL;
+
 	return (void __user *)(sp - framesize);
 }
 
arch/sparc64/kernel/signal.c +17 -4
@@ -377,16 +377,29 @@ save_fpu_state(struct pt_regs *regs, __s
 
 static inline void __user *get_sigframe(struct k_sigaction *ka, struct pt_regs *regs, unsigned long framesize)
 {
-	unsigned long sp;
+	unsigned long sp = regs->u_regs[UREG_FP] + STACK_BIAS;
 
-	sp = regs->u_regs[UREG_FP] + STACK_BIAS;
+	/*
+	 * 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 (ka->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 mindful of platform specific stack
+	 * alignment.  Second, if we took this signal because the stack
+	 * is not aligned properly, we'd like to take the signal cleanly
+	 * and report that.
+	 */
+	sp &= ~7UL;
+
 	return (void __user *)(sp - framesize);
 }
 
arch/sparc/kernel/signal.c +17 -3
@@ -345,15 +345,29 @@ static inline int invalid_frame_pointer(
 
 static inline void __user *get_sigframe(struct sigaction *sa, struct pt_regs *regs, unsigned long framesize)
 {
-	unsigned long sp;
+	unsigned long sp = regs->u_regs[UREG_FP];
 
-	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 mindful of platform specific stack
+	 * alignment.  Second, if we took this signal because the stack
+	 * is not aligned properly, we'd like to take the signal cleanly
+	 * and report that.
+	 */
+	sp &= ~7UL;
+
 	return (void __user *)(sp - framesize);
 }
 
author
#12 lore raw

PATCH 8/37 sparc: Fix fork/clone/vfork system call restart.

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: David S. Miller <[email protected]>

[ 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.

---
 arch/sparc/kernel/process.c   |   20 ++++++++++++++++----
 arch/sparc64/kernel/process.c |   18 +++++++++++++++---
 2 files changed, 31 insertions(+), 7 deletions(-)
arch/sparc64/kernel/process.c +15 -3
@@ -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
arch/sparc/kernel/process.c +16 -4
@@ -421,14 +421,26 @@ asmlinkage int sparc_do_fork(unsigned lo
                              unsigned long stack_size)
 {
 	unsigned long parent_tid_ptr, child_tid_ptr;
+	unsigned long orig_i1 = regs->u_regs[UREG_I1];
+	long ret;
 
 	parent_tid_ptr = regs->u_regs[UREG_I2];
 	child_tid_ptr = regs->u_regs[UREG_I4];
 
-	return do_fork(clone_flags, stack_start,
-		       regs, stack_size,
-		       (int __user *) parent_tid_ptr,
-		       (int __user *) child_tid_ptr);
+	ret = do_fork(clone_flags, stack_start,
+		      regs, stack_size,
+		      (int __user *) parent_tid_ptr,
+		      (int __user *) 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
author
#13 lore raw

PATCH 9/37 sparc64: Stop creating dummy root PCI host controller devices.

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: David S. Miller <[email protected]>

[ 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
---
 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(-)
arch/sparc64/kernel/pci.c +33 -97
@@ -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 << 8;
-		sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
-			0x00, PCI_SLOT(devfn), PCI_FUNC(devfn));
-	} else {
-		dev->vendor = of_getintprop_default(node, "vendor-id", 0xffff);
-		dev->device = of_getintprop_default(node, "device-id", 0xffff);
-		dev->subsystem_vendor =
-			of_getintprop_default(node, "subsystem-vendor-id", 0);
-		dev->subsystem_device =
-			of_getintprop_default(node, "subsystem-id", 0);
-
-		dev->cfg_size = pci_cfg_space_size(dev);
-
-		/* We can't actually use the firmware value, we have
-		 * to read what is in the register right now.  One
-		 * reason is that in the case of IDE interfaces the
-		 * firmware can sample the value before the the IDE
-		 * interface is programmed into native mode.
-		 */
-		pci_read_config_dword(dev, PCI_CLASS_REVISION, &class);
-		dev->class = class >> 8;
-		dev->revision = class & 0xff;
+	dev->vendor = of_getintprop_default(node, "vendor-id", 0xffff);
+	dev->device = of_getintprop_default(node, "device-id", 0xffff);
+	dev->subsystem_vendor =
+		of_getintprop_default(node, "subsystem-vendor-id", 0);
+	dev->subsystem_device =
+		of_getintprop_default(node, "subsystem-id", 0);
+
+	dev->cfg_size = pci_cfg_space_size(dev);
+
+	/* We can't actually use the firmware value, we have
+	 * to read what is in the register right now.  One
+	 * reason is that in the case of IDE interfaces the
+	 * firmware can sample the value before the the IDE
+	 * interface is programmed into native mode.
+	 */
+	pci_read_config_dword(dev, PCI_CLASS_REVISION, &class);
+	dev->class = class >> 8;
+	dev->revision = class & 0xff;
+
+	sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
+		dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
 
-		sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
-			dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
-	}
 	if (ofpci_verbose)
 		printk("    class: 0x%x device name: %s\n",
 		       dev->class, pci_name(dev));
@@ -440,26 +424,21 @@ struct pci_dev *of_create_pci_dev(struct
 	dev->current_state = 4;		/* unknown power state */
 	dev->error_state = pci_channel_io_normal;
 
-	if (host_controller) {
+	if (!strcmp(type, "pci") || !strcmp(type, "pciex")) {
+		/* a PCI-PCI bridge */
 		dev->hdr_type = PCI_HEADER_TYPE_BRIDGE;
 		dev->rom_base_reg = PCI_ROM_ADDRESS1;
-		dev->irq = PCI_IRQ_NONE;
+	} else if (!strcmp(type, "cardbus")) {
+		dev->hdr_type = PCI_HEADER_TYPE_CARDBUS;
 	} else {
-		if (!strcmp(type, "pci") || !strcmp(type, "pciex")) {
-			/* a PCI-PCI bridge */
-			dev->hdr_type = PCI_HEADER_TYPE_BRIDGE;
-			dev->rom_base_reg = PCI_ROM_ADDRESS1;
-		} else if (!strcmp(type, "cardbus")) {
-			dev->hdr_type = PCI_HEADER_TYPE_CARDBUS;
-		} else {
-			dev->hdr_type = PCI_HEADER_TYPE_NORMAL;
-			dev->rom_base_reg = PCI_ROM_ADDRESS;
+		dev->hdr_type = PCI_HEADER_TYPE_NORMAL;
+		dev->rom_base_reg = PCI_ROM_ADDRESS;
 
-			dev->irq = sd->op->irqs[0];
-			if (dev->irq == 0xffffffff)
-				dev->irq = PCI_IRQ_NONE;
-		}
+		dev->irq = sd->op->irqs[0];
+		if (dev->irq == 0xffffffff)
+			dev->irq = PCI_IRQ_NONE;
 	}
+
 	pci_parse_of_addrs(sd->op, node, dev);
 
 	if (ofpci_verbose)
@@ -748,7 +727,7 @@ static void __devinit pci_of_scan_bus(st
 		prev_devfn = devfn;
 
 		/* create a new pci_dev for this device */
-		dev = of_create_pci_dev(pbm, child, bus, devfn, 0);
+		dev = of_create_pci_dev(pbm, child, bus, devfn);
 		if (!dev)
 			continue;
 		if (ofpci_verbose)
@@ -795,48 +774,9 @@ static void __devinit pci_bus_register_o
 		pci_bus_register_of_sysfs(child_bus);
 }
 
-int pci_host_bridge_read_pci_cfg(struct pci_bus *bus_dev,
-				 unsigned int devfn,
-				 int where, int size,
-				 u32 *value)
-{
-	static u8 fake_pci_config[] = {
-		0x8e, 0x10, /* Vendor: 0x108e (Sun) */
-		0xf0, 0x80, /* Device: 0x80f0 (Fire) */
-		0x46, 0x01, /* Command: 0x0146 (SERR, PARITY, MASTER, MEM) */
-		0xa0, 0x22, /* Status: 0x02a0 (DEVSEL_MED, FB2B, 66MHZ) */
-		0x00, 0x00, 0x00, 0x06, /* Class: 0x06000000 host bridge */
-		0x00, /* Cacheline: 0x00 */
-		0x40, /* Latency: 0x40 */
-		0x00, /* Header-Type: 0x00 normal */
-	};
-
-	*value = 0;
-	if (where >= 0 && where < sizeof(fake_pci_config) &&
-	    (where + size) >= 0 &&
-	    (where + size) < sizeof(fake_pci_config) &&
-	    size <= sizeof(u32)) {
-		while (size--) {
-			*value <<= 8;
-			*value |= fake_pci_config[where + size];
-		}
-	}
-
-	return PCIBIOS_SUCCESSFUL;
-}
-
-int pci_host_bridge_write_pci_cfg(struct pci_bus *bus_dev,
-				  unsigned int devfn,
-				  int where, int size,
-				  u32 value)
-{
-	return PCIBIOS_SUCCESSFUL;
-}
-
 struct pci_bus * __devinit pci_scan_one_pbm(struct pci_pbm_info *pbm)
 {
 	struct device_node *node = pbm->prom_node;
-	struct pci_dev *host_pdev;
 	struct pci_bus *bus;
 
 	printk("PCI: Scanning PBM %s\n", node->full_name);
@@ -854,10 +794,6 @@ struct pci_bus * __devinit pci_scan_one_
 	bus->resource[0] = &pbm->io_space;
 	bus->resource[1] = &pbm->mem_space;
 
-	/* Create the dummy host bridge and link it in.  */
-	host_pdev = of_create_pci_dev(pbm, node, bus, 0x00, 1);
-	bus->self = host_pdev;
-
 	pci_of_scan_bus(pbm, node, bus);
 	pci_bus_add_devices(bus);
 	pci_bus_register_of_sysfs(bus);
arch/sparc64/kernel/pci_common.c +0 -6
@@ -264,9 +264,6 @@ static int sun4v_read_pci_cfg(struct pci
 	unsigned int func = PCI_FUNC(devfn);
 	unsigned long ret;
 
-	if (!bus && devfn == 0x00)
-		return pci_host_bridge_read_pci_cfg(bus_dev, devfn, where,
-						    size, value);
 	if (config_out_of_range(pbm, bus, devfn, where)) {
 		ret = ~0UL;
 	} else {
@@ -300,9 +297,6 @@ static int sun4v_write_pci_cfg(struct pc
 	unsigned int func = PCI_FUNC(devfn);
 	unsigned long ret;
 
-	if (!bus && devfn == 0x00)
-		return pci_host_bridge_write_pci_cfg(bus_dev, devfn, where,
-						     size, value);
 	if (config_out_of_range(pbm, bus, devfn, where)) {
 		/* Do nothing. */
 	} else {
arch/sparc64/kernel/pci_impl.h +0 -9
@@ -167,15 +167,6 @@ extern void pci_get_pbm_props(struct pci
 extern struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm);
 extern void pci_determine_mem_io_space(struct pci_pbm_info *pbm);
 
-extern int pci_host_bridge_read_pci_cfg(struct pci_bus *bus_dev,
-					unsigned int devfn,
-					int where, int size,
-					u32 *value);
-extern int pci_host_bridge_write_pci_cfg(struct pci_bus *bus_dev,
-					 unsigned int devfn,
-					 int where, int size,
-					 u32 value);
-
 /* Error reporting support. */
 extern void pci_scan_for_target_abort(struct pci_pbm_info *, struct pci_bus *);
 extern void pci_scan_for_master_abort(struct pci_pbm_info *, struct pci_bus *);
author
#14 lore raw

PATCH 10/37 sparc64: Fix wedged irq regression.

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: David S. Miller <[email protected]>

[ 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.

---
 arch/sparc64/kernel/irq.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
arch/sparc64/kernel/irq.c +2 -1
@@ -1,6 +1,6 @@
 /* irq.c: UltraSparc IRQ handling/init/registry.
  *
- * Copyright (C) 1997, 2007  David S. Miller  ([email protected])
+ * Copyright (C) 1997, 2007, 2008 David S. Miller ([email protected])
  * Copyright (C) 1998  Eddie C. Dost    ([email protected])
  * Copyright (C) 1998  Jakub Jelinek    ([email protected])
  */
@@ -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);
 	}
 }
 
author
#15 lore raw

PATCH 11/37 SPARC64: Fix args to 64-bit sys_semctl() via sys_ipc().

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: David S. Miller <[email protected]>

[ Upstream commit: 020cfb05f2c594c778537159bd45ea5efb0c5e0d ]

Second and third arguments were swapped for whatever reason.

Reported by Tom Callaway.

---
 arch/sparc64/kernel/sys_sparc.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/sparc64/kernel/sys_sparc.c +2 -2
@@ -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;
 		}
author
#16 lore raw

PATCH 12/37 serial: Fix sparc driver name strings.

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: David S. Miller <[email protected]>

[ 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
---
 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(-)
drivers/serial/sunhv.c +1 -1
@@ -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,
 };
drivers/serial/sunsab.c +1 -1
@@ -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,
 };
drivers/serial/sunsu.c +1 -1
@@ -1173,7 +1173,7 @@ out:
 
 static struct uart_driver sunsu_reg = {
 	.owner			= THIS_MODULE,
-	.driver_name		= "serial",
+	.driver_name		= "sunsu",
 	.dev_name		= "ttyS",
 	.major			= TTY_MAJOR,
 };
drivers/serial/sunzilog.c +1 -1
@@ -1023,7 +1023,7 @@ static struct uart_sunzilog_port *sunzil
 
 static struct uart_driver sunzilog_reg = {
 	.owner		=	THIS_MODULE,
-	.driver_name	=	"ttyS",
+	.driver_name	=	"sunzilog",
 	.dev_name	=	"ttyS",
 	.major		=	TTY_MAJOR,
 };
author
#17 lore raw

PATCH 13/37 sch_htb: remove from event queue in htb_parent_to_leaf()

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Jarek Poplawski <[email protected]>

[ 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.

---
 net/sched/sch_htb.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
net/sched/sch_htb.c +6 -2
@@ -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);
author
#18 lore raw

PATCH 14/37 macvlan: Fix memleak on device removal/crash on module removal

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Patrick McHardy <[email protected]>

[ 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 <[email protected]>

---
 drivers/net/macvlan.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/macvlan.c +1 -1
@@ -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 = {
author
#19 lore raw

PATCH 15/37 ipvs: fix oops in backup for fwmark conn templates

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Julian Anastasov <[email protected]>

[ 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 <[email protected]>

---
 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(-)
include/net/ip_vs.h +2 -1
@@ -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 */
net/ipv4/ipvs/ip_vs_proto_ah.c +1 -0
@@ -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,
net/ipv4/ipvs/ip_vs_proto.c +1 -1
@@ -148,7 +148,7 @@ const char * ip_vs_state_name(__u16 prot
 	struct ip_vs_protocol *pp = ip_vs_proto_get(proto);
 
 	if (pp == NULL || pp->state_name == NULL)
-		return "ERR!";
+		return (IPPROTO_IP == proto) ? "NONE" : "ERR!";
 	return pp->state_name(state);
 }
 
net/ipv4/ipvs/ip_vs_proto_esp.c +1 -0
@@ -159,6 +159,7 @@ static void esp_exit(struct ip_vs_protoc
 struct ip_vs_protocol ip_vs_protocol_esp = {
 	.name =			"ESP",
 	.protocol =		IPPROTO_ESP,
+	.num_states =		1,
 	.dont_defrag =		1,
 	.init =			esp_init,
 	.exit =			esp_exit,
net/ipv4/ipvs/ip_vs_proto_tcp.c +1 -0
@@ -594,6 +594,7 @@ static void ip_vs_tcp_exit(struct ip_vs_
 struct ip_vs_protocol ip_vs_protocol_tcp = {
 	.name =			"TCP",
 	.protocol =		IPPROTO_TCP,
+	.num_states =		IP_VS_TCP_S_LAST,
 	.dont_defrag =		0,
 	.appcnt =		ATOMIC_INIT(0),
 	.init =			ip_vs_tcp_init,
net/ipv4/ipvs/ip_vs_proto_udp.c +1 -0
@@ -409,6 +409,7 @@ static void udp_exit(struct ip_vs_protoc
 struct ip_vs_protocol ip_vs_protocol_udp = {
 	.name =			"UDP",
 	.protocol =		IPPROTO_UDP,
+	.num_states =		IP_VS_UDP_S_LAST,
 	.dont_defrag =		0,
 	.init =			udp_init,
 	.exit =			udp_exit,
net/ipv4/ipvs/ip_vs_sync.c +59 -21

116 lines not on this page · raw message

author
#20 lore raw

PATCH 16/37 dccp: return -EINVAL on invalid feature length

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Chris Wright <[email protected]>

[ 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.

---
 net/dccp/feat.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/dccp/feat.c +1 -1
@@ -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 */
 
author
#21 lore raw

PATCH 17/37 can: Fix can_send() handling on dev_queue_xmit() failures

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Oliver Hartkopp <[email protected]>

[ 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 <[email protected]> for reporting this issue.

---
 net/can/af_can.c |   16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)
net/can/af_can.c +12 -4
@@ -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);
 
author
#22 lore raw

PATCH 18/37 x86: use defconfigs from x86/configs/*

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Sam Ravnborg <[email protected]>

commit b9b39bfba5b0de3418305f01cfa7bc55a16004e1 upstream

x86: use defconfigs from x86/configs/*

Daniel Drake <[email protected]> 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.

---
 arch/x86/Kconfig |   12 ++++++++++++
 1 file changed, 12 insertions(+)
arch/x86/Kconfig +12 -0
@@ -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
author
#23 lore raw

PATCH 19/37 nf_conntrack: padding breaks conntrack hash on ARM

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Philip Craig <[email protected]>

[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).

---
 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(-)
include/net/netfilter/nf_conntrack_tuple.h +0 -10
@@ -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)						     \
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c +1 -1
@@ -305,7 +305,7 @@ getorigdst(struct sock *sk, int optval, 
 	const struct nf_conntrack_tuple_hash *h;
 	struct nf_conntrack_tuple tuple;
 
-	NF_CT_TUPLE_U_BLANK(&tuple);
+	memset(&tuple, 0, sizeof(tuple));
 	tuple.src.u3.ip = inet->rcv_saddr;
 	tuple.src.u.tcp.port = inet->sport;
 	tuple.dst.u3.ip = inet->daddr;
net/netfilter/nf_conntrack_core.c +2 -2
@@ -104,7 +104,7 @@ nf_ct_get_tuple(const struct sk_buff *sk
 		const struct nf_conntrack_l3proto *l3proto,
 		const struct nf_conntrack_l4proto *l4proto)
 {
-	NF_CT_TUPLE_U_BLANK(tuple);
+	memset(tuple, 0, sizeof(*tuple));
 
 	tuple->src.l3num = l3num;
 	if (l3proto->pkt_to_tuple(skb, nhoff, tuple) == 0)
@@ -153,7 +153,7 @@ nf_ct_invert_tuple(struct nf_conntrack_t
 		   const struct nf_conntrack_l3proto *l3proto,
 		   const struct nf_conntrack_l4proto *l4proto)
 {
-	NF_CT_TUPLE_U_BLANK(inverse);
+	memset(inverse, 0, sizeof(*inverse));
 
 	inverse->src.l3num = orig->src.l3num;
 	if (l3proto->invert_tuple(inverse, orig) == 0)
author
#24 lore raw

PATCH 20/37 {nfnetlink, ip, ip6}_queue: fix skb_over_panic when enlarging packets

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Arnaud Ebalard <[email protected]>

[NETFILTER]: {nfnetlink,ip,ip6}_queue: fix skb_over_panic when enlarging packets

From: Arnaud Ebalard <[email protected]>

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>] ? pty_write+0x47/0x60
 [<c033d59b>] ? tty_default_put_char+0x1b/0x20
 [<c011d2e9>] ? __wake_up+0x49/0x70
 [<c033df99>] ? tty_ldisc_deref+0x39/0x90
 [<c033ff20>] ? tty_write+0x1a0/0x1b0
 [<c04c93af>] ? sys_socketcall+0x7f/0x260
 [<c0102ff9>] ? sysenter_past_esp+0x6a/0x91
 [<c05f0000>] ? snd_intel8x0m_probe+0x270/0x6e0
 =======================
Code: 00 00 89 5c 24 14 8b 98 9c 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 50 89 4c 24 04 c7 04 24 38 e6 71 c0 89 44 24 08 e8 c4 46 c5 ff <0f> 0b eb fe 55 89 e5 56 89 d6 53 89 c3 83 ec 0c 8b 40 50 39 d0
EIP: [<c04ccdfc>] skb_over_panic+0x5c/0x60 SS:ESP 0068:f6015bf8

Looking at the code, I ended up in nfq_mangle() function (called by nfqnl_recv_verdict()) which performs a call to skb_copy_expand() due to the increased size of data passed to the function. AFAICT, it should ask for 'diff' instead of 'diff - skb_tailroom(e->skb)'. Because the resulting sk_buff has not enough space to support the skb_put(skb, diff) call a few lines later, this results in the call to skb_over_panic().

The patch below asks for allocation of a copy with enough space for mangled packet and the same amount of headroom as old sk_buff. While looking at how the regression appeared (e2b58a67), I noticed the same pattern in ipq_mangle_ipv6() and ipq_mangle_ipv4(). The patch corrects those locations too.

Tested with bigger reinjected IPv6 packets (nfqnl_mangle() path), things are ok (2.6.25 and today's net-2.6 git tree).

---
 net/ipv4/netfilter/ip_queue.c   |    5 ++---
 net/ipv6/netfilter/ip6_queue.c  |    5 ++---
 net/netfilter/nfnetlink_queue.c |    5 ++---
 3 files changed, 6 insertions(+), 9 deletions(-)
net/ipv4/netfilter/ip_queue.c +2 -3
@@ -296,9 +296,8 @@ ipq_mangle_ipv4(ipq_verdict_msg_t *v, st
 		if (v->data_len > 0xFFFF)
 			return -EINVAL;
 		if (diff > skb_tailroom(e->skb)) {
-			nskb = skb_copy_expand(e->skb, 0,
-					       diff - skb_tailroom(e->skb),
-					       GFP_ATOMIC);
+			nskb = skb_copy_expand(e->skb, skb_headroom(e->skb),
+					       diff, GFP_ATOMIC);
 			if (!nskb) {
 				printk(KERN_WARNING "ip_queue: error "
 				      "in mangle, dropping packet\n");
net/ipv6/netfilter/ip6_queue.c +2 -3
@@ -298,9 +298,8 @@ ipq_mangle_ipv6(ipq_verdict_msg_t *v, st
 		if (v->data_len > 0xFFFF)
 			return -EINVAL;
 		if (diff > skb_tailroom(e->skb)) {
-			nskb = skb_copy_expand(e->skb, 0,
-					       diff - skb_tailroom(e->skb),
-					       GFP_ATOMIC);
+			nskb = skb_copy_expand(e->skb, skb_headroom(e->skb),
+					       diff, GFP_ATOMIC);
 			if (!nskb) {
 				printk(KERN_WARNING "ip6_queue: OOM "
 				      "in mangle, dropping packet\n");
net/netfilter/nfnetlink_queue.c +2 -3
@@ -454,9 +454,8 @@ nfqnl_mangle(void *data, int data_len, s
 		if (data_len > 0xFFFF)
 			return -EINVAL;
 		if (diff > skb_tailroom(e->skb)) {
-			nskb = skb_copy_expand(e->skb, 0,
-					       diff - skb_tailroom(e->skb),
-					       GFP_ATOMIC);
+			nskb = skb_copy_expand(e->skb, skb_headroom(e->skb),
+					       diff, GFP_ATOMIC);
 			if (!nskb) {
 				printk(KERN_WARNING "nf_queue: OOM "
 				      "in mangle, dropping packet\n");
#25 lore raw

Re: [patch 20/37] {nfnetlink, ip, ip6}_queue: fix skb_over_panic when enlarging packets

Hi,

Quoted 2 lines · Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

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 if it's probably too late for that poor guy :-( ).

Quoted 11 lines

------------------
From: Arnaud Ebalard <[email protected]>

[NETFILTER]: {nfnetlink,ip,ip6}_queue: fix skb_over_panic when enlarging packets

From: Arnaud Ebalard <[email protected]>

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)

                                            ^^^^^^
                                  i.e. read 2.6.24.x with x<4

Cheers,

a+

author
#26 lore raw

Re: [patch 20/37] {nfnetlink, ip, ip6}_queue: fix skb_over_panic when enlarging packets

Quoted 10 lines · Arnaud Ebalard

Hi,

Quoted 2 lines · Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

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 if it's probably too late for that poor guy :-( ).

Sorry, yes, we are no longer doing 2.6.24-stable releases.

thanks,

greg k-h

#27 lore raw

Re: [patch 20/37] {nfnetlink, ip, ip6}_queue: fix skb_over_panic when enlarging packets

Quoted 4 lines · Greg KH
Quoted 3 lines · Arnaud Ebalard

Hi,

Greg KH <[email protected]> writes:

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

2.6.25-stable review patch. If anyone has any objections, please let us know.

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 if it's probably too late for that poor guy :-( ).

Sorry, yes, we are no longer doing 2.6.24-stable releases.

the fix will be available in 2.6.25.4 ?

Signature · 3 lines
Gustavo Guillermo Pérez
Compunauta uLinux
www.compunauta.com
#28 lore raw

Re: [patch 20/37] {nfnetlink, ip, ip6}_queue: fix skb_over_panic when enlarging packets

Quoted 5 lines · Gustavo Guillermo Perez
Quoted 4 lines · Greg KH
Quoted 3 lines · Arnaud Ebalard

Hi,

Greg KH <[email protected]> writes:

Quoted 8 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines

2.6.25-stable review patch. If anyone has any objections, please let us know.

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 if it's probably too late for that poor guy :-( ).

Sorry, yes, we are no longer doing 2.6.24-stable releases.

the fix will be available in 2.6.25.4 ?

Yes. This is the patch against the latest 2.6.24.x release in case someone needs it. Not sure anymore if it differs from the 2.6.25 version.

commit 431e3757dbafdad741ef7d9bdaa2fca7fce3d5cc

Author: Arnaud Ebalard <[email protected]>
Date:   Tue May 6 13:03:59 2008 +0200
    [NETFILTER]: {nfnetlink,ip,ip6}_queue: fix skb_over_panic when enlarging packets
    
    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>] ? pty_write+0x47/0x60
     [<c033d59b>] ? tty_default_put_char+0x1b/0x20
     [<c011d2e9>] ? __wake_up+0x49/0x70
     [<c033df99>] ? tty_ldisc_deref+0x39/0x90
     [<c033ff20>] ? tty_write+0x1a0/0x1b0
     [<c04c93af>] ? sys_socketcall+0x7f/0x260
     [<c0102ff9>] ? sysenter_past_esp+0x6a/0x91
     [<c05f0000>] ? snd_intel8x0m_probe+0x270/0x6e0
     =======================
    Code: 00 00 89 5c 24 14 8b 98 9c 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 50 89 4c 24 04 c7 04 24 38 e6 71 c0 89 44 24 08 e8 c4 46 c5 ff <0f> 0b eb fe 55 89 e5 56 89 d6 53 89 c3 83 ec 0c 8b 40 50 39 d0
    EIP: [<c04ccdfc>] skb_over_panic+0x5c/0x60 SS:ESP 0068:f6015bf8
    
    
    Looking at the code, I ended up in nfq_mangle() function (called by
    nfqnl_recv_verdict()) which performs a call to skb_copy_expand() due to
    the increased size of data passed to the function. AFAICT, it should ask
    for 'diff' instead of 'diff - skb_tailroom(e->skb)'. Because the
    resulting sk_buff has not enough space to support the skb_put(skb, diff)
    call a few lines later, this results in the call to skb_over_panic().
    
    The patch below asks for allocation of a copy with enough space for
    mangled packet and the same amount of headroom as old sk_buff. While
    looking at how the regression appeared (e2b58a67), I noticed the same
    pattern in ipq_mangle_ipv6() and ipq_mangle_ipv4(). The patch corrects
    those locations too.
    
    Tested with bigger reinjected IPv6 packets (nfqnl_mangle() path), things
    are ok (2.6.25 and today's net-2.6 git tree).
    
    Signed-off-by: Arnaud Ebalard <[email protected]>
    Signed-off-by: Patrick McHardy <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
net/ipv4/netfilter/ip_queue.c +2 -3
index 16d0fb3..f821a9b 100644
@@ -349,9 +349,8 @@ ipq_mangle_ipv4(ipq_verdict_msg_t *v, struct ipq_queue_entry *e)
 		if (v->data_len > 0xFFFF)
 			return -EINVAL;
 		if (diff > skb_tailroom(e->skb)) {
-			nskb = skb_copy_expand(e->skb, 0,
-					       diff - skb_tailroom(e->skb),
-					       GFP_ATOMIC);
+			nskb = skb_copy_expand(e->skb, skb_headroom(e->skb),
+					       diff, GFP_ATOMIC);
 			if (!nskb) {
 				printk(KERN_WARNING "ip_queue: error "
 				      "in mangle, dropping packet\n");
net/ipv6/netfilter/ip6_queue.c +2 -3
index 710a04f..b9db6d9 100644
@@ -346,9 +346,8 @@ ipq_mangle_ipv6(ipq_verdict_msg_t *v, struct ipq_queue_entry *e)
 		if (v->data_len > 0xFFFF)
 			return -EINVAL;
 		if (diff > skb_tailroom(e->skb)) {
-			nskb = skb_copy_expand(e->skb, 0,
-					       diff - skb_tailroom(e->skb),
-					       GFP_ATOMIC);
+			nskb = skb_copy_expand(e->skb, skb_headroom(e->skb),
+					       diff, GFP_ATOMIC);
 			if (!nskb) {
 				printk(KERN_WARNING "ip6_queue: OOM "
 				      "in mangle, dropping packet\n");
net/netfilter/nfnetlink_queue.c +2 -3
index 7c3646c..d5fab38 100644
@@ -627,9 +627,8 @@ nfqnl_mangle(void *data, int data_len, struct nfqnl_queue_entry *e)
 		if (data_len > 0xFFFF)
 			return -EINVAL;
 		if (diff > skb_tailroom(e->skb)) {
-			nskb = skb_copy_expand(e->skb, 0,
-					       diff - skb_tailroom(e->skb),
-					       GFP_ATOMIC);
+			nskb = skb_copy_expand(e->skb, skb_headroom(e->skb),
+					       diff, GFP_ATOMIC);
 			if (!nskb) {
 				printk(KERN_WARNING "nf_queue: OOM "
 				      "in mangle, dropping packet\n");
author
#29 lore raw

PATCH 21/37 ata_piix: verify SIDPR access before enabling it

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Tejun Heo <[email protected]>

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.

---
 drivers/ata/ata_piix.c |   25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)
drivers/ata/ata_piix.c +25 -0
@@ -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 = &piix_sidpr_sata_ops;
 	host->ports[1]->ops = &piix_sidpr_sata_ops;
 }
author
#30 lore raw

PATCH 22/37 x86: sysfs cpu?/topology is empty in 2.6.25 (32-bit Intel system)

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Vaidyanathan Srinivasan <[email protected]>

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.

---
 include/asm-x86/topology.h |   18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)
include/asm-x86/topology.h +10 -8
@@ -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 ENABLE_TOPO_DEFINES
-# endif
-
 # define SD_CACHE_NICE_TRIES	1
 # define SD_IDLE_IDX		1
 # define SD_NEWIDLE_IDX		2
@@ -123,10 +129,6 @@ extern unsigned long node_remap_size[];
 
 #else
 
-# ifdef CONFIG_SMP
-#  define ENABLE_TOPO_DEFINES
-# endif
-
 # define SD_CACHE_NICE_TRIES	2
 # define SD_IDLE_IDX		2
 # define SD_NEWIDLE_IDX		0
Tested-by on v1 22/37
#31 lore raw

Re: [patch 22/37] x86: sysfs cpu?/topology is empty in 2.6.25 (32-bit Intel system)

Quoted 2 lines · Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

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

author
#32 lore raw

Re: [patch 22/37] x86: sysfs cpu?/topology is empty in 2.6.25 (32-bit Intel system)

Quoted 7 lines · Vaidyanathan Srinivasan
Quoted 2 lines · Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

Hi Greg,

Quoted 7 lines

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

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

author
#33 lore raw

PATCH 23/37 i2c-piix4: Blacklist two mainboards

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Jean Delvare <[email protected]>

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.

---
 drivers/i2c/busses/i2c-piix4.c |   32 ++++++++++++++++++++++++++++++--
 1 file changed, 30 insertions(+), 2 deletions(-)
drivers/i2c/busses/i2c-piix4.c +30 -2
@@ -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)) {
+		dev_err(&PIIX4_dev->dev,
+			"Accessing the SMBus on this system is unsafe!\n");
+		return -EPERM;
+	}
+
 	/* Don't access SMBus on IBM systems which get corrupted eeproms */
-	if (dmi_check_system(piix4_dmi_table) &&
+	if (dmi_check_system(piix4_dmi_ibm) &&
 			PIIX4_dev->vendor == PCI_VENDOR_ID_INTEL) {
 		dev_err(&PIIX4_dev->dev, "IBM system detected; this module "
 			"may corrupt your serial eeprom! Refusing to load "
#34 lore raw

Hardware designt to prevent Damages... [WAS: [patch 23/37] i2c-piix4: Blacklist two mainboards]

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:

Am 2008-05-13 13:12:25, schrieb Greg KH:

Quoted 5 lines

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.

------------------------ 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

Signature · 5 lines
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)
#35 lore raw

Re: Hardware designt to prevent Damages... [WAS: [patch 23/37] i2c-piix4: Blacklist two mainboards]

Quoted 7 lines · Michelle Konzack

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:

Quoted 8 lines

Am 2008-05-13 13:12:25, schrieb Greg KH:

Quoted 5 lines

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.

------------------------ END OF REPLIED MESSAGE ------------------------

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 [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

#36 lore raw

Re: Hardware designt to prevent Damages... [WAS: [patch 23/37] i2c-piix4: Blacklist two mainboards]

Hello Dick,

Thank you for the answer...

Even if I use several times an I2C current Sink/Source converter from 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

Am 2008-05-15 13:57:35, schrieb linux-os (Dick Johnson):

Quoted 21 lines

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.

Quoted 4 lines

Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/

------------------------ END OF REPLIED MESSAGE ------------------------

Signature · 5 lines
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)
#37 lore raw

Re: Hardware designt to prevent Damages... [WAS: [patch 23/37] i2c-piix4: Blacklist two mainboards]

In reply to Michelle Konzack
Quoted 8 lines · Michelle Konzack

Am 2008-05-13 13:12:25, schrieb Greg KH:

Quoted 5 lines

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.

------------------------ END OF REPLIED MESSAGE ------------------------

Quoted 7 lines

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...

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.

Signature · 1 line
Jean Delvare
#38 lore raw

Re: Hardware designt to prevent Damages... [WAS: [patch 23/37] i2c-piix4: Blacklist two mainboards]

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

Am 2008-05-15 20:49:55, schrieb Jean Delvare:

Quoted 10 lines

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.

Quoted 11 lines

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.

------------------------ END OF REPLIED MESSAGE ------------------------

Signature · 5 lines
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)
author
#39 lore raw

PATCH 24/37 sparc: Fix ptrace() detach.

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: David S. Miller <[email protected]>

[ 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.

---
 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(+)
arch/sparc64/kernel/ptrace.c +4 -0
@@ -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;
 	}
arch/sparc/kernel/ptrace.c +2 -0
@@ -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;
 	}
include/asm-sparc64/ptrace.h +1 -0
@@ -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            13
 #define PTRACE_GETFPREGS          14
include/asm-sparc/ptrace.h +1 -0
@@ -149,6 +149,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            13
 #define PTRACE_GETFPREGS          14
author
#40 lore raw

PATCH 25/37 sparc: Fix mremap address range validation.

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: David S. Miller <[email protected]>

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 <[email protected]>

---
 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(-)
arch/sparc64/kernel/sys_sparc32.c +2 -31
@@ -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 : 0,
-				    map_flags);
-		ret = new_addr;
-		if (new_addr & ~PAGE_MASK)
-			goto out_sem;
-		flags |= MREMAP_FIXED;
-	}
 	ret = do_mremap(addr, old_len, new_len, flags, new_addr);
-out_sem:
 	up_write(&current->mm->mmap_sem);
 out:
 	return ret;       
arch/sparc64/kernel/sys_sparc.c +4 -32
@@ -542,8 +542,7 @@ asmlinkage long sparc64_personality(unsi
 	return ret;
 }
 
-int sparc64_mmap_check(unsigned long addr, unsigned long len,
-		unsigned long flags)
+int sparc64_mmap_check(unsigned long addr, unsigned long len)
 {
 	if (test_thread_flag(TIF_32BIT)) {
 		if (len >= STACK_TOP32)
@@ -609,46 +608,19 @@ asmlinkage unsigned long sys64_mremap(un
 	unsigned long old_len, unsigned long new_len,
 	unsigned long flags, unsigned long new_addr)
 {
-	struct vm_area_struct *vma;
 	unsigned long ret = -EINVAL;
 
 	if (test_thread_flag(TIF_32BIT))
 		goto out;
 	if (unlikely(new_len >= VA_EXCLUDE_START))
 		goto out;
-	if (unlikely(invalid_64bit_range(addr, old_len)))
+	if (unlikely(sparc64_mmap_check(addr, old_len)))
+		goto out;
+	if (unlikely(sparc64_mmap_check(new_addr, new_len)))
 		goto out;
 
 	down_write(&current->mm->mmap_sem);
-	if (flags & MREMAP_FIXED) {
-		if (invalid_64bit_range(new_addr, new_len))
-			goto out_sem;
-	} else if (invalid_64bit_range(addr, 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 : 0,
-				    map_flags);
-		ret = new_addr;
-		if (new_addr & ~PAGE_MASK)
-			goto out_sem;
-		flags |= MREMAP_FIXED;
-	}
 	ret = do_mremap(addr, old_len, new_len, flags, new_addr);
-out_sem:
 	up_write(&current->mm->mmap_sem);
 out:
 	return ret;       
arch/sparc/kernel/sys_sparc.c +5 -43

64 lines not on this page · raw message

include/asm-sparc64/mman.h +2 -3
@@ -37,9 +37,8 @@
 
 #ifdef __KERNEL__
 #ifndef __ASSEMBLY__
-#define arch_mmap_check	sparc64_mmap_check
-int sparc64_mmap_check(unsigned long addr, unsigned long len,
-		unsigned long flags);
+#define arch_mmap_check(addr,len,flags)	sparc64_mmap_check(addr,len)
+int sparc64_mmap_check(unsigned long addr, unsigned long len);
 #endif
 #endif
 
include/asm-sparc/mman.h +2 -3
@@ -37,9 +37,8 @@
 
 #ifdef __KERNEL__
 #ifndef __ASSEMBLY__
-#define arch_mmap_check	sparc_mmap_check
-int sparc_mmap_check(unsigned long addr, unsigned long len,
-		unsigned long flags);
+#define arch_mmap_check(addr,len,flags)	sparc_mmap_check(addr,len)
+int sparc_mmap_check(unsigned long addr, unsigned long len);
 #endif
 #endif
 
#41 lore raw

Re: [patch 25/37] sparc: Fix mremap address range validation.

Quoted 5 lines · Greg KH

From: David S. Miller <[email protected]>

Just like mmap, we need to validate address ranges regardless of MAP_FIXED.

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

author
#42 lore raw

Re: [patch 25/37] sparc: Fix mremap address range validation.

Quoted 11 lines · Linus Torvalds
Quoted 5 lines · Greg KH

From: David S. Miller <[email protected]>

Just like mmap, we need to validate address ranges regardless of MAP_FIXED.

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.

Odd, I missed that. David, did you just forget to send this one?

thanks,

greg k-h

maintainer
#43 lore raw

Re: [patch 25/37] sparc: Fix mremap address range validation.

From: Greg KH <[email protected]>
Date: Tue, 13 May 2008 13:37:05 -0700

Quoted 7 lines · Linus Torvalds
Quoted 6 lines · Greg KH
Quoted 3 lines

From: David S. Miller <[email protected]>

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

Just like mmap, we need to validate address ranges regardless of MAP_FIXED.

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.

Odd, I missed that. David, did you just forget to send this one?

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.

maintainer
#44 lore raw

Re: [patch 25/37] sparc: Fix mremap address range validation.

In reply to Linus Torvalds

From: Linus Torvalds <[email protected]>
Date: Tue, 13 May 2008 13:28:32 -0700 (PDT)

Quoted 9 lines · Greg KH
Quoted 5 lines

From: David S. Miller <[email protected]>

Just like mmap, we need to validate address ranges regardless of MAP_FIXED.

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.

It's pending, sorry I just didn't push it to you yet.

author
#45 lore raw

PATCH 26/37 sparc: Fix debugger syscall restart interactions.

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: David S. Miller <[email protected]>

[ 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 before doing a syscall restart. We have to do a final recheck right after get_signal_to_deliver() in case the debugger cleared the bit during ptrace_stop().

3) Clear the bit in trap return so we don't accidently try to set that bit in the real register.

As a result we also get a ptrace_{is,clear}_syscall() for sparc32 just like sparc64 has.

M68K has this same exact bug, and is now the only other user of the ptrace_signal_deliver hook. It needs to be fixed in the same exact way as sparc.

---
 arch/sparc/kernel/entry.S       |    2 +
 arch/sparc/kernel/ptrace.c      |    4 +-
 arch/sparc/kernel/rtrap.S       |   11 ++++--
 arch/sparc/kernel/signal.c      |   64 ++++++++++++++++---------------------
 arch/sparc64/kernel/etrap.S     |    7 ++--
 arch/sparc64/kernel/ptrace.c    |   12 ++++--
 arch/sparc64/kernel/rtrap.S     |    1 
 arch/sparc64/kernel/signal.c    |   69 +++++++++++++++++-----------------------
 arch/sparc64/kernel/signal32.c  |   30 +++++++++++------
 include/asm-sparc/psr.h         |    1 
 include/asm-sparc/ptrace.h      |   12 ++++++
 include/asm-sparc/signal.h      |    8 ----
 include/asm-sparc64/psrcompat.h |    2 +
 include/asm-sparc64/pstate.h    |    1 
 include/asm-sparc64/ptrace.h    |   12 ++++++
 include/asm-sparc64/signal.h    |    8 ----
 include/asm-sparc64/ttable.h    |    7 ++--
 17 files changed, 136 insertions(+), 115 deletions(-)
arch/sparc64/kernel/etrap.S +4 -3
@@ -27,11 +27,12 @@
 
 		.text		
 		.align	64
-		.globl	etrap, etrap_irq, etraptl1
+		.globl	etrap_syscall, etrap, etrap_irq, etraptl1
 etrap:		rdpr	%pil, %g2
-etrap_irq:
-		TRAP_LOAD_THREAD_REG(%g6, %g1)
+etrap_irq:	clr	%g3
+etrap_syscall:	TRAP_LOAD_THREAD_REG(%g6, %g1)
 		rdpr	%tstate, %g1
+		or	%g1, %g3, %g1
 		sllx	%g2, 20, %g3
 		andcc	%g1, TSTATE_PRIV, %g0
 		or	%g1, %g3, %g1
arch/sparc64/kernel/ptrace.c +7 -5
@@ -287,11 +287,11 @@ static int genregs64_set(struct task_str
 					 32 * sizeof(u64),
 					 33 * sizeof(u64));
 		if (!ret) {
-			/* Only the condition codes can be modified
-			 * in the %tstate register.
+			/* Only the condition codes and the "in syscall"
+			 * state can be modified in the %tstate register.
 			 */
-			tstate &= (TSTATE_ICC | TSTATE_XCC);
-			regs->tstate &= ~(TSTATE_ICC | TSTATE_XCC);
+			tstate &= (TSTATE_ICC | TSTATE_XCC | TSTATE_SYSCALL);
+			regs->tstate &= ~(TSTATE_ICC | TSTATE_XCC | TSTATE_SYSCALL);
 			regs->tstate |= tstate;
 		}
 	}
@@ -657,8 +657,10 @@ static int genregs32_set(struct task_str
 		switch (pos) {
 		case 32: /* PSR */
 			tstate = regs->tstate;
-			tstate &= ~(TSTATE_ICC | TSTATE_XCC);
+			tstate &= ~(TSTATE_ICC | TSTATE_XCC | TSTATE_SYSCALL);
 			tstate |= psr_to_tstate_icc(reg);
+			if (reg & PSR_SYSCALL)
+				tstate |= TSTATE_SYSCALL;
 			regs->tstate = tstate;
 			break;
 		case 33: /* PC */
arch/sparc64/kernel/rtrap.S +1 -0
@@ -270,6 +270,7 @@ rt_continue:	ldx			[%sp + PTREGS_OFF + P
 		wr			%o3, %g0, %y
 		wrpr			%l4, 0x0, %pil
 		wrpr			%g0, 0x1, %tl
+		andn			%l1, TSTATE_SYSCALL, %l1
 		wrpr			%l1, %g0, %tstate
 		wrpr			%l2, %g0, %tpc
 		wrpr			%o2, %g0, %tnpc
arch/sparc64/kernel/signal32.c +20 -10
@@ -295,6 +295,9 @@ void do_new_sigreturn32(struct pt_regs *
 	regs->tstate &= ~(TSTATE_ICC|TSTATE_XCC);
 	regs->tstate |= psr_to_tstate_icc(psr);
 
+ 	/* Prevent syscall restart.  */
+ 	pt_regs_clear_syscall(regs);
+
 	err |= __get_user(fpu_save, &sf->fpu_save);
 	if (fpu_save)
 		err |= restore_fpu_state32(regs, &sf->fpu_state);
@@ -448,6 +451,9 @@ asmlinkage void do_rt_sigreturn32(struct
 	regs->tstate &= ~(TSTATE_ICC|TSTATE_XCC);
 	regs->tstate |= psr_to_tstate_icc(psr);
 
+ 	/* Prevent syscall restart.  */
+ 	pt_regs_clear_syscall(regs);
+
 	err |= __get_user(fpu_save, &sf->fpu_save);
 	if (fpu_save)
 		err |= restore_fpu_state32(regs, &sf->fpu_state);
@@ -1280,20 +1286,24 @@ static inline void syscall_restart32(uns
  * mistake.
  */
 void do_signal32(sigset_t *oldset, struct pt_regs * regs,
-		 unsigned long orig_i0, int restart_syscall)
+		 int restart_syscall, unsigned long orig_i0)
 {
-	siginfo_t info;
-	struct signal_deliver_cookie cookie;
 	struct k_sigaction ka;
+	siginfo_t info;
 	int signr;
 	int svr4_signal = current->personality == PER_SVR4;
 	
-	cookie.restart_syscall = restart_syscall;
-	cookie.orig_i0 = orig_i0;
+	signr = get_signal_to_deliver(&info, &ka, regs, NULL);
+
+	/* If the debugger messes with the program counter, it clears
+	 * the "in syscall" bit, directing us to not perform a syscall
+	 * restart.
+	 */
+	if (restart_syscall && !pt_regs_is_syscall(regs))
+		restart_syscall = 0;
 
-	signr = get_signal_to_deliver(&info, &ka, regs, &cookie);
 	if (signr > 0) {
-		if (cookie.restart_syscall)
+		if (restart_syscall)
 			syscall_restart32(orig_i0, regs, &ka.sa);
 		handle_signal32(signr, &ka, &info, oldset,
 				regs, svr4_signal);
@@ -1307,16 +1317,16 @@ void do_signal32(sigset_t *oldset, struc
 			clear_thread_flag(TIF_RESTORE_SIGMASK);
 		return;
 	}
-	if (cookie.restart_syscall &&
+	if (restart_syscall &&
 	    (regs->u_regs[UREG_I0] == ERESTARTNOHAND ||
 	     regs->u_regs[UREG_I0] == ERESTARTSYS ||
 	     regs->u_regs[UREG_I0] == ERESTARTNOINTR)) {
 		/* replay the system call when we are done */
-		regs->u_regs[UREG_I0] = cookie.orig_i0;
+		regs->u_regs[UREG_I0] = orig_i0;
 		regs->tpc -= 4;
 		regs->tnpc -= 4;
 	}
-	if (cookie.restart_syscall &&
+	if (restart_syscall &&
 	    regs->u_regs[UREG_I0] == ERESTART_RESTARTBLOCK) {
 		regs->u_regs[UREG_G1] = __NR_restart_syscall;
 		regs->tpc -= 4;
arch/sparc64/kernel/signal.c +30 -39

118 lines not on this page · raw message

arch/sparc/kernel/entry.S +2 -0
@@ -1398,6 +1398,8 @@ ret_from_fork:
 	.align	4
 	.globl	linux_sparc_syscall
 linux_sparc_syscall:
+	sethi	%hi(PSR_SYSCALL), %l4
+	or	%l0, %l4, %l0
 	/* Direct access to user regs, must faster. */
 	cmp	%g1, NR_SYSCALLS
 	bgeu	linux_sparc_ni_syscall
arch/sparc/kernel/ptrace.c +2 -2
@@ -170,8 +170,8 @@ static int genregs32_set(struct task_str
 		switch (pos) {
 		case 32: /* PSR */
 			psr = regs->psr;
-			psr &= ~PSR_ICC;
-			psr |= (reg & PSR_ICC);
+			psr &= ~(PSR_ICC | PSR_SYSCALL);
+			psr |= (reg & (PSR_ICC | PSR_SYSCALL));
 			regs->psr = psr;
 			break;
 		case 33: /* PC */
arch/sparc/kernel/rtrap.S +8 -3
@@ -50,8 +50,9 @@ rtrap_7win_patch5:	and	%g1, 0x7f, %g1
 ret_trap_entry:
 ret_trap_lockless_ipi:
 	andcc	%t_psr, PSR_PS, %g0
+	sethi	%hi(PSR_SYSCALL), %g1
 	be	1f
-	 nop
+	 andn	%t_psr, %g1, %t_psr
 
 	wr	%t_psr, 0x0, %psr
 	b	ret_trap_kernel
@@ -73,7 +74,6 @@ signal_p:
 	 ld	[%sp + STACKFRAME_SZ + PT_PSR], %t_psr
 
 	mov	%l5, %o1
-	mov	%l6, %o2
 	call	do_signal
 	 add	%sp, STACKFRAME_SZ, %o0	! pt_regs ptr
 
@@ -81,6 +81,8 @@ signal_p:
 	ld	[%sp + STACKFRAME_SZ + PT_PSR], %t_psr
 	clr	%l6
 ret_trap_continue:
+	sethi	%hi(PSR_SYSCALL), %g1
+	andn	%t_psr, %g1, %t_psr
 	wr	%t_psr, 0x0, %psr
 	WRITE_PAUSE
 
@@ -137,8 +139,9 @@ ret_trap_userwins_ok:
 	LOAD_PT_PRIV(sp, t_psr, t_pc, t_npc)
 	or	%t_pc, %t_npc, %g2
 	andcc	%g2, 0x3, %g0
+	sethi	%hi(PSR_SYSCALL), %g2
 	be	1f
-	 nop
+	 andn	%t_psr, %g2, %t_psr
 
 	b	ret_trap_unaligned_pc
 	 add	%sp, STACKFRAME_SZ, %o0
@@ -201,6 +204,8 @@ rtrap_patch5:	and	%g1, 0xff, %g1
 1:
 	LOAD_PT_ALL(sp, t_psr, t_pc, t_npc, g1)
 2:
+	sethi	%hi(PSR_SYSCALL), %twin_tmp1
+	andn	%t_psr, %twin_tmp1, %t_psr
 	wr	%t_psr, 0x0, %psr
 	WRITE_PAUSE
 
arch/sparc/kernel/signal.c +28 -36

114 lines not on this page · raw message

include/asm-sparc64/psrcompat.h +2 -0
@@ -12,6 +12,7 @@
 #define PSR_PIL     0x00000f00         /* processor interrupt level  */
 #define PSR_EF      0x00001000         /* enable floating point      */
 #define PSR_EC      0x00002000         /* enable co-processor        */
+#define PSR_SYSCALL 0x00004000         /* inside of a syscall        */
 #define PSR_LE      0x00008000         /* SuperSparcII little-endian */
 #define PSR_ICC     0x00f00000         /* integer condition codes    */
 #define PSR_C       0x00100000         /* carry bit                  */
@@ -30,6 +31,7 @@ static inline unsigned int tstate_to_psr
 		PSR_S					|
 		((tstate & TSTATE_ICC) >> 12)		|
 		((tstate & TSTATE_XCC) >> 20)		|
+		((tstate & TSTATE_SYSCALL) ? PSR_SYSCALL : 0) |
 		PSR_V8PLUS);
 }
 
include/asm-sparc64/pstate.h +1 -0
@@ -62,6 +62,7 @@
 #define TSTATE_PRIV	_AC(0x0000000000000400,UL) /* Privilege.	*/
 #define TSTATE_IE	_AC(0x0000000000000200,UL) /* Interrupt Enable.	*/
 #define TSTATE_AG	_AC(0x0000000000000100,UL) /* Alternate Globals.*/
+#define TSTATE_SYSCALL	_AC(0x0000000000000020,UL) /* in syscall trap   */
 #define TSTATE_CWP	_AC(0x000000000000001f,UL) /* Curr Win-Pointer.	*/
 
 /* Floating-Point Registers State Register.
include/asm-sparc64/ptrace.h +12 -0
@@ -10,6 +10,8 @@
 
 #ifndef __ASSEMBLY__
 
+#include <linux/types.h>
+
 struct pt_regs {
 	unsigned long u_regs[16]; /* globals and ins */
 	unsigned long tstate;
@@ -27,6 +29,16 @@ struct pt_regs32 {
 	unsigned int u_regs[16]; /* globals and ins */
 };
 
+static inline bool pt_regs_is_syscall(struct pt_regs *regs)
+{
+	return (regs->tstate & TSTATE_SYSCALL);
+}
+
+static inline bool pt_regs_clear_syscall(struct pt_regs *regs)
+{
+	return (regs->tstate &= ~TSTATE_SYSCALL);
+}
+
 #define UREG_G0        0
 #define UREG_G1        1
 #define UREG_G2        2
include/asm-sparc64/signal.h +1 -7
@@ -186,13 +186,7 @@ struct k_sigaction {
 	void __user		*ka_restorer;
 };
 
-struct signal_deliver_cookie {
-	int restart_syscall;
-	unsigned long orig_i0;
-};
-
-struct pt_regs;
-extern void ptrace_signal_deliver(struct pt_regs *regs, void *cookie);
+#define ptrace_signal_deliver(regs, cookie) do { } while (0)
 
 #endif /* !(__KERNEL__) */
 
include/asm-sparc64/ttable.h +4 -3
@@ -91,13 +91,14 @@
 	 clr	%l6;
 	
 #define SYSCALL_TRAP(routine, systbl)			\
+	rdpr	%pil, %g2;				\
+	mov	TSTATE_SYSCALL, %g3;			\
 	sethi	%hi(109f), %g7;				\
-	ba,pt	%xcc, etrap;				\
+	ba,pt	%xcc, etrap_syscall;			\
 109:	 or	%g7, %lo(109b), %g7;			\
 	sethi	%hi(systbl), %l7;			\
 	ba,pt	%xcc, routine;				\
-	 or	%l7, %lo(systbl), %l7;			\
-	nop; nop;
+	 or	%l7, %lo(systbl), %l7;
 	
 #define INDIRECT_SOLARIS_SYSCALL(num)			\
 	sethi	%hi(109f), %g7;				\
include/asm-sparc/psr.h +1 -0
@@ -25,6 +25,7 @@
 #define PSR_PIL     0x00000f00         /* processor interrupt level  */
 #define PSR_EF      0x00001000         /* enable floating point      */
 #define PSR_EC      0x00002000         /* enable co-processor        */
+#define PSR_SYSCALL 0x00004000         /* inside of a syscall        */
 #define PSR_LE      0x00008000         /* SuperSparcII little-endian */
 #define PSR_ICC     0x00f00000         /* integer condition codes    */
 #define PSR_C       0x00100000         /* carry bit                  */
include/asm-sparc/ptrace.h +12 -0
@@ -10,6 +10,8 @@
 
 #ifndef __ASSEMBLY__
 
+#include <linux/types.h>
+
 struct pt_regs {
 	unsigned long psr;
 	unsigned long pc;
@@ -39,6 +41,16 @@ struct pt_regs {
 #define UREG_FP        UREG_I6
 #define UREG_RETPC     UREG_I7
 
+static inline bool pt_regs_is_syscall(struct pt_regs *regs)
+{
+	return (regs->psr & PSR_SYSCALL);
+}
+
+static inline bool pt_regs_clear_syscall(struct pt_regs *regs)
+{
+	return (regs->psr &= ~PSR_SYSCALL);
+}
+
 /* A register window */
 struct reg_window {
 	unsigned long locals[8];
include/asm-sparc/signal.h +1 -7
@@ -199,13 +199,7 @@ typedef struct sigaltstack {
 	size_t		ss_size;
 } stack_t;
 
-struct sparc_deliver_cookie {
-	int restart_syscall;
-	unsigned long orig_i0;
-};
-
-struct pt_regs;
-extern void ptrace_signal_deliver(struct pt_regs *regs, void *cookie);
+#define ptrace_signal_deliver(regs, cookie) do { } while (0)
 
 #endif /* !(__KERNEL__) */
 
author
#46 lore raw

PATCH 27/37 sparc32: Dont twiddle PT_DTRACE in exec.

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: David S. Miller <[email protected]>

[ Upstream commit: c07c6053c41f736711ed856aa377007078c7c396 ]

That bit isn't used on this platform.

---
 arch/sparc/kernel/process.c |    5 -----
 1 file changed, 5 deletions(-)
arch/sparc/kernel/process.c +0 -5
@@ -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;
 }
author
#47 lore raw

PATCH 28/37 USB: airprime: unlock mutex instead of trying to lock it again

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Leonardo Chiquitto <[email protected]>

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.

---
 drivers/usb/serial/airprime.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/serial/airprime.c +1 -1
@@ -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]);
author
#48 lore raw

PATCH 29/37 r8169: fix past rtl_chip_info array size for unknown chipsets

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Roel Kluin <[email protected]>

commit cee60c377de6d9d10f0a2876794149bd79a15020 upstream.

'i' is unsigned.

---
 drivers/net/r8169.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/net/r8169.c +3 -3
@@ -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;
 
author
#49 lore raw

PATCH 30/37 r8169: fix oops in r8169_get_mac_version

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Ivan Vecera <[email protected]>

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.

---
 drivers/net/r8169.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/r8169.c +1 -1
@@ -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;
author
#50 lore raw

PATCH 31/37 SCSI: qla1280: Fix queue depth problem

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Jeremy Higdon <[email protected]>

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.

---
 drivers/scsi/qla1280.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/scsi/qla1280.c +2 -2
@@ -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;
 		nv->bus[bus].selection_timeout = 250;
-		nv->bus[bus].max_queue_depth = 256;
+		nv->bus[bus].max_queue_depth = 32;
 
 		if (IS_ISP1040(ha)) {
 			nv->bus[bus].bus_reset_delay = 3;
@@ -2056,7 +2056,7 @@ qla1280_config_target(struct scsi_qla_ho
 	status = qla1280_mailbox_command(ha, 0x0f, mb);
 
 	/* Save Tag queuing enable flag. */
-	flag = (BIT_0 << target) & mb[0];
+	flag = (BIT_0 << target);
 	if (nv->bus[bus].target[target].parameter.tag_queuing)
 		ha->bus_settings[bus].qtag_enables |= flag;
 
author
#51 lore raw

PATCH 32/37 SCSI: libiscsi regression in 2.6.25: fix nop timer handling

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Mike Christie <[email protected]>

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.

---
 drivers/scsi/libiscsi.c |   17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)
drivers/scsi/libiscsi.c +9 -8
@@ -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 &&
+	    time_before_eq(conn->last_ping + (conn->ping_timeout * HZ),
 			   jiffies)) {
 		iscsi_conn_printk(KERN_ERR, conn, "ping timeout of %d secs "
 				  "expired, last rx %lu, last ping %lu, "
@@ -1376,15 +1377,15 @@ static void iscsi_check_transport_timeou
 		return;
 	}
 
-	if (time_before_eq(last_recv + timeout, jiffies)) {
+	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);
 		}
-		next_timeout = last_recv + timeout + (conn->ping_timeout * HZ);
+		next_timeout = conn->last_ping + (conn->ping_timeout * HZ);
 	} else
-		next_timeout = last_recv + timeout;
+		next_timeout = last_recv + recv_timeout;
 
 	debug_scsi("Setting next tmo %lu\n", next_timeout);
 	mod_timer(&conn->transport_timer, next_timeout);
author
#52 lore raw

PATCH 33/37 SCSI: libiscsi regression in 2.6.25: fix setting of recv timer

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Mike Christie <[email protected]>

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.

---
 drivers/scsi/libiscsi.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/scsi/libiscsi.c +6 -6
@@ -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;
author
#53 lore raw

PATCH 34/37 SCSI: aha152x: Fix oops on module removal

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: James Bottomley <[email protected]>

commit 64976a0387835a7ac61bbe2a99b27ccae34eac5d upstream

Quoted 17 lines

after trying to unload the module:

BUG: unable to handle kernel paging request at 00100100
IP: [<fb9ff667>] :aha152x:aha152x_exit+0x47/0x6a
*pde = 00000000
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: aha152x(-) w83781d hwmon_vid tun ne 8390 bonding

usb_storage snd_usb_audio snd_usb_lib snd_rawmidi pwc snd_seq_device compat_ioctl32 snd_hwdep videodev v4l1_compat 3c59x mii intel_agp agpgart snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd

Pid: 2837, comm: rmmod Not tainted (2.6.25.3 #1)
EIP: 0060:[<fb9ff667>] EFLAGS: 00210212 CPU: 0
EIP is at aha152x_exit+0x47/0x6a [aha152x]
EAX: 00000001 EBX: 000ffdc4 ECX: f7c517a8 EDX: 00000001
ESI: 00000000 EDI: 00000003 EBP: e7880000 ESP: e7881f58
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process rmmod (pid: 2837, ti=e7880000 task=f27eb580 task.ti=e7880000)

Quoted 9 lines
Stack: fba03700 c01419d2 31616861 00783235 e795ee70 c0157709 b7f24000 e79ae000
        c0158271 ffffffff b7f25000 e79ae004 e795e370 b7f25000 e795e37c e795e370
        009ae000 fba03700 00000880 e7881fa8 00000000 bf93ec20 bf93ec20 c0102faa
Call Trace:
  [<c01419d2>] sys_delete_module+0x112/0x1a0
  [<c0157709>] remove_vma+0x39/0x50
  [<c0158271>] do_munmap+0x181/0x1f0
  [<c0102faa>] sysenter_past_esp+0x5f/0x85
  [<c0490000>] rsc_parse+0x0/0x3c0

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().

---
 drivers/scsi/aha152x.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/scsi/aha152x.c +2 -2
@@ -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);
author
#54 lore raw

PATCH 35/37 SCSI: aha152x: fix init suspiciously returned 1, it should follow 0/-E convention

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: James Bottomley <[email protected]>

commit ad2fa42d044b98469449880474a9662fb689f7f9 upstream

Quoted 4 lines

[1.] One line summary of the problem:
linux-2.6.25.3, aha152x'->init suspiciously returned 1, it should follow 0/-E convention. The module / driver works okay. Unloading the module is impossible.

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.

---
 drivers/scsi/aha152x.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/scsi/aha152x.c +2 -2
@@ -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)
author
#55 lore raw

PATCH 36/37 rtc: rtc_time_to_tm: use unsigned arithmetic

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Maciej W. Rozycki <[email protected]>

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.

[[email protected]: remove old-fashioned `register' keyword]
Cc Alessandro Zummo <[email protected]>
Cc David Brownell <[email protected]>
Cc Dmitri Vorobiev <[email protected]>
---
 drivers/rtc/rtc-lib.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/rtc/rtc-lib.c +1 -1
@@ -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;
author
#56 lore raw

PATCH 37/37 md: fix raid5 repair operations

In reply to Greg KH

2.6.25-stable review patch. If anyone has any objections, please let us know.

------------------
From: Dan Williams <[email protected]>

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)

---
 drivers/md/raid5.c |   25 +++++++++++++------------
 1 file changed, 13 insertions(+), 12 deletions(-)
drivers/md/raid5.c +13 -12
@@ -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_
 			canceled_check = 1; /* STRIPE_INSYNC is not set */
 	}
 
-	/* check if we can clear a parity disk reconstruct */
-	if (test_bit(STRIPE_OP_COMPUTE_BLK, &sh->ops.complete) &&
-		test_bit(STRIPE_OP_MOD_REPAIR_PD, &sh->ops.pending)) {
-
-		clear_bit(STRIPE_OP_MOD_REPAIR_PD, &sh->ops.pending);
-		clear_bit(STRIPE_OP_COMPUTE_BLK, &sh->ops.complete);
-		clear_bit(STRIPE_OP_COMPUTE_BLK, &sh->ops.ack);
-		clear_bit(STRIPE_OP_COMPUTE_BLK, &sh->ops.pending);
-	}
-
 	/* start a new check operation if there are no failures, the stripe is
 	 * not insync, and a repair is not in flight
 	 */
@@ -2409,6 +2399,17 @@ static void handle_parity_checks5(raid5_
 		}
 	}
 
+	/* check if we can clear a parity disk reconstruct */
+	if (test_bit(STRIPE_OP_COMPUTE_BLK, &sh->ops.complete) &&
+	    test_bit(STRIPE_OP_MOD_REPAIR_PD, &sh->ops.pending)) {
+
+		clear_bit(STRIPE_OP_MOD_REPAIR_PD, &sh->ops.pending);
+		clear_bit(STRIPE_OP_COMPUTE_BLK, &sh->ops.complete);
+		clear_bit(STRIPE_OP_COMPUTE_BLK, &sh->ops.ack);
+		clear_bit(STRIPE_OP_COMPUTE_BLK, &sh->ops.pending);
+	}
+
+
 	/* Wait for check parity and compute block operations to complete
 	 * before write-back.  If a failure occurred while the check operation
 	 * was in flight we need to cycle this stripe through handle_stripe