Tráfico del Núcleo #120 For 28 May 2001

There were 415 different contributors. 190 posted more than once. 161 posted last week too.

Ext2 hace getblk+wait_on_buffer para los nuevos bloques de metadatos antes de llenarlos con ceros. Mientras esto es suficiente para un solo procesador, en SMP tenemos la siguiente carrera:

CPU1 CPU2
getblk nos da bh desbloqueado, no actualizado
wait_on_buffer() no hace nada

lee de los bloqueos del dispositivo y comienza la ES

lo ponemos en cero.

los datos del disco sobreescriben nuestros ceros.

lo marcamos como sucios
bdflush escribe los datos antiguos (que _no_ son ceros) de regreso al disco.

	CPU1	CPU2
getblk nos da bh desbloqueado, no actualizado wait_on_buffer() no hace nada
	lee de los bloqueos del dispositivo y comienza la ES
lo ponemos en cero.
	los datos del disco sobreescriben nuestros ceros.
lo marcamos como sucios bdflush escribe los datos antiguos (que _no_ son ceros) de regreso al disco.

Resultado: basura en los bloques de metadatos. Compostura propuesta: lock_buffer()/unlock_buffer() alrededor de memset()/mark_buffer_uptodate() en lugar de wait_on_buffer() antes de ellos.

Andrea Arcangeli confirmó la carrera, y especuló que probablemente otros sistemas de ficheros también eran afectados. Chris Mason confirmó que reiserfs tenía la carrera; agregó que estaba trabajando en una compostura, pero tenía que asegurarse que no dañaría al código de balanceo.

Linus Torvalds entró a la discusión, diciendo que vió la carrera, pero no vió como podía ser activada. Parecía como algo sin importancia para él. Dijo, "Ahora, no estoy en desacuerdo con tu parche (es sólo obviamente más limpio bloquearlo adecuadamente), pero no pienso que sea un bug real." Agregó, "Acostumbrábamos tener a "breada()" haciendo lectura en avance física que podría haber activado esto, pero desde hace tiempo que que nos deshicimos de eso. ¿O estoy pasando algo por alto?" Alexander señaló que simplemente haciendo un 'dd' desde el disco podría activar la carrera. Cierto, reconoció, en ese caso particular 'dd' solo se podría esperar que produjera basura, y así nadie en su sano juicio lo haría, pero dijo:

Supongamos que /dev/hda1 es propiedad de root.disks y los permisos son 640. Está montado para lectura-escritura.

El proceso foo pertenece a pfy.staff. PFY está incluído en los discos, pero no tiene root. Proclamo que no debería ser capaz de causar corrupción de sistema de fichero en /dev/hda1.

Actualmente foo _puede_ causar tal corrupción, aún si no tiene nada semejante a permisos de escritura para el dispositivo en cuestión.

En mi opinión esto está mal. No estoy diciendo que sea un problema real de seguridad. No estoy diciendo que PFY no es idiota o que sus acciones no tienen ningún sentido. De cualquier forma, pienso que esta situación está completamente mal cuando él puede hacerlo sin permiso de escritura al dispositivo.

Andrea coincidío. Tuvieron un pequeño ir y venir, y en un punto Linus remarcó:

Noten que pienso que todos esos argumentos son bastante ambiguos. Haciendo cosas como "dump" en un sistema de ficheros en vivo es estúpido y peligroso (en mi opinión es estúpido y peligroso usar "dump" _después de todo_, pero eso es otra discusión completa por sí sola), y realmente no hay usos válidos para abrir un dispositivo de bloques que ya está montado. Más importante, no creo que nadie lo haga.

El hecho de que _puedes_ hacerlo hace válido al parche, y coincido con Al en el factor de "menos sorpresas". Ya he aplicado el parche, de hecho. Pero el hecho es que nadie nunca debería hacer las cosas que causarían problemas.

La discusión continuó, con varias sugerencias de acciones legítimas que podrían activar la carrera; algunas de las cuales causaron carcajadas en ambos bandos.

Jacky Liu seguía experimentando lo que parecían ser bloqueos aleatorios cada par de días bajo 2.4.4; Vincent Stemen confirmó:

He estado experimentando estos mismos problemas desde la versión 2.4.0. Aunque, pienso que ha mejorado un poco en 2.4.4, aún se bloquea. El problema parece estar relacionado con la administración de memoria y/o el espacio de intercambio, y parece que lo hace primariamente en máquinas con más de 128Mb de RAM. Aunque, no lo he probado lo suficientemente sistemático para confirmarlo.

