similar to: crash while fts searching a virtual folder

Hi, When searching in a virtual mailbox imap process crashes if the virtual mailbox has a lot of physical mailboxes behind (more than 80 - 100 mailboxes). Dovecot 2.2.18 build from sources ./configure --prefix=/opt/dovecot2 --with-mysql --with-sqlite --with-solr --with-ssl --disable-rpath --disable-static. Debian Wheezy 3.2.63-2 x86_64. Filesystem is ZFS. docecot -n : # 2.2.18:

Hi all, when I try to search in a virtual mailbox with FTS enabled,?imap cores dump. Sample IMAP session in a virtual mailbox: 1 OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT

Steps to reproduce: - Enable CLucene FTS in Dovecot; - Open mailbox with MUA; - Search for message with any text; - IMAP session crash. OS: Gentoo Base System release 2.6 Version: FTS: dev-cpp/clucene-2.3.3.4-r6 IMAP: net-mail/dovecot-2.3.2.1 LIBC: sys-libs/musl-1.1.21 Dovecot FTS config: plugin { fts = lucene fts_lucene = whitespace_chars=@. normalize no_snowball fts_autoindex=yes

Hi Devs, I experience reproducible crashes when searching in a virtual folder with fts-solr activated. The crashes occur only, if the folder contains a large number of mails and the result set of the search is also large. If the result set is small, no crash occurs. This happens on Debian Wheezy with versions 2.1.7 and 2.2.9. My goal was it to setup the possibility for cross-folder fulltext

From: Maarten Lankhorst <maarten.lankhorst at ubuntu.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/core/core/event.c | 4 drivers/gpu/drm/nouveau/nouveau_bo.c | 6 drivers/gpu/drm/nouveau/nouveau_display.c | 4 drivers/gpu/drm/nouveau/nouveau_fence.c | 434 ++++++++++++++++++++---------

My apologies if I'm posting the wrong place, or am asking a common question. All my looking so far hasn't turned up anything very useful in knowing what to look at, or what to modify. --- CentOS 5, running BIND 9.3.6 i386 Hardware: P4, 2.8Ghz, 1G memory Sata drives - non mirrored etc. Load is light, usually under 0.1 -- This box is running Postfix as our mail server. BIND (9.3.6)

From: Dave Airlie <airlied at redhat.com> fences are signalled on nvidia hw using non-stall interrupts. non-stall interrupts are not latched from my reading. When nouveau emits a fence, it requests a NON_STALL signalling, but it only calls the interface to allow the non-stall irq to happen after it has already emitted the fence. A recent change eacabb546271 ("nouveau: push event

From: Dave Airlie <airlied at redhat.com> This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue. Signed-off-by: Dave Airlie <airlied at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_fence.c | 24 ++++++++++++++++++------ drivers/gpu/drm/nouveau/nouveau_fence.h | 1 + 2 files changed, 19

On Tue, Jan 23, 2024 at 05:25:38PM +1000, Dave Airlie wrote: > From: Dave Airlie <airlied at redhat.com> > > fences are signalled on nvidia hw using non-stall interrupts. > > non-stall interrupts are not latched from my reading. > > When nouveau emits a fence, it requests a NON_STALL signalling, > but it only calls the interface to allow the non-stall irq to happen

Hi, i was searching in the source code, but i didn't find any MAX_MPX or something like that. How can i change MAX_MPX_REQUESTS that smbd can handle?

I just set up a CentOS 5.2 system with bind9 (9.3.4-6.0.1.P1.el5) and I'm running up against a problem that seems to be related to SELinux. If I set named_disable_trans to 1, everything works as expected, but if I leave it enabled the server will only give me data for the zones for which it is authoritative. For external sites it returns a ServFail error. This is with nslookup and dig. If I

Using the kernel global workqueue to signal fences can lead to unexpected deadlocks. Some other work (e.g. from a different driver) could directly or indirectly depend on this fence to be signaled. However, if the WQ_MAX_ACTIVE limit is reached by waiters, this can prevent the work signaling the fence from running. While this seems fairly unlikely, it's potentially exploitable. Fixes:

On Fri, Feb 23, 2024 at 10:14:53AM +1000, Dave Airlie wrote: > On Fri, 23 Feb 2024 at 00:45, Danilo Krummrich <dakr at redhat.com> wrote: > > > > Using the kernel global workqueue to signal fences can lead to > > unexpected deadlocks. Some other work (e.g. from a different driver) > > could directly or indirectly depend on this fence to be signaled. > >

On 09/22/2014 03:08 AM, Maarten Lankhorst wrote: > This fixes a regression introduced by "drm/nouveau: rework to new fence interface" > (commit 29ba89b2371d466). > > The fence sequence should not be reset after creation, the old value is used instead. > On destruction the final value is written, to prevent another source of accidental > wraparound in case of a channel

On Tue, Sep 23, 2014 at 2:23 AM, Ted Percival <ted at tedp.id.au> wrote: > On 09/22/2014 03:08 AM, Maarten Lankhorst wrote: >> This fixes a regression introduced by "drm/nouveau: rework to new fence interface" >> (commit 29ba89b2371d466). >> >> The fence sequence should not be reset after creation, the old value is used instead. >> On destruction

On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > This increases the chance slightly that recovery from lockup can happen > succesfully. I'd *really* love to see proof of this. When channels die, all outstanding fences are marked as signalled. This should do absolutely nothing... > > Signed-off-by: Maarten Lankhorst

I am a little unsure about the change in nouveau_fence, maybe somebody with more knowledge about the code can look into it? Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- drm/nouveau/dispnv04/arb.c | 6 ++---- drm/nouveau/nouveau_fence.c | 2 -- drm/nouveau/nvkm/subdev/fb/ramgk104.c | 4 +--- 3 files changed, 3 insertions(+), 9 deletions(-) diff --git

Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/nouveau/nouveau_fence.c: In function 'nouveau_fence_wait_uevent_handler': drivers/gpu/drm/nouveau/nouveau_fence.c:156:27: warning: variable 'chan' set but not used [-Wunused-but-set-variable] nouveau_fence_update should use rcu protected 'chan' rather than 'fence->channel' Fixes:

Like other cases, it should use rcu protected 'chan' rather than 'fence->channel' in nouveau_fence_wait_uevent_handler. Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and protect with rcu") Signed-off-by: YueHaibing <yuehaibing at huawei.com> --- drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +- 1 file changed, 1 insertion(+), 1

From: YueHaibing <yuehaibing at huawei.com> [ Upstream commit 1eb013473bff5f95b6fe1ca4dd7deda47257b9c2 ] Like other cases, it should use rcu protected 'chan' rather than 'fence->channel' in nouveau_fence_wait_uevent_handler. Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and protect with rcu") Signed-off-by: YueHaibing