ome/krisman/src/linux/include/linux/kmod.h:28:8: warning: the omitted middle
operand in ‘?:’ will always be ‘true’, suggest explicit middle operand
[-Wparentheses]
28 | ((x) ?: (__request_module(true, mod), (x)))
|^
/home/krisman/src/linux/fs/unicode/unicode-core.c:123:7: note: in expansion of
macro ‘try_then_request_module’
123 | if (!try_then_request_module(utf8mod_get(), "utf8")) {
But in this specific case, i think gcc is just being silly. What would
be the right way to avoid it?
--
Gabriel Krisman Bertazi
e-insensitive and you gotta have utf8 as built-in or have
it in an early userspace.
> I think it should work analogously to CONFIG_FS_ENCRYPTION and
> CONFIG_FS_ENCRYPTION_ALGS. That is, CONFIG_UNICODE should be a
> user-selectable
> bool, and then the tristate symbols CONFIG_EXT4_FS and CONFIG_F2FS_FS should
> select the tristate symbol CONFIG_UNICODE_UTF8 if CONFIG_UNICODE.
--
Gabriel Krisman Bertazi
Shreeya Patel writes:
> On 30/03/21 2:50 am, Gabriel Krisman Bertazi wrote:
>>> +DEFINE_STATIC_CALL(_unicode_strncmp, unicode_strncmp_default);
>>> +EXPORT_STATIC_CALL(_unicode_strncmp);
>>> -int unicode_strncmp(const struct unicode_map *um,
>>> -
unicode_warn_on();
> + return ERR_PTR(-EIO);
> +}
>
> -int unicode_normalize(const struct unicode_map *um, const struct qstr *str,
> - unsigned char *dest, size_t dlen);
> +DECLARE_STATIC_CALL(_unicode_validate, unicode_validate_default);
> +DECLARE_STATIC_CALL(_unicode_strncmp, unicode_strncmp_default);
> +DECLARE_STATIC_CALL(_unicode_strncasecmp, unicode_strncasecmp_default);
> +DECLARE_STATIC_CALL(_unicode_strncasecmp_folded,
> unicode_strncasecmp_folded_default);
> +DECLARE_STATIC_CALL(_unicode_normalize, unicode_normalize_default);
> +DECLARE_STATIC_CALL(_unicode_casefold, unicode_casefold_default);
> +DECLARE_STATIC_CALL(_unicode_casefold_hash, unicode_casefold_hash_default);
> +DECLARE_STATIC_CALL(_unicode_load, unicode_load_default);
nit: I hate this functions starting with a single _ . they are not common in
the
rest of the kernel either.
> -int unicode_casefold(const struct unicode_map *um, const struct qstr *str,
> - unsigned char *dest, size_t dlen);
> +static inline int unicode_validate(const struct unicode_map *um, const
> struct qstr *str)
> +{
> + return static_call(_unicode_validate)(um, str);
> +}
>
> -int unicode_casefold_hash(const struct unicode_map *um, const void *salt,
> - struct qstr *str);
> +static inline int unicode_strncmp(const struct unicode_map *um,
> + const struct qstr *s1, const struct qstr *s2)
> +{
> + return static_call(_unicode_strncmp)(um, s1, s2);
> +}
> +
> +static inline int unicode_strncasecmp(const struct unicode_map *um,
> + const struct qstr *s1, const struct qstr
> *s2)
> +{
> + return static_call(_unicode_strncasecmp)(um, s1, s2);
> +}
> +
> +static inline int unicode_strncasecmp_folded(const struct unicode_map *um,
> + const struct qstr *cf,
> + const struct qstr *s1)
> +{
> + return static_call(_unicode_strncasecmp_folded)(um, cf, s1);
> +}
> +
> +static inline int unicode_normalize(const struct unicode_map *um, const
> struct qstr *str,
> + unsigned char *dest, size_t dlen)
> +{
> + return static_call(_unicode_normalize)(um, str, dest, dlen);
> +}
> +
> +static inline int unicode_casefold(const struct unicode_map *um, const
> struct qstr *str,
> +unsigned char *dest, size_t dlen)
> +{
> + return static_call(_unicode_casefold)(um, str, dest, dlen);
> +}
> +
> +static inline int unicode_casefold_hash(const struct unicode_map *um, const
> void *salt,
> + struct qstr *str)
> +{
> + return static_call(_unicode_casefold_hash)(um, salt, str);
> +}
>
> struct unicode_map *unicode_load(const char *version);
> void unicode_unload(struct unicode_map *um);
>
> +void unicode_register(struct module *owner);
> +void unicode_unregister(void);
> +
> #endif /* _LINUX_UNICODE_H */
--
Gabriel Krisman Bertazi
t; This is not the expected behavior since it would sometimes lead
>> to unloading utf8 even before loading it.
>> Hence, add a condition which will check if sb->encoding is NOT NULL
>> before calling the utf8_unload().
>>
>> Reviewed-by: Gabriel Krisman Bertazi
>
s within a casefolded one will inherit the flag.
> +
> +Example::
> +
> +$ mount -t tmpfs -o casefold=utf8-12.1.0,cf_strict tmpfs /mytmpfs
> +$ cd /mytmpfs
> +$ touch a; touch A
> +$ ls
> +A a
> +$ mkdir dir
> +$ chattr +F dir
> +$ touch dir/a; touch dir/A
> +$ ls dir
> +a
>
> :Author:
> Christoph Rohland , 1.12.01
--
Gabriel Krisman Bertazi
ic const struct file_operations shmem_dir_operations = {
> + .open = dcache_dir_open,
> + .release= dcache_dir_close,
> + .llseek = dcache_dir_lseek,
> + .read = generic_read_dir,
> + .iterate_shared = dcache_readdir,
> + .fsync = noop_fsync,
> + .unlocked_ioctl = shmem_ioctl,
> +};
> +
> static const struct inode_operations shmem_dir_inode_operations = {
> #ifdef CONFIG_TMPFS
> .create = shmem_create,
--
Gabriel Krisman Bertazi
long long size;
> + char version[10];
> char *rest;
> - int opt;
> + int opt, ret;
>
> opt = fs_parse(fc, shmem_fs_parameters, param, );
> if (opt < 0)
> @@ -3468,6 +3519,23 @@ static int shmem_parse_one(struct fs_context *fc,
> struct fs_parameter *param)
> ctx->full_inums = true;
> ctx->seen |= SHMEM_SEEN_INUMS;
> break;
> + case Opt_casefold:
> + if (strncmp(param->string, "utf8-", 5))
> + return invalfc(fc, "Only utf8 encondings are
> supported");
> + ret = strscpy(version, param->string + 5, sizeof(version));
Ugh. Now we are doing two strscpy for the parse api (in unicode_load).
Can change the unicode_load api to reuse it?
thanks,
--
Gabriel Krisman Bertazi
min, rev))
> - return ERR_PTR(-EINVAL);
> -
> - unicode_version = UNICODE_AGE(maj, min, rev);
> - } else {
> - unicode_version = utf8version_latest();
> - printk(KERN_WARNING"UTF-8 version not specified. "
> -"Assuming latest supported version (%d.%d.%d).",
> -(unicode_version >> 16) & 0xff,
> -(unicode_version >> 8) & 0xff,
> -(unicode_version & 0xff));
> - }
> -
> - um = kzalloc(sizeof(struct unicode_map), GFP_KERNEL);
> - if (!um)
> - return ERR_PTR(-ENOMEM);
> -
> - um->charset = "UTF-8";
> - um->version = unicode_version;
> -
> - return um;
> -}
> +{
> + int ret = unicode_load_module();
> +
> + if (ret)
> + return ERR_PTR(ret);
> +
> + spin_lock(_lock);
> + if (!utf8_ops || !try_module_get(utf8_ops->owner)) {
> + spin_unlock(_lock);
> + return ERR_PTR(-ENODEV);
> + } else {
> + spin_unlock(_lock);
> + return static_call(utf8_load)(version);
> + }
> +}
> EXPORT_SYMBOL(unicode_load);
>
> void unicode_unload(struct unicode_map *um)
> {
> - kfree(um);
> + if (WARN_ON(!utf8_ops))
> + return;
> +
> + module_put(utf8_ops->owner);
> + static_call(utf8_unload)(um);
The module reference drop should happen after utf8_unload to prevent
calling utf8_unload after it is removed if you race with module removal.
--
Gabriel Krisman Bertazi
Shreeya Patel writes:
> Rename the file name from utf8-core to unicode-core for transformation of
> utf8-core file into the unicode subsystem layer file and also for better
> understanding.
>
> Signed-off-by: Shreeya Patel
Acked-by: Gabriel Krisman Bertazi
Thanks,
>
Shreeya Patel writes:
> Rename the function names from utf8 to unicode for taking the first step
> towards the transformation of utf8-core file into the unicode subsystem
> layer file.
>
> Signed-off-by: Shreeya Patel
Reviewed-by: Gabriel Krisman Bertazi
Thanks,
> ---
tf8 even before loading it.
> Hence, add a condition which will check if sb->encoding is NOT NULL
> before calling the utf8_unload().
Just to mention this used to be safe, since it was just doing a
kfree(NULL), but won't be anymore after the rest of this series.
Reviewed-by: Gabriel Kris
const char *version,
> unsigned int *maj,
> {0, NULL}
> };
>
> - strncpy(version_string, version, sizeof(version_string));
> + int ret = strscpy(version_string, version, sizeof(version_string));
Usually, no spaces between variable declarations
Shreeya Patel writes:
> On 19/03/21 1:27 am, Gabriel Krisman Bertazi wrote:
>> Maybe, the if leg should be:
>>
>> if (!utf8_ops || !try_module_get(utf8_ops->owner)
>> return ERR_PTR(-ENODEV)
>>
>> But this is still racy, since you are n
.",
> -(unicode_version >> 16) & 0xff,
> -(unicode_version >> 8) & 0xff,
> -(unicode_version & 0xff));
> - }
> -
> - um = kzalloc(sizeof(struct unicode_map), GFP_KERNEL);
> - if (!um)
> - return ERR_PTR(-ENOMEM);
> -
> - um->charset = "UTF-8";
> - um->version = unicode_version;
> -
> - return um;
> + utf8_ops = ops;
While we guarantee that utf8_ops isn't modified when a unicode_map is
in-use by acquiring the module reference, registering/unregistering the
module should be protected, to avoid that race I mentioned above.
> }
> -EXPORT_SYMBOL(unicode_load);
> +EXPORT_SYMBOL(unicode_register);
>
> -void unicode_unload(struct unicode_map *um)
> +void unicode_unregister(void)
> {
> - kfree(um);
> + utf8_ops = NULL;
> }
> -EXPORT_SYMBOL(unicode_unload);
> +EXPORT_SYMBOL(unicode_unregister);
>
> MODULE_LICENSE("GPL v2");
> diff --git a/fs/unicode/utf8mod.c b/fs/unicode/utf8mod.c
> new file mode 100644
> index ..9981960da863
> --- /dev/null
> +++ b/fs/unicode/utf8mod.c
This is a bit nitpicky, but can you follow the naming scheme and call
this file unicode-utf8.c or maybe utf8-mod.c ?
--
Gabriel Krisman Bertazi
Shreeya Patel writes:
> On 14/03/21 7:19 am, Gabriel Krisman Bertazi wrote:
>> Shreeya Patel writes:
>>
>>> utf8data.h_shipped has a large database table which is an auto-generated
>>> decodification trie for the unicode normalization functions.
>>> It
), GFP_KERNEL);
> + if (!um)
> + return ERR_PTR(-ENOMEM);
> +
> + um->charset = "UTF-8";
> + um->version = unicode_version;
> +
> + return um;
> +}
> +
> +static struct unicode_ops ops = {
> + .validate = utf8_validate,
> + .strncmp = utf8_strncmp,
> + .strncasecmp = utf8_strncasecmp,
> + .strncasecmp_folded = utf8_strncasecmp_folded,
> + .casefold = utf8_casefold,
> + .casefold_hash = utf8_casefold_hash,
> + .normalize = utf8_normalize,
> + .load = utf8_load,
> +};
> +
> +static int __init utf8_init(void)
> +{
> + unicode_register();
> + return 0;
> +}
> +
> +static void __exit utf8_exit(void)
> +{
> + unicode_unregister();
> +}
> +
> +module_init(utf8_init);
> +module_exit(utf8_exit);
> +
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/unicode.h b/include/linux/unicode.h
> index de23f9ee720b..b0d59069e438 100644
> --- a/include/linux/unicode.h
> +++ b/include/linux/unicode.h
> @@ -10,6 +10,23 @@ struct unicode_map {
> int version;
> };
>
> +struct unicode_ops {
> + int (*validate)(const struct unicode_map *um, const struct qstr *str);
> + int (*strncmp)(const struct unicode_map *um, const struct qstr *s1,
> +const struct qstr *s2);
> + int (*strncasecmp)(const struct unicode_map *um, const struct qstr *s1,
> +const struct qstr *s2);
> + int (*strncasecmp_folded)(const struct unicode_map *um, const struct
> qstr *cf,
> + const struct qstr *s1);
> + int (*normalize)(const struct unicode_map *um, const struct qstr *str,
> + unsigned char *dest, size_t dlen);
> + int (*casefold)(const struct unicode_map *um, const struct qstr *str,
> + unsigned char *dest, size_t dlen);
> + int (*casefold_hash)(const struct unicode_map *um, const void *salt,
> + struct qstr *str);
> + struct unicode_map* (*load)(const char *version);
> +};
Also, make sure you run checkpatch.pl on the patch series before
submitting.
> +
> int unicode_validate(const struct unicode_map *um, const struct qstr *str);
>
> int unicode_strncmp(const struct unicode_map *um,
> @@ -33,4 +50,7 @@ int unicode_casefold_hash(const struct unicode_map *um,
> const void *salt,
> struct unicode_map *unicode_load(const char *version);
> void unicode_unload(struct unicode_map *um);
>
> +void unicode_register(struct unicode_ops *ops);
> +void unicode_unregister(void);
> +
> #endif /* _LINUX_UNICODE_H */
--
Gabriel Krisman Bertazi
return 1;
>> If you are awakened, you don't need to waste time with trying to get
>> the
>> next key.
>>
>
> Yes, and this is what this return is supposed to do. What I'm missing?
you don't need to do that __get_user if some other key was already awoke.
[...]
if (*awakened >= 0)
return 1;
if (__get_user(uval, uaddr))
return -EFAULT;
[...]
--
Gabriel Krisman Bertazi
ing the
community accepts, including NUMA support, provided we also get
semantics to fix the problem we are trying to solve. But for that, we
gonna need more directioning on what the community is willing to accept
not only regarding the interface, but on internals too.
--
Gabriel Krisman Bertazi
email in a row. But, if futex_wake is just a
futex_wakev with nr_futexes == 1, why do we need two syscalls for that?
Why not only have futex_waitv?
--
Gabriel Krisman Bertazi
Zebediah, one use case Wine has to
support is the ability to wait on all (instead of any) of a list of
futexes . I suppose that could be done by a new FLAG_WAITALL passed on
the third argument of the syscall.
--
Gabriel Krisman Bertazi
futexv
> + * @timo:Timeout
> + * @flags: Timeout flags
> + *
> + * Return:
> + * * 0 >= - Hint of which futex woke us
> + * * 0 < - Error code
> + */
> +static int futex_set_timer_and_wait(struct futexv_head *futexv,
> + unsigned int nr_futexes,
> + struct __kernel_timespec __user *timo,
> + unsigned int flags)
> +{
> + struct hrtimer_sleeper timeout;
> + int ret;
> +
> + if (timo) {
> + ret = futex_setup_time(timo, , flags);
> + if (ret)
> + return ret;
> + }
> +
> + ret = __futex_wait(futexv, nr_futexes, timo ? : NULL);
> +
> + if (timo)
> + hrtimer_cancel();
> +
> + return ret;
> +}
I'm having a hard time understanding why this function exists. part of
the futex is set up outside of it, part inside. Not sure if this isn't
just part of sys_futex_wait.
Thanks,
--
Gabriel Krisman Bertazi
Looking at the code and other documentation, the unit of size is
bytes. Previously, the same documentation says bytes.
Signed-off-by: Gabriel Krisman Bertazi
---
Documentation/watch_queue.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/watch_queue.rst b
info_id needs to be or'ed when initializing a struct watch. That's an
internal detail to the watch_queue api, so fold that logic into the
watch_queue implementation, instead of replicating it on multiple
callers.
Signed-off-by: Gabriel Krisman Bertazi
---
Documentation/watch_queue.rst | 5
Hi David,
You'll find here a couple of misc improvements to watch_queue
documentation and code.
Gabriel Krisman Bertazi (2):
watch_queue: Fold info_id initialization into init_watch
docs: watch_queue: Fix unit of the notification size field
Documentation/watch_queue.rst | 7
374: 4e 80 00 20 blr
>378: 48 00 00 00 b 378
Infinite loop (seems to be on test of MSR_PR)?
Gabriel
>37c: 94 21 ff f0 stwur1,-16(r1)
>380: 7c 08 02 a6 mflrr0
>384: 90 01 00 14 stw r0,
The following commit has been merged into the core/urgent branch of tip:
Commit-ID: 6342adcaa683c2b705c24ed201dc11b35854c88d
Gitweb:
https://git.kernel.org/tip/6342adcaa683c2b705c24ed201dc11b35854c88d
Author:Gabriel Krisman Bertazi
AuthorDate:Wed, 03 Feb 2021 13:00:48 -05
The following commit has been merged into the core/urgent branch of tip:
Commit-ID: 36a6c843fd0d8e02506681577e96dabd203dd8e8
Gitweb:
https://git.kernel.org/tip/36a6c843fd0d8e02506681577e96dabd203dd8e8
Author:Gabriel Krisman Bertazi
AuthorDate:Fri, 05 Feb 2021 13:43:21 -05
this changes the API, it is backward compatible, as the values
remained the same and the old defines are still in place. In addition,
SUD has never been part of a Linux release, it will show up for the
first time in 5.11.
Cc: Linux API
Suggested-by: Michael Kerrisk (man-pages)
Signed-off-by: Gabriel
this changes the API, it is backward compatible, as the values
remained the same and the old defines are still in place. In addition,
SUD has never been part of a Linux release, it will show up for the
first time in 5.11.
Cc: Linux API
Suggested-by: Michael Kerrisk (man-pages)
Signed-off-by: Gabriel
uggested-by: Linus Torvalds
Fixes: 299155244770 ("entry: Drop usage of TIF flags in the generic syscall
code")
Signed-off-by: Gabriel Krisman Bertazi
---
arch/x86/include/asm/entry-common.h | 2 --
arch/x86/kernel/step.c | 10 --
include/linux/entry-common.h| 1
you and Thomas during
the first part of the week, for the next -rc. I will also review the x86
version of ARCH_SYSCALL_EXIT WORK to make sure i didn't miss anything
else.
Reverting would be slightly be annoying as it requires reverting syscall
user dispatch as well.
--
Gabriel Krisman Bertazi
e.
To gather the right attention, you should directly CC the correct maintainers.
Fixes: 64eb35f701f0 ("ptrace: Migrate TIF_SYSCALL_EMU to use SYSCALL_WORK flag")
Reviewed-by: Gabriel Krisman Bertazi
--
Gabriel Krisman Bertazi
Paul Lawrence writes:
> Below patch will cause NULL ptr dereferences if the optional filenames
> are not present.
>
> Fixes: ef3ba87cb7c9 (um: ubd: Set device serial attribute from cmdline)
> Signed-off-by: Paul Lawrence
Looks good.
Reviewed-by: Gabriel Krisman Bertazi
To
[write|read][8|16|32|64]()'.
This patch renames 'litex_[set|get]_reg()' to '_litex_[set|get]_reg()',
indicating that they should NOT be directly called from outside of
the 'include/linux/litex.h' header file.
Signed-off-by: Gabriel Somlo
---
Changes since v5:
- fixed typo in "c
Move generic LiteX CSR (MMIO) register accessors to litex.h and
declare them as "static inline", in preparation for supporting
32-bit CSR subregisters and 64-bit CPUs.
NOTE: this is a non-functional change.
Signed-off-by: Gabriel Somlo
---
drivers/soc/litex/litex_soc_c
The constant LITEX_REG_SIZE is renamed to the more descriptive
LITEX_SUBREG_ALIGN (LiteX CSR subregisters are located at 32-bit
aligned MMIO addresses).
NOTE: this is a non-functional change.
Signed-off-by: Gabriel Somlo
---
include/linux/litex.h | 8 +---
1 file changed, 5 insertions
the added benefit of automatically matching the appropriate
LITEX_SUBREG_SIZE.
NOTE that litex_[get|set]_reg() nominally operate on 64-bit data,
but that will also be optimized by the compiler in situations where
narrower data is used from a call site.
Signed-off-by: Gabriel Somlo
---
Change
]_reg()
(compiler should produce code as efficient as hardcoded shifts,
but also automatically matching LITEX_SUBREG_SIZE).
Gabriel Somlo (5):
drivers/soc/litex: move generic accessors to litex.h
drivers/soc/litex: separate MMIO from subregister offset calculation
dr
Separate MMIO (read/write) access into _[read|write]_litex_subregister()
static inline functions, leaving existing "READ|WRITE" macros to handle
calculation of the subregister offset only.
NOTE: this is a non-functional change.
Signed-off-by: Gabriel Somlo
---
include/linux/li
ptimization, will result in code as efficient as hardcoded shifts,
> > but with the added benefit of automatically matching the appropriate
> > LITEX_SUBREG_SIZE.
> >
> > NOTE that litex_[get|set]_reg() nominally operate on 64-bit data,
> > but that will also be optimized by the
Ping :)
On Sun, Dec 27, 2020 at 11:13:16AM -0500, Gabriel Somlo wrote:
> This series expands on commit 22447a99c97e ("drivers/soc/litex: add LiteX
> SoC Controller driver"), adding support for handling both 8- and 32-bit
> LiteX CSR (MMIO) subregisters, on both 32- and 64-bit
this changes the API, it is backward compatible, as the values
remained the same and the old defines are still in place. In addition,
SUD has never been part of a Linux release, it will show up for the
first time in 5.11.
Cc: Linux API
Suggested-by: Michael Kerrisk (man-pages)
Signed-off-by: Gabriel
On Sun, Dec 27, 2020 at 11:13:20AM -0500, Gabriel Somlo wrote:
> The 'litex_[set|get]_reg()' methods use the 'reg_size' parameter to
> specify the width of the LiteX CSR (MMIO) register being accessed.
>
> Since 'u64' is the widest data being supported, the value of 'reg_size'
> MU
ead|write][8|16|32|64]() using litex_[get|set]_reg()
(compiler should produce code as efficient as hardcoded shifts,
but also automatically matching LITEX_SUBREG_SIZE).
Gabriel Somlo (4):
drivers/soc/litex: move generic accessors to litex.h
drivers/soc/litex: separate MMIO from
[write|read][8|16|32|64]()'.
This patch renames 'litex_[set|get]_reg()' to '_litex_[set|get]_reg()',
indicating that they should NOT be directly called from outside of
the 'include/linux/litex.h' header file.
Signed-off-by: Gabriel Somlo
---
drivers/soc/litex/Kconfig | 2 +-
include/linux
4-bit data,
but that will also be optimized by the compiler in situations where
narrower data is used from a call site.
Signed-off-by: Gabriel Somlo
---
Changes since v4:
- tighter, more optimized implementation of 'litex_set_reg()'
Changes since v3:
- improved legibility, fixed typos in co
Separate MMIO (read/write) access into _[read|write]_litex_subregister()
static inline functions, leaving existing "READ|WRITE" macros to handle
calculation of the subregister offset only.
NOTE: this is a non-functional change.
Signed-off-by: Gabriel Somlo
---
include/linux/li
Move generic LiteX CSR (MMIO) register accessors to litex.h and
declare them as "static inline", in preparation for supporting
32-bit CSR subregisters and 64-bit CPUs.
NOTE: this is a non-functional change.
Signed-off-by: Gabriel Somlo
---
drivers/soc/litex/litex_soc_c
_SUBREG_ALIGN!
- move litex_[get|set]_reg() to include/linux/litex.h and mark
them as "static inline";
- redo litex_[read|write][8|16|32|64]() using litex_[get|set]_reg()
(compiler should produce code as efficient as hardcoded shifts,
but also a
Separate MMIO (read/write) access into _[read|write]_litex_subregister()
static inline functions, leaving existing "READ|WRITE" macros to handle
calculation of the subregister offset only.
NOTE: this is a non-functional change.
Signed-off-by: Gabriel Somlo
---
include/linux/li
Move generic LiteX CSR (MMIO) register accessors to litex.h and
declare them as "static inline", in preparation for supporting
32-bit CSR subregisters and 64-bit CPUs.
NOTE: this is a non-functional change.
Signed-off-by: Gabriel Somlo
---
drivers/soc/litex/litex_soc_c
4-bit data,
but that will also be optimized by the compiler in situations where
narrower data is used from a call site.
Signed-off-by: Gabriel Somlo
---
drivers/soc/litex/Kconfig | 12 +++
drivers/soc/litex/litex_soc_ctrl.c | 3 +-
include/linux/litex.h | 141 --
On Fri, Dec 25, 2020 at 09:21:20AM -0500, Gabriel Somlo wrote:
> Upstream LiteX now defaults to using 32-bit CSR subregisters
> (see https://github.com/enjoy-digital/litex/commit/a2b71fde).
>
> This patch expands on commit 22447a99c97e ("drivers/soc/litex: add
> LiteX S
ut also automatically matching LITEX_SUBREG_SIZE).
Gabriel Somlo (3):
drivers/soc/litex: move generic accessors to litex.h
drivers/soc/litex: separate MMIO from subregister offset calculation
drivers/soc/litex: support 32-bit subregisters, 64-bit CPUs
drivers/soc/litex/Kconfig
Separate MMIO (read/write) access into _[read|write]_litex_subregister()
static inline functions, leaving existing "READ|WRITE" macros to handle
calculation of the subregister offset only.
NOTE: this is a non-functional change.
Signed-off-by: Gabriel Somlo
---
include/linux/li
t
that too will be optimized away by the compiler in situations where
narrower data is used.
Signed-off-by: Gabriel Somlo
---
drivers/soc/litex/Kconfig | 12 +++
drivers/soc/litex/litex_soc_ctrl.c | 3 +-
include/linux/litex.h | 139 -
3 fil
Move generic LiteX CSR (MMIO) register accessors to litex.h and
declare them as "static inline", in preparation for supporting
32-bit CSR subregisters and 64-bit CPUs.
NOTE: this is a non-functional change.
Signed-off-by: Gabriel Somlo
---
drivers/soc/litex/litex_soc_c
Am Mi., 23. Dez. 2020 um 11:41 Uhr schrieb Jan Engelhardt :
>
>
> On Tuesday 2020-12-22 04:58, Guenter Roeck wrote:
> >On 12/21/20 5:45 PM, Gabriel C wrote:
> >> Hello Guenter,
> >>
> >> while trying to add ZEN3 support for zenpower out of tree modules, I
Am Mi., 23. Dez. 2020 um 11:41 Uhr schrieb Jan Engelhardt :
>
>
> On Tuesday 2020-12-22 04:58, Guenter Roeck wrote:
> >On 12/21/20 5:45 PM, Gabriel C wrote:
> >> Hello Guenter,
> >>
> >> while trying to add ZEN3 support for zenpower out of tree modules, I
The module has only support for Zen3 server CPUs right now.
Add support for Family 0x19, model 0x21 which are Zen3 Ryzen Desktop CPUs.
Tested on 5800x, 5900x and 5950x CPUs.
Signed-off-by: Gabriel Craciunescu
---
drivers/hwmon/k10temp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
option.
Signed-off-by: Gabriel Somlo
---
Notes v2:
- fix typo (s/u32/u64/) in litex_read64().
Notes v1:
- LITEX_SUBREG_SIZE now provided by Kconfig.
- it's not LITEX_REG_SIZE, but rather LITEX_SUBREG_ALIGN!
- move litex_[get|set]_reg() to include/linux/litex.h
Am Di., 22. Dez. 2020 um 07:16 Uhr schrieb Guenter Roeck :
>
> On Tue, Dec 22, 2020 at 05:33:17AM +0100, Gabriel C wrote:
> [ ... ]
> > At least is what the weird amd_energy driver added and since is only
> > supporting
> > fam 17h model 0x31 which is TR 3000 &
option.
Signed-off-by: Gabriel Somlo
---
Notes v1:
- LITEX_SUBREG_SIZE now provided by Kconfig.
- it's not LITEX_REG_SIZE, but rather LITEX_SUBREG_ALIGN!
- move litex_[get|set]_reg() to include/linux/litex.h and mark
them as "static inline";
Am Di., 22. Dez. 2020 um 05:33 Uhr schrieb Wei Huang :
>
>
>
> On 12/21/20 9:58 PM, Guenter Roeck wrote:
> > Hi,
> >
> > On 12/21/20 5:45 PM, Gabriel C wrote:
> >> Hello Guenter,
> >>
> >> while trying to add ZEN3 support for zenpower
Am Di., 22. Dez. 2020 um 04:58 Uhr schrieb Guenter Roeck :
>
> Hi,
>
> On 12/21/20 5:45 PM, Gabriel C wrote:
> > Hello Guenter,
> >
> > while trying to add ZEN3 support for zenpower out of tree modules, I find
> > out
> > the in-kernel k10temp driver is
ing for both drivers:
https://github.com/ocerman/zenpower/issues/39
Best Regards,
Gabriel C
Greeting to you my Dearest,
Please I need your help and Assistance. Permit me to inform you of my
desire of going into business relationship with you. I am Miss. Esther
Gabriel, the only Daughter of late Mr. and Mrs. Gabriel Kadjo. My
father was a very wealthy cocoa merchant in Abidjan
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 1446e1df9eb183fdf81c3f0715402f1d7595d4cb
Gitweb:
https://git.kernel.org/tip/1446e1df9eb183fdf81c3f0715402f1d7595d4cb
Author:Gabriel Krisman Bertazi
AuthorDate:Fri, 27 Nov 2020 14:32:34 -05
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 11894468e39def270199f845b76df6c36d4ed133
Gitweb:
https://git.kernel.org/tip/11894468e39def270199f845b76df6c36d4ed133
Author:Gabriel Krisman Bertazi
AuthorDate:Fri, 27 Nov 2020 14:32:35 -05
The following commit has been merged into the core/entry branch of tip:
Commit-ID: d87ae0fa21c26db2d7c66f22dee9c27ecda48ce2
Gitweb:
https://git.kernel.org/tip/d87ae0fa21c26db2d7c66f22dee9c27ecda48ce2
Author:Gabriel Krisman Bertazi
AuthorDate:Fri, 27 Nov 2020 14:32:37 -05
The following commit has been merged into the core/entry branch of tip:
Commit-ID: a4452e671c6770e1bb80764f39995934067f70a0
Gitweb:
https://git.kernel.org/tip/a4452e671c6770e1bb80764f39995934067f70a0
Author:Gabriel Krisman Bertazi
AuthorDate:Fri, 27 Nov 2020 14:32:38 -05
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 179ef035992e89646e17138b18b130bb874b86bb
Gitweb:
https://git.kernel.org/tip/179ef035992e89646e17138b18b130bb874b86bb
Author:Gabriel Krisman Bertazi
AuthorDate:Fri, 27 Nov 2020 14:32:36 -05
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 1d7637d89cfce54a4f4a41c2325288c2f47470e8
Gitweb:
https://git.kernel.org/tip/1d7637d89cfce54a4f4a41c2325288c2f47470e8
Author:Gabriel Krisman Bertazi
AuthorDate:Fri, 27 Nov 2020 14:32:33 -05
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 5a5c45c624b8851cbfd269d5b0a8856a2b728502
Gitweb:
https://git.kernel.org/tip/5a5c45c624b8851cbfd269d5b0a8856a2b728502
Author:Gabriel Krisman Bertazi
AuthorDate:Fri, 27 Nov 2020 14:32:35 -05
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 3e8df777fbf4531a4ec740aae991090baed27856
Gitweb:
https://git.kernel.org/tip/3e8df777fbf4531a4ec740aae991090baed27856
Author:Gabriel Krisman Bertazi
AuthorDate:Fri, 27 Nov 2020 14:32:37 -05
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 7a2cc679e8bb5bfdeef28ec80dc3c34edbc099fd
Gitweb:
https://git.kernel.org/tip/7a2cc679e8bb5bfdeef28ec80dc3c34edbc099fd
Author:Gabriel Krisman Bertazi
AuthorDate:Fri, 27 Nov 2020 14:32:34 -05
The following commit has been merged into the core/entry branch of tip:
Commit-ID: c5c878125ad5aca199dfc10b1af4010165aaa596
Gitweb:
https://git.kernel.org/tip/c5c878125ad5aca199dfc10b1af4010165aaa596
Author:Gabriel Krisman Bertazi
AuthorDate:Fri, 27 Nov 2020 14:32:32 -05
The following commit has been merged into the core/entry branch of tip:
Commit-ID: a4cff1161486c47a5d303f913d5d2fcba26cc553
Gitweb:
https://git.kernel.org/tip/a4cff1161486c47a5d303f913d5d2fcba26cc553
Author:Gabriel Krisman Bertazi
AuthorDate:Fri, 27 Nov 2020 14:32:38 -05
The following commit has been merged into the core/entry branch of tip:
Commit-ID: c33fb498e133d8d059ad779d621d6a64315ca746
Gitweb:
https://git.kernel.org/tip/c33fb498e133d8d059ad779d621d6a64315ca746
Author:Gabriel Krisman Bertazi
AuthorDate:Fri, 27 Nov 2020 14:32:36 -05
() examines context to skip the
tracepoint, audit and other work.
Signed-off-by: Gabriel Krisman Bertazi
Acked-by: Peter Zijlstra (Intel)
---
Changes since v6:
- Update do_syscall_intercept signature (Christian Brauner)
- Move it to before tracepoints
- Use SYSCALL_WORK flags
---
include
/lists/linux-kselftest/msg16377.html
v5: https://lkml.org/lkml/2020/8/10/1320
v6: https://lkml.org/lkml/2020/9/4/1122
v7: https://lwn.net/Articles/837598/
Gabriel Krisman Bertazi (7):
x86: vdso: Expose sigreturn address on vdso to the kernel
signal: Expose SYS_USER_DISPATCH si_code type
kernel
avoid dispatching syscalls from that region to userspace.
Suggested-by: Andy Lutomirski
Signed-off-by: Gabriel Krisman Bertazi
Acked-by: Andy Lutomirski
Reviewed-by: Kees Cook
Acked-by: Peter Zijlstra (Intel)
---
Changes since V5
- Change return address to bool (Andy)
---
arch/x86/entry/vdso
, with SMAP off, the overhead is consistently less than 5ns on my
test box.
Cc: Matthew Wilcox
Cc: Andy Lutomirski
Cc: Paul Gofman
Cc: Kees Cook
Cc: linux-...@vger.kernel.org
Signed-off-by: Gabriel Krisman Bertazi
Acked-by: Peter Zijlstra (Intel)
---
Changes since v7:
- Correct half-open
Explain the interface, provide some background and security notes.
Signed-off-by: Gabriel Krisman Bertazi
Reviewed-by: Kees Cook
Acked-by: Peter Zijlstra (Intel)
---
Changes since v7:
- Change process -> thread (Florian Weimer)
- Drop bogus reference to CONFIG_SYSCALL_USER_DISPATCH
Implement functionality tests for syscall user dispatch. In order to
make the test portable, refrain from open coding syscall dispatchers and
calculating glibc memory ranges.
Signed-off-by: Gabriel Krisman Bertazi
Acked-by: Kees Cook
Acked-by: Peter Zijlstra (Intel)
---
Changes since v6
SYS_USER_DISPATCH will be triggered when a syscall is sent to userspace
by the Syscall User Dispatch mechanism. This adjusts eventual
BUILD_BUG_ON around the tree.
Signed-off-by: Gabriel Krisman Bertazi
Acked-by: Kees Cook
Acked-by: Christian Brauner
Acked-by: Peter Zijlstra (Intel
= 3750
Avg syscall time 134ns.
Caught sys_ff00
trapped_call_count 1, native_call_count 0.
Avg syscall time 147ns.
Interception overhead: 9.7% (+13ns).
Signed-off-by: Gabriel Krisman Bertazi
Acked-by: Peter Zijlstra (Intel)
---
.../selftests/syscall_user_dispatch/Makefile | 2
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 5903f61e035320104394f721f74cd22171636f63
Gitweb:
https://git.kernel.org/tip/5903f61e035320104394f721f74cd22171636f63
Author:Gabriel Krisman Bertazi
AuthorDate:Mon, 23 Nov 2020 10:54:58 -05
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 0395124a2fbff5132afee5767071ebe7e05885ac
Gitweb:
https://git.kernel.org/tip/0395124a2fbff5132afee5767071ebe7e05885ac
Author:Gabriel Krisman Bertazi
AuthorDate:Mon, 23 Nov 2020 10:54:58 -05
applying the commit?
The patch I submitted is different from what is in the TIP tree.
https://www.spinics.net/lists/arm-kernel/msg857461.html
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=core/entry
--
Gabriel Krisman Bertazi
work/patch/1344098/
Thanks,
--
Gabriel Krisman Bertazi
y/+/1483316/2#message-2e1f6ab0010a3e35e7d8effea73f60341f84ee4d
>>
>> Just found it by chance (and not sure if it's vital for now), and
>> a kind reminder about this.
>>
>
> Yes, overlayfs doesn't work on ext4 or f2fs filesystems that have the casefold
> feature e
Eric Biggers writes:
> On Sat, Nov 21, 2020 at 11:45:41PM -0500, Gabriel Krisman Bertazi wrote:
>> > diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>> > index 6633b20224d5..0288bedf46e1 100644
>> > --- a/fs/ext4/super.c
>> > +++ b/fs/ext4/super.c
Gabriel Krisman Bertazi writes:
> Jann Horn writes:
>> As part of fixing this, it might be a good idea to put "enum
>> syscall_work_bit" behind a "#ifdef CONFIG_GENERIC_ENTRY" to avoid
>> future accidents like this?
>
> Hi Jan, Arnd,
>
>
ot; to check if filter is constant
>> > allow
>> > f9d480b6ffbe seccomp/cache: Lookup syscall allowlist bitmap for fast path
>> > 23d67a54857a seccomp: Migrate to use SYSCALL_WORK flag
>> >
>> >
>> > Please find these easy steps to reproduce the
s we can get away with, maximizing compatibility with overlayfs, which
> will not function if a filesystem supports certain dentry_operations.
>
> Signed-off-by: Daniel Rosenberg
> Reviewed-by: Eric Biggers
Reviewed-by: Gabriel Krisman Bertazi
--
Gabriel Krisman Bertazi
,
> * directory's encryption key is available, then the lookup is assumed to be
> by
> * plaintext name; otherwise, it is assumed to be by no-key name.
> *
> - * This also installs a custom ->d_revalidate() method which will invalidate
> the
> - * dentry if it was created without the key and the key is later added.
> + * This will set DCACHE_NOKEY_NAME on the dentry if the lookup is by no-key
> + * name. In this case the filesystem must assign the dentry a
> dentry_operations
> + * which contains fscrypt_d_revalidate (or contains a d_revalidate method
> that
> + * calls fscrypt_d_revalidate), so that the dentry will be invalidated if the
> + * directory's encryption key is later added.
> *
> * Return: 0 on success; -ENOENT if the directory's key is unavailable but
> the
> * filename isn't a valid no-key name, so a negative dentry should be
> created;
--
Gabriel Krisman Bertazi
Gabriel Krisman Bertazi writes:
> Introduce a mechanism to quickly disable/enable syscall handling for a
> specific process and redirect to userspace via SIGSYS. This is useful
> for processes with parts that require syscall redirection and parts that
> don't, but who nee
Rich Felker writes:
> On Thu, Nov 19, 2020 at 11:15:46AM -0500, Gabriel Krisman Bertazi wrote:
>> Rich Felker writes:
>>
>> > On Wed, Nov 18, 2020 at 01:57:26PM -0500, Gabriel Krisman Bertazi via
>> > Libc-alpha wrote:
>>
>> [...]
>&g
1 - 100 of 2879 matches
Mail list logo
