On 29. 05. 24, 23:42, Nathan Chancellor wrote:
drivers/nvme/target/fc.c:151:2: error: 'counted_by' should not be applied to
an array with element of unknown size because 'struct nvmet_fc_fcp_iod' is a
struct type with a flexible array member.
The same as for mxser_port:
struct nvmet_fc_fc
On 29. 05. 24, 23:29, Nathan Chancellor wrote:
Work for __counted_by on generic pointers in structures (not just
flexible array members) has started landing in Clang 19 (current tip of
tree). During the development of this feature, a restriction was added
to __counted_by to prevent the flexible a
On 29/05/2024 3:20 am, Gatlin Newhouse wrote:
> diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
> index a3ec87d198ac..e3fbed9073f8 100644
> --- a/arch/x86/include/asm/bug.h
> +++ b/arch/x86/include/asm/bug.h
> @@ -13,6 +13,14 @@
> #define INSN_UD2 0x0b0f
> #define LEN_UD2
On Wed, May 29, 2024 at 01:36:39PM -0700, Gatlin Newhouse wrote:
> On Wed, May 29, 2024 at 08:30:20PM UTC, Marco Elver wrote:
> > On Wed, 29 May 2024 at 20:17, Gatlin Newhouse
> > wrote:
> > >
> > > On Wed, May 29, 2024 at 09:25:21AM UTC, Marco Elver wrote:
> > > > On Wed, 29 May 2024 at 04:20, G
ref;
/* array of fcp_iods */
- struct nvmet_fc_fcp_iod fod[] __counted_by(sqsize);
+ struct nvmet_fc_fcp_iod fod[] /* __counted_by(sqsize) */;
} __aligned(sizeof(unsigned long long));
struct nvmet_fc_hostport {
---
base-commit: c758b77d4a0a0ed3a129
s[] /* __counted_by(nports) */;
};
static DECLARE_BITMAP(mxser_boards, MXSER_BOARDS);
---
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
change-id: 20240529-drop-counted-by-ports-mxser-board-ed2a66f1a6e2
Best regards,
--
Nathan Chancellor
On Wed, May 29, 2024 at 08:30:20PM UTC, Marco Elver wrote:
> On Wed, 29 May 2024 at 20:17, Gatlin Newhouse
> wrote:
> >
> > On Wed, May 29, 2024 at 09:25:21AM UTC, Marco Elver wrote:
> > > On Wed, 29 May 2024 at 04:20, Gatlin Newhouse
> > > wrote:
> > > [...]
> > > > if (regs->flags & X
On Wed, 29 May 2024 at 20:17, Gatlin Newhouse wrote:
>
> On Wed, May 29, 2024 at 09:25:21AM UTC, Marco Elver wrote:
> > On Wed, 29 May 2024 at 04:20, Gatlin Newhouse
> > wrote:
> > [...]
> > > if (regs->flags & X86_EFLAGS_IF)
> > > raw_local_irq_enable();
> > > - if
On Wed, May 29, 2024 at 09:25:21AM UTC, Marco Elver wrote:
> On Wed, 29 May 2024 at 04:20, Gatlin Newhouse
> wrote:
> [...]
> > if (regs->flags & X86_EFLAGS_IF)
> > raw_local_irq_enable();
> > - if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN ||
> > -
E_BOOTUP
---
base-commit: e0cce98fe279b64f4a7d81b7f5c3a23d80b92fbc
change-id: 20240529-fortify_panic-325601efe71d
On Wed, May 29, 2024 at 10:09:45AM -0700, Jeff Johnson wrote:
> On 5/29/2024 9:55 AM, Kees Cook wrote:
> > On Wed, May 29, 2024 at 07:36:25AM -0700, Jeff Johnson wrote:
> >> 'make W=1 C=1' on x86 gives the warning:
> >> arch/x86/boot/compressed/misc.c:535:6: warning: symbol '__fortify_panic'
> >>
On 5/29/2024 9:55 AM, Kees Cook wrote:
> On Wed, May 29, 2024 at 07:36:25AM -0700, Jeff Johnson wrote:
>> 'make W=1 C=1' on x86 gives the warning:
>> arch/x86/boot/compressed/misc.c:535:6: warning: symbol '__fortify_panic' was
>> not declared. Should it be static?
>
> Hm, I can't reproduce this c
On Wed, May 29, 2024 at 07:36:25AM -0700, Jeff Johnson wrote:
> 'make W=1 C=1' on x86 gives the warning:
> arch/x86/boot/compressed/misc.c:535:6: warning: symbol '__fortify_panic' was
> not declared. Should it be static?
Hm, I can't reproduce this currently (but yes, it looks like arm vs x86
is m
On Fri, 2024-05-17 at 10:54 -0400, Kenton Groombridge wrote:
> req->n_channels must be set before req->channels[] can be used.
>
I don't know why, but this patch breaks a number of hwsim test cases.
https://w1.fi/cgit/hostap/tree/tests/hwsim/
johannes
'make W=1 C=1' on x86 gives the warning:
arch/x86/boot/compressed/misc.c:535:6: warning: symbol '__fortify_panic' was
not declared. Should it be static?
Looking at this I see for ARM there is a prototype for __fortify_panic() in
arch/arm/boot/compressed/misc.h
And there is a matching implementati
On Mon, May 27 2024 at 10:26, Miroslav Lichvar wrote:
> On Fri, May 24, 2024 at 02:44:19PM +0200, Thomas Gleixner wrote:
>> On Fri, May 24 2024 at 14:09, Thomas Gleixner wrote:
>> > So instead of turning the clock back, we might be better off to actually
>> > put the normalization in place at the a
On 2024/5/29 15:45, Thomas Gleixner wrote:
[这封邮件来自外部发件人 谨防风险]
On Wed, May 29 2024 at 14:44, Tony W Wang-oc wrote:
Actually, this scenario is what this patch is trying to solve.
We encountered hpet_lock deadlock from the call path of the MCE handler,
and this hpet_lock deadlock scenario ma
On Wed, May 29 2024 at 14:44, Tony W Wang-oc wrote:
> Actually, this scenario is what this patch is trying to solve.
>
> We encountered hpet_lock deadlock from the call path of the MCE handler,
> and this hpet_lock deadlock scenario may happen when others exceptions'
> handler like #PF/#GP... to ca
On Wed, May 29 2024 at 12:39, Tony W Wang-oc wrote:
> printk deadlock will happened at #A because in_nmi() evaluates to false
> on CPU B and CPU B do not enter the panic() AT #A.
>
> Update user space MCE handler to NMI class context is preferred?
No.
Linus!
On Tue, May 28 2024 at 16:22, Linus Torvalds wrote:
> On Tue, 28 May 2024 at 15:12, Thomas Gleixner wrote:
> I see the smiley, but yeah, I don't think we really care about it.
Indeed. But the same problem exists on other architectures as
well. drivers/clocksource alone has 4 examples asid
On Wed, 29 May 2024 at 04:20, Gatlin Newhouse wrote:
[...]
> if (regs->flags & X86_EFLAGS_IF)
> raw_local_irq_enable();
> - if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN ||
> - handle_cfi_failure(regs) == BUG_TRAP_TYPE_WARN) {
> - regs->
21 matches
Mail list logo
