- 15 Aug, 2007 20 commits
-
-
Thomas Gleixner authored
The return value of futex_find_get_task() needs to be -ESRCH in case that the search fails. This was part of the original futex fixes and got accidentally dropped, when the futex-tidy-up patch was split out. Results in a NULL pointer dereference in case the search fails. Restore it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ulrich Drepper <drepper@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Christoph Lameter authored
Fix massive SMP imbalance on NUMA nodes observed on 2.6.21.5 with CFS. (and later on reproduced without CFS as well). The intervals of domains that do not have SD_BALANCE_NEWIDLE must be considered for the calculation of the time of the next balance. Otherwise we may defer rebalancing forever and nodes might stay idle for very long times. Siddha also spotted that the conversion of the balance interval to jiffies is missing. Fix that to. From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> also continue the loop if !(sd->flags & SD_LOAD_BALANCE). Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> It did in fact trigger under all three of mainline, CFS, and -rt including CFS -- see below for a couple of emails from last Friday giving results for these three on the AMD box (where it happened) and on a single-quad NUMA-Q system (where it did not, at least not with such severity). Signed-off-by: Christoph Lameter <clameter@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Olaf Kirch authored
Get rid of first_clone in dm-crypt This gets rid of first_clone, which is not really needed. Apparently, cloned bios used to share their bvec some time way in the past - this is no longer the case. Contrarily, this even hurts us if we try to create a clone off first_clone after it has completed, and crypt_endio has destroyed its bvec. Signed-off-by: Olaf Kirch <olaf.kirch@oracle.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Olaf Kirch authored
Do not access the bio after generic_make_request We should never access a bio after generic_make_request - there's no guarantee it still exists. Signed-off-by: Olaf Kirch <olaf.kirch@oracle.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Olaf Kirch authored
Call clone_init early We need to call clone_init as early as possible - at least before call bio_put(clone) in any error path. Otherwise, the destructor will try to dereference bi_private, which may still be NULL. Signed-off-by: Olaf Kirch <olaf.kirch@oracle.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Milan Broz authored
Disable barriers in dm-crypt because of current workqueue processing can reorder requests. This must be addresed later but for now disabling barriers is needed to prevent data corruption. Signed-off-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Mike Accetta authored
If raid1/repair (which reads all block and fixes any differences it finds) hits a read error, it doesn't reset the bio for writing before writing correct data back, so the read error isn't fixed, and the device probably gets a zero-length write which it might complain about. Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
NeilBrown authored
1/ When resyncing a degraded raid10 which has more than 2 copies of each block, garbage can get synced on top of good data. 2/ We round the wrong way in part of the device size calculation, which can cause confusion. Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Alexey Kuznetsov authored
1. New entries can be added to tsk->pi_state_list after task completed exit_pi_state_list(). The result is memory leakage and deadlocks. 2. handle_mm_fault() is called under spinlock. The result is obvious. 3. results in self-inflicted deadlock inside glibc. Sometimes futex_lock_pi returns -ESRCH, when it is not expected and glibc enters to for(;;) sleep() to simulate deadlock. This problem is quite obvious and I think the patch is right. Though it looks like each "if" in futex_lock_pi() got some stupid special case "else if". :-) 4. sometimes futex_lock_pi() returns -EDEADLK, when nobody has the lock. The reason is also obvious (see comment in the patch), but correct fix is far beyond my comprehension. I guess someone already saw this, the chunk: if (rt_mutex_trylock(&q.pi_state->pi_mutex)) ret = 0; is obviously from the same opera. But it does not work, because the rtmutex is really taken at this point: wake_futex_pi() of previous owner reassigned it to us. My fix works. But it looks very stupid. I would think about removal of shift of ownership in wake_futex_pi() and making all the work in context of process taking lock. From: Thomas Gleixner <tglx@linutronix.de> Fix 1) Avoid the tasklist lock variant of the exit race fix by adding an additional state transition to the exit code. This fixes also the issue, when a task with recursive segfaults is not able to release the futexes. Fix 2) Cleanup the lookup_pi_state() failure path and solve the -ESRCH problem finally. Fix 3) Solve the fixup_pi_state_owner() problem which needs to do the fixup in the lock protected section by using the in_atomic userspace access functions. This removes also the ugly lock drop / unqueue inside of fixup_pi_state() Fix 4) Fix a stale lock in the error path of futex_wake_pi() Added some error checks for verification. The -EDEADLK problem is solved by the rtmutex fixups. Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Thomas Gleixner authored
Alexey Kuznetsov found some problems in the pi-futex code. One of the root causes is: When a wakeup happens, we do not to stop the chain walk so we we follow a non existing locking chain. Drop out when this happens. Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Thomas Gleixner authored
Alexey Kuznetsov found some problems in the pi-futex code. The major problem is a stale return value in rt_mutex_slowlock(): When the pi chain walk returns -EDEADLK, but the waiter was woken up during the phases where the locks were dropped, the rtmutex could be acquired, but due to the stale return value -EDEADLK returned to the caller. Reset the return value in the woken up path. Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Bob Picco authored
We aren't sampling for holes in memory. Thus we encounter a section hole with empty section map pointer for SPARSEMEM and OOPs for show_mem. This issue has been seen in 2.6.21, current git and current mm. This patch is for 2.6.21 stable. It was tested against sparsemem. Previous to commit f0a5a58a memory_present was called for node_start_pfn to node_end_pfn. This would cover the hole(s) with reserved pages and valid sections. Most SPARSEMEM supported arches do a pfn_valid check in show_mem before computing the page structure address. This issue was brought to my attention on IRC by Arnaldo Carvalho de Melo at acme@redhat.com. Thanks to Arnaldo for testing. Signed-off-by: Bob Picco <bob.picco@hp.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Zou Nan hai authored
On systems with huge amount of physical memory, VFS cache and memory memmap may eat all available system memory under 4G, then the system may fail to allocate swiotlb bounce buffer. There was a fix for this issue in arch/x86_64/mm/numa.c, but that fix dose not cover sparsemem model. This patch add fix to sparsemem model by first try to allocate memmap above 4G. Signed-off-by: Zou Nan hai <nanhai.zou@intel.com> Acked-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Andi Kleen <ak@suse.de> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [chrisw: trivial backport] Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jason Gaston authored
This patch updates the Intel ICH9M LPC Controller DID's, due to a specification change. Signed-off-by: Jason Gaston <jason.d.gaston@intel.com> Cc: <stable@kernel.org> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Auke Kok authored
To assure the symmetry of poll enable/disable in up/down, we should initialize the netdevice to be poll_disabled at load time. Doing this after register_netdevice leaves us open to another race, so lets move all the netif_* calls above register_netdevice so the stack starts out how we expect it to be. Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Doug Chapman <doug.chapman@hp.com> Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Slaby authored
An omitted unlock. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Oleg Nesterov authored
It is a known fact that freezeable multithreaded workqueues doesn't like CPU_DEAD. We keep them only for the incoming CPU-hotplug rework. Sadly, we can't just kill create_freezeable_workqueue() right now, make them singlethread. Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Gautham R Shenoy <ego@in.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
NeilBrown authored
It is possible that real data or metadata follows the bitmap without full page alignment. So limit the last write to be only the required number of bytes, rounded up to the hard sector size of the device. Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
NeilBrown authored
If a raid0 has a component device larger than 4TB, and is accessed on a 32bit machines, then as 'chunk' is unsigned lock, chunk << chunksize_bits can overflow (this can be as high as the size of the device in KB). chunk itself will not overflow (without triggering a BUG). So change 'chunk' to be 'sector_t, and get rid of the 'BUG' as it becomes impossible to hit. Cc: "Jeff Zheng" <Jeff.Zheng@endace.com> Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Andi Kleen authored
Only try to allocate MSRs once instead of for every CPU. This assumes the MSRs are the same on all CPUs which is currently true. P4-HT is a special case for different SMT threads, but the code always saves/restores all MSRs so it works identical. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
- 07 Jul, 2007 2 commits
-
-
Greg Kroah-Hartman authored
-
Jing Min Zhao authored
[NETFILTER]: nf_conntrack_h323: add checking of out-of-range on choices' index values Choices' index values may be out of range while still encoded in the fixed length bit-field. This bug may cause access to undefined types (NULL pointers) and thus crashes (Reported by Zhongling Wen). This patch also adds checking of decode flag when decoding SEQUENCEs. Signed-off-by: Jing Min Zhao <zhaojingmin@vivecode.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
- 11 Jun, 2007 18 commits
-
-
Chris Wright authored
-
Roland Scheidegger authored
The i8042 driver fails detection of the AUX port with some chips, because they apparently do not change the I8042_CTR_AUXDIS bit immediately. This is known to affect at least HP500/HP510 notebooks, consequently the built-in touchpad will not work. The patch will simply reread the value until it gets the expected value or a retry limit is hit, without touching other workaround code in the same area. Signed-off-by: Roland Scheidegger <sroland@tungstengraphics.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
David Miller authored
Handle arbitrary base and length values as long as they are multiples of IO_PAGE_SIZE. Bug found by Arun Kumar Rao. Signed-off-by: David S. Miller <davem@davemloft.net> [chrisw: backport to 2.6.20] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-
YOSHIFUJI Hideaki authored
We do not need to handle ::/0 routes specially any longer. This should fix BUG #8349. Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Acked-by: Yuji Sekiya <sekiya@wide.ad.jp> Signed-off-by: David S. Miller <davem@davemloft.net> [chrisw: backport to 2.6.20] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-
David Miller authored
This combines two upstream commits to fix an OOPS with AF_UNIX and SELINUX. basically, sk->sk_socket can become null because we access a peer socket without any locking, so it can be shut down and released in another thread. Commit: d410b81b4eef2e4409f9c38ef201253fbbcc7d94 [AF_UNIX]: Make socket locking much less confusing. The unix_state_*() locking macros imply that there is some rwlock kind of thing going on, but the implementation is actually a spinlock which makes the code more confusing than it needs to be. So use plain unix_state_lock and unix_state_unlock. Signed-off-by: David S. Miller <davem@davemloft.net> Commit: 19fec3e807a487415e77113cb9dbdaa2da739836 [AF_UNIX]: Fix datagram connect race causing an OOPS. Based upon an excellent bug report and initial patch by Frederik Deweerdt. The UNIX datagram connect code blindly dereferences other->sk_socket via the call down to the security_unix_may_send() function. Without locking 'other' that pointer can go NULL via unix_release_sock() which does sock_orphan() which also marks the socket SOCK_DEAD. So we have to lock both 'sk' and 'other' yet avoid all kinds of potential deadlocks (connect to self is OK for datagram sockets and it is possible for two datagram sockets to perform a simultaneous connect to each other). So what we do is have a "double lock" function similar to how we handle this situation in other areas of the kernel. We take the lock of the socket pointer with the smallest address first in order to avoid ABBA style deadlocks. Once we have them both locked, we check to see if SOCK_DEAD is set for 'other' and if so, drop everything and retry the lookup. Signed-off-by: David S. Miller <davem@davemloft.net> [chrisw: backport to 2.6.20] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-
Stephen Hemminger authored
Kenji Kaneshige found this race between device removal and registration. On unregister it is possible for the old device to exist, because sysfs file is still open. A new device with 'eth%d' will select the same name, but sysfs kobject register will fial. The following changes the shutdown order slightly. It hold a removes the sysfs entries earlier (on unregister_netdevice), but holds a kobject reference. Then when todo runs the actual last put free happens. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net> [chrisw: backport to 2.6.20] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-
Mark Glines authored
This diff changes the default port range used for outgoing connections, from "use 32768-61000 in most cases, but use N-4999 on small boxes (where N is a multiple of 1024, depending on just *how* small the box is)" to just "use 32768-61000 in all cases". I don't believe there are any drawbacks to this change, and it keeps outgoing connection ports farther away from the mess of IANA-registered ports. Signed-off-by: Mark Glines <mark@glines.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-
David Miller authored
It was using an immediate _PAGE_EXEC_4U value in an 'and' instruction to perform the test. This doesn't work because the immediate field is signed 13-bit, this the mask being tested against the PTE was 0x1000 sign-extended to 32-bits instead of just plain 0x1000. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-
David Miller authored
1) The TSB lookup was not using the correct hash mask. 2) It was not aligned on a boundary equal to it's size, which is required by the sun4v Hypervisor. wasn't having it's return value checked, and that bug will be fixed up as well in a subsequent changeset. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-
Vasily Averin authored
sys_setsockopt() do not check properly timeout values for SO_RCVTIMEO/SO_SNDTIMEO, for example it's possible to set negative timeout values. POSIX do not defines behaviour for sys_setsockopt in case negative timeouts, but requires that setsockopt() shall fail with -EDOM if the send and receive timeout values are too big to fit into the timeout fields in the socket structure. In current implementation negative timeout can lead to error messages like "schedule_timeout: wrong timeout value". Proposed patch: - checks tv_usec and returns -EDOM if it is wrong - do not allows to set negative timeout values (sets 0 instead) and outputs ratelimited information message about such attempts. Signed-off-By: Vasily Averin <vvs@sw.ru> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-
Jan Engelhardt authored
The Linux kernel ignored the PROM's serial settings (115200,n,8,1 in my case). This was because mode_prop remained "ttyX-mode" (expected: "ttya-mode") due to the constness of string literals when used with "char *". Since there is no "ttyX-mode" property in the PROM, Linux always used the default 9600. [ Investigation of the suncore.s assembler reveals that gcc optimizied away the stores, yet did not emit a warning, which is a pretty anti-social thing to do and is the only reason this bug lived for so long -DaveM ] Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-
Dave Jones authored
As mentioned in http://bugzilla.kernel.org/show_bug.cgi?id=5015 The helptext implies that this is on by default. This may be true on some distros (Fedora/RHEL have it enabled in /etc/sysctl.conf), but the kernel defaults to it off. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-
David Miller authored
Noticed by Matvejchikov Ilya. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-
Kazunori MIYAZAWA authored
Signed-off-by: Kazunori MIYAZAWA <kazunori@miyazawa.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-
Jerome Borsboom authored
in4_pton converts a textual representation of an ip4 address into an integer representation. However, when the textual representation is of in the form ip:port, e.g. 192.168.1.1:5060, and 'delim' is set to -1, the function bails out with an error when reading the colon. It makes sense to allow the colon as a delimiting character without explicitly having to set it through the 'delim' variable as there can be no ambiguity in the point where the ip address is completely parsed. This function is indeed called from nf_conntrack_sip.c in this way to parse textual ip:port combinations which fails due to the reason stated above. Signed-off-by: Jerome Borsboom <j.borsboom@erasmusmc.nl> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-
David Miller authored
Currently when icmp_errors_use_inbound_ifaddr is set and an ICMP error is sent after the packet passed through ip_output(), an address from the outgoing interface is chosen as ICMP source address since skb->dev doesn't point to the incoming interface anymore. Fix this by doing an interface lookup on rt->dst.iif and using that device. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-
Andrew Morton authored
Local variable `i' is a byte-counter. Don't use it as an index into an array of le32's. Reported-by: "young dave" <hidave.darkstar@gmail.com> Cc: "Christoph Lameter" <clameter@sgi.com> Acked-by: Anton Altaparmakov <aia21@cantab.net> Cc: <stable@kernel.org> Cc: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-
Andy Green authored
build scripts: fixdep blows segfault on string CONFIG_MODULE seen The string "CONFIG_MODULE" appearing anywhere in a source file causes fixdep to segfault. This string appeared in the wild in the current mISDN sources (I think they meant CONFIG_MODULES). But it shouldn't segfault (esp as CONFIG_MODULE appeared in a quoted string). Signed-off-by: Andy Green <andy@warmcat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
-