kernel/linux.git/drivers, branch linux-2.6.18.y

read_zero_pagealigned() locking fix

2007-02-23T23:49:52+00:00

Ramiro Voicu hits the BUG_ON(!pte_none(*pte)) in zeromap_pte_range: kernel bugzilla 7645. Right: read_zero_pagealigned uses down_read of mmap_sem, but another thread's racing read of /dev/zero, or a normal fault, can easily set that pte again, in between zap_page_range and zeromap_page_range getting there. It's been wrong ever since 2.4.3. The simple fix is to use down_write instead, but that would serialize reads of /dev/zero more than at present: perhaps some app would be badly affected. So instead let zeromap_page_range return the error instead of BUG_ON, and read_zero_pagealigned break to the slower clear_user loop in that case - there's no need to optimize for it. Use -EEXIST for when a pte is found: BUG_ON in mmap_zero (the other user of zeromap_page_range), though it really isn't interesting there. And since mmap_zero wants -EAGAIN for out-of-memory, the zeromaps better return that than -ENOMEM. Signed-off-by: Hugh Dickins Cc: Ramiro Voicu: Signed-off-by: Andrew Morton Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

V4L: buf_qbuf: fix videobuf_queue->stream corruption and lockup

2007-02-23T23:49:52+00:00

We are doing ->buf_prepare(buf) before adding buf to q->stream list. This means that videobuf_qbuf() should not try to re-add a STATE_PREPARED buffer. (cherry picked from commit 419dd8378dfa32985672ab7927b4bc827f33b332) Signed-off-by: Oleg Nesterov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman

V4L: tveeprom: autodetect LG TAPC G701D as tuner type 37

2007-02-23T23:49:52+00:00

Autodetect LG TAPC G701D as tuner type 37, fixing mis-detected tuners in some Hauppauge tv tuner cards. Thanks to Adonis Papas, for pointing this out. (cherry picked from commit 1323fbda1343f50f198bc8bd6d1d59c8b7fc45bf) Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

V4L: fix ks0127 status flags

2007-02-23T23:49:52+00:00

Or status flags together in DECODER_GET_STATUS instead of and-zapping them. (cherry picked from commit 55d5440d4587454628a850ce26703639885af678) Signed-off-by: Martin Samuelsson Signed-off-by: Andrew Morton Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman

V4L: Fix quickcam communicator driver for big endian architectures

2007-02-23T23:49:52+00:00

Host endianess does not affect the order that pixel rgb data comes in from the quickcam (the values are bytes, not words or longs). The driver is erroniously swapping the order of rgb values for big endian machines. This patch is needed get the Quickcam communicator working on big endian machines (tested on powerpc) (cherry picked from commit c6d704c8c4453f05717ba88792f70f8babf95268) Signed-off-by: Grant Likely Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman

v4l: cx88: Fix leadtek_eeprom tagging

2007-02-23T23:49:52+00:00

reference to .init.text: from .text between 'cx88_card_setup' (at offset 0x68c) and 'cx88_risc_field' Caused by leadtek_eeprom() being declared __devinit and called from a non-devinit context. (cherry picked from commit 69f7e75a9d45e5eaca16917a8d0dedf76149f13f) Signed-off-by: Jean Delvare Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

dvb-core: fix bug in CRC-32 checking on 64-bit systems

2007-02-23T23:49:51+00:00

CRC-32 checking during ULE decapsulation always failed on x86_64 systems due to the size of a variable used to store CRC. This bug was discovered on Fedora Core 6 with kernel-2.6.18-1.2849. The i386 counterpart has no such problem. This patch has been tested on 64-bit system as well as 32-bit system. (cherry picked from commit dedcefb085fe98a1feaf63590fe2fc7e0ecb1987) Signed-off-by: Ang Way Chuang Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

IB/mad: Fix race between cancel and receive completion

2007-02-23T23:49:51+00:00

When ib_cancel_mad() is called, it puts the canceled send on a list and schedules a "flushed" callback from process context. However, this leaves a window where a receive completion could be processed before the send is fully flushed. This is fine, except that ib_find_send_mad() will find the MAD and return it to the receive processing, which results in the sender getting both a successful receive and a "flushed" send completion for the same request. Understandably, this confuses the sender, which is expecting only one of these two callbacks, and leads to grief such as a use-after-free in IPoIB. Fix this by changing ib_find_send_mad() to return a send struct only if the status is still successful (and not "flushed"). The search of the send_list already had this check, so this patch just adds the same check to the search of the wait_list. Signed-off-by: Roland Dreier Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

i2c: fix broken ds1337 initialization

2007-02-23T23:49:51+00:00

On a custom board with ds1337 RTC I found that upgrade from 2.6.15 to 2.6.18 broke RTC support. The main problem are changes to ds1337_init_client(). When a ds1337 recognizes a problem (e.g. power or clock failure) bit 7 in status register is set. This has to be reset by writing 0 to status register. But since there are only 16 byte written to the chip and the first byte is interpreted as an address, the status register (which is the 16th) is never written. The other problem is, that initializing all registers to zero is not valid for day, date and month register. Funny enough this is checked by ds1337_detect(), which depends on this values not being zero. So then treated by ds1337_init_client() the ds1337 is not detected anymore, whereas the failure bit in the status register is still set. Broken by commit f9e8957937ebf60d22732a5ca9130f48a7603f60 (2.6.16-rc1, 2006-01-06). This fix is in Linus' tree since 2.6.20-rc1 (commit 763d9c046a2e511ec090a8986d3f85edf7448e7e). Signed-off-by: Dirk Stieler Signed-off-by: Dirk Eibach Signed-off-by: Jean Delvare Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

IB/srp: Fix FMR mapping for 32-bit kernels and addresses above 4G

2007-02-23T23:49:51+00:00

struct srp_device.fmr_page_mask was unsigned long, which means that the top part of addresses above 4G was being chopped off on 32-bit architectures. Of course nothing good happens when data from SRP targets is DMAed to the wrong place. Fix this by changing fmr_page_mask to u64, to match the addresses actually used by IB devices. Thanks to Brian Cain and David McMillen for help diagnosing the bug and testing the fix. Signed-off-by: Roland Dreier Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman