| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
information that device is already suspended or that device is using
one-time key and suspend is not supported.
- 'geli suspend -a' silently skips devices that use one-time key, this is fine,
but because we log which device were suspended on the console, log also which
devices were skipped.
|
| |
|
|
|
|
|
|
|
| |
# geli status
Name Status Components
da0.eli SUSPENDED da0
da1.eli ACTIVE da1
|
|
|
|
| |
we don't panic when we detach suspended device.
|
|
|
|
|
| |
function which eliminates code duplication and will ensure proper order
of operation.
|
| |
|
|
|
|
| |
initializing it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this change if you wanted to suspend your laptop and be sure that your
encryption keys are safe, you had to stop all processes that use file system
stored on encrypted device, unmount the file system and detach geli provider.
This isn't very handy. If you are a lucky user of a laptop where suspend/resume
actually works with FreeBSD (I'm not!) you most likely want to suspend your
laptop, because you don't want to start everything over again when you turn
your laptop back on.
And this is where geli suspend/resume steps in. When you execute:
# geli suspend -a
geli will wait for all in-flight I/O requests, suspend new I/O requests, remove
all geli sensitive data from the kernel memory (like encryption keys) and will
wait for either 'geli resume' or 'geli detach'.
Now with no keys in memory you can suspend your laptop without stopping any
processes or unmounting any file systems.
When you resume your laptop you have to resume geli devices using 'geli resume'
command. You need to provide your passphrase, etc. again so the keys can be
restored and suspended I/O requests released.
Of course you need to remember that 'geli suspend' won't clear file system
cache and other places where data from your geli-encrypted file system might be
present. But to get rid of those stopping processes and unmounting file system
won't help either - you have to turn your laptop off. Be warned.
Also note, that suspending geli device which contains file system with geli
utility (or anything used by 'geli resume') is not very good idea, as you won't
be able to resume it - when you execute geli(8), the kernel will try to read it
and this read I/O request will be suspended.
|
|
|
|
| |
- Make a comment consistent with others.
|
|
|
|
|
|
|
|
|
|
| |
and print a diagnostic if the call fails.
This avoids a panic when a device with an invalid name is attempted to
be registered. For example the label class gets device names from
untrusted input.
Reviewed by: freebsd-geom
|
|
|
|
| |
("%s", __func__). This avoids clang's -Wformat-string warnings.
|
|
|
|
|
|
| |
Suggested by: kib
Approved by: kib (mentor)
MFC after: 5 days
|
|
|
|
|
| |
Submitted by: arundel
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
| |
GEOM does withering this memory doesn't freed. Add G_PART_DESTROY
call to g_part_wither. Also add missed g_free() call to G_PART_READ
method for MBR and PC98 schemes.
Submitted by: jh (previous version)
Reviewed by: pjd
Approved by: kib (mentor)
|
|
|
|
|
|
| |
kern.geom.eli.debug sysctl to -1.
MFC after: 2 weeks
|
|
|
|
|
|
| |
really killed. What we really care about are write errors only.
MFC after: 2 weeks
|
|
|
|
|
|
|
|
| |
attribute (it should be allowed only to unset it), but for test purposes it
might be useful, so the current code allows it.
Reviewed by: arch@ (Message-ID: <20100917234542.GE1902@garage.freebsd.pl>)
MFC after: 2 weeks
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
|
| |
This ensures the same encryption key won't be used for more than
2^20 blocks (sectors). This will be the default now.
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
| |
Reviewed by: pjd
|
|
|
|
| |
Dumping goes to the component, where dump partition begins.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
ada0 has <attrib> set
After:
<attrib> set on ada0
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
confusing.
Note there is still no information about 'partcode' being written to disk
(gpart bootcode -p <partcode> <disk>).
Maybe in the future all the messages printed by gpart(8) on success could be
hidden under -v?
PR: bin/150239
Reported by: Roddi <roddi@me.com>
Submitted by: arundel
MFC after: 2 weeks
|
|
|
|
|
| |
It turns out the new type wasn't really needed.
- Reorganize code a little bit.
|
| |
|
|
|
|
|
|
|
| |
understand everything correctly, we don't really need it.
- Provide default numeric value as strings. This allows to simplify
a lot of code.
- Bump version number.
|
|
|
|
| |
- Make optional string values always an empty string.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the BIO_ORDERED flag for struct bio and update bio clients to use it.
The barrier semantics of bioq_insert_tail() were broken in two ways:
o In bioq_disksort(), an added bio could be inserted at the head of
the queue, even when a barrier was present, if the sort key for
the new entry was less than that of the last queued barrier bio.
o The last_offset used to generate the sort key for newly queued bios
did not stay at the position of the barrier until either the
barrier was de-queued, or a new barrier (which updates last_offset)
was queued. When a barrier is in effect, we know that the disk
will pass through the barrier position just before the
"blocked bios" are released, so using the barrier's offset for
last_offset is the optimal choice.
sys/geom/sched/subr_disk.c:
sys/kern/subr_disk.c:
o Update last_offset in bioq_insert_tail().
o Only update last_offset in bioq_remove() if the removed bio is
at the head of the queue (typically due to a call via
bioq_takefirst()) and no barrier is active.
o In bioq_disksort(), if we have a barrier (insert_point is non-NULL),
set prev to the barrier and cur to it's next element. Now that
last_offset is kept at the barrier position, this change isn't
strictly necessary, but since we have to take a decision branch
anyway, it does avoid one, no-op, loop iteration in the while
loop that immediately follows.
o In bioq_disksort(), bypass the normal sort for bios with the
BIO_ORDERED attribute and instead insert them into the queue
with bioq_insert_tail(). bioq_insert_tail() not only gives
the desired command order during insertion, but also provides
barrier semantics so that commands disksorted in the future
cannot pass the just enqueued transaction.
sys/sys/bio.h:
Add BIO_ORDERED as bit 4 of the bio_flags field in struct bio.
sys/cam/ata/ata_da.c:
sys/cam/scsi/scsi_da.c
Use an ordered command for SCSI/ATA-NCQ commands issued in
response to bios with the BIO_ORDERED flag set.
sys/cam/scsi/scsi_da.c
Use an ordered tag when issuing a synchronize cache command.
Wrap some lines to 80 columns.
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
sys/geom/geom_io.c
Mark bios with the BIO_FLUSH command as BIO_ORDERED.
Sponsored by: Spectra Logic Corporation
MFC after: 1 month
|
|
|
|
|
|
|
|
| |
but because of a bug it was a no-op, so we were still using offsets in native
byte order for the host. Do it properly this time, bump version to 4 and set
the G_ELI_FLAG_NATIVE_BYTE_ORDER flag when version is under 4.
MFC after: 2 weeks
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
|
| |
for some cases.
Approved by: kib (mentor)
MFC after: 1 week
|
|
|
|
|
|
|
| |
for some cases.
Approved by: mav (mentor)
MFC after: 2 weeks
|
|
|
|
|
|
|
|
| |
PR: 148540
Silence from: luigi
Reviewed by: pjd
Approved by: mav (mentor)
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
| |
indirectly by orphan method.
PR: 148688
Silence from: marcel
Approved by: mav (mentor)
MFC after: 2 weeks
|
|
|
|
|
| |
GEOM. This information needed for proper soft-RAID's on-disk metadata
reading and writing.
|
|
|
|
|
|
|
|
|
| |
user deletes partition that not yet created (changes doesn't
committed to disk).
PR: 148687
Approved by: mav (mentor)
MFC after: 7 days
|
|
|
|
|
|
| |
PR: kern/144732
Submitted by: Eugene Grosbein
MFC after: 3 days
|
| |
|
|
|
|
|
|
| |
Found by: Coverity Prevent
CID: 3731
MFC after: 3 days
|
|
|
|
|
|
| |
data, so there is no need to copy it to userland.
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
| |
via %s
Most of the cases looked harmless, but this is done for the sake of
correctness. In one case it even allowed to drop an intermediate buffer.
Found by: clang
MFC after: 2 week
|
|
|
|
|
| |
Found with: Coverity Prevent
CID: 3566, 3567
|
|
|
|
|
| |
Obtained from: Jaako Heinonen
MFC after: 1 month
|
|
|
|
|
| |
Found with: Coverity Prevent
CID: 3411
|
|
|
|
|
| |
Reviewed by: marcel
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
in case glabel debug level is >= 1 and gp->provider list is empty
for some reason
Found by: clang static analyzer
MFC after: 4 days
|