Perguntas[linux-kernel](unix)

Estou trabalhando em alguns scripts antigos que lidam com cpusets, portando para o openSUSE. Os scripts funcionavam bem com o openSUSE 15.5, mas agora com o 15.6 eles falham porque os /dev/cpusetarquivos que eles esperavam não estão lá. Na verdade, os arquivos estão todos lá, mas perderam o prefixo cpuset.em seus nomes.

Por exemplo, para um cpuset chamado sys, os scripts esperam manipular /dev/cpuset/sys/cpuset.cpus, mas o arquivo real parece ser chamado /dev/cpuset/sys/cpus. Esse padrão continua para todos os treze arquivos que no openSUSE 15.5 (e sistemas mais antigos) tinham nomes começando com cpuset.; os mesmos arquivos estão lá, mas sem o cpuset.prefixo.

Olhando para a página de referência do docs.kernel.org , a cpuset.*nomenclatura é a que está documentada. Alguma ideia de onde os arquivos sem o cpuset.prefixo vieram?

Mais informações: aqui está o /dev/cpuset/sysdiretório completo (onde sysestá o nome do cpuset) em uma máquina openSUSE Leap 15.5:

devuser@product:/dev/cpuset/sys> ls -al
total 0
drwxr-xr-x 2 root root 0 Feb 18 14:07 .
dr-xr-xr-x 3 root root 0 Feb 18 14:03 ..
-rw-r--r-- 1 root root 0 Feb 18 14:07 cgroup.clone_children
-rw-r--r-- 1 root root 0 Feb 18 14:07 cgroup.procs
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.cpu_exclusive
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.cpus
-r--r--r-- 1 root root 0 Feb 18 14:07 cpuset.effective_cpus
-r--r--r-- 1 root root 0 Feb 18 14:07 cpuset.effective_mems
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.mem_exclusive
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.mem_hardwall
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.memory_migrate
-r--r--r-- 1 root root 0 Feb 18 14:07 cpuset.memory_pressure
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.memory_spread_page
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.memory_spread_slab
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.mems
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.sched_load_balance
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.sched_relax_domain_level
-rw-r--r-- 1 root root 0 Feb 18 14:07 notify_on_release
-rw-r--r-- 1 root root 0 Feb 18 14:07 tasks
devuser@product:/dev/cpuset/sys> 

E aqui está o mesmo diretório em uma máquina openSUSE 15.6:

devuser@product:/dev/cpuset/sys> ls -al
total 0
drwxr-xr-x 2 root root 0 Feb 18 11:25 .
dr-xr-xr-x 5 root root 0 Feb 18 11:25 ..
-rw-r--r-- 1 root root 0 Feb 18 11:29 cgroup.clone_children
-rw-r--r-- 1 root root 0 Feb 18 11:29 cgroup.procs
-rw-r--r-- 1 root root 0 Feb 18 11:29 cpu_exclusive
-rw-r--r-- 1 root root 0 Feb 18 11:29 cpus
-r--r--r-- 1 root root 0 Feb 18 11:29 effective_cpus
-r--r--r-- 1 root root 0 Feb 18 11:29 effective_mems
-rw-r--r-- 1 root root 0 Feb 18 11:29 mem_exclusive
-rw-r--r-- 1 root root 0 Feb 18 11:29 mem_hardwall
-rw-r--r-- 1 root root 0 Feb 18 11:29 memory_migrate
-r--r--r-- 1 root root 0 Feb 18 11:29 memory_pressure
-rw-r--r-- 1 root root 0 Feb 18 11:29 memory_spread_page
-rw-r--r-- 1 root root 0 Feb 18 11:29 memory_spread_slab
-rw-r--r-- 1 root root 0 Feb 18 11:29 mems
-rw-r--r-- 1 root root 0 Feb 18 11:29 notify_on_release
-rw-r--r-- 1 root root 0 Feb 18 11:29 sched_load_balance
-rw-r--r-- 1 root root 0 Feb 18 11:29 sched_relax_domain_level
-rw-r--r-- 1 root root 0 Feb 18 12:41 tasks
devuser@product:/dev/cpuset/sys> 

