--- /dev/null
+From 4acd57c3de62374fe5bb52e5cd24538190f4eab2 Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+Date: Sun, 29 Nov 2009 16:39:52 +0000
+Subject: ALSA: AACI: fix AC97 multiple-open bug
+
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+
+commit 4acd57c3de62374fe5bb52e5cd24538190f4eab2 upstream.
+
+Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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));
--- /dev/null
+From 8ee763b9c82c6ca0a59a7271ce4fa29d7baf5c09 Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+Date: Sun, 29 Nov 2009 16:39:59 +0000
+Subject: ALSA: AACI: fix recording bug
+
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+
+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 <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
--- /dev/null
+From 8ef5837a47f73faee18fa7ce2f9a9eb7675be8de Mon Sep 17 00:00:00 2001
+From: Daniel J Blueman <daniel.blueman@gmail.com>
+Date: Sat, 14 Nov 2009 18:20:04 +0000
+Subject: ALSA: hda - Dell Studio 1557 hd-audio quirk
+
+From: Daniel J Blueman <daniel.blueman@gmail.com>
+
+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 <daniel.blueman@gmail.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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 */
+ };
+
--- /dev/null
+From f495088210c8b9e20791d995a8210170c68d2deb Mon Sep 17 00:00:00 2001
+From: Julian Anastasov <ja@ssi.bg>
+Date: Fri, 6 Nov 2009 23:44:53 +0200
+Subject: ALSA: usb-audio: fix combine_word problem
+
+From: Julian Anastasov <ja@ssi.bg>
+
+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 <ja@ssi.bg>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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))
+
--- /dev/null
+From ec06aedd44541129840ed52e6165afa3796a27bf Mon Sep 17 00:00:00 2001
+From: Jeff Layton <jlayton@redhat.com>
+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 <jlayton@redhat.com>
+
+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 <theosib@gmail.com>
+Signed-off-by: Jeff Layton <jlayton@redhat.com>
+Signed-off-by: Steve French <sfrench@us.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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);
--- /dev/null
+From f534dc994397560343be4a3223b9bbaa8e739e1f Mon Sep 17 00:00:00 2001
+From: Suresh Jayaraman <sjayaraman@suse.de>
+Date: Mon, 16 Nov 2009 12:03:16 +0530
+Subject: cifs: clear server inode number flag while autodisabling
+
+From: Suresh Jayaraman <sjayaraman@suse.de>
+
+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 <sjayaraman@suse.de>
+Acked-by: Jeff Layton <jlayton@redhat.com>
+Signed-off-by: Steve French <sfrench@us.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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 "
--- /dev/null
+From f475f6775465283494346663f201ad04810d2e8a Mon Sep 17 00:00:00 2001
+From: Jeff Layton <jlayton@redhat.com>
+Date: Fri, 6 Nov 2009 14:18:49 -0500
+Subject: cifs: don't use CIFSGetSrvInodeNumber in is_path_accessible
+
+From: Jeff Layton <jlayton@redhat.com>
+
+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 <jlayton@redhat.com>
+Signed-off-by: Steve French <sfrench@us.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
--- /dev/null
+From cea62343956c24452700c06cf028b72414c58a74 Mon Sep 17 00:00:00 2001
+From: Steve French <sfrench@us.ibm.com>
+Date: Tue, 24 Nov 2009 22:49:37 +0000
+Subject: CIFS: Duplicate data on appending to some Samba servers
+
+From: Steve French <sfrench@us.ibm.com>
+
+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 <shirishp@us.ibm.com>
+Signed-off-by: Jeff Layton <jlayton@redhat.com>
+Signed-off-by: Steve French <sfrench@us.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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)
--- /dev/null
+From 8e6c0332d5032aef2d3bc8f41771f999112c8c66 Mon Sep 17 00:00:00 2001
+From: Steve French <sfrench@us.ibm.com>
+Date: Tue, 24 Nov 2009 22:17:59 +0000
+Subject: CIFS: fix oops in cifs_lookup during net boot
+
+From: Steve French <sfrench@us.ibm.com>
+
+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 <shirishp@us.ibm.com>
+Acked-by: Jeff Layton <jlayton@redhat.com>
+Tested-by: Vladimir Stavrinov <vs@inist.ru>
+Signed-off-by: Steve French <sfrench@us.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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,
--- /dev/null
+From 690e744869f3262855b83b4fb59199cf142765b0 Mon Sep 17 00:00:00 2001
+From: Dave Jones <davej@redhat.com>
+Date: Mon, 19 Oct 2009 19:55:13 -0400
+Subject: [SCSI] gdth: Prevent negative offsets in ioctl CVE-2009-3080
+
+From: Dave Jones <davej@redhat.com>
+
+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 <davej@redhat.com>
+Signed-off-by: James Bottomley <James.Bottomley@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
+ }
--- /dev/null
+From d4515646699b6ad7b1a98ceb871296b957f3ef47 Mon Sep 17 00:00:00 2001
+From: Soeren Sandmann <sandmann@daimi.au.dk>
+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 <sandmann@daimi.au.dk>
+
+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 <sandmann@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: a.p.zijlstra@chello.nl
+LKML-Reference: <ye8vdhz8krw.fsf@camel23.daimi.au.dk>
+Signed-off-by: Ingo Molnar <mingo@elte.hu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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--;
--- /dev/null
+From 5ebd4c22897dce65845807a9bd3a31cc4e142b53 Mon Sep 17 00:00:00 2001
+From: Soeren Sandmann <sandmann@daimi.au.dk>
+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 <sandmann@daimi.au.dk>
+
+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 <sandmann@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: a.p.zijlstra@chello.nl
+LKML-Reference: <ye8zl7b8ktj.fsf@camel23.daimi.au.dk>
+Signed-off-by: Ingo Molnar <mingo@elte.hu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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())) {
--- /dev/null
+From 199bc9ff5ca5e4b3bcaff8927b2983c65f34c263 Mon Sep 17 00:00:00 2001
+From: David Woodhouse <dwmw2@infradead.org>
+Date: Mon, 30 Nov 2009 09:06:40 +0000
+Subject: jffs2: Fix memory corruption in jffs2_read_inode_range()
+
+From: David Woodhouse <dwmw2@infradead.org>
+
+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, <huge unsigned negative>);
+
+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 <avorontsov@ru.mvista.com>
+Tested-By: Anton Vorontsov <avorontsov@ru.mvista.com>
+Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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);
+ }
--- /dev/null
+From 24395a85d8efe6eee477ea35c73d045a8dd7a3a1 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Fri, 6 Nov 2009 14:59:27 +1100
+Subject: md: don't clear endpoint for resync when resync is interrupted.
+
+From: NeilBrown <neilb@suse.de>
+
+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 <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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);
--- /dev/null
+From 1d9d52416c0445019ccc1f0fddb9a227456eb61b Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Fri, 16 Oct 2009 15:55:32 +1100
+Subject: md/raid1/raid10: add a cond_resched
+
+From: NeilBrown <neilb@suse.de>
+
+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 <faxguy@howardsilvan.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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);
--- /dev/null
+From 8dee7211467a56b7eb4e4359efb0aa4a72e1b6f3 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Fri, 6 Nov 2009 14:59:29 +1100
+Subject: md/raid5: make sure curr_sync_completes is uptodate when reshape starts
+
+From: NeilBrown <neilb@suse.de>
+
+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 <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
+ }
--- /dev/null
+From 5399dd1fc8f5e812db931225ef5f67d89f3b1a56 Mon Sep 17 00:00:00 2001
+From: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
+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 <konishi.ryusuke@lab.ntt.co.jp>
+
+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 <markus@trippelsdorf.de>
+Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
--- /dev/null
+From 37b12dd2b07b4d7dc222a5f7f88b25cec532b2aa Mon Sep 17 00:00:00 2001
+From: Larry Finger <Larry.Finger@lwfinger.net>
+Date: Wed, 4 Nov 2009 00:00:25 -0600
+Subject: rtl8187: Fix kernel oops when device is removed when LEDS enabled
+
+From: Larry Finger <Larry.Finger@lwfinger.net>
+
+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 <herton@mandriva.com.br> 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 <Larry.Finger@lwfinger.net>
+Reported-by: Rick Farina <sidhayn@gmail.com>
+Tested-by: Rick Farina <sidhayn@gmail.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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 */
+
--- /dev/null
+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
--- /dev/null
+From 2d4b842014dc76a81abced47ef27177eedb9deba Mon Sep 17 00:00:00 2001
+From: Clemens Ladisch <clemens@ladisch.de>
+Date: Mon, 13 Jul 2009 13:52:46 +0200
+Subject: sound: rawmidi: disable active-sensing-on-close by default
+
+From: Clemens Ladisch <clemens@ladisch.de>
+
+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 <clemens@ladisch.de>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+
+---
+ 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;
--- /dev/null
+From 16fb109644b5644e42ececeff644514de6f4bd03 Mon Sep 17 00:00:00 2001
+From: Clemens Ladisch <clemens@ladisch.de>
+Date: Wed, 21 Oct 2009 09:10:16 +0200
+Subject: sound: rawmidi: fix checking of O_APPEND when opening MIDI device
+
+From: Clemens Ladisch <clemens@ladisch.de>
+
+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 <clemens@ladisch.de>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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) {
--- /dev/null
+From 8579d2d7779d7ff41ea2a0183015e0e5038f1043 Mon Sep 17 00:00:00 2001
+From: Clemens Ladisch <clemens@ladisch.de>
+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 <clemens@ladisch.de>
+
+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 <clemens@ladisch.de>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
+ }
--- /dev/null
+From b7fe750fcceda4fa6bef399b0e2812562728ea82 Mon Sep 17 00:00:00 2001
+From: Clemens Ladisch <clemens@ladisch.de>
+Date: Wed, 21 Oct 2009 09:11:43 +0200
+Subject: sound: rawmidi: fix MIDI device O_APPEND error handling
+
+From: Clemens Ladisch <clemens@ladisch.de>
+
+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 <clemens@ladisch.de>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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 */
--- /dev/null
+From b00bc0b237055b4c45816325ee14f0bd83e6f590 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Mon, 2 Nov 2009 13:01:56 +0100
+Subject: uids: Prevent tear down race
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+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 <tglx@linutronix.de>
+Acked-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
+Cc: Paul E. McKenney <paulmck@us.ibm.com>
+Cc: Kay Sievers <kay.sievers@vrfy.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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 */
--- /dev/null
+From 7646b9de26c54cf4bc9c446d7ada9f91ece31e0a Mon Sep 17 00:00:00 2001
+From: Martin Samek <martin@marsark.sytes.net>
+Date: Wed, 30 Sep 2009 22:59:09 -0300
+Subject: V4L/DVB (13079): dib0700: fixed xc2028 firmware loading kernel oops
+
+From: Martin Samek <martin@marsark.sytes.net>
+
+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 <martin@marsark.sytes.net>
+Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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);
--- /dev/null
+From 4d8317876d5f53ef792e90f89d8f162d7bca5c81 Mon Sep 17 00:00:00 2001
+From: Michael Krufky <mkrufky@kernellabs.com>
+Date: Sun, 27 Sep 2009 14:05:12 -0300
+Subject: V4L/DVB (13107): tda18271: fix overflow in FM radio frequency calculation
+
+From: Michael Krufky <mkrufky@kernellabs.com>
+
+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 <Henk.Vergonet@gmail.com>
+Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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) {
--- /dev/null
+From a57c1dcb93e43357ed3f666e5a2b5d5071dd3930 Mon Sep 17 00:00:00 2001
+From: Seth Barry <seth@cyberseth.com>
+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 <seth@cyberseth.com>
+
+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 <seth@cyberseth.com>
+Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
--- /dev/null
+From 66349b4e7ab3825dbfc167a5f0309792a587adb7 Mon Sep 17 00:00:00 2001
+From: Mike Isely <isely@pobox.com>
+Date: Mon, 21 Sep 2009 12:09:08 -0300
+Subject: V4L/DVB (13169): bttv: Fix potential out-of-order field processing
+
+From: Mike Isely <isely@pobox.com>
+
+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 <isely@pobox.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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 <isely@pobox.com> - 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;
--- /dev/null
+From 2de26c0a4a218a351bb1970eeaddf2905b47ff13 Mon Sep 17 00:00:00 2001
+From: Mike Isely <isely@pobox.com>
+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 <isely@pobox.com>
+
+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 <isely@pobox.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
+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
+@@ -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 */
--- /dev/null
+From 96fbf771d86a90ff006bc62ca4d4de6474b3de31 Mon Sep 17 00:00:00 2001
+From: Devin Heitmueller <dheitmueller@kernellabs.com>
+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 <dheitmueller@kernellabs.com>
+
+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 <dheitmueller@kernellabs.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
+ }
+
--- /dev/null
+From 1f95725755ab67f3198df3b5bf7517f926f310ca Mon Sep 17 00:00:00 2001
+From: Mike Isely <isely@pobox.com>
+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 <isely@pobox.com>
+
+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 <isely@pobox.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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);
--- /dev/null
+From dcff9cfe432c74b382cea327509ede2e114b1615 Mon Sep 17 00:00:00 2001
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+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 <stefanr@s5r6.in-berlin.de>
+
+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 <stefanr@s5r6.in-berlin.de>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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,
projects / thirdparty / kernel / stable-queue.git / commitdiff
