Re: A PRIV_* flag for /dev/mem?
Alexander Leidinger wrote:
On Sat, 18 May 2013 07:36:01 -0600
Jamie Gritton wrote:
On 05/18/13 05:43, Konstantin Belousov wrote:
On Fri, May 17, 2013 at 01:14:23PM -0600, Jamie Gritton wrote:
I'm considering Alexander Leidinger's patch to make X11 work
inside a jail
(http://leidinger.net/FreeBSD/current-patches/0_jail.diff). It
allows a jail to optionally have access to /dev/io and DRI
(provided the requisite device files are visible in the devfs
ruleset).
I'm planning on putting this under a single jail permission, which
would group those two together as device access that allows
messing with kernel memory. It seems more complete to
put /dev/mem under that same umbrella, with the side benefit of
letting me call it "allow.dev_mem".
Currently, access is controlled only by device file permission and
a securelevel check. Jail access is allowed as long as
the /dev/mem is in the jail's ruleset (it isn't by default).
Adding a prison_priv_check() call would allow some finer control
over this. Something like:
int
memopen(struct cdev *dev __unused, int flags, int fmt __unused,
struct thread *td)
{
int error;
error = priv_check(td, PRIV_FOO);
if (error != 0&& (flags& FWRITE))
error = securelevel_gt(td->td_ucred, 0);
return (error);
}
The main question I'm coming up with here is, what PRIV_* flag
should I use. Does PRIV_IO make sense? PRIV_DRIVER? Something
new like PRIV_KMEM? Also, I'd appreciate if anyone familiar with
this interface can tell me if memopen() is the right/only place to
make this change.
Why do we need the PRIV check there at all, esp. for DRM ?
Why the devfs rulesets are not enough ?
At least for the reason Alexander's patch was first made, X11 working
inside a jail, there's already a need to get past PRIV_IO and
PRIV_DRIVER - those checks are already made so in that case the
presence of device files isn't sufficient. His solution was to
special-case PRIV_DRIVER for drm, and then add jail permission bits
that allowed PRIV_IO and PRIV_DRI_DRIVER. A largish but apparently
arbitrary set of of devices use PRIV_DRIVER, so it makes sense to
separate out this one that's necessary.
So while there may be a question as to why /dev/io and DRM should have
PRIV checks, the fact of the matter is they already do.
Now as to the change I'm considering: kmem. Since the main danger of
the existing checks (io and drm) is that they can allow you to stomp
on kernel memory, I thought it reasonable to combine them into a
single jail flag that allowed that behavior. In coming up with a
succinct name for it, I decided on allow.dev_mem (permission for
devices that work with system memory), and that brought up the
question for /dev/mem. No, I don't need to add a priv check to it;
but it seems that if such checks as PRIV_IO and PRIV_DRIVER exist for
Info:
I spoke with the author of the dri1 driver lng ago, and it was OK
for him if I would change the PRIV_DRIVER in DRI to something else.
devices already, then an architectural decision has already been made
that device file access isn't the only level of control we'd like to
have. Really I'm surprised something as potentially damaging as kmem
didn't already have a priv_check associated with it.
Now I could certainly add his patch with no changes (or with very
few), and just put in a jail flag that's X11-specific. The /dev/mem
I wouldn't be happy if my patch is committed as is. Your suggestion
sounds much better.
I would suggest "allow.kmem" or "allow.kmem_devs". The reason is that
"dev_mem" could be seen as "/dev/mem" only.
change isn't necessary to this, but it just seemed a good time to add
something that feels like a hole in the paradigm.
Bye,
Alexander.
I have 2 comments on this subject.
If I understand correctly, all the names being suggested are for an
internal flag name. What it's called internally does not interest me.
But using the internal flag name as the jail(8) parameter name would be
misleading and confusing. The single purpose of this patch is to enable
xorg to run in a jail. Naming it after some internal nob that the patch
tweaks makes no sense. Naming it "allow.xorg" identifies it's intended
purpose in a user-friendly way and is crystal clear to every one no
matter their level of technical knowledge.
Correct me if I am wrong here, but what this patch does internally
breaks the security of the jail container. There are already jail(8)
parameters that do this, so this is not new. I strongly suggest that the
documentation on this new parameter contains strong wording that informs
the reader of this security exposure and that it should NOT be used on a
jail exposed to public internet access.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on ia64/ia64
TB --- 2013-05-26 11:55:22 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-26 11:55:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-26 11:55:22 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-05-26 11:55:22 - cleaning the object tree TB --- 2013-05-26 11:56:55 - /usr/local/bin/svn stat /src TB --- 2013-05-26 11:56:58 - At svn revision 250994 TB --- 2013-05-26 11:56:59 - building world TB --- 2013-05-26 11:56:59 - CROSS_BUILD_TESTING=YES TB --- 2013-05-26 11:56:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-26 11:56:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-26 11:56:59 - SRCCONF=/dev/null TB --- 2013-05-26 11:56:59 - TARGET=ia64 TB --- 2013-05-26 11:56:59 - TARGET_ARCH=ia64 TB --- 2013-05-26 11:56:59 - TZ=UTC TB --- 2013-05-26 11:56:59 - __MAKE_CONF=/dev/null TB --- 2013-05-26 11:56:59 - cd /src TB --- 2013-05-26 11:56:59 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun May 26 11:57:06 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 26 13:28:10 UTC 2013 TB --- 2013-05-26 13:28:10 - generating LINT kernel config TB --- 2013-05-26 13:28:10 - cd /src/sys/ia64/conf TB --- 2013-05-26 13:28:10 - /usr/bin/make -B LINT TB --- 2013-05-26 13:28:11 - cd /src/sys/ia64/conf TB --- 2013-05-26 13:28:11 - /usr/sbin/config -m LINT TB --- 2013-05-26 13:28:11 - building LINT kernel TB --- 2013-05-26 13:28:11 - CROSS_BUILD_TESTING=YES TB --- 2013-05-26 13:28:11 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-26 13:28:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-26 13:28:11 - SRCCONF=/dev/null TB --- 2013-05-26 13:28:11 - TARGET=ia64 TB --- 2013-05-26 13:28:11 - TARGET_ARCH=ia64 TB --- 2013-05-26 13:28:11 - TZ=UTC TB --- 2013-05-26 13:28:11 - __MAKE_CONF=/dev/null TB --- 2013-05-26 13:28:11 - cd /src TB --- 2013-05-26 13:28:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 26 13:28:11 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] *** Error code 1 Stop. make: stopped in /obj/ia64.ia64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-05-26 13:48:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-26 13:48:31 - ERROR: failed to build LINT kernel TB --- 2013-05-26 13:48:31 - 5437.93 user 885.52 system 6788.98 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A PRIV_* flag for /dev/mem?
On 05/26/13 07:33, Joe wrote:
Alexander Leidinger wrote:
On Sat, 18 May 2013 07:36:01 -0600
Jamie Gritton wrote:
On 05/18/13 05:43, Konstantin Belousov wrote:
On Fri, May 17, 2013 at 01:14:23PM -0600, Jamie Gritton wrote:
I'm considering Alexander Leidinger's patch to make X11 work
inside a jail
(http://leidinger.net/FreeBSD/current-patches/0_jail.diff). It
allows a jail to optionally have access to /dev/io and DRI
(provided the requisite device files are visible in the devfs
ruleset).
I'm planning on putting this under a single jail permission, which
would group those two together as device access that allows
messing with kernel memory. It seems more complete to
put /dev/mem under that same umbrella, with the side benefit of
letting me call it "allow.dev_mem".
Currently, access is controlled only by device file permission and
a securelevel check. Jail access is allowed as long as
the /dev/mem is in the jail's ruleset (it isn't by default).
Adding a prison_priv_check() call would allow some finer control
over this. Something like:
int
memopen(struct cdev *dev __unused, int flags, int fmt __unused,
struct thread *td)
{
int error;
error = priv_check(td, PRIV_FOO);
if (error != 0&& (flags& FWRITE))
error = securelevel_gt(td->td_ucred, 0);
return (error);
}
The main question I'm coming up with here is, what PRIV_* flag
should I use. Does PRIV_IO make sense? PRIV_DRIVER? Something
new like PRIV_KMEM? Also, I'd appreciate if anyone familiar with
this interface can tell me if memopen() is the right/only place to
make this change.
Why do we need the PRIV check there at all, esp. for DRM ?
Why the devfs rulesets are not enough ?
At least for the reason Alexander's patch was first made, X11 working
inside a jail, there's already a need to get past PRIV_IO and
PRIV_DRIVER - those checks are already made so in that case the
presence of device files isn't sufficient. His solution was to
special-case PRIV_DRIVER for drm, and then add jail permission bits
that allowed PRIV_IO and PRIV_DRI_DRIVER. A largish but apparently
arbitrary set of of devices use PRIV_DRIVER, so it makes sense to
separate out this one that's necessary.
So while there may be a question as to why /dev/io and DRM should have
PRIV checks, the fact of the matter is they already do.
Now as to the change I'm considering: kmem. Since the main danger of
the existing checks (io and drm) is that they can allow you to stomp
on kernel memory, I thought it reasonable to combine them into a
single jail flag that allowed that behavior. In coming up with a
succinct name for it, I decided on allow.dev_mem (permission for
devices that work with system memory), and that brought up the
question for /dev/mem. No, I don't need to add a priv check to it;
but it seems that if such checks as PRIV_IO and PRIV_DRIVER exist for
Info:
I spoke with the author of the dri1 driver lng ago, and it was OK
for him if I would change the PRIV_DRIVER in DRI to something else.
devices already, then an architectural decision has already been made
that device file access isn't the only level of control we'd like to
have. Really I'm surprised something as potentially damaging as kmem
didn't already have a priv_check associated with it.
Now I could certainly add his patch with no changes (or with very
few), and just put in a jail flag that's X11-specific. The /dev/mem
I wouldn't be happy if my patch is committed as is. Your suggestion
sounds much better.
I would suggest "allow.kmem" or "allow.kmem_devs". The reason is that
"dev_mem" could be seen as "/dev/mem" only.
change isn't necessary to this, but it just seemed a good time to add
something that feels like a hole in the paradigm.
Bye,
Alexander.
I have 2 comments on this subject.
If I understand correctly, all the names being suggested are for an
internal flag name. What it's called internally does not interest me.
But using the internal flag name as the jail(8) parameter name would be
misleading and confusing. The single purpose of this patch is to enable
xorg to run in a jail. Naming it after some internal nob that the patch
tweaks makes no sense. Naming it "allow.xorg" identifies it's intended
purpose in a user-friendly way and is crystal clear to every one no
matter their level of technical knowledge.
The function of the proposed jail flag is to allow changes to
kernel-level memory. The current best use for this might be to run an
X11 server. Currently, the X11 server in favor is Xorg. So we should
call it allow.xorg? Good thing we didn't do it a few years ago, or it
would confusingly be called allow.xfree86. Perhaps some other X11 server
will fall into favor. Perhaps some other graphics system will become
more popular than the aging X11 (admittedly not likely). And someone may
have some other reason to have a jail that has kernel memory permission.
So, no. Changing the name from function to "purpose" is not at all clear.
Correct me if I am wrong here, but what this patch does internally
bre
Re: HP 2570p installation
I am sorry for the delay. > On Sat, 25 May 2013 19:14:43 -0400 > g...@freebsd.org(Glen Barber) said: > > [[PGP Signed Part:No public key for 524F0C37A0B946A3 created at > 2013-05-26T01:14:43+0200 using RSA]] > On Sun, May 26, 2013 at 12:54:09AM +0200, Ludovit Koren wrote: > > After Setting BIOS to legacy, with the 9.1-RELEASE-amd64-memstick.img, > > I succeeded to boot. The 10-CURRENT has still problems to boot to > > installation window. > > > > Where does it stop? The same place? > no. Before, it stopped right after beginning phase: bios control transfering to boot. Now, right before gtk? install phase. thanks. lk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-HEAD gets stuck on vnode operations
On 25/05/13 19:52, Roger Pau Monné wrote: > On 20/05/13 20:34, John Baldwin wrote: >> On Tuesday, May 14, 2013 1:15:47 pm Roger Pau Monné wrote: >>> On 14/05/13 18:31, Konstantin Belousov wrote: On Tue, May 14, 2013 at 06:08:45PM +0200, Roger Pau Monn? wrote: > On 13/05/13 17:00, Konstantin Belousov wrote: >> On Mon, May 13, 2013 at 04:33:04PM +0200, Roger Pau Monn? wrote: >>> On 13/05/13 13:18, Roger Pau Monn? wrote: > > Thanks for taking a look, > >>> I would like to explain this a little bit more, the syncer process >>> doesn't get blocked on the _mtx_trylock_flags_ call, it just continues >>> looping forever in what seems to be an endless loop around >>> mnt_vnode_next_active/ffs_sync. Also while in this state there is no >>> noticeable disk activity, so I'm unsure of what is happening. >> How many CPUs does your VM have ? > > 7 vCPUs, but I've also seen this issue with 4 and 16 vCPUs. > >> >> The loop you describing means that other thread owns the vnode >> interlock. Can you track what this thread does ? E.g. look at the >> vp->v_interlock.mtx_lock, which is basically a pointer to the struct >> thread owning the mutex, clear low bits as needed. Then you can >> inspect the thread and get a backtrace. > > There are no other threads running, only syncer is running on CPU 1 (see > ps in previous email). All other CPUs are idle, and as seen from the ps > quite a lot of threads are blocked in vnode related operations, either > "*Name Cac", "*vnode_fr" or "*vnode in". I've also attached the output > of alllocks in the previous email. This is not useful. You need to look at the mutex which fails the trylock operation in the mnt_vnode_next_active(), see who owns it, and then 'unwind' the locking dependencies from there. >>> >>> Sorry, now I get it, let's see if I can find the locked vnodes and the >>> thread that owns them... >> >> You can use 'show lock v_interlock>' to find an owning >> thread and then use 'show sleepchain '. If you are using kgdb on >> the >> live system (probably easier) then you can grab my scripts at >> www.freebsd.org/~jhb/gdb/ (do 'cd /path/to/scripts; source gdb6'). You can >> then find the offending thread and do 'mtx_owner &vp->v_interlock' and then >> 'sleepchain ' Hello, I've been looking into this issue a little bit more, and the lock dependencies look right to me, the lockup happens when the thread owning the v_interlock mutex tries to acquire the vnode_free_list_mtx mutex which is already owned by the syncer thread, at this point, the thread owning the v_interlock mutex goes to sleep, and the syncer process will start doing a sequence of: VI_TRYLOCK -> mtx_unlock vnode_free_list_mtx -> kern_yield -> mtx_lock vnode_free_list_mtx ... It seems like kern_yield, which I assume is placed there in order to allow the thread owning v_interlock to be able to also lock vnode_free_list_mtx, doesn't get a window big enough to wake up the waiting thread and get the vnode_free_list_mtx mutex. Since the syncer is the only process runnable on the CPU there is no context switch, and the syncer process continues to run. Relying on kern_yield to provide a window big enough that allows any other thread waiting on vnode_free_list_mtx to run doesn't seem like a good idea on SMP systems. I've not tested this on bare metal, but waking up an idle CPU in a virtualized environment might be more expensive than doing it on bare metal. Bear in mind that I'm not familiar with either the scheduler or the ufs code, my proposed naive fix is to replace the kern_yield call with a pause, that will allow any other threads waiting on vnode_free_list_mtx to lock the vnode_free_list_mtx mutex and finish whatever they are doing and release the v_interlock mutex, so the syncer thread can also finish it's work. I've tested the patch for a couple of hours and seems to be fine, I haven't been able to reproduce the issue anymore. >From fec90f7bb9cdf05b49d11dbe4930d3c595c147f5 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Sun, 26 May 2013 19:55:43 +0200 Subject: [PATCH] mnt_vnode_next_active: replace kern_yield with pause On SMP systems there is no way to assure that a kern_yield will allow any other threads waiting on the vnode_free_list_mtx to be able to acquire it. The syncer process can get stuck in a loop trying to lock the v_interlock mutex, without allowing other threads waiting on vnode_free_list_mtx to run. Replace the kern_yield with a pause, that should allow any thread owning v_interlock and waiting on vnode_free_list_mtx to finish it's work and release v_interlock. --- sys/kern/vfs_subr.c | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index 0da6764..597f4b7 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -4703,7 +4703,15 @@ restart: if (mp_ncpus == 1
Re: HP 2570p installation
On Sun, May 26, 2013 at 09:20:56PM +0200, Ludovit Koren wrote: > > I am sorry for the delay. > Acutally, I did get your original reply. Sorry I did not repsond sooner. > > > After Setting BIOS to legacy, with the 9.1-RELEASE-amd64-memstick.img, > > > I succeeded to boot. The 10-CURRENT has still problems to boot to > > > installation window. > > > > > > > Where does it stop? The same place? > > > > no. Before, it stopped right after beginning phase: bios control > transfering to boot. Now, right before gtk? install phase. > Are you able to see what is on the screen right before the installation screen? FWIW, I did test this image, and was able to get to the initial installation screen, and was able to get to the live cd. Can you also try pressing [CTRL][ALT][F4]? I think there is an emergency TTY set up, same as with the 8.x images. Also, what options do you have for the SATA controller on this machine? Can you toggle between AHCI and ATA to see if you can get past this hang? Glen pgphbm8jpzVg7.pgp Description: PGP signature
Re: FreeBSD-HEAD gets stuck on vnode operations
On Sun, May 26, 2013 at 09:28:05PM +0200, Roger Pau Monné wrote: > On 25/05/13 19:52, Roger Pau Monné wrote: > > On 20/05/13 20:34, John Baldwin wrote: > >> On Tuesday, May 14, 2013 1:15:47 pm Roger Pau Monné wrote: > >>> On 14/05/13 18:31, Konstantin Belousov wrote: > On Tue, May 14, 2013 at 06:08:45PM +0200, Roger Pau Monn? wrote: > > On 13/05/13 17:00, Konstantin Belousov wrote: > >> On Mon, May 13, 2013 at 04:33:04PM +0200, Roger Pau Monn? wrote: > >>> On 13/05/13 13:18, Roger Pau Monn? wrote: > > Thanks for taking a look, > >>> I would like to explain this a little bit more, the syncer process > >>> doesn't get blocked on the _mtx_trylock_flags_ call, it just continues > >>> looping forever in what seems to be an endless loop around > >>> mnt_vnode_next_active/ffs_sync. Also while in this state there is no > >>> noticeable disk activity, so I'm unsure of what is happening. > >> How many CPUs does your VM have ? > > 7 vCPUs, but I've also seen this issue with 4 and 16 vCPUs. > >> The loop you describing means that other thread owns the vnode > >> interlock. Can you track what this thread does ? E.g. look at the > >> vp->v_interlock.mtx_lock, which is basically a pointer to the struct > >> thread owning the mutex, clear low bits as needed. Then you can > >> inspect the thread and get a backtrace. > > There are no other threads running, only syncer is running on CPU 1 (see > > ps in previous email). All other CPUs are idle, and as seen from the ps > > quite a lot of threads are blocked in vnode related operations, either > > "*Name Cac", "*vnode_fr" or "*vnode in". I've also attached the output > > of alllocks in the previous email. > This is not useful. You need to look at the mutex which fails the > trylock operation in the mnt_vnode_next_active(), see who owns it, > and then 'unwind' the locking dependencies from there. > >>> Sorry, now I get it, let's see if I can find the locked vnodes and the > >>> thread that owns them... > >> You can use 'show lock v_interlock>' to find an owning > >> thread and then use 'show sleepchain '. If you are using kgdb on > >> the > >> live system (probably easier) then you can grab my scripts at > >> www.freebsd.org/~jhb/gdb/ (do 'cd /path/to/scripts; source gdb6'). You > >> can > >> then find the offending thread and do 'mtx_owner &vp->v_interlock' and then > >> 'sleepchain ' > I've been looking into this issue a little bit more, and the lock > dependencies look right to me, the lockup happens when the thread owning > the v_interlock mutex tries to acquire the vnode_free_list_mtx mutex > which is already owned by the syncer thread, at this point, the thread > owning the v_interlock mutex goes to sleep, and the syncer process will > start doing a sequence of: > VI_TRYLOCK -> mtx_unlock vnode_free_list_mtx -> kern_yield -> mtx_lock > vnode_free_list_mtx ... > It seems like kern_yield, which I assume is placed there in order to > allow the thread owning v_interlock to be able to also lock > vnode_free_list_mtx, doesn't get a window big enough to wake up the > waiting thread and get the vnode_free_list_mtx mutex. Since the syncer > is the only process runnable on the CPU there is no context switch, and > the syncer process continues to run. > Relying on kern_yield to provide a window big enough that allows any > other thread waiting on vnode_free_list_mtx to run doesn't seem like a > good idea on SMP systems. I've not tested this on bare metal, but waking > up an idle CPU in a virtualized environment might be more expensive than > doing it on bare metal. > Bear in mind that I'm not familiar with either the scheduler or the ufs > code, my proposed naive fix is to replace the kern_yield call with a > pause, that will allow any other threads waiting on vnode_free_list_mtx > to lock the vnode_free_list_mtx mutex and finish whatever they are doing > and release the v_interlock mutex, so the syncer thread can also finish > it's work. I've tested the patch for a couple of hours and seems to be > fine, I haven't been able to reproduce the issue anymore. Instead of a pause() that may be too short or too long, how about waiting for the necessary lock? In other words, replace the kern_yield() call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach to acquire two locks without imposing an order between them. I expect blocking on a mutex to be safe enough; a mutex may not be held across waiting for hardware or other events. > >From fec90f7bb9cdf05b49d11dbe4930d3c595c147f5 Mon Sep 17 00:00:00 2001 > From: Roger Pau Monne > Date: Sun, 26 May 2013 19:55:43 +0200 > Subject: [PATCH] mnt_vnode_next_active: replace kern_yield with pause > > On SMP systems there is no way to assure that a kern_yield will allow > any other threads waiting on the vnode_free_list_mtx to be able to > acquire it. The syncer process can get stuck in a loop trying to lock >
Re: HP 2570p installation
> On Sun, 26 May 2013 16:13:24 -0400 > g...@freebsd.org(Glen Barber) said: > > [[PGP Signed Part:No public key for 524F0C37A0B946A3 created at > 2013-05-26T22:13:24+0200 using RSA]] > On Sun, May 26, 2013 at 09:20:56PM +0200, Ludovit Koren wrote: > > > > I am sorry for the delay. > > > > Acutally, I did get your original reply. Sorry I did not repsond > sooner. > > > > > After Setting BIOS to legacy, with the 9.1-RELEASE-amd64-memstick.img, > > > > I succeeded to boot. The 10-CURRENT has still problems to boot to > > > > installation window. > > > > > > > > > > Where does it stop? The same place? > > > > > > > no. Before, it stopped right after beginning phase: bios control > > transfering to boot. Now, right before gtk? install phase. > > > > Are you able to see what is on the screen right before the installation > screen? FWIW, I did test this image, and was able to get to the initial > installation screen, and was able to get to the live cd. > > Can you also try pressing [CTRL][ALT][F4]? I think there is an > emergency TTY set up, same as with the 8.x images. > In 9.1, I can switch to the shell... > Also, what options do you have for the SATA controller on this machine? > Can you toggle between AHCI and ATA to see if you can get past this > hang? > when in ahci I cannot boot. If in the IDE, it stops in mountroot> lk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-HEAD gets stuck on vnode operations
On 26/05/13 22:20, Jilles Tjoelker wrote: > Instead of a pause() that may be too short or too long, how about > waiting for the necessary lock? In other words, replace the kern_yield() > call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach > to acquire two locks without imposing an order between them. Since there might be more than one locked vnode, waiting on a specific locked vnode seemed rather arbitrary, but I agree that the pause is also rather arbitrary. Also, can we be sure that the v_interlock mutex will not be destroyed while the syncer process is waiting for it to be unlocked? > I expect blocking on a mutex to be safe enough; a mutex may not be held > across waiting for hardware or other events. > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-HEAD gets stuck on vnode operations
On Sun, May 26, 2013 at 10:52:07PM +0200, Roger Pau Monné wrote: > On 26/05/13 22:20, Jilles Tjoelker wrote: > > Instead of a pause() that may be too short or too long, how about > > waiting for the necessary lock? In other words, replace the kern_yield() > > call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach > > to acquire two locks without imposing an order between them. > Since there might be more than one locked vnode, waiting on a specific > locked vnode seemed rather arbitrary, but I agree that the pause is also > rather arbitrary. > Also, can we be sure that the v_interlock mutex will not be destroyed > while the syncer process is waiting for it to be unlocked? I think this is a major problem. My idea was too easy and will not work. That said, the code in mnt_vnode_next_active() appears to implement some sort of adaptive spinning for SMP. It tries VI_TRYLOCK for 200ms (default value of hogticks) and then yields. This is far too long for a mutex lock and if it takes that long it means that either the thread owning the lock is blocked by us somehow or someone is abusing a mutex to work like a sleepable lock such as by spinning or DELAY. Given that it has been spinning for 200ms, it is not so bad to pause for one additional microsecond. The adaptive spinning was added fairly recently, so apparently it happens fairly frequently that VI_TRYLOCK fails transiently. Unfortunately, the real adaptive spinning code cannot be used because it will spin forever as long as the thread owning v_interlock is running, including when that is because it is spinning for vnode_free_list_mtx. Perhaps we can try to VI_TRYLOCK a certain number of times. It is also possible to check the contested bit of vnode_free_list_mtx (sys/netgraph/netflow/netflow.c does something similar) and stop spinning in that case. A cpu_spinwait() invocation should also be added to the spin loop. -- Jilles Tjoelker ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Building of libc in /usr/src/lib/libc results in error
Because the last message was over the limit, I will only post the end of file error here. building shared library libc.so.7 /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [libc.so.7] Error code 1 Stop in /usr/src/lib/libc. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
make: "/usr/ports/mail/postfix/Makefile" line 92: warning: Couldn't read shell's output ...
What's up with this? imb@toshi:/home/imb> sudo portupgrade -aR make: "/usr/ports/mail/postfix/Makefile" line 92: warning: Couldn't read shell's output for "/usr/bin/grep -m 1 '^purgestat' /etc/mail/mailer.conf || true" imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on ia64/ia64
TB --- 2013-05-26 23:02:01 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-26 23:02:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-26 23:02:01 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-05-26 23:02:02 - cleaning the object tree TB --- 2013-05-26 23:03:34 - /usr/local/bin/svn stat /src TB --- 2013-05-26 23:03:38 - At svn revision 251002 TB --- 2013-05-26 23:03:39 - building world TB --- 2013-05-26 23:03:39 - CROSS_BUILD_TESTING=YES TB --- 2013-05-26 23:03:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-26 23:03:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-26 23:03:39 - SRCCONF=/dev/null TB --- 2013-05-26 23:03:39 - TARGET=ia64 TB --- 2013-05-26 23:03:39 - TARGET_ARCH=ia64 TB --- 2013-05-26 23:03:39 - TZ=UTC TB --- 2013-05-26 23:03:39 - __MAKE_CONF=/dev/null TB --- 2013-05-26 23:03:39 - cd /src TB --- 2013-05-26 23:03:39 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun May 26 23:03:46 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon May 27 00:34:57 UTC 2013 TB --- 2013-05-27 00:34:57 - generating LINT kernel config TB --- 2013-05-27 00:34:57 - cd /src/sys/ia64/conf TB --- 2013-05-27 00:34:57 - /usr/bin/make -B LINT TB --- 2013-05-27 00:34:57 - cd /src/sys/ia64/conf TB --- 2013-05-27 00:34:57 - /usr/sbin/config -m LINT TB --- 2013-05-27 00:34:57 - building LINT kernel TB --- 2013-05-27 00:34:57 - CROSS_BUILD_TESTING=YES TB --- 2013-05-27 00:34:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-27 00:34:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-27 00:34:57 - SRCCONF=/dev/null TB --- 2013-05-27 00:34:57 - TARGET=ia64 TB --- 2013-05-27 00:34:57 - TARGET_ARCH=ia64 TB --- 2013-05-27 00:34:57 - TZ=UTC TB --- 2013-05-27 00:34:57 - __MAKE_CONF=/dev/null TB --- 2013-05-27 00:34:57 - cd /src TB --- 2013-05-27 00:34:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon May 27 00:34:57 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] *** Error code 1 Stop. make: stopped in /obj/ia64.ia64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-05-27 00:55:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-27 00:55:15 - ERROR: failed to build LINT kernel TB --- 2013-05-27 00:55:15 - 5435.63 user 884.82 system 6793.12 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-HEAD gets stuck on vnode operations
On Mon, May 27, 2013 at 12:22:54AM +0200, Jilles Tjoelker wrote: > On Sun, May 26, 2013 at 10:52:07PM +0200, Roger Pau Monn? wrote: > > On 26/05/13 22:20, Jilles Tjoelker wrote: > > > Instead of a pause() that may be too short or too long, how about > > > waiting for the necessary lock? In other words, replace the kern_yield() > > > call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach > > > to acquire two locks without imposing an order between them. > > > Since there might be more than one locked vnode, waiting on a specific > > locked vnode seemed rather arbitrary, but I agree that the pause is also > > rather arbitrary. > > > Also, can we be sure that the v_interlock mutex will not be destroyed > > while the syncer process is waiting for it to be unlocked? > > I think this is a major problem. My idea was too easy and will not work. > > That said, the code in mnt_vnode_next_active() appears to implement some > sort of adaptive spinning for SMP. It tries VI_TRYLOCK for 200ms > (default value of hogticks) and then yields. This is far too long for a > mutex lock and if it takes that long it means that either the thread > owning the lock is blocked by us somehow or someone is abusing a mutex > to work like a sleepable lock such as by spinning or DELAY. > > Given that it has been spinning for 200ms, it is not so bad to pause for > one additional microsecond. > > The adaptive spinning was added fairly recently, so apparently it > happens fairly frequently that VI_TRYLOCK fails transiently. > Unfortunately, the real adaptive spinning code cannot be used because it > will spin forever as long as the thread owning v_interlock is running, > including when that is because it is spinning for vnode_free_list_mtx. > Perhaps we can try to VI_TRYLOCK a certain number of times. It is also > possible to check the contested bit of vnode_free_list_mtx > (sys/netgraph/netflow/netflow.c does something similar) and stop > spinning in that case. > > A cpu_spinwait() invocation should also be added to the spin loop. There are two 'proper' solutions for this issue: One is to change the handling of the vnode lifecycle to allow the safe block for the vnode interlock acquisition. In particular, the change would add some stability of the vnode memory when vnode is put on the free list. As example, the vnode zone could be marked as type-stable again, and then the vnode interlock can be obtained with dropped free list lock. Arguably, marking the zone as non-freeable would be a regression, esp. for the zone which accounts for largest allocation on the kernel memory. Another one is to somehow ensure that the priority is properly propagated from the spinning thread to the vnode interlock owner. I think that it is desirable to donate some amount of priority from the spinning thread. Unfortunately, I was unable to come up with elegant solution for this which would be also contained and did not require rewamp of the mutex interfaces. BTW, if anybody come up with the idea of the restructuring the free list handling to avoid the free list/vnode interlock LOR altogether, it would be the best. I do not have objections against the pause() addition, but I would argue that should_yield() should be removed then, switching the code to unconditionally pause when the collision detected. pgpx2bUtXS6KF.pgp Description: PGP signature
Re: NAND Framework ONFI chip detection
From: Alexander Fedorov Date: 24 maja 2013 03:51:58 GMT-07:00 To: curr...@freebsd.org Subject: Re: [PATCH] NAND Framework ONFI chip detection Hi, current! I received a positive feedback from Grzegorz Bernacki (semihalf). He said that my patch is ok. Can anyone commit a proposed patch? Hi Alexander, I've just submitted your patch. Thanks for fixing it. regards, grzesiek ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
