From Newsgroup: news.software.nntp

Running into an issue with an article that causes the server to throttle and record the following:

Jul 22 12:58:01.826 - 192.168.1.110 <20220707140258.GA3492673@roeck-us.net>
403 Can't store article
Jul 22 12:58:01.826 - 192.168.1.110 <sIBxK.434012$zgr9.35372@fx13.iad> no matching entry in storage.conf storing article -- throttling

The article's Newsgroups header is ridiculously long, but it got stored fine
on the original server and I'm running snapshots of 2.8.0 on both with a
pretty identical configuration. Unsure why it won't store on the destination server?

storage.conf is basic as can be:

method cnfs {
newsgroups: *
class: 0
options: TEXT
}
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

Il 22/07/2026 20:17, Jesse Rehmer ha scritto:

Running into an issue with an article that causes the server to throttle and record the following:

i run on same trouble some time ago. The problem is the other header of
that article. I never understand that, but same article without that
header accepted fine. Same thing: newsgroups: header too long, I removed
the follow header, and the article was accepted.

NG header too long threat the next header as part of ng part?
--
Ivo Gandolfo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

On Jul 22, 2026 at 1:27:46rC>PM CDT, "Ivo Gandolfo" <usenet@bofh.team> wrote:

Il 22/07/2026 20:17, Jesse Rehmer ha scritto:

Running into an issue with an article that causes the server to throttle and >> record the following:

i run on same trouble some time ago. The problem is the other header of
that article. I never understand that, but same article without that
header accepted fine. Same thing: newsgroups: header too long, I removed
the follow header, and the article was accepted.

NG header too long threat the next header as part of ng part?

It seems to be some weird issue with having icdsynccount raised very high. I had it set at 15000, but if I lower it to 1000, and reinsert the storage
tokens in the batch, the articles are accepted.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

On 7/22/26 11:17, Jesse Rehmer wrote:

Running into an issue with an article that causes the server to throttle and record the following:

Jul 22 12:58:01.826 - 192.168.1.110 <20220707140258.GA3492673@roeck-us.net> 403 Can't store article
Jul 22 12:58:01.826 - 192.168.1.110 <sIBxK.434012$zgr9.35372@fx13.iad> no matching entry in storage.conf storing article -- throttling

Can you paste the headers for these here in a body?

The article's Newsgroups header is ridiculously long, but it got stored fine on the original server and I'm running snapshots of 2.8.0 on both with a pretty identical configuration. Unsure why it won't store on the destination server?

storage.conf is basic as can be:

method cnfs {
newsgroups: *
class: 0
options: TEXT
}

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

On 7/22/26 11:40, Jesse Rehmer wrote:

On Jul 22, 2026 at 1:27:46rC>PM CDT, "Ivo Gandolfo" <usenet@bofh.team> wrote:

Il 22/07/2026 20:17, Jesse Rehmer ha scritto:

Running into an issue with an article that causes the server to throttle and
record the following:

i run on same trouble some time ago. The problem is the other header of
that article. I never understand that, but same article without that
header accepted fine. Same thing: newsgroups: header too long, I removed
the follow header, and the article was accepted.

NG header too long threat the next header as part of ng part?

It seems to be some weird issue with having icdsynccount raised very high. I had it set at 15000, but if I lower it to 1000, and reinsert the storage tokens in the batch, the articles are accepted.

Not sure if it is reproducible but can you try https://github.com/InterNetNews/inn/pull/369

The icdsynccount was either moving something around enough to cause the
pain, or even purely coincidental, if this is the right fix.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

On Jul 23, 2026 at 4:44:52rC>AM CDT, "Kevin Bowling" <kevin.bowling@kev009.com> wrote:

On 7/22/26 11:40, Jesse Rehmer wrote:

On Jul 22, 2026 at 1:27:46rC>PM CDT, "Ivo Gandolfo" <usenet@bofh.team> wrote:

Il 22/07/2026 20:17, Jesse Rehmer ha scritto:

Running into an issue with an article that causes the server to throttle and
record the following:

