Date: Sun, 30 Jan 2011 17:44:15 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: Julian Elischer <julian@freebsd.org> Cc: Daniel Eischen <deischen@freebsd.org>, Hans Petter Selasky <hselasky@c2i.net>, freebsd-arch@freebsd.org Subject: Re: ofed merge soon Message-ID: <alpine.BSF.2.00.1101301741310.1412@desktop> In-Reply-To: <4D4559A2.7040601@freebsd.org> References: <alpine.BSF.2.00.1101271653470.1412@desktop> <201101291032.35544.hselasky@c2i.net> <alpine.BSF.2.00.1101292143010.1412@desktop> <201101301016.55633.hselasky@c2i.net> <Pine.GSO.4.64.1101300710520.20802@sea.ntplx.net> <4D4559A2.7040601@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 30 Jan 2011, Julian Elischer wrote:
> On 1/30/11 4:12 AM, Daniel Eischen wrote:
>> On Sun, 30 Jan 2011, Hans Petter Selasky wrote:
>>
>>> On Sunday 30 January 2011 08:44:45 Jeff Roberson wrote:
>>>> On Sat, 29 Jan 2011, Hans Petter Selasky wrote:
>>>>> Hi,
>>>>>
>>>>> Just a comment:
>>>>>
>>>>> +
>>>>> +#define DEFINE_MUTEX(lock)
>>>>> \
>>>>> + mutex_t lock;
>>>>> \
>>>>> + SX_SYSINIT_FLAGS(lock, &(lock).sx, "lnxmtx", SX_NOWITNESS)
>>>>> +
>>>>> +static inline void
>>>>> +linux_mutex_init(mutex_t *m)
>>>>> +{
>>>>> +
>>>>> + memset(&m->sx, 0, sizeof(m->sx));
>>>>> + sx_init_flags(&m->sx, "lnxmtx", SX_NOWITNESS);
>>>>> +}
>>>>> +
>>>>> +#define mutex_init linux_mutex_init
>>>>>
>>>>> I see you workaround the fact that Linux does not destroy any mutexes by
>>>>> disabling witness. Do you have any plan to upgrade the Linux 3rd party
>>>>> code to destroy mutexes?
>>>>
>>>> It introduces too many diffs that are difficult to maintain. I don't
>>>> think it's viable. One option would be to tag the memory linux uses so
>>>> that when it's freed we reclaim any locks in it. You could scan the
>>>> witness tables for pointers within the free'd region fairly easily. It
>>>> wouldn't be pretty though.
>>>
>>> How about requiring that Linux code, once imported, must destroy it's
>>> mutexes?
>>
>> Or add a mutex_destroy for all OS's, and make it a noop
>> for Linux. Then there are no diffs to maintain...
>
> the upstream source is linux only code and they do not accept non linux
> patches.
Julian's right. They won't accept anything. There is also the problem
that their locks have no names and witness requires a name. We'd have to
name them by address or something similarly hacky and this then leaves
holes in what witness can discover.
Fortunately, they have their own lock order test tool (lockdep) and do
their own order validation. The places where they cross over into FreeBSD
are few and well contained. If we can assume that they get the locks
right on their own platform and we get our locks correctly it's not so
hard to manage the places that they meet.
Thanks,
Jeff
>
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1101301741310.1412>