headers
FreeBSD bugmaster | 4 Jun 2012 13:07
Picon
Favicon

Current problem reports assigned to freebsd-geom <at> FreeBSD.org

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/165745  geom       [geom] geom_multipath page fault on removed drive
o kern/165428  geom       [glabel][patch] Add xfs support to glabel
o kern/164254  geom       [geom] gjournal not stopping on GPT partitions
o kern/164252  geom       [geom] gjournal overflow
o kern/164143  geom       [geom] Partition table not recognized after upgrade R8
a kern/163020  geom       [geli] [patch] enable the Camellia-XTS on GEOM ELI
o kern/162010  geom       [geli] panic: Provider's error should be set (error=0)
o kern/161979  geom       [geom] glabel doesn't update after newfs, and glabel s
o kern/161752  geom       [geom] glabel(8) doesn't get gpt label change
o bin/161677   geom       gpart(8) Probably bug in gptboot
o kern/160562  geom       [geom][patch] Allow to insert new component to geom_ra
o kern/160409  geom       [geli] failed to attach provider
f kern/159595  geom       [geom] [panic] panic on gmirror unload in vbox [regres
p kern/158398  geom       [headers] [patch] <geom/geom.h> includes <sys/sbuf.h> 
o kern/158197  geom       [geom] geom_cache with size>1000 leads to panics
o kern/157879  geom       [libgeom] [regression] ABI change without version bump
o kern/157863  geom       [geli] kbdmux prevents geli passwords from being enter
o kern/157739  geom       [geom] GPT labels with geom_multipath
o kern/157724  geom       [geom] gpart(8) 'add' command must preserve gap for sc
o kern/157723  geom       [geom] GEOM should not process 'c' (raw) partitions fo
o kern/157108  geom       [gjournal] dumpon(8) fails on gjournal providers
(Continue reading)

Permalink | Reply | 0 comments |
headers
gavin | 5 Jun 2012 16:05
Picon
Favicon

Re: kern/165745: [geom] geom_multipath page fault on removed drive

Synopsis: [geom] geom_multipath page fault on removed drive

State-Changed-From-To: open->feedback
State-Changed-By: gavin
State-Changed-When: Tue Jun 5 14:02:24 UTC 2012
State-Changed-Why: 
To submitter: it sounds like this may be fixed - are you still able
to recreate the problem?

http://www.freebsd.org/cgi/query-pr.cgi?pr=165745
Permalink | Reply | 1 comment |
headers
Garrett Wollman | 5 Jun 2012 18:10
Picon
Picon
Favicon

Re: kern/165745: [geom] geom_multipath page fault on removed drive

The following reply was made to PR kern/165745; it has been noted by GNATS.

From: Garrett Wollman <wollman <at> csail.mit.edu>
To: gavin <at> FreeBSD.org
Cc: freebsd-gnats-submit <at> FreeBSD.org
Subject: Re: kern/165745: [geom] geom_multipath page fault on removed drive
Date: Tue, 5 Jun 2012 12:03:57 -0400

 <<On Tue, 5 Jun 2012 14:05:15 GMT, gavin <at> FreeBSD.org said:

 > To submitter: it sounds like this may be fixed - are you still able
 > to recreate the problem?

 I haven't had time to backport the new version to 9.0, nor to actually
 reboot the server we are testing to install a new kernel.  This will
 get done when I need to put the server into production, assuming 9.1
 isn't released by then.

 -GAWollman
Permalink | Reply | 0 comments |
headers
John W. O'Brien | 9 Jun 2012 22:57
Favicon
Gravatar

Scope and purpose of each kind geli key


Hello freebsd-geom <at> ,

I recently started using geli and found it necessary to read a bunch
of source code to supplement the manpages and Handbook sections. In
particular, there are several different kinds of keys (and sources of
key material), but they are not clearly differentiated in the docs. Of
course, one need not understand the entire geli architecture and
theory of operation in order to use it, but a bit more context would
make things easier.

So, the purpose of this inquiry is twofold: first, to sanity check
what I think I learned from my studies; second, to find out if others
would find it useful for me to take a swipe at integrating this
information into the docs.

Master Key
----------

There is exactly one Master Key per provider, and it never changes for
the life of the provider. It is generated in userland upon init (or
onetime) and the user can select the key length (-l).

Up to two, encrypted copies of the Master Key can be stored in the
provider metadata. Each copy is encrypted with a Key Encrypting Key
derived from a User Key.

Storage Key
-----------
(Continue reading)

Permalink | Reply | 8 comments |
headers
RW | 10 Jun 2012 01:36

Re: Scope and purpose of each kind geli key

On Sat, 09 Jun 2012 16:57:57 -0400
John W. O'Brien wrote:

> There is exactly one Master Key per provider, and it never changes for
> the life of the provider. It is generated in userland upon init (or
> onetime) and the user can select the key length (-l).

I think it's fixed at 512 bits and -l determines the key size of the
actual encryption algorithm.

> Storage Key per 2^20 blocks. A block's offset is used as an
> Initialization Vector (IV) when encrypting or decrypting its data with
> the applicable Storage Key.

I thought that the IV came from a hash that includes the offset, but
I'm not sure.

> 
> For my sake and the sake of future mailing list archaeologists, are
> there any errors or significant ambiguities in my description? Once
> I've addressed any problems, would this, or something like it, be a
> welcome addition to the manpage and/or the Handbook? 

IMO this is far too much information for the man page or handbook -
it might be turned into an article though. 

What I think is important is that the user understands that the actual
encryption derives from a fixed master key and there are two encrypted
copies of this, each encrypted with one of the user keys.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pawel Jakub Dawidek | 10 Jun 2012 10:13
Picon
Favicon

Re: Scope and purpose of each kind geli key

On Sat, Jun 09, 2012 at 04:57:57PM -0400, John W. O'Brien wrote:
> I recently started using geli and found it necessary to read a bunch
> of source code to supplement the manpages and Handbook sections. In
> particular, there are several different kinds of keys (and sources of
> key material), but they are not clearly differentiated in the docs. Of
> course, one need not understand the entire geli architecture and
> theory of operation in order to use it, but a bit more context would
> make things easier.
> 
> So, the purpose of this inquiry is twofold: first, to sanity check
> what I think I learned from my studies; second, to find out if others
> would find it useful for me to take a swipe at integrating this
> information into the docs.

I think this is great you decided to document it and I'll do my best to
help. I'd also like to see such description to be available easly and
I'd be happy to add it to GELI manual page or create dedicated manual
page with detailed documentation how it works.

> Master Key
> - ----------
> 
> There is exactly one Master Key per provider, and it never changes for
> the life of the provider. It is generated in userland upon init (or
> onetime) and the user can select the key length (-l).

The Master Key is always 1024 bits long (128 bytes).

We split it into two parts. First part (first 64 bytes) is called IV Key
and is used for IV generations when encryption algorithm is used in CBC
(Continue reading)

Permalink | Reply | 6 comments |
headers
FreeBSD bugmaster | 11 Jun 2012 13:07
Picon
Favicon

Current problem reports assigned to freebsd-geom <at> FreeBSD.org

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
f kern/165745  geom       [geom] geom_multipath page fault on removed drive
o kern/165428  geom       [glabel][patch] Add xfs support to glabel
o kern/164254  geom       [geom] gjournal not stopping on GPT partitions
o kern/164252  geom       [geom] gjournal overflow
o kern/164143  geom       [geom] Partition table not recognized after upgrade R8
a kern/163020  geom       [geli] [patch] enable the Camellia-XTS on GEOM ELI
o kern/162010  geom       [geli] panic: Provider's error should be set (error=0)
o kern/161979  geom       [geom] glabel doesn't update after newfs, and glabel s
o kern/161752  geom       [geom] glabel(8) doesn't get gpt label change
o bin/161677   geom       gpart(8) Probably bug in gptboot
o kern/160562  geom       [geom][patch] Allow to insert new component to geom_ra
o kern/160409  geom       [geli] failed to attach provider
f kern/159595  geom       [geom] [panic] panic on gmirror unload in vbox [regres
p kern/158398  geom       [headers] [patch] <geom/geom.h> includes <sys/sbuf.h> 
o kern/158197  geom       [geom] geom_cache with size>1000 leads to panics
o kern/157879  geom       [libgeom] [regression] ABI change without version bump
o kern/157863  geom       [geli] kbdmux prevents geli passwords from being enter
o kern/157739  geom       [geom] GPT labels with geom_multipath
o kern/157724  geom       [geom] gpart(8) 'add' command must preserve gap for sc
o kern/157723  geom       [geom] GEOM should not process 'c' (raw) partitions fo
o kern/157108  geom       [gjournal] dumpon(8) fails on gjournal providers
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven Haber | 11 Jun 2012 19:19

Geom / destroy_dev() deadlock

Hey FreeBSD devs,

I hope this is the right forum for this. I haven't used the FreeBSD
mailing lists before. I'm a relatively new hire at EMC Isilon. We are
using FreeBSD 7.0 as the basis for our scale-out NAS product line. We
are frequently hitting the deadlock described here:

http://lists.freebsd.org/pipermail/freebsd-geom/2010-February/003888.htm
l

The race is that destroy_dev() sleeps indefinitely waiting for thread
references to drop from a dev. In the case of geom, we hold the topology
lock the whole time we're in the dev layer. In devfs_open() and
devfs_close(), we take a ref on the dev before calling into to geom.

The proposed solution of destroy_dev_sched() makes sense to me. I am
trying to understand the necessity of Alexander Motin's additional
changes. destroy_dev_tq() holds the devmtx during the destroy and devfs
uses this lock to take refs before calling into geom. To me it seems we
should be able to protect the cdev with just the devmtx, provided
consumers of d_close(), d_open(), etc. ref and rel the dev
appropriately.

Steven Haber
Software Engineer, EMC Isilon
(206) 753-1526
Permalink | Reply | 7 comments |
headers
Konstantin Belousov | 11 Jun 2012 22:43
Picon

Re: Geom / destroy_dev() deadlock

On Mon, Jun 11, 2012 at 10:19:07AM -0700, Steven Haber wrote:
> Hey FreeBSD devs,
> 
> I hope this is the right forum for this. I haven't used the FreeBSD
> mailing lists before. I'm a relatively new hire at EMC Isilon. We are
> using FreeBSD 7.0 as the basis for our scale-out NAS product line. We
> are frequently hitting the deadlock described here:
> 
> http://lists.freebsd.org/pipermail/freebsd-geom/2010-February/003888.htm
> l
> 
> The race is that destroy_dev() sleeps indefinitely waiting for thread
> references to drop from a dev. In the case of geom, we hold the topology
> lock the whole time we're in the dev layer. In devfs_open() and
> devfs_close(), we take a ref on the dev before calling into to geom.
> 
> The proposed solution of destroy_dev_sched() makes sense to me. I am
> trying to understand the necessity of Alexander Motin's additional
> changes. destroy_dev_tq() holds the devmtx during the destroy and devfs
> uses this lock to take refs before calling into geom. To me it seems we
> should be able to protect the cdev with just the devmtx, provided
> consumers of d_close(), d_open(), etc. ref and rel the dev
> appropriately.
devmtx is mutex. If taken, then cdevsw methods would be unable to sleep.
Permalink | Reply | 6 comments |
headers
Steven Haber | 11 Jun 2012 23:15

RE: Geom / destroy_dev() deadlock

> On Mon, Jun 11, 2012 at 10:19:07AM -0700, Steven Haber wrote:
>> Hey FreeBSD devs,
>>  
>> I hope this is the right forum for this. I haven't used the FreeBSD
>> mailing lists before. I'm a relatively new hire at EMC Isilon. We are
>> using FreeBSD 7.0 as the basis for our scale-out NAS product line. We
>> are frequently hitting the deadlock described here:
>> 
>>
http://lists.freebsd.org/pipermail/freebsd-geom/2010-February/003888.htm
>> l
>> 
>> The race is that destroy_dev() sleeps indefinitely waiting for thread
>> references to drop from a dev. In the case of geom, we hold the
topology
>> lock the whole time we're in the dev layer. In devfs_open() and
>> devfs_close(), we take a ref on the dev before calling into to geom.
>> 
>> The proposed solution of destroy_dev_sched() makes sense to me. I am
>> trying to understand the necessity of Alexander Motin's additional
>> changes. destroy_dev_tq() holds the devmtx during the destroy and
devfs
>> uses this lock to take refs before calling into geom. To me it seems
we
>> should be able to protect the cdev with just the devmtx, provided
>> consumers of d_close(), d_open(), etc. ref and rel the dev
>> appropriately.

> From: Konstantin Belousov
> Sent: Monday, June 11, 2012 1:44 PM
(Continue reading)

Permalink | Reply | 5 comments |

Gmane