diff options
| author | Hoang-Nam Nguyen <hnguyen@linux.vnet.ibm.com> | 2007-01-09 18:04:14 +0100 |
|---|---|---|
| committer | Roland Dreier <rolandd@cisco.com> | 2007-01-09 14:14:24 -0800 |
| commit | f2d9136133de257abbd97fec6f624d3a73d1e1fd (patch) | |
| tree | eece9275aaab3755855d49bbbaef9ec430fdd634 /drivers/infiniband/hw/ehca/ehca_irq.c | |
| parent | 98714cb161b4b1a5d0c5bd0337a8578196b73677 (diff) | |
| download | linux-f2d9136133de257abbd97fec6f624d3a73d1e1fd.tar.gz linux-f2d9136133de257abbd97fec6f624d3a73d1e1fd.tar.bz2 linux-f2d9136133de257abbd97fec6f624d3a73d1e1fd.zip | |
IB/ehca: Use proper GFP_ flags for get_zeroed_page()
Here is a patch for ehca to use proper flag, ie. GFP_ATOMIC
resp. GFP_KERNEL, when calling get_zeroed_page() to prevent "Bug:
scheduling while atomic...". This error does not cause a kernel panic
but makes ipoib un-usable afterwards. It is reproducible on
2.6.20-rc4 if one does ifconfig down during a flood ping test. I have
not observed this error in earlier releases incl. 2.6.20-rc1.
This error occurs when a qp event/irq is received and ehca event
handler allocates a control block/page to obtain HCA error data block.
Use of GFP_ATOMIC when in interrupt context prevents this issue.
Signed-off-by Hoang-Nam Nguyen <hnguyen@de.ibm.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Diffstat (limited to 'drivers/infiniband/hw/ehca/ehca_irq.c')
| -rw-r--r-- | drivers/infiniband/hw/ehca/ehca_irq.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c b/drivers/infiniband/hw/ehca/ehca_irq.c index c3ea746e9045..e7209afb4250 100644 --- a/drivers/infiniband/hw/ehca/ehca_irq.c +++ b/drivers/infiniband/hw/ehca/ehca_irq.c @@ -138,7 +138,7 @@ int ehca_error_data(struct ehca_shca *shca, void *data, u64 *rblock; unsigned long block_count; - rblock = ehca_alloc_fw_ctrlblock(); + rblock = ehca_alloc_fw_ctrlblock(GFP_ATOMIC); if (!rblock) { ehca_err(&shca->ib_device, "Cannot allocate rblock memory."); ret = -ENOMEM; |