I am announcing the release of the Linux 3.16.7-ckt2 kernel.
The updated 3.16.y-ckt tree can be found at:
git://kernel.ubuntu.com/ubuntu/linux.git linux-3.16.y
and can be browsed at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.16.y;a=shortlog
The diff from
On 12/1/14, Markos Chandras markos.chand...@imgtec.com wrote:
On 12/01/2014 09:57 AM, Denis Kirjanov wrote:
Remove optimize_div() from BPF_MOD | BPF_K case
since we don't know the dividend and fix the
emit_mod() by reading the mod operation result from HI register
Signed-off-by: Denis
On Sun, Nov 16, 2014 at 10:53:50PM +0100, Willy Tarreau wrote:
2.6.32-longterm review patch. If anyone has any objections, please let me
know.
--
From: Andrey Ryabinin ryabinin@gmail.com
[ Upstream commit 40eea803c6b2cfaab092f053248cbeab3f368412 ]
Sasha's
Hi Luis,
On Mon, Dec 01, 2014 at 11:45:22AM +, Luis Henriques wrote:
diff --git a/net/compat.c b/net/compat.c
index e9672c8..71ed839 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -83,7 +83,7 @@ int verify_compat_iovec(struct msghdr *kern_msg, struct
iovec *kern_iov,
{
The end timer is used for switching back from repeat code timings when
no repeat codes have been received for a certain amount of time. When
the protocol is changed, the end timer is deleted synchronously with
del_timer_sync(), however this takes place while holding the main spin
lock, and the
When the img-ir driver is asked to change protocol, if the chosen
decoder is already loaded then don't call img_ir_set_decoder(), so as
not to clear the current filter.
This is important because store_protocol() does not refresh the scancode
filter with the new protocol if the set of enabled
Otherwise we'll have backtraces in assert_panel_unlocked because the
BIOS locks the register. In the reporter's case this regression was
introduced in
commit c31407a3672aaebb4acddf90944a114fa5c8af7b
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Thu Oct 18 21:07:01 2012 +0100
Moritz asked that this mainline patch be applied to 3.13-stable:
92a5655 nfs: Don't busy-wait on SIGKILL in __nfs_iocounter_wait
Looks like 3.14-stable and 3.16-stable need it too. (3.12 already
carries it). My context backport (posted as a follow-up to this)
applies to 3.14 and 3.16.
From: David Jeffery djeff...@redhat.com
commit 92a56555bd576c61b27a5cab9f38a33a1e9a1df5 upstream.
If a SIGKILL is sent to a task waiting in __nfs_iocounter_wait,
it will busy-wait or soft lockup in its while loop.
nfs_wait_bit_killable won't sleep, and the loop won't exit on
the error return.
On Mon, Dec 1, 2014 at 5:56 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Alexey, please test this patch.
Ok, I will.
--
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
l...@kernel.org [l...@kernel.org] wrote:
| From: Cong Wang cw...@twopensource.com
|
| 3.4.105-rc1 review patch. If anyone has any objections, please let me know.
|
snip
|
| diff --git a/kernel/events/core.c b/kernel/events/core.c
| index 685ce46..c958be1 100644
| --- a/kernel/events/core.c
|
Paravirtual guests are not expected to load microcode into processors
and therefore it is not necessary to initialize microcode loading
logic.
In fact, under certain circumstances initializing this logic may cause
the guest to crash. Specifically, 32-bit kernels use __pa_nodebug()
macro which
The patch titled
Subject: mm: fix swapoff hang after page migration and fork
has been added to the -mm tree. Its filename is
mm-fix-swapoff-hang-after-page-migration-and-fork.patch
This patch should soon appear at
On Mon, Dec 01, 2014 at 04:27:44PM -0500, Boris Ostrovsky wrote:
Paravirtual guests are not expected to load microcode into processors
and therefore it is not necessary to initialize microcode loading
logic.
In fact, under certain circumstances initializing this logic may cause
the guest to
On Mon, Dec 01, 2014 at 04:27:44PM -0500, Boris Ostrovsky wrote:
Paravirtual guests are not expected to load microcode into processors
and therefore it is not necessary to initialize microcode loading
logic.
CC-ing the KVM folks since they use the paravirt interface too.
In fact, under
On 01/12/2014 22:57, Konrad Rzeszutek Wilk wrote:
On Mon, Dec 01, 2014 at 04:27:44PM -0500, Boris Ostrovsky wrote:
Paravirtual guests are not expected to load microcode into processors
and therefore it is not necessary to initialize microcode loading
logic.
CC-ing the KVM folks since they
On 12/01/2014 05:00 PM, Borislav Petkov wrote:
On Mon, Dec 01, 2014 at 04:27:44PM -0500, Boris Ostrovsky wrote:
Paravirtual guests are not expected to load microcode into processors
and therefore it is not necessary to initialize microcode loading
logic.
In fact, under certain circumstances
On Mon, Dec 01, 2014 at 11:12:38PM +0100, Paolo Bonzini wrote:
We also do not want to load microcode. :) Thanks for the heads-up.
You don't need to :P
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line
On Mon, Dec 01, 2014 at 05:31:56PM -0500, Boris Ostrovsky wrote:
I think so. The problem we have now is __pa() macro that we only use
on 32-bit. I'll queue this for overnight tests to make sure and if it
indeed works then 3.19 should be fine.
Cool, thanks.
I'd still take your patch for 3.19
The patch titled
Subject: exit: pidns: alloc_pid() leaks pid_namespace if child_reaper is
exiting
has been added to the -mm tree. Its filename is
exit-pidns-alloc_pid-leaks-pid_namespace-if-child_reaper-is-exiting.patch
This patch should soon appear at
| diff --git a/kernel/events/core.c b/kernel/events/core.c
| index 685ce46..c958be1 100644
| --- a/kernel/events/core.c
| +++ b/kernel/events/core.c
| @@ -1702,6 +1702,16 @@ retry:
| */
| if (ctx-is_active) {
| raw_spin_unlock_irq(ctx-lock);
| + /*
| +
On Mon, Dec 01, 2014 at 04:27:44PM -0500, Boris Ostrovsky wrote:
Paravirtual guests are not expected to load microcode into processors
and therefore it is not necessary to initialize microcode loading
logic.
In fact, under certain circumstances initializing this logic may cause
the guest to
Greg, could you release 3.4.105 for me, please?
Thanks.
===
The following changes since commit bb4a05a0400ed6d2f1e13d1f82f289ff74300a70:
Linux 3.4.104 (2014-09-25 11:49:19 +0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lizf/linux-3.4.y.git
On Mon, Dec 01, 2014 at 07:49:56PM +0200, Sagi Grimberg wrote:
ISER_CONN_UP state is not sufficient to know if
we should wait for completion of flush errors and
disconnected_handler event.
Instead, split it to 2 states:
- ISER_CONN_UP: Got to CM connected phase, This state
indicates that
On Tue, Dec 02, 2014 at 09:27:19AM +0800, Zefan Li wrote:
Greg, could you release 3.4.105 for me, please?
Thanks.
===
The following changes since commit bb4a05a0400ed6d2f1e13d1f82f289ff74300a70:
Linux 3.4.104 (2014-09-25 11:49:19 +0800)
are available in the git repository at:
I'm announcing the release of the 3.4.105 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:
From: Nicholas Bellinger n...@linux-iscsi.org
commit 0d0f660d882c1c02748ced13966a2413aa5d6cc2 upstream.
This patch explicitly disables TX completion interrupt coalescing logic
in isert_put_response() and isert_put_datain() that was originally added
as an efficiency optimization in commit
From: Nicholas Bellinger n...@linux-iscsi.org
Hi Greg-KH,
Here are two upstream bugfixes that where missing from v3.14.y.
Thank you,
--nab
Nicholas Bellinger (1):
iser-target: Disable TX completion interrupt coalescing
Sagi Grimberg (1):
Target/iser: Fix a wrong dereference in case
From: Sagi Grimberg sa...@mellanox.com
commit e0546fc1ba66c90cb38a5764357366267d3e58e4 upstream.
In case the discovery session is carried over iser, we can't
access the assumed network portal since the default portal is
used. In this case we don't really need to allocate the fastreg
pool, just
This can happen and there is no point in added more
detection code lower in the stack. Catching these in one
single point (cfg80211) is enough. Stop WARNING about this
case.
This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=89001
Cc: stable@vger.kernel.org
Fixes: 2f1c6c572d7b (cfg80211:
30 matches
Mail list logo
