LinuxLists.cc - 2.6 must-fix list, v3

[permalink] [raw]

Subject: Re: 2.6 must-fix list, v3

On Wed, May 14, 2003 at 03:27:12AM -0700, Andrew Morton wrote:
>
> Quite a lot of changes here. Mostly additions, but some things have been
> crossed off.
>
> Also at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix

Here's a patch against must-fix-3.txt that consolodates the 4 different
places people are complaining about a lack of PCI device locking, and
put the bugzilla bug number for it.

As soon as I finish this OLS paper, I'm going to work on finally fixing
this...

thanks,

greg k-h

--- must-fix-3.txt.original Wed May 14 09:46:43 2003
+++ must-fix-3.txt Wed May 14 09:52:47 2003
@@ -115,7 +115,11 @@

- alan: Some cardbus crashes the system

-- alan: Hotplug locking is hosed
+- We have multiple drivers walking the pci device lists and also using
+ things like pci_find_device in unsafe ways with no refcounting. I think
+ we have to make pci_find_device etc refcount somewhere and add
+ pci_device_put as was done with networking.
+ http://bugzilla.kernel.org/show_bug.cgi?id=709

drivers/pcmcia/
---------------
@@ -567,17 +571,8 @@
drivers
=======

-- Alan: We have multiple drivers walking the pci device lists and also
- using things like pci_find_device in unsafe ways with no refcounting. I
- think we have to make pci_find_device etc refcount somewhere and add
- pci_device_put as was done with networking.
-
- Some network drivers don't even build

-- Alan: PCI hotplug is unsafe (locking is totally screwed)
-
-- Ditto cardbus
-
- Alan: Cardbus/PCMCIA requires all Russell's stuff is merged to do
multiheader right and so on

2003-05-14 16:57:19

[permalink] [raw]

Subject: Re: 2.6 must-fix list, v3

On Wed, May 14, 2003 at 03:27:12AM -0700, Andrew Morton wrote:
>
> Quite a lot of changes here. Mostly additions, but some things have been
> crossed off.

Has handling of async write errors fallen off your radar? Should I
start pushing that again?

--
Matt Mackall : http://www.selenic.com : of or relating to the moon

2003-05-14 17:31:28

by Andrew Morton

[permalink] [raw]

Subject: Re: 2.6 must-fix list, v3

Matt Mackall <[email protected]> wrote:
>
> On Wed, May 14, 2003 at 03:27:12AM -0700, Andrew Morton wrote:
> >
> > Quite a lot of changes here. Mostly additions, but some things have been
> > crossed off.
>
> Has handling of async write errors fallen off your radar? Should I
> start pushing that again?
>

No, I haven't forgotten. If you want to rediff the patches sometime that'd
be appreciated, thanks.

2003-05-14 20:59:37

[permalink] [raw]

Subject: Re: 2.6 must-fix list, v3

Andrew Morton wrote :
>
> Quite a lot of changes here. Mostly additions, but some things have been
> crossed off.
>
> Also at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix

I don't like making todo list for other people, because it's
up to them to decide, but here is my wishlist for 2.6.X in term of
Wireless stuff.
I hope those concerned will react and send you their real todo
list.

o get latest orinoco changes from David. Linus seems timely in
picking David's changes, so I'm not worried about this one.

o get the latest airo.c fixes from CVS. This will hopefully
fix problems people have reported on the LKML.

o get HostAP driver in the kernel. No consolidation of the
802.11 management across driver can happen until this one is in (which
is probably 2.7.X material). I think Jouni is mostly ready but didn't
find time for it.

o get more wireless drivers into the kernel. The most
"integrable" drivers at this point seem the NWN driver, Pavel's
Spectrum driver and the Atmel driver.

o The last two drivers mentioned above are held up by firmware
issues (see flamewar on LKML a few days ago). So maybe fixing those
firmware issues should be a requirement for 2.6.X, because we can
expect more wireless devices to need firmware upload at startup coming
to market.
As this firmware business seems to me not a wireless specific
issue (see for example drivers/scsi/qlogicfc_asm.c or
drivers/atm/atmsar11.data), I would prefer a generic solution to that
problem, either saying it's OK to put firmware in the kernel (with
proper licensing) or providing working technical solutions.
My personal position is that I don't want to hold wireless
drivers in higher standard than other drivers in the kernel, and I
don't want to leave those drivers in the black hole where they
currently are.

Have fun...

Jean

2003-05-14 21:54:07

by Jeff Garzik

[permalink] [raw]

Subject: airo and firmware upload (was Re: 2.6 must-fix list, v3)

Jean Tourrilhes wrote:
> o get the latest airo.c fixes from CVS. This will hopefully
> fix problems people have reported on the LKML.

please beg Javier to split up his patch. He sends me a _huge_ patch
with tons of changes each time. If I object to one thing, we spin in
another huge-patch loop... :/

Sending me 20, 50, 100 patches to the same file is ok. Even encouraged.

> o get HostAP driver in the kernel. No consolidation of the
> 802.11 management across driver can happen until this one is in (which
> is probably 2.7.X material). I think Jouni is mostly ready but didn't
> find time for it.

yeah, there are many requests for this one

> o The last two drivers mentioned above are held up by firmware
> issues (see flamewar on LKML a few days ago). So maybe fixing those
> firmware issues should be a requirement for 2.6.X, because we can
> expect more wireless devices to need firmware upload at startup coming
> to market.

> As this firmware business seems to me not a wireless specific
> issue (see for example drivers/scsi/qlogicfc_asm.c or
> drivers/atm/atmsar11.data), I would prefer a generic solution to that
> problem, either saying it's OK to put firmware in the kernel (with
> proper licensing) or providing working technical solutions.

We need firmware upload, and, firmware _should_ be uploaded from userspace.

All someone needs to do is actually write the code for their driver to
receive firmware from userspace, and the rest is easy. A working
technical solution is obvious, it just needs interested parties to
implement.

We can upload firmware from initrd, if no boot device is available at
the time.

Jeff

2003-05-14 23:19:49

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

On Wed, May 14, 2003 at 06:06:36PM -0400, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> > o get the latest airo.c fixes from CVS. This will hopefully
> >fix problems people have reported on the LKML.
>
> please beg Javier to split up his patch. He sends me a _huge_ patch
> with tons of changes each time. If I object to one thing, we spin in
> another huge-patch loop... :/
>
> Sending me 20, 50, 100 patches to the same file is ok. Even encouraged.

Javier is cc'ed.
While we are on the subject : a few months ago, Javier added
support for MIC to the airo driver. It's basically crypto based on
AES. You refused to include that part in the kernel because crypto was
not accepted in the kernel.
Fast forward : today we have crypto in the 2.5.X kernel. Does
this mean that you would have no objection accepting a patch from
Javier including the crypto part ?

> > o get HostAP driver in the kernel. No consolidation of the
> >802.11 management across driver can happen until this one is in (which
> >is probably 2.7.X material). I think Jouni is mostly ready but didn't
> >find time for it.
>
> yeah, there are many requests for this one

