From: Jeff Mahoney
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit d0ce7b8567ae76b8a6c0eb8361d121deb98c1b3f upstream.
Commit 8116188fdef594 ("nouveau/acpi: hook up to the MXM method for mux
switching.") broke the build on non-x86 architecture
From: Andy Adamson
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit c297c8b99b07f496ff69a719cfb8e8fe852832ed upstream.
Otherwise RPCSEC_GSS_DESTROY messages are not sent.
Signed-off-by: Andy Adamson
Signed-off-by: Trond Myklebust
Signed-off
From: "J. Bruce Fields"
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit a3f432bfd06a4ec3b812e32d3266e0d1ad75d008 upstream.
This check was added by Al Viro with
d9e80b7de91db05c1c4d2e5ebbfd70b3b3ba0e0f "nfs d_revalidate() is too
trigger-happy
From: Andy Adamson
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit f9c96fcc501a43dbc292b17fc0ded4b54e63b79d upstream.
Fix a dynamic session slot leak where a slot is preallocated and I/O is
resent through the MDS.
Signed-off-by: Andy Adamson
From: Takashi Iwai
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 7fe307117db5bd7ec6efb93c563dcf44577b6d2b upstream.
The current code for controlling mic mute LED in patch_sigmatel.c
blindly assumes that there is a single capture switch. Bu
From: Artem Fetishev
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 825600c0f20e595daaa7a6dd8970f84fa2a2ee57 upstream.
On x86 uniprocessor systems topology_physical_package_id() returns -1
which causes rapl_cpu_prepare() to leave rapl_pmu va
From: Oliver Neukum
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 16c0c4e1656c14ef9deac189a4240b5ca19c6919 upstream.
The AVX2 implementation also uses BMI2 instructions,
but doesn't test for their availability. The assumption
that AVX2 and
On 04/02/2014 12:47 PM, Johannes Weiner wrote:
> On Wed, Apr 02, 2014 at 12:01:00PM -0700, John Stultz wrote:
>> On Wed, Apr 2, 2014 at 10:58 AM, Johannes Weiner wrote:
>>> On Wed, Apr 02, 2014 at 10:40:16AM -0700, John Stultz wrote:
That point beside, I think the other problem with the page-
This is the start of the stable review cycle for the 3.12.17 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 made by Fri Apr 4 20:06:31 2014
Anything received af
On Wed, Apr 2, 2014 at 9:50 PM, Thomas Gleixner wrote:
> On Wed, 2 Apr 2014, Andrew Morton wrote:
>> On Wed, 2 Apr 2014 14:42:19 -0400 Steven Rostedt wrote:
>>
>> > It has come to our attention that a system running a specific user
>> > space init program will not boot if you add "debug" to the k
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm announcing the release of the 3.12.16 kernel.
All users of the 3.12 kernel series must upgrade.
The updated 3.12.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.12.y
and can be bro
Hello,
I have been reconsidering requirements and solutions brought up in my
post "How about allowing processes to expose memory for cross memory
attaching?". I now have a much clearer idea of what I want. I think
there is a need for publicly exposing process scoped
interfaces. Previous solutions
On Wed, Apr 02, 2014 at 10:24:03AM +0200, Paul Bolle wrote:
> On Tue, 2014-04-01 at 11:48 -0700, Greg KH wrote:
> > Staging driver pull request for 3.15-rc1
> >
> > Here's the huge drivers/staging/ update for 3.15-rc1.
> >
> > Loads of cleanup fixes, a few drivers removed, and some new ones added
On 14-04-01 05:59 PM, Brown, Len wrote:
>> I've got an eval board with a 1.7GHz Avaton/C2000 that hangs at boot
>> shortly after the idle driver registration -- typically 1/2 dozen
>> dmesg lines later, around rtc init, or net stack init.
>
> Paul,
> Please boot the failing board with "intel_idle.
On Wed, Apr 02, 2014 at 07:06:00AM -0600, Shuah Khan wrote:
> On Tue, Apr 1, 2014 at 12:48 PM, Greg KH wrote:
> > The following changes since commit dcb99fd9b08cfe1afe426af4d8d3cbc429190f15:
> >
> > Linux 3.14-rc7 (2014-03-16 18:51:24 -0700)
> >
> > are available in the git repository at:
> >
>
On Mon, 2014-03-31 at 21:43 +0200, Oleg Nesterov wrote:
> Hello.
>
> x86 can not handle the rip-relative jmp/call instrsuctions, the probed
> task can be killed by general protection fault. I'll describe this in
> more details when I send the fixes. Now I am sending the preparations
> which (I hop
On Fri, Mar 21, 2014 at 04:16:24PM +0800, Axel Lin wrote:
> Current code misses updating the register when enable_shift is 0.
> e.g. S2MPS11_BUCK9_RAMP_SHIFT and S2MPS11_BUCK6_RAMP_EN_SHIFT are 0.
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, 2014-03-31 at 21:44 +0200, Oleg Nesterov wrote:
...
> +static void
> +handle_riprel_post_xol(struct arch_uprobe *auprobe, struct pt_regs *regs,
> long *correction)
> +{
> + if (auprobe->fixups & (UPROBE_FIX_RIP_AX | UPROBE_FIX_RIP_CX)) {
> + struct arch_uprobe_task *autask;
On Fri, Mar 21, 2014 at 04:15:20PM +0800, Axel Lin wrote:
> Current code misses updating the register when enable_shift is 0.
> e.g. S2MPA01_BUCK4_RAMP_EN_SHIFT is 0.
Applied, thanks.
signature.asc
Description: Digital signature
On Tue, Apr 01, 2014 at 07:34:09PM +0800, Nicolin Chen wrote:
> The next coming i.MX6 Solo X SoC also contains SAI module while we use
> imp_pcm_init() for i.MX platform.
I've applied this, though obviously it'd be better if we had dmaengine
support for this SoC so that it was just a compatible st
On 04/02/2014 11:41 AM, Jan Kara wrote:
> Thanks for the patches and measurements! So I agree we contend a lot on
> orphan list changes in ext4. But what you do seems to be unnecessarily
> complicated and somewhat hiding the real substance of the patch. If I
> understand your patch correctly, all
On 04/02/2014 11:31 AM, Andrea Arcangeli wrote:
> On Tue, Apr 01, 2014 at 09:03:57PM -0700, John Stultz wrote:
>> Now... once you've chosen SIGBUS semantics, there will be folks who will
>> try to exploit the fact that we get SIGBUS on purged page access (at
>> least on the user-space side) and wil
On Wed, Apr 02, 2014 at 06:09:09PM +0800, Xiubo Li wrote:
> + ret = of_regmap_get_endian(dev, bus, config, "reg_endian", ®_endian);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + ret = of_regmap_get_endian(dev, bus, config, "val_endian", &val_endian);
> + if (ret)
> +
On Wed, 2 Apr 2014, Andrew Morton wrote:
> On Wed, 2 Apr 2014 14:42:19 -0400 Steven Rostedt wrote:
>
> > It has come to our attention that a system running a specific user
> > space init program will not boot if you add "debug" to the kernel
> > command line. What happens is that the user space t
On Wed, Apr 02, 2014 at 06:09:08PM +0800, Xiubo Li wrote:
> +sai2: sai@40031000 {
> + compatible = "fsl,vf610-sai";
> + reg = <0x40031000 0x1000>;
> + ...
> + val-endian = 'LE';
> +};
This is mostly OK as a binding (though it should be CCed to the DT list
a
On Wed, Apr 02, 2014 at 12:01:00PM -0700, John Stultz wrote:
> On Wed, Apr 2, 2014 at 10:58 AM, Johannes Weiner wrote:
> > On Wed, Apr 02, 2014 at 10:40:16AM -0700, John Stultz wrote:
> >> That point beside, I think the other problem with the page-cleaning
> >> volatility approach is that there ar
On Mon, 2014-03-31 at 21:44 +0200, Oleg Nesterov wrote:
...
> +/*
> + * Adjust the return address pushed by a call insn executed out of line.
> + */
> +static int adjust_ret_addr(unsigned long sp, long correction)
> +{
> + int rasize, ncopied;
> + long ra = 0;
> +
> + if (is_ia32_task()
On 04/02/2014 12:47 PM, David Sterba wrote:
On Tue, Apr 01, 2014 at 06:23:11PM -0400, Josh Boyer wrote:
Below is a lockdep spew I have on a local VM running Linus' tree as of
this afternoon. The specific git commit is v3.14-751-g683b6c6f82a6.
[ 295.349016]CPU0CPU
On Wed, Apr 02, 2014 at 06:09:07PM +0800, Xiubo Li wrote:
> Allow busses to request little endianness formatting and
> parsing for 16- and 32-bit values. This will be useful to
> support regmap-mmio.
Applied, thanks.
signature.asc
Description: Digital signature
Adding -header + help function like other .pl in /scripts.
Cc: linux-kbu...@vger.kernel.org
Signed-off-by: Fabian Frederick
---
v2: fix some typos
scripts/bootgraph.pl | 42 --
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/scripts/bootgr
On Wed, Apr 2, 2014 at 11:07 AM, Johannes Weiner wrote:
> On Wed, Apr 02, 2014 at 10:48:03AM -0700, John Stultz wrote:
>> I suspect handling the SIGBUS and patching up the purged page you
>> trapped on is likely much to complicated for most use cases. But I do
>> think SIGBUS is preferable to zero
On Wed, 2 Apr 2014 11:46:38 -0700
Linus Torvalds wrote:
> On Wed, Apr 2, 2014 at 10:26 AM, Steven Rostedt wrote:
> >
> > Here are two patches that fix the deadlock that you discovered.
> >
> > The first patch is the real culprit, but as I was looking at the code
> > I realized that the irq stack
On Mon, Mar 31, 2014 at 4:08 AM, Hidetoshi Seto
wrote:
> There are 2 problems:
>
> [PROBLEM 1]: there is no exclusive control.
>
> It is easy to understand that there are 2 different cpu - an
> observing cpu where running a program observing idle cpu's stat
> and an observed cpu where performing i
On Sat, Mar 29, 2014 at 05:30:28PM +0100, Jan Kara wrote:
> > @@ -379,7 +379,9 @@ static int brd_direct_access(struct block_device *bdev,
> > sector_t sector,
> > *kaddr = page_address(page);
> > *pfn = page_to_pfn(page);
> >
> > - return 0;
> > + /* Could optimistically check to see
On Wed, Apr 2, 2014 at 12:56 PM, Josh Boyer wrote:
> On Wed, Apr 2, 2014 at 12:47 PM, David Sterba wrote:
>> On Tue, Apr 01, 2014 at 06:23:11PM -0400, Josh Boyer wrote:
>>> Below is a lockdep spew I have on a local VM running Linus' tree as of
>>> this afternoon. The specific git commit is v3.14
Hi,
On Wed, Apr 02, 2014 at 09:26:27PM +0200, Rabin Vincent wrote:
> 30a70b026b4cde4 ("usb: musb: fix obex in g_nokia.ko causing kernel
> panic") broke USB gadget support on Pandaboard because it simply deletes
> the call to phy_power_on() and the PHY is therefore never turned on.
>
> Fix it by a
On Wed, 2 Apr 2014 21:08:51 +0200
Borislav Petkov wrote:
> Well, maybe the minor nit that it leaves two spaces in /proc/cmdline now:
>
> "root=/dev/sda1 ignore_loglevel log_buf_len=10M earlyprintk=ttyS0,115200
> console=ttyS0,115200 console=tty0"
>
> Also, you need to add
>
> Suggested-by:
This series has been rebased but its content has not changed.
This is series has two parts. The first two patches are changes
to the existing Broadcom Kona family clock code to prepare for the
addition of support for another SoC, bcm21664.
The remaining three define the binding and code for bcm2
The next patch defines a binding for a new Broadcom SoC that uses
Kona style CCUs for its clocks. Update the generic Kona clock
binding document so it's more natural to accomodate the definitions
of additional SoC families.
Specifically:
- Define the compatible string values generically, refe
Document the device tree binding for Broadcom BCM28164 clock control
units and clocks. This SoC uses Kona CCUs, similar to the BCM281XX
SoC family.
Signed-off-by: Alex Elder
---
.../devicetree/bindings/clock/bcm-kona-clock.txt | 39
1 file changed, 39 insertions(+)
dif
The Broadcom 281xx clock code uses a #define for the compatible
string for it's clock control units (CCUs). Rather than defining
those in the C source file, define them in the header file that's
shared by both the code and the device tree source file (along with
all the clock ids).
Signed-off-by:
Replace the "fake" fixed-rate clocks used previously for the
bcm21664 family with "real" ones.
Signed-off-by: Alex Elder
---
arch/arm/boot/dts/bcm21664.dtsi | 190 ---
1 file changed, 118 insertions(+), 72 deletions(-)
diff --git a/arch/arm/boot/dts/bcm21664
On Wed, Apr 02, 2014 at 12:29:42PM +0200, Takashi Iwai wrote:
> The driver is well written to be used as a module, just the exit call
> is missing.
>
> Signed-off-by: Takashi Iwai
> ---
> drivers/char/Kconfig | 2 +-
> drivers/char/ttyprintk.c | 13 -
> 2 files changed, 13 inser
Define the set of CCUs and provided clocks sufficient to satisfy the
needs of all the existing clock references for BCM21664. Replace
the "fake" fixed-rate clocks used previously with "real" ones.
Note that only the minimal set of these clocks and CCUs is defined
here. More clock definitions wil
On Wed, Apr 02, 2014 at 08:31:13PM +0200, Andrea Arcangeli wrote:
> Hi everyone,
>
> On Tue, Apr 01, 2014 at 09:03:57PM -0700, John Stultz wrote:
> > So between zero-fill and SIGBUS, I think SIGBUS makes the most sense. If
> > you have a third option you're thinking of, I'd of course be interested
30a70b026b4cde4 ("usb: musb: fix obex in g_nokia.ko causing kernel
panic") broke USB gadget support on Pandaboard because it simply deletes
the call to phy_power_on() and the PHY is therefore never turned on.
Fix it by actually turning the phy on.
Cc: sta...@vger.kernel.org
Signed-off-by: Rabin V
On Sat, Mar 29, 2014 at 05:22:16PM +0100, Jan Kara wrote:
> On Sun 23-03-14 15:08:29, Matthew Wilcox wrote:
> > The 'pfn' returned by axonram was completely bogus, and has been since
> > 2008.
> Maybe time to drop the driver instead? When noone noticed for 6 years, it
> seems pretty much dead...
Adding -header + help function like other .pl in /scripts.
Cc: linux-kbu...@vger.kernel.org
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
scripts/bootgraph.pl | 42 --
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/scripts/bootgrap
On 04/02, Jim Keniston wrote:
>
> On Tue, 2014-04-01 at 18:39 +0200, Oleg Nesterov wrote:
>
> > So let me explain the problem, and how (I think) it should be solved.
> > Unfortunately, I do not even know the terminology, so firstly I have
> > to explain you the things I recently learned when I inve
On Wed, Apr 02, 2014 at 02:42:19PM -0400, Steven Rostedt wrote:
> It has come to our attention that a system running a specific user
> space init program will not boot if you add "debug" to the kernel
> command line. What happens is that the user space tool parses the
> kernel command line, and if
On Wed, Apr 02, 2014 at 10:03:24PM +0400, Konstantin Khlebnikov wrote:
> > +void filemap_map_pages(struct vm_area_struct *vma, struct vm_fault *vmf)
> > +{
> > + struct radix_tree_iter iter;
> > + void **slot;
> > + struct file *file = vma->vm_file;
> > + struct address_spac
On 04/02/2014 12:04 PM, Andrew Morton wrote:
On Wed, 2 Apr 2014 14:42:19 -0400 Steven Rostedt wrote:
It has come to our attention that a system running a specific user
space init program will not boot if you add "debug" to the kernel
command line. What happens is that the user space tool parse
On Wed, Apr 02, 2014 at 12:04:40PM -0700, Andrew Morton wrote:
> On Wed, 2 Apr 2014 14:42:19 -0400 Steven Rostedt wrote:
>
> > It has come to our attention that a system running a specific user
> > space init program will not boot if you add "debug" to the kernel
> > command line. What happens is
Adds tty driver to netconsole module. When module is loaded,
creates /dev/netcon0 device and enables support for console=netcon0
kernel cmdline option, causing /dev/console output to be sent to
/dev/netcon0. This allows startup/shutdown script output from
headless platforms to be logged over (secur
On Wed, 2 Apr 2014 14:42:19 -0400 Steven Rostedt wrote:
> It has come to our attention that a system running a specific user
> space init program will not boot if you add "debug" to the kernel
> command line. What happens is that the user space tool parses the
> kernel command line, and if it see
Loongson2 has been using (incorrectly) kHz for cpu_clk rate. This has
been unnoticed, as loongson2_cpufreq was the only place where the rate
was set/get. After commit 652ed95d5fa6074b3c4ea245deb0691f1acb6656
(cpufreq: introduce cpufreq_generic_get() routine) things however broke,
and now loops_per_
2014-04-02 2:09 GMT-07:00 Alexander Holler :
> Am 02.04.2014 02:57, schrieb Florian Fainelli:
>
>> 2014-04-01 16:55 GMT-07:00 Alexander Holler :
>>>
>>> Commit 7cd1463664c2a15721ff4ccfb61d4d970815cb3d (introduced with 3.14)
>>> changed the initialization of the mv643xx_eth driver to use phy_init_hw
On Wed, Apr 02, 2014 at 08:30:23PM +0200, Frederic Weisbecker wrote:
> 2014-04-02 20:05 GMT+02:00 Paul E. McKenney :
> > On Wed, Apr 02, 2014 at 06:26:05PM +0200, Frederic Weisbecker wrote:
> >> diff --git a/kernel/smp.c b/kernel/smp.c
> >> index 06d574e..bfe7b36 100644
> >> --- a/kernel/smp.c
> >>
On Wed, Apr 2, 2014 at 10:58 AM, Johannes Weiner wrote:
> On Wed, Apr 02, 2014 at 10:40:16AM -0700, John Stultz wrote:
>> That point beside, I think the other problem with the page-cleaning
>> volatility approach is that there are other awkward side effects. For
>> example: Say an application mark
On Wed, Apr 2, 2014 at 11:42 AM, Steven Rostedt wrote:
>
> The response is:
>
> "Generic terms are generic, not the first user owns them."
And by "their" you mean Kay Sievers.
Key, I'm f*cking tired of the fact that you don't fix problems in the
code *you* write, so that the kernel then has to w
On 14/04/02, Mimi Zohar wrote:
> On Wed, 2014-04-02 at 14:18 -0400, Eric Paris wrote:
> > On Wed, 2014-04-02 at 14:12 -0400, Mimi Zohar wrote:
> > > On Wed, 2014-04-02 at 14:00 -0400, Steve Grubb wrote:
> > > > Hello Mimi,
> > > >
> > > > On Wednesday, April 02, 2014 01:39:47 PM Mimi Zohar wrote
It has come to our attention that a system running a specific user
space init program will not boot if you add "debug" to the kernel
command line. What happens is that the user space tool parses the
kernel command line, and if it sees "debug" it will spit out so much
information that the system fai
On Wed, Apr 2, 2014 at 10:26 AM, Steven Rostedt wrote:
>
> Here are two patches that fix the deadlock that you discovered.
>
> The first patch is the real culprit, but as I was looking at the code
> I realized that the irq stack part was a bit off too. That part didn't
> cause the lock up, but nee
On 14/04/02, Mimi Zohar wrote:
> On Wed, 2014-04-02 at 12:19 -0400, Richard Guy Briggs wrote:
> > When task->comm is passed directly to audit_log_untrustedstring() without
> > getting a copy or using the task_lock, there is a race that could happen
> > that
> > would output a NULL (\0) in the out
Hi everyone,
On Tue, Apr 01, 2014 at 09:03:57PM -0700, John Stultz wrote:
> So between zero-fill and SIGBUS, I think SIGBUS makes the most sense. If
> you have a third option you're thinking of, I'd of course be interested
> in hearing it.
I actually thought the way of being notified with a page
2014-04-02 20:05 GMT+02:00 Paul E. McKenney :
> On Wed, Apr 02, 2014 at 06:26:05PM +0200, Frederic Weisbecker wrote:
>> diff --git a/kernel/smp.c b/kernel/smp.c
>> index 06d574e..bfe7b36 100644
>> --- a/kernel/smp.c
>> +++ b/kernel/smp.c
>> @@ -265,6 +265,50 @@ int smp_call_function_single_async(in
On Wed, Apr 02, 2014 at 10:20:17AM +0800, Xiubo Li wrote:
> 'offset = *(u32 *)reg;'
> This will be okey for 32/64-bits register device, but for 8/16-bits
> register ones, the 'offset' value will overflow, for example:
Applied, thanks.
signature.asc
Description: Digital signature
On Wed, 2014-04-02 at 14:18 -0400, Eric Paris wrote:
> On Wed, 2014-04-02 at 14:12 -0400, Mimi Zohar wrote:
> > On Wed, 2014-04-02 at 14:00 -0400, Steve Grubb wrote:
> > > Hello Mimi,
> > >
> > > On Wednesday, April 02, 2014 01:39:47 PM Mimi Zohar wrote:
> > > > This change is already being upst
On Wed, Apr 02, 2014 at 02:17:19PM -0400, Santosh Shilimkar wrote:
> On Wednesday 02 April 2014 02:16 PM, Greg KH wrote:
> > On Wed, Apr 02, 2014 at 01:53:19PM -0400, Santosh Shilimkar wrote:
> >> On Thursday 13 March 2014 05:44 PM, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> On Thu, Mar 13, 2014 at
On Wed, 2014-04-02 at 14:12 -0400, Mimi Zohar wrote:
> On Wed, 2014-04-02 at 14:00 -0400, Steve Grubb wrote:
> > Hello Mimi,
> >
> > On Wednesday, April 02, 2014 01:39:47 PM Mimi Zohar wrote:
> > > This change is already being upstreamed as commit 73a6b44 "Integrity:
> > > Pass commname via get_t
On Wednesday 02 April 2014 02:16 PM, Greg KH wrote:
> On Wed, Apr 02, 2014 at 01:53:19PM -0400, Santosh Shilimkar wrote:
>> On Thursday 13 March 2014 05:44 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Thu, Mar 13, 2014 at 10:20:24AM -0500, Felipe Balbi wrote:
On Thu, Mar 13, 2014 at 01:11:13PM +
On Wed 02-04-14 23:19:06, Jianyu Zhan wrote:
> A bitwise flag comparison could be done using a more efficient bit-ops way.
OK, but have you checked the generated code is actually any better? This
is something I'd expect a compiler might be able to optimize anyway. And the
original code looks more
On Wed, Apr 02, 2014 at 01:53:19PM -0400, Santosh Shilimkar wrote:
> On Thursday 13 March 2014 05:44 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Mar 13, 2014 at 10:20:24AM -0500, Felipe Balbi wrote:
> >> On Thu, Mar 13, 2014 at 01:11:13PM +0200, Grygorii Strashko wrote:
> >>> This fixes a regr
On Wed, 2014-04-02 at 00:19 +0200, Steffen Trumtrar wrote:
> Hi!
>
> On Tue, Apr 01, 2014 at 03:11:41PM -0500, Thor Thayer - Sendmail wrote:
> > On Tue, 2014-04-01 at 07:28 +0200, Steffen Trumtrar wrote:
> > > Hi!
> > >
> > > On Mon, Mar 31, 2014 at 05:07:06PM -0500, ttha...@altera.com wrote:
> >
On Wed, 2014-04-02 at 14:00 -0400, Steve Grubb wrote:
> Hello Mimi,
>
> On Wednesday, April 02, 2014 01:39:47 PM Mimi Zohar wrote:
> > This change is already being upstreamed as commit 73a6b44 "Integrity:
> > Pass commname via get_task_comm()".
>
> While I was looking at Richard's patch, I notic
Hugepages pages never get the PG_reserved bit set, so don't clear it. But
add a warning just in case.
Signed-off-by: Luiz Capitulino
---
mm/hugetlb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 8c50547..7e07e47 100644
--- a/mm/hugetl
The HugeTLB subsystem uses the buddy allocator to allocate hugepages during
runtime. This means that hugepages allocation during runtime is limited to
MAX_ORDER order. For archs supporting gigantic pages (that is, page sizes
greater than MAX_ORDER), this in turn means that those pages can't be
allo
Next commit will add new code which will want to call the
for_each_node_mask_to_alloc() macro. Move it, its buddy
for_each_node_mask_to_free() and their dependencies up in the file so
the new code can use them. This is just code movement, no logic change.
Signed-off-by: Luiz Capitulino
---
mm/hu
Signed-off-by: Luiz Capitulino
---
include/linux/hugetlb.h | 5 +
mm/hugetlb.c| 28 ++--
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 8c43cc4..8590134 100644
--- a/include/linux/hu
Looks ok to me.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
HugeTLB is limited to allocating hugepages whose size are less than
MAX_ORDER order. This is so because HugeTLB allocates hugepages via
the buddy allocator. Gigantic pages (that is, pages whose size is
greater than MAX_ORDER order) have to be allocated at boottime.
However, boottime allocation has
On 04/02/14 04:02, Lei Wen wrote:
> Since arm's arch_timer's counter would keep accumulated even in the
> low power mode, including suspend state, it is very suitable to be
> the persistent clock instead of RTC.
>
> While read_persistent_clock calling place shall be rare, like only
> suspend/resume
On Wed, Apr 02, 2014 at 10:48:03AM -0700, John Stultz wrote:
> On Wed, Apr 2, 2014 at 10:40 AM, Dave Hansen wrote:
> > On 04/02/2014 10:18 AM, Johannes Weiner wrote:
> >> Hence my follow-up question in the other mail about how large we
> >> expect such code caches to become in practice in relation
On Wed, 2 Apr 2014 13:47:07 -0400
Theodore Ts'o wrote:
> On Wed, Apr 02, 2014 at 07:29:50PM +0200, Fabian Frederick wrote:
> > + set_mask_bits(&inode->i_flags, S_IMMUTABLE | S_APPEND | S_NOATIME |
> > + S_DIRSYNC | S_SYNC, new_fl);
>
> Warning --- per discussio
On Wed, Apr 02, 2014 at 06:26:05PM +0200, Frederic Weisbecker wrote:
> Some IPI users, such as the nohz subsystem, need to be able to send
> an async IPI (async = non waiting for any other IPI completion) on
> contexts with disabled interrupts. And we want the IPI subsystem to handle
> concurrent c
From: Mikulas Patocka
Various subsystems can ask the bio subsystem to create a bio slab cache
with some free space before the bio. This free space can be used for any
purpose. Device mapper uses this per-bio-data feature to place some
target-specific and device-mapper specific data before the b
On Thu, Feb 27, 2014 at 11:53 PM, Kirill A. Shutemov
wrote:
> filemap_map_pages() is generic implementation of ->map_pages() for
> filesystems who uses page cache.
>
> It should be safe to use filemap_map_pages() for ->map_pages() if
> filesystem use filemap_fault() for ->fault().
>
> Signed-off-b
(cc'ing memcg maintainers and cgroup ML)
On Wed, Apr 02, 2014 at 02:08:04PM +0100, Glyn Normington wrote:
> Currently, a memory cgroup can hit its oom limit when pages could, in
> principle, be reclaimed by the kernel except that the kernel does not
> respond directly to cgroup-local memory pressu
On 04/02/2014 12:47 PM, Theodore Ts'o wrote:
> On Wed, Apr 02, 2014 at 07:29:50PM +0200, Fabian Frederick wrote:
>> +set_mask_bits(&inode->i_flags, S_IMMUTABLE | S_APPEND | S_NOATIME |
>> + S_DIRSYNC | S_SYNC, new_fl);
>
> Warning --- per discussion with Linus
Hello Mimi,
On Wednesday, April 02, 2014 01:39:47 PM Mimi Zohar wrote:
> This change is already being upstreamed as commit 73a6b44 "Integrity:
> Pass commname via get_task_comm()".
While I was looking at Richard's patch, I noticed a few places where cause and
op are logged and the string isn't t
On Wed, 02 Apr 2014 10:10:12 -0700
"H. Peter Anvin" wrote:
)
>
> Do you want to do the patch?
Sure, I could probably whip something up.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Wed, Apr 02, 2014 at 10:40:16AM -0700, John Stultz wrote:
> On Wed, Apr 2, 2014 at 9:36 AM, Johannes Weiner wrote:
> > On Tue, Apr 01, 2014 at 09:12:44PM -0700, John Stultz wrote:
> >> On 04/01/2014 04:01 PM, Dave Hansen wrote:
> >> > On 04/01/2014 02:35 PM, H. Peter Anvin wrote:
> >> >> On 04/
Do not initialize private_destroy_list twice.
list_replace_init() already takes care of initializing private_destroy_list.
We don't need to initialize it with LIST_HEAD() beforehand.
Signed-off-by: David Cohen
---
fs/notify/mark.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Igor Mammedov writes:
> Hang is observed on virtual machines during CPU hotplug,
> especially in big guests with many CPUs. (It reproducible
> more often if host is over-committed).
>
> It happens because master CPU gives up waiting on
> secondary CPU and allows it to run wild. As result
> AP cau
Wrap both macros inside a 'do { ... } while(0)' to prevent breakage if
used within another 'if'. Also fix a usage of DBG_PRT with a missing
semicolon.
Signed-off-by: Guido Martínez
---
drivers/staging/vt6655/device.h | 13 +++--
drivers/staging/vt6655/wpactl.c | 2 +-
2 files changed, 1
On Tue, 2014-04-01 at 18:39 +0200, Oleg Nesterov wrote:
> On 04/01, Oleg Nesterov wrote:
> >
> > Good point, I'll send v2.
>
> Masami, et al, I was going to send v2 plus the next short RFC series
> which fixes the problem today, but it turns out that I have no time.
> Will try to do this tomorrow.
Comments mention a function CARDbSetBasicRate, but it never existed in
the source tree. Remove all mention of it.
Signed-off-by: Guido Martínez
---
drivers/staging/vt6655/card.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6
Miscellaneous style fixes for the vt6655 driver. Should not affect
functionality at all. Also remove dead code and some stale comments.
Shrink driver size by 1100 lines.
Guido Martínez (4):
staging: vt6655: fix DBG_PRT and PRINT_K macros
staging: vt6655: remove mention of nonexistent function
On Thursday 13 March 2014 05:44 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Mar 13, 2014 at 10:20:24AM -0500, Felipe Balbi wrote:
>> On Thu, Mar 13, 2014 at 01:11:13PM +0200, Grygorii Strashko wrote:
>>> This fixes a regression on Keystone 2 platforms caused by patch
>>> 57303488cd37da58263e842de134
On Wed, Apr 2, 2014 at 10:40 AM, Dave Hansen wrote:
> On 04/02/2014 10:18 AM, Johannes Weiner wrote:
>> Hence my follow-up question in the other mail about how large we
>> expect such code caches to become in practice in relationship to
>> overall system memory. Are code caches interesting reclai
201 - 300 of 640 matches
Mail list logo
