> К примеру попытка создать свой аналог LSM, вместо того что бы брать
> / адаптировать готовую инфраструктуру.
> Сомнительное удовольствие как по мне, увеличивающее размер изменений.Почему и зачем это сделано, можно прочитать здесь: https://www.grsecurity.net/lsm.php
> Сомнительное переименование atomic / atomic_unchecked, увеличение патча без толку. Теже
В каком смысле, переименование? У atomic_t и atomic_unchecked_t разная семантика и соответствующие наборы функций операций, с проверками на переполнение и без них. Чуть подробнее об этом можно прочитать здесь: https://forums.grsecurity.net/viewtopic.php?f=3&t=2750#p11162
> атрибуты могли встроиться в обычный atomic, а для нужных и так
> заводится тип.
О каких атрибутах речь? У обоих типов он только один, counter.
"заводится тип" - это вы про refcount_t? Он-то как раз и есть велосипед с квадратными колёсами, снижающий производительность: https://lwn.net/Articles/718275/
Помимо самой заметки, стоит обратить внимание на два последних комментария от zyzzyva и PaX Team.
> которые просто лишние, зато влияют на время инспекций.
Дело вкуса. Ляпом это назвать никак нельзя.
> @@ -258,19 +259,19 @@ static ssize_t process_vm_rw_core(pid_t pid, const struct iovec *lvec,
> + return -ENOSYS; // PaX: until properly audited
Это соответствует моим ожиданиям как пользователя патча, с тем уточнением, что мои ядра вообще собраны без поддержки process_vm_*. :) То есть, тоже субъективно. Bikeshedding в любом случае. Сравнивать подобные якобы "ляпы" с серьёзными изъянами в результатах работы KSPP - совершенно некорректно.
> -static struct vfsmount *shm_mnt;
> +struct vfsmount *shm_mnt;
> Опа.. теперь любой полазив в system.map может добраться сюда..
А пара десятков тысяч других подобных определений в коде ядра вас не смущают? :)
> в догонку ляп.
>
> - if (current->fs->users != 1)
> + if (atomic_read(*t->fs->users) != 1)
> return -EINVAL;
>
> если открыть стандарт - reading always atomic if integer type size less or same than long.
> так что эта замена вызовет только лишние LOCK по шине и тормоза.
> Так и еще замены подобные есть.
Вы это серьёзно или подкалываете? Атомарность чтения как операции не имеет совершенно никакого отношения к валидности значения при его конкурентном чтении и записи из нескольких параллельных потоков. Согласно стандарту, поведение в таких случаях не определено. Зачем бы тогда вообще atomic_read нужен был?
> вообщем оно хорошо, но надо быть честным - есть ляпы и там.
Наверное, всё-таки действительно надо быть честным и признать, что если смысл чего-либо неясен на первый взгляд, это ещё не значит, что его нет? :)
