Re: [PATCH] Ext4 Docs: Add missing bigalloc documentation.
On Sat, Aug 31, 2019 at 10:44:19AM -0500, Ayush Ranjan wrote: > There was a broken link for bigalloc. The page > https://ext4.wiki.kernel.org/index.php/Bigalloc was not migrated into > the current documentation sources. This patch adds the contents of that > missing page into the section for Bigalloc itself. > > Signed-off-by: Ayush Ranjan Thanks, applied. - Ted
Re: [PATCH 0/6] Address issues with SPDX requirements and PEP-263
On Sat, Sep 07, 2019 at 11:17:22PM +0200, Thomas Gleixner wrote: > On Sat, 7 Sep 2019, Markus Heiser wrote: > > Am 07.09.19 um 20:04 schrieb Mauro Carvalho Chehab: > > > No idea. I would actually prefer to just remove the restriction, and let > > > the SPDX header to be anywhere inside the first comment block inside a > > > file [2]. > > > [2] I *suspect* that the restriction was added in order to make > > > ./scripts/spdxcheck.py to run faster and to avoid false positives. > > > Right now, if the maximum limit is removed (or set to a very high > > > value), there will be one false positive: > > Nope. The intention was to have a well define place and format instead of > everyone and his dog deciding to put it somewhere. SPDX is not intended to > replace the existing licensing mess with some other randomly placed and > formatted licensing mess. I find the current style quite unaesthetic: // SPDX-License-Identifier: GPL-2.0-only /* * linux/mm/memory.c * * Copyright (C) 1991, 1992, 1993, 1994 Linus Torvalds */ I'd much rather see /* * SPDX-License-Identifier: GPL-2.0-only * Copyright (C) 1991, 1992, 1993, 1994 Linus Torvalds */ but I appreciate the desire to force it to be on the first line if at all possible.
Re: [PATCH 0/6] Address issues with SPDX requirements and PEP-263
On Sun, 8 Sep 2019, Matthew Wilcox wrote: > On Sat, Sep 07, 2019 at 11:17:22PM +0200, Thomas Gleixner wrote: > > On Sat, 7 Sep 2019, Markus Heiser wrote: > > > Am 07.09.19 um 20:04 schrieb Mauro Carvalho Chehab: > > > > No idea. I would actually prefer to just remove the restriction, and let > > > > the SPDX header to be anywhere inside the first comment block inside a > > > > file [2]. > > > > [2] I *suspect* that the restriction was added in order to make > > > > ./scripts/spdxcheck.py to run faster and to avoid false positives. > > > > Right now, if the maximum limit is removed (or set to a very high > > > > value), there will be one false positive: > > > > Nope. The intention was to have a well define place and format instead of > > everyone and his dog deciding to put it somewhere. SPDX is not intended to > > replace the existing licensing mess with some other randomly placed and > > formatted licensing mess. > > I find the current style quite unaesthetic: > > // SPDX-License-Identifier: GPL-2.0-only > /* > * linux/mm/memory.c > * > * Copyright (C) 1991, 1992, 1993, 1994 Linus Torvalds > */ > > I'd much rather see > > /* > * SPDX-License-Identifier: GPL-2.0-only > * Copyright (C) 1991, 1992, 1993, 1994 Linus Torvalds > */ > > but I appreciate the desire to force it to be on the first line if at all > possible. That style is inflicted upon you by Penguin Emperor Decree. :)
[PATCH] Ext4 Documentation: Add missing quota section.
There were a few broken links for quota. The page https://ext4.wiki.kernel.org/index.php/Quota was not migrated into the current documentation sources. This patch adds the contents of that missing page as a new section in the overview page. Also fixes those broken links by replacing them with cross document links to this new quota section. Signed-off-by: Ayush Ranjan --- Documentation/filesystems/ext4/overview.rst | 1 + Documentation/filesystems/ext4/quota.rst| 53 + Documentation/filesystems/ext4/super.rst| 6 +-- 3 files changed, 57 insertions(+), 3 deletions(-) create mode 100644 Documentation/filesystems/ext4/quota.rst diff --git a/Documentation/filesystems/ext4/overview.rst b/Documentation/filesystems/ext4/overview.rst index cbab18bab..f97ea68ea 100644 --- a/Documentation/filesystems/ext4/overview.rst +++ b/Documentation/filesystems/ext4/overview.rst @@ -24,3 +24,4 @@ order. .. include:: bigalloc.rst .. include:: inlinedata.rst .. include:: eainode.rst +.. include:: quota.rst diff --git a/Documentation/filesystems/ext4/quota.rst b/Documentation/filesystems/ext4/quota.rst new file mode 100644 index 0..8964c26cb --- /dev/null +++ b/Documentation/filesystems/ext4/quota.rst @@ -0,0 +1,53 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _quota: + +Quota Feature +- + +The quota feature (``EXT4_FEATURE_RO_COMPAT_QUOTA``) causes the quota +files (i.e., user.quota and group.quota which existed in the older quota +design) to be hidden inodes, so they can not be corrupted by user space +programs. Instead, these inodes are managed directly via e2fsprogs, and +journaled quota will be automatically enabled by the kernel as soon as +the file system is mounted. This way, it strongly reduces the +possibility that the usage tracking performed by the file system will +get out of sync. + +Kernel Support +~~ + +Support for the quota feature first appeared in the 3.6 upstream kernel +version. There is a bug which will not be fixed until v3.8 which will +cause ext4 to fail to mount a file system with quotas if the quota code +is built as a module. So users who wish to experiment with this feature +are strongly encouraged to build with the following configuration +options: + +- ``CONFIG_QUOTA=y`` +- ``CONFIG_QUOTATREE=y`` +- ``CONFIG_QUOTACTL=y`` + +E2fsprogs Support +~ + +Support for the quota feature first appeared in e2fsprogs 1.42, although +it is not enabled by default. It must enabled via a compile-time +configuration option, --enable-quota. There are bug fixes which have +been applied in various 1.42.x maintenance branch releases, so users who +wish to experiment with the quota feature are strongly encouraged +upgrade to the latest e2fsprogs 1.42.x maintenance release. As of this +writing the following bugs are still in e2fsprogs 1.42.7, which means +use of file systems with the quota feature in production can not be +recommended: + +- The e2fsck check of the on-disk quota inodes won't notice if there is + a missing uid record. (i.e., if some uid, say daemon owns a bunch of + files, but that uid record is not in the quota inode, e2fsck won't say + boo.) +- If e2fsck *does* notice a discrepancy between the usage information + recorded in the hidden quota inodes, and the actual number of blocks + used by a particular user id or group id, it will overwrite the user + or group quota inode with all of the information it has. + Unfortunately, in the process it will zero out all of the current + quota limits set. This is unfortunate diff --git a/Documentation/filesystems/ext4/super.rst b/Documentation/filesystems/ext4/super.rst index 04ff079a2..2a9e1438f 100644 --- a/Documentation/filesystems/ext4/super.rst +++ b/Documentation/filesystems/ext4/super.rst @@ -404,11 +404,11 @@ The ext4 superblock is laid out as follows in * - 0x240 - \_\_le32 - s\_usr\_quota\_inum - - Inode number of user `quota `__ file. + - Inode number of user :ref:`quota ` file. * - 0x244 - \_\_le32 - s\_grp\_quota\_inum - - Inode number of group `quota `__ file. + - Inode number of group :ref:`quota ` file. * - 0x248 - \_\_le32 - s\_overhead\_blocks @@ -678,7 +678,7 @@ the following: * - 0x80 - This filesystem has a snapshot (RO\_COMPAT\_HAS\_SNAPSHOT). * - 0x100 - - `Quota `__ (RO\_COMPAT\_QUOTA). + - :ref:`Quota ` (RO\_COMPAT\_QUOTA). * - 0x200 - This filesystem supports “bigalloc”, which means that file extents are tracked in units of clusters (of blocks) instead of blocks -- 2.23.0
Re: [PATCH] Documentation: kunit: Fix verification command
On Sat, Sep 7, 2019 at 2:01 PM SeongJae Park wrote:
>
> kunit wrapper script ('kunit.py') receives a sub-command (only 'run' for
> now) as its argument. If no sub-command is given, it prints help
> message and just quit. However, an example command in the kunit
> documentation for a verification of kunit is missing the sub-command.
> This commit fixes the example.
>
> Signed-off-by: SeongJae Park
Reviewed-by: Brendan Higgins
> ---
> Documentation/dev-tools/kunit/start.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/dev-tools/kunit/start.rst
> b/Documentation/dev-tools/kunit/start.rst
> index 6dc229e..aeeddfa 100644
> --- a/Documentation/dev-tools/kunit/start.rst
> +++ b/Documentation/dev-tools/kunit/start.rst
> @@ -43,7 +43,7 @@ wrapper from your kernel repo:
>
> .. code-block:: bash
>
> - ./tools/testing/kunit/kunit.py
> + ./tools/testing/kunit/kunit.py run
Ooops, that's embarrassing; I have the right command a couple lines above.
In anycase, thanks for finding and fixing this!
> .. note::
> You may want to run ``make mrproper`` first.
> --
> 2.7.4
>
Re: [RFC 02/19] ktf: Introduce the main part of the kernel side of ktf
On Tue, Aug 13, 2019 at 08:09:17AM +0200, Knut Omang wrote:
Sorry, it's taken me way too long to get down to a proper code review on
this. I was hoping to send you something a couple weeks ago in
preparation for Tuesday, but I have been crazy busy.
> The ktf module itself and basic data structures for management
> of test cases and tests and contexts for tests.
> Also contains the top level include file for kernel clients
> in ktf.h.
>
> More elaborate documentation follows towards the end of the
> patch set.
>
> This patch set contains both user level and kernel code,
> we'll provide the full implementation of ktf on the kernel side in
> this and forthcoming patches, then the user space code to execute
> tests within the kernel and report results, then documentation
> before introducing a small self test suite of tests to test ktf
> itself, and some very simple additional example tests.
>
> ktf.h: Defines the KTF user API for kernel clients
> ktf_test.c: Kernel side code for tracking and reporting ktf test results
>
> Signed-off-by: Knut Omang
> ---
> tools/testing/selftests/ktf/kernel/Makefile | 15 +-
> tools/testing/selftests/ktf/kernel/ktf.h | 604 -
> tools/testing/selftests/ktf/kernel/ktf_context.c | 409 +++-
> tools/testing/selftests/ktf/kernel/ktf_test.c| 397 +++-
> tools/testing/selftests/ktf/kernel/ktf_test.h| 381 ++-
> 5 files changed, 1806 insertions(+)
> create mode 100644 tools/testing/selftests/ktf/kernel/Makefile
> create mode 100644 tools/testing/selftests/ktf/kernel/ktf.h
> create mode 100644 tools/testing/selftests/ktf/kernel/ktf_context.c
> create mode 100644 tools/testing/selftests/ktf/kernel/ktf_test.c
> create mode 100644 tools/testing/selftests/ktf/kernel/ktf_test.h
[...]
> diff --git a/tools/testing/selftests/ktf/kernel/ktf.h
> b/tools/testing/selftests/ktf/kernel/ktf.h
> new file mode 100644
> index 000..ea270e7
> --- /dev/null
> +++ b/tools/testing/selftests/ktf/kernel/ktf.h
> @@ -0,0 +1,604 @@
> +/*
> + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> + *Author: Knut Omang
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + *
> + * ktf.h: Defines the KTF user API for kernel clients
> + */
> +#ifndef _KTF_H
> +#define _KTF_H
> +
> +#include
> +#include
> +#include
> +#include
> +#include "ktf_test.h"
> +#include "ktf_override.h"
> +#include "ktf_map.h"
Where do you add this file? I don't see any definitions of
`struct ktf_map` in either this or the preceding patches, so I don't
think that this will compile.
> +#include "ktf_unlproto.h"
Same here. This looks important for understanding what you presented
here.
> +#define KTF_MAX_LOG 2048
> +
> +/* Type for an optional configuration callback for contexts.
> + * Implementations should copy and store data into their private
> + * extensions of the context structure. The data pointer is
> + * only valid inside the callback:
> + */
> +typedef int (*ktf_config_cb)(struct ktf_context *ctx, const void* data,
> size_t data_sz);
> +typedef void (*ktf_context_cb)(struct ktf_context *ctx);
> +
> +struct ktf_context_type;
> +
> +struct ktf_context {
> + struct ktf_map_elem elem; /* Linkage for ctx_map in handle */
> + char name[KTF_MAX_KEY];/* Context name used in map */
> + struct ktf_handle *handle; /* Owner of this context */
> + ktf_config_cb config_cb; /* Optional configuration callback */
> + ktf_context_cb cleanup;/* Optional callback upon context release */
> + int config_errno; /* If config_cb set: state of configuration
> */
> + struct ktf_context_type *type; /* Associated type, must be set */
> +};
> +
> +typedef struct ktf_context* (*ktf_context_alloc)(struct ktf_context_type
> *ct);
> +
> +struct ktf_context_type {
> + struct ktf_map_elem elem; /* Linkage for map in handle */
> + char name[KTF_MAX_KEY];/* Context type name */
> + struct ktf_handle *handle; /* Owner of this context type */
> + ktf_context_alloc alloc; /* Allocate a new context of this type */
> + ktf_config_cb config_cb; /* Configuration callback */
> + ktf_context_cb cleanup;/* Optional callback upon context release */
> +};
> +
> +#include "ktf_netctx.h"
> +
> +/* type for a test function */
> +struct ktf_test;
Okay, so a `struct ktf_test` (I know you define it later in the patch);
it seems like it correlates to a `struct kunit_case` in KUnit, correct?
It represents the test to be run, kind of analogous to a
`struct device_driver`, correct?
> +/* state of running test, used to pass to threads spawned by test. */
> +struct ktf_test_state;
> +
> +struct ktf_thread {
> + int (*func)(void *);
> + const char *name;
> + struct task_struct *task;
> + struct ktf_test_state state;
> + struct completion started;
> + struct completion completed;
> +};
So that makes this analogous to `struct kunit` or `st
Re: [RFC 03/19] ktf: Introduce a generic netlink protocol for test result communication
On Tue, Aug 13, 2019 at 08:09:18AM +0200, Knut Omang wrote: > The generic netlink protocol used to communicate between > kernel and user space about tests and test results, as well as some > means for configuring tests within the kernel. > > Unlike other kernel side test code in the kernel, ktf does not print > anything from inside the kernel (except for optional debugging > features to help "internal" debugging of ktf or ktf tests). > Instead all test results are communicated back to the user space > frontend, which decides how to do the reporting. So why netlink? Why not just a file interface? [...] Cheers
