Re: [Nbd] [patch net-next 0/3] net/sched: Improve getting objects by indexes
- To: Christian König <christian.koenig@...2979...>, "Chris Mi" <chrism@...1480...>, netdev@...25...
- Cc: aditr@...1745..., stern@...2977..., agk@...696..., alexander.shishkin@...2913..., alexandre.bounine@...2978..., alexander.deucher@...2979..., oakad@...34..., ast@...1285..., elder@...1285..., adobriyan@...17..., alex.williamson@...696..., AlexBin.Xie@...2979..., viro@...1300..., amd-gfx@...1051..., amitkarwar@...17..., andresx7@...17..., andrew.donnellan@...2980..., afd@...1861..., akpm@...133..., anil.gurumurthy@...1472..., anna.schumaker@...2366..., acme@...1285..., arnd@...2332..., dedekind1@...17..., ashutosh.dixit@...1303..., ath10k@...1331..., Bart.VanAssche@...2981..., bhaktipriya96@...17..., bjorn.andersson@...1479..., boris.brezillon@...1551..., computersforpeace@...17..., bryan.thompson@...2982..., cgroups@...25..., 3chas3@...17..., ccaulfie@...696..., david1.zhou@...2979..., cluster-devel@...696..., colin.king@...1301..., xiyou.wangcong@...17..., cyrille.pitchen@...2984..., daniel@...2985..., daniel.vetter@...1303..., dasaratharaman.chandramouli@...1303..., airlied@...696..., dsa@...2986..., airlied@...2987..., david.binder@...2982..., dhowells@...696..., david.kershner@...2982..., dtwlin@...17..., dave@...2988..., davem@...2890..., teigland@...696..., dwindsor@...17..., dwmw2@...1270..., dennis.dalessandro@...1303..., devel@...1311..., devesh.sharma@...2989..., devicetree@...25..., dick.kennedy@...2989..., dm-devel@...696..., don.hiatt@...1303..., dgilbert@...2990..., dledford@...696..., drbd-dev@...1284..., dri-devel@...1051..., elena.reshetova@...1303..., edumazet@...79..., eparis@...2991..., ericvh@...17..., ebiederm@...2992..., evan.quan@...2979..., felipe.balbi@...2913..., Felix.Kuehling@...2979..., f.fainelli@...17..., fw@...2993..., frowand.list@...17..., fbarrat@...1294..., fujita.tomonori@...934..., gbhat@...1552..., geliangtang@...17..., kraxel@...696..., gregkh@...1299..., greybus-dev@...2994..., linux@...2995..., gustavo.padovan@...2996..., hal.rosenstock@...17..., hannes@...2997..., hare@...122..., ishkamiel@...17..., hans.westgaard.ry@...57..., ray.huang@...2979..., mingo@...696..., inki.dae@...1329..., intel-gfx@...1051..., intel-gvt-dev@...1051..., iommu@...1310..., ira.weiny@...1303..., jinpu.wang@...2998..., jhs@...2999..., jejb@...1294..., james.smart@...2989..., jani.nikula@...2913..., jack@...1290..., jarkko.sakkinen@...2913..., jarno@...3000..., Jason@...3001..., jgunthorpe@...3002..., jasowang@...696..., javier@...3003..., bfields@...3004..., jlayton@...3005..., axboe@...161..., jens.wiklander@...1479..., jiangyilism@...17..., jiri@...1480..., jiri@...3006..., jlbec@...3007..., joro@...3008..., johan@...1285..., johannes@...3009..., hannes@...1554..., john@...3010..., jonathanh@...3011..., jon.maloy@...3012..., joonas.lahtinen@...2913..., jy0922.shim@...1329..., jbacik@...2204..., Jerry.Zhang@...2979..., jsarha@...1861..., Kai.Makisara@...3013..., kvalo@...3014..., keescook@...3015..., krzk@...1285..., kgene@...1285..., kvm@...25..., kyungmin.park@...1329..., jiangshanlai@...17..., lars.ellenberg@...2433..., lucho@...3016..., lee.jones@...1479..., leo.liu@...2979..., leon@...1285..., linux1394-devel@lists.sourceforge.net, linux-arm-kernel@...1331..., linux-atm-general@lists.sourceforge.net, linux-block@...25..., linux-i2c@...25..., linux-kernel@...25..., linux-mm@...1312..., linux-mtd@...1331..., linux-nfs@...25..., linux-pm@...25..., linuxppc-dev@...1308..., linux-ppp@...25..., linux-raid@...25..., linux-rdma@...25..., linux-remoteproc@...25..., linux-samsung-soc@...25..., linux-scsi@...25..., linux-sctp@...25..., linux-tegra@...25..., linux-usb@...25..., linux-wireless@...25..., logang@...3017..., majd@...1480..., manfred@...3018..., tpmdd@...3019..., marcos.souza.org@...17..., marek.vasut@...17..., mario.kleiner.de@...17..., markb@...1480..., mfasheh@...3020..., elfring@...81..., martin.petersen@...57..., matan@...1480..., mawilcox@...3021..., mporter@...1287..., mchehab@...1285..., maximlevitsky@...17..., mst@...696..., mhocko@...1285..., michel.daenzer@...2979..., mike.marciniszyn@...1303..., rppt@...1294..., snitzer@...696..., mszeredi@...696..., minchan@...1285..., tom.leiming@...17..., monis@...1480..., Monk.Liu@...2979..., nbd-general@lists.sourceforge.net, neilb@...1750..., nhorman@...1473..., nab@...1420..., nicolai.haehnle@...2979..., nicolas.dichtel@...3022..., niranjana.vishwanathapura@...1303..., nishants@...1552..., ngupta@...1305..., ocfs2-devel@...1749..., ohad@...3023..., oneukum@...1750..., osandov@...2204..., ogerlitz@...1480..., pali.rohar@...17..., pantelis.antoniou@...3024..., paulus@...1288..., paul@...1476..., peterhuewe@...13..., peterz@...1270..., pmladek@...1750..., philipp.reisner@...2433..., pshelar@...3000..., rjw@...3025..., richard@...2889..., rlove@...3026..., robh+dt@...1285..., giometti@...3027..., rogerq@...1861..., roman.kapl@...3028..., rminnich@...3029..., rmk+kernel@...3030..., sainath.grandhi@...1303..., sameer.wadgaonkar@...2982..., sean.hefty@...1303..., seanpaul@...3015..., bigeasy@...1530..., sre@...1285..., nsekhar@...1861..., selvin.xavier@...2989..., sergey.senozhatsky.work@...17..., sw0312.kim@...1329..., p.shailesh@...1329..., shli@...1285..., shaun.tancheff@...3031..., syeh@...1745..., sparmaintainer@...2982..., stefanr@...3032..., sboyd@...3033..., stephen@...3034..., swise@...3035..., sudarsana.kalluru@...1472..., sudeep.dutt@...1303..., sumit.semwal@...1479..., target-devel@...25..., tj@...1285..., thierry.reding@...17..., thellstrom@...1745..., timothy.sell@...2982..., tipc-discussion@lists.sourceforge.net, tomas.winkler@...1303..., tomi.valkeinen@...1861..., tpmdd-devel@lists.sourceforge.net, trond.myklebust@...1570..., v9fs-developer@lists.sourceforge.net, varun@...3035..., virtualization@...1310..., vdavydov.dev@...17..., vyasevich@...17..., linux-graphics-maintainer@...1745..., longman@...696..., weiyj.lk@...17..., wsa@...3036..., huxm@...1552..., ying.xue@...3037..., yishaih@...1480..., yuval.shaia@...57..., lizefan@...1511..., zhenyuw@...2913..., zhi.a.wang@...1303...
- Subject: Re: [Nbd] [patch net-next 0/3] net/sched: Improve getting objects by indexes
- From: Chris Wilson <chris@...2983...>
- Date: Wed, 16 Aug 2017 10:19:53 +0100
- Message-id: <150287519355.15499.3124883464555211520@...3039...>
- In-reply-to: <144b87a3-bbe4-a194-ed83-e54840d7c7c2@...2979...>
- References: <1502849538-14284-1-git-send-email-chrism@...1480...> <144b87a3-bbe4-a194-ed83-e54840d7c7c2@...2979...>
Quoting Christian König (2017-08-16 08:49:07)
> Am 16.08.2017 um 04:12 schrieb Chris Mi:
> > Using current TC code, it is very slow to insert a lot of rules.
> >
> > In order to improve the rules update rate in TC,
> > we introduced the following two changes:
> > 1) changed cls_flower to use IDR to manage the filters.
> > 2) changed all act_xxx modules to use IDR instead of
> > a small hash table
> >
> > But IDR has a limitation that it uses int. TC handle uses u32.
> > To make sure there is no regression, we also changed IDR to use
> > unsigned long. All clients of IDR are changed to use new IDR API.
>
> WOW, wait a second. The idr change is touching a lot of drivers and to
> be honest doesn't looks correct at all.
>
> Just look at the first chunk of your modification:
> > @@ -998,8 +999,9 @@ int bsg_register_queue(struct request_queue *q, struct device *parent,
> >
> > mutex_lock(&bsg_mutex);
> >
> > - ret = idr_alloc(&bsg_minor_idr, bcd, 0, BSG_MAX_DEVS, GFP_KERNEL);
> > - if (ret < 0) {
> > + ret = idr_alloc(&bsg_minor_idr, bcd, &idr_index, 0, BSG_MAX_DEVS,
> > + GFP_KERNEL);
> > + if (ret) {
> > if (ret == -ENOSPC) {
> > printk(KERN_ERR "bsg: too many bsg devices\n");
> > ret = -EINVAL;
> The condition "if (ret)" will now always be true after the first
> allocation and so we always run into the error handling after that.
ret is now purely the error code, so it doesn't look that suspicious.
> I've never read the bsg code before, but that's certainly not correct.
> And that incorrect pattern repeats over and over again in this code.
>
> Apart from that why the heck do you want to allocate more than 1<<31
> handles?
And more to the point, arbitrarily changing the maximum to ULONG_MAX
where the ABI only supports U32_MAX is dangerous. Unless you do the
analysis otherwise, you have to replace all the end=0 with end=INT_MAX
to maintain existing behaviour.
-Chris
Reply to: