Date:Fri, 10 Aug 2018 19:17:55 -0400 (EDT)
From:Mouse
Message-ID: <201808102317.taa24...@stone.rodents-montreal.org>
| However, whether it means "nyah nyah, I'm not telling you this" or
| "don't worry, this won't be on the exam"
Not either I would think - the
I doubt that your new proposed ioctl() is a very good
interface - to do what you really need you would require
the equivalent of a "test & set" otherwise all you are
doing is creating a race condition - even though it is,
because of the low number of users, one that is
unlikely to matter very
Emmanuel Dreyfus wrote:
> Perhaps the right way is to add a FSSIOBUSY ioctl that would
> use mutex_tryenter and return EBUSY if the device is in use?
I propose the change below, so that we can find an available /dev/fss*
device without hanging:
--- sys/dev/fss.c.orig
+++ sys/dev/fss.c
@@
>> | Ancient BSD tradition is not to explain these things :-(
>> Older than that. Don't you remember
>> you are not expected to understand this
>> (or wording very similar) in ancient 4th/5th edition unix.
> The explanation for that comment I've read somewhere was that it
> really meant
> Are you sure it _only_ happens in the do/while and _never_ in the
> preceding if?
Well, the three times I looked at the backtrace carefully, yes (I have photos).
The next two or three times, I'm not completely sure.
> In any case, it's just a diagnostic, not a protocol for a robust
> software
On Sat, Aug 11, 2018 at 00:46:26 +0700, Robert Elz wrote:
> Date:Fri, 10 Aug 2018 08:03:55 -0400
> From:Greg Troxel
> Message-ID:
>
> | Ancient BSD tradition is not to explain these things :-(
>
> Older than that. Don't you remember
> you are not
> Date: Fri, 10 Aug 2018 19:48:40 +0200
> From: Edgar Fuß
>
> > Yes -- isn't that the symptom you're seeing, or did I miss something?
> It's the mutex_oncpu in the while condition that crashes, not the on in the
> if condition above the do.
Are you sure it _only_ happens in the do/while and
> Yes -- isn't that the symptom you're seeing, or did I miss something?
It's the mutex_oncpu in the while condition that crashes, not the on in the
if condition above the do.
> It doesn't really matter since (a) only one thread ever sets the
> variable, (b) there are no invariants around it, and
Date:Fri, 10 Aug 2018 08:03:55 -0400
From:Greg Troxel
Message-ID:
| Ancient BSD tradition is not to explain these things :-(
Older than that. Don't you remember
you are not expected to understand this
(or wording very similar) in ancient 4th/5th edition
> Date: Fri, 10 Aug 2018 19:05:28 +0200
> From: Edgar Fuß
>
> > More likely is that the socket is prematurely freed before unp_gc
> > grabs it at all.
> But then the mutex_oncpu() in the if above the do...while would panic, no?
Yes -- isn't that the symptom you're seeing, or did I miss
> More likely is that the socket is prematurely freed before unp_gc
> grabs it at all.
But then the mutex_oncpu() in the if above the do...while would panic, no?
> You could do something like create a global variable that stores the
> socket pointer that unp_gc is currently working on, shortly
> Date: Fri, 10 Aug 2018 17:51:11 +0200
> From: Edgar Fuß
>
> I'm currently running an 8.0_STABLE kernel on the machine (with 6.1_STABLE
> userland) and no panics so far. This smay be
> -- luck
> -- different timing that doesn't trigger the race
> -- a bug fixed since 6.1
>
> If someone
Thank you both for the detailed explanations and audits!
I'm currently running an 8.0_STABLE kernel on the machine (with 6.1_STABLE
userland) and no panics so far. This smay be
-- luck
-- different timing that doesn't trigger the race
-- a bug fixed since 6.1
If someone remembers a bug in this
> Date: Fri, 10 Aug 2018 08:03:55 -0400
> From: Greg Troxel
>
> Edgar Fuà writes:
>
> > Is there a general scheme/rule/proposal how to prevent a mutex that someone
> > is trying to mutex_enter() from being teared down by someone else calling
> > mutex_destroy() on it during that?
>
> Not
Thanks for the link.
On Fri, Aug 10, 2018 at 3:19 PM Maxime Villard wrote:
> Le 10/08/2018 à 11:18, Ripunjay Tripathi a écrit :
> > I am trying to test presence of CVE-2018-6922 [...]
>
> NetBSD 5 is not supported anymore, and NetBSD 6 is about to reach EOL. So
> there is no way this is ever
Hello
How are user processes supposed to find an unused fss device?
In dump(8) code, there is an iteration on /dev/rfss* trying to
performan an ioctl FSSIOCSET. The code tests for EBUSY on failure,
but in my experience that struggles to happen: if the device is
already in use, the ioctl will
Edgar Fuß writes:
> I know very little about locking so that's probably a stupid question, but:
Don't worry - locking is probably the hardest thing to get right.
> Is there a general scheme/rule/proposal how to prevent a mutex that someone
> is trying to mutex_enter() from being teared down
I saw the thread [Re: Sample based profiling] on tech-userlevel@, I'm not
subscribed to this list but I'm answering here because it's related to
tprof among other things.
I agree that it would be better to retire gprof in base, because there are
more powerful tools now, and also advanced
>> I am trying to test presence of CVE-2018-6922 [...]
> NetBSD 5 is not supported anymore, and NetBSD 6 is about to reach
> EOL. So there is no way this is ever going to be fixed in NetBSD 5.
That's a bit of an overstatement. Not fixed _by NetBSD_, perhaps, but
there are at least a few people
Le 10/08/2018 à 11:18, Ripunjay Tripathi a écrit :
I am trying to test presence of CVE-2018-6922 [...]
NetBSD 5 is not supported anymore, and NetBSD 6 is about to reach EOL. So
there is no way this is ever going to be fixed in NetBSD 5.
There was a small conversation about the issue
But what do I gain if the real keyboard and the internal-USB keyboard emulated
by IPMI's console redirection are on different USB ports?
> ddb should be able to talk to the console keyboard (via polling)
What exactly does that mean in case the console keyboard is wscins?
> Sorry, my description wasn't clear.
I did understand it.
The drawback is you don't see the kernel messages (including the fact the
machne paniced) on the VGA monitor. You would need to use IPMI.
I know very little about locking so that's probably a stupid question, but:
Is there a general scheme/rule/proposal how to prevent a mutex that someone
is trying to mutex_enter() from being teared down by someone else calling
mutex_destroy() on it during that?
Specifically, I'm trying to
> > >> 100.002054 14.18 kernel_lock
> > >> 47.43 846 6.72 kernel_lockfileassoc_file_delete+20
> > >> 23.73 188 3.36 kernel_lockintr_biglock_wrapper+16
> > >> 16.01 203 2.27 kernel_lockscsipi_adapter_request+63
m...@netbsd.org (Emmanuel Dreyfus) writes:
>I can tell that in vfs_bio.c, bread() -> bio_doread() will call
>VOP_STRATEGY once for the offendinf buf_t, but biodone() is called twice
>in interrupt context for the buf_t, leading to the biodone2 already
>panic later.
>Since you know the xbd code
> On Aug 9, 2018, at 10:40 AM, Thor Lancelot Simon wrote:
>
> Actually, I wonder if we could kill off the time spent by fileassoc. Is
> it still used only by veriexec? We can easily option that out of the build
> box kernels.
Indeed. And there are better ways to do what veriexec does, in
I would be interested to finish that off, I need to make some time to
get to doing it though.
I have been sitting on some changes to veriexec for ~ years that
change it from locking everything to using reference counts and
condition variables which removes some nasty hacks I did. I have not
dholland-t...@netbsd.org (David Holland) writes:
>Probably, but I don't think it's supposed to happen and possibly it
>should be a panic:
It can regularly happen under load and the retry is supposed to handle that
condition. Still, it shouldn't occur frequently, so in this case there
is a
29 matches
Mail list logo
