All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: cocci@inria.fr
Subject: [cocci] Need some help with spatch
Date: Fri, 5 Nov 2021 17:12:09 +0100	[thread overview]
Message-ID: <17a7a40f-b736-e0ea-02ae-1b03ef4483bf@suse.cz> (raw)

Hi all,

I'm working on a patchset originally by Matthew Wilcox that replaces "struct
page" with "struct slab" in slab allocators [1].
Because a lot of the changes there are mechanistic, I thought it would be a
good idea to perform them via coccinelle semantic patch. But it's my first
attempt at large real usage of spatch, and it probably shows.

Overal I have managed to do what I wanted, but encountered some issues that
required workarounds so I will list them here and would welcome any help. I
assume most are from my inexperience and it's possible to adjust the
semantic patches so the workarounds are not needed.

The current development snapshot of the series is at [2], git clone url [3]
branch slab-struct_slab-v1r8

There are 3 semantic patches used in the series. For easier development, the
respective commits add a .cocci file in addition to applying it (when
finalized, the .cocci content would be moved to changelog as usual):

184d9494c1a4 ("mm/slub: mass conversion of struct page to struct slab by
spatch") adds slub.cocci

ccd7da3f3888 ("mm/slab: mass conversion of struct page to struct slab by
spatch") adds slab.cocci

0c60a4fcc1b2 ("mm: spatch conversion of struct page to struct slab for
subsystems interacting with slab") adds slab_shared.cocci

So here are the issues I encountered:

1) patching complex variable declarations;

I need to perform changes such as:
-struct page *page;
+struct slab *slab;

This I was able to somehow specify in the .cocci, but not for situations
where the original declarations looks like this:

struct page *page, *page2;

or

struct page *page = NULL;

Therefore, for 2 of the 3 semantic patches I have a "prerequisite" commits
that change those declarations to split multiple variables or initial assinment:
f15698e1c920 ("mm/slub: prepare for struct patch conversion by spatch")
8a685ebb3b2a ("mm/slab: prepare for struct patch conversion by spatch")

It would be nice to eliminate those, if possible, but I don't know how
to adjust the respective .cocci for that.

2) for the SLUB cocci patch, some places where the semantic patch should
change something are "missed" even though other similar places are not

It can be seen in this commit that fixes them up:

d12d641854a8 ("mm/slub: fix up places that spatch missed")

for example the cocci patch is supposed to change all "page" to "slab", but
some lines are patched like this:

-       __free_slab(page->slab_cache, page);
+       __free_slab(page->slab_cache, slab);

so it missed the first 'page' and commit d12d641854a8 has to fix that up. I
don't know why. It seems it's mainly places where two different changes
would be applicable to a single line? Maybe the .cocci rules should be
written differently to handle this?

3) eliminated whitespace including newlines

This is stylistic but will require some postprocessing fixups if not solved.
There seem to be several cases like this where whitespace including newlines
is eliminated between two lines that are patched by the spatch:

-       struct page *page;
-
-       page = container_of(h, struct page, rcu_head);
+       struct slab *slab;slab = container_of(h, struct page, rcu_head);

4) unnecessary indentation changes for multiline function declarations or calls

This is the least critical, but maybe there's a way to preserve original
indentation and not do reindenting like this?

-static inline bool cmpxchg_double_slab(struct kmem_cache *s, struct page *page,
-               void *freelist_old, unsigned long counters_old,
-               void *freelist_new, unsigned long counters_new,
-               const char *n)
+static inline bool cmpxchg_double_slab(struct kmem_cache *s,
+                                      struct slab *slab,
+                                      void *freelist_old,
+                                      unsigned long counters_old,
+                                      void *freelist_new,
+                                      unsigned long counters_new,
+                                      const char *n)

Thanks in advance for any hints!

[1] https://lwn.net/Articles/871982/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slab-struct_slab-v1r8
[3] git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git

             reply	other threads:[~2021-11-05 16:12 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-05 16:12 Vlastimil Babka [this message]
2021-11-05 16:20 ` [cocci] Need some help with spatch Luis Chamberlain
2021-11-06  6:44   ` Julia Lawall
2021-11-07 23:08   ` Vlastimil Babka
2021-11-08 14:35     ` Vlastimil Babka
2021-11-08 14:45       ` Julia Lawall
2021-11-08 16:53         ` Vlastimil Babka
2021-11-08 17:01           ` Julia Lawall
2021-11-05 20:56 ` Julia Lawall
2021-11-05 21:13 ` Julia Lawall
2021-11-05 21:24   ` Vlastimil Babka
2021-11-05 21:27     ` Julia Lawall
2021-11-05 21:31 ` Julia Lawall
2021-11-05 21:32   ` Vlastimil Babka
2021-11-05 21:43 ` Julia Lawall
2021-11-05 21:59 ` Julia Lawall
2021-11-06 15:36 ` [cocci] mm/slab: mass conversion of struct page to struct slab by spatch Markus Elfring
2021-11-07 12:10 ` [cocci] mm/slab: prepare for struct patch conversion " Markus Elfring
2021-11-07 12:22   ` Julia Lawall
2021-11-07 12:50     ` [cocci] mm/slab: prepare for struct page " Markus Elfring
2021-11-07 13:18       ` Julia Lawall
2021-11-07 13:40         ` Markus Elfring
2021-11-07 17:50       ` Vlastimil Babka
2021-11-07 18:09         ` Julia Lawall
2021-11-08 17:35           ` Markus Elfring
2021-11-08 17:40             ` Julia Lawall
2021-11-08 23:35             ` Vlastimil Babka

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=17a7a40f-b736-e0ea-02ae-1b03ef4483bf@suse.cz \
    --to=vbabka@suse.cz \
    --cc=cocci@inria.fr \
    /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.