i run on same trouble some time ago. The problem is the other header of
that article. I never understand that, but same article without that
header accepted fine. Same thing: newsgroups: header too long, I removed >>> the follow header, and the article was accepted.

NG header too long threat the next header as part of ng part?

It seems to be some weird issue with having icdsynccount raised very high. I >> had it set at 15000, but if I lower it to 1000, and reinsert the storage
tokens in the batch, the articles are accepted.

Not sure if it is reproducible but can you try https://github.com/InterNetNews/inn/pull/369

The icdsynccount was either moving something around enough to cause the
pain, or even purely coincidental, if this is the right fix.

It was reproducible before I got around it by lowering icdsynccount, though I had the same settings on the origin server and didn't run into the issue
there. Will get a new box setup over the weekend and try to reproduce without and with the patch.

Here are the headers from one of the articles:

Message-ID: <62c683a2.g1VSVt6BrQC6ZzOz%lkp@intel.com>
Subject: [linux-next:master] BUILD REGRESSION 088b9c375534d905a4d337c78db3b3bfbb52c4a0
Date: Thu, 07 Jul 2022 14:56:34 +0800
From: kernel test robot <lkp@intel.com>
Path: illumos!news.pugleaf.net!.TX!i2pn2.pugleaf.net!archive.newsdeef.eu!apf9.newsd eef.eu!nntp.lore.kernel.org!not-for-mail
Return-Path: <ath11k-bounces+ath11k=archiver.kernel.org@lists.infradead.org> X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133])
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
Received: from localhost ([::1] helo=bombadil.infradead.org)
Received: from mga07.intel.com ([134.134.136.100])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
t=1657177068; x=1688713068;
h=date:from:to:cc:subject:message-id:mime-version:
content-transfer-encoding;
bh=hUaxS4FbU98cO1hd7qPjY6PMv7SAZrQrjnJcWkGCO9c=;
b=ne7IEPFWkXJ2+LSU81rwzlEet/vFLHwf0eKBd3Nl+A0Gled+NBG6SrOz
KlGaJYwXghZeD+b5H0yeKaO7xTdxDMFBbBkomaYSm05lP9XBzm4IAQSAV
eRp74mUmocQ8fc9v/5B/Bsh9duWyhP9JN8GZR5Xh/drbGMhLRj1I+DOOC
O10s0bwKAa5fpJLQBFVixdzI/WOPCtmH/B+Nf4WvPbBsNqBPaLprIeKd/
HJW6xqYkstOgTdHRkRN6jc+e8os0NsVssw+upT85O++GL001x0teqcjNs
Ao1yUZ1L3hUm4BYThlZcVx0eoEdkKqIcEK5Mk4z6HX7qwM110/zI3ZWH5
g==;
X-IronPort-AV: E=McAfee;i="6400,9594,10400"; a="347932685"
X-IronPort-AV: E=Sophos;i="5.92,252,1650956400";
d="scan'208";a="347932685"
Received: from fmsmga008.fm.intel.com ([10.253.24.58])
X-IronPort-AV: E=Sophos;i="5.92,252,1650956400";
d="scan'208";a="651007648"
Received: from lkp-server01.sh.intel.com (HELO 68b931ab7ac1) ([10.239.97.150])
Received: from kbuild by 68b931ab7ac1 with local (Exim 4.95)
To: Andrew Morton <akpm@linux-foundation.org>
Cc: virtualization@lists.linux-foundation.org,
usbb2k-api-dev@nongnu.org, tipc-discussion@lists.sourceforge.net,
target-devel@vger.kernel.org, sound-open-firmware@alsa-project.org,
samba-technical@lists.samba.org, rds-devel@oss.oracle.com,
patches@opensource.cirrus.com, osmocom-net-gprs@lists.osmocom.org,
openipmi-developer@lists.sourceforge.net, nvdimm@lists.linux.dev,
ntb@lists.linux.dev, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, mjpeg-users@lists.sourceforge.net,
megaraidlinux.pdl@broadcom.com, linuxppc-dev@lists.ozlabs.org,
linux1394-devel@lists.sourceforge.net, linux-x25@vger.kernel.org,
linux-wpan@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-watchdog@vger.kernel.org, linux-usb@vger.kernel.org,
linux-unionfs@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-staging@lists.linux.dev, linux-serial@vger.kernel.org,
linux-sctp@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-samsung-soc@vger.kernel.org, linux-rockchip@lists.infradead.org,
linux-renesas-soc@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-raid@vger.kernel.org, linux-pm@vger.kernel.org,
linux-phy@lists.infradead.org, linux-perf-users@vger.kernel.org,
linux-pci@vger.kernel.org, linux-parport@lists.infradead.org,
linux-parisc@vger.kernel.org, linux-omap@vger.kernel.org,
linux-nfc@lists.01.org, linux-mtd@lists.infradead.org,
linux-mmc@vger.kernel.org, linux-mm@kvack.org,
linux-mediatek@lists.infradead.org, linux-media@vger.kernel.org,
linux-leds@vger.kernel.org, linux-integrity@vger.kernel.org,
linux-input@vger.kernel.org, linux-iio@vger.kernel.org,
linux-ide@vger.kernel.org, linux-hwmon@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-fpga@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-efi@vger.kernel.org, linux-doc@vger.kernel.org,
linux-cxl@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-clk@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-amlogic@lists.infradead.org, linaro-mm-sig@lists.linaro.org,
legousb-devel@lists.sourceforge.net, kvm@vger.kernel.org,
keyrings@vger.kernel.org, isdn4linux@listserv.isdn4linux.de,
iommu@lists.linux.dev, iommu@lists.linux-foundation.org,
intel-wired-lan@lists.osuosl.org, greybus-dev@lists.linaro.org,
dri-devel@lists.freedesktop.org, dm-devel@redhat.com,
devicetree@vger.kernel.org, dev@openvswitch.org, dccp@vger.kernel.org,
damon@lists.linux.dev, coreteam@netfilter.org, cgroups@vger.kernel.org,
ceph-devel@vger.kernel.org, ath11k@lists.infradead.org,
apparmor@lists.ubuntu.com, amd-gfx@lists.freedesktop.org,
alsa-devel@alsa-project.org,
accessrunner-general@lists.sourceforge.net,
Linux Memory Management List <linux-mm@kvack.org>
User-Agent: Heirloom mailx 12.5 6/20/10
MIME-Version: 1.0
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220706_235749_215598_3B6A4876
X-CRM114-Status: UNSURE ( 5.13 )
X-CRM114-Notice: Please train this message.
X-BeenThere: ath11k@lists.infradead.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: <ath11k.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/ath11k>,
<ath11k-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/ath11k/>
List-Post: <ath11k@lists.infradead.org>
List-Help: <ath11k-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/ath11k>,
<ath11k-request@lists.infradead.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "ath11k" <ath11k-bounces@lists.infradead.org>
Errors-To: ath11k-bounces+ath11k=archiver.kernel.org@lists.infradead.org Newsgroups: org.infradead.lists.ath11k,com.redhat.dm-devel,dev.linux.lists.damon,dev.linu x.lists.iommu,dev.linux.lists.linux-staging,dev.linux.lists.ntb,dev.linux.lis ts.nvdimm,org.alsa-project.alsa-devel,org.freedesktop.lists.amd-gfx,org.freed esktop.lists.dri-devel,org.infradead.lists.linux-amlogic,org.infradead.lists. linux-mediatek,org.infradead.lists.linux-mtd,org.infradead.lists.linux-phy,or g.kernel.vger.ceph-devel,org.kernel.vger.keyrings,org.kernel.vger.kvm,org.ker nel.vger.linux-arm-msm,org.kernel.vger.linux-bcache,org.kernel.vger.linux-blo ck,org.kernel.vger.linux-bluetooth,org.kernel.vger.linux-btrfs,org.kernel.vge r.linux-cifs,org.kernel.vger.linux-clk,org.kernel.vger.linux-crypto,org.kerne l.vger.linux-cxl,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-doc,o rg.kernel.vger.linux-efi,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fbd ev,org.kernel.vger.linux-fpga,org.kernel.vger.linux-fsdevel,org.kernel.vger.l inux-hwmon,org.kernel.vger.linux-ide,org.kernel.vger.linux-iio,org.kernel.vge r.linux-input,org.kernel.vger.linux-integrity,org.kernel.vger.linux-leds,org. kernel.vger.linux-media,org.kernel.vger.linux-mmc,org.kernel.vger.linux-omap, org.kernel.vger.linux-parisc,org.kernel.vger.linux-pci,org.kernel.vger.linux- perf-users,org.kernel.vger.linux-pm,org.kernel.vger.linux-raid,org.kernel.vge r.linux-rdma,org.kernel.vger.linux-renesas-soc,org.kernel.vger.linux-samsung- soc,org.kernel.vger.linux-scsi,org.kernel.vger.linux-sctp,org.kernel.vger.lin ux-serial,org.kernel.vger.linux-tegra,org.kernel.vger.linux-unionfs,org.kerne l.vger.linux-usb,org.kernel.vger.linux-watchdog,org.kernel.vger.linux-wireles s,org.kernel.vger.linux-wpan,org.kernel.vger.netdev,org.kernel.vger.netfilter -devel,org.kernel.vger.target-devel,org.kvack.linux-mm,org.linuxfoundation.li sts.virtualization,org.osuosl.intel-wired-lan,org.ozlabs.lists.linuxppc-dev Xref: illumos org.infradead.lists.ath11k:4936 org.alsa-project.alsa-devel:186701 org.freedesktop.lists.amd-gfx:30880 org.freedesktop.lists.dri-devel:223137 org.infradead.lists.linux-amlogic:21234
org.infradead.lists.linux-mediatek:60055 org.infradead.lists.linux-mtd:106177 org.infradead.lists.linux-phy:4293 org.kernel.vger.ceph-devel:1859 org.kernel.vger.keyrings:8197 org.kernel.vger.kvm:54431 org.kernel.vger.linux-arm-msm:88595 org.kernel.vger.linux-bcache:10135 org.kernel.vger.linux-block:78162 org.kernel.vger.linux-bluetooth:89554 org.kernel.vger.linux-btrfs:5266 org.kernel.vger.linux-cifs:20857 org.kernel.vger.linux-clk:66513 org.kernel.vger.linux-crypto:61056 org.kernel.vger.linux-cxl:3615 org.kernel.vger.linux-devicetree:321361 org.kernel.vger.linux-doc:56569 org.kernel.vger.linux-efi:23821 org.kernel.vger.linux-ext4:11379 org.kernel.vger.linux-fbdev:44508 org.kernel.vger.linux-fpga:6298 org.kernel.vger.linux-fsdevel:122258 org.kernel.vger.linux-hwmon:15131
org.kernel.vger.linux-ide:52581 org.kernel.vger.linux-iio:52360 org.kernel.vger.linux-input:53178 org.kernel.vger.linux-integrity:20709 org.kernel.vger.linux-leds:17954 org.kernel.vger.linux-media:67562 org.kernel.vger.linux-mmc:17753 org.kernel.vger.linux-omap:44207 org.kernel.vger.linux-parisc:5986 org.kernel.vger.linux-pci:49179 org.kernel.vger.linux-perf-users:3098 org.kernel.vger.linux-pm:54488 org.kernel.vger.linux-raid:8879 org.kernel.vger.linux-rdma:15048 org.kernel.vger.linux-renesas-soc:33028 org.kernel.vger.linux-samsung-soc:33980 org.kernel.vger.linux-scsi:37190 org.kernel.vger.linux-sctp:3559 org.kernel.vger.linux-serial:13437 org.kernel.vger.linux-tegra:29903 org.kernel.vger.linux-unionfs:4103 org.kernel.vger.linux-usb:22978 org.kernel.vger.linux-watchdog:9391 org.kernel.vger.linux-wireless:36823 org.kernel.vger.linux-wpan:4971 org.kernel.vger.netdev:154425 org.kernel.vger.netfilter-devel:8169 org.kernel.vger.target-devel:3116 org.kvack.linux-mm:135423 org.linuxfoundation.lists.virtualization:2835 org.osuosl.intel-wired-lan:21826
org.ozlabs.lists.linuxppc-dev:75197

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