By the way, the HostAP driver include crypto (currently only
RC4 for WEP). Same question, I hope you would not refuse the crypto
part of HostAP (which is mandatory because most PrismII firmwares are
broken and can't do basic WEP properly).

> > o The last two drivers mentioned above are held up by firmware
> >issues (see flamewar on LKML a few days ago). So maybe fixing those
> >firmware issues should be a requirement for 2.6.X, because we can
> >expect more wireless devices to need firmware upload at startup coming
> >to market.
>
> > As this firmware business seems to me not a wireless specific
> >issue (see for example drivers/scsi/qlogicfc_asm.c or
> >drivers/atm/atmsar11.data), I would prefer a generic solution to that
> >problem, either saying it's OK to put firmware in the kernel (with
> >proper licensing) or providing working technical solutions.
>
>
> We need firmware upload, and, firmware _should_ be uploaded from userspace.

Ok, so I ask it this way : currently the kernel include some
drivers containing some binary firmwares blobs which are linked
directly into the kernel/module (including networking). Does this mean
that you are going to remove those driver from the kernel ASAP ? Or
does this mean that the rule above only apply to wireless drivers ?
Let's be logical and coherent here...

> All someone needs to do is actually write the code for their driver to
> receive firmware from userspace, and the rest is easy. A working
> technical solution is obvious, it just needs interested parties to
> implement.
>
> We can upload firmware from initrd, if no boot device is available at
> the time.

Currently, it looks like every driver will use its own method,
which I guess is ok.

> Jeff

Thanks !

Jean

2003-05-14 23:30:33

by Dave Jones

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

On Wed, May 14, 2003 at 04:32:35PM -0700, Jean Tourrilhes wrote:

> While we are on the subject : a few months ago, Javier added
> support for MIC to the airo driver. It's basically crypto based on
> AES. You refused to include that part in the kernel because crypto was
> not accepted in the kernel.
> Fast forward : today we have crypto in the 2.5.X kernel. Does
> this mean that you would have no objection accepting a patch from
> Javier including the crypto part ?

Sounds like it would be better to get it using the in-kernel crypto
stuff rather than reimplementing its own routines. Same for the HostAP
driver.

Dave

2003-05-14 23:30:13

by Andrew Morton

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

Jean Tourrilhes <[email protected]> wrote:
>
> firmwares blobs

well for the purposes of tracking 2.6 activities I'll separate this issue
of firmware access policy out from drivers/net/wireless/.

yeah, it would be nice if the core kernel provided a "give me my firmware"
API or something.

2003-05-14 23:40:58

by Jeff Garzik

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

Dave Jones wrote:
> On Wed, May 14, 2003 at 04:32:35PM -0700, Jean Tourrilhes wrote:
>
> > While we are on the subject : a few months ago, Javier added
> > support for MIC to the airo driver. It's basically crypto based on
> > AES. You refused to include that part in the kernel because crypto was
> > not accepted in the kernel.
> > Fast forward : today we have crypto in the 2.5.X kernel. Does
> > this mean that you would have no objection accepting a patch from
> > Javier including the crypto part ?
>
> Sounds like it would be better to get it using the in-kernel crypto
> stuff rather than reimplementing its own routines. Same for the HostAP
> driver.

Correct.

_I_ didn't refuse the crypto, Linus did. But that was a positive step,
that kicked off inclusion of crypto into the kernel.

airo and HostAP do indeed need to use CryptoAPI not reimplement their
own crypto, though...

Jeff

2003-05-15 00:46:58

by Jouni Malinen

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

On Wed, May 14, 2003 at 07:53:31PM -0400, Jeff Garzik wrote:

> airo and HostAP do indeed need to use CryptoAPI not reimplement their
> own crypto, though...

Host AP driver has a dynamic crypto implementation that allows one to
load new algorithms as a separate kernel modules. One of such modules
was an interface to use CryptoAPI. However, I don't think there is a
public release of it.

Do you think WEP should be implemented as a CryptoAPI algorithm? It is a
combination of CRC-32 and RC4 and the crypto module in Host AP does
these together in one pass of the packet payload to minimize host CPU
load. I'm not keen on using RC4 separately with CryptoAPI (I don't think
it is even included yet) if that means making the WEP encryption use
more CPU.. However, I could consider taking CryptoAPI into use it would
support WEP as an algorithm (i.e., I could consider porting the current
Host AP WEP code to CryptoAPI).

Since I'm not that interested in maintaining multiple source trees of
the driver, own WEP implementation is going to remain in the Host AP
driver for 2.2 and 2.4 kernels. Anyway, this could probably be
automatically stripped from the code if backward compatibility in
drivers must be removed from 2.5/2.6 kernel tree.

--
Jouni Malinen PGP id EFC895FA

2003-05-15 00:42:29

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

On Thu, May 15, 2003 at 12:43:59AM +0100, Dave Jones wrote:
> On Wed, May 14, 2003 at 04:32:35PM -0700, Jean Tourrilhes wrote:
>
> > While we are on the subject : a few months ago, Javier added
> > support for MIC to the airo driver. It's basically crypto based on
> > AES. You refused to include that part in the kernel because crypto was
> > not accepted in the kernel.
> > Fast forward : today we have crypto in the 2.5.X kernel. Does
> > this mean that you would have no objection accepting a patch from
> > Javier including the crypto part ?
>
> Sounds like it would be better to get it using the in-kernel crypto
> stuff rather than reimplementing its own routines. Same for the HostAP
> driver.
>
> Dave

For HostAP, the kernel crypto doesn't include any RC4 support,
so it can't use kernel crypto as it is.
For airo, crypto was added before kernel crypto was available
in the kernel, and I don't know how easy it will be to refactor the
code.
I just wanted to know the position of Jeff on this issue. I'll
let the technical decision to the respective authors.

Thanks...

Jean

2003-05-15 00:52:33

by David Gibson

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

On Wed, May 14, 2003 at 04:38:26PM -0700, Andrew Morton wrote:
> Jean Tourrilhes <[email protected]> wrote:
> >
> > firmwares blobs
>
> well for the purposes of tracking 2.6 activities I'll separate this issue
> of firmware access policy out from drivers/net/wireless/.
>
> yeah, it would be nice if the core kernel provided a "give me my firmware"
> API or something.

Well, Manuel Estrada (also author of the orinoco USB patches) has
proposed one on lkml. Doesn't look like people were happy with that
version, but I think he's still working on revising it based on
feedback.

--
David Gibson | For every complex problem there is a
[email protected] | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson

2003-05-15 00:49:48

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

On Wed, May 14, 2003 at 07:53:31PM -0400, Jeff Garzik wrote:
> Dave Jones wrote:
> >On Wed, May 14, 2003 at 04:32:35PM -0700, Jean Tourrilhes wrote:
> >
> > > While we are on the subject : a few months ago, Javier added
> > > support for MIC to the airo driver. It's basically crypto based on
> > > AES. You refused to include that part in the kernel because crypto was
> > > not accepted in the kernel.
> > > Fast forward : today we have crypto in the 2.5.X kernel. Does
> > > this mean that you would have no objection accepting a patch from
> > > Javier including the crypto part ?
> >
> >Sounds like it would be better to get it using the in-kernel crypto
> >stuff rather than reimplementing its own routines. Same for the HostAP
> >driver.
>
>
> Correct.
>
> _I_ didn't refuse the crypto, Linus did. But that was a positive step,
> that kicked off inclusion of crypto into the kernel.
>
> airo and HostAP do indeed need to use CryptoAPI not reimplement their
> own crypto, though...
>
> Jeff

