Re: [ PATCH ] Documentation: fixed doc-build warnings
kushagra...@outlook.com wrote: > @@ -256,7 +256,6 @@ struct fscache_cookie *fscache_acquire_cookie(struct > fscache_volume *volume, > > /** > * fscache_use_cookie - Request usage of cookie attached to an object > - * @object: Object description > * @will_modify: If cache is expected to be modified locally > * > * Request usage of the cookie attached to an object. The caller should tell > @@ -272,7 +271,6 @@ static inline void fscache_use_cookie(struct > fscache_cookie *cookie, > > /** > * fscache_unuse_cookie - Cease usage of cookie attached to an object > - * @object: Object description > * @aux_data: Updated auxiliary data (or NULL) > * @object_size: Revised size of the object (or NULL) > * Just deleting these lines is the wrong thing to do. They should instead mention the cookie parameter. David
Re: [RFC PATCH 14/68] vfs: Convert drm to use the new mount API
Hi Al, I wonder if it would be possible to extend anon_inodes to return just an anonymous inode, thereby allowing the drm filesystem to be removed in favour of just using an anon_inode. David ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] wake_up_var() memory ordering
Peter Zijlstra wrote:
> I tried using wake_up_var() today and accidentally noticed that it
> didn't imply an smp_mb() and specifically requires it through
> wake_up_bit() / waitqueue_active().
Thinking about it again, I'm not sure why you need to add the barrier when
wake_up() (which this is a wrapper around) is required to impose a barrier at
the front if there's anything to wake up (ie. the wait queue isn't empty).
If this is insufficient, does it make sense just to have wake_up*() functions
do an unconditional release or full barrier right at the front, rather than it
being conditional on something being woken up?
> @@ -619,9 +614,7 @@ static int dvb_usb_fe_sleep(struct dvb_frontend *fe)
> err:
> if (!adap->suspend_resume_active) {
> adap->active_fe = -1;
I'm wondering if there's a missing barrier here. Should the clear_bit() on
the next line be clear_bit_unlock() or clear_bit_release()?
> - clear_bit(ADAP_SLEEP, &adap->state_bits);
> - smp_mb__after_atomic();
> - wake_up_bit(&adap->state_bits, ADAP_SLEEP);
> + clear_and_wake_up_bit(ADAP_SLEEP, &adap->state_bits);
> }
>
> dev_dbg(&d->udev->dev, "%s: ret=%d\n", __func__, ret);
> diff --git a/fs/afs/fs_probe.c b/fs/afs/fs_probe.c
> index cfe62b154f68..377ee07d5f76 100644
> --- a/fs/afs/fs_probe.c
> +++ b/fs/afs/fs_probe.c
> @@ -18,6 +18,7 @@ static bool afs_fs_probe_done(struct afs_server *server)
>
> wake_up_var(&server->probe_outstanding);
> clear_bit_unlock(AFS_SERVER_FL_PROBING, &server->flags);
> + smp_mb__after_atomic();
> wake_up_bit(&server->flags, AFS_SERVER_FL_PROBING);
> return true;
> }
Looking at this and the dvb one, does it make sense to stick the release
semantics of clear_bit_unlock() into clear_and_wake_up_bit()?
Also, should clear_bit_unlock() be renamed to clear_bit_release() (and
similarly test_and_set_bit_lock() -> test_and_set_bit_acquire()) if we seem to
be trying to standardise on that terminology.
David
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/38] VFS: Convert trivial filesystems and more
Hi Al, Here's a set of patches that: (1) Provides a convenience member in struct fs_context that is OR'd into sb->s_iflags by sget_fc(). (2) Provides a convenience vfs_init_pseudo_fs_context() helper function for doing most of the work in mounting a pseudo filesystem. (3) Converts all the trivial filesystems that have no arguments to fs_context. (4) Converts binderfs (which was trivial before January). (5) Converts ramfs, tmpfs, rootfs and devtmpfs. (6) Kills off mount_pseudo(), mount_pseudo_xattr(), mount_ns(), sget_userns(). The patches can be found here also: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git on branch: mount-api-viro David --- David Howells (38): vfs: Provide sb->s_iflags settings in fs_context struct vfs: Provide a mount_pseudo-replacement for fs_context vfs: Convert aio to fs_context vfs: Convert anon_inodes to fs_context vfs: Convert bdev to fs_context vfs: Convert nsfs to fs_context vfs: Convert pipe to fs_context vfs: Convert zsmalloc to fs_context vfs: Convert sockfs to fs_context vfs: Convert dax to fs_context vfs: Convert drm to fs_context vfs: Convert ia64 perfmon to fs_context vfs: Convert cxl to fs_context vfs: Convert ocxlflash to fs_context vfs: Convert virtio_balloon to fs_context vfs: Convert btrfs_test to fs_context vfs: Kill off mount_pseudo() and mount_pseudo_xattr() vfs: Use sget_fc() for pseudo-filesystems vfs: Convert binderfs to fs_context vfs: Convert nfsctl to fs_context vfs: Convert rpc_pipefs to fs_context vfs: Kill off mount_ns() vfs: Kill sget_userns() vfs: Convert binfmt_misc to fs_context vfs: Convert configfs to fs_context vfs: Convert efivarfs to fs_context vfs: Convert fusectl to fs_context vfs: Convert qib_fs/ipathfs to fs_context vfs: Convert ibmasmfs to fs_context vfs: Convert oprofilefs to fs_context vfs: Convert gadgetfs to fs_context vfs: Convert xenfs to fs_context vfs: Convert openpromfs to fs_context vfs: Convert apparmorfs to fs_context vfs: Convert securityfs to fs_context vfs: Convert selinuxfs to fs_context vfs: Convert smackfs to fs_context tmpfs, devtmpfs, ramfs, rootfs: Convert to fs_context arch/ia64/kernel/perfmon.c | 14 + drivers/android/binderfs.c | 173 +--- drivers/base/devtmpfs.c| 16 + drivers/dax/super.c| 13 + drivers/gpu/drm/drm_drv.c | 14 + drivers/infiniband/hw/qib/qib_fs.c | 26 ++ drivers/misc/cxl/api.c | 10 - drivers/misc/ibmasm/ibmasmfs.c | 21 +- drivers/oprofile/oprofilefs.c | 20 +- drivers/scsi/cxlflash/ocxl_hw.c| 21 +- drivers/usb/gadget/legacy/inode.c | 21 +- drivers/virtio/virtio_balloon.c| 19 +- drivers/xen/xenfs/super.c | 21 +- fs/aio.c | 15 + fs/anon_inodes.c | 12 + fs/binfmt_misc.c | 20 +- fs/block_dev.c | 14 + fs/btrfs/tests/btrfs-tests.c | 13 + fs/configfs/mount.c| 20 +- fs/efivarfs/super.c| 20 +- fs/fuse/control.c | 20 +- fs/libfs.c | 91 ++-- fs/nfsd/nfsctl.c | 33 ++- fs/nsfs.c | 13 + fs/openpromfs/inode.c | 20 +- fs/pipe.c | 12 + fs/ramfs/inode.c | 104 ++--- fs/super.c | 106 ++ include/linux/fs.h | 21 -- include/linux/fs_context.h |8 + include/linux/ramfs.h |6 - include/linux/shmem_fs.h |4 init/do_mounts.c | 12 - mm/shmem.c | 396 mm/zsmalloc.c | 19 +- net/socket.c | 14 + net/sunrpc/rpc_pipe.c | 34 ++- security/apparmor/apparmorfs.c | 20 +- security/inode.c | 21 +- security/selinux/selinuxfs.c | 20 +- security/smack/smackfs.c | 34 ++- 41 files changed, 902 insertions(+), 609 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/38] vfs: Convert drm to fs_context
Signed-off-by: David Howells
cc: David Airlie
cc: Daniel Vetter
cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_drv.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 381581b01d48..9eead5a478de 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -413,20 +414,17 @@ static const struct super_operations drm_fs_sops = {
.statfs = simple_statfs,
};
-static struct dentry *drm_fs_mount(struct file_system_type *fs_type, int flags,
- const char *dev_name, void *data)
+static int drm_fs_init_fs_context(struct fs_context *fc)
{
- return mount_pseudo(fs_type,
- "drm:",
- &drm_fs_sops,
- &drm_fs_dops,
- 0x010203ff);
+ return vfs_init_pseudo_fs_context(fc, "drm:",
+ &drm_fs_sops, NULL,
+ &drm_fs_dops, 0x010203ff);
}
static struct file_system_type drm_fs_type = {
.name = "drm",
.owner = THIS_MODULE,
- .mount = drm_fs_mount,
+ .init_fs_context = drm_fs_init_fs_context,
.kill_sb= kill_anon_super,
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 14/68] vfs: Convert drm to use the new mount API
Convert the drm filesystem to the new internal mount API as the old
one will be obsoleted and removed. This allows greater flexibility in
communication of mount parameters between userspace, the VFS and the
filesystem.
See Documentation/filesystems/mount_api.txt for more information.
Signed-off-by: David Howells
cc: David Airlie
cc: Daniel Vetter
cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_drv.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 381581b01d48..9eead5a478de 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -413,20 +414,17 @@ static const struct super_operations drm_fs_sops = {
.statfs = simple_statfs,
};
-static struct dentry *drm_fs_mount(struct file_system_type *fs_type, int flags,
- const char *dev_name, void *data)
+static int drm_fs_init_fs_context(struct fs_context *fc)
{
- return mount_pseudo(fs_type,
- "drm:",
- &drm_fs_sops,
- &drm_fs_dops,
- 0x010203ff);
+ return vfs_init_pseudo_fs_context(fc, "drm:",
+ &drm_fs_sops, NULL,
+ &drm_fs_dops, 0x010203ff);
}
static struct file_system_type drm_fs_type = {
.name = "drm",
.owner = THIS_MODULE,
- .mount = drm_fs_mount,
+ .init_fs_context = drm_fs_init_fs_context,
.kill_sb= kill_anon_super,
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 00/68] VFS: Convert a bunch of filesystems to the new mount API
Hi Al, Here's a set of patches that converts a bunch (but not yet all!) to the new mount API. To this end, it makes the following changes: (1) Provides a convenience member in struct fs_context that is OR'd into sb->s_iflags by sget_fc(). (2) Provides a convenience helper function, vfs_init_pseudo_fs_context(), for doing most of the work in mounting a pseudo filesystem. (3) Provides a convenience helper function, vfs_get_block_super(), for doing the work in setting up a block-based superblock. (4) Improves the handling of fd-type parameters. (5) Moves some of the subtype handling int fuse. (6) Provides a convenience helper function, vfs_get_mtd_super(), for doing the work in setting up an MTD device-based superblock. (7) Kills off mount_pseudo(), mount_pseudo_xattr(), mount_ns(), sget_userns(), mount_mtd(), mount_single(). (8) Converts a slew of filesystems to use the mount API. (9) Fixes a bug in hypfs. The patches can be found here also: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git on branch: mount-api-viro David --- Andrew Price (1): gfs2: Convert gfs2 to fs_context David Howells (66): vfs: Update mount API docs vfs: Fix refcounting of filenames in fs_parser vfs: Provide sb->s_iflags settings in fs_context struct vfs: Provide a mount_pseudo-replacement for the new mount API vfs: Convert aio to use the new mount API vfs: Convert anon_inodes to use the new mount API vfs: Convert bdev to use the new mount API vfs: Convert nsfs to use the new mount API vfs: Convert pipe to use the new mount API vfs: Convert zsmalloc to use the new mount API vfs: Convert sockfs to use the new mount API vfs: Convert dax to use the new mount API vfs: Convert drm to use the new mount API vfs: Convert ia64 perfmon to use the new mount API vfs: Convert cxl to use the new mount API vfs: Convert ocxlflash to use the new mount API vfs: Convert virtio_balloon to use the new mount API vfs: Convert btrfs_test to use the new mount API vfs: Kill off mount_pseudo() and mount_pseudo_xattr() vfs: Use sget_fc() for pseudo-filesystems vfs: Convert binderfs to use the new mount API vfs: Convert nfsctl to use the new mount API vfs: Convert rpc_pipefs to use the new mount API vfs: Kill mount_ns() vfs: Kill sget_userns() vfs: Convert binfmt_misc to use the new mount API vfs: Convert configfs to use the new mount API vfs: Convert efivarfs to use the new mount API vfs: Convert fusectl to use the new mount API vfs: Convert qib_fs/ipathfs to use the new mount API vfs: Convert ibmasmfs to use the new mount API vfs: Convert oprofilefs to use the new mount API vfs: Convert gadgetfs to use the new mount API vfs: Convert xenfs to use the new mount API vfs: Convert openpromfs to use the new mount API vfs: Convert apparmorfs to use the new mount API vfs: Convert securityfs to use the new mount API vfs: Convert selinuxfs to use the new mount API vfs: Convert smackfs to use the new mount API vfs: Convert ramfs, shmem, tmpfs, devtmpfs, rootfs to use the new mount API vfs: Create fs_context-aware mount_bdev() replacement vfs: Make fs_parse() handle fs_param_is_fd-type params better vfs: Convert fuse to use the new mount API vfs: Move the subtype parameter into fuse mtd: Provide fs_context-aware mount_mtd() replacement vfs: Convert romfs to use the new mount API vfs: Convert cramfs to use the new mount API vfs: Convert jffs2 to use the new mount API mtd: Kill mount_mtd() vfs: Convert squashfs to use the new mount API vfs: Convert ceph to use the new mount API vfs: Convert functionfs to use the new mount API vfs: Add a single-or-reconfig keying to vfs_get_super() vfs: Convert debugfs to use the new mount API vfs: Convert tracefs to use the new mount API vfs: Convert pstore to use the new mount API hypfs: Fix error number left in struct pointer member vfs: Convert hypfs to use the new mount API vfs: Convert spufs to use the new mount API vfs: Kill mount_single() vfs: Convert coda to use the new mount API vfs: Convert autofs to use the new mount API vfs: Convert devpts to use the new mount API vfs: Convert bpf to use the new mount API vfs: Convert ubifs to use the new mount API vfs: Convert orangefs to use the new mount API Masahiro Yamada (1): kbuild: skip sub-make for in-tree build with GNU Make 4.x Documentation/filesystems/mount_api.txt | 367 --- Documentation/filesystems/vfs.txt |4 Makefile | 31 + arch/ia64/kernel/perfmon.c| 14 - arch/powerpc/platforms/cell/spuf
A panic and a hang in the i915 drm driver
Hi,
I'm seeing the attached oops and panic from the i915 drm driver. I've tried
bisecting it, but there's a problem in that one of the merged branches causes
the machine to hang without output.
The oops for commit c41219fda6e04255c44d37fd2c0d898c1c46abf1 looks like:
BUG: kernel NULL pointer dereference, address:
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD 0 P4D 0
Oops: [#1] SMP PTI
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc2-fscache+ #883
Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
RIP: 0010:intel_psr_enabled+0xb/0x6e
Code: 8b 44 24 08 65 48 33 04 25 28 00 00 00 74 05 e8 7e ff 97 ff 48 83 c4 10
5b 5d 41 5c 41 5d c3 0f 1f 44 00 00 41 55 41 54 55 53 <48> 8b 9f d8 fe ff ff f6
83 5e 08 00 00 20 75 05 45 31 e4 eb 44 80
RSP: :88840dedfa18 EFLAGS: 00010246
RAX: RBX: 8884086f9000 RCX:
RDX: 0001 RSI: 8884086f9000 RDI: 0128
RBP: 8884086fb000 R08: R09: 0001
R10: 0001 R11: 00ff R12: 88840868
R13: R14: R15: 8884086fb200
FS: () GS:88840fb0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: CR3: 0440c001 CR4: 001606e0
Call Trace:
intel_read_dp_sdp+0x71/0x2c5
hsw_crt_get_config+0x18/0x41
intel_modeset_readout_hw_state+0x24d/0x662
? do_raw_spin_lock+0x8b/0xcd
? _raw_spin_lock_irqsave+0x10/0x16
intel_modeset_setup_hw_state+0xa8/0xb59
? __next_node_in+0x39/0x42
? ww_mutex_lock+0x3d/0x1da
? modeset_lock+0xd4/0x114
? drm_modeset_lock_all_ctx+0x86/0xcc
intel_modeset_init+0x285/0x5bf
? intel_irq_postinstall+0x485/0x4d1
i915_driver_probe+0x1b4/0x49c
? __kernfs_new_node+0x161/0x1b2
? rpm_resume+0x45e/0x485
i915_pci_probe+0xfd/0x11d
? __pm_runtime_resume+0x51/0x5e
local_pci_probe+0x39/0x7a
pci_device_probe+0xf5/0x14f
? sysfs_do_create_link_sd.isra.0+0x77/0xa3
really_probe+0x140/0x2a9
driver_probe_device+0x9c/0xd1
device_driver_attach+0x3c/0x55
__driver_attach+0x97/0x9f
? device_driver_attach+0x55/0x55
bus_for_each_dev+0x72/0xa8
bus_add_driver+0x108/0x1b9
driver_register+0x9e/0xd7
? mipi_dsi_bus_init+0x11/0x11
i915_init+0x58/0x6b
do_one_initcall+0x83/0x18a
kernel_init_freeable+0x19b/0x1fd
? rest_init+0x9f/0x9f
kernel_init+0xa/0xfa
ret_from_fork+0x1f/0x30
Modules linked in:
CR2:
---[ end trace d0c4f561618aeb37 ]---
RIP: 0010:intel_psr_enabled+0xb/0x6e
Code: 8b 44 24 08 65 48 33 04 25 28 00 00 00 74 05 e8 7e ff 97 ff 48 83 c4 10
5b 5d 41 5c 41 5d c3 0f 1f 44 00 00 41 55 41 54 55 53 <48> 8b 9f d8 fe ff ff f6
83 5e 08 00 00 20 75 05 45 31 e4 eb 44 80
RSP: :88840dedfa18 EFLAGS: 00010246
RAX: RBX: 8884086f9000 RCX:
RDX: 0001 RSI: 8884086f9000 RDI: 0128
RBP: 8884086fb000 R08: R09: 0001
R10: 0001 R11: 00ff R12: 88840868
R13: R14: R15: 8884086fb200
FS: () GS:88840fb0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: CR3: 0440c001 CR4: 001606e0
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009
Kernel Offset: disabled
---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0009 ]---
Decoding the RIP gives:
RIP: 0010:intel_psr_enabled
(/data/fs/linux-fs/build3/../drivers/gpu/drm/i915/display/intel_display_types.h:1595
/data/fs/linux-fs/build3/../drivers/gpu/drm/i915/display/intel_psr.c:1598)
Commit c41219fda6e04255c44d37fd2c0d898c1c46abf1 ("Merge tag
'drm-intel-next-fixes-2020-05-20' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next") is definitely bad
and logs an oops to the console and panics, but it's a merge.
On one side is e20bb857dea2f620ff37ae541ed8aee70e3c89f1 ("Merge tag
'exynos-drm-next-for-v5.8' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
drm-next"), which hangs. This is also a merge.
One side of e20bb is f84e1ba336a4f47ae251e4d2d8a694902571b0df
("drm/exynos-vidi: convert platform driver to use dev_groups") which is good.
The other side of c4121 and e20bb derive from the same line of commits, with
three patches between. All of these, down to at least
230982d8d8df7f9d9aa216840ea2db1df6ad5d37 ("drm/i915: Update DRIVER_DATE to
20200430") cause the machine to hang without any sort of console output.
Commit bfbe1744e4417986419236719922a9a7fda224d1 ("Merge tag
'amd-drm-next-5.8-2020-05-19' of git://people.freedesktop.org/~agd5f/linux
into drm-next") is good.
Commit 47e51832ae93534d872511ba557115722582d94c
("drm/i915/gvt: use context lrc_reg_state for shadow ppgtt override") is good.
I've attached the git log and the config file.
David
git bisect start
Re: A panic and a hang in the i915 drm driver
Here's the dmesg from a successful boot (commit f84e1ba336a4f47ae251e4d2d8a694902571b0df). David --- [0.007455] Normal [mem 0x0001-0x00041fdf] [0.007456] Movable zone start for each node [0.007456] Early memory node ranges [0.007457] node 0: [mem 0x1000-0x00057fff] [0.007458] node 0: [mem 0x00059000-0x0009efff] [0.007459] node 0: [mem 0x0010-0xaf304fff] [0.007460] node 0: [mem 0xaf30c000-0xaf774fff] [0.007460] node 0: [mem 0xafbbd000-0xd8b7bfff] [0.007461] node 0: [mem 0xd9fff000-0xd9ff] [0.007461] node 0: [mem 0x0001-0x00041fdf] [0.007845] Zeroed struct page in unavailable ranges: 31541 pages [0.007846] Initmem setup node 0 [mem 0x1000-0x00041fdf] [0.007848] On node 0 totalpages: 4162763 [0.007849] DMA zone: 64 pages used for memmap [0.007849] DMA zone: 24 pages reserved [0.007850] DMA zone: 3997 pages, LIFO batch:0 [0.007901] DMA32 zone: 13789 pages used for memmap [0.007901] DMA32 zone: 882478 pages, LIFO batch:63 [0.020153] Normal zone: 51192 pages used for memmap [0.020155] Normal zone: 3276288 pages, LIFO batch:63 [0.064070] Reserving Intel graphics memory at [mem 0xdb20-0xdf1f] [0.064144] ACPI: PM-Timer IO Port: 0x1808 [0.064146] ACPI: Local APIC address 0xfee0 [0.064150] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) [0.064159] IOAPIC[0]: apic_id 8, version 32, address 0xfec0, GSI 0-23 [0.064161] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.064162] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.064163] ACPI: IRQ0 used by override. [0.064164] ACPI: IRQ9 used by override. [0.064166] Using ACPI (MADT) for SMP configuration information [0.064167] ACPI: HPET id: 0x8086a701 base: 0xfed0 [0.064171] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later) [0.064172] smpboot: Allowing 4 CPUs, 0 hotplug CPUs [0.064198] [mem 0xdf20-0xf7ff] available for PCI devices [0.064204] clocksource: refined-jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 7645519600211568 ns [0.077227] setup_percpu: NR_CPUS:4 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1 [0.077563] percpu: Embedded 54 pages/cpu s181200 r8192 d31792 u524288 [0.077569] pcpu-alloc: s181200 r8192 d31792 u524288 alloc=1*2097152 [0.077570] pcpu-alloc: [0] 0 1 2 3 [0.077588] Built 1 zonelists, mobility grouping on. Total pages: 4097694 [0.077588] Policy zone: Normal [0.077590] Kernel command line: BOOT_IMAGE=/data/tftp/andromeda-vmlinuz ip=enp3s0:dhcp console=tty0 console=ttyS0,115200 ro root=/dev/sdb2 [0.079327] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes, linear) [0.080136] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear) [0.080167] mem auto-init: stack:off, heap alloc:off, heap free:off [0.159182] Memory: 16016000K/16651052K available (12290K kernel code, 1927K rwdata, 5372K rodata, 1608K init, 1296K bss, 635052K reserved, 0K cma-reserved) [0.159242] Kernel/User page tables isolation: enabled [0.159256] ftrace: allocating 47297 entries in 185 pages [0.172236] ftrace: allocated 185 pages with 5 groups [0.172293] rcu: Hierarchical RCU implementation. [0.172294] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. [0.175046] NR_IRQS: 4352, nr_irqs: 456, preallocated irqs: 16 [0.175193] rcu: Offload RCU callbacks from CPUs: (none). [0.175244] random: get_random_bytes called from start_kernel+0x3f5/0x5c0 with crng_init=0 [0.175342] Console: colour dummy device 80x25 [0.175458] printk: console [tty0] enabled [0.957870] printk: console [ttyS0] enabled [0.960753] ACPI: Core revision 20200326 [0.963468] clocksource: hpet: mask: 0x max_cycles: 0x, max_idle_ns: 133484882848 ns [0.971296] APIC: Switch to symmetric I/O mode setup [0.975260] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0 [0.999294] clocksource: tsc-early: mask: 0x max_cycles: 0x6a6cab8f549, max_idle_ns: 881590883366 ns [1.008503] Calibrating delay loop (skipped), value calculated using timer frequency.. 7383.19 BogoMIPS (lpj=14766392) [1.012503] pid_max: default: 32768 minimum: 301 [1.024069] LSM: Security Framework initializing [1.024510] Yama: becoming mindful. [1.028507] SELinux: Initializing. [1.030772] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes, linear) [1.032558] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes, linear) [1.036710] mce: CPU0: Thermal monitoring enabled (TM1) [1.040511] process: using mwait in idle threads [1
Re: [Intel-gfx] A panic and a hang in the i915 drm driver
Jani Nikula wrote: > David, please try [1]. Assuming you mean this: https://patchwork.freedesktop.org/patch/366958/?series=77635&rev=1 yes, that works. Tested-by: David Howells ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] treewide: Make remaining source files non-executable
Joe Perches wrote: > .c and .h source files should not be executable, change > the permissions to 0644. Acked-by: David Howells
[RFC] UAPI: Check headers by compiling all together as C++
Here's a set of patches that inserts a step into the build process to make sure that the UAPI headers can all be built together with C++ (if the compiler being used supports C++). All but the final patch perform fixups, including: (1) Fix member names that conflict with C++ reserved words by providing alternates that can be used anywhere. An anonymous union is used so that that the conflicting name is still available outside of C++. (2) Fix the use of flexible arrays in structs that get embedded (which is illegal in C++). (3) Remove the use of internal kernel structs in UAPI structures. (4) Fix symbol collisions. (5) Replace usage of u32 and co. with __u32 and co. (6) Fix use of sparsely initialised arrays (which g++ doesn't implement). (7) Remove some use of PAGE_SIZE since this isn't valid outside of the kernel. And lastly: (8) Compile all of the UAPI headers (with a few exceptions) together as C++ to catch new errors occurring as part of the regular build process. The patches can also be found here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=uapi-check Thanks, David --- David Howells (11): UAPI: drm: Fix use of C++ keywords as structural members UAPI: keys: Fix use of C++ keywords as structural members UAPI: virtio_net: Fix use of C++ keywords as structural members UAPI: bcache: Fix use of embedded flexible array UAPI: coda: Don't use internal kernel structs in UAPI UAPI: netfilter: Fix symbol collision issues UAPI: nilfs2: Fix use of undefined byteswapping functions UAPI: sound: Fix use of u32 and co. in UAPI headers UAPI: ndctl: Fix g++-unsupported initialisation in headers UAPI: ndctl: Remove use of PAGE_SIZE UAPI: Check headers build for C++ Makefile |1 include/linux/ndctl.h | 22 include/uapi/drm/i810_drm.h |7 + include/uapi/drm/msm_drm.h|7 + include/uapi/linux/bcache.h |2 include/uapi/linux/coda_psdev.h |4 + include/uapi/linux/keyctl.h |7 + include/uapi/linux/ndctl.h| 20 ++- include/uapi/linux/netfilter/nfnetlink_cthelper.h |2 include/uapi/linux/netfilter_ipv4/ipt_ECN.h |9 -- include/uapi/linux/nilfs2_ondisk.h| 21 ++-- include/uapi/linux/virtio_net.h |7 + include/uapi/sound/skl-tplg-interface.h | 106 +- scripts/headers-c++.sh| 124 + 14 files changed, 255 insertions(+), 84 deletions(-) create mode 100644 include/linux/ndctl.h create mode 100755 scripts/headers-c++.sh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/11] UAPI: drm: Fix use of C++ keywords as structural members
The i810 and msm drm drivers use C++ keywords as structural members. Fix
this by inserting an anonymous union that provides an alternative name and
then hide the reserved name in C++.
Signed-off-by: David Howells
cc: Rob Clark
cc: David Airlie
cc: linux-arm-...@vger.kernel.org
cc: dri-devel@lists.freedesktop.org
cc: freedr...@lists.freedesktop.org
---
include/uapi/drm/i810_drm.h |7 ++-
include/uapi/drm/msm_drm.h |7 ++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/uapi/drm/i810_drm.h b/include/uapi/drm/i810_drm.h
index d285d5e72e6a..617d79ec3fc5 100644
--- a/include/uapi/drm/i810_drm.h
+++ b/include/uapi/drm/i810_drm.h
@@ -266,7 +266,12 @@ typedef struct _drm_i810_copy_t {
#define PR_MASK (0x7<<18)
typedef struct drm_i810_dma {
- void *virtual;
+ union {
+#ifndef __cplusplus
+ void *virtual;
+#endif
+ void *_virtual;
+ };
int request_idx;
int request_size;
int granted;
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index c06d0a5bdd80..e99bab72d58c 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -148,7 +148,12 @@ struct drm_msm_gem_cpu_fini {
*/
struct drm_msm_gem_submit_reloc {
__u32 submit_offset; /* in, offset from submit_bo */
- __u32 or; /* in, value OR'd with result */
+ union {
+#ifndef __cplusplus
+ __u32 or; /* in, value OR'd with result */
+#endif
+ __u32 _or; /* in, value OR'd with result */
+ };
__s32 shift; /* in, amount of left shift (can be negative) */
__u32 reloc_idx; /* in, index of reloc_bo buffer */
__u64 reloc_offset; /* in, offset from start of reloc_bo */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] UAPI: Check headers by compiling all together as C++
Greg KH wrote: > > Here's a set of patches that inserts a step into the build process to make > > sure that the UAPI headers can all be built together with C++ (if the > > compiler being used supports C++). All but the final patch perform fixups, > > including: > > Wait, why do we care? What has recently changed to start to directly > import kernel uapi files into C++ code? There's at least one outstanding bug due to a C++ identifier in the kernel UAPI headers. Are you saying you explicitly don't want people to be able to use the kernel UAPI headers in C++? > And if userspace wants to do this, can't they do the C namespace trick > themselves when they do the import? That must be how they are doing it > today, right? No, because there's no such trick (except with the preprocessor). David ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] UAPI: Check headers by compiling all together as C++
Here's a set of patches that inserts a step into the build process to make sure that the UAPI headers can all be built together with C++ (if the compiler being used supports C++). Note that it's based on a commit from the sound tree to fix usage of u32 and co.. Most of the patches perform fixups, including: (1) Fix member names that conflict with C++ reserved words by providing alternates that can be used anywhere. An anonymous union is used so that that the conflicting name is still available outside of C++. (2) Fix the use of flexible arrays in structs that get embedded (which is illegal in C++). (3) Remove the use of internal kernel structs in UAPI structures. (4) Fix symbol collisions. (5) Fix use of sparsely initialised arrays (which g++ doesn't implement). (6) Remove some use of PAGE_SIZE since this isn't valid outside of the kernel. There's also: (7) Move the coda_psdev.h header file to fs/coda/. And lastly: (8) Compile all of the UAPI headers (with a few exceptions) together as C++ to catch new errors occurring as part of the regular build process. Changes for v2: - Merge commit from sound tree to fix u32 usage issues - Use a switch to fix sparse array initialisation - Simplify nilfs2 by performing bitwise ops in LE space not CPU space - Handle conflicting fix to use of 'private' in keyctl.h - Move kernel internal coda bits to coda internal headers - Move coda_psdev.h header to fs/coda/. The patches can also be found here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=uapi-check Thanks, David --- David Howells (11): UAPI: drm: Fix use of C++ keywords as structural members UAPI: keys: Fix use of C++ keywords as structural members UAPI: virtio_net: Fix use of C++ keywords as structural members UAPI: bcache: Fix use of embedded flexible array UAPI: coda: Move kernel internals out of public view coda: Move internal defs out of include/linux/ UAPI: netfilter: Fix symbol collision issues UAPI: nilfs2: Fix use of undefined byteswapping functions UAPI: ndctl: Fix g++-unsupported initialisation in headers UAPI: ndctl: Remove use of PAGE_SIZE UAPI: Check headers build for C++ Makefile |1 fs/coda/cache.c |2 fs/coda/cnode.c |2 fs/coda/coda_linux.c |2 fs/coda/coda_psdev.h | 88 +++ fs/coda/dir.c |2 fs/coda/file.c|3 - fs/coda/inode.c |2 fs/coda/pioctl.c |3 - fs/coda/psdev.c |3 - fs/coda/symlink.c |3 - fs/coda/upcall.c |2 include/linux/coda_psdev.h| 72 include/linux/ndctl.h | 22 include/uapi/drm/i810_drm.h |7 + include/uapi/drm/msm_drm.h|7 + include/uapi/linux/bcache.h |2 include/uapi/linux/coda_psdev.h | 18 --- include/uapi/linux/keyctl.h |7 + include/uapi/linux/ndctl.h| 52 - include/uapi/linux/netfilter/nfnetlink_cthelper.h |2 include/uapi/linux/netfilter_ipv4/ipt_ECN.h |9 -- include/uapi/linux/nilfs2_ondisk.h| 28 ++--- include/uapi/linux/virtio_net.h |7 + scripts/headers-c++.sh| 124 + 25 files changed, 304 insertions(+), 166 deletions(-) create mode 100644 fs/coda/coda_psdev.h delete mode 100644 include/linux/coda_psdev.h create mode 100644 include/linux/ndctl.h create mode 100755 scripts/headers-c++.sh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/11] UAPI: drm: Fix use of C++ keywords as structural members [ver #2]
The i810 and msm drm drivers use C++ keywords as structural members. Fix
this by inserting an anonymous union that provides an alternative name and
then hide the reserved name in C++.
Signed-off-by: David Howells
cc: Rob Clark
cc: David Airlie
cc: linux-arm-...@vger.kernel.org
cc: dri-devel@lists.freedesktop.org
cc: freedr...@lists.freedesktop.org
---
include/uapi/drm/i810_drm.h |7 ++-
include/uapi/drm/msm_drm.h |7 ++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/uapi/drm/i810_drm.h b/include/uapi/drm/i810_drm.h
index d285d5e72e6a..617d79ec3fc5 100644
--- a/include/uapi/drm/i810_drm.h
+++ b/include/uapi/drm/i810_drm.h
@@ -266,7 +266,12 @@ typedef struct _drm_i810_copy_t {
#define PR_MASK (0x7<<18)
typedef struct drm_i810_dma {
- void *virtual;
+ union {
+#ifndef __cplusplus
+ void *virtual;
+#endif
+ void *_virtual;
+ };
int request_idx;
int request_size;
int granted;
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index c06d0a5bdd80..e99bab72d58c 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -148,7 +148,12 @@ struct drm_msm_gem_cpu_fini {
*/
struct drm_msm_gem_submit_reloc {
__u32 submit_offset; /* in, offset from submit_bo */
- __u32 or; /* in, value OR'd with result */
+ union {
+#ifndef __cplusplus
+ __u32 or; /* in, value OR'd with result */
+#endif
+ __u32 _or; /* in, value OR'd with result */
+ };
__s32 shift; /* in, amount of left shift (can be negative) */
__u32 reloc_idx; /* in, index of reloc_bo buffer */
__u64 reloc_offset; /* in, offset from start of reloc_bo */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH net-next v6 07/15] page_pool: convert to use netmem
Hi Mina, I recommend you cc linux-mm and Matthew Wilcox on these two patches also. David
Re: [PATCH 00/16] remove eight obsolete architectures
Do we have anything left that still implements NOMMU? David ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/27] kill devm_ioremap_nocache
Arnd Bergmann wrote:
> - mn10300 appears to be wrong, broken by David Howells in
> commit 83c2dc15ce82 ("MN10300: Handle cacheable PCI regions
> in pci_iomap()") for any driver calling ioremap() by to get uncached
> memory,
It's not clear what the right thing to do was, given that there's an ioremap()
and an ioremap_uncached().
But the asb2305's pci_iomap() will use ioremap() (the cacheable window) if
IORESOURCE_CACHEABLE is set, but IORESOURCE_IO is not and ioremap_uncached()
otherwise.
The other supported units don't have PCI buses.
> if I understand the comment for commit 34f1bdee1910 ("mn10300: switch to
> GENERIC_PCI_IOMAP") correctly: it seems that PCI addresses include the
> 'uncached' bit by default to get the right behavior, but dropping that bit
> breaks it.
Not exactly. The CPU has a window in the range 0xa000-0xbfff which is
an uncached view of its hardware buses. It has another window in the range
0x8000-0x9fff which is a cached view of that region. These windows
cannot be changed and addresses above 0x8000 are statically mapped and are
only accessible by the kernel (this is hardwired in the MMU).
So the arch has two subwindows to the PCI bus, one cached and one uncached.
These subwindows are further subdivided into ioport and iomem spaces, an SRAM
and some control registers for the CPU-PCI bridge.
David
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm merge for rc1 (part 1)
Linus Torvalds wrote: > Ok, as usual I actually wanted to do the merge myself despite the > annoying conflicts (this *really* is the last time I will ever accept > any header file "cleanups" - they simply aren't worth the pain). There was a reason I asked you to pull the patches at the *end* of the merge window, and a reason I asked you to give me a chance to regenerate the patches before you pulled them. Anyway, I can feed much of the main set of patches through subsystem trees now - so thanks for that at least. David
[git pull] drm merge for rc1 (part 1)
David Howells wrote: > Linus Torvalds wrote: > > > Ok, as usual I actually wanted to do the merge myself despite the > > annoying conflicts (this *really* is the last time I will ever accept > > any header file "cleanups" - they simply aren't worth the pain). > > There was a reason I asked you to pull the patches at the *end* of the merge > window, Okay, I owe you an apology... I forgot to request that you pull at the end of the merge window when I asked you to pull the preparatory patches instead. David
[PATCH 1/2] uapi: update includes for drm content when no kernel API exists
Luis R. Rodriguez wrote: > >> The include_next trick can work as well but that'd mean synching the UAPI > >> files regularly into compat. I'd much prefer to have code intact when > >> possible when backporting so the option I stuck with then was to patch > >> the code directly and then as part of compat-drivers to always copy > >> that day's linux-next UAPI headers into the current directory for > >> compilation. I see no other driver code using the uapi path explicitly > >> though, is that by design? > > > > As far as I understand that's by design, yes. Kernel code isn't expected to > > reference uapi/ headers directly. > > Did the design consider the case where no respective kernel API header > file would ever exist? I didn't particularly design it such that kernel .c files couldn't access uapi .h files directly. I did, however, design it so that my scripts wouldn't have to touch any .c files where possible, and certainly I didn't want to have to double up all #includes that refer to KAPI/UAPI split headers. Ideally, I'd've used #include_next in the KAPI file to refer to the UAPI file where both exist, but some people have strong objections to that, so I ended up having to do #include instead. I also didn't want to rename the asm/, linux/, etc. prefixes as that would mandate changing pretty much every #include in the kernel. For the case where no respective KAPI file exists, it was considered and it is handled. This is done by adding extra -I flags, for example: -I include -I include/uapi so looking for linux/foo.h, say, will look first for include/linux/foo.h and then for include/uapi/linux/foo.h. David
Re: [PATCH] gpu: drm/nouveau/nouveau_fence.c: remove unnecessary null pointer check
Cong Ding wrote: > the variable sender is dereferenced in line 190, so it is no reason to check > null again in line 198. Did you mean "The variable 'chan'"? David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm/nouveau/nouveau_fence.c: remove unnecessary null pointer check
Cong Ding wrote: > > > the variable sender is dereferenced in line 190, so it is no reason to > > > check > > > null again in line 198. > > > > Did you mean "The variable 'chan'"? > sorry, my fault. so should I send a new version to correct the typo? Yep. David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm merge for rc1 (part 1)
Linus Torvalds wrote: > Ok, as usual I actually wanted to do the merge myself despite the > annoying conflicts (this *really* is the last time I will ever accept > any header file "cleanups" - they simply aren't worth the pain). There was a reason I asked you to pull the patches at the *end* of the merge window, and a reason I asked you to give me a chance to regenerate the patches before you pulled them. Anyway, I can feed much of the main set of patches through subsystem trees now - so thanks for that at least. David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm merge for rc1 (part 1)
David Howells wrote: > Linus Torvalds wrote: > > > Ok, as usual I actually wanted to do the merge myself despite the > > annoying conflicts (this *really* is the last time I will ever accept > > any header file "cleanups" - they simply aren't worth the pain). > > There was a reason I asked you to pull the patches at the *end* of the merge > window, Okay, I owe you an apology... I forgot to request that you pull at the end of the merge window when I asked you to pull the preparatory patches instead. David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] uapi: update includes for drm content when no kernel API exists
Luis R. Rodriguez wrote: > >> The include_next trick can work as well but that'd mean synching the UAPI > >> files regularly into compat. I'd much prefer to have code intact when > >> possible when backporting so the option I stuck with then was to patch > >> the code directly and then as part of compat-drivers to always copy > >> that day's linux-next UAPI headers into the current directory for > >> compilation. I see no other driver code using the uapi path explicitly > >> though, is that by design? > > > > As far as I understand that's by design, yes. Kernel code isn't expected to > > reference uapi/ headers directly. > > Did the design consider the case where no respective kernel API header > file would ever exist? I didn't particularly design it such that kernel .c files couldn't access uapi .h files directly. I did, however, design it so that my scripts wouldn't have to touch any .c files where possible, and certainly I didn't want to have to double up all #includes that refer to KAPI/UAPI split headers. Ideally, I'd've used #include_next in the KAPI file to refer to the UAPI file where both exist, but some people have strong objections to that, so I ended up having to do #include instead. I also didn't want to rename the asm/, linux/, etc. prefixes as that would mandate changing pretty much every #include in the kernel. For the case where no respective KAPI file exists, it was considered and it is handled. This is done by adding extra -I flags, for example: -I include -I include/uapi so looking for linux/foo.h, say, will look first for include/linux/foo.h and then for include/uapi/linux/foo.h. David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: system_nrt_wq, system suspend, and the freezer
Alan Stern wrote: > My question to all of you: Should system_nrt_wq be made freezable, or > should I create a new workqueue that is both freezable and > non-reentrant? And if I do, which of the usages above should be > converted to the new workqueue? As far as keys are concerned, it's only for garbage collection purposes, so having it freezable shouldn't be a problem. David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: system_nrt_wq, system suspend, and the freezer
Tejun Heo wrote: > > > My question to all of you: Should system_nrt_wq be made freezable, or > > > should I create a new workqueue that is both freezable and > > > non-reentrant? And if I do, which of the usages above should be > > > converted to the new workqueue? > > > > As far as keys are concerned, it's only for garbage collection purposes, so > > having it freezable shouldn't be a problem. > > If freezing is not strictly necessary, please avoid marking it as > freezable. ? The key_garbage_collector work item is marked neither freezable nor unfreezable that I can see. David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 17/28] drm: Constify drm_proc_list[] [RFC]
Constify drm_proc_list[] and related pointers.
Signed-off-by: David Howells
cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_proc.c |6 +++---
include/drm/drmP.h |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index e064318..aead653 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -49,7 +49,7 @@
/**
* Proc file list.
*/
-static struct drm_info_list drm_proc_list[] = {
+static const struct drm_info_list drm_proc_list[] = {
{"name", drm_name_info, 0},
{"vm", drm_vm_info, 0},
{"clients", drm_clients_info, 0},
@@ -89,7 +89,7 @@ static const struct file_operations drm_proc_fops = {
* Create a given set of proc files represented by an array of
* gdm_proc_lists in the given root directory.
*/
-static int drm_proc_create_files(struct drm_info_list *files, int count,
+static int drm_proc_create_files(const struct drm_info_list *files, int count,
struct proc_dir_entry *root, struct drm_minor *minor)
{
struct drm_device *dev = minor->dev;
@@ -172,7 +172,7 @@ int drm_proc_init(struct drm_minor *minor, int minor_id,
return 0;
}
-static int drm_proc_remove_files(struct drm_info_list *files, int count,
+static int drm_proc_remove_files(const struct drm_info_list *files, int count,
struct drm_minor *minor)
{
struct list_head *pos, *q;
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2d94d74..af53320 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1022,7 +1022,7 @@ struct drm_info_list {
struct drm_info_node {
struct list_head list;
struct drm_minor *minor;
- struct drm_info_list *info_ent;
+ const struct drm_info_list *info_ent;
struct dentry *dent;
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 18/28] drm: proc: Use minor->index to label things, not PDE->name [RFC]
Use minor->index to label things, not the name field from the proc_dir_entry
of the /proc/dwm// directory.
Also, use "%u" not "%d" to render the value and use a 12-byte buffer in which
to render the integer, not a 16-byte buffer. The longest string an unsigned
int can give you is 10 chars (4294967295) plus a NUL, so round up to 12 as the
stack is likely to be 4- or 8-byte aligned.
Signed-off-by: David Howells
cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_proc.c | 13 +
drivers/gpu/drm/drm_stub.c |2 +-
include/drm/drmP.h |3 +--
3 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index aead653..0646a46 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -116,14 +116,13 @@ static int drm_proc_create_files(const struct
drm_info_list *files, int count,
ent = proc_create_data(files[i].name, S_IRUGO, root,
&drm_proc_fops, tmp);
if (!ent) {
- DRM_ERROR("Cannot create /proc/dri/%s/%s\n",
- root->name, files[i].name);
+ DRM_ERROR("Cannot create /proc/dri/%u/%s\n",
+ minor->index, files[i].name);
list_del(&tmp->list);
kfree(tmp);
ret = -1;
goto fail;
}
-
}
return 0;
@@ -137,7 +136,6 @@ fail:
* Initialize the DRI proc filesystem for a device
*
* \param dev DRM device
- * \param minor device minor number
* \param root DRI proc dir entry.
* \param dev_root resulting DRI device proc dir entry.
* \return root entry pointer on success, or NULL on failure.
@@ -146,14 +144,13 @@ fail:
* "/proc/dri/%minor%/", and each entry in proc_list as
* "/proc/dri/%minor%/%name%".
*/
-int drm_proc_init(struct drm_minor *minor, int minor_id,
- struct proc_dir_entry *root)
+int drm_proc_init(struct drm_minor *minor, struct proc_dir_entry *root)
{
- char name[64];
+ char name[12];
int ret;
INIT_LIST_HEAD(&minor->proc_nodes.list);
- sprintf(name, "%d", minor_id);
+ sprintf(name, "%u", minor->index);
minor->proc_root = proc_mkdir(name, root);
if (!minor->proc_root) {
DRM_ERROR("Cannot create /proc/dri/%s\n", name);
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 7d30802..16f3ec5 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -352,7 +352,7 @@ int drm_get_minor(struct drm_device *dev, struct drm_minor
**minor, int type)
idr_replace(&drm_minors_idr, new_minor, minor_id);
if (type == DRM_MINOR_LEGACY) {
- ret = drm_proc_init(new_minor, minor_id, drm_proc_root);
+ ret = drm_proc_init(new_minor, drm_proc_root);
if (ret) {
DRM_ERROR("DRM: Failed to initialize /proc/dri.\n");
goto err_mem;
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index af53320..60c33f1 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1546,8 +1546,7 @@ extern struct idr drm_minors_idr;
extern struct drm_local_map *drm_getsarea(struct drm_device *dev);
/* Proc support (drm_proc.h) */
-extern int drm_proc_init(struct drm_minor *minor, int minor_id,
-struct proc_dir_entry *root);
+extern int drm_proc_init(struct drm_minor *minor, struct proc_dir_entry *root);
extern int drm_proc_cleanup(struct drm_minor *minor, struct proc_dir_entry
*root);
/* Debugfs support */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 19/28] drm: proc: Use remove_proc_subtree() [RFC]
Use remove_proc_subtree() rather than remove_proc_entry() to remove a
minor-specific drm proc directory and all its children.
Things could theoretically be improved by storing the drm_minor pointer in the
minor-specific dir proc_dir_entry struct data and then scrapping the list of
proc files - but that's shared with the debugfs interface where you can't do
that, so I don't see an easy way of doing it.
Signed-off-by: David Howells
cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_proc.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index 0646a46..d7f2324 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -95,7 +95,7 @@ static int drm_proc_create_files(const struct drm_info_list
*files, int count,
struct drm_device *dev = minor->dev;
struct proc_dir_entry *ent;
struct drm_info_node *tmp;
- int i, ret;
+ int i;
for (i = 0; i < count; i++) {
u32 features = files[i].driver_features;
@@ -105,10 +105,9 @@ static int drm_proc_create_files(const struct
drm_info_list *files, int count,
continue;
tmp = kmalloc(sizeof(struct drm_info_node), GFP_KERNEL);
- if (tmp == NULL) {
- ret = -1;
- goto fail;
- }
+ if (!tmp)
+ return -1;
+
tmp->minor = minor;
tmp->info_ent = &files[i];
list_add(&tmp->list, &minor->proc_nodes.list);
@@ -120,16 +119,10 @@ static int drm_proc_create_files(const struct
drm_info_list *files, int count,
minor->index, files[i].name);
list_del(&tmp->list);
kfree(tmp);
- ret = -1;
- goto fail;
+ return -1;
}
}
return 0;
-
-fail:
- for (i = 0; i < count; i++)
- remove_proc_entry(drm_proc_list[i].name, minor->proc_root);
- return ret;
}
/**
@@ -160,7 +153,7 @@ int drm_proc_init(struct drm_minor *minor, struct
proc_dir_entry *root)
ret = drm_proc_create_files(drm_proc_list, DRM_PROC_ENTRIES,
minor->proc_root, minor);
if (ret) {
- remove_proc_entry(name, root);
+ remove_proc_subtree(name, root);
minor->proc_root = NULL;
DRM_ERROR("Failed to create core drm proc files\n");
return ret;
@@ -210,8 +203,7 @@ int drm_proc_cleanup(struct drm_minor *minor, struct
proc_dir_entry *root)
drm_proc_remove_files(drm_proc_list, DRM_PROC_ENTRIES, minor);
sprintf(name, "%d", minor->index);
- remove_proc_entry(name, root);
-
+ remove_proc_subtree(name, root);
return 0;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
system_nrt_wq, system suspend, and the freezer
Alan Stern wrote: > My question to all of you: Should system_nrt_wq be made freezable, or > should I create a new workqueue that is both freezable and > non-reentrant? And if I do, which of the usages above should be > converted to the new workqueue? As far as keys are concerned, it's only for garbage collection purposes, so having it freezable shouldn't be a problem. David
system_nrt_wq, system suspend, and the freezer
Tejun Heo wrote: > > > My question to all of you: Should system_nrt_wq be made freezable, or > > > should I create a new workqueue that is both freezable and > > > non-reentrant? And if I do, which of the usages above should be > > > converted to the new workqueue? > > > > As far as keys are concerned, it's only for garbage collection purposes, so > > having it freezable shouldn't be a problem. > > If freezing is not strictly necessary, please avoid marking it as > freezable. ? The key_garbage_collector work item is marked neither freezable nor unfreezable that I can see. David
[PATCH 17/28] drm: Constify drm_proc_list[] [RFC]
Constify drm_proc_list[] and related pointers.
Signed-off-by: David Howells
cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_proc.c |6 +++---
include/drm/drmP.h |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index e064318..aead653 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -49,7 +49,7 @@
/**
* Proc file list.
*/
-static struct drm_info_list drm_proc_list[] = {
+static const struct drm_info_list drm_proc_list[] = {
{"name", drm_name_info, 0},
{"vm", drm_vm_info, 0},
{"clients", drm_clients_info, 0},
@@ -89,7 +89,7 @@ static const struct file_operations drm_proc_fops = {
* Create a given set of proc files represented by an array of
* gdm_proc_lists in the given root directory.
*/
-static int drm_proc_create_files(struct drm_info_list *files, int count,
+static int drm_proc_create_files(const struct drm_info_list *files, int count,
struct proc_dir_entry *root, struct drm_minor *minor)
{
struct drm_device *dev = minor->dev;
@@ -172,7 +172,7 @@ int drm_proc_init(struct drm_minor *minor, int minor_id,
return 0;
}
-static int drm_proc_remove_files(struct drm_info_list *files, int count,
+static int drm_proc_remove_files(const struct drm_info_list *files, int count,
struct drm_minor *minor)
{
struct list_head *pos, *q;
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2d94d74..af53320 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1022,7 +1022,7 @@ struct drm_info_list {
struct drm_info_node {
struct list_head list;
struct drm_minor *minor;
- struct drm_info_list *info_ent;
+ const struct drm_info_list *info_ent;
struct dentry *dent;
};
[PATCH 18/28] drm: proc: Use minor->index to label things, not PDE->name [RFC]
Use minor->index to label things, not the name field from the proc_dir_entry
of the /proc/dwm// directory.
Also, use "%u" not "%d" to render the value and use a 12-byte buffer in which
to render the integer, not a 16-byte buffer. The longest string an unsigned
int can give you is 10 chars (4294967295) plus a NUL, so round up to 12 as the
stack is likely to be 4- or 8-byte aligned.
Signed-off-by: David Howells
cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_proc.c | 13 +
drivers/gpu/drm/drm_stub.c |2 +-
include/drm/drmP.h |3 +--
3 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index aead653..0646a46 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -116,14 +116,13 @@ static int drm_proc_create_files(const struct
drm_info_list *files, int count,
ent = proc_create_data(files[i].name, S_IRUGO, root,
&drm_proc_fops, tmp);
if (!ent) {
- DRM_ERROR("Cannot create /proc/dri/%s/%s\n",
- root->name, files[i].name);
+ DRM_ERROR("Cannot create /proc/dri/%u/%s\n",
+ minor->index, files[i].name);
list_del(&tmp->list);
kfree(tmp);
ret = -1;
goto fail;
}
-
}
return 0;
@@ -137,7 +136,6 @@ fail:
* Initialize the DRI proc filesystem for a device
*
* \param dev DRM device
- * \param minor device minor number
* \param root DRI proc dir entry.
* \param dev_root resulting DRI device proc dir entry.
* \return root entry pointer on success, or NULL on failure.
@@ -146,14 +144,13 @@ fail:
* "/proc/dri/%minor%/", and each entry in proc_list as
* "/proc/dri/%minor%/%name%".
*/
-int drm_proc_init(struct drm_minor *minor, int minor_id,
- struct proc_dir_entry *root)
+int drm_proc_init(struct drm_minor *minor, struct proc_dir_entry *root)
{
- char name[64];
+ char name[12];
int ret;
INIT_LIST_HEAD(&minor->proc_nodes.list);
- sprintf(name, "%d", minor_id);
+ sprintf(name, "%u", minor->index);
minor->proc_root = proc_mkdir(name, root);
if (!minor->proc_root) {
DRM_ERROR("Cannot create /proc/dri/%s\n", name);
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 7d30802..16f3ec5 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -352,7 +352,7 @@ int drm_get_minor(struct drm_device *dev, struct drm_minor
**minor, int type)
idr_replace(&drm_minors_idr, new_minor, minor_id);
if (type == DRM_MINOR_LEGACY) {
- ret = drm_proc_init(new_minor, minor_id, drm_proc_root);
+ ret = drm_proc_init(new_minor, drm_proc_root);
if (ret) {
DRM_ERROR("DRM: Failed to initialize /proc/dri.\n");
goto err_mem;
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index af53320..60c33f1 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1546,8 +1546,7 @@ extern struct idr drm_minors_idr;
extern struct drm_local_map *drm_getsarea(struct drm_device *dev);
/* Proc support (drm_proc.h) */
-extern int drm_proc_init(struct drm_minor *minor, int minor_id,
-struct proc_dir_entry *root);
+extern int drm_proc_init(struct drm_minor *minor, struct proc_dir_entry *root);
extern int drm_proc_cleanup(struct drm_minor *minor, struct proc_dir_entry
*root);
/* Debugfs support */
[PATCH 19/28] drm: proc: Use remove_proc_subtree() [RFC]
Use remove_proc_subtree() rather than remove_proc_entry() to remove a
minor-specific drm proc directory and all its children.
Things could theoretically be improved by storing the drm_minor pointer in the
minor-specific dir proc_dir_entry struct data and then scrapping the list of
proc files - but that's shared with the debugfs interface where you can't do
that, so I don't see an easy way of doing it.
Signed-off-by: David Howells
cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_proc.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index 0646a46..d7f2324 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -95,7 +95,7 @@ static int drm_proc_create_files(const struct drm_info_list
*files, int count,
struct drm_device *dev = minor->dev;
struct proc_dir_entry *ent;
struct drm_info_node *tmp;
- int i, ret;
+ int i;
for (i = 0; i < count; i++) {
u32 features = files[i].driver_features;
@@ -105,10 +105,9 @@ static int drm_proc_create_files(const struct
drm_info_list *files, int count,
continue;
tmp = kmalloc(sizeof(struct drm_info_node), GFP_KERNEL);
- if (tmp == NULL) {
- ret = -1;
- goto fail;
- }
+ if (!tmp)
+ return -1;
+
tmp->minor = minor;
tmp->info_ent = &files[i];
list_add(&tmp->list, &minor->proc_nodes.list);
@@ -120,16 +119,10 @@ static int drm_proc_create_files(const struct
drm_info_list *files, int count,
minor->index, files[i].name);
list_del(&tmp->list);
kfree(tmp);
- ret = -1;
- goto fail;
+ return -1;
}
}
return 0;
-
-fail:
- for (i = 0; i < count; i++)
- remove_proc_entry(drm_proc_list[i].name, minor->proc_root);
- return ret;
}
/**
@@ -160,7 +153,7 @@ int drm_proc_init(struct drm_minor *minor, struct
proc_dir_entry *root)
ret = drm_proc_create_files(drm_proc_list, DRM_PROC_ENTRIES,
minor->proc_root, minor);
if (ret) {
- remove_proc_entry(name, root);
+ remove_proc_subtree(name, root);
minor->proc_root = NULL;
DRM_ERROR("Failed to create core drm proc files\n");
return ret;
@@ -210,8 +203,7 @@ int drm_proc_cleanup(struct drm_minor *minor, struct
proc_dir_entry *root)
drm_proc_remove_files(drm_proc_list, DRM_PROC_ENTRIES, minor);
sprintf(name, "%d", minor->index);
- remove_proc_entry(name, root);
-
+ remove_proc_subtree(name, root);
return 0;
}
[PATCH] gpu: drm/nouveau/nouveau_fence.c: remove unnecessary null pointer check
Cong Ding wrote: > the variable sender is dereferenced in line 190, so it is no reason to check > null again in line 198. Did you mean "The variable 'chan'"? David
[PATCH] gpu: drm/nouveau/nouveau_fence.c: remove unnecessary null pointer check
Cong Ding wrote: > > > the variable sender is dereferenced in line 190, so it is no reason to > > > check > > > null again in line 198. > > > > Did you mean "The variable 'chan'"? > sorry, my fault. so should I send a new version to correct the typo? Yep. David
Re: [PATCH v2 1/9] 9p: Add a migrate_folio method
Matthew Wilcox (Oracle) wrote: > The migration code used to be able to migrate dirty 9p folios by writing > them back using writepage. When the writepage method was removed, > we neglected to add a migrate_folio method, which means that dirty 9p > folios have been unmovable ever since. This reduced our success at > defragmenting memory on machines which use 9p heavily. > > Fixes: 80105ed2fd27 (9p: Use netfslib read/write_iter) > Cc: sta...@vger.kernel.org > Cc: David Howells > Cc: v...@lists.linux.dev > Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: David Howells
