Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1610994
| From | "Reshetova, Elena" <elena.reshetova@intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | RE: [PATCH 06/16] drivers, net, mlx5: convert mlx5_cq.refcount from atomic_t to refcount_t |
| Date | 2017-03-28 16:10 +0200 |
| Message-ID | <tpZYS-lk-21@gated-at.bofh.it> (permalink) |
| References | <tpV8T-535-29@gated-at.bofh.it> <tpV8T-535-27@gated-at.bofh.it> <tpVLA-5we-31@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
> From: Elena Reshetova > > Sent: 28 March 2017 09:57 > > > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > > situations. > > I can't help feeling that you ought to find a scheme > that will detect extra decrements and extra increments > before the counter wraps 32 bits. > > If an extra reference is requested every 100us it takes 4.8 days > for the counter to increment back to zero. > Simple tests aren't doing to find that - but it can easily happen > on a system that is running for several years. So, you are proposing to try detecting this case instead of preventing overflows? Not sure how this would look like in a generic form... > > David
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH 06/16] drivers, net, mlx5: convert mlx5_cq.refcount from atomic_t to refcount_t Elena Reshetova <elena.reshetova@intel.com> - 2017-03-28 11:00 +0200
RE: [PATCH 06/16] drivers, net, mlx5: convert mlx5_cq.refcount from atomic_t to refcount_t David Laight <David.Laight@ACULAB.COM> - 2017-03-28 11:40 +0200
RE: [PATCH 06/16] drivers, net, mlx5: convert mlx5_cq.refcount from atomic_t to refcount_t "Reshetova, Elena" <elena.reshetova@intel.com> - 2017-03-28 16:10 +0200
csiph-web