All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shreeya Patel <shreeya.patel@collabora.com>
To: Eric Biggers <ebiggers@kernel.org>,
	Gabriel Krisman Bertazi <krisman@collabora.com>
Cc: tytso@mit.edu, adilger.kernel@dilger.ca, jaegeuk@kernel.org,
	chao@kernel.org, drosen@google.com, yuchao0@huawei.com,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, kernel@collabora.com,
	andre.almeida@collabora.com
Subject: Re: [PATCH v3 5/5] fs: unicode: Add utf8 module and a unicode layer
Date: Wed, 24 Mar 2021 03:48:10 +0530	[thread overview]
Message-ID: <dd7dae42-6024-8868-3e3e-f6d672274682@collabora.com> (raw)
In-Reply-To: <YFpPxCQiMLqctIuS@gmail.com>


On 24/03/21 1:59 am, Eric Biggers wrote:
> On Tue, Mar 23, 2021 at 03:51:44PM -0400, Gabriel Krisman Bertazi wrote:
>>> -int unicode_validate(const struct unicode_map *um, const struct qstr *str)
>>> -{
>>> -	const struct utf8data *data = utf8nfdi(um->version);
>>> -
>>> -	if (utf8nlen(data, str->name, str->len) < 0)
>>> -		return -1;
>>> -	return 0;
>>> -}
>>> +struct unicode_ops *utf8_ops;
>>> +EXPORT_SYMBOL(utf8_ops);
>>> +
>>> +int _utf8_validate(const struct unicode_map *um, const struct qstr *str)
>>> +{
>>> +	return 0;
>>> +}
>>> -EXPORT_SYMBOL(unicode_validate);
>> I think that any calls to the default static calls should return errors
>> instead of succeeding without doing anything.
>>
>> In fact, are the default calls really necessary?  If someone gets here,
>> there is a bug elsewhere, so WARN_ON and maybe -EIO.
>>
>> int unicode_validate_default_static_call(...)
>> {
>>     WARN_ON(1);
>>     return -EIO;
>> }
>>
>> Or just have a NULL default, as I mentioned below, if that is possible.
>>
> [...]
>>> +DEFINE_STATIC_CALL(utf8_validate, _utf8_validate);
>>> +DEFINE_STATIC_CALL(utf8_strncmp, _utf8_strncmp);
>>> +DEFINE_STATIC_CALL(utf8_strncasecmp, _utf8_strncasecmp);
>>> +DEFINE_STATIC_CALL(utf8_strncasecmp_folded, _utf8_strncasecmp_folded);
>>> +DEFINE_STATIC_CALL(utf8_normalize, _utf8_normalize);
>>> +DEFINE_STATIC_CALL(utf8_casefold, _utf8_casefold);
>>> +DEFINE_STATIC_CALL(utf8_casefold_hash, _utf8_casefold_hash);
>>> +DEFINE_STATIC_CALL(utf8_load, _utf8_load);
>>> +DEFINE_STATIC_CALL_NULL(utf8_unload, _utf8_unload);
>>> +EXPORT_STATIC_CALL(utf8_strncmp);
>>> +EXPORT_STATIC_CALL(utf8_strncasecmp);
>>> +EXPORT_STATIC_CALL(utf8_strncasecmp_folded);
>> I'm having a hard time understanding why some use
>> DEFINE_STATIC_CALL_NULL, while other use DEFINE_STATIC_CALL.  This new
>> static call API is new to me :).  None of this can be called if the
>> module is not loaded anyway, so perhaps the default function can just be
>> NULL, per the documentation of include/linux/static_call.h?
>>
>> Anyway, Aren't utf8_{validate,casefold,normalize} missing the
>> equivalent EXPORT_STATIC_CALL?
>>
> The static_call API is fairly new to me too.  But the intent of this patch seems
> to be that none of the utf8 functions are called without the utf8 module loaded.
> If they are called, it's a kernel bug.  So there are two options for what to do
> if it happens anyway:
>
>    1. call a "null" static call, which does nothing
>
> *or*
>
>    2. call a default function which does WARN_ON_ONCE() and returns an error if
>       possible.
>
> (or 3. don't use static calls and instead dereference a NULL utf8_ops like
> previous versions of this patch did.)
>
> It shouldn't really matter which of these approaches you take, but please be
> consistent and use the same one everywhere.
>
>> + void unicode_unregister(void)
>> + {
>> +         spin_lock(&utf8ops_lock);
>> +         utf8_ops = NULL;
>> +         spin_unlock(&utf8ops_lock);
>> + }
>> + EXPORT_SYMBOL(unicode_unregister);
> This should restore the static calls to their default values (either NULL or the
> default functions, depending on what you decide).
>
> Also, it's weird to still have the utf8_ops structure when using static calls.
> It seems it should be one way or the other: static calls *or* utf8_ops.
>
> The static calls could be exported, and the module could be responsible for
> updating them.  That would eliminate the need for utf8_ops.