On 7/23/26 04:35, Jesse Rehmer wrote:

On Jul 23, 2026 at 4:44:52rC>AM CDT, "Kevin Bowling" <kevin.bowling@kev009.com>
wrote:

On 7/22/26 11:40, Jesse Rehmer wrote:

On Jul 22, 2026 at 1:27:46rC>PM CDT, "Ivo Gandolfo" <usenet@bofh.team> wrote:

Il 22/07/2026 20:17, Jesse Rehmer ha scritto:

Running into an issue with an article that causes the server to throttle and
record the following:

i run on same trouble some time ago. The problem is the other header of >>>> that article. I never understand that, but same article without that
header accepted fine. Same thing: newsgroups: header too long, I removed >>>> the follow header, and the article was accepted.

NG header too long threat the next header as part of ng part?

It seems to be some weird issue with having icdsynccount raised very high. I
had it set at 15000, but if I lower it to 1000, and reinsert the storage >>> tokens in the batch, the articles are accepted.

Not sure if it is reproducible but can you try
https://github.com/InterNetNews/inn/pull/369

The icdsynccount was either moving something around enough to cause the
pain, or even purely coincidental, if this is the right fix.

It was reproducible before I got around it by lowering icdsynccount, though I had the same settings on the origin server and didn't run into the issue there. Will get a new box setup over the weekend and try to reproduce without and with the patch.

