[sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Michael Shigorin]

	Здравствуйте.
Несколько ранее было обнаружено, что sispmctl сегфолтится
при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:

---
$ strace sispmctl -o 1
......
open("/sys/bus/usb/devices", O_RDONLY|O_NONBLOCK|O_DIRECTORY|
      O_CLOEXEC) = 3
getdents(3, /* 14 entries */, 32768)    = 384
stat("/sys/bus/usb/devices/1-1/descriptors", 0x7fff9270a8a0) = -1
      ENOENT (No such file or directory)
open("/sys/bus/usb/devices/1-1/busnum", O_RDONLY) = -1 ENOENT
      (No such file or directory)
close(3)                                = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) --- 
+++ killed by SIGSEGV +++
---

Возможно ли собрать, как понимаю, libusb/libusb-compat таким
образом, чтобы они работали и на самом старом из официально
поддерживаемых в сизифе ядер?  Что для этого следует сделать?
(один из пакетов собирается с linux-libc-headers)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

В Вск, 16/08/2009 в 17:24 +0300, Michael Shigorin пишет:
> 	Здравствуйте.
> Несколько ранее было обнаружено, что sispmctl сегфолтится
> при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:

все что ниже 2.6.27 пора закопать. если они как то еще работают, то это
не на долго (до нового udev)

-- 
Valery V. Inozemtsev

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

В Вск, 16/08/2009 в 18:30 +0400, Valery V. Inozemtsev пишет:
> В Вск, 16/08/2009 в 17:24 +0300, Michael Shigorin пишет:
> > 	Здравствуйте.
> > Несколько ранее было обнаружено, что sispmctl сегфолтится
> > при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:
> 
> все что ниже 2.6.27 пора закопать. если они как то еще работают, то это
> не на долго (до нового udev)

да, совсем забыл... на самом деле все еще страшнее. для нашего glibc
(собранного с хидерами от 2.6.29) нужно ядро 2.6.27 и выше. т.ч. это
2.6.18 все еще работает просто чудом или весь юзерспейс, что там
работает, не использует (пока не использует) новые системные вызовы.

-- 
Valery V. Inozemtsev

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

On Sun, Aug 16, 2009 at 07:58:14PM +0400, Valery V. Inozemtsev wrote:
> В Вск, 16/08/2009 в 18:30 +0400, Valery V. Inozemtsev пишет:
> > В Вск, 16/08/2009 в 17:24 +0300, Michael Shigorin пишет:
> > > 	Здравствуйте.
> > > Несколько ранее было обнаружено, что sispmctl сегфолтится
> > > при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:
> > 
> > все что ниже 2.6.27 пора закопать. если они как то еще работают, то это
> > не на долго (до нового udev)
> 
> да, совсем забыл... на самом деле все еще страшнее. для нашего glibc
> (собранного с хидерами от 2.6.29) нужно ядро 2.6.27 и выше. т.ч. это
> 2.6.18 все еще работает просто чудом или весь юзерспейс, что там
> работает, не использует (пока не использует) новые системные вызовы.

Валера, тот эффект, который ты описываешь, правильно было бы назвать
glibc ABI break.  Только я этот вопрос специально проверял, и ничего
подозрительного не выявил.  Так что, пожалуйста, расскажи подробности.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

On Sun, Aug 16, 2009 at 06:30:03PM +0400, Valery V. Inozemtsev wrote:
> В Вск, 16/08/2009 в 17:24 +0300, Michael Shigorin пишет:
> > 	Здравствуйте.
> > Несколько ранее было обнаружено, что sispmctl сегфолтится
> > при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:
> 
> все что ниже 2.6.27 пора закопать. если они как то еще работают, то это
> не на долго (до нового udev)

Если 2.6.18-ovz-rhel закопать, то жизнь остановится. :)
Не шути так! :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]

В Вск, 16/08/2009 в 20:52 +0400, Dmitry V. Levin пишет:
> On Sun, Aug 16, 2009 at 07:58:14PM +0400, Valery V. Inozemtsev wrote:
> > В Вск, 16/08/2009 в 18:30 +0400, Valery V. Inozemtsev пишет:
> > > В Вск, 16/08/2009 в 17:24 +0300, Michael Shigorin пишет:
> > > > 	Здравствуйте.
> > > > Несколько ранее было обнаружено, что sispmctl сегфолтится
> > > > при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:
> > > 
> > > все что ниже 2.6.27 пора закопать. если они как то еще работают, то это
> > > не на долго (до нового udev)
> > 
> > да, совсем забыл... на самом деле все еще страшнее. для нашего glibc
> > (собранного с хидерами от 2.6.29) нужно ядро 2.6.27 и выше. т.ч. это
> > 2.6.18 все еще работает просто чудом или весь юзерспейс, что там
> > работает, не использует (пока не использует) новые системные вызовы.
> 
> Валера, тот эффект, который ты описываешь, правильно было бы назвать
> glibc ABI break.  Только я этот вопрос специально проверял, и ничего
> подозрительного не выявил.  Так что, пожалуйста, расскажи подробности.
> 