Hmmm yes, I think we are just using utf8_ops for getting the owner details
which we can now remove and instead pass it as an argument while 
registering the module.
Will make this change in v4. Thanks


>
> - Eric

WARNING: multiple messages have this Message-ID (diff)
From: Shreeya Patel <shreeya.patel@collabora.com>
To: Eric Biggers <ebiggers@kernel.org>,
	Gabriel Krisman Bertazi <krisman@collabora.com>
Cc: tytso@mit.edu, drosen@google.com, linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net, kernel@collabora.com,
	adilger.kernel@dilger.ca, linux-fsdevel@vger.kernel.org,
	jaegeuk@kernel.org, andre.almeida@collabora.com,
	linux-ext4@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH v3 5/5] fs: unicode: Add utf8 module and a unicode layer
Date: Wed, 24 Mar 2021 03:48:10 +0530	[thread overview]
Message-ID: <dd7dae42-6024-8868-3e3e-f6d672274682@collabora.com> (raw)
In-Reply-To: <YFpPxCQiMLqctIuS@gmail.com>


On 24/03/21 1:59 am, Eric Biggers wrote:
> On Tue, Mar 23, 2021 at 03:51:44PM -0400, Gabriel Krisman Bertazi wrote:
>>> -int unicode_validate(const struct unicode_map *um, const struct qstr *str)
>>> -{
>>> -	const struct utf8data *data = utf8nfdi(um->version);
>>> -
>>> -	if (utf8nlen(data, str->name, str->len) < 0)
>>> -		return -1;
>>> -	return 0;
>>> -}
>>> +struct unicode_ops *utf8_ops;
>>> +EXPORT_SYMBOL(utf8_ops);
>>> +
>>> +int _utf8_validate(const struct unicode_map *um, const struct qstr *str)
>>> +{
>>> +	return 0;
>>> +}
>>> -EXPORT_SYMBOL(unicode_validate);
>> I think that any calls to the default static calls should return errors
>> instead of succeeding without doing anything.
>>
>> In fact, are the default calls really necessary?  If someone gets here,
>> there is a bug elsewhere, so WARN_ON and maybe -EIO.
>>
>> int unicode_validate_default_static_call(...)
>> {
>>     WARN_ON(1);
>>     return -EIO;
>> }
>>
>> Or just have a NULL default, as I mentioned below, if that is possible.
>>
> [...]
>>> +DEFINE_STATIC_CALL(utf8_validate, _utf8_validate);
>>> +DEFINE_STATIC_CALL(utf8_strncmp, _utf8_strncmp);
>>> +DEFINE_STATIC_CALL(utf8_strncasecmp, _utf8_strncasecmp);
>>> +DEFINE_STATIC_CALL(utf8_strncasecmp_folded, _utf8_strncasecmp_folded);
>>> +DEFINE_STATIC_CALL(utf8_normalize, _utf8_normalize);
>>> +DEFINE_STATIC_CALL(utf8_casefold, _utf8_casefold);
>>> +DEFINE_STATIC_CALL(utf8_casefold_hash, _utf8_casefold_hash);
>>> +DEFINE_STATIC_CALL(utf8_load, _utf8_load);
>>> +DEFINE_STATIC_CALL_NULL(utf8_unload, _utf8_unload);
>>> +EXPORT_STATIC_CALL(utf8_strncmp);
>>> +EXPORT_STATIC_CALL(utf8_strncasecmp);
>>> +EXPORT_STATIC_CALL(utf8_strncasecmp_folded);
>> I'm having a hard time understanding why some use
>> DEFINE_STATIC_CALL_NULL, while other use DEFINE_STATIC_CALL.  This new
>> static call API is new to me :).  None of this can be called if the
>> module is not loaded anyway, so perhaps the default function can just be
>> NULL, per the documentation of include/linux/static_call.h?
>>
>> Anyway, Aren't utf8_{validate,casefold,normalize} missing the
>> equivalent EXPORT_STATIC_CALL?
>>
> The static_call API is fairly new to me too.  But the intent of this patch seems
> to be that none of the utf8 functions are called without the utf8 module loaded.
> If they are called, it's a kernel bug.  So there are two options for what to do
> if it happens anyway:
>
>    1. call a "null" static call, which does nothing
>
> *or*
>
>    2. call a default function which does WARN_ON_ONCE() and returns an error if
>       possible.
>
> (or 3. don't use static calls and instead dereference a NULL utf8_ops like
> previous versions of this patch did.)
>
> It shouldn't really matter which of these approaches you take, but please be
> consistent and use the same one everywhere.
>
>> + void unicode_unregister(void)
>> + {
>> +         spin_lock(&utf8ops_lock);
>> +         utf8_ops = NULL;
>> +         spin_unlock(&utf8ops_lock);
>> + }
>> + EXPORT_SYMBOL(unicode_unregister);
> This should restore the static calls to their default values (either NULL or the
> default functions, depending on what you decide).
>
> Also, it's weird to still have the utf8_ops structure when using static calls.
> It seems it should be one way or the other: static calls *or* utf8_ops.
>
> The static calls could be exported, and the module could be responsible for
> updating them.  That would eliminate the need for utf8_ops.


