* Re: 2.6.36-rc7: kernel panic with SECURITY_TOMOYO=y
From: KOSAKI Motohiro @ 2010-10-08 4:55 UTC (permalink / raw)
To: Christian Kujau; +Cc: kosaki.motohiro, LKML, takedakn, penguin-kernel
In-Reply-To: <alpine.DEB.2.01.1010071637090.21082@trent.utfs.org>
> On Thu, 7 Oct 2010 at 15:43, Christian Kujau wrote:
> > Kernel panic - not syncing: Profile uersion 0 is not supported
>
> OK, I just saw that security/tomoyo/common.c panics when:
>
> if (tomoyo_profile_version != 20090903)
> panic("Profile version %u is not supported.\n",
> tomoyo_profile_version);
>
> If it's imperative that the profile version is somewhat current (mine was
> not, I had old tomoyo-ccstools installed), I would have expected a
> slightly more descriptive error messages (apart from that panic), but now
> I know. Upgraded to tomoyo-tools-2.3.0-20100820 did the trick.
I agree this zero information panic is suck.
Handa-san, please see this panic message again.
> Kernel panic - not syncing: Profile uersion 0 is not supported
Profile?
This message doesn't have any information which should we look!
And, 'profile' is wrong word. TOMOYO have to recommend to upgrade
userland tools here at minimum.
The best way is, of cource, you don't break backward compatibility.
> Call Trace:
> [efB4fd60] [c0008c88] show_stack+0x48/0x168 (unreliable)
> [ef84fda0] [c0375fe01 panic+0xa4/0x1ec
> [ef84fdf0] [c01c5f30] tomoyo_close_control+0x0/0xa4
> [efB4fe00] [c01cc2f0] tomoyo_load_policy+0xeB/0x11c
^ permalink raw reply
* Re: [PATCH v2] memcg: reduce lock time at move charge (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: Andrew Morton @ 2010-10-08 4:55 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Daisuke Nishimura, Minchan Kim, Greg Thelen, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <20101008133712.2a836331.kamezawa.hiroyu@jp.fujitsu.com>
On Fri, 8 Oct 2010 13:37:12 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Thu, 7 Oct 2010 16:14:54 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > On Thu, 7 Oct 2010 17:04:05 +0900
> > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> >
> > > Now, at task migration among cgroup, memory cgroup scans page table and moving
> > > account if flags are properly set.
> > >
> > > The core code, mem_cgroup_move_charge_pte_range() does
> > >
> > > pte_offset_map_lock();
> > > for all ptes in a page table:
> > > 1. look into page table, find_and_get a page
> > > 2. remove it from LRU.
> > > 3. move charge.
> > > 4. putback to LRU. put_page()
> > > pte_offset_map_unlock();
> > >
> > > for pte entries on a 3rd level? page table.
> > >
> > > This pte_offset_map_lock seems a bit long. This patch modifies a rountine as
> > >
> > > for 32 pages: pte_offset_map_lock()
> > > find_and_get a page
> > > record it
> > > pte_offset_map_unlock()
> > > for all recorded pages
> > > isolate it from LRU.
> > > move charge
> > > putback to LRU
> > > for all recorded pages
> > > put_page()
> >
> > The patch makes the code larger, more complex and slower!
> >
>
> Slower ?
Sure. It walks the same data three times, potentially causing
thrashing in the L1 cache. It takes and releases locks at a higher
frequency. It increases the text size.
^ permalink raw reply
* RE: [PATCH 2/2] davinci: Platform support for OMAP-L137/AM17x NOR flash driver
From: Nori, Sekhar @ 2010-10-08 4:54 UTC (permalink / raw)
To: Sergei Shtylyov, Dharmappa, Savinay
Cc: Aleksey Makarov, davinci-linux-open-source@linux.davincidsp.com,
linux-mtd@lists.infradead.org, David Griego
In-Reply-To: <4CADE1B8.50800@mvista.com>
Hi Sergei,
On Thu, Oct 07, 2010 at 20:35:28, Sergei Shtylyov wrote:
> > +static void da830_evm_nor_done(void *data)
> > +{
> > + clk_disable(da830_evm_nor.clk);
> > + clk_put(da830_evm_nor.clk);
> > + iounmap(da830_evm_nor.latch.addr);
> > + release_mem_region(DA8XX_AEMIF_CS3_BASE, PAGE_SIZE);
> > + iounmap(da830_evm_nor.aemif.addr);
> > + release_mem_region(DA8XX_AEMIF_CTL_BASE, SZ_32K);
> > +}
>
> Why you've changed this function which was useful also for the error cleanup
> before?
The issues down below aside, I think goto based error handling
is clearer to follow. Any objections to using goto based
error handing per-se?
Thanks,
Sekhar
>
> > +static int da830_evm_nor_init(void *data, int cs)
> > +{
> > + /* Turn on AEMIF clocks */
> > + da830_evm_nor.clk = clk_get(NULL, "aemif");
> > + if (IS_ERR(da830_evm_nor.clk)) {
> > + pr_err("%s: could not get AEMIF clock\n", __func__);
> > + da830_evm_nor.clk = NULL;
> > + return -ENODEV;
> > + }
> > + clk_enable(da830_evm_nor.clk);
> > +
> > + da830_evm_nor.aemif.res = request_mem_region(DA8XX_AEMIF_CTL_BASE,
> > + SZ_32K, "AEMIF control");
> > + if (da830_evm_nor.aemif.res == NULL) {
> > + pr_err("%s: could not request AEMIF control region\n",
> > + __func__);
> > + goto err_aemif_region;
>
> I wonder why you used goto's at all. Anyway, the error cleanup code is
> completely broken now.
>
> > + }
> > +
> > + da830_evm_nor.aemif.addr = ioremap_nocache(DA8XX_AEMIF_CTL_BASE,
> > + SZ_32K);
> > + if (da830_evm_nor.aemif.addr == NULL) {
> > + pr_err("%s: could not remap AEMIF control region\n", __func__);
> > + goto err_aemif_ioremap;
> > + }
> > +
> > + /* Setup AEMIF -- timings, etc. */
> > +
> > + /* Set maximum wait cycles */
> > + davinci_aemif_setup_timing(&da830_evm_norflash_timing,
> > + da830_evm_nor.aemif.addr, cs);
> > +
> > + davinci_aemif_setup_timing(&da830_evm_norflash_timing,
> > + da830_evm_nor.aemif.addr, cs + 1);
> > +
> > + /* Setup the window to access the latch */
> > + da830_evm_nor.latch.res =
> > + request_mem_region(DA8XX_AEMIF_CS3_BASE, PAGE_SIZE,
> > + "DA830 UI NOR address latch");
> > + if (da830_evm_nor.latch.res == NULL) {
> > + pr_err("%s: could not request address latch region\n",
> > + __func__);
> > + goto err_latch_region;
> > + }
> > +
> > + da830_evm_nor.latch.addr =
> > + ioremap_nocache(DA8XX_AEMIF_CS3_BASE, PAGE_SIZE);
> > + if (da830_evm_nor.latch.addr == NULL) {
> > + pr_err("%s: could not remap address latch region\n", __func__);
> > + goto err_latch_ioremap;
> > + }
> > + return 0;
> > +
> > +err_aemif_region:
> > + release_mem_region(DA8XX_AEMIF_CTL_BASE, SZ_32K);
>
> Why release what you've just failed to request?!
>
> > + da830_evm_nor.aemif.res = NULL;
>
> Useless assignment.
>
> > + return -EBUSY;
>
> And you're not calling clk_disable().
>
> > +err_aemif_ioremap:
> > + iounmap(da830_evm_nor.aemif.addr);
>
> Why unmap what you've just failed to map?! da830_evm_nor.aemif.addr is NULL.
>
> > + da830_evm_nor.aemif.addr = NULL;
>
> Useless assignment.
>
> > + return -ENOMEM;
>
> You're not calling release_mem_region() and clk_disable().
>
> > +err_latch_region:
> > + release_mem_region(DA8XX_AEMIF_CS3_BASE, PAGE_SIZE);
>
> Why release what you've just failed to request?!
>
> > + da830_evm_nor.latch.res = NULL;
>
> Useless assginment.
>
> > + return -EBUSY;
>
> You're not calling iounmap() and release_mem_region() for the NOR flash
> region and also not calling clk_disable().
>
> > +
> > +err_latch_ioremap:
> > + iounmap(da830_evm_nor.latch.addr);
>
> Why unmap what you've just failed to map?! da830_evm_nor.latch.addr is NULL.
>
> > + da830_evm_nor.latch.addr = NULL;
>
> Useless assginment.
>
> > + return -ENOMEM;
>
> You're not release_mem_region() for the latch region, not calling iounmap()
> and release_mem_region() for the NOR flash region and also not calling
> clk_disable().
>
> > +}
> [...]
>
> Your changes made me doubt that you actually understood the code well enough
> before doing them...
>
> WBR, Sergei
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
^ permalink raw reply
* Re: Ok, dumb question time ...
From: Neil Brown @ 2010-10-08 4:54 UTC (permalink / raw)
To: landman; +Cc: linux-raid
In-Reply-To: <4CAE9C13.3060002@scalableinformatics.com>
On Fri, 08 Oct 2010 00:20:35 -0400
Joe Landman <landman@scalableinformatics.com> wrote:
> Not having much luck with this. Let me explain ...
>
> Imagine we have a RAID1 with 3 elements. It was originally a RAID1 with
> 2 elements, and we added a 3rd using
>
> mdadm /dev/md0 --add /dev/loop1
>
> What I want to do is conceptually very simple. I want to permanently
> remove loop1, without having the array become dirty, or degraded. That
> is, I would like
>
> mdadm /dev/md0 --fail /dev/loop1 --remove /dev/loop1
>
> to result in a clean array with two members.
>
> It doesn't. The array is marked as being in the "clean, degraded"
> state. Which, as it is the root file system array, has the unfortunate
> side effect of not allowing the RAID1 to properly assemble at boot (that
> degraded state).
>
> So ... can I force the array to either remove the extra unneeded loop1
> device, and update its metadata properly ... or force it into a clean,
> active state without the loop1 device, or force the assembly on boot to
> occur regardless of what it thinks it should have?
>
> This is quite disconcerting ... I thought it would be simple.
It is.
You want the array to think that it only has two devices?
mdadm --grow /dev/md0 --raid-devices=2
Done.
NeilBrown
^ permalink raw reply
* Re: [PATCH] remove leftover rcu_read_unlock calls from __mkroute_output
From: Eric Dumazet @ 2010-10-08 4:47 UTC (permalink / raw)
To: Dimitris Michailidis; +Cc: netdev
In-Reply-To: <1286498918-30636-1-git-send-email-dm@chelsio.com>
Le jeudi 07 octobre 2010 à 17:48 -0700, Dimitris Michailidis a écrit :
> Commit "fib: RCU conversion of fib_lookup()" removed rcu_read_lock() from
> __mkroute_output but left a couple of calls to rcu_read_unlock() in there.
> This causes lockdep to complain that the rcu_read_unlock() call in
> __ip_route_output_key causes a lock inbalance and quickly crashes the
> kernel. The below fixes this for me.
>
> Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Thanks Dimitris !
^ permalink raw reply
* Re: [PATCH] memcg: lock-free clear page writeback (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: KAMEZAWA Hiroyuki @ 2010-10-08 4:41 UTC (permalink / raw)
To: Minchan Kim
Cc: Daisuke Nishimura, Greg Thelen, Andrew Morton, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <AANLkTi=kBnrtb5KkFQE3tNwVh1dWeUVBepWjec7ReVL0@mail.gmail.com>
On Fri, 8 Oct 2010 08:35:30 +0900
Minchan Kim <minchan.kim@gmail.com> wrote:
> Hi Kame,
>
> On Thu, Oct 7, 2010 at 3:24 PM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > Greg, I think clear_page_writeback() will not require _any_ locks with this patch.
> > But set_page_writeback() requires it...
> > (Maybe adding a special function for clear_page_writeback() is better rather than
> > A adding some complex to switch() in update_page_stat())
> >
> > ==
> > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> >
> > Now, at page information accounting, we do lock_page_cgroup() if pc->mem_cgroup
> > points to a cgroup where someone is moving charges from.
> >
> > At supporing dirty-page accounting, one of troubles is writeback bit.
> > In general, writeback can be cleared via IRQ context. To update writeback bit
> > with lock_page_cgroup() in safe way, we'll have to disable IRQ.
> > ....or do something.
> >
> > This patch waits for completion of writeback under lock_page() and do
> > lock_page_cgroup() in safe way. (We never got end_io via IRQ context.)
> >
> > By this, writeback-accounting will never see race with account_move() and
> > it can trust pc->mem_cgroup always _without_ any lock.
> >
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > ---
> > A mm/memcontrol.c | A 18 ++++++++++++++++++
> > A 1 file changed, 18 insertions(+)
> >
> > Index: mmotm-0928/mm/memcontrol.c
> > ===================================================================
> > --- mmotm-0928.orig/mm/memcontrol.c
> > +++ mmotm-0928/mm/memcontrol.c
> > @@ -2183,17 +2183,35 @@ static void __mem_cgroup_move_account(st
> > A /*
> > A * check whether the @pc is valid for moving account and call
> > A * __mem_cgroup_move_account()
> > + * Don't call this under pte_lock etc...we'll do lock_page() and wait for
> > + * the end of I/O.
> > A */
> > A static int mem_cgroup_move_account(struct page_cgroup *pc,
> > A A A A A A A A struct mem_cgroup *from, struct mem_cgroup *to, bool uncharge)
> > A {
> > A A A A int ret = -EINVAL;
> > +
> > + A A A /*
> > + A A A A * We move severl flags and accounting information here. So we need to
> > + A A A A * avoid the races with update_stat routines. For most of routines,
> > + A A A A * lock_page_cgroup() is enough for avoiding race. But we need to take
> > + A A A A * care of IRQ context. If flag updates comes from IRQ context, This
> > + A A A A * "move account" will be racy (and cause deadlock in lock_page_cgroup())
> > + A A A A *
> > + A A A A * Now, the only race we have is Writeback flag. We wait for it cleared
> > + A A A A * before starting our jobs.
> > + A A A A */
> > +
> > + A A A lock_page(pc->page);
> > + A A A wait_on_page_writeback(pc->page);
> > +
> > A A A A lock_page_cgroup(pc);
> > A A A A if (PageCgroupUsed(pc) && pc->mem_cgroup == from) {
> > A A A A A A A A __mem_cgroup_move_account(pc, from, to, uncharge);
> > A A A A A A A A ret = 0;
> > A A A A }
> > A A A A unlock_page_cgroup(pc);
> > + A A A unlock_page(pc->page);
> > A A A A /*
> > A A A A * check events
> > A A A A */
> >
> >
>
> Looks good to me.
> But let me ask a question.
> Why do only move_account need this logic?
Because charge/uncharge (add/remove to radix-tree or swapcache)
never happens while a page is PG_writeback.
> Is deadlock candidate is only this place?
yes.
> How about mem_cgroup_prepare_migration?
>
> unmap_and_move
> lock_page
> mem_cgroup_prepare_migration
> lock_page_cgroup
> ...
> softirq happen
> lock_page_cgroup
>
>
Nice cactch. I'll move prepare_migraon after wait_on_page_writeback()
> If race happens only where move_account and writeback, please describe
> it as comment.
> It would help to review the code in future.
>
Sure, updates are necessary.
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] memcg: lock-free clear page writeback (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: KAMEZAWA Hiroyuki @ 2010-10-08 4:41 UTC (permalink / raw)
To: Minchan Kim
Cc: Daisuke Nishimura, Greg Thelen, Andrew Morton, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <AANLkTi=kBnrtb5KkFQE3tNwVh1dWeUVBepWjec7ReVL0@mail.gmail.com>
On Fri, 8 Oct 2010 08:35:30 +0900
Minchan Kim <minchan.kim@gmail.com> wrote:
> Hi Kame,
>
> On Thu, Oct 7, 2010 at 3:24 PM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > Greg, I think clear_page_writeback() will not require _any_ locks with this patch.
> > But set_page_writeback() requires it...
> > (Maybe adding a special function for clear_page_writeback() is better rather than
> > adding some complex to switch() in update_page_stat())
> >
> > ==
> > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> >
> > Now, at page information accounting, we do lock_page_cgroup() if pc->mem_cgroup
> > points to a cgroup where someone is moving charges from.
> >
> > At supporing dirty-page accounting, one of troubles is writeback bit.
> > In general, writeback can be cleared via IRQ context. To update writeback bit
> > with lock_page_cgroup() in safe way, we'll have to disable IRQ.
> > ....or do something.
> >
> > This patch waits for completion of writeback under lock_page() and do
> > lock_page_cgroup() in safe way. (We never got end_io via IRQ context.)
> >
> > By this, writeback-accounting will never see race with account_move() and
> > it can trust pc->mem_cgroup always _without_ any lock.
> >
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > ---
> > mm/memcontrol.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > Index: mmotm-0928/mm/memcontrol.c
> > ===================================================================
> > --- mmotm-0928.orig/mm/memcontrol.c
> > +++ mmotm-0928/mm/memcontrol.c
> > @@ -2183,17 +2183,35 @@ static void __mem_cgroup_move_account(st
> > /*
> > * check whether the @pc is valid for moving account and call
> > * __mem_cgroup_move_account()
> > + * Don't call this under pte_lock etc...we'll do lock_page() and wait for
> > + * the end of I/O.
> > */
> > static int mem_cgroup_move_account(struct page_cgroup *pc,
> > struct mem_cgroup *from, struct mem_cgroup *to, bool uncharge)
> > {
> > int ret = -EINVAL;
> > +
> > + /*
> > + * We move severl flags and accounting information here. So we need to
> > + * avoid the races with update_stat routines. For most of routines,
> > + * lock_page_cgroup() is enough for avoiding race. But we need to take
> > + * care of IRQ context. If flag updates comes from IRQ context, This
> > + * "move account" will be racy (and cause deadlock in lock_page_cgroup())
> > + *
> > + * Now, the only race we have is Writeback flag. We wait for it cleared
> > + * before starting our jobs.
> > + */
> > +
> > + lock_page(pc->page);
> > + wait_on_page_writeback(pc->page);
> > +
> > lock_page_cgroup(pc);
> > if (PageCgroupUsed(pc) && pc->mem_cgroup == from) {
> > __mem_cgroup_move_account(pc, from, to, uncharge);
> > ret = 0;
> > }
> > unlock_page_cgroup(pc);
> > + unlock_page(pc->page);
> > /*
> > * check events
> > */
> >
> >
>
> Looks good to me.
> But let me ask a question.
> Why do only move_account need this logic?
Because charge/uncharge (add/remove to radix-tree or swapcache)
never happens while a page is PG_writeback.
> Is deadlock candidate is only this place?
yes.
> How about mem_cgroup_prepare_migration?
>
> unmap_and_move
> lock_page
> mem_cgroup_prepare_migration
> lock_page_cgroup
> ...
> softirq happen
> lock_page_cgroup
>
>
Nice cactch. I'll move prepare_migraon after wait_on_page_writeback()
> If race happens only where move_account and writeback, please describe
> it as comment.
> It would help to review the code in future.
>
Sure, updates are necessary.
Thanks,
-Kame
^ permalink raw reply
* Re: [PATCH] ehea: Fix a checksum issue on the receive path
From: Eric Dumazet @ 2010-10-08 4:45 UTC (permalink / raw)
To: leitao; +Cc: davem, netdev, Jay Vosburgh
In-Reply-To: <1286493453-21784-1-git-send-email-leitao@linux.vnet.ibm.com>
Le jeudi 07 octobre 2010 à 19:17 -0400, leitao@linux.vnet.ibm.com a
écrit :
> Currently we set all skbs with CHECKSUM_UNNECESSARY, even
> those whose protocol we don't know. This patch just
> add the CHECKSUM_COMPLETE tag for non TCP/UDP packets.
>
> Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
> ---
> drivers/net/ehea/ehea_main.c | 9 ++++++++-
> drivers/net/ehea/ehea_qmr.h | 1 +
> 2 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
> index 0471cae..45fd045 100644
> --- a/drivers/net/ehea/ehea_main.c
> +++ b/drivers/net/ehea/ehea_main.c
> @@ -533,8 +533,15 @@ static inline void ehea_fill_skb(struct net_device *dev,
> int length = cqe->num_bytes_transfered - 4; /*remove CRC */
>
> skb_put(skb, length);
> - skb->ip_summed = CHECKSUM_UNNECESSARY;
> skb->protocol = eth_type_trans(skb, dev);
> +
> + /* The packet was not an IPV4 packet so a complemented checksum was
> + calculated. The value is found in the Internet Checksum field. */
> + if (cqe->status & EHEA_CQE_BLIND_CKSUM) {
> + skb->ip_summed = CHECKSUM_COMPLETE;
> + skb->csum = csum_unfold(~cqe->inet_checksum_value);
> + } else
> + skb->ip_summed = CHECKSUM_UNNECESSARY;
> }
>
Hi Breno
Just to be clear : packets with wrong checksums are not given to upper
stack, so a tcpdump can not display them ? I am not sure many drivers do
that.
(EHEA_CQE_STAT_ERR_TCP, EHEA_CQE_STAT_ERR_IP)
Thanks !
^ permalink raw reply
* Re: [PATCH v2] memcg: reduce lock time at move charge (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: KAMEZAWA Hiroyuki @ 2010-10-08 4:37 UTC (permalink / raw)
To: Andrew Morton
Cc: Daisuke Nishimura, Minchan Kim, Greg Thelen, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <20101007161454.84570cf9.akpm@linux-foundation.org>
On Thu, 7 Oct 2010 16:14:54 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 7 Oct 2010 17:04:05 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> > Now, at task migration among cgroup, memory cgroup scans page table and moving
> > account if flags are properly set.
> >
> > The core code, mem_cgroup_move_charge_pte_range() does
> >
> > pte_offset_map_lock();
> > for all ptes in a page table:
> > 1. look into page table, find_and_get a page
> > 2. remove it from LRU.
> > 3. move charge.
> > 4. putback to LRU. put_page()
> > pte_offset_map_unlock();
> >
> > for pte entries on a 3rd level? page table.
> >
> > This pte_offset_map_lock seems a bit long. This patch modifies a rountine as
> >
> > for 32 pages: pte_offset_map_lock()
> > find_and_get a page
> > record it
> > pte_offset_map_unlock()
> > for all recorded pages
> > isolate it from LRU.
> > move charge
> > putback to LRU
> > for all recorded pages
> > put_page()
>
> The patch makes the code larger, more complex and slower!
>
Slower ?
> I do think we're owed a more complete description of its benefits than
> "seems a bit long". Have problems been observed? Any measurements
> taken?
>
I'll rewrite the whole patch against today's mmotom.
Thanks,
-Kame
>
>
^ permalink raw reply
* Re: [PATCH] memcg: lock-free clear page writeback (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: KAMEZAWA Hiroyuki @ 2010-10-08 4:41 UTC (permalink / raw)
To: Minchan Kim
Cc: Daisuke Nishimura, Greg Thelen, Andrew Morton, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <AANLkTi=kBnrtb5KkFQE3tNwVh1dWeUVBepWjec7ReVL0@mail.gmail.com>
On Fri, 8 Oct 2010 08:35:30 +0900
Minchan Kim <minchan.kim@gmail.com> wrote:
> Hi Kame,
>
> On Thu, Oct 7, 2010 at 3:24 PM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > Greg, I think clear_page_writeback() will not require _any_ locks with this patch.
> > But set_page_writeback() requires it...
> > (Maybe adding a special function for clear_page_writeback() is better rather than
> > adding some complex to switch() in update_page_stat())
> >
> > ==
> > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> >
> > Now, at page information accounting, we do lock_page_cgroup() if pc->mem_cgroup
> > points to a cgroup where someone is moving charges from.
> >
> > At supporing dirty-page accounting, one of troubles is writeback bit.
> > In general, writeback can be cleared via IRQ context. To update writeback bit
> > with lock_page_cgroup() in safe way, we'll have to disable IRQ.
> > ....or do something.
> >
> > This patch waits for completion of writeback under lock_page() and do
> > lock_page_cgroup() in safe way. (We never got end_io via IRQ context.)
> >
> > By this, writeback-accounting will never see race with account_move() and
> > it can trust pc->mem_cgroup always _without_ any lock.
> >
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > ---
> > mm/memcontrol.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > Index: mmotm-0928/mm/memcontrol.c
> > ===================================================================
> > --- mmotm-0928.orig/mm/memcontrol.c
> > +++ mmotm-0928/mm/memcontrol.c
> > @@ -2183,17 +2183,35 @@ static void __mem_cgroup_move_account(st
> > /*
> > * check whether the @pc is valid for moving account and call
> > * __mem_cgroup_move_account()
> > + * Don't call this under pte_lock etc...we'll do lock_page() and wait for
> > + * the end of I/O.
> > */
> > static int mem_cgroup_move_account(struct page_cgroup *pc,
> > struct mem_cgroup *from, struct mem_cgroup *to, bool uncharge)
> > {
> > int ret = -EINVAL;
> > +
> > + /*
> > + * We move severl flags and accounting information here. So we need to
> > + * avoid the races with update_stat routines. For most of routines,
> > + * lock_page_cgroup() is enough for avoiding race. But we need to take
> > + * care of IRQ context. If flag updates comes from IRQ context, This
> > + * "move account" will be racy (and cause deadlock in lock_page_cgroup())
> > + *
> > + * Now, the only race we have is Writeback flag. We wait for it cleared
> > + * before starting our jobs.
> > + */
> > +
> > + lock_page(pc->page);
> > + wait_on_page_writeback(pc->page);
> > +
> > lock_page_cgroup(pc);
> > if (PageCgroupUsed(pc) && pc->mem_cgroup == from) {
> > __mem_cgroup_move_account(pc, from, to, uncharge);
> > ret = 0;
> > }
> > unlock_page_cgroup(pc);
> > + unlock_page(pc->page);
> > /*
> > * check events
> > */
> >
> >
>
> Looks good to me.
> But let me ask a question.
> Why do only move_account need this logic?
Because charge/uncharge (add/remove to radix-tree or swapcache)
never happens while a page is PG_writeback.
> Is deadlock candidate is only this place?
yes.
> How about mem_cgroup_prepare_migration?
>
> unmap_and_move
> lock_page
> mem_cgroup_prepare_migration
> lock_page_cgroup
> ...
> softirq happen
> lock_page_cgroup
>
>
Nice cactch. I'll move prepare_migraon after wait_on_page_writeback()
> If race happens only where move_account and writeback, please describe
> it as comment.
> It would help to review the code in future.
>
Sure, updates are necessary.
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: empty filter on FORWARD chain with rp_filter means safe right?
From: Payam Chychi @ 2010-10-08 4:40 UTC (permalink / raw)
To: Scott Mcdermott; +Cc: netfilter
In-Reply-To: <20101008043129.GA2017@omnius.omnisys.com>
Thats correct Scott,
in order for any systems to abuse your setup they will need to be
directly connected to a segment that has knowledge of valid route to the
end system... meaning if a computer is 2 hops away and the router in
between has no knowledge of how to get to your private rfc1918 then pkts
get dropped.
Keep in mind that as ipv4 exhaustion gets extreme, some isps will use
rcf1918 blocks and route them either in their IGP or even EGP (aka
internet routes)...
-Payam
Network Engineer / Security Specialist
Scott Mcdermott wrote:
> Hello,
>
> I encountered a system today with two attached
> networks, one public and the other RFC1918. The box
> had ip_foward=1, FORWARD chain empty, policy ACCEPT.
> rp_filter was set on both the interfaces.
>
> Now if I were somewhere off the public interface, but
> many hops away, there is no possible way to get packets
> to the RFC1918 side of the box is there? Because I
> have no way to actually route the packets to the
> gateway with destination addresses on the far side. So
> actually this box is safe from malicious activity, even
> though there is an ACCEPT policy on FORWARD and it's
> set with routing enabled. Is this correct?
>
> Now if instead I have control of a station on the same
> segment as the gateway's public interface, or if I
> control routers in-between and can set up routes to get
> packets to the box with the internal IPs as
> destinations, then it's a different story. But in the
> common case of having ISPs in between (which will drop
> my packets with RFC1918 destinations), it's not
> possible to get packets to the gateway's internal
> network except if they NAT some of them for me.
>
> Please help me to see if my understanding is correct.
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: [PATCH 2/3] Retry page fault when blocking on disk transfer.
From: Michel Lespinasse @ 2010-10-08 4:39 UTC (permalink / raw)
To: Rik van Riel, Linus Torvalds
Cc: linux-mm, Ying Han, linux-kernel, Andrew Morton, Nick Piggin,
Peter Zijlstra
In-Reply-To: <AANLkTimdACZ9Xm01DM2+E64+T5XfLffrkFBhf7CJ286p@mail.gmail.com>
On Tue, Oct 05, 2010 at 03:44:22PM -0700, Michel Lespinasse wrote:
> On Tue, Oct 5, 2010 at 10:38 AM, Rik van Riel <riel@redhat.com> wrote:
> > Looks like it should be relatively easy to do something
> > similar in do_swap_page also.
>
> Good idea. We don't make use of swap too much, which is probably why
> we didn't have that in our kernel, but it seems like a good idea just
> for uniformity. I'll add this in a follow-on patch.
So here's the patch. Sorry for the delay - it did not take long to write,
but I couldn't test it before today.
Please have a look - I'd like to add this to the series I sent earlier.
----------------------------------- 8< ---------------------------------
Retry page fault when blocking on swap in
This change is the cousin of 'Retry page fault when blocking
on disk transfer'. The idea here is to reduce mmap_sem hold times
that are caused by disk transfers when swapping in pages. We drop
mmap_sem while waiting for the page lock, and return the VM_FAULT_RETRY
flag. do_page_fault will then re-acquire mmap_sem and retry the
page fault. It is expected that upon retry the page will now be cached,
and thus the retry will complete with a low mmap_sem hold time.
Signed-off-by: Michel Lespinasse <walken@google.com>
diff --git a/mm/memory.c b/mm/memory.c
index b068c68..0ec70b4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2613,6 +2613,21 @@ int vmtruncate_range(struct inode *inode, loff_t offset, loff_t end)
return 0;
}
+static inline int lock_page_or_retry(struct page *page, struct mm_struct *mm,
+ unsigned int flags)
+{
+ if (trylock_page(page))
+ return 1;
+ if (!(flags & FAULT_FLAG_ALLOW_RETRY)) {
+ __lock_page(page);
+ return 1;
+ }
+
+ up_read(&mm->mmap_sem);
+ wait_on_page_locked(page);
+ return 0;
+}
+
/*
* We enter with non-exclusive mmap_sem (to exclude vma changes,
* but allow concurrent faults), and pte mapped but not yet locked.
@@ -2626,6 +2641,7 @@ static int do_swap_page(struct mm_struct *mm, struct vm_area_struct *vma,
struct page *page, *swapcache = NULL;
swp_entry_t entry;
pte_t pte;
+ int locked;
struct mem_cgroup *ptr = NULL;
int exclusive = 0;
int ret = 0;
@@ -2676,8 +2692,12 @@ static int do_swap_page(struct mm_struct *mm, struct vm_area_struct *vma,
goto out_release;
}
- lock_page(page);
+ locked = lock_page_or_retry(page, mm, flags);
delayacct_clear_flag(DELAYACCT_PF_SWAPIN);
+ if (!locked) {
+ ret |= VM_FAULT_RETRY;
+ goto out_release;
+ }
/*
* Make sure try_to_free_swap or reuse_swap_page or swapoff did not
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [PATCH 2/3] Retry page fault when blocking on disk transfer.
From: Michel Lespinasse @ 2010-10-08 4:39 UTC (permalink / raw)
To: Rik van Riel, Linus Torvalds
Cc: linux-mm, Ying Han, linux-kernel, Andrew Morton, Nick Piggin,
Peter Zijlstra
In-Reply-To: <AANLkTimdACZ9Xm01DM2+E64+T5XfLffrkFBhf7CJ286p@mail.gmail.com>
On Tue, Oct 05, 2010 at 03:44:22PM -0700, Michel Lespinasse wrote:
> On Tue, Oct 5, 2010 at 10:38 AM, Rik van Riel <riel@redhat.com> wrote:
> > Looks like it should be relatively easy to do something
> > similar in do_swap_page also.
>
> Good idea. We don't make use of swap too much, which is probably why
> we didn't have that in our kernel, but it seems like a good idea just
> for uniformity. I'll add this in a follow-on patch.
So here's the patch. Sorry for the delay - it did not take long to write,
but I couldn't test it before today.
Please have a look - I'd like to add this to the series I sent earlier.
----------------------------------- 8< ---------------------------------
Retry page fault when blocking on swap in
This change is the cousin of 'Retry page fault when blocking
on disk transfer'. The idea here is to reduce mmap_sem hold times
that are caused by disk transfers when swapping in pages. We drop
mmap_sem while waiting for the page lock, and return the VM_FAULT_RETRY
flag. do_page_fault will then re-acquire mmap_sem and retry the
page fault. It is expected that upon retry the page will now be cached,
and thus the retry will complete with a low mmap_sem hold time.
Signed-off-by: Michel Lespinasse <walken@google.com>
diff --git a/mm/memory.c b/mm/memory.c
index b068c68..0ec70b4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2613,6 +2613,21 @@ int vmtruncate_range(struct inode *inode, loff_t offset, loff_t end)
return 0;
}
+static inline int lock_page_or_retry(struct page *page, struct mm_struct *mm,
+ unsigned int flags)
+{
+ if (trylock_page(page))
+ return 1;
+ if (!(flags & FAULT_FLAG_ALLOW_RETRY)) {
+ __lock_page(page);
+ return 1;
+ }
+
+ up_read(&mm->mmap_sem);
+ wait_on_page_locked(page);
+ return 0;
+}
+
/*
* We enter with non-exclusive mmap_sem (to exclude vma changes,
* but allow concurrent faults), and pte mapped but not yet locked.
@@ -2626,6 +2641,7 @@ static int do_swap_page(struct mm_struct *mm, struct vm_area_struct *vma,
struct page *page, *swapcache = NULL;
swp_entry_t entry;
pte_t pte;
+ int locked;
struct mem_cgroup *ptr = NULL;
int exclusive = 0;
int ret = 0;
@@ -2676,8 +2692,12 @@ static int do_swap_page(struct mm_struct *mm, struct vm_area_struct *vma,
goto out_release;
}
- lock_page(page);
+ locked = lock_page_or_retry(page, mm, flags);
delayacct_clear_flag(DELAYACCT_PF_SWAPIN);
+ if (!locked) {
+ ret |= VM_FAULT_RETRY;
+ goto out_release;
+ }
/*
* Make sure try_to_free_swap or reuse_swap_page or swapoff did not
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
^ permalink raw reply related
* Re: [PATCH v2] memcg: reduce lock time at move charge (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: KAMEZAWA Hiroyuki @ 2010-10-08 4:37 UTC (permalink / raw)
To: Andrew Morton
Cc: Daisuke Nishimura, Minchan Kim, Greg Thelen, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <20101007161454.84570cf9.akpm@linux-foundation.org>
On Thu, 7 Oct 2010 16:14:54 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 7 Oct 2010 17:04:05 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> > Now, at task migration among cgroup, memory cgroup scans page table and moving
> > account if flags are properly set.
> >
> > The core code, mem_cgroup_move_charge_pte_range() does
> >
> > pte_offset_map_lock();
> > for all ptes in a page table:
> > 1. look into page table, find_and_get a page
> > 2. remove it from LRU.
> > 3. move charge.
> > 4. putback to LRU. put_page()
> > pte_offset_map_unlock();
> >
> > for pte entries on a 3rd level? page table.
> >
> > This pte_offset_map_lock seems a bit long. This patch modifies a rountine as
> >
> > for 32 pages: pte_offset_map_lock()
> > find_and_get a page
> > record it
> > pte_offset_map_unlock()
> > for all recorded pages
> > isolate it from LRU.
> > move charge
> > putback to LRU
> > for all recorded pages
> > put_page()
>
> The patch makes the code larger, more complex and slower!
>
Slower ?
> I do think we're owed a more complete description of its benefits than
> "seems a bit long". Have problems been observed? Any measurements
> taken?
>
I'll rewrite the whole patch against today's mmotom.
Thanks,
-Kame
>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Configuration of nestedhvm
From: Dong, Eddie @ 2010-10-08 4:34 UTC (permalink / raw)
To: Keir Fraser; +Cc: Xen-devel, Dong, Eddie
In-Reply-To: <987664A83D2D224EAE907B061CE93D530163EA9749@orsmsx505.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 4104 bytes --]
Keir:
Despite of the negotioatiom of nested virtualization wrapper, here comes with the global configuration parameter and the CR4 layout handling between SVM & VMX. These are wrapper neutral IMO.
Thx, Eddie
===Patch1
Nested virtualization usage model is emerging, however we must guarantee it won't impact the performance of simple virtualization.
This patch add an boot parameter for nested virtualization, which is disabled by default for now.
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 1385b15e168f xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/arch/x86/hvm/hvm.c Fri Oct 08 10:29:38 2010 +0800
@@ -66,6 +66,9 @@ unsigned int opt_hvm_debug_level __read_
unsigned int opt_hvm_debug_level __read_mostly;
integer_param("hvm_debug", opt_hvm_debug_level);
+unsigned int enable_nested_hvm __read_mostly;
+integer_param("nested_hvm", enable_nested_hvm);
+
struct hvm_function_table hvm_funcs __read_mostly;
/* I/O permission bitmap is globally shared by all HVM guests. */
diff -r 1385b15e168f xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/include/asm-x86/hvm/hvm.h Fri Oct 08 10:35:03 2010 +0800
@@ -250,6 +250,9 @@ hvm_set_segment_register(struct vcpu *v,
#define is_viridian_domain(_d) \
(is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]))
+/* TODO: handle per domain configuration */
+#define is_nestedhvm(_d) (enable_nested_hvm && is_hvm_domain(_d))
+
void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
unsigned int *ecx, unsigned int *edx);
void hvm_migrate_timers(struct vcpu *v);
===Patch2
This patch solves the CR4 bit (VMXE) format difference between AMD & Intel processor.
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 1385b15e168f xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/arch/x86/hvm/hvm.c Fri Oct 08 10:46:55 2010 +0800
@@ -630,6 +630,11 @@ static int hvm_load_cpu_ctxt(struct doma
struct hvm_hw_cpu ctxt;
struct segment_register seg;
struct vcpu_guest_context *vc;
+ unsigned long rsv_bits = HVM_CR4_GUEST_RESERVED_BITS;
+
+ if ( !is_nestedhvm(d) ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+ rsv_bits |= X86_CR4_VMXE;
/* Which vcpu is this? */
vcpuid = hvm_load_instance(h);
@@ -662,7 +667,7 @@ static int hvm_load_cpu_ctxt(struct doma
return -EINVAL;
}
- if ( ctxt.cr4 & HVM_CR4_GUEST_RESERVED_BITS )
+ if ( ctxt.cr4 & rsv_bits )
{
gdprintk(XENLOG_ERR, "HVM restore: bad CR4 0x%"PRIx64"\n",
ctxt.cr4);
@@ -1243,8 +1248,12 @@ int hvm_set_cr4(unsigned long value)
{
struct vcpu *v = current;
unsigned long old_cr;
-
- if ( value & HVM_CR4_GUEST_RESERVED_BITS )
+ unsigned long rsv_bits = HVM_CR4_GUEST_RESERVED_BITS;
+
+ if ( !is_nestedhvm(v->domain) ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+ rsv_bits |= X86_CR4_VMXE;
+ if ( value & rsv_bits )
{
HVM_DBG_LOG(DBG_LEVEL_1,
"Guest attempts to set reserved bit in CR4: %lx",
diff -r 1385b15e168f xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/include/asm-x86/hvm/hvm.h Fri Oct 08 10:46:35 2010 +0800
@@ -291,7 +291,8 @@ static inline int hvm_do_pmu_interrupt(s
X86_CR4_DE | X86_CR4_PSE | X86_CR4_PAE | \
X86_CR4_MCE | X86_CR4_PGE | X86_CR4_PCE | \
X86_CR4_OSFXSR | X86_CR4_OSXMMEXCPT | \
- (cpu_has_xsave ? X86_CR4_OSXSAVE : 0))))
+ (cpu_has_xsave ? X86_CR4_OSXSAVE : 0))) | \
+ X86_CR4_VMXE)
/* These exceptions must always be intercepted. */
#define HVM_TRAP_MASK ((1U << TRAP_machine_check) | (1U << TRAP_invalid_op))
[-- Attachment #2: patch1 --]
[-- Type: application/octet-stream, Size: 1540 bytes --]
Nested virtualization usage model is emerging, however we must guarantee it won't impact the performance of simple virtualization.
This patch add an boot parameter for nested virtualization, which is disabled by default for now.
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 1385b15e168f xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/arch/x86/hvm/hvm.c Fri Oct 08 10:29:38 2010 +0800
@@ -66,6 +66,9 @@ unsigned int opt_hvm_debug_level __read_
unsigned int opt_hvm_debug_level __read_mostly;
integer_param("hvm_debug", opt_hvm_debug_level);
+unsigned int enable_nested_hvm __read_mostly;
+integer_param("nested_hvm", enable_nested_hvm);
+
struct hvm_function_table hvm_funcs __read_mostly;
/* I/O permission bitmap is globally shared by all HVM guests. */
diff -r 1385b15e168f xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/include/asm-x86/hvm/hvm.h Fri Oct 08 10:35:03 2010 +0800
@@ -250,6 +250,9 @@ hvm_set_segment_register(struct vcpu *v,
#define is_viridian_domain(_d) \
(is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]))
+/* TODO: handle per domain configuration */
+#define is_nestedhvm(_d) (enable_nested_hvm && is_hvm_domain(_d))
+
void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
unsigned int *ecx, unsigned int *edx);
void hvm_migrate_timers(struct vcpu *v);
[-- Attachment #3: patch2 --]
[-- Type: application/octet-stream, Size: 2231 bytes --]
This patch solves the CR4 bit (VMXE) format difference between AMD & Intel processor.
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 1385b15e168f xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/arch/x86/hvm/hvm.c Fri Oct 08 10:46:55 2010 +0800
@@ -630,6 +630,11 @@ static int hvm_load_cpu_ctxt(struct doma
struct hvm_hw_cpu ctxt;
struct segment_register seg;
struct vcpu_guest_context *vc;
+ unsigned long rsv_bits = HVM_CR4_GUEST_RESERVED_BITS;
+
+ if ( !is_nestedhvm(d) ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+ rsv_bits |= X86_CR4_VMXE;
/* Which vcpu is this? */
vcpuid = hvm_load_instance(h);
@@ -662,7 +667,7 @@ static int hvm_load_cpu_ctxt(struct doma
return -EINVAL;
}
- if ( ctxt.cr4 & HVM_CR4_GUEST_RESERVED_BITS )
+ if ( ctxt.cr4 & rsv_bits )
{
gdprintk(XENLOG_ERR, "HVM restore: bad CR4 0x%"PRIx64"\n",
ctxt.cr4);
@@ -1243,8 +1248,12 @@ int hvm_set_cr4(unsigned long value)
{
struct vcpu *v = current;
unsigned long old_cr;
-
- if ( value & HVM_CR4_GUEST_RESERVED_BITS )
+ unsigned long rsv_bits = HVM_CR4_GUEST_RESERVED_BITS;
+
+ if ( !is_nestedhvm(v->domain) ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+ rsv_bits |= X86_CR4_VMXE;
+ if ( value & rsv_bits )
{
HVM_DBG_LOG(DBG_LEVEL_1,
"Guest attempts to set reserved bit in CR4: %lx",
diff -r 1385b15e168f xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/include/asm-x86/hvm/hvm.h Fri Oct 08 10:46:35 2010 +0800
@@ -291,7 +291,8 @@ static inline int hvm_do_pmu_interrupt(s
X86_CR4_DE | X86_CR4_PSE | X86_CR4_PAE | \
X86_CR4_MCE | X86_CR4_PGE | X86_CR4_PCE | \
X86_CR4_OSFXSR | X86_CR4_OSXMMEXCPT | \
- (cpu_has_xsave ? X86_CR4_OSXSAVE : 0))))
+ (cpu_has_xsave ? X86_CR4_OSXSAVE : 0))) | \
+ X86_CR4_VMXE)
/* These exceptions must always be intercepted. */
#define HVM_TRAP_MASK ((1U << TRAP_machine_check) | (1U << TRAP_invalid_op))
[-- Attachment #4: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: Slow link/Capacity changed + Kernel OOPS... possible hardware issues, ideas?
From: C Anthony Risinger @ 2010-10-08 4:34 UTC (permalink / raw)
To: Chris Ball; +Cc: linux-btrfs
In-Reply-To: <m37hhtmku4.fsf@pullcord.laptop.org>
On Thu, Oct 7, 2010 at 10:20 PM, Chris Ball <cjb@laptop.org> wrote:
> Hi,
>
> =A0 > can anyone point me in the right direction? =A0it looks like ma=
ybe
> =A0 > the SSD is failing to me (all the "slow link" and "capacity
> =A0 > changed to 0" stuff), but i really don't know. =A0i knew there =
was
> =A0 > a reason they were selling these things cheap on Newegg!!!
>
> Yes, the read errors are coming all the way up from the hardware;
> I don't think this is a btrfs problem.
>
> There's not much btrfs could do to help, except (over time) grow
> to handle I/O errors without BUG()ing out.
hmm, i'll have to keep playing with it i guess. /dev/sda1 is a ext2
boot partition; i tar + ssh'ed that several times to my other machine
without problems... i thought it would trip an issue if it really was
hardware, but it didn't, even after 30+ times.
i'll try to reinstall i guess, unless anyone has other input. i'll
probably just have to ask ASUS to replace it, because i don't think
i've even had it 6mo yet...
>:-O
thanks,
C Anthony
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Tips on debugging suspend/resume failure
From: Chris Ball @ 2010-10-08 4:37 UTC (permalink / raw)
To: Man Spaz; +Cc: linux-kernel
In-Reply-To: <103889.39682.qm@web120217.mail.ne1.yahoo.com>
Hi,
> But the question remains, how to get debug out? Is there a dmesg
> buffer that can persist if DRAM is being refreshed perhaps?
The most promising attempts involve using GPU RAM to store dmesg,
since it persists across a soft reboot and isn't going to be
overwritten as long as you get to it before the video driver does
after the crash. (Which you can ensure by blacklisting the driver.)
> Is there another way to skin this mongrel, I mean cat?
The most basic tool is probably CONFIG_PM_TRACE, which uses the
real-time clock to store a signature for the last driver to init
during suspend/resume -- after the crash, the kernel will interpret
the RTC hash it placed to give you a hint as to what might be failing.
The real answer, though, is to just keep trying to find any way at all
to get usable serial output, including by finding a different machine
with the same problem that has a serial port.
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* empty filter on FORWARD chain with rp_filter means safe right?
From: Scott Mcdermott @ 2010-10-08 4:31 UTC (permalink / raw)
To: netfilter
Hello,
I encountered a system today with two attached
networks, one public and the other RFC1918. The box
had ip_foward=1, FORWARD chain empty, policy ACCEPT.
rp_filter was set on both the interfaces.
Now if I were somewhere off the public interface, but
many hops away, there is no possible way to get packets
to the RFC1918 side of the box is there? Because I
have no way to actually route the packets to the
gateway with destination addresses on the far side. So
actually this box is safe from malicious activity, even
though there is an ACCEPT policy on FORWARD and it's
set with routing enabled. Is this correct?
Now if instead I have control of a station on the same
segment as the gateway's public interface, or if I
control routers in-between and can set up routes to get
packets to the box with the internal IPs as
destinations, then it's a different story. But in the
common case of having ISPs in between (which will drop
my packets with RFC1918 destinations), it's not
possible to get packets to the gateway's internal
network except if they NAT some of them for me.
Please help me to see if my understanding is correct.
Thanks.
^ permalink raw reply
* [Buildroot] buildroot not support c++ compliing
From: olyvine.chen at logiways.com.cn @ 2010-10-08 4:23 UTC (permalink / raw)
To: buildroot
Dear all,
I now try to add package libmusicbrainz to buildroot, but many errors
happen, such as the following:
*************************************************************************
buildroot/output/build/libmusicbrainz-3.0.2/src/artist.cpp:23:18: error:
string: No such file or directory
*************************************************************************
it seems indicate that no c++ library available, then how to enable c
++ compiling for buildroot?
I enabled glibc via:
Toolchain => Toolchain type (External toolchain) => External toolchain
C library (glibc)
Kindest regards!
Olyvine
^ permalink raw reply
* Ok, dumb question time ...
From: Joe Landman @ 2010-10-08 4:20 UTC (permalink / raw)
To: linux-raid
Not having much luck with this. Let me explain ...
Imagine we have a RAID1 with 3 elements. It was originally a RAID1 with
2 elements, and we added a 3rd using
mdadm /dev/md0 --add /dev/loop1
What I want to do is conceptually very simple. I want to permanently
remove loop1, without having the array become dirty, or degraded. That
is, I would like
mdadm /dev/md0 --fail /dev/loop1 --remove /dev/loop1
to result in a clean array with two members.
It doesn't. The array is marked as being in the "clean, degraded"
state. Which, as it is the root file system array, has the unfortunate
side effect of not allowing the RAID1 to properly assemble at boot (that
degraded state).
So ... can I force the array to either remove the extra unneeded loop1
device, and update its metadata properly ... or force it into a clean,
active state without the loop1 device, or force the assembly on boot to
occur regardless of what it thinks it should have?
This is quite disconcerting ... I thought it would be simple.
--
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics, Inc.
email: landman@scalableinformatics.com
web : http://scalableinformatics.com
http://scalableinformatics.com/jackrabbit
phone: +1 734 786 8423 x121
fax : +1 866 888 3112
cell : +1 734 612 4615
^ permalink raw reply
* Re: DRAFT Design Spec for 1st Class Quota Support in Ext4
From: Dmitry @ 2010-10-08 4:19 UTC (permalink / raw)
To: Theodore Ts'o, Jan Kara; +Cc: linux-ext4
In-Reply-To: <87y6gad45r.fsf@openvz.org>
On Mon, 26 Apr 2010 12:11:28 +0400, Dmitry Monakhov <dmonakhov@openvz.org> wrote:
> "Theodore Ts'o" <tytso@mit.edu> writes:
>
> > Please comment!
> >
> > 1st Class Quota Support in Ext4
> > DRAFT Design Specification, v0.5
> >
> >
> > This proposal promotes quota to being a first class supported feature in
> > ext4. To do this, we will do the following:
> >
> > 1) We define the following two new fields to the superblock. No new
> > COMPAT features are defined; since unused superblock fields are zero, if
> > the fields are not known.
> > *) A superblock field containing the inode number for the user quota
> > file. This inode number will be 3 if the inode is user quota file
> > is hidden. If this field is zero, then user quotas will not be tracked.
> > *) A superblock field containing the inode number for the group quota
> > file. This inode number will be 4 if the inode is group quota file
> > is hidden. If this field is zero, then group quotas will not be
> > tracked.
> >
I hope, that it is no too late for new thoughts.
While working on generic quota code i've realized what we can make
journalled quota accounting almost for free.
Today it is painful because
1) each quota modification result in quota write
make_quota_dirty
->write_quota
which means
1A) i_mutex on quota file
1B) locks for quota-info and buffer on data copy.
1C) locking in journal internals.
It is relatively easy to solve (1A) and was already discussed,
just skip it if quota already exist on the disk.
But others issues are also solvable. Here is an idea:
1) dquot should contain per_cpu counters
{
per_cpu_ptr b_reserved;
per_cpu_ptr b_current;
per_cpu_ptr i_current;
};
This allow us to make charge/claim/free path lock-less if we do not
care about quota_limits. Even with limits we can avoid synchronization
(i hope) in most cases if consider per_cpu variables as preallocation
buckets.
Off course per_cpu vars comes with the cost of memory, but in most cases
we have hundreds of dquot objects per sb or even less.
2) Change quota mark_dirty policy like follows
2A) Remember transaction id inside dquot object
and if transaction is the same as before just exit.
2B) If transaction not the same do:
get_write_access(bh)
/* do not copy quota data yet */
hanle_dirty_metadata(bh, "a_copy_callback)
quota_copy_callback will be attached to journal_head and will
be called by jbd2 on transaction commit or on starting new
transaction. That callback will copy data from quota-info,
and at this moment we do need synchronization with chargers,
but only once for each transaction.
Changes in jbd2 doesn't look so scary. And performance gain seems
promising.
I'll try to come up with the proof of concept path soon.
BTW what are current ETAs for huge ext4-quota changes?
> I now that it is always not right time for ask about this, but still.
> Don't you mind to reserve 5'th inode number for projectID quota?
> > 2) The quota files will use the v2 format only, and updates to the quota
> > files will be protected with the journal if the journal is present.
> Since we are about to starting huge movements let's use new (v3) quota
> format. The only difference with v2 is extended header wider than old
> magic+version.
>
> struct v3_disk_dqheader {
> __le32 dqh_magic; /* Magic number identifying file */
> __le32 dqh_version; /* File version */
> __le32 dqh_state; /* quota file state */
> __u32 dqh_reserved[125];
> };
> dqh_state is an equivalent of sb's s_state.
> >
> > 3) If e2fsck needs to do a full file system consistency check, it will
> > keep track of the disk space used by each user and/or groups ids, and
> > update the user and/or group quota files at the end of the e2fsck run.
> >
> > 4) If the filesystem appears consistent, but the user and/or group quota
> > fils are not equal to the last superblock write time, e2fsck will do a
> > partical file system consistency check. This will consist of e2fsck
> > pass #1, and if no errors were detected, e2fsck will update the user and
> > group quota files and exit. If any errors were detected during pass #1,
> > then e2fsck will continue to do pass numbers 2-5, and thus do a full
> > file system consistency check before updating the quota files.
> >
> > 5) Mke2fs will take an extended option (quota=user,group) which if
> > present will force the initialization of the quota inodes. Using the
> > /etc/mke2fs.conf file, the system administrator can also specify a quota
> > option in the [defaults] and [fs_types] section, so that quota files can
> > be enabled by default.
> >
> > 6) Tune2fs will have a facility for adding and removing user and group
> > quotas inodes while the file system is mounted. The quota usage will
> > not be correct after the quota inodes are newly added, however, so quota
> > will not be enabled by default, If the quota inodes are removed, quota
> > will be disabled first.
> Who is responsible for quota enabling in that scenario?
> Will it enabled by default on mount time?
>
> Small note: quotacheck -cug /mnt will result in unlink/create
> so we have options exclusive options:
> if inode is already exist
> replace unlink/create with truncate
> else
> call tune2fs from quotacheck after inodes was created.
> >
> > 7) There will be a new interface so that bulk quota information can be
> > fetched from the file system. This needs to be negotiated with Jan
> > Kara. It can either be a new system call, or a magic file in /proc that
> > can be opened and the repquota data extracted.
> >
> > 8) Traditional style quota will still be supported; that is the
> > appropriate magic flags will be passed through to /proc/mounts so that
> > the old-style init scripts will still function correctly. This support
> > will be deprecated over an 18 month period after the new-style kernel
> > code and userspace tools have been released.
> 9) Make ext4_orphan_cleanup() more tolerate to quota, if quota is
> enabled for given SB, but cleanup procedure is unable to perform
> ext4_quota_on_mount() mount should fail as it does in case of wrong
> options.
>
> The rest is looking very promising.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: fatal: BUG: dashless options don't support arguments
From: Jeff King @ 2010-10-08 4:11 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Brian Zitzow, git, Christopher Cameron, Henrik Tidefelt
In-Reply-To: <20101008031818.GC992@burratino>
On Thu, Oct 07, 2010 at 10:18:18PM -0500, Jonathan Nieder wrote:
> > Ki:$ git checkout master
> > fatal: BUG: dashless options don't support arguments
>
> Strange indeed. Here's what I would suggest:
>
> 1. For debugging output:
>
> $ echo 'prefix=/usr/local' >>config.mak; # or whatever prefix you use
> $ git describe
> $ gcc --version
> $ wget 'http://download.gmane.org/gmane.comp.version-control.git/128067/128068'
> $ git am -3 128068
> $ make
> $ bin-wrappers/git checkout m
Yeah, I would be curious to see the output of that. Interesting, too,
that it seems to happen with multiple commands (it looked like it
happened with "git push foo" in the pastebin from the irc log).
> 2. To track down the issue, if you like to read assembler:
>
> $ make builtin/checkout.s
> $ vi checkout.s
Ugh. I think a better course of action is to find out which option is
being munged (from step 1 above), and then try running it under gdb with
a watch set on that option struct. Assuming it's easily reproducible of
course.
-Peff
^ permalink raw reply
* Tips on debugging suspend/resume failure
From: Man Spaz @ 2010-10-08 4:09 UTC (permalink / raw)
To: linux-kernel
Hello
I have a machine x86 arch with no serial port, only console. I have a suspend/resume (mem, not hibernate) problem (not sure which one it is, if something fails on the suspend, or the resume fails - but it does seem to go to sleep) that doesn't suspend nor resume at all, using stock standard x86_64 kernel.
I compiled everything as a module and removed all unnecessary ones, so I cannot isolate the problem to a specific driver. This very same machine had no problems with <2.6.34.2 kernels.
But the question remains, how to get debug out? Is there a dmesg buffer that can persist if DRAM is being refreshed perhaps? Is there another way to skin this mongrel, I mean cat?
Spaz
^ permalink raw reply
* Re: upgrade kvm with running vm
From: Teck Choon Giam @ 2010-10-08 4:07 UTC (permalink / raw)
To: sofa5000; +Cc: kvm
In-Reply-To: <46949.90.146.57.124.1286466221.squirrel@lavabit.com>
On Thu, Oct 7, 2010 at 11:43 PM, <sofa5000@lavabit.com> wrote:
> hi everybody,
>
> is it a problem to update kvm (the kvm package (qemu-kvm on debian) with
> the package manager) while some vms are turned on? or should i shutdown
> all vms first?
>From personal experience (install from source), there shouldn't be a
problem to perform upgrade/update of qemu-kvm without shutting down
those running VMs. However, in order to use the updated version of
the qemu-kvm, you will need to unload those loaded kvm-intel or
kvm-amd and kvm kernel modules. Such unloading of modules will need
to shutdown all running VMs in order to successfully unload (rmmod)
those kernel modules. After unloading, you can reload the updated
version by using modprobe or insmod after you have done depmod.
Hope this helps!
Kindest regards,
Giam Teck Choon
^ permalink raw reply
* [PATCH] sdhci: on error print out SD CMD and CAPABILITY_1 Register
From: Philip Rakity @ 2010-10-08 4:05 UTC (permalink / raw)
To: linux-mmc@vger.kernel.org
More information should be shown when sdhci_dumpregs is called.
Knowing the command is useful for debugging.
Capability 1 is useful for sdio v3
Signed-off-by: Philip Rakity <prakity@marvell.com>
---
drivers/mmc/host/sdhci.c | 5 ++++-
drivers/mmc/host/sdhci.h | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9cb60ba..ea8472b 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -77,8 +77,11 @@ static void sdhci_dumpregs(struct sdhci_host *host)
printk(KERN_DEBUG DRIVER_NAME ": AC12 err: 0x%08x | Slot int: 0x%08x\n",
sdhci_readw(host, SDHCI_ACMD12_ERR),
sdhci_readw(host, SDHCI_SLOT_INT_STATUS));
- printk(KERN_DEBUG DRIVER_NAME ": Caps: 0x%08x | Max curr: 0x%08x\n",
+ printk(KERN_DEBUG DRIVER_NAME ": Caps: 0x%08x | Caps_1: 0x%08x\n",
sdhci_readl(host, SDHCI_CAPABILITIES),
+ sdhci_readl(host, SDHCI_CAPABILITIES_1));
+ printk(KERN_DEBUG DRIVER_NAME ": Cmd: 0x%08x | Max curr: 0x%08x\n",
+ sdhci_readw(host, SDHCI_COMMAND),
sdhci_readl(host, SDHCI_MAX_CURRENT));
if (host->flags & SDHCI_USE_ADMA)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index bfcd611..38ae340 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -161,7 +161,7 @@
#define SDHCI_CAN_VDD_180 0x04000000
#define SDHCI_CAN_64BIT 0x10000000
-/* 44-47 reserved for more caps */
+#define SDHCI_CAPABILITIES_1 0x44
#define SDHCI_MAX_CURRENT 0x48
--
1.6.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.