вот пример (тот же код и в glibc)
http://git.altlinux.org/people/shrek/packages/?p=klibc.git;a=blob;f=usr/klibc/signalfd.c;h=1edc05d936229b5cbf5b56afc1fb2c0ddf56f458;hb=HEAD
__NR_signalfd4 появился в 2.6.27
есть еще кучка at()
http://git.altlinux.org/people/shrek/packages/?p=klibc.git;a=commitdiff;h=7383280c094de24c926623b3996ce651e9d812d4

этот вопрос подробно может осветить Власов, я к сожалению не обладаю
таким красноречием и силой убеждения :)

-- 
Valery V. Inozemtsev

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

В Вск, 16/08/2009 в 20:54 +0400, Dmitry V. Levin пишет:
> On Sun, Aug 16, 2009 at 06:30:03PM +0400, Valery V. Inozemtsev wrote:
> > В Вск, 16/08/2009 в 17:24 +0300, Michael Shigorin пишет:
> > > 	Здравствуйте.
> > > Несколько ранее было обнаружено, что sispmctl сегфолтится
> > > при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:
> > 
> > все что ниже 2.6.27 пора закопать. если они как то еще работают, то это
> > не на долго (до нового udev)
> 
> Если 2.6.18-ovz-rhel закопать, то жизнь остановится. :)

она уже остановилась. полноценный gnome-2.28 без нового udev мы не
получим

> Не шути так! :)

да я и не начинал

-- 
Valery V. Inozemtsev

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] klibc incompatibilities

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

On Sun, Aug 16, 2009 at 09:15:25PM +0400, Valery V. Inozemtsev wrote:
> В Вск, 16/08/2009 в 20:52 +0400, Dmitry V. Levin пишет:
> > On Sun, Aug 16, 2009 at 07:58:14PM +0400, Valery V. Inozemtsev wrote:
> > > В Вск, 16/08/2009 в 18:30 +0400, Valery V. Inozemtsev пишет:
> > > > В Вск, 16/08/2009 в 17:24 +0300, Michael Shigorin пишет:
> > > > > 	Здравствуйте.
> > > > > Несколько ранее было обнаружено, что sispmctl сегфолтится
> > > > > при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:
> > > > 
> > > > все что ниже 2.6.27 пора закопать. если они как то еще работают, то это
> > > > не на долго (до нового udev)
> > > 
> > > да, совсем забыл... на самом деле все еще страшнее. для нашего glibc
> > > (собранного с хидерами от 2.6.29) нужно ядро 2.6.27 и выше. т.ч. это
> > > 2.6.18 все еще работает просто чудом или весь юзерспейс, что там
> > > работает, не использует (пока не использует) новые системные вызовы.
> > 
> > Валера, тот эффект, который ты описываешь, правильно было бы назвать
> > glibc ABI break.  Только я этот вопрос специально проверял, и ничего
> > подозрительного не выявил.  Так что, пожалуйста, расскажи подробности.
> > 
> 
> вот пример (тот же код и в glibc)
> http://git.altlinux.org/people/shrek/packages/?p=klibc.git;a=blob;f=usr/klibc/signalfd.c;h=1edc05d936229b5cbf5b56afc1fb2c0ddf56f458;hb=HEAD
> __NR_signalfd4 появился в 2.6.27
> есть еще кучка at()
> http://git.altlinux.org/people/shrek/packages/?p=klibc.git;a=commitdiff;h=7383280c094de24c926623b3996ce651e9d812d4

klibc - это простая библиотека, которая, в отличие от glibc, не
обеспечивает обратной совместимости.  В glibc совсем другой код,
при желании можешь посмотреть.

Вопрос, эти новые системные вызовы в безусловной реализации klibc
уже где-нибудь используются?  Если да, то начиная с каких сборок?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] klibc incompatibilities

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]