Ok, this point is clarified as well. I'll communicate
downstream.
Thanks.

Jean

2003-05-15 02:07:49

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

On Wed, May 14, 2003 at 05:59:04PM -0700, Jouni Malinen wrote:
> On Wed, May 14, 2003 at 07:53:31PM -0400, Jeff Garzik wrote:
>
> > airo and HostAP do indeed need to use CryptoAPI not reimplement their
> > own crypto, though...
>
> Host AP driver has a dynamic crypto implementation that allows one to
> load new algorithms as a separate kernel modules. One of such modules
> was an interface to use CryptoAPI. However, I don't think there is a
> public release of it.
>
> Do you think WEP should be implemented as a CryptoAPI algorithm? It is a
> combination of CRC-32 and RC4 and the crypto module in Host AP does
> these together in one pass of the packet payload to minimize host CPU
> load. I'm not keen on using RC4 separately with CryptoAPI (I don't think
> it is even included yet) if that means making the WEP encryption use
> more CPU.. However, I could consider taking CryptoAPI into use it would
> support WEP as an algorithm (i.e., I could consider porting the current
> Host AP WEP code to CryptoAPI).

There is no RC4 currently in the crypto API (guess why), and I
believe that most wireless driver would be interested in the RC4+CRC,
so I would advocate for doing "WEP".

> Since I'm not that interested in maintaining multiple source trees of
> the driver, own WEP implementation is going to remain in the Host AP
> driver for 2.2 and 2.4 kernels. Anyway, this could probably be
> automatically stripped from the code if backward compatibility in
> drivers must be removed from 2.5/2.6 kernel tree.

If you define the WEP in the kernel crypto, it could even be
the exact same file.

> Jouni Malinen

Thanks...

Jean

2003-05-15 04:09:12

by Jouni Malinen

[permalink] [raw]

Subject: Re: CryptoAPI and WEP/stream ciphers (was: airo and firmware upload)

On Wed, May 14, 2003 at 07:53:31PM -0400, Jeff Garzik wrote:

> airo and HostAP do indeed need to use CryptoAPI not reimplement their
> own crypto, though...

I tried to change my WEP implementation to use CryptoAPI, but that ended
up in problems.. If I understood correctly, current CryptoAPI supports
only block ciphers(?). However, WEP uses RC4 as a stream cipher. This
does not seem to fit the cipher definition in CryptoAPI. One might be
able to implement it as an compression algorithm (encrypt as decompress,
since it adds IV and ICV; and decrypt as compress). However, this
certainly does not sound very reasonable.. Another alternative would be
to add support for stream ciphers into CryptoAPI.

Do you think that it would still be required to get rid of the own WEP
implementation in the Host AP driver before including it into the kernel
tree? Would this mean that someone would first need to add support for
stream ciphers into CryptoAPI? Any change of that happening for Linux
2.6.x?

And one more question before using more time with WEP implementation..
Is someone already working with stream cipher support for CryptoAPI?

--
Jouni Malinen PGP id EFC895FA

2003-05-15 05:52:39

by James Morris

[permalink] [raw]

Subject: Re: CryptoAPI and WEP/stream ciphers (was: airo and firmware upload)

On Wed, 14 May 2003, Jouni Malinen wrote:

> I tried to change my WEP implementation to use CryptoAPI, but that ended
> up in problems.. If I understood correctly, current CryptoAPI supports
> only block ciphers(?).

Block ciphers and digests.

> certainly does not sound very reasonable.. Another alternative would be
> to add support for stream ciphers into CryptoAPI.

Yes, it would be good to have API support for stream encryption in
general, e.g. also for OFB and Counter Mode.

> Do you think that it would still be required to get rid of the own WEP
> implementation in the Host AP driver before including it into the kernel
> tree? Would this mean that someone would first need to add support for
> stream ciphers into CryptoAPI? Any change of that happening for Linux
> 2.6.x?

I'd like to see it go in if the code is available.

> And one more question before using more time with WEP implementation..
> Is someone already working with stream cipher support for CryptoAPI?

Not that I know of.

- James
--
James Morris
<[email protected]>

2003-05-15 06:04:00

by James Morris

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

On Wed, 14 May 2003, Jean Tourrilhes wrote:

> There is no RC4 currently in the crypto API (guess why), and I

If you mean because of IP issues, that's not the reason. As far as I
know, we can use 'arcfour', which is compatible.

Arcfour is also needed potentially for MPPE support (check for recent
thread).

- James
--
James Morris
<[email protected]>

2003-05-15 07:00:16

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

On Wed, May 14, 2003 at 04:32:35PM -0700, Jean Tourrilhes wrote:
> Ok, so I ask it this way : currently the kernel include some
> drivers containing some binary firmwares blobs which are linked
> directly into the kernel/module (including networking). Does this mean
> that you are going to remove those driver from the kernel ASAP ? Or
> does this mean that the rule above only apply to wireless drivers ?
> Let's be logical and coherent here...

I've stated this for _years_ now, I'm very glad to take patches to move
the firmware blobs out of the usb drivers that currently have them, and
move it to userspace, if people send me those patches. For all the
whining on debian-legal about them over the _years_, no one has sent me
such a patch.

Ok, yes, I did get the start of some patches in the early 2.4 series, I
said I would accept them in 2.5 as it was too radical of a change to
take during a stable kernel series (the developer agreed with me.) They
were never resubmitted to me during the entire 2.5 development time.

thanks,

greg k-h

2003-05-15 17:12:06

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

On Thu, May 15, 2003 at 12:13:18AM -0700, Greg KH wrote:
> On Wed, May 14, 2003 at 04:32:35PM -0700, Jean Tourrilhes wrote:
> > Ok, so I ask it this way : currently the kernel include some
> > drivers containing some binary firmwares blobs which are linked
> > directly into the kernel/module (including networking). Does this mean
> > that you are going to remove those driver from the kernel ASAP ? Or
> > does this mean that the rule above only apply to wireless drivers ?
> > Let's be logical and coherent here...
>
> I've stated this for _years_ now, I'm very glad to take patches to move
> the firmware blobs out of the usb drivers that currently have them, and
> move it to userspace, if people send me those patches. For all the
> whining on debian-legal about them over the _years_, no one has sent me
> such a patch.
>
> Ok, yes, I did get the start of some patches in the early 2.4 series, I
> said I would accept them in 2.5 as it was too radical of a change to
> take during a stable kernel series (the developer agreed with me.) They
> were never resubmitted to me during the entire 2.5 development time.
>
> thanks,
>
> greg k-h

At this point, we must get something ASAP in the kernel,
otherwise the various drivers waiting for it will just implement their
own proprietary solutions and be done with it. And it doesn't need to
be perfect at this stage, as long as it can evolve in the right
direction.
Manuel Estrada sent me a proposal for that. As it seems it's
the only one we have on the table right now, I will spend some time
looking at it and convincing other wireless driver authors to adopt
it. I hope you will help us getting that integrated and adopted.
Thanks...

