lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1489839338.9183.68.camel@users.sourceforge.net>
Date:   Sat, 18 Mar 2017 13:15:38 +0100
From:   Paul Menzel <paulepanter@...rs.sourceforge.net>
To:     Andy Whitcroft <apw@...onical.com>, Joe Perches <joe@...ches.com>
Cc:     linux-kernel@...r.kernel.org, coreboot@...eboot.org
Subject: checkpatch: Question regarding asmlinkage and storage class

Dear checkpatch developers,


The coreboot project started using checkpatch.pl, and now some effort
is going into fixing issues pointed out by `checkpatch.pl`.

The file `src/arch/x86/acpi_s3.c` in coreboot contains the code below.

```
   205	void (*acpi_do_wakeup)(uintptr_t vector, u32 backup_source, u32 backup_target,
   206		u32 backup_size) asmlinkage = (void *)WAKEUP_BASE;
```

The warning is

> WARNING: storage class should be at the beginning of the declaration

which raised the question below [2].

> And I am waiting for someone to answer why checkpatch.pl claims
> asmlinkage as a storage-class in the first place.

In coreboot the macro is defined similarly to Linux.

```
#define asmlinkage __attribute__((regparm(0)))
#define alwaysinline inline __attribute__((always_inline))
```

In Linux, commit 9c0ca6f9 (update checkpatch.pl to version 0.10) seems
to have introduced the check. The commit message contains “asmlinkage
is also a storage type”.

Furthermore, `checkpatch.pl` doesn’t seem to warn about the code below.

```
void __attribute__((weak)) mainboard_suspend_resume(void)
```

This raises the question below.

> It appears coreboot proper mostly followed this placement for
> function attributes before. It would be nice if we were consistent,
> specially if checkpatch starts to complaint about these.

Is there another reason, besides not having that implemented?

I am looking forward to your answers.


Kind regards,

Paul


[1] https://review.coreboot.org/#/c/18865/1/src/arch/x86/acpi_s3.c@205
[2] https://review.coreboot.org/18865/
[3] https://review.coreboot.org/#/c/18865/1/src/arch/x86/acpi_s3.c@244
Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