Bug#1071590: linux-image-6.1.0-21-amd64: Kernel werning in unmap_page_range()
Package: src:linux Version: 6.1.90-1 Severity: normal Dear Maintainer, I recently upgraded a machine from bullseye to bookworm. While this was successful, I started noticing a kernel warning a few hours after every boot. The kernel warning happens only once per-boot. Seems to be an issue with a bind9 process (isc-net-). This was the first 6.1 kernel on this machine so I don't know which versions have the problem or not. I have another, very similar machine, which also runs bind and the same kernel, but has never hit the warning. -- Package-specific info: ** Version: Linux version 6.1.0-21-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03) ** Command line: root=UUID=744e1ad4-2d7a-4ee8-a078-a34a255a8a51 ro quiet ** Tainted: W (512) * kernel issued warning ** Kernel log: [7.498136] systemd[1]: Finished modprobe@configfs.service - Load Kernel Module configfs. [7.499099] systemd[1]: modprobe@efi_pstore.service: Deactivated successfully. [7.499502] systemd[1]: Finished modprobe@efi_pstore.service - Load Kernel Module efi_pstore. [7.503590] systemd[1]: Mounting sys-kernel-config.mount - Kernel Configuration File System... [7.509953] loop: module loaded [7.513703] systemd[1]: modprobe@loop.service: Deactivated successfully. [7.514201] systemd[1]: Finished modprobe@loop.service - Load Kernel Module loop. [7.514887] systemd[1]: Mounted sys-kernel-config.mount - Kernel Configuration File System. [7.524965] fuse: init (API version 7.37) [7.527159] systemd[1]: modprobe@fuse.service: Deactivated successfully. [7.527524] systemd[1]: Finished modprobe@fuse.service - Load Kernel Module fuse. [7.532762] systemd[1]: Mounting sys-fs-fuse-connections.mount - FUSE Control File System... [7.537138] device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log. [7.537217] device-mapper: uevent: version 1.0.3 [7.537332] device-mapper: ioctl: 4.47.0-ioctl (2022-07-28) initialised: dm-de...@redhat.com [7.538973] systemd[1]: modprobe@dm_mod.service: Deactivated successfully. [7.539317] systemd[1]: Finished modprobe@dm_mod.service - Load Kernel Module dm_mod. [7.540631] systemd[1]: Mounted sys-fs-fuse-connections.mount - FUSE Control File System. [7.540962] systemd[1]: systemd-repart.service - Repartition Root Disk was skipped because no trigger condition checks were met. [7.582060] systemd[1]: Started systemd-journald.service - Journal Service. [7.612989] EXT4-fs (xvda): re-mounted. Quota mode: none. [7.732271] systemd-journald[232]: Received client request to flush runtime journal. [7.746542] lp: driver loaded but no devices found [7.755019] ppdev: user-space parallel port driver [9.620575] input: PC Speaker as /devices/platform/pcspkr/input/input0 [ 10.450818] Adding 8388604k swap on /dev/xvdb. Priority:-2 extents:1 across:8388604k SSFS [ 12.883148] EXT4-fs (xvdc): barriers disabled [ 12.903173] EXT4-fs (xvdc): mounted filesystem with ordered data mode. Quota mode: none. [ 14.672597] audit: type=1400 audit(1715718337.874:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="tcpdump" pid=326 comm="apparmor_parser" [ 14.709567] audit: type=1400 audit(1715718337.910:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=325 comm="apparmor_parser" [ 14.709581] audit: type=1400 audit(1715718337.910:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=325 comm="apparmor_parser" [ 14.709587] audit: type=1400 audit(1715718337.910:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=325 comm="apparmor_parser" [ 14.766342] audit: type=1400 audit(1715718337.966:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/freshclam" pid=324 comm="apparmor_parser" [ 14.783948] audit: type=1400 audit(1715718337.982:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=323 comm="apparmor_parser" [ 14.783960] audit: type=1400 audit(1715718337.982:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=323 comm="apparmor_parser" [ 14.787738] audit: type=1400 audit(1715718337.986:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=322 comm="apparmor_parser" [ 14.805238] audit: type=1400 audit(1715718338.006:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="named" pid=331 comm="apparmor_parser" [ 14.810506] audit: type=1400 audit(1715718338.010:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/clamd" pid=327 comm="apparmor_parser" [ 27.204462]
Bug#1015871: Enabling PCI_P2PDMA for distro kernels?
On 2023-10-25 11:35, Bjorn Helgaas wrote: > On Wed, Oct 25, 2023 at 07:11:26PM +0200, Lukas Wunner wrote: >> On Wed, Oct 25, 2023 at 10:30:07AM -0600, Logan Gunthorpe wrote: >>> In addition to the above, P2PDMA transfers are only allowed by the >>> kernel for traffic that flows through certain host bridges that are >>> known to work. For AMD, all modern CPUs are on this list, but for Intel, >>> the list is very patchy. >> >> This has recently been brought up internally at Intel and nobody could >> understand why there's a whitelist in the first place. A long-time PCI >> architect told me that Intel silicon validation has been testing P2PDMA >> at least since the Lindenhurst days, i.e. since 2005. >> >> What's the reason for the whitelist? Was there Intel hardware which >> didn't support it or turned out to be broken? >> >> I imagine (but am not certain) that the feature might only be enabled >> for server SKUs, is that the reason? > > No, the reason is that the PCIe spec doesn't require routing of > peer-to-peer transactions between Root Ports: > https://git.kernel.org/linus/0f97da831026 > > I think there was a little discussion about adding a firmware > interface to advertise this capability, but I guess nobody cared > enough to advance it. Yes, I remember someone advancing that in the PCI spec, but I don't know that it got anywhere. I definitely remember also testing Intel hardware several years ago where P2PDMA "worked" but the performance was so awful there was no point. I vaguely remember this not working on non-server machines in the past (circa 2015). That's why we had to buy a Xeon. Though this was a long time ago and my memory is fuzzy. I'd love it if someone from Intel can give us a reasonable check on the CPU that guarantees P2PDMA will work for everything that passes the check (like AMD has done.) But in the absence of Intel telling us this we can't easily make these assumptions. Logan
Bug#1015871: Enabling PCI_P2PDMA for distro kernels?
On 2023-10-25 00:19, Uwe Kleine-König wrote: > Hello, > > in https://bugs.debian.org/1015871 the Debian kernel team got a request > to enable PCI_P2PDMA. Given the description of the feature and also the > "If unsure, say N." I wonder if you consider it safe to enable this > option. I don't know. Not being a security expert, I'd say the attack surface exposed is fairly minimal. Most of what goes on is internal to the kernel. So the main risk is the same rough risk that goes with enabling any feature: there may be bugs. My opinion is that 'No' is recommended because the feature is still very nascent and advanced. Right now it enables two user visible niche features: p2p transfers in nvme-target between an NVMe device and an RDMA NIC and transferring buffers between two NVMe devices through the CMB via O_DIRECT. Both uses require an NVMe device with CMB memory, which is rare. Anyone using this option to do GPU P2PDMA transfers are certainly using out of tree (and likely proprietary) modules as the upstream kernel does not yet appear to support anything like that at this time. Thus it's not clear how such code is using the P2PDMA subsystem or what implications there may be. It's not commonly the case that using these features increases throughput as CMB memory is usually much slower than system memory. It's use makes more sense in smaller/cheaper boutique systems where the system memory or bus bandwidth to the CPU is limited. Typically with a PCIe switch involved. In addition to the above, P2PDMA transfers are only allowed by the kernel for traffic that flows through certain host bridges that are known to work. For AMD, all modern CPUs are on this list, but for Intel, the list is very patchy. When using a PCIe switch (also uncommon) this restriction is not present seeing the traffic can avoid the host bridge. Thus, my contention is anyone experimenting with this stuff ought to be capable of installing a custom kernel with the feature enabled. Logan
Bug#946829: Added upstream.
I've also hit this issue.
Bug#903800: linux-image-4.9.0-7-amd64: general protection fault / kernel panic at boot
Just wanted to add a me too. After upgrading a Xen hypervisor to 4.9.0-7-amd64 I see the same infinite reboot loop as reported above. As this box is a production server I downgraded back to 4.9.0-6 to fix the issue for now. Thanks, -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64)
Bug#660810: bandwidthd: Recover CDF feature does not work
Package: bandwidthd Version: 2.0.1+cvs20090917-4.1 Severity: normal When using bandwidthd with the recover-cdf option set to true the log files will never get correctly read on startup. This is true even if the CDF files exist and are valid. The following messages are seen in the logs on startup: bandwidthd: Finished recovering 0 records bandwidthd: Failed to parse part of log file. Giving up on the file This seems to be the same issue as a bug submitted upstream that is a few years old. (Sourceforge tracker number 2018613.) However, the upstream project seems rather dead. The bug is a simple mistake with a pair of fscanf calls. They expect 7 fields to be parsed when they ask for 8. I've attached a patch that fixes the problem and I've submitted the same patch to the upstream tracker. -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- bandwidthd-2.0.1+cvs20090917.orig/bandwidthd.c +++ bandwidthd-2.0.1+cvs20090917/bandwidthd.c @@ -1192,10 +1192,10 @@ if (fscanf(cdf, %llu,%llu,%llu,%llu,%llu,%llu,%llu,%llu,, ip-Send.total, ip-Send.icmp, ip-Send.udp, -ip-Send.tcp, ip-Send.ftp, ip-Send.http, ip-Send.mail, ip-Send.p2p) != 7 +ip-Send.tcp, ip-Send.ftp, ip-Send.http, ip-Send.mail, ip-Send.p2p) != 8 || fscanf(cdf, %llu,%llu,%llu,%llu,%llu,%llu,%llu,%llu, ip-Receive.total, ip-Receive.icmp, ip-Receive.udp, -ip-Receive.tcp, ip-Receive.ftp, ip-Receive.http, ip-Receive.mail, ip-Receive.p2p) != 7) +ip-Receive.tcp, ip-Receive.ftp, ip-Receive.http, ip-Receive.mail, ip-Receive.p2p) != 8) goto End_RecoverDataFromCdf; }
Bug#471716: dovecot-common: Permission Denied Errors after converting to 'mail_privileged_group'
Package: dovecot-common Version: 1.0.rc15-2etch4 Severity: important I began receiving the following log messages for numerous users after upgrading to the most recent stable version of dovecot and changing the configuration files to use mail_priviliged_group instead of mail_extra_groups. Mar 18 20:31:13 porter dovecot: POP3(logang): open(/var/mail/logang, O_CREAT) failed: Permission denied Mar 18 20:51:46 porter dovecot: IMAP(logang): open(/var/mail/logang, O_CREAT) failed: Permission denied The errors seem to correspond to connections by a mail client, however they do not occur for every connection and I get this error for some users much more than others. The permissions I have set for the /var/mail directory and inbox files are: drwxrwsr-x 2 root mail 4096 2008-03-19 11:11 /var/mail -rw-r- 1 logang mail 39860176 2008-03-18 22:31 /var/mail/logang Also, note that these files are stored on an NFS mount and fcntl locking with lockd is used. I briefly tried dotlock, but still got the error messages. If I add the mail group to the mail_access_groups the problem appears to go away. (I'm aware that due to the security concerns this is not an acceptable permanent fix.) Besides these errors, email clients still work fine, and I have not received any complaints from users regarding any unusual behaviour with their mail. -- System Information: Debian Release: 4.0 APT prefers deltatee APT policy: (500, 'deltatee'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.21.1deltatee Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=ISO-8859-1) (ignored: LC_ALL set to en_CA) Versions of packages dovecot-common depends on: ii add 3.102Add and remove users and groups ii lib 2.3.6.ds1-13etch5GNU C Library: Shared libraries ii lib 1.39+1.40-WIP-2006.11.14+dfsg-2etch1 common error description library ii lib 1.4.4-7etch4 MIT Kerberos runtime libraries ii lib 2.1.30-13.3 OpenLDAP libraries ii lib 5.0.32-7etch5mysql database client library ii lib 0.79-5 Runtime support for the PAM librar ii lib 0.79-5 Pluggable Authentication Modules l ii lib 8.1.11-0etch1PostgreSQL C client library ii lib 3.3.8-1.1SQLite 3 shared library ii lib 0.9.8c-4etch1SSL shared libraries ii ope 0.9.8c-4etch1Secure Socket Layer (SSL) binary a ii zli 1:1.2.3-13 compression library - runtime dovecot-common recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471716: dovecot-common: Permission Denied Errors after converting to 'mail_privileged_group'
These files never get deleted. They should be simply opening the already existing files. It may be a good idea to use the mail_privileged_group for creating new inboxes however I do not believe that is the problem here. Timo Sirainen wrote: On Wed, 2008-03-19 at 11:45 -0600, Logan Gunthorpe wrote: Mar 18 20:31:13 porter dovecot: POP3(logang): open(/var/mail/logang, O_CREAT) failed: Permission denied Mar 18 20:51:46 porter dovecot: IMAP(logang): open(/var/mail/logang, O_CREAT) failed: Permission denied Do these files get deleted by something? Can your users access the mailboxes directly? Some MUAs delete the whole mbox when all messages have been deleted. mail_privileged_group is used only while dotlocking, it's not used when trying to create new mailboxes. Perhaps it should also be used for creating INBOX.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471716: dovecot-common: Permission Denied Errors after converting to 'mail_privileged_group'
Hi,
I do not use the sieve plug-in.
I've attached a the strace log of a single process with an error. I've
obfuscated the user's name with user.
Just for reference this log was created using the following commands (as
root):
strace -tf dovecot -F 2 ~/dovecot.strace
grep 'pid 6477' /root/dovecot.strace dovecot.6477.strace
If you would like the full unedited dovecot.strace log I can send you
that. However, it is 11MB and I'd prefer not to post the user
information it contains on the public mailing list.
Also, this may be nothing, but when I ran the command above with sudo,
(instead of su'ing) the problem did not seem to occur. I ran it for a
good half hour with no errors, and when I switched to su I got a couple
errors rather quickly. Although, that may have just been a coincidence.
Thanks,
Logan
Fabio Tranchitella wrote:
Hello,
* 2008-03-19 18:54, Logan Gunthorpe wrote:
Package: dovecot-common
Version: 1.0.rc15-2etch4
Severity: important
I began receiving the following log messages for numerous users after
upgrading to the most recent stable version of dovecot and changing the
configuration files to use mail_priviliged_group instead of
mail_extra_groups.
Mar 18 20:31:13 porter dovecot: POP3(logang): open(/var/mail/logang, O_CREAT)
failed: Permission denied
Mar 18 20:51:46 porter dovecot: IMAP(logang): open(/var/mail/logang, O_CREAT)
failed: Permission denied
The mail_priviliged_group is used for writing the lock file, but it seems
that the problem lies somewhere else and this is why adding the mail group
added to mail_priviliged_group doesn't fix it.
I don't see any obvious reason why you get these messages. Do you use the
sieve plug-in? Also, can you strace some of the processes to understand
what is happening?
Thanks,
[pid 6477] 14:29:44 dup2(42, 0 unfinished ...
[pid 6477] 14:29:44 ... dup2 resumed ) = 0
[pid 6477] 14:29:44 dup2(42, 1 unfinished ...
[pid 6477] 14:29:44 ... dup2 resumed ) = 1
[pid 6477] 14:29:44 dup2(45, 2 unfinished ...
[pid 6477] 14:29:44 ... dup2 resumed ) = 2
[pid 6477] 14:29:44 fcntl64(0, F_GETFD unfinished ...
[pid 6477] 14:29:44 ... fcntl64 resumed ) = 0
[pid 6477] 14:29:44 fcntl64(0, F_SETFD, 0) = 0
[pid 6477] 14:29:44 fcntl64(1, F_GETFD) = 0
[pid 6477] 14:29:44 fcntl64(1, F_SETFD, 0) = 0
[pid 6477] 14:29:44 fcntl64(2, F_GETFD) = 0
[pid 6477] 14:29:44 fcntl64(2, F_SETFD, 0) = 0
[pid 6477] 14:29:44 setrlimit(RLIMIT_DATA, {rlim_cur=262144*1024,
rlim_max=262144*1024}) = 0
[pid 6477] 14:29:44 setrlimit(RLIMIT_AS, {rlim_cur=262144*1024,
rlim_max=262144*1024}) = 0
[pid 6477] 14:29:44 setresgid32(-1, 100, -1) = 0
[pid 6477] 14:29:44 setresuid32(-1, 2190, -1) = 0
[pid 6477] 14:29:44 chdir(/home/user) = 0
[pid 6477] 14:29:44 setresuid32(-1, 0, -1) = 0
[pid 6477] 14:29:44 umask(077) = 077
[pid 6477] 14:29:44 close(11) = 0
[pid 6477] 14:29:44 execve(/usr/lib/dovecot/pop3, [pop3], [/* 37 vars */])
= 0
[pid 6477] 14:29:44 uname({sys=Linux, node=porter, ...}) = 0
[pid 6477] 14:29:44 brk(0) = 0x80c5000
[pid 6477] 14:29:44 fcntl64(0, F_GETFD) = 0
[pid 6477] 14:29:44 fcntl64(1, F_GETFD) = 0
[pid 6477] 14:29:44 fcntl64(2, F_GETFD) = 0
[pid 6477] 14:29:44 access(/etc/suid-debug, F_OK) = -1 ENOENT (No such file
or directory)
[pid 6477] 14:29:44 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such
file or directory)
[pid 6477] 14:29:44 mmap2(NULL, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fc9000
[pid 6477] 14:29:44 access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such
file or directory)
[pid 6477] 14:29:44 open(/etc/ld.so.cache, O_RDONLY) = 3
[pid 6477] 14:29:44 fstat64(3, {st_mode=S_IFREG|0644, st_size=25539, ...}) = 0
[pid 6477] 14:29:44 mmap2(NULL, 25539, PROT_READ, MAP_PRIVATE, 3, 0) =
0xb7fc2000
[pid 6477] 14:29:44 close(3) = 0
[pid 6477] 14:29:44 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such
file or directory)
[pid 6477] 14:29:44 open(/lib/tls/libdl.so.2, O_RDONLY) = 3
[pid 6477] 14:29:44 read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\f\0..., 512) = 512
[pid 6477] 14:29:44 fstat64(3, {st_mode=S_IFREG|0644, st_size=9592, ...}) = 0
[pid 6477] 14:29:44 mmap2(NULL, 12404, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7fbe000
[pid 6477] 14:29:44 mmap2(0xb7fc, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7fc
[pid 6477] 14:29:44 close(3) = 0
[pid 6477] 14:29:44 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such
file or directory)
[pid 6477] 14:29:44 open(/lib/tls/libc.so.6, O_RDONLY) = 3
[pid 6477] 14:29:44 read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240O\1..., 512) = 512
[pid 6477] 14:29:44 fstat64(3, {st_mode=S_IFREG|0644, st_size=1245488, ...}) = 0
[pid 6477] 14:29:44 mmap2(NULL, 1251484, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e8c000
[pid 6477] 14:29:44 mmap2(0xb7fb4000, 28672, PROT_READ|PROT_WRITE
