FYI: Userland breakage caused by udev bind commit

Hi, I am the maintainer of libmtp and libgphoto2 Some months ago I was made aware of this bug: https://bugs.kde.org/show_bug.cgi?id=387454 This was fallout identified to come from this kernel commit: commit 1455cf8dbfd06aa7651dcfccbadb7a093944ca65 Author: Dmitry

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 06:49:20PM -0500, Theodore Ts'o wrote: > On Tue, Nov 28, 2017 at 03:29:01PM -0800, Kees Cook wrote: > > > So in these two cases, if the kernel was built w/o modules, and HDLC > > > and DCCP was built-in, you'd be screwed, then? > > > > Sure, but that's not the common

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 06:49:20PM -0500, Theodore Ts'o wrote: > On Tue, Nov 28, 2017 at 03:29:01PM -0800, Kees Cook wrote: > > > So in these two cases, if the kernel was built w/o modules, and HDLC > > > and DCCP was built-in, you'd be screwed, then? > > > > Sure, but that's not the common

Re: [oss-security] Linux kernel ping socket / AF_LLC connect() sin_family race

people relatively > inattentive ("compiles with the new interfaces and still works? must be > correct"), compared to when writing new code. > > Anyhow, I share some responsibility for this mess, for having advocated > this patch being forward-ported and merged back then. I still like > having this functionality and its userspace security benefits... but I > don't like the kernel bugs. > > Alexander > -- Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real <meiss...@suse.de>

Re: [oss-security] Linux kernel ping socket / AF_LLC connect() sin_family race

people relatively > inattentive ("compiles with the new interfaces and still works? must be > correct"), compared to when writing new code. > > Anyhow, I share some responsibility for this mess, for having advocated > this patch being forward-ported and merged back then. I still like > having this functionality and its userspace security benefits... but I > don't like the kernel bugs. > > Alexander > -- Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real

authenc methods vs FIPS in light of unencrypted associated data

Hi, In February I already tagged some authenc ciphers for FIPS compatibility. I currently revisit this to get testmgr running all the tests in strict FIPS mode. The authenc() class is troublesome. There is a HASH + ENC part of this method, but you can also add associated data, which is not

authenc methods vs FIPS in light of unencrypted associated data

Hi, In February I already tagged some authenc ciphers for FIPS compatibility. I currently revisit this to get testmgr running all the tests in strict FIPS mode. The authenc() class is troublesome. There is a HASH + ENC part of this method, but you can also add associated data, which is not

[PATCH] crypto: allow rfc3686 aes-ctr variants in fips mode.

RFC 3686 CTR in various authenc methods. rfc3686(ctr(aes)) is already marked fips compliant, so these should be fine. Signed-off-by: Marcus Meissner <meiss...@suse.de> --- crypto/testmgr.c | 16 1 file changed, 16 insertions(+) diff --git a/crypto/testmgr.c b/crypto/tes

[PATCH] crypto: allow rfc3686 aes-ctr variants in fips mode.

RFC 3686 CTR in various authenc methods. rfc3686(ctr(aes)) is already marked fips compliant, so these should be fine. Signed-off-by: Marcus Meissner --- crypto/testmgr.c | 16 1 file changed, 16 insertions(+) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index 190a290

[PATCH] crypto: fips: allow more ipsec related methods

IPSEC for aes-ctr requests: authenc(digest_null,rfc3686(ctr(aes))) which can be used in FIPS mode. rfc3686(ctr(aes)) is already allowed for FIPS usage. I also allowed "digest_null" for FIPS usage. Signed-off-by: Marcus Meissner --- crypto/testmgr.c | 5 + 1 file

[PATCH] crypto: fips: allow more ipsec related methods

IPSEC for aes-ctr requests: authenc(digest_null,rfc3686(ctr(aes))) which can be used in FIPS mode. rfc3686(ctr(aes)) is already allowed for FIPS usage. I also allowed "digest_null" for FIPS usage. Signed-off-by: Marcus Meissner <meiss...@suse.de> --- crypto/testmg

[PATCH] crypto: mark authenticated ctr(aes) also as FIPS able

(2nd try that adds missing , to build.) Signed-off-by: Marcus Meissner --- crypto/testmgr.c | 16 1 file changed, 16 insertions(+) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index ae8c57fd..7d66cf8 100644 --- a/crypto/testmgr.c +++ b/crypto/testmgr.c @@ -2143,6 +2143,10

