On Thu, 29 Feb 2024, Kees Cook wrote:
> The __is_constexpr() macro is dark magic. Shed some light on it with
> a comment to explain how and why it works.
Hey, it was a fun little puzzle to figure out using the C standard. Now
you're ruining it for everyone! ;)
The description matches my recollec
On Thu, Feb 22, 2024 at 12:07:10PM -0800, mhkelle...@gmail.com wrote:
> From: Michael Kelley
>
> Add documentation topic for PCI pass-thru devices in Linux guests
> on Hyper-V and for the associated PCI controller driver (pci-hyperv.c).
>
> Signed-off-by: Michael Kelley
> Reviewed-by: Easwar Ha
From: Kees Cook
> Sent: 01 March 2024 04:45
> To: Rasmus Villemoes
>
> The __is_constexpr() macro is dark magic. Shed some light on it with
> a comment to explain how and why it works.
All the 8s don't help...
I don't think you need that much explanation.
Perhaps just saying that the type of ?
Currently ftrace only dumps the global trace buffer on an OOPs. For
debugging a production usecase, instance trace will be helpful to
check specific problems since global trace buffer may be used for
other purposes.
This patch extend the ftrace_dump_on_oops parameter to dump a specific
or multiple
BTW my main email addess is now: uec...@tugraz.at
My suggestion would also to limit explanation. Nobody should
write such code and if you need to, you can find explanations
all over the internet.
Finally, I still think the motivation for this macro (removing
VLAs) is misguided if security is the
From: Uecker, Martin
> Sent: 01 March 2024 13:22
>
> My suggestion would also to limit explanation. Nobody should
> write such code and if you need to, you can find explanations
> all over the internet.
>
> Finally, I still think the motivation for this macro (removing
> VLAs) is misguided if sec
Dear Jonathan,
I wanted to clean up the development-process documentation. There is
however no easy way to break the ice here:
The elephant in the room is that there is some unclear relation between
5.Posting.rst, 6.Followthrough.rst and submitting-patches.rst.
(Yes, I know each document has its
Submitting-patches is already assuming that git is used to prepare
patches. So, developers will use git format-patch and git send-email, and
this will take care that PATCH is usually in the subject line. Hence, the
'include PATCH in the subject' does not deserve be an own section.
Move this note i
The top-level structure should basically be along the temporal order of
things: Prepare a patch, Post a patch, Respond to review, Send reworked
patches, Be patient before resending.
Start bringing submitting-patches into this clear temporal flow.
Move 'Separate your changes' before 'Describe your
The top-level structure should basically be along the temporal order of
things: Prepare a patch, Post a patch, Respond to review, Send reworked
patches, Be patient before resending.
For that, content from the canonical patch format needs to dissolve into
the pieces along the temporal order.
Move
Am Freitag, dem 01.03.2024 um 13:43 + schrieb David Laight:
> From: Uecker, Martin
> > Sent: 01 March 2024 13:22
> >
> > My suggestion would also to limit explanation. Nobody should
> > write such code and if you need to, you can find explanations
> > all over the internet.
> >
> > Finally, I
On Fri, Mar 01, 2024 at 11:34:42PM +0200, Adrian Ratiu wrote:
> Prior to v2.6.39 write access to /proc//mem was restricted,
> after which it got allowed in commit 198214a7ee50 ("proc: enable
> writing to /proc/pid/mem"). Famous last words from that patch:
> "no longer a security hazard". :)
>
> Af
Thu, Feb 29, 2024 at 08:44:37PM -0800, Kees Cook kirjoitti:
> The __is_constexpr() macro is dark magic. Shed some light on it with
> a comment to explain how and why it works.
I was under impression that somebody did it already once and it fell through
cracks when has been moved (?) to compiler.h.
On Sat, Mar 02, 2024 at 03:17:32AM +0200, Andy Shevchenko wrote:
> Thu, Feb 29, 2024 at 08:44:37PM -0800, Kees Cook kirjoitti:
> > The __is_constexpr() macro is dark magic. Shed some light on it with
> > a comment to explain how and why it works.
>
> I was under impression that somebody did it alr
On LoongArch system, there is hypercall instruction special for
virtualization. When system executes this instruction on host side,
there is illegal instruction exception reported, however it will
trap into host when it is executed in VM mode.
When hypercall is emulated, A0 register is set with va
Physical cpuid is used for interrupt routing for irqchips such as
ipi/msi/extioi interrupt controller. And physical cpuid is stored
at CSR register LOONGARCH_CSR_CPUID, it can not be changed once vcpu
is created and physical cpuid of two vcpus cannot be the same.
Different irqchips have different
Instruction cpucfg can be used to get processor features. And there
is trap exception when it is executed in VM mode, and also it is
to provide cpu features to VM. On real hardware cpucfg area 0 - 20
is used. Here one specified area 0x4000 -- 0x40ff is used
for KVM hypervisor to privide PV
On physical machine, ipi HW uses IOCSR registers, however there is trap
into hypervisor when vcpu accesses IOCSR registers if system is in VM
mode. SWI is a interrupt mechanism like SGI on ARM, software can send
interrupt to CPU, only that on LoongArch SWI can only be sent to local CPU
now. So SWI
It is code refine about ipi handling on LoongArch platform, there are
three modifications.
1. Add generic function get_percpu_irq(), replacing some percpu irq
functions such as get_ipi_irq()/get_pmc_irq()/get_timer_irq() with
get_percpu_irq().
2. Change definition about parameter action called by
On LoongArch system, ipi hw uses iocsr registers, there is one iocsr
register access on ipi sending, and two iocsr access on ipi receiving
which is ipi interrupt handler. On VM mode all iocsr accessing will
cause VM to trap into hypervisor. So with one ipi hw notification
there will be three times
20 matches
Mail list logo