Jean

2003-05-15 17:32:09

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

On Thu, May 15, 2003 at 10:24:46AM -0700, Jean Tourrilhes wrote:
> Manuel Estrada sent me a proposal for that.

I provided some feedback to him that I think will make his proposal work
for almost everyone. Hopefully he has the time to implement it :)

thanks,

greg k-h

2003-05-15 19:42:37

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

On Thu, May 15, 2003 at 10:46:48AM -0700, Greg KH wrote:
> On Thu, May 15, 2003 at 10:24:46AM -0700, Jean Tourrilhes wrote:
> > Manuel Estrada sent me a proposal for that.
>
> I provided some feedback to him that I think will make his proposal work
> for almost everyone. Hopefully he has the time to implement it :)
>
> thanks,
>
> greg k-h

I read that thread and I don't agree with some of your
unrealistic requirements.
As long as kernel 2.6.X is not standard in most major
distributions (including Debian), whatever scheme we decide on must be
easy to implement on 2.4.X. Let be realistic : all of us still
continue to update 2.4.X on a regular basis. Those 3 drivers are ready
today (one of them has been waiting on this issue for already 6
months), and I want them in 2.4.X not long after they go in 2.5.X.
Therefore, unless you plan to port sysfs to 2.4.X real soon,
the scheme can't depend exclusively on sysfs. I would even say,
because sysfs change on a weekly basis, it might even be wise to take
a two phase approach, with sysfs used only in the second phase and
based on the feedback and the results from the first phase (I
personally don't believe we will get it perfect at the first try). The
hotplug facility is flexible enough to migrate to sysfs smoothly.
I'm pragmatic : I prefer to have something imperfect now
rather than something perfect later. I think Manuel's solution is a
good stepping stone to where we want to go. If you make it too
difficult, this will never happen (and each driver will use a
proprietary solution or be kept in a black hole).

So, my question for you is :
o how do you plan to make it work with 2.4.X.

Have fun...

Jean

2003-05-15 19:55:41

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

On Thu, May 15, 2003 at 12:55:16PM -0700, Jean Tourrilhes wrote:
> On Thu, May 15, 2003 at 10:46:48AM -0700, Greg KH wrote:
> > On Thu, May 15, 2003 at 10:24:46AM -0700, Jean Tourrilhes wrote:
> > > Manuel Estrada sent me a proposal for that.
> >
> > I provided some feedback to him that I think will make his proposal work
> > for almost everyone. Hopefully he has the time to implement it :)
> >
> > thanks,
> >
> > greg k-h
>
> I read that thread and I don't agree with some of your
> unrealistic requirements.

If you think that having a common firmware interface for any kind of
device for 2.5 is unrealistic, then this is going to be a very short
discussion.

<2.4 is here for a long time ramble snipped>

> So, my question for you is :
> o how do you plan to make it work with 2.4.X.

In short, I don't care how you do it for 2.4.x. Do it like the
bluetooth usb drivers do it, that's a good place to start with. Or do
it like the usb drivers that do firmware download from userspace, that's
also a good way to do this for 2.4. So for 2.4 you have a lot of
different options on how to do this, _because_ we don't have the
goodness of sysfs and the driver model there.

For 2.5 do it the way I proposed, that way _all_ devices in the kernel
have a single way to have firmware downloaded to them, which will result
in peace and harmony for many years to come, during which we will gaze
thoughtfully back on the anarchistic ways of 2.4 and laugh at how
foolish we were then.

thanks,

greg k-h

2003-05-16 07:18:31

by Manuel Estrada Sainz

[permalink] [raw]

Subject: Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

On Thu, May 15, 2003 at 11:04:59AM +1000, David Gibson wrote:
> On Wed, May 14, 2003 at 04:38:26PM -0700, Andrew Morton wrote:
> > Jean Tourrilhes <[email protected]> wrote:
> > >
> > > firmwares blobs
> >
> > well for the purposes of tracking 2.6 activities I'll separate this issue
> > of firmware access policy out from drivers/net/wireless/.
> >
> > yeah, it would be nice if the core kernel provided a "give me my firmware"
> > API or something.
>
> Well, Manuel Estrada (also author of the orinoco USB patches) has
> proposed one on lkml. Doesn't look like people were happy with that
> version, but I think he's still working on revising it based on
> feedback.

Yep, I posted it yesterday. Please provide feedback so I can get it
"right (TM)" and it gets in the kernel for all to enjoy.

Thanks

Manuel
--
--- Manuel Estrada Sainz <[email protected]>
<[email protected]>
<[email protected]>
------------------------ <[email protected]> -------------------
Let us have the serenity to accept the things we cannot change, courage to
change the things we can, and wisdom to know the difference.

2003-05-17 16:47:48

by Pavel Machek

[permalink] [raw]

Subject: Re: 2.6 must-fix list, v3

Hi!

> > Quite a lot of changes here. Mostly additions, but some things have been
> > crossed off.
> >
> > Also at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix
>
> I don't like making todo list for other people, because it's
> up to them to decide, but here is my wishlist for 2.6.X in term of
> Wireless stuff.
> I hope those concerned will react and send you their real todo
> list.
>
> o get latest orinoco changes from David. Linus seems timely in
> picking David's changes, so I'm not worried about this one.
>
> o get the latest airo.c fixes from CVS. This will hopefully
> fix problems people have reported on the LKML.
>
> o get HostAP driver in the kernel. No consolidation of the
> 802.11 management across driver can happen until this one is in (which
> is probably 2.7.X material). I think Jouni is mostly ready but didn't
> find time for it.
>
> o get more wireless drivers into the kernel. The most
> "integrable" drivers at this point seem the NWN driver, Pavel's
> Spectrum driver and the Atmel driver.

Is that Pavel Roskin or is there another Pavel around here?

Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

2003-05-29 19:29:32

[permalink] [raw]

Subject: [PATCH] write errors [1/3] async-write-errors

On Wed, May 14, 2003 at 10:44:55AM -0700, Andrew Morton wrote:
> Matt Mackall <[email protected]> wrote:
> >
> > On Wed, May 14, 2003 at 03:27:12AM -0700, Andrew Morton wrote:
> > >
> > > Quite a lot of changes here. Mostly additions, but some things have been
> > > crossed off.
> >
> > Has handling of async write errors fallen off your radar? Should I
> > start pushing that again?
> >
>
> No, I haven't forgotten. If you want to rediff the patches sometime that'd
> be appreciated, thanks.

Ok, rediffed and tested against 2.5.70-mm2. 1 of 3.

Record async write errors and report at subsequent fsync/fdatasync.

