This reverts commit 1b788400bb.
It causes oopses when passed incorrect arguments and has a
design fault using IPIs with interrupts disabled.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Add a README that explains what the different example configs in the
ktest example directory are about.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
I used the snowball.conf in a live demo that demonstrated how to use
ktest.pl with a snowball ARM board. I've been asked to included that
config in the ktest repository.
Here it is.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Add the config that I use to test several archs. I downloaded several
cross compilers from:
http://kernel.org/pub/tools/crosstool/files/bin/x86_64/
and this config is an example to crosscompile several archs to make sure
that your changes do not break archs that you are not working on.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
I've been asked several times to provide more useful example configs for
ktest.pl, as the sample.conf is too complex (because it explains all
configs). This adds configs broken up by use case, and these configs are
based on actual configs that I use on a daily basis.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
If the file that OUTPUT_MIN_CONFIG exists then ktest.pl will prompt the
user and ask them if the OUTPUT_MIN_CONFIG should be used as the
starting point for make_min_config instead of MIN_CONFIG.
This is usually the case, and to allow the user to do so, which is
helpful if the user is creating different min configs based on tests,
and they know one is a superset of another test, they can set
USE_OUTPUT_MIN_CONFIG to one, which will prevent kest.pl from prompting
to use the OUTPUT_MIN_CONFIG and it will just use it.
If USE_OUTPUT_MIN_CONIFG is set to zero, then ktest.pl will continue to
use MIN_CONFIG instead.
The default is that USE_OUTPUT_MIN_CONFIG is undefined.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
It's already called if TIF_NOTIFY_RESUME is set, so we only
need to add the actual work. Note that checking for RESTORE_SIGMASK
was not needed - set_restore_sigmask() also sets SIGPENDING, so
we never RESTORE_SIGMASK without SIGPENDING.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
TIF_NOTIFY_RESUME added (as bit 5). That way nommu glue needs no changes at
all; mmu one needs just to replace jmi do_signal_return to jne do_signal_return
There we have flags shifted up, until bit 6 (SIGPENDING) is in MSBit; instead
of checking that MSBit is set (jmi) we check that MSBit or something below it
is set (jne); bits 0..4 are never set, so that's precisely "bit 6 or bit 5 is
set".
Usual handling of NOTIFY_RESUME/SIGPENDING is done in do_notify_resume(); glue
calls it instead of do_signal().
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
When using the MERAM the LCDC line size needs to be programmed with a
MERAM-specific value different than the real frame buffer pitch. Fix it.
Reported-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: stable@vger.kernel.org # for 3.4
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* move force_sigsegv() (from setup...frame()) and clearing RESTART_SIGMASK
(from do_signal()) into hanlde_signal()
* get rid of handle_signal() return value and oldset argument
* checking for TIF_SIGPENDING is enough; set_restart_sigmask() sets this
one as well.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
It's been a dead code since commit 571202f50f
Author: Michal Simek <monstr@monstr.eu>
Date: Fri Dec 11 12:54:04 2009 +0100
microblaze: Remove rt_sigsuspend wrapper
Generic rt_sigsuspend syscalls doesn't need any asm wrapper.
but that commit has only removed it from entry.S, missing one in entry-nommu.S.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
... and resetting sa_handler in local copy filled by get_signal_to_deliver()
is obviously pointless anyway.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Complete the move of sh64 to it, trim the crap from prototypes,
tidy up a bit. Infrastructure in do_signal() had already been
there, in signal_64 as well as in signal_32 (where it was already
used).
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Now that bitmaps can grow and shrink it is best if we record
how much space is available. This means that when
we reduce the size of the bitmap we won't "lose" the space
for late when we might want to increase the size of the bitmap
again.
Signed-off-by: NeilBrown <neilb@suse.de>
When a reshape which reduced the number of devices finishes
we must remove the extra devices.
So ensure that raid10_remove_disk won't try to keep them, and
have raid10_finish_reshape clear the 'in_sync' flag. Then
remove_and_add_spares will be able to remove them.
Reported-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: NeilBrown <neilb@suse.de>
After a reshape which reduced the number of devices we need
to disconnect the extra devices.
The code for this doesn't currently handle 'replacement' devices.
It is very unlikely that such devices will be present, but it is
safest to handle them anyway.
So simplify the handling. Just clear In_sync and leave it
to remove_and_add_spaces (which will be called soon) to do
the real works.
Signed-off-by: NeilBrown <neilb@suse.de>
Check the return of mddev_find(), since it may fail due to out of
memeory or out of usable minor number.
The reason I chose -ENODEV instead of -ENOMEM or something else is
md_alloc() function chose that ;)
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
A RAID1 device does not necessarily need a fullsync if the bitmap can be used instead.
Similar to commit d6b212f4b1 in raid5.c, if a raid1
device can be brought back (i.e. from a transient failure) it shouldn't need a
complete resync. Provided the bitmap is not to old, it will have recorded the areas
of the disk that need recovery.
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
When encountering an error while reading the superblock, call md_error.
We are currently setting the 'Faulty' bit on one of the array devices when an
error is encountered while reading the superblock of a dm-raid array. We should
be calling md_error(), as it handles the error more completely.
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Missing dm-raid devices should be recorded in the superblock
When specifying the devices that compose a DM RAID array, it is possible to denote
failed or missing devices with '-'s. When this occurs, we must record this in the
superblock. We do this by checking if the array position's data device is missing
and then forcing MD to record the superblock by setting 'MD_CHANGE_DEVS' in
'raid_resume'. If we do not cause the superblock to be rewritten by the resume
function, it is possible for a stale superblock to be written by an out-going
in-active table (during 'raid_dtr').
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Properly initialize MD recovery flags when resuming device-mapper devices.
When a device-mapper device is suspended, all I/O must stop. This is done by
calling 'md_stop_writes' and 'mddev_suspend'. These calls in-turn manipulate
the recovery flags - including setting 'MD_RECOVERY_FROZEN'. The DM device
may have been suspended while recovery was not yet complete, so the process
needs to pick-up where it left off. Since 'mddev_resume' does not unset
'MD_RECOVERY_FROZEN' and set 'MD_RECOVERY_NEEDED', we must do it ourselves.
'MD_RECOVERY_NEEDED' can safely be set in 'mddev_resume', but 'MD_RECOVERY_FROZEN'
must be set outside of 'mddev_resume' due to how MD handles RAID reshaping.
(e.g. It is possible for a user to delay reshaping a RAID5->RAID6 by purposefully
setting 'MD_RECOVERY_FROZEN'. Clearing it in 'mddev_resume' would override the
desired behavior.)
Because 'mddev_resume' already unconditionally calls 'md_wakeup_thread(mddev->thread)'
there is no need to make this call from 'raid_resume' since it calls 'mddev_resume'.
Also clean up where level_store calls mddev_resume() - it current
duplicates some of the funcitons of that call. - NB
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
We always should have allowed this. A raid5 reshape doesn't change
the size of the bitmap, so not need to restrict it.
Also add a test to make sure we don't try to start a reshape on a
failed array.
Signed-off-by: NeilBrown <neilb@suse.de>
Now that bitmaps can be resized, we can allow an array to be resized
while the bitmap is present.
This only covers resizing that involves changing the effective size
of member devices, not resizing that changes the number of devices.
Signed-off-by: NeilBrown <neilb@suse.de>
As a reshape may change the sync_size and/or chunk_size, we need
to update these whenever we write out the bitmap superblock.
Signed-off-by: NeilBrown <neilb@suse.de>
This function will allocate the new data structures and copy
bits across from old to new, allowing for the possibility that the
chunksize has changed.
Use the same function for performing the initial allocation
of the structures. This improves test coverage.
When bitmap_resize is used to resize an existing bitmap, it
only copies '1' bits in, not '0' bits.
So when allocating the bitmap, ensure everything is initialised
to ZERO.
Signed-off-by: NeilBrown <neilb@suse.de>
Benjamin Herrenschmidt
Anshuman Khandual
Steven Rostedt
Al Viro
Laurent Pinchart
NeilBrown
Yuanhan Liu
Jonathan Brassow