He estado monitoreando constantemente el uso de memoria con el medidor de uso de memoria de gnome y noté que mientras el espacio de intercambio crece nunca es liberado de regreso. Puedo matar la mayoría de las aplicaciones grandes, como netscape, xemacs, etc, y será liberada muy poca memoria o nada. Una vez que el espacio de intercambio está lleno después de unos cuantos días, mi máquina se bloqueará.

Si apago todo el espacio de intercambio o lo prendo y lo apago periódicamente para limpiar el espacio de intercambio antes de que quede lleno, parece que no experimienta los bloqueos.

Estoy corriéndolo en un AMD K6-400 con 256 Mb de RAM pero he experimentado estos problemas también con otras varias máquinas.

Alan Cox replicó cripticamente, "El manejo del espacio de intercambio en 2.4 está algo atascado por el momento." Agregó, "Puedo darte un pequeño parche que compondrá los bloqueos y en lugar de eso matará procesos que excedan la memoria pero obviamente no es la compostura correcta 8)" Despúes, también dijo, "He cambiado mi computadora de escritorio de regreso a 2.2 un rato hasta que la MV funcione." ¡Ouch!

Como probablemente muchos de ustedes saben, hemos recibido críticas desde hace unas cuantas semanas sobre nuestra política de parches del núcleo Linux que causa que el código de LVM del núcleo estándard difiera del que nosotros liberamos directamente.

Para evitar esta diferencia proveeremos ahora parches más pequeños y más frecuentes. Ya hemos comenzado con un subconjunto de cerca de 50 parches necesarios.

Aún cuando tenemos el amable apoyo de Alan Cox para hacer que tengan calidad asegurada y sean integrados, la sola cantidad de parches tomará por lo menos unas cuantas semanas para hacer que entren.

Esto conduce al dilema, que el tratar de evitar mayores diferencias entre nuestras versiones de LVM y el código del núcleo estándard nos forzaría a posponer de manera acorde la versión de LVM 1.0 pendiente lo cual por otra parte es inconveniente para la base de usuarios de LVM.

En vista de esta situación quisiéramos saber su opinión en la siguiente petición: ¿es aceptable liberar 1.0 pronto *antes* de que todos los parches que alcancen el estado del código 1.0 estén en el núcleo común (asumiendo que los proveemos con nuestra versión como siempre lo hemos hecho antes)?

Recopilaremos sus respuestas por algunos días y enviaremos la conclusión a las listas.

Jeff Garzik replicó, "¿Los están enviando todos en un solo lote (50 e-mails a Linus al mismo tiempo), o enviándo a Linus unos cuantos a la vez? Podría ser más rápido enviarle un lote (aunque no necesariamente 50), notando con cada e-mail, después de la descripción de cada parche, que el parche en particular depende de los parches C, F, y que H debe haber sido aplicado antes. De esa forma Linus puede aplicar 8 de 10 parches, y entonces se sincronizan con él y comienza el ciclo de nuevo."

Esto compone un bug en la función autoconfig_startech_uarts en serial.c. El problema es que se escriben 0's a los registros de la tasa de baudaje para detectar un XR16C850 o un XR16C854. Esto hace que el Exar ST16C654 haga cataplúm. El guardar y restaurar los registros de la tasa de baudaje después de la prueba lo compone.

Estoy asumiendo que la detección de XR16C85[04] funciona tal cual y no necesita la tasa de baudaje original restaurada. Si estoy mal, reescribiré el parche.

Stuart MacDonald, que había trabajado en el código en cuestión, pidió clarificación y ofreció algunas críticas sobre el parche. En particular, quiso saber los números de versión para el controlador serial, el núcleo, y la distribución que Val usó para lograr que el Exar hiciera "cataplúm". Sintió que el parche de Val era bueno, pero quería entender la conducta que Val vió. Val replicó que estaba usando el controlador serial versión 5.05a (2001-03-20) con MANY_PORTS SHARE_IRQ SERIAL_PCI activados, y el núcleo versión 2.4.5-pre1. Fueron y vinieron, pero Stuart no pudo reproducir la caída.

Linus Torvalds ha solicitado una moratoria en la asignación de nuevos números de dispositivo. Su esperanza es que emergerá como resultado un nuevo y mejorado método para asignación de espacio de dispositivo.

Alan Cox ha solicitado que yo mantenga un registro bifurcado para su árbol de parches del núcleo -ac. Concedí en hacerlo una vez que haya bifurcado la versión "final" del registro para el árbol de Linus. En ese momento procesaré el trabajo atrasado sólo para el beneficio del registro -ac. Por favor tengan paciencia hasta que haga que esto suceda.

