Re: [PATCH] ARM: DMA-mapping: add missing GFP_DMA flag for atomic buffer allocation
On Wed, Mar 20, 2013 at 07:33:18AM +0100, Marek Szyprowski wrote: > Hello, > > On 3/19/2013 3:24 PM, Luis Henriques wrote: > >Hi Marek, > > > >On Tue, Mar 19, 2013 at 08:24:21AM +0100, Marek Szyprowski wrote: > >> commit 9d1400cf79afb49584b4873eb22cd5130cb341db upstream. > >> > >> Atomic pool should always be allocated from DMA zone if such zone is > >> available in the system to avoid issues caused by limited dma mask of > >> any of the devices used for making an atomic allocation. > >> > >> Reported-by: Krzysztof Halasa > >> Signed-off-by: Marek Szyprowski > >> Cc: Stable [v3.6+] > >> --- > >> Hello, > >> > >> This is a backported version of mainline 9d1400cf79afb49584b commit. > >> It should apply fine to v3.8.y, v3.7.y and v3.6.y stable kernel trees. > > > >Could you confirm this should *not* be added to 3.5 kernels? > > This patch fixes issue introduced by commit > e9da6e9905e639b0f842a244bc770b48ad0523e9, > which has been merged to v3.6-rc1. All v3.5.x and earlier are not > affected by this > bug. I should have added such information to commit message to avoid > confusion. Thank you for confirming this; I'll ignore it for the 3.5 kernel. Cheers, -- Luis -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#703271: linux-image-3.2.0-4-amd64: Fix brightness hotkeys on ASUS UX31A laptop
Le mercredi 20 mars 2013 à 03:14 +, Ben Hutchings a écrit : > On Sun, 2013-03-17 at 21:54 +0100, Vincent Blut wrote: > > Package: src:linux > > Version: 3.2.39-2 > > Severity: normal > > Tags: upstream > > > > Hi, > > > > Since Linux 3.7, the brightness hotkeys work on this laptop. Initially I > > thought that this support was added by a specific plateform driver > > commit but after diving in git log it didn't make any sense about why these > > hotkeys worked in 3.7 so I started to bisect in order to find the > > culprit. Here it is: > > Please apply this to stable branches earlier than 3.7. It doesn't > appear to depend on any other changes post-3.0. Hi Ben, As you can see in my bug report, I was using 3.2.40+ (your last longterm release with this patch). > > > >From d627b62ff8d4d36761adbcd90ff143d79c94ab22 Mon Sep 17 00:00:00 2001 > > From: Lekensteyn > > Date: Mon, 25 Jun 2012 22:36:24 + > > Subject: i915: initialize CADL in opregion > [...] > > Well, after this result I was puzzled because it seemed to be a > > Clevo specific issue but I decided to give it a try and effectively it > > gave me the expected behavior, so please could you add it in the next > > Wheezy upload? > > > > Also this should probably be forwarded to stable@vger.kernel.org with a > > revised commit message stipulating that not only Clevo laptop are > > affected, don't know if it is possible though. > > Normally the original commit message is used unchanged. > Ok > Ben. > Cheers, Vincent -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kernel panic on stable kernel 3.8.2 when closing bluetooth dun connection
Hi, This is just a short note to let you know that 3.8.2 panics on closing a bluetooth dun connection. This is seen with the ubuntu mainline kernel 3.8.2 that should be a vanilla stable kernel. Observed on a DELL E6500 which has BCM2046 Bluetooth while connecting to the internet using a Samsung Galaxy S mobile phone via bluetooth DUN through the network manager. When network manager is asked to close the connection, the kernel panics, the system drops out of Xorg, shows for a couple of seconds a long log including the words 'panic' and 'not synching', the numlock, caps-lock keys start flashing and the system freezes. It is 100% repeatable. The ubuntu kernel, that is a 3.5.0 plus ubuntu tweaks, backports, etc does not panic. Thanks for the attention and best regards, Sergio Callegari -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] powerpc/uprobes: teach uprobes to ignore gdb breakpoints
From: Ananth N Mavinakayanahalli
GDB uses a variant of the trap instruction that is different from the
one used by uprobes. Currently, running gdb on a program being traced
by uprobes causes an endless loop since uprobes doesn't understand
that the trap is inserted by some other entity and hence a SIGTRAP needs
to be delivered.
Teach uprobes to ignore breakpoints that doesn't belong to it.
Signed-off-by: Ananth N Mavinakayanahalli
Cc: stable@vger.kernel.org
---
arch/powerpc/kernel/uprobes.c | 10 ++
1 file changed, 10 insertions(+)
Index: linux-3.9-rc3/arch/powerpc/kernel/uprobes.c
===
--- linux-3.9-rc3.orig/arch/powerpc/kernel/uprobes.c
+++ linux-3.9-rc3/arch/powerpc/kernel/uprobes.c
@@ -80,6 +80,16 @@ unsigned long uprobe_get_swbp_addr(struc
return instruction_pointer(regs);
}
+/**
+ * is_swbp_insn - check if the instruction is a breakpoint instruction.
+ * @insn: instruction to be checked.
+ * Returns true if @insn is a breakpoint instruction.
+ */
+bool is_swbp_insn(uprobe_opcode_t *insn)
+{
+ return (is_trap(*insn));
+}
+
/*
* If xol insn itself traps and generates a signal (SIGILL/SIGSEGV/etc),
* then detect the case where a singlestepped instruction jumps back to its
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] xen/events: avoid race with raising an event in unmask_evtchn()
On Tue, 19 Mar 2013, David Vrabel wrote:
> From: David Vrabel
>
> In unmask_evtchn(), when the mask bit is cleared after testing for
> pending and the event becomes pending between the test and clear, then
> the upcall will not become pending and the event may be lost or
> delayed.
>
> Avoid this by always clearing the mask bit before checking for
> pending.
>
> This fixes a regression introduced in 3.7 by
> b5e579232d635b79a3da052964cb357ccda8d9ea (xen/events: fix
> unmask_evtchn for PV on HVM guests) which reordered the clear mask and
> check pending operations.
The race you are trying to fix is real, but the fix you are proposing
breaks PV on HVM and ARM guests again.
>From the description of b5e579232d635b79a3da052964cb357ccda8d9ea, it's
clear that the reason to call EVTCHNOP_unmask is to trigger an event
notification injection again.
But if you clear the evtchn_mask bit *before* calling EVTCHNOP_unmask,
EVTCHNOP_unmask won't reinject the event.
>From evtchn_unmask:
if ( test_and_clear_bit(port, &shared_info(d, evtchn_mask)) &&
test_bit (port, &shared_info(d, evtchn_pending)) &&
!test_and_set_bit (port / BITS_PER_EVTCHN_WORD(d),
&vcpu_info(v, evtchn_pending_sel)) )
{
vcpu_mark_events_pending(v);
}
The first condition for reinjection would fail.
> Signed-off-by: David Vrabel
> Cc: stable@vger.kernel.org
> Cc: Stefano Stabellini
> ---
> drivers/xen/events.c | 10 +-
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index d17aa41..4bdd0a5 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -403,11 +403,13 @@ static void unmask_evtchn(int port)
>
> if (unlikely((cpu != cpu_from_evtchn(port
> do_hypercall = 1;
> - else
> + else {
> + sync_clear_bit(port, BM(&s->evtchn_mask[0]));
> evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
>
> - if (unlikely(evtchn_pending && xen_hvm_domain()))
> - do_hypercall = 1;
> + if (unlikely(evtchn_pending && xen_hvm_domain()))
> + do_hypercall = 1;
> + }
>
> /* Slow path (hypercall) if this is a non-local port or if this is
>* an hvm domain and an event is pending (hvm domains don't have
> @@ -418,8 +420,6 @@ static void unmask_evtchn(int port)
> } else {
> struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
>
> - sync_clear_bit(port, BM(&s->evtchn_mask[0]));
> -
> /*
>* The following is basically the equivalent of
>* 'hw_resend_irq'. Just like a real IO-APIC we 'lose
> --
> 1.7.2.5
>
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] powerpc/uprobes: teach uprobes to ignore gdb breakpoints
Hi Ananth,
First of all, let me remind that I know nothing about powerpc ;)
But iirc we already discussed this a bit, I forgot the details but
still I have some concerns...
On 03/20, Ananth N Mavinakayanahalli wrote:
>
> GDB uses a variant of the trap instruction that is different from the
> one used by uprobes. Currently, running gdb on a program being traced
> by uprobes causes an endless loop since uprobes doesn't understand
> that the trap is inserted by some other entity and hence a SIGTRAP needs
> to be delivered.
Yes, and thus is_swbp_at_addr()->is_swbp_insn() called by handle_swbp()
should be updated,
> +bool is_swbp_insn(uprobe_opcode_t *insn)
> +{
> + return (is_trap(*insn));
> +}
And this patch should fix the problem. (and probably this is fine
for prepare_uprobe()).
But, at the same time, is the new definition fine for verify_opcode()?
IOW, powerpc has another is_trap() insn(s) used by gdb, lets denote it X.
X != UPROBE_SWBP_INSN.
Suppose that gdb installs the trap X at some addr, and then uprobe_register()
tries to install uprobe at the same address. Then set_swbp() will do nothing,
assuming the uprobe was already installed.
But we did not install UPROBE_SWBP_INSN. Is it fine? I hope yes, just to
verify. If not, we need 2 definitions. is_uprobe_insn() should still check
insns == UPROBE_SWBP_INSN, and is_swbp_insn() should check is_trap().
And I am just curious, could you explain how X and UPROBE_SWBP_INSN
differ?
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ext4: fix data=journal fast mount/umount hang
In data=journal mode, if we unmount the file system before a
transaction has a chance to complete, when the journal inode is being
evicted, we can end up calling into jbd2_log_wait_commit() for the
current transaction.
Arguably we should adjust ext4_should_journal_data() to return FALSE
for the journal inode, but the only place it matters is
ext4_evict_inode(), and so it's to save a bit of CPU time, and to make
the patch much more obviously correct by inspection(tm), we'll fix it
by explicitly not trying to waiting for a journal commit when we are
evicting the journal inode, since it's guaranteed to never succeed in
this case.
This can be easily replicated via:
mount -t ext4 -o data=journal /dev/vdb /vdb ; umount /vdb
[ cut here ]
WARNING: at /usr/projects/linux/ext4/fs/jbd2/journal.c:542
__jbd2_log_start_commit+0xba/0xcd()
Hardware name: Bochs
JBD2: bad log_start_commit: 3005630206 3005630206 0 0
Modules linked in:
Pid: 2909, comm: umount Not tainted 3.8.0-rc3 #1020
Call Trace:
[] warn_slowpath_common+0x68/0x7d
[] ? __jbd2_log_start_commit+0xba/0xcd
[] warn_slowpath_fmt+0x2b/0x2f
[] __jbd2_log_start_commit+0xba/0xcd
[] jbd2_log_start_commit+0x24/0x34
[] ext4_evict_inode+0x71/0x2e3
[] evict+0x94/0x135
[] iput+0x10a/0x110
[] jbd2_journal_destroy+0x190/0x1ce
[] ? bit_waitqueue+0x50/0x50
[] ext4_put_super+0x52/0x294
[] generic_shutdown_super+0x48/0xb4
[] kill_block_super+0x22/0x60
[] deactivate_locked_super+0x22/0x49
[] deactivate_super+0x30/0x33
[] mntput_no_expire+0x107/0x10c
[] sys_umount+0x2cf/0x2e0
[] sys_oldumount+0x12/0x14
[] syscall_call+0x7/0xb
---[ end trace 6a954cc790501c1f ]---
jbd2_log_wait_commit: error: j_commit_request=-1289337090, tid=0
Signed-off-by: "Theodore Ts'o"
Cc: Jan Kara
Cc: stable@vger.kernel.org
---
fs/ext4/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 15e0da1..0a6434c 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -205,7 +205,8 @@ void ext4_evict_inode(struct inode *inode)
* don't use page cache.
*/
if (ext4_should_journal_data(inode) &&
- (S_ISLNK(inode->i_mode) || S_ISREG(inode->i_mode))) {
+ (S_ISLNK(inode->i_mode) || S_ISREG(inode->i_mode)) &&
+ inode->i_ino != EXT4_JOURNAL_INO) {
journal_t *journal = EXT4_SB(inode->i_sb)->s_journal;
tid_t commit_tid = EXT4_I(inode)->i_datasync_tid;
--
1.7.12.rc0.22.gcdd159b
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] powerpc/uprobes: teach uprobes to ignore gdb breakpoints
On 03/20, Oleg Nesterov wrote:
>
> But we did not install UPROBE_SWBP_INSN. Is it fine? I hope yes, just to
> verify. If not, we need 2 definitions. is_uprobe_insn() should still check
> insns == UPROBE_SWBP_INSN, and is_swbp_insn() should check is_trap().
>
> And I am just curious, could you explain how X and UPROBE_SWBP_INSN
> differ?
IOW, if I wasn't clear... Lets forget about gdb/etc for the moment.
Suppose we apply the patch below. Will uprobes on powerpc work?
If yes, then your patch should be fine. If not, we probably need more
changes.
And, forgot to mention. If you change is_swbp_insn(), you can remove
is_trap() from arch_uprobe_analyze_insn().
Oleg.
--- x/arch/powerpc/include/asm/uprobes.h
+++ x/arch/powerpc/include/asm/uprobes.h
@@ -31,7 +31,7 @@ typedef ppc_opcode_t uprobe_opcode_t;
#define UPROBE_XOL_SLOT_BYTES (MAX_UINSN_BYTES)
/* The following alias is needed for reference from arch-agnostic code */
-#define UPROBE_SWBP_INSN BREAKPOINT_INSTRUCTION
+#define UPROBE_SWBP_INSN TRAP_INSN_USED_BY_GDB
#define UPROBE_SWBP_INSN_SIZE 4 /* swbp insn size in bytes */
struct arch_uprobe {
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ext4: fix data=journal fast mount/umount hang
On Wed 20-03-13 08:37:37, Ted Tso wrote:
> In data=journal mode, if we unmount the file system before a
> transaction has a chance to complete, when the journal inode is being
> evicted, we can end up calling into jbd2_log_wait_commit() for the
> current transaction.
>
> Arguably we should adjust ext4_should_journal_data() to return FALSE
> for the journal inode, but the only place it matters is
> ext4_evict_inode(), and so it's to save a bit of CPU time, and to make
> the patch much more obviously correct by inspection(tm), we'll fix it
> by explicitly not trying to waiting for a journal commit when we are
> evicting the journal inode, since it's guaranteed to never succeed in
> this case.
>
> This can be easily replicated via:
>
> mount -t ext4 -o data=journal /dev/vdb /vdb ; umount /vdb
>
> [ cut here ]
> WARNING: at /usr/projects/linux/ext4/fs/jbd2/journal.c:542
> __jbd2_log_start_commit+0xba/0xcd()
> Hardware name: Bochs
> JBD2: bad log_start_commit: 3005630206 3005630206 0 0
> Modules linked in:
> Pid: 2909, comm: umount Not tainted 3.8.0-rc3 #1020
> Call Trace:
> [] warn_slowpath_common+0x68/0x7d
> [] ? __jbd2_log_start_commit+0xba/0xcd
> [] warn_slowpath_fmt+0x2b/0x2f
> [] __jbd2_log_start_commit+0xba/0xcd
> [] jbd2_log_start_commit+0x24/0x34
> [] ext4_evict_inode+0x71/0x2e3
> [] evict+0x94/0x135
> [] iput+0x10a/0x110
> [] jbd2_journal_destroy+0x190/0x1ce
> [] ? bit_waitqueue+0x50/0x50
> [] ext4_put_super+0x52/0x294
> [] generic_shutdown_super+0x48/0xb4
> [] kill_block_super+0x22/0x60
> [] deactivate_locked_super+0x22/0x49
> [] deactivate_super+0x30/0x33
> [] mntput_no_expire+0x107/0x10c
> [] sys_umount+0x2cf/0x2e0
> [] sys_oldumount+0x12/0x14
> [] syscall_call+0x7/0xb
> ---[ end trace 6a954cc790501c1f ]---
> jbd2_log_wait_commit: error: j_commit_request=-1289337090, tid=0
>
> Signed-off-by: "Theodore Ts'o"
> Cc: Jan Kara
> Cc: stable@vger.kernel.org
Looks good. You can add:
Reviewed-by: Jan Kara
I'll also push a similar fix to ext3.
Honza
> ---
> fs/ext4/inode.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 15e0da1..0a6434c 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -205,7 +205,8 @@ void ext4_evict_inode(struct inode *inode)
>* don't use page cache.
>*/
> if (ext4_should_journal_data(inode) &&
> - (S_ISLNK(inode->i_mode) || S_ISREG(inode->i_mode))) {
> + (S_ISLNK(inode->i_mode) || S_ISREG(inode->i_mode)) &&
> + inode->i_ino != EXT4_JOURNAL_INO) {
> journal_t *journal = EXT4_SB(inode->i_sb)->s_journal;
> tid_t commit_tid = EXT4_I(inode)->i_datasync_tid;
>
> --
> 1.7.12.rc0.22.gcdd159b
>
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ext4: fix data=journal fast mount/umount hang
On Wed, Mar 20, 2013 at 02:38:11PM +0100, Jan Kara wrote:
> I'll also push a similar fix to ext3.
Great. I did make some minor adjustments to the commit description
for clarity's sake, and to fix a typo.
- Ted
>From ed4fe107ccba4424a9a074b060172eb390691ffa Mon Sep 17 00:00:00 2001
From: Theodore Ts'o
Date: Wed, 20 Mar 2013 09:42:11 -0400
Subject: [PATCH] ext4: fix data=journal fast mount/umount hang
In data=journal mode, if we unmount the file system before a
transaction has a chance to complete, when the journal inode is being
evicted, we can end up calling into jbd2_log_wait_commit() for the
last transaction, after the journalling machinery has been shut down.
Arguably we should adjust ext4_should_journal_data() to return FALSE
for the journal inode, but the only place it matters is
ext4_evict_inode(), and so to save a bit of CPU time, and to make the
patch much more obviously correct by inspection(tm), we'll fix it by
explicitly not trying to waiting for a journal commit when we are
evicting the journal inode, since it's guaranteed to never succeed in
this case.
This can be easily replicated via:
mount -t ext4 -o data=journal /dev/vdb /vdb ; umount /vdb
[ cut here ]
WARNING: at /usr/projects/linux/ext4/fs/jbd2/journal.c:542
__jbd2_log_start_commit+0xba/0xcd()
Hardware name: Bochs
JBD2: bad log_start_commit: 3005630206 3005630206 0 0
Modules linked in:
Pid: 2909, comm: umount Not tainted 3.8.0-rc3 #1020
Call Trace:
[] warn_slowpath_common+0x68/0x7d
[] ? __jbd2_log_start_commit+0xba/0xcd
[] warn_slowpath_fmt+0x2b/0x2f
[] __jbd2_log_start_commit+0xba/0xcd
[] jbd2_log_start_commit+0x24/0x34
[] ext4_evict_inode+0x71/0x2e3
[] evict+0x94/0x135
[] iput+0x10a/0x110
[] jbd2_journal_destroy+0x190/0x1ce
[] ? bit_waitqueue+0x50/0x50
[] ext4_put_super+0x52/0x294
[] generic_shutdown_super+0x48/0xb4
[] kill_block_super+0x22/0x60
[] deactivate_locked_super+0x22/0x49
[] deactivate_super+0x30/0x33
[] mntput_no_expire+0x107/0x10c
[] sys_umount+0x2cf/0x2e0
[] sys_oldumount+0x12/0x14
[] syscall_call+0x7/0xb
---[ end trace 6a954cc790501c1f ]---
jbd2_log_wait_commit: error: j_commit_request=-1289337090, tid=0
Signed-off-by: "Theodore Ts'o"
Reviewed-by: Jan Kara
Cc: stable@vger.kernel.org
---
fs/ext4/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 15e0da1..0a6434c 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -205,7 +205,8 @@ void ext4_evict_inode(struct inode *inode)
* don't use page cache.
*/
if (ext4_should_journal_data(inode) &&
- (S_ISLNK(inode->i_mode) || S_ISREG(inode->i_mode))) {
+ (S_ISLNK(inode->i_mode) || S_ISREG(inode->i_mode)) &&
+ inode->i_ino != EXT4_JOURNAL_INO) {
journal_t *journal = EXT4_SB(inode->i_sb)->s_journal;
tid_t commit_tid = EXT4_I(inode)->i_datasync_tid;
--
1.7.12.rc0.22.gcdd159b
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm/x86: Patch out arch_flush_lazy_mmu_mode() when running on bare metal
- jwbo...@redhat.com wrote: > On Wed, Mar 13, 2013 at 09:25:44AM -0400, Boris Ostrovsky wrote: > > On 03/01/2013 07:14 AM, Josh Boyer wrote: > > >On Thu, Feb 28, 2013 at 04:52:20PM -0800, H. Peter Anvin wrote: > > >>On 02/28/2013 04:42 PM, Josh Boyer wrote: > > >>>On Fri, Mar 01, 2013 at 01:36:29AM +0100, Borislav Petkov wrote: > > On Thu, Feb 28, 2013 at 04:15:45PM -0800, H. Peter Anvin wrote: > > >>I'll try to get someone to test this tomorrow. > > Btw, you'd need to apply that other patch too > > > > http://marc.info/?l=xen-devel&m=136206183814547&w=2 > > > > so that arch_flush_lazy_mmu_mode() has at least one caller on > x86_64. > > >>>Yeah, we already have that applied. It stops crashes in xen > > >>>environments so we pulled it in as a bugfix. Thanks though! > > >>> > > >>Who are "we"? > > >Sorry, Fedora. That patch has a link to a bug in it. We applied > the > > >patch for that bug. I'll apply Boris' patch on top and get the > same > > >people to test it. > > > > Josh, have you had a chance to test this? > > I've tested it on bare metal for a while now. No problems noticed at > all. I've not heard back from Krishna who was testing it in the Xen > environment. Krishna? Any updates? Thanks. -boris -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Revert "crypto: caam - add IPsec ESN support"
This reverts commit 891104ed008e8646c7860fe5bc70b0aac55dcc6c
(upstream: 891104ed008e8646c7860fe5bc70b0aac55dcc6c).
Current IPsec ESN implementation for authencesn(cbc(aes), hmac(sha))
(separate encryption and integrity algorithms) does not conform
to RFC4303.
ICV is generated by hashing the sequence
SPI, SeqNum-High, SeqNum-Low, IV, Payload
instead of
SPI, SeqNum-Low, IV, Payload, SeqNum-High.
Cc: # 3.8, 3.7
Reported-by: Chaoxing Lin
Signed-off-by: Horia Geanta
---
drivers/crypto/caam/caamalg.c | 27 ++-
drivers/crypto/caam/compat.h |1 -
2 files changed, 2 insertions(+), 26 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index b2a0a07..cf268b1 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -1650,11 +1650,7 @@ struct caam_alg_template {
};
static struct caam_alg_template driver_algs[] = {
- /*
-* single-pass ipsec_esp descriptor
-* authencesn(*,*) is also registered, although not present
-* explicitly here.
-*/
+ /* single-pass ipsec_esp descriptor */
{
.name = "authenc(hmac(md5),cbc(aes))",
.driver_name = "authenc-hmac-md5-cbc-aes-caam",
@@ -2217,9 +2213,7 @@ static int __init caam_algapi_init(void)
for (i = 0; i < ARRAY_SIZE(driver_algs); i++) {
/* TODO: check if h/w supports alg */
struct caam_crypto_alg *t_alg;
- bool done = false;
-authencesn:
t_alg = caam_alg_alloc(ctrldev, &driver_algs[i]);
if (IS_ERR(t_alg)) {
err = PTR_ERR(t_alg);
@@ -2233,25 +2227,8 @@ authencesn:
dev_warn(ctrldev, "%s alg registration failed\n",
t_alg->crypto_alg.cra_driver_name);
kfree(t_alg);
- } else {
+ } else
list_add_tail(&t_alg->entry, &priv->alg_list);
- if (driver_algs[i].type == CRYPTO_ALG_TYPE_AEAD &&
- !memcmp(driver_algs[i].name, "authenc", 7) &&
- !done) {
- char *name;
-
- name = driver_algs[i].name;
- memmove(name + 10, name + 7, strlen(name) - 7);
- memcpy(name + 7, "esn", 3);
-
- name = driver_algs[i].driver_name;
- memmove(name + 10, name + 7, strlen(name) - 7);
- memcpy(name + 7, "esn", 3);
-
- done = true;
- goto authencesn;
- }
- }
}
if (!list_empty(&priv->alg_list))
dev_info(ctrldev, "%s algorithms registered in /proc/crypto\n",
diff --git a/drivers/crypto/caam/compat.h b/drivers/crypto/caam/compat.h
index cf15e78..762aeff 100644
--- a/drivers/crypto/caam/compat.h
+++ b/drivers/crypto/caam/compat.h
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Revert "crypto: talitos - add IPsec ESN support"
This reverts commit e763eb699be723fb41af818118068c6b3afdaf8d
(upstream: 891104ed008e8646c7860fe5bc70b0aac55dcc6c).
Current IPsec ESN implementation for authencesn(cbc(aes), hmac(sha))
(separate encryption and integrity algorithms) does not conform
to RFC4303.
ICV is generated by hashing the sequence
SPI, SeqNum-High, SeqNum-Low, IV, Payload
instead of
SPI, SeqNum-Low, IV, Payload, SeqNum-High.
Cc: # 3.8, 3.7
Reported-by: Chaoxing Lin
Signed-off-by: Horia Geanta
---
drivers/crypto/talitos.c | 30 ++
1 files changed, 2 insertions(+), 28 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 09b184a..5b2b5e6 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
#include
@@ -1974,11 +1973,7 @@ struct talitos_alg_template {
};
static struct talitos_alg_template driver_algs[] = {
- /*
-* AEAD algorithms. These use a single-pass ipsec_esp descriptor.
-* authencesn(*,*) is also registered, although not present
-* explicitly here.
-*/
+ /* AEAD algorithms. These use a single-pass ipsec_esp descriptor */
{ .type = CRYPTO_ALG_TYPE_AEAD,
.alg.crypto = {
.cra_name = "authenc(hmac(sha1),cbc(aes))",
@@ -2820,9 +2815,7 @@ static int talitos_probe(struct platform_device *ofdev)
if (hw_supports(dev, driver_algs[i].desc_hdr_template)) {
struct talitos_crypto_alg *t_alg;
char *name = NULL;
- bool authenc = false;
-authencesn:
t_alg = talitos_alg_alloc(dev, &driver_algs[i]);
if (IS_ERR(t_alg)) {
err = PTR_ERR(t_alg);
@@ -2837,8 +2830,6 @@ authencesn:
err = crypto_register_alg(
&t_alg->algt.alg.crypto);
name = t_alg->algt.alg.crypto.cra_driver_name;
- authenc = authenc ? !authenc :
- !(bool)memcmp(name, "authenc", 7);
break;
case CRYPTO_ALG_TYPE_AHASH:
err = crypto_register_ahash(
@@ -2851,25 +2842,8 @@ authencesn:
dev_err(dev, "%s alg registration failed\n",
name);
kfree(t_alg);
- } else {
+ } else
list_add_tail(&t_alg->entry, &priv->alg_list);
- if (authenc) {
- struct crypto_alg *alg =
- &driver_algs[i].alg.crypto;
-
- name = alg->cra_name;
- memmove(name + 10, name + 7,
- strlen(name) - 7);
- memcpy(name + 7, "esn", 3);
-
- name = alg->cra_driver_name;
- memmove(name + 10, name + 7,
- strlen(name) - 7);
- memcpy(name + 7, "esn", 3);
-
- goto authencesn;
- }
- }
}
}
if (!list_empty(&priv->alg_list))
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "crypto: caam - add IPsec ESN support"
On 3/20/2013 4:15 PM, Horia Geanta wrote: This reverts commit 891104ed008e8646c7860fe5bc70b0aac55dcc6c (upstream: 891104ed008e8646c7860fe5bc70b0aac55dcc6c). This line is not needed. Will resend this with commit message updated. Sorry for the noise. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 3.4-stable] rt2x00: error in configurations with mesh support disabled
On Tue, Mar 19, 2013 at 01:06:46PM +0800, Lingzhu Xiang wrote: > commit 6ef9e2f6d12ce9e2120916804d2ddd46b954a70b upstream. > > Backported for 3.4-stable. Removed code of simultaneous AP and mesh > mode added in 4a5fc6d 3.9-rc1. I'm also queuing this for the 3.5 kernel as well. Cheers, -- Luis > > From: Felix Fietkau > > If CONFIG_MAC80211_MESH is not set, cfg80211 will now allow advertising > interface combinations with NL80211_IFTYPE_MESH_POINT present. > Add appropriate ifdefs to avoid running into errors. > > Cc: stable@vger.kernel.org > Signed-off-by: Felix Fietkau > Acked-by: Gertjan van Wingerde > Signed-off-by: John W. Linville > Signed-off-by: Lingzhu Xiang > Reviewed-by: CAI Qian > > diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c > b/drivers/net/wireless/rt2x00/rt2x00dev.c > index 12b1ff5..866fd56 100644 > --- a/drivers/net/wireless/rt2x00/rt2x00dev.c > +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c > @@ -1157,7 +1157,9 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev) > rt2x00dev->hw->wiphy->interface_modes |= > BIT(NL80211_IFTYPE_ADHOC) | > BIT(NL80211_IFTYPE_AP) | > +#ifdef CONFIG_MAC80211_MESH > BIT(NL80211_IFTYPE_MESH_POINT) | > +#endif > BIT(NL80211_IFTYPE_WDS); > > /* > -- > 1.7.11.7 > > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "crypto: talitos - add IPsec ESN support"
On 3/20/2013 4:15 PM, Horia Geanta wrote: This reverts commit e763eb699be723fb41af818118068c6b3afdaf8d (upstream: 891104ed008e8646c7860fe5bc70b0aac55dcc6c). This line is not needed. Will resend this with commit message updated. Sorry for the noise. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Revert "crypto: caam - add IPsec ESN support"
This reverts commit 891104ed008e8646c7860fe5bc70b0aac55dcc6c.
Current IPsec ESN implementation for authencesn(cbc(aes), hmac(sha))
(separate encryption and integrity algorithms) does not conform
to RFC4303.
ICV is generated by hashing the sequence
SPI, SeqNum-High, SeqNum-Low, IV, Payload
instead of
SPI, SeqNum-Low, IV, Payload, SeqNum-High.
Cc: # 3.8, 3.7
Reported-by: Chaoxing Lin
Signed-off-by: Horia Geanta
---
drivers/crypto/caam/caamalg.c | 27 ++-
drivers/crypto/caam/compat.h |1 -
2 files changed, 2 insertions(+), 26 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index b2a0a07..cf268b1 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -1650,11 +1650,7 @@ struct caam_alg_template {
};
static struct caam_alg_template driver_algs[] = {
- /*
-* single-pass ipsec_esp descriptor
-* authencesn(*,*) is also registered, although not present
-* explicitly here.
-*/
+ /* single-pass ipsec_esp descriptor */
{
.name = "authenc(hmac(md5),cbc(aes))",
.driver_name = "authenc-hmac-md5-cbc-aes-caam",
@@ -2217,9 +2213,7 @@ static int __init caam_algapi_init(void)
for (i = 0; i < ARRAY_SIZE(driver_algs); i++) {
/* TODO: check if h/w supports alg */
struct caam_crypto_alg *t_alg;
- bool done = false;
-authencesn:
t_alg = caam_alg_alloc(ctrldev, &driver_algs[i]);
if (IS_ERR(t_alg)) {
err = PTR_ERR(t_alg);
@@ -2233,25 +2227,8 @@ authencesn:
dev_warn(ctrldev, "%s alg registration failed\n",
t_alg->crypto_alg.cra_driver_name);
kfree(t_alg);
- } else {
+ } else
list_add_tail(&t_alg->entry, &priv->alg_list);
- if (driver_algs[i].type == CRYPTO_ALG_TYPE_AEAD &&
- !memcmp(driver_algs[i].name, "authenc", 7) &&
- !done) {
- char *name;
-
- name = driver_algs[i].name;
- memmove(name + 10, name + 7, strlen(name) - 7);
- memcpy(name + 7, "esn", 3);
-
- name = driver_algs[i].driver_name;
- memmove(name + 10, name + 7, strlen(name) - 7);
- memcpy(name + 7, "esn", 3);
-
- done = true;
- goto authencesn;
- }
- }
}
if (!list_empty(&priv->alg_list))
dev_info(ctrldev, "%s algorithms registered in /proc/crypto\n",
diff --git a/drivers/crypto/caam/compat.h b/drivers/crypto/caam/compat.h
index cf15e78..762aeff 100644
--- a/drivers/crypto/caam/compat.h
+++ b/drivers/crypto/caam/compat.h
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Revert "crypto: talitos - add IPsec ESN support"
This reverts commit e763eb699be723fb41af818118068c6b3afdaf8d.
Current IPsec ESN implementation for authencesn(cbc(aes), hmac(sha))
(separate encryption and integrity algorithms) does not conform
to RFC4303.
ICV is generated by hashing the sequence
SPI, SeqNum-High, SeqNum-Low, IV, Payload
instead of
SPI, SeqNum-Low, IV, Payload, SeqNum-High.
Cc: # 3.8, 3.7
Reported-by: Chaoxing Lin
Signed-off-by: Horia Geanta
---
drivers/crypto/talitos.c | 30 ++
1 files changed, 2 insertions(+), 28 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 09b184a..5b2b5e6 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
#include
@@ -1974,11 +1973,7 @@ struct talitos_alg_template {
};
static struct talitos_alg_template driver_algs[] = {
- /*
-* AEAD algorithms. These use a single-pass ipsec_esp descriptor.
-* authencesn(*,*) is also registered, although not present
-* explicitly here.
-*/
+ /* AEAD algorithms. These use a single-pass ipsec_esp descriptor */
{ .type = CRYPTO_ALG_TYPE_AEAD,
.alg.crypto = {
.cra_name = "authenc(hmac(sha1),cbc(aes))",
@@ -2820,9 +2815,7 @@ static int talitos_probe(struct platform_device *ofdev)
if (hw_supports(dev, driver_algs[i].desc_hdr_template)) {
struct talitos_crypto_alg *t_alg;
char *name = NULL;
- bool authenc = false;
-authencesn:
t_alg = talitos_alg_alloc(dev, &driver_algs[i]);
if (IS_ERR(t_alg)) {
err = PTR_ERR(t_alg);
@@ -2837,8 +2830,6 @@ authencesn:
err = crypto_register_alg(
&t_alg->algt.alg.crypto);
name = t_alg->algt.alg.crypto.cra_driver_name;
- authenc = authenc ? !authenc :
- !(bool)memcmp(name, "authenc", 7);
break;
case CRYPTO_ALG_TYPE_AHASH:
err = crypto_register_ahash(
@@ -2851,25 +2842,8 @@ authencesn:
dev_err(dev, "%s alg registration failed\n",
name);
kfree(t_alg);
- } else {
+ } else
list_add_tail(&t_alg->entry, &priv->alg_list);
- if (authenc) {
- struct crypto_alg *alg =
- &driver_algs[i].alg.crypto;
-
- name = alg->cra_name;
- memmove(name + 10, name + 7,
- strlen(name) - 7);
- memcpy(name + 7, "esn", 3);
-
- name = alg->cra_driver_name;
- memmove(name + 10, name + 7,
- strlen(name) - 7);
- memcpy(name + 7, "esn", 3);
-
- goto authencesn;
- }
- }
}
}
if (!list_empty(&priv->alg_list))
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] sysfs: fix race between readdir and lseek
While readdir() is running, lseek() may set filp->f_pos as zero,
then may leave filp->private_data pointing to one sysfs_dirent
object without holding its reference counter, so the sysfs_dirent
object may be used after free in next readdir().
This patch holds inode->i_mutex to avoid the problem since
the lock is always held in readdir path.
Reported-by: Dave Jones
Tested-by: Sasha Levin
Cc:
Signed-off-by: Ming Lei
---
fs/sysfs/dir.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 2fbdff6..c9e1660 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -1058,10 +1058,21 @@ static int sysfs_readdir(struct file * filp, void *
dirent, filldir_t filldir)
return 0;
}
+static loff_t sysfs_dir_llseek(struct file *file, loff_t offset, int whence)
+{
+ struct inode *inode = file_inode(file);
+ loff_t ret;
+
+ mutex_lock(&inode->i_mutex);
+ ret = generic_file_llseek(file, offset, whence);
+ mutex_unlock(&inode->i_mutex);
+
+ return ret;
+}
const struct file_operations sysfs_dir_operations = {
.read = generic_read_dir,
.readdir= sysfs_readdir,
.release= sysfs_dir_release,
- .llseek = generic_file_llseek,
+ .llseek = sysfs_dir_llseek,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] sysfs: handle failure path correctly for readdir()
In case of 'if (filp->f_pos == 0 or 1)' of sysfs_readdir(),
the failure from filldir() isn't handled, and the reference counter
of the sysfs_dirent object pointed by filp->private_data will be
released without clearing filp->private_data, so use after free
bug will be triggered later.
This patch returns immeadiately under the situation for fixing the bug,
and it is reasonable to return from readdir() when filldir() fails.
Reported-by: Dave Jones
Tested-by: Sasha Levin
Cc:
Signed-off-by: Ming Lei
---
fs/sysfs/dir.c |4
1 file changed, 4 insertions(+)
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index c9e1660..e145126 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -1020,6 +1020,8 @@ static int sysfs_readdir(struct file * filp, void *
dirent, filldir_t filldir)
ino = parent_sd->s_ino;
if (filldir(dirent, ".", 1, filp->f_pos, ino, DT_DIR) == 0)
filp->f_pos++;
+ else
+ return 0;
}
if (filp->f_pos == 1) {
if (parent_sd->s_parent)
@@ -1028,6 +1030,8 @@ static int sysfs_readdir(struct file * filp, void *
dirent, filldir_t filldir)
ino = parent_sd->s_ino;
if (filldir(dirent, "..", 2, filp->f_pos, ino, DT_DIR) == 0)
filp->f_pos++;
+ else
+ return 0;
}
mutex_lock(&sysfs_mutex);
for (pos = sysfs_dir_pos(ns, parent_sd, filp->f_pos, pos);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] powerpc/uprobes: teach uprobes to ignore gdb breakpoints
On Wed, Mar 20, 2013 at 01:26:39PM +0100, Oleg Nesterov wrote:
> Hi Ananth,
>
> First of all, let me remind that I know nothing about powerpc ;)
>
> But iirc we already discussed this a bit, I forgot the details but
> still I have some concerns...
>
> On 03/20, Ananth N Mavinakayanahalli wrote:
> >
> > GDB uses a variant of the trap instruction that is different from the
> > one used by uprobes. Currently, running gdb on a program being traced
> > by uprobes causes an endless loop since uprobes doesn't understand
> > that the trap is inserted by some other entity and hence a SIGTRAP needs
> > to be delivered.
>
> Yes, and thus is_swbp_at_addr()->is_swbp_insn() called by handle_swbp()
> should be updated,
>
> > +bool is_swbp_insn(uprobe_opcode_t *insn)
> > +{
> > + return (is_trap(*insn));
> > +}
>
> And this patch should fix the problem. (and probably this is fine
> for prepare_uprobe()).
Correct
> But, at the same time, is the new definition fine for verify_opcode()?
>
> IOW, powerpc has another is_trap() insn(s) used by gdb, lets denote it X.
> X != UPROBE_SWBP_INSN.
>
> Suppose that gdb installs the trap X at some addr, and then uprobe_register()
> tries to install uprobe at the same address. Then set_swbp() will do nothing,
> assuming the uprobe was already installed.
>
> But we did not install UPROBE_SWBP_INSN. Is it fine? I hope yes, just to
> verify. If not, we need 2 definitions. is_uprobe_insn() should still check
> insns == UPROBE_SWBP_INSN, and is_swbp_insn() should check is_trap().
is_trap() checks for all trap variants on powerpc, including the one
uprobe uses. It returns true if the instruction is *any* trap variant.
So, install_breakpoint()->prepare_uprobe()->is_swbp_insn() will return
ENOTSUPP. In fact, arch_uprobe_analyze_insn() will also do the same.
This itself should take care of all the cases.
> And I am just curious, could you explain how X and UPROBE_SWBP_INSN
> differ?
Powerpc has numerous variants of the trap instruction based on
comparison of two registers or a regsiter and immediate value and a condition
(less than, greater than, [signed forms thereof], or equal to).
Uprobes uses 0x7fe0008 which is 'tw 31,0,0' which essentially is an
unconditional trap.
Gdb uses many traps, one of which is 0x7d821008 which is twge r2,r2,
which is basically trap if r2 greater than or equal to r2.
Ananth
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] powerpc/uprobes: teach uprobes to ignore gdb breakpoints
On Wed, Mar 20, 2013 at 01:43:01PM +0100, Oleg Nesterov wrote: > On 03/20, Oleg Nesterov wrote: > > > > But we did not install UPROBE_SWBP_INSN. Is it fine? I hope yes, just to > > verify. If not, we need 2 definitions. is_uprobe_insn() should still check > > insns == UPROBE_SWBP_INSN, and is_swbp_insn() should check is_trap(). > > > > And I am just curious, could you explain how X and UPROBE_SWBP_INSN > > differ? > > IOW, if I wasn't clear... Lets forget about gdb/etc for the moment. > Suppose we apply the patch below. Will uprobes on powerpc work? > > If yes, then your patch should be fine. If not, we probably need more > changes. Yes, it will work fine. > And, forgot to mention. If you change is_swbp_insn(), you can remove > is_trap() from arch_uprobe_analyze_insn(). Yeah, that check is no longer needed. I'll send a separate cleanup after this patch gets applied. Ananth -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH stable 3.4.y, 3.8.y] tg3: 5715 does not link up when autoneg off
From: Nithin Sujir
Hi Greg,
Resubmitting this patch for the stable 3.4.y and 3.8.y trees.
It is now in Linus's tree.
Upstream commit id: 7c6cdead7cc9a99650d15497aae47d7472217eb1
The upstream patch has been modified to compile on 3.4 and 3.8.
Specifically tg3_asic_rev() has been changed to GET_ASIC_REV().
=
Commit d13ba512cbba7de5d55d7a3b2aae7d83c8921457 ("tg3: Remove
SPEED_UNKNOWN checks") cleaned up the autoneg advertisement by
removing some dead code. One effect of this change was that the
advertisement register would not be updated if autoneg is turned off.
This exposed a bug on the 5715 device w.r.t linking. The 5715 defaults
to advertise only 10Mb Full duplex. But with autoneg disabled, it needs
the configured speed enabled in the advertisement register to link up.
This patch adds the work around to advertise all speeds on the 5715 when
autoneg is disabled.
Reported-by: Marcin Miotk
Reviewed-by: Benjamin Li
Signed-off-by: Nithin Nayak Sujir
Signed-off-by: Michael Chan
Signed-off-by: David S. Miller
---
drivers/net/ethernet/broadcom/tg3.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/tg3.c
b/drivers/net/ethernet/broadcom/tg3.c
index bdb0869..054e5ee 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -4097,6 +4097,14 @@ static void tg3_phy_copper_begin(struct tg3 *tp)
tp->link_config.active_speed = tp->link_config.speed;
tp->link_config.active_duplex = tp->link_config.duplex;
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5714) {
+ /* With autoneg disabled, 5715 only links up when the
+* advertisement register has the configured speed
+* enabled.
+*/
+ tg3_writephy(tp, MII_ADVERTISE, ADVERTISE_ALL);
+ }
+
bmcr = 0;
switch (tp->link_config.speed) {
default:
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] powerpc/uprobes: teach uprobes to ignore gdb breakpoints
On 03/20, Ananth N Mavinakayanahalli wrote:
>
> On Wed, Mar 20, 2013 at 01:26:39PM +0100, Oleg Nesterov wrote:
> > But, at the same time, is the new definition fine for verify_opcode()?
> >
> > IOW, powerpc has another is_trap() insn(s) used by gdb, lets denote it X.
> > X != UPROBE_SWBP_INSN.
> >
> > Suppose that gdb installs the trap X at some addr, and then
> > uprobe_register()
> > tries to install uprobe at the same address. Then set_swbp() will do
> > nothing,
> > assuming the uprobe was already installed.
> >
> > But we did not install UPROBE_SWBP_INSN. Is it fine? I hope yes, just to
> > verify. If not, we need 2 definitions. is_uprobe_insn() should still check
> > insns == UPROBE_SWBP_INSN, and is_swbp_insn() should check is_trap().
>
> is_trap() checks for all trap variants on powerpc, including the one
> uprobe uses. It returns true if the instruction is *any* trap variant.
I understand,
> So, install_breakpoint()->prepare_uprobe()->is_swbp_insn() will return
> ENOTSUPP. In fact, arch_uprobe_analyze_insn() will also do the same.
Yes and the check in arch_uprobe_analyze_insn() should go away.
But you missed my point. Please forget about prepare_uprobe(), it is
wrong anyway. And, prepare_uprobe() inspects the _original_ insn from
the file, this has nothing install_breakpoint/etc.
I meant verify_opcode() called by install_breakpoint/etc.
> This itself should take care of all the cases.
>
> > And I am just curious, could you explain how X and UPROBE_SWBP_INSN
> > differ?
>
> Powerpc has numerous variants of the trap instruction based on
> comparison of two registers or a regsiter and immediate value and a condition
> (less than, greater than, [signed forms thereof], or equal to).
>
> Uprobes uses 0x7fe0008 which is 'tw 31,0,0' which essentially is an
> unconditional trap.
>
> Gdb uses many traps, one of which is 0x7d821008 which is twge r2,r2,
> which is basically trap if r2 greater than or equal to r2.
OK. So, if I understand correctly, gdb can use some conditional
breakpoint, and it is possible that this insn won't generate the
trap?
Then this patch is not right, or at least we need another change
on top?
Once again. Suppose that gdb installs the TRAP_IF_R1_GT_R2.
After that uprobe_register() is called, but it won't change this
insn because verify_opcode() returns 0.
Then the probed task hits this breakoint with "r1 < r2" and we do
not report this event.
So. I still think that we actually need something like below, and
powerpc should reimplement is_trap_insn() to use is_trap(insn).
No?
Oleg.
--- x/kernel/events/uprobes.c
+++ x/kernel/events/uprobes.c
@@ -532,6 +532,12 @@ static int copy_insn(struct uprobe *upro
return __copy_insn(mapping, filp, uprobe->arch.insn, bytes,
uprobe->offset);
}
+bool __weak is_trap_insn(uprobe_opcode_t *insn)
+{
+ // powerpc: should use is_trap()
+ return is_swbp_insn(insn);
+}
+
static int prepare_uprobe(struct uprobe *uprobe, struct file *file,
struct mm_struct *mm, unsigned long vaddr)
{
@@ -550,7 +556,7 @@ static int prepare_uprobe(struct uprobe
goto out;
ret = -ENOTSUPP;
- if (is_swbp_insn((uprobe_opcode_t *)uprobe->arch.insn))
+ if (is_trap_insn((uprobe_opcode_t *)uprobe->arch.insn))
goto out;
ret = arch_uprobe_analyze_insn(&uprobe->arch, mm, vaddr);
@@ -1452,7 +1458,7 @@ static int is_swbp_at_addr(struct mm_str
copy_opcode(page, vaddr, &opcode);
put_page(page);
out:
- return is_swbp_insn(&opcode);
+ return is_trap_insn(&opcode);
}
static struct uprobe *find_active_uprobe(unsigned long bp_vaddr, int *is_swbp)
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] powerpc/uprobes: teach uprobes to ignore gdb breakpoints
On 03/20, Ananth N Mavinakayanahalli wrote: > > On Wed, Mar 20, 2013 at 01:43:01PM +0100, Oleg Nesterov wrote: > > On 03/20, Oleg Nesterov wrote: > > > > > > But we did not install UPROBE_SWBP_INSN. Is it fine? I hope yes, just to > > > verify. If not, we need 2 definitions. is_uprobe_insn() should still check > > > insns == UPROBE_SWBP_INSN, and is_swbp_insn() should check is_trap(). > > > > > > And I am just curious, could you explain how X and UPROBE_SWBP_INSN > > > differ? > > > > IOW, if I wasn't clear... Lets forget about gdb/etc for the moment. > > Suppose we apply the patch below. Will uprobes on powerpc work? > > > > If yes, then your patch should be fine. If not, we probably need more > > changes. > > Yes, it will work fine. Even if this new insn is conditional? Oleg. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel panic on stable kernel 3.8.2 when closing bluetooth dun connection
On Wed, Mar 20, 2013 at 11:18:38AM +0100, Sergio Callegari wrote: > Hi, > > This is just a short note to let you know that 3.8.2 panics on > closing a bluetooth dun connection. Have you notified the linux bluetooth developers about this? Is this new in 3.8.2 and 3.8.1 or 3.8 works fine? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] sysfs: handle failure path correctly for readdir()
On Wed, Mar 20, 2013 at 9:25 AM, Ming Lei wrote:
> In case of 'if (filp->f_pos == 0 or 1)' of sysfs_readdir(),
> the failure from filldir() isn't handled, and the reference counter
> of the sysfs_dirent object pointed by filp->private_data will be
> released without clearing filp->private_data, so use after free
> bug will be triggered later.
>
> This patch returns immeadiately under the situation for fixing the bug,
> and it is reasonable to return from readdir() when filldir() fails.
>
> Reported-by: Dave Jones
> Tested-by: Sasha Levin
> Cc:
> Signed-off-by: Ming Lei
> ---
> fs/sysfs/dir.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
> index c9e1660..e145126 100644
> --- a/fs/sysfs/dir.c
> +++ b/fs/sysfs/dir.c
> @@ -1020,6 +1020,8 @@ static int sysfs_readdir(struct file * filp, void *
> dirent, filldir_t filldir)
> ino = parent_sd->s_ino;
> if (filldir(dirent, ".", 1, filp->f_pos, ino, DT_DIR) == 0)
> filp->f_pos++;
> + else
> + return 0;
> }
> if (filp->f_pos == 1) {
> if (parent_sd->s_parent)
> @@ -1028,6 +1030,8 @@ static int sysfs_readdir(struct file * filp, void *
> dirent, filldir_t filldir)
> ino = parent_sd->s_ino;
> if (filldir(dirent, "..", 2, filp->f_pos, ino, DT_DIR) == 0)
> filp->f_pos++;
> + else
> + return 0;
> }
Looks good to me. This is just an observation. readdir callers are
checking against NULL as opposed 0. Not a problem really probably
since NULL is defined as 0.
-- Shuah
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: mwifiex: fix potential out-of-boundary access to ibss rate table
commit: 5f0fabf84d7b52f979dcbafa3d3c530c60d9a92c From: Bing Zhao Date: Thu, 7 Mar 2013 20:00:16 -0800 Subject: mwifiex: fix potential out-of-boundary access to ibss rate table smatch found this error: CHECK drivers/net/wireless/mwifiex/join.c drivers/net/wireless/mwifiex/join.c:1121 mwifiex_cmd_802_11_ad_hoc_join() error: testing array offset 'i' after use. Cc: # 3.0+ Signed-off-by: Bing Zhao Signed-off-by: John W. Linville --- drivers/net/wireless/mwifiex/join.c |7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/mwifiex/join.c b/drivers/net/wireless/mwifiex/join.c index 246aa62..2fe0ceb 100644 --- a/drivers/net/wireless/mwifiex/join.c +++ b/drivers/net/wireless/mwifiex/join.c @@ -1117,10 +1117,9 @@ mwifiex_cmd_802_11_ad_hoc_join(struct mwifiex_private *priv, adhoc_join->bss_descriptor.bssid, adhoc_join->bss_descriptor.ssid); - for (i = 0; bss_desc->supported_rates[i] && - i < MWIFIEX_SUPPORTED_RATES; - i++) - ; + for (i = 0; i < MWIFIEX_SUPPORTED_RATES && + bss_desc->supported_rates[i]; i++) + ; rates_size = i; /* Copy Data Rates from the Rates recorded in scan response */ -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: vhost/net: fix heads usage of ubuf_info
commit: 46aa92d1ba162b4b3d6b7102440e459d4e4ee255
From: "Michael S. Tsirkin"
Date: Sun, 17 Mar 2013 02:46:09 +
Subject: vhost/net: fix heads usage of ubuf_info
ubuf info allocator uses guest controlled head as an index,
so a malicious guest could put the same head entry in the ring twice,
and we will get two callbacks on the same value.
To fix use upend_idx which is guaranteed to be unique.
Reported-by: Rusty Russell
Signed-off-by: Michael S. Tsirkin
Cc: sta...@kernel.org
Signed-off-by: David S. Miller
---
drivers/vhost/net.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 959b1cd..ec6fb3f 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -339,7 +339,8 @@ static void handle_tx(struct vhost_net *net)
msg.msg_controllen = 0;
ubufs = NULL;
} else {
- struct ubuf_info *ubuf = &vq->ubuf_info[head];
+ struct ubuf_info *ubuf;
+ ubuf = vq->ubuf_info + vq->upend_idx;
vq->heads[vq->upend_idx].len =
VHOST_DMA_IN_PROGRESS;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: rtlwifi: rtl8192cu: Fix schedule while atomic bug splat
commit: 664899786cb49cb52f620e06ac19c0be524a7cfa From: Larry Finger Date: Wed, 27 Feb 2013 14:10:30 -0600 Subject: rtlwifi: rtl8192cu: Fix schedule while atomic bug splat When run at debug 3 or higher, rtl8192cu reports a BUG as follows: BUG: scheduling while atomic: kworker/u:0/5281/0x0002 INFO: lockdep is turned off. Modules linked in: rtl8192cu rtl8192c_common rtlwifi fuse af_packet bnep bluetooth b43 mac80211 cfg80211 ipv6 snd_hda_codec_conexant kvm_amd k vm snd_hda_intel snd_hda_codec bcma rng_core snd_pcm ssb mmc_core snd_seq snd_timer snd_seq_device snd i2c_nforce2 sr_mod pcmcia forcedeth i2c_core soundcore cdrom sg serio_raw k8temp hwmon joydev ac battery pcmcia_core snd_page_alloc video button wmi autofs4 ext4 mbcache jbd2 crc16 thermal processor scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_acpi pata_amd [last unloaded: rtlwifi] Pid: 5281, comm: kworker/u:0 Tainted: GW3.8.0-wl+ #119 Call Trace: [] __schedule_bug+0x62/0x70 [] __schedule+0x730/0xa30 [] ? usb_hcd_link_urb_to_ep+0x19/0xa0 [] schedule+0x24/0x70 [] schedule_timeout+0x18c/0x2f0 [] ? wait_for_common+0x40/0x180 [] ? ehci_urb_enqueue+0xf1/0xee0 [] ? trace_hardirqs_on+0xd/0x10 [] wait_for_common+0xe5/0x180 [] ? try_to_wake_up+0x2d0/0x2d0 [] wait_for_completion_timeout+0xe/0x10 [] usb_start_wait_urb+0x8c/0x100 [] usb_control_msg+0xd9/0x130 [] _usb_read_sync+0xcd/0x140 [rtlwifi] [] _usb_read32_sync+0xe/0x10 [rtlwifi] [] rtl92cu_update_hal_rate_table+0x1a5/0x1f0 [rtl8192cu] The cause is a synchronous read from routine rtl92cu_update_hal_rate_table(). The resulting output is not critical, thus the debug statement is deleted. Reported-by: Jussi Kivilinna Signed-off-by: Larry Finger Cc: Stable Signed-off-by: John W. Linville --- drivers/net/wireless/rtlwifi/rtl8192cu/hw.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c index b1ccff4..3c6e18c 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c @@ -2058,8 +2058,6 @@ void rtl92cu_update_hal_rate_table(struct ieee80211_hw *hw, (shortgi_rate << 4) | (shortgi_rate); } rtl_write_dword(rtlpriv, REG_ARFR0 + ratr_index * 4, ratr_value); - RT_TRACE(rtlpriv, COMP_RATR, DBG_DMESG, "%x\n", -rtl_read_dword(rtlpriv, REG_ARFR0)); } void rtl92cu_update_hal_rate_mask(struct ieee80211_hw *hw, u8 rssi_level) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: workqueue: fix possible pool stall bug in wq_unbind_fn()
commit: eb2834285cf172856cd12f66892fc7467935ebed From: Lai Jiangshan Date: Fri, 8 Mar 2013 15:18:28 -0800 Subject: workqueue: fix possible pool stall bug in wq_unbind_fn() Since multiple pools per cpu have been introduced, wq_unbind_fn() has a subtle bug which may theoretically stall work item processing. The problem is two-fold. * wq_unbind_fn() depends on the worker executing wq_unbind_fn() itself to start unbound chain execution, which works fine when there was only single pool. With multiple pools, only the pool which is running wq_unbind_fn() - the highpri one - is guaranteed to have such kick-off. The other pool could stall when its busy workers block. * The current code is setting WORKER_UNBIND / POOL_DISASSOCIATED of the two pools in succession without initiating work execution inbetween. Because setting the flags requires grabbing assoc_mutex which is held while new workers are created, this could lead to stalls if a pool's manager is waiting for the previous pool's work items to release memory. This is almost purely theoretical tho. Update wq_unbind_fn() such that it sets WORKER_UNBIND / POOL_DISASSOCIATED, goes over schedule() and explicitly kicks off execution for a pool and then moves on to the next one. tj: Updated comments and description. Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo Cc: stable@vger.kernel.org --- kernel/workqueue.c | 44 +--- 1 file changed, 25 insertions(+), 19 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 81f2457..604801b 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -3446,28 +3446,34 @@ static void wq_unbind_fn(struct work_struct *work) spin_unlock_irq(&pool->lock); mutex_unlock(&pool->assoc_mutex); - } - /* -* Call schedule() so that we cross rq->lock and thus can guarantee -* sched callbacks see the %WORKER_UNBOUND flag. This is necessary -* as scheduler callbacks may be invoked from other cpus. -*/ - schedule(); + /* +* Call schedule() so that we cross rq->lock and thus can +* guarantee sched callbacks see the %WORKER_UNBOUND flag. +* This is necessary as scheduler callbacks may be invoked +* from other cpus. +*/ + schedule(); - /* -* Sched callbacks are disabled now. Zap nr_running. After this, -* nr_running stays zero and need_more_worker() and keep_working() -* are always true as long as the worklist is not empty. Pools on -* @cpu now behave as unbound (in terms of concurrency management) -* pools which are served by workers tied to the CPU. -* -* On return from this function, the current worker would trigger -* unbound chain execution of pending work items if other workers -* didn't already. -*/ - for_each_std_worker_pool(pool, cpu) + /* +* Sched callbacks are disabled now. Zap nr_running. +* After this, nr_running stays zero and need_more_worker() +* and keep_working() are always true as long as the +* worklist is not empty. This pool now behaves as an +* unbound (in terms of concurrency management) pool which +* are served by workers tied to the pool. +*/ atomic_set(&pool->nr_running, 0); + + /* +* With concurrency management just turned off, a busy +* worker blocking could lead to lengthy stalls. Kick off +* unbound chain execution of currently pending work items. +*/ + spin_lock_irq(&pool->lock); + wake_up_worker(pool); + spin_unlock_irq(&pool->lock); + } } /* -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: rtlwifi: rtl8192cu: Fix problem that prevents reassociation
commit: 9437a248e7cac427c898bdb11bd1ac6844a1ead4
From: Larry Finger
Date: Wed, 13 Mar 2013 10:28:13 -0500
Subject: rtlwifi: rtl8192cu: Fix problem that prevents reassociation
The driver was failing to clear the BSSID when a disconnect happened. That
prevented a reconnection. This problem is reported at
https://bugzilla.redhat.com/show_bug.cgi?id=789605,
https://bugzilla.redhat.com/show_bug.cgi?id=866786,
https://bugzilla.redhat.com/show_bug.cgi?id=906734, and
https://bugzilla.kernel.org/show_bug.cgi?id=46171.
Thanks to Jussi Kivilinna for making the critical observation
that led to the solution.
Reported-by: Jussi Kivilinna
Tested-by: Jussi Kivilinna
Tested-by: Alessandro Lannocca
Signed-off-by: Larry Finger
Cc: Stable
Signed-off-by: John W. Linville
---
drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 87 +++
1 file changed, 35 insertions(+), 52 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
index 3c6e18c..c08d0f4 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
@@ -1377,74 +1377,57 @@ void rtl92cu_card_disable(struct ieee80211_hw *hw)
void rtl92cu_set_check_bssid(struct ieee80211_hw *hw, bool check_bssid)
{
- /* dummy routine needed for callback from rtl_op_configure_filter() */
-}
-
-/*== */
-
-static void _rtl92cu_set_check_bssid(struct ieee80211_hw *hw,
- enum nl80211_iftype type)
-{
struct rtl_priv *rtlpriv = rtl_priv(hw);
- u32 reg_rcr = rtl_read_dword(rtlpriv, REG_RCR);
struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
- struct rtl_phy *rtlphy = &(rtlpriv->phy);
- u8 filterout_non_associated_bssid = false;
+ u32 reg_rcr = rtl_read_dword(rtlpriv, REG_RCR);
- switch (type) {
- case NL80211_IFTYPE_ADHOC:
- case NL80211_IFTYPE_STATION:
- filterout_non_associated_bssid = true;
- break;
- case NL80211_IFTYPE_UNSPECIFIED:
- case NL80211_IFTYPE_AP:
- default:
- break;
- }
- if (filterout_non_associated_bssid) {
+ if (rtlpriv->psc.rfpwr_state != ERFON)
+ return;
+
+ if (check_bssid) {
+ u8 tmp;
if (IS_NORMAL_CHIP(rtlhal->version)) {
- switch (rtlphy->current_io_type) {
- case IO_CMD_RESUME_DM_BY_SCAN:
- reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
- rtlpriv->cfg->ops->set_hw_reg(hw,
-HW_VAR_RCR, (u8 *)(®_rcr));
- /* enable update TSF */
- _rtl92cu_set_bcn_ctrl_reg(hw, 0, BIT(4));
- break;
- case IO_CMD_PAUSE_DM_BY_SCAN:
- reg_rcr &= ~(RCR_CBSSID_DATA | RCR_CBSSID_BCN);
- rtlpriv->cfg->ops->set_hw_reg(hw,
-HW_VAR_RCR, (u8 *)(®_rcr));
- /* disable update TSF */
- _rtl92cu_set_bcn_ctrl_reg(hw, BIT(4), 0);
- break;
- }
+ reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
+ tmp = BIT(4);
} else {
- reg_rcr |= (RCR_CBSSID);
- rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
- (u8 *)(®_rcr));
- _rtl92cu_set_bcn_ctrl_reg(hw, 0, (BIT(4)|BIT(5)));
+ reg_rcr |= RCR_CBSSID;
+ tmp = BIT(4) | BIT(5);
}
- } else if (filterout_non_associated_bssid == false) {
+ rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
+ (u8 *) (®_rcr));
+ _rtl92cu_set_bcn_ctrl_reg(hw, 0, tmp);
+ } else {
+ u8 tmp;
if (IS_NORMAL_CHIP(rtlhal->version)) {
- reg_rcr &= (~(RCR_CBSSID_DATA | RCR_CBSSID_BCN));
- rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
- (u8 *)(®_rcr));
- _rtl92cu_set_bcn_ctrl_reg(hw, BIT(4), 0);
+ reg_rcr &= ~(RCR_CBSSID_DATA | RCR_CBSSID_BCN);
+ tmp = BIT(4);
} else {
- reg_rcr &= (~RCR_CBSSID);
- rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
- (u8 *)(®_rcr));
- _rtl92cu_set_bcn_ctrl_reg(hw, (BIT(4)|BIT(5)), 0);
+ reg_rcr &= ~RCR_CBSSID;
+ t
[PATCH] drm/i915: Fix pipe enabled mask for pipe C in WM calculations
From: Ville Syrjälä
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8a3d89e..89a2d6f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1943,7 +1943,7 @@ static void ivybridge_update_wm(struct drm_device *dev)
DRM_DEBUG_KMS("FIFO watermarks For pipe C -"
" plane %d, cursor: %d\n",
plane_wm, cursor_wm);
- enabled |= 3;
+ enabled |= 4;
}
/*
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linux 3.2.41
I'm announcing the release of the 3.2.41 kernel. All users of the 3.2 kernel series should upgrade. The updated 3.2.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.2.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git Ben. .../devicetree/bindings/tty/serial/of-serial.txt |3 + Makefile |2 +- arch/arm/kernel/perf_event_v7.c|2 +- arch/arm/mm/alignment.c| 11 +- arch/arm/vfp/vfpmodule.c |2 +- arch/powerpc/include/asm/eeh.h |3 - arch/powerpc/kernel/of_platform.c |3 - arch/powerpc/kernel/pci-common.c |7 +- arch/powerpc/platforms/pseries/eeh.c | 24 +- arch/x86/pci/xen.c |9 + crypto/ablkcipher.c| 12 +- crypto/aead.c |9 +- crypto/ahash.c |2 +- crypto/blkcipher.c |6 +- crypto/crypto_user.c | 22 +- crypto/pcompress.c |3 +- crypto/rng.c |2 +- crypto/shash.c |3 +- drivers/ata/ahci.c | 40 +++ drivers/block/loop.c | 24 +- drivers/char/hw_random/core.c | 19 +- drivers/char/hw_random/virtio-rng.c| 13 +- drivers/connector/cn_proc.c|8 + drivers/cpufreq/cpufreq_stats.c|1 + drivers/firmware/dmi_scan.c|5 +- drivers/firmware/efivars.c | 136 ++-- drivers/gpu/drm/i915/intel_display.c | 11 +- drivers/gpu/drm/radeon/radeon_combios.c|9 + drivers/hid/hid-core.c |1 + drivers/hid/hid-ids.h |1 + drivers/hid/hid-sony.c | 18 +- drivers/hv/hv_kvp.c| 10 +- drivers/hwmon/lineage-pem.c|2 + drivers/hwmon/pmbus/ltc2978.c | 40 +-- drivers/hwmon/sht15.c |8 +- drivers/iommu/amd_iommu_init.c | 10 +- drivers/md/dm-crypt.c | 39 +-- drivers/md/dm-delay.c |8 +- drivers/md/dm-flakey.c |7 +- drivers/md/dm-ioctl.c | 14 +- drivers/md/dm-linear.c |7 +- drivers/md/dm-mpath.c |8 +- drivers/md/dm-raid.c |8 +- drivers/md/dm-raid1.c |8 +- drivers/md/dm-snap.c | 18 +- drivers/md/dm-stripe.c |7 +- drivers/md/dm-thin.c | 78 +++-- drivers/md/md.c|7 + drivers/md/raid0.c |5 +- drivers/net/ethernet/intel/e1000e/netdev.c |2 +- drivers/net/wireless/ath/ath9k/common.h|2 +- drivers/net/wireless/ath/ath9k/htc.h |1 + drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 18 +- drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h |9 + drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c | 72 - drivers/net/wireless/mwifiex/pcie.c|2 +- drivers/net/xen-netfront.c |4 +- drivers/scsi/dc395x.c |2 +- drivers/staging/hv/storvsc_drv.c |1 + drivers/staging/vt6656/main_usb.c |4 - drivers/tty/serial/8250.c | 21 ++ drivers/tty/serial/8250_pci.c | 21 +- drivers/tty/serial/Kconfig |2 +- drivers/tty/serial/of_serial.c |6 + drivers/tty/tty_buffer.c | 11 +- drivers/usb/class/cdc-wdm.c| 23 +- drivers/usb/core/hub.c | 178 ++- drivers/usb/serial/cp210x.c| 20 ++ drivers/usb/serial/option.c|5 + drivers/usb/serial/qcaux.c |1 + drivers/usb/storage/initializers.c | 76 + drivers/usb/storage/initializers.h |4 +- drivers/usb/storage/unusual_devs.h | 329 +++- drivers/w1/w1.c|
Re: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers
On Tue, Mar 19, 2013 at 10:44:30PM +0100, Sven Joachim wrote: > On 2013-03-19 22:00 +0100, Alan Stern wrote: > > > On Tue, 19 Mar 2013, Sven Joachim wrote: > > > >> On 2013-03-19 21:10 +0100, Alan Stern wrote: > >> > >> > On Tue, 19 Mar 2013, Sven Joachim wrote: > >> > > >> >> > In what way is resume broken? > >> >> > >> >> The kernel comes back, but the screen is black. Manually switching VT's > >> >> is possible, and if I type something I can see it on the screen, but > >> >> there is no response and the cursor does not blink. It looks as if the > >> >> VT is not switched backed on resume, and userspace tasks are not > >> >> restarted. Sysrq combinations apparently work, but produce no output. > >> > > >> > Are there any other problems? For example, even before you do a > >> > suspend, if you type Alt-SysRq-W do you see any processes listed? > >> > >> No. > >> > >> > There was another report on the linux-usb mailing list today of this > >> > same patch causing the khubd task to hang. I'm thinking that you might > >> > be facing a similar problem. > >> > >> Maybe, but before the suspend everything seems to be normal. > > > > Just out of curiosity, does the patch posted here: > > > > http://marc.info/?l=linux-usb&m=136361874807411&w=2 > > > > make any difference? > > It fixes the problem for me, thanks. :-) Ok, I'll postpone this patch for the next stable release, in time for the fix to be put in at the same time. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Linux 3.0.70
I'm announcing the release of the 3.0.70 kernel. All users of the 3.0 kernel series must upgrade. The updated 3.0.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.0.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/powerpc/kernel/cputable.c|2 arch/s390/include/asm/tlbflush.h |2 arch/x86/kernel/cpu/perf_event_intel_ds.c | 10 arch/x86/power/cpu.c |2 drivers/block/loop.c |2 drivers/char/hw_random/virtio-rng.c | 13 + drivers/gpu/drm/i915/i915_gem.c |5 drivers/hwmon/lineage-pem.c |2 drivers/hwmon/sht15.c |2 drivers/md/md.c |4 drivers/net/tun.c |2 drivers/staging/vt6656/main_usb.c |4 drivers/tty/pty.c |1 drivers/tty/serial/Kconfig|2 drivers/usb/class/cdc-wdm.c | 23 +- drivers/usb/host/ehci-q.c | 18 + drivers/usb/serial/cp210x.c | 20 + drivers/usb/serial/option.c |5 drivers/usb/serial/qcaux.c|1 drivers/usb/storage/initializers.c| 76 -- drivers/usb/storage/initializers.h|4 drivers/usb/storage/unusual_devs.h| 329 +- drivers/w1/w1.c |3 fs/block_dev.c|4 fs/btrfs/volumes.c|6 fs/ext3/super.c |4 include/linux/perf_event.h|6 kernel/signal.c |3 net/core/dev.c|1 net/core/rtnetlink.c |1 net/dcb/dcbnl.c |7 net/ipv4/tcp_input.c |6 net/ipv6/ip6_input.c |3 net/ipv6/route.c |3 net/l2tp/l2tp_ppp.c |1 net/netlabel/netlabel_unlabeled.c | 27 +- net/rds/message.c |3 security/selinux/xfrm.c |2 sound/core/seq/seq_timer.c|8 tools/perf/util/trace-event-parse.c |2 41 files changed, 488 insertions(+), 133 deletions(-) Alan Stern (1): USB: EHCI: don't check DMA values in QH overlays Amit Shah (1): virtio: rng: disallow multiple device registrations, fixes crashes Axel Lin (1): hwmon: (lineage-pem) Add missing terminating entry for pem_[input|fan]_attributes Ben Hutchings (1): hwmon: (sht15) Fix memory leak if regulator_enable() fails Benjamin Herrenschmidt (1): powerpc: Fix cputable entry for 970MP rev 1.0 Bjørn Mork (2): USB: option: add Huawei E5331 USB: storage: fix Huawei mode switching regression Christian Schmiedl (1): USB: added support for Cinterion's products AH6 and PLS8 Cong Wang (1): rds: limit the size allocated by rds_message_alloc() Cristian Bercaru (1): bridging: fix rx_handlers return code Dan Carpenter (1): selinux: use GFP_ATOMIC under spin_lock Dan Williams (1): qcaux: add Franklin U600 David Rientjes (1): perf,x86: fix link failure for non-Intel configs Dmitry Rogozhkin (1): drm/i915: EBUSY status handling added to i915_gem_fault(). Eric Dumazet (1): tun: add a missing nf_reset() in tun_net_xmit() Eric Sandeen (1): btrfs: use rcu_barrier() to wait for bdev puts at unmount Greg Kroah-Hartman (2): Revert duplicated perf commit. Linux 3.0.70 Guillaume Nault (1): l2tp: Restore socket refcount when sendmsg succeeds Guo Chao (2): block: use i_size_write() in bd_set_size() loopdev: fix a deadlock Hannes Frederic Sowa (1): ipv6: stop multicast forwarding to process interface scoped addresses Heiko Carstens (1): s390/mm: fix flush_tlb_kernel_range() Jiri Slaby (1): TTY: do not reset master's packet mode Kees Cook (1): signal: always clear sa_restorer on execve Lars-Peter Clausen (1): ext3: Fix format string issues Linus Torvalds (1): perf,x86: fix wrmsr_on_cpu() warning on suspend/resume Lorenzo Colitti (1): net: ipv6: Don't purge default router if accept_ra=2 Malcolm Priestley (1): staging: vt6656: Fix oops on resume from suspend. Marcin Jurkowski (1): w1: fix oops when w1_search is called from netlink connector Mathias Krause (2): rtnl: fix info leak on RTM_GETLINK request for VF devices dcbnl: fix various netlink info leaks Matwey V. Kornilov (1): usb: cp210x new Vendor/Device IDs Neal Cardwell (1): tcp: fix double-counted
Re: Linux 3.0.70
diff --git a/Makefile b/Makefile
index 534f7de..6754172 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 0
-SUBLEVEL = 69
+SUBLEVEL = 70
EXTRAVERSION =
NAME = Sneaky Weasel
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 9fb9332..421c9a0 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -268,7 +268,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_features = CPU_FTRS_PPC970,
.cpu_user_features = COMMON_USER_POWER4 |
PPC_FEATURE_HAS_ALTIVEC_COMP,
- .mmu_features = MMU_FTR_HPTE_TABLE,
+ .mmu_features = MMU_FTRS_PPC970,
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
diff --git a/arch/s390/include/asm/tlbflush.h b/arch/s390/include/asm/tlbflush.h
index b7a4f2e..d7862ad 100644
--- a/arch/s390/include/asm/tlbflush.h
+++ b/arch/s390/include/asm/tlbflush.h
@@ -73,8 +73,6 @@ static inline void __tlb_flush_idte(unsigned long asce)
static inline void __tlb_flush_mm(struct mm_struct * mm)
{
- if (unlikely(cpumask_empty(mm_cpumask(mm
- return;
/*
* If the machine has IDTE we prefer to do a per mm flush
* on all cpus instead of doing a local flush if the mm
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index d812fe2..c81d1f8 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -754,6 +754,16 @@ static void intel_ds_init(void)
}
}
+void perf_restore_debug_store(void)
+{
+ struct debug_store *ds = __this_cpu_read(cpu_hw_events.ds);
+
+ if (!x86_pmu.bts && !x86_pmu.pebs)
+ return;
+
+ wrmsrl(MSR_IA32_DS_AREA, (unsigned long)ds);
+}
+
#else /* CONFIG_CPU_SUP_INTEL */
static void reserve_ds_buffers(void)
diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
index 87bb35e..0ea8bd2 100644
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include
@@ -224,6 +225,7 @@ static void __restore_processor_state(struct saved_context
*ctxt)
do_fpu_end();
mtrr_bp_restore();
+ perf_restore_debug_store();
}
/* Needed by apm.c */
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 2ebacf0..258cd0a 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1274,11 +1274,9 @@ static int loop_set_capacity(struct loop_device *lo,
struct block_device *bdev)
/* the width of sector_t may be narrow for bit-shift */
sz = sec;
sz <<= 9;
- mutex_lock(&bdev->bd_mutex);
bd_set_size(bdev, sz);
/* let user-space know about the new size */
kobject_uevent(&disk_to_dev(bdev->bd_disk)->kobj, KOBJ_CHANGE);
- mutex_unlock(&bdev->bd_mutex);
out:
return err;
diff --git a/drivers/char/hw_random/virtio-rng.c
b/drivers/char/hw_random/virtio-rng.c
index 75f1cbd..ca7570d 100644
--- a/drivers/char/hw_random/virtio-rng.c
+++ b/drivers/char/hw_random/virtio-rng.c
@@ -88,14 +88,22 @@ static int virtrng_probe(struct virtio_device *vdev)
{
int err;
+ if (vq) {
+ /* We only support one device for now */
+ return -EBUSY;
+ }
/* We expect a single virtqueue. */
vq = virtio_find_single_vq(vdev, random_recv_done, "input");
- if (IS_ERR(vq))
- return PTR_ERR(vq);
+ if (IS_ERR(vq)) {
+ err = PTR_ERR(vq);
+ vq = NULL;
+ return err;
+ }
err = hwrng_register(&virtio_hwrng);
if (err) {
vdev->config->del_vqs(vdev);
+ vq = NULL;
return err;
}
@@ -107,6 +115,7 @@ static void __devexit virtrng_remove(struct virtio_device
*vdev)
vdev->config->reset(vdev);
hwrng_unregister(&virtio_hwrng);
vdev->config->del_vqs(vdev);
+ vq = NULL;
}
static struct virtio_device_id id_table[] = {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5548593..46e04a1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1256,6 +1256,11 @@ out:
case 0:
case -ERESTARTSYS:
case -EINTR:
+ case -EBUSY:
+ /*
+* EBUSY is ok: this just means that another thread
+* already did the job.
+*/
return VM_FAULT_NOPAGE;
case -ENOMEM:
return VM_FAULT_OOM;
diff --git a/drivers/hwmon/lineage-pem.c b/drivers/hwmon/lineage-pem.c
index 58eded2..c9910f7 100644
--- a/drivers/hwmon/lineage-pem.c
+++ b/drivers/hwmon/lineage-pem.c
@@ -421,6 +421,7 @@ static struct attribute *pem_input_
Linux 3.4.37
I'm announcing the release of the 3.4.37 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/powerpc/kernel/cputable.c|2 arch/powerpc/mm/hash_utils_64.c |2 arch/s390/include/asm/tlbflush.h |2 arch/s390/kernel/entry.S |3 arch/s390/kernel/entry64.S|5 arch/x86/kernel/cpu/perf_event_intel_ds.c | 10 arch/x86/power/cpu.c |2 drivers/block/loop.c | 24 +- drivers/char/hw_random/virtio-rng.c | 13 + drivers/gpu/drm/i915/i915_gem.c |5 drivers/gpu/drm/i915/intel_display.c |2 drivers/hwmon/lineage-pem.c |2 drivers/hwmon/pmbus/ltc2978.c | 14 - drivers/hwmon/sht15.c |2 drivers/net/macvlan.c |1 drivers/net/tun.c |2 drivers/staging/vt6656/main_usb.c |4 drivers/tty/pty.c |1 drivers/tty/serial/8250/8250_pci.c|4 drivers/tty/serial/Kconfig|2 drivers/usb/class/cdc-wdm.c | 23 +- drivers/usb/host/ehci-q.c | 18 + drivers/usb/serial/cp210x.c | 20 + drivers/usb/serial/option.c |5 drivers/usb/serial/qcaux.c|1 drivers/usb/storage/initializers.c| 76 -- drivers/usb/storage/initializers.h|4 drivers/usb/storage/unusual_devs.h| 329 +- drivers/video/atmel_lcdfb.c | 22 +- drivers/w1/w1.c |3 drivers/xen/xen-pciback/pciback_ops.c |3 fs/block_dev.c|4 fs/btrfs/volumes.c|6 fs/ext3/super.c |4 include/linux/perf_event.h|6 include/video/atmel_lcdc.h|1 kernel/signal.c |3 net/core/dev.c|1 net/core/rtnetlink.c |1 net/dcb/dcbnl.c |7 net/ieee802154/6lowpan.h |2 net/ipv4/tcp_input.c |6 net/ipv6/ip6_input.c |3 net/ipv6/route.c |3 net/l2tp/l2tp_ppp.c |1 net/netlabel/netlabel_unlabeled.c | 27 +- net/rds/message.c |3 security/selinux/xfrm.c |2 sound/core/seq/seq_timer.c|8 50 files changed, 540 insertions(+), 156 deletions(-) Alan Stern (1): USB: EHCI: don't check DMA values in QH overlays Amit Shah (1): virtio: rng: disallow multiple device registrations, fixes crashes Axel Lin (1): hwmon: (lineage-pem) Add missing terminating entry for pem_[input|fan]_attributes Ben Hutchings (1): hwmon: (sht15) Fix memory leak if regulator_enable() fails Benjamin Herrenschmidt (2): powerpc: Fix STAB initialization powerpc: Fix cputable entry for 970MP rev 1.0 Bjørn Mork (2): USB: option: add Huawei E5331 USB: storage: fix Huawei mode switching regression Christian Schmiedl (1): USB: added support for Cinterion's products AH6 and PLS8 Cong Wang (1): rds: limit the size allocated by rds_message_alloc() Cristian Bercaru (1): bridging: fix rx_handlers return code Dan Carpenter (1): selinux: use GFP_ATOMIC under spin_lock Dan Williams (1): qcaux: add Franklin U600 David Rientjes (1): perf,x86: fix link failure for non-Intel configs Dmitry Rogozhkin (1): drm/i915: EBUSY status handling added to i915_gem_fault(). Eric Dumazet (1): tun: add a missing nf_reset() in tun_net_xmit() Eric Sandeen (1): btrfs: use rcu_barrier() to wait for bdev puts at unmount Greg Kroah-Hartman (1): Linux 3.4.37 Guenter Roeck (1): hwmon: (pmbus/ltc2978) Fix temperature reporting Guillaume Nault (1): l2tp: Restore socket refcount when sendmsg succeeds Guo Chao (3): block: use i_size_write() in bd_set_size() loopdev: fix a deadlock loopdev: remove an user triggerable oops Hannes Frederic Sowa (1): ipv6: stop multicast forwarding to process interface scoped addresses Heiko Carstens (1): s390/mm: fix flush_tlb_kernel_range() Jiri Slaby (1): TTY: do not reset master's packet mode Johan Hovold (1): atmel_lcdfb: fix 16-bpp modes on older SOCs Kees Cook (1): signal: always clear sa_
Re: Linux 3.4.37
diff --git a/Makefile b/Makefile
index 2659987..a9e4d61 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 4
-SUBLEVEL = 36
+SUBLEVEL = 37
EXTRAVERSION =
NAME = Saber-toothed Squirrel
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 455faa3..31a3dd0 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -269,7 +269,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_features = CPU_FTRS_PPC970,
.cpu_user_features = COMMON_USER_POWER4 |
PPC_FEATURE_HAS_ALTIVEC_COMP,
- .mmu_features = MMU_FTR_HPTE_TABLE,
+ .mmu_features = MMU_FTRS_PPC970,
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 377e5cb..15972e2 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -759,6 +759,8 @@ void __init early_init_mmu(void)
/* Initialize stab / SLB management */
if (mmu_has_feature(MMU_FTR_SLB))
slb_initialize();
+ else
+ stab_initialize(get_paca()->stab_real);
}
#ifdef CONFIG_SMP
diff --git a/arch/s390/include/asm/tlbflush.h b/arch/s390/include/asm/tlbflush.h
index 1d8648c..8743029 100644
--- a/arch/s390/include/asm/tlbflush.h
+++ b/arch/s390/include/asm/tlbflush.h
@@ -74,8 +74,6 @@ static inline void __tlb_flush_idte(unsigned long asce)
static inline void __tlb_flush_mm(struct mm_struct * mm)
{
- if (unlikely(cpumask_empty(mm_cpumask(mm
- return;
/*
* If the machine has IDTE we prefer to do a per mm flush
* on all cpus instead of doing a local flush if the mm
diff --git a/arch/s390/kernel/entry.S b/arch/s390/kernel/entry.S
index 74ee563..009518c 100644
--- a/arch/s390/kernel/entry.S
+++ b/arch/s390/kernel/entry.S
@@ -669,7 +669,8 @@ ENTRY(mcck_int_handler)
UPDATE_VTIME %r14,%r15,__LC_MCCK_ENTER_TIMER
mcck_skip:
SWITCH_ASYNC __LC_GPREGS_SAVE_AREA+32,__LC_PANIC_STACK,PAGE_SHIFT
- mvc __PT_R0(64,%r11),__LC_GPREGS_SAVE_AREA
+ stm %r0,%r7,__PT_R0(%r11)
+ mvc __PT_R8(32,%r11),__LC_GPREGS_SAVE_AREA+32
stm %r8,%r9,__PT_PSW(%r11)
xc __SF_BACKCHAIN(4,%r15),__SF_BACKCHAIN(%r15)
l %r1,BASED(.Ldo_machine_check)
diff --git a/arch/s390/kernel/entry64.S b/arch/s390/kernel/entry64.S
index 4e1c292..b6f3e7c 100644
--- a/arch/s390/kernel/entry64.S
+++ b/arch/s390/kernel/entry64.S
@@ -689,8 +689,9 @@ ENTRY(mcck_int_handler)
UPDATE_VTIME %r14,__LC_MCCK_ENTER_TIMER
LAST_BREAK %r14
mcck_skip:
- lghi%r14,__LC_GPREGS_SAVE_AREA
- mvc __PT_R0(128,%r11),0(%r14)
+ lghi%r14,__LC_GPREGS_SAVE_AREA+64
+ stmg%r0,%r7,__PT_R0(%r11)
+ mvc __PT_R8(64,%r11),0(%r14)
stmg%r8,%r9,__PT_PSW(%r11)
xc __SF_BACKCHAIN(8,%r15),__SF_BACKCHAIN(%r15)
lgr %r2,%r11# pass pointer to pt_regs
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index 7f64df1..fca48c4 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -723,3 +723,13 @@ void intel_ds_init(void)
}
}
}
+
+void perf_restore_debug_store(void)
+{
+ struct debug_store *ds = __this_cpu_read(cpu_hw_events.ds);
+
+ if (!x86_pmu.bts && !x86_pmu.pebs)
+ return;
+
+ wrmsrl(MSR_IA32_DS_AREA, (unsigned long)ds);
+}
diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
index 218cdb1..fcbaac60 100644
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -227,6 +228,7 @@ static void __restore_processor_state(struct saved_context
*ctxt)
do_fpu_end();
x86_platform.restore_sched_clock_state();
mtrr_bp_restore();
+ perf_restore_debug_store();
}
/* Needed by apm.c */
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index bbca966..5e3be05 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1263,11 +1263,9 @@ static int loop_set_capacity(struct loop_device *lo,
struct block_device *bdev)
/* the width of sector_t may be narrow for bit-shift */
sz = sec;
sz <<= 9;
- mutex_lock(&bdev->bd_mutex);
bd_set_size(bdev, sz);
/* let user-space know about the new size */
kobject_uevent(&disk_to_dev(bdev->bd_disk)->kobj, KOBJ_CHANGE);
- mutex_unlock(&bdev->bd_mutex);
out:
return err;
@@ -1837,11 +1835,15 @@ static int __init loop_init(void)
max_part = (1UL << part_shift) - 1;
}
- if ((1UL << part_shift) > DISK_MAX_PAR
Linux 3.8.4
I'm announcing the release of the 3.8.4 kernel. All users of the 3.8 kernel series must upgrade. The updated 3.8.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.8.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/devicetree/bindings/tty/serial/of-serial.txt |3 Makefile |2 arch/arm/mach-at91/board-foxg20.c |1 arch/arm/mach-at91/board-stamp9g20.c |1 arch/arm/mach-davinci/dma.c|3 arch/arm/mach-ixp4xx/vulcan-setup.c|1 arch/arm/mach-kirkwood/board-dt.c | 24 arch/arm/mach-pxa/raumfeld.c |1 arch/powerpc/include/asm/mmu-hash64.h | 128 ++--- arch/powerpc/kernel/cputable.c |2 arch/powerpc/kernel/exceptions-64s.S | 34 - arch/powerpc/kvm/book3s_64_mmu_host.c |4 arch/powerpc/mm/hash_utils_64.c| 22 arch/powerpc/mm/mmu_context_hash64.c | 11 arch/powerpc/mm/pgtable_64.c |2 arch/powerpc/mm/slb_low.S | 50 - arch/powerpc/mm/tlb_hash64.c |2 arch/s390/include/asm/tlbflush.h |2 arch/s390/kernel/entry.S |3 arch/s390/kernel/entry64.S |5 arch/x86/kernel/cpu/perf_event_intel_ds.c | 10 arch/x86/power/cpu.c |2 drivers/block/loop.c | 24 drivers/char/hw_random/virtio-rng.c| 13 drivers/gpu/drm/i915/i915_dma.c| 23 drivers/gpu/drm/i915/i915_drv.c| 13 drivers/gpu/drm/i915/i915_drv.h|1 drivers/gpu/drm/i915/i915_irq.c|4 drivers/hwmon/lineage-pem.c|2 drivers/hwmon/pmbus/ltc2978.c | 14 drivers/mtd/nand/nand_base.c | 16 drivers/mtd/nand/nand_ids.c| 80 +-- drivers/net/bonding/bond_main.c|5 drivers/net/ethernet/atheros/atl1c/atl1c_main.c|2 drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 16 drivers/net/macvlan.c |1 drivers/net/team/team.c|2 drivers/net/tun.c |2 drivers/net/vxlan.c|9 drivers/staging/comedi/drivers/dt9812.c| 16 drivers/staging/vt6656/main_usb.c |4 drivers/tty/pty.c |1 drivers/tty/serial/8250/8250.c | 52 ++ drivers/tty/serial/8250/8250_pci.c | 21 drivers/tty/serial/8250/8250_pnp.c | 12 drivers/tty/serial/Kconfig |4 drivers/tty/serial/of_serial.c |6 drivers/tty/tty_buffer.c |2 drivers/usb/class/cdc-wdm.c| 23 drivers/usb/dwc3/core.c|1 drivers/usb/host/ehci-q.c | 18 drivers/usb/serial/cp210x.c| 20 drivers/usb/serial/option.c|5 drivers/usb/serial/qcaux.c |1 drivers/usb/serial/qcserial.c |7 drivers/usb/storage/initializers.c | 76 --- drivers/usb/storage/initializers.h |4 drivers/usb/storage/unusual_devs.h | 329 - drivers/video/atmel_lcdfb.c| 22 drivers/w1/masters/w1-gpio.c |4 drivers/w1/w1.c|3 drivers/xen/xen-pciback/pciback_ops.c |3 fs/block_dev.c |4 fs/btrfs/volumes.c |6 fs/ext3/super.c|4 include/linux/mtd/nand.h |7 include/linux/perf_event.h |6
Re: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers
On 2013-03-20 21:08 +0100, Greg Kroah-Hartman wrote:
> On Tue, Mar 19, 2013 at 10:44:30PM +0100, Sven Joachim wrote:
>> On 2013-03-19 22:00 +0100, Alan Stern wrote:
>>
>> > On Tue, 19 Mar 2013, Sven Joachim wrote:
>> >
>> >> On 2013-03-19 21:10 +0100, Alan Stern wrote:
>> >>
>> >> > On Tue, 19 Mar 2013, Sven Joachim wrote:
>> >> >
>> >> >> > In what way is resume broken?
>> >> >>
>> >> >> The kernel comes back, but the screen is black. Manually switching
>> >> >> VT's
>> >> >> is possible, and if I type something I can see it on the screen, but
>> >> >> there is no response and the cursor does not blink. It looks as if the
>> >> >> VT is not switched backed on resume, and userspace tasks are not
>> >> >> restarted. Sysrq combinations apparently work, but produce no output.
>> >> >
>> >> > Are there any other problems? For example, even before you do a
>> >> > suspend, if you type Alt-SysRq-W do you see any processes listed?
>> >>
>> >> No.
>> >>
>> >> > There was another report on the linux-usb mailing list today of this
>> >> > same patch causing the khubd task to hang. I'm thinking that you might
>> >> > be facing a similar problem.
>> >>
>> >> Maybe, but before the suspend everything seems to be normal.
>> >
>> > Just out of curiosity, does the patch posted here:
>> >
>> >http://marc.info/?l=linux-usb&m=136361874807411&w=2
>> >
>> > make any difference?
>>
>> It fixes the problem for me, thanks. :-)
>
> Ok, I'll postpone this patch for the next stable release, in time for
> the fix to be put in at the same time.
I think patch 13/75 ("USB: EHCI: dont check DMA values in QH overlays")
should also be postponed then, at least Alan said so in
.
Cheers,
Sven
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers
On Wed, Mar 20, 2013 at 09:14:38PM +0100, Sven Joachim wrote:
> On 2013-03-20 21:08 +0100, Greg Kroah-Hartman wrote:
>
> > On Tue, Mar 19, 2013 at 10:44:30PM +0100, Sven Joachim wrote:
> >> On 2013-03-19 22:00 +0100, Alan Stern wrote:
> >>
> >> > On Tue, 19 Mar 2013, Sven Joachim wrote:
> >> >
> >> >> On 2013-03-19 21:10 +0100, Alan Stern wrote:
> >> >>
> >> >> > On Tue, 19 Mar 2013, Sven Joachim wrote:
> >> >> >
> >> >> >> > In what way is resume broken?
> >> >> >>
> >> >> >> The kernel comes back, but the screen is black. Manually switching
> >> >> >> VT's
> >> >> >> is possible, and if I type something I can see it on the screen, but
> >> >> >> there is no response and the cursor does not blink. It looks as if
> >> >> >> the
> >> >> >> VT is not switched backed on resume, and userspace tasks are not
> >> >> >> restarted. Sysrq combinations apparently work, but produce no
> >> >> >> output.
> >> >> >
> >> >> > Are there any other problems? For example, even before you do a
> >> >> > suspend, if you type Alt-SysRq-W do you see any processes listed?
> >> >>
> >> >> No.
> >> >>
> >> >> > There was another report on the linux-usb mailing list today of this
> >> >> > same patch causing the khubd task to hang. I'm thinking that you
> >> >> > might
> >> >> > be facing a similar problem.
> >> >>
> >> >> Maybe, but before the suspend everything seems to be normal.
> >> >
> >> > Just out of curiosity, does the patch posted here:
> >> >
> >> > http://marc.info/?l=linux-usb&m=136361874807411&w=2
> >> >
> >> > make any difference?
> >>
> >> It fixes the problem for me, thanks. :-)
> >
> > Ok, I'll postpone this patch for the next stable release, in time for
> > the fix to be put in at the same time.
>
> I think patch 13/75 ("USB: EHCI: dont check DMA values in QH overlays")
> should also be postponed then, at least Alan said so in
> .
Crap, I didn't postpone that one, hopefully it doesn't cause as many
problems...
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers
On Wed, 20 Mar 2013, Greg Kroah-Hartman wrote:
> > > Ok, I'll postpone this patch for the next stable release, in time for
> > > the fix to be put in at the same time.
> >
> > I think patch 13/75 ("USB: EHCI: dont check DMA values in QH overlays")
> > should also be postponed then, at least Alan said so in
> > .
>
> Crap, I didn't postpone that one, hopefully it doesn't cause as many
> problems...
I haven't tested this combination of changes, except in a highly
artificial setting (i.e., running the usbtest suite), so I don't know
how it will behave under normal use. In any case, it's too late to do
anything now except issue another -stable release.
I just saw that the "dont check DMA values" patch did get into the
3.0-stable and 3.4-stable releases. I didn't realize at the time, but
it shouldn't be in any kernel earlier than 3.6. I guess the best thing
to do is queue up a reversion for those two series.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "USB: EHCI: work around silicon bug in Intel's EHCI controllers" has been added to the 3.8-stable tree
This is a note to let you know that I've just added the patch titled
USB: EHCI: work around silicon bug in Intel's EHCI controllers
to the 3.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
usb-ehci-work-around-silicon-bug-in-intel-s-ehci-controllers.patch
and it can be found in the queue-3.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 6402c796d3b4205d3d7296157956c5100a05d7d6 Mon Sep 17 00:00:00 2001
From: Alan Stern
Date: Fri, 1 Mar 2013 10:50:08 -0500
Subject: USB: EHCI: work around silicon bug in Intel's EHCI controllers
From: Alan Stern
commit 6402c796d3b4205d3d7296157956c5100a05d7d6 upstream.
This patch (as1660) works around a hardware problem present in some
(if not all) Intel EHCI controllers. After a QH has been unlinked
from the async schedule and the corresponding IAA interrupt has
occurred, the controller is not supposed access the QH and its qTDs.
There certainly shouldn't be any more DMA writes to those structures.
Nevertheless, Intel's controllers have been observed to perform a
final writeback to the QH's overlay region and to the most recent qTD.
For more information and a test program to determine whether this
problem is present in a particular controller, see
http://marc.info/?l=linux-usb&m=135492071812265&w=2
http://marc.info/?l=linux-usb&m=136182570800963&w=2
This patch works around the problem by always waiting for two IAA
cycles when unlinking an async QH. The extra IAA delay gives the
controller time to perform its final writeback.
Surprisingly enough, the effects of this silicon bug have gone
undetected until quite recently. More through luck than anything
else, it hasn't caused any apparent problems. However, it does
interact badly with the path that follows this one, so it needs to be
addressed.
This is the first part of a fix for the regression reported at:
https://bugs.launchpad.net/bugs/1088733
Signed-off-by: Alan Stern
Tested-by: Stephen Thirlwall
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/ehci-hcd.c |6 ++
drivers/usb/host/ehci-q.c | 18 ++
2 files changed, 16 insertions(+), 8 deletions(-)
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -748,11 +748,9 @@ static irqreturn_t ehci_irq (struct usb_
/* guard against (alleged) silicon errata */
if (cmd & CMD_IAAD)
ehci_dbg(ehci, "IAA with IAAD still set?\n");
- if (ehci->async_iaa) {
+ if (ehci->async_iaa)
COUNT(ehci->stats.iaa);
- end_unlink_async(ehci);
- } else
- ehci_dbg(ehci, "IAA with nothing unlinked?\n");
+ end_unlink_async(ehci);
}
/* remote wakeup [4.3.1] */
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -1178,7 +1178,7 @@ static void single_unlink_async(struct e
struct ehci_qh *prev;
/* Add to the end of the list of QHs waiting for the next IAAD */
- qh->qh_state = QH_STATE_UNLINK;
+ qh->qh_state = QH_STATE_UNLINK_WAIT;
if (ehci->async_unlink)
ehci->async_unlink_last->unlink_next = qh;
else
@@ -1221,9 +1221,19 @@ static void start_iaa_cycle(struct ehci_
/* Do only the first waiting QH (nVidia bug?) */
qh = ehci->async_unlink;
- ehci->async_iaa = qh;
- ehci->async_unlink = qh->unlink_next;
- qh->unlink_next = NULL;
+
+ /*
+* Intel (?) bug: The HC can write back the overlay region
+* even after the IAA interrupt occurs. In self-defense,
+* always go through two IAA cycles for each QH.
+*/
+ if (qh->qh_state == QH_STATE_UNLINK_WAIT) {
+ qh->qh_state = QH_STATE_UNLINK;
+ } else {
+ ehci->async_iaa = qh;
+ ehci->async_unlink = qh->unlink_next;
+ qh->unlink_next = NULL;
+ }
/* Make sure the unlinks are all visible to the hardware */
wmb();
Patches currently in stable-queue which might be from st...@rowland.harvard.edu
are
queue-3.8/usb-ehci-work-around-silicon-bug-in-intel-s-ehci-controllers.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 12/48] signal: always clear sa_restorer on execve
Am 20.03.2013 20:02, schrieb Sebastian Gottschall (DD-WRT): Hello The patch for sa_restorer will break mips builds, since sa_restorer isnt defined as field within the struct, but the MACRO is. so use the __ARCH_HAS_SA_RESTORER way which is implemented in that way in linux 3.9 or simply revert the patch regards, Sebastian Gottschall -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Berliner Ring 101, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565 -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Berliner Ring 101, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
+ drivers-video-ep93xx-fbc-include-linux-ioh-for-devm_ioremap.patch added to -mm tree
The patch titled
Subject: drivers/video/ep93xx-fb.c: include for devm_ioremap()
has been added to the -mm tree. Its filename is
drivers-video-ep93xx-fbc-include-linux-ioh-for-devm_ioremap.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
--
From: H Hartley Sweeten
Subject: drivers/video/ep93xx-fb.c: include for devm_ioremap()
Commit be867814 ("drivers/video/ep93xx-fb.c: use devm_ functions")
introduced a build error:
drivers/video/ep93xx-fb.c: In function 'ep93xxfb_probe':
drivers/video/ep93xx-fb.c:532: error: implicit declaration of function
'devm_ioremap'
drivers/video/ep93xx-fb.c:533: warning: assignment makes pointer from integer
without a cast
Include to pickup the declaration of 'devm_ioremap'.
Signed-off-by: H Hartley Sweeten
Cc: Florian Tobias Schandinat
Acked-by: Ryan Mallon
Cc: Damien Cassou
Cc:
Signed-off-by: Andrew Morton
---
drivers/video/ep93xx-fb.c |1 +
1 file changed, 1 insertion(+)
diff -puN
drivers/video/ep93xx-fb.c~drivers-video-ep93xx-fbc-include-linux-ioh-for-devm_ioremap
drivers/video/ep93xx-fb.c
---
a/drivers/video/ep93xx-fb.c~drivers-video-ep93xx-fbc-include-linux-ioh-for-devm_ioremap
+++ a/drivers/video/ep93xx-fb.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
_
Patches currently in -mm which might be from hartl...@visionengravers.com are
linux-next.patch
drivers-video-ep93xx-fbc-include-linux-ioh-for-devm_ioremap.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] refactoring for mask_cache
On Wed, 20 Mar 2013, Gerlando Falauto wrote: > On 03/19/2013 12:56 PM, Jason Cooper wrote: > > On Tue, Mar 19, 2013 at 07:44:31AM -0400, Jason Cooper wrote: > > > Those commit IDs are going to change once LinusW (I presume) applies > > > them to his tree, so he'll have to edit each commit message to point the > > > the correct commit. > > > > > > LinusW, do you want me to handle this? > > > > Never mind, coffee underflow to /dev/brain. One drawback to mutt, can't > > view thread while typing messages... > > 1) I had no idea who LinusW is, I assume Linus Walleij who should be the > maintainer of linux-gpio. And linux-gpio should have nothing to do with this > discussion... so I should assume you never mentioned him, right? Jason had a brain hickup as he told. So please ignore that part :) > 2) About the SOB part... most of this is inspired by Simon's original (single) > patch and Holger's reworking. Should they be given credit or not? If yes, how? > If I don't get an answer I would just assume no and I'll take all the blame > and credit all by myself. :-) Yes, you can give them credit. There are only a few official "-by:" tags, but you can chose from the inofficial ones: Suggested-by: Originally-by: Original-patch-by: Requested-by: Original-idea-by: Based-on-patch-by: That's an incomplete list of already in-use tags, but one of those is probably sufficient. > 3) Jason, did you mean you would pull it to > http://git.infradead.org/users/jcooper/linux.git? Shall I change the SOB lines > and resubmit? Or should I submit it somewhere else instead? That needs to go through my tree, really. And please just post it to LKML with the relevant people CC'ed. > 4) About submitting to -stable, I guess it wouldn't make any sense until it > gets included upstream Right. Though I'm a bit concerned about the amount of change involved. So it's simpler to do: Cc: # simple resolution will be sent in reply Then let the people who have this problem reply on that patch series with a simple revert of that generic_chip() conversion commit concering their particular subarchitecture instead of forcing a nightmare of complex (and maybe untested) changes onto stable. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Intel-gfx] [PATCH] drm/i915: Fix pipe enabled mask for pipe C in WM calculations
On Wed, Mar 20, 2013 at 09:51:05PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Cc: stable@vger.kernel.org
One of the stable rules is that patches should fix real issues. So can you
please hunt through bugzillas quickly and feed this to relevant bug
reports?
-Daniel
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 8a3d89e..89a2d6f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1943,7 +1943,7 @@ static void ivybridge_update_wm(struct drm_device *dev)
> DRM_DEBUG_KMS("FIFO watermarks For pipe C -"
> " plane %d, cursor: %d\n",
> plane_wm, cursor_wm);
> - enabled |= 3;
> + enabled |= 4;
> }
>
> /*
> --
> 1.8.1.5
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "Revert "USB: EHCI: don't check DMA values in QH overlays"" has been added to the 3.4-stable tree
This is a note to let you know that I've just added the patch titled
Revert "USB: EHCI: don't check DMA values in QH overlays"
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
revert-usb-ehci-don-t-check-dma-values-in-qh-overlays.patch
and it can be found in the queue-3.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From foo@baz Wed Mar 20 14:16:12 PDT 2013
Date: Wed, 20 Mar 2013 14:16:12 -0700
To: Greg KH
From: Greg Kroah-Hartman
Subject: Revert "USB: EHCI: don't check DMA values in QH overlays"
This reverts commit 0319f9909ce68a7516dfc8d53400e07168d281a8, which is commit
feca7746d5d9e84b105a613b7f3b6ad00d327372 upstream.
It shouldn't have gone into this stable release.
Cc: Alan Stern
Cc: Joseph Salisbury
Cc: Stephen Thirlwall
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/ehci-q.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -135,7 +135,7 @@ qh_refresh (struct ehci_hcd *ehci, struc
* qtd is updated in qh_completions(). Update the QH
* overlay here.
*/
- if (qh->hw->hw_token & ACTIVE_BIT(ehci)) {
+ if (cpu_to_hc32(ehci, qtd->qtd_dma) == qh->hw->hw_current) {
qh->hw->hw_qtd_next = qtd->hw_next;
qtd = NULL;
}
@@ -459,19 +459,11 @@ qh_completions (struct ehci_hcd *ehci, s
else if (last_status == -EINPROGRESS && !urb->unlinked)
continue;
- /*
-* If this was the active qtd when the qh was unlinked
-* and the overlay's token is active, then the overlay
-* hasn't been written back to the qtd yet so use its
-* token instead of the qtd's. After the qtd is
-* processed and removed, the overlay won't be valid
-* any more.
-*/
- if (state == QH_STATE_IDLE &&
- qh->qtd_list.next == &qtd->qtd_list &&
- (hw->hw_token & ACTIVE_BIT(ehci))) {
+ /* qh unlinked; token in overlay may be most current */
+ if (state == QH_STATE_IDLE
+ && cpu_to_hc32(ehci, qtd->qtd_dma)
+ == hw->hw_current) {
token = hc32_to_cpu(ehci, hw->hw_token);
- hw->hw_token &= ~ACTIVE_BIT(ehci);
/* An unlink may leave an incomplete
* async transaction in the TT buffer.
Patches currently in stable-queue which might be from
gre...@linuxfoundation.org are
queue-3.4/revert-usb-ehci-don-t-check-dma-values-in-qh-overlays.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch "Revert "USB: EHCI: don't check DMA values in QH overlays"" has been added to the 3.0-stable tree
This is a note to let you know that I've just added the patch titled
Revert "USB: EHCI: don't check DMA values in QH overlays"
to the 3.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
revert-usb-ehci-don-t-check-dma-values-in-qh-overlays.patch
and it can be found in the queue-3.0 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From foo@baz Wed Mar 20 14:16:12 PDT 2013
Date: Wed, 20 Mar 2013 14:16:12 -0700
To: Greg KH
From: Greg Kroah-Hartman
Subject: Revert "USB: EHCI: don't check DMA values in QH overlays"
This reverts commit 0319f9909ce68a7516dfc8d53400e07168d281a8, which is commit
feca7746d5d9e84b105a613b7f3b6ad00d327372 upstream.
It shouldn't have gone into this stable release.
Cc: Alan Stern
Cc: Joseph Salisbury
Cc: Stephen Thirlwall
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/ehci-q.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -137,7 +137,7 @@ qh_refresh (struct ehci_hcd *ehci, struc
* qtd is updated in qh_completions(). Update the QH
* overlay here.
*/
- if (qh->hw->hw_token & ACTIVE_BIT(ehci)) {
+ if (cpu_to_hc32(ehci, qtd->qtd_dma) == qh->hw->hw_current) {
qh->hw->hw_qtd_next = qtd->hw_next;
qtd = NULL;
}
@@ -450,19 +450,11 @@ qh_completions (struct ehci_hcd *ehci, s
else if (last_status == -EINPROGRESS && !urb->unlinked)
continue;
- /*
-* If this was the active qtd when the qh was unlinked
-* and the overlay's token is active, then the overlay
-* hasn't been written back to the qtd yet so use its
-* token instead of the qtd's. After the qtd is
-* processed and removed, the overlay won't be valid
-* any more.
-*/
- if (state == QH_STATE_IDLE &&
- qh->qtd_list.next == &qtd->qtd_list &&
- (hw->hw_token & ACTIVE_BIT(ehci))) {
+ /* qh unlinked; token in overlay may be most current */
+ if (state == QH_STATE_IDLE
+ && cpu_to_hc32(ehci, qtd->qtd_dma)
+ == hw->hw_current) {
token = hc32_to_cpu(ehci, hw->hw_token);
- hw->hw_token &= ~ACTIVE_BIT(ehci);
/* An unlink may leave an incomplete
* async transaction in the TT buffer.
Patches currently in stable-queue which might be from
gre...@linuxfoundation.org are
queue-3.0/revert-usb-ehci-don-t-check-dma-values-in-qh-overlays.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers
On Wed, Mar 20, 2013 at 04:41:21PM -0400, Alan Stern wrote:
> On Wed, 20 Mar 2013, Greg Kroah-Hartman wrote:
>
> > > > Ok, I'll postpone this patch for the next stable release, in time for
> > > > the fix to be put in at the same time.
> > >
> > > I think patch 13/75 ("USB: EHCI: dont check DMA values in QH overlays")
> > > should also be postponed then, at least Alan said so in
> > > .
> >
> > Crap, I didn't postpone that one, hopefully it doesn't cause as many
> > problems...
>
> I haven't tested this combination of changes, except in a highly
> artificial setting (i.e., running the usbtest suite), so I don't know
> how it will behave under normal use. In any case, it's too late to do
> anything now except issue another -stable release.
>
> I just saw that the "dont check DMA values" patch did get into the
> 3.0-stable and 3.4-stable releases. I didn't realize at the time, but
> it shouldn't be in any kernel earlier than 3.6. I guess the best thing
> to do is queue up a reversion for those two series.
I've now done this, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Intel-gfx] [PATCH] drm/i915: Fix pipe enabled mask for pipe C in WM calculations
On Wed, Mar 20, 2013 at 11:05:37PM +0100, Daniel Vetter wrote: > On Wed, Mar 20, 2013 at 09:51:05PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Cc: stable@vger.kernel.org > > One of the stable rules is that patches should fix real issues. So can you > please hunt through bugzillas quickly and feed this to relevant bug > reports? It would take an astute user to notice that his machine was not using a lower power self-refresh FIFO mode. And the number of machines that only set up the third pipe is going to be small, so the impact minor. It will not fix any of the three pipe issues we have open, for example. The patch is correct, though had I used enabled |= 1 << PIPE_[ABC] it would have probably prevented this bug. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 3.8.4
consider that this kernel is not compileable on mips targets due the patch in kernel/signal.c SA_RESTORER is defined in mips, but sa_restorer does not exist on that platform Am 20.03.2013 21:15, schrieb Greg KH: I'm announcing the release of the 3.8.4 kernel. All users of the 3.8 kernel series must upgrade. The updated 3.8.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.8.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/devicetree/bindings/tty/serial/of-serial.txt |3 Makefile |2 arch/arm/mach-at91/board-foxg20.c |1 arch/arm/mach-at91/board-stamp9g20.c |1 arch/arm/mach-davinci/dma.c|3 arch/arm/mach-ixp4xx/vulcan-setup.c|1 arch/arm/mach-kirkwood/board-dt.c | 24 arch/arm/mach-pxa/raumfeld.c |1 arch/powerpc/include/asm/mmu-hash64.h | 128 ++--- arch/powerpc/kernel/cputable.c |2 arch/powerpc/kernel/exceptions-64s.S | 34 - arch/powerpc/kvm/book3s_64_mmu_host.c |4 arch/powerpc/mm/hash_utils_64.c| 22 arch/powerpc/mm/mmu_context_hash64.c | 11 arch/powerpc/mm/pgtable_64.c |2 arch/powerpc/mm/slb_low.S | 50 - arch/powerpc/mm/tlb_hash64.c |2 arch/s390/include/asm/tlbflush.h |2 arch/s390/kernel/entry.S |3 arch/s390/kernel/entry64.S |5 arch/x86/kernel/cpu/perf_event_intel_ds.c | 10 arch/x86/power/cpu.c |2 drivers/block/loop.c | 24 drivers/char/hw_random/virtio-rng.c| 13 drivers/gpu/drm/i915/i915_dma.c| 23 drivers/gpu/drm/i915/i915_drv.c| 13 drivers/gpu/drm/i915/i915_drv.h|1 drivers/gpu/drm/i915/i915_irq.c|4 drivers/hwmon/lineage-pem.c|2 drivers/hwmon/pmbus/ltc2978.c | 14 drivers/mtd/nand/nand_base.c | 16 drivers/mtd/nand/nand_ids.c| 80 +-- drivers/net/bonding/bond_main.c|5 drivers/net/ethernet/atheros/atl1c/atl1c_main.c|2 drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 16 drivers/net/macvlan.c |1 drivers/net/team/team.c|2 drivers/net/tun.c |2 drivers/net/vxlan.c|9 drivers/staging/comedi/drivers/dt9812.c| 16 drivers/staging/vt6656/main_usb.c |4 drivers/tty/pty.c |1 drivers/tty/serial/8250/8250.c | 52 ++ drivers/tty/serial/8250/8250_pci.c | 21 drivers/tty/serial/8250/8250_pnp.c | 12 drivers/tty/serial/Kconfig |4 drivers/tty/serial/of_serial.c |6 drivers/tty/tty_buffer.c |2 drivers/usb/class/cdc-wdm.c| 23 drivers/usb/dwc3/core.c|1 drivers/usb/host/ehci-q.c | 18 drivers/usb/serial/cp210x.c| 20 drivers/usb/serial/option.c|5 drivers/usb/serial/qcaux.c |1 drivers/usb/serial/qcserial.c |7 drivers/usb/storage/initializers.c | 76 --- drivers/usb/storage/initializers.h |4 drivers/usb/storage/unusual_devs.h | 329 - drivers/video/atmel_lcdfb.c| 22 drivers/w1/masters/w1-gpio.c |4 drivers/w1/w1.c|3 drivers/xen/xen-pciback/pciback_ops.c |3 fs/block_dev.c |4 fs/btrfs/volumes.c
Re: [Intel-gfx] [PATCH] drm/i915: Fix pipe enabled mask for pipe C in WM calculations
On Wed, Mar 20, 2013 at 11:39 PM, Chris Wilson wrote: > On Wed, Mar 20, 2013 at 11:05:37PM +0100, Daniel Vetter wrote: >> On Wed, Mar 20, 2013 at 09:51:05PM +0200, ville.syrj...@linux.intel.com >> wrote: >> > From: Ville Syrjälä >> > >> > Cc: stable@vger.kernel.org >> >> One of the stable rules is that patches should fix real issues. So can you >> please hunt through bugzillas quickly and feed this to relevant bug >> reports? > > It would take an astute user to notice that his machine was not using a > lower power self-refresh FIFO mode. And the number of machines that only > set up the third pipe is going to be small, so the impact minor. It > will not fix any of the three pipe issues we have open, for example. Ah, lazy me didn't read the docs. Low power fifo mode is indeed hard to report in a bug ;-) > The patch is correct, though had I used enabled |= 1 << PIPE_[ABC] it > would have probably prevented this bug. This would be quite a bit less magic I think. Can I have it, please? -Daniel > Reviewed-by: Chris Wilson -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
+ drivers-char-randomc-fix-priming-of-last_data.patch added to -mm tree
The patch titled
Subject: drivers/char/random.c: fix priming of last_data
has been added to the -mm tree. Its filename is
drivers-char-randomc-fix-priming-of-last_data.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
--
From: Jarod Wilson
Subject: drivers/char/random.c: fix priming of last_data
Commit ec8f02da9e ("random: prime last_data value per fips requirements")
added priming of last_data per fips requirements. Unfortuantely, it did
so in a way that can lead to multiple threads all incrementing nbytes, but
only one actually doing anything with the extra data, which leads to some
fun random corruption and panics.
The fix is to simply do everything needed to prime last_data in a single
shot, so there's no window for multiple cpus to increment nbytes -- in
fact, we won't even increment or decrement nbytes anymore, we'll just
extract the needed EXTRACT_BYTES one time per pool and then carry on with
the normal routine.
All these changes have been tested across multiple hosts and architectures
where panics were previously encoutered. The code changes are are
strictly limited to areas only touched when when booted in fips mode.
This change should also go into 3.8-stable, to make the myriads of fips
users on 3.8.x happy.
Signed-off-by: Jarod Wilson
Tested-by: Jan Stancek
Tested-by: Jan Stodola
Cc: Herbert Xu
Cc: Neil Horman
Cc: "David S. Miller"
Cc: Matt Mackall
Cc: "Theodore Ts'o"
Cc:
Signed-off-by: Andrew Morton
---
drivers/char/random.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff -puN drivers/char/random.c~drivers-char-randomc-fix-priming-of-last_data
drivers/char/random.c
--- a/drivers/char/random.c~drivers-char-randomc-fix-priming-of-last_data
+++ a/drivers/char/random.c
@@ -957,10 +957,23 @@ static ssize_t extract_entropy(struct en
{
ssize_t ret = 0, i;
__u8 tmp[EXTRACT_SIZE];
+ unsigned long flags;
/* if last_data isn't primed, we need EXTRACT_SIZE extra bytes */
- if (fips_enabled && !r->last_data_init)
- nbytes += EXTRACT_SIZE;
+ if (fips_enabled) {
+ spin_lock_irqsave(&r->lock, flags);
+ if (!r->last_data_init) {
+ r->last_data_init = true;
+ spin_unlock_irqrestore(&r->lock, flags);
+ trace_extract_entropy(r->name, EXTRACT_SIZE,
+ r->entropy_count, _RET_IP_);
+ xfer_secondary_pool(r, EXTRACT_SIZE);
+ extract_buf(r, tmp);
+ spin_lock_irqsave(&r->lock, flags);
+ memcpy(r->last_data, tmp, EXTRACT_SIZE);
+ }
+ spin_unlock_irqrestore(&r->lock, flags);
+ }
trace_extract_entropy(r->name, nbytes, r->entropy_count, _RET_IP_);
xfer_secondary_pool(r, nbytes);
@@ -970,19 +983,6 @@ static ssize_t extract_entropy(struct en
extract_buf(r, tmp);
if (fips_enabled) {
- unsigned long flags;
-
-
- /* prime last_data value if need be, per fips 140-2 */
- if (!r->last_data_init) {
- spin_lock_irqsave(&r->lock, flags);
- memcpy(r->last_data, tmp, EXTRACT_SIZE);
- r->last_data_init = true;
- nbytes -= EXTRACT_SIZE;
- spin_unlock_irqrestore(&r->lock, flags);
- extract_buf(r, tmp);
- }
-
spin_lock_irqsave(&r->lock, flags);
if (!memcmp(tmp, r->last_data, EXTRACT_SIZE))
panic("Hardware RNG duplicated output!\n");
_
Patches currently in -mm which might be from ja...@redhat.com are
drivers-char-randomc-fix-priming-of-last_data.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
+ drivers-char-randomc-fix-priming-of-last_data.patch added to -mm tree
The patch titled
Subject: drivers/char/random.c: fix priming of last_data
has been added to the -mm tree. Its filename is
drivers-char-randomc-fix-priming-of-last_data.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
--
From: Jarod Wilson
Subject: drivers/char/random.c: fix priming of last_data
Commit ec8f02da9e ("random: prime last_data value per fips requirements")
added priming of last_data per fips requirements. Unfortuantely, it did
so in a way that can lead to multiple threads all incrementing nbytes, but
only one actually doing anything with the extra data, which leads to some
fun random corruption and panics.
The fix is to simply do everything needed to prime last_data in a single
shot, so there's no window for multiple cpus to increment nbytes -- in
fact, we won't even increment or decrement nbytes anymore, we'll just
extract the needed EXTRACT_SIZE one time per pool and then carry on with
the normal routine.
All these changes have been tested across multiple hosts and architectures
where panics were previously encoutered. The code changes are are
strictly limited to areas only touched when when booted in fips mode.
This change should also go into 3.8-stable, to make the myriads of fips
users on 3.8.x happy.
Signed-off-by: Jarod Wilson
Tested-by: Jan Stancek
Tested-by: Jan Stodola
Cc: Herbert Xu
Acked-by: Neil Horman
Cc: "David S. Miller"
Cc: Matt Mackall
Cc: "Theodore Ts'o"
Cc:
Signed-off-by: Andrew Morton
---
drivers/char/random.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff -puN drivers/char/random.c~drivers-char-randomc-fix-priming-of-last_data
drivers/char/random.c
--- a/drivers/char/random.c~drivers-char-randomc-fix-priming-of-last_data
+++ a/drivers/char/random.c
@@ -957,10 +957,23 @@ static ssize_t extract_entropy(struct en
{
ssize_t ret = 0, i;
__u8 tmp[EXTRACT_SIZE];
+ unsigned long flags;
/* if last_data isn't primed, we need EXTRACT_SIZE extra bytes */
- if (fips_enabled && !r->last_data_init)
- nbytes += EXTRACT_SIZE;
+ if (fips_enabled) {
+ spin_lock_irqsave(&r->lock, flags);
+ if (!r->last_data_init) {
+ r->last_data_init = true;
+ spin_unlock_irqrestore(&r->lock, flags);
+ trace_extract_entropy(r->name, EXTRACT_SIZE,
+ r->entropy_count, _RET_IP_);
+ xfer_secondary_pool(r, EXTRACT_SIZE);
+ extract_buf(r, tmp);
+ spin_lock_irqsave(&r->lock, flags);
+ memcpy(r->last_data, tmp, EXTRACT_SIZE);
+ }
+ spin_unlock_irqrestore(&r->lock, flags);
+ }
trace_extract_entropy(r->name, nbytes, r->entropy_count, _RET_IP_);
xfer_secondary_pool(r, nbytes);
@@ -970,19 +983,6 @@ static ssize_t extract_entropy(struct en
extract_buf(r, tmp);
if (fips_enabled) {
- unsigned long flags;
-
-
- /* prime last_data value if need be, per fips 140-2 */
- if (!r->last_data_init) {
- spin_lock_irqsave(&r->lock, flags);
- memcpy(r->last_data, tmp, EXTRACT_SIZE);
- r->last_data_init = true;
- nbytes -= EXTRACT_SIZE;
- spin_unlock_irqrestore(&r->lock, flags);
- extract_buf(r, tmp);
- }
-
spin_lock_irqsave(&r->lock, flags);
if (!memcmp(tmp, r->last_data, EXTRACT_SIZE))
panic("Hardware RNG duplicated output!\n");
_
Patches currently in -mm which might be from ja...@redhat.com are
drivers-char-randomc-fix-priming-of-last_data.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
patch "USB: EHCI: fix regression in QH unlinking" added to usb tree
This is a note to let you know that I've just added the patch titled
USB: EHCI: fix regression in QH unlinking
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From d714aaf649460cbfd5e82e75520baa856b4fa0a0 Mon Sep 17 00:00:00 2001
From: Alan Stern
Date: Wed, 20 Mar 2013 15:07:26 -0400
Subject: USB: EHCI: fix regression in QH unlinking
This patch (as1670) fixes a regression caused by commit
6402c796d3b4205d3d7296157956c5100a05d7d6 (USB: EHCI: work around
silicon bug in Intel's EHCI controllers). The workaround goes through
two IAA cycles for each QH being unlinked. During the first cycle,
the QH is not added to the async_iaa list (because it isn't fully gone
from the hardware yet), which means that list will be empty.
Unfortunately, I forgot to update the IAA watchdog timer routine. It
thinks that an empty async_iaa list means the timer expiration was an
error, which isn't true any more. This problem didn't show up during
initial testing because the controllers being tested all had working
IAA interrupts. But not all controllers do, and when the watchdog
timer expires, the empty-list check prevents the second IAA cycle from
starting. As a result, URB unlinks never complete. The check needs
to be removed.
Among the symptoms of the regression are processes stuck in D wait
states and hangs during system shutdown.
Signed-off-by: Alan Stern
Reported-and-tested-by: Stephen Warren
Reported-and-tested-by: Sven Joachim
Reported-by: Andreas Bombe
Cc: stable
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/host/ehci-timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-timer.c b/drivers/usb/host/ehci-timer.c
index 20dbdcb..c3fa130 100644
--- a/drivers/usb/host/ehci-timer.c
+++ b/drivers/usb/host/ehci-timer.c
@@ -304,7 +304,7 @@ static void ehci_iaa_watchdog(struct ehci_hcd *ehci)
* (a) SMP races against real IAA firing and retriggering, and
* (b) clean HC shutdown, when IAA watchdog was pending.
*/
- if (ehci->async_iaa) {
+ if (1) {
u32 cmd, status;
/* If we get here, IAA is *REALLY* late. It's barely
--
1.8.0.rc0.18.gf84667d
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "crypto: talitos - add IPsec ESN support"
On Wed, 20 Mar 2013 16:31:38 +0200 Horia Geanta wrote: > This reverts commit e763eb699be723fb41af818118068c6b3afdaf8d. > > Current IPsec ESN implementation for authencesn(cbc(aes), hmac(sha)) > (separate encryption and integrity algorithms) does not conform > to RFC4303. > > ICV is generated by hashing the sequence > SPI, SeqNum-High, SeqNum-Low, IV, Payload > instead of > SPI, SeqNum-Low, IV, Payload, SeqNum-High. > > Cc: # 3.8, 3.7 > Reported-by: Chaoxing Lin > Signed-off-by: Horia Geanta > --- Reviewed-by: Kim Phillips Kim -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "crypto: caam - add IPsec ESN support"
On Wed, 20 Mar 2013 16:31:58 +0200 Horia Geanta wrote: > This reverts commit 891104ed008e8646c7860fe5bc70b0aac55dcc6c. > > Current IPsec ESN implementation for authencesn(cbc(aes), hmac(sha)) > (separate encryption and integrity algorithms) does not conform > to RFC4303. > > ICV is generated by hashing the sequence > SPI, SeqNum-High, SeqNum-Low, IV, Payload > instead of > SPI, SeqNum-Low, IV, Payload, SeqNum-High. > > Cc: # 3.8, 3.7 > Reported-by: Chaoxing Lin > Signed-off-by: Horia Geanta > --- Reviewed-by: Kim Phillips Kim -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
patch "sysfs: fix race between readdir and lseek" added to driver-core tree
This is a note to let you know that I've just added the patch titled
sysfs: fix race between readdir and lseek
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 991f76f837bf22c5bb07261cfd86525a0a96650c Mon Sep 17 00:00:00 2001
From: Ming Lei
Date: Wed, 20 Mar 2013 23:25:24 +0800
Subject: sysfs: fix race between readdir and lseek
While readdir() is running, lseek() may set filp->f_pos as zero,
then may leave filp->private_data pointing to one sysfs_dirent
object without holding its reference counter, so the sysfs_dirent
object may be used after free in next readdir().
This patch holds inode->i_mutex to avoid the problem since
the lock is always held in readdir path.
Reported-by: Dave Jones
Tested-by: Sasha Levin
Cc:
Signed-off-by: Ming Lei
Signed-off-by: Greg Kroah-Hartman
---
fs/sysfs/dir.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 2fbdff6..c9e1660 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -1058,10 +1058,21 @@ static int sysfs_readdir(struct file * filp, void *
dirent, filldir_t filldir)
return 0;
}
+static loff_t sysfs_dir_llseek(struct file *file, loff_t offset, int whence)
+{
+ struct inode *inode = file_inode(file);
+ loff_t ret;
+
+ mutex_lock(&inode->i_mutex);
+ ret = generic_file_llseek(file, offset, whence);
+ mutex_unlock(&inode->i_mutex);
+
+ return ret;
+}
const struct file_operations sysfs_dir_operations = {
.read = generic_read_dir,
.readdir= sysfs_readdir,
.release= sysfs_dir_release,
- .llseek = generic_file_llseek,
+ .llseek = sysfs_dir_llseek,
};
--
1.8.0.rc0.18.gf84667d
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
patch "sysfs: handle failure path correctly for readdir()" added to driver-core tree
This is a note to let you know that I've just added the patch titled
sysfs: handle failure path correctly for readdir()
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From e5110f411d2ee35bf8d202ccca2e89c633060dca Mon Sep 17 00:00:00 2001
From: Ming Lei
Date: Wed, 20 Mar 2013 23:25:25 +0800
Subject: sysfs: handle failure path correctly for readdir()
In case of 'if (filp->f_pos == 0 or 1)' of sysfs_readdir(),
the failure from filldir() isn't handled, and the reference counter
of the sysfs_dirent object pointed by filp->private_data will be
released without clearing filp->private_data, so use after free
bug will be triggered later.
This patch returns immeadiately under the situation for fixing the bug,
and it is reasonable to return from readdir() when filldir() fails.
Reported-by: Dave Jones
Tested-by: Sasha Levin
Cc:
Signed-off-by: Ming Lei
Signed-off-by: Greg Kroah-Hartman
---
fs/sysfs/dir.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index c9e1660..e145126 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -1020,6 +1020,8 @@ static int sysfs_readdir(struct file * filp, void *
dirent, filldir_t filldir)
ino = parent_sd->s_ino;
if (filldir(dirent, ".", 1, filp->f_pos, ino, DT_DIR) == 0)
filp->f_pos++;
+ else
+ return 0;
}
if (filp->f_pos == 1) {
if (parent_sd->s_parent)
@@ -1028,6 +1030,8 @@ static int sysfs_readdir(struct file * filp, void *
dirent, filldir_t filldir)
ino = parent_sd->s_ino;
if (filldir(dirent, "..", 2, filp->f_pos, ino, DT_DIR) == 0)
filp->f_pos++;
+ else
+ return 0;
}
mutex_lock(&sysfs_mutex);
for (pos = sysfs_dir_pos(ns, parent_sd, filp->f_pos, pos);
--
1.8.0.rc0.18.gf84667d
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm/x86: Patch out arch_flush_lazy_mmu_mode() when running on bare metal
On Wed, Mar 20, 2013 at 06:53:55AM -0700, Boris Ostrovsky wrote: > > - jwbo...@redhat.com wrote: > > > On Wed, Mar 13, 2013 at 09:25:44AM -0400, Boris Ostrovsky wrote: > > > On 03/01/2013 07:14 AM, Josh Boyer wrote: > > > >On Thu, Feb 28, 2013 at 04:52:20PM -0800, H. Peter Anvin wrote: > > > >>On 02/28/2013 04:42 PM, Josh Boyer wrote: > > > >>>On Fri, Mar 01, 2013 at 01:36:29AM +0100, Borislav Petkov wrote: > > > On Thu, Feb 28, 2013 at 04:15:45PM -0800, H. Peter Anvin wrote: > > > >>I'll try to get someone to test this tomorrow. > > > Btw, you'd need to apply that other patch too > > > > > > http://marc.info/?l=xen-devel&m=136206183814547&w=2 > > > > > > so that arch_flush_lazy_mmu_mode() has at least one caller on > > x86_64. > > > >>>Yeah, we already have that applied. It stops crashes in xen > > > >>>environments so we pulled it in as a bugfix. Thanks though! > > > >>> > > > >>Who are "we"? > > > >Sorry, Fedora. That patch has a link to a bug in it. We applied > > the > > > >patch for that bug. I'll apply Boris' patch on top and get the > > same > > > >people to test it. > > > > > > Josh, have you had a chance to test this? > > > > I've tested it on bare metal for a while now. No problems noticed at > > all. I've not heard back from Krishna who was testing it in the Xen > > environment. Krishna? > > > Any updates? No. I've still not heard from Krishna. At this point I've tested it on bare metal quite a bit, and Konrad has tested it on both bare metal and Xen. That should already cover the case Krishna was going to test anyway. I suggest we move forward and take the patch. josh -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 12/48] signal: always clear sa_restorer on execve
On Wed, 2013-03-20 at 21:43 +0100, Sebastian Gottschall (DD-WRT) wrote:
> Am 20.03.2013 20:02, schrieb Sebastian Gottschall (DD-WRT):
> > Hello
> >
> > The patch for sa_restorer will break mips builds, since sa_restorer
> > isnt defined as field within the struct, but the MACRO is.
> > so use the __ARCH_HAS_SA_RESTORER way which is implemented in that way
> > in linux 3.9 or simply revert the patch
This also appears to break blackfin, ia64, parisc and tile.
I think for earlier 3.x.y series we can use one of the attached
(untested) patches to define __ARCH_HAS_SA_RESTORER appropriately, and
then apply the upstream change:
commit 522cff142d7d2f9230839c9e1f21a4d8bcc22a4a
Author: Andrew Morton
Date: Wed Mar 13 14:59:34 2013 -0700
kernel/signal.c: use __ARCH_HAS_SA_RESTORER instead of SA_RESTORER
Ben.
--
Ben Hutchings
It is easier to write an incorrect program than to understand a correct one.
From: Ben Hutchings
Date: Sun, 25 Nov 2012 22:24:19 -0500
Subject: signal: Fix use of missing sa_restorer field
flush_signal_handlers() needs to know whether sigaction::sa_restorer
is defined, not whether SA_RESTORER is defined. Define the
__ARCH_HAS_SA_RESTORER macro to indicate this.
Vaguely based on upstream commit 574c4866e33d 'consolidate kernel-side
struct sigaction declarations'.
Signed-off-by: Ben Hutchings
Cc: Al Viro
---
--- a/arch/arm/include/asm/signal.h
+++ b/arch/arm/include/asm/signal.h
@@ -127,6 +127,7 @@ struct sigaction {
__sigrestore_t sa_restorer;
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/avr32/include/asm/signal.h
+++ b/arch/avr32/include/asm/signal.h
@@ -128,6 +128,7 @@ struct sigaction {
__sigrestore_t sa_restorer;
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/cris/include/asm/signal.h
+++ b/arch/cris/include/asm/signal.h
@@ -122,6 +122,7 @@ struct sigaction {
void (*sa_restorer)(void);
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/h8300/include/asm/signal.h
+++ b/arch/h8300/include/asm/signal.h
@@ -121,6 +121,7 @@ struct sigaction {
void (*sa_restorer)(void);
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/m32r/include/asm/signal.h
+++ b/arch/m32r/include/asm/signal.h
@@ -123,6 +123,7 @@ struct sigaction {
__sigrestore_t sa_restorer;
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/m68k/include/asm/signal.h
+++ b/arch/m68k/include/asm/signal.h
@@ -119,6 +119,7 @@ struct sigaction {
__sigrestore_t sa_restorer;
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/mn10300/include/asm/signal.h
+++ b/arch/mn10300/include/asm/signal.h
@@ -131,6 +131,7 @@ struct sigaction {
__sigrestore_t sa_restorer;
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/powerpc/include/asm/signal.h
+++ b/arch/powerpc/include/asm/signal.h
@@ -109,6 +109,7 @@ struct sigaction {
__sigrestore_t sa_restorer;
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/s390/include/asm/signal.h
+++ b/arch/s390/include/asm/signal.h
@@ -131,6 +131,7 @@ struct sigaction {
void (*sa_restorer)(void);
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/arch/sparc/include/asm/signal.h
+++ b/arch/sparc/include/asm/signal.h
@@ -191,6 +191,7 @@ struct __old_sigaction {
unsigned long sa_flags;
void (*sa_restorer)(void); /* not used by Linux/SPARC yet */
};
+#define __ARCH_HAS_SA_RESTORER
typedef struct sigaltstack {
void __user *ss_sp;
--- a/arch/x86/include/asm/signal.h
+++ b/arch/x86/include/asm/signal.h
@@ -125,6 +125,8 @@ typedef unsigned long sigset_t;
extern void do_notify_resume(struct pt_regs *, void *, __u32);
# endif /* __KERNEL__ */
+#define __ARCH_HAS_SA_RESTORER
+
#ifdef __i386__
# ifdef __KERNEL__
struct old_sigaction {
--- a/arch/xtensa/include/asm/signal.h
+++ b/arch/xtensa/include/asm/signal.h
@@ -133,6 +133,7 @@ struct sigaction {
void (*sa_restorer)(void);
sigset_t sa_mask; /* mask last for extensibility */
};
+#define __ARCH_HAS_SA_RESTORER
struct k_sigaction {
struct sigaction sa;
--- a/include/asm-generic/signal.h
+++ b/include/asm-generic/signal.h
@@ -99,6 +99,10 @@ typedef unsigned long old_sigset_t;
#include
+#ifdef SA_RESTORER
+#de
Re: [stable request] TTY: do not reset master's packet mode
On Thu, 2013-03-14 at 12:01 +0100, Jiri Slaby wrote: > Hi, > > please include the patch below to all maintained stable trees. > > commit b81273a132177edd806476b953f6afeb17b786d5 > Author: Jiri Slaby > Date: Tue Jan 15 23:26:22 2013 +0100 > > TTY: do not reset master's packet mode Queued up for 3.2, thanks. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
[git pull] device-mapper fixes for 3.9
Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm tags/dm-3.9-fixes to get the following device-mapper fixes for 3.9. Thanks, Alasdair A set of device-mapper fixes for 3.9. Fix reported data loss with discards and thin snapshots; avoid a deadlock observed in dm verity; fix a race in the new dm cache code along with some other minor bugs; store the cache policy version on disk to make the stored hints format future-proof. Heinz Mauelshagen (2): dm cache: detect cache_create failure dm cache: avoid calling policy destructor twice on error Joe Thornber (5): dm thin: fix discard corruption dm thin: fix non power of two discard granularity calc dm cache: avoid 64 bit division on 32 bit dm cache: metadata clear dirty bits on clean shutdown dm cache: fix race in writethrough implementation Mike Snitzer (2): dm cache: policy change version from string to integer set dm cache: policy ignore hints if generated by different version Mikulas Patocka (1): dm verity: avoid deadlock drivers/md/dm-bufio.c|2 + drivers/md/dm-cache-metadata.c | 64 -- drivers/md/dm-cache-metadata.h |2 +- drivers/md/dm-cache-policy-cleaner.c |7 +- drivers/md/dm-cache-policy-internal.h|2 + drivers/md/dm-cache-policy-mq.c |8 +- drivers/md/dm-cache-policy.c |8 ++ drivers/md/dm-cache-policy.h |2 + drivers/md/dm-cache-target.c | 169 +- drivers/md/dm-thin.c | 11 +- drivers/md/dm-verity.c | 39 +- drivers/md/persistent-data/dm-btree-remove.c | 46 +++ 12 files changed, 252 insertions(+), 108 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] sysfs: fix race between readdir and lseek
On 2013/3/20 23:25, Ming Lei wrote: > While readdir() is running, lseek() may set filp->f_pos as zero, > then may leave filp->private_data pointing to one sysfs_dirent > object without holding its reference counter, so the sysfs_dirent > object may be used after free in next readdir(). > > This patch holds inode->i_mutex to avoid the problem since > the lock is always held in readdir path. > In fact the same race exists between readdir() and read()/write()... > Reported-by: Dave Jones > Tested-by: Sasha Levin > Cc: > Signed-off-by: Ming Lei > --- > fs/sysfs/dir.c | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3.0] perf,x86: fix kernel crash with PEBS/BTS after suspend/resume
On Fri, 2013-03-15 at 18:57 -0600, Shuah Khan wrote: > This patch fixes a kernel crash when using precise sampling (PEBS) > after a suspend/resume. Turns out the CPU notifier code is not invoked > on CPU0 (BP). Therefore, the DS_AREA (used by PEBS) is not restored properly > by the kernel and keeps it power-on/resume value of 0 causing any PEBS > measurement to crash when running on CPU0. > > The workaround is to add a hook in the actual resume code to restore > the DS Area MSR value. It is invoked for all CPUS. So for all but CPU0, > the DS_AREA will be restored twice but this is harmless. > > Upstream commit id: 1d9d8639c063caf6efc2447f5f26aa637f844ff6 > > Reported-by: Linus Torvalds > Signed-off-by: Stephane Eranian > Signed-off-by: Linus Torvalds > Signed-off-by: Shuah Khan > CC: stable@vger.kernel.org 3.0 [...] I've queued this up for 3.2 (though context was different again), along with the following fix-ups: commit 2a6e06b2aed6995af401dcd4feb5e79a0c7ea554 Author: Linus Torvalds Date: Sun Mar 17 15:44:43 2013 -0700 perf,x86: fix wrmsr_on_cpu() warning on suspend/resume commit 6c4d3bc99b3341067775efd4d9d13cc8e655fd7c Author: David Rientjes Date: Sun Mar 17 15:49:10 2013 -0700 perf,x86: fix link failure for non-Intel configs Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/2] sysfs: fix race between readdir and lseek
On Thu, Mar 21, 2013 at 10:41 AM, Li Zefan wrote: > > In fact the same race exists between readdir() and read()/write()... Fortunately, no read()/write() are implemented on sysfs directory, :-) Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHES] Networking fixes for -stable
On Mon, 2013-03-18 at 15:30 -0400, David Miller wrote: > Please apply the following networking bug fixes to 3.0.x, 3.2.x, > 3.4.x, and 3.8.x -stable, respectively. Queued up for 3.2, thanks. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Re: [ 16/40] Revert duplicated perf commit.
On Mon, 2013-03-18 at 14:10 -0700, Greg Kroah-Hartman wrote: > 3.0-stable review patch. If anyone has any objections, please let me know. > > -- > > This reverts commit 2431496fbdd142ccc83138d94f3f510a36ce9270 as it was > applied incorrectly twice. > > Thanks to Jiri for pointing this out. > > Signed-off-by: Greg Kroah-Hartman > Cc: Jiri Slaby > Cc: Andrew Vagin > Cc: Steven Rostedt 3.2.y had the same problem, so I'm making a similar revert there. Ben. > --- > tools/perf/util/trace-event-parse.c |2 -- > 1 file changed, 2 deletions(-) > > --- a/tools/perf/util/trace-event-parse.c > +++ b/tools/perf/util/trace-event-parse.c > @@ -1582,8 +1582,6 @@ process_symbols(struct event *event, str > field = malloc_or_die(sizeof(*field)); > > type = process_arg(event, field, &token); > - while (type == EVENT_OP) > - type = process_op(event, field, &token); > if (test_type_token(type, token, EVENT_DELIM, ",")) > goto out_free; > > > > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/2] sysfs: fix race between readdir and lseek
On 2013/3/21 11:17, Ming Lei wrote: > On Thu, Mar 21, 2013 at 10:41 AM, Li Zefan wrote: >> >> In fact the same race exists between readdir() and read()/write()... > > Fortunately, no read()/write() are implemented on sysfs directory, :-) > That's irrelevant... See my report: https://patchwork.kernel.org/patch/2160771/ -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[stable] tools: hv: Netlink source address validation allows DoS (CVE-2012-5532)
I believe this fix is needed on stable branches 3.2.y, 3.4.y and 3.5.7.z: commit 95a69adab9acfc3981c504737a2b6578e4d846ef Author: Tomas Hozza Date: Thu Nov 8 10:53:29 2012 +0100 tools: hv: Netlink source address validation allows DoS The source code without this patch caused hypervkvpd to exit when it processed a spoofed Netlink packet which has been sent from an untrusted local user. Now Netlink messages with a non-zero nl_pid source address are ignored and a warning is printed into the syslog. Signed-off-by: Tomas Hozza Acked-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
[stable] udf: avoid info leak on export (CVE-2012-6548)
This fix is needed on stable branches 3.0.y, 3.2.y, 3.4.y and 3.5.7.z: commit 0143fc5e9f6f5aad4764801015bc8d4b4a278200 Author: Mathias Krause Date: Thu Jul 12 08:46:55 2012 +0200 udf: avoid info leak on export For type 0x51 the udf.parent_partref member in struct fid gets copied uninitialized to userland. Fix this by initializing it to 0. Signed-off-by: Mathias Krause Signed-off-by: Jan Kara -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
[stable] isofs: avoid info leak on export (CVE-2012-6549)
This fix is needed on stable branches 3.0.y, 3.2.y, 3.4.y and 3.5.7.z: commit fe685aabf7c8c9f138e5ea900954d295bf229175 Author: Mathias Krause Date: Thu Jul 12 08:46:54 2012 +0200 isofs: avoid info leak on export For type 1 the parent_offset member in struct isofs_fid gets copied uninitialized to userland. Fix this by initializing it to 0. Signed-off-by: Mathias Krause Signed-off-by: Jan Kara Only 1 line of context matches in branches older than 3.5, but it still seems to be valid. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/2] sysfs: fix race between readdir and lseek
On Thu, Mar 21, 2013 at 11:28 AM, Li Zefan wrote: > On 2013/3/21 11:17, Ming Lei wrote: >> On Thu, Mar 21, 2013 at 10:41 AM, Li Zefan wrote: >>> >>> In fact the same race exists between readdir() and read()/write()... >> >> Fortunately, no read()/write() are implemented on sysfs directory, :-) >> > > That's irrelevant... As far as sysfs is concerned, the filp->f_ops can't be changed in read/write path. > > See my report: > > https://patchwork.kernel.org/patch/2160771/ Yes, I know there might be some mess after the commit ef3d0fd2 (vfs: do (nearly) lockless generic_file_llseek). Also looks it has been stated in Documentation/filesystems/Locking: ->llseek() locking has moved from llseek to the individual llseek implementations. If your fs is not using generic_file_llseek, you need to acquire and release the appropriate locks in your ->llseek(). For many filesystems, it is probably safe to acquire the inode mutex or just to use i_size_read() instead. Note: this does not protect the file->f_pos against concurrent modifications since this is something the userspace has to take care about. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ioat: remove chanerr mask setting for IOAT v3.x
On Wed, Nov 28, 2012 at 03:46:08AM +0530, Jiang, Dave wrote:
> The existing code set a value in the PCI_CHANERRMSK_INT register
> for a workaround to address a pre-silicon bug on the Intel 5520 IO hub that
> has been fixed when the hardware was released. There is no need for this
> code.
>
> Signed-off-by: Dave Jiang
> ---
>
> drivers/dma/ioat/dma_v3.c |7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/dma/ioat/dma_v3.c b/drivers/dma/ioat/dma_v3.c
> index f7f1dc6..fda3b8a1 100644
> --- a/drivers/dma/ioat/dma_v3.c
> +++ b/drivers/dma/ioat/dma_v3.c
> @@ -1126,12 +1126,7 @@ static int ioat3_reset_hw(struct ioat_chan_common
> *chan)
> chanerr = readl(chan->reg_base + IOAT_CHANERR_OFFSET);
> writel(chanerr, chan->reg_base + IOAT_CHANERR_OFFSET);
>
> - /* -= IOAT ver.3 workarounds =- */
> - /* Write CHANERRMSK_INT with 3E07h to mask out the errors
> - * that can cause stability issues for IOAT ver.3, and clear any
> - * pending errors
> - */
What is this code based against? i dont have above lines in -rc1 or my next?
> - pci_write_config_dword(pdev, IOAT_PCI_CHANERRMASK_INT_OFFSET, 0x3e07);
> + /* clear any pending errors */
> err = pci_read_config_dword(pdev, IOAT_PCI_CHANERR_INT_OFFSET,
> &chanerr);
> if (err) {
> dev_err(&pdev->dev, "channel error register unreachable\n");
>
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[stable] key: Fix resource leak
This fix is needed in stable branches 3.0.y, 3.2.y, 3.4.y and 3.5.7.z: commit a84a921978b7d56e0e4b87ffaca6367429b4d8ff Author: Alan Cox Date: Fri Sep 28 12:20:02 2012 +0100 key: Fix resource leak On an error iov may still have been reallocated and need freeing Signed-off-by: Alan Cox Signed-off-by: David Howells The corresponding fix to the compat function was included in commit 8aec0f5d4137532de14e6554fd5dd201ff3a3c49 which also belongs in all of those branches, but is currently missing in 3.0.y (needs backporting?) and 3.5.7.z. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
