syzbot has bisected this issue to:
commit 6b0b708f12d18f9cccfb1c418bea59fcbff8798c
Author: Takashi Sakamoto
Date: Wed May 1 07:32:38 2024 +
firewire: core: add tracepoint event for handling bus reset
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14969a1698
start
11 @@ bool mce_gen_pool_empty(void)
return llist_empty(_event_llist);
}
-int mce_gen_pool_add(struct mce *mce)
+int mce_gen_pool_add(struct mce_hw_err *err)
{
struct mce_evt_llist *node;
- if (filter_mce(mce))
+ if (filter_mce(>m))
return -EINV
Expose memory scan/reclaim information to the host side via virtio
balloon device.
Now we have a metric to analyze the memory performance:
y: counter increases
n: counter does not changes
h: the rate of counter change is high
l: the rate of counter change is low
OOM: VIRTIO_BALLOON_S_OOM_KILL
Expose memory scan/reclaim information to the host side via virtio
balloon device.
Now we have a metric to analyze the memory performance:
y: counter increases
n: counter does not changes
h: the rate of counter change is high
l: the rate of counter change is low
OOM: VIRTIO_BALLOON_S_OOM_KILL
On Fri, 5 Apr 2024 00:07:06 +
"Ho-Ren (Jack) Chuang" wrote:
> The current implementation treats emulated memory devices, such as
> CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
> (E820_TYPE_RAM). However, these emulated devices have different
> characteristics
On 18.04.24 08:26, zhenwei pi wrote:
Expose memory scan/reclaim information to the host side via virtio
balloon device.
Now we have a metric to analyze the memory performance:
y: counter increases
n: counter does not changes
h: the rate of counter change is high
l: the rate of counter change
Expose memory scan/reclaim information to the host side via virtio
balloon device.
Now we have a metric to analyze the memory performance:
y: counter increases
n: counter does not changes
h: the rate of counter change is high
l: the rate of counter change is low
OOM: VIRTIO_BALLOON_S_OOM_KILL
to
> > > > > > handle cases where memtype is not initialized and where HMAT
> > > > > > information is
> > > > > > available.
> > > > > >
> > > > > > * Introduce `default_memory_types` for those memory
On 15.04.24 10:41, zhenwei pi wrote:
Expose memory scan/reclaim information to the host side via virtio
balloon device.
Now we have a metric to analyze the memory performance:
y: counter increases
n: counter does not changes
h: the rate of counter change is high
l: the rate of counter change
Expose memory scan/reclaim information to the host side via virtio
balloon device.
Now we have a metric to analyze the memory performance:
y: counter increases
n: counter does not changes
h: the rate of counter change is high
l: the rate of counter change is low
OOM: VIRTIO_BALLOON_S_OOM_KILL
t; information is
> > > > > available.
> > > > >
> > > > > * Introduce `default_memory_types` for those memory types that are not
> > > > > initialized by device drivers.
> > > > > Because late initialized memory and de
managed,
> >> > a default memory type is created for storing all memory types that are
> >> > not initialized by device drivers and as a fallback.
> >> >
> >> > Signed-off-by: Ho-Ren (Jack) Chuang
> >> > Signed-off-by: Hao Xiang
>
a fallback.
>> >
>> > Signed-off-by: Ho-Ren (Jack) Chuang
>> > Signed-off-by: Hao Xiang
>> > Reviewed-by: "Huang, Ying"
>>
>> Hi - one remaining question. Why can't we delay init for all nodes
>> to either drivers or your fallback late
y device drivers.
> > > > Because late initialized memory and default DRAM memory need to be
> > > > managed,
> > > > a default memory type is created for storing all memory types that are
> > > > not initialized by device drivers and as a fallback
-by: "Huang, Ying"
> >
> > Hi - one remaining question. Why can't we delay init for all nodes
> > to either drivers or your fallback late_initcall code.
> > It would be nice to reduce possible code paths.
>
> I try not to change too much
all nodes
> to either drivers or your fallback late_initcall code.
> It would be nice to reduce possible code paths.
I try not to change too much of the existing code structure in
this patchset.
To me, postponing/moving all memory tier registrations to
late_initcall() is another possible action it
On Fri, 5 Apr 2024 00:07:06 +
"Ho-Ren (Jack) Chuang" wrote:
> The current implementation treats emulated memory devices, such as
> CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
> (E820_TYPE_RAM). However, these emulated devices have different
> characteristics
@@ static struct demotion_nodes *node_demotion __read_mostly;
static BLOCKING_NOTIFIER_HEAD(mt_adistance_algorithms);
+/* The lock is used to protect `default_dram_perf*` info and nid. */
+static DEFINE_MUTEX(default_dram_perf_lock);
static bool default_dram_perf_error;
static struct access_
Hi Jonathan,
Thank you! I will fix them and send a V11 soon.
On Thu, Apr 4, 2024 at 6:37 AM Jonathan Cameron
wrote:
>
>
>
> > > > @@ -858,7 +910,8 @@ static int __init memory_tier_init(void)
> > > >* For now we can have 4 faster memory tiers with smaller
> > > > adistance
> > > >
> > > @@ -858,7 +910,8 @@ static int __init memory_tier_init(void)
> > >* For now we can have 4 faster memory tiers with smaller adistance
> > >* than default DRAM tier.
> > >*/
> > > - default_dram_type = alloc_memory_type(MEMTIER_ADISTANCE_DRAM);
> > > +
_memory_type_map node_memory_types[MAX_NUMNODES];
> > struct memory_dev_type *default_dram_type;
> >
> > @@ -108,6 +113,8 @@ static struct demotion_nodes *node_demotion
> > __read_mostly;
> >
> > static BLOCKING_NOTIFIER_HEAD(mt_adistance_algorithms);
> >
> >
t_dram_type;
>
> @@ -108,6 +113,8 @@ static struct demotion_nodes *node_demotion __read_mostly;
>
> static BLOCKING_NOTIFIER_HEAD(mt_adistance_algorithms);
>
> +/* The lock is used to protect `default_dram_perf*` info and nid. */
> +static DEFINE_MUTEX(default_dram_perf_lock);
&
ck is used to protect `default_dram_perf*` info and nid. */
+static DEFINE_MUTEX(default_dram_perf_lock);
static bool default_dram_perf_error;
static struct access_coordinate default_dram_perf;
static int default_dram_perf_ref_nid = NUMA_NO_NODE;
@@ -505,7 +512,8 @@ static inline void __init_node_m
@@ static struct demotion_nodes *node_demotion __read_mostly;
static BLOCKING_NOTIFIER_HEAD(mt_adistance_algorithms);
+/* The lock is used to protect `default_dram_perf*` info and nid. */
+static DEFINE_MUTEX(default_dram_perf_lock);
static bool default_dram_perf_error;
static struct access_
> >
> > static DEFINE_MUTEX(memory_tier_lock);
> > static LIST_HEAD(memory_tiers);
> > +/*
> > + * The list is used to store all memory types that are not created
> > + * by a device driver.
> > + */
> > +static LIST_HEAD(default_memory_types);
> >
emory_dev_type *default_dram_type;
>
> @@ -108,6 +113,8 @@ static struct demotion_nodes *node_demotion __read_mostly;
>
> static BLOCKING_NOTIFIER_HEAD(mt_adistance_algorithms);
>
> +/* The lock is used to protect `default_dram_perf*` info and nid. */
> +stati
@@ static struct demotion_nodes *node_demotion __read_mostly;
static BLOCKING_NOTIFIER_HEAD(mt_adistance_algorithms);
+/* The lock is used to protect `default_dram_perf*` info and nid. */
+static DEFINE_MUTEX(default_dram_perf_lock);
static bool default_dram_perf_error;
static struct access_
On Wed, Mar 27, 2024 at 6:37 PM Huang, Ying wrote:
>
> "Ho-Ren (Jack) Chuang" writes:
>
> [snip]
>
> > @@ -655,6 +672,34 @@ void mt_put_memory_types(struct list_head
> > *memory_types)
> > }
> > EXPORT_SYMBOL_GPL(mt_put_memory_types);
> >
> > +/*
> > + * This is invoked via `late_initcall()`
"Ho-Ren (Jack) Chuang" writes:
[snip]
> @@ -655,6 +672,34 @@ void mt_put_memory_types(struct list_head *memory_types)
> }
> EXPORT_SYMBOL_GPL(mt_put_memory_types);
>
> +/*
> + * This is invoked via `late_initcall()` to initialize memory tiers for
> + * CPU-less memory nodes after driver
*node_demotion __read_mostly;
static BLOCKING_NOTIFIER_HEAD(mt_adistance_algorithms);
+/* The lock is used to protect `default_dram_perf*` info and nid. */
+static DEFINE_MUTEX(default_dram_perf_lock);
static bool default_dram_perf_error;
static struct access_coordinate default_dram_perf;
static
ic DEFINE_MUTEX(memory_tier_lock);
> > static LIST_HEAD(memory_tiers);
> > +/*
> > + * The list is used to store all memory types that are not created
> > + * by a device driver.
> > + */
> > +static LIST_HEAD(default_memory_types);
> > static struct node_m
LIST_HEAD(memory_tiers);
> +/*
> + * The list is used to store all memory types that are not created
> + * by a device driver.
> + */
> +static LIST_HEAD(default_memory_types);
> static struct node_memory_type_map node_memory_types[MAX_NUMNODES];
> struct memory_dev_type *default_dram_typ
;
static BLOCKING_NOTIFIER_HEAD(mt_adistance_algorithms);
+/* The lock is used to protect `default_dram_perf*` info and nid. */
+static DEFINE_MUTEX(default_dram_perf_lock);
static bool default_dram_perf_error;
static struct access_coordinate default_dram_perf;
static int
.c
> >> > +++ b/mm/memory-tiers.c
> >> > @@ -36,6 +36,11 @@ struct node_memory_type_map {
> >> >
> >> > static DEFINE_MUTEX(memory_tier_lock);
> >> > static LIST_HEAD(memory_tiers);
> >> > +/*
> >> > + * The list i
tatic LIST_HEAD(memory_tiers);
>> > +/*
>> > + * The list is used to store all memory types that are not created
>> > + * by a device driver.
>> > + */
>> > +static LIST_HEAD(default_memory_types);
>> > static struct node_memory_type_map node_memory_typ
_types[MAX_NUMNODES];
> > struct memory_dev_type *default_dram_type;
> >
> > @@ -108,6 +113,7 @@ static struct demotion_nodes *node_demotion
> > __read_mostly;
> >
> > static BLOCKING_NOTIFIER_HEAD(mt_adistance_algorithms);
> >
> > +static DEFINE_MUTEX(default_
"Ho-Ren (Jack) Chuang" writes:
> The current implementation treats emulated memory devices, such as
> CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
> (E820_TYPE_RAM). However, these emulated devices have different
> characteristics than traditional DRAM, making it
The current implementation treats emulated memory devices, such as
CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
(E820_TYPE_RAM). However, these emulated devices have different
characteristics than traditional DRAM, making it important to
distinguish them. Thus, we
ll
> back.\n");
> }
> }
>
Sounds good! I will do.
> > + __init_node_memory_type(node, mtype);
> >
> > memtype = node_memory_types[node].memtype;
> > node_set(node, memtype->nodes);
> > @@ -623,6 +641,55 @@ void
t
> memory_dev_type *memtype)
> }
> EXPORT_SYMBOL_GPL(clear_node_memory_type);
>
> +struct memory_dev_type *mt_find_alloc_memory_type(int adist, struct
> list_head *memory_types)
> +{
> + bool found = false;
> + struct memory_dev_type *mtype;
> +
> + list_for
)
+ list_add(>list, memory_types);
+ }
+
+ return mtype;
+}
+EXPORT_SYMBOL_GPL(mt_find_alloc_memory_type);
+
+/*
+ * This is invoked via late_initcall() to create
+ * CPUless memory tiers after HMAT info is ready or
+ * when there is no HMAT.
+ */
+static int __init
the reason why you mention to exclude
> > "node_memory_types[nid].memtype != NULL" in memory_tier_late_init().
> > Is my understanding correct?
>
> Yes.
>
Thanks.
> >> > static DEFINE_MUTEX(target_lock);
> >> >
> >> &g
?
Yes.
>> > static DEFINE_MUTEX(target_lock);
>> >
>> > /*
>> > @@ -149,6 +151,12 @@ int acpi_get_genport_coordinates(u32 uid,
>> > }
>> > EXPORT_SYMBOL_NS_GPL(acpi_get_genport_coordinates, CXL);
>> >
>> > +struct memory_de
YMBOL_NS_GPL(acpi_get_genport_coordinates, CXL);
> >
> > +struct memory_dev_type *hmat_find_alloc_memory_type(int adist)
> > +{
> > + return find_alloc_memory_type(adist, _memory_types);
> > +}
> > +EXPORT_SYMBOL_GPL(hmat_find_alloc_memory_type);
> >
d alloc_memory_initiator(unsigned int cpu_pxm)
> {
> struct memory_initiator *initiator;
> @@ -1038,6 +1046,9 @@ static __init int hmat_init(void)
> if (!hmat_set_default_dram_perf())
> register_mt_adistance_algorithm(_adist_nb);
>
> + /* Post-create CPUless m
+1046,9 @@ static __init int hmat_init(void)
if (!hmat_set_default_dram_perf())
register_mt_adistance_algorithm(_adist_nb);
+ /* Post-create CPUless memory tiers after getting HMAT info */
+ memory_tier_late_init();
+
return 0;
out_put
On Sat, 03 Feb 2024 14:16:16 +0800 Ubisectech Sirius
> Hello.
> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> Recently, our team has discovered a issue in Linux kernel
> 6.8.0-rc2-g6764c317b6bb.
> Attached to the email were a POC file of the issue.
Could you test
Hello.
We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
Recently, our team has discovered a issue in Linux kernel
6.8.0-rc1-gecb1b8288dc7. Attached to the email were a POC file of the issue.
Stack dump:
rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 1
Hello.
We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
Recently, our team has discovered a issue in Linux kernel
6.8.0-rc2-g6764c317b6bb. Attached to the email were a POC file of the issue.
Stack dump:
rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks
-assets/ac6cb620d377/zImage-610a9b8f.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+fe8f8efd070d727de...@syzkaller.appspotmail.com
INFO: task kworker/0:1:9 blocked for more than 450 seconds.
Not tainted 6.7.0-rc8-syzkaller #0
"echo 0 &g
The new version info format has a superset of symbols in the old format.
Since this is a tool for in-tree modules, we don't need to parse the old
one with this tool any longer.
Signed-off-by: Matthew Maurer
---
scripts/export_report.pl | 22 ++
1 file changed, 10 insertions
The 'bytes' info in file 'per_cpu/cpu/stats' means the number of
bytes in cpu buffer that have not been consumed. However, currently
after consuming data by reading file 'trace_pipe', the 'bytes' info
was not changed as expected.
# cat per_cpu/cpu0/stats
entries: 0
overrun: 0
commit
e between close() and fork()")
INFO: task syz-executor890:6628 blocked for more than 143 seconds.
Not tainted 5.12.0-rc8-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor890 state:D stack:25968 pid: 6628 ppid: 8391 flags:0x000
On Mon, Apr 19, 2021 at 08:56:19PM +, Guido Kiener wrote:
> Hi all,
>
> The error is in usbtmc_interrupt(struct urb *urb) since five years. The
> status code EPROTO is not handled correctly.
> It's not a showstopper, but we should fix it and check the status code
> according to
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an
issue:
KASAN: null-ptr-deref Write in io_uring_cancel_sqpoll
==
BUG: KASAN: null-ptr-deref in instrument_atomic_read_write
zkaller.appspot.com/x/log.txt?x=15b86f9ad0
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+47fc00967b06a3019...@syzkaller.appspotmail.com
> Fixes: d9d05217cb69 ("io_uring: stop SQPOLL submit on creator's death")
>
&g
it.
@Greg: Is it urgent?
- Guido
-Original Message-
From: Dmitry
Sent: Monday, April 19, 2021 9:27 AM
Subject: Re: [syzbot] INFO: rcu detected stall in tx
On Mon, Apr 19, 2021 at 9:19 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:
://syzkaller.appspot.com/x/log.txt?x=15b86f9ad0
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+47fc00967b06a3019...@syzkaller.appspotmail.com
Fixes: d9d05217cb69 ("io_uring: stop SQPOLL submit on creator's death")
INFO: task iou-sqp-8700:8701 blocke
On Mon, 19 Apr 2021 at 12:53, Jes Sorensen wrote:
>
> On 3/23/21 3:36 PM, Pascal Terjan wrote:
> > Based on 2001:3319 and 2357:0109 which I used to test the fix and
> > 0bda:818b and 2357:0108 for which I found efuse dumps online.
> >
> > == 2357:0109 ==
> > === Before ===
> > Vendor: Realtek
> >
From: Chunguang Xu
Many distributions do not install the getdelay tool by
default, similar to task_io_accounting, adding a proc
file to make access easier.
v2: Fix some errors prompted by the kernel test robot.
Signed-off-by: Chunguang Xu
Reported-by: kernel test robot
---
fs/proc/base.c
bool assign_lock_key(struct lockdep_map *lock)
/* Debug-check: all keys must be persistent! */
debug_locks_off();
pr_err("INFO: trying to register non-static key.\n");
- pr_err("the code is fine but needs lockde
bool assign_lock_key(struct lockdep_map *lock)
/* Debug-check: all keys must be persistent! */
debug_locks_off();
pr_err("INFO: trying to register non-static key.\n");
- pr_err("the code is fine but needs lockde
bool assign_lock_key(struct lockdep_map *lock)
/* Debug-check: all keys must be persistent! */
debug_locks_off();
pr_err("INFO: trying to register non-static key.\n");
- pr_err("the code is fine but needs lockde
On 3/23/21 3:36 PM, Pascal Terjan wrote:
> Based on 2001:3319 and 2357:0109 which I used to test the fix and
> 0bda:818b and 2357:0108 for which I found efuse dumps online.
>
> == 2357:0109 ==
> === Before ===
> Vendor: Realtek
> Product: \x03802.11n NI
> Serial:
> === After ===
> Vendor: Realtek
sbtmc 2-1:0.0: unknown status received: -71
[ 370.275974][C1] usbtmc 3-1:0.0: unknown status received: -71
[ 370.282100][C0] usbtmc 6-1:0.0: unknown status received: -71
[ 370.288262][C1] usbtmc 5-1:0.0: unknown status received: -71
[ 370.294399][C0] usbtmc 4-1:0.0: unknown statu
: unknown status received: -71
usbtmc 3-1:0.0: unknown status received: -71
usbtmc 5-1:0.0: unknown status received: -71
rcu: INFO: rcu_preempt self-detected stall on CPU
rcu:1-...!: (8580 ticks this GP) idle=72e/1/0x4000
softirq=20679/20679 fqs=0
(t=10500 jiffies g=27129 q
On Sat, Apr 17, 2021 at 12:41 PM syzbot
wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit 363eaa3a450abb4e63bd6e3ad79d1f7a0f717814
> Author: Shuah Khan
> Date: Tue Mar 30 01:36:51 2021 +
>
> usbip: synchronize event handler with sysfs code paths
>
> bisection log:
Pascal Terjan wrote:
> Based on 2001:3319 and 2357:0109 which I used to test the fix and
> 0bda:818b and 2357:0108 for which I found efuse dumps online.
>
> == 2357:0109 ==
> === Before ===
> Vendor: Realtek
> Product: \x03802.11n NI
> Serial:
> === After ===
> Vendor: Realtek
> Product:
syzbot suspects this issue was fixed by commit:
commit 363eaa3a450abb4e63bd6e3ad79d1f7a0f717814
Author: Shuah Khan
Date: Tue Mar 30 01:36:51 2021 +
usbip: synchronize event handler with sysfs code paths
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16c89e91d0
start
Committer: Borislav Petkov
CommitterDate: Fri, 16 Apr 2021 12:51:41 +02:00
x86/platform/uv: Add more to secondary CPU kdump info
Add call to run_crash_ipi_callback() to gather more info of what the
secondary CPUs were doing to help with failure analysis.
Excerpt from Georges:
'It is only
dashboard link: https://syzkaller.appspot.com/bug?extid=0b2182efb62fe1a7e162
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+0b2182efb62fe1a7e...@syzkaller.appspotmail.com
INFO: trying
Remove the following pci-legacy message:
PCI host bridge /pci@44/host-bridge ranges:
MEM 0x2000..0x2fff
IO 0x0046..0x0046
It is followed shortly by the same data from pci_register_host_bridge:
PCI host bridge to bus :00
pci_bus
Hi brookxu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.12-rc7 next-20210413]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
Our driver while supporting HDR didn't send the proper colorimetry info
in the AVI infoframe.
Let's add the property needed so that the userspace can let us know what
the colorspace is supposed to be.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- New patch
---
drivers/gpu/drm/vc4
Remove the following pci-legacy message:
PCI host bridge /pci@44/host-bridge ranges:
MEM 0x2000..0x2fff
IO 0x0046..0x0046
It is followed shortly by the same data from pci_register_host_bridge:
PCI host bridge to bus :00
pci_bus
Hi brookxu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.12-rc7 next-20210412]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as
From: Chunguang Xu
Many distributions do not install the getdelay tool by
default, similar to task_io_accounting, adding a proc
file to make access easier.
Signed-off-by: Chunguang Xu
---
fs/proc/base.c | 7 +++
kernel/delayacct.c | 41 +
2
35fab8667 100644
--- a/include/linux/fpga/fpga-sec-mgr.h
+++ b/include/linux/fpga/fpga-sec-mgr.h
@@ -40,6 +40,9 @@ enum fpga_sec_err {
* function and is called at the completion
* of the update, whether success or failure,
Committer: Borislav Petkov
CommitterDate: Mon, 12 Apr 2021 19:42:10 +02:00
x86/platform/uv: Add more to secondary CPU kdump info
Add call to run_crash_ipi_callback() to gather more info of what the
secondary CPUs were doing to help with failure analysis.
Excerpt from Georges:
'It is only
bool assign_lock_key(struct lockdep_map *lock)
/* Debug-check: all keys must be persistent! */
debug_locks_off();
pr_err("INFO: trying to register non-static key.\n");
- pr_err("the code is fine but needs lockde
bool assign_lock_key(struct lockdep_map *lock)
/* Debug-check: all keys must be persistent! */
debug_locks_off();
pr_err("INFO: trying to register non-static key.\n");
- pr_err("the code is fine but needs lockde
bool assign_lock_key(struct lockdep_map *lock)
/* Debug-check: all keys must be persistent! */
debug_locks_off();
pr_err("INFO: trying to register non-static key.\n");
- pr_err("the code is fine but needs lockde
bool assign_lock_key(struct lockdep_map *lock)
/* Debug-check: all keys must be persistent! */
debug_locks_off();
pr_err("INFO: trying to register non-static key.\n");
- pr_err("the code is fine but needs lockde
insertions(+), 4 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 5523f069b9a5..f35b0b83fe85 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -908,8 +908,16 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct
net_device *dev,
o tx_error;
} else if (err) {
if (info) {
+ struct ip_tunnel_info *unclone;
struct in_addr src, dst;
+ unclone = skb_tunnel_info_unclone(skb);
+ if
insertions(+), 4 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 1426bfc009bc..abd37f26af68 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -907,8 +907,16 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct
net_device *dev,
o tx_error;
} else if (err) {
if (info) {
+ struct ip_tunnel_info *unclone;
struct in_addr src, dst;
+ unclone = skb_tunnel_info_unclone(skb);
+ if
Fill fw version info into smem to be printed as part of
soc info.
Signed-off-by: Dikshita Agarwal
Reviewed-by: Stephen Boyd
---
drivers/media/platform/Kconfig | 2 +-
drivers/media/platform/qcom/venus/hfi_msgs.c | 20 ++--
2 files changed, 19 insertions(+), 3
Removes old information related to the stop file interface in sysfs left
by mistake during patch revision.
Improves the document text format to be more user-friendly and adds
basic driver related information, such as support, datasheet, and author.
Signed-off-by: Gustavo Pimentel
---
On Wed, Apr 07, 2021 at 10:31:48PM +0200, Gustavo Pimentel wrote:
> Fixes documentation build warnings related to indentation and text
> formatting, such as:
>
> Documentation/misc-devices/dw-xdata-pcie.rst:20: WARNING: Unexpected
> indentation.
> Documentation/misc-devices/dw-xdata-pcie.rst:24:
:
Reported-by: syzbot+f013a12629d1698e2...@syzkaller.appspotmail.com
INFO: task agetty:1550 blocked for more than 143 seconds.
Not tainted 5.12.0-rc5-next-20210401-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:agetty state:D stack:27
Quoting Dikshita Agarwal (2021-04-09 04:46:19)
> Fill fw version info into smem to be printed as part of
> soc info.
>
> Signed-off-by: Dikshita Agarwal
> Reported-by: kernel test robot
>
> change since v3:
> added dependency on QCOM_SMEM (Stephen)
> ---
Reviewed-by: Stephen Boyd
On Fri 09 Apr 06:46 CDT 2021, Dikshita Agarwal wrote:
> Fill fw version info into smem to be printed as part of
> soc info.
>
> Signed-off-by: Dikshita Agarwal
> Reported-by: kernel test robot
Why/how did kernel test robot tell you that you should write the
firmware
Fill fw version info into smem to be printed as part of
soc info.
Signed-off-by: Dikshita Agarwal
Reported-by: kernel test robot
change since v3:
added dependency on QCOM_SMEM (Stephen)
---
drivers/media/platform/Kconfig | 2 +-
drivers/media/platform/qcom/venus/hfi_msgs.c
From: Nina Wu
For new ICs, there are multiple devapc HWs for different subsys.
The number of devices controlled by each devapc (i.e. 'vio_idx_num')
will be set in DT for per devapc node.
On the other hand, for old ICs which have only one devapc HW, the
'vio_idx_num' info is set in compatible
Add a simple-mfd representing IMEM on SDX55 and define the PIL
relocation info region, so that post mortem tools will be able to locate
the loaded remoteproc.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm/boot/dts/qcom-sdx55.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an
issue:
INFO: task hung in io_ring_exit_work
INFO: task kworker/u4:0:9 blocked for more than 143 seconds.
Not tainted 5.12.0-rc2-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs&q
On 08/04/2021 14:57, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer is still triggering
> an issue:
> INFO: task hung in io_ring_exit_work
>
> commit: 07c3d710 Revert "Revert "io_uring: wait potential ->releas..
E
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an
issue:
INFO: task hung in io_ring_exit_work
INFO: task kworker/u4:1:25 blocked for more than 143 seconds.
Not tainted 5.12.0-rc2-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs&q
On 08/04/2021 06:05, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer is still triggering
> an issue:
> INFO: task hung in io_ring_exit_work
Ok, it's really fancy, we add task_work with TWA_SIGNAL to a guaranteed
not exited/exec ta
1 - 100 of 15695 matches
Mail list logo