> > > > да, совсем забыл... на самом деле все еще страшнее. для нашего glibc
> > > > (собранного с хидерами от 2.6.29) нужно ядро 2.6.27 и выше. т.ч. это
> > > > 2.6.18 все еще работает просто чудом или весь юзерспейс, что там
> > > > работает, не использует (пока не использует) новые системные вызовы.
> > > 
> > > Валера, тот эффект, который ты описываешь, правильно было бы назвать
> > > glibc ABI break.  Только я этот вопрос специально проверял, и ничего
> > > подозрительного не выявил.  Так что, пожалуйста, расскажи подробности.
> > > 
> > 
> > вот пример (тот же код и в glibc)
> > http://git.altlinux.org/people/shrek/packages/?p=klibc.git;a=blob;f=usr/klibc/signalfd.c;h=1edc05d936229b5cbf5b56afc1fb2c0ddf56f458;hb=HEAD
> > __NR_signalfd4 появился в 2.6.27
> > есть еще кучка at()
> > http://git.altlinux.org/people/shrek/packages/?p=klibc.git;a=commitdiff;h=7383280c094de24c926623b3996ce651e9d812d4
> 
> klibc - это простая библиотека, которая, в отличие от glibc, не
> обеспечивает обратной совместимости.  В glibc совсем другой код,
> при желании можешь посмотреть.

реализация signalfd в klibc была мной слизана из glibc практически 1:1

> Вопрос, эти новые системные вызовы в безусловной реализации klibc
> уже где-нибудь используются?  Если да, то начиная с каких сборок?

они используются в udev >= 143

-- 
Valery V. Inozemtsev

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] klibc incompatibilities

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

> > klibc - это простая библиотека, которая, в отличие от glibc, не
> > обеспечивает обратной совместимости.  В glibc совсем другой код,
> > при желании можешь посмотреть.
> 
> реализация signalfd в klibc была мной слизана из glibc практически 1:1

игра "найди 10 отличий"
http://git.altlinux.org/people/shrek/packages/?p=klibc.git;a=blob;f=usr/klibc/signalfd.c;h=2ade718cc9e978ba5aebd495b6b2be56e08e4408;hb=HEAD
http://git.altlinux.org/people/ldv/packages/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/signalfd.c;h=9898f2923122bd0f9efc008bb4b27354ab2da5a2;hb=HEAD

-- 
Valery V. Inozemtsev

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Michael Shigorin]

On Sun, Aug 16, 2009 at 09:17:08PM +0400, Valery V. Inozemtsev wrote:
> > > > Несколько ранее было обнаружено, что sispmctl сегфолтится
> > > > при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:
> > > все что ниже 2.6.27 пора закопать. если они как то еще
> > > работают, то это не на долго (до нового udev)
> > Если 2.6.18-ovz-rhel закопать, то жизнь остановится. :)
> она уже остановилась. полноценный gnome-2.28 без нового udev мы
> не получим

Замечательно, у нас уже как-то поднимался (и со скандалом
заминался) вопрос о двух udev.  Поскольку как понимаю, то
2.6.27-ovz в продакшн не годится, а целевые аудитории ovz-rhel
и gnome-2.28 пересекаются слабо.

> > Не шути так! :)
> да я и не начинал

Да понятно, что невесело, и что делать теперь будем?
Тут рядом негромко звучит "все на lxc".

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 1626 bytes --]

В Вск, 16/08/2009 в 21:20 +0300, Michael Shigorin пишет:
> On Sun, Aug 16, 2009 at 09:17:08PM +0400, Valery V. Inozemtsev wrote:
> > > > > Несколько ранее было обнаружено, что sispmctl сегфолтится
> > > > > при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:
> > > > все что ниже 2.6.27 пора закопать. если они как то еще
> > > > работают, то это не на долго (до нового udev)
> > > Если 2.6.18-ovz-rhel закопать, то жизнь остановится. :)
> > она уже остановилась. полноценный gnome-2.28 без нового udev мы
> > не получим
> 
> Замечательно, у нас уже как-то поднимался (и со скандалом
> заминался) вопрос о двух udev.

udev <= 142 пусть себе живет где нибудь в 5.0 вместе с 2.6.18-ovz-rhel

>   Поскольку как понимаю, то
> 2.6.27-ovz в продакшн не годится, а целевые аудитории ovz-rhel
> и gnome-2.28 пересекаются слабо.

ну тут либо 2.6.18-ovz-rhel закапывать, либо сизиф будет не сизиф

> > > Не шути так! :)
> > да я и не начинал
> 
> Да понятно, что невесело, и что делать теперь будем?
> Тут рядом негромко звучит "все на lxc".

-- 
Valery V. Inozemtsev

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Michael Shigorin]

