--- /dev/null
+From efc968d450e013049a662d22727cf132618dcb2f Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Thu, 9 Oct 2008 14:04:54 -0700
+Subject: Don't allow splice() to files opened with O_APPEND
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+commit efc968d450e013049a662d22727cf132618dcb2f upstream
+
+This is debatable, but while we're debating it, let's disallow the
+combination of splice and an O_APPEND destination.
+
+It's not entirely clear what the semantics of O_APPEND should be, and
+POSIX apparently expects pwrite() to ignore O_APPEND, for example. So
+we could make up any semantics we want, including the old ones.
+
+But Miklos convinced me that we should at least give it some thought,
+and that accepting writes at arbitrary offsets is wrong at least for
+IS_APPEND() files (which always have O_APPEND set, even if the reverse
+isn't true: you can obviously have O_APPEND set on a regular file).
+
+So disallow O_APPEND entirely for now. I doubt anybody cares, and this
+way we have one less gray area to worry about.
+
+Reported-and-argued-for-by: Miklos Szeredi <miklos@szeredi.hu>
+Acked-by: Jens Axboe <ens.axboe@oracle.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/splice.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/splice.c
++++ b/fs/splice.c
+@@ -889,6 +889,9 @@ static long do_splice_from(struct pipe_i
+ if (unlikely(!(out->f_mode & FMODE_WRITE)))
+ return -EBADF;
+
++ if (unlikely(out->f_flags & O_APPEND))
++ return -EINVAL;
++
+ ret = rw_verify_area(WRITE, out, ppos, len);
+ if (unlikely(ret < 0))
+ return ret;
--- /dev/null
+From cebbert@redhat.com Thu Oct 16 15:47:05 2008
+From: Tejun Heo <tj@kernel.org>
+Date: Mon, 13 Oct 2008 19:21:28 -0400
+Subject: libata: always do follow-up SRST if hardreset returned -EAGAIN
+To: stable@kernel.org
+Cc: Tejun Heo <tj@kernel.org>
+Message-ID: <20081013192128.5a797eac@redhat.com>
+
+
+From: Tejun Heo <tj@kernel.org>
+
+commit 5dbfc9cb59d4ad75199949d7dd8a8c6d7bc518df upstream
+
+As an optimization, follow-up SRST used to be skipped if
+classification wasn't requested even when hardreset requested it via
+-EAGAIN. However, some hardresets can't wait for device readiness and
+skipping SRST can cause timeout or other failures during revalidation.
+Always perform follow-up SRST if hardreset returns -EAGAIN. This
+makes reset paths more predictable and thus less error-prone.
+
+While at it, move hardreset error checking such that it's done right
+after hardreset is finished. This simplifies followup SRST condition
+check a bit and makes the reset path easier to modify.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
+Cc: Chuck Ebbert <cebbert@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/ata/libata-eh.c | 20 ++++++--------------
+ 1 file changed, 6 insertions(+), 14 deletions(-)
+
+--- a/drivers/ata/libata-eh.c
++++ b/drivers/ata/libata-eh.c
+@@ -2050,18 +2050,12 @@ static int ata_do_reset(struct ata_link
+ }
+
+ static int ata_eh_followup_srst_needed(struct ata_link *link,
+- int rc, int classify,
+- const unsigned int *classes)
++ int rc, const unsigned int *classes)
+ {
+ if ((link->flags & ATA_LFLAG_NO_SRST) || ata_link_offline(link))
+ return 0;
+- if (rc == -EAGAIN) {
+- if (classify)
+- return 1;
+- rc = 0;
+- }
+- if (rc != 0)
+- return 0;
++ if (rc == -EAGAIN)
++ return 1;
+ if (sata_pmp_supported(link->ap) && ata_is_host_link(link))
+ return 1;
+ return 0;
+@@ -2174,9 +2168,11 @@ int ata_eh_reset(struct ata_link *link,
+ ehc->i.flags |= ATA_EHI_DID_SOFTRESET;
+
+ rc = ata_do_reset(link, reset, classes, deadline);
++ if (rc && rc != -EAGAIN)
++ goto fail;
+
+ if (reset == hardreset &&
+- ata_eh_followup_srst_needed(link, rc, classify, classes)) {
++ ata_eh_followup_srst_needed(link, rc, classes)) {
+ /* okay, let's do follow-up softreset */
+ reset = softreset;
+
+@@ -2191,10 +2187,6 @@ int ata_eh_reset(struct ata_link *link,
+ ata_eh_about_to_do(link, NULL, ATA_EH_RESET);
+ rc = ata_do_reset(link, reset, classes, deadline);
+ }
+-
+- /* -EAGAIN can happen if we skipped followup SRST */
+- if (rc && rc != -EAGAIN)
+- goto fail;
+ } else {
+ if (verbose)
+ ata_link_printk(link, KERN_INFO, "no reset method "
--- /dev/null
+From cebbert@redhat.com Thu Oct 16 15:47:56 2008
+From: Tejun Heo <tj@kernel.org>
+Date: Mon, 13 Oct 2008 19:19:59 -0400
+Subject: libata: fix EH action overwriting in ata_eh_reset()
+To: stable@kernel.org
+Cc: Tejun Heo <tj@kernel.org>
+Message-ID: <20081013191959.447d12f6@redhat.com>
+
+From: Tejun Heo <tj@kernel.org>
+
+Commit a674050e068a2919908730279f0b731ae6d2e005 upstream
+
+ehc->i.action got accidentally overwritten to ATA_EH_HARD/SOFTRESET in
+ata_eh_reset(). The original intention was to clear reset action
+which wasn't selected. This can cause unexpected behavior when other
+EH actions are scheduled together with reset. Fix it.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
+Cc: Chuck Ebbert <cebbert@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/ata/libata-eh.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/ata/libata-eh.c
++++ b/drivers/ata/libata-eh.c
+@@ -2112,10 +2112,10 @@ int ata_eh_reset(struct ata_link *link,
+ ehc->i.action &= ~ATA_EH_RESET;
+ if (hardreset) {
+ reset = hardreset;
+- ehc->i.action = ATA_EH_HARDRESET;
++ ehc->i.action |= ATA_EH_HARDRESET;
+ } else if (softreset) {
+ reset = softreset;
+- ehc->i.action = ATA_EH_SOFTRESET;
++ ehc->i.action |= ATA_EH_SOFTRESET;
+ }
+
+ if (prereset) {
--- /dev/null
+From cebbert@redhat.com Thu Oct 16 15:52:52 2008
+From: Taisuke Yamada <tai@rakugaki.org>
+Date: Mon, 13 Oct 2008 19:18:33 -0400
+Subject: libata: LBA28/LBA48 off-by-one bug in ata.h
+To: stable@kernel.org
+Cc: Tejun Heo <tj@kernel.org>
+Message-ID: <20081013191833.18fb5f17@redhat.com>
+
+From: Taisuke Yamada <tai@rakugaki.org>
+
+commit 97b697a11b07e2ebfa69c488132596cc5eb24119 upstream
+
+I recently bought 3 HGST P7K500-series 500GB SATA drives and
+had trouble accessing the block right on the LBA28-LBA48 border.
+Here's how it fails (same for all 3 drives):
+
+ # dd if=/dev/sdc bs=512 count=1 skip=268435455 > /dev/null
+ dd: reading `/dev/sdc': Input/output error
+ 0+0 records in
+ 0+0 records out
+ 0 bytes (0 B) copied, 0.288033 seconds, 0.0 kB/s
+ # dmesg
+ ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
+ ata1.00: BMDMA stat 0x25
+ ata1.00: cmd c8/00:08:f8:ff:ff/00:00:00:00:00/ef tag 0 dma 4096 in
+ res 51/04:08:f8:ff:ff/00:00:00:00:00/ef Emask 0x1 (device error)
+ ata1.00: status: { DRDY ERR }
+ ata1.00: error: { ABRT }
+ ata1.00: configured for UDMA/33
+ ata1: EH complete
+ ...
+
+After some investigations, it turned out this seems to be caused
+by misinterpretation of the ATA specification on LBA28 access.
+Following part is the code in question:
+
+ === include/linux/ata.h ===
+ static inline int lba_28_ok(u64 block, u32 n_block)
+ {
+ /* check the ending block number */
+ return ((block + n_block - 1) < ((u64)1 << 28)) && (n_block <= 256);
+ }
+
+HGST drive (sometimes) fails with LBA28 access of {block = 0xfffffff,
+n_block = 1}, and this behavior seems to be comformant. Other drives,
+including other HGST drives are not that strict, through.
+
+>From the ATA specification:
+(http://www.t13.org/Documents/UploadedDocuments/project/d1410r3b-ATA-ATAPI-6.pdf)
+
+ 8.15.29 Word (61:60): Total number of user addressable sectors
+ This field contains a value that is one greater than the total number
+ of user addressable sectors (see 6.2). The maximum value that shall
+ be placed in this field is 0FFFFFFFh.
+
+So the driver shouldn't use the value of 0xfffffff for LBA28 request
+as this exceeds maximum user addressable sector. The logical maximum
+value for LBA28 is 0xffffffe.
+
+The obvious fix is to cut "- 1" part, and the patch attached just do
+that. I've been using the patched kernel for about a month now, and
+the same fix is also floating on the net for some time. So I believe
+this fix works reliably.
+
+Just FYI, many Windows/Intel platform users also seems to be struck
+by this, and HGST has issued a note pointing to Intel ICH8/9 driver.
+
+ "28-bit LBA command is being used to access LBAs 29-bits in length"
+http://www.hitachigst.com/hddt/knowtree.nsf/cffe836ed7c12018862565b000530c74/b531b8bce8745fb78825740f00580e23
+
+Also, *BSDs seems to have similar fix included sometime around ~2004,
+through I have not checked out exact portion of the code.
+
+Signed-off-by: Taisuke Yamada <tai@rakugaki.org>
+Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
+Cc: Chuck Ebbert <cebbert@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ include/linux/ata.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/linux/ata.h
++++ b/include/linux/ata.h
+@@ -682,7 +682,7 @@ static inline int ata_ok(u8 status)
+ static inline int lba_28_ok(u64 block, u32 n_block)
+ {
+ /* check the ending block number */
+- return ((block + n_block - 1) < ((u64)1 << 28)) && (n_block <= 256);
++ return ((block + n_block) < ((u64)1 << 28)) && (n_block <= 256);
+ }
+
+ static inline int lba_48_ok(u64 block, u32 n_block)
b43legacy-fix-failure-in-rate-adjustment-mechanism.patch
modules-fix-module-notes-kobject-leak.patch
fbcon_set_all_vcs-fix-kernel-crash-when-switching-the-rotated-consoles.patch
+libata-always-do-follow-up-srst-if-hardreset-returned-eagain.patch
+libata-fix-eh-action-overwriting-in-ata_eh_reset.patch
+libata-lba28-lba48-off-by-one-bug-in-ata.h.patch
+v4l-bttv-prevent-null-pointer-dereference-in-radio_open.patch
+v4l-zr36067-fix-rgbr-pixel-format.patch
+don-t-allow-splice-to-files-opened-with-o_append.patch
--- /dev/null
+From mkrufky@linuxtv.org Thu Oct 16 15:56:52 2008
+From: Jean Delvare <khali@linux-fr.org>
+Date: Fri, 10 Oct 2008 08:41:38 -0400
+Subject: V4L: bttv: Prevent NULL pointer dereference in radio_open
+To: stable@kernel.org
+Cc: Jean Delvare <khali@linux-fr.org>, v4l-dvb maintainer list <v4l-dvb-maintainer@linuxtv.org>, Mauro Carvalho Chehab <mchehab@infradead.org>
+Message-ID: <48EF4D82.5070609@linuxtv.org>
+
+
+From: Jean Delvare <khali@linux-fr.org>
+
+(cherry picked from commit c37396c19403e249f12626187d51e92c915f2bc9)
+
+Fix the following crash in the bttv driver:
+
+BUG: unable to handle kernel NULL pointer dereference at 000000000000036c
+IP: [<ffffffffa037860a>] radio_open+0x3a/0x170 [bttv]
+
+This happens because radio_open assumes that all present bttv devices
+have a radio function. If a bttv device without radio and one with
+radio are installed on the same system, and the one without radio is
+registered first, then radio_open checks for the radio device number
+of a bttv device that has no radio function, and this breaks. All we
+have to do to fix it is to skip bttv devices without a radio function.
+
+Signed-off-by: Jean Delvare <khali@linux-fr.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
+Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/media/video/bt8xx/bttv-driver.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/video/bt8xx/bttv-driver.c
++++ b/drivers/media/video/bt8xx/bttv-driver.c
+@@ -3428,7 +3428,7 @@ static int radio_open(struct inode *inod
+ dprintk("bttv: open minor=%d\n",minor);
+
+ for (i = 0; i < bttv_num; i++) {
+- if (bttvs[i].radio_dev->minor == minor) {
++ if (bttvs[i].radio_dev && bttvs[i].radio_dev->minor == minor) {
+ btv = &bttvs[i];
+ break;
+ }
--- /dev/null
+From mkrufky@linuxtv.org Thu Oct 16 15:57:24 2008
+From: Jean Delvare <khali@linux-fr.org>
+Date: Fri, 10 Oct 2008 08:41:43 -0400
+Subject: V4L: zr36067: Fix RGBR pixel format
+To: stable@kernel.org
+Cc: Jean Delvare <khali@linux-fr.org>, v4l-dvb maintainer list <v4l-dvb-maintainer@linuxtv.org>, Trent Piepho <xyzzy@speakeasy.org>, Mauro Carvalho Chehab <mchehab@infradead.org>
+Message-ID: <48EF4D87.2000701@linuxtv.org>
+
+
+From: Jean Delvare <khali@linux-fr.org>
+
+cherry picked from commit a30ee3c747728f9151664118ffcbdeefd202c332
+
+The zr36067 driver is improperly declaring pixel format RGBP twice,
+once as "16-bit RGB LE" and once as "16-bit RGB BE". The latter is
+actually RGBR. Fix the code to properly map both pixel formats.
+
+Signed-off-by: Jean Delvare <khali@linux-fr.org>
+Acked-by: Trent Piepho <xyzzy@speakeasy.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
+Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/media/video/zoran_driver.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/video/zoran_driver.c
++++ b/drivers/media/video/zoran_driver.c
+@@ -134,7 +134,7 @@ const struct zoran_format zoran_formats[
+ }, {
+ .name = "16-bit RGB BE",
+ ZFMT(-1,
+- V4L2_PIX_FMT_RGB565, V4L2_COLORSPACE_SRGB),
++ V4L2_PIX_FMT_RGB565X, V4L2_COLORSPACE_SRGB),
+ .depth = 16,
+ .flags = ZORAN_FORMAT_CAPTURE |
+ ZORAN_FORMAT_OVERLAY,
projects / thirdparty / kernel / stable-queue.git / commitdiff
