linux-kernel - Re: [patch] convert aio event reap to use atomic-op instead of spin

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Apr 2007 11:29:45 -0700
From:	"Ken Chen" <kenchen@...gle.com>
To:	"Zach Brown" <zach.brown@...cle.com>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>, linux-aio@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] convert aio event reap to use atomic-op instead of spin_lock

On 4/11/07, Zach Brown <zach.brown@...cle.com> wrote:
> > Sorry I wasn't thorough enough.  And partially because I was worried
> > about changing structure type for user space facing struct aio_ring.
> > Now that I looked through all arches, it looks safe as all arch's
> > atomic_t has the same size as int.
>
> > Here is the updated patch.
>
> > @@ -144,7 +144,7 @@ struct kiocb {
> >  struct aio_ring {
> >       unsigned        id;     /* kernel internal index number */
> >       unsigned        nr;     /* number of io_events */
> > -     unsigned        head;
> > +     atomic_t        head;
> >       unsigned        tail;
>
> Embedding an atomic_t in an ABI struct?  That makes everyone else
> nervous too, right?

sure, make me nervous at least.


> It may look safe on i386/x86-64 today, but this doesn't seem like wise
> practice.  Is there any reason to believe that atomic_t will never
> change size?  Does anything else do this already?
>
> If nothing else, the "unsigned" (should be __u32, sigh) could be cast to
> an atomic_t.

The atomic_t cast is equally iffy.  I don't know what would be a best solution.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/