On Sun, Aug 16, 2009 at 10:30:14PM +0400, Valery V. Inozemtsev wrote:
> > Замечательно, у нас уже как-то поднимался (и со скандалом
> > заминался) вопрос о двух udev.
> udev <= 142 пусть себе живет где нибудь в 5.0 вместе с 2.6.18-ovz-rhel
> > Поскольку как понимаю, то 2.6.27-ovz в продакшн не годится, а
> > целевые аудитории ovz-rhel и gnome-2.28 пересекаются слабо.
> ну тут либо 2.6.18-ovz-rhel закапывать, либо сизиф будет не сизиф

Ну это с ldv@ разбирайтесь.  Тут я относительно за сизиф спокоен.
:)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] klibc incompatibilities

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]

On Sun, Aug 16, 2009 at 09:47:54PM +0400, Valery V. Inozemtsev wrote:
> > > > > да, совсем забыл... на самом деле все еще страшнее. для нашего glibc
> > > > > (собранного с хидерами от 2.6.29) нужно ядро 2.6.27 и выше. т.ч. это
> > > > > 2.6.18 все еще работает просто чудом или весь юзерспейс, что там
> > > > > работает, не использует (пока не использует) новые системные вызовы.
> > > > 
> > > > Валера, тот эффект, который ты описываешь, правильно было бы назвать
> > > > glibc ABI break.  Только я этот вопрос специально проверял, и ничего
> > > > подозрительного не выявил.  Так что, пожалуйста, расскажи подробности.
> > > > 
> > > 
> > > вот пример (тот же код и в glibc)
> > > http://git.altlinux.org/people/shrek/packages/?p=klibc.git;a=blob;f=usr/klibc/signalfd.c;h=1edc05d936229b5cbf5b56afc1fb2c0ddf56f458;hb=HEAD
> > > __NR_signalfd4 появился в 2.6.27
> > > есть еще кучка at()
> > > http://git.altlinux.org/people/shrek/packages/?p=klibc.git;a=commitdiff;h=7383280c094de24c926623b3996ce651e9d812d4
> > 
> > klibc - это простая библиотека, которая, в отличие от glibc, не
> > обеспечивает обратной совместимости.  В glibc совсем другой код,
> > при желании можешь посмотреть.
> 
> реализация signalfd в klibc была мной слизана из glibc практически 1:1

Если glibc собран со старыми хедерами ядра, то получится signalfd(),
который всегда будет возвращать ENOSYS.
Если glibc собран с новыми  хедерами ядра, то получится signalfd(),
который будет возвращать ENOSYS только на старых ядрах, которые не
поддерживают signalfd(2).

Если какой-то userspace завязан на signalfd(2), то он будет работать
только на тех ядрах, котрые поддерживают signalfd(2).  Интересно,
кто-нибудь уже заложился на этот signalfd(2) в такой степени?

> > Вопрос, эти новые системные вызовы в безусловной реализации klibc
> > уже где-нибудь используются?  Если да, то начиная с каких сборок?
> 
> они используются в udev >= 143

Т.е. в Сизифе udev ещё не использует эти системные вызовы.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Alexey Borovskoy]

17 августа 2009 г. 7:20 пользователь Michael Shigorin (mike@osdn) написал:
>
> Да понятно, что невесело, и что делать теперь будем?
> Тут рядом негромко звучит "все на lxc".

А как его можно посмотреть?

Re: [sisyphus] klibc incompatibilities

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

On Sun, Aug 16, 2009 at 09:53:35PM +0400, Valery V. Inozemtsev wrote:
> > > klibc - это простая библиотека, которая, в отличие от glibc, не
> > > обеспечивает обратной совместимости.  В glibc совсем другой код,
> > > при желании можешь посмотреть.
> > 
> > реализация signalfd в klibc была мной слизана из glibc практически 1:1
> 
> игра "найди 10 отличий"
> http://git.altlinux.org/people/shrek/packages/?p=klibc.git;a=blob;f=usr/klibc/signalfd.c;h=2ade718cc9e978ba5aebd495b6b2be56e08e4408;hb=HEAD
> http://git.altlinux.org/people/ldv/packages/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/signalfd.c;h=9898f2923122bd0f9efc008bb4b27354ab2da5a2;hb=HEAD

В glibc этот sysdeps/unix/sysv/linux/signalfd.c недавно изменился в
сторону большей обратной совместимости, см. коммит
о7e2253d98c0136d9ad3f7ddd38ec1a2d7d2dc4e


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] klibc incompatibilities

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]

