Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
Hi all,
The writel/readl is too expensive especially on Cortex A9 w/ outer L2 cache.
This
introduce i2c read/write error on Marvell Berlin SoCs when there are L2 cache
maintenance operations at the same time.
In our internal berlin bsp, we just replaced readl/writel with the relaxed
version.
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(_cpu_notifier);
Recommend the usage of the new CPU hotplug callback registration APIs
(__register_cpu_notifier() etc), when subsystems need to also perform
initialization for already online CPUs. Provide examples of correct
and race-free ways of achieving this, and point out the kinds of code
that are
The following method of CPU hotplug callback registration is not safe
due to the possibility of an ABBA deadlock involving the cpu_add_remove_lock
and the cpu_hotplug.lock.
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
From: Gautham R. Shenoy
Add lockdep annotations for get/put_online_cpus() and
cpu_hotplug_begin()/cpu_hotplug_end().
Cc: Ingo Molnar
Reviewed-by: Oleg Nesterov
Signed-off-by: Gautham R. Shenoy
Signed-off-by: Srivatsa S. Bhat
---
kernel/cpu.c | 17 +
1 file changed, 17
Hi,
Many subsystems and drivers have the need to register CPU hotplug callbacks
from their init routines and also perform initialization for the CPUs that are
already online. But unfortunately there is no race-free way to achieve this
today.
For example, consider this piece of code:
On 02/13/2014 11:48 PM, Stefani Seibold wrote:
> Am Donnerstag, den 13.02.2014, 22:47 -0800 schrieb H. Peter Anvin:
>> Hi,
>>
>> I tried this patchset, but it fails to compile on i386 "make allyesconfig".
>>
>> -hpa
>>
>
> I tried "make allyseconfig" on my i386, but the resulting config will
Am Donnerstag, den 13.02.2014, 22:47 -0800 schrieb H. Peter Anvin:
> Hi,
>
> I tried this patchset, but it fails to compile on i386 "make allyesconfig".
>
> -hpa
>
I tried "make allyseconfig" on my i386, but the resulting config will
always set CONFIG_X86_64=y, so it fails with
On Thu, 2014-02-13 at 19:07 +, Mark Brown wrote:
> On Thu, Feb 13, 2014 at 10:14:00AM +0100, Krzysztof Kozlowski wrote:
>
> > - for (i = 0; i < S2MPS11_REGULATOR_CNT; i++)
> > + s2mps11->rdev = devm_kzalloc(>dev,
> > + sizeof(*s2mps11->rdev)*rdev_num, GFP_KERNEL);
> > +
On Thu 13-02-14 16:37:53, Linus Torvalds wrote:
> Is this whole thread still just for the crazy and pointless
> "max_sane_readahead()"?
>
> Or is there some *real* reason we should care?
>
> Because if it really is just for max_sane_readahead(), then for the
> love of God, let us just do this
>
On 02/12/2014 05:19 AM, Andrew Morton wrote:
There are three locks involved in two sequence:
a) pm suspend:
console_lock (@suspend_console())
cpu_add_remove_lock (@disable_nonboot_cpus())
cpu_hotplug.lock (@_cpu_down())
But but but. suspend_console() releases
On Thu, 2014-02-13 at 19:10 +, Mark Brown wrote:
> On Thu, Feb 13, 2014 at 10:14:02AM +0100, Krzysztof Kozlowski wrote:
> > Add support for S2MPS14 PMIC regulators to s2mps11 driver. The S2MPS14
> > has fewer BUCK-s and LDO-s than S2MPS11. It also does not support
> > controlling the BUCK ramp
Namjae Jeon writes:
>>> [...]
>>>
+ /* Release unwritten fallocated blocks on inode eviction. */
+ if (MSDOS_I(inode)->mmu_private < MSDOS_I(inode)->i_disksize) {
+ int err;
+ fat_truncate_blocks(inode,
From: Borislav Petkov
We do not enable the new efi memmap on 32-bit and thus we need to run
runtime_code_page_mkexec() unconditionally there. Fix that.
Reported-and-tested-by: Lejun Zhu
Cc: # v3.14+
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/efi.h | 2 ++
drivers/net/bonding/bond_options.c includes rwlock.h directly,
which is a nono, and which also breaks RT kernel build.
Signed-off-by: Mike Galbraith
---
diff --git a/drivers/net/bonding/bond_options.c
b/drivers/net/bonding/bond_options.c
index 11cb943222d5..c37878432717 100644
---
Hi Stephane,
On Thu, 13 Feb 2014 17:26:30 +0100, Stephane Eranian wrote:
> Hi,
>
> Your patch does solve the file consumption problem on my test case.
> We still open and do the ELF read 5 times.
>>> The first problem is why is dso__read_binary_type_filename()
>>> blindly returning success on
On Thu, 13 Feb 2014, Luis Ortega wrote:
> On Thu, Feb 13, 2014 at 05:24:23PM +0100, Luis Ortega wrote:
>> > I dare say either your bisect went sour or you don't have 945GM. Please
>> > verify your steps.
>>
>> Well, what can I say? I was careful when testing and the last kernel I
>> compiled
>>
On Thu, Feb 13, 2014 at 12:40 PM, Lee Jones wrote:
>> http://comments.gmane.org/gmane.linux.kernel/1645251
>>
>> Step 2 did not happen. I did not get any review for my change. I
>> literally submitted that within a couple of hours after the request.
>>
>> Could you please tell me what was wrong
node isn't changed, so we don't need to retreive this structure
everytime we move the object. Maybe compiler do this optimization,
but making it explicitly is better.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slab.c b/mm/slab.c
index 6d17cad..53d1a36 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@
This patchset does some clean-up and tries to remove lockdep annotation.
Patches 1~3 are just for really really minor improvement.
Patches 4~9 are for clean-up and removing lockdep annotation.
There are two cases that lockdep annotation is needed in SLAB.
1) holding two node locks
2) holding two
Factor out initialization of array cache to use it in following patch.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slab.c b/mm/slab.c
index 551d503..90bfd79 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -741,13 +741,8 @@ static void start_cpu_timer(int cpu)
}
}
-static struct array_cache
Currently, we use array_cache for alien_cache. Although they are mostly
similar, there is one difference, that is, need for spinlock.
We don't need spinlock for array_cache itself, but to use array_cache for
alien_cache, array_cache structure should have spinlock. This is needless
overhead, so
Now, we have separate alien_cache structure, so it'd be better to hold
the lock on alien_cache while manipulating alien_cache. After that,
we don't need the lock on array_cache, so remove it.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slab.c b/mm/slab.c
index c048ac5..ec1df4c 100644
---
I haven't heard that this alien cache lock is contended, but to reduce
chance of contention would be better generally. And with this change,
we can simplify complex lockdep annotation in slab code.
In the following patch, it will be implemented.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slab.c
In free_block(), if freeing object makes new free slab and number of
free_objects exceeds free_limit, we start to destroy this new free slab
with holding the kmem_cache node lock. Holding the lock is useless and,
generally, holding a lock as least as possible is good thing. I never
measure
clear_obj_pfmemalloc() takes the pointer to the object pointer as argument
to store masked value back into this address.
But this is useless, since we don't use this stored value anymore.
All we need is just masked value. So makes clear_obj_pfmemalloc()
just return masked value.
Signed-off-by:
Now, there is no code to hold two lock simultaneously, since
we don't call slab_destroy() with holding any lock. So, lockdep
annotation is useless now. Remove it.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slab.c b/mm/slab.c
index 9c9d4d4..f723a72 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@
slab_should_failslab() is called on every allocation, so to optimize it
is reasonable. We normally don't allocate from kmem_cache. It is just
used when new kmem_cache is created, so it's very rare case. Therefore,
add unlikely macro to help compiler optimization.
Signed-off-by: Joonsoo Kim
diff
It is odd to drop the spinlock when we scan (SWAP_CLUSTER_MAX - 1) th pfn
page. This may results in below situation while isolating migratepage.
1. try isolate 0x0 ~ 0x200 pfn pages.
2. When low_pfn is 0x1ff, ((low_pfn+1) % SWAP_CLUSTER_MAX) == 0, so drop
the spinlock.
3. Then, to complete
changes for v2
o include more experiment data in cover letter
o deal with vlastimil's comments mostly about commit description on 4/5
This patchset is related to the compaction.
patch 1 fixes contrary implementation of the purpose of compaction.
patch 2~4 are for optimization.
patch 5 is just
Purpose of compaction is to get a high order page. Currently, if we find
high-order page while searching migration target page, we break it to
order-0 pages and use them as migration target. It is contrary to purpose
of compaction, so disallow high-order page to be used for
migration target.
suitable_migration_target() checks that pageblock is suitable for
migration target. In isolate_freepages_block(), it is called on every
page and this is inefficient. So make it called once per pageblock.
suitable_migration_target() also checks if page is highorder or not,
but it's criteria for
It is just for clean-up to reduce code size and improve readability.
There is no functional change.
Acked-by: Vlastimil Babka
Signed-off-by: Joonsoo Kim
diff --git a/mm/compaction.c b/mm/compaction.c
index 56536d3..a1a9270 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -553,11 +553,7 @@
isolation_suitable() and migrate_async_suitable() is used to be sure
that this pageblock range is fine to be migragted. It isn't needed to
call it on every page. Current code do well if not suitable, but, don't
do well when suitable.
1) It re-checks isolation_suitable() on each page of a
Hi,
I tried this patchset, but it fails to compile on i386 "make allyesconfig".
-hpa
--
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
On Thursday 06 February 2014 03:36 AM, Srivatsa S. Bhat wrote:
> Subsystems that want to register CPU hotplug callbacks, as well as perform
> initialization for the CPUs that are already online, often do it as shown
> below:
>
> get_online_cpus();
>
> for_each_online_cpu(cpu)
>
Dear David :
Thanks all the same.
2014-02-14
liujunliang_ljl
发件人： David Miller
发送时间： 2014-02-14 07:42:24
收件人： sergei.shtylyov
抄送： liujunliang_ljl; thierry.reding; horms; joe; romieu; gregkh; netdev;
linux-usb; linux-kernel; sunhecheng
主题： Re: [PATCH] Fix
We abort direct reclaim if find the zone is ready for compaction.
Sometimes the zone is just a promoted highmem zone to force scan
pinning highmem, which is not the intended zone the caller want to
alloc page from. In this situation, setting aborted_reclaim to
indicate the caller turn back to
We promote sc->gfp_mask to __GFP_HIGHMEM to forcibly scan highmem if
there are too many buffer_heads pinning highmem. see: cc715d99e5
This patch restores sc->gfp_mask to its caller original value after
finishing the scan job, to avoid the impact on other invocations from
its upper caller, such as
At Thu, 13 Feb 2014 19:02:46 +0100,
rauchwo...@gmx.net wrote:
>
> Hi,
>
> this patch doesn't work. The sound is now muted after the resume (light is
> on).
> But the userspace knows nothing about it. (kmix shows the volume as umuted)
OK, scratch the last patch. I thought the mute LED is also
LM3631 regulator driver has 5 regulators.
One boost output and four LDOs are used for the display module.
Boost voltage is configurable but always on.
Supported operations for LDOs are enabled/disabled and voltage change.
Cc: Mark Brown
Signed-off-by: Milo Kim
---
drivers/regulator/Kconfig
Bindings for TI LMU, backlight, LM3631 regulator and LM3633 LED are added.
Cc: devicet...@vger.kernel.org
Cc: Bryan Wu
Cc: Jingoo Han
Cc: Lee Jones
Cc: Mark Brown
Cc: Samuel Ortiz
Signed-off-by: Milo Kim
---
.../devicetree/bindings/leds/leds-lm3633.txt | 39 +
LM3633 has 3 backlight strings and 11 bit dimming is supported.
PWM brightness control is also supported.
Common backlight driver is controlled by TI LMU backlight driver.
Only LM3633 specific code is implemented here.
Cc: Jingoo Han
Cc: Bryan Wu
Cc: Lee Jones
Signed-off-by: Milo Kim
---
LM3697 has 3 backlight strings and 11 bit dimming is supported.
PWM brightness control is also supported.
Common backlight driver is controlled by TI LMU backlight driver.
Only LM3697 specific code is implemented here.
Cc: Jingoo Han
Cc: Bryan Wu
Cc: Lee Jones
Signed-off-by: Milo Kim
---
LM3631 has 2 backlight strings and 11 bit dimming is supported.
PWM brightness control is also supported.
Common backlight driver is controlled by TI LMU backlight driver.
Only LM3631 specific code is implemented here.
Cc: Jingoo Han
Cc: Bryan Wu
Cc: Lee Jones
Signed-off-by: Milo Kim
---
LM3633 LED driver supports generic LED functions and pattern generation.
Pattern is generated by using LMU effect driver APIs.
Sysfs documentation is added.
Cc: Bryan Wu
Signed-off-by: Milo Kim
---
Documentation/leds/leds-lm3633.txt | 38 +++
drivers/leds/Kconfig | 10 +
LM3695 has 2 backlight strings and 11 bit dimming is supported.
Common backlight driver is controlled by TI LMU backlight driver.
Only LM3695 specific code is implemented here.
Cc: Jingoo Han
Cc: Bryan Wu
Cc: Lee Jones
Signed-off-by: Milo Kim
---
drivers/video/backlight/Kconfig |8
TI LMU (Lighting Management Unit) driver supports lighting devices such like
LM3532, LM3631, LM3633, LM3695 and LM3697.
LMU devices has common features as below.
- I2C interface for accessing device registers
- Hardware enable pin control
- Backlight brightness control
- Light effect
TI LMU backlight driver provides common driver features.
Chip specific configuration is handled by each backlight driver such like
LM3532, LM3631, LM3633, LM3695 and LM3697.
It supports common features as below.
- Consistent device control flow
- Control bank assignment from the platform data
LM3532 has 3 backlight strings and 8 bit dimming is supported.
PWM brightness control is also supported.
Common backlight driver is controlled by TI LMU backlight driver.
Only LM3532 specific code is implemented here.
Cc: Jingoo Han
Cc: Bryan Wu
Cc: Lee Jones
Signed-off-by: Milo Kim
---
TI LMU (Lighting Management Unit) driver supports lighting devices such like
LM3532, LM3631, LM3633, LM3695 and LM3697.
Enable pin Backlights PWM control Light effects Others
-- -- --- - --
LM3532 Yes Yes Yes
On 02/13/2014 03:55 PM, Thomas Gleixner wrote:
On Thu, 13 Feb 2014, Fernando Lopez-Lezcano wrote:
On 02/13/2014 02:25 PM, Thomas Gleixner wrote:
On Wed, 12 Feb 2014, Fernando Lopez-Lezcano wrote:
[771508.546449] RIP: 0010:[] []
smp_call_function_many+0x2ca/0x330
Can you decode the exact
Set TIF_MEMDIE tsk_thread flag before send kill signal to the
selected thread. This is to fit a usual code sequence and avoid
potential race issue.
Signed-off-by: Weijie Yang
---
drivers/staging/android/lowmemorykiller.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Johannes Weiner wrote:
> Thanks for the report. There is already a fix for this in -mm:
> http://marc.info/?l=linux-mm-commits=139180637114625=2
>
> It was merged on the 7th, so it should show up in -next... any day
> now?
That patch solved this bproblem but breaks build instead.
ERROR:
On 13.02.2014 [14:41:04 -0800], David Rientjes wrote:
> On Thu, 13 Feb 2014, Raghavendra K T wrote:
>
> > Thanks David, unfortunately even after applying that patch, I do not see
> > the improvement.
> >
> > Interestingly numa_mem_id() seem to still return the value of a
> > memoryless node.
> >
When device is booted using devicetree, platforms impacted by Erratum
2.1.1.128 is not detected easily in the mmc driver. This erratum
indicates that the module cannot do multi-block transfers. Platforms
such as LDP which use OMAP3 ES revision prior to ES3.0 are impacted by
this.
Provide a new
MMC1 is the only MMC interface available on the platform. Further,
since the platform is based on older revision of SoC which is not
capable of doing multi-block reads, mark it with compatibility for the
same and add pinmux to ensure that all relevant pins are configured
for non-MMC boot mode.
Originally reported in: https://patchwork.kernel.org/patch/3514851/
https://patchwork.kernel.org/patch/3514881/
ES3.0+ provides MMC controller which is fixed for multi-block reads,
however LDP platform
Looking at the various IP revision register information:
sdp2430: Revision: 1.2, Spec: 0.0,
Ping? :)
(2014/02/06 14:32), Masami Hiramatsu wrote:
> Hi,
>
> Here is the 3rd version of the series for handling local
> functions correctly with perf-probe. This version also
> includes distro debuginfo-file support (a small
> enhancement, based on existing feature).
>
> In this version, I
On Thu, Feb 13, 2014 at 9:34 PM, Ben Dooks wrote:
> On 13/02/14 03:03, Magnus Damm wrote:
>>
>> PCI: rcar: Recent driver patches from Ben Dooks and me
>>
>> [PATCH 01/08] PCI: rcar: check platform_get_irq() return code
>> [PATCH v2 02/08] PCI: rcar: add error interrupt handling
>> [PATCH 03/08]
From: Haiyang Zhang
Date: Wed, 12 Feb 2014 16:54:27 -0800
> Without this patch, the "cat /sys/class/net/ethN/operstate" shows
> "unknown", and "ethtool ethN" shows "Link detected: yes", when VM
> boots up with or without vNIC connected.
>
> This patch fixed the problem.
>
> Signed-off-by:
(more than usual) the powerpc allyesconfig build.
Changes since 20140213:
The wireless tree gained a conflict against Linus' tree.
The powerpc tree still had its build failure.
The mfd-lj tree lost its build failure but gained another so I used the
version from next-20140210.
The wireless-next
commit 6c31b21 (mmc: omap_hsmmc: remove access to SYSCONFIG register)
introduced an smatch(http://smatch.sf.net) warning for the following:
drivers/mmc/host/omap_hsmmc.c:608 omap_hsmmc_context_restore() warn: add
some parenthesis here?
drivers/mmc/host/omap_hsmmc.c:608
Hi Stephane,
On Thu, 13 Feb 2014 17:26:30 +0100, Stephane Eranian wrote:
> Hi,
>
> Your patch does solve the file consumption problem on my test case.
> We still open and do the ELF read 5 times.
Cool. Could you also confirm what's the problem case - whether it's
stripped or static linked?
>
>
Users have reported being unable to trace non-signed modules loaded
within a kernel supporting module signature.
This is caused by tracepoint.c:tracepoint_module_coming() refusing to
take into account tracepoints sitting within force-loaded modules
(TAINT_FORCED_MODULE). The reason for this
On 02/13/2014 08:01 PM, Tomasz Figa wrote:
Hi Alexandre,
On 07.02.2014 05:35, Alexandre Courbot wrote:
Some firmwares do not put the CPU into idle mode themselves, but still
need to be informed that the CPU is about to enter idle mode before this
happens. Add a prepare_idle() operation to the
From: Greg KH
Date: Thu, 13 Feb 2014 16:03:20 -0800
> So how about just "open coding" a kref for this structure, as it wants
> something that doesn't fit into the kref model, and should be pretty
> simple to do (you can ensure you get the locking right, unlike almost
> all users of krefs, as Al
On Wed, 2014-02-12 at 10:19 +0100, Peter Zijlstra wrote:
> > I don't know the specifics of your example, but from how I understand
> > it, I don't see a problem if the compiler can prove that the store will
> > always happen.
> >
> > To be more specific, if the compiler can prove that the store
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
drivers/spi/spi.c between commit 513273538a6c ("spi: Make max_tx and
max_rx the same type") from the spi tree and commit "drivers/spi/spi.c:
fix max() warning" from the akpm tree.
I fixed it up (I used the version from the
Since idle_balance() will release rq-lock for a while, there is a chance that
RT/DL tasks will be enqueued and ask for the resched, the func used to be
invoked ahead of pick_next_task(), which will make sure we drop into the
bottom-half inside pick_next_task().
Now since idle_balance() was done
>> [...]
>>
>>> + /* Release unwritten fallocated blocks on inode eviction. */
>>> + if (MSDOS_I(inode)->mmu_private < MSDOS_I(inode)->i_disksize) {
>>> + int err;
>>> + fat_truncate_blocks(inode, MSDOS_I(inode)->mmu_private);
>>> +
Hi Yoshihiro,
On Thu, 13 Feb 2014 10:28:58 +0900, Yoshihiro YUNOMAE wrote:
> Introduce nr_saved_cmdlines I/F for changing the number of pid-comm list.
> saved_cmdlines can store 128 command names using SAVED_CMDLINES now, but
> 'no-existing processes' names are often lost in saved_cmdlines when
Found another buffer overflow in this code that was introduced by
e3756477aec028427fec767957c0d4b6cfb87208 trying to solve a related overflow.
strace still shows a problem:
syslog(0x3, 0x7fffd65375d0, 0x1000) = 4107
The first record output was in the middle of a LOG_CONT line:
On Thu, Feb 13, 2014 at 12:20 PM, Daniel Borkmann wrote:
> On 02/07/2014 02:20 AM, Alexei Starovoitov wrote:
> ...
>>
>> Hi Daniel,
>
>
> Thanks for your answer and sorry for the late reply.
>
>
>> Thank you for taking a look. Good questions. I had the same concerns.
>> Old BPF was carefully
On Thu, 2014-02-13 at 18:01 -0800, Paul E. McKenney wrote:
> On Thu, Feb 13, 2014 at 12:03:57PM -0800, Torvald Riegel wrote:
> > On Wed, 2014-02-12 at 16:23 -0800, Paul E. McKenney wrote:
> > > On Wed, Feb 12, 2014 at 12:22:53PM -0800, Linus Torvalds wrote:
> > > > On Wed, Feb 12, 2014 at 10:07
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
mm/memcontrol.c between commit e61734c55c24 ("cgroup: remove
cgroup->name") from the cgroup tree and commit 05d3a02a1a0d ("memcg:
change oom_info_lock to mutex") from the akpm-current tree.
I fixed it up (see below)
Commit-ID: 80375980f1608f43b47abc2671456b23ec68c434
Gitweb: http://git.kernel.org/tip/80375980f1608f43b47abc2671456b23ec68c434
Author: Joe Mario
AuthorDate: Sat, 8 Feb 2014 09:01:09 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:24:50 -0800
lto: Handle LTO common
Hi Linus,
On 13.02.2014 [16:37:53 -0800], Linus Torvalds wrote:
> Is this whole thread still just for the crazy and pointless
> "max_sane_readahead()"?
>
> Or is there some *real* reason we should care?
There is an open issue on powerpc with memoryless nodes (inasmuch as we
can have them, but
Commit-ID: 1e64ff42ea3d8d2fc8aa71f9717b3c1cb6c2f893
Gitweb: http://git.kernel.org/tip/1e64ff42ea3d8d2fc8aa71f9717b3c1cb6c2f893
Author: Andi Kleen
AuthorDate: Sat, 8 Feb 2014 09:01:15 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:25:03 -0800
Kbuild, lto: Disable LTO
Commit-ID: ef178f9238b142cc1020265e176b20d27fd02ba9
Gitweb: http://git.kernel.org/tip/ef178f9238b142cc1020265e176b20d27fd02ba9
Author: Andi Kleen
AuthorDate: Sat, 8 Feb 2014 09:01:17 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:25:05 -0800
Kbuild, lto: Handle basic
Commit-ID: 8564ed2b3888176ac323eefea1722003daeba3d3
Gitweb: http://git.kernel.org/tip/8564ed2b3888176ac323eefea1722003daeba3d3
Author: Andi Kleen
AuthorDate: Sat, 8 Feb 2014 09:01:14 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:25:02 -0800
Kbuild, lto: Add a gcc-ld
Commit-ID: ccbef1674a1579842c7dbdf554efca85d2cd245a
Gitweb: http://git.kernel.org/tip/ccbef1674a1579842c7dbdf554efca85d2cd245a
Author: Andi Kleen
AuthorDate: Sat, 8 Feb 2014 09:01:13 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:25:00 -0800
Kbuild, lto: add
Commit-ID: 77ab21adae509c5540956729e2d03bc1a59bc82a
Gitweb: http://git.kernel.org/tip/77ab21adae509c5540956729e2d03bc1a59bc82a
Author: Andi Kleen
AuthorDate: Sat, 8 Feb 2014 09:01:11 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:24:56 -0800
Kbuild, lto, workaround:
Commit-ID: 58edae3aac9f2ccd1afb12ea08127e840a0a706c
Gitweb: http://git.kernel.org/tip/58edae3aac9f2ccd1afb12ea08127e840a0a706c
Author: Andi Kleen
AuthorDate: Sat, 8 Feb 2014 09:01:10 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:24:53 -0800
lto: Disable LTO for
Commit-ID: ef1b893c29d0dba778f67ad97b554b37f9108dcc
Gitweb: http://git.kernel.org/tip/ef1b893c29d0dba778f67ad97b554b37f9108dcc
Author: Andi Kleen
AuthorDate: Sat, 8 Feb 2014 09:01:08 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:24:13 -0800
lto, workaround: Add
Commit-ID: 7d02b490e93c199a15b3c4bce1c393588c1300ca
Gitweb: http://git.kernel.org/tip/7d02b490e93c199a15b3c4bce1c393588c1300ca
Author: Andi Kleen
AuthorDate: Sat, 8 Feb 2014 09:01:12 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:24:58 -0800
Kbuild, lto: Drop .number
Commit-ID: 67424d5a22124fa2d115faa8f32d12506989628f
Gitweb: http://git.kernel.org/tip/67424d5a22124fa2d115faa8f32d12506989628f
Author: Andi Kleen
AuthorDate: Sat, 8 Feb 2014 09:01:05 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:21:57 -0800
x86, lto: Disable LTO for
Commit-ID: 128ea04a9885af9629059e631ddf0cab4815b589
Gitweb: http://git.kernel.org/tip/128ea04a9885af9629059e631ddf0cab4815b589
Author: Andi Kleen
AuthorDate: Sat, 8 Feb 2014 09:01:07 +0100
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 20:21:59 -0800
lto: Make asmlinkage
[Just adding Tejun]
On Fri, 14 Feb 2014 15:25:57 +1100 Stephen Rothwell
wrote:
>
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in
> kernel/cpuset.c between commit d66393e54e0a ("cpuset: use
> css_task_iter_start/next/end() instead of css_scan_tasks()") from
I am about to commit the patches before this except 02/17 and 12/17 to
tip:x86/asmlinkage; however, I figure we need a new 02/17 before
committing the actual LTO patches to avoid build breakage.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
1 - 100 of 1502 matches
Mail list logo
