All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulrich Hecht <uli@fpond.eu>
To: Pavel Machek <pavel@denx.de>, cip-dev@lists.cip-project.org
Subject: Re: 4.4-rt nilfs problem
Date: Thu, 12 Dec 2024 04:06:08 +0100 (CET)	[thread overview]
Message-ID: <83580734.2136174.1733972768709@webmail.strato.de> (raw)
In-Reply-To: <Z1oKlyKZkSw0Bhq0@duo.ucw.cz>


> On 12/11/2024 10:56 PM CET Pavel Machek <pavel@denx.de> wrote:
> This 4.4-rt release is proving more "fun" then average. Last problem I
> hit is this one:
> 
> https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/8612057735
> 
> fs/nilfs2/dir.c: In function 'nilfs_find_entry':
> 2705
> fs/nilfs2/dir.c:350:31: error: initialization of 'char *' from incompatible pointer type 'struct page *' [-Werror=incompatible-pointer-types]
> 2706
>   350 |                 char *kaddr = nilfs_get_page(dir, n);
> 2707
>       |                               ^~~~~~~~~~~~~~
> 2708
> 
> And I believe it is caused by 3ab089df2d67491785a5bdaab01cfab8eb35dab5
> :
> 
>     nilfs2: propagate directory read errors from nilfs_find_entry()
> 
> @@ -345,25 +347,26 @@ nilfs_find_entry(struct inode *dir, const struct qstr *qstr,
>                 start = 0;
>         n = start;
>         do {
> -               char *kaddr;
> -               page = nilfs_get_page(dir, n);
> -               if (!IS_ERR(page)) {
> -                       kaddr = page_address(page);
> ...
> +               char *kaddr = nilfs_get_page(dir, n);
> 
> Compiler does not like page * assigned into char *, and I don't blame
> him.

It seems this is missing a dependency, namely ea2ac9238d4919bdc6963a2b487a65ccdaa11c78 ("nilfs2: return the mapped address from nilfs_get_page()"), which in turn has more dependencies...

> I could probably hack something up -- like below -- but it raises
> questions such as
> 
> a) "should kaddr by checked for IS_ERR like that"?

AFAICT, no. page_address() returns NULL on error.

> b) "am I comfortable changing code we are not testing"?

Given that that is what this backport does and how well that worked, I guess the answer is no...

When maintaining file systems for 4.4, nilfs2 is the biggest effort by a mile. From what I can tell it's used in only one config (moxa_mxc_defconfig). Is there any way to find out if it is actually used or just happens to be enabled?

CU
Uli


  reply	other threads:[~2024-12-12  3:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-11 21:56 4.4-rt nilfs problem Pavel Machek
2024-12-12  3:06 ` Ulrich Hecht [this message]
2024-12-12 11:53   ` [cip-dev] " Pavel Machek

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=83580734.2136174.1733972768709@webmail.strato.de \
    --to=uli@fpond.eu \
    --cc=cip-dev@lists.cip-project.org \
    --cc=pavel@denx.de \
    /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.