> > > klibc - это простая библиотека, которая, в отличие от glibc, не
> > > обеспечивает обратной совместимости.  В glibc совсем другой код,
> > > при желании можешь посмотреть.
> > 
> > реализация signalfd в klibc была мной слизана из glibc практически 1:1
> 
> Если glibc собран со старыми хедерами ядра, то получится signalfd(),
> который всегда будет возвращать ENOSYS.
> Если glibc собран с новыми  хедерами ядра, то получится signalfd(),
> который будет возвращать ENOSYS только на старых ядрах, которые не
> поддерживают signalfd(2).

что и требовалось доказать

> Если какой-то userspace завязан на signalfd(2), то он будет работать
> только на тех ядрах, котрые поддерживают signalfd(2).  Интересно,
> кто-нибудь уже заложился на этот signalfd(2) в такой степени?

мне известен пока только один - udev >= 143

> > > Вопрос, эти новые системные вызовы в безусловной реализации klibc
> > > уже где-нибудь используются?  Если да, то начиная с каких сборок?
> > 
> > они используются в udev >= 143
> 
> Т.е. в Сизифе udev ещё не использует эти системные вызовы.

в сизифе 141. 142 уже без libvolume_id, а вот 143 с
signalfd/readlinkat/unlinkat/openat/и_пр._at()

-- 
Valery V. Inozemtsev

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Michael Shigorin]

On Sun, Aug 16, 2009 at 05:24:01PM +0300, I wrote:
> Несколько ранее было обнаружено, что sispmctl сегфолтится
> при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:
[...]
> Возможно ли собрать, как понимаю, libusb/libusb-compat таким
> образом, чтобы они работали и на самом старом из официально
> поддерживаемых в сизифе ядер?  Что для этого следует сделать?
> (один из пакетов собирается с linux-libc-headers)

Джентльмены, так всё же?  Как понимаю, с ovz-rhel нам ещё жить
и жить, если только не произойдёт что-то совсем неожиданное.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Alexander Bokovoy]

2009/8/17 Michael Shigorin <mike@osdn.org.ua>:
> On Sun, Aug 16, 2009 at 05:24:01PM +0300, I wrote:
>> Несколько ранее было обнаружено, что sispmctl сегфолтится
>> при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:
> [...]
>> Возможно ли собрать, как понимаю, libusb/libusb-compat таким
>> образом, чтобы они работали и на самом старом из официально
>> поддерживаемых в сизифе ядер?  Что для этого следует сделать?
>> (один из пакетов собирается с linux-libc-headers)
>
> Джентльмены, так всё же?  Как понимаю, с ovz-rhel нам ещё жить
> и жить, если только не произойдёт что-то совсем неожиданное.
Поскольку со стороны libusb никаких реальных действий делать не надо,
максимум, что я могу сделать, это собрать альтернативный пакет
относительно альтернативной версии linux-libc-headers, если ее
кто-нибудь обеспечит.
-- 
/ Alexander Bokovoy

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Michael Shigorin]

On Mon, Aug 17, 2009 at 07:21:44PM +0300, Alexander Bokovoy wrote:
> > Джентльмены, так всё же? Как понимаю, с ovz-rhel нам ещё жить
> > и жить, если только не произойдёт что-то совсем неожиданное.
> Поскольку со стороны libusb никаких реальных действий делать не
> надо, максимум, что я могу сделать, это собрать альтернативный
> пакет относительно альтернативной версии linux-libc-headers,
> если ее кто-нибудь обеспечит.

Я пересобирал libusb с kernel-headers-ovz-rhel -- _кажется_
(сейчас не совсем уверен, а ребутнуть сборочницу не могу),
не помогло, иначе б уже висел FR.  Софтинку с пересобранной
libusb тоже пересобрал, но тут хедеры явно не подсовывал --
вроде как там всё через библиотеку.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]

В Пнд, 17/08/2009 в 18:56 +0300, Michael Shigorin пишет:
> On Sun, Aug 16, 2009 at 05:24:01PM +0300, I wrote:
> > Несколько ранее было обнаружено, что sispmctl сегфолтится
> > при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:
> [...]
> > Возможно ли собрать, как понимаю, libusb/libusb-compat таким
> > образом, чтобы они работали и на самом старом из официально
> > поддерживаемых в сизифе ядер?  Что для этого следует сделать?
> > (один из пакетов собирается с linux-libc-headers)
> 
> Джентльмены, так всё же?  Как понимаю, с ovz-rhel нам ещё жить
> и жить,

и как жить с этой археологической находкой?

>  если только не произойдёт что-то совсем неожиданное.

если этого не произойдет, сизиф лично мне становится не интересен

