From: Tomer Samara <tomersamara98@gmail.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: devel@driverdev.osuosl.org, "Todd Kjos" <tkjos@android.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Riley Andrews" <riandrews@android.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
"Suren Baghdasaryan" <surenb@google.com>,
"Hridya Valsaraju" <hridya@google.com>,
"Arve Hjønnevåg" <arve@android.com>,
"Joel Fernandes" <joel@joelfernandes.org>,
"Laura Abbott" <labbott@redhat.com>,
"Martijn Coenen" <maco@android.com>,
"Christian Brauner" <christian@brauner.io>
Subject: Re: [PATCH v4 2/2] staging: android: Remove BUG from ion_system_heap.c
Date: Sat, 22 Aug 2020 12:34:21 +0300 [thread overview]
Message-ID: <20200822093421.GA6631@tsnow> (raw)
In-Reply-To: <3eba90dc-128f-49da-41a6-81494653d535@infradead.org>
On Fri, Aug 21, 2020 at 09:25:26AM -0700, Randy Dunlap wrote:
> On 8/21/20 8:28 AM, Tomer Samara wrote:
> > Remove BUG() from ion_sytem_heap.c
> >
> > this fix the following checkpatch issue:
> > Avoid crashing the kernel - try using WARN_ON &
> > recovery code ratherthan BUG() or BUG_ON().
> >
> > Signed-off-by: Tomer Samara <tomersamara98@gmail.com>
> > ---
> > drivers/staging/android/ion/ion_system_heap.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
> > index eac0632ab4e8..00d6154aec34 100644
> > --- a/drivers/staging/android/ion/ion_system_heap.c
> > +++ b/drivers/staging/android/ion/ion_system_heap.c
> > @@ -30,7 +30,7 @@ static int order_to_index(unsigned int order)
> > for (i = 0; i < NUM_ORDERS; i++)
> > if (order == orders[i])
> > return i;
> > - BUG();
> > + /* This is impossible. */
> > return -1;
> > }
>
> Hi,
> Please explain why this is impossible.
>
> If some caller calls order_to_index(5), it will return -1, yes?
>
> --
> ~Randy
>
As Dan Carpenter says here https://lkml.kernel.org/lkml/cover.1597865771.git.tomersamara98@gmail.com/T/#mc790b91029565b1bb0cb87997b39007d9edb6e04.
After looking at callers we see that order_to_index called from 2 functions:
- alloc_buffer_page called from alloc_largest_available which
loop over all legit order nubmers
( Flow:
alloc_largest_available-->alloc_buffer_page-->order_to_index
)
- free_buffer_page takes the order using compound_order, which return 0 or
the order number for the page, this function has 2 callers too,
ion_system_heap_allocate (which called it in case of failure at sg_alloc_table,
thus calling from this flow will no casue error) and ion_system_heap_free
(which will be called on every sg table in the buffer that allocated good,
meaning from this flow also error will not be created).
( Flows:
ion_system_heap_free --> free_buffer_page --> order_to_index
ion_system_heap_allocate --> free_buffer_page --> order_to_index
)
Of course if some user will use this function with wrong order number he will be able to get this -1.
So should I remove this comment and resotre the error checks?
Btw, this is the same reason that I dropped the error check at ion_page_pool_shrink, so should I restore here also?
Thanks,
Tomer Samara
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Tomer Samara <tomersamara98@gmail.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arve Hjønnevåg" <arve@android.com>,
"Riley Andrews" <riandrews@android.com>,
"Laura Abbott" <labbott@redhat.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Todd Kjos" <tkjos@android.com>,
"Martijn Coenen" <maco@android.com>,
"Joel Fernandes" <joel@joelfernandes.org>,
"Christian Brauner" <christian@brauner.io>,
"Hridya Valsaraju" <hridya@google.com>,
"Suren Baghdasaryan" <surenb@google.com>,
devel@driverdev.osuosl.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/2] staging: android: Remove BUG from ion_system_heap.c
Date: Sat, 22 Aug 2020 12:34:21 +0300 [thread overview]
Message-ID: <20200822093421.GA6631@tsnow> (raw)
In-Reply-To: <3eba90dc-128f-49da-41a6-81494653d535@infradead.org>
On Fri, Aug 21, 2020 at 09:25:26AM -0700, Randy Dunlap wrote:
> On 8/21/20 8:28 AM, Tomer Samara wrote:
> > Remove BUG() from ion_sytem_heap.c
> >
> > this fix the following checkpatch issue:
> > Avoid crashing the kernel - try using WARN_ON &
> > recovery code ratherthan BUG() or BUG_ON().
> >
> > Signed-off-by: Tomer Samara <tomersamara98@gmail.com>
> > ---
> > drivers/staging/android/ion/ion_system_heap.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
> > index eac0632ab4e8..00d6154aec34 100644
> > --- a/drivers/staging/android/ion/ion_system_heap.c
> > +++ b/drivers/staging/android/ion/ion_system_heap.c
> > @@ -30,7 +30,7 @@ static int order_to_index(unsigned int order)
> > for (i = 0; i < NUM_ORDERS; i++)
> > if (order == orders[i])
> > return i;
> > - BUG();
> > + /* This is impossible. */
> > return -1;
> > }
>
> Hi,
> Please explain why this is impossible.
>
> If some caller calls order_to_index(5), it will return -1, yes?
>
> --
> ~Randy
>
As Dan Carpenter says here https://lkml.kernel.org/lkml/cover.1597865771.git.tomersamara98@gmail.com/T/#mc790b91029565b1bb0cb87997b39007d9edb6e04.
After looking at callers we see that order_to_index called from 2 functions:
- alloc_buffer_page called from alloc_largest_available which
loop over all legit order nubmers
( Flow:
alloc_largest_available-->alloc_buffer_page-->order_to_index
)
- free_buffer_page takes the order using compound_order, which return 0 or
the order number for the page, this function has 2 callers too,
ion_system_heap_allocate (which called it in case of failure at sg_alloc_table,
thus calling from this flow will no casue error) and ion_system_heap_free
(which will be called on every sg table in the buffer that allocated good,
meaning from this flow also error will not be created).
( Flows:
ion_system_heap_free --> free_buffer_page --> order_to_index
ion_system_heap_allocate --> free_buffer_page --> order_to_index
)
Of course if some user will use this function with wrong order number he will be able to get this -1.
So should I remove this comment and resotre the error checks?
Btw, this is the same reason that I dropped the error check at ion_page_pool_shrink, so should I restore here also?
Thanks,
Tomer Samara
next prev parent reply other threads:[~2020-08-24 6:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-21 15:27 [PATCH v4 0/2] staging: android: Remove BUG/BUG_ON from ion Tomer Samara
2020-08-21 15:27 ` Tomer Samara
2020-08-21 15:27 ` [PATCH v4 1/2] staging: android: Remove BUG_ON from ion_page_pool.c Tomer Samara
2020-08-21 15:27 ` Tomer Samara
2020-08-21 17:45 ` kernel test robot
2020-08-22 0:45 ` kernel test robot
2020-08-24 11:22 ` Dan Carpenter
2020-08-24 11:22 ` Dan Carpenter
2020-08-21 15:28 ` [PATCH v4 2/2] staging: android: Remove BUG from ion_system_heap.c Tomer Samara
2020-08-21 15:28 ` Tomer Samara
2020-08-21 16:25 ` Randy Dunlap
2020-08-21 16:25 ` Randy Dunlap
2020-08-22 9:34 ` Tomer Samara [this message]
2020-08-22 9:34 ` Tomer Samara
2020-08-22 14:22 ` Randy Dunlap
2020-08-22 14:22 ` Randy Dunlap
2020-08-24 11:24 ` Dan Carpenter
2020-08-24 11:24 ` Dan Carpenter
2020-08-24 11:27 ` Dan Carpenter
2020-08-24 11:27 ` Dan Carpenter
2020-08-24 11:43 ` Dan Carpenter
2020-08-24 11:43 ` Dan Carpenter
2020-08-25 6:47 ` [PATCH v4 0/2] staging: android: Remove BUG/BUG_ON from ion Christoph Hellwig
2020-08-25 6:52 ` Greg Kroah-Hartman
2020-08-25 6:52 ` Greg Kroah-Hartman
2020-08-27 7:16 ` Christoph Hellwig
2020-08-27 12:15 ` Greg Kroah-Hartman
2020-08-27 12:15 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200822093421.GA6631@tsnow \
--to=tomersamara98@gmail.com \
--cc=arve@android.com \
--cc=christian@brauner.io \
--cc=devel@driverdev.osuosl.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=hridya@google.com \
--cc=joel@joelfernandes.org \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maco@android.com \
--cc=rdunlap@infradead.org \
--cc=riandrews@android.com \
--cc=surenb@google.com \
--cc=tkjos@android.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.