Here are the headers from one of the articles:

Thanks Jesse. That confirms it hits exactly this realloc path, and that
the icdsynccount chance was inplace vs moving buffer layout for this
realloc.

Message-ID: <62c683a2.g1VSVt6BrQC6ZzOz%lkp@intel.com>
Subject: [linux-next:master] BUILD REGRESSION
088b9c375534d905a4d337c78db3b3bfbb52c4a0
Date: Thu, 07 Jul 2022 14:56:34 +0800
From: kernel test robot <lkp@intel.com>
Path:
illumos!news.pugleaf.net!.TX!i2pn2.pugleaf.net!archive.newsdeef.eu!apf9.newsd
eef.eu!nntp.lore.kernel.org!not-for-mail
Return-Path: <ath11k-bounces+ath11k=archiver.kernel.org@lists.infradead.org> >> X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
Received: from bombadil.infradead.org (bombadil.infradead.org
[198.137.202.133])
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
Received: from localhost ([::1] helo=bombadil.infradead.org)
Received: from mga07.intel.com ([134.134.136.100])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
t=1657177068; x=1688713068;
h=date:from:to:cc:subject:message-id:mime-version:
content-transfer-encoding;
bh=hUaxS4FbU98cO1hd7qPjY6PMv7SAZrQrjnJcWkGCO9c=;
b=ne7IEPFWkXJ2+LSU81rwzlEet/vFLHwf0eKBd3Nl+A0Gled+NBG6SrOz
KlGaJYwXghZeD+b5H0yeKaO7xTdxDMFBbBkomaYSm05lP9XBzm4IAQSAV
eRp74mUmocQ8fc9v/5B/Bsh9duWyhP9JN8GZR5Xh/drbGMhLRj1I+DOOC
O10s0bwKAa5fpJLQBFVixdzI/WOPCtmH/B+Nf4WvPbBsNqBPaLprIeKd/
HJW6xqYkstOgTdHRkRN6jc+e8os0NsVssw+upT85O++GL001x0teqcjNs
Ao1yUZ1L3hUm4BYThlZcVx0eoEdkKqIcEK5Mk4z6HX7qwM110/zI3ZWH5
g==;
X-IronPort-AV: E=McAfee;i="6400,9594,10400"; a="347932685"
X-IronPort-AV: E=Sophos;i="5.92,252,1650956400";
d="scan'208";a="347932685"
Received: from fmsmga008.fm.intel.com ([10.253.24.58])
X-IronPort-AV: E=Sophos;i="5.92,252,1650956400";
d="scan'208";a="651007648"
Received: from lkp-server01.sh.intel.com (HELO 68b931ab7ac1) ([10.239.97.150])
Received: from kbuild by 68b931ab7ac1 with local (Exim 4.95)
To: Andrew Morton <akpm@linux-foundation.org>
Cc: virtualization@lists.linux-foundation.org,
usbb2k-api-dev@nongnu.org, tipc-discussion@lists.sourceforge.net,
target-devel@vger.kernel.org, sound-open-firmware@alsa-project.org,
samba-technical@lists.samba.org, rds-devel@oss.oracle.com,
patches@opensource.cirrus.com, osmocom-net-gprs@lists.osmocom.org,
openipmi-developer@lists.sourceforge.net, nvdimm@lists.linux.dev,
ntb@lists.linux.dev, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, mjpeg-users@lists.sourceforge.net,
megaraidlinux.pdl@broadcom.com, linuxppc-dev@lists.ozlabs.org,
linux1394-devel@lists.sourceforge.net, linux-x25@vger.kernel.org,
linux-wpan@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-watchdog@vger.kernel.org, linux-usb@vger.kernel.org,
linux-unionfs@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-staging@lists.linux.dev, linux-serial@vger.kernel.org,
linux-sctp@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-samsung-soc@vger.kernel.org, linux-rockchip@lists.infradead.org,
linux-renesas-soc@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-raid@vger.kernel.org, linux-pm@vger.kernel.org,
linux-phy@lists.infradead.org, linux-perf-users@vger.kernel.org,
linux-pci@vger.kernel.org, linux-parport@lists.infradead.org,
linux-parisc@vger.kernel.org, linux-omap@vger.kernel.org,
linux-nfc@lists.01.org, linux-mtd@lists.infradead.org,
linux-mmc@vger.kernel.org, linux-mm@kvack.org,
linux-mediatek@lists.infradead.org, linux-media@vger.kernel.org,
linux-leds@vger.kernel.org, linux-integrity@vger.kernel.org,
linux-input@vger.kernel.org, linux-iio@vger.kernel.org,
linux-ide@vger.kernel.org, linux-hwmon@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-fpga@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-efi@vger.kernel.org, linux-doc@vger.kernel.org,
linux-cxl@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-clk@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-amlogic@lists.infradead.org, linaro-mm-sig@lists.linaro.org,
legousb-devel@lists.sourceforge.net, kvm@vger.kernel.org,
keyrings@vger.kernel.org, isdn4linux@listserv.isdn4linux.de,
iommu@lists.linux.dev, iommu@lists.linux-foundation.org,
intel-wired-lan@lists.osuosl.org, greybus-dev@lists.linaro.org,
dri-devel@lists.freedesktop.org, dm-devel@redhat.com,
devicetree@vger.kernel.org, dev@openvswitch.org, dccp@vger.kernel.org,
damon@lists.linux.dev, coreteam@netfilter.org, cgroups@vger.kernel.org,
ceph-devel@vger.kernel.org, ath11k@lists.infradead.org,
apparmor@lists.ubuntu.com, amd-gfx@lists.freedesktop.org,
alsa-devel@alsa-project.org,
accessrunner-general@lists.sourceforge.net,
Linux Memory Management List <linux-mm@kvack.org>
User-Agent: Heirloom mailx 12.5 6/20/10
MIME-Version: 1.0
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3
X-CRM114-CacheID: sfid-20220706_235749_215598_3B6A4876
X-CRM114-Status: UNSURE ( 5.13 )
X-CRM114-Notice: Please train this message.
X-BeenThere: ath11k@lists.infradead.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: <ath11k.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/ath11k>,
<ath11k-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/ath11k/>
List-Post: <ath11k@lists.infradead.org>
List-Help: <ath11k-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/ath11k>,
<ath11k-request@lists.infradead.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "ath11k" <ath11k-bounces@lists.infradead.org>
Errors-To: ath11k-bounces+ath11k=archiver.kernel.org@lists.infradead.org
Newsgroups:
org.infradead.lists.ath11k,com.redhat.dm-devel,dev.linux.lists.damon,dev.linu
x.lists.iommu,dev.linux.lists.linux-staging,dev.linux.lists.ntb,dev.linux.lis
ts.nvdimm,org.alsa-project.alsa-devel,org.freedesktop.lists.amd-gfx,org.freed
esktop.lists.dri-devel,org.infradead.lists.linux-amlogic,org.infradead.lists.
linux-mediatek,org.infradead.lists.linux-mtd,org.infradead.lists.linux-phy,or
g.kernel.vger.ceph-devel,org.kernel.vger.keyrings,org.kernel.vger.kvm,org.ker
nel.vger.linux-arm-msm,org.kernel.vger.linux-bcache,org.kernel.vger.linux-blo
ck,org.kernel.vger.linux-bluetooth,org.kernel.vger.linux-btrfs,org.kernel.vge
r.linux-cifs,org.kernel.vger.linux-clk,org.kernel.vger.linux-crypto,org.kerne
l.vger.linux-cxl,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-doc,o
rg.kernel.vger.linux-efi,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fbd
ev,org.kernel.vger.linux-fpga,org.kernel.vger.linux-fsdevel,org.kernel.vger.l
inux-hwmon,org.kernel.vger.linux-ide,org.kernel.vger.linux-iio,org.kernel.vge
r.linux-input,org.kernel.vger.linux-integrity,org.kernel.vger.linux-leds,org.
kernel.vger.linux-media,org.kernel.vger.linux-mmc,org.kernel.vger.linux-omap,
org.kernel.vger.linux-parisc,org.kernel.vger.linux-pci,org.kernel.vger.linux-
perf-users,org.kernel.vger.linux-pm,org.kernel.vger.linux-raid,org.kernel.vge
r.linux-rdma,org.kernel.vger.linux-renesas-soc,org.kernel.vger.linux-samsung-
soc,org.kernel.vger.linux-scsi,org.kernel.vger.linux-sctp,org.kernel.vger.lin
ux-serial,org.kernel.vger.linux-tegra,org.kernel.vger.linux-unionfs,org.kerne
l.vger.linux-usb,org.kernel.vger.linux-watchdog,org.kernel.vger.linux-wireles
s,org.kernel.vger.linux-wpan,org.kernel.vger.netdev,org.kernel.vger.netfilter
-devel,org.kernel.vger.target-devel,org.kvack.linux-mm,org.linuxfoundation.li
sts.virtualization,org.osuosl.intel-wired-lan,org.ozlabs.lists.linuxppc-dev >> Xref: illumos org.infradead.lists.ath11k:4936
org.alsa-project.alsa-devel:186701 org.freedesktop.lists.amd-gfx:30880
org.freedesktop.lists.dri-devel:223137 org.infradead.lists.linux-amlogic:21234
org.infradead.lists.linux-mediatek:60055 org.infradead.lists.linux-mtd:106177
org.infradead.lists.linux-phy:4293 org.kernel.vger.ceph-devel:1859
org.kernel.vger.keyrings:8197 org.kernel.vger.kvm:54431
org.kernel.vger.linux-arm-msm:88595 org.kernel.vger.linux-bcache:10135
org.kernel.vger.linux-block:78162 org.kernel.vger.linux-bluetooth:89554
org.kernel.vger.linux-btrfs:5266 org.kernel.vger.linux-cifs:20857
org.kernel.vger.linux-clk:66513 org.kernel.vger.linux-crypto:61056
org.kernel.vger.linux-cxl:3615 org.kernel.vger.linux-devicetree:321361
org.kernel.vger.linux-doc:56569 org.kernel.vger.linux-efi:23821
org.kernel.vger.linux-ext4:11379 org.kernel.vger.linux-fbdev:44508
org.kernel.vger.linux-fpga:6298 org.kernel.vger.linux-fsdevel:122258
org.kernel.vger.linux-hwmon:15131
org.kernel.vger.linux-ide:52581 org.kernel.vger.linux-iio:52360
org.kernel.vger.linux-input:53178 org.kernel.vger.linux-integrity:20709
org.kernel.vger.linux-leds:17954 org.kernel.vger.linux-media:67562
org.kernel.vger.linux-mmc:17753 org.kernel.vger.linux-omap:44207
org.kernel.vger.linux-parisc:5986 org.kernel.vger.linux-pci:49179
org.kernel.vger.linux-perf-users:3098 org.kernel.vger.linux-pm:54488
org.kernel.vger.linux-raid:8879 org.kernel.vger.linux-rdma:15048
org.kernel.vger.linux-renesas-soc:33028
org.kernel.vger.linux-samsung-soc:33980 org.kernel.vger.linux-scsi:37190
org.kernel.vger.linux-sctp:3559 org.kernel.vger.linux-serial:13437
org.kernel.vger.linux-tegra:29903 org.kernel.vger.linux-unionfs:4103
org.kernel.vger.linux-usb:22978 org.kernel.vger.linux-watchdog:9391
org.kernel.vger.linux-wireless:36823 org.kernel.vger.linux-wpan:4971
org.kernel.vger.netdev:154425 org.kernel.vger.netfilter-devel:8169
org.kernel.vger.target-devel:3116 org.kvack.linux-mm:135423
org.linuxfoundation.lists.virtualization:2835 org.osuosl.intel-wired-lan:21826
org.ozlabs.lists.linuxppc-dev:75197

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

