2.6.25.4 -stable review
Subsystems (27)
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(-)
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 150static 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(strumsleep (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
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
6ca8f0b97473dcef3a754bab5239dcfcdd00b244upstreamThis patch introduces support for dvb-t for the following DiBcom based cards:
- Terratec Cinergy HT USB XE (USB-ID: 0ccd:0058)
- Terratec Cinergy HT Express (USB-ID: 0ccd:0060)
- Pinnacle 320CX (USB-ID: 2304:022e)
- Pinnacle PCTV72e (USB-ID: 2304:0236)
- Pinnacle PCTV73e (USB-ID: 2304:0237)
- Yuan EC372S (USB-ID: 1164:1edc)Signed-off-by Hans-Frieder Vogt <[email protected]>Signed-off-by Felix Apitzsch <[email protected]>Signed-off-by Antti Palosaari <[email protected]>Signed-off-by Albert Comerma <[email protected]>Signed-off-by Patrick Boettcher <[email protected]>Signed-off-by Mauro Carvalho Chehab <[email protected]>Cc Michel Morisot <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
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
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
6ca8f0b97473dcef3a754bab5239dcfcdd00b244upstreamThis patch introduces support for dvb-t for the following DiBcom based cards:
- Terratec Cinergy HT USB XE (USB-ID: 0ccd:0058)
- Terratec Cinergy HT Express (USB-ID: 0ccd:0060)
- Pinnacle 320CX (USB-ID: 2304:022e)
- Pinnacle PCTV72e (USB-ID: 2304:0236)
- Pinnacle PCTV73e (USB-ID: 2304:0237)
- Yuan EC372S (USB-ID: 1164:1edc)Signed-off-by Hans-Frieder Vogt <[email protected]>Signed-off-by Felix Apitzsch <[email protected]>Signed-off-by Antti Palosaari <[email protected]>Signed-off-by Albert Comerma <[email protected]>Signed-off-by Patrick Boettcher <[email protected]>Signed-off-by Mauro Carvalho Chehab <[email protected]>Cc Michel Morisot <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
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
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
6ca8f0b97473dcef3a754bab5239dcfcdd00b244upstreamThis patch introduces support for dvb-t for the following DiBcom based cards:
- Terratec Cinergy HT USB XE (USB-ID: 0ccd:0058)
- Terratec Cinergy HT Express (USB-ID: 0ccd:0060)
- Pinnacle 320CX (USB-ID: 2304:022e)
- Pinnacle PCTV72e (USB-ID: 2304:0236)
- Pinnacle PCTV73e (USB-ID: 2304:0237)
- Yuan EC372S (USB-ID: 1164:1edc)Signed-off-by Hans-Frieder Vogt <[email protected]>Signed-off-by Felix Apitzsch <[email protected]>Signed-off-by Antti Palosaari <[email protected]>Signed-off-by Albert Comerma <[email protected]>Signed-off-by Patrick Boettcher <[email protected]>Signed-off-by Mauro Carvalho Chehab <[email protected]>Cc Michel Morisot <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
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
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
6ca8f0b97473dcef3a754bab5239dcfcdd00b244upstreamThis patch introduces support for dvb-t for the following DiBcom based cards:
- Terratec Cinergy HT USB XE (USB-ID: 0ccd:0058)
- Terratec Cinergy HT Express (USB-ID: 0ccd:0060)
- Pinnacle 320CX (USB-ID: 2304:022e)
- Pinnacle PCTV72e (USB-ID: 2304:0236)
- Pinnacle PCTV73e (USB-ID: 2304:0237)
- Yuan EC372S (USB-ID: 1164:1edc)Signed-off-by Hans-Frieder Vogt <[email protected]>Signed-off-by Felix Apitzsch <[email protected]>Signed-off-by Antti Palosaari <[email protected]>Signed-off-by Albert Comerma <[email protected]>Signed-off-by Patrick Boettcher <[email protected]>Signed-off-by Mauro Carvalho Chehab <[email protected]>Cc Michel Morisot <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
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
PATCH 2/37 vt: fix canonical input in UTF-8 mode
In reply to Greg KH2.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))
PATCH 3/37 serial: access after NULL check in uart_flush_buffer()
In reply to Greg KH2.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 tstatic 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 ttyreturn ; } + port = state->port;pr_debug ("uart_flush_buffer(%d) called\n" , tty->index);spin_lock_irqsave (&port->lock, flags);
PATCH 4/37 OHCI: fix regression upon awakening from hibernation
In reply to Greg KH2.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(struif (!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(step93xx_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 platfomap_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(streturn 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 platsm501_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_dessb_device_enable (dev, ohcidev->enable_flags); +ohci_finish_controller_resume (hcd);return 0 ; }
PATCH 5/37 XFRM: AUDIT: Fix flowlabel text format ambibuity.
In reply to Greg KH2.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,
PATCH 6/37 sparc: sunzilog uart order
In reply to Greg KH2.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] enabledffd37420: ttyS1 at MMIO 0xf1100004 (irq = 44) is a zs (ESCC)ffd37500: Keyboard at MMIO 0xf1000000 (irq = 44) is a zsffd37500: Mouse at MMIO 0xf1000004 (irq = 44) is a zsffd3c5c0: 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_drivstatic 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; }
PATCH 7/37 sparc: Fix SA_ONSTACK signal handling.
In reply to Greg KH2.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, __sstatic 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); }
PATCH 8/37 sparc: Fix fork/clone/vfork system call restart.
In reply to Greg KH2.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
PATCH 9/37 sparc64: Stop creating dummy root PCI host controller devices.
In reply to Greg KH2.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 ofstruct 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_opci_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 pciunsigned 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 pcunsigned 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 pciextern 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 *);
PATCH 10/37 sparc64: Fix wedged irq regression.
In reply to Greg KH2.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); } }
PATCH 11/37 SPARC64: Fix args to 64-bit sys_semctl() via sys_ipc().
In reply to Greg KH2.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; }
PATCH 12/37 serial: Fix sparc driver name strings.
In reply to Greg KH2.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 *sunzilstatic struct uart_driver sunzilog_reg = { .owner =THIS_MODULE , - .driver_name ="ttyS" , + .driver_name ="sunzilog" , .dev_name ="ttyS" , .major =TTY_MAJOR , };
PATCH 13/37 sch_htb: remove from event queue in htb_parent_to_leaf()
In reply to Greg KH2.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);
PATCH 14/37 macvlan: Fix memleak on device removal/crash on module removal
In reply to Greg KH2.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_dunregister_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 = {
PATCH 15/37 ipvs: fix oops in backup for fwmark conn templates
In reply to Greg KH2.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_protocostruct 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 protstruct 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_protocstruct 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_protocstruct 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
PATCH 16/37 dccp: return -EINVAL on invalid feature length
In reply to Greg KH2.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_minisocif (len >3 ) {DCCP_WARN ("invalid length %d\n" , len); -return 1 ; +return -EINVAL ; }/* XXX add further sanity checks */
PATCH 17/37 can: Fix can_send() handling on dev_queue_xmit() failures
In reply to Greg KH2.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 loif (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);
PATCH 18/37 x86: use defconfigs from x86/configs/*
In reply to Greg KH2.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
PATCH 19/37 nf_conntrack: padding breaks conntrack hash on ARM
In reply to Greg KH2.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 *skconst 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_tconst 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 )
PATCH 20/37 {nfnetlink, ip, ip6}_queue: fix skb_over_panic when enlarging packets
In reply to Greg KH2.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:f6015bf8Looking 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, stif (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, stif (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, sif (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" );
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_panicwhen enlarging packetsFrom: 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<4Cheers,
a+
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
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
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
@@ -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
@@ -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
@@ -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" );
PATCH 21/37 ata_piix: verify SIDPR access before enabling it
In reply to Greg KH2.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(streturn ; 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; }
PATCH 22/37 x86: sysfs cpu?/topology is empty in 2.6.25 (32-bit Intel system)
In reply to Greg KH2.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
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
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
PATCH 23/37 i2c-piix4: Blacklist two mainboards
In reply to Greg KH2.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(structdev_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 "
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)
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.
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)
Re: Hardware designt to prevent Damages... [WAS: [patch 23/37] i2c-piix4: Blacklist two mainboards]
In reply to Michelle KonzackQuoted 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
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)
PATCH 24/37 sparc: Fix ptrace() detach.
In reply to Greg KH2.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_strubreak ;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 *chibreak ;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 *chibreak ;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
PATCH 25/37 sparc: Fix mremap address range validation.
In reply to Greg KH2.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 (¤t->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 (¤t->mm->mmap_sem); out:return ret;
arch/sparc64/kernel/sys_sparc.c +4 -32
@@ -542,8 +542,7 @@ asmlinkage long sparc64_personality(unsireturn 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 (¤t->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 (¤t->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
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
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
David Miller
maintainerRe: [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.
David Miller
maintainerRe: [patch 25/37] sparc: Fix mremap address range validation.
In reply to Linus TorvaldsFrom: 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.
PATCH 26/37 sparc: Fix debugger syscall restart interactions.
In reply to Greg KH2.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_str32 *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_strswitch (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, strucclear_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_strswitch (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_psrPSR_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__) */
PATCH 27/37 sparc32: Dont twiddle PT_DTRACE in exec.
In reply to Greg KH2.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; }
PATCH 28/37 USB: airprime: unlock mutex instead of trying to lock it again
In reply to Greg KH2.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_semutex_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]);
PATCH 29/37 r8169: fix past rtl_chip_info array size for unknown chipsets
In reply to Greg KH2.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, crtl8169_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;
PATCH 30/37 r8169: fix oops in r8169_get_mac_version
In reply to Greg KH2.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, cSET_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;
PATCH 31/37 SCSI: qla1280: Fix queue depth problem
In reply to Greg KH2.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;
PATCH 32/37 SCSI: libiscsi regression in 2.6.25: fix nop timer handling
In reply to Greg KH2.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_timeoureturn ; } -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);
PATCH 33/37 SCSI: libiscsi regression in 2.6.25: fix setting of recv timer
In reply to Greg KH2.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 iif (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;
PATCH 34/37 SCSI: aha152x: Fix oops on module removal
In reply to Greg KH2.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_storagesnd_usb_audiosnd_usb_libsnd_rawmidipwcsnd_seq_devicecompat_ioctl32snd_hwdepvideodevv4l1_compat3c59x miiintel_agpagpgartsnd_pcm_osssnd_pcmsnd_timersnd_page_allocsnd_mixer_osssndPid: 2837, comm: rmmod Not tainted (2.6.25.3 #1)
EIP: 0060:[<fb9ff667>] EFLAGS: 00210212 CPU: 0
EIP is ataha152x_exit+0x47/0x6a[aha152x]
EAX: 00000001 EBX:000ffdc4ECX:f7c517a8EDX: 00000001
ESI: 00000000 EDI: 00000003 EBP:e7880000ESP: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/0x3c0The 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);
PATCH 35/37 SCSI: aha152x: fix init suspiciously returned 1, it should follow 0/-E convention
In reply to Greg KH2.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)
PATCH 36/37 rtc: rtc_time_to_tm: use unsigned arithmetic
In reply to Greg KH2.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.
--- 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) { - registerint days, month, year; +unsigned int days, month, year; days = time /86400 ; time -= days *86400 ;
PATCH 37/37 md: fix raid5 repair operations
In reply to Greg KH2.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