diff -urN -x '*.ver' -x '.patch*' -x '*.orig' orig/fs/buffer.c patched/fs/buffer.c
--- orig/fs/buffer.c 2003-05-21 11:03:25.000000000 -0500
+++ patched/fs/buffer.c 2003-05-21 12:44:43.000000000 -0500
@@ -180,15 +180,29 @@
* Default synchronous end-of-IO handler.. Just mark it up-to-date and
* unlock the buffer. This is what ll_rw_block uses too.
*/
-void end_buffer_io_sync(struct buffer_head *bh, int uptodate)
+void end_buffer_read_sync(struct buffer_head *bh, int uptodate)
{
if (uptodate) {
set_buffer_uptodate(bh);
} else {
- /*
- * This happens, due to failed READA attempts.
- * buffer_io_error(bh);
- */
+ /* This happens, due to failed READA attempts. */
+ clear_buffer_uptodate(bh);
+ }
+ unlock_buffer(bh);
+ put_bh(bh);
+}
+
+void end_buffer_write_sync(struct buffer_head *bh, int uptodate)
+{
+ char b[BDEVNAME_SIZE];
+
+ if (uptodate) {
+ set_buffer_uptodate(bh);
+ } else {
+ buffer_io_error(bh);
+ printk(KERN_WARNING "lost page write due to I/O error on %s\n",
+ bdevname(bh->b_bdev, b));
+ set_buffer_write_io_error(bh);
clear_buffer_uptodate(bh);
}
unlock_buffer(bh);
@@ -556,6 +570,7 @@
*/
void end_buffer_async_write(struct buffer_head *bh, int uptodate)
{
+ char b[BDEVNAME_SIZE];
static spinlock_t page_uptodate_lock = SPIN_LOCK_UNLOCKED;
unsigned long flags;
struct buffer_head *tmp;
@@ -568,6 +583,9 @@
set_buffer_uptodate(bh);
} else {
buffer_io_error(bh);
+ printk(KERN_WARNING "lost page write due to I/O error on %s\n",
+ bdevname(bh->b_bdev, b));
+ page->mapping->error = -EIO;
clear_buffer_uptodate(bh);
SetPageError(page);
}
@@ -1300,7 +1318,7 @@
if (buffer_dirty(bh))
buffer_error();
get_bh(bh);
- bh->b_end_io = end_buffer_io_sync;
+ bh->b_end_io = end_buffer_read_sync;
submit_bh(READ, bh);
if (-EIOCBRETRY == wait_on_buffer_wq(bh, wait))
return ERR_PTR(-EIOCBRETRY);
@@ -2661,8 +2679,10 @@
buffer_error();
if (rw == READ && buffer_dirty(bh))
buffer_error();
-
- set_buffer_req(bh);
+
+ /* Only clear out a write error when rewriting */
+ if (test_set_buffer_req(bh) && rw == WRITE)
+ clear_buffer_write_io_error(bh);

/*
* from here on down, it's all bio -- do the initial mapping,
@@ -2722,13 +2742,14 @@
continue;

get_bh(bh);
- bh->b_end_io = end_buffer_io_sync;
if (rw == WRITE) {
+ bh->b_end_io = end_buffer_write_sync;
if (test_clear_buffer_dirty(bh)) {
submit_bh(WRITE, bh);
continue;
}
} else {
+ bh->b_end_io = end_buffer_read_sync;
if (!buffer_uptodate(bh)) {
submit_bh(rw, bh);
continue;
@@ -2749,7 +2770,7 @@
lock_buffer(bh);
if (test_clear_buffer_dirty(bh)) {
get_bh(bh);
- bh->b_end_io = end_buffer_io_sync;
+ bh->b_end_io = end_buffer_write_sync;
submit_bh(WRITE, bh);
wait_on_buffer(bh);
} else {
@@ -2808,6 +2829,8 @@
bh = head;
do {
check_ttfb_buffer(page, bh);
+ if (buffer_write_io_error(bh))
+ page->mapping->error = -EIO;
if (buffer_busy(bh))
goto failed;
if (!buffer_uptodate(bh) && !buffer_req(bh))
diff -urN -x '*.ver' -x '.patch*' -x '*.orig' orig/fs/inode.c patched/fs/inode.c
--- orig/fs/inode.c 2003-05-21 11:03:26.000000000 -0500
+++ patched/fs/inode.c 2003-05-21 12:37:26.000000000 -0500
@@ -144,6 +144,7 @@
mapping->dirtied_when = 0;
mapping->assoc_mapping = NULL;
mapping->backing_dev_info = &default_backing_dev_info;
+ mapping->error = 0;
if (sb->s_bdev)
mapping->backing_dev_info = sb->s_bdev->bd_inode->i_mapping->backing_dev_info;
memset(&inode->u, 0, sizeof(inode->u));
diff -urN -x '*.ver' -x '.patch*' -x '*.orig' orig/fs/mpage.c patched/fs/mpage.c
--- orig/fs/mpage.c 2003-04-19 21:48:55.000000000 -0500
+++ patched/fs/mpage.c 2003-05-21 12:37:26.000000000 -0500
@@ -388,6 +388,7 @@
mpage_writepage(struct bio *bio, struct page *page, get_block_t get_block,
sector_t *last_block_in_bio, int *ret, struct writeback_control *wbc)
{
+ struct address_space *mapping = page->mapping;
struct inode *inode = page->mapping->host;
const unsigned blkbits = inode->i_blkbits;
unsigned long end_index;
@@ -562,6 +563,17 @@
if (bio)
bio = mpage_bio_submit(WRITE, bio);
*ret = page->mapping->a_ops->writepage(page, wbc);
+ if (*ret < 0) {
+ /*
+ * lock the page to keep truncate away
+ * then check that it is still on the
+ * mapping.
+ */
+ lock_page(page);
+ if (page->mapping == mapping)
+ mapping->error = *ret;
+ unlock_page(page);
+ }
out:
return bio;
}
@@ -665,6 +677,17 @@
test_clear_page_dirty(page)) {
if (writepage) {
ret = (*writepage)(page, wbc);
+ if (ret < 0) {
+ /*
+ * lock the page to keep truncate away
+ * then check that it is still on the
+ * mapping.
+ */
+ lock_page(page);
+ if (page->mapping == mapping)
+ mapping->error = ret;
+ unlock_page(page);
+ }
} else {
bio = mpage_writepage(bio, page, get_block,
&last_block_in_bio, &ret, wbc);
diff -urN -x '*.ver' -x '.patch*' -x '*.orig' orig/fs/ntfs/compress.c patched/fs/ntfs/compress.c
--- orig/fs/ntfs/compress.c 2003-05-12 14:34:30.000000000 -0500
+++ patched/fs/ntfs/compress.c 2003-05-21 12:37:26.000000000 -0500
@@ -643,7 +643,7 @@
continue;
}
atomic_inc(&tbh->b_count);
- tbh->b_end_io = end_buffer_io_sync;
+ tbh->b_end_io = end_buffer_read_sync;
submit_bh(READ, tbh);
}

