From: Greg Kroah-Hartman Date: Tue, 1 Dec 2009 20:46:39 +0000 (-0800) Subject: start the .31 queue X-Git-Tag: v2.6.31.7~17 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=66448686803509bfd7ad2b91b43dbdff28a08ad7;p=thirdparty%2Fkernel%2Fstable-queue.git start the .31 queue --- diff --git a/queue-2.6.31/alsa-aaci-fix-ac97-multiple-open-bug.patch b/queue-2.6.31/alsa-aaci-fix-ac97-multiple-open-bug.patch new file mode 100644 index 00000000000..dc87c0a5a49 --- /dev/null +++ b/queue-2.6.31/alsa-aaci-fix-ac97-multiple-open-bug.patch @@ -0,0 +1,30 @@ +From 4acd57c3de62374fe5bb52e5cd24538190f4eab2 Mon Sep 17 00:00:00 2001 +From: Russell King +Date: Sun, 29 Nov 2009 16:39:52 +0000 +Subject: ALSA: AACI: fix AC97 multiple-open bug + +From: Russell King + +commit 4acd57c3de62374fe5bb52e5cd24538190f4eab2 upstream. + +Signed-off-by: Russell King +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/arm/aaci.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/sound/arm/aaci.c ++++ b/sound/arm/aaci.c +@@ -504,6 +504,10 @@ static int aaci_pcm_hw_params(struct snd + int err; + + aaci_pcm_hw_free(substream); ++ if (aacirun->pcm_open) { ++ snd_ac97_pcm_close(aacirun->pcm); ++ aacirun->pcm_open = 0; ++ } + + err = devdma_hw_alloc(NULL, substream, + params_buffer_bytes(params)); diff --git a/queue-2.6.31/alsa-aaci-fix-recording-bug.patch b/queue-2.6.31/alsa-aaci-fix-recording-bug.patch new file mode 100644 index 00000000000..06d172ecd45 --- /dev/null +++ b/queue-2.6.31/alsa-aaci-fix-recording-bug.patch @@ -0,0 +1,32 @@ +From 8ee763b9c82c6ca0a59a7271ce4fa29d7baf5c09 Mon Sep 17 00:00:00 2001 +From: Russell King +Date: Sun, 29 Nov 2009 16:39:59 +0000 +Subject: ALSA: AACI: fix recording bug + +From: Russell King + +commit 8ee763b9c82c6ca0a59a7271ce4fa29d7baf5c09 upstream. + +pcm->r[1].slots is the double rate slot information, not the +capture information. For capture, 'pcm' will already be the +capture ac97 pcm structure. + +Signed-off-by: Russell King +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/arm/aaci.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/arm/aaci.c ++++ b/sound/arm/aaci.c +@@ -521,7 +521,7 @@ static int aaci_pcm_hw_params(struct snd + else + err = snd_ac97_pcm_open(aacirun->pcm, params_rate(params), + params_channels(params), +- aacirun->pcm->r[1].slots); ++ aacirun->pcm->r[0].slots); + + if (err) + goto out; diff --git a/queue-2.6.31/alsa-hda-dell-studio-1557-hd-audio-quirk.patch b/queue-2.6.31/alsa-hda-dell-studio-1557-hd-audio-quirk.patch new file mode 100644 index 00000000000..e89843539ea --- /dev/null +++ b/queue-2.6.31/alsa-hda-dell-studio-1557-hd-audio-quirk.patch @@ -0,0 +1,31 @@ +From 8ef5837a47f73faee18fa7ce2f9a9eb7675be8de Mon Sep 17 00:00:00 2001 +From: Daniel J Blueman +Date: Sat, 14 Nov 2009 18:20:04 +0000 +Subject: ALSA: hda - Dell Studio 1557 hd-audio quirk + +From: Daniel J Blueman + +commit 8ef5837a47f73faee18fa7ce2f9a9eb7675be8de upstream. + +Add the Dell Studio 15 (model 1557, Core i7) laptop to the hd-audio +quirk list, enabling audio. + +Signed-off-by: Daniel J Blueman +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_sigmatel.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/sound/pci/hda/patch_sigmatel.c ++++ b/sound/pci/hda/patch_sigmatel.c +@@ -1817,6 +1817,8 @@ static struct snd_pci_quirk stac92hd73xx + "Dell Studio 17", STAC_DELL_M6_DMIC), + SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x02be, + "Dell Studio 1555", STAC_DELL_M6_DMIC), ++ SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x02bd, ++ "Dell Studio 1557", STAC_DELL_M6_DMIC), + {} /* terminator */ + }; + diff --git a/queue-2.6.31/alsa-usb-audio-fix-combine_word-problem.patch b/queue-2.6.31/alsa-usb-audio-fix-combine_word-problem.patch new file mode 100644 index 00000000000..d1a150344d2 --- /dev/null +++ b/queue-2.6.31/alsa-usb-audio-fix-combine_word-problem.patch @@ -0,0 +1,43 @@ +From f495088210c8b9e20791d995a8210170c68d2deb Mon Sep 17 00:00:00 2001 +From: Julian Anastasov +Date: Fri, 6 Nov 2009 23:44:53 +0200 +Subject: ALSA: usb-audio: fix combine_word problem + +From: Julian Anastasov + +commit f495088210c8b9e20791d995a8210170c68d2deb upstream. + +Fix combine_word problem where first octet is not +read properly. The only affected place seems to be the +INPUT_TERMINAL type. Before now, sound controls can be created +with the output terminal's name which is a fallback mechanism +used only for unknown input terminal types. For example, +Line can wrongly appear as Speaker. After the change it +should appear as Line. + + The side effect of this change can be that users +can expect the wrong control name in their scripts or +programs while now we return the correct one. + + Probably, these defines should use get_unaligned_le16 and +friends. + +Signed-off-by: Julian Anastasov +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/usb/usbaudio.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/usb/usbaudio.h ++++ b/sound/usb/usbaudio.h +@@ -210,7 +210,7 @@ struct snd_usb_midi_endpoint_info { + /* + */ + +-#define combine_word(s) ((*s) | ((unsigned int)(s)[1] << 8)) ++#define combine_word(s) ((*(s)) | ((unsigned int)(s)[1] << 8)) + #define combine_triple(s) (combine_word(s) | ((unsigned int)(s)[2] << 16)) + #define combine_quad(s) (combine_triple(s) | ((unsigned int)(s)[3] << 24)) + diff --git a/queue-2.6.31/cifs-clean-up-handling-when-server-doesn-t-consistently-support-inode-numbers.patch b/queue-2.6.31/cifs-clean-up-handling-when-server-doesn-t-consistently-support-inode-numbers.patch new file mode 100644 index 00000000000..7672aa904c3 --- /dev/null +++ b/queue-2.6.31/cifs-clean-up-handling-when-server-doesn-t-consistently-support-inode-numbers.patch @@ -0,0 +1,96 @@ +From ec06aedd44541129840ed52e6165afa3796a27bf Mon Sep 17 00:00:00 2001 +From: Jeff Layton +Date: Fri, 6 Nov 2009 14:18:29 -0500 +Subject: cifs: clean up handling when server doesn't consistently support inode numbers + +From: Jeff Layton + +commit ec06aedd44541129840ed52e6165afa3796a27bf upstream. + +It's possible that a server will return a valid FileID when we query the +FILE_INTERNAL_INFO for the root inode, but then zeroed out inode numbers +when we do a FindFile with an infolevel of +SMB_FIND_FILE_ID_FULL_DIR_INFO. + +In this situation turn off querying for server inode numbers, generate a +warning for the user and just generate an inode number using iunique. +Once we generate any inode number with iunique we can no longer use any +server inode numbers or we risk collisions, so ensure that we don't do +that in cifs_get_inode_info either. + +Reported-by: Timothy Normand Miller +Signed-off-by: Jeff Layton +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/cifsproto.h | 1 + + fs/cifs/inode.c | 7 ++----- + fs/cifs/misc.c | 14 ++++++++++++++ + fs/cifs/readdir.c | 7 ++++--- + 4 files changed, 21 insertions(+), 8 deletions(-) + +--- a/fs/cifs/cifsproto.h ++++ b/fs/cifs/cifsproto.h +@@ -389,4 +389,5 @@ extern int CIFSSMBSetPosixACL(const int + const struct nls_table *nls_codepage, int remap_special_chars); + extern int CIFSGetExtAttr(const int xid, struct cifsTconInfo *tcon, + const int netfid, __u64 *pExtAttrBits, __u64 *pMask); ++extern void cifs_autodisable_serverino(struct cifs_sb_info *cifs_sb); + #endif /* _CIFSPROTO_H */ +--- a/fs/cifs/inode.c ++++ b/fs/cifs/inode.c +@@ -512,13 +512,10 @@ int cifs_get_inode_info(struct inode **p + cifs_sb->local_nls, + cifs_sb->mnt_cifs_flags & + CIFS_MOUNT_MAP_SPECIAL_CHR); +- if (rc1) { ++ if (rc1 || !fattr.cf_uniqueid) { + cFYI(1, ("GetSrvInodeNum rc %d", rc1)); + fattr.cf_uniqueid = iunique(sb, ROOT_I); +- /* disable serverino if call not supported */ +- if (rc1 == -EINVAL) +- cifs_sb->mnt_cifs_flags &= +- ~CIFS_MOUNT_SERVER_INUM; ++ cifs_autodisable_serverino(cifs_sb); + } + } else { + fattr.cf_uniqueid = iunique(sb, ROOT_I); +--- a/fs/cifs/misc.c ++++ b/fs/cifs/misc.c +@@ -705,3 +705,17 @@ cifsConvertToUCS(__le16 *target, const c + ctoUCS_out: + return i; + } ++ ++void ++cifs_autodisable_serverino(struct cifs_sb_info *cifs_sb) ++{ ++ if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM) { ++ cifs_sb->mnt_cifs_flags &= CIFS_MOUNT_SERVER_INUM; ++ cERROR(1, ("Autodisabling the use of server inode numbers on " ++ "%s. This server doesn't seem to support them " ++ "properly. Hardlinks will not be recognized on this " ++ "mount. Consider mounting with the \"noserverino\" " ++ "option to silence this message.", ++ cifs_sb->tcon->treeName)); ++ } ++} +--- a/fs/cifs/readdir.c ++++ b/fs/cifs/readdir.c +@@ -727,11 +727,12 @@ static int cifs_filldir(char *pfindEntry + cifs_dir_info_to_fattr(&fattr, (FILE_DIRECTORY_INFO *) + pfindEntry, cifs_sb); + +- /* FIXME: make _to_fattr functions fill this out */ +- if (pCifsF->srch_inf.info_level == SMB_FIND_FILE_ID_FULL_DIR_INFO) ++ if (inum && (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM)) { + fattr.cf_uniqueid = inum; +- else ++ } else { + fattr.cf_uniqueid = iunique(sb, ROOT_I); ++ cifs_autodisable_serverino(cifs_sb); ++ } + + ino = cifs_uniqueid_to_ino_t(fattr.cf_uniqueid); + tmp_dentry = cifs_readdir_lookup(file->f_dentry, &qstring, &fattr); diff --git a/queue-2.6.31/cifs-clear-server-inode-number-flag-while-autodisabling.patch b/queue-2.6.31/cifs-clear-server-inode-number-flag-while-autodisabling.patch new file mode 100644 index 00000000000..43d17508283 --- /dev/null +++ b/queue-2.6.31/cifs-clear-server-inode-number-flag-while-autodisabling.patch @@ -0,0 +1,34 @@ +From f534dc994397560343be4a3223b9bbaa8e739e1f Mon Sep 17 00:00:00 2001 +From: Suresh Jayaraman +Date: Mon, 16 Nov 2009 12:03:16 +0530 +Subject: cifs: clear server inode number flag while autodisabling + +From: Suresh Jayaraman + +commit f534dc994397560343be4a3223b9bbaa8e739e1f upstream. + +Fix the commit ec06aedd44 that intended to turn off querying for server inode +numbers when server doesn't consistently support inode numbers. Presumably +the commit didn't actually clear the CIFS_MOUNT_SERVER_INUM flag, perhaps a +typo. + +Signed-off-by: Suresh Jayaraman +Acked-by: Jeff Layton +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/misc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/cifs/misc.c ++++ b/fs/cifs/misc.c +@@ -710,7 +710,7 @@ void + cifs_autodisable_serverino(struct cifs_sb_info *cifs_sb) + { + if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM) { +- cifs_sb->mnt_cifs_flags &= CIFS_MOUNT_SERVER_INUM; ++ cifs_sb->mnt_cifs_flags &= ~CIFS_MOUNT_SERVER_INUM; + cERROR(1, ("Autodisabling the use of server inode numbers on " + "%s. This server doesn't seem to support them " + "properly. Hardlinks will not be recognized on this " diff --git a/queue-2.6.31/cifs-don-t-use-cifsgetsrvinodenumber-in-is_path_accessible.patch b/queue-2.6.31/cifs-don-t-use-cifsgetsrvinodenumber-in-is_path_accessible.patch new file mode 100644 index 00000000000..e692700d8e1 --- /dev/null +++ b/queue-2.6.31/cifs-don-t-use-cifsgetsrvinodenumber-in-is_path_accessible.patch @@ -0,0 +1,46 @@ +From f475f6775465283494346663f201ad04810d2e8a Mon Sep 17 00:00:00 2001 +From: Jeff Layton +Date: Fri, 6 Nov 2009 14:18:49 -0500 +Subject: cifs: don't use CIFSGetSrvInodeNumber in is_path_accessible + +From: Jeff Layton + +commit f475f6775465283494346663f201ad04810d2e8a upstream. + +Because it's lighter weight, CIFS tries to use CIFSGetSrvInodeNumber to +verify the accessibility of the root inode and then falls back to doing a +full QPathInfo if that fails with -EOPNOTSUPP. I have at least a report +of a server that returns NT_STATUS_INTERNAL_ERROR rather than something +that translates to EOPNOTSUPP. + +Rather than trying to be clever with that call, just have +is_path_accessible do a normal QPathInfo. That call is widely +supported and it shouldn't increase the overhead significantly. + +Signed-off-by: Jeff Layton +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/connect.c | 8 -------- + 1 file changed, 8 deletions(-) + +--- a/fs/cifs/connect.c ++++ b/fs/cifs/connect.c +@@ -2200,16 +2200,8 @@ is_path_accessible(int xid, struct cifsT + struct cifs_sb_info *cifs_sb, const char *full_path) + { + int rc; +- __u64 inode_num; + FILE_ALL_INFO *pfile_info; + +- rc = CIFSGetSrvInodeNumber(xid, tcon, full_path, &inode_num, +- cifs_sb->local_nls, +- cifs_sb->mnt_cifs_flags & +- CIFS_MOUNT_MAP_SPECIAL_CHR); +- if (rc != -EOPNOTSUPP) +- return rc; +- + pfile_info = kmalloc(sizeof(FILE_ALL_INFO), GFP_KERNEL); + if (pfile_info == NULL) + return -ENOMEM; diff --git a/queue-2.6.31/cifs-duplicate-data-on-appending-to-some-samba-servers.patch b/queue-2.6.31/cifs-duplicate-data-on-appending-to-some-samba-servers.patch new file mode 100644 index 00000000000..34f5ec6f112 --- /dev/null +++ b/queue-2.6.31/cifs-duplicate-data-on-appending-to-some-samba-servers.patch @@ -0,0 +1,52 @@ +From cea62343956c24452700c06cf028b72414c58a74 Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Tue, 24 Nov 2009 22:49:37 +0000 +Subject: CIFS: Duplicate data on appending to some Samba servers + +From: Steve French + +commit cea62343956c24452700c06cf028b72414c58a74 upstream. + +SMB writes are sent with a starting offset and length. When the server +supports the newer SMB trans2 posix open (rather than using the SMB +NTCreateX) a file can be opened with SMB_O_APPEND flag, and for that +case Samba server assumes that the offset sent in SMBWriteX is unneeded +since the write should go to the end of the file - which can cause +problems if the write was cached (since the beginning part of a +page could be written twice by the client mm). Jeff suggested that +masking the flag on posix open on the client is easiest for the time +being. Note that recent Samba server also had an unrelated problem with +SMB NTCreateX and append (see samba bugzilla bug number 6898) which +should not affect current Linux clients (unless cifs Unix Extensions +are disabled). + +The cifs client did not send the O_APPEND flag on posix open +before 2.6.29 so the fix is unneeded on early kernels. + +In the future, for the non-cached case (O_DIRECT, and forcedirectio mounts) +it would be possible and useful to send O_APPEND on posix open (for Windows +case: FILE_APPEND_DATA but not FILE_WRITE_DATA on SMB NTCreateX) but for +cached writes although the vfs sets the offset to end of file it +may fragment a write across pages - so we can't send O_APPEND on +open (could result in sending part of a page twice). + +Reviewed-by: Shirish Pargaonkar +Signed-off-by: Jeff Layton +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/dir.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/fs/cifs/dir.c ++++ b/fs/cifs/dir.c +@@ -212,8 +212,6 @@ int cifs_posix_open(char *full_path, str + posix_flags |= SMB_O_EXCL; + if (oflags & O_TRUNC) + posix_flags |= SMB_O_TRUNC; +- if (oflags & O_APPEND) +- posix_flags |= SMB_O_APPEND; + if (oflags & O_SYNC) + posix_flags |= SMB_O_SYNC; + if (oflags & O_DIRECTORY) diff --git a/queue-2.6.31/cifs-fix-oops-in-cifs_lookup-during-net-boot.patch b/queue-2.6.31/cifs-fix-oops-in-cifs_lookup-during-net-boot.patch new file mode 100644 index 00000000000..a13376c1018 --- /dev/null +++ b/queue-2.6.31/cifs-fix-oops-in-cifs_lookup-during-net-boot.patch @@ -0,0 +1,47 @@ +From 8e6c0332d5032aef2d3bc8f41771f999112c8c66 Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Tue, 24 Nov 2009 22:17:59 +0000 +Subject: CIFS: fix oops in cifs_lookup during net boot + +From: Steve French + +commit 8e6c0332d5032aef2d3bc8f41771f999112c8c66 upstream. + +Fixes bugzilla.kernel.org bug number 14641 + +Lookup called during network boot (network root filesystem +for diskless workstation) has case where nd is null in +lookup. This patch fixes that in cifs_lookup. + +(Shirish noted that 2.6.30 and 2.6.31 stable need the same check) + +Signed-off-by: Shirish Pargaonkar +Acked-by: Jeff Layton +Tested-by: Vladimir Stavrinov +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/dir.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/fs/cifs/dir.c ++++ b/fs/cifs/dir.c +@@ -648,7 +648,7 @@ cifs_lookup(struct inode *parent_dir_ino + * O_EXCL: optimize away the lookup, but don't hash the dentry. Let + * the VFS handle the create. + */ +- if (nd->flags & LOOKUP_EXCL) { ++ if (nd && (nd->flags & LOOKUP_EXCL)) { + d_instantiate(direntry, NULL); + return 0; + } +@@ -680,7 +680,7 @@ cifs_lookup(struct inode *parent_dir_ino + * reduction in network traffic in the other paths. + */ + if (pTcon->unix_ext) { +- if (!(nd->flags & (LOOKUP_PARENT | LOOKUP_DIRECTORY)) && ++ if (nd && !(nd->flags & (LOOKUP_PARENT | LOOKUP_DIRECTORY)) && + (nd->flags & LOOKUP_OPEN) && !pTcon->broken_posix_open && + (nd->intent.open.flags & O_CREAT)) { + rc = cifs_posix_open(full_path, &newInode, diff --git a/queue-2.6.31/gdth-prevent-negative-offsets-in-ioctl-cve-2009-3080.patch b/queue-2.6.31/gdth-prevent-negative-offsets-in-ioctl-cve-2009-3080.patch new file mode 100644 index 00000000000..67077b7f12b --- /dev/null +++ b/queue-2.6.31/gdth-prevent-negative-offsets-in-ioctl-cve-2009-3080.patch @@ -0,0 +1,31 @@ +From 690e744869f3262855b83b4fb59199cf142765b0 Mon Sep 17 00:00:00 2001 +From: Dave Jones +Date: Mon, 19 Oct 2009 19:55:13 -0400 +Subject: [SCSI] gdth: Prevent negative offsets in ioctl CVE-2009-3080 + +From: Dave Jones + +commit 690e744869f3262855b83b4fb59199cf142765b0 upstream. + +A negative offset could be used to index before the event buffer and +lead to a security breach. + +Signed-off-by: Dave Jones +Signed-off-by: James Bottomley +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/gdth.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/scsi/gdth.c ++++ b/drivers/scsi/gdth.c +@@ -2900,7 +2900,7 @@ static int gdth_read_event(gdth_ha_str * + eindex = handle; + estr->event_source = 0; + +- if (eindex >= MAX_EVENTS) { ++ if (eindex < 0 || eindex >= MAX_EVENTS) { + spin_unlock_irqrestore(&ha->smp_lock, flags); + return eindex; + } diff --git a/queue-2.6.31/highmem-fix-debug_kmap_atomic-to-also-handle-km_irq_pte-km_nmi-and-km_nmi_pte.patch b/queue-2.6.31/highmem-fix-debug_kmap_atomic-to-also-handle-km_irq_pte-km_nmi-and-km_nmi_pte.patch new file mode 100644 index 00000000000..952122bf0d4 --- /dev/null +++ b/queue-2.6.31/highmem-fix-debug_kmap_atomic-to-also-handle-km_irq_pte-km_nmi-and-km_nmi_pte.patch @@ -0,0 +1,56 @@ +From d4515646699b6ad7b1a98ceb871296b957f3ef47 Mon Sep 17 00:00:00 2001 +From: Soeren Sandmann +Date: Wed, 28 Oct 2009 18:56:35 +0100 +Subject: highmem: Fix debug_kmap_atomic() to also handle KM_IRQ_PTE, KM_NMI, and KM_NMI_PTE + +From: Soeren Sandmann + +commit d4515646699b6ad7b1a98ceb871296b957f3ef47 upstream. + +Previously calling debug_kmap_atomic() with these types would +cause spurious warnings. + +(triggered by SysProf using perf events) + +Signed-off-by: Soeren Sandmann Pedersen +Cc: Linus Torvalds +Cc: a.p.zijlstra@chello.nl +LKML-Reference: +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + mm/highmem.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +--- a/mm/highmem.c ++++ b/mm/highmem.c +@@ -432,10 +432,15 @@ void debug_kmap_atomic(enum km_type type + return; + + if (unlikely(in_interrupt())) { +- if (in_irq()) { ++ if (in_nmi()) { ++ if (type != KM_NMI && type != KM_NMI_PTE) { ++ WARN_ON(1); ++ warn_count--; ++ } ++ } else if (in_irq()) { + if (type != KM_IRQ0 && type != KM_IRQ1 && + type != KM_BIO_SRC_IRQ && type != KM_BIO_DST_IRQ && +- type != KM_BOUNCE_READ) { ++ type != KM_BOUNCE_READ && type != KM_IRQ_PTE) { + WARN_ON(1); + warn_count--; + } +@@ -452,7 +457,9 @@ void debug_kmap_atomic(enum km_type type + } + + if (type == KM_IRQ0 || type == KM_IRQ1 || type == KM_BOUNCE_READ || +- type == KM_BIO_SRC_IRQ || type == KM_BIO_DST_IRQ) { ++ type == KM_BIO_SRC_IRQ || type == KM_BIO_DST_IRQ || ++ type == KM_IRQ_PTE || type == KM_NMI || ++ type == KM_NMI_PTE ) { + if (!irqs_disabled()) { + WARN_ON(1); + warn_count--; diff --git a/queue-2.6.31/highmem-fix-race-in-debug_kmap_atomic-which-could-cause-warn_count-to-underflow.patch b/queue-2.6.31/highmem-fix-race-in-debug_kmap_atomic-which-could-cause-warn_count-to-underflow.patch new file mode 100644 index 00000000000..3286b37c9ff --- /dev/null +++ b/queue-2.6.31/highmem-fix-race-in-debug_kmap_atomic-which-could-cause-warn_count-to-underflow.patch @@ -0,0 +1,42 @@ +From 5ebd4c22897dce65845807a9bd3a31cc4e142b53 Mon Sep 17 00:00:00 2001 +From: Soeren Sandmann +Date: Wed, 28 Oct 2009 18:55:36 +0100 +Subject: highmem: Fix race in debug_kmap_atomic() which could cause warn_count to underflow + +From: Soeren Sandmann + +commit 5ebd4c22897dce65845807a9bd3a31cc4e142b53 upstream. + +debug_kmap_atomic() tries to prevent ever printing more than 10 +warnings, but it does so by testing whether an unsigned integer +is equal to 0. However, if the warning is caused by a nested +IRQ, then this counter may underflow and the stream of warnings +will never end. + +Fix that by using a signed integer instead. + +Signed-off-by: Soeren Sandmann Pedersen +Cc: Linus Torvalds +Cc: a.p.zijlstra@chello.nl +LKML-Reference: +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + mm/highmem.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/mm/highmem.c ++++ b/mm/highmem.c +@@ -426,9 +426,9 @@ void __init page_address_init(void) + + void debug_kmap_atomic(enum km_type type) + { +- static unsigned warn_count = 10; ++ static int warn_count = 10; + +- if (unlikely(warn_count == 0)) ++ if (unlikely(warn_count < 0)) + return; + + if (unlikely(in_interrupt())) { diff --git a/queue-2.6.31/jffs2-fix-memory-corruption-in-jffs2_read_inode_range.patch b/queue-2.6.31/jffs2-fix-memory-corruption-in-jffs2_read_inode_range.patch new file mode 100644 index 00000000000..46db54690e1 --- /dev/null +++ b/queue-2.6.31/jffs2-fix-memory-corruption-in-jffs2_read_inode_range.patch @@ -0,0 +1,84 @@ +From 199bc9ff5ca5e4b3bcaff8927b2983c65f34c263 Mon Sep 17 00:00:00 2001 +From: David Woodhouse +Date: Mon, 30 Nov 2009 09:06:40 +0000 +Subject: jffs2: Fix memory corruption in jffs2_read_inode_range() + +From: David Woodhouse + +commit 199bc9ff5ca5e4b3bcaff8927b2983c65f34c263 upstream. + +In 2.6.23 kernel, commit a32ea1e1f925399e0d81ca3f7394a44a6dafa12c +("Fix read/truncate race") fixed a race in the generic code, and as a +side effect, now do_generic_file_read() can ask us to readpage() past +the i_size. This seems to be correctly handled by the block routines +(e.g. block_read_full_page() fills the page with zeroes in case if +somebody is trying to read past the last inode's block). + +JFFS2 doesn't handle this; it assumes that it won't be asked to read +pages which don't exist -- and thus that there will be at least _one_ +valid 'frag' on the page it's being asked to read. It will fill any +holes with the following memset: + + memset(buf, 0, min(end, frag->ofs + frag->size) - offset); + +When the 'closest smaller match' returned by jffs2_lookup_node_frag() is +actually on a previous page and ends before 'offset', that results in: + + memset(buf, 0, ); + +Hopefully, in most cases the corruption is fatal, and quickly causing +random oopses, like this: + + root@10.0.0.4:~/ltp-fs-20090531# ./testcases/kernel/fs/ftest/ftest01 + Unable to handle kernel paging request for data at address 0x00000008 + Faulting instruction address: 0xc01cd980 + Oops: Kernel access of bad area, sig: 11 [#1] + [...] + NIP [c01cd980] rb_insert_color+0x38/0x184 + LR [c0043978] enqueue_hrtimer+0x88/0xc4 + Call Trace: + [c6c63b60] [c004f9a8] tick_sched_timer+0xa0/0xe4 (unreliable) + [c6c63b80] [c0043978] enqueue_hrtimer+0x88/0xc4 + [c6c63b90] [c0043a48] __run_hrtimer+0x94/0xbc + [c6c63bb0] [c0044628] hrtimer_interrupt+0x140/0x2b8 + [c6c63c10] [c000f8e8] timer_interrupt+0x13c/0x254 + [c6c63c30] [c001352c] ret_from_except+0x0/0x14 + --- Exception: 901 at memset+0x38/0x5c + LR = jffs2_read_inode_range+0x144/0x17c + [c6c63cf0] [00000000] (null) (unreliable) + +This patch fixes the issue, plus fixes all LTP tests on NAND/UBI with +JFFS2 filesystem that were failing since 2.6.23 (seems like the bug +above also broke the truncation). + +Reported-By: Anton Vorontsov +Tested-By: Anton Vorontsov +Signed-off-by: David Woodhouse +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + fs/jffs2/read.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/fs/jffs2/read.c ++++ b/fs/jffs2/read.c +@@ -164,12 +164,15 @@ int jffs2_read_inode_range(struct jffs2_ + + /* XXX FIXME: Where a single physical node actually shows up in two + frags, we read it twice. Don't do that. */ +- /* Now we're pointing at the first frag which overlaps our page */ ++ /* Now we're pointing at the first frag which overlaps our page ++ * (or perhaps is before it, if we've been asked to read off the ++ * end of the file). */ + while(offset < end) { + D2(printk(KERN_DEBUG "jffs2_read_inode_range: offset %d, end %d\n", offset, end)); +- if (unlikely(!frag || frag->ofs > offset)) { ++ if (unlikely(!frag || frag->ofs > offset || ++ frag->ofs + frag->size <= offset)) { + uint32_t holesize = end - offset; +- if (frag) { ++ if (frag && frag->ofs > offset) { + D1(printk(KERN_NOTICE "Eep. Hole in ino #%u fraglist. frag->ofs = 0x%08x, offset = 0x%08x\n", f->inocache->ino, frag->ofs, offset)); + holesize = min(holesize, frag->ofs - offset); + } diff --git a/queue-2.6.31/md-don-t-clear-endpoint-for-resync-when-resync-is-interrupted.patch b/queue-2.6.31/md-don-t-clear-endpoint-for-resync-when-resync-is-interrupted.patch new file mode 100644 index 00000000000..855f4f3580e --- /dev/null +++ b/queue-2.6.31/md-don-t-clear-endpoint-for-resync-when-resync-is-interrupted.patch @@ -0,0 +1,44 @@ +From 24395a85d8efe6eee477ea35c73d045a8dd7a3a1 Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Fri, 6 Nov 2009 14:59:27 +1100 +Subject: md: don't clear endpoint for resync when resync is interrupted. + +From: NeilBrown + +commit 24395a85d8efe6eee477ea35c73d045a8dd7a3a1 upstream. + +If a 'sync_max' has been set (via sysfs), it is wrong to clear it +until a resync (or reshape or recovery ...) actually reached that +point. +So if a resync is interrupted (e.g. by device failure), +leave 'resync_max' unchanged. + +This is particularly important for 'reshape' operations that do not +change the size of the array. For such operations mdadm needs to +monitor the reshape taking rolling backups of the section being +reshaped. If resync_max gets cleared, the reshape can get ahead of +mdadm and then the backups that mdadm creates are useless. + +This is suitable for 2.6.31.y stable kernels. + +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/md.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/md/md.c ++++ b/drivers/md/md.c +@@ -6495,8 +6495,9 @@ void md_do_sync(mddev_t *mddev) + skip: + mddev->curr_resync = 0; + mddev->curr_resync_completed = 0; +- mddev->resync_min = 0; +- mddev->resync_max = MaxSector; ++ if (!test_bit(MD_RECOVERY_INTR, &mddev->recovery)) ++ /* We completed so max setting can be forgotten. */ ++ mddev->resync_max = MaxSector; + sysfs_notify(&mddev->kobj, NULL, "sync_completed"); + wake_up(&resync_wait); + set_bit(MD_RECOVERY_DONE, &mddev->recovery); diff --git a/queue-2.6.31/md-raid1-raid10-add-a-cond_resched.patch b/queue-2.6.31/md-raid1-raid10-add-a-cond_resched.patch new file mode 100644 index 00000000000..eb2e2d239d5 --- /dev/null +++ b/queue-2.6.31/md-raid1-raid10-add-a-cond_resched.patch @@ -0,0 +1,43 @@ +From 1d9d52416c0445019ccc1f0fddb9a227456eb61b Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Fri, 16 Oct 2009 15:55:32 +1100 +Subject: md/raid1/raid10: add a cond_resched + +From: NeilBrown + +commit 1d9d52416c0445019ccc1f0fddb9a227456eb61b upstream. + +During 'check' of a raid1 or raid10 it is possible for the management +thread to spend a lot of time running 'memcmp' on blocks from +different devices, so make sure the thread has a chance to schedule. +raid5d already has a cond_resched (in process_stripe). + +Reported-By: Lee Howard +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/raid1.c | 1 + + drivers/md/raid10.c | 1 + + 2 files changed, 2 insertions(+) + +--- a/drivers/md/raid10.c ++++ b/drivers/md/raid10.c +@@ -1630,6 +1630,7 @@ static void raid10d(mddev_t *mddev) + generic_make_request(bio); + } + } ++ cond_resched(); + } + if (unplug) + unplug_slaves(mddev); +--- a/drivers/md/raid1.c ++++ b/drivers/md/raid1.c +@@ -1676,6 +1676,7 @@ static void raid1d(mddev_t *mddev) + generic_make_request(bio); + } + } ++ cond_resched(); + } + if (unplug) + unplug_slaves(mddev); diff --git a/queue-2.6.31/md-raid5-make-sure-curr_sync_completes-is-uptodate-when-reshape-starts.patch b/queue-2.6.31/md-raid5-make-sure-curr_sync_completes-is-uptodate-when-reshape-starts.patch new file mode 100644 index 00000000000..db4c2a29bb9 --- /dev/null +++ b/queue-2.6.31/md-raid5-make-sure-curr_sync_completes-is-uptodate-when-reshape-starts.patch @@ -0,0 +1,36 @@ +From 8dee7211467a56b7eb4e4359efb0aa4a72e1b6f3 Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Fri, 6 Nov 2009 14:59:29 +1100 +Subject: md/raid5: make sure curr_sync_completes is uptodate when reshape starts + +From: NeilBrown + +commit 8dee7211467a56b7eb4e4359efb0aa4a72e1b6f3 upstream. + +This value is visible through sysfs and is used by mdadm +when it manages a reshape (backing up data that is about to be +rearranged). So it is important that it is always correct. +Current it does not get updated properly when a reshape +starts which can cause problems when assembling an array +that is in the middle of being reshaped. + +This is suitable for 2.6.31.y stable kernels. + +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/raid5.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/md/raid5.c ++++ b/drivers/md/raid5.c +@@ -3790,6 +3790,8 @@ static sector_t reshape_request(mddev_t + sector_nr = conf->reshape_progress; + sector_div(sector_nr, new_data_disks); + if (sector_nr) { ++ mddev->curr_resync_completed = sector_nr; ++ sysfs_notify(&mddev->kobj, NULL, "sync_completed"); + *skipped = 1; + return sector_nr; + } diff --git a/queue-2.6.31/nilfs2-fix-kernel-oops-in-error-case-of-nilfs_ioctl_move_blocks.patch b/queue-2.6.31/nilfs2-fix-kernel-oops-in-error-case-of-nilfs_ioctl_move_blocks.patch new file mode 100644 index 00000000000..1e2cca46d5f --- /dev/null +++ b/queue-2.6.31/nilfs2-fix-kernel-oops-in-error-case-of-nilfs_ioctl_move_blocks.patch @@ -0,0 +1,90 @@ +From 5399dd1fc8f5e812db931225ef5f67d89f3b1a56 Mon Sep 17 00:00:00 2001 +From: Ryusuke Konishi +Date: Sat, 7 Nov 2009 18:45:16 +0900 +Subject: nilfs2: fix kernel oops in error case of nilfs_ioctl_move_blocks + +From: Ryusuke Konishi + +commit 5399dd1fc8f5e812db931225ef5f67d89f3b1a56 upstream. + +This fixes a kernel oops reported by Markus Trippelsdorf in the email +titled "[NILFS users] kernel Oops while running nilfs_cleanerd". + +The oops was caused by a bug of error path in +nilfs_ioctl_move_blocks() function, which was inlined in +nilfs_ioctl_clean_segments(). + +nilfs_ioctl_move_blocks checks duplication of blocks which will be +moved in garbage collection. But, the check should have be done +within nilfs_ioctl_move_inode_block() to prevent list corruption among +buffers storing the target blocks. + +To fix the kernel oops, this moves forward the duplication check +before the list insertion. + +I also tested this for stable trees [2.6.30, 2.6.31]. + +Reported-by: Markus Trippelsdorf +Signed-off-by: Ryusuke Konishi +Signed-off-by: Greg Kroah-Hartman + +--- + fs/nilfs2/ioctl.c | 30 +++++++++++++----------------- + 1 file changed, 13 insertions(+), 17 deletions(-) + +--- a/fs/nilfs2/ioctl.c ++++ b/fs/nilfs2/ioctl.c +@@ -297,7 +297,18 @@ static int nilfs_ioctl_move_inode_block( + (unsigned long long)vdesc->vd_vblocknr); + return ret; + } +- bh->b_private = vdesc; ++ if (unlikely(!list_empty(&bh->b_assoc_buffers))) { ++ printk(KERN_CRIT "%s: conflicting %s buffer: ino=%llu, " ++ "cno=%llu, offset=%llu, blocknr=%llu, vblocknr=%llu\n", ++ __func__, vdesc->vd_flags ? "node" : "data", ++ (unsigned long long)vdesc->vd_ino, ++ (unsigned long long)vdesc->vd_cno, ++ (unsigned long long)vdesc->vd_offset, ++ (unsigned long long)vdesc->vd_blocknr, ++ (unsigned long long)vdesc->vd_vblocknr); ++ brelse(bh); ++ return -EEXIST; ++ } + list_add_tail(&bh->b_assoc_buffers, buffers); + return 0; + } +@@ -335,24 +346,10 @@ static int nilfs_ioctl_move_blocks(struc + list_for_each_entry_safe(bh, n, &buffers, b_assoc_buffers) { + ret = nilfs_gccache_wait_and_mark_dirty(bh); + if (unlikely(ret < 0)) { +- if (ret == -EEXIST) { +- vdesc = bh->b_private; +- printk(KERN_CRIT +- "%s: conflicting %s buffer: " +- "ino=%llu, cno=%llu, offset=%llu, " +- "blocknr=%llu, vblocknr=%llu\n", +- __func__, +- vdesc->vd_flags ? "node" : "data", +- (unsigned long long)vdesc->vd_ino, +- (unsigned long long)vdesc->vd_cno, +- (unsigned long long)vdesc->vd_offset, +- (unsigned long long)vdesc->vd_blocknr, +- (unsigned long long)vdesc->vd_vblocknr); +- } ++ WARN_ON(ret == -EEXIST); + goto failed; + } + list_del_init(&bh->b_assoc_buffers); +- bh->b_private = NULL; + brelse(bh); + } + return nmembs; +@@ -360,7 +357,6 @@ static int nilfs_ioctl_move_blocks(struc + failed: + list_for_each_entry_safe(bh, n, &buffers, b_assoc_buffers) { + list_del_init(&bh->b_assoc_buffers); +- bh->b_private = NULL; + brelse(bh); + } + return ret; diff --git a/queue-2.6.31/rtl8187-fix-kernel-oops-when-device-is-removed-when-leds-enabled.patch b/queue-2.6.31/rtl8187-fix-kernel-oops-when-device-is-removed-when-leds-enabled.patch new file mode 100644 index 00000000000..c0bb159cbc3 --- /dev/null +++ b/queue-2.6.31/rtl8187-fix-kernel-oops-when-device-is-removed-when-leds-enabled.patch @@ -0,0 +1,52 @@ +From 37b12dd2b07b4d7dc222a5f7f88b25cec532b2aa Mon Sep 17 00:00:00 2001 +From: Larry Finger +Date: Wed, 4 Nov 2009 00:00:25 -0600 +Subject: rtl8187: Fix kernel oops when device is removed when LEDS enabled + +From: Larry Finger + +commit 37b12dd2b07b4d7dc222a5f7f88b25cec532b2aa upstream. + +As reported by Rick Farina (sidhayn@gmail.com), removing the RTL8187 +USB stick, or unloading the driver rtl8187 using rmmod will cause a +kernel oops. There are at least two forms of the failure, (1) BUG: +Scheduling while atomic, and (2) a fatal kernel page fault. This +problem is reported in Bugzilla #14539. + +This problem does not occur for kernel 2.6.31, but does for 2.6.32-rc2, +thus it is technically a regression; however, bisection did not locate +any faulty patch. The fix was found by comparing the faulty code in +rtl8187 with p54usb. My interpretation is that the handling of work +queues in mac80211 changed enough to the LEDs to be unregistered +before tasks on the work queues are cancelled. Previously, these +actions could be done in either order. + +(Herton Ronaldo Krzesinski reports that the +code is the same in 2.6.31, so this may be a candidate for 2.6.31.x. +-- JWL) + +Signed-off-by: Larry Finger +Reported-by: Rick Farina +Tested-by: Rick Farina +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/rtl818x/rtl8187_leds.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/wireless/rtl818x/rtl8187_leds.c ++++ b/drivers/net/wireless/rtl818x/rtl8187_leds.c +@@ -210,10 +210,10 @@ void rtl8187_leds_exit(struct ieee80211_ + + /* turn the LED off before exiting */ + queue_delayed_work(dev->workqueue, &priv->led_off, 0); +- cancel_delayed_work_sync(&priv->led_off); +- cancel_delayed_work_sync(&priv->led_on); + rtl8187_unregister_led(&priv->led_rx); + rtl8187_unregister_led(&priv->led_tx); ++ cancel_delayed_work_sync(&priv->led_off); ++ cancel_delayed_work_sync(&priv->led_on); + } + #endif /* def CONFIG_RTL8187_LED */ + diff --git a/queue-2.6.31/series b/queue-2.6.31/series new file mode 100644 index 00000000000..a47099b9c10 --- /dev/null +++ b/queue-2.6.31/series @@ -0,0 +1,31 @@ +nilfs2-fix-kernel-oops-in-error-case-of-nilfs_ioctl_move_blocks.patch +cifs-don-t-use-cifsgetsrvinodenumber-in-is_path_accessible.patch +cifs-clean-up-handling-when-server-doesn-t-consistently-support-inode-numbers.patch +cifs-clear-server-inode-number-flag-while-autodisabling.patch +cifs-fix-oops-in-cifs_lookup-during-net-boot.patch +cifs-duplicate-data-on-appending-to-some-samba-servers.patch +gdth-prevent-negative-offsets-in-ioctl-cve-2009-3080.patch +rtl8187-fix-kernel-oops-when-device-is-removed-when-leds-enabled.patch +md-don-t-clear-endpoint-for-resync-when-resync-is-interrupted.patch +md-raid5-make-sure-curr_sync_completes-is-uptodate-when-reshape-starts.patch +md-raid1-raid10-add-a-cond_resched.patch +alsa-usb-audio-fix-combine_word-problem.patch +alsa-hda-dell-studio-1557-hd-audio-quirk.patch +alsa-aaci-fix-ac97-multiple-open-bug.patch +alsa-aaci-fix-recording-bug.patch +jffs2-fix-memory-corruption-in-jffs2_read_inode_range.patch +sound-rawmidi-disable-active-sensing-on-close-by-default.patch +sound-rawmidi-fix-checking-of-o_append-when-opening-midi-device.patch +sound-rawmidi-fix-double-init-when-opening-midi-device-with-o_append.patch +sound-rawmidi-fix-midi-device-o_append-error-handling.patch +highmem-fix-race-in-debug_kmap_atomic-which-could-cause-warn_count-to-underflow.patch +highmem-fix-debug_kmap_atomic-to-also-handle-km_irq_pte-km_nmi-and-km_nmi_pte.patch +v4l-dvb-13169-bttv-fix-potential-out-of-order-field-processing.patch +v4l-dvb-13170-bttv-fix-reversed-polarity-error-when-switching-video-standard.patch +v4l-dvb-13109-tda18271-fix-signedness-issue-in-tda18271_rf_tracking_filters_init.patch +v4l-dvb-13107-tda18271-fix-overflow-in-fm-radio-frequency-calculation.patch +v4l-dvb-13190-em28xx-fix-panic-that-can-occur-when-starting-audio-streaming.patch +v4l-dvb-13240-firedtv-fix-regression-tuning-fails-due-to-bogus-error-return.patch +v4l-dvb-13079-dib0700-fixed-xc2028-firmware-loading-kernel-oops.patch +v4l-dvb-13230-s2255drv-don-t-conditionalize-video-buffer-completion-on-waiting-processes.patch +uids-prevent-tear-down-race.patch diff --git a/queue-2.6.31/sound-rawmidi-disable-active-sensing-on-close-by-default.patch b/queue-2.6.31/sound-rawmidi-disable-active-sensing-on-close-by-default.patch new file mode 100644 index 00000000000..e3d53cda783 --- /dev/null +++ b/queue-2.6.31/sound-rawmidi-disable-active-sensing-on-close-by-default.patch @@ -0,0 +1,43 @@ +From 2d4b842014dc76a81abced47ef27177eedb9deba Mon Sep 17 00:00:00 2001 +From: Clemens Ladisch +Date: Mon, 13 Jul 2009 13:52:46 +0200 +Subject: sound: rawmidi: disable active-sensing-on-close by default + +From: Clemens Ladisch + +commit 2d4b842014dc76a81abced47ef27177eedb9deba upstream. + +Sending an Active Sensing message when closing a port can interfere with +the following data if the port is reopened and a note-on is sent before +the device's timeout has elapsed. Therefore, it is better to disable +this setting by default. + +Signed-off-by: Clemens Ladisch +Signed-off-by: Takashi Iwai + +--- + sound/core/rawmidi.c | 2 +- + sound/core/seq/seq_midi.c | 1 + + 2 files changed, 2 insertions(+), 1 deletion(-) + +--- a/sound/core/rawmidi.c ++++ b/sound/core/rawmidi.c +@@ -274,7 +274,7 @@ static int open_substream(struct snd_raw + return err; + substream->opened = 1; + if (substream->use_count++ == 0) +- substream->active_sensing = 1; ++ substream->active_sensing = 0; + if (mode & SNDRV_RAWMIDI_LFLG_APPEND) + substream->append = 1; + rmidi->streams[substream->stream].substream_opened++; +--- a/sound/core/seq/seq_midi.c ++++ b/sound/core/seq/seq_midi.c +@@ -236,6 +236,7 @@ static int midisynth_use(void *private_d + memset(¶ms, 0, sizeof(params)); + params.avail_min = 1; + params.buffer_size = output_buffer_size; ++ params.no_active_sensing = 1; + if ((err = snd_rawmidi_output_params(msynth->output_rfile.output, ¶ms)) < 0) { + snd_rawmidi_kernel_release(&msynth->output_rfile); + return err; diff --git a/queue-2.6.31/sound-rawmidi-fix-checking-of-o_append-when-opening-midi-device.patch b/queue-2.6.31/sound-rawmidi-fix-checking-of-o_append-when-opening-midi-device.patch new file mode 100644 index 00000000000..adfca947ff5 --- /dev/null +++ b/queue-2.6.31/sound-rawmidi-fix-checking-of-o_append-when-opening-midi-device.patch @@ -0,0 +1,36 @@ +From 16fb109644b5644e42ececeff644514de6f4bd03 Mon Sep 17 00:00:00 2001 +From: Clemens Ladisch +Date: Wed, 21 Oct 2009 09:10:16 +0200 +Subject: sound: rawmidi: fix checking of O_APPEND when opening MIDI device + +From: Clemens Ladisch + +commit 16fb109644b5644e42ececeff644514de6f4bd03 upstream. + +Commit 9a1b64caac82aa02cb74587ffc798e6f42c6170a in 2.6.30 dropped the +check that a substream must already have been opened with O_APPEND to be +able to open it a second time. + +This would make it possible for a substream to be switched to append +mode, which would mean that non-atomic writes would fail unexpectedly. + +Signed-off-by: Clemens Ladisch +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/core/rawmidi.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/sound/core/rawmidi.c ++++ b/sound/core/rawmidi.c +@@ -248,7 +248,8 @@ static int assign_substream(struct snd_r + list_for_each_entry(substream, &s->substreams, list) { + if (substream->opened) { + if (stream == SNDRV_RAWMIDI_STREAM_INPUT || +- !(mode & SNDRV_RAWMIDI_LFLG_APPEND)) ++ !(mode & SNDRV_RAWMIDI_LFLG_APPEND) || ++ !substream->append) + continue; + } + if (subdevice < 0 || subdevice == substream->number) { diff --git a/queue-2.6.31/sound-rawmidi-fix-double-init-when-opening-midi-device-with-o_append.patch b/queue-2.6.31/sound-rawmidi-fix-double-init-when-opening-midi-device-with-o_append.patch new file mode 100644 index 00000000000..7bc9dec6900 --- /dev/null +++ b/queue-2.6.31/sound-rawmidi-fix-double-init-when-opening-midi-device-with-o_append.patch @@ -0,0 +1,57 @@ +From 8579d2d7779d7ff41ea2a0183015e0e5038f1043 Mon Sep 17 00:00:00 2001 +From: Clemens Ladisch +Date: Wed, 21 Oct 2009 09:09:38 +0200 +Subject: sound: rawmidi: fix double init when opening MIDI device with O_APPEND + +From: Clemens Ladisch + +commit 8579d2d7779d7ff41ea2a0183015e0e5038f1043 upstream. + +Commit 9a1b64caac82aa02cb74587ffc798e6f42c6170a in 2.6.30 moved the +substream initialization code to where it would be executed every time +the substream is opened. + +This had the consequence that any further opening would drop and leak +the data in the existing buffer, and that the device driver's open +callback would be called multiple times, unexpectedly. + +Signed-off-by: Clemens Ladisch +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/core/rawmidi.c | 22 ++++++++++++---------- + 1 file changed, 12 insertions(+), 10 deletions(-) + +--- a/sound/core/rawmidi.c ++++ b/sound/core/rawmidi.c +@@ -267,17 +267,19 @@ static int open_substream(struct snd_raw + { + int err; + +- err = snd_rawmidi_runtime_create(substream); +- if (err < 0) +- return err; +- err = substream->ops->open(substream); +- if (err < 0) +- return err; +- substream->opened = 1; +- if (substream->use_count++ == 0) ++ if (substream->use_count == 0) { ++ err = snd_rawmidi_runtime_create(substream); ++ if (err < 0) ++ return err; ++ err = substream->ops->open(substream); ++ if (err < 0) ++ return err; ++ substream->opened = 1; + substream->active_sensing = 0; +- if (mode & SNDRV_RAWMIDI_LFLG_APPEND) +- substream->append = 1; ++ if (mode & SNDRV_RAWMIDI_LFLG_APPEND) ++ substream->append = 1; ++ } ++ substream->use_count++; + rmidi->streams[substream->stream].substream_opened++; + return 0; + } diff --git a/queue-2.6.31/sound-rawmidi-fix-midi-device-o_append-error-handling.patch b/queue-2.6.31/sound-rawmidi-fix-midi-device-o_append-error-handling.patch new file mode 100644 index 00000000000..a280357e289 --- /dev/null +++ b/queue-2.6.31/sound-rawmidi-fix-midi-device-o_append-error-handling.patch @@ -0,0 +1,88 @@ +From b7fe750fcceda4fa6bef399b0e2812562728ea82 Mon Sep 17 00:00:00 2001 +From: Clemens Ladisch +Date: Wed, 21 Oct 2009 09:11:43 +0200 +Subject: sound: rawmidi: fix MIDI device O_APPEND error handling + +From: Clemens Ladisch + +commit b7fe750fcceda4fa6bef399b0e2812562728ea82 upstream. + +Commit 9a1b64caac82aa02cb74587ffc798e6f42c6170a in 2.6.30 broke the +error handling code in rawmidi_open_priv(). + +If only the output substream of a RawMIDI device has been opened and +if this device is then opened with O_RDWR | O_APPEND and if the +initialization of the input substream fails (either because of low +memory or because the device driver's open callback fails), then the +runtime structure of the already open output substream will be freed +and all following writes through the first handle will cause +snd_rawmidi_write() to use the NULL runtime pointer. + +Signed-off-by: Clemens Ladisch +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/core/rawmidi.c | 19 +++++++------------ + 1 file changed, 7 insertions(+), 12 deletions(-) + +--- a/sound/core/rawmidi.c ++++ b/sound/core/rawmidi.c +@@ -272,8 +272,10 @@ static int open_substream(struct snd_raw + if (err < 0) + return err; + err = substream->ops->open(substream); +- if (err < 0) ++ if (err < 0) { ++ snd_rawmidi_runtime_free(substream); + return err; ++ } + substream->opened = 1; + substream->active_sensing = 0; + if (mode & SNDRV_RAWMIDI_LFLG_APPEND) +@@ -300,27 +302,27 @@ static int rawmidi_open_priv(struct snd_ + SNDRV_RAWMIDI_STREAM_INPUT, + mode, &sinput); + if (err < 0) +- goto __error; ++ return err; + } + if (mode & SNDRV_RAWMIDI_LFLG_OUTPUT) { + err = assign_substream(rmidi, subdevice, + SNDRV_RAWMIDI_STREAM_OUTPUT, + mode, &soutput); + if (err < 0) +- goto __error; ++ return err; + } + + if (sinput) { + err = open_substream(rmidi, sinput, mode); + if (err < 0) +- goto __error; ++ return err; + } + if (soutput) { + err = open_substream(rmidi, soutput, mode); + if (err < 0) { + if (sinput) + close_substream(rmidi, sinput, 0); +- goto __error; ++ return err; + } + } + +@@ -328,13 +330,6 @@ static int rawmidi_open_priv(struct snd_ + rfile->input = sinput; + rfile->output = soutput; + return 0; +- +- __error: +- if (sinput && sinput->runtime) +- snd_rawmidi_runtime_free(sinput); +- if (soutput && soutput->runtime) +- snd_rawmidi_runtime_free(soutput); +- return err; + } + + /* called from sound/core/seq/seq_midi.c */ diff --git a/queue-2.6.31/uids-prevent-tear-down-race.patch b/queue-2.6.31/uids-prevent-tear-down-race.patch new file mode 100644 index 00000000000..db8ff71f11a --- /dev/null +++ b/queue-2.6.31/uids-prevent-tear-down-race.patch @@ -0,0 +1,70 @@ +From b00bc0b237055b4c45816325ee14f0bd83e6f590 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Mon, 2 Nov 2009 13:01:56 +0100 +Subject: uids: Prevent tear down race + +From: Thomas Gleixner + +commit b00bc0b237055b4c45816325ee14f0bd83e6f590 upstream. + +Ingo triggered the following warning: + +WARNING: at lib/debugobjects.c:255 debug_print_object+0x42/0x50() +Hardware name: System Product Name +ODEBUG: init active object type: timer_list +Modules linked in: +Pid: 2619, comm: dmesg Tainted: G W 2.6.32-rc5-tip+ #5298 +Call Trace: + [<81035443>] warn_slowpath_common+0x6a/0x81 + [<8120e483>] ? debug_print_object+0x42/0x50 + [<81035498>] warn_slowpath_fmt+0x29/0x2c + [<8120e483>] debug_print_object+0x42/0x50 + [<8120ec2a>] __debug_object_init+0x279/0x2d7 + [<8120ecb3>] debug_object_init+0x13/0x18 + [<810409d2>] init_timer_key+0x17/0x6f + [<81041526>] free_uid+0x50/0x6c + [<8104ed2d>] put_cred_rcu+0x61/0x72 + [<81067fac>] rcu_do_batch+0x70/0x121 + +debugobjects warns about an enqueued timer being initialized. If +CONFIG_USER_SCHED=y the user management code uses delayed work to +remove the user from the hash table and tear down the sysfs objects. + +free_uid is called from RCU and initializes/schedules delayed work if +the usage count of the user_struct is 0. The init/schedule happens +outside of the uidhash_lock protected region which allows a concurrent +caller of find_user() to reference the about to be destroyed +user_struct w/o preventing the work from being scheduled. If the next +free_uid call happens before the work timer expired then the active +timer is initialized and the work scheduled again. + +The race was introduced in commit 5cb350ba (sched: group scheduling, +sysfs tunables) and made more prominent by commit 3959214f (sched: +delayed cleanup of user_struct) + +Move the init/schedule_delayed_work inside of the uidhash_lock +protected region to prevent the race. + +Signed-off-by: Thomas Gleixner +Acked-by: Dhaval Giani +Cc: Paul E. McKenney +Cc: Kay Sievers +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/user.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/user.c ++++ b/kernel/user.c +@@ -330,9 +330,9 @@ done: + */ + static void free_user(struct user_struct *up, unsigned long flags) + { +- spin_unlock_irqrestore(&uidhash_lock, flags); + INIT_DELAYED_WORK(&up->work, cleanup_user_struct); + schedule_delayed_work(&up->work, msecs_to_jiffies(1000)); ++ spin_unlock_irqrestore(&uidhash_lock, flags); + } + + #else /* CONFIG_USER_SCHED && CONFIG_SYSFS */ diff --git a/queue-2.6.31/v4l-dvb-13079-dib0700-fixed-xc2028-firmware-loading-kernel-oops.patch b/queue-2.6.31/v4l-dvb-13079-dib0700-fixed-xc2028-firmware-loading-kernel-oops.patch new file mode 100644 index 00000000000..c427f7e50a8 --- /dev/null +++ b/queue-2.6.31/v4l-dvb-13079-dib0700-fixed-xc2028-firmware-loading-kernel-oops.patch @@ -0,0 +1,40 @@ +From 7646b9de26c54cf4bc9c446d7ada9f91ece31e0a Mon Sep 17 00:00:00 2001 +From: Martin Samek +Date: Wed, 30 Sep 2009 22:59:09 -0300 +Subject: V4L/DVB (13079): dib0700: fixed xc2028 firmware loading kernel oops + +From: Martin Samek + +commit 7646b9de26c54cf4bc9c446d7ada9f91ece31e0a upstream. + +Fixing kernel oops when driver attemps to load xc2028 firmware. + +Note by djh: the patch contribute by Martin is a port of a fix I made during +the PCTV 340e development. It's a temporary workaround that fixes a regression +(an OOPS condition) and the real fix should be in the code that manages the +i2c master on the dib7000p. But this fix does address the immmediate +regression and should be merged upstream until we do a cleaner fix. + +Signed-off-by: Martin Samek +Signed-off-by: Devin Heitmueller +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/dvb/frontends/dib7000p.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/media/dvb/frontends/dib7000p.c ++++ b/drivers/media/dvb/frontends/dib7000p.c +@@ -1344,6 +1344,11 @@ struct dvb_frontend * dib7000p_attach(st + if (dib7000p_identify(st) != 0) + goto error; + ++ /* FIXME: make sure the dev.parent field is initialized, or else ++ request_firmware() will hit an OOPS (this should be moved somewhere ++ more common) */ ++ st->i2c_master.gated_tuner_i2c_adap.dev.parent = i2c_adap->dev.parent; ++ + dibx000_init_i2c_master(&st->i2c_master, DIB7000P, st->i2c_adap, st->i2c_addr); + + dib7000p_demod_reset(st); diff --git a/queue-2.6.31/v4l-dvb-13107-tda18271-fix-overflow-in-fm-radio-frequency-calculation.patch b/queue-2.6.31/v4l-dvb-13107-tda18271-fix-overflow-in-fm-radio-frequency-calculation.patch new file mode 100644 index 00000000000..d4537eb0147 --- /dev/null +++ b/queue-2.6.31/v4l-dvb-13107-tda18271-fix-overflow-in-fm-radio-frequency-calculation.patch @@ -0,0 +1,42 @@ +From 4d8317876d5f53ef792e90f89d8f162d7bca5c81 Mon Sep 17 00:00:00 2001 +From: Michael Krufky +Date: Sun, 27 Sep 2009 14:05:12 -0300 +Subject: V4L/DVB (13107): tda18271: fix overflow in FM radio frequency calculation + +From: Michael Krufky + +commit 4d8317876d5f53ef792e90f89d8f162d7bca5c81 upstream. + +Multiplication by 62500 causes an overflow in the 32 bit freq variable, +which is later divided by 1000 when using FM radio. + +This patch prevents the overflow by scaling the frequency value correctly +upfront. Thanks to Henk Vergonet for spotting the problem and providing +a preliminary patch, which this changeset was based upon. + +Cc: Henk Vergonet +Signed-off-by: Michael Krufky +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/common/tuners/tda18271-fe.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/media/common/tuners/tda18271-fe.c ++++ b/drivers/media/common/tuners/tda18271-fe.c +@@ -963,12 +963,12 @@ static int tda18271_set_analog_params(st + struct tda18271_std_map_item *map; + char *mode; + int ret; +- u32 freq = params->frequency * 62500; ++ u32 freq = params->frequency * 125 * ++ ((params->mode == V4L2_TUNER_RADIO) ? 1 : 1000) / 2; + + priv->mode = TDA18271_ANALOG; + + if (params->mode == V4L2_TUNER_RADIO) { +- freq = freq / 1000; + map = &std_map->fm_radio; + mode = "fm"; + } else if (params->std & V4L2_STD_MN) { diff --git a/queue-2.6.31/v4l-dvb-13109-tda18271-fix-signedness-issue-in-tda18271_rf_tracking_filters_init.patch b/queue-2.6.31/v4l-dvb-13109-tda18271-fix-signedness-issue-in-tda18271_rf_tracking_filters_init.patch new file mode 100644 index 00000000000..0c62d284c1d --- /dev/null +++ b/queue-2.6.31/v4l-dvb-13109-tda18271-fix-signedness-issue-in-tda18271_rf_tracking_filters_init.patch @@ -0,0 +1,65 @@ +From a57c1dcb93e43357ed3f666e5a2b5d5071dd3930 Mon Sep 17 00:00:00 2001 +From: Seth Barry +Date: Sun, 27 Sep 2009 16:42:29 -0300 +Subject: V4L/DVB (13109): tda18271: fix signedness issue in tda18271_rf_tracking_filters_init + +From: Seth Barry + +commit a57c1dcb93e43357ed3f666e5a2b5d5071dd3930 upstream. + +While having tda18271 module set with debug=17 (cal & info prints) and +cal=0 (delay calibration process until first use) - I discovered that +during the calibration process, if the frequency test for 69750000 +returned a bcal of 0 (see tda18721-fe.c in tda18271_powerscan func) that +the tuner wouldn't be able to pickup any of the frequencies in the range +(all the other frequencies bands returned bcal=1). I spent some time +going over the code and the NXP's tda18271 spec (ver.4 of it i think) and +adding a lot of debug prints and walking/stepping through the calibration +process. I found that when the powerscan fails to find a frequency, the +rf calibration is not run and the default value is supposed to be used in +its place (pulled from the RF_CAL_map table) - but something was getting +goofed up there. + +Now, my c coding skills are very rusty, but i think root of the problem is +a signedness issue with the math operation for calculating the rf_a1 and +rf_a2 values in tda18271_rf_tracking_filters_init func, which results in +values like 20648 for rf_a1 (when it should probably have a value like 0, +or so slightly negative that it should be zero - this bad value for rf_a1 +would in turn makes the approx calc within +tda18271c2_rf_tracking_filters_correction go out of whack). The simplest +solution i found was to explicitly convert the signedness of the +denominator to avoid the implicit conversion. The values placed into the +u32 rf_freq array should never exceed about 900mhz, so i think the s32 max +value shouldn't be an issue in this case. + +I've tested it out a little, and even when i get a bcal=0 with the +modified code, the default calibration value gets used, rf_a1 is zero, and +the tuner seems to lock on the stream and mythtv seems to play it fine. + +Signed-off-by: Seth Barry +Signed-off-by: Michael Krufky +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/common/tuners/tda18271-fe.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/media/common/tuners/tda18271-fe.c ++++ b/drivers/media/common/tuners/tda18271-fe.c +@@ -595,13 +595,13 @@ static int tda18271_rf_tracking_filters_ + case RF2: + map[i].rf_a1 = (prog_cal[RF2] - prog_tab[RF2] - + prog_cal[RF1] + prog_tab[RF1]) / +- ((rf_freq[RF2] - rf_freq[RF1]) / 1000); ++ (s32)((rf_freq[RF2] - rf_freq[RF1]) / 1000); + map[i].rf2 = rf_freq[RF2] / 1000; + break; + case RF3: + map[i].rf_a2 = (prog_cal[RF3] - prog_tab[RF3] - + prog_cal[RF2] + prog_tab[RF2]) / +- ((rf_freq[RF3] - rf_freq[RF2]) / 1000); ++ (s32)((rf_freq[RF3] - rf_freq[RF2]) / 1000); + map[i].rf_b2 = prog_cal[RF2] - prog_tab[RF2]; + map[i].rf3 = rf_freq[RF3] / 1000; + break; diff --git a/queue-2.6.31/v4l-dvb-13169-bttv-fix-potential-out-of-order-field-processing.patch b/queue-2.6.31/v4l-dvb-13169-bttv-fix-potential-out-of-order-field-processing.patch new file mode 100644 index 00000000000..74de9085989 --- /dev/null +++ b/queue-2.6.31/v4l-dvb-13169-bttv-fix-potential-out-of-order-field-processing.patch @@ -0,0 +1,125 @@ +From 66349b4e7ab3825dbfc167a5f0309792a587adb7 Mon Sep 17 00:00:00 2001 +From: Mike Isely +Date: Mon, 21 Sep 2009 12:09:08 -0300 +Subject: V4L/DVB (13169): bttv: Fix potential out-of-order field processing + +From: Mike Isely + +commit 66349b4e7ab3825dbfc167a5f0309792a587adb7 upstream. + +There is a subtle interaction in the bttv driver which can result in +fields being repeatedly processed out of order. This is a problem +specifically when running in V4L2_FIELD_ALTERNATE mode (probably the +most common case). + +1. The determination of which fields are associated with which buffers +happens in videobuf, before the bttv driver gets a chance to queue the +corresponding DMA. Thus by the point when the DMA is queued for a +given buffer, the algorithm has to do the queuing based on the +buffer's already assigned field type - not based on which field is +"next" in the video stream. + +2. The driver normally tries to queue both the top and bottom fields +at the same time (see bttv_irq_next_video()). It tries to sort out +top vs bottom by looking at the field type for the next 2 available +buffers and assigning them appropriately. + +3. However the bttv driver *always* actually processes the top field +first. There's even an interrupt set aside for specifically +recognizing when the top field has been processed so that it can be +marked done even while the bottom field is still being DMAed. + +Given all of the above, if one gets into a situation where +bttv_irq_next_video() gets entered when the first available buffer has +been pre-associated as a bottom field, then the function is going to +process the buffers out of order. That first available buffer will be +put into the bottom field slot and the buffer after that will be put +into the top field slot. Problem is, since the top field is always +processed first by the driver, then that second buffer (the one after +the first available buffer) will be the first one to be finished. +Because of the strict fifo handling of all video buffers, then that +top field won't be seen by the app until after the bottom field is +also processed. Worse still, the app will get back the +chronologically later bottom field first, *before* the top field is +received. The buffer's timestamps will even be backwards. + +While not fatal to most TV apps, this behavior can subtlely degrade +userspace deinterlacing (probably will cause jitter). That's probably +why it has gone unnoticed. But it will also cause serious problems if +the app in question discards all but the latest received buffer (a +latency minimizing tactic) - causing one field to only ever be +displayed since the other is now always late. Unfortunately once you +get into this state, you're stuck this way - because having consumed +two buffers, now the next time around the "first" available buffer +will again be a bottom field and the same thing happens. + +How can we get into this state? In a perfect world, where there's +always a few free buffers queued to the driver, it should be +impossible. However if something disrupts streaming, e.g. if the +userspace app can't queue free buffers fast enough for a moment due +perhaps to a CPU scheduling glitch, then the driver can get +momentarily starved and some number of fields will be dropped. That's +OK. But if an odd number of fields get dropped, then that "first" +available buffer might be the bottom field and now we're stuck... + +This patch fixes that problem by deliberately only setting up a single +field for one frame if we don't get a top field as the first available +buffer. By purposely skipping the other field, then we only handle a +single buffer thus bringing things back into proper sync (i.e. top +field first) for the next frame. To do this we just drop the few +lines in bttv_irq_next_video() that attempt to set up the second +buffer when that second buffer isn't for the bottom field. + +This is definitely a problem in when in V4L2_FIELD_ALTERNATE mode. In +the other modes this change either has no effect or doesn't harm +things any further anyway. + +Signed-off-by: Mike Isely +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/video/bt8xx/bttv-driver.c | 31 +++++++++++++++++++++++++++---- + 1 file changed, 27 insertions(+), 4 deletions(-) + +--- a/drivers/media/video/bt8xx/bttv-driver.c ++++ b/drivers/media/video/bt8xx/bttv-driver.c +@@ -3798,11 +3798,34 @@ bttv_irq_next_video(struct bttv *btv, st + if (!V4L2_FIELD_HAS_BOTH(item->vb.field) && + (item->vb.queue.next != &btv->capture)) { + item = list_entry(item->vb.queue.next, struct bttv_buffer, vb.queue); ++ /* Mike Isely - Only check ++ * and set up the bottom field in the logic ++ * below. Don't ever do the top field. This ++ * of course means that if we set up the ++ * bottom field in the above code that we'll ++ * actually skip a field. But that's OK. ++ * Having processed only a single buffer this ++ * time, then the next time around the first ++ * available buffer should be for a top field. ++ * That will then cause us here to set up a ++ * top then a bottom field in the normal way. ++ * The alternative to this understanding is ++ * that we set up the second available buffer ++ * as a top field, but that's out of order ++ * since this driver always processes the top ++ * field first - the effect will be the two ++ * buffers being returned in the wrong order, ++ * with the second buffer also being delayed ++ * by one field time (owing to the fifo nature ++ * of videobuf). Worse still, we'll be stuck ++ * doing fields out of order now every time ++ * until something else causes a field to be ++ * dropped. By effectively forcing a field to ++ * drop this way then we always get back into ++ * sync within a single frame time. (Out of ++ * order fields can screw up deinterlacing ++ * algorithms.) */ + if (!V4L2_FIELD_HAS_BOTH(item->vb.field)) { +- if (NULL == set->top && +- V4L2_FIELD_TOP == item->vb.field) { +- set->top = item; +- } + if (NULL == set->bottom && + V4L2_FIELD_BOTTOM == item->vb.field) { + set->bottom = item; diff --git a/queue-2.6.31/v4l-dvb-13170-bttv-fix-reversed-polarity-error-when-switching-video-standard.patch b/queue-2.6.31/v4l-dvb-13170-bttv-fix-reversed-polarity-error-when-switching-video-standard.patch new file mode 100644 index 00000000000..36ba3d43467 --- /dev/null +++ b/queue-2.6.31/v4l-dvb-13170-bttv-fix-reversed-polarity-error-when-switching-video-standard.patch @@ -0,0 +1,65 @@ +From 2de26c0a4a218a351bb1970eeaddf2905b47ff13 Mon Sep 17 00:00:00 2001 +From: Mike Isely +Date: Mon, 21 Sep 2009 12:42:22 -0300 +Subject: V4L/DVB (13170): bttv: Fix reversed polarity error when switching video standard + +From: Mike Isely + +commit 2de26c0a4a218a351bb1970eeaddf2905b47ff13 upstream. + +The bttv driver function which handles switching of the video standard +(set_tvnorm() in bttv-driver.c) includes a check which can optionally +also reset the cropping configuration to a default value. It is +"optional" based on a comparison of the cropcap parameters of the +previous vs the newly requested video standard. The comparison is +being done with a memcmp(), a function which only returns a true value +if the comparison actually fails. + +This if-statement appears to have been written to assume wrong +memcmp() semantics. That is, it was re-initializing the cropping +configuration only if the new video standard did NOT have different +cropcap values. That doesn't make any sense. One definitely should +reset things if the cropcap parameters are different - if there's any +comparison to made at all. + +The effect of this problem was that a transition from, say, PAL to +NTSC would leave in place old cropping setup that made sense for the +PAL geometry but not for NTSC. If the application doesn't care about +cropping it also won't try to reset the cropping configuration, +resulting in an improperly cropped video frame. In the case I was +testing this actually caused black video frames to be displayed. + +Another interesting effect of this bug is that if one does something +which does NOT change the video standard and this function is run, +then the cropping setup gets reset anyway - again because of the +backwards comparison. It turns out that just running anything which +merely opens and closes the video device node (e.g. v4l-info) will +cause this to happen. One can argue that simply opening the device +node and not doing anything to it should not mess with any of its +state - but because of this behavior, any TV app which does such +things (e.g. xawtv) probably therefore doesn't see the problem. + +The solution is to fix the sense of the if-statement. It's easy to +see how this mistake could have been made given how memcmp() works. +The patch is therefore removal of a single "!" character from the +if-statement in set_tvnorm in bttv-driver.c. + +Signed-off-by: Mike Isely +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -1299,7 +1299,7 @@ set_tvnorm(struct bttv *btv, unsigned in + + tvnorm = &bttv_tvnorms[norm]; + +- if (!memcmp(&bttv_tvnorms[btv->tvnorm].cropcap, &tvnorm->cropcap, ++ if (memcmp(&bttv_tvnorms[btv->tvnorm].cropcap, &tvnorm->cropcap, + sizeof (tvnorm->cropcap))) { + bttv_crop_reset(&btv->crop[0], norm); + btv->crop[1] = btv->crop[0]; /* current = default */ diff --git a/queue-2.6.31/v4l-dvb-13190-em28xx-fix-panic-that-can-occur-when-starting-audio-streaming.patch b/queue-2.6.31/v4l-dvb-13190-em28xx-fix-panic-that-can-occur-when-starting-audio-streaming.patch new file mode 100644 index 00000000000..df8c73a15fb --- /dev/null +++ b/queue-2.6.31/v4l-dvb-13190-em28xx-fix-panic-that-can-occur-when-starting-audio-streaming.patch @@ -0,0 +1,38 @@ +From 96fbf771d86a90ff006bc62ca4d4de6474b3de31 Mon Sep 17 00:00:00 2001 +From: Devin Heitmueller +Date: Thu, 15 Oct 2009 01:14:34 -0300 +Subject: V4L/DVB (13190): em28xx: fix panic that can occur when starting audio streaming + +From: Devin Heitmueller + +commit 96fbf771d86a90ff006bc62ca4d4de6474b3de31 upstream. + +Because the counters were not reset when starting up streaming, they would +be reused from the previous run. This can result in cases such that when the +second instance of streaming starts up, the "cnt" variable in +em28xx_audio_isocirq() can end up being negative, resulting in attempting to +write to memory before the start of runtime->dma_area (as well as having a +negative number of bytes to copy). + +Signed-off-by: Devin Heitmueller +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/video/em28xx/em28xx-audio.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/media/video/em28xx/em28xx-audio.c ++++ b/drivers/media/video/em28xx/em28xx-audio.c +@@ -383,6 +383,11 @@ static int snd_em28xx_hw_capture_free(st + + static int snd_em28xx_prepare(struct snd_pcm_substream *substream) + { ++ struct em28xx *dev = snd_pcm_substream_chip(substream); ++ ++ dev->adev.hwptr_done_capture = 0; ++ dev->adev.capture_transfer_done = 0; ++ + return 0; + } + diff --git a/queue-2.6.31/v4l-dvb-13230-s2255drv-don-t-conditionalize-video-buffer-completion-on-waiting-processes.patch b/queue-2.6.31/v4l-dvb-13230-s2255drv-don-t-conditionalize-video-buffer-completion-on-waiting-processes.patch new file mode 100644 index 00000000000..06e02923d14 --- /dev/null +++ b/queue-2.6.31/v4l-dvb-13230-s2255drv-don-t-conditionalize-video-buffer-completion-on-waiting-processes.patch @@ -0,0 +1,48 @@ +From 1f95725755ab67f3198df3b5bf7517f926f310ca Mon Sep 17 00:00:00 2001 +From: Mike Isely +Date: Wed, 23 Sep 2009 18:06:57 -0300 +Subject: V4L/DVB (13230): s2255drv: Don't conditionalize video buffer completion on waiting processes + +From: Mike Isely + +commit 1f95725755ab67f3198df3b5bf7517f926f310ca upstream. + +The s2255 driver had logic which aborted processing of a video frame +if there was no process waiting on the video buffer in question. That +simply doesn't work when the application is doing things in an +asynchronous manner. If the application went to the trouble to queue +the buffer in the first place, then the driver should always attempt +to complete it - even if the application at that moment has its +attention turned elsewhere. Applications which always blocked waiting +for I/O on the capture device would not have been affected by this. +Applications which *mostly* blocked waiting for I/O on the capture +device probably only would have been somewhat affected (frame lossage, +at a rate which goes up as the application blocks less). Applications +which never blocked on the capture device (e.g. polling only) however +would never have been able to receive any video frames, since in that +case this "is anyone waiting on this?" check on the buffer never would +have evalutated true. This patch just deletes that harmful check +against the buffer's wait queue. + +Signed-off-by: Mike Isely +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/video/s2255drv.c | 5 ----- + 1 file changed, 5 deletions(-) + +--- a/drivers/media/video/s2255drv.c ++++ b/drivers/media/video/s2255drv.c +@@ -598,11 +598,6 @@ static int s2255_got_frame(struct s2255_ + buf = list_entry(dma_q->active.next, + struct s2255_buffer, vb.queue); + +- if (!waitqueue_active(&buf->vb.done)) { +- /* no one active */ +- rc = -1; +- goto unlock; +- } + list_del(&buf->vb.queue); + do_gettimeofday(&buf->vb.ts); + dprintk(100, "[%p/%d] wakeup\n", buf, buf->vb.i); diff --git a/queue-2.6.31/v4l-dvb-13240-firedtv-fix-regression-tuning-fails-due-to-bogus-error-return.patch b/queue-2.6.31/v4l-dvb-13240-firedtv-fix-regression-tuning-fails-due-to-bogus-error-return.patch new file mode 100644 index 00000000000..6cc5ac6dea4 --- /dev/null +++ b/queue-2.6.31/v4l-dvb-13240-firedtv-fix-regression-tuning-fails-due-to-bogus-error-return.patch @@ -0,0 +1,43 @@ +From dcff9cfe432c74b382cea327509ede2e114b1615 Mon Sep 17 00:00:00 2001 +From: Stefan Richter +Date: Sat, 17 Oct 2009 17:46:25 -0300 +Subject: V4L/DVB (13240): firedtv: fix regression: tuning fails due to bogus error return + +From: Stefan Richter + +commit dcff9cfe432c74b382cea327509ede2e114b1615 upstream. + +Since 2.6.32(-rc1), DVB core checks the return value of +dvb_frontend_ops.set_frontend. Now it becomes apparent that firedtv +always returned a bogus value from its set_frontend method. + +Signed-off-by: Stefan Richter +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/dvb/firewire/firedtv-fe.c | 8 +------- + 1 file changed, 1 insertion(+), 7 deletions(-) + +--- a/drivers/media/dvb/firewire/firedtv-fe.c ++++ b/drivers/media/dvb/firewire/firedtv-fe.c +@@ -141,18 +141,12 @@ static int fdtv_read_uncorrected_blocks( + return -EOPNOTSUPP; + } + +-#define ACCEPTED 0x9 +- + static int fdtv_set_frontend(struct dvb_frontend *fe, + struct dvb_frontend_parameters *params) + { + struct firedtv *fdtv = fe->sec_priv; + +- /* FIXME: avc_tuner_dsd never returns ACCEPTED. Check status? */ +- if (avc_tuner_dsd(fdtv, params) != ACCEPTED) +- return -EINVAL; +- else +- return 0; /* not sure of this... */ ++ return avc_tuner_dsd(fdtv, params); + } + + static int fdtv_get_frontend(struct dvb_frontend *fe,