[patch 00/18] 2.6.18-stable review

[patch 00/18] 2.6.18-stable review

[Greg KH]

This is the start of the stable review cycle for the 2.6.18.8 release.

This will be the last release of the 2.6.18-stable series, so if there
are patches that you feel should be applied to that tree, please let me
know.

There are 18 patches in this series, all will be posted as a response to
this one.  If anyone has any issues with these being applied, please let
us know.  If anyone is a maintainer of the proper subsystem, and wants
to add a Signed-off-by: line to the patch, please respond with it.

These patches are sent out with a number of different people on the Cc:
line.  If you wish to be a reviewer, please email stable@kernel.org to
add your name to the list.  If you want to be off the reviewer list,
also email us.

Responses should be made by Friday February 23 00:00 UTC.  Anything
received after that time might be too late.

The whole patch set can be downloaded at:
        kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.18.8-rc1.gz

thanks,

the -stable release team

[patch 01/18] bcm43xx: Fix for oops on resume

[Greg KH]

[-- Attachment #1: bcm43xx-fix-for-oops-on-resume.patch --]
[-- Type: text/plain, Size: 779 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Larry Finger <Larry.Finger@lwfinger.net>

There is a kernel oops on bcm43xx when resuming due to an overly tight timeout loop.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/bcm43xx/bcm43xx.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -21,7 +21,7 @@
 #define PFX				KBUILD_MODNAME ": "
 
 #define BCM43xx_SWITCH_CORE_MAX_RETRIES	50
-#define BCM43xx_IRQWAIT_MAX_RETRIES	50
+#define BCM43xx_IRQWAIT_MAX_RETRIES	100
 
 #define BCM43xx_IO_SIZE			8192
 

--

Re: [patch 01/18] bcm43xx: Fix for oops on resume

[Pavel Machek]

Hi!

> -stable review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> From: Larry Finger <Larry.Finger@lwfinger.net>
> 
> There is a kernel oops on bcm43xx when resuming due to an overly tight timeout loop.
> 
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> ---
>  drivers/net/wireless/bcm43xx/bcm43xx.h |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
> +++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx.h
> @@ -21,7 +21,7 @@
>  #define PFX				KBUILD_MODNAME ": "
>  
>  #define BCM43xx_SWITCH_CORE_MAX_RETRIES	50
> -#define BCM43xx_IRQWAIT_MAX_RETRIES	50
> +#define BCM43xx_IRQWAIT_MAX_RETRIES	100
>  
>  #define BCM43xx_IO_SIZE			8192

I'm sorry, but this does not look like fixing an oops. It may make it
go away for you, or make it less probable, but it certainly can't fix
it.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [patch 01/18] bcm43xx: Fix for oops on resume

[Larry Finger]

Pavel Machek wrote:
> Hi!
> 
>> -stable review patch.  If anyone has any objections, please let us know.
>>
>> ------------------
>> From: Larry Finger <Larry.Finger@lwfinger.net>
>>
>> There is a kernel oops on bcm43xx when resuming due to an overly tight timeout loop.
>>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>>
>> ---
>>  drivers/net/wireless/bcm43xx/bcm43xx.h |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> --- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
>> +++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx.h
>> @@ -21,7 +21,7 @@
>>  #define PFX				KBUILD_MODNAME ": "
>>  
>>  #define BCM43xx_SWITCH_CORE_MAX_RETRIES	50
>> -#define BCM43xx_IRQWAIT_MAX_RETRIES	50
>> +#define BCM43xx_IRQWAIT_MAX_RETRIES	100
>>  
>>  #define BCM43xx_IO_SIZE			8192
> 
> I'm sorry, but this does not look like fixing an oops. It may make it
> go away for you, or make it less probable, but it certainly can't fix
> it.

Upon resume, it was taking 65 times through the loop, which caused an oops. We think it is due to a
slow-clock setting at that point, but it certainly does get rid of the oops. This change has also
eliminated the odd oops seen by a few users.

Larry

Re: [patch 01/18] bcm43xx: Fix for oops on resume

[Andrew Morton]

> On Sat, 24 Feb 2007 20:30:41 -0600 Larry Finger <larry.finger@lwfinger.net> wrote:
> Pavel Machek wrote:
> > Hi!
> > 
> >> -stable review patch.  If anyone has any objections, please let us know.
> >>
> >> ------------------
> >> From: Larry Finger <Larry.Finger@lwfinger.net>
> >>
> >> There is a kernel oops on bcm43xx when resuming due to an overly tight timeout loop.
> >>
> >> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> >> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> >>
> >> ---
> >>  drivers/net/wireless/bcm43xx/bcm43xx.h |    2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> --- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
> >> +++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx.h
> >> @@ -21,7 +21,7 @@
> >>  #define PFX				KBUILD_MODNAME ": "
> >>  
> >>  #define BCM43xx_SWITCH_CORE_MAX_RETRIES	50
> >> -#define BCM43xx_IRQWAIT_MAX_RETRIES	50
> >> +#define BCM43xx_IRQWAIT_MAX_RETRIES	100
> >>  
> >>  #define BCM43xx_IO_SIZE			8192
> > 
> > I'm sorry, but this does not look like fixing an oops. It may make it
> > go away for you, or make it less probable, but it certainly can't fix
> > it.
> 
> Upon resume, it was taking 65 times through the loop, which caused an oops. We think it is due to a
> slow-clock setting at that point, but it certainly does get rid of the oops. This change has also
> eliminated the odd oops seen by a few users.
> 

Pavel's point is that the driver shouldn't oops the kernel if
BCM43xx_IRQWAIT_MAX_RETRIES is exceeded.

Presumably, the driver will oops if bcm43xx_chip_init() fails for other
reasons?

[patch 02/18] bcm43xx: Fix for oops on ampdu status

[Greg KH]

[-- Attachment #1: bcm43xx-fix-for-oops-on-ampdu-status.patch --]
[-- Type: text/plain, Size: 2022 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Michael Buesch <mb@bu3sch.de>

If bcm43xx were to process an afterburner (ampdu) status response, Linux would oops. The
ampdu and intermediate status bits are properly named.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/bcm43xx/bcm43xx_main.c |    8 +++-----
 drivers/net/wireless/bcm43xx/bcm43xx_xmit.h |   10 ++--------
 2 files changed, 5 insertions(+), 13 deletions(-)

--- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1449,12 +1449,10 @@ static void handle_irq_transmit_status(s
 
 		bcm43xx_debugfs_log_txstat(bcm, &stat);
 
-		if (stat.flags & BCM43xx_TXSTAT_FLAG_IGNORE)
+		if (stat.flags & BCM43xx_TXSTAT_FLAG_AMPDU)
+			continue;
+		if (stat.flags & BCM43xx_TXSTAT_FLAG_INTER)
 			continue;
-		if (!(stat.flags & BCM43xx_TXSTAT_FLAG_ACK)) {
-			//TODO: packet was not acked (was lost)
-		}
-		//TODO: There are more (unknown) flags to test. see bcm43xx_main.h
 
 		if (bcm43xx_using_pio(bcm))
 			bcm43xx_pio_handle_xmitstatus(bcm, &stat);
--- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.h
+++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx_xmit.h
@@ -137,14 +137,8 @@ struct bcm43xx_xmitstatus {
 	u16 unknown; //FIXME
 };
 
-#define BCM43xx_TXSTAT_FLAG_ACK		0x01
-//TODO #define BCM43xx_TXSTAT_FLAG_???	0x02
-//TODO #define BCM43xx_TXSTAT_FLAG_???	0x04
-//TODO #define BCM43xx_TXSTAT_FLAG_???	0x08
-//TODO #define BCM43xx_TXSTAT_FLAG_???	0x10
-#define BCM43xx_TXSTAT_FLAG_IGNORE	0x20
-//TODO #define BCM43xx_TXSTAT_FLAG_???	0x40
-//TODO #define BCM43xx_TXSTAT_FLAG_???	0x80
+#define BCM43xx_TXSTAT_FLAG_AMPDU	0x10
+#define BCM43xx_TXSTAT_FLAG_INTER	0x20
 
 u8 bcm43xx_plcp_get_ratecode_cck(const u8 bitrate);
 u8 bcm43xx_plcp_get_ratecode_ofdm(const u8 bitrate);

--

[patch 03/18] Dont leak NT bit into next task

[Greg KH]

[-- Attachment #1: don-t-leak-nt-bit-into-next-task.patch --]
[-- Type: text/plain, Size: 2367 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Andi Kleen <ak@suse.de>

SYSENTER can cause a NT to be set which might cause crashes on the IRET
in the next task.

Following similar i386 patch from Linus.

Signed-off-by: Andi Kleen <ak@suse.de>
[backport from Chuck Ebbert]
Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/x86_64/kernel/entry.S   |    4 ++++
 arch/x86_64/kernel/setup64.c |    4 ++++
 include/asm-x86_64/system.h  |    5 +++--
 3 files changed, 11 insertions(+), 2 deletions(-)

--- linux-2.6.18.7.orig/arch/x86_64/kernel/entry.S
+++ linux-2.6.18.7/arch/x86_64/kernel/entry.S
@@ -146,6 +146,10 @@
 /* rdi:	prev */	
 ENTRY(ret_from_fork)
 	CFI_DEFAULT_STACK
+	push kernel_eflags(%rip)
+	CFI_ADJUST_CFA_OFFSET 4
+	popf				# reset kernel eflags
+	CFI_ADJUST_CFA_OFFSET -4
 	call schedule_tail
 	GET_THREAD_INFO(%rcx)
 	testl $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT),threadinfo_flags(%rcx)
--- linux-2.6.18.7.orig/arch/x86_64/kernel/setup64.c
+++ linux-2.6.18.7/arch/x86_64/kernel/setup64.c
@@ -178,6 +178,8 @@ void __cpuinit check_efer(void)
         }       
 }
 
+unsigned long kernel_eflags;
+
 /*
  * cpu_init() initializes state that is per-CPU. Some data is already
  * initialized (naturally) in the bootstrap process, such as the GDT
@@ -290,4 +292,6 @@ void __cpuinit cpu_init (void)
 	set_debugreg(0UL, 7);
 
 	fpu_init(); 
+
+	raw_local_save_flags(kernel_eflags);
 }
--- linux-2.6.18.7.orig/include/asm-x86_64/system.h
+++ linux-2.6.18.7/include/asm-x86_64/system.h
@@ -14,12 +14,13 @@
 #define __RESTORE(reg,offset) "movq (14-" #offset ")*8(%%rsp),%%" #reg "\n\t"
 
 /* frame pointer must be last for get_wchan */
-#define SAVE_CONTEXT    "pushq %%rbp ; movq %%rsi,%%rbp\n\t"
-#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\n\t"
+#define SAVE_CONTEXT    "pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
+#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"
 
 #define __EXTRA_CLOBBER  \
 	,"rcx","rbx","rdx","r8","r9","r10","r11","r12","r13","r14","r15"
 
+/* Save restore flags to clear handle leaking NT */
 #define switch_to(prev,next,last) \
 	asm volatile(SAVE_CONTEXT						    \
 		     "movq %%rsp,%P[threadrsp](%[prev])\n\t" /* save RSP */	  \

--

Re: [patch 03/18] Dont leak NT bit into next task

[Giuseppe Bilotta]

On Wednesday 21 February 2007 02:49, Greg KH wrote:

>  /* frame pointer must be last for get_wchan */
> -#define SAVE_CONTEXT    "pushq %%rbp ; movq %%rsi,%%rbp\n\t"
> -#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\n\t"
> +#define SAVE_CONTEXT    "pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
> +#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"

No idea if this is a problem or not, but you forgot a \n after popf.

-- 
Giuseppe "Oblomov" Bilotta

Re: [patch 03/18] Dont leak NT bit into next task

[Jan Engelhardt]

On Feb 21 2007 11:00, Giuseppe Bilotta wrote:
>On Wednesday 21 February 2007 02:49, Greg KH wrote:
>
>>  /* frame pointer must be last for get_wchan */
>> -#define SAVE_CONTEXT    "pushq %%rbp ; movq %%rsi,%%rbp\n\t"
>> -#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\n\t"
>> +#define SAVE_CONTEXT    "pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
>> +#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"
>
>No idea if this is a problem or not, but you forgot a \n after popf.

It is on the edge. RESTORE_CONTEXT will not be passed any 
arguments, so it is the only thing in a single line, and hence
the implicit \n of the source file applies after \t.
But yes, it may be dangerous. Better is an explicit \n or semicolon
after popf.


Jan
-- 

Re: [patch 03/18] Dont leak NT bit into next task

[Chuck Ebbert]

Giuseppe Bilotta wrote:
> On Wednesday 21 February 2007 02:49, Greg KH wrote:
> 
>>  /* frame pointer must be last for get_wchan */
>> -#define SAVE_CONTEXT    "pushq %%rbp ; movq %%rsi,%%rbp\n\t"
>> -#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\n\t"
>> +#define SAVE_CONTEXT    "pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
>> +#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"
> 
> No idea if this is a problem or not, but you forgot a \n after popf.
> 

It's that way in 2.6.21-rc1.

Re: [patch 03/18] Dont leak NT bit into next task

[Adrian Bunk]

On Wed, Feb 21, 2007 at 11:00:15AM +0100, Giuseppe Bilotta wrote:
> On Wednesday 21 February 2007 02:49, Greg KH wrote:
> 
> >  /* frame pointer must be last for get_wchan */
> > -#define SAVE_CONTEXT    "pushq %%rbp ; movq %%rsi,%%rbp\n\t"
> > -#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\n\t"
> > +#define SAVE_CONTEXT    "pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
> > +#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"
> 
> No idea if this is a problem or not, but you forgot a \n after popf.

A discussion of this issue is in the thread starting with [1]
(and I'd re-add the \n in -stable kernels with the patch below 
 (stolen from 2.6.16) no matter what happened in Linus' tree).

> Giuseppe "Oblomov" Bilotta

cu
Adrian

[1] http://lkml.org/lkml/2007/1/8/374


commit e02612a14b2b714e9d231d14c91e729f0f168299
Author: Adrian Bunk <bunk@stusta.de>
Date:   Tue Jan 9 03:36:59 2007 +0100

    x86_64: re-add a newline to RESTORE_CONTEXT
    
    RESTORE_CONTEXT lost a newline:
    http://www.mail-archive.com/kgdb-bugreport@lists.sourceforge.net/msg00559.html
    
    Reported by Steven M. Christey.
    
    Signed-off-by: Adrian Bunk <bunk@stusta.de>

diff --git a/include/asm-x86_64/system.h b/include/asm-x86_64/system.h
index 7b2c7aa..dacec59 100644
--- a/include/asm-x86_64/system.h
+++ b/include/asm-x86_64/system.h
@@ -21,7 +21,7 @@
 
 /* frame pointer must be last for get_wchan */
 #define SAVE_CONTEXT    "pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
-#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"
+#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\n\t"
 
 #define __EXTRA_CLOBBER  \
 	,"rcx","rbx","rdx","r8","r9","r10","r11","r12","r13","r14","r15"

Re: [patch 03/18] Dont leak NT bit into next task

[Andi Kleen]

On Thursday 22 February 2007 16:29, Adrian Bunk wrote:
> On Wed, Feb 21, 2007 at 11:00:15AM +0100, Giuseppe Bilotta wrote:
> > On Wednesday 21 February 2007 02:49, Greg KH wrote:
> > 
> > >  /* frame pointer must be last for get_wchan */
> > > -#define SAVE_CONTEXT    "pushq %%rbp ; movq %%rsi,%%rbp\n\t"
> > > -#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\n\t"
> > > +#define SAVE_CONTEXT    "pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
> > > +#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"
> > 
> > No idea if this is a problem or not, but you forgot a \n after popf.
> 
> A discussion of this issue is in the thread starting with [1]
> (and I'd re-add the \n in -stable kernels with the patch below 
>  (stolen from 2.6.16) no matter what happened in Linus' tree).

The newline only helps some broken out of tree patches (which I won't name here)
that shouldn't touch this anyways.

-Andi

[patch 04/18] SCSI: add missing cdb clearing in scsi_execute()

[Greg KH]

[-- Attachment #1: scsi-add-missing-cdb-clearing-in-scsi_execute.patch --]
[-- Type: text/plain, Size: 1098 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Tejun Heo <htejun@gmail.com>

Clear-garbage-after-CDB patch missed scsi_execute() and it causes some
ODDs (HL-DT-ST DVD-RAM GSA-H30N) choke during SCSI scan.  Note that
this patch is only for -stable.  There is another more reliable fix
for this problem proposed for devel tree.

http://thread.gmane.org/gmane.linux.ide/14605/focus=14605

Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Douglas Gilbert <dougg@torque.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/scsi/scsi_lib.c |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.18.7.orig/drivers/scsi/scsi_lib.c
+++ linux-2.6.18.7/drivers/scsi/scsi_lib.c
@@ -191,6 +191,7 @@ int scsi_execute(struct scsi_device *sde
 		goto out;
 
 	req->cmd_len = COMMAND_SIZE(cmd[0]);
+	memset(req->cmd, 0, BLK_MAX_CDB); /* ATAPI hates garbage after CDB */
 	memcpy(req->cmd, cmd, req->cmd_len);
 	req->sense = sense;
 	req->sense_len = 0;

--

[patch 05/18] IB/srp: Fix FMR mapping for 32-bit kernels and addresses above 4G

[Greg KH]

[-- Attachment #1: ib-srp-fix-fmr-mapping-for-32-bit-kernels-and-addresses-above-4g.patch --]
[-- Type: text/plain, Size: 1723 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Roland Dreier <rdreier@cisco.com>

struct srp_device.fmr_page_mask was unsigned long, which means that
the top part of addresses above 4G was being chopped off on 32-bit
architectures.  Of course nothing good happens when data from SRP
targets is DMAed to the wrong place.

Fix this by changing fmr_page_mask to u64, to match the addresses
actually used by IB devices.

Thanks to Brian Cain <Brian.Cain@ge.com> and David McMillen
<davem@systemfabricworks.com> for help diagnosing the bug and testing
the fix.

Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/infiniband/ulp/srp/ib_srp.c |    2 +-
 drivers/infiniband/ulp/srp/ib_srp.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.18.7.orig/drivers/infiniband/ulp/srp/ib_srp.c
+++ linux-2.6.18.7/drivers/infiniband/ulp/srp/ib_srp.c
@@ -1851,7 +1851,7 @@ static void srp_add_one(struct ib_device
 	 */
 	srp_dev->fmr_page_shift = max(9, ffs(dev_attr->page_size_cap) - 1);
 	srp_dev->fmr_page_size  = 1 << srp_dev->fmr_page_shift;
-	srp_dev->fmr_page_mask  = ~((unsigned long) srp_dev->fmr_page_size - 1);
+	srp_dev->fmr_page_mask  = ~((u64) srp_dev->fmr_page_size - 1);
 
 	INIT_LIST_HEAD(&srp_dev->dev_list);
 
--- linux-2.6.18.7.orig/drivers/infiniband/ulp/srp/ib_srp.h
+++ linux-2.6.18.7/drivers/infiniband/ulp/srp/ib_srp.h
@@ -87,7 +87,7 @@ struct srp_device {
 	struct ib_fmr_pool     *fmr_pool;
 	int			fmr_page_shift;
 	int			fmr_page_size;
-	unsigned long		fmr_page_mask;
+	u64			fmr_page_mask;
 };
 
 struct srp_host {

--

[patch 06/18] i2c: fix broken ds1337 initialization

[Greg KH]

[-- Attachment #1: i2c-fix-broken-ds1337-initialization.patch --]
[-- Type: text/plain, Size: 2187 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Dirk Eibach <eibach@gdsys.de>

On a custom board with ds1337 RTC I found that upgrade from 2.6.15 to
2.6.18 broke RTC support.

The main problem are changes to ds1337_init_client().
When a ds1337 recognizes a problem (e.g. power or clock failure) bit 7
in status register is set. This has to be reset by writing 0 to status
register. But since there are only 16 byte written to the chip and the
first byte is interpreted as an address, the status register (which is
the 16th) is never written.
The other problem is, that initializing all registers to zero is not
valid for day, date and month register. Funny enough this is checked by
ds1337_detect(), which depends on this values not being zero. So then
treated by ds1337_init_client() the ds1337 is not detected anymore,
whereas the failure bit in the status register is still set.

Broken by commit f9e8957937ebf60d22732a5ca9130f48a7603f60 (2.6.16-rc1,
2006-01-06). This fix is in Linus' tree since 2.6.20-rc1 (commit
763d9c046a2e511ec090a8986d3f85edf7448e7e).

Signed-off-by: Dirk Stieler <stieler@gdsys.de>
Signed-off-by: Dirk Eibach <eibach@gdsys.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/i2c/chips/ds1337.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- linux-2.6.18.7.orig/drivers/i2c/chips/ds1337.c
+++ linux-2.6.18.7/drivers/i2c/chips/ds1337.c
@@ -347,13 +347,19 @@ static void ds1337_init_client(struct i2
 
 	if ((status & 0x80) || (control & 0x80)) {
 		/* RTC not running */
-		u8 buf[16];
+		u8 buf[1+16];	/* First byte is interpreted as address */
 		struct i2c_msg msg[1];
 
 		dev_dbg(&client->dev, "%s: RTC not running!\n", __FUNCTION__);
 
 		/* Initialize all, including STATUS and CONTROL to zero */
 		memset(buf, 0, sizeof(buf));
+
+		/* Write valid values in the date/time registers */
+		buf[1+DS1337_REG_DAY] = 1;
+		buf[1+DS1337_REG_DATE] = 1;
+		buf[1+DS1337_REG_MONTH] = 1;
+
 		msg[0].addr = client->addr;
 		msg[0].flags = 0;
 		msg[0].len = sizeof(buf);

--

[patch 07/18] grow_buffers() infinite loop fix (CVE-2006-5757, CVE-2006-6060)

[Greg KH]

[-- Attachment #1: grow_buffers-infinite-loop-fix.patch --]
[-- Type: text/plain, Size: 1986 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Andrew Morton <akpm@osdl.org>

If grow_buffers() is for some reason passed a block number which wants to lie
outside the maximum-addressable pagecache range (PAGE_SIZE * 4G bytes) then it
will accidentally truncate `index' and will then instnatiate a page at the
wrong pagecache offset.  This causes __getblk_slow() to go into an infinite
loop.

This can happen with corrupted disks, or with software errors elsewhere.

Detect that, and handle it.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/buffer.c |   21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

--- linux-2.6.18.7.orig/fs/buffer.c
+++ linux-2.6.18.7/fs/buffer.c
@@ -1179,8 +1179,21 @@ grow_buffers(struct block_device *bdev, 
 	} while ((size << sizebits) < PAGE_SIZE);
 
 	index = block >> sizebits;
-	block = index << sizebits;
 
+	/*
+	 * Check for a block which wants to lie outside our maximum possible
+	 * pagecache index.  (this comparison is done using sector_t types).
+	 */
+	if (unlikely(index != block >> sizebits)) {
+		char b[BDEVNAME_SIZE];
+
+		printk(KERN_ERR "%s: requested out-of-range block %llu for "
+			"device %s\n",
+			__FUNCTION__, (unsigned long long)block,
+			bdevname(bdev, b));
+		return -EIO;
+	}
+	block = index << sizebits;
 	/* Create a page with the proper size buffers.. */
 	page = grow_dev_page(bdev, block, index, size);
 	if (!page)
@@ -1207,12 +1220,16 @@ __getblk_slow(struct block_device *bdev,
 
 	for (;;) {
 		struct buffer_head * bh;
+		int ret;
 
 		bh = __find_get_block(bdev, block, size);
 		if (bh)
 			return bh;
 
-		if (!grow_buffers(bdev, block, size))
+		ret = grow_buffers(bdev, block, size);
+		if (ret < 0)
+			return NULL;
+		if (ret == 0)
 			free_more_memory();
 	}
 }

--

[patch 08/18] hfs_fill_super returns success even if no root inode (CVE-2006-6056)

[Greg KH]

[-- Attachment #1: hfs_fill_super-returns-success-even-if-no-root-inode.patch --]
[-- Type: text/plain, Size: 2186 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Eric Sandeen <sandeen@redhat.com>

http://kernelfun.blogspot.com/2006/11/mokb-14-11-2006-linux-26x-selinux.html

mount that image...
fs: filesystem was not cleanly unmounted, running fsck.hfs is recommended.  mounting read-only.
hfs: get root inode failed.
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000018
 printing eip
...
EIP is at superblock_doinit+0x21/0x767
...
 [] selinux_sb_kern_mount+0xc/0x4b
 [] vfs_kern_mount+0x99/0xf6
 [] do_kern_mount+0x2d/0x3e
 [] do_mount+0x5fa/0x66d
 [] sys_mount+0x77/0xae
 [] syscall_call+0x7/0xb
DWARF2 unwinder stuck at syscall_call+0x7/0xb

hfs_fill_super() returns success even if
  root_inode = hfs_iget(sb, &fd.search_key->cat, &rec);
or
  sb->s_root = d_alloc_root(root_inode);

fails.  This superblock finds its way to superblock_doinit() which does:

        struct dentry *root = sb->s_root;
        struct inode *inode = root->d_inode;

and boom.  Need to make sure the error cases return an error, I think.

[akpm@osdl.org: return -ENOMEM on oom]
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
Date: Thu, 16 Nov 2006 09:19:22 +0000 (-0800)
Subject: [patch 08/18] [PATCH] hfs_fill_super returns success even if no root inode
X-Git-Tag: v2.6.19
X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d6ddf55440833fd9404138026af246c51ebeef22

 fs/hfs/super.c |    2 ++
 1 file changed, 2 insertions(+)

--- linux-2.6.18.7.orig/fs/hfs/super.c
+++ linux-2.6.18.7/fs/hfs/super.c
@@ -391,11 +391,13 @@ static int hfs_fill_super(struct super_b
 		hfs_find_exit(&fd);
 		goto bail_no_root;
 	}
+	res = -EINVAL;
 	root_inode = hfs_iget(sb, &fd.search_key->cat, &rec);
 	hfs_find_exit(&fd);
 	if (!root_inode)
 		goto bail_no_root;
 
+	res = -ENOMEM;
 	sb->s_root = d_alloc_root(root_inode);
 	if (!sb->s_root)
 		goto bail_iput;

--

[patch 09/18] IB/mad: Fix race between cancel and receive completion

[Greg KH]

[-- Attachment #1: ib-mad-fix-race-between-cancel-and-receive-completion.patch --]
[-- Type: text/plain, Size: 1609 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Roland Dreier <rdreier@cisco.com>

When ib_cancel_mad() is called, it puts the canceled send on a list
and schedules a "flushed" callback from process context.  However,
this leaves a window where a receive completion could be processed
before the send is fully flushed.

This is fine, except that ib_find_send_mad() will find the MAD and
return it to the receive processing, which results in the sender
getting both a successful receive and a "flushed" send completion for
the same request.  Understandably, this confuses the sender, which is
expecting only one of these two callbacks, and leads to grief such as
a use-after-free in IPoIB.

Fix this by changing ib_find_send_mad() to return a send struct only
if the status is still successful (and not "flushed").  The search of
the send_list already had this check, so this patch just adds the same
check to the search of the wait_list.

Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

---
 drivers/infiniband/core/mad.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18.7.orig/drivers/infiniband/core/mad.c
+++ linux-2.6.18.7/drivers/infiniband/core/mad.c
@@ -1750,7 +1750,7 @@ ib_find_send_mad(struct ib_mad_agent_pri
 		     */
 		    (is_direct(wc->recv_buf.mad->mad_hdr.mgmt_class) ||
 		     rcv_has_same_gid(mad_agent_priv, wr, wc)))
-			return wr;
+			return (wr->status == IB_WC_SUCCESS) ? wr : NULL;
 	}
 
 	/*

--

[patch 10/18] dvb-core: fix bug in CRC-32 checking on 64-bit systems

[Greg KH]

[-- Attachment #1: dvb-core-fix-bug-in-CRC-32-checking-on-64-bit-systems.patch --]
[-- Type: text/plain, Size: 1894 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Ang Way Chuang <wcang@nrg.cs.usm.my>

CRC-32 checking during ULE decapsulation always failed on x86_64 systems due
to the size of a variable used to store CRC. This bug was discovered on
Fedora Core 6 with kernel-2.6.18-1.2849. The i386 counterpart has no such
problem. This patch has been tested on 64-bit system as well as 32-bit system.

(cherry picked from commit dedcefb085fe98a1feaf63590fe2fc7e0ecb1987)

Signed-off-by: Ang Way Chuang <wcang@nrg.cs.usm.my>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/dvb/dvb-core/dvb_net.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.18.7.orig/drivers/media/dvb/dvb-core/dvb_net.c
+++ linux-2.6.18.7/drivers/media/dvb/dvb-core/dvb_net.c
@@ -604,7 +604,7 @@ static void dvb_net_ule( struct net_devi
 				{ &utype, sizeof utype },
 				{ priv->ule_skb->data, priv->ule_skb->len - 4 }
 			};
-			unsigned long ule_crc = ~0L, expected_crc;
+			u32 ule_crc = ~0L, expected_crc;
 			if (priv->ule_dbit) {
 				/* Set D-bit for CRC32 verification,
 				 * if it was set originally. */
@@ -617,7 +617,7 @@ static void dvb_net_ule( struct net_devi
 				       *((u8 *)priv->ule_skb->tail - 2) << 8 |
 				       *((u8 *)priv->ule_skb->tail - 1);
 			if (ule_crc != expected_crc) {
-				printk(KERN_WARNING "%lu: CRC32 check FAILED: %#lx / %#lx, SNDU len %d type %#x, ts_remain %d, next 2: %x.\n",
+				printk(KERN_WARNING "%lu: CRC32 check FAILED: %08x / %08x, SNDU len %d type %#x, ts_remain %d, next 2: %x.\n",
 				       priv->ts_count, ule_crc, expected_crc, priv->ule_sndu_len, priv->ule_sndu_type, ts_remain, ts_remain > 2 ? *(unsigned short *)from_where : 0);
 
 #ifdef ULE_DEBUG

--

[patch 11/18] v4l: cx2341x audio_properties is an u16, not u8

[Greg KH]

[-- Attachment #1: v4l-cx2341x-audio_properties-is-an-u16-not-u8.patch --]
[-- Type: text/plain, Size: 950 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Hans Verkuil <hverkuil@xs4all.nl>

This bug broke the MPEG audio mode controls.

(cherry picked from commit cb2c7b4927c8f376b7ba9557978d8c59ed472664)

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 include/media/cx2341x.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18.7.orig/include/media/cx2341x.h
+++ linux-2.6.18.7/include/media/cx2341x.h
@@ -49,7 +49,7 @@ struct cx2341x_mpeg_params {
 	enum v4l2_mpeg_audio_mode_extension audio_mode_extension;
 	enum v4l2_mpeg_audio_emphasis audio_emphasis;
 	enum v4l2_mpeg_audio_crc audio_crc;
-	u8 audio_properties;
+	u16 audio_properties;
 
 	/* video */
 	enum v4l2_mpeg_video_encoding video_encoding;

--

[patch 12/18] v4l: cx88: Fix leadtek_eeprom tagging

[Greg KH]

[-- Attachment #1: v4l-cx88-Fix-leadtek_eeprom-tagging.patch --]
[-- Type: text/plain, Size: 1309 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Jean Delvare <khali@linux-fr.org>

reference to .init.text: from .text between 'cx88_card_setup'
(at offset 0x68c) and 'cx88_risc_field'
Caused by leadtek_eeprom() being declared __devinit and called from
a non-devinit context.

(cherry picked from commit 69f7e75a9d45e5eaca16917a8d0dedf76149f13f)

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/cx88/cx88-cards.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18.7.orig/drivers/media/video/cx88/cx88-cards.c
+++ linux-2.6.18.7/drivers/media/video/cx88/cx88-cards.c
@@ -1465,7 +1465,7 @@ const unsigned int cx88_idcount = ARRAY_
 /* ----------------------------------------------------------------------- */
 /* some leadtek specific stuff                                             */
 
-static void __devinit leadtek_eeprom(struct cx88_core *core, u8 *eeprom_data)
+static void leadtek_eeprom(struct cx88_core *core, u8 *eeprom_data)
 {
 	/* This is just for the "Winfast 2000XP Expert" board ATM; I don't have data on
 	 * any others.

--

[patch 13/18] V4L: cx88: Fix lockup on suspend

[Greg KH]

[-- Attachment #1: V4L-cx88-Fix-lockup-on-suspend.patch --]
[-- Type: text/plain, Size: 1305 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Robert Hancock <hancockr@shaw.ca>

Suspending with the cx88xx module loaded causes the system to lock up
because the cx88_audio_thread kthread was missing a try_to_freeze()
call, which caused it to go into a tight loop and result in softlockup
when suspending. Fix that.

(cherry picked from commit a96afb3e9428f2e7463344f12dbc85faf08e2e09)

Signed-off-by: Robert Hancock <hancockr@shaw.ca>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/cx88/cx88-tvaudio.c |    2 ++
 1 file changed, 2 insertions(+)

--- linux-2.6.18.7.orig/drivers/media/video/cx88/cx88-tvaudio.c
+++ linux-2.6.18.7/drivers/media/video/cx88/cx88-tvaudio.c
@@ -38,6 +38,7 @@
 #include <linux/module.h>
 #include <linux/moduleparam.h>
 #include <linux/errno.h>
+#include <linux/freezer.h>
 #include <linux/kernel.h>
 #include <linux/slab.h>
 #include <linux/mm.h>
@@ -979,6 +980,7 @@ int cx88_audio_thread(void *data)
 		msleep_interruptible(1000);
 		if (kthread_should_stop())
 			break;
+		try_to_freeze();
 
 		/* just monitor the audio status for now ... */
 		memset(&t, 0, sizeof(t));

--

Re: [patch 13/18] V4L: cx88: Fix lockup on suspend

[Michael Krufky]

Greg KH wrote:
> -stable review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> From: Robert Hancock <hancockr@shaw.ca>
> 
> Suspending with the cx88xx module loaded causes the system to lock up
> because the cx88_audio_thread kthread was missing a try_to_freeze()
> call, which caused it to go into a tight loop and result in softlockup
> when suspending. Fix that.
> 
> (cherry picked from commit a96afb3e9428f2e7463344f12dbc85faf08e2e09)
> 
> Signed-off-by: Robert Hancock <hancockr@shaw.ca>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 

Please drop this one... I shouldn't have sent it to 2.6.18.y nor 2.6.19.y ... tree-mixup :-/

Sorry about that...

-Mike Krufky


> ---
>  drivers/media/video/cx88/cx88-tvaudio.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> --- linux-2.6.18.7.orig/drivers/media/video/cx88/cx88-tvaudio.c
> +++ linux-2.6.18.7/drivers/media/video/cx88/cx88-tvaudio.c
> @@ -38,6 +38,7 @@
>  #include <linux/module.h>
>  #include <linux/moduleparam.h>
>  #include <linux/errno.h>
> +#include <linux/freezer.h>
>  #include <linux/kernel.h>
>  #include <linux/slab.h>
>  #include <linux/mm.h>
> @@ -979,6 +980,7 @@ int cx88_audio_thread(void *data)
>  		msleep_interruptible(1000);
>  		if (kthread_should_stop())
>  			break;
> +		try_to_freeze();
>  
>  		/* just monitor the audio status for now ... */
>  		memset(&t, 0, sizeof(t));
> 
> --

Re: [patch 13/18] V4L: cx88: Fix lockup on suspend

[Greg KH]

On Wed, Feb 21, 2007 at 08:14:22PM -0500, Michael Krufky wrote:
> Greg KH wrote:
> > -stable review patch.  If anyone has any objections, please let us know.
> > 
> > ------------------
> > From: Robert Hancock <hancockr@shaw.ca>
> > 
> > Suspending with the cx88xx module loaded causes the system to lock up
> > because the cx88_audio_thread kthread was missing a try_to_freeze()
> > call, which caused it to go into a tight loop and result in softlockup
> > when suspending. Fix that.
> > 
> > (cherry picked from commit a96afb3e9428f2e7463344f12dbc85faf08e2e09)
> > 
> > Signed-off-by: Robert Hancock <hancockr@shaw.ca>
> > Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
> > Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > 
> 
> Please drop this one... I shouldn't have sent it to 2.6.18.y nor 2.6.19.y ... tree-mixup :-/

Dropped, thanks for letting me know.

greg k-h

[patch 14/18] V4L: Fix quickcam communicator driver for big endian architectures

[Greg KH]

[-- Attachment #1: V4L-Fix-quickcam-communicator-driver-for-big-endian-architectures.patch --]
[-- Type: text/plain, Size: 1357 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Grant Likely <grant.likely@secretlab.ca>

Host endianess does not affect the order that pixel rgb data comes
in from the quickcam (the values are bytes, not words or longs).  The
driver is erroniously swapping the order of rgb values for big endian
machines.  This patch is needed get the Quickcam communicator working
on big endian machines (tested on powerpc)

(cherry picked from commit c6d704c8c4453f05717ba88792f70f8babf95268)

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/usbvideo/quickcam_messenger.h |   14 --------------
 1 file changed, 14 deletions(-)

--- linux-2.6.18.7.orig/drivers/media/video/usbvideo/quickcam_messenger.h
+++ linux-2.6.18.7/drivers/media/video/usbvideo/quickcam_messenger.h
@@ -35,27 +35,13 @@ struct rgb {
 };
 
 struct bayL0 {
-#ifdef __BIG_ENDIAN
-	u8 r;
-	u8 g;
-#elif __LITTLE_ENDIAN
 	u8 g;
 	u8 r;
-#else
-#error not byte order defined
-#endif
 };
 
 struct bayL1 {
-#ifdef __BIG_ENDIAN
-	u8 g;
-	u8 b;
-#elif __LITTLE_ENDIAN
 	u8 b;
 	u8 g;
-#else
-#error not byte order defined
-#endif
 };
 
 struct cam_size {

--

[patch 15/18] V4L: fix ks0127 status flags

[Greg KH]

[-- Attachment #1: V4L-fix-ks0127-status-flags.patch --]
[-- Type: text/plain, Size: 1389 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Martin Samuelsson <sam@home.se>

Or status flags together in DECODER_GET_STATUS instead of and-zapping them.

(cherry picked from commit 55d5440d4587454628a850ce26703639885af678)

Signed-off-by: Martin Samuelsson <sam@home.se>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/ks0127.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- linux-2.6.18.7.orig/drivers/media/video/ks0127.c
+++ linux-2.6.18.7/drivers/media/video/ks0127.c
@@ -712,13 +712,13 @@ static int ks0127_command(struct i2c_cli
 		*iarg = 0;
 		status = ks0127_read(ks, KS_STAT);
 		if (!(status & 0x20))		 /* NOVID not set */
-			*iarg = (*iarg & DECODER_STATUS_GOOD);
+			*iarg = (*iarg | DECODER_STATUS_GOOD);
 		if ((status & 0x01))		      /* CLOCK set */
-			*iarg = (*iarg & DECODER_STATUS_COLOR);
+			*iarg = (*iarg | DECODER_STATUS_COLOR);
 		if ((status & 0x08))		   /* PALDET set */
-			*iarg = (*iarg & DECODER_STATUS_PAL);
+			*iarg = (*iarg | DECODER_STATUS_PAL);
 		else
-			*iarg = (*iarg & DECODER_STATUS_NTSC);
+			*iarg = (*iarg | DECODER_STATUS_NTSC);
 		break;
 
 	//Catch any unknown command

--

[patch 16/18] V4L: tveeprom: autodetect LG TAPC G701D as tuner type 37

[Greg KH]

[-- Attachment #1: V4L-tveeprom-autodetect-LG-TAPC-G701D-as-tuner-type-37.patch --]
[-- Type: text/plain, Size: 1100 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Michael Krufky <mkrufky@linuxtv.org>

Autodetect LG TAPC G701D as tuner type 37, fixing
mis-detected tuners in some Hauppauge tv tuner cards.

Thanks to Adonis Papas, for pointing this out.

(cherry picked from commit 1323fbda1343f50f198bc8bd6d1d59c8b7fc45bf)

Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/tveeprom.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18.7.orig/drivers/media/video/tveeprom.c
+++ linux-2.6.18.7/drivers/media/video/tveeprom.c
@@ -184,7 +184,7 @@ hauppauge_tuner[] =
 	{ TUNER_ABSENT,        "Thompson DTT757"},
 	/* 80-89 */
 	{ TUNER_ABSENT,        "Philips FQ1216LME MK3"},
-	{ TUNER_ABSENT,        "LG TAPC G701D"},
+	{ TUNER_LG_PAL_NEW_TAPC, "LG TAPC G701D"},
 	{ TUNER_LG_NTSC_NEW_TAPC, "LG TAPC H791F"},
 	{ TUNER_LG_PAL_NEW_TAPC, "TCL 2002MB 3"},
 	{ TUNER_LG_PAL_NEW_TAPC, "TCL 2002MI 3"},

--

[patch 17/18] V4L: buf_qbuf: fix videobuf_queue->stream corruption and lockup

[Greg KH]

[-- Attachment #1: V4L-buf_qbuf-fix-videobuf_queue-stream-corruption-and-lockup.patch --]
[-- Type: text/plain, Size: 1019 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Oleg Nesterov <oleg@tv-sign.ru>

We are doing ->buf_prepare(buf) before adding buf to q->stream list. This
means that videobuf_qbuf() should not try to re-add a STATE_PREPARED buffer.

(cherry picked from commit 419dd8378dfa32985672ab7927b4bc827f33b332)

Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/video-buf.c |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.18.7.orig/drivers/media/video/video-buf.c
+++ linux-2.6.18.7/drivers/media/video/video-buf.c
@@ -695,6 +695,7 @@ videobuf_qbuf(struct videobuf_queue *q,
 		goto done;
 	}
 	if (buf->state == STATE_QUEUED ||
+	    buf->state == STATE_PREPARED ||
 	    buf->state == STATE_ACTIVE) {
 		dprintk(1,"qbuf: buffer is already queued or active.\n");
 		goto done;

--

[patch 18/18] x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted

[Greg KH]

[-- Attachment #1: x86_64-fix-2.6.18-regression-ptrace_oldsetoptions-should-be-accepted.patch --]
[-- Type: text/plain, Size: 1437 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: "Paolo 'Blaisorblade' Giarrusso" <blaisorblade@yahoo.it>

Also PTRACE_OLDSETOPTIONS should be accepted, as done by kernel/ptrace.c and
forced by binary compatibility. UML/32bit breaks because of this - since it is wise
enough to use PTRACE_OLDSETOPTIONS to be binary compatible with 2.4 host
kernels.

Until 2.6.17 (commit f0f2d6536e3515b5b1b7ae97dc8f176860c8c2ce) we had:

       default:
                return sys_ptrace(request, pid, addr, data);

Instead here we have:
        case PTRACE_GET_THREAD_AREA:
	case ...:
                return sys_ptrace(request, pid, addr, data);

        default:
                return -EINVAL;

This change was a style change - when a case is added, it must be explicitly
tested this way. In this case, not enough testing was done.

Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86_64/ia32/ptrace32.c |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.18.7.orig/arch/x86_64/ia32/ptrace32.c
+++ linux-2.6.18.7/arch/x86_64/ia32/ptrace32.c
@@ -239,6 +239,7 @@ asmlinkage long sys32_ptrace(long reques
 	case PTRACE_SINGLESTEP:
 	case PTRACE_DETACH:
 	case PTRACE_SYSCALL:
+	case PTRACE_OLDSETOPTIONS:
 	case PTRACE_SETOPTIONS:
 		return sys_ptrace(request, pid, addr, data); 
 

--

[uml-devel] [patch 18/18] x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted

[Greg KH]

[-- Attachment #1: x86_64-fix-2.6.18-regression-ptrace_oldsetoptions-should-be-accepted.patch --]
[-- Type: text/plain, Size: 1978 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: "Paolo 'Blaisorblade' Giarrusso" <blaisorblade@yahoo.it>

Also PTRACE_OLDSETOPTIONS should be accepted, as done by kernel/ptrace.c and
forced by binary compatibility. UML/32bit breaks because of this - since it is wise
enough to use PTRACE_OLDSETOPTIONS to be binary compatible with 2.4 host
kernels.

Until 2.6.17 (commit f0f2d6536e3515b5b1b7ae97dc8f176860c8c2ce) we had:

       default:
                return sys_ptrace(request, pid, addr, data);

Instead here we have:
        case PTRACE_GET_THREAD_AREA:
	case ...:
                return sys_ptrace(request, pid, addr, data);

        default:
                return -EINVAL;

This change was a style change - when a case is added, it must be explicitly
tested this way. In this case, not enough testing was done.

Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86_64/ia32/ptrace32.c |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.18.7.orig/arch/x86_64/ia32/ptrace32.c
+++ linux-2.6.18.7/arch/x86_64/ia32/ptrace32.c
@@ -239,6 +239,7 @@ asmlinkage long sys32_ptrace(long reques
 	case PTRACE_SINGLESTEP:
 	case PTRACE_DETACH:
 	case PTRACE_SYSCALL:
+	case PTRACE_OLDSETOPTIONS:
 	case PTRACE_SETOPTIONS:
 		return sys_ptrace(request, pid, addr, data); 
 

--

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [patch 00/18] 2.6.18-stable review

[S.Çağlar Onur]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

21 Şub 2007 Çar tarihinde, Greg KH şunları yazmıştı: 
> Responses should be made by Friday February 23 00:00 UTC.  Anything
> received after that time might be too late.

We have still some CVEish patches in our package which maybe you want to 
consider adding into -stable.

* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006

Cheers
-- 
S.Çağlar Onur <caglar@pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [stable] [patch 00/18] 2.6.18-stable review

[Greg KH]

On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
> 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazm????t??: 
> > Responses should be made by Friday February 23 00:00 UTC.  Anything
> > received after that time might be too late.
> 
> We have still some CVEish patches in our package which maybe you want to 
> consider adding into -stable.
> 
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006

Do you have a pointer to the patches for these fixes anywhere?

And are you sure they are all for 2.6.18?  The first one above is for
the 2.4 kernel tree :)

thanks,

greg k-h

Re: [stable] [patch 00/18] 2.6.18-stable review

[S.Çağlar Onur]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

Hi;

21 Şub 2007 Çar tarihinde, Greg KH şunları yazmıştı: 
> On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
> > 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazm????t??:
> > > Responses should be made by Friday February 23 00:00 UTC.  Anything
> > > received after that time might be too late.
> >
> > We have still some CVEish patches in our package which maybe you want to
> > consider adding into -stable.
> >
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006
>
> Do you have a pointer to the patches for these fixes anywhere?

http://svn.pardus.org.tr/pardus/2007/kernel/kernel/files/CVE/ has all of them 
as you can see some of them backports grabbed from newer kernels/git trees

> And are you sure they are all for 2.6.18?  The first one above is for
> the 2.4 kernel tree :)

Yep, but that one still clearly applies on top of 2.6.18.7. I'm not sure they 
have _valid cases_, i'm simply following the CVE announcements :)

Cheers
-- 
S.Çağlar Onur <caglar@pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [stable] [patch 00/18] 2.6.18-stable review

[Ismail Dönmez]

On Wednesday 21 February 2007 19:34:45 Greg KH wrote:
> On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
> > 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazm????t??:
> > > Responses should be made by Friday February 23 00:00 UTC.  Anything
> > > received after that time might be too late.
> >
> > We have still some CVEish patches in our package which maybe you want to
> > consider adding into -stable.
> >
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006
>
> Do you have a pointer to the patches for these fixes anywhere?
>
> And are you sure they are all for 2.6.18?  The first one above is for
> the 2.4 kernel tree :)

Yep and Mandriva fixed that in their kernel release which is 2.6.x, I mailed 
security@kernel.org about it some time ago, but got no response so far.

Regards,
ismail

-- 
FFmpeg doxy @ http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs

Re: [stable] [patch 00/18] 2.6.18-stable review

[Willy Tarreau]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

Hi Greg,

On Wed, Feb 21, 2007 at 09:34:45AM -0800, Greg KH wrote:
> On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
> > 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazm????t??: 
> > > Responses should be made by Friday February 23 00:00 UTC.  Anything
> > > received after that time might be too late.
> > 
> > We have still some CVEish patches in our package which maybe you want to 
> > consider adding into -stable.
> > 
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006
> 
> Do you have a pointer to the patches for these fixes anywhere?
> 
> And are you sure they are all for 2.6.18?  The first one above is for
> the 2.4 kernel tree :)

No, in fact the CVE description is not precise enough. Maybe we should
propose an update to Steven, I don't know how CVE descriptions are
supposed to evolve.

The patch merged in 2.4 was a backport by Hugh Dickins of Linus' 2.6 patch,
which itself was composed of three successive fixes :

  2f77d107050abc14bc393b34bdb7b91cf670c250
  4fb23e439ce09157d64b89a21061b9fc08f2b495
  825020c3866e7312947e17a0caa9dd1a5622bafc

I attach all of them to this mail for your convenience. I noticed that
Linus recently applied other changes to mincore, though I'm not sure
they are security-related.

Hoping this helps,
Willy


[-- Attachment #2: 0001-Fix-incorrect-user-space-access-locking-in-mincore.txt --]
[-- Type: text/plain, Size: 6697 bytes --]

>From 2f77d107050abc14bc393b34bdb7b91cf670c250 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@woody.osdl.org>
Date: Sat, 16 Dec 2006 09:44:32 -0800
Subject: Fix incorrect user space access locking in mincore()

Doug Chapman noticed that mincore() will doa "copy_to_user()" of the
result while holding the mmap semaphore for reading, which is a big
no-no.  While a recursive read-lock on a semaphore in the case of a page
fault happens to work, we don't actually allow them due to deadlock
schenarios with writers due to fairness issues.

Doug and Marcel sent in a patch to fix it, but I decided to just rewrite
the mess instead - not just fixing the locking problem, but making the
code smaller and (imho) much easier to understand.

Cc: Doug Chapman <dchapman@redhat.com>
Cc: Marcel Holtmann <holtmann@redhat.com>
Cc: Hugh Dickins <hugh@veritas.com>
Cc: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
 mm/mincore.c |  190 ++++++++++++++++++++++++++--------------------------------
 1 files changed, 86 insertions(+), 104 deletions(-)

diff --git a/mm/mincore.c b/mm/mincore.c
index 7289078..b44d7f8 100644
--- a/mm/mincore.c
+++ b/mm/mincore.c
@@ -1,7 +1,7 @@
 /*
  *	linux/mm/mincore.c
  *
- * Copyright (C) 1994-1999  Linus Torvalds
+ * Copyright (C) 1994-2006  Linus Torvalds
  */
 
 /*
@@ -38,46 +38,60 @@ static unsigned char mincore_page(struct
 	return present;
 }
 
-static long mincore_vma(struct vm_area_struct * vma,
-	unsigned long start, unsigned long end, unsigned char __user * vec)
+/*
+ * Do a chunk of "sys_mincore()". We've already checked
+ * all the arguments, we hold the mmap semaphore: we should
+ * just return the amount of info we're asked for.
+ */
+static long do_mincore(unsigned long addr, unsigned char *vec, unsigned long pages)
 {
-	long error, i, remaining;
-	unsigned char * tmp;
+	unsigned long i, nr, pgoff;
+	struct vm_area_struct *vma = find_vma(current->mm, addr);
 
-	error = -ENOMEM;
-	if (!vma->vm_file)
-		return error;
-
-	start = ((start - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
-	if (end > vma->vm_end)
-		end = vma->vm_end;
-	end = ((end - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
+	/*
+	 * find_vma() didn't find anything: the address
+	 * is above everything we have mapped.
+	 */
+	if (!vma) {
+		memset(vec, 0, pages);
+		return pages;
+	}
 
-	error = -EAGAIN;
-	tmp = (unsigned char *) __get_free_page(GFP_KERNEL);
-	if (!tmp)
-		return error;
+	/*
+	 * find_vma() found something, but we might be
+	 * below it: check for that.
+	 */
+	if (addr < vma->vm_start) {
+		unsigned long gap = (vma->vm_start - addr) >> PAGE_SHIFT;
+		if (gap > pages)
+			gap = pages;
+		memset(vec, 0, gap);
+		return gap;
+	}
 
-	/* (end - start) is # of pages, and also # of bytes in "vec */
-	remaining = (end - start),
+	/*
+	 * Ok, got it. But check whether it's a segment we support
+	 * mincore() on. Right now, we don't do any anonymous mappings.
+	 */
+	if (!vma->vm_file)
+		return -ENOMEM;
 
-	error = 0;
-	for (i = 0; remaining > 0; remaining -= PAGE_SIZE, i++) {
-		int j = 0;
-		long thispiece = (remaining < PAGE_SIZE) ?
-						remaining : PAGE_SIZE;
+	/*
+	 * Calculate how many pages there are left in the vma, and
+	 * what the pgoff is for our address.
+	 */
+	nr = (vma->vm_end - addr) >> PAGE_SHIFT;
+	if (nr > pages)
+		nr = pages;
 
-		while (j < thispiece)
-			tmp[j++] = mincore_page(vma, start++);
+	pgoff = (addr - vma->vm_start) >> PAGE_SHIFT;
+	pgoff += vma->vm_pgoff;
 
-		if (copy_to_user(vec + PAGE_SIZE * i, tmp, thispiece)) {
-			error = -EFAULT;
-			break;
-		}
-	}
+	/* And then we just fill the sucker in.. */
+	for (i = 0 ; i < nr; i++, pgoff++)
+		vec[i] = mincore_page(vma, pgoff);
 
-	free_page((unsigned long) tmp);
-	return error;
+	return nr;
 }
 
 /*
@@ -107,82 +121,50 @@ static long mincore_vma(struct vm_area_s
 asmlinkage long sys_mincore(unsigned long start, size_t len,
 	unsigned char __user * vec)
 {
-	int index = 0;
-	unsigned long end, limit;
-	struct vm_area_struct * vma;
-	size_t max;
-	int unmapped_error = 0;
-	long error;
-
-	/* check the arguments */
- 	if (start & ~PAGE_CACHE_MASK)
-		goto einval;
-
-	limit = TASK_SIZE;
-	if (start >= limit)
-		goto enomem;
-
-	if (!len)
-		return 0;
+	long retval;
+	unsigned long pages;
+	unsigned char *tmp;
 
-	max = limit - start;
-	len = PAGE_CACHE_ALIGN(len);
-	if (len > max || !len)
-		goto enomem;
-
-	end = start + len;
+	/* Check the start address: needs to be page-aligned.. */
+ 	if (start & ~PAGE_CACHE_MASK)
+		return -EINVAL;
 
-	/* check the output buffer whilst holding the lock */
-	error = -EFAULT;
-	down_read(&current->mm->mmap_sem);
+	/* ..and we need to be passed a valid user-space range */
+	if (!access_ok(VERIFY_READ, (void __user *) start, len))
+		return -ENOMEM;
 
-	if (!access_ok(VERIFY_WRITE, vec, len >> PAGE_SHIFT))
-		goto out;
+	/* This also avoids any overflows on PAGE_CACHE_ALIGN */
+	pages = len >> PAGE_SHIFT;
+	pages += (len & ~PAGE_MASK) != 0;
 
-	/*
-	 * If the interval [start,end) covers some unmapped address
-	 * ranges, just ignore them, but return -ENOMEM at the end.
-	 */
-	error = 0;
-
-	vma = find_vma(current->mm, start);
-	while (vma) {
-		/* Here start < vma->vm_end. */
-		if (start < vma->vm_start) {
-			unmapped_error = -ENOMEM;
-			start = vma->vm_start;
-		}
+	if (!access_ok(VERIFY_WRITE, vec, pages))
+		return -EFAULT;
 
-		/* Here vma->vm_start <= start < vma->vm_end. */
-		if (end <= vma->vm_end) {
-			if (start < end) {
-				error = mincore_vma(vma, start, end,
-							&vec[index]);
-				if (error)
-					goto out;
-			}
-			error = unmapped_error;
-			goto out;
+	tmp = (void *) __get_free_page(GFP_USER);
+	if (!tmp)
+		return -ENOMEM;
+
+	retval = 0;
+	while (pages) {
+		/*
+		 * Do at most PAGE_SIZE entries per iteration, due to
+		 * the temporary buffer size.
+		 */
+		down_read(&current->mm->mmap_sem);
+		retval = do_mincore(start, tmp, max(pages, PAGE_SIZE));
+		up_read(&current->mm->mmap_sem);
+
+		if (retval <= 0)
+			break;
+		if (copy_to_user(vec, tmp, retval)) {
+			retval = -EFAULT;
+			break;
 		}
-
-		/* Here vma->vm_start <= start < vma->vm_end < end. */
-		error = mincore_vma(vma, start, vma->vm_end, &vec[index]);
-		if (error)
-			goto out;
-		index += (vma->vm_end - start) >> PAGE_CACHE_SHIFT;
-		start = vma->vm_end;
-		vma = vma->vm_next;
+		pages -= retval;
+		vec += retval;
+		start += retval << PAGE_SHIFT;
+		retval = 0;
 	}
-
-	/* we found a hole in the area queried if we arrive here */
-	error = -ENOMEM;
-
-out:
-	up_read(&current->mm->mmap_sem);
-	return error;
-
-einval:
-	return -EINVAL;
-enomem:
-	return -ENOMEM;
+	free_page((unsigned long) tmp);
+	return retval;
 }
-- 
1.4.2.4


[-- Attachment #3: 0002-Fix-up-mm-mincore.c-error-value-cases.txt --]
[-- Type: text/plain, Size: 2494 bytes --]

>From 4fb23e439ce09157d64b89a21061b9fc08f2b495 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@woody.osdl.org>
Date: Sat, 16 Dec 2006 16:01:50 -0800
Subject: Fix up mm/mincore.c error value cases

Hugh Dickins correctly points out that mincore() is actually _supposed_
to fail on an unmapped hole in the user address space, rather than
return valid ("empty") information about the hole.  This just simplifies
the problem further (I had been misled by our previous confusing and
complicated way of doing mincore()).

Also, in the unlikely situation that we can't allocate a temporary
kernel buffer, we should actually return EAGAIN, not ENOMEM, to keep the
"unmapped hole" and "allocation failure" error cases separate.

Finally, add a comment about our stupid historical lack of support for
anonymous mappings.  I'll fix that if somebody reminds me after 2.6.20
is out.

Acked-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
 mm/mincore.c |   29 ++++++++++-------------------
 1 files changed, 10 insertions(+), 19 deletions(-)

diff --git a/mm/mincore.c b/mm/mincore.c
index b44d7f8..566b6c2 100644
--- a/mm/mincore.c
+++ b/mm/mincore.c
@@ -49,29 +49,20 @@ static long do_mincore(unsigned long add
 	struct vm_area_struct *vma = find_vma(current->mm, addr);
 
 	/*
-	 * find_vma() didn't find anything: the address
-	 * is above everything we have mapped.
+	 * find_vma() didn't find anything above us, or we're
+	 * in an unmapped hole in the address space: ENOMEM.
 	 */
-	if (!vma) {
-		memset(vec, 0, pages);
-		return pages;
-	}
-
-	/*
-	 * find_vma() found something, but we might be
-	 * below it: check for that.
-	 */
-	if (addr < vma->vm_start) {
-		unsigned long gap = (vma->vm_start - addr) >> PAGE_SHIFT;
-		if (gap > pages)
-			gap = pages;
-		memset(vec, 0, gap);
-		return gap;
-	}
+	if (!vma || addr < vma->vm_start)
+		return -ENOMEM;
 
 	/*
 	 * Ok, got it. But check whether it's a segment we support
 	 * mincore() on. Right now, we don't do any anonymous mappings.
+	 *
+	 * FIXME: This is just stupid. And returning ENOMEM is 
+	 * stupid too. We should just look at the page tables. But
+	 * this is what we've traditionally done, so we'll just
+	 * continue doing it.
 	 */
 	if (!vma->vm_file)
 		return -ENOMEM;
@@ -142,7 +133,7 @@ asmlinkage long sys_mincore(unsigned lon
 
 	tmp = (void *) __get_free_page(GFP_USER);
 	if (!tmp)
-		return -ENOMEM;
+		return -EAGAIN;
 
 	retval = 0;
 	while (pages) {
-- 
1.4.2.4


[-- Attachment #4: 0003-PATCH-sys_mincore-s-max-min.txt --]
[-- Type: text/plain, Size: 857 bytes --]

>From 825020c3866e7312947e17a0caa9dd1a5622bafc Mon Sep 17 00:00:00 2001
From: Oleg Nesterov <oleg@tv-sign.ru>
Date: Sun, 17 Dec 2006 18:52:47 +0300
Subject: [PATCH] sys_mincore: s/max/min/

fix a typo, sys_mincore() needs min().

Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: Linus "I'm a moron" Torvalds <torvalds@osdl.org>
---
 mm/mincore.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mm/mincore.c b/mm/mincore.c
index 566b6c2..8aca6f7 100644
--- a/mm/mincore.c
+++ b/mm/mincore.c
@@ -142,7 +142,7 @@ asmlinkage long sys_mincore(unsigned lon
 		 * the temporary buffer size.
 		 */
 		down_read(&current->mm->mmap_sem);
-		retval = do_mincore(start, tmp, max(pages, PAGE_SIZE));
+		retval = do_mincore(start, tmp, min(pages, PAGE_SIZE));
 		up_read(&current->mm->mmap_sem);
 
 		if (retval <= 0)
-- 
1.4.2.4

Re: [stable] [patch 00/18] 2.6.18-stable review

[Adrian Bunk]

On Wed, Feb 21, 2007 at 09:34:45AM -0800, Greg KH wrote:
> On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
> > 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazm????t??: 
> > > Responses should be made by Friday February 23 00:00 UTC.  Anything
> > > received after that time might be too late.
> > 
> > We have still some CVEish patches in our package which maybe you want to 
> > consider adding into -stable.
> > 
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006
> 
> Do you have a pointer to the patches for these fixes anywhere?
> 
> And are you sure they are all for 2.6.18?  The first one above is for
> the 2.4 kernel tree :)

Fixed in 2.6.19.2 and 2.6.18.8 (the latter contains a
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>  ;-) ).

> thanks,
> 
> greg k-h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [patch 00/18] 2.6.18-stable review

[Adrian Bunk]

On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.Çağlar Onur wrote:
> 21 Şub 2007 Çar tarihinde, Greg KH şunları yazmıştı: 
> > Responses should be made by Friday February 23 00:00 UTC.  Anything
> > received after that time might be too late.
> 
> We have still some CVEish patches in our package which maybe you want to 
> consider adding into -stable.

Below, I'll only look at the 2.6.18, 2.6.19 and 2.6.20 kernels.

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814

fixed in:
- 2.6.18.8
- 2.6.19.2
- 2.6.20

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749

fixed in:
- 2.6.20 (commit dab6df63086762629936e8b89a5984bae39724f6)

missing in:
- 2.6.18
- 2.6.19

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753

fixed in:
- 2.6.20 (commit be6aab0e9fa6d3c6d75aa1e38ac972d8b4ee82b8)

missing in:
- 2.6.18
- 2.6.19

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823

fixed in:
- 2.6.19.2
- 2.6.20

missing in:
- 2.6.18

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053

fixed in:
- 2.6.19.2
- 2.6.20

missing in:
- 2.6.18

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054

fixed in:
- 2.6.19.2
- 2.6.20

missing in:
- 2.6.18

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333

fixed in:
- 2.6.19.1
- 2.6.20

problem not present in:
- 2.6.18

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006

fixed in:
- 2.6.19.5

missing in:
- 2.6.18
- 2.6.20

> Cheers

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [patch 00/18] 2.6.18-stable review

[S.Çağlar Onur]

[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]

26 Şub 2007 Pts tarihinde, Adrian Bunk şunları yazmıştı: 
> On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.Çağlar Onur wrote:
> > 21 Şub 2007 Çar tarihinde, Greg KH şunları yazmıştı:
> > > Responses should be made by Friday February 23 00:00 UTC.  Anything
> > > received after that time might be too late.
> >
> > We have still some CVEish patches in our package which maybe you want to
> > consider adding into -stable.
>
> Below, I'll only look at the 2.6.18, 2.6.19 and 2.6.20 kernels.
>
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
>
> fixed in:
> - 2.6.18.8
> - 2.6.19.2
> - 2.6.20
>
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
>
> fixed in:
> - 2.6.20 (commit dab6df63086762629936e8b89a5984bae39724f6)
>
> missing in:
> - 2.6.18
> - 2.6.19
>
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
>
> fixed in:
> - 2.6.20 (commit be6aab0e9fa6d3c6d75aa1e38ac972d8b4ee82b8)
>
> missing in:
> - 2.6.18
> - 2.6.19
>
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
>
> fixed in:
> - 2.6.19.2
> - 2.6.20
>
> missing in:
> - 2.6.18
>
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
>
> fixed in:
> - 2.6.19.2
> - 2.6.20
>
> missing in:
> - 2.6.18
>
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
>
> fixed in:
> - 2.6.19.2
> - 2.6.20
>
> missing in:
> - 2.6.18
>
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
>
> fixed in:
> - 2.6.19.1
> - 2.6.20
>
> problem not present in:
> - 2.6.18
>
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006
>
> fixed in:
> - 2.6.19.5
>
> missing in:
> - 2.6.18
> - 2.6.20

So maybe 2.6.18 deserves another stable release :) ?


-- 
S.Çağlar Onur <caglar@pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch 00/18] 2.6.18-stable review

[Greg KH]

On Mon, Mar 05, 2007 at 03:44:22PM +0200, S.??a??lar Onur wrote:
> 26 ??ub 2007 Pts tarihinde, Adrian Bunk ??unlar?? yazm????t??: 
> > On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
> > > 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazm????t??:
> > > > Responses should be made by Friday February 23 00:00 UTC.  Anything
> > > > received after that time might be too late.
> > >
> > > We have still some CVEish patches in our package which maybe you want to
> > > consider adding into -stable.
> >
> > Below, I'll only look at the 2.6.18, 2.6.19 and 2.6.20 kernels.
> >
> > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
> >
> > fixed in:
> > - 2.6.18.8
> > - 2.6.19.2
> > - 2.6.20
> >
> > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
> >
> > fixed in:
> > - 2.6.20 (commit dab6df63086762629936e8b89a5984bae39724f6)
> >
> > missing in:
> > - 2.6.18
> > - 2.6.19
> >
> > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
> >
> > fixed in:
> > - 2.6.20 (commit be6aab0e9fa6d3c6d75aa1e38ac972d8b4ee82b8)
> >
> > missing in:
> > - 2.6.18
> > - 2.6.19
> >
> > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
> >
> > fixed in:
> > - 2.6.19.2
> > - 2.6.20
> >
> > missing in:
> > - 2.6.18
> >
> > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
> >
> > fixed in:
> > - 2.6.19.2
> > - 2.6.20
> >
> > missing in:
> > - 2.6.18
> >
> > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
> >
> > fixed in:
> > - 2.6.19.2
> > - 2.6.20
> >
> > missing in:
> > - 2.6.18
> >
> > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
> >
> > fixed in:
> > - 2.6.19.1
> > - 2.6.20
> >
> > problem not present in:
> > - 2.6.18
> >
> > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006
> >
> > fixed in:
> > - 2.6.19.5
> >
> > missing in:
> > - 2.6.18
> > - 2.6.20
> 
> So maybe 2.6.18 deserves another stable release :) ?

Why?  Does anyone really use it now that 2.6.19 and 2.6.20 is out?

I don't want to do a new release as we need to catch up on the 2.6.20
issues...

And also remember, the point of the -stable tree was that we would drop
older releases after the next release came out.

thanks,

greg k-h

Re: [patch 00/18] 2.6.18-stable review

[S.Çağlar Onur]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

05 Mar 2007 Pts tarihinde, Greg KH şunları yazmıştı: 
> > So maybe 2.6.18 deserves another stable release :) ?
>
> Why?  Does anyone really use it now that 2.6.19 and 2.6.20 is out?
>
> I don't want to do a new release as we need to catch up on the 2.6.20
> issues...
>
> And also remember, the point of the -stable tree was that we would drop
> older releases after the next release came out.

I know, i just referred your "Barring anything extremely serious, this will be 
the last 2.6.18 based release." sentence from last stable release 
announcement and some security regressions seems something to me and just 
want to ping :) and of course i clearly understand your point of -stable tree 
maintanence with much more up2date kernel and drop olders view.

Cheers
-- 
S.Çağlar Onur <caglar@pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch 00/18] 2.6.18-stable review

[Hugh Dickins]

On Tue, 20 Feb 2007, Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.18.8 release.
> 
> This will be the last release of the 2.6.18-stable series, so if there
> are patches that you feel should be applied to that tree, please let me
> know.
> 
> Responses should be made by Friday February 23 00:00 UTC.  Anything
> received after that time might be too late.

Sorry I'm late to the party, just climbed through 2000 mails.

I do hope you'll manage an -rc2,
I seem not the only one to notice wanted patches missing.

There's two from 2.6.19-stable that I thought Chris had agreed
for 2.6.18-stable (Linus' mincore and my read_zero_pagealigned);
two that I sent Chris cc stable for 2.6.18-stable on 4th January
(msync and powerpc current); one I know about from 2.6.19-stable
equally desirable in 2.6.18-stable (Badari's shmem_truncate); and
a new one I was waiting to appear in 2.6.21-rc1 before sending
(Tigran's extN noacl umask).

I'm reassembling the six patches against 2.6.18.8-rc1 for these
now (plus a 2.6.19-stable and a 2.6.20-stable for the latter),
will send them to Greg cc stable shortly.

I wonder whether Chris has a tree somewhere, or a mailbox,
containing further goodies which have been missed.

Hugh

Re: [stable] [patch 00/18] 2.6.18-stable review

[Chris Wright]

* Hugh Dickins (hugh@veritas.com) wrote:
> On Tue, 20 Feb 2007, Greg KH wrote:
> > This is the start of the stable review cycle for the 2.6.18.8 release.
> > 
> > This will be the last release of the 2.6.18-stable series, so if there
> > are patches that you feel should be applied to that tree, please let me
> > know.
> > 
> > Responses should be made by Friday February 23 00:00 UTC.  Anything
> > received after that time might be too late.
> 
> Sorry I'm late to the party, just climbed through 2000 mails.
> 
> I do hope you'll manage an -rc2,
> I seem not the only one to notice wanted patches missing.
> 
> There's two from 2.6.19-stable that I thought Chris had agreed
> for 2.6.18-stable (Linus' mincore and my read_zero_pagealigned);
> two that I sent Chris cc stable for 2.6.18-stable on 4th January
> (msync and powerpc current); one I know about from 2.6.19-stable
> equally desirable in 2.6.18-stable (Badari's shmem_truncate); and
> a new one I was waiting to appear in 2.6.21-rc1 before sending
> (Tigran's extN noacl umask).

Yes, you're right.  I've got the first five here, will get those
sorted shortly.

thanks,
-chris

Re: [stable] [patch 00/18] 2.6.18-stable review

[Hugh Dickins]

On Fri, 23 Feb 2007, Chris Wright wrote:
> * Hugh Dickins (hugh@veritas.com) wrote:
> > 
> > There's two from 2.6.19-stable that I thought Chris had agreed
> > for 2.6.18-stable (Linus' mincore and my read_zero_pagealigned);
> > two that I sent Chris cc stable for 2.6.18-stable on 4th January
> > (msync and powerpc current); one I know about from 2.6.19-stable
> > equally desirable in 2.6.18-stable (Badari's shmem_truncate); and
> > a new one I was waiting to appear in 2.6.21-rc1 before sending
> > (Tigran's extN noacl umask).
> 
> Yes, you're right.  I've got the first five here, will get those
> sorted shortly.

Okay, thanks a lot Chris, I'll minimize the noise and stick to
just sending the .18 .19 .20 versions of the last one (umask).

Hugh