From: Masami Hiramatsu (Google)
Since the kprobe-events selftest shows OK or NG with the reason, the
WARN_ON_ONCE()s for each place are redundant. Let's remove it.
Signed-off-by: Masami Hiramatsu (Google)
---
kernel/trace/trace_kprobe.c | 26 +-
1 file changed, 13
In [1], Dan points out that all of the WARN_ON_ONCE() usage in the
referenced patch should be replaced with lockdep_assert_held, or
lockdep_held_assert_write(). Replace these as appropriate.
Link:
https://lore.kernel.org/r/65f0b5ef41817_aa2229...@dwillia2-mobl3.amr.corp.intel.com.notmuch
[1
Vishal Verma wrote:
> In [1], Dan points out that all of the WARN_ON_ONCE() usage in the
> referenced patch should be replaced with lockdep_assert_held, or
> lockdep_held_assert_write(). Replace these as appropriate.
>
> Link:
> https://lore.kernel.org/r/65f0b5ef41817_aa2229
In [1], Dan points out that all of the WARN_ON_ONCE() usage in the
referenced patch should be replaced with lockdep_assert_held, or
lockdep_held_assert_write(). Replace these as appropriate.
Link:
https://lore.kernel.org/r/65f0b5ef41817_aa2229...@dwillia2-mobl3.amr.corp.intel.com.notmuch
[1
On Thu, 2024-04-04 at 14:23 -0700, Andrew Morton wrote:
> On Tue, 02 Apr 2024 00:24:28 -0600 Vishal Verma
> wrote:
>
> > In [1], Dan points out that all of the WARN_ON_ONCE() usage in the
> > referenced patch should be replaced with lockdep_assert_held(_write)().
&
On Tue, 02 Apr 2024 00:24:28 -0600 Vishal Verma
wrote:
> In [1], Dan points out that all of the WARN_ON_ONCE() usage in the
> referenced patch should be replaced with lockdep_assert_held(_write)().
>
> Replace those, and additionally, replace a couple of other
> WARN_ON_ON
Vishal Verma wrote:
> In [1], Dan points out that all of the WARN_ON_ONCE() usage in the
> referenced patch should be replaced with lockdep_assert_held(_write)().
>
> Replace those, and additionally, replace a couple of other
> WARN_ON_ONCE() introduced in the same patch for
In [1], Dan points out that all of the WARN_ON_ONCE() usage in the
referenced patch should be replaced with lockdep_assert_held(_write)().
Replace those, and additionally, replace a couple of other
WARN_ON_ONCE() introduced in the same patch for actual failure
cases (i.e. when acquiring
Hello,
kernel test robot noticed
"WARNING:at_kernel/trace/trace_seq.c:#trace_seq_printf" on:
commit: 233bcd2427b36992e8918a67a88912f9c3d497af ("[PATCH v3 3/3] tracing:
convert __trace_seq_init to use WARN_ON_ONCE")
url:
https://github.com/intel-lab-lkp/linux/commit
}From: "Steven Rostedt (Google)"
There's a couple of if statements in eventfs_root_lookup() that should
never be true. Instead of removing them, add WARN_ON_ONCE() around them.
One is a tracefs_inode not being for eventfs.
The other is a child being freed but still on the parent'
ti = get_tracefs(dir);
> - if (!(ti->flags & TRACEFS_EVENT_INODE))
> + if (WARN_ON_ONCE!(ti->flags & TRACEFS_EVENT_INODE)))
I added this patch at the end but never tested it :-p
I then did a rebase to move it ahead of patch 6, which was tested.
Will resend this patch.
-- St
From: "Steven Rostedt (Google)"
There's a couple of if statements in eventfs_root_lookup() that should
never be true. Instead of removing them, add WARN_ON_ONCE() around them.
One is a tracefs_inode not being for eventfs.
The other is a child being freed but still on the parent'
ize))
+ if (WARN_ON_ONCE(!s->seq.size))
trace_seq_init(s);
}
--
2.43.0
ize))
+ if (WARN_ON_ONCE(!s->seq.size))
trace_seq_init(s);
}
--
2.43.0
Thomas Gleixner writes:
> On Thu, Mar 18 2021 at 08:58, Vitaly Kuznetsov wrote:
>> Thomas Gleixner writes:
>>> There is a way more useful way to handle this. In such a case the bit is
>>> NOT set in the alloc map. So:
>>>
>>> if (!WARN_
On Thu, Mar 18 2021 at 08:58, Vitaly Kuznetsov wrote:
> Thomas Gleixner writes:
>> There is a way more useful way to handle this. In such a case the bit is
>> NOT set in the alloc map. So:
>>
>> if (!WARN_ON_ONCE(test_and_clear_bit(bit, cm->alloc_map)))
>&
Thomas Gleixner writes:
> On Fri, Feb 19 2021 at 12:31, Vitaly Kuznetsov wrote:
>
>> When irq_matrix_assign()/irq_matrix_free() calls get unsynced, weird
>> effects are possible, e.g. when cm->allocated goes negative CPU hotplug
>> may get blocked. Add WARN_ON_O
On Fri, Feb 19 2021 at 12:31, Vitaly Kuznetsov wrote:
> When irq_matrix_assign()/irq_matrix_free() calls get unsynced, weird
> effects are possible, e.g. when cm->allocated goes negative CPU hotplug
> may get blocked. Add WARN_ON_ONCE() to simplify detecting such situations.
&g
When irq_matrix_assign()/irq_matrix_free() calls get unsynced, weird
effects are possible, e.g. when cm->allocated goes negative CPU hotplug
may get blocked. Add WARN_ON_ONCE() to simplify detecting such situations.
Signed-off-by: Vitaly Kuznetsov
---
kernel/irq/matrix.c | 11 +--
On Wed, 3 Feb 2021 17:50:12 +0800
Yue Hu wrote:
> From: Yue Hu
>
> Since SCHED_WARN_ON() is provided as a wrapper for WARN_ON_ONCE().
Reviewed-by: Steven Rostedt (VMware)
Peter, care to take this?
Also, looks like we can get rid of the #ifdef CONFIG_SCHED_DEBUG in
set
From: Loris Reiff
[ Upstream commit bb8b81e396f7afbe7c50d789e2107512274d2a35 ]
A toctou issue in `__cgroup_bpf_run_filter_getsockopt` can trigger a
WARN_ON_ONCE in a check of `copy_from_user`.
`*optlen` is checked to be non-negative in the individual getsockopt
functions beforehand. Changing
From: Loris Reiff
[ Upstream commit bb8b81e396f7afbe7c50d789e2107512274d2a35 ]
A toctou issue in `__cgroup_bpf_run_filter_getsockopt` can trigger a
WARN_ON_ONCE in a check of `copy_from_user`.
`*optlen` is checked to be non-negative in the individual getsockopt
functions beforehand. Changing
From: Yue Hu
Since SCHED_WARN_ON() is provided as a wrapper for WARN_ON_ONCE().
Signed-off-by: Yue Hu
---
kernel/sched/core.c | 2 +-
kernel/sched/rt.c | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 8c54810..8f1f345
hu, Dec 3, 2020 at 10:10 AM Alexey Kardashevskiy
> >>>> wrote:
> >>>>>
> >>>>> Hi!
> >>>>>
> >>>>> Syzkaller triggered WARN_ON_ONCE at
> >>>>>
> >>>>> https://git.kernel.org/pub
Alexey Kardashevskiy writes:
> On 04/12/2020 12:25, Michael Ellerman wrote:
>> Dmitry Vyukov writes:
>>> On Thu, Dec 3, 2020 at 10:19 AM Dmitry Vyukov wrote:
>>>> On Thu, Dec 3, 2020 at 10:10 AM Alexey Kardashevskiy
>>>> wrote:
>>>>&g
On 04/12/2020 12:25, Michael Ellerman wrote:
Dmitry Vyukov writes:
On Thu, Dec 3, 2020 at 10:19 AM Dmitry Vyukov wrote:
On Thu, Dec 3, 2020 at 10:10 AM Alexey Kardashevskiy wrote:
Hi!
Syzkaller triggered WARN_ON_ONCE at
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds
Dmitry Vyukov writes:
> On Thu, Dec 3, 2020 at 10:19 AM Dmitry Vyukov wrote:
>> On Thu, Dec 3, 2020 at 10:10 AM Alexey Kardashevskiy wrote:
>> >
>> > Hi!
>> >
>> > Syzkaller triggered WARN_ON_ONCE at
>> >
>> > https://git.ker
On Thu, Dec 3, 2020 at 10:19 AM Dmitry Vyukov wrote:
>
> On Thu, Dec 3, 2020 at 10:10 AM Alexey Kardashevskiy wrote:
> >
> > Hi!
> >
> > Syzkaller triggered WARN_ON_ONCE at
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
From: Qian Cai
[ Upstream commit a805c111650cdba6ee880f528abdd03c1af82089 ]
It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
unprivileged users which would taint the kernel, or worse - panic if
panic_on_warn or panic_on_taint is set. Hence, just convert
From: Qian Cai
[ Upstream commit a805c111650cdba6ee880f528abdd03c1af82089 ]
It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
unprivileged users which would taint the kernel, or worse - panic if
panic_on_warn or panic_on_taint is set. Hence, just convert
From: Qian Cai
[ Upstream commit a805c111650cdba6ee880f528abdd03c1af82089 ]
It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
unprivileged users which would taint the kernel, or worse - panic if
panic_on_warn or panic_on_taint is set. Hence, just convert
From: Qian Cai
[ Upstream commit a805c111650cdba6ee880f528abdd03c1af82089 ]
It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
unprivileged users which would taint the kernel, or worse - panic if
panic_on_warn or panic_on_taint is set. Hence, just convert
From: Qian Cai
[ Upstream commit a805c111650cdba6ee880f528abdd03c1af82089 ]
It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
unprivileged users which would taint the kernel, or worse - panic if
panic_on_warn or panic_on_taint is set. Hence, just convert
From: Qian Cai
[ Upstream commit a805c111650cdba6ee880f528abdd03c1af82089 ]
It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
unprivileged users which would taint the kernel, or worse - panic if
panic_on_warn or panic_on_taint is set. Hence, just convert
and the buffer up-to-date flag
is cleared. If that happens mark_buffer_dirty() can end up throwing a
WARN_ON_ONCE.
To Fix this warning, lock buffer when call mark_buffer_dirty in function
__ext4_handle_dirty_metadate.
Signed-off-by: Ye Bin
---
fs/ext4/ext4_jbd2.c | 2 ++
1 file changed, 2 insertions
---
drivers/net/phy/mdio_bus.c | 15 ---
1 file changed, 15 deletions(-)
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -825,9 +825,6 @@ int mdiobus_read_nested(struct mii_bus *
{
int retval;
- if (WARN_ON_ONCE(in_interrupt
On Sun, Sep 27, 2020 at 09:48:59PM +0200, Thomas Gleixner wrote:
> From: Sebastian Andrzej Siewior
>
> in_interrupt() is ill defined and does not provide what the name
> suggests. The usage especially in driver code is deprecated and a tree wide
> effort to clean up and consolidate the (ab)usage
ead_nested(struct mii_bus *
{
int retval;
- if (WARN_ON_ONCE(in_interrupt()))
- return -EINVAL;
-
mutex_lock_nested(>mdio_lock, MDIO_MUTEX_NESTED);
retval = __mdiobus_read(bus, addr, regnum);
mutex_unlock(>mdio_lock);
@@ -850,9 +847,6 @@
Hello sir,
> > I hope the patch will get merged soon.
>
> No need to "hope"; you could split up Matthew's patch yourself, and test and
> send the resulting patches. From the above thread, it looks like the
> networking
> developers want one patch to fix the improper use of GFP_ATOMIC (which is
On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:
> > > > > idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
> > > > > and this happens when syzbot does fuzzing, and that warning is
> > > > > expected, but WARN_ON_ONCE(
> > idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
> > > > and this happens when syzbot does fuzzing, and that warning is
> > > > expected, but WARN_ON_ONCE() is not required here and, cecking
> > > > the condition and returning NULL v
On Tue, Sep 15, 2020 at 12:17:55AM +0530, Anmol Karn wrote:
> On Mon, Sep 14, 2020 at 12:08:03PM +0100, Matthew Wilcox wrote:
> > On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:
> > > idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
> &
On Mon, Sep 14, 2020 at 12:08:03PM +0100, Matthew Wilcox wrote:
> On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:
> > idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
> > and this happens when syzbot does fuzzing, and that warning is
> > ex
On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:
> idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
> and this happens when syzbot does fuzzing, and that warning is
> expected, but WARN_ON_ONCE() is not required here and, cecking
> the condition and
idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
and this happens when syzbot does fuzzing, and that warning is
expected, but WARN_ON_ONCE() is not required here and, cecking
the condition and returning NULL value would be suffice.
Reference: commit b9959c7a347 ("fi
On Mon, Aug 31, 2020 at 02:23:53PM -0400, Qian Cai wrote:
> It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
> unprivileged users which would taint the kernel, or worse - panic if
> panic_on_warn or panic_on_taint is set. Hence, just convert it to
> pr_warn_ratelimi
On Mon, Aug 31, 2020 at 02:23:53PM -0400, Qian Cai wrote:
> It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
> unprivileged users which would taint the kernel, or worse - panic if
> panic_on_warn or panic_on_taint is set. Hence, just convert it to
> pr_warn_ratelimi
It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
unprivileged users which would taint the kernel, or worse - panic if
panic_on_warn or panic_on_taint is set. Hence, just convert it to
pr_warn_ratelimited() to let users know their workloads are racing.
Thank Dave Chinner
On Mon, Aug 31, 2020 at 06:42:19PM +0100, Matthew Wilcox wrote:
> On Mon, Aug 31, 2020 at 01:25:34PM -0400, Qian Cai wrote:
> > + case IOMAP_DELALLOC:
> > + /*
> > +* DIO is not serialised against mmap() access at all, and so
> > +* if the page_mkwrite occurs
On Mon, Aug 31, 2020 at 01:25:34PM -0400, Qian Cai wrote:
> + case IOMAP_DELALLOC:
> + /*
> + * DIO is not serialised against mmap() access at all, and so
> + * if the page_mkwrite occurs between the writeback and the
> + * iomap_apply() call
On Mon, Aug 31, 2020 at 01:25:34PM -0400, Qian Cai wrote:
> It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
> unprivileged users which would taint the kernel, or worse - panic if
> panic_on_warn or panic_on_taint is set. Hence, just convert it to
> pr_warn_ratelimi
It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
unprivileged users which would taint the kernel, or worse - panic if
panic_on_warn or panic_on_taint is set. Hence, just convert it to
pr_warn_ratelimited() to let users know their workloads are racing.
Thank Dave Chinner
On 8/31/20 10:56 AM, Darrick J. Wong wrote:
> On Mon, Aug 31, 2020 at 10:48:59AM -0500, Eric Sandeen wrote:
>> On 8/30/20 8:45 PM, Qian Cai wrote:
>>> It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
>>> unprivileged users which would taint t
On Mon, Aug 31, 2020 at 10:48:59AM -0500, Eric Sandeen wrote:
> On 8/30/20 8:45 PM, Qian Cai wrote:
> > It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
> > unprivileged users which would taint the kernel, or worse - panic if
> > panic_on_warn or panic_o
On Mon, Aug 31, 2020 at 10:48:59AM -0500, Eric Sandeen wrote:
> On 8/30/20 8:45 PM, Qian Cai wrote:
> > It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
> > unprivileged users which would taint the kernel, or worse - panic if
> > panic_on_warn or panic_o
On 8/30/20 8:45 PM, Qian Cai wrote:
> It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
> unprivileged users which would taint the kernel, or worse - panic if
> panic_on_warn or panic_on_taint is set. Hence, just convert it to
> pr_warn_ratelimited() to le
It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
unprivileged users which would taint the kernel, or worse - panic if
panic_on_warn or panic_on_taint is set. Hence, just convert it to
pr_warn_ratelimited() to let users know their workloads are racing.
Thanks Dave Chinner
On Sun, Aug 30, 2020 at 05:30:33PM -0700, Darrick J. Wong wrote:
> On Sat, Aug 29, 2020 at 09:30:57PM -0400, Qian Cai wrote:
> > It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
> > unprivileged users which would taint the kernel, or worse - panic if
&g
On Sat, Aug 29, 2020 at 09:30:57PM -0400, Qian Cai wrote:
> It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
> unprivileged users which would taint the kernel, or worse - panic if
> panic_on_warn or panic_on_taint is set. Hence, just convert it to
> pr_warn_ratelimi
It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by
unprivileged users which would taint the kernel, or worse - panic if
panic_on_warn or panic_on_taint is set. Hence, just convert it to
pr_warn_ratelimited() to let users know their workloads are racing.
Thanks Dave Chinner
On Thu, Aug 13, 2020 at 03:52:13AM -0400, Qian Cai wrote:
> > No sane application would ever do this, it's behaviour as expected,
> > so I don't think there's anything to care about here.
>
> It looks me the kernel warning is trivial to trigger by an non-root user.
> Shouldn???t we worry a bit
if (!ret) {
drain_all_pages(zone);
- } else {
- WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE);
-
- if ((isol_flags & REPORT_FAILURE) && unmovable)
- /*
-* printk() with zone->lock held will likely trigger a
-
> On Aug 13, 2020, at 1:44 AM, Dave Chinner wrote:
>
> Ok:
>
> file.fd_write = safe_open("./testfile", O_RDWR|O_CREAT);
>
> file.fd_read = safe_open("./testfile", O_RDWR|O_CREAT|O_DIRECT);
>
> file.ptr = safe_mmap(NULL, fsize, PROT_READ|PROT_WRITE, MAP_SHARED,
>
t; > > *srcmap)
> > > > > 374 {
> > > > > 375 struct iomap_dio *dio = data;
> > > > > 376
> > > > > 377 switch (iomap->type) {
> > > > > 378 case IOMAP_HOLE:
> > > >
> > > > 372 iomap_dio_actor(struct inode *inode, loff_t pos, loff_t length,
> > > > 373 void *data, struct iomap *iomap, struct iomap
> > > > *srcmap)
> > > > 374 {
> > > > 375 struct iomap_dio *dio = data;
> > > >
if (!ret) {
drain_all_pages(zone);
- } else {
- WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE);
-
- if ((isol_flags & REPORT_FAILURE) && unmovable)
- /*
-* printk() with zone->lock held will likely trigger a
-
if (!ret) {
drain_all_pages(zone);
- } else {
- WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE);
-
- if ((isol_flags & REPORT_FAILURE) && unmovable)
- /*
-* printk() with zone->lock held will likely trigger a
-
if (!ret) {
drain_all_pages(zone);
- } else {
- WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE);
-
- if ((isol_flags & REPORT_FAILURE) && unmovable)
- /*
-* printk() with zone->lock held will likely trigger a
-
olation.c
> >> @@ -58,16 +58,12 @@ static int set_migratetype_isolate(struct page *page,
> >> int migratetype, int isol_
> >>spin_unlock_irqrestore(>lock, flags);
> >>if (!ret) {
> >>drain_all_pages(zone);
> >> - } else {
ion.c
>> index 553b49a34cf71..02a01bff6b219 100644
>> --- a/mm/page_isolation.c
>> +++ b/mm/page_isolation.c
>> @@ -58,16 +58,12 @@ static int set_migratetype_isolate(struct page *page,
>> int migratetype, int isol_
>> spin_unlock_irqrestore(>lock, f
16 +58,12 @@ static int set_migratetype_isolate(struct page *page, int
> migratetype, int isol_
> spin_unlock_irqrestore(>lock, flags);
> if (!ret) {
> drain_all_pages(zone);
> - } else {
> - WARN_O
> > > > 372 iomap_dio_actor(struct inode *inode, loff_t pos, loff_t length,
> > > > 373 void *data, struct iomap *iomap, struct iomap
> > > > *srcmap)
> > > > 374 {
> > > > 375 struct iomap_dio *dio = data;
> > > >
void *data, struct iomap *iomap, struct iomap *srcmap)
> > > 374 {
> > > 375 struct iomap_dio *dio = data;
> > > 376
> > > 377 switch (iomap->type) {
> > > 378 case IOMAP_HOLE:
> > > 379 if (WARN_ON_ONCE(dio
dio *dio = data;
> > 376
> > 377 switch (iomap->type) {
> > 378 case IOMAP_HOLE:
> > 379 if (WARN_ON_ONCE(dio->flags & IOMAP_DIO_WRITE))
> > 380 return -EIO;
> > 381 return iomap_d
219 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -58,16 +58,12 @@ static int set_migratetype_isolate(struct page *page, int
migratetype, int isol_
spin_unlock_irqrestore(>lock, flags);
if (!ret) {
drain_all_pages(zone);
- } else {
-
dio *dio = data;
> > 376
> > 377 switch (iomap->type) {
> > 378 case IOMAP_HOLE:
> > 379 if (WARN_ON_ONCE(dio->flags & IOMAP_DIO_WRITE))
> > 380 return -EIO;
> > 381 return iomap_d
actor(struct inode *inode, loff_t pos, loff_t length,
> 373 void *data, struct iomap *iomap, struct iomap *srcmap)
> 374 {
> 375 struct iomap_dio *dio = data;
> 376
> 377 switch (iomap->type) {
> 378 case IOMAP_HOLE:
> 379
ase IOMAP_HOLE:
379 if (WARN_ON_ONCE(dio->flags & IOMAP_DIO_WRITE))
380 return -EIO;
381 return iomap_dio_hole_actor(length, dio);
382 case IOMAP_UNWRITTEN:
383 if (!(dio->flags & IOMAP_DIO_WRITE))
384
this bit off, the end result will be that we will get intercepts for
all function codes. Usually the first one will be a query like PQAP(QCI).
So the WARN_ON_ONCE is not right. Let us simply remove it.
Cc: Pierre Morel
Cc: Tony Krowiak
Cc: sta...@vger.kernel.org # v5.3+
Fixes: e5282de93105 ("
this bit off, the end result will be that we will get intercepts for
all function codes. Usually the first one will be a query like PQAP(QCI).
So the WARN_ON_ONCE is not right. Let us simply remove it.
Cc: Pierre Morel
Cc: Tony Krowiak
Cc: sta...@vger.kernel.org # v5.3+
Fixes: e5282de93105 ("
Daniel,
> Commit 88263208dd23 ("scsi: qla2xxx: Complain if sp->done() is not
> called from the completion path") introduced the WARN_ON_ONCE in
> qla2x00_status_cont_entry(). The assumption was that there is only one
> status continuations element. According to t
Hi,
> Should the following be added?
>
> Fixes: 88263208dd23 ("scsi: qla2xxx: Complain if sp->done() is not
> called from the completion path")
Good point. Just send out and updated version
> Anyway:
>
> Reviewed-by: Bart Van Assche
Thanks!
Daniel
Commit 88263208dd23 ("scsi: qla2xxx: Complain if sp->done() is not
called from the completion path") introduced the WARN_ON_ONCE in
qla2x00_status_cont_entry(). The assumption was that there is only one
status continuations element. According to the firmware documentation
i
On 2019-09-26 00:46, Daniel Wagner wrote:
> Commit 88263208dd23 ("scsi: qla2xxx: Complain if sp->done() is not
> called from the completion path") introduced the WARN_ON_ONCE in
> qla2x00_status_cont_entry(). The assumption was that there is only one
> status continu
On 9/26/19 9:46 AM, Daniel Wagner wrote:
> Commit 88263208dd23 ("scsi: qla2xxx: Complain if sp->done() is not
> called from the completion path") introduced the WARN_ON_ONCE in
> qla2x00_status_cont_entry(). The assumption was that there is only one
> status continu
On Wed, Sep 25, 2019 at 06:33:35PM -0700, Bart Van Assche wrote:
> On 2019-09-25 05:39, Daniel Wagner wrote:
> > So I after starring on the code I am not sure if the WARN_ON_ONCE is
> > correct. It assumes that after processing one status continuation,
> > there is no more
Commit 88263208dd23 ("scsi: qla2xxx: Complain if sp->done() is not
called from the completion path") introduced the WARN_ON_ONCE in
qla2x00_status_cont_entry(). The assumption was that there is only one
status continuations element. According to the firmware documentation
i
On 2019-09-25 05:39, Daniel Wagner wrote:
> So I after starring on the code I am not sure if the WARN_ON_ONCE is
> correct. It assumes that after processing one status continuation,
> there is no more work. Though it looks like there is another element
> to process. Is it possible th
Hi,
While testing an update of the qla2xxx driver (10.01.00.19-k) in our
downstream kernel, I noticed that the WARN_ON_ONCE in
qla2x00_status_cont_entry() is triggered. It was introduced by
88263208dd23 ("scsi: qla2xxx: Complain if sp->done() is not called
from the completion path")
On Fri, Aug 30, 2019 at 10:41:10AM +0900, Austin Kim wrote:
> If the CONFIG_BUG is enabled, BUG is executed and then system is crashed.
> However, the bailout for mount is no longer proceeding.
>
> Using WARN_ON_ONCE rather than BUG can prevent this situation.
>
> Signed-
If the CONFIG_BUG is enabled, BUG is executed and then system is crashed.
However, the bailout for mount is no longer proceeding.
Using WARN_ON_ONCE rather than BUG can prevent this situation.
Signed-off-by: Austin Kim
---
fs/xfs/xfs_mount.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
2019년 8월 30일 (금) 오전 9:33, Darrick J. Wong 님이 작성:
>
> On Fri, Aug 30, 2019 at 09:30:22AM +0900, Austin Kim wrote:
> > If the CONFIG_BUG is enabled, BUG is executed and then system is crashed.
> > However, the bailout for mount is no longer proceeding.
> >
> > For t
On Fri, Aug 30, 2019 at 09:30:22AM +0900, Austin Kim wrote:
> If the CONFIG_BUG is enabled, BUG is executed and then system is crashed.
> However, the bailout for mount is no longer proceeding.
>
> For this reason, using WARN_ON_ONCE rather than BUG can prevent this
> situation.
If the CONFIG_BUG is enabled, BUG is executed and then system is crashed.
However, the bailout for mount is no longer proceeding.
For this reason, using WARN_ON_ONCE rather than BUG can prevent this situation.
Signed-off-by: Austin Kim
---
fs/xfs/xfs_mount.c | 3 +--
1 file changed, 1
is a bug.
+*/
+ if (WARN_ON_ONCE(index != 0))
+ return -EINVAL;
+
/* all calls to cpuid_count() should be made on the same cpu */
get_cpu();
@@ -480,38 +488,31 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2
*entry, u32 function
From: Sai Praneeth Prakhya
Calling WARN_ON_ONCE() from atomic bit ops xxx_bit() throws a build error
as shown below.
HOSTLD scripts/mod/modpost
CC kernel/bounds.s
CALLscripts/atomic/check-atomics.sh
In file included from ./include/linux/bitops.h:19:0,
from
Peter Zijlstra writes:
> On Wed, Apr 10, 2019 at 03:51:24PM +0200, Thomas-Mich Richter wrote:
>> Thanks for the fix with commit id 86071b11317550d994b55ce5e31aa06bcad783b5.
>>
>> However doing an fgrep on the pending_disable member of struct perf_event
>> reveals two more hits in file
On Wed, Apr 10, 2019 at 03:51:24PM +0200, Thomas-Mich Richter wrote:
> Thanks for the fix with commit id 86071b11317550d994b55ce5e31aa06bcad783b5.
>
> However doing an fgrep on the pending_disable member of struct perf_event
> reveals two more hits in file kernel/events/ringbuffer.c when events
>
On 4/9/19 10:53 AM, Mark Rutland wrote:
> On Mon, Apr 08, 2019 at 11:50:31AM +0200, Peter Zijlstra wrote:
>> On Mon, Apr 08, 2019 at 10:22:29AM +0200, Peter Zijlstra wrote:
>>> On Mon, Apr 08, 2019 at 09:12:28AM +0200, Thomas-Mich Richter wrote:
>>
.
>>
>> Instead encode the CPU number in
On Mon, Apr 08, 2019 at 11:50:31AM +0200, Peter Zijlstra wrote:
> On Mon, Apr 08, 2019 at 10:22:29AM +0200, Peter Zijlstra wrote:
> > On Mon, Apr 08, 2019 at 09:12:28AM +0200, Thomas-Mich Richter wrote:
>
> > > very good news, your fix ran over the weekend without any hit!!!
> > >
> > > Thanks
1 - 100 of 676 matches
Mail list logo