Por favor noten que esta no es mi decisión (de hecho, tengo serias preocupaciones con esto). En particular la coordinación del espacio de nombres /dev aún aplica.

Aquí está mi sugerencia para una solución.

Una vez que pase a través de un montón de problemas de controladores de red, quiero presentar una prueba de controlador de dispositivos de bloque (congela un blkdev en el tiempo). Para esto, necesito un número mayor de bloque. Después de oir acerca del congelamiento de números de dispositivo, me preguntaba si esta solución funciona:

Registrar el dispositivo de bloque utilizando la API existente, y obtener un número mayor asignado dinámicamente. Exportar un pequeño ramfs que enumere todos los nodos de dispositivo. Montado en /dev/snap, /dev/snap/0 sería el primer blkdev para el mayor asignado dinámicamente de snap. (Al Viro dijo que él tiene el esqueleto del código para crear tal sf, si recuerdo correctamente)

Esta solución

evita atascar un poco más a /proc [había considerado proc_mknod() hasta que viro me habló de eso]
no requiere mayores y menores centralizadamente asignados.
no requiere devfs. casi todas las distribuciones salen sin él hasta donde yo sé, y

cambiar a él no es un proceso para desvelarse, y requiere que devfsd sea útil en la vida real.

H. Peter replicó que la propuesta de Jeff, de todas maneras, "no maneja permisos, ni provee de un espacio de nombres sano (expone demasiados detalles de implementación internos en la interfaz -- en particular, el controlador se vuelve parte del espacio de nombres, y regularmente los dispositivos se mueven entre los controladores.)" Pero Jeff replicó que esto ha sido vigilado por devfs y devfsd. Pero Alan Cox dijo, "Con respecto a devfsd Al Viro bien ha reportado carreras en él por largo tiempo que no creo que Richard haya tenido tiempo de componer ni alguien más haya compuesto. ¿Cuál es el estado de devfs en eso?" Richard Gooch replicó, "De hecho, era devfs, no devfsd sobre el cual Al se quejaba. Afortunadamente estas carreras son difíciles de activar sin tratar deliberadamente de activarlas, de otra forma estaría inundado de reportes de bugs :-/" Él agregó con respecto al estado, "Me estoy acercando mucho ahora. El pasado fin de semana fue mi primera vez en eras que he tenido un fin de semana ininterrumpido para hackear en Linux y no he tenido otras cosas realmente urgentes con las cuales lidiar."

En este punto surgió de nuevo la discusión de incrementar el tamaño de dev_t, con Linus iniciándola:

un dev_t de 32-bit (o 64-bit) NO hace nada fácil manejar los permisos de nada como esto de cualquier manera. Miren el revoltijo que es actualmente /dev. Imagínenlo en un orden peor de magnitud.

Los números de dispositivos grandes _no_ son una solución. Aceptaré uno de 32-bit, pero no más, y _no_ aceptaré más una aproximación de "administrar manualmente". Ha transcurrido largo rato para que llegue a decir "No". Lo cual he hecho. Si no pueden lograr manejar automáticamente la cosa con un guión, no obtendrán un número de dispositivo mayor fijo sólo porque son flojos.

Fin de la discusión.

He estado dudando entre trabajar tanto en los núcleos -ac como en el árbol -linus, pero este es muy buen argumento para quedarse con -ac y tan sólo ignorar el árbol -linus...

Veamos qué sucede...

El tiempo hará esta decisión. Linus amablemente nos ha dado todo el poder de votar con nuestros pies. Una cosa que absolutamente rechazo hacer es dejar que un desacuerdo sore la implementación de un dispositivo específico se convierta en una excusa para una diferencia más amplia en los árboles.

Así que sí -ac mantendrá mayores estáticos pero el resto intentaré mantenerlo mezclado con Linus y rastrear de cerca su árbol. Ciertamente no ignorando el árbol -linus.

Rik replicó, "Coincido. De cualquier forma, si esta cosa significa que no puedo usar el árbol -linus sin devfs, entonces eso significa también que mis cosas de MV solamente serán probadas en núcleos -ac..."

