On Fri, 26 Jan 2024 at 10:41, Steven Rostedt wrote:
>
> Fine, but I still plan on sending you the update to give all files unique
> inode numbers. If it screws up tar, it could possibly screw up something
> else.
Well, that in many ways just regularizes the code, and the dynamic
inode numbers
On Fri, 26 Jan 2024 11:06:33 -0800
Linus Torvalds wrote:
> On Fri, 26 Jan 2024 at 10:41, Steven Rostedt wrote:
> >
> > Fine, but I still plan on sending you the update to give all files unique
> > inode numbers. If it screws up tar, it could possibly screw up something
> > else.
>
> Well,
Hello trace maintainers/developers,
This is a 31-day syzbot report for the trace subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/trace
During the period, 2 new issues were detected and 0 were fixed.
In total, 8 issues are still open and 29
On Fri, 26 Jan 2024 at 10:18, Steven Rostedt wrote:
>
> By following what sysfs does, and give files a default size of PAGE_SIZE,
> it allows the tar to work. No event file is greater than PAGE_SIZE.
No, please. Just don't.
Nobody has asked for this, and nobody sane should use 'tar' on tracefs
On Fri, 26 Jan 2024 10:31:07 -0800
Linus Torvalds wrote:
> On Fri, 26 Jan 2024 at 10:18, Steven Rostedt wrote:
> >
> > By following what sysfs does, and give files a default size of PAGE_SIZE,
> > it allows the tar to work. No event file is greater than PAGE_SIZE.
>
> No, please. Just don't.
On Fri, Jan 26, 2024 at 07:15:50PM +, Luck, Tony wrote:
> If deployment of a microcode update across a fleet always went
> flawlessly, life would be simpler. But things can fail. And maybe the
> failure wasn't noticed. Perhaps a node was rebooting when the sysadmin
> pushed the update to the
On Fri, 26 Jan 2024 11:10:07 -0800
Beau Belgrave wrote:
> > OK, so the each different event has suffixed name. But this will
> > introduce non C-variable name.
> >
> > Steve, do you think your library can handle these symbols? It will
> > be something like "event:[1]" as the event name.
> >
On Fri, 26 Jan 2024 15:24:17 -0500
Mathieu Desnoyers wrote:
> On 2024-01-26 15:12, Steven Rostedt wrote:
> [...]
> > diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
> > index e1b172c0e091..2187be6d7b23 100644
> > --- a/fs/tracefs/inode.c
> > +++ b/fs/tracefs/inode.c
> > @@ -223,13 +223,41
On Fri, Jan 26, 2024 at 05:10:20PM +, Luck, Tony wrote:
> 12 extra bytes divided by (say) 64GB (a very small server these days, may
> laptop has that much)
>= 0.0001746%
>
> We will need 57000 changes like this one before we get to 0.001% :-)
You're forgetting that those 12 bytes
> But no, that's not the right question to ask.
>
> It is rather: which bits of information are very relevant to an error
> record and which are transient enough so that they cannot be gathered
> from a system by other means or only gathered in a difficult way, and
> should be part of that record.
On Sat, Jan 27, 2024 at 12:01:04AM +0900, Masami Hiramatsu wrote:
> On Tue, 23 Jan 2024 22:08:42 +
> Beau Belgrave wrote:
>
> > Add a register_name (reg_name) to the user_event struct which allows for
> > split naming of events. We now have the name that was used to register
> > within
On Fri, Jan 26, 2024 at 08:49:03PM +, Luck, Tony wrote:
> Every patch that adds new code or data structures adds to the kernel
> memory footprint. Each should be considered on its merits. The basic
> question being:
>
>"Is the new functionality worth the cost?"
>
> Where does it end? It
Hi,
This commit introduced in v5.13 prevents building FS_DAX on 32-bit ARM,
even on ARMv7 which does not have virtually aliased dcaches:
commit d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
It used to work fine before: I have customers using dax over pmem on
On 2024-01-26 15:12, Steven Rostedt wrote:
[...]
diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index e1b172c0e091..2187be6d7b23 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -223,13 +223,41 @@ static const struct inode_operations
tracefs_file_inode_operations = {
> > Is it so very different to add this to a trace record so that rasdaemon
> > can have feature parity with mcelog(8)?
>
> I knew you were gonna say that. When someone decides that it is
> a splendid idea to add more stuff to struct mce then said someone would
> want it in the tracepoint too.
>
>
On Wed, Jan 24, 2024 at 12:03:47PM -0800, Vishal Verma wrote:
> There were several places where drivers/dax/bus.c uses 'sprintf' to
> print sysfs data. Since a sysfs_emit() helper is available specifically
> for this purpose, replace all the sprintf() usage for sysfs with
> sysfs_emit() in this
On Wed, Jan 24, 2024 at 12:03:50PM -0800, Vishal Verma wrote:
> Add a sysfs knob for dax devices to control the memmap_on_memory setting
> if the dax device were to be hotplugged as system memory.
>
> The default memmap_on_memory setting for dax devices originating via
> pmem or hmem is set to
On Fri, Jan 26, 2024 at 05:12:12PM +0100, Ulf Hansson wrote:
> On Fri, 5 Jan 2024 at 17:01, Ulf Hansson wrote:
> >
> > Updates in v2:
> > - Ccing Daniel Baluta and Iuliana Prodan the NXP remoteproc patches
> > to
> > requests help with testing.
> > - Fixed NULL pointer
On Thu, Jan 25, 2024 at 8:43 AM Alexandru Elisei
wrote:
>
> arm64 uses VM_HIGH_ARCH_0 and VM_HIGH_ARCH_1 for enabling MTE for a VMA.
> When VM_HIGH_ARCH_0, which arm64 renames to VM_MTE, is set for a VMA, and
> the gfp flag __GFP_ZERO is present, the __GFP_ZEROTAGS gfp flag also gets
> set in
From: "Steven Rostedt (Google)"
Linus suggested to use the same inode numbers to make it easier to
implement getdents(), as it was creating inodes just for generating a
unique and consistent inode number. Linus suggested to just use the same
inode for all files and directories.
Later it was
> > You've spent enough time with Ashok and Thomas tweaking the Linux
> > microcode driver to know that going back to the machine the next day
> > to ask about microcode version has a bunch of ways to get a wrong
> > answer.
>
> Huh, what does that have to do with this?
If deployment of a
On Fri, Jan 26, 2024, at 20:33, Mathieu Desnoyers wrote:
>
> A) I have prepared a patch series introducing cache_is_aliasing() with
> new Kconfig
> options:
>
>* ARCH_HAS_CACHE_ALIASING
>* ARCH_HAS_CACHE_ALIASING_DYNAMIC
>
> and implemented it for all architectures. The "DYNAMIC"
On Wed, Jan 24, 2024 at 12:03:46PM -0800, Vishal Verma wrote:
> The dax driver incorrectly used driver-core device locks to protect
> internal dax region and dax device configuration structures. Replace the
> device lock usage with a local rwsem, one each for dax region
> configuration and dax
On Sat, 27 Jan 2024 00:14:05 +0900
Masami Hiramatsu (Google) wrote:
> On Thu, 25 Jan 2024 15:54:53 +0100
> Jiri Olsa wrote:
>
> > On Fri, Jan 12, 2024 at 07:10:50PM +0900, Masami Hiramatsu (Google) wrote:
> > > Hi,
> > >
> > > Here is the 6th version of the series to re-implement the fprobe
Both INTs (INT n, INT1, INT3, INTO) and UDs (UD0, UD1, UD2) serve
special purposes in the kernel, e.g., INT3 is used by KGDB and UD2 is
involved in LLVM-KCFI instrumentation. At the same time, attaching
kprobes on these instructions (particularly UDs) will pollute the stack
trace dumped in the
Hi everyone,
This patch set makes the following 2 changes:
- It adds an exception opcode detector to prevent kprobing on INTs and UDs.
These opcodes serves special purposes in the kernel and kprobing them
will also cause the stack trace to be polluted by the copy buffer
address. This is
With the instruction decoder, we are now able to decode and recognize
instructions with opcode extensions. There are more instructions in
these groups that can be boosted:
Group 2: ROL, ROR, RCL, RCR, SHL/SAL, SHR, SAR
Group 3: TEST, NOT, NEG, MUL, IMUL, DIV, IDIV
Group 4: INC, DEC (byte
On Thu Jan 25, 2024 at 5:30 PM CET, Konrad Dybcio wrote:
>
>
> On 1/24/24 16:31, Luca Weiss wrote:
> > Add the definitions for the various thermal zones found on the SM6350
> > SoC. Hooking up GPU and CPU cooling can limit the clock speeds there to
> > reduce the temperature again to good levels.
Currently, the microcode field (Microcode Revision) of struct mce is not
exported to userspace through the mce_record tracepoint.
Export it through the tracepoint as it may provide useful information for
debug and analysis.
Signed-off-by: Avadhut Naik
Reviewed-by: Sohil Mehta
---
On 25/01/2024 17:42, Alexandru Elisei wrote:
> Allow the kernel to get the base address, size, block size and associated
> memory node for tag storage from the device tree blob.
>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that
On 18/01/2024 11:04, Arnaud Pouliquen wrote:
> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
> where the Cortex-M4 firmware is loaded by the Trusted execution Environment
> (TEE).
> For instance, this compatible is used in both the Linux and OP-TEE
> device-tree:
> - In
On Thu, Jan 25, 2024 at 07:19:22PM +, Luck, Tony wrote:
> 8 bytes for PPIN, 4 more for microcode.
I know, nothing leads to bloat like 0.01% here, 0.001% there...
> Number of recoverable machine checks per system I hope the
> monthly rate should be countable on my fingers...
That's not
Machine Check Error information from struct mce is exported to userspace
through the mce_record tracepoint.
Currently, however, the PPIN (Protected Processor Inventory Number) field
of struct mce is not exported through the tracepoint.
Export PPIN through the tracepoint as it may provide useful
This patchset updates the mce_record tracepoint so that the recently added
fields of struct mce are exported through it to userspace.
The first patch adds PPIN (Protected Processor Inventory Number) field to
the tracepoint.
The second patch adds the microcode field (Microcode Revision) to the
Hi Mathieu,
On 1/25/24 19:55, Mathieu Poirier wrote:
> Hi Arnaud,
>
> On Thu, Jan 18, 2024 at 11:04:30AM +0100, Arnaud Pouliquen wrote:
>> From: Arnaud Pouliquen
>>
>> Add a remoteproc TEE (Trusted Execution Environment) device
>
> Device or driver? Seems to be the latter...
Right, driver is
>
> Signed-off-by: Haitao Huang
> Reported-by: Mikko Ylinen
> ---
Non-technical staff:
I believe checkpatch requires you to have a "Closes" tag after "Reported-by"
otherwise it complains something like this:
WARNING: Reported-by: should be immediately followed by Closes: with a URL
to
Hello Krzysztof,
On 1/26/24 12:03, Krzysztof Kozlowski wrote:
> On 18/01/2024 11:04, Arnaud Pouliquen wrote:
>> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
>> where the Cortex-M4 firmware is loaded by the Trusted execution Environment
>> (TEE).
>> For instance, this
On Fri, 26 Jan 2024 08:37:25 -0600, Huang, Kai wrote:
Signed-off-by: Haitao Huang
Reported-by: Mikko Ylinen
---
Non-technical staff:
I believe checkpatch requires you to have a "Closes" tag after
"Reported-by"
otherwise it complains something like this:
WARNING: Reported-by:
On Fri, 26 Jan 2024 09:42:58 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> Fix register_snapshot_trigger() to return error code if it failed to
> allocate a snapshot instead of 0 (success). Unless that, it will register
> snapshot trigger without an error.
>
>
Hi Krzysztof,
On Fri, Jan 26, 2024 at 09:50:58AM +0100, Krzysztof Kozlowski wrote:
> On 25/01/2024 17:42, Alexandru Elisei wrote:
> > Allow the kernel to get the base address, size, block size and associated
> > memory node for tag storage from the device tree blob.
> >
>
> Please use
> > 8 bytes for PPIN, 4 more for microcode.
>
> I know, nothing leads to bloat like 0.01% here, 0.001% there...
12 extra bytes divided by (say) 64GB (a very small server these days, may
laptop has that much)
= 0.0001746%
We will need 57000 changes like this one before we get to 0.001%
On Tue, 23 Jan 2024 22:08:42 +
Beau Belgrave wrote:
> Add a register_name (reg_name) to the user_event struct which allows for
> split naming of events. We now have the name that was used to register
> within user_events as well as the unique name for the tracepoint. Upon
> registering
On Thu, 25 Jan 2024 15:54:53 +0100
Jiri Olsa wrote:
> On Fri, Jan 12, 2024 at 07:10:50PM +0900, Masami Hiramatsu (Google) wrote:
> > Hi,
> >
> > Here is the 6th version of the series to re-implement the fprobe on
> > function-graph tracer. The previous version is;
> >
> >
On Thu, 25 Jan 2024 16:11:51 +0100
Jiri Olsa wrote:
> On Fri, Jan 12, 2024 at 07:17:06PM +0900, Masami Hiramatsu (Google) wrote:
>
> SNIP
>
> > * Register @fp to ftrace for enabling the probe on the address given by
> > @addrs.
> > @@ -298,23 +547,27 @@ EXPORT_SYMBOL_GPL(register_fprobe);
>
On Fri, Jan 26, 2024 at 02:39:33PM +0100, Arnaud POULIQUEN wrote:
> Hi Mathieu,
>
> On 1/25/24 19:55, Mathieu Poirier wrote:
> > Hi Arnaud,
> >
> > On Thu, Jan 18, 2024 at 11:04:30AM +0100, Arnaud Pouliquen wrote:
> >> From: Arnaud Pouliquen
> >>
> >> Add a remoteproc TEE (Trusted Execution
On Fri, 5 Jan 2024 at 17:01, Ulf Hansson wrote:
>
> Updates in v2:
> - Ccing Daniel Baluta and Iuliana Prodan the NXP remoteproc patches to
> requests help with testing.
> - Fixed NULL pointer bug in patch1, pointed out by Nikunj.
> - Added some tested/reviewed-by
On Thu, Jan 18, 2024 at 11:04:33AM +0100, Arnaud Pouliquen wrote:
> The new TEE remoteproc device is used to manage remote firmware in a
> secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
> introduced to delegate the loading of the firmware to the trusted
> execution context. In
On Wed, Jan 03, 2024 at 02:11:24PM -0800, Tanmay Shah wrote:
> From: Mathieu Poirier
>
> Multi-cluster remoteproc designs typically have the following DT
> declaration:
>
> remoteproc_cluster {
> compatible = "soc,remoteproc-cluster";
>
> core0: core0 {
>
On Wed, Jan 03, 2024 at 02:11:25PM -0800, Tanmay Shah wrote:
> This patch enhances rproc_put() to support remoteproc clusters
> with multiple child nodes as in rproc_get_by_phandle().
>
> Signed-off-by: Tarak Reddy
> Signed-off-by: Tanmay Shah
As described in the first patch, this documents
On Thu, Jan 18, 2024 at 11:04:30AM +0100, Arnaud Pouliquen wrote:
> From: Arnaud Pouliquen
>
> Add a remoteproc TEE (Trusted Execution Environment) device
> that will be probed by the TEE bus. If the associated Trusted
> application is supported on secure part this device offers a client
>
From: "Steven Rostedt (Google)"
The sqlhist utility[1] (or the new trace-cmd sqlhist command[2]) creates
the commands of a synthetic event based on the files in the tracefs/events
directory. When creating these commands for an embedded system, it is
asked to copy the files to the temp directory,
51 matches
Mail list logo