Hmmm yes, I think we are just using utf8_ops for getting the owner details
which we can now remove and instead pass it as an argument while 
registering the module.
Will make this change in v4. Thanks


>
> - Eric


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2021-03-23 22:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-23 18:31 [PATCH v3 0/4] Make UTF-8 encoding loadable Shreeya Patel
2021-03-23 18:31 ` [f2fs-dev] " Shreeya Patel
2021-03-23 18:31 ` [PATCH v3 1/5] fs: unicode: Use strscpy() instead of strncpy() Shreeya Patel
2021-03-23 18:31   ` [f2fs-dev] " Shreeya Patel
2021-03-23 19:09   ` Gabriel Krisman Bertazi
2021-03-23 19:09     ` [f2fs-dev] " Gabriel Krisman Bertazi
2021-03-23 18:31 ` [PATCH v3 2/5] fs: Check if utf8 encoding is loaded before calling utf8_unload() Shreeya Patel
2021-03-23 18:31   ` [f2fs-dev] " Shreeya Patel
2021-03-23 19:10   ` Gabriel Krisman Bertazi
2021-03-23 19:10     ` [f2fs-dev] " Gabriel Krisman Bertazi
2021-03-23 18:31 ` [PATCH v3 3/5] fs: unicode: Rename function names from utf8 to unicode Shreeya Patel
2021-03-23 18:31   ` [f2fs-dev] " Shreeya Patel
2021-03-23 19:14   ` Gabriel Krisman Bertazi
2021-03-23 19:14     ` [f2fs-dev] " Gabriel Krisman Bertazi
2021-03-23 18:32 ` [PATCH v3 4/5] fs: unicode: Rename utf8-core file to unicode-core Shreeya Patel
2021-03-23 18:32   ` [f2fs-dev] " Shreeya Patel
2021-03-23 19:15   ` Gabriel Krisman Bertazi
2021-03-23 19:15     ` [f2fs-dev] " Gabriel Krisman Bertazi
2021-03-23 18:32 ` [PATCH v3 5/5] fs: unicode: Add utf8 module and a unicode layer Shreeya Patel
2021-03-23 18:32   ` [f2fs-dev] " Shreeya Patel
2021-03-23 19:51   ` Gabriel Krisman Bertazi
2021-03-23 19:51     ` [f2fs-dev] " Gabriel Krisman Bertazi
2021-03-23 20:29     ` Eric Biggers
2021-03-23 20:29       ` [f2fs-dev] " Eric Biggers
2021-03-23 22:18       ` Shreeya Patel [this message]
2021-03-23 22:18         ` Shreeya Patel
2021-03-23 22:12     ` Shreeya Patel
2021-03-23 22:12       ` [f2fs-dev] " Shreeya Patel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dd7dae42-6024-8868-3e3e-f6d672274682@collabora.com \
    --to=shreeya.patel@collabora.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=andre.almeida@collabora.com \
    --cc=chao@kernel.org \
    --cc=drosen@google.com \
    --cc=ebiggers@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=kernel@collabora.com \
    --cc=krisman@collabora.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=yuchao0@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.