On Thu, Jun 27, 2019 at 3:10 PM Davide Caratti wrote:
>
> On Wed, 2019-06-26 at 14:15 -0700, Cong Wang wrote:
> > Hi, Davide
> >
> > On Tue, Jun 25, 2019 at 12:29 PM Cong Wang wrote:
> > > It should handle this overflow case more gracefully, I hope.
> > >
> >
> > Please try this attached one and
On Wed, 2019-06-26 at 14:15 -0700, Cong Wang wrote:
> Hi, Davide
>
> On Tue, Jun 25, 2019 at 12:29 PM Cong Wang wrote:
> > It should handle this overflow case more gracefully, I hope.
> >
>
> Please try this attached one and let me know if it works.
> Hope I get it right this time.
>
> Thanks!
Hi, Davide
On Tue, Jun 25, 2019 at 12:29 PM Cong Wang wrote:
> It should handle this overflow case more gracefully, I hope.
>
Please try this attached one and let me know if it works.
Hope I get it right this time.
Thanks!
idr_get_next_ul.patch
Description: Binary data
On Tue, Jun 25, 2019 at 12:29 PM Cong Wang wrote:
>
> On Tue, Jun 25, 2019 at 11:07 AM Cong Wang wrote:
> > On one hand, its callers should not need to worry about details
> > like overflow. On the other hand, in fact it does exactly what its
> > callers tell it to do, the problematic part is act
On Tue, Jun 25, 2019 at 11:07 AM Cong Wang wrote:
> On one hand, its callers should not need to worry about details
> like overflow. On the other hand, in fact it does exactly what its
> callers tell it to do, the problematic part is actually the
> incremented id. On 64bit, it is fairly easy, we c
Hello,
On Tue, Jun 25, 2019 at 8:47 AM Davide Caratti wrote:
> hello Cong,
>
> I tested the above patch, but I still see the infinite loop on kernel
> 5.2.0-0.rc5.git0.1.fc31.i686 .
>
> idr_get_next_ul() returns the entry in the radix tree which is greater or
> equal to '*nextid' (which has the s
On Tue, 2019-06-25 at 17:47 +0200, Davide Caratti wrote:
> On Thu, 2019-06-20 at 10:33 -0700, Cong Wang wrote:
> > On Thu, Jun 20, 2019 at 5:52 AM Davide Caratti wrote:
> > > hello Cong, thanks for reading.
> > >
> > > On Wed, 2019-06-19 at 15:04 -0700, Cong Wang wrote:
> > > > On Wed, Jun 19, 20
On Thu, 2019-06-20 at 10:33 -0700, Cong Wang wrote:
> On Thu, Jun 20, 2019 at 5:52 AM Davide Caratti wrote:
> > hello Cong, thanks for reading.
> >
> > On Wed, 2019-06-19 at 15:04 -0700, Cong Wang wrote:
> > > On Wed, Jun 19, 2019 at 2:10 PM Davide Caratti
> > > wrote:
> > > > on some CPUs (e.g
On Thu, Jun 20, 2019 at 5:52 AM Davide Caratti wrote:
>
> hello Cong, thanks for reading.
>
> On Wed, 2019-06-19 at 15:04 -0700, Cong Wang wrote:
> > On Wed, Jun 19, 2019 at 2:10 PM Davide Caratti wrote:
> > > on some CPUs (e.g. i686), tcf_walker.cookie has the same size as the IDR.
> > > In this
hello Cong, thanks for reading.
On Wed, 2019-06-19 at 15:04 -0700, Cong Wang wrote:
> On Wed, Jun 19, 2019 at 2:10 PM Davide Caratti wrote:
> > on some CPUs (e.g. i686), tcf_walker.cookie has the same size as the IDR.
> > In this situation, the following script:
> >
> > # tc filter add dev eth0
On Wed, Jun 19, 2019 at 2:10 PM Davide Caratti wrote:
>
> on some CPUs (e.g. i686), tcf_walker.cookie has the same size as the IDR.
> In this situation, the following script:
>
> # tc filter add dev eth0 ingress handle 0x flower action ok
> # tc filter show dev eth0 ingress
>
> results i
on some CPUs (e.g. i686), tcf_walker.cookie has the same size as the IDR.
In this situation, the following script:
# tc filter add dev eth0 ingress handle 0x flower action ok
# tc filter show dev eth0 ingress
results in an infinite loop. It happened also on other CPUs (e.g x86_64),
befo
12 matches
Mail list logo
