From: Rasmus Villemoes
> Sent: 12 June 2023 12:08
>
> On 10/06/2023 22.40, Demi Marie Obenour wrote:
> > Passing spaces before e.g. an integer is usually
> > not intended.
>
> Maybe, maybe not. But it's mandated by POSIX/C99.
>
> And of course we are free to ignore that and implement our own
From: Demi Marie Obenour
> Sent: 10 June 2023 21:41
>
> Passing spaces before e.g. an integer is usually
> not intended. This was suggested by Christoph in
> https://lore.kernel.org/lkml/ziqrohcizoj4b...@infradead.org/.
This is contrary to libc scanf and could easily affect userspace
writing
From: Andrew Cooper
> Sent: 09 June 2023 00:58
>
...
> The important point is the l suffix on btsl, which forces it to be long
> (32bit) irrespective of the default operand size.
Does that matter at all?
The 'bit' opcodes (I'm sure 'bts' is 'bit test and set') take
a bit offset from the base
From: Johannes Berg
> Sent: 05 May 2022 21:13
> On Thu, 2022-05-05 at 13:08 -0700, Keith Packard wrote:
>
>
> > I bet you've already considered the simpler form:
> >
> > struct something *instance = mem_to_flex_dup(byte_array, count,
> > GFP_KERNEL);
> > if (IS_ERR(instance))
>
From: Kees Cook
> Sent: 04 May 2022 16:38
...
> > > struct something *instance = NULL;
> > > int rc;
> > >
> > > rc = mem_to_flex_dup(, byte_array, count, GFP_KERNEL);
> > > if (rc)
> > > return rc;
> >
> > This seems rather awkward, having to set it to NULL, then checking
From: Juergen Gross
> Sent: 18 March 2022 16:56
>
> On 18.03.22 16:22, David Laight wrote:
> > From: Juergen Gross
> >> Sent: 18 March 2022 15:10
> >>
> >> The dcdbas driver is used to call SMI handlers for both, dcdbas and
> >> dell-smbios-sm
From: Juergen Gross
> Sent: 18 March 2022 15:10
>
> The dcdbas driver is used to call SMI handlers for both, dcdbas and
> dell-smbios-smm. Both drivers allocate a buffer for communicating
> with the SMI handler. The physical buffer address is then passed to
> the called SMI handler via %ebx.
>
>
From: Chen Huang
> Sent: 26 May 2021 10:20
>
> The simple_strtoull() function is deprecated in some situation, since
> it does not check for the range overflow, use kstrtoull() instead.
>
...
> - target_bytes = simple_strtoull(buf, , 0) * 1024;
> + ret = kstrtoull(buf, 0, _bytes);
> +
From: Thomas Gleixner
> Sent: 11 December 2020 21:11
>
> On Fri, Dec 11 2020 at 14:19, David Laight wrote:
> > From: Thomas Gleixner
> >> You can't catch that. If this really becomes an issue you need a
> >> sequence counter around it.
> >
> > Or j
From: Thomas Gleixner
> Sent: 11 December 2020 12:58
..
> > After my failed hasty sketch from last night I had a different one which
> > was kind of heuristics based (re-reading the upper dword and retrying if
> > it changed on 32-bit).
>
> The problem is that there will be two seperate
From: Arvind Sankar
> Sent: 29 October 2020 21:35
>
> On Thu, Oct 29, 2020 at 09:41:13PM +0100, Thomas Gleixner wrote:
> > On Thu, Oct 29 2020 at 17:59, Paolo Bonzini wrote:
> > > On 29/10/20 17:56, Arvind Sankar wrote:
> > >>> For those two just add:
> > >>> struct apic *apic =
From: Arnd Bergmann
> Sent: 29 October 2020 09:51
...
> I think ideally there would be no global variable, withall accesses
> encapsulated in function calls, possibly using static_call() optimizations
> if any of them are performance critical.
There isn't really a massive difference between
From: Arnd Bergmann
> Sent: 28 October 2020 21:21
>
> From: Arnd Bergmann
>
> There are hundreds of warnings in a W=2 build about a local
> variable shadowing the global 'apic' definition:
>
> arch/x86/kvm/lapic.h:149:65: warning: declaration of 'apic' shadows a global
> declaration
From: Boris Ostrovsky
> Sent: 30 April 2018 17:24
> To: linux-ker...@vger.kernel.org; xen-devel@lists.xenproject.org
> Cc: jgr...@suse.com; Boris Ostrovsky; sta...@vger.kernel.org
> Subject: [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant
>
> Latest binutils release (2.29.1) will no
From: Stefano Stabellini
> Sent: 27 February 2018 19:55
>
> We are using test_and_* operations on the status and flag fields of
> struct sock_mapping. However, these functions require the operand to be
> 64-bit aligned on arm64. Currently, only status is 64-bit aligned.
That sounds like a big
From: Arnd Bergmann
> Sent: 09 February 2018 12:58
...
> However, aside from this driver, I wonder if we should be worried about
> Spectre type 1 attacks on similar code, when gcc-8 turns a switch/case
> statement into an array lookup behind our back, e.g. in an ioctl handler.
> Has anybody got
From: Andrew Cooper
> Sent: 05 February 2018 15:14
>
> On 05/02/18 15:03, Arnd Bergmann wrote:
>
> Snipping deleted code to make things clearer:
>
> > + if (cmd > ARRAY_SIZE(physdevop_len))
> > + return -ENOSYS;
> >
> > + len = physdevop_len[cmd];
> > + memcpy(, arg, len);
>
>
From: Arnd Bergmann
> Sent: 05 February 2018 12:37
> > Are the EVTCHNOP_xxx values dense?
> > In which case an array is almost certainly better than the switch statement.
>
> They are, yes. PHYSDEVOP_xxx are also consecutive by start at '4'.
> Dan made the same comment earlier, and I replied
From: Boris Ostrovsky
> Sent: 02 February 2018 23:34
...
> > switch (cmd) {
> > + case EVTCHNOP_bind_interdomain:
> > + len = sizeof(struct evtchn_bind_interdomain);
> > + break;
> > + case EVTCHNOP_bind_virq:
> > + len = sizeof(struct evtchn_bind_virq);
> > +
19 matches
Mail list logo
