can close the loop for 64bit mmio resource allocation.
>
Just FYI, a Mellanox net card failed after exactly this patch.
3.13-rc7 + bjorn's series is OK. After this patch applied, Mellanox
driver complains:
|mlx4_core 0003:05:00.0: Multiple PFs not yet supported. Skipping PF.
|mlx4_co
again (system does not expose 4G above aperture yet). Not sure what's
the root cause, looks like a driver/firmware/hardware defect.
Thanks
Guo Chao
Thanks
Yinghai
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
>>> causing assign failed eventually.
>
> >>>
> >>> Will you figure out a better way to cover them or just add a 'type3'
> >>> parameter?
> >
> > Looks like we have add type3 for that case.
>
> please check attached delta pat
assign failed eventually.
Will you figure out a better way to cover them or just add a 'type3'
parameter?
Looks like we have add type3 for that case.
please check attached delta patch.
It works, thank you.
Guo Chao
Thanks
Yinghai
---
drivers/pci/setup-bus.c | 17
idge res support with bridge mem res for pref_mem children
> res.
> -v3: refresh and make it can be applied early before for_each_dev_res
> patchset.
>
> Signed-off-by: Yinghai Lu
> Tested-by: Guo Chao
> ---
> drivers/pci/setup-bus.c | 133
> ---
res.
-v3: refresh and make it can be applied early before for_each_dev_res
patchset.
Signed-off-by: Yinghai Lu ying...@kernel.org
Tested-by: Guo Chao y...@linux.vnet.ibm.com
---
drivers/pci/setup-bus.c | 133
drivers/pci/setup-res.c
range, preventing 64-bit MMIO from being used at all.
What's worse, in some machines, 32-bit range is too small to provide
fall back space for prefetchable window, causing all prefetchable
BAR failing to get address.
64-bit MMIO on PowerNV is still pending (but definitely in plan).
So if no one e
is too small to provide
fall back space for prefetchable window, causing all prefetchable
BAR failing to get address.
64-bit MMIO on PowerNV is still pending (but definitely in plan).
So if no one else complained, it seems not fix any problems in upstream.
Thanks,
Guo Chao
-v2: Add release bridge
-like problem
#5 - a little clean up based on #3 and #4
#6 - fix a user triggable oops
#7 - avoid loop device size being messed up by parameters from users
Guo Chao (7):
block: use i_size_write() in bd_set_size()
block: remove redundant check to bd_openers
loopdev: fix
bd_openers is stable under bd_mutex, no need to check it twice.
Cc: Alexander Viro
Cc: linux-fsde...@vger.kernel.org
Signed-off-by: Guo Chao
---
fs/block_dev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 82b7c9a..2f70584 100644
due to invalid parameter)
sudo modprobe loop
(oops)
Clean up nicely to avoid such oops.
Signed-off-by: Guo Chao
---
drivers/block/loop.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 6579f69..9190a82
Update block device size in accord with gendisk size and let userspace
know the change in loop_figure_size(). This is a clean up to remove
common code of loop_figure_size()'s two callers.
Signed-off-by: Guo Chao
---
drivers/block/loop.c | 31 +++
1 file changed, 7
blkdev_ioctl(GETBLKSIZE) uses i_size_read() to read size
of block device. If we update block size directly, reader
may see intermediate result in some machines and configurations.
Use i_size_write() instead.
Cc: Alexander Viro
Cc: linux-fsde...@vger.kernel.org
Signed-off-by: Guo Chao
---
fs
it
with i_mutex in a previous patch, so drop bd_mutex at this site.
Signed-off-by: Guo Chao
---
drivers/block/loop.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index ae12512..7f80653 100644
--- a/drivers/block/loop.c
+++ b/drivers/block
in a block device whose
size is backing file size. If the device is not released after
LOOP_SET_STATUS64 ioctl, blockdev will not see the updated size.
Update block size in LOOP_SET_STATUS64 ioctl.
Reported-by: M. Hindess
Signed-off-by: Guo Chao
---
drivers/block/loop.c |5 +
1 file
error
It makes no sense to do that. Only apply offset when it's positive.
Fix a typo in the comment by the way.
Signed-off-by: Guo Chao
---
drivers/block/loop.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index
in a block device whose
size is backing file size. If the device is not released after
LOOP_SET_STATUS64 ioctl, blockdev will not see the updated size.
Update block size in LOOP_SET_STATUS64 ioctl.
Reported-by: M. Hindess hinde...@uk.ibm.com
Signed-off-by: Guo Chao y...@linux.vnet.ibm.com
error
It makes no sense to do that. Only apply offset when it's positive.
Fix a typo in the comment by the way.
Signed-off-by: Guo Chao y...@linux.vnet.ibm.com
---
drivers/block/loop.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/block/loop.c b/drivers
-by: Guo Chao y...@linux.vnet.ibm.com
---
fs/block_dev.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 172f849..82b7c9a 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1032,7 +1032,9 @@ void bd_set_size(struct block_device *bdev
it
with i_mutex in a previous patch, so drop bd_mutex at this site.
Signed-off-by: Guo Chao y...@linux.vnet.ibm.com
---
drivers/block/loop.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index ae12512..7f80653 100644
--- a/drivers/block/loop.c
due to invalid parameter)
sudo modprobe loop
(oops)
Clean up nicely to avoid such oops.
Signed-off-by: Guo Chao y...@linux.vnet.ibm.com
---
drivers/block/loop.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
Update block device size in accord with gendisk size and let userspace
know the change in loop_figure_size(). This is a clean up to remove
common code of loop_figure_size()'s two callers.
Signed-off-by: Guo Chao y...@linux.vnet.ibm.com
---
drivers/block/loop.c | 31
bd_openers is stable under bd_mutex, no need to check it twice.
Cc: Alexander Viro v...@zeniv.linux.org.uk
Cc: linux-fsde...@vger.kernel.org
Signed-off-by: Guo Chao y...@linux.vnet.ibm.com
---
fs/block_dev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/block_dev.c b
-like problem
#5 - a little clean up based on #3 and #4
#6 - fix a user triggable oops
#7 - avoid loop device size being messed up by parameters from users
Guo Chao (7):
block: use i_size_write() in bd_set_size()
block: remove redundant check to bd_openers
loopdev: fix
;
> efi_free_boot_services();
> }
I just wonder why we compile efi code away explicitly by CONFIG_X86 in
one place and implicitly by if (0) in another place, in the same
function.
Thanks,
Guo Chao
--
To unsubscribe from this list: send the line "unsubscribe linu
explicitly by CONFIG_X86 in
one place and implicitly by if (0) in another place, in the same
function.
Thanks,
Guo Chao
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
per-bucket inode hash lock or
per-superblock inode list lock, did not get merged. I wonder what
stopped them back then and what has changed that (part of) them can be
considered again.
Regards,
Guo Chao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
then and what has changed that (part of) them can be
considered again.
Regards,
Guo Chao
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
On Mon, Sep 24, 2012 at 04:28:12PM +1000, Dave Chinner wrote:
> On Mon, Sep 24, 2012 at 02:12:05PM +0800, Guo Chao wrote:
> > On Mon, Sep 24, 2012 at 02:23:43PM +1000, Dave Chinner wrote:
> > > On Mon, Sep 24, 2012 at 10:42:21AM +0800, Guo Chao wrote:
> > > > On S
On Mon, Sep 24, 2012 at 02:23:43PM +1000, Dave Chinner wrote:
> On Mon, Sep 24, 2012 at 10:42:21AM +0800, Guo Chao wrote:
> > On Sat, Sep 22, 2012 at 08:49:12AM +1000, Dave Chinner wrote:
> >
> > > On Fri, Sep 21, 2012 at 05:31:02PM +0800, Guo Chao wrote:
> > >
On Mon, Sep 24, 2012 at 02:23:43PM +1000, Dave Chinner wrote:
On Mon, Sep 24, 2012 at 10:42:21AM +0800, Guo Chao wrote:
On Sat, Sep 22, 2012 at 08:49:12AM +1000, Dave Chinner wrote:
On Fri, Sep 21, 2012 at 05:31:02PM +0800, Guo Chao wrote:
This patchset optimizes several places which
On Mon, Sep 24, 2012 at 04:28:12PM +1000, Dave Chinner wrote:
On Mon, Sep 24, 2012 at 02:12:05PM +0800, Guo Chao wrote:
On Mon, Sep 24, 2012 at 02:23:43PM +1000, Dave Chinner wrote:
On Mon, Sep 24, 2012 at 10:42:21AM +0800, Guo Chao wrote:
On Sat, Sep 22, 2012 at 08:49:12AM +1000, Dave
On Sat, Sep 22, 2012 at 08:49:12AM +1000, Dave Chinner wrote:
> On Fri, Sep 21, 2012 at 05:31:02PM +0800, Guo Chao wrote:
> > This patchset optimizes several places which take the per inode spin lock.
> > They have not been fully tested yet, thus they are marked as RFC.
>
>
On Sat, Sep 22, 2012 at 08:49:12AM +1000, Dave Chinner wrote:
On Fri, Sep 21, 2012 at 05:31:02PM +0800, Guo Chao wrote:
This patchset optimizes several places which take the per inode spin lock.
They have not been fully tested yet, thus they are marked as RFC.
Inodes are RCU freed
in a
virtual machine, no suspicious log appears.
Guo Chao (4):
fs/inode.c: do not take i_lock on newly allocated inode
fs/inode.c: do not take i_lock in __(insert|remove)_inode_hash
fs/inode.c: do not take i_lock when identify an inode
fs/inode.c: always take i_lock before calling filesystem's
. test_inode_iunique().
Then, fix those functions which take i_lock, e.g. find_inode_fast().
Note this change still put individual filesystem's test() method under
i_lock's protection. See next patch for more.
Signed-off-by: Guo Chao
---
fs/inode.c | 16 +---
1 file changed, 5
.
In __(insert|remove)_inode_hash(), our only goal is to manipulate i_hash, do
not take i_lock in these functions.
Signed-off-by: Guo Chao
---
fs/inode.c |4
1 file changed, 4 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index d2d15aa..54e4b29 100644
--- a/fs/inode.c
+++ b/fs/inode.c
the protection of i_lock in
insert_inode_locked4().
Signed-off-by: Guo Chao
---
fs/inode.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index 89d2bcc..4c7e6e2 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1312,9 +1312,11 @@ int insert_inode_locked4
ock.
This patch fixes three places that take the unnecessary i_lock.
Note in iget5_locked(), I have no strong proof set() should not put the inode
into private lists. Any suggestion?
Signed-off-by: Guo Chao
---
fs/inode.c |6 --
1 file changed, 6 deletions(-)
diff --git a/fs/inode.c b/fs/inod
.
This patch fixes three places that take the unnecessary i_lock.
Note in iget5_locked(), I have no strong proof set() should not put the inode
into private lists. Any suggestion?
Signed-off-by: Guo Chao y...@linux.vnet.ibm.com
---
fs/inode.c |6 --
1 file changed, 6 deletions(-)
diff --git a/fs
the protection of i_lock in
insert_inode_locked4().
Signed-off-by: Guo Chao y...@linux.vnet.ibm.com
---
fs/inode.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index 89d2bcc..4c7e6e2 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1312,9 +1312,11 @@ int
.
In __(insert|remove)_inode_hash(), our only goal is to manipulate i_hash, do
not take i_lock in these functions.
Signed-off-by: Guo Chao y...@linux.vnet.ibm.com
---
fs/inode.c |4
1 file changed, 4 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index d2d15aa..54e4b29 100644
--- a/fs
. test_inode_iunique().
Then, fix those functions which take i_lock, e.g. find_inode_fast().
Note this change still put individual filesystem's test() method under
i_lock's protection. See next patch for more.
Signed-off-by: Guo Chao y...@linux.vnet.ibm.com
---
fs/inode.c | 16
in a
virtual machine, no suspicious log appears.
Guo Chao (4):
fs/inode.c: do not take i_lock on newly allocated inode
fs/inode.c: do not take i_lock in __(insert|remove)_inode_hash
fs/inode.c: do not take i_lock when identify an inode
fs/inode.c: always take i_lock before calling filesystem's
On Sun, Aug 26, 2012 at 03:44:54PM -0500, Andrew Watts wrote:
> BUG: unable to handle kernel NULL pointer dereference at 0064
> IP: [] fsnotify+0x8b/0x270
> *pde =
> Oops: [#1]
> Pid: 14083, comm: firefox Tainted: G O 3.5.2
> EIP: 0060:[] EFLAGS: 00210246 CPU: 0
> EIP is at
On Sun, Aug 26, 2012 at 03:44:54PM -0500, Andrew Watts wrote:
BUG: unable to handle kernel NULL pointer dereference at 0064
IP: [c1109b7d] fsnotify+0x8b/0x270
*pde =
Oops: [#1]
Pid: 14083, comm: firefox Tainted: G O 3.5.2
EIP: 0060:[c1109b7d] EFLAGS: 00210246 CPU: 0
EIP is
46 matches
Mail list logo