Então, exatamente o mesmo conjunto de arquivos, exceto que enquanto o Leap 15.5 tem um cpuset.prefixo em treze arquivos, o Leap 15.6 tem os mesmos arquivos, mas cpuset.removidos.

Editar: aqui está como eu fiz o diretório cpuset no sistema Leap 15.6. Em um sistema recém-reinicializado:

devuser@product:~> ls /dev/cpuset
ls: cannot access '/dev/cpuset': No such file or directory
devuser@product:~> sudo mkdir /dev/cpuset
[sudo] password for root: 
devuser@product:~> sudo mount -t cpuset none /dev/cpuset
devuser@product:~> sudo mkdir /dev/cpuset/sys
devuser@product:~> ls /dev/cpuset/sys
cgroup.clone_children  mem_exclusive       mems
cgroup.procs           mem_hardwall        notify_on_release
cpu_exclusive          memory_migrate      sched_load_balance
cpus                   memory_pressure     sched_relax_domain_level
effective_cpus         memory_spread_page  tasks
effective_mems         memory_spread_slab
devuser@product:~> 

Esta pergunta é uma continuação desta resposta . Em geral, meu objetivo é saber se meu sistema (Debian/Raspberry Pi 5 'bookworm') está atualizando meu relógio RTC/hardware a partir do horário do sistema. Observe que o RPi 5 (diferentemente de seus ancestrais Pi) tem um relógio RTC/hardware embutido .

Aqui está o que consegui determinar até agora:

1. Sinto que estabeleci que o relógio do sistema está sendo atualizado a partir do hwclock:

$ dmesg | grep "system clock" 

[    1.588793] rpi-rtc soc:rpi_rtc: setting system clock to 2025-02-18T04:59:13 UTC (1739854753)

Depois de alguma busca dmesg, no entanto, não consegui encontrar nenhuma indicação de que o hwclock esteja sendo atualizado a partir do horário do sistema. No entanto, encontrei uma referência a um fake-hardwarerelógio (o que parece estranho ). :

[    4.037230] systemd[1]: Starting fake-hwclock.service - Restore / save the current clock...

2. O kernel está aparentemente configurado para fazer atualizações de relógio em "ambas as direções":

$ cat /boot/config-$(uname -r) | grep -i HCTOSYS
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"  

$ cat /boot/config-$(uname -r) | grep -i SYSTOHC
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_SYSTOHC_DEVICE="rtc0"

Ocorreu-me que o kernel pode estar executando a sincronização SYSTOHC somente durante o desligamento, e talvez não esteja sendo capturado por dmesg... mas isso é um WAG.

Alguém pode explicar como confirmar se o kernel está (ou não) atualizando o hwclock/RTC?

Como os drivers oficiais NVIDIA 391.xx não suportam Linux 6.x, sou forçado a usar o noveau, mas o desempenho é muito ruim. Existe uma versão não oficial desses drivers para kernels Linux mais novos? Agradeço antecipadamente por sua resposta.

Li que não se deve usar uma chamada de sistema de bloqueio em um manipulador de interrupção.

Para sistemas de processador único, isso faz sentido, mas, para sistemas multiprocessadores, tal operação de bloqueio realmente bloqueará o sistema inteiro? Ou apenas o processador em que ele roda?

Então, atualmente estou aprendendo a escrever módulos de kernel/drivers de dispositivo e estava analisando a implementação de unregister_chrdev_region:

https://elixir.bootlin.com/linux/v6.12/source/fs/char_dev.c#L311

/**
 * unregister_chrdev_region() - unregister a range of device numbers
 * @from: the first in the range of numbers to unregister
 * @count: the number of device numbers to unregister
 *
 * This function will unregister a range of @count device numbers,
 * starting with @from.  The caller should normally be the one who
 * allocated those numbers in the first place...
 */
void unregister_chrdev_region(dev_t from, unsigned count)
{
    dev_t to = from + count;
    dev_t n, next;

    for (n = from; n < to; n = next) {
        next = MKDEV(MAJOR(n)+1, 0);
        if (next > to)
            next = to;
        kfree(__unregister_chrdev_region(MAJOR(n), MINOR(n), next - n));
    }
}

