On Tue, Jan 21, 2014 at 04:22:52PM -0500, Paul Gortmaker wrote:
> None of these files are actually using any __init type directives
> and hence don't need to include . Most are just a
> left over from __devinit and __cpuinit removal, or simply due to
> code getting copied from one driver to the
cftype handling is about to be revamped. Relocate cgroup_rm_cftypes()
above cgroup_add_cftypes() in preparation. This is pure relocation.
Signed-off-by: Tejun Heo
---
kernel/cgroup.c | 70 -
1 file changed, 35 insertions(+), 35
Dynamic cftype addition and removal using cgroup_add/rm_cftypes()
respectively has been quite hairy due to vfs i_mutex. As i_mutex
nests outside cgroup_mutex, cgroup_mutex has to be released and
regrabbed on each iteration through the hierarchy complicating the
process. Now that i_mutex is no
Hello,
This patchset does a number of cleanups which are possible now that
cgroup is converted to kernfs. This patchset contains the following
eight patches.
0001-cgroup-warn-if-xattr-is-specified-with-sane_behavior.patch
0002-cgroup-relocate-cgroup_rm_cftypes.patch
cgroup->name handling became quite complicated over time involving
dedicated struct cgroup_name for RCU protection. Now that cgroup is
on kernfs, we can drop all of it and simply use kernfs_name/path() and
friends. Replace cgroup->name and all related code with kernfs
name/path constructs.
*
cftype_set was added primarily to allow registering the same cftype
array more than once for different subsystems. Nobody uses or needs
such thing and it's already broken because each cftype has ->ss
pointer which is initialized during registration.
Let's add list_head ->node to cftype and use
root->number_of_cgroups is currently an integer protected with
cgroup_mutex. Except for sanity checks and proc reporting, the only
place it's used is to check whether the root has any child during
remount; however, this is a bit flawed as the counter is not
decremented when the cgroup is unlinked
Currently, cgroupfs_root and its ->top_cgroup are separated reference
counted and the latter's is ignored. There's no reason to do this
separately. This patch removes cgroupfs_root->refcnt and destroys
cgroupfs_root when the top_cgroup is released.
* cgroup_put() updated to ignore
cgroup currently releases its kernfs_node when it gets removed. While
not buggy, this makes cgroup->kn access rules complicated than
necessary and leads to things like get/put protection around
kernfs_remove() in cgroup_destroy_locked(). In addition, we want to
use kernfs_name/path() and friends
css_from_dir() returns the matching css (cgroup_subsys_state) given a
dentry and subsystem. The function doesn't pin the css before
returning and requires the caller to be holding RCU read lock or
cgroup_mutex and handling pinning on the caller side.
Given that users of the function are likely
cgroup is scheduled to be converted to kernfs. After conversion,
cgroup_mount() won't use the sget() machinery for finding out existing
super_blocks but instead would do that directly. It'll search the
existing cgroupfs_roots for a matching one and create a new one iff a
match doesn't exist. To
Hi Linus,
Miscellaneous cleanups to the intel-mid code merged earlier in this
merge window.
The following changes since commit 4500cf60dbe4b7f514d11b24c3e1edfda2a6d69d:
Merge branch 'x86-intel-mid-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2014-01-20 12:06:50
Hello,
cgroup filesystem code was derived from the original sysfs
implementation which was heavily intertwined with vfs objects and
locking with the goal of re-using the existing vfs infrastructure.
That experiment turned out rather disastrous and sysfs switched, a
long time ago, to distributed
Currently cgroup uses combination of inode->i_mutex'es and
cgroup_mutex for synchronization. With the scheduled kernfs
conversion, i_mutex'es will be removed. Unfortunately, just using
cgroup_mutex isn't possible. All kernfs file and syscall operations,
most of which require grabbing
Factor out new root initialization into cgroup_setup_root() from
cgroup_mount(). This makes it easier to follow and will ease kernfs
conversion.
Signed-off-by: Tejun Heo
---
kernel/cgroup.c | 211 ++--
1 file changed, 113 insertions(+), 98
Now that cftypes and all tree modification operations are protected by
cgroup_tree_mutex, we can drop cgroup_mutex while deleting files and
directories. Drop cgroup_mutex over removals.
This doesn't make any noticeable difference now but is to help kernfs
conversion. In kernfs, removals are
cftype->max_write_len is used to extend the maximum size of writes.
It's interpreted in such a way that the actual maximum size is one
less than the specified value. The default size is defined by
CGROUP_LOCAL_BUFFER_SIZE. Its interpretation is quite confusing - its
value is decremented by 1 and
Straightforward updates to cgroup name handling in preparation of
kernfs conversion.
* cgroup_alloc_name() is updated to take const char * isntead of
dentry * for name source.
* cgroup name formatting is separated out into cgroup_file_name().
While at it, buffer length protection is added.
Hi Linus,
Despite the branch name, **most of these changes are to generic
code**. They change types so that they make an increasing amount of
the exported uapi kernel headers usable for libc.
The ARM64 people are also interested in these changes for their ILP32
ABI.
Acked-by: Catalin Marinas
mm/memory-failure.c::hwpoison_filter_task() has been reaching into
cgroup to extract the associated ino to be used as a filtering
criterion. This is an implementation detail which shouldn't be
depended upon from outside cgroup proper and is about to change with
the scheduled kernfs conversion.
Factor out cft->ss initialization into cgroup_init_cftypes() from
cgroup_add_cftypes() and add cft->ss clearing to cgroup_rm_cftypes()
through cgroup_exit_cftypes().
This doesn't make any meaningful difference now but the two new
functions will be expanded during kernfs transition.
Currently, cgroup_subsys->base_cftypes registration is different from
dynamic cftypes registartion. Instead of going through
cgroup_add_cftypes(), cgroup_init_subsys() invokes
cgroup_init_cftsets() which makes use of cgroup_subsys->base_cftset
which doesn't involve dynamic allocation.
While
Relocate cgroup_init/exit_root_id(), cgroup_free_root(),
cgroup_kill_sb() and cgroup_file_name() in preparation of kernfs
conversion.
These are pure relocations to make kernfs conversion easier to follow.
Signed-off-by: Tejun Heo
---
kernel/cgroup.c | 232
cgroup filesystem code was derived from the original sysfs
implementation which was heavily intertwined with vfs objects and
locking with the goal of re-using the existing vfs infrastructure.
That experiment turned out rather disastrous and sysfs switched, a
long time ago, to distributed
* Un-inline seq_css(). After kernfs conversion, the function will
need to dereference internal data structures.
* Add cgroup_get/put_root() and replace direct super_block->s_active
manipulatinos with them. These will be converted to kernfs_root
refcnting.
* Add cgroup_get/put() and
From: Rafael J. Wysocki
Since acpi_bus_notify() is executed on all notifications for all
devices anyway, rename acpi_hotplug_notify_cb() to acpi_system_notify()
and call it directly from acpi_bus_notify() instead of installing
notify handlers pointing to it for all hotplug devices.
This change
in this branch
to see if we'd be giving much up by axing the code?
https://github.com/hansendc/linux/tree/slub-nocmpxchg-for-Fengguang-20140128
I was talking with one of the distros about turning it off as well.
They mentioned that they saw a few performance regressions when it was
tu
From: Rafael J. Wysocki
Use the observation that the ACPI scan handler of the device object
in acpi_hotplug_notify_cb() can be obtained from that device object's
handler pointer and do not pass it as data to
acpi_install_hotplug_notify_handler() in acpi_scan_init_hotplug().
That allows the
From: Rafael J. Wysocki
The ACPI-based PCI hotplug (ACPIPHP) code currently attaches its
hotplug context objects directly to ACPI namespace nodes representing
hotplug devices. However, after recent changes causing struct
acpi_device to be created for every namespace node representing a
device
From: Rafael J. Wysocki
Use the same ACPI notify handler, acpi_hotplug_notify_cb() for both
ACPI-based PCI hotplug (ACPIPHP) and the generic ACPI-based hotplug
of devices. For PCI devices use the .hp.event() callback from
their ACPI companions that points to acpiphp_hotplug_event().
For other
From: Rafael J. Wysocki
Introduce a helper routine for installing acpi_hotplug_notify_cb()
as an ACPI notify handler for the given ACPI namespace node and make
acpi_scan_init_hotplug() use it.
This is to make subsequent changes easier to follow.
Signed-off-by: Rafael J. Wysocki
---
On Tuesday, January 28, 2014 06:43:58 PM Tejun Heo wrote:
> cgroup_subsys is a bit messier than it needs to be.
>
> * The name of a subsys can be different from its internal identifier
> defined in cgroup_subsys.h. Most subsystems use the matching name
> but three - cpu, memory and
On Tuesday, January 28, 2014 11:10:30 PM Rafael J. Wysocki wrote:
> Hi All,
>
> It looks like there's time for more adventurous stuff. :-)
>
> The following series is on top of the one I sent on Sunday:
>
> https://lkml.org/lkml/2014/1/26/191
>
> The final outcome of the patches below is that
net_prio is the only cgroup which is allowed to be built as a module.
The savings from allowing one controller to be built as a module are
tiny especially given that cgroup module support itself adds quite a
bit of complexity.
Given that none of other controllers has much chance of being made a
Hello,
This is the second take. Changes from the last take[L] are
* Updated to reflect changes in fe1217c4f3f7 ("net: net_cls: move
cgroupfs classid handling into core").
* Rebased on top of the current linus#master + some cgroup fix
patches.
There's only one controller which makes use of
cgroup_subsys is a bit messier than it needs to be.
* The name of a subsys can be different from its internal identifier
defined in cgroup_subsys.h. Most subsystems use the matching name
but three - cpu, memory and perf_event - use different ones.
* cgroup_subsys_id enums are postfixed with
cgroup_show_options() grabs cgroup_root_mutex to protect the options
changing while printing; however, holding root_mutex or not doesn't
really make much difference for the function. subsys_mask can be
atomically tested and most of the options aren't allowed to change
anyway once mounted.
The
cgroup_root_mutex was added to avoid deadlock involving namespace_sem
via cgroup_show_options(). It added a lot of overhead for the small
purpose of it and, because it's nested under cgroup_mutex, it has very
limited usefulness. The previous patch made cgroup_show_options() not
use
With module supported dropped from net_prio, no controller is using
cgroup module support. None of actual resource controllers can be
built as a module and we aren't gonna add new controllers which don't
control resources. This patch drops module support from cgroup.
* cgroup_[un]load_subsys()
It's no longer referenced outside cgroup core, so renaming is easy.
Let's rename it for consistency & brevity.
This patch is pure rename.
Signed-off-by: Tejun Heo
---
include/linux/cgroup.h | 4 ++--
kernel/cgroup.c| 20 ++--
2 files changed, 12 insertions(+), 12
Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
Signed-off-by: Peter De Schrijver
---
Documentation/ABI/testing/sysfs-driver-tegra-fuse |8 +
drivers/misc/fuse/Makefile|1 +
drivers/misc/fuse/tegra/Makefile |7 +
Add efuse bindings for Tegra20, Tegra30, Tegra114 and Tegra124.
Signed-off-by: Peter De Schrijver
---
.../devicetree/bindings/fuse/fuse-tegra.txt| 32
arch/arm/boot/dts/tegra114.dtsi|7
arch/arm/boot/dts/tegra124.dtsi
All fuse related functionality is now provided by the tegra fuse driver.
Hence all the fuse related files in mach-tegra can be removed.
Signed-off-by: Peter De Schrijver
---
arch/arm/mach-tegra/fuse.c| 252
arch/arm/mach-tegra/fuse.h| 61
Enable building the fuse drivers.
Signed-off-by: Peter De Schrijver
---
arch/arm/mach-tegra/Makefile |4
drivers/misc/Makefile|1 +
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index
All fuse related functionality will move to a driver in the following patches.
To prepare for this, export all the required functionality in a global header
file and move all users of fuse.h to tegra-soc.h
Signed-off-by: Peter De Schrijver
---
arch/arm/mach-tegra/cpuidle.c |2 +-
On Tue, Jan 28, 2014 at 09:49:06PM +0100, Borislav Petkov wrote:
> On Tue, Jan 28, 2014 at 12:25:15PM -0800, Linus Torvalds wrote:
> > Probably. And then we should make sure that allyesconfig/allmodconfig
> > don't pick it.
>
> I'd need to think about that a bit longer as scripts/kconfig/conf.c
Export APB DMA readl and writel. These are needed because we can't access
the fuses directly on Tegra20 without potentially causing a system hang.
Also have the APB DMA readl and writel return an error in case of a read
failure instead of just returning zero or ignore write failures.
This driver allows userspace to read the raw efuse data. Its userspace
interface is modelled after the sunxi_sid driver which provides similar
functionality for some Allwinner SoCs. It has been tested on
Tegra20 (ventana), Tegra30 (beaverboard) and Tegra114 (dalmore).
Changes since v1:
* Add
We're gonna need non-dir syscall callbacks, which will make dir_ops a
misnomer. Let's rename kernfs_dir_ops to kernfs_syscall_ops.
This is pure rename.
Signed-off-by: Tejun Heo
---
fs/kernfs/dir.c| 25 +
include/linux/kernfs.h | 18 +-
2 files
Add two super_block related syscall callbacks ->remount_fs() and
->show_options() to kernfs_syscall_ops. These simply forward the
matching super_operations.
Signed-off-by: Tejun Heo
---
fs/kernfs/mount.c | 23 +++
include/linux/kernfs.h | 3 +++
2 files changed, 26
Hello,
This patchset makes various updates in preparation of cgroup's kernfs
conversion. This patchset contains the following 9 patches.
0001-kernfs-invoke-dir_ops-while-holding-active-ref-of-th.patch
0002-kernfs-rename-kernfs_dir_ops-to-kernfs_syscall_ops.patch
On 01/28/2014 07:48 PM, Ingo Molnar wrote:
* David Rientjes wrote:
On Tue, 28 Jan 2014, Tang Chen wrote:
On-stack variable numa_kernel_nodes in numa_clear_kernel_node_hotplug()
was not initialized. So we need to initialize it.
Signed-off-by: Tang Chen
Tested-by: Gu Zheng
Reported-by:
A write to a kernfs_node is buffered through a kernel buffer. Writes
<= PAGE_SIZE are performed atomically, while larger ones are executed
in PAGE_SIZE chunks. While this is enough for sysfs, cgroup which is
scheduled to be converted to use kernfs needs a bit more control over
it.
This patch
kernfs_dir_ops are currently being invoked without any active
reference, which makes it tricky for the invoked operations to
determine whether the objects associated those nodes are safe to
access and will remain that way for the duration of such operations.
kernfs already has active_ref
Currently, kernfs_nodes are made visible to userland on creation,
which makes it difficult for kernfs users to atomically succeed or
fail creation of multiple nodes. In addition, if something fails
after creating some nodes, the created nodes might already be in use
and their active refs need to
kernfs_iop_lookup(), kernfs_dir_pos() and kernfs_dir_next_pos() were
missing kernfs_active() tests before using the found kernfs_node. As
deactivated state is currently visible only while a node is being
removed, this doesn't pose an actual problem. e.g. lookup succeeding
on a deactivated node
Add a private data field to be used by kernfs file operations. This
generally makes sense and will be used by cgroup.
Signed-off-by: Tejun Heo
---
include/linux/kernfs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
index 47f5235..9ca0f09
kernfs_node->parent and ->name are currently marked as "published"
indicating that kernfs users may access them directly; however, those
fields may get updated by kernfs_rename[_ns]() and unrestricted access
may lead to erroneous values or oops.
Protect ->parent and ->name updates with a irq-safe
Implement helpers to determine node from dentry and root from
super_block. Also add a kernfs_rename_ns() wrapper which assumes NULL
namespace. These generally make sense and will be used by cgroup.
Signed-off-by: Tejun Heo
---
fs/kernfs/dir.c| 18 ++
fs/kernfs/mount.c
On Tue, 28 Jan 2014 15:17:22 -0800 Dave Hansen wrote:
> Commit abca7c496 notes that we can not _set_ a page->counters
> directly, except when using a real double-cmpxchg. Doing so can
> lose updates to ->_count.
>
> That an absolute rule:
>
> You may not *set* page->counters except
kernfs_node->u.completion is used to notify deactivation completion
from kernfs_put_active() to kernfs_deactivate(). We now allow
multiple racing removals of the same node and the current removal
scheme is no longer correct - kernfs_remove() invocation may return
before the node is properly
KERNFS_REMOVED is used to mark half-initialized and dying nodes so
that they don't show up in lookups and deny adding new nodes under or
renaming it; however, its role overlaps that of deactivation.
It's necessary to deny addition of new children while removal is in
progress; however, this role
There currently are two mechanisms gating active ref lockdep
annotations - KERNFS_LOCKDEP flag and KERNFS_ACTIVE_REF type mask.
The former disables lockdep annotations in kernfs_get/put_active()
while the latter disables all of kernfs_deactivate().
While KERNFS_ACTIVE_REF also behaves as an
Sometimes it's necessary to implement a node which wants to delete
nodes including itself. This isn't straightforward because of kernfs
active reference. While a file operation is in progress, an active
reference is held and kernfs_remove() waits for all such references to
drain before
kernfs_addrm_cxt and the accompanying kernfs_addrm_start/finish() were
added because there were operations which should be performed outside
kernfs_mutex after adding and removing kernfs_nodes. The necessary
operations were recorded in kernfs_addrm_cxt and performed by
kernfs_addrm_finish();
kernfs_unmap_bin_file() is supposed to unmap all memory mappings of
the target file before kernfs_remove() finishes; however, it currently
is being called from kernfs_addrm_finish() and has the same race
problem as the original implementation of deactivation when there are
multiple removers - only
driver-core now supports synchrnous self-deletion of attributes and
the asynchrnous removal mechanism is scheduled for removal. Use it
instead of device_schedule_callback(). This makes "delete" behave
synchronously.
Signed-off-by: Tejun Heo
Cc: "James E.J. Bottomley"
Cc:
driver-core now supports synchrnous self-deletion of attributes and
the asynchrnous removal mechanism is scheduled for removal. Use it
instead of device_schedule_callback().
* Conversions in arch/s390/pci/pci_sysfs.c and
drivers/s390/block/dcssblk.c are straightforward.
*
driver-core now supports synchrnous self-deletion of attributes and
the asynchrnous removal mechanism is scheduled for removal. Use it
instead of device_schedule_callback(). This makes "remove" behave
synchronously.
Signed-off-by: Tejun Heo
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
---
All device_schedule_callback_owner() users are converted to use
device_remove_file_self(). Remove now unused
{sysfs|device}_schedule_callback_owner().
Signed-off-by: Tejun Heo
---
drivers/base/core.c| 33 --
fs/sysfs/file.c| 92
On Tue, Jan 28, 2014 at 06:10:59PM -0500, Boris Ostrovsky wrote:
> The patch seems to have fixed the problem.
Thanks, I'll add your Reported-and-tested-by.
>> I'll give it a spin. Apparently the problem is currently in
>> install_equiv_cpu_table() when we are trying to index into buf and
>> buf
The recursive nature of kernfs_remove() means that, even if
kernfs_remove() is not allowed to be called multiple times on the same
node, there may be race conditions between removal of parent and its
descendants. While we can claim that kernfs_remove() shouldn't be
called on one of the
Hello,
This is v4 of kernfs self-removal patchset. Unfortunately, this
series has a somewhat turbulent history. After sending out the first
iteration[1], I realized that cgroup's use case would need more
flexibility so I called it off and after a while posted the second
version[2] which
2014-01-28 Konrad Rzeszutek Wilk :
> On Mon, Jan 27, 2014 at 02:54:47PM +0100, Marek Szyprowski wrote:
>> Hello,
>>
>> On 2014-01-14 15:13, Akinobu Mita wrote:
>> >Calling dma_alloc_coherent() with __GFP_ZERO must return zeroed memory.
>> >
>> >But when the contiguous memory allocator (CMA) is
From: Dave Hansen
Commit abca7c496 notes that we can not _set_ a page->counters
directly, except when using a real double-cmpxchg. Doing so can
lose updates to ->_count.
That an absolute rule:
You may not *set* page->counters except via a cmpxchg.
Commit abca7c496 fixed this for the
Commit-ID: 790ed7421a973d9773dda8b4e5300c3f7f6fbcf7
Gitweb: http://git.kernel.org/tip/790ed7421a973d9773dda8b4e5300c3f7f6fbcf7
Author: David Cohen
AuthorDate: Tue, 28 Jan 2014 15:09:27 -0800
Committer: H. Peter Anvin
CommitDate: Tue, 28 Jan 2014 15:13:40 -0800
x86, intel-mid: Cleanup
On Tue, 2014-01-28 at 13:08 -0800, Davidlohr Bueso wrote:
> On Tue, 2014-01-28 at 11:13 -0800, Jason Low wrote:
> > v1->v2:
> > - Replace the previous patch that limits the # of times a thread can spin
> > with
> > !lock->owner with a patch that releases the mutex before holding the
> >
On 01/28/2014 04:37 PM, Boris Ostrovsky wrote:
On 01/28/2014 04:30 PM, Borislav Petkov wrote:
On Tue, Jan 28, 2014 at 04:05:20PM -0500, Boris Ostrovsky wrote:
Yes. This was a bug in our build environment. It is fixed now but I
put this bug back when I was testing your patch.
Right, that was
On 01/28/2014 03:19 PM, Tejun Heo wrote:
> arch/arm/mach-tegra/pm.c, kernel/power/console.c and mm/vmpressure.c
> were somehow getting slab.h indirectly through cgroup.h which in turn
> was getting it indirectly through xattr.h. A scheduled cgroup change
> drops xattr.h inclusion from cgroup.h
platform_ipc.h and platform_msic.h are wrongly declaring functions as
external and with 'weak' attribute. This patch does a cleanup on those
header files.
It should have no functional change.
Signed-off-by: David Cohen
Cc: Bjorn Helgaas
---
Guten Tag,
Mein Name ist Mr.SUN Zhijun, ich mit der Bank of China zu arbeiten. Ich brauche
Ihre Unterstützung in Durchführung einer Transaktion bei $ 18,5 Millionen
Dollar geschätzt, möchte ich Ihnen 30% der gesamten Mittel als Ausgleich für
Ihre Unterstützung in dieser Transaktion. Ich werde
On 01/28/2014 02:47 PM, Yinghai Lu wrote:
> On Tue, Jan 28, 2014 at 2:08 PM, Dave Hansen wrote:
>> On 01/28/2014 02:04 PM, Yinghai Lu wrote:
>>> In original bootmem wrapper for memblock, we have limit checking.
>>>
>>> Add it to memblock_virt_alloc, to address arm and x86 booting crash.
>>>
>> Do
On Tue, Jan 28 2014, Jens Axboe wrote:
> Hi Linus,
>
> This is the pull request for the core block IO changes for 3.14. The
> major piece in here is the immutable bio_ve series from Kent, the rest
> is fairly minor. It was supposed to go in last round, but various issues
> pushed it to this
On Tue, 2014-01-28 at 22:07 +0100, Peter Zijlstra wrote:
> On Tue, Jan 28, 2014 at 11:13:16AM -0800, Jason Low wrote:
> > Before a thread attempts mutex spin on owner, it is first added to a queue
> > using an MCS lock so that only 1 thread spins on owner at a time. However,
> > when
> > the
Hi Linus,
This is the block driver pull request for 3.14. It contains:
- bcache update from Kent Overstreet.
- Two bcache fixes from Nicholas Swenson.
- cciss pci init error fix from Andrew.
- Underflow fix in the parallel IDE pg_write code from Dan Carpenter.
I'm sure the 1 (or 0) users of
On Tue, Jan 28, 2014 at 2:08 PM, Dave Hansen wrote:
> On 01/28/2014 02:04 PM, Yinghai Lu wrote:
>> In original bootmem wrapper for memblock, we have limit checking.
>>
>> Add it to memblock_virt_alloc, to address arm and x86 booting crash.
>>
>> Signed-off-by: Yinghai Lu
>
> Do you have a git
Hi Linus,
This is the pull request for the core block IO changes for 3.14. The
major piece in here is the immutable bio_ve series from Kent, the rest
is fairly minor. It was supposed to go in last round, but various issues
pushed it to this release instead. The pull request contains:
- Various
From: Dave Hansen
On x86, SLUB creates and handles <=8192-byte allocations internally.
It passes larger ones up to the allocator. Saying "up to order 2" is,
at best, ambiguous. Is that order-1? Or (order-2 bytes)? Make
it more clear.
SLOB commits a similar sin. It *handles* page-size
On Mon, Jan 27, 2014 at 07:11:28PM +0100, Paolo Bonzini wrote:
> When KVM also presents Hyper-V features (which is useful because Windows
> behaves better), Linux guests prefer KVM because emulated leaves are at
> 0x4000 and the native ones are at 0x4100.
>
> However, Linux is then not
arch/arm/mach-tegra/pm.c, kernel/power/console.c and mm/vmpressure.c
were somehow getting slab.h indirectly through cgroup.h which in turn
was getting it indirectly through xattr.h. A scheduled cgroup change
drops xattr.h inclusion from cgroup.h and breaks compilation of these
three files. Add
On Tue, 2014-01-28 at 21:54 +0100, Peter Zijlstra wrote:
> On Tue, Jan 28, 2014 at 11:13:15AM -0800, Jason Low wrote:
> > This RFC patch disables preemption between modifying lock->owner and
> > locking/unlocking the mutex lock. This prevents situations where the owner
> > can preempt between
On Tue, 2014-01-28 at 12:23 -0800, Paul E. McKenney wrote:
> On Tue, Jan 28, 2014 at 11:13:13AM -0800, Jason Low wrote:
> > /*
> > * The cpu_relax() call is a compiler barrier which forces
> > @@ -514,6 +511,7 @@ __mutex_lock_common(struct mutex *lock, long state,
> >
On Tue, 28 Jan 2014 14:04:25 -0800 Yinghai Lu wrote:
> In original bootmem wrapper for memblock, we have limit checking.
>
> Add it to memblock_virt_alloc, to address arm and x86 booting crash.
>
> ...
>
> --- linux-2.6.orig/mm/memblock.c
> +++ linux-2.6/mm/memblock.c
> @@ -1077,6 +1077,9 @@
On Tue, Jan 28, 2014 at 2:04 PM, Yinghai Lu wrote:
> In original bootmem wrapper for memblock, we have limit checking.
>
> Add it to memblock_virt_alloc, to address arm and x86 booting crash.
>
> Signed-off-by: Yinghai Lu
Tested-by: Olof Johansson
Verified to resolve the crashes on boot on
On 01/28/2014 02:04 PM, Yinghai Lu wrote:
> In original bootmem wrapper for memblock, we have limit checking.
>
> Add it to memblock_virt_alloc, to address arm and x86 booting crash.
>
> Signed-off-by: Yinghai Lu
Do you have a git tree or cumulative set of patches that you'd like us
to all
From: Rafael J. Wysocki
The ACPI-based PCI hotplug (ACPIPHP) code currently attaches its
hotplug context objects directly to ACPI namespace nodes representing
hotplug devices. However, after recent changes causing struct
acpi_device to be created for every namespace node representing a
device
From: Rafael J. Wysocki
Use the same ACPI notify handler, acpi_hotplug_notify_cb() for both
ACPI-based PCI hotplug (ACPIPHP) and the generic ACPI-based hotplug
of devices. For PCI devices use the .hp.event() callback from
their ACPI companions that points to acpiphp_hotplug_event().
For other
From: Rafael J. Wysocki
Since acpi_bus_notify() is executed on all notifications for all
devices anyway, rename acpi_hotplug_notify_cb() to acpi_system_notify()
and call it directly from acpi_bus_notify() instead of installing
notify handlers pointing to it for all hotplug devices.
This change
Hi All,
It looks like there's time for more adventurous stuff. :-)
The following series is on top of the one I sent on Sunday:
https://lkml.org/lkml/2014/1/26/191
The final outcome of the patches below is that all ACPI hotplug notifications
for PCI devices and for core system things like CPU,
From: Rafael J. Wysocki
Use the observation that the ACPI scan handler of the device object
in acpi_hotplug_notify_cb() can be obtained from that device object's
handler pointer and do not pass it as data to
acpi_install_hotplug_notify_handler() in acpi_scan_init_hotplug().
That allows the
101 - 200 of 1194 matches
Mail list logo