[PATCH] crypto: mark authenticated ctr(aes) also as FIPS able

(2nd try that adds missing , to build.) Signed-off-by: Marcus Meissner <meiss...@suse.de> --- crypto/testmgr.c | 16 1 file changed, 16 insertions(+) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index ae8c57fd..7d66cf8 100644 --- a/crypto/testmgr.c +++ b/crypto/tes

Re: [PATCH 2/2] crypto: testmgr: mark more algorithms as FIPS compliant

On Fri, Feb 05, 2016 at 02:41:01PM +0100, Stephan Mueller wrote: > Am Freitag, 5. Februar 2016, 14:22:25 schrieb Marcus Meissner: > > Hi Marcus, > > >Some more authenc() wrapped algorithms are FIPS compliant, tag > >them as such. > > Is this patch a duplica

[PATCH] crypto: testmgr: mark more algorithms as FIPS compliant

Some more authenc() wrapped algorithms are FIPS compliant, tag them as such. Signed-off-by: Marcus Meissner --- crypto/testmgr.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index ff6a799..b0cbad8 100644 --- a/crypto/testmgr.c +++ b/crypto

[PATCH 2/2] crypto: testmgr: mark more algorithms as FIPS compliant

Some more authenc() wrapped algorithms are FIPS compliant, tag them as such. Signed-off-by: Marcus Meissner --- crypto/testmgr.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index ff6a799..b0cbad8 100644 --- a/crypto/testmgr.c +++ b/crypto

[PATCH 2/2] crypto: testmgr: mark more algorithms as FIPS compliant

Some more authenc() wrapped algorithms are FIPS compliant, tag them as such. Signed-off-by: Marcus Meissner <meiss...@suse.de> --- crypto/testmgr.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index ff6a799..b0cbad8 100644 --- a/crypto/tes

[PATCH] crypto: testmgr: mark more algorithms as FIPS compliant

Some more authenc() wrapped algorithms are FIPS compliant, tag them as such. Signed-off-by: Marcus Meissner <meiss...@suse.de> --- crypto/testmgr.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index ff6a799..b0cbad8 100644 --- a/crypto/tes

Re: [PATCH 2/2] crypto: testmgr: mark more algorithms as FIPS compliant

On Fri, Feb 05, 2016 at 02:41:01PM +0100, Stephan Mueller wrote: > Am Freitag, 5. Februar 2016, 14:22:25 schrieb Marcus Meissner: > > Hi Marcus, > > >Some more authenc() wrapped algorithms are FIPS compliant, tag > >them as such. > > Is this patch a duplica

[PATCH] crypto: mark authenticated ctr(aes) also as FIPS able

Signed-off-by: Marcus Meissner --- crypto/testmgr.c | 16 1 file changed, 16 insertions(+) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index ae8c57fd..ff6a799 100644 --- a/crypto/testmgr.c +++ b/crypto/testmgr.c @@ -2143,6 +2143,10 @@ static const struct alg_test_desc

[PATCH] crypto: mark authenticated ctr(aes) also as FIPS able

Signed-off-by: Marcus Meissner <meiss...@suse.de> --- crypto/testmgr.c | 16 1 file changed, 16 insertions(+) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index ae8c57fd..ff6a799 100644 --- a/crypto/testmgr.c +++ b/crypto/testmgr.c @@ -2143,6 +2143,10 @@ static const

PATCH: scsi: make scsi reset permissions more relaxed (RFC)

t; bus -> host resetting if one fails.) Signed-off-by: Marcus Meissner Ciao, Marcus --- drivers/scsi/scsi_ioctl.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/scsi_ioctl.c b/drivers/scsi/scsi_ioctl.c index d9564fb..770720e 100644 --- a/dri

PATCH: scsi: make scsi reset permissions more relaxed (RFC)

- host resetting if one fails.) Signed-off-by: Marcus Meissner meiss...@suse.de Ciao, Marcus --- drivers/scsi/scsi_ioctl.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/scsi_ioctl.c b/drivers/scsi/scsi_ioctl.c index d9564fb..770720e 100644 --- a/drivers

[PATCH] tokenring/3c359.c: fixed array index problem

Hi, I tried to send this to netdev and various maintainers, but they seem not to have seen it. Please add to -mm and have it merged somewhere. The xl_laa array is just 6 bytes long, so we should substract 10 from the index, like is also done some lines above already. Signed-Off-By: Marcus

