headers
Linus Torvalds | 1 Apr 2012 01:58
Gravatar

Linux 3.4-rc1

Ok, it's been two weeks, and the merge window is over. Linux 3.4-rc1
has been pushed out to the git servers, and the tar-ball and patches
are going out as I type this (probably done by the time I'm done).

And yes, if you actually counted, it has only been 13 days. And if
somebody delayed their pull request until the last day of the merge
window, I'm sure they'll be even happier to delay it another two
months until the next merge window. Yay!

That said, there are four pull requests in my mailbox that weren't
delayed, and that I will (probably) still pull, but that I wanted to
get extra confirmation from *other* maintainers from first. So they
were sent in time, I just decided that I can make the actual pull
choice a bit later.

The four remaining pull requests (and the people I want comments from) are:

 - HSI (High Speed Synchronous Serial Interface) framework. I'm
planning on pulling this into 3.4, it's in my queue, but I wanted to
bring it up one more time in case somebody has issues with it. Ping?

 - pohmelfs. The old pohmelfs got deleted from staging, there's an
all-new one waiting in the sidelines. Al was a bit unhappy about some
of it, Evgeniy fixed it up some, and then the discussion died. Again,
I'm likely to pull this, but I wanted more commentary on it.

 - drm dma-buf prime support. Dave Airlie sent me the pull request but
didn't push very hard for it, it's in my "ok, I can still pull it for
3.4 if individual DRM driver people tell me that it will make their
lives easier." So this is in limbo - I have nothing against it, but I
(Continue reading)

Permalink | Reply | 28 comments |
headers
H. Peter Anvin | 1 Apr 2012 02:00
Favicon

[PATCH] x86-32: A better system call mechanism

On x86-32, we currently use int $0x80 as the primary system call
mechanism.  Although there are some recent variants available on
certain hardware (sysenter, syscall) via the vdso, the primary system
call vector is still way up the interrupt vector table, which is
inefficient.

This patch adds a very small amount of code which permits the very
first vector to be used for system call.  That vector is #DE, divide
error, generally known as division by zero.

An example of how to use this new system call mechanism:

	.text
	.globl	_start
_start:
	movl $__NR_write, %eax
	movl $1, %ebx
	movl $str_1, %ecx
	movl $str_1_len, %edx
	aam $0

	movl $__NR_write, %eax
	movl $1, %ebx
	movl $str_2, %ecx
	movl $str_2_len, %edx
	divl %edx

	movl $__NR_exit, %eax
	xorl %ebx, %ebx
	divl %edx
(Continue reading)

Permalink | Reply | 2 comments |
headers
Indan Zupancic | 1 Apr 2012 01:47
Picon

Re: [PATCH] net: bpf_jit: fix BPF_S_ALU_AND_K compilation

On Sun, April 1, 2012 01:13, Greg KH wrote:
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
>
> </formletter>

Thanks for pointing that out. It won't happen again.

Greetings,

Indan
Permalink | Reply | 0 comments |
headers
Christoph Hellwig | 1 Apr 2012 02:09
Favicon

Re: Linux 3.4-rc1

On Sat, Mar 31, 2012 at 04:58:35PM -0700, Linus Torvalds wrote:
>  - pohmelfs. The old pohmelfs got deleted from staging, there's an
> all-new one waiting in the sidelines. Al was a bit unhappy about some
> of it, Evgeniy fixed it up some, and then the discussion died. Again,
> I'm likely to pull this, but I wanted more commentary on it.

I haven't looked at the code, but given that the old one basically
bitrotted after it got merged and I've not even heard about any
users of it I would suggest not to merge it for now.
Permalink | Reply | 0 comments |
headers
Jeff Layton | 1 Apr 2012 02:18
Picon
Favicon

Re: [ 105/175] CIFS: Respect negotiated MaxMpxCount

On Fri, 30 Mar 2012 12:50:10 -0700
Greg KH <gregkh <at> linuxfoundation.org> wrote:

> 3.3-stable review patch.  If anyone has any objections, please let me know.
> 

I'm not sure it's a good idea to put this patch into any stable release
just yet. I think it's a correct and necessary fix, but it has some
potential to cause regressions too (or uncover other preexisting
problems with this code). Might it be best to wait until we have some
more experience with this before we push it into stable?

> ------------------
> 
> From: Pavel Shilovsky <piastry <at> etersoft.ru>
> 
> commit 10b9b98e41ba248a899f6175ce96ee91431b6194 upstream.
> 
> Some servers sets this value less than 50 that was hardcoded and
> we lost the connection if when we exceed this limit. Fix this by
> respecting this value - not sending more than the server allows.
> 
> Reviewed-by: Jeff Layton <jlayton <at> samba.org>
> Signed-off-by: Pavel Shilovsky <piastry <at> etersoft.ru>
> Signed-off-by: Steve French <smfrench <at> gmail.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh <at> linuxfoundation.org>
> 
> ---
>  fs/cifs/cifsfs.c    |    8 ++++----
>  fs/cifs/cifsglob.h  |   10 +++-------
(Continue reading)

Permalink | Reply | 2 comments |
headers
Wang YanQing | 1 Apr 2012 02:47
Picon

[PATCH] video:uvesafb: Fix oops that uvesafb try to execute NX-protected page


This patch fix the oops below that catched in my machine

[   81.560602] uvesafb: NVIDIA Corporation, GT216 Board - 0696a290, Chip Rev   , OEM: NVIDIA, VBE v3.0
[   81.609384] uvesafb: protected mode interface info at c000:d350
[   81.609388] uvesafb: pmi: set display start = c00cd3b3, set palette = c00cd40e
[   81.609390] uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da
[   81.614558] uvesafb: VBIOS/hardware doesn't support DDC transfers
[   81.614562] uvesafb: no monitor limits have been set, default refresh rate will be used
[   81.614994] uvesafb: scrolling: ypan using protected mode interface, yres_virtual=4915
[   81.744147] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[   81.744153] BUG: unable to handle kernel paging request at c00cd3b3
[   81.744159] IP: [<c00cd3b3>] 0xc00cd3b2
[   81.744167] *pdpt = 00000000016d6001 *pde = 0000000001c7b067 *pte = 80000000000cd163
[   81.744171] Oops: 0011 [#1] SMP
[   81.744174] Modules linked in: uvesafb(+) cfbcopyarea cfbimgblt cfbfillrect
[   81.744178]
[   81.744181] Pid: 3497, comm: modprobe Not tainted 3.3.0-rc4NX+ #71 Acer            Aspire 4741                    /Aspire 4741
[   81.744185] EIP: 0060:[<c00cd3b3>] EFLAGS: 00010246 CPU: 0
[   81.744187] EIP is at 0xc00cd3b3
[   81.744189] EAX: 00004f07 EBX: 00000000 ECX: 00000000 EDX: 00000000
[   81.744191] ESI: f763f000 EDI: f763f6e8 EBP: f57f3a0c ESP: f57f3a00
[   81.744192]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   81.744195] Process modprobe (pid: 3497, ti=f57f2000 task=f748c600 task.ti=f57f2000)
[   81.744196] Stack:
[   81.744197]  f82512c5 f759341c 00000000 f57f3a30 c124a9bc 00000001 00000001 000001e0
[   81.744202]  f8251280 f763f000 f7593400 00000000 f57f3a40 c12598dd f5c0c000 00000000
[   81.744206]  f57f3b10 c1255efe c125a21a 00000006 f763f09c 00000000 c1c6cb60 f7593400
[   81.744210] Call Trace:
[   81.744215]  [<f82512c5>] ? uvesafb_pan_display+0x45/0x60 [uvesafb]
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wang YanQing | 1 Apr 2012 02:54
Picon

[PATCH] video:uvesafb: Fix oops that uvesafb try to execute NX-protected page

This patch fix the oops below that catched in my machine

[   81.560602] uvesafb: NVIDIA Corporation, GT216 Board - 0696a290, Chip Rev   , OEM: NVIDIA, VBE v3.0
[   81.609384] uvesafb: protected mode interface info at c000:d350
[   81.609388] uvesafb: pmi: set display start = c00cd3b3, set palette = c00cd40e
[   81.609390] uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da
[   81.614558] uvesafb: VBIOS/hardware doesn't support DDC transfers
[   81.614562] uvesafb: no monitor limits have been set, default refresh rate will be used
[   81.614994] uvesafb: scrolling: ypan using protected mode interface, yres_virtual=4915
[   81.744147] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[   81.744153] BUG: unable to handle kernel paging request at c00cd3b3
[   81.744159] IP: [<c00cd3b3>] 0xc00cd3b2
[   81.744167] *pdpt = 00000000016d6001 *pde = 0000000001c7b067 *pte = 80000000000cd163
[   81.744171] Oops: 0011 [#1] SMP
[   81.744174] Modules linked in: uvesafb(+) cfbcopyarea cfbimgblt cfbfillrect
[   81.744178]
[   81.744181] Pid: 3497, comm: modprobe Not tainted 3.3.0-rc4NX+ #71 Acer            Aspire 4741                    /Aspire 4741
[   81.744185] EIP: 0060:[<c00cd3b3>] EFLAGS: 00010246 CPU: 0
[   81.744187] EIP is at 0xc00cd3b3
[   81.744189] EAX: 00004f07 EBX: 00000000 ECX: 00000000 EDX: 00000000
[   81.744191] ESI: f763f000 EDI: f763f6e8 EBP: f57f3a0c ESP: f57f3a00
[   81.744192]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   81.744195] Process modprobe (pid: 3497, ti=f57f2000 task=f748c600 task.ti=f57f2000)
[   81.744196] Stack:
[   81.744197]  f82512c5 f759341c 00000000 f57f3a30 c124a9bc 00000001 00000001 000001e0
[   81.744202]  f8251280 f763f000 f7593400 00000000 f57f3a40 c12598dd f5c0c000 00000000
[   81.744206]  f57f3b10 c1255efe c125a21a 00000006 f763f09c 00000000 c1c6cb60 f7593400
[   81.744210] Call Trace:
[   81.744215]  [<f82512c5>] ? uvesafb_pan_display+0x45/0x60 [uvesafb]
[   81.744222]  [<c124a9bc>] fb_pan_display+0x10c/0x160
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wang YanQing | 1 Apr 2012 02:55
Picon

Re: [PATCH] video:uvesafb: Fix oops that uvesafb try to execute NX-protected page

On Sun, Apr 01, 2012 at 08:47:28AM +0800, Wang YanQing wrote:
> 
> This patch fix the oops below that catched in my machine
> 
> [   81.560602] uvesafb: NVIDIA Corporation, GT216 Board - 0696a290, Chip Rev   , OEM: NVIDIA, VBE v3.0
> [   81.609384] uvesafb: protected mode interface info at c000:d350
> [   81.609388] uvesafb: pmi: set display start = c00cd3b3, set palette = c00cd40e
> [   81.609390] uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da
> [   81.614558] uvesafb: VBIOS/hardware doesn't support DDC transfers
> [   81.614562] uvesafb: no monitor limits have been set, default refresh rate will be used
> [   81.614994] uvesafb: scrolling: ypan using protected mode interface, yres_virtual=4915
> [   81.744147] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
> [   81.744153] BUG: unable to handle kernel paging request at c00cd3b3
> [   81.744159] IP: [<c00cd3b3>] 0xc00cd3b2
> [   81.744167] *pdpt = 00000000016d6001 *pde = 0000000001c7b067 *pte = 80000000000cd163
> [   81.744171] Oops: 0011 [#1] SMP
> [   81.744174] Modules linked in: uvesafb(+) cfbcopyarea cfbimgblt cfbfillrect
> [   81.744178]
> [   81.744181] Pid: 3497, comm: modprobe Not tainted 3.3.0-rc4NX+ #71 Acer            Aspire 4741                    /Aspire 4741
> [   81.744185] EIP: 0060:[<c00cd3b3>] EFLAGS: 00010246 CPU: 0
> [   81.744187] EIP is at 0xc00cd3b3
> [   81.744189] EAX: 00004f07 EBX: 00000000 ECX: 00000000 EDX: 00000000
> [   81.744191] ESI: f763f000 EDI: f763f6e8 EBP: f57f3a0c ESP: f57f3a00
> [   81.744192]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> [   81.744195] Process modprobe (pid: 3497, ti=f57f2000 task=f748c600 task.ti=f57f2000)
> [   81.744196] Stack:
> [   81.744197]  f82512c5 f759341c 00000000 f57f3a30 c124a9bc 00000001 00000001 000001e0
> [   81.744202]  f8251280 f763f000 f7593400 00000000 f57f3a40 c12598dd f5c0c000 00000000
> [   81.744206]  f57f3b10 c1255efe c125a21a 00000006 f763f09c 00000000 c1c6cb60 f7593400
> [   81.744210] Call Trace:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wang YanQing | 1 Apr 2012 03:05
Picon

Re: [PATCH] video:uvesafb: Fix oops that uvesafb try to execute NX-protected page

On Wed, Mar 28, 2012 at 08:52:38AM +0800, Wang YanQing wrote:
> On Tue, Mar 27, 2012 at 02:32:43PM +0100, Alan Cox wrote:
> > On Tue, 27 Mar 2012 18:01:36 +0800
> > Wang YanQing <udknight <at> gmail.com> wrote:
> > 
> > > 
> > > Ok! I try to check pcibios_enabled first, but get some opposition by Alan Cox,
> > > but I want to make thing work and fix the oops, so I choice the simple way to
> > > check the (__supported_pte_mask & _PAGE_NX) instead of to check this variable plus
> > > pci kernel boot parameter, pci mmconfig works or not, and more, and more. It is not
> > > the best method, but it works and maybe all will feel happy.
> > 
> > Okay let me ask the obvious question - why is it not the best method ?
> > 
> > Apart from adding a helper in the includes for the arch code of
> > 
> > 	static inline is_nx_enabled(void)
> > 	{
> > 		return !!(__supported_pte_mask & _PAGE_NX);
> > 	}
> > 
> > is there anything else it lacks ?
> > 
> > Yes ideally we'd set the relevant ROM areas executable, but for a simple
> > fix is there anything else that's a problem with it ?
> Ok! Maybe you had missed my previous reply
> http://permalink.gmane.org/gmane.linux.kernel/1272433
> It is not the best method, because the check is not enough.
> I means when NX is actively, the pci bios is NX or not also depend on
> the code path in pci_arch_init which will be influenced by the acpi on or off, pci kernel boot
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Gortmaker | 1 Apr 2012 03:29
Favicon

linux-next: triage for March 31, 2012

This represents the state of the builds as of Friday, since there
are no weekend linux-next builds.  This is still the 3.4 content.

Lots of breakage to report.  Most of it appears to be caused by
the asm/system.h split up going directly into Linus' tree without
any soak in linux-next.  Lets hope we can avoid this in the future.

I'm not going to list all the fails individually because there are
simply too many.  I'll try and do an arch overview and capture
what has been fixed already and what may remain as unfixed.

Note that "fixed" does not imply it made it into 3.4-rc1; I've
not yet checked what made it there.  But since we now have 3.4-rc1
I'm assuming that linux-next will move onto the 3.5 content, and
so we'll be largely changing context with these triage reports,
and this will represent the last 3.4 based status report.

Of course if breakage is due to mainline commits, please work
to get those in the pending 3.4-rcN (N>1) releases.  I think
the system.h fallout definitely falls into this category.

That said, the asm/system.h breakage that _should_ be fixed:

   ARM: ~10 fails. Olof has run all the defconfigs, and I think fixed them all
	http://lists.arm.linux.org.uk/lurker/message/20120330.143801.0025ae2c.en.html
	http://lists.arm.linux.org.uk/lurker/message/20120330.232025.982eba3a.en.html

   SPARC: SamR/DaveM have already got the fixes to Linus
	http://marc.info/?l=linux-sparc&m=133315678827041&w=2
(Continue reading)

Permalink | Reply | 0 comments |

Gmane