My first impression was that is somewhat over-engineered. It's like adding "#define sum(a, b) (a + b)" to do 1 + 2.

But I can see some merit of it, however I'd extend it to take pp and fs:

G_LABEL_DIFF(pp, fs, sm) (((pp)->(mediasize) / (fs)->(fs_fsize)) - (fs)->(sm))

Then your code would reduce from:

G_LABEL_DIFF(pp->mediasize / fs->fs_fsize, fs->fs_old_size) -> G_LABEL_DIFF(pp, fs, fs_old_size)

You can also further reduce it by combining it with the comparison, i.e.:

G_LABEL_CMP(pp, fs, sm) ((((pp)->(mediasize) / (fs)->(fs_fsize)) - (fs)->(sm)) < G_LABEL_MAX_DIFF), then the whole comparison becomes:

if (fs->fs_magic == FS_UFS1_MAGIC && fs->fs_fsize > 0 && (G_LABEL_CMP(pp, fs, fs_old_size) || (G_LABEL_CMP(pp, fs, fs_providersize))

Not strictly required, but it's good practice to put names of "variables" in the cpp macro into (), otherwise say you have a macro like this:

#define mul(a, b) (a * b)

Then you can use it in your code in a way as you would any function, i.e. mul(2, 10 + 1) and expect it to evaluate to "22" (i.e. 2 * 11). However it would expand into 2 * 10 + 1 and hence evaluate to "21". Would work properly if you do it:

#define mul(a, b) ((a) * (b))

This is especially easy to screw if you accept pointers as "arguments", where you may need to do pointer arithmetic when calling macro, i.e. MACRO(p + i, x, y), would evaluate into "p + i->foobar" unless you have () around (p).