-- 
Valery V. Inozemtsev

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

On Sun, Aug 16, 2009 at 05:24:01PM +0300, Michael Shigorin wrote:
> 	Здравствуйте.
> Несколько ранее было обнаружено, что sispmctl сегфолтится
> при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:
> 
> ---
> $ strace sispmctl -o 1
> ......
> open("/sys/bus/usb/devices", O_RDONLY|O_NONBLOCK|O_DIRECTORY|
>       O_CLOEXEC) = 3
> getdents(3, /* 14 entries */, 32768)    = 384
> stat("/sys/bus/usb/devices/1-1/descriptors", 0x7fff9270a8a0) = -1
>       ENOENT (No such file or directory)
> open("/sys/bus/usb/devices/1-1/busnum", O_RDONLY) = -1 ENOENT
>       (No such file or directory)
> close(3)                                = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) --- 
> +++ killed by SIGSEGV +++
> ---

$ rpmquery -R sispmctl |grep ^libusb
libusb-0.1.so.4()(64bit)  
$ ldd /usr/bin/sispmctl |awk '/libusb/{print $1}'
libusb-0.1.so.4
libusb-1.0.so.0

Это нормально, что sispmctl использует одновременно libusb и libusb-compat?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Michael Shigorin]

On Mon, Aug 17, 2009 at 08:49:09PM +0400, Dmitry V. Levin wrote:
> $ rpmquery -R sispmctl |grep ^libusb
> libusb-0.1.so.4()(64bit)  
> $ ldd /usr/bin/sispmctl |awk '/libusb/{print $1}'
> libusb-0.1.so.4
> libusb-1.0.so.0

ldd сделать не догадался.

> Это нормально, что sispmctl использует одновременно libusb и libusb-compat?

Не знаю, вообще-то libusb-compat суть обёртка над libusb.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

В Пнд, 17/08/2009 в 20:49 +0400, Dmitry V. Levin пишет:
> On Sun, Aug 16, 2009 at 05:24:01PM +0300, Michael Shigorin wrote:
> > 	Здравствуйте.
> > Несколько ранее было обнаружено, что sispmctl сегфолтится
> > при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:
> > 
> > ---
> > $ strace sispmctl -o 1
> > ......
> > open("/sys/bus/usb/devices", O_RDONLY|O_NONBLOCK|O_DIRECTORY|
> >       O_CLOEXEC) = 3
> > getdents(3, /* 14 entries */, 32768)    = 384
> > stat("/sys/bus/usb/devices/1-1/descriptors", 0x7fff9270a8a0) = -1
> >       ENOENT (No such file or directory)
> > open("/sys/bus/usb/devices/1-1/busnum", O_RDONLY) = -1 ENOENT
> >       (No such file or directory)
> > close(3)                                = 0
> > --- SIGSEGV (Segmentation fault) @ 0 (0) --- 
> > +++ killed by SIGSEGV +++
> > ---
> 
> $ rpmquery -R sispmctl |grep ^libusb
> libusb-0.1.so.4()(64bit)  
> $ ldd /usr/bin/sispmctl |awk '/libusb/{print $1}'
> libusb-0.1.so.4
> libusb-1.0.so.0
> 
> Это нормально, что sispmctl использует одновременно libusb и libusb-compat?

это не sispmctl
$ ldd /lib/libusb-0.1.so.4
	linux-gate.so.1 =>  (0xb7fb0000)
	libusb-1.0.so.0 => /lib/libusb-1.0.so.0 (0xb7f8e000)
	libc.so.6 => /lib/libc.so.6 (0xb7e35000)
	librt.so.1 => /lib/librt.so.1 (0xb7e2c000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xb7e13000)
	/lib/ld-linux.so.2 (0xb7fb1000)

-- 
Valery V. Inozemtsev

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

> Замечательно, у нас уже как-то поднимался (и со скандалом
> заминался) вопрос о двух udev.  Поскольку как понимаю, то
> 2.6.27-ovz в продакшн не годится, а целевые аудитории ovz-rhel
> и gnome-2.28 пересекаются слабо.

целевые аудитории ovz-rhel и libusb (да и всего вставил/вытащил) как бы
совсем не пересекаются

-- 
Valery V. Inozemtsev

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] q: libusb{,-compat} и 2.6.18-ovz-rhel

[Michael Shigorin]