[PATCH] tokenring/3c359.c: fixed array index problem

Hi, I tried to send this to netdev and various maintainers, but they seem not to have seen it. Please add to -mm and have it merged somewhere. The xl_laa array is just 6 bytes long, so we should substract 10 from the index, like is also done some lines above already. Signed-Off-By: Marcus

Re: [2.6 patch] kernel/audit.c: change the exports to EXPORT_SYMBOL_GPL

On Sun, Jul 29, 2007 at 11:40:33AM -0700, Arjan van de Ven wrote: > On Sun, 2007-07-29 at 17:02 +0200, Adrian Bunk wrote: > > This patch changes some completely unused audit exports from > > EXPORT_SYMBOL to EXPORT_SYMBOL_GPL. > > > > They are still completely unused, but hopefully some of the

Re: [2.6 patch] kernel/audit.c: change the exports to EXPORT_SYMBOL_GPL

On Sun, Jul 29, 2007 at 11:40:33AM -0700, Arjan van de Ven wrote: On Sun, 2007-07-29 at 17:02 +0200, Adrian Bunk wrote: This patch changes some completely unused audit exports from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL. They are still completely unused, but hopefully some of the

Re: [PATCH try #3] security: Convert LSM into a static interface

In article <[EMAIL PROTECTED]> you wrote: > Convert LSM into a static interface, as the ability to unload a security > module is not required by in-tree users and potentially complicates the > overall security architecture. > > Needlessly exported LSM symbols have been unexported, to help reduce

Re: [PATCH try #3] security: Convert LSM into a static interface

In article [EMAIL PROTECTED] you wrote: Convert LSM into a static interface, as the ability to unload a security module is not required by in-tree users and potentially complicates the overall security architecture. Needlessly exported LSM symbols have been unexported, to help reduce API

Re: revert PIE randomization?

On Sat, Jan 06, 2007 at 10:45:05PM +0100, Ingo Molnar wrote: > > * Marcus Meissner <[EMAIL PROTECTED]> wrote: > > > > You're right. I'm inclined to just revert it, modulo some comments > > > from others. Marcus? > > > > After thinking about this

Re: revert PIE randomization?

On Sat, Jan 06, 2007 at 01:04:02PM -0800, Linus Torvalds wrote: > > > On Sat, 6 Jan 2007, Hugh Dickins wrote: > > > > Isn't that randomization, anywhere from 0x1 to ELF_ET_DYN_BASE, > > sure to place the ET_DYN from time to time just where the comment says > > it's trying to avoid? I

Re: revert PIE randomization?

On Sat, Jan 06, 2007 at 01:04:02PM -0800, Linus Torvalds wrote: On Sat, 6 Jan 2007, Hugh Dickins wrote: Isn't that randomization, anywhere from 0x1 to ELF_ET_DYN_BASE, sure to place the ET_DYN from time to time just where the comment says it's trying to avoid? I assume that

Re: revert PIE randomization?

On Sat, Jan 06, 2007 at 10:45:05PM +0100, Ingo Molnar wrote: * Marcus Meissner [EMAIL PROTECTED] wrote: You're right. I'm inclined to just revert it, modulo some comments from others. Marcus? After thinking about this, yes. I would rather have a working range used here

PATCH: cciss small pci id table patch

Hi, The cciss driver in 2.4.5-ac19 is missing the terminating {0,}. Ciao, Marcus Index: drivers/block/cciss.c === RCS file: /build/mm/work/repository/linux-mm/drivers/block/cciss.c,v retrieving revision 1.23 diff -u -r1.23 cciss.c

Re: Why we need LDT at all in 2.2 kernels ??

In article <[EMAIL PROTECTED]> you wrote: > Hi, > In 2.2 kernel do we really need its own LDT (not default_ldt) for every > process (no mm sharing) ?? > In what circumstances a process may need its own LDT ?? When using the Windows Emulator WINE and related projects (WordPerfect 2000) for

Re: Why we need LDT at all in 2.2 kernels ??

In article [EMAIL PROTECTED] you wrote: Hi, In 2.2 kernel do we really need its own LDT (not default_ldt) for every process (no mm sharing) ?? In what circumstances a process may need its own LDT ?? When using the Windows Emulator WINE and related projects (WordPerfect 2000) for

PATCH: cciss small pci id table patch

Hi, The cciss driver in 2.4.5-ac19 is missing the terminating {0,}. Ciao, Marcus Index: drivers/block/cciss.c === RCS file: /build/mm/work/repository/linux-mm/drivers/block/cciss.c,v retrieving revision 1.23 diff -u -r1.23 cciss.c

BUG: 2.4.x NFS client mmap race

Hi, While debugging a rather strange WINE problem I came across a 2.4.x NFS race condition. I trimmed down the WINE code to a very small testcase, attached below, which has following test patterns: ext2 local : SUCCESS 2.4.5-ac6 -> 2.2.10 (unfsd)

BUG: 2.4.x NFS client mmap race

Hi, While debugging a rather strange WINE problem I came across a 2.4.x NFS race condition. I trimmed down the WINE code to a very small testcase, attached below, which has following test patterns: ext2 local : SUCCESS 2.4.5-ac6 - 2.2.10 (unfsd)

PATCH: ns558 bugfix / CSC ids

Hi, I have added two CSC function ids to the ISAPNP joystick probing. CSC cards use a lot of varying ids for the functions, but in my set of data, 0010 and 0110 are always 'CTL'Game Controllers. One bugfix: port->size must be set, or the release_region on rmmod ns558 fails badly. Tested on IBM

PATCH: ns558 bugfix / CSC ids

Hi, I have added two CSC function ids to the ISAPNP joystick probing. CSC cards use a lot of varying ids for the functions, but in my set of data, 0010 and 0110 are always 'CTL'Game Controllers. One bugfix: port-size must be set, or the release_region on rmmod ns558 fails badly. Tested on IBM

Re: ln -s broken on 2.4.5

On Wed, May 30, 2001 at 10:49:18PM +0100, Alan Cox wrote: > > The problem is only there if you specify a directory for the linked to > > component. > > > > [marcus@wine /tmp]$ strace -f ln -s fupp/berk xxx > > execve("/bin/ln", ["ln", "-s", "fupp/berk", "xxx"], [/* 39 vars */]) = 0 > > ... ld

Re: ln -s broken on 2.4.5

In article <[EMAIL PROTECTED]> you wrote: >> I downloaded the linux 2.4.5 sources and built and installed them on my >> system. Since then, I've noticed strange file system behavior: > What file system. Its find on my 2.4.5-ac with ext2 100% reproducible on NFS and EXT2 here, with following:

PATCH: 3c509 PNP80f7 id

Hi, This adds the PNP80f7 compat Id to 3c509.c, making it now autodetect my '3C509B EtherLink III'. BTW, there is a problem there: It has a card id of TCM5094 and a function id of PNP80f7, the cardid is already there, but only probed as function id... Anyway, I will let the dust settle on

PATCH: 3c509 PNP80f7 id

Hi, This adds the PNP80f7 compat Id to 3c509.c, making it now autodetect my '3C509B EtherLink III'. BTW, there is a problem there: It has a card id of TCM5094 and a function id of PNP80f7, the cardid is already there, but only probed as function id... Anyway, I will let the dust settle on

Re: ln -s broken on 2.4.5

In article [EMAIL PROTECTED] you wrote: I downloaded the linux 2.4.5 sources and built and installed them on my system. Since then, I've noticed strange file system behavior: What file system. Its find on my 2.4.5-ac with ext2 100% reproducible on NFS and EXT2 here, with following: $ ln -s

Re: ln -s broken on 2.4.5

On Wed, May 30, 2001 at 10:49:18PM +0100, Alan Cox wrote: The problem is only there if you specify a directory for the linked to component. [marcus@wine /tmp]$ strace -f ln -s fupp/berk xxx execve(/bin/ln, [ln, -s, fupp/berk, xxx], [/* 39 vars */]) = 0 ... ld stuff ... locale stuff

Re: Linux 2.4.4-ac15

In article <[EMAIL PROTECTED]> you wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ >Intermediate diffs are available from > http://www.bzimage.org > 2.4.4-ac15 > o Merge Linus 2.4.5pre5 > | Also fixes a dumb bug in my mmx

Re: Linux 2.4.4-ac15

In article [EMAIL PROTECTED] you wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org 2.4.4-ac15 o Merge Linus 2.4.5pre5 | Also fixes a dumb bug in my mmx fixups

PATCH: more esssolo1 cleanups

:06:38 1.12 +++ drivers/sound/esssolo1.c2001/05/22 12:28:54 @@ -79,6 +79,9 @@ * for abs. Bug report by Andrew Morton <[EMAIL PROTECTED]> *15.05.2001 pci_enable_device moved, return values in probe cleaned * up. Marcus Me

PATCH: more esssolo1 cleanups

:06:38 1.12 +++ drivers/sound/esssolo1.c2001/05/22 12:28:54 @@ -79,6 +79,9 @@ * for abs. Bug report by Andrew Morton [EMAIL PROTECTED] *15.05.2001 pci_enable_device moved, return values in probe cleaned * up. Marcus Meissner [EMAIL

Re: PATCH: maestro ported to 2.4 PCI API

1/05/18 08:06:38 1.7 +++ drivers/sound/maestro.c 2001/05/21 21:06:55 @@ -115,6 +115,10 @@ * themselves, but we'll see. * * History + * v0.15 - May 21 2001 - Marcus Meissner <[EMAIL PROTECTED]> + * Ported to Linux 2.4 PCI API. Some clean ups, global devs list + * rem

PATCH: toshoboe 2.4 PCI api

Hi, I cleaned up the Toshoboe IrDA driver: - Ported to Linux 2.4 PCI API. Including PowerManagement this time. - got rid of static dev array, using pci device data - some misc cleanups. Tested that IrDA still works on Toshiba Satellite 4080XCDT with irdadump and a Siemens S25. Ciao, Marcus

PATCH: maestro ported to 2.4 PCI API

@@ * themselves, but we'll see. * * History + * v0.15 - May 21 2001 - Marcus Meissner <[EMAIL PROTECTED]> + * Ported to Linux 2.4 PCI API. Some clean ups, global devs list + * removed (now using pci device driver data). + * PM needs to be polished still. Bumped v

PATCH: toshoboe 2.4 PCI api

Hi, I cleaned up the Toshoboe IrDA driver: - Ported to Linux 2.4 PCI API. Including PowerManagement this time. - got rid of static dev array, using pci device data - some misc cleanups. Tested that IrDA still works on Toshiba Satellite 4080XCDT with irdadump and a Siemens S25. Ciao, Marcus

PATCH: maestro ported to 2.4 PCI API

@@ * themselves, but we'll see. * * History + * v0.15 - May 21 2001 - Marcus Meissner [EMAIL PROTECTED] + * Ported to Linux 2.4 PCI API. Some clean ups, global devs list + * removed (now using pci device driver data). + * PM needs to be polished still. Bumped version. * (still

Re: PATCH: maestro ported to 2.4 PCI API

@@ -115,6 +115,10 @@ * themselves, but we'll see. * * History + * v0.15 - May 21 2001 - Marcus Meissner [EMAIL PROTECTED] + * Ported to Linux 2.4 PCI API. Some clean ups, global devs list + * removed (now using pci device driver data). + * PM needs to be polished

PATCH: sonicvibes / pci_enabled_device and error returns

0.29 Register/Unregister gameport * Fix SETTRIGGER non OSS API conformity + *18.05.2001 0.30 PCI probing and error values cleaned up by Marcus + * Meissner <[EMAIL

PATCH: sonicvibes / pci_enabled_device and error returns

Register/Unregister gameport * Fix SETTRIGGER non OSS API conformity + *18.05.2001 0.30 PCI probing and error values cleaned up by Marcus + * Meissner [EMAIL PROTECTED

PATCH: wd7000 missing release_region

Hi, One else case in wd7000.c did not have a release_region(). Ciao, Marcus Index: drivers/scsi/wd7000.c === RCS file: /build/mm/work/repository/linux-mm/drivers/scsi/wd7000.c,v retrieving revision 1.7 diff -u -r1.7 wd7000.c ---

PATCH: missing release_region in qlogicfas.c

Hi, qlogicfas was missing a release_region in autoprobing too. Ciao, Marcus Index: drivers/scsi/qlogicfas.c === RCS file: /build/mm/work/repository/linux-mm/drivers/scsi/qlogicfas.c,v retrieving revision 1.13 diff -u -r1.13

PATCH: NCR53c406 missing release_region

Hi, There was a missing release_region in NCR53c406a.c, which fscked up probing with 'modprobe NCR53c406' like one mode of our installer does. (Tested by checking the contents of /proc/ioports before and after. After modprobe it contained junk for the probed port range. It no longer does.)

PATCH: NCR53c406 missing release_region

Hi, There was a missing release_region in NCR53c406a.c, which fscked up probing with 'modprobe NCR53c406' like one mode of our installer does. (Tested by checking the contents of /proc/ioports before and after. After modprobe it contained junk for the probed port range. It no longer does.)

PATCH: missing release_region in qlogicfas.c

Hi, qlogicfas was missing a release_region in autoprobing too. Ciao, Marcus Index: drivers/scsi/qlogicfas.c === RCS file: /build/mm/work/repository/linux-mm/drivers/scsi/qlogicfas.c,v retrieving revision 1.13 diff -u -r1.13

PATCH: wd7000 missing release_region

Hi, One else case in wd7000.c did not have a release_region(). Ciao, Marcus Index: drivers/scsi/wd7000.c === RCS file: /build/mm/work/repository/linux-mm/drivers/scsi/wd7000.c,v retrieving revision 1.7 diff -u -r1.7 wd7000.c ---

PATCH: esssolo pci_enable_device / retcodes

* for abs. Bug report by Andrew Morton <[EMAIL PROTECTED]> + *15.05.2001 pci_enable_device moved, return values in probe cleaned + * up. Marcus Meissner <[EMAIL PROTECTED]> */ /*/

PATCH: esssolo pci_enable_device / retcodes

* for abs. Bug report by Andrew Morton [EMAIL PROTECTED] + *15.05.2001 pci_enable_device moved, return values in probe cleaned + * up. Marcus Meissner [EMAIL PROTECTED] */ /*/ @@ -2277,22

Re: PATCH: es1370 move pci_enable_device

On Wed, May 02, 2001 at 09:44:21AM +0200, Marcus Meissner wrote: > Hi, > > This moves pci_enable_device to the correct position in es1370 and > cleans up the return values in es1370_probe > > Ciao, Marcus > + if ((!pci_resource_flags(pcidev, 0) & IORESOURCE_IO

PATCH: es1370 move pci_enable_device

Hi, This moves pci_enable_device to the correct position in es1370 and cleans up the return values in es1370_probe. Ciao, Marcus Index: drivers/sound/es1370.c === RCS file:

PATCH: emu10k1 moving pci_enable_device

Hi, This moves pci_enable_device in emu10k1 driver before any resource access. Ciao, Marcus Index: main.c === RCS file: /build/mm/work/repository/linux-mm/drivers/sound/emu10k1/main.c,v retrieving revision 1.3 diff -u -r1.3

PATCH: emu10k1 moving pci_enable_device

Hi, This moves pci_enable_device in emu10k1 driver before any resource access. Ciao, Marcus Index: main.c === RCS file: /build/mm/work/repository/linux-mm/drivers/sound/emu10k1/main.c,v retrieving revision 1.3 diff -u -r1.3

PATCH: es1370 move pci_enable_device

Hi, This moves pci_enable_device to the correct position in es1370 and cleans up the return values in es1370_probe. Ciao, Marcus Index: drivers/sound/es1370.c === RCS file:

Re: PATCH: es1370 move pci_enable_device

On Wed, May 02, 2001 at 09:44:21AM +0200, Marcus Meissner wrote: Hi, This moves pci_enable_device to the correct position in es1370 and cleans up the return values in es1370_probe Ciao, Marcus + if ((!pci_resource_flags(pcidev, 0) IORESOURCE_IO) || Slightly bad placed braces

Re: PATCH: trident , pci_enable_device moved

On Wed, Apr 25, 2001 at 09:04:38AM +0200, Marcus Meissner wrote: > Hi Alan, linux-kernel, > > This moves pci_enable_device() in trident.c before any PCI resource access. > Everything else appears to be ok in regards to 2.4 PCI API and return values. > > Ciao, Marcus Argh, a

PATCH: trident , pci_enable_device moved

Hi Alan, linux-kernel, This moves pci_enable_device() in trident.c before any PCI resource access. Everything else appears to be ok in regards to 2.4 PCI API and return values. Ciao, Marcus Index: trident.c === RCS file:

PATCH: trident , pci_enable_device moved

Hi Alan, linux-kernel, This moves pci_enable_device() in trident.c before any PCI resource access. Everything else appears to be ok in regards to 2.4 PCI API and return values. Ciao, Marcus Index: trident.c === RCS file:

Re: [PATCH] es1371 pci fix/cleanup

On Mon, Apr 23, 2001 at 11:58:25AM -0400, Jeff Garzik wrote: > Marcus Meissner wrote: > > > > Hi, > > > > This moves pci_enable_device in the es1371 driver before any resource > > access and also replaces the RSRCISIOREGION by just pci_resource_flags > >

[PATCH] es1371 pci fix/cleanup

Hi, This moves pci_enable_device in the es1371 driver before any resource access and also replaces the RSRCISIOREGION by just pci_resource_flags as suggested by Jeff. Tested and verified. Ciao, Marcus Index: drivers/sound/es1371.c

Re: [PATCH] es1371 pci fix/cleanup

On Mon, Apr 23, 2001 at 11:58:25AM -0400, Jeff Garzik wrote: Marcus Meissner wrote: Hi, This moves pci_enable_device in the es1371 driver before any resource access and also replaces the RSRCISIOREGION by just pci_resource_flags as suggested by Jeff. Tested and verified

Re: [PATCH] drivers/sound/nm256_audio.c

On Thu, Apr 19, 2001 at 11:56:01AM -0400, Jeff Garzik wrote: > Marcus Meissner wrote: > > > > Hi, > > > > This updates the nm256_audio driver to the 2.4 PCI API. > > > > Patch is against 2.4.3-ac9, verified on Sony VAIO Laptop. > > "verif

[PATCH] drivers/sound/nm256_audio.c

d some __init + * 19-04-2001 Marcus Meissner <[EMAIL PROTECTED]> + * Ported to 2.4 PCI API. */ #define __NO_VERSION__ @@ -49,8 +52,6 @@ #define PCI_DEVICE_ID_NEOMAGIC_NM256AV_AUDIO 0x8005 #define PCI_DEVICE_ID_NEOMAGIC_NM256ZX_AUDIO 0x8006 -#define RSRCADDRESS(de

[PATCH] drivers/sound/nm256_audio.c

__init + * 19-04-2001 Marcus Meissner [EMAIL PROTECTED] + * Ported to 2.4 PCI API. */ #define __NO_VERSION__ @@ -49,8 +52,6 @@ #define PCI_DEVICE_ID_NEOMAGIC_NM256AV_AUDIO 0x8005 #define PCI_DEVICE_ID_NEOMAGIC_NM256ZX_AUDIO 0x8006 -#define RSRCADDRESS(dev,num) ((dev)-resource

Re: [PATCH] drivers/sound/nm256_audio.c

On Thu, Apr 19, 2001 at 11:56:01AM -0400, Jeff Garzik wrote: Marcus Meissner wrote: Hi, This updates the nm256_audio driver to the 2.4 PCI API. Patch is against 2.4.3-ac9, verified on Sony VAIO Laptop. "verified" is the really important part with this driver, since i

Re: [PATCH] misplaced pci_enable_device()s in drivers/sound/

On Wed, Apr 18, 2001 at 12:55:50PM -0400, Jeff Garzik wrote: > Marcus Meissner wrote: > > Several pci_enable_device()s in drivers/sound happen _after_ accessing > > PCI resources. I have moved them before the relevant first accesses. > > cool > > >

[PATCH] misplaced pci_enable_device()s in drivers/sound/

Hi, Several pci_enable_device()s in drivers/sound happen _after_ accessing PCI resources. I have moved them before the relevant first accesses. (Untested, but should work.) Against 2.4.3-ac9. Ciao, Marcus Index: es1370.c ===

[PATCH] toshoboe pci enable

Hi, Enable PCI for toshoboe IRDA adapters. Ciao, Marcus Index: drivers/net/irda/toshoboe.c === RCS file: /build/mm/work/repository/linux-mm/drivers/net/irda/toshoboe.c,v retrieving revision 1.12 diff -u -r1.12 toshoboe.c ---

[PATCH] pci enable nm256 audio

Hi Alan, linux-kernel, Some of our customer reported a hang when modprobing nm256_audio, this patch should fix the problem. Ciao, Marcus Index: nm256_audio.c === RCS file:

[PATCH] pci enable nm256 audio

Hi Alan, linux-kernel, Some of our customer reported a hang when modprobing nm256_audio, this patch should fix the problem. Ciao, Marcus Index: nm256_audio.c === RCS file:

[PATCH] toshoboe pci enable

Hi, Enable PCI for toshoboe IRDA adapters. Ciao, Marcus Index: drivers/net/irda/toshoboe.c === RCS file: /build/mm/work/repository/linux-mm/drivers/net/irda/toshoboe.c,v retrieving revision 1.12 diff -u -r1.12 toshoboe.c ---

[PATCH] misplaced pci_enable_device()s in drivers/sound/

Hi, Several pci_enable_device()s in drivers/sound happen _after_ accessing PCI resources. I have moved them before the relevant first accesses. (Untested, but should work.) Against 2.4.3-ac9. Ciao, Marcus Index: es1370.c ===

Re: [PATCH] misplaced pci_enable_device()s in drivers/sound/

On Wed, Apr 18, 2001 at 12:55:50PM -0400, Jeff Garzik wrote: Marcus Meissner wrote: Several pci_enable_device()s in drivers/sound happen _after_ accessing PCI resources. I have moved them before the relevant first accesses. cool if (!RSRCISIOREGION(pcidev, 0

Re: [Problem] 3c90x on 2.4.3-ac3

In article <[EMAIL PROTECTED]> you wrote: > hi lkml, > I just built 2.4.3-ac3 with my old 2.4.2 .config and somehow networking does >not work. > dhclient eventually froze the machine. > here is what dhclient complains. > [root@psubash linux]# cat /tmp/error.txt > skb: pf=2 (unowned)

PATCH: pci_enable_device fixes for sound/* and block/cpqarray and block/cciss

Hi Alan, linux-kernel, This moves all pci_enable_device()s before any resource usage in sound/*.c,sound/*/*.c and block/cciss.c, block/cpqarray.c. I have NOT tested them except the es1370, but they should be correct as is. Note that it was missing in nm256_audio.c. Ciao, Marcus ---

PATCH: pci_enable_device fixes for sound/* and block/cpqarray and block/cciss

Hi Alan, linux-kernel, This moves all pci_enable_device()s before any resource usage in sound/*.c,sound/*/*.c and block/cciss.c, block/cpqarray.c. I have NOT tested them except the es1370, but they should be correct as is. Note that it was missing in nm256_audio.c. Ciao, Marcus ---

PATCH: CS4281: missing pci_enable_dervice

Hi, My Laptop has a CS4281 soundchip. It requires the following patch to start working (enable pci device). Ciao, Marcus --- linux/drivers/sound/cs4281/cs4281m.c.marcus Mon Mar 12 09:55:35 2001 +++ linux/drivers/sound/cs4281/cs4281m.cMon Mar 12 09:55:57 2001 @@ -4289,6 +4289,9 @@

PATCH: CS4281: missing pci_enable_dervice

Hi, My Laptop has a CS4281 soundchip. It requires the following patch to start working (enable pci device). Ciao, Marcus --- linux/drivers/sound/cs4281/cs4281m.c.marcus Mon Mar 12 09:55:35 2001 +++ linux/drivers/sound/cs4281/cs4281m.cMon Mar 12 09:55:57 2001 @@ -4289,6 +4289,9 @@

Re: Netgear FA311

In article <[EMAIL PROTECTED]> you wrote: > Is this where you got the sources? > http://www.scyld.com/network/natsemi.html (Thanks Steve) The linux driver is actually on the accompanying floppy disk. Without license statement unfortunately. Ciao, Marcus - To unsubscribe from this list: send

Re: Netgear FA311

In article [EMAIL PROTECTED] you wrote: Is this where you got the sources? http://www.scyld.com/network/natsemi.html (Thanks Steve) The linux driver is actually on the accompanying floppy disk. Without license statement unfortunately. Ciao, Marcus - To unsubscribe from this list: send the

Re: hotplug mopup

In article <[EMAIL PROTECTED]> you wrote: > A compendium of questions and misc stuff concerning hotplug: > - Is everyone happy with call_usermodehelper() being asynchronous? It > _could_ be given a `synchronous' option, but that's a fair bit of > obfuscation and it does expose us to

Re: hotplug mopup

In article [EMAIL PROTECTED] you wrote: A compendium of questions and misc stuff concerning hotplug: - Is everyone happy with call_usermodehelper() being asynchronous? It _could_ be given a `synchronous' option, but that's a fair bit of obfuscation and it does expose us to deadlocks if

  1   2   >