diff -urN -x '*.ver' -x '.patch*' -x '*.orig' orig/fs/open.c patched/fs/open.c
--- orig/fs/open.c 2003-05-21 11:03:26.000000000 -0500
+++ patched/fs/open.c 2003-05-21 12:37:26.000000000 -0500
@@ -842,21 +842,38 @@
*/
int filp_close(struct file *filp, fl_owner_t id)
{
- int retval;
+ struct address_space *mapping = filp->f_dentry->d_inode->i_mapping;
+ int retval = 0, err;
+
+ /* Report and clear outstanding errors */
+ err = filp->f_error;
+ if (err) {
+ filp->f_error = 0;
+ retval = err;
+ }
+
+ err = mapping->error;
+ if (err && !retval) {
+ mapping->error = 0;
+ retval = err;
+ }

if (!file_count(filp)) {
printk(KERN_ERR "VFS: Close: file count is 0\n");
- return 0;
+ return retval;
}
- retval = 0;
+
if (filp->f_op && filp->f_op->flush) {
lock_kernel();
- retval = filp->f_op->flush(filp);
+ err = filp->f_op->flush(filp);
unlock_kernel();
+ if (err && !retval)
+ retval = err;
}
dnotify_flush(filp, id);
locks_remove_posix(filp, id);
fput(filp);
+
return retval;
}

diff -urN -x '*.ver' -x '.patch*' -x '*.orig' orig/include/linux/buffer_head.h patched/include/linux/buffer_head.h
--- orig/include/linux/buffer_head.h 2003-05-21 11:03:28.000000000 -0500
+++ patched/include/linux/buffer_head.h 2003-05-21 12:42:06.000000000 -0500
@@ -24,8 +24,9 @@
BH_Async_Read, /* Is under end_buffer_async_read I/O */
BH_Async_Write, /* Is under end_buffer_async_write I/O */
BH_Delay, /* Buffer is not yet allocated on disk */
-
BH_Boundary, /* Block is followed by a discontiguity */
+ BH_Write_EIO, /* I/O error on write */
+
BH_PrivateStart,/* not a state bit, but the first bit available
* for private allocation by other entities
*/
@@ -109,12 +110,14 @@
BUFFER_FNS(Lock, locked)
TAS_BUFFER_FNS(Lock, locked)
BUFFER_FNS(Req, req)
+TAS_BUFFER_FNS(Req, req)
BUFFER_FNS(Mapped, mapped)
BUFFER_FNS(New, new)
BUFFER_FNS(Async_Read, async_read)
BUFFER_FNS(Async_Write, async_write)
-BUFFER_FNS(Delay, delay);
+BUFFER_FNS(Delay, delay)
BUFFER_FNS(Boundary, boundary)
+BUFFER_FNS(Write_EIO,write_io_error)

#define bh_offset(bh) ((unsigned long)(bh)->b_data & ~PAGE_MASK)
#define touch_buffer(bh) mark_page_accessed(bh->b_page)
@@ -139,7 +142,8 @@
int try_to_free_buffers(struct page *);
void create_empty_buffers(struct page *, unsigned long,
unsigned long b_state);
-void end_buffer_io_sync(struct buffer_head *bh, int uptodate);
+void end_buffer_read_sync(struct buffer_head *bh, int uptodate);
+void end_buffer_write_sync(struct buffer_head *bh, int uptodate);
void end_buffer_async_write(struct buffer_head *bh, int uptodate);

/* Things to do with buffers at mapping->private_list */
diff -urN -x '*.ver' -x '.patch*' -x '*.orig' orig/include/linux/fs.h patched/include/linux/fs.h
--- orig/include/linux/fs.h 2003-05-21 11:03:29.000000000 -0500
+++ patched/include/linux/fs.h 2003-05-21 12:37:27.000000000 -0500
@@ -329,6 +329,7 @@
spinlock_t private_lock; /* for use by the address_space */
struct list_head private_list; /* ditto */
struct address_space *assoc_mapping; /* ditto */
+ int error; /* write error for fsync */
};

struct block_device {
diff -urN -x '*.ver' -x '.patch*' -x '*.orig' orig/kernel/ksyms.c patched/kernel/ksyms.c
--- orig/kernel/ksyms.c 2003-05-21 11:03:33.000000000 -0500
+++ patched/kernel/ksyms.c 2003-05-21 12:42:26.000000000 -0500
@@ -175,7 +175,8 @@
EXPORT_SYMBOL(d_lookup);
EXPORT_SYMBOL(d_path);
EXPORT_SYMBOL(mark_buffer_dirty);
-EXPORT_SYMBOL(end_buffer_io_sync);
+EXPORT_SYMBOL(end_buffer_read_sync);
+EXPORT_SYMBOL(end_buffer_write_sync);
EXPORT_SYMBOL(end_buffer_async_write);
EXPORT_SYMBOL(__mark_inode_dirty);
EXPORT_SYMBOL(get_empty_filp);
diff -urN -x '*.ver' -x '.patch*' -x '*.orig' orig/mm/filemap.c patched/mm/filemap.c
--- orig/mm/filemap.c 2003-05-21 11:03:33.000000000 -0500
+++ patched/mm/filemap.c 2003-05-21 12:41:34.000000000 -0500
@@ -199,6 +199,14 @@
spin_lock(&mapping->page_lock);
}
spin_unlock(&mapping->page_lock);
+
+ /* Check for outstanding write errors */
+ if (mapping->error)
+ {
+ ret = mapping->error;
+ mapping->error = 0;
+ }
+
return ret;
}

diff -urN -x '*.ver' -x '.patch*' -x '*.orig' orig/mm/vmscan.c patched/mm/vmscan.c
--- orig/mm/vmscan.c 2003-05-21 11:03:33.000000000 -0500
+++ patched/mm/vmscan.c 2003-05-21 12:37:27.000000000 -0500
@@ -340,6 +340,20 @@
SetPageReclaim(page);
res = mapping->a_ops->writepage(page, &wbc);

+ if (res < 0) {
+ /*
+ * lock the page to keep truncate away
+ * then check that it is still on the
+ * mapping.
+ */
+ lock_page(page);
+ if (page->mapping == mapping)
+ mapping->error = res;
+ unlock_page(page);
+ }
+ if (res < 0) {
+ mapping->error = res;
+ }
if (res == WRITEPAGE_ACTIVATE) {
ClearPageReclaim(page);
goto activate_locked;

--
Matt Mackall : http://www.selenic.com : of or relating to the moon

2003-05-29 19:31:17

[permalink] [raw]

Subject: [PATCH] write errors [2/3] flags

Combine mapping->error and ->gfp_mask into ->flags

diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/drivers/block/loop.c patched/drivers/block/loop.c
--- orig/drivers/block/loop.c 2003-05-29 12:49:24.000000000 -0500
+++ patched/drivers/block/loop.c 2003-05-29 12:52:28.000000000 -0500
@@ -714,8 +714,8 @@
fput(file);
goto out_putf;
}
- lo->old_gfp_mask = inode->i_mapping->gfp_mask;
- inode->i_mapping->gfp_mask = GFP_NOIO;
+ lo->old_gfp_mask = mapping_gfp_mask(inode->i_mapping);
+ mapping_set_gfp_mask(inode->i_mapping, GFP_NOIO);

set_blocksize(bdev, lo_blocksize);