Alan también replicó directamente a Linus, con respecto a los números de dispositivo, diciendo, "en ese asunto estoy tan convencido de que estás mal que estoy preparado a mantener la conducta sensible de dispositivos Unix en -ac indefinidamente." Agregó que tampoco le gustó el enfoque de "fin de la discusión" de Linus. Dijo (en el curso de varios mensajes) que Linus estaba cometiendo un error similar al del SO Plan9 -- un sistema hermoso, en su opinión, pero sin una base de usuarios significativa porque tenía problemas de compatibilidad. Acerca de la voluntad de los vendedores de continuar los las incompatibilidades de Linux, dijo, "Apuesto que los vendedores en cuestión no piensan más que el sol brilla en la espalda de linus." Esto no impresionó a Linus, quien replicó en un punto, "Sé lo que quiero, y he dejado que el relajo actual continúe por demasiado tiempo. Si produce algún dolor componerlo, entonces que sea. Necesita ser compuesto, aún si la gente de repente empieza a pensar que la luz de mi c*l* disminuye un poco. Está bien."

En otro lugar continuó una larga discusión acerca de las mejores maneras para manejar los números de dispositivo, devfs y la compatibilidad.

Linus, el parche es el primer bloque de cosas de rootfs. He tratado de hacerlo tan pequeño como sea posible - todo lo que hace es la adición de la raíz absoluta en ramfs y los cambios necesarios para mount_root/change_root/sys_pivot_root y follow_dotdot. La raíz real es montada sobre la "absoluta".

Las cosas más interesantes viven en las siguientes partes - una vez que tengamos rootfs nos podemos deshacer de mucha basura en fs/super.c sobre montar la raíz real y cambiarla después de initrd. En particular, podremos deshacernos de la bandera umount_root en do_umount() y kill_super() que permite un manejo mucho más limpio de montajes de vfs. Trataré de alimentar estas cosas en piezas pequeñas y obvias.

Es transparente para el espacio de usuario - el único efecto visible es una línea extra en /proc/mounts. Más aún, es transparente para el núcleo - las únicas funciones que realmente importan son aquéllas que hacen el primer montaje.

Un punto que podría ser mejor hecho de forma diferente - ya que necesitamos ramfs para arrancar he hecho que fs/Config.in declare CONFIG_RAMFS como define_bool CONFIG_RAMFS y. Si ramfs crece (v.g. obtiene parches de límite de recursos de -ac) mejor podríamos hacer permanentemente una variante mínima en el núcleo (llamándola rootfs) y haciendo que ramfs use métodos de rootfs. Es un asunto completamente separado, así que lo he hecho en la forma más simple para el tiempo actual.

Linus Torvalds y Alan Cox sintieron que esto definitivamente era material de 2.5, aunque Linus agregó que el parche mismo se veía OK. Alexander sintió que el parche era lo suficientemente local para entrar en 2.4, aunque él no tenía fuerte preferencia en cualquiera de las opciones. En otro lugar, añadió:

hace las composturas de carreras en fs/super.c más fáciles y necesitaremos eso en 2.4 (o, por lo menos, transportado hacia atrás a 2.4 en algún punto)
es compatible hacia atrás.
permite matar toneladas de la fealdad en rd.c en una forma obviamente correcta, para valores de corrección obvios iguales a "conducta probablemente equivalente al código anterior"

Pienso que está OK para 2.4, pero yo estoy obviamente inclinado (más por el hecho de que sé que tanto permite limpiar sin romper ninguna compatibilidad, incluyendo compatibilidad binaria en el núcleo). Está en ustedes, de cualquier forma.

Hubo un poco de discusión técnica sobre en parche en sí, y el hilo de discusión terminó.

He documentado el inicio del núcleo Linux en x86/i386/IA-32 (después de los cargadores). Es bastante largo, así que tal vez haya mucho detalle ahí y podría cortar algo si pareciera ser necesario.

Son bienvenidos comentarios, retroalimentación, correcciones y adiciones. Como lo digo en la introducción, espero que alguno de ustedes (o nosotros) lo encuentre útil/de ayuda.

Está visible en http://rddunlap.home.att.net/linit/lin240_init_x86.html

La versión 0.3.2 of JFS se ha hecho disponible el día de hoy.

Después de dejar 32 el 18 de Mayo de 2001 (jfs-0.3.2-patch.tar.gz) incluye composturas al sistema de ficheros y utilidades.

Función y Composturas en la versión 0.3.2

Se eliminó el mensaje de advertencia de fsck cuando la partición es montada como sólo lectura
So compuso assert(mp->count) jfs_metapage.c reporte 675! como problema de enlaces duros en drop 31 (dtDeleteUp estaba descartando el metapage_t erróneo.)
Se compuso problema de falta de segmento durante la creación de enlaces duros.
Se compuso el colgado de dbench, que hacía que los bloqueos de transacción no fueran liberados
Se agregó soporte para manejar correctamente la sólo lectura y el remontaje del sistema de ficheros.

