| Commit message (Collapse) | Author | Files | Lines |
|---|
|
Now that nobody use the "priv" arg passed to can_fork/cancel_fork/fork we can
kill CGROUP_CANFORK_COUNT/SUBSYS_TAG/etc and cgrp_ss_priv[] in copy_process().
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Because accounting resources for the root cgroup sometimes incurs
measureable overhead for workloads which don't care about cgroup and
often ends up calculating a number which is available elsewhere in a
slightly different form, cgroup is not in the business of providing
system-wide statistics. The pids controller which was introduced
recently was exposing "pids.current" at the root. This patch disable
accounting for root cgroup and removes the file from the root
directory.
While this is a userland visible behavior change, pids has been
available only in one version and was badly broken there, so I don't
think this will be noticeable. If it turns out to be a problem, we
can reinstate it for v1 hierarchies.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Aleksa Sarai <cyphar@cyphar.com>
|
|
enabling
Consider the following v2 hierarchy.
P0 (+memory) --- P1 (-memory) --- A
\- B
P0 has memory enabled in its subtree_control while P1 doesn't. If
both A and B contain processes, they would belong to the memory css of
P1. Now if memory is enabled on P1's subtree_control, memory csses
should be created on both A and B and A's processes should be moved to
the former and B's processes the latter. IOW, enabling controllers
can cause atomic migrations into different csses.
The core cgroup migration logic has been updated accordingly but the
controller migration methods haven't and still assume that all tasks
migrate to a single target css; furthermore, the methods were fed the
css in which subtree_control was updated which is the parent of the
target csses. pids controller depends on the migration methods to
move charges and this made the controller attribute charges to the
wrong csses often triggering the following warning by driving a
counter negative.
WARNING: CPU: 1 PID: 1 at kernel/cgroup_pids.c:97 pids_cancel.constprop.6+0x31/0x40()
Modules linked in:
CPU: 1 PID: 1 Comm: systemd Not tainted 4.4.0-rc1+ #29
...
ffffffff81f65382 ffff88007c043b90 ffffffff81551ffc 0000000000000000
ffff88007c043bc8 ffffffff810de202 ffff88007a752000 ffff88007a29ab00
ffff88007c043c80 ffff88007a1d8400 0000000000000001 ffff88007c043bd8
Call Trace:
[<ffffffff81551ffc>] dump_stack+0x4e/0x82
[<ffffffff810de202>] warn_slowpath_common+0x82/0xc0
[<ffffffff810de2fa>] warn_slowpath_null+0x1a/0x20
[<ffffffff8118e031>] pids_cancel.constprop.6+0x31/0x40
[<ffffffff8118e0fd>] pids_can_attach+0x6d/0xf0
[<ffffffff81188a4c>] cgroup_taskset_migrate+0x6c/0x330
[<ffffffff81188e05>] cgroup_migrate+0xf5/0x190
[<ffffffff81189016>] cgroup_attach_task+0x176/0x200
[<ffffffff8118949d>] __cgroup_procs_write+0x2ad/0x460
[<ffffffff81189684>] cgroup_procs_write+0x14/0x20
[<ffffffff811854e5>] cgroup_file_write+0x35/0x1c0
[<ffffffff812e26f1>] kernfs_fop_write+0x141/0x190
[<ffffffff81265f88>] __vfs_write+0x28/0xe0
[<ffffffff812666fc>] vfs_write+0xac/0x1a0
[<ffffffff81267019>] SyS_write+0x49/0xb0
[<ffffffff81bcef32>] entry_SYSCALL_64_fastpath+0x12/0x76
This patch fixes the bug by removing @css parameter from the three
migration methods, ->can_attach, ->cancel_attach() and ->attach() and
updating cgroup_taskset iteration helpers also return the destination
css in addition to the task being migrated. All controllers are
updated accordingly.
* Controllers which don't care whether there are one or multiple
target csses can be converted trivially. cpu, io, freezer, perf,
netclassid and netprio fall in this category.
* cpuset's current implementation assumes that there's single source
and destination and thus doesn't support v2 hierarchy already. The
only change made by this patchset is how that single destination css
is obtained.
* memory migration path already doesn't do anything on v2. How the
single destination css is obtained is updated and the prep stage of
mem_cgroup_can_attach() is reordered to accomodate the change.
* pids is the only controller which was affected by this bug. It now
correctly handles multi-destination migrations and no longer causes
counter underflow from incorrect accounting.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Cc: Aleksa Sarai <cyphar@cyphar.com>
|
|
freezer_attach()
If one or more tasks get moved into a frozen css, the frozen state is
cleared up from the destination css so that it can be reasserted once
the migrated tasks are frozen. freezer_attach() implements this in
two separate steps - clearing CGROUP_FROZEN on the target css while
processing each task and propagating the clearing upwards after the
task loop is done if necessary.
This patch merges the two steps. Propagation now takes place inside
the task loop. This simplifies the code and prepares it for the fix
of multi-destination migration.
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Now that we know that the forking task can't migrate amd the child is always
moved to the same cgroup by cgroup_post_fork()->css_set_move_task() we can
change pids_can_fork() and pids_cancel_fork() to just use task_css(current).
And since we no longer need to pin this css, we can remove pid_fork().
Note: the patch uses task_css_check(true), perhaps it makes sense to add a
helper or change task_css_set_check() to take cgroup_threadgroup_rwsem into
account.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Zefan Li <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
If the new child migrates to another cgroup before cgroup_post_fork() calls
subsys->fork(), then both pids_can_attach() and pids_fork() will do the same
pids_uncharge(old_pids) + pids_charge(pids) sequence twice.
Change copy_process() to call threadgroup_change_begin/threadgroup_change_end
unconditionally. percpu_down_read() is cheap and this allows other cleanups,
see the next changes.
Also, this way we can unify cgroup_threadgroup_rwsem and dup_mmap_sem.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Zefan Li <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
A css_set represents the relationship between a set of tasks and
css's. css_set never pinned the associated css's. This was okay
because tasks used to always disassociate immediately (in RCU sense) -
either a task is moved to a different css_set or exits and never
accesses css_set again.
Unfortunately, afcf6c8b7544 ("cgroup: add cgroup_subsys->free() method
and use it to fix pids controller") and patches leading up to it made
a zombie hold onto its css_set and deref the associated css's on its
release. Nothing pins the css's after exit and it might have already
been freed leading to use-after-free.
general protection fault: 0000 [#1] PREEMPT SMP
task: ffffffff81bf2500 ti: ffffffff81be4000 task.ti: ffffffff81be4000
RIP: 0010:[<ffffffff810fa205>] [<ffffffff810fa205>] pids_cancel.constprop.4+0x5/0x40
...
Call Trace:
<IRQ>
[<ffffffff810fb02d>] ? pids_free+0x3d/0xa0
[<ffffffff810f8893>] cgroup_free+0x53/0xe0
[<ffffffff8104ed62>] __put_task_struct+0x42/0x130
[<ffffffff81053557>] delayed_put_task_struct+0x77/0x130
[<ffffffff810c6b34>] rcu_process_callbacks+0x2f4/0x820
[<ffffffff810c6af3>] ? rcu_process_callbacks+0x2b3/0x820
[<ffffffff81056e54>] __do_softirq+0xd4/0x460
[<ffffffff81057369>] irq_exit+0x89/0xa0
[<ffffffff81876212>] smp_apic_timer_interrupt+0x42/0x50
[<ffffffff818747f4>] apic_timer_interrupt+0x84/0x90
<EOI>
...
Code: 5b 5d c3 48 89 df 48 c7 c2 c9 f9 ae 81 48 c7 c6 91 2c ae 81 e8 1d 94 0e 00 31 c0 5b 5d c3 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 <f0> 48 83 87 e0 00 00 00 ff 78 01 c3 80 3d 08 7a c1 00 00 74 02
RIP [<ffffffff810fa205>] pids_cancel.constprop.4+0x5/0x40
RSP <ffff88001fc03e20>
---[ end trace 89a4a4b916b90c49 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: disabled
---[ end Kernel panic - not syncing: Fatal exception in interrupt
Fix it by making css_set pin the associate css's until its release.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Dave Jones <davej@codemonkey.org.uk>
Reported-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Link: http://lkml.kernel.org/g/20151120041836.GA18390@codemonkey.org.uk
Link: http://lkml.kernel.org/g/5652D448.3080002@bmw-carit.de
Fixes: afcf6c8b7544 ("cgroup: add cgroup_subsys->free() method and use it to fix pids controller")
|
|
The following patch replaces all instances of time_t with time64_t i.e.
change the type used for representing time from 32-bit to 64-bit. All
32-bit kernels to date use a signed 32-bit time_t type, which can only
represent time until January 2038. Since embedded systems running 32-bit
Linux are going to survive beyond that date, we have to change all
current uses, in a backwards compatible way.
The patch also changes the function get_seconds() that returns a 32-bit
integer to ktime_get_seconds() that returns seconds as 64-bit integer.
The patch changes the type of ticks from time_t to u32. We keep ticks as
32-bits as the function uses 32-bit arithmetic which would prove less
expensive than 64-bit arithmetic and the function is expected to be
called atleast once every 32 seconds.
Signed-off-by: Heena Sirwani <heenasirwani@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Implement cgroup_get_from_path() using kernfs_walk_and_get() which
obtains a default hierarchy cgroup from its path. This will be used
to allow cgroup path based matching from outside cgroup proper -
e.g. networking and perf.
v2: Add EXPORT_SYMBOL_GPL(cgroup_get_from_path).
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Implement kernfs_walk_and_get() which is similar to
kernfs_find_and_get() but can walk a path instead of just a name.
v2: Use strlcpy() instead of strlen() + memcpy() as suggested by
David.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: David Miller <davem@davemloft.net>
|
|
cgroup_is_descendant() currently walks up the hierarchy and compares
each ancestor to the cgroup in question. While enough for cgroup core
usages, this can't be used in hot paths to test cgroup membership.
This patch adds cgroup->ancestor_ids[] which records the IDs of all
ancestors including self and cgroup->level for the nesting level.
This allows testing whether a given cgroup is a descendant of another
in three finite steps - testing whether the two belong to the same
hierarchy, whether the descendant candidate is at the same or a higher
level than the ancestor and comparing the recorded ancestor_id at the
matching level. cgroup_is_descendant() is accordingly reimplmented
and made inline.
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Now that cgroup v2 is almost out of the door, replace the development
documentation unified-hierarchy.txt with Documentation/cgroup.txt
which is a superset of unified-hierarchy.txt and authoritatively
describes all userland-visible aspects of cgroup.
v2: Updated to include all information from blkio-controller.txt and
list filesystems which support cgroup writeback as suggested by
Vivek.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
|
|
In preparation for adding cgroup2 documentation, rename
Documentation/cgroups/ to Documentation/cgroup-legacy/.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Li Zefan <lizefan@huawei.com>
|
|
With major controllers - cpu, memory and io - shaping up for the
unified hierarchy, cgroup2 is about ready to be, gradually, released
into the wild. Replace __DEVEL__sane_behavior flag which was used to
select the unified hierarchy with a separate filesystem type "cgroup2"
so that unified hierarchy can be mounted as follows.
mount -t cgroup2 none $MOUNT_POINT
The cgroup2 fs has its own magic number - 0x63677270 ("cgrp").
v2: Assign a different magic number to cgroup2 fs.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
|
|
6f60eade2433 ("cgroup: generalize obtaining the handles of and
notifying cgroup files") introduced cftype->file_offset so that the
handles for per-css file instances can be recorded. These handles
then can be used, for example, to generate file modified
notifications.
Unfortunately, it made the wrong assumption that files are created
once for a given css and removed on its destruction. Due to the
dependencies among subsystems, a css may be hidden from userland and
then later shown again. This is implemented by removing and
re-creating the affected files, so the associated kernfs_node for a
given cgroup file may change over time. This incorrect assumption led
to the corruption of css->files lists.
Reimplement cftype->file_offset handling so that cgroup_file->kn is
protected by a lock and updated as files are created and destroyed.
This also makes keeping them on per-cgroup list unnecessary.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: James Sedgwick <jsedgwick@fb.com>
Fixes: 6f60eade2433 ("cgroup: generalize obtaining the handles of and notifying cgroup files")
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Zefan Li <lizefan@huawei.com>
|
|
|
|
|
|
cpu_relax() on ARC has been barrier only for SMP (and no-op for UP). Per
recent discussions, it is safer to make it a compiler barrier
unconditionally.
Link: http://lkml.kernel.org/r/53A7D3AA.9020100@synopsys.com
Acked-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
|
|
ARCompact and ARCv2 only have ASL, while binutils used to support LSL as
a alias mnemonic.
Newer binutils (upstream) don't want to do that so replace it.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
|
|
Bus errors from userspace on ARCompact based cores are handled by core
as a high priority L2 interrupt but current code treated it as interrupt
Handling an interrupt like exception is certainly not going to go unnoticed.
(and it worked so far as we never saw a Bus error from userspace until
IPPK guys tested a DDR controller with ECC error detection etc hence
needed to explicitly trigger/handle such errors)
- So move mem_service exception handler from common code into ARCv2 code.
- In ARCompact code, define mem_service as L2 interrupt handler which
just drops down to pure kernel mode and goes of to enqueue SIGBUS
Reported-by: Nelson Pereira <npereira@synopsys.com>
Tested-by: Ana Martins <amartins@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
|
|
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
|
|
Now that the xattr handler is passed to the xattr handler operations, we
have access to the attribute name prefix, so simplify
f2fs_xattr_generic_list.
Also, f2fs_xattr_advise_list is only ever called for
f2fs_xattr_advise_handler; there is no need to double check for that.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Changman Lee <cm224.lee@samsung.com>
Cc: Chao Yu <chao2.yu@samsung.com>
Cc: linux-f2fs-devel@lists.sourceforge.net
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
Now that the xattr handler is passed to the xattr handler operations, we
have access to the attribute name prefix, so simplify the squashfs xattr
handlers a bit.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Phillip Lougher <phillip@squashfs.org.uk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
Now that the xattr handler is passed to the xattr handler operations, we
can use the same get and set operations for the user, trusted, and security
xattr namespaces. In those namespaces, we can access the full attribute
name by "reattaching" the name prefix the vfs has skipped for us. Add a
xattr_full_name helper to make this obvious in the code.
For the "system.posix_acl_access" and "system.posix_acl_default"
attributes, handler->prefix is the full attribute name; the suffix is the
empty string.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Ron Minnich <rminnich@sandia.gov>
Cc: Latchesar Ionkov <lucho@ionkov.net>
Cc: v9fs-developer@lists.sourceforge.net
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
The xattr_handler operations are currently all passed a file system
specific flags value which the operations can use to disambiguate between
different handlers; some file systems use that to distinguish the xattr
namespace, for example. In some oprations, it would be useful to also have
access to the handler prefix. To allow that, pass a pointer to the handler
to operations instead of the flags value alone.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
The vfs checks if a task has the appropriate access for get and set
operations, but it cannot do that for the list operation; the file system
must check for that itself.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
The list operations can never be called; they are even documented to be
unused.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
Ubifs installs a security xattr handler in sb->s_xattr but doesn't use the
generic_{get,set,list,remove}xattr inode operations needed for processing
this list of attribute handlers; the handler is never called. Instead,
ubifs uses its own xattr handlers which also process security xattrs.
Remove the dead code.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Richard Weinberger <richard@nod.at>
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: linux-mtd@lists.infradead.org
Cc: Subodh Nijsure <snijsure@grid-net.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
When a filesystem that contains POSIX ACLs is mounted without ACL support
(-o noacl), the appropriate behavior is not to list any existing POSIX ACL
xattrs. The return value for list xattr handlers in this case is 0, not an
error code: several filesystems that use the POSIX ACL xattr handlers do
not expect the list operation to fail.
Symlinks cannot have ACLs, so posix_acl_xattr_list will never be called for
symlinks in the first place.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
The get and set operations of the POSIX ACL xattr handlers failed to check
the attribute names, so all names with "system.posix_acl_access" or
"system.posix_acl_default" as a prefix were accepted. Reject invalid names
from now on.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
After merging the scsi tree, today's linux-next build (powerpc
allyesconfig) failed like this:
In file included from drivers/scsi/mpt3sas/mpt3sas_scsih.c:59:0:
drivers/scsi/mpt3sas/mpt3sas_scsih.c: In function '_scsih_io_done':
drivers/scsi/mpt3sas/mpt3sas_base.h:1414:1: error: inlining failed in call to always_inline 'mpt3sas_scsi_direct_io_get': function body not available
mpt3sas_scsi_direct_io_get(struct MPT3SAS_ADAPTER *ioc, u16 smid);
^
drivers/scsi/mpt3sas/mpt3sas_scsih.c:4448:6: error: called from here
if (mpt3sas_scsi_direct_io_get(ioc, smid) &&
^
In file included from drivers/scsi/mpt3sas/mpt3sas_scsih.c:59:0:
drivers/scsi/mpt3sas/mpt3sas_base.h:1416:1: error: inlining failed in call to always_inline 'mpt3sas_scsi_direct_io_set': function body not available
mpt3sas_scsi_direct_io_set(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 direct_io);
^
drivers/scsi/mpt3sas/mpt3sas_scsih.c:4454:3: error: called from here
mpt3sas_scsi_direct_io_set(ioc, smid, 0);
^
In file included from drivers/scsi/mpt3sas/mpt3sas_scsih.c:5
9:0:
drivers/scsi/mpt3sas/mpt3sas_base.h:1416:1: error: inlining failed in call to always_inline 'mpt3sas_scsi_direct_io_set': function body not available
mpt3sas_scsi_direct_io_set(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 direct_io);
^
drivers/scsi/mpt3sas/mpt3sas_scsih.c:4454:3: error: called from here
mpt3sas_scsi_direct_io_set(ioc, smid, 0);
^
Presumably caused by commit
c84b06a48c4d ("mpt3sas: Single driver module which supports both SAS 2.0 & SAS 3.0 HBAs")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
|
|
Since 4.3 introduced devm_memremap_pages() the pfns handled by DAX may
optionally have a struct page backing. When a mapped pfn reaches
vmf_insert_pfn_pmd() it fails with a crash signature like the following:
kernel BUG at mm/huge_memory.c:905!
[..]
Call Trace:
[<ffffffff812a73ba>] __dax_pmd_fault+0x2ea/0x5b0
[<ffffffffa01a4182>] xfs_filemap_pmd_fault+0x92/0x150 [xfs]
[<ffffffff811fbe02>] handle_mm_fault+0x312/0x1b50
Fix this by falling back to 4K mappings in the pfn_valid() case. Longer
term, vmf_insert_pfn_pmd() needs to grow support for architectures that
can provide a 'pmd_special' capability.
Cc: <stable@vger.kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
drm_of_component_probe()"
This reverts commit 52f5eb60940de889ce98a876f6933b574ead3225.
Rockchip drm can't work with generic drm_of_component_probe now
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
wasn't called
Seems the crtc helpers call drm_calc_timestamping_constants()
unconditionally even if the driver didn't initialize vblank support by
calling drm_vblank_init(). That used to be OK since the constants were
stored under drm_crtc.
However I broke this with
commit eba1f35dfe14 ("drm: Move timestamping constants into drm_vblank_crtc")
when I moved the constants to live inside the drm_vblank_crtc struct
instead. If drm_vblank_init() isn't called, we don't allocate these
structures, and so drm_calc_timestamping_constants() will oops.
Fix it by adding a check into drm_calc_timestamping_constants() to see
if vblank support was initialized at all. And to keep in line with other
such checks, also toss in a check and warn for the case where vblank
support was initialized, but the wrong number of crtcs was specified.
Fixes the following sort of oops:
BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0
IP: [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm]
PGD 0
Oops: 0002 [#1] SMP
Modules linked in: sr_mod cdrom mgag200(+) i2c_algo_bit drm_kms_helper ahci syscopyarea sysfillrect sysimgblt libahci fb_sys_fops bnx2x ttm tg3(+) mdio drm ptp sd_mod libata i2c_core pps_core libcrc32c hpsa dm_mirror dm_region_hash dm_log dm_mod
CPU: 0 PID: 418 Comm: kworker/0:2 Not tainted 4.3.0+ #1
Hardware name: HP ProLiant DL380 Gen9, BIOS P89 06/09/2015
Workqueue: events work_for_cpu_fn
task: ffff88046ca95500 ti: ffff88007830c000 task.ti: ffff88007830c000
RIP: 0010:[<ffffffffa014b266>] [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm]
RSP: 0018:ffff88007830f4e8 EFLAGS: 00010246
RAX: 0000000000fe4c00 RBX: ffff88006a849160 RCX: 0000000000000540
RDX: 0000000000000000 RSI: 000000000000fde8 RDI: ffff88006a849000
RBP: ffff88007830f518 R08: ffff88007830c000 R09: 00000001b87e3712
R10: 00000000000050c4 R11: 0000000000000000 R12: 0000000000fe4c00
R13: ffff88006a849000 R14: 0000000000000000 R15: 000000000000fde8
FS: 0000000000000000(0000) GS:ffff88046f800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000b0 CR3: 00000000019d6000 CR4: 00000000001406f0
Stack:
ffff88007830f518 ffff88006a849000 ffff880c69b90340 ffff880c69b90000
ffff880c69b90348 ffff880c69b90340 ffff88007830f748 ffffffffa042f7e7
ffff88006a849090 0000000000000000 ffff88006a849160 0000000000000000
Call Trace:
[<ffffffffa042f7e7>] drm_crtc_helper_set_mode+0x3d7/0x4b0 [drm_kms_helper]
[<ffffffffa04307d4>] drm_crtc_helper_set_config+0x8d4/0xb10 [drm_kms_helper]
[<ffffffffa01548d4>] drm_mode_set_config_internal+0x64/0x100 [drm]
[<ffffffffa043c342>] drm_fb_helper_pan_display+0xa2/0x280 [drm_kms_helper]
[<ffffffff81392c7b>] fb_pan_display+0xbb/0x170
[<ffffffff8138cf70>] bit_update_start+0x20/0x50
[<ffffffff8138b81b>] fbcon_switch+0x39b/0x590
[<ffffffff8140a3d0>] redraw_screen+0x1a0/0x240
[<ffffffff8140b30e>] do_bind_con_driver+0x2ee/0x310
[<ffffffff8140b651>] do_take_over_console+0x141/0x1b0
[<ffffffff81387377>] do_fbcon_takeover+0x57/0xb0
[<ffffffff8138c98b>] fbcon_event_notify+0x60b/0x750
[<ffffffff810a5599>] notifier_call_chain+0x49/0x70
[<ffffffff810a58dd>] __blocking_notifier_call_chain+0x4d/0x70
[<ffffffff810a5916>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff8139282b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff81394881>] register_framebuffer+0x1f1/0x330
[<ffffffffa043d9aa>] drm_fb_helper_initial_config+0x27a/0x3d0 [drm_kms_helper]
[<ffffffffa0469b4d>] mgag200_fbdev_init+0xdd/0xf0 [mgag200]
[<ffffffffa0468586>] mgag200_modeset_init+0x176/0x1e0 [mgag200]
[<ffffffffa0464659>] mgag200_driver_load+0x3f9/0x580 [mgag200]
[<ffffffffa014e067>] drm_dev_register+0xa7/0xb0 [drm]
[<ffffffffa015054f>] drm_get_pci_dev+0x8f/0x1e0 [drm]
[<ffffffffa046937b>] mga_pci_probe+0x9b/0xc0 [mgag200]
[<ffffffff813662d5>] local_pci_probe+0x45/0xa0
[<ffffffff8109afe4>] work_for_cpu_fn+0x14/0x20
[<ffffffff8109e13c>] process_one_work+0x14c/0x3c0
[<ffffffff8109eaa4>] worker_thread+0x244/0x470
[<ffffffff8168bfba>] ? __schedule+0x2aa/0x760
[<ffffffff8109e860>] ? rescuer_thread+0x310/0x310
[<ffffffff810a4438>] kthread+0xd8/0xf0
[<ffffffff810a4360>] ? kthread_park+0x60/0x60
[<ffffffff8169030f>] ret_from_fork+0x3f/0x70
[<ffffffff810a4360>] ? kthread_park+0x60/0x60
Code: f6 31 d2 41 89 c2 8b 83 b4 00 00 00 0f af c1 48 98 48 69 c0 40 42 0f 00 48 f7 f6 f6 43 74 10 41 89 c4 75 26 f6 05 9a 6f 03 00 01 <45> 89 96 b0 00 00 00 45 89 a6 ac 00 00 00 75 35 48 83 c4 08 5b
RIP [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm]
RSP <ffff88007830f4e8>
CR2: 00000000000000b0
Cc: Jeff Moyer <jmoyer@redhat.com>
Reported-by: Jeff Moyer <jmoyer@redhat.com>
References: http://lists.freedesktop.org/archives/dri-devel/2015-November/094217.html
Fixes: eba1f35dfe14 ("drm: Move timestamping constants into drm_vblank_crtc")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
There are several sound drivers that 'select ZONE_DMA'. This is
backwards as ZONE_DMA is an architecture capability exported to drivers.
Switch the polarity of the dependency to disable these drivers when the
architecture does not support ZONE_DMA. This was discovered in the
context of testing/enabling devm_memremap_pages() which depends on
ZONE_DEVICE. ZONE_DEVICE in turn depends on !ZONE_DMA.
Reported-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
A bunch of changes that I hope will help in understanding it
better for first-time readers.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
This masking prevents access to the end of the device via dax_do_io(),
and is unnecessary as arch_add_memory() would have rejected an unaligned
allocation.
Cc: <stable@vger.kernel.org>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Rather than punt on the numa node for these e820 ranges try to find a
better answer with memory_add_physaddr_to_nid() when it is available.
Cc: <stable@vger.kernel.org>
Reported-by: Boaz Harrosh <boaz@plexistor.com>
Tested-by: Boaz Harrosh <boaz@plexistor.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Commit ca321d1ca672 "ACPICA: Update NFIT table to rename a flags field"
performed a tree-wide s/ACPI_NFIT_MEM_ARMED/ACPI_NFIT_MEM_NOT_ARMED/
operation, but missed the tools/testing/nvdimm/ directory.
Cc: Bob Moore <robert.moore@intel.com>
Cc: Lv Zheng <lv.zheng@intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
hw_breakpoint_restore is only used within suspend.c, so it can be
declared static.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
split_pud and fixup_executable are only called from within mmu.c, so
they can be declared static.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
of_parse_and_init_cpus is only called from within smp.c, so it can be
declared static.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
We should always use linux/types.h instead of asm/types.h for
consistency, and Kbuild actually warns about it:
./usr/include/asm/kvm.h:35: include of <linux/types.h> is preferred over <asm/types.h>
This patch does as Kbuild asks us.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
On a cross-toolchain without glibc support, libgcov may not be
available, and attempting to build an arm64 kernel with GCOV
enabled then results in a build error:
/home/arnd/cross-gcc/lib/gcc/aarch64-linux/5.2.1/../../../../aarch64-linux/bin/ld: cannot find -lgcov
We don't really want to link libgcov into the vdso anyway, so
this patch just disables GCOV in the vdso directory, just as
we do for most other architectures.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
cpus_have_hwcap() is defined as a 'static' function an only used in
one place that is inside of an #ifdef, so we get a warning when
the only user is disabled:
arch/arm64/kernel/cpufeature.c:699:13: warning: 'cpus_have_hwcap' defined but not used [-Wunused-function]
This marks the function as __maybe_unused, so the compiler knows that
it can drop the function definition without warning about it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 37b01d53ceef ("arm64/HWCAP: Use system wide safe values")
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
The HDMI codec parser may create a phantom jack, but the helper
function snd_hda_jack_add_kctl() treats always as a normal jack. This
is superfluous as the jack query is executed at each time the jack
sync is performed.
Since the HDMI codec parser is the only caller of this function, it's
easier to change back this directly calling the original
__snd_hda_jack_add_kctl() with phantom_jack parameter.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
While the 5KE processors have never been taped out, they exists though
a CP0.PRId and experimental RTLs or QEMU implementations. Add a case
entry in the idle code, as they can use the standard idle loop like the
5K processors.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11099/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
Use appended DTB when available.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11115/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
For bootloaders that support booting only ELF kernels and load only ELF
segments to memory there is no easy way to supply DTB without kernel
recompilation. For that purpose, create a section called .appended_dtb
that can be later updated with board-specific DTB using binutils e.g. at
kernel installation time.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11114/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
While mips can't use the generic compat_siginfo_t directly because
its si_code and si_errno are inverted, we can still make it as
close to the generic version as possible. This makes it easier
to update when new members are added to siginfo_t.
The main changes are adding a missing _sigsys union member and
eliminating the unused _irix_sigchld one.
Signed-off-by: Amanieu d'Antras <amanieu@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11455/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
