On Sat, Mar 16, 2013 at 10:11:22PM -0600, Alex Williamson wrote:
> On Sat, 2013-03-16 at 18:03 -0700, Greg KH wrote:
> > On Sat, Mar 16, 2013 at 05:50:53PM -0600, Myron Stowe wrote:
> > > On Sat, 2013-03-16 at 15:11 -0700, Greg KH wrote:
> > > > On Sat, Mar 16, 2013 at 03:35:19PM -0600, Myron
Hi Benoit,
On Thu, Mar 7, 2013 at 12:21 PM, Benoit Cousson wrote:
> Hi,
>
> On 03/06/2013 06:53 PM, Tony Lindgren wrote:
>> * Anil Kumar [130305 18:40]:
>>> Hi Tony,
>>>
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Anil Kumar
> Sent:
On Mon, 2013-03-11 at 18:23 -0700, Colin Cross wrote:
> On Mon, Oct 15, 2012 at 1:30 PM, Rafael J. Wysocki wrote:
> > On Monday 15 of October 2012 02:48:28 Tu, Xiaobing wrote:
> >>
> >> Fix memory leak in cpufreq stats.
> >>
> >> When system enter sleep, non-boot CPUs will be disable.
> >>
On Sat, Mar 16, 2013 at 8:23 AM, Ming Lei wrote:
> Since find_vma() may return NULL, so don't dereference the
> returned 'vma' until it is valid.
Agree this was an issue. This is fixed with commit a2362d24764a.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user
On Sat, 2013-03-16 at 18:03 -0700, Greg KH wrote:
> On Sat, Mar 16, 2013 at 05:50:53PM -0600, Myron Stowe wrote:
> > On Sat, 2013-03-16 at 15:11 -0700, Greg KH wrote:
> > > On Sat, Mar 16, 2013 at 03:35:19PM -0600, Myron Stowe wrote:
> > > > Sysfs includes entries to memory that backs a PCI
On Mon, 2013-03-04 at 23:19 +0400, Ilya Zykov wrote:
> On 03.12.2012 13:54, Ilya Zykov wrote:
> > The root of problem is carelessly zeroing pointer(in function
> > __tty_buffer_flush()),
> > when another thread can use it. It can be cause of "NULL pointer
> > dereference".
> > Main idea of
On Sun, 2013-03-03 at 23:58 +0100, Joerg Roedel wrote:
> Hi Ben,
>
> On Sat, Mar 02, 2013 at 11:00:35PM +, Ben Hutchings wrote:
> > I'm not convinced about this backport, because the order of
> > initialisation already changed a lot after 3.2 and before the upstream
> > commit. So I'm going
Hi Andrew,
Thanks for the bug report. I need to send a patch to update the maintainers
file...
Haven't had a chance to look into this yet. Will get back to you.
Thanks,
-Jason
On 03/11/2013 10:28 PM, Andrew Cooks wrote:
> On Tue, Mar 12, 2013 at 9:14 AM, Andrew Cooks wrote:
>> Hi Jason
>>
On 2013年03月15日 19:29, Arnd Bergmann wrote:
> On Friday 15 March 2013, Chen Gang F T wrote:
>> > excuse me, my English is not quite well.
>> >
>> > I guess your meaning is:
>> > "that bug" means the toolchain's bug (need toolchain people fix it).
>> > prefer to apply your patch, before
On Fri, 2013-03-15 at 15:35 +1030, Rusty Russell wrote:
> Satoru Takeuchi writes:
> > At Thu, 14 Mar 2013 17:11:21 +1030,
> > Rusty Russell wrote:
> >>
> >> Satoru Takeuchi writes:
> >> > Hi Rusty,
> >> >
> >> > At Tue, 12 Mar 2013 15:43:33 -0700,
> >> > Greg Kroah-Hartman wrote:
> >> >> @@
* Eric Wong (normalper...@yhbt.net) wrote:
> Eric Wong wrote:
> > Mathieu Desnoyers wrote:
> > > * Eric Wong (normalper...@yhbt.net) wrote:
> > > > Mathieu Desnoyers wrote:
> > > > > +/*
> > > > > + * Load a data from shared memory.
> > > > > + */
> > > > > +#define CMM_LOAD_SHARED(p)
On Sat, Mar 16, 2013 at 05:50:53PM -0600, Myron Stowe wrote:
> On Sat, 2013-03-16 at 15:11 -0700, Greg KH wrote:
> > On Sat, Mar 16, 2013 at 03:35:19PM -0600, Myron Stowe wrote:
> > > Sysfs includes entries to memory that backs a PCI device's BARs, both I/O
> > > Port space and MMIO. This memory
On Sun, Mar 17, 2013 at 2:33 AM, Sasha Levin wrote:
>
> I don't think it shows what we want it to show thought:
>
> [ 327.416905] Pid: 10504, comm: trinity-child98 Tainted: GW
> 3.9.0-rc2-next-20130315-sasha-00046-gecde602-dirty #301
> [ 327.418815] Call Trace:
> [ 327.419255] []
On Saturday, March 16, 2013 08:10:11 AM Roberto Oppedisano wrote:
> Il 15/03/2013 18:13, Rafael J. Wysocki ha scritto:
> >> Here's the new suspect:
> >>
> >> f95988de06ea62ef5bd861f06e9ef56cea405ed1 is the first bad commit
> >> commit f95988de06ea62ef5bd861f06e9ef56cea405ed1
> >> Author: Rafael J.
On Sat, Mar 16, 2013 at 06:58:45PM +0100, Oleg Nesterov wrote:
> On 03/15, Daniel Walker wrote:
> >
> > I was writing an application to ptrace a process which is dumping core
> > from inside the pipe application for core_pattern.
>
> This was never possible. And never will, I think.
>
> > So for
On Thu, Mar 14, 2013 at 9:03 AM, Myron Stowe wrote:
> On Wed, Mar 13, 2013 at 3:40 AM, Xiangliang Yu wrote:
>> Hi, Bjorn
>>
>>> >> > Now, the situation is like this:
>>> >> > I captured the PCIE trace with analyzer and found that 1st BE is 0x
>>> >> > when
>>> >> > accessing IO port space.
On 17/03/13 01:57, Arnd Bergmann wrote:
> On Saturday 16 March 2013, H Hartley Sweeten wrote:
>> Remove the __init tags from the ep93xx_pwm_probe() and
>> ep93xx_pwm_remove() functions to fix the section mismatch
>> warnings.
>>
>> Use module_platform_driver() to remove the init/exit boilerplate.
On Sat, 2013-03-16 at 15:11 -0700, Greg KH wrote:
> On Sat, Mar 16, 2013 at 03:35:19PM -0600, Myron Stowe wrote:
> > Sysfs includes entries to memory that backs a PCI device's BARs, both I/O
> > Port space and MMIO. This memory regions correspond to the device's
> > internal status and control
On Sat, Mar 16, 2013 at 4:11 PM, Greg KH wrote:
> On Sat, Mar 16, 2013 at 03:35:19PM -0600, Myron Stowe wrote:
>> Sysfs includes entries to memory that backs a PCI device's BARs, both I/O
>> Port space and MMIO. This memory regions correspond to the device's
>> internal status and control
On Sat, Mar 16, 2013 at 2:30 PM, Paul Bolle wrote:
> CONFIG_EXPERIMENTAL has been removed from the tree, in commit
> 3d374d09f16f64ab4d71704cbe621514d36cd0b1 ("final removal of
> CONFIG_EXPERIMENTAL"). There's no need to test for it in checkpatch
> anymore. If it ever pops up again it can be
On Sat, Mar 16, 2013 at 09:47:24PM +0100, Paul Bolle wrote:
> On Sat, 2013-03-16 at 20:35 +0100, Martin Walch wrote:
> > 64_BIT should probably say 64BIT which has corresponding config sections in
> > arch/{x86,ia64,mips,s390,tile,alpha,arm64,sparc,parisc,powerpc}/Kconfig and
> >
On Sat, Mar 16, 2013 at 10:30:35PM +0100, Paul Bolle wrote:
> 1) A lot of defconfigs still have CONFIG_EXPERIMENTAL in them. How
> should that be cleaned up?
Just ignore it, when ever those defconfigs ever get used, or updated, it
will fall out automatically.
thanks,
greg k-h
--
To unsubscribe
On Sat, Mar 16, 2013 at 03:35:19PM -0600, Myron Stowe wrote:
> Sysfs includes entries to memory that backs a PCI device's BARs, both I/O
> Port space and MMIO. This memory regions correspond to the device's
> internal status and control registers used to drive the device.
>
> Accessing these
On Sat, Mar 16, 2013 at 1:56 PM, Linus Torvalds
wrote:
> On Sat, Mar 16, 2013 at 9:11 AM, Parag Warudkar wrote:
>>
>> This seems to trigger a WARN_ON during suspend/resume.
>
> Ugh, yes. It's practically harmless, but it's ugly and technically
> wrong (we're using wrmsr_on_cpu() on our current
Eric Wong wrote:
> Mathieu Desnoyers wrote:
> > * Eric Wong (normalper...@yhbt.net) wrote:
> > > Mathieu Desnoyers wrote:
> > > > +/*
> > > > + * Load a data from shared memory.
> > > > + */
> > > > +#define CMM_LOAD_SHARED(p) ACCESS_ONCE(p)
> > >
> > > When iterating through the
On Sat, Mar 16, 2013 at 10:23:51PM +0100, Oleg Nesterov wrote:
> On 03/16, Andi Kleen wrote:
> >
> > > Perhaps rcu can be better, although a global rwsem looks simpler,
> > > I dunno.
> >
> > It's a general problem with lots of sysctls.
> > >
> > > But argv_split() or its usage should be changed
Sysfs includes entries to memory that backs a PCI device's BARs, both I/O
Port space and MMIO. This memory regions correspond to the device's
internal status and control registers used to drive the device.
Accessing these registers from userspace such as "udevadm info
--attribute-walk
I've been working on identifying the root cause of an issue exposed by
'udevadm' that was first exposed on the linux-pci mail list [1] and
believe that there is now enough of an understanding to propose a fix.
What was originally witnessed was the platform hanging after "udevadm info
CONFIG_EXPERIMENTAL has been removed from the tree, in commit
3d374d09f16f64ab4d71704cbe621514d36cd0b1 ("final removal of
CONFIG_EXPERIMENTAL"). There's no need to test for it in checkpatch
anymore. If it ever pops up again it can be caught when someone feels
like cleaning up invalid Kconfig
On 03/16, Andi Kleen wrote:
>
> > Perhaps rcu can be better, although a global rwsem looks simpler,
> > I dunno.
>
> It's a general problem with lots of sysctls.
> >
> > But argv_split() or its usage should be changed anyway, and GFP_KERNEL
> > won't work under rcu_read_lock().
>
> rcu strings has
On Sat, Mar 16, 2013 at 12:50:02PM -0700, Greg Kroah-Hartman wrote:
> On Sat, Mar 16, 2013 at 11:12:53AM -0700, Guenter Roeck wrote:
> > Adding lm-sensors.
> >
> > On Sat, Mar 16, 2013 at 09:21:40AM -0700, Greg Kroah-Hartman wrote:
> > > On Thu, Mar 14, 2013 at 08:24:45PM -0700, Guenter Roeck
The split_page() function will be very useful for balloon drivers. On Hyper-V,
it will be very efficient to use 2M allocations in the guest as this (a) makes
the ballooning protocol with the host that much more efficient and (b) moving
memory in 2M chunks minimizes fragmentation in the host.
While ballooning memory out of the guest, attempt 2M allocations first.
If 2M allocations fail, then go for 4K allocations. In cases where we
have performed 2M allocations, split this 2M page so that we can free this
page at 4K granularity (when the host returns the memory).
Signed-off-by: K. Y.
Support 2M page allocations when memory is ballooned out of the
guest. Hyper-V Dynamic Memory protocol is optimized around the ability
to move memory in 2M chunks.
K. Y. Srinivasan (2):
mm: Export split_page()
Drivers: hv: balloon: Support 2M page allocations for ballooning
> Perhaps rcu can be better, although a global rwsem looks simpler,
> I dunno.
It's a general problem with lots of sysctls.
>
> But argv_split() or its usage should be changed anyway, and GFP_KERNEL
> won't work under rcu_read_lock().
rcu strings has a helper function to copy the string for
On Sat, 2013-03-16 at 20:35 +0100, Martin Walch wrote:
> 64_BIT should probably say 64BIT which has corresponding config sections in
> arch/{x86,ia64,mips,s390,tile,alpha,arm64,sparc,parisc,powerpc}/Kconfig and
> arch/x86/um/Kconfig.
>
> I do not know if there are any bad consequences about
On 03/16, Andi Kleen wrote:
>
> On Sat, Mar 16, 2013 at 09:23:27PM +0100, Oleg Nesterov wrote:
> > On 03/15, Oleg Nesterov wrote:
> > >
> > > To remind, say, argv_split(poweroff_cmd) can race with sysctl changing
> > > this
> > > string, in this case it can write to the memory after argv[] array.
On Sat, Mar 16, 2013 at 09:23:27PM +0100, Oleg Nesterov wrote:
> On 03/15, Oleg Nesterov wrote:
> >
> > To remind, say, argv_split(poweroff_cmd) can race with sysctl changing this
> > string, in this case it can write to the memory after argv[] array. We can
> > fix this, or we can rewrite
set_task_comm() does memset() + wmb() before strlcpy(). This buys
nothing but adds the confusion, the comment is wrong.
- We do not need memset() to be "safe from non-terminating string
reads", the final char is always zero and we never change it.
- wmb() is paired with nothing, it can't not
On 03/15, Oleg Nesterov wrote:
>
> To remind, say, argv_split(poweroff_cmd) can race with sysctl changing this
> string, in this case it can write to the memory after argv[] array. We can
> fix this, or we can rewrite argv_split/free:
OK, please see 1/2.
And this reminds me about set_task_comm()
argv_split() allocates argv[count_argc(str)] array and assumes that
it will find the same number of arguments later. This is obviously
wrong if this string can be changed, say, by sysctl.
With this patch argv_split() kstrndup's the whole string and does
not split it, we simply replace the spaces
> On Sat, 2013-03-16 at 10:36 -0700, Eric Dumazet wrote:
> > On Fri, 2013-03-15 at 00:19 +0100, Eric Dumazet wrote:
> >
> > > Thanks thats really useful, we might miss to increment socket refcount
> > > in a timer setup.
> > >
> >
> > Hmm, please add following debugging patch as well
> >
> > diff
On Sat, Mar 16, 2013 at 6:38 PM, Randy Dunlap wrote:
> On 03/16/13 08:08, Thomas Meyer wrote:
>> Am Mittwoch, den 13.03.2013, 12:56 -0700 schrieb Randy Dunlap:
>>> On 03/13/13 10:15, Thomas Meyer wrote:
help text says:
"You should normally N here, unless you want to debug such a crash.
Hi Benson,
> From: Daniel Kurtz
>
> Use the kernel request_firmware API to allow a hotplug script to load new
> firmware into CYAPA device. When request_firmware is called by a driver,
> the kernel creates 'loading' and 'data' sysfs entries, and generates a
> firmware udev event containing the
On Sat, Mar 16, 2013 at 11:12:53AM -0700, Guenter Roeck wrote:
> Adding lm-sensors.
>
> On Sat, Mar 16, 2013 at 09:21:40AM -0700, Greg Kroah-Hartman wrote:
> > On Thu, Mar 14, 2013 at 08:24:45PM -0700, Guenter Roeck wrote:
> > > Provide devres functions for device_create_file, sysfs_create_file,
On Fri, Mar 15, 2013 at 07:19:56PM +0100, Oleg Nesterov wrote:
> On 03/15, Al Viro wrote:
> >
> > On Fri, Mar 15, 2013 at 12:07:14AM -0400, Sasha Levin wrote:
> > > Hi all,
> > >
> > > While fuzzing with trinity inside a KVM tools guest running latest -next
> > > kernel
> > > I've stumbled on the
At drivers/staging/zcache/Kconfig:13 it says
config RAMSTER
bool "Cross-machine RAM capacity sharing, aka peer-to-peer tmem"
depends on CONFIGFS_FS=y && SYSFS=y && !HIGHMEM && ZCACHE=y
depends on NET
# must ensure struct page is 8-byte aligned
select
Hi Benson,
> cyapa_check_is_operational and cyapa_create_input_dev are common to
> the probe and firmware update paths. Pull those out into
> cyapa_detect.
>
> Signed-off-by: Benson Leung
> ---
> drivers/input/mouse/cyapa.c | 57
> +++--
> 1 file
On 3/5/2013 2:34 PM, Arnd Bergmann wrote:
> On Tuesday 05 March 2013, Stephen Boyd wrote:
>> On 02/27/13 15:43, Stephen Warren wrote:
>>> Seems simple enough it doesn't really need many, but for Tegra,
>>> Acked-by: Stephen Warren
>>>
>>> Which kernel is this going into? It's possible Tegra will
On Sat, 2013-03-16 at 18:01 +, Al Viro wrote:
> On Sat, Mar 16, 2013 at 10:51:18AM -0700, Joe Perches wrote:
> > > This is certainly a neat trick.
> > >
> > > But I don't really like the fact that it complicates things for every
> > > future code reader, especially when a trivial change in
On 03/15, Paul E. McKenney wrote:
>
> On Fri, Mar 15, 2013 at 07:34:32PM +0100, Frederic Weisbecker wrote:
> > 2013/3/15 Oleg Nesterov :
> > >
> > > My point was: should we fix atomic_add_unless() then? If not, why
> > > should atomic_add_unless_negative() differ?
> >
> > They shouldn't differ I
On 03/16/2013 11:58 AM, Ming Lei wrote:
> On Sat, Mar 16, 2013 at 11:22 PM, Ming Lei wrote:
>> On Sat, Mar 16, 2013 at 11:07 PM, Sasha Levin
>> wrote:
>>>
>>> Hi Ming,
>>>
>>> With your patch:
>>>
>>>
>>> [ 1525.874312] release_sysfs_dirent sysfs_dirent use after free:
>>> ptysb-uevent
>>
>>
> From: Konrad Rzeszutek Wilk [mailto:kon...@darnok.org]
> Subject: Re: [PATCH v2 1/4] introduce zero filled pages handler
>
> > +
> > + for (pos = 0; pos < PAGE_SIZE / sizeof(*page); pos++) {
> > + if (page[pos])
> > + return false;
>
> Perhaps allocate a static
On 03/15, Frederic Weisbecker wrote:
>
> 2013/3/15 Oleg Nesterov :
> >
> > do_something() looks fine, if atomic_add_unless_negative() succeeds
> > we do have a barrier?
>
> Ok, I guess the guarantee of a barrier in case of failure is probably
> not needed. But since the only way to safely read the
Adding lm-sensors.
On Sat, Mar 16, 2013 at 09:21:40AM -0700, Greg Kroah-Hartman wrote:
> On Thu, Mar 14, 2013 at 08:24:45PM -0700, Guenter Roeck wrote:
> > Provide devres functions for device_create_file, sysfs_create_file,
> > and sysfs_create_group plus the respective remove functions.
> >
> >
On Sat, Mar 16, 2013 at 10:51:18AM -0700, Joe Perches wrote:
> > This is certainly a neat trick.
> >
> > But I don't really like the fact that it complicates things for every
> > future code reader, especially when a trivial change in the caller
> > would accomplish the same thing. Do you have
Hi Daniel,
Sorry, I can't understand your email...
On 03/15, Daniel Walker wrote:
>
> I was writing an application to ptrace a process which is dumping core
> from inside the pipe application for core_pattern.
This was never possible. And never will, I think.
> So for example you make core
Correct spelling typos in Documentation/sound/alsa
Signed-off-by: Masanari Iida
---
Documentation/sound/alsa/ALSA-Configuration.txt | 2 +-
Documentation/sound/alsa/seq_oss.html | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
On Sat, Mar 16, 2013 at 9:11 AM, Parag Warudkar wrote:
>
> This seems to trigger a WARN_ON during suspend/resume.
Ugh, yes. It's practically harmless, but it's ugly and technically
wrong (we're using wrmsr_on_cpu() on our current cpu, but in a context
where using it on anything else would be
On Sat, Mar 16, 2013 at 06:50:44AM -0700, Joe Perches wrote:
> Instead of converting the 800 or so uses of seq_printf with
> a constant format (without a % substitution) to seq_puts,
> maybe there's another way to slightly speed up these outputs.
>
> Taking a similar approach to commit abd84d60eb
On Sat, 2013-03-16 at 09:43 -0600, Bjorn Helgaas wrote:
> On Sat, Mar 16, 2013 at 7:50 AM, Joe Perches wrote:
> > Instead of converting the 800 or so uses of seq_printf with
> > a constant format (without a % substitution) to seq_puts,
> > maybe there's another way to slightly speed up these
On 03/17/2013 01:37 AM, Geert Uytterhoeven wrote:
> On Sat, Mar 16, 2013 at 6:03 PM, Jiang Liu wrote:
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -5130,13 +5130,13 @@ unsigned long free_reserved_area(unsigned long
>> start, unsigned long end,
>> pos = start =
On Sat, 2013-03-16 at 10:36 -0700, Eric Dumazet wrote:
> On Fri, 2013-03-15 at 00:19 +0100, Eric Dumazet wrote:
>
> > Thanks thats really useful, we might miss to increment socket refcount
> > in a timer setup.
> >
>
> Hmm, please add following debugging patch as well
>
> diff --git
On Sat, 2013-03-16 at 09:43 -0600, Bjorn Helgaas wrote:
> Checkpatch could look for additions of seq_printf() with constant formats.
Suggested-by: Bjorn Helgaas
Signed-off-by: Joe Perches
---
I don't know what perl version introduced $-[0] and $+[0]
so this may not work with older perl.
On Sat, 16 Mar 2013, Soeren Moch wrote:
> I implemented the counter. The max value is sampled at the beginning of
> end_free_itds(), the current counter value is sampled at the end of this
> function. Counter values w/o a max number are from the error path in
> itd_urb_transaction().
> The
On 03/16/13 08:08, Thomas Meyer wrote:
> Am Mittwoch, den 13.03.2013, 12:56 -0700 schrieb Randy Dunlap:
>> On 03/13/13 10:15, Thomas Meyer wrote:
>>> Hi,
>>>
>>> -*- Early printk
>>>
>>> help text says:
>>> "You should normally N here, unless you want to debug such a crash.
>>> (Depends on:
On Sat, Mar 16, 2013 at 6:03 PM, Jiang Liu wrote:
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5130,13 +5130,13 @@ unsigned long free_reserved_area(unsigned long start,
> unsigned long end,
> pos = start = PAGE_ALIGN(start);
> end &= PAGE_MASK;
> for (pages = 0;
On Fri, 2013-03-15 at 00:19 +0100, Eric Dumazet wrote:
> Thanks thats really useful, we might miss to increment socket refcount
> in a timer setup.
>
Hmm, please add following debugging patch as well
diff --git a/include/net/sock.h b/include/net/sock.h
index 14f6e9d..fe7c8a6 100644
---
Use free_reserved_area() to kill poison_init_mem() on ARM64.
Signed-off-by: Jiang Liu
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm64/mm/init.c | 17 +++--
1 file changed, 3 insertions(+), 14
Concentrate code to modify totalram_pages into the mm core, so the arch
memory initialized code doesn't need to take care of it. With these
changes applied, only following functions from mm core modify global
variable totalram_pages:
free_bootmem_late(), free_all_bootmem(),
Use common help functions to free reserved pages.
Signed-off-by: Jiang Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Yinghai Lu
Cc: Tang Chen
Cc: Wen Congyang
Cc: Jianguo Wu
Cc: linux-kernel@vger.kernel.org
---
arch/x86/mm/init.c| 14
Use common help functions to free reserved pages.
Signed-off-by: Jiang Liu
Cc: Ralf Baechle
Cc: Jiang Liu
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
---
arch/mips/powertv/asic/asic_devices.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git
Enhance adjust_managed_page_count() to adjust totalhigh_pages for
highmem pages. And change code which directly adjusts totalram_pages
to use adjust_managed_page_count() because it adjusts totalram_pages,
totalhigh_pages and zone->managed_pages altogether in a safe way.
Remove
As reported by https://bugzilla.kernel.org/show_bug.cgi?id=53501,
"MemTotal" from /proc/meminfo means memory pages managed by the buddy
system (managed_pages), but "MemTotal" from /sys/.../node/nodex/meminfo
means phsical pages present (present_pages) within the NUMA node.
There's a difference
Avoid using __free_pages_bootmem() at runtime, so we could easily
manage totalram_pages and zone->managed_pages. With this change applied,
__free_pages_bootmem() is only used by bootmem.c and nobootmem.c at
boot time, so mark it as __init. And other callers of
__free_pages_bootmem() have been
Commit "mm: introduce new field 'managed_pages' to struct zone" assumes
that all highmem pages will be freed into the buddy system by function
mem_init(). But that's not always true, some architectures may reserve
some highmem pages during boot. For example PPC may allocate highmem
pages for
Use common help functions to free reserved pages.
Signed-off-by: Jiang Liu
Cc: Florian Tobias Schandinat
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/video/acornfb.c | 28 ++--
1 file changed, 2 insertions(+), 26 deletions(-)
diff --git
Currently lock_memory_hotplug()/unlock_memory_hotplug() are used to
protect totalram_pages and zone->managed_pages. Other than the memory
hotplug driver, totalram_pages and zone->managed_pages may be modified
by Xen balloon, virtio_balloon etc at runtime. For those case, memory
hotplug lock is a
Address comments from last round of code review.
1) Enhance free_reserved_area() to support poisoning memory with zero.
This could be used to get rid of poison_init_mem() on ARM64.
2) Other minor fixes.
Signed-off-by: Jiang Liu
Cc: Geert Uytterhoeven
---
arch/alpha/kernel/sys_nautilus.c |
Use common help functions to free reserved pages.
Signed-off-by: Jiang Liu
Cc: Chris Metcalf
Cc: Wen Congyang
Cc: linux-kernel@vger.kernel.org
---
arch/tile/mm/init.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/tile/mm/init.c b/arch/tile/mm/init.c
index
The original goal of this patchset is to fix the bug reported by
https://bugzilla.kernel.org/show_bug.cgi?id=53501
Now it has also been expanded to reduce common code used by memory
initializion.
This is the third part, previous two patch sets could be accessed at:
On Sat, 2013-03-16 at 09:15 -0700, Joe Perches wrote:
> > > +int (seq_printf)(struct seq_file *m, const char *f, ...)
> >
> > That's rather ugly. Why not just #undef seq_printf before defining it?
>
> The whole thing is ugly, nasty and hackish.
> I kinda like it.
>
> But I don't like
During suspend below warning is seen when ath9k is active. Attached
patch fixes the warning for me. Tested to work across few
suspend-resume cycles.
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.642939] WARNING: at
net/mac80211/util.c:599 ieee80211_can_queue_work.isra.7+0x32/0x40
[mac80211]()
Mar
Hi Wim,
I found out the commit of this patch in the linux-next. Thank you for
improving the commit log.
I am sorry for all the trouble I have caused you and Paul.
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=84a9a694633692d54c8b969664ce8fd115fa09f9
Best regards,
On Thu, Mar 14, 2013 at 08:24:45PM -0700, Guenter Roeck wrote:
> Provide devres functions for device_create_file, sysfs_create_file,
> and sysfs_create_group plus the respective remove functions.
>
> Idea is to be able to drop calls to the remove functions from the various
> drivers using those
On Sat, Mar 16, 2013 at 08:46:03AM -0400, Eduardo Valentin wrote:
> Hello Dan,
>
> On 16-03-2013 05:05, Dan Carpenter wrote:
> >I've reviewed this set.
> >
> >I hate to make people redo whole patchset sets, and I hate
> >re-reviewing code. Obviously, I don't really like the bunny hop
> >patches
On Sat, 2013-03-16 at 11:57 -0400, Steven Rostedt wrote:
> My macro nastiness is contagious ;-)
True.
> On Sat, 2013-03-16 at 06:50 -0700, Joe Perches wrote:
> > +int (seq_printf)(struct seq_file *m, const char *f, ...)
>
> That's rather ugly. Why not just #undef seq_printf before defining it?
On Sat, 2013-03-16 at 09:43 -0600, Bjorn Helgaas wrote:
> This is certainly a neat trick.
Thank you ;-)
>
> But I don't really like the fact that it complicates things for every
> future code reader, especially when a trivial change in the caller
> would accomplish the same thing. Do you have
On Fri, Mar 15, 2013 at 9:26 AM, Stephane Eranian 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
On 03/16/2013 11:22 AM, Ming Lei wrote:
> On Sat, Mar 16, 2013 at 11:07 PM, Sasha Levin wrote:
>>
>> Hi Ming,
>>
>> With your patch:
>>
>>
>> [ 1525.874312] release_sysfs_dirent sysfs_dirent use after free: ptysb-uevent
>
> Sasha, thanks for your test.
>
> So is the oops always triggered on
On Sat, Mar 16, 2013 at 11:22 PM, Ming Lei wrote:
> On Sat, Mar 16, 2013 at 11:07 PM, Sasha Levin wrote:
>>
>> Hi Ming,
>>
>> With your patch:
>>
>>
>> [ 1525.874312] release_sysfs_dirent sysfs_dirent use after free: ptysb-uevent
>
> Sasha, thanks for your test.
>
> So is the oops always
My macro nastiness is contagious ;-)
On Sat, 2013-03-16 at 06:50 -0700, Joe Perches wrote:
> Instead of converting the 800 or so uses of seq_printf with
> a constant format (without a % substitution) to seq_puts,
> maybe there's another way to slightly speed up these outputs.
>
> Taking a
On Sat, Mar 16, 2013 at 7:50 AM, Joe Perches wrote:
> Instead of converting the 800 or so uses of seq_printf with
> a constant format (without a % substitution) to seq_puts,
> maybe there's another way to slightly speed up these outputs.
>
> Taking a similar approach to commit abd84d60eb
>
Since find_vma() may return NULL, so don't dereference the
returned 'vma' until it is valid.
The problem is introduced by the commit in linus tree:
6d7825b(mm/fremap.c: fix oops on error path).
Also mark vm_flags as ninitialized_var() to avoid compile
warning.
Cc: Tommi Rantala
Cc: Michel
On Sat, Mar 16, 2013 at 11:07 PM, Sasha Levin wrote:
>
> Hi Ming,
>
> With your patch:
>
>
> [ 1525.874312] release_sysfs_dirent sysfs_dirent use after free: ptysb-uevent
Sasha, thanks for your test.
So is the oops always triggered on this node of 'ptysb-uevent' or the node name
is changed
Hi Sebastian,
On 16.03.2013 14:10, Sebastian Hesselbarth wrote:
> This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> i2c programmable clock generators. Currently, the driver supports
> DT kernels only and VXCO feature of si5351b is not implemented. DT
> bindings selectively
Am Mittwoch, den 13.03.2013, 12:56 -0700 schrieb Randy Dunlap:
> On 03/13/13 10:15, Thomas Meyer wrote:
> > Hi,
> >
> > -*- Early printk
> >
> > help text says:
> > "You should normally N here, unless you want to debug such a crash.
> > (Depends on: EXPERT [=n])"
> >
> > How to normally N
On 03/16/2013 09:30 AM, Ming Lei wrote:
> On Sat, Mar 16, 2013 at 8:39 PM, Hillf Danton wrote:
>> init rb node before use due to empty node checked by rb_next().
>>
>> --- a/fs/sysfs/dir.cSat Mar 16 20:12:16 2013
>> +++ b/fs/sysfs/dir.cSat Mar 16 20:37:10 2013
>> @@ -396,6 +396,7 @@
On Saturday 16 March 2013, H Hartley Sweeten wrote:
> Remove the __init tags from the ep93xx_pwm_probe() and
> ep93xx_pwm_remove() functions to fix the section mismatch
> warnings.
>
> Use module_platform_driver() to remove the init/exit boilerplate.
>
> Signed-off-by: H Hartley Sweeten
> Cc:
On Saturday 16 March 2013, Sebastian Hesselbarth wrote:
> This driver adds a DT test clock consumer that exposes debugfs files to
> enable/disable and set/get rate of the attached programmable clock.
> During development of a i2c-attached clock generator I found it useful
> to debug the clock
1 - 100 of 356 matches
Mail list logo