On Mon, Aug 17, 2009 at 09:05:12PM +0400, Valery V. Inozemtsev wrote:
> > Замечательно, у нас уже как-то поднимался (и со скандалом
> > заминался) вопрос о двух udev.  Поскольку как понимаю, то
> > 2.6.27-ovz в продакшн не годится, а целевые аудитории
> > ovz-rhel и gnome-2.28 пересекаются слабо.
> целевые аудитории ovz-rhel и libusb (да и всего
> вставил/вытащил) как бы совсем не пересекаются

Ты не поверишь, но метрах в семи от меня они пересеклись -- там
в сборочный сервер, где есть аккаунт у удалённого разработчика,
воткнута управляемая по USB розетка, деглюкирующая железку, над
прошивкой к которой он работает.

У меня на самом деле есть не очень удобный вариант переткнуть
розетку в офисный сервер под 4.0, но это всё равно останется
ovz-rhel и libusb. :)

Надеюсь, с гномом хотя бы легче, но тут я совсем не теоретизирую.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] q: libusb error handling bug

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]

On Mon, Aug 17, 2009 at 08:49:09PM +0400, Dmitry V. Levin wrote:
> On Sun, Aug 16, 2009 at 05:24:01PM +0300, Michael Shigorin wrote:
> > 	Здравствуйте.
> > Несколько ранее было обнаружено, что sispmctl сегфолтится
> > при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:
> > 
> > ---
> > $ strace sispmctl -o 1
[...]

$ valgrind sispmctl -o 1
[...]
==12345== Invalid read of size 4
==12345==    at 0x5381B9F: usbi_log (core.c:1431)
==12345==    by 0x538724D: sysfs_get_device_list (linux_usbfs.c:924)
==12345==    by 0x5387379: op_get_device_list (linux_usbfs.c:963)
==12345==    by 0x5380ADD: libusb_get_device_list (core.c:560)
==12345==    by 0x4E29F27: usb_find_busses (in /lib64/libusb-0.1.so.4.4.4)
==12345==    by 0x40185B: (within /usr/bin/sispmctl)
==12345==    by 0x504B9DC: (below main) (in /lib64/libc-2.10.1.so)
==12345==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==12345== 
==12345== Process terminating with default action of signal 11 (SIGSEGV)
==12345==  Access not within mapped region at address 0x0
==12345==    at 0x5381B9F: usbi_log (core.c:1431)
==12345==    by 0x538724D: sysfs_get_device_list (linux_usbfs.c:924)
==12345==    by 0x5387379: op_get_device_list (linux_usbfs.c:963)
==12345==    by 0x5380ADD: libusb_get_device_list (core.c:560)
==12345==    by 0x4E29F27: usb_find_busses (in /lib64/libusb-0.1.so.4.4.4)
==12345==    by 0x40185B: (within /usr/bin/sispmctl)
==12345==    by 0x504B9DC: (below main) (in /lib64/libc-2.10.1.so)

(gdb) bt
#0  0x00002b7d2e6b2b9f in usbi_log (ctx=0x0, level=LOG_LEVEL_ERROR, function=0x2b7d2e6bb810 "sysfs_get_device_list", 
    format=0x2b7d2e6bb1e0 "opendir devices failed errno=%d") at core.c:1431
#1  0x00002b7d2e6b824e in sysfs_get_device_list (ctx=0x0, _discdevs=0x7fff7cb6b050, usbfs_fallback=0x7fff7cb6b00c)
    at os/linux_usbfs.c:924
#2  0x00002b7d2e6b837a in op_get_device_list (ctx=0x0, _discdevs=0x7fff7cb6b050) at os/linux_usbfs.c:963
#3  0x00002b7d2e6b1ade in libusb_get_device_list (ctx=0x0, list=0x7fff7cb6b098) at core.c:560
#4  0x00002b7d2e15af28 in usb_find_busses () from /lib64/libusb-0.1.so.4
#5  0x000000000040185c in ?? ()
#6  0x00002b7d2e37c9dd in __libc_start_main () from /lib64/libc.so.6

Это NULL dereference в usbi_log() из libusb.
Вызов libusb_init() завершился неудачно, в результате чего
usbi_default_context остался непроинициализированным.
Остальной код libusb на это не рассчитывает.

Короче говоря, надо исправить обработку ошибок в libusb.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] q: libusb error handling bug

[Alexander Bokovoy]