@@ -823,7 +823,7 @@
memset(lo->lo_name, 0, LO_NAME_SIZE);
invalidate_bdev(bdev, 0);
set_capacity(disks[lo->lo_number], 0);
- filp->f_dentry->d_inode->i_mapping->gfp_mask = gfp;
+ mapping_set_gfp_mask(filp->f_dentry->d_inode->i_mapping, gfp);
lo->lo_state = Lo_unbound;
fput(filp);
/* This is safe: open() is still holding a reference. */
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/fs/block_dev.c patched/fs/block_dev.c
--- orig/fs/block_dev.c 2003-05-29 12:49:42.000000000 -0500
+++ patched/fs/block_dev.c 2003-05-29 12:52:28.000000000 -0500
@@ -318,7 +318,7 @@
inode->i_rdev = kdev;
inode->i_bdev = new_bdev;
inode->i_data.a_ops = &def_blk_aops;
- inode->i_data.gfp_mask = GFP_USER;
+ mapping_set_gfp_mask(&inode->i_data, GFP_USER);
inode->i_data.backing_dev_info = &default_backing_dev_info;
spin_lock(&bdev_lock);
bdev = bdfind(dev, head);
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/fs/buffer.c patched/fs/buffer.c
--- orig/fs/buffer.c 2003-05-29 12:52:33.000000000 -0500
+++ patched/fs/buffer.c 2003-05-29 12:52:28.000000000 -0500
@@ -600,7 +600,7 @@
buffer_io_error(bh);
printk(KERN_WARNING "lost page write due to I/O error on %s\n",
bdevname(bh->b_bdev, b));
- page->mapping->error = -EIO;
+ set_bit(AS_EIO, &page->mapping->flags);
clear_buffer_uptodate(bh);
SetPageError(page);
}
@@ -2846,7 +2846,7 @@
do {
check_ttfb_buffer(page, bh);
if (buffer_write_io_error(bh))
- page->mapping->error = -EIO;
+ set_bit(AS_EIO, &page->mapping->flags);
if (buffer_busy(bh))
goto failed;
if (!buffer_uptodate(bh) && !buffer_req(bh))
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/fs/inode.c patched/fs/inode.c
--- orig/fs/inode.c 2003-05-29 12:52:33.000000000 -0500
+++ patched/fs/inode.c 2003-05-29 12:53:07.000000000 -0500
@@ -18,6 +18,7 @@
#include <linux/hash.h>
#include <linux/swap.h>
#include <linux/security.h>
+#include <linux/pagemap.h>
#include <linux/cdev.h>

/*
@@ -142,11 +143,11 @@

mapping->a_ops = &empty_aops;
mapping->host = inode;
- mapping->gfp_mask = GFP_HIGHUSER;
+ mapping->flags = 0;
+ mapping_set_gfp_mask(mapping, GFP_HIGHUSER);
mapping->dirtied_when = 0;
mapping->assoc_mapping = NULL;
mapping->backing_dev_info = &default_backing_dev_info;
- mapping->error = 0;
if (sb->s_bdev)
mapping->backing_dev_info = sb->s_bdev->bd_inode->i_mapping->backing_dev_info;
memset(&inode->u, 0, sizeof(inode->u));
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/fs/jfs/inode.c patched/fs/jfs/inode.c
--- orig/fs/jfs/inode.c 2003-04-19 21:48:46.000000000 -0500
+++ patched/fs/jfs/inode.c 2003-05-29 12:52:28.000000000 -0500
@@ -20,6 +20,7 @@
#include <linux/fs.h>
#include <linux/mpage.h>
#include <linux/buffer_head.h>
+#include <linux/pagemap.h>
#include "jfs_incore.h"
#include "jfs_filsys.h"
#include "jfs_imap.h"
@@ -57,7 +58,7 @@
inode->i_op = &jfs_dir_inode_operations;
inode->i_fop = &jfs_dir_operations;
inode->i_mapping->a_ops = &jfs_aops;
- inode->i_mapping->gfp_mask = GFP_NOFS;
+ mapping_set_gfp_mask(inode->i_mapping, GFP_NOFS);
} else if (S_ISLNK(inode->i_mode)) {
if (inode->i_size >= IDATASIZE) {
inode->i_op = &page_symlink_inode_operations;
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/fs/jfs/jfs_imap.c patched/fs/jfs/jfs_imap.c
--- orig/fs/jfs/jfs_imap.c 2003-04-19 21:48:53.000000000 -0500
+++ patched/fs/jfs/jfs_imap.c 2003-05-29 12:52:28.000000000 -0500
@@ -43,6 +43,7 @@

#include <linux/fs.h>
#include <linux/buffer_head.h>
+#include <linux/pagemap.h>

#include "jfs_incore.h"
#include "jfs_filsys.h"
@@ -504,7 +505,7 @@
}

ip->i_mapping->a_ops = &jfs_aops;
- ip->i_mapping->gfp_mask = GFP_NOFS;
+ mapping_set_gfp_mask(ip->i_mapping, GFP_NOFS);

if ((inum == FILESYSTEM_I) && (JFS_IP(ip)->ipimap == sbi->ipaimap)) {
sbi->gengen = le32_to_cpu(dp->di_gengen);
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/fs/jfs/namei.c patched/fs/jfs/namei.c
--- orig/fs/jfs/namei.c 2003-04-19 21:50:35.000000000 -0500
+++ patched/fs/jfs/namei.c 2003-05-29 12:52:28.000000000 -0500
@@ -257,7 +257,7 @@
ip->i_op = &jfs_dir_inode_operations;
ip->i_fop = &jfs_dir_operations;
ip->i_mapping->a_ops = &jfs_aops;
- ip->i_mapping->gfp_mask = GFP_NOFS;
+ mapping_set_gfp_mask(ip->i_mapping, GFP_NOFS);

insert_inode_hash(ip);
mark_inode_dirty(ip);
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/fs/mpage.c patched/fs/mpage.c
--- orig/fs/mpage.c 2003-05-29 12:52:33.000000000 -0500
+++ patched/fs/mpage.c 2003-05-29 12:52:28.000000000 -0500
@@ -570,8 +570,12 @@
* mapping.
*/
lock_page(page);
- if (page->mapping == mapping)
- mapping->error = *ret;
+ if (page->mapping == mapping) {
+ if (*ret == -EIO)
+ set_bit(AS_EIO, &mapping->flags);
+ else if (*ret == -ENOSPC)
+ set_bit(AS_ENOSPC, &mapping->flags);
+ }
unlock_page(page);
}
out:
@@ -684,8 +688,12 @@
* mapping.
*/
lock_page(page);
- if (page->mapping == mapping)
- mapping->error = ret;
+ if (page->mapping == mapping) {
+ if (ret == -EIO)
+ set_bit(AS_EIO, &mapping->flags);
+ else if (ret == -ENOSPC)
+ set_bit(AS_ENOSPC, &mapping->flags);
+ }
unlock_page(page);
}
} else {
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/fs/open.c patched/fs/open.c
--- orig/fs/open.c 2003-05-29 12:52:33.000000000 -0500
+++ patched/fs/open.c 2003-05-29 12:52:28.000000000 -0500
@@ -20,6 +20,7 @@
#include <linux/mount.h>
#include <linux/vfs.h>
#include <asm/uaccess.h>
+#include <linux/pagemap.h>

#define special_file(m) (S_ISCHR(m)||S_ISBLK(m)||S_ISFIFO(m)||S_ISSOCK(m))

@@ -852,11 +853,10 @@
retval = err;
}