On 7/22/26 11:27, Ivo Gandolfo wrote:

Il 22/07/2026 20:17, Jesse Rehmer ha scritto:

Running into an issue with an article that causes the server to
throttle and
record the following:

i run on same trouble some time ago. The problem is the other header of
that article. I never understand that, but same article without that
header accepted fine. Same thing: newsgroups: header too long, I removed
the follow header, and the article was accepted.

NG header too long threat the next header as part of ng part?

Ivo,

https://github.com/InterNetNews/inn/pull/369 should fix the Newsgroups
header. If you can show me any messages that were problematic beyond
that header I can take a look.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

Hi Kevin,

https://github.com/InterNetNews/inn/pull/369 should fix the Newsgroups header.

Thanks for the patch!
I will have more time next week in August to integrate all your recent PRs.

If you can show me any messages that were problematic beyond
that header I can take a look.

Probably unrelated to this very bug, but Richard Kettlewell looked at ARTassignnumbers() last November in
<wwvecpvhqu2.fsf@LkoBDZeT.terraraq.uk> and also noted the following
possible issues:

"""
ReplicLength is set in ARTassignnumbers, which is the kind of ad-hoc
string builder that tends to be full of bugs. It has a number of issues
but the most relevant is:

* If the collection of group names (and article numbers etc) adds up to
more than 2GB then len will overflow to negative. This could explain
the outcome seen, although it would need a pathologically large input
article.

Other observations about ARTassignnumbers, which I don't think can
explain the behavior seen:

* A pathhost bigger than the default xref buffer size (2049 bytes) would
generate a buffer overflow.

* An article number longer than ARTNUMPRINTSIZE could fail to expand the
buffer when needed. Currently you get ten digits, and the starting
buffer size is 2049 bytes, so this is probably not an issue in
real life.

* If there are no groups at all then the buffer expansion never happens
at all, so nothing explicitly accounts for the CRLF at the end -
i.e. the commented assumption "checked during the reallocation above"
is violated. But the default buffer size is more than enough in that
case.

* p and len are tracked separately, which is pointless and invites
error, but I don't see any way to get them out of sync apart from the
overflow issue described above.

* ReplicLength is set in an unnecessarily complicated way, because
len - (q + 1 - data->Xref) == Path.used - 1
but I don't see any realistic way for that to end up negative or for
q+1 to run past the end of the buffer.
"""
--
Julien |eLIE

-2-a21.1.1 How to convert mSQL tools for MySQL?
1. Run the shell script msql2mysql on the source. This requires the
replace program, which is distributed with MySQL.
2. Compile.
3. Fix all compiler errors.-a-+ (MySQL online manual)

--- Synchronet 3.22a-Linux NewsLink 1.2