On Tue, Nov 25, 2014 at 9:38 AM, Mindaugas Rasiukevicius
wrote:
> I would rather extend atomic_ops(3) API to have functions which ensure
> a particular memory barrier or a function which takes the constraint as
> an extra argument, like in C11 API. Speaking of which, it might be worth
> to evalua
The problem of kpreempt_*() API is that its meaning is overriden by kernel
internal (scheduler, sync primitives, ...). This change separates the internal
use (scheduler disables preeemption) and others (kernel subsystem code executes
critical section). Detect sleep from within critical section in
On Wed, Nov 26, 2014 at 02:18:12PM +1100, Paul Ripke wrote:
> On Tue, Nov 25, 2014 at 12:00:48PM +0100, Edgar Fu? wrote:
> > > Nope, it's inaccessible - again, it was the daily security reports
> > > that alerted me:
> > >
> > > slave:ksh$ find /home/tmp > /dev/null
> > > find: /home/tmp/badfile:
On Wed, Nov 26, 2014 at 2:43 PM, Masao Uebayashi wrote:
> On Wed, Nov 26, 2014 at 1:02 PM, Ryota Ozaki wrote:
>> Here is a latest patch:
>> http://www.netbsd.org/~ozaki-r/watchdog-callout-per-if.diff
>
> OK from me.
>
>> So my remaining concern is whether we can embed callout_t with _KERNEL
>> wh
On Wed, Nov 26, 2014 at 1:02 PM, Ryota Ozaki wrote:
> Here is a latest patch:
> http://www.netbsd.org/~ozaki-r/watchdog-callout-per-if.diff
OK from me.
> So my remaining concern is whether we can embed callout_t with _KERNEL
> which I proposed earlier. If the answer is no, the above patch that
>
On Tue, Nov 25, 2014 at 09:25:02AM +0100, Martin Husemann wrote:
> On Tue, Nov 25, 2014 at 01:22:00PM +1100, Paul Ripke wrote:
> > slave:ksh$ find /home/tmp > /dev/null
> > find: /home/tmp/badfile: Bad file descriptor
>
> Is that FS on raidframe?
>
> I saw something like this once and blamed it o
On Tue, Nov 25, 2014 at 12:00:48PM +0100, Edgar Fu? wrote:
> > Nope, it's inaccessible - again, it was the daily security reports
> > that alerted me:
> >
> > slave:ksh$ find /home/tmp > /dev/null
> > find: /home/tmp/badfile: Bad file descriptor
> I remember having run into the same thing.
> I sim
On Wed, Nov 26, 2014 at 11:58 AM, Ryota Ozaki wrote:
> On Wed, Nov 26, 2014 at 11:24 AM, Masao Uebayashi wrote:
>> On Wed, Nov 26, 2014 at 1:31 AM, Ryota Ozaki wrote:
I'd change if__pad1 to if_flags2 and define IFF2_SLOWTIMO_MPSAFE etc.
>>>
>>> Hmm, I think it's a last resort. I don't want
On Wed, Nov 26, 2014 at 11:24 AM, Masao Uebayashi wrote:
> On Wed, Nov 26, 2014 at 1:31 AM, Ryota Ozaki wrote:
>>> I'd change if__pad1 to if_flags2 and define IFF2_SLOWTIMO_MPSAFE etc.
>>
>> Hmm, I think it's a last resort. I don't want to do something like
>> (ifp->if_flags & IFF_XXX) && (ifp->i
On Wed, Nov 26, 2014 at 1:31 AM, Ryota Ozaki wrote:
>> I'd change if__pad1 to if_flags2 and define IFF2_SLOWTIMO_MPSAFE etc.
>
> Hmm, I think it's a last resort. I don't want to do something like
> (ifp->if_flags & IFF_XXX) && (ifp->if_flags2 & IFF_XXX2) if possible.
>
> I'm thinking more to avoid
Date: Tue, 25 Nov 2014 16:40:30 + (UTC)
From: Eduardo Horvath
On Mon, 24 Nov 2014, Taylor R Campbell wrote:
> What exactly is the consistency you need before accessing the lock?
I know you need a `membar #Lookaside' before accessing the atomic
variable. I don't recall if
On Mon, 24 Nov 2014, Taylor R Campbell wrote:
>Date: Mon, 24 Nov 2014 16:44:41 + (UTC)
>From: Eduardo Horvath
>
>I enhanced membar_ops with proper memory barriers and then was looking at
>the mutex code. Unfortunately, I didn't get very far. It seemed at the
>time tha
On Wed, Nov 26, 2014 at 12:50 AM, Masao Uebayashi wrote:
> On Wed, Nov 26, 2014 at 12:29 AM, Ryota Ozaki wrote:
>> Yes, we can extend if_flags to int by unifying with if__pad1, and it works
>> for the kernel and for old userland programs on little endian machines.
>> However, it doesn't work for
On Wed, Nov 26, 2014 at 12:29 AM, Ryota Ozaki wrote:
> Yes, we can extend if_flags to int by unifying with if__pad1, and it works
> for the kernel and for old userland programs on little endian machines.
> However, it doesn't work for old userland programs on big endian machines,
> IIUC. An old us
On Tue, Nov 25, 2014 at 10:02 PM, Masao Uebayashi wrote:
> On Tue, Nov 25, 2014 at 7:18 PM, Ryota Ozaki wrote:
>> Hmm, if_flags.
>>
>> http://mail-index.netbsd.org/tech-net/2009/01/27/msg000985.html
>>
>> Do we have to care about kvm(3) users (i.e., netstat) as well as
>> the callout_t issue?
>
>
On Nov 25, 1:22pm, s...@stix.id.au (Paul Ripke) wrote:
-- Subject: Re: Unallocated inode
| On Mon, Nov 24, 2014 at 08:01:57PM -0500, Christos Zoulas wrote:
| > On Nov 25, 10:59am, s...@stix.id.au (Paul Ripke) wrote:
| > -- Subject: Re: Unallocated inode
| >
| > | On Tue, Sep 02, 2014 at 06:15:49
I think I can help sysctl'ification, but let's check in this callout
thing first.
On Tue, Nov 25, 2014 at 7:18 PM, Ryota Ozaki wrote:
> Hmm, if_flags.
>
> http://mail-index.netbsd.org/tech-net/2009/01/27/msg000985.html
>
> Do we have to care about kvm(3) users (i.e., netstat) as well as
> the callout_t issue?
For new flags, you can reuse if__pad1.
> I don't understand how kvm
> Nope, it's inaccessible - again, it was the daily security reports
> that alerted me:
>
> slave:ksh$ find /home/tmp > /dev/null
> find: /home/tmp/badfile: Bad file descriptor
I remember having run into the same thing.
I simultaneously had another FS problem (the kernel repeatedly panic()ing
on
On Mon, Nov 24, 2014 at 5:26 PM, matthew green wrote:
>
> could you also fix netstat, etc., to use sysctl to obtain this
> info, while you're at it, so we can provide a stable ABI for this
> such that changing internel kernel information doesn't matter.
I'm putting the task in my todo list. I'm n
On Mon, Nov 24, 2014 at 3:26 PM, Masao Uebayashi wrote:
> (I'm trying, but I can't follow up all mails soon, because I need more
> than x2 energy & time to write English than you.)
>
> On Mon, Nov 24, 2014 at 12:12 PM, Taylor R Campbell
> wrote:
>>Date: Mon, 24 Nov 2014 11:23:28 +0900
>>F
On Mon, Nov 24, 2014 at 11:23 AM, Masao Uebayashi wrote:
> http://marc.info/?t=14167055271&r=1&w=2
>
> Following the ideas raised in that thread:
Thank you for the information.
>
> - Allocate callout_t dynamically. struct ifnet only has a pointer to struct
> callout, which will not be rea
On Tue, Nov 25, 2014 at 01:22:00PM +1100, Paul Ripke wrote:
> slave:ksh$ find /home/tmp > /dev/null
> find: /home/tmp/badfile: Bad file descriptor
Is that FS on raidframe?
I saw something like this once and blamed it on a failing disk (which
did show SMART errors shortly afterwards), i.e. I assum
23 matches
Mail list logo