2009/8/18 Dmitry V. Levin <ldv@altlinux.org>:
> On Mon, Aug 17, 2009 at 08:49:09PM +0400, Dmitry V. Levin wrote:
>> On Sun, Aug 16, 2009 at 05:24:01PM +0300, Michael Shigorin wrote:
>> >     Здравствуйте.
>> > Несколько ранее было обнаружено, что sispmctl сегфолтится
>> > при попытке работы с USB-устройством на 2.6.18-ovz-rhel-alt7:
>> >
>> > ---
>> > $ strace sispmctl -o 1
> [...]
>
> $ valgrind sispmctl -o 1
> [...]
> ==12345== Invalid read of size 4
> ==12345==    at 0x5381B9F: usbi_log (core.c:1431)
> ==12345==    by 0x538724D: sysfs_get_device_list (linux_usbfs.c:924)
> ==12345==    by 0x5387379: op_get_device_list (linux_usbfs.c:963)
> ==12345==    by 0x5380ADD: libusb_get_device_list (core.c:560)
> ==12345==    by 0x4E29F27: usb_find_busses (in /lib64/libusb-0.1.so.4.4.4)
> ==12345==    by 0x40185B: (within /usr/bin/sispmctl)
> ==12345==    by 0x504B9DC: (below main) (in /lib64/libc-2.10.1.so)
> ==12345==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> ==12345==
> ==12345== Process terminating with default action of signal 11 (SIGSEGV)
> ==12345==  Access not within mapped region at address 0x0
> ==12345==    at 0x5381B9F: usbi_log (core.c:1431)
> ==12345==    by 0x538724D: sysfs_get_device_list (linux_usbfs.c:924)
> ==12345==    by 0x5387379: op_get_device_list (linux_usbfs.c:963)
> ==12345==    by 0x5380ADD: libusb_get_device_list (core.c:560)
> ==12345==    by 0x4E29F27: usb_find_busses (in /lib64/libusb-0.1.so.4.4.4)
> ==12345==    by 0x40185B: (within /usr/bin/sispmctl)
> ==12345==    by 0x504B9DC: (below main) (in /lib64/libc-2.10.1.so)
>
> (gdb) bt
> #0  0x00002b7d2e6b2b9f in usbi_log (ctx=0x0, level=LOG_LEVEL_ERROR, function=0x2b7d2e6bb810 "sysfs_get_device_list",
>    format=0x2b7d2e6bb1e0 "opendir devices failed errno=%d") at core.c:1431
> #1  0x00002b7d2e6b824e in sysfs_get_device_list (ctx=0x0, _discdevs=0x7fff7cb6b050, usbfs_fallback=0x7fff7cb6b00c)
>    at os/linux_usbfs.c:924
> #2  0x00002b7d2e6b837a in op_get_device_list (ctx=0x0, _discdevs=0x7fff7cb6b050) at os/linux_usbfs.c:963
> #3  0x00002b7d2e6b1ade in libusb_get_device_list (ctx=0x0, list=0x7fff7cb6b098) at core.c:560
> #4  0x00002b7d2e15af28 in usb_find_busses () from /lib64/libusb-0.1.so.4
> #5  0x000000000040185c in ?? ()
> #6  0x00002b7d2e37c9dd in __libc_start_main () from /lib64/libc.so.6
>
> Это NULL dereference в usbi_log() из libusb.
> Вызов libusb_init() завершился неудачно, в результате чего
> usbi_default_context остался непроинициализированным.
> Остальной код libusb на это не рассчитывает.
>
> Короче говоря, надо исправить обработку ошибок в libusb.
Ok.
-- 
/ Alexander Bokovoy

Re: [sisyphus] q: libusb error handling bug

[Michael Shigorin]

On Tue, Aug 18, 2009 at 06:55:28AM +0300, Alexander Bokovoy wrote:
> > Это NULL dereference в usbi_log() из libusb.
> > Вызов libusb_init() завершился неудачно, в результате чего
> > usbi_default_context остался непроинициализированным.
> > Остальной код libusb на это не рассчитывает.

Спасибо!

> > Короче говоря, надо исправить обработку ошибок в libusb.
> Ok.

Повесить?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] q: libusb error handling bug

[Alexander Bokovoy]

2009/8/18 Michael Shigorin <mike@osdn.org.ua>:
> On Tue, Aug 18, 2009 at 06:55:28AM +0300, Alexander Bokovoy wrote:
>> > Это NULL dereference в usbi_log() из libusb.
>> > Вызов libusb_init() завершился неудачно, в результате чего
>> > usbi_default_context остался непроинициализированным.
>> > Остальной код libusb на это не рассчитывает.
>
> Спасибо!
Это все compat, он много на что не рассчитывает.

>> > Короче говоря, надо исправить обработку ошибок в libusb.
>> Ok.
>
> Повесить?
Да, у меня будет возможность это сделать только ближе к выходным. Плюс
еще патчи от kas@ в очереди стоят.

-- 
/ Alexander Bokovoy