- err = mapping->error;
- if (err && !retval) {
- mapping->error = 0;
- retval = err;
- }
+ if (test_and_clear_bit(AS_ENOSPC, &mapping->flags))
+ retval = -ENOSPC;
+ if (test_and_clear_bit(AS_EIO, &mapping->flags))
+ retval = -EIO;

if (!file_count(filp)) {
printk(KERN_ERR "VFS: Close: file count is 0\n");
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/include/linux/fs.h patched/include/linux/fs.h
--- orig/include/linux/fs.h 2003-05-29 12:52:33.000000000 -0500
+++ patched/include/linux/fs.h 2003-05-29 12:52:28.000000000 -0500
@@ -324,12 +324,11 @@
struct list_head i_mmap_shared; /* list of shared mappings */
struct semaphore i_shared_sem; /* protect both above lists */
unsigned long dirtied_when; /* jiffies of first page dirtying */
- int gfp_mask; /* how to allocate the pages */
+ unsigned long flags; /* error bits/gfp mask */
struct backing_dev_info *backing_dev_info; /* device readahead, etc */
spinlock_t private_lock; /* for use by the address_space */
struct list_head private_list; /* ditto */
struct address_space *assoc_mapping; /* ditto */
- int error; /* write error for fsync */
};

struct block_device {
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/include/linux/gfp.h patched/include/linux/gfp.h
--- orig/include/linux/gfp.h 2003-05-12 14:34:35.000000000 -0500
+++ patched/include/linux/gfp.h 2003-05-29 12:52:28.000000000 -0500
@@ -33,6 +33,9 @@
#define __GFP_NORETRY 0x1000 /* Do not retry. Might fail */
#define __GFP_NO_GROW 0x2000 /* Slab internal usage */

+#define __GFP_BITS_SHIFT 16 /* Room for 16 __GFP_FOO bits */
+#define __GFP_BITS_MASK ((1 << __GFP_BITS_SHIFT) - 1)
+
#define GFP_ATOMIC (__GFP_HIGH)
#define GFP_NOIO (__GFP_WAIT)
#define GFP_NOFS (__GFP_WAIT | __GFP_IO)
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/include/linux/pagemap.h patched/include/linux/pagemap.h
--- orig/include/linux/pagemap.h 2003-05-29 12:52:33.000000000 -0500
+++ patched/include/linux/pagemap.h 2003-05-29 12:52:28.000000000 -0500
@@ -8,7 +8,30 @@
#include <linux/fs.h>
#include <linux/list.h>
#include <linux/highmem.h>
+#include <linux/pagemap.h>
#include <asm/uaccess.h>
+#include <linux/gfp.h>
+
+/*
+ * Bits in mapping->flags. The lower __GFP_BITS_SHIFT bits are the page
+ * allocation mode flags.
+ */
+#define AS_EIO (__GFP_BITS_SHIFT + 0) /* IO error on async write */
+#define AS_ENOSPC (__GFP_BITS_SHIFT + 1) /* ENOSPC on async write */
+
+static inline int mapping_gfp_mask(struct address_space * mapping)
+{
+ return mapping->flags & __GFP_BITS_MASK;
+}
+
+/*
+ * This is non-atomic. Only to be used before the mapping is activated.
+ * Probably needs a barrier...
+ */
+static inline void mapping_set_gfp_mask(struct address_space *m, int mask)
+{
+ m->flags = (m->flags & ~__GFP_BITS_MASK) | mask;
+}

/*
* The page cache can done in larger chunks than
@@ -29,12 +52,12 @@

static inline struct page *page_cache_alloc(struct address_space *x)
{
- return alloc_pages(x->gfp_mask, 0);
+ return alloc_pages(mapping_gfp_mask(x), 0);
}

static inline struct page *page_cache_alloc_cold(struct address_space *x)
{
- return alloc_pages(x->gfp_mask|__GFP_COLD, 0);
+ return alloc_pages(mapping_gfp_mask(x)|__GFP_COLD, 0);
}

typedef int filler_t(void *, struct page *);
@@ -56,7 +79,7 @@
*/
static inline struct page *grab_cache_page(struct address_space *mapping, unsigned long index)
{
- return find_or_create_page(mapping, index, mapping->gfp_mask);
+ return find_or_create_page(mapping, index, mapping_gfp_mask(mapping));
}

extern struct page * grab_cache_page_nowait(struct address_space *mapping,
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/mm/filemap.c patched/mm/filemap.c
--- orig/mm/filemap.c 2003-05-29 12:52:33.000000000 -0500
+++ patched/mm/filemap.c 2003-05-29 12:52:28.000000000 -0500
@@ -201,11 +201,10 @@
spin_unlock(&mapping->page_lock);

/* Check for outstanding write errors */
- if (mapping->error)
- {
- ret = mapping->error;
- mapping->error = 0;
- }
+ if (test_and_clear_bit(AS_ENOSPC, &mapping->flags))
+ ret = -ENOSPC;
+ if (test_and_clear_bit(AS_EIO, &mapping->flags))
+ ret = -EIO;

return ret;
}
@@ -591,7 +590,7 @@
page_cache_release(page);
return NULL;
}
- gfp_mask = mapping->gfp_mask & ~__GFP_FS;
+ gfp_mask = mapping_gfp_mask(mapping) & ~__GFP_FS;
page = alloc_pages(gfp_mask, 0);
if (page && add_to_page_cache_lru(page, mapping, index, gfp_mask)) {
page_cache_release(page);
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/mm/shmem.c patched/mm/shmem.c
--- orig/mm/shmem.c 2003-05-29 12:49:55.000000000 -0500
+++ patched/mm/shmem.c 2003-05-29 12:52:28.000000000 -0500
@@ -318,7 +318,7 @@
spin_unlock(&sbinfo->stat_lock);

spin_unlock(&info->lock);
- page = shmem_dir_alloc(inode->i_mapping->gfp_mask);
+ page = shmem_dir_alloc(mapping_gfp_mask(inode->i_mapping));
if (page) {
clear_highpage(page);
page->nr_swapped = 0;
diff -urN -x genksyms -x '*.ver' -x '.patch*' -x '*.orig' orig/mm/vmscan.c patched/mm/vmscan.c
--- orig/mm/vmscan.c 2003-05-29 12:52:34.000000000 -0500
+++ patched/mm/vmscan.c 2003-05-29 12:52:28.000000000 -0500
@@ -347,13 +347,14 @@
* mapping.
*/
lock_page(page);
- if (page->mapping == mapping)
- mapping->error = res;
+ if (page->mapping == mapping) {
+ if (res == -EIO)
+ set_bit(AS_EIO, &mapping->flags);
+ else if (res == -ENOSPC)
+ set_bit(AS_ENOSPC, &mapping->flags);
+ }
unlock_page(page);
}
- if (res < 0) {
- mapping->error = res;
- }
if (res == WRITEPAGE_ACTIVATE) {
ClearPageReclaim(page);
goto activate_locked;

--
Matt Mackall : http://www.selenic.com : of or relating to the moon

2003-05-29 19:32:33