On Mon, Feb 10, 2014 at 10:59:54PM +0200, Ivan T. Ivanov wrote:
> On Mon, 2014-02-10 at 12:29 -0800, Courtney Cavin wrote:
> > A developer doesn't have to have much skill at all to copy-paste DT
> > configurations around and muck with numbers I agree with Andy here,
> > early validation is a
On Mon, 10 Feb 2014, Michal Hocko wrote:
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 19d5d4274e22..55e6731ebcd5 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1687,7 +1687,7 @@ void mem_cgroup_print_oom_info(struct mem_cgroup
> *memcg, struct task_struct *p)
>*
"Serge E. Hallyn" writes:
> Hi Eric,
>
> most filesystems cannot be mounted in a non-init user namespace because we
> don't trust the superblock parsers to DTRT when handed garbage.
Correct, and mostly this is plain conservatism and not a real
limitation. As most distro's and thus most users
On Mon, Feb 10, 2014 at 11:18 AM, Mark Rutland wrote:
> On Fri, Feb 07, 2014 at 07:48:49PM +, Marek Belisko wrote:
>> Signed-off-by: NeilBrown
>> Signed-off-by: Marek Belisko
>> ---
>> Based on Neil's patch and extend for documentation and bindings include.
>>
>>
On Sun, Feb 9, 2014 at 6:25 AM, Paul Bolle wrote:
> On Sun, 2014-02-09 at 13:15 +, Steven Newbury wrote:
>> PCI resource allocation is undergoing some changes at the moment, it's
>> definitely a bug if the Flush Page isn't getting allocated. I'm looking
>> forward to hopefully getting
On Mon, 2014-02-10 at 14:52 -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Feb 06, 2014 at 02:13:15PM +, Ben Hutchings escreveu:
> > On Thu, 2014-02-06 at 10:48 -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Feb 06, 2014 at 12:59:21AM +, Ben Hutchings escreveu:
> > > > perf no
On Mon, Feb 10, 2014 at 01:15:59PM -0800, Jason Low wrote:
> On Mon, 2014-02-10 at 20:58 +0100, Peter Zijlstra wrote:
> > +void osq_unlock(struct optimistic_spin_queue **lock)
> > +{
> > + struct optimistic_spin_queue *node = this_cpu_ptr(_node);
> > + struct optimistic_spin_queue *next;
> > +
On Mon, Feb 10, 2014 at 12:28:55PM -0500, Don Zickus wrote:
> The data output is verbose and there are lots of data tables that interprit
> the latencies
> and data addresses in different ways to help see where bottlenecks might be
> lying.
Would be good to see what the output looks like.
What
On Thu, 30 Jan 2014, Dave Jones wrote:
> I gave Vince's perf_fuzzer a run, hoping to trigger a different perf bug
> that I've been seeing. Instead I hit a different bug.
I've been seeing that WARN_ON for months but it was hard to reproduce.
After a lot of hassle (and scores or reboots) I managed
Signed-off-by: Paul Bolle
---
0) This typo was introduced in commit 0d47acc4ffaa ("ASoC: smdk_wm8994:
Make driver name more unique").
1) So currently there's a difference between platform_drive.driver.name
and the (sub)string used in MODULE_ALIAS(). If I'd understand the
platform_driver
On Mon, Feb 10, 2014 at 12:28:55PM -0500, Don Zickus wrote:
> With the introduction of NUMA systems, came the possibility of remote memory
> accesses.
> Combine those remote memory accesses with contention on the remote node (ie a
> modified
> cacheline) and you have a possibility for very long
On Mon, 2014-02-10 at 20:58 +0100, Peter Zijlstra wrote:
> +void osq_unlock(struct optimistic_spin_queue **lock)
> +{
> + struct optimistic_spin_queue *node = this_cpu_ptr(_node);
> + struct optimistic_spin_queue *next;
> +
> + /*
> + * Fast path for the uncontended case.
> +
Hello Eric,
> Hmm.. I was not aware of high RTT for some packets.
> Can you spot this on the pcap you provided ?
with the latest patch as in:
(node-62) [~/work/linux-2.6] git diff | pbot
http://pbot.rmdir.de/CQwqI6b7wJProw_xaukmEg
with net.ipv4.tcp_min_tso_segs=2 we had this pcap:
On Mon, Feb 10, 2014 at 04:08:11PM -0500, Chris Metcalf wrote:
> (+LKML again)
>
> On 2/10/2014 3:57 PM, Peter Zijlstra wrote:
> > On Mon, Feb 10, 2014 at 03:50:04PM -0500, Chris Metcalf wrote:
> >> On 2/6/2014 8:52 AM, Peter Zijlstra wrote:
> >>> Its been compiled on everything I have a compiler
Hello Eric,
> Also please make sure you have this patch :
> http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=4a5ab4e224288403b0b4b6b8c4d339323150c312
I did not have this patch. I apply it, rerun and send you the pcap.
(node-62) [~/work/linux-2.6] wcat
> -Original Message-
> From: Andrew Morton [mailto:a...@linux-foundation.org]
> Sent: Tuesday, February 11, 2014 5:51 AM
> To: Johannes Weiner
> Cc: Rik van Riel; Dave Hansen; Michal Hocko; Motohiro Kosaki JP; KAMEZAWA
> Hiroyuki; linux...@kvack.org; linux-kernel@vger.kernel.org
>
On Mon, 2014-02-10 at 13:01 -0800, Eric Dumazet wrote:
> On Mon, 2014-02-10 at 21:56 +0100, Thomas Glanzmann wrote:
> > Hello Nab,
> >
> > > This looks correct to me. Thomas, once your able to confirm please
> > > include your 'Tested-by' and I'll include for the next -rc3 PULL
> > > request.
>
(+LKML again)
On 2/10/2014 3:57 PM, Peter Zijlstra wrote:
> On Mon, Feb 10, 2014 at 03:50:04PM -0500, Chris Metcalf wrote:
>> On 2/6/2014 8:52 AM, Peter Zijlstra wrote:
>>> Its been compiled on everything I have a compiler for, however frv and
>>> tile are missing because they're special and I
On Tue, 4 February 2014 12:39:28 -0800, H. Peter Anvin wrote:
>
> USB and the Ethernet PHY frequently do still have their own crystals,
> for reasons not entirely clear to me. However, what all of these have
> in common is that they are way out in the periphery.
Storage might be another source.
Em Thu, Feb 06, 2014 at 10:48:19AM -0700, David Ahern escreveu:
> On 2/6/14, 8:24 AM, Stephane Eranian wrote:
> >On Thu, Feb 6, 2014 at 3:09 PM, Arnaldo Carvalho de Melo
> > wrote:
> >>Em Thu, Feb 06, 2014 at 12:07:05PM -0200, Arnaldo Carvalho de Melo escreveu:
> >>>Em Thu, Feb 06, 2014 at
On Mon, Feb 10, 2014 at 08:58:22PM +0100, Peter Zijlstra wrote:
Bah, I forgot Quilt eats the From: headers and I forgot to re-add them.
They're still present in the queue, just lost in mailing :/
> The mutex_can_spin_on_owner() function should also return false if the
> task needs to be
On Mon, 2014-02-10 at 21:56 +0100, Thomas Glanzmann wrote:
> Hello Nab,
>
> > This looks correct to me. Thomas, once your able to confirm please
> > include your 'Tested-by' and I'll include for the next -rc3 PULL
> > request.
>
> Eric is currently reviewing our latest iteration with MSG_MORE
Hi,
On Mon, 2014-02-10 at 12:29 -0800, Courtney Cavin wrote:
> On Mon, Feb 10, 2014 at 08:41:44PM +0100, Ivan T. Ivanov wrote:
> >
> > Hi,
> >
> > On Mon, 2014-02-10 at 11:47 -0600, Andy Gross wrote:
> > > On Mon, Feb 10, 2014 at 06:55:02PM +0200, Ivan T. Ivanov wrote:
> > >
> > > []
> >
Hello Nab,
> This looks correct to me. Thomas, once your able to confirm please
> include your 'Tested-by' and I'll include for the next -rc3 PULL
> request.
Eric is currently reviewing our latest iteration with MSG_MORE for
kernel_sendmsg and MSG_MORE | MSG_SENDPAGE_NOTLAST for sendpage.
On Fri, 2014-02-07 at 15:49 +0200, Tomi Valkeinen wrote:
> On 07/02/14 12:12, Christoph Fritz wrote:
>
> > Yes, your patch fixes the issues for sys_clkout2. Thanks! If you want,
> > you can add my:
> > Tested-by: Christoph Fritz
> >
> > Below is my clock fix for dss:
> >
> > From
On Fri, 7 Feb 2014 16:26:01 -0500 Johannes Weiner wrote:
> On Fri, Feb 07, 2014 at 12:31:29PM -0800, Andrew Morton wrote:
> > On Fri, 7 Feb 2014 13:13:32 -0500 Johannes Weiner
> > wrote:
> >
> > > @@ -63,6 +64,9 @@ int drop_caches_sysctl_handler(ctl_table *table, int
> > > write,
> > >
There are least three choices for what the "current frequency" is:
1. The frequency that the cpufreq driver thinks it has requested.
This shows up in scaling_cur_freq.
2. The frequency that is actually programmed into the CPU. This is
what acpi_cpufreq's cpuinfo_cur_freq reports.
3. A
On Mon, Feb 10, 2014 at 1:59 PM, Courtney Cavin
wrote:
> On Mon, Feb 10, 2014 at 08:09:34PM +0100, Josh Cartwright wrote:
>> On Mon, Feb 10, 2014 at 11:52:05AM -0600, Rob Herring wrote:
>> > On Mon, Feb 10, 2014 at 8:11 AM, Arnd Bergmann wrote:
>> > > On Friday 07 February 2014 16:50:14 Courtney
The mutex->spin_mlock was introduced in order to ensure that only 1 thread
spins for lock acquisition at a time to reduce cache line contention. When
lock->owner is NULL and the lock->count is still not 1, the spinner(s) will
continually release and obtain the lock->spin_mlock. This can generate
The mutex_can_spin_on_owner() function should also return false if the
task needs to be rescheduled to avoid entering the MCS queue when it
needs to reschedule.
Cc: chegu_vi...@hp.com
Cc: paul...@linux.vnet.ibm.com
Cc: waiman.l...@hp.com
Cc: torva...@linux-foundation.org
Cc: t...@linutronix.de
The mcs_spinlock code is not meant (or suitable) as a generic locking
primitive, therefore take it away from the normal includes and place
it in kernel/locking/.
This way the locking primitives implemented there can use it as part
of their implementation but we do not risk it getting used
When running workloads that have high contention in mutexes on an 8 socket
machine, mutex spinners would often spin for a long time with no lock owner.
The main reason why this is occuring is in __mutex_unlock_common_slowpath(),
if __mutex_slowpath_needs_to_unlock(), then the owner needs to
Add in an extra reschedule in an attempt to avoid getting reschedule
the moment we've acquired the lock.
Signed-off-by: Peter Zijlstra
---
kernel/locking/mutex.c |7 +++
1 file changed, 7 insertions(+)
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -468,6 +468,13 @@
This rwlock uses the arch_spin_lock_t as a waitqueue, and assuming the
arch_spin_lock_t is a fair lock (ticket,mcs etc..) the resulting
rwlock is a fair lock.
It fits in the same 8 bytes as the regular rwlock_t by folding the
reader and writer count into a single integer, using the remaining 4
Make x86 use the fair rwlock_t.
Implement the custom queue_write_unlock() for best performance.
Signed-off-by: Waiman Long
[peterz: near complete rewrite]
Signed-off-by: Peter Zijlstra
---
arch/x86/Kconfig |1 +
arch/x86/include/asm/qrwlock.h| 18
Hi all,
I would propose merging the following patches...
The first set is mostly from Jason and tweaks the mutex adaptive
spinning, AIM7 throughput numbers:
PRE: 100 2000.04 21564.90 2721.29 311.99 3.12 0.01 0.00 99
POST: 100 2000.04 42603.85 5142.80 311.99 3.12
Since we want a task waiting for a mutex_lock() to go to sleep and
reschedule on need_resched() we must be able to abort the
mcs_spin_lock() around the adaptive spin.
Therefore implement a cancelable mcs lock.
Cc: r...@redhat.com
Cc: a...@linux-foundation.org
Cc: davidl...@hp.com
Cc:
On Sat 08-02-14 17:18:37, Frederic Weisbecker wrote:
> Move this function closer to __smp_call_function_single(). These functions
> have very similar behavior and should be displayed in the same block
> for clarity.
Whatever :). You can add:
Reviewed-by: Jan Kara
From: Ivan Khoronzhuk
The address for control regs in clkvcp3 node is not correct and should
be 0x023500a8 instead of 0x0235000a8.
This lead to few unexpected behaviors while clocks were turned
of in absence of clk_ignore_unused
Mike Turquette
Signed-off-by: Ivan Khoronzhuk
Signed-off-by:
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Jack Pham
commit 9005355af23856c55a5538c9024355785424821b upstream.
If CONFIG_PCI is enabled, make sure xhci_cleanup_msix()
doesn't try to free a bogus PCI IRQ or dereference an
cgroup_transfer_tasks() can currently fail in the middle due to memory
allocation failure. When that happens, the function just aborts and
returns error code and there's no way to tell how many actually got
migrated at the point of failure and or to revert the partial
migration.
Update it to use
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Sebastian Andrzej Siewior
commit d6a484520c5572a4170fa915109ccfc0c38f5008 upstream.
In commit 85747f ("PATCH] parport: add NetMOS 9805 support") Max added
the PCI ID for NetMOS 9805
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Yegor Yefremov
commit 48c0247d7b7bf58abb85a39021099529df365c4d upstream.
Signed-off-by: Yegor Yefremov
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
---
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Malcolm Priestley
commit 8f248dae133668bfb8e9379b4b3f0571c858b24a upstream.
byBBPreEDIndex value is initially 0, this means that from
cold BBvUpdatePreEDThreshold is never set.
This
On Sat 08-02-14 17:18:31, Frederic Weisbecker wrote:
> rq_fifo_clear() reset the csd.list through INIT_LIST_HEAD for no clear
> purpose. The csd.list doesn't need to be initialized as a list head
> because it's only ever used as a list node.
>
> Lets remove this useless initialization.
>
> Cc:
> -Original Message-
> From: Haiyang Zhang [mailto:haiya...@microsoft.com]
> Sent: Monday, January 13, 2014 7:21 PM
> To: florianschandi...@gmx.de; a...@linux-foundation.org; linux-
> fb...@vger.kernel.org
> Cc: Haiyang Zhang; KY Srinivasan; o...@aepfle.de; jasow...@redhat.com;
>
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Cong Ding
commit a046b816a4587c7898772af7cc7e6798cc8b56dd upstream.
the variable inti should be freed in the branch CPUSTAT_STOPPED.
Signed-off-by: Cong Ding
Signed-off-by: Cornelia
On Monday 10 February 2014, Randy Dunlap wrote:
>On 02/09/2014 08:32 PM, Gene Heskett wrote:
>AUTOSELECT driver feature Better! ugh.
Spit. I presume geneology discussions are off topic. :)
>
>Good luck. Let me know if you need more guidance.
Hat in hand, I figured I had better get the first
From: Ivan Khoronzhuk
The clk_init_data struct is allocated in the stack. All members of
this struct should be initialized before using otherwise it will
lead to unpredictable situation as it can contain garbage.
Ultimately the clk->flag field contains garbage. In my case it leads
that flag
On Sat 08-02-14 17:18:36, Frederic Weisbecker wrote:
> __smp_call_function_single() and smp_call_function_single() share some
> code that can be factorized: execute inline when the target is local,
> check if the target is online, lock the csd, call generic_exec_single().
>
> Lets move the common
On Mon, Feb 10, 2014 at 08:41:44PM +0100, Ivan T. Ivanov wrote:
>
> Hi,
>
> On Mon, 2014-02-10 at 11:47 -0600, Andy Gross wrote:
> > On Mon, Feb 10, 2014 at 06:55:02PM +0200, Ivan T. Ivanov wrote:
> >
> > []
> >
> > > > > > Bail here?
> > > > >
> > > > > I don't know. What will be the
This will be used by the planned migration path update.
Signed-off-by: Tejun Heo
---
kernel/cgroup.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 6727171..9201160 100644
--- a/kernel/cgroup.c
+++
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Dave Young
commit a7f84f03f660d93574ac88835d056c0d6468aebe upstream.
Current code check boot service region with kernel text region by:
start+size >= __pa_symbol(_text)
The end of the
Mike,
Can you please look at these couple of keystone clock fixes ?
Without these, we have seen some random kernel crashes. I
have included the dts fix since both fixes are related. Do
let me know if you prefer dts patch to be sent it via arm-soc tree.
The following changes since commit
Currently, while migrating tasks from one cgroup to another,
cgroup_attach_task() builds a flex array of all target tasks;
unfortunately, this has a couple issues.
* Flex array has size limit. On 64bit, struct task_and_cgroup is
24bytes making the flex element limit around 87k. It is a high
Currently, while migrating tasks from one cgroup to another,
cgroup_attach_task() builds a flex array of all target tasks;
unfortunately, this has a couple issues.
* Flex array has size limit. On 64bit, struct task_and_cgroup is
24bytes making the flex element limit around 87k. It is a high
Hello,
Currently, when migrating a task or process from one cgroup to
another, a flex_array is used to keep track of the target tasks and
associated css_sets. This has a couple issues.
* flex_array size is limited. Given the current data structure, the
limit is ~87k on 64bit, which is pretty
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Thomas Huth
commit e879892c725217a4af1012f31ae56be762473216 upstream.
The SIGP order STOP_AND_STORE_STATUS is defined to stop a CPU and store
its status. However, we only stored the
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Konrad Rzeszutek Wilk
commit 51c71a3bbaca868043cc45b3ad3786dd48a90235 upstream.
The user has the option of disabling the platform driver:
00:02.0 Unassigned class [ff80]: XenSource,
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Trond Myklebust
commit c7848f69ec4a8c03732cde5c949bd2aa711a9f4b upstream.
decode_op_hdr() cannot distinguish between an XDR decoding error and
the perfectly valid errorcode NFS4ERR_IO.
Currently, process / task migration is a single operation which may
fail depending on memory pressure or the involved controllers'
->can_attach() callbacks. One problem with this approach is migration
of multiple targets. It's impossible to tell whether a given target
will be successfully
On Mon, Feb 10, 2014 at 09:19:46AM -0800, Joe Perches wrote:
> On Mon, 2014-02-10 at 12:27 +0300, Dan Carpenter wrote:
> > These messages are terrifying...
>
> Hey Dan.
>
> Do bumps in the night keep you up too? :)
>
> > We do not want to encourage a million
> > first patch submitters to start
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Antti Palosaari
commit c57f87e62368c33ebda11a4993380c8e5a19a5c5 upstream.
PLL was attached twice to frontend0 leaving frontend1 without a tuner.
frontend0 is DVB-C and frontend1 is
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Vijaya Mohan Guvva
commit dcaf9aed995c2b2a49fb86bbbcfa2f92c797ab5d upstream.
Bfa driver crash is observed while pushing the firmware on to chinook
quad port card due to uninitialized
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Dongsheng Yang
commit ad85ace07a05062ef6b59c35a5e80b6eaee1eee6 upstream.
Currently, if we use perf kvm --guestkallsyms --guestmodules report, we
can not get the perf information from
Hi,
On Mon, 2014-02-10 at 11:47 -0600, Andy Gross wrote:
> On Mon, Feb 10, 2014 at 06:55:02PM +0200, Ivan T. Ivanov wrote:
>
> []
>
> > > > > Bail here?
> > > >
> > > > I don't know. What will be the consequences if controller continue to
> > > > operate on its default rate?
> > > >
> >
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Larry Finger
commit 62009b7f12793c932aaba0df946b04cb4a77d022 upstream.
Vendor driver rtl8188C_8192C_8192D_usb_linux_v3.4.2_3727.20120404 introduced
new firmware for these chips. The
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Larry Finger
commit 10d0b9030a3f86e1e26c710c7580524d7787d688 upstream.
A typo causes routine rtl92cu_phy_rf6052_set_cck_txpower() to test the
same condition twice. The problem was
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Larry Finger
commit 619ce76f8bb850b57032501a39f26aa6c6731c70 upstream.
The present code fails to set the linked state when an interface is
added.
Signed-off-by: Larry Finger
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Mauro Carvalho Chehab
commit 5ac64ba12aca3bef18e61c866583155a3bbf81c4 upstream.
As the dvb-frontend kthread can be called anytime, it can race
with some get status ioctl. So, it seems
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Larry Finger
commit 09164043f63c947a49797750a09ca1cd7c31108e upstream.
In https://bugzilla.kernel.org/show_bug.cgi?id=67561, a locking dependency is
reported
when b43 is used with
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Dave Airlie
commit f4b4718b61d1d5a7442a4fd6863ea80c3a10e508 upstream.
these 3 were checking in_interrupt but we have situations where
calling vunmap under this could cause a BUG to be
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Johannes Weiner
commit a1c3bfb2f67ef766de03f1f56bdfff9c8595ab14 upstream.
The VM is currently heavily tuned to avoid swapping. Whether that is
good or bad is a separate discussion,
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Takashi Iwai
commit 2510538fa000dd13a3e57b79bf073ffb1748976c upstream.
When the mode is set with 16bpp on QEMU, the output gets totally broken.
The culprit is the bogus register values
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: =?UTF-8?q?=E5=BC=A0=E5=90=9B?=
commit 4d90b819ae4c7ea8fd5e2bb7edc68c0f334be2e4 upstream.
Signed-off-by: Jun zhang
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Kamal Mostafa
---
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Maarten Lankhorst
commit 8ade2b8281d58a8336a1742a44ceffd9d07d6629 upstream.
Mutexes should not be acquired in interrupt context. While the trylock
fastpath is arguably safe on all
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Mikulas Patocka
commit be35f486108227e10fe5d96fd42fb2b344c59983 upstream.
There may be other parts of the kernel holding a reference on the dm
kobject. We must wait until all
On Sat, 2014-02-08 at 18:29 +0100, Antonios Motakis wrote:
> The ARM SMMU driver expects the IOMMU_EXEC flag, otherwise it will
> set the page tables for a device as XN (execute never). This affects
> devices such as the ARM PL330 DMA Controller, which fails to operate
> if the XN flag is set on
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Peter Chen
commit feffe09f510c475df082546815f9e4a573f6a233 upstream.
According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
register error issue", All USB register write
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: David Sterba
commit d024206133ce21936b3d5780359afc00247655b7 upstream.
Currently, any user can snapshot any subvolume if the path is accessible and
thus indirectly create and keep
On Mon, 10 Feb 2014, Michal Hocko wrote:
> On Fri 07-02-14 12:04:20, Johannes Weiner wrote:
> > Reparenting memory charges in the css_free() callback was meant as a
> > temporary fix for charges that race with offlining, but after some
> > follow-up discussion, it turns out that this is really the
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Johannes Weiner
commit a804552b9a15c931cfc2a92a2e0aed1add8b580a upstream.
Tejun reported stuttering and latency spikes on a system where random
tasks would enter direct reclaim and get
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Neal Cardwell
[ Based upon upstream commit 70315d22d3c7383f9a508d0aab21e2eb35b2303a ]
Fix inet_diag_dump_icsk() to reflect the fact that both TIME_WAIT and
FIN_WAIT2 connections are
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Stephen Warren
commit 75ea799df4cb07e505c91b4abaa87bc28aad3e66 upstream.
The current MAX8907 driver has two issues related to weekday value
handling:
1)
The HW WEEKDAY register has
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Max Filippov
commit a558d99263936b8a67d4eff8918745a77bfd8c31 upstream.
Remove __initdata attribute, as the devices may be used after init
sections are freed.
Signed-off-by: Max
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: "Steven Rostedt (Red Hat)"
commit 8c4f3c3fa9681dc549cd35419b259496082fef8b upstream.
There's been a nasty bug that would show up and not give much info.
The bug displayed the following
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Larry Finger
commit f87f960b2fb802f26ee3b00c19320e57a9c583ff upstream.
Reported-by: Jan Prinsloo
Tested-by: Jan Prinsloo
Signed-off-by: Larry Finger
Signed-off-by: John W. Linville
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Larry Finger
commit 3a21f00a5002b14e4aab52aef59d33ed28468a13 upstream.
The latest version of NetworkManager does not recognize the device as wireless
without this change.
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Larry Finger
commit 452028665312672c6ba9e16a19248ee00ead9400 upstream.
The asyncronous firmware load uses a completion struct to hold firmware
processing until the user-space routines
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Mark Brown
commit 49a12877d2777cadcb838981c3c4f5a424aef310 upstream.
There is currently no facility in ACPI to express the hookup of voltage
regulators, the expectation is that the
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: AKASHI Takahiro
commit 06bdadd7634551cfe8ce071fe44d0311b3033d9e upstream.
audit_syscall_exit() saves a result of regs_return_value() in intermediate
"int" variable and passes it to
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Nicolas Dichtel
[ No relevant upstream commit. ]
This problem was fixed upstream by commit 1e9f3d6f1c40 ("ip6tnl: fix use after
free of fb_tnl_dev").
The upstream patch depends on
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Ira Weiny
commit 6e0ea9e6cbcead7fa8c76e3e3b9de4a50c5131c5 upstream.
The GSI QP type is compatible with and should be allowed to send data
to/from any UD QP. This was found when
On Mon, Feb 10, 2014 at 9:54 AM, Dr. H. Nikolaus Schaller
wrote:
> Am 10.02.2014 um 09:27 schrieb Johannes Berg:
>
>> On Fri, 2014-02-07 at 20:48 +0100, Marek Belisko wrote:
>>
>>> +#define RFKILL_TYPE_ALL (0)
>>> +#define RFKILL_TYPE_WLAN(1)
>>> +#define RFKILL_TYPE_BLUETOOTH
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Aristeu Rozanski
commit 90ed4988b8c030d65b41b7d13140e9376dc6ec5a upstream.
In case the device 0, function 1 is not found using pci_get_device(),
pci_scan_single_device() will be used
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Andy Grover
commit ee291e63293146db64668e8d65eb35c97e8324f4 upstream.
When creating network portals rapidly, such as when restoring a
configuration, LIO's code to reuse existing
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Maarten Lankhorst
commit a06b9a74c73750835b8fd69fe0d0bd7877da111b upstream.
Mutexes should not be acquired in interrupt context. While the trylock
fastpath is arguably safe on all
On Mon, Feb 10, 2014 at 11:33 AM, Andy Lutomirski wrote:
>
> I agree that reading to module space is awful, but is it obviously
> terrible for a module to do this:
>
> static const char header[] = {...};
> kernel_write(file, header, sizeof(header), 0);
Yes, it is terrible. Don't do it. It
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Mel Gorman
commit c297663c0b3930491a3cb2aba4b6e5a7159c3503 upstream.
The command line parsing takes place before jump labels are initialised
which generates a warning if
3.8.13.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: Boaz Harrosh
commit aad560b7f63b495f48a7232fd086c5913a676e6f upstream.
At IO preparation we calculate the max pages at each device and
allocate a BIO per device of that size. The
201 - 300 of 2010 matches
Mail list logo