O que não entendo é a verificação nesta linha:

https://elixir.bootlin.com/linux/v6.12/source/fs/char_dev.c#L318

if (next > to) next = to;

O loop, como eu vejo, já quebra quando a variável do loop é igual ao limite superior to = from + count. Quando teríamos o caso de encontrarmos o condicional if (next > to)? Qual é o motivo dessa verificação condicional?

Meu laptop Linux (openSUSE Tumbleweed) deveria hibernar, mas não hiberna e não entendo o porquê. Já tive sistemas semelhantes (Arch Linux) hibernando nas mesmas circunstâncias (LVM no LUKS). Aqui está minha configuração:

• Inicialização EFI-GRUB
• LVM no LUKS; LVM tem partições raiz, home e swap
• Swap habilitado e montado por UUID em /etc/fstab, swapon -smostra que ele está ativo. Ele tem 32 GB de tamanho com 16 GB de RAM instalados.
• O GRUB tem instruções resume na configuração padrão e /boot/grub2/grub.cfg(veja abaixo).

Aqui estão alguns comandos para verificar os recursos de hibernação do kernel e do sistema:

# zgrep HIBERN /proc/config.gz
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_HIBERNATION_SNAPSHOT_DEV=y
CONFIG_HIBERNATION_COMP_LZO=y
# CONFIG_HIBERNATION_COMP_LZ4 is not set
CONFIG_HIBERNATION_DEF_COMP="lzo"

Então o kernel está configurado para suportar hibernação.

Esta bota (da GRUB) tem:

# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-6.11.6-2-default root=/dev/mapper/cryptolvm-opensuse splash=silent resume=/dev/mapper/cryptolvm-swap mem_sleep_default=deep security=selinux selinux=1 enforcing=1 mitigations=auto

Tentei variar resume=o uso UUID=....com o UUID do swap, mas não tive efeito.

# cat /sys/power/state
freeze mem

Aqui diskestá faltando, mas não sei por quê.

Claro que isso não vai funcionar agora:

# systemctl hibernate
Call to Hibernate failed: Sleep verb 'hibernate' is not configured or configuration is not supported by kernel
Exit 1

O kernel depende do BIOS para habilitar a hibernação? (Não que eu saiba.) Nesse caso, posso verificar algo lá?

Minha tarefa é a seguinte: é necessário ler todos os dados do firmware UEFI do chip BIOS e calcular a checksumquantidade desses dados.

Como isso pode ser feito (qual é a área de memória do firmware UEFI e é possível ler o firmware UEFI do kernel Linux)?

Eu sei que o comando dmesg imprime a mensagem armazenada em um buffer de anel. Mas, a partir do código-fonte do Linux, qual é o nome do buffer? Quero olhar para o buffer depois que o Linux for encerrado sem nenhuma mensagem. Suspeito que não seja por uma armadilha de software (portanto, nenhuma mensagem de pânico), mas posso examinar a memória (com algum System.map e conversão de endereço virtual para físico).

Estou planejando usar a habilidade de criptografia de arquivos Ext4. Tudo funciona bem, mas ainda há um problema. Depois de remover a SENHA via keyctl, ainda consigo ver o conteúdo do diretório criptografado. Tentei deletar a chave, sincronizar e esvaziar o cache de páginas, desmontar o sistema de arquivos, reiniciar o gerenciador de arquivos caja e montar o fs novamente. Mas não funciona. Embora eu não consiga mais escrever no diretório, ainda consigo ver nomes claros.

Como esvazio o cache do KeyRing do Kernel? (sem reinicializar ou reiniciar minha sessão X)

Fontes:

• Introdução
• Tutorial
• e4crypt - página de manual
• Implementação de login
• Linux Kernel Keyring - notas

Estou observando um comportamento muito estranho.

/proc/1154/cmdlineexiste, e kill -0 1154tem sucesso, mas ps -ef | grep 1154não ls /proc | grep 1154mostra nada.

1154 era um processo postgres no meio do desligamento (ou os logs dizem, mas talvez eles não tenham sido liberados) quando a VM foi reiniciada.

Como isso é possível?