Para más detalles acerca de los problemas compuestos, por favor vean el README.

Este bug deshabilita incondicionalmente una pregunta de configuración -- y es tan antiguo que se ha propagado a través de tres ficheros de transporte, sin que ninguna de las gentes que hicieron el cortar y copiar para los últimos dos lo notara.

Este tipo de cosas nunca surgirán en CML2, porque el compilador arrojaría una advertencia de símbolo indefinido en BLK_DEV_ST. Es grande la tentación de enfrascarme en comentarios sarcásticos a expensas de la gente que aún piensa que CML2 es un dolor innecesario en el trasero. Pero me reprimiré. Esta vez.

John Levon agregó, "de hecho esto estaba también originalmente en i386. Yo lo noté y lo compuse, nunca pensé siquiera acerca de las otras arquitecturas." Mike Galbraith sugirió, "Erm.. si este bug es _tan antiguo_ y nadie lo notó, ¿no es la compostura correcta sólo borrar la opción muerta?" No hubo respuesta a esto, pero en otro lado Benedict Bridgwater objetó sarcásticamente:

¿Así que una limitación de las herramientas CML1 justifica el lenguaje CML2?

Creo que el siguiente error que se encuentre en el intérprete de Python2 justificará escribir CML3 en FORTRAN.

Miles Lane condescendió con Benedict en tonos mesurados, con, "Si recuerdo correctamente, Eric salió con la idea de CML2 desde hace un año, proveyendo algo de código rudimentario y pidiendo retroalimentación. Ha parecido, por largo tiempo, que hay consenso entre la mayoría de los desarrolladores del núcleo que había problemas serios con CML1 y que necesitaban ser eliminados. Hay tantas cosas que CML1 no nos permitiría hacer que serán posibles con CML2 (subconjuntos del árbol de código, etc). No pienso que la afirmación de Eric sobre este bug en particular (tan vergonzoso como para cubrirnos la cabeza con una bolsa) signifique que él piense que esta sola razón justifica la migración hacia CML2. Hay una gran cantidad de buenas razones para la migración. No es, tal vez, una solución perfecta, pero esta es una que Eric ha implementado durante un año lleno de esfuerzo, con total conocimiento de la comunidad de desarrollo del núcleo y con una invitación abierta para contribuciones y retroalimentación. Sermonear sobre eso ahora parece tardío y de poca ayuda. Sería más útil si ayudaras a Eric a mejorar CML2, ya que parece haber acuerdo de que será usado en 2.5." Pero Benedict argumentó, "CML2 por sí mismo parece estar bien justificado (¡aunque no en términos de un diagnóstico de que las herramientas CML1 pueden ser cambiadas para generar!), pero no hay razón para que las herramientas que utilicen las reglas basadas en CML2 no puedan presentar un *superconjunto* de la funcionalidad existente. Para presentar una IU aligerada destinada para la "Tía Millie" o cualquiera contra las protestas de la audiencia de la herramienta del núcleo principal tiene sentido nulo para mí." Pero Keith Owens increpó, "¿Cuántas veces tenemos que decir esto? CML2 da soporte a todos desde la Tía Millie (modo novato) hasta configuraciones de máquina no estándares (modo experto) hasta Linus (vi .config, make oldconfig). Escoje el nivel de configuración que necesitas." Fin del hilo de discusión.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	26 Apr 2001 - 18 May 2001	(91 posts)	Carrera De SMP En ext2
2.	9 May 2001 - 15 May 2001	(14 posts)	Problemas Serios Con Los Núcleos 2.4 Actuales
3.	11 May 2001 - 16 May 2001	(19 posts)	Política De Desarrollo De LVM
4.	11 May 2001 - 17 May 2001	(8 posts)	Compostura Para Exar ST16C654 En Las Series Estables
5.	14 May 2001 - 21 May 2001	(365 posts)	Números De Dispositivo; Descontento De Desarrolladores
6.	16 May 2001	(21 posts)	Nuevo rootfs Para 2.5
7.	18 May 2001	(1 post)	Documento De Inicio De Linux En IA-32 Disponible
8.	18 May 2001	(1 post)	JFS 0.3.2 Disponible
9.	19 May 2001	(8 posts)	Bug De Configuración Muy Antiguo; Discusión De CML2

Tráfico del Núcleo #120 For 28 May 2001

By Zack Brown

Translated By: Cristian Othón Martínez Vera