BTW, the right way to handle lock balancing is to handle the unlocking
at the same level where you do the locking. So I guess you're looking
for the following patch instead, which is really not very useful because
(as Li noted) the lock is freed immediately afterward anyway:
Yeah, I do
Hi,
This commit was reported to cause performance regressions in
http://article.gmane.org/gmane.linux.kernel/1642948
Is it really appropriate for -stable at this stage?
Thanks,
-r
dirk.brande...@gmail.com writes:
From: Dirk Brandewie dirk.j.brande...@intel.com
Take non-idle time into
On 02/16/2014 03:59 PM, Daniel Borkmann wrote:
From: Vlastimil Babka vba...@suse.cz
[ 4366.519657] [ cut here ]
[ 4366.519709] kernel BUG at mm/mlock.c:528!
[ 4366.519742] invalid opcode: [#1] SMP
[ 4366.519782] Modules linked in: ccm arc4 iwldvm [...]
[
On Thu, Feb 13, 2014 at 11:49:28AM -0500, Mikulas Patocka wrote:
On Mon, 10 Feb 2014, Greg KH wrote:
On Mon, Feb 10, 2014 at 03:02:24PM -0500, Mikulas Patocka wrote:
On Sat, 8 Feb 2014, gre...@linuxfoundation.org wrote:
The patch below does not apply to the 3.13-stable
Hi
On Tuesday 18 February 2014, Greg Kroah-Hartman wrote:
3.13-stable review patch. If anyone has any objections, please let me know.
--
From: Dirk Brandewie dirk.j.brande...@intel.com
commit fcb6a15c2e7e76d493e6f91ea889ab40e1c643a4 upstream.
Take non-idle time into
This is a note to let you know that I've just added the patch titled
mei: set client's read_cb to NULL when flow control fails
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-next branch.
The patch will
On 02/19/2014 04:52 AM, Stefan Lippers-Hollmann wrote:
Hi
On Tuesday 18 February 2014, Greg Kroah-Hartman wrote:
3.13-stable review patch. If anyone has any objections, please let me know.
--
From: Dirk Brandewie dirk.j.brande...@intel.com
commit
On Wed, 19 Feb 2014 08:41:46 -0800, Dirk Brandewie wrote:
On 02/19/2014 04:52 AM, Stefan Lippers-Hollmann wrote:
Hi
On Tuesday 18 February 2014, Greg Kroah-Hartman wrote:
3.13-stable review patch. If anyone has any objections, please let me know.
--
From: Dirk Brandewie
From: Dirk Brandewie dirk.j.brande...@intel.com
Take non-idle time into account when calculating core busy time.
This ensures that intel_pstate will notice a decrease in load.
backport of commit: fcb6a15c2e7e76d493e6f91ea889ab40e1c643a4
Applies to v3.10.30, v3.12.11, v3.13.3
References:
On Tue, Feb 04, 2014 at 12:29:12PM +, Will Deacon wrote:
Linux requires a number of atomic operations to provide full barrier
semantics, that is no memory accesses after the operation can be
observed before any accesses up to and including the operation in
program order.
On arm64, these
Don't initialize force-feedback for devices that don't support it to avoid calls
to schedule_work() with an uninitialized work_struct.
Move the cancel_work_sync() call out of sony_destroy_ff() since the state worker
is used for the LEDs even when force-feedback is disabled.
Remove
On Wed, Feb 19, 2014 at 01:09:22PM -0500, Frank Praznik wrote:
Don't initialize force-feedback for devices that don't support it to avoid
calls
to schedule_work() with an uninitialized work_struct.
Move the cancel_work_sync() call out of sony_destroy_ff() since the state
worker
is used
Added the functions task_ppid_nr_ns() and task_ppid_nr() to abstract the lookup
of the PPID (real_parent's pid_t) of a process, including rcu locking, in the
arbitrary and init_pid_ns.
This provides an alternative to sys_getppid(), which is relative to the child
process' pid namespace.
(informed
sys_getppid() returns the parent pid of the current process in its own pid
namespace. Since audit filters are based in the init pid namespace, a process
could avoid a filter or trigger an unintended one by being in an alternate pid
namespace or log meaningless information.
Switch to
Hi
On Wednesday 19 February 2014, dirk.brande...@gmail.com wrote:
From: Dirk Brandewie dirk.j.brande...@intel.com
Take non-idle time into account when calculating core busy time.
This ensures that intel_pstate will notice a decrease in load.
backport of commit:
On Wed, Feb 19, 2014 at 10:37:26PM +, Stefan Lippers-Hollmann wrote:
Hi
On Wednesday 19 February 2014, dirk.brande...@gmail.com wrote:
From: Dirk Brandewie dirk.j.brande...@intel.com
Take non-idle time into account when calculating core busy time.
This ensures that intel_pstate
On 02/18/2014 03:46 PM, Greg Kroah-Hartman wrote:
Many thanks to Li Zefan for digging up a bunch of these patches, that
work is much appreciated.
This is the start of the stable review cycle for the 3.4.81 release.
There are 24 patches in this series, all will be posted as a response
to this
On 02/18/2014 03:47 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.12.12 release.
There are 32 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
Hello, Lai.
On Wed, Feb 19, 2014 at 11:39:42AM +0800, Lai Jiangshan wrote:
CC: stable@vger.kernel.org
I think no one hit this bug. So I add this stable TAG?
(Jason's bug-report drives me to review the workqueue harder,
and I found this possible bug, but I think it is irrespective
with
On 02/18/2014 03:47 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.13.4 release.
There are 40 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On 02/18/2014 03:46 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.10.31 release.
There are 26 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
Hi Oleksij,
On Monday 17 February 2014 10:40:35 Oleksij Rempel wrote:
Am 17.02.2014 10:28, schrieb Laurent Pinchart:
On Monday 17 February 2014 10:05:41 Oleksij Rempel wrote:
Am 17.02.2014 01:26, schrieb Laurent Pinchart:
On Sunday 16 February 2014 10:59:32 Oleksij Rempel wrote:
[snip]
On Wed, Feb 19, 2014 at 05:16:22PM -0700, Shuah Khan wrote:
On Intel systems, there are no dmesg regressions: emerg, crit,
alert, err are clean. No regressions in warn.
On AMD systems, the following new error messages - suspect is to
drivers/regulator/core.c - patch
3.13.4 - amd:
On 02/19/2014 05:36 PM, Mark Brown wrote:
On Wed, Feb 19, 2014 at 05:16:22PM -0700, Shuah Khan wrote:
On Intel systems, there are no dmesg regressions: emerg, crit,
alert, err are clean. No regressions in warn.
On AMD systems, the following new error messages - suspect is to
Hi
On Wednesday 19 February 2014, Greg KH wrote:
On Wed, Feb 19, 2014 at 10:37:26PM +, Stefan Lippers-Hollmann wrote:
Hi
On Wednesday 19 February 2014, dirk.brande...@gmail.com wrote:
From: Dirk Brandewie dirk.j.brande...@intel.com
Take non-idle time into account when
On Wed, Feb 19, 2014 at 06:20:13PM -0700, Shuah Khan wrote:
Right. I think this message should be a warning instead of an error.
Error is too alarming, unless there is a good reason for it to be an
error.
Patches welcome...
signature.asc
Description: Digital signature
The front headphone and mic jackes on a HP desktop model (Vendor Id:
0x111d76c7 Subsystem Id: 0x103c2b17) can not work, the codec on this
machine has 8 physical ports, 6 of them are routed to rear jackes
and all of them work very well, while the remaining 2 ports are
routed to front headphone and
There is a race between the Tx path and the STA wake up
flow.
If a station is asleep, mac80211 buffers frames, but up to
a certain limit. When this limit is reached, mac80211 begins
to drop the oldest buffered frames. This is done in the Tx
path.
When a station wakes up, mac80211 will go over the
On Thu, 2014-02-20 at 08:18 +0200, Emmanuel Grumbach wrote:
There is a race between the Tx path and the STA wake up
flow.
If a station is asleep, mac80211 buffers frames, but up to
a certain limit. When this limit is reached, mac80211 begins
to drop the oldest buffered frames. This is done in
Since commit 77873803363c net_dma: mark broken we no longer pin dma
engines active for the network-receive-offload use case. As a result
the -free_chan_resources() that occurs after the driver self-test no
longer has a NET_DMA induced -alloc_chan_resources() to back it up. A
late firing irq can
At Thu, 20 Feb 2014 11:47:21 +0800,
Hui Wang wrote:
The front headphone and mic jackes on a HP desktop model (Vendor Id:
0x111d76c7 Subsystem Id: 0x103c2b17) can not work, the codec on this
machine has 8 physical ports, 6 of them are routed to rear jackes
and all of them work very well,
There is a race between the Tx path and the STA wake up
flow.
If a station is asleep, mac80211 buffers frames. When the
station wakes up, mac80211 will go over the buffered frames
list and send them.
Since these two flows can run concurrently, we can get to a
situation where the buffered frame
Am 20.02.2014 01:36, schrieb Laurent Pinchart:
Hi Oleksij,
On Monday 17 February 2014 10:40:35 Oleksij Rempel wrote:
Am 17.02.2014 10:28, schrieb Laurent Pinchart:
On Monday 17 February 2014 10:05:41 Oleksij Rempel wrote:
Am 17.02.2014 01:26, schrieb Laurent Pinchart:
On Sunday 16 February
On 2014/2/20 8:29, Shuah Khan wrote:
On 02/18/2014 03:46 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.10.31 release.
There are 26 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied,
On 02/20/2014 03:17 PM, Takashi Iwai wrote:
At Thu, 20 Feb 2014 11:47:21 +0800,
Hui Wang wrote:
The front headphone and mic jackes on a HP desktop model (Vendor Id:
0x111d76c7 Subsystem Id: 0x103c2b17) can not work, the codec on this
machine has 8 physical ports, 6 of them are routed to rear
35 matches
Mail list logo
