* [TopGit PATCH 03/10] branch_empty: use pretty_tree and therefore respect -i/-w
From: Bert Wesarg @ 2010-10-08 7:58 UTC (permalink / raw)
To: Uwe Kleine-Koenig; +Cc: git, pasky, martin f krafft, Bert Wesarg
In-Reply-To: <160b8b0eb6152da98f4fa633ac25c7a25ff32aa4.1286524446.git.bert.wesarg@googlemail.com>
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
tg.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tg.sh b/tg.sh
index 308ed28..a166a70 100644 tg.sh
--- a/tg.sh
+++ b/tg.sh
@@ -283,10 +283,10 @@ needs_update()
recurse_deps branch_needs_update "$@"
}
-# branch_empty NAME
+# branch_empty NAME [-i | -w]
branch_empty()
{
- [ -z "$(git diff-tree "refs/top-bases/$1" "$1" -- | fgrep -v " .top")" ]
+ [ "$(pretty_tree "$1" -b)" = "$(pretty_tree "$1" ${2-})" ]
}
# list_deps
--
1.7.1.1067.g5aeb7
^ permalink raw reply related
* [TopGit PATCH 02/10] pretty_tree: globalize and respect -i/-w options
From: Bert Wesarg @ 2010-10-08 7:58 UTC (permalink / raw)
To: Uwe Kleine-Koenig; +Cc: git, pasky, martin f krafft, Bert Wesarg
In-Reply-To: <160b8b0eb6152da98f4fa633ac25c7a25ff32aa4.1286524446.git.bert.wesarg@googlemail.com>
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
tg-export.sh | 13 ++-----------
tg.sh | 47 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 49 insertions(+), 11 deletions(-)
diff --git a/tg-export.sh b/tg-export.sh
index 6d82d55..5c707ce 100644 tg-export.sh
--- a/tg-export.sh
+++ b/tg-export.sh
@@ -63,15 +63,6 @@ trap 'rm -rf "$playground"' EXIT
## Collapse driver
-# pretty_tree NAME
-# Output tree ID of a cleaned-up tree without tg's artifacts.
-pretty_tree()
-{
- git ls-tree --full-tree "$1" \
- | awk -F ' ' '$2 !~ /^.top/' \
- | git mktree
-}
-
create_tg_commit()
{
name="$1"
@@ -112,7 +103,7 @@ collapsed_commit()
echo "TopGit-driven merge of branches:"
echo
cut -f 2 "$playground/$name^parents"
- } | git commit-tree "$(pretty_tree "refs/top-bases/$name")" \
+ } | git commit-tree "$(pretty_tree "$name" -b)" \
$(for p in $parent; do echo -p $p; done))"
fi
@@ -227,7 +218,7 @@ linearize()
else
retmerge=0;
- git merge-recursive "$(pretty_tree "refs/top-bases/$_dep")" -- HEAD "$(pretty_tree "refs/heads/$_dep")" || retmerge="$?";
+ git merge-recursive "$(pretty_tree "$_dep" -b)" -- HEAD "$(pretty_tree "refs/heads/$_dep")" || retmerge="$?";
if test "x$retmerge" != "x0"; then
git rerere;
diff --git a/tg.sh b/tg.sh
index 4d7d4ef..308ed28 100644 tg.sh
--- a/tg.sh
+++ b/tg.sh
@@ -42,6 +42,53 @@ cat_file()
esac
}
+# get tree for the committed topic
+get_tree_()
+{
+ echo "$1"
+}
+
+# get tree for the base
+get_tree_b()
+{
+ echo "refs/top-bases/$1"
+}
+
+# get tree for the index
+get_tree_i()
+{
+ git write-tree
+}
+
+# get tree for the worktree
+get_tree_w()
+{
+ i_tree=$(git write-tree)
+ (
+ # the file for --index-output needs to sit next to the
+ # current index file
+ : ${GIT_INDEX_FILE:="$git_dir/index"}
+ TMP_INDEX="$(mktemp "${GIT_INDEX_FILE}-tg.XXXXXX")"
+ git read-tree -m $i_tree --index-output="$TMP_INDEX" &&
+ GIT_INDEX_FILE="$TMP_INDEX" &&
+ export GIT_INDEX_FILE &&
+ git diff --name-only -z HEAD |
+ git update-index -z --add --remove --stdin &&
+ git write-tree &&
+ rm -f "$TMP_INDEX"
+ )
+}
+
+# pretty_tree NAME [-b | -i | -w]
+# Output tree ID of a cleaned-up tree without tg's artifacts.
+# NAME will be ignored for -i and -w, but needs to be present
+pretty_tree()
+{
+ git ls-tree --full-tree "$(get_tree_${2#-} "$1")" |
+ awk -F ' ' '$2 !~ /^.top/' |
+ git mktree
+}
+
# setup_hook NAME
setup_hook()
{
--
1.7.1.1067.g5aeb7
^ permalink raw reply related
* [TopGit PATCH 01/10] cat_file: take -i/-w parameters
From: Bert Wesarg @ 2010-10-08 7:57 UTC (permalink / raw)
To: Uwe Kleine-Koenig; +Cc: git, pasky, martin f krafft, Bert Wesarg
This changes the way how cat_file selects the source of the file. It
accepts an optional parameter which is either -i or -w and will react on this
instead of the branch name. tg-patch is updated accordingly and can now
accepts the current branch name as argument with -i or -w given.
cat_file was also broken for the worktree case when we are not in the top level.
Also, tg-patch allowed to be on the top-base branch, but -i and -w doesn't
make sense there too.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
I will probably never understand why TopGit accepts to be on a top-base branch.
I will probably never understand why TopGit not changes the cwd to the top level.
I will probably never understand why TopGit does not use the git-sh-setup.sh.
---
tg-patch.sh | 25 ++++++++++++++-----------
tg.sh | 27 +++++++++++++++------------
2 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/tg-patch.sh b/tg-patch.sh
index 7bafdfe..5b7386a 100644 tg-patch.sh
--- a/tg-patch.sh
+++ b/tg-patch.sh
@@ -5,7 +5,7 @@
name=
-topic=
+head_from=
diff_opts=
diff_committed_only=yes # will be unset for index/worktree
@@ -16,11 +16,13 @@ while [ -n "$1" ]; do
arg="$1"; shift
case "$arg" in
-i)
- topic='(i)'
+ [ -z "$head_from" ] || die "-i and -w are mutually exclusive"
+ head_from=-i
diff_opts="$diff_opts --cached";
diff_committed_only=;;
-w)
- topic='(w)'
+ [ -z "$head_from" ] || die "-i and -w are mutually exclusive"
+ head_from=-w
diff_committed_only=;;
-*)
echo "Usage: tg [...] patch [-i | -w] [NAME]" >&2
@@ -31,22 +33,23 @@ while [ -n "$1" ]; do
esac
done
+head="$(git symbolic-ref HEAD)"
+head="${head#refs/heads/}"
-[ -n "$name" -a -z "$diff_committed_only" ] &&
- die "-i/-w are mutually exclusive with NAME"
-
-[ -n "$name" ] || name="$(git symbolic-ref HEAD | sed 's#^refs/\(heads\|top-bases\)/##')"
+[ -n "$name" ] ||
+ name="$head"
base_rev="$(git rev-parse --short --verify "refs/top-bases/$name" 2>/dev/null)" ||
die "not a TopGit-controlled branch"
-# if not index/worktree, topic is current branch
-[ -z "$topic" ] && topic="$name"
+if [ -n "$head_from" ] && [ "$name" != "$head" ]; then
+ die "$head_from makes only sense for the current branch"
+fi
setup_pager
-cat_file "$topic:.topmsg"
+cat_file "$name:.topmsg" $head_from
echo
[ -n "$(git grep $diff_opts '^[-]--' ${diff_committed_only:+"$name"} -- ".topmsg")" ] || echo '---'
@@ -64,7 +67,7 @@ fi
rm "$git_is_stupid"
echo '-- '
-echo "tg: ($base_rev..) $name (depends on: $(cat_file "$topic:.topdeps" | paste -s -d' '))"
+echo "tg: ($base_rev..) $name (depends on: $(cat_file "$name:.topdeps" $head_from | paste -s -d' '))"
branch_contains "$name" "$base_rev" ||
echo "tg: The patch is out-of-date wrt. the base! Run \`$tg update\`."
diff --git a/tg.sh b/tg.sh
index 3718702..4d7d4ef 100644 tg.sh
--- a/tg.sh
+++ b/tg.sh
@@ -18,24 +18,27 @@ die()
exit 1
}
-# cat_file "topic:file"
-# Like `git cat-file blob $1`, but topics '(i)' and '(w)' means index and worktree
+# cat_file TOPIC:PATH FROM
+# cat the file PATH from branch TOPIC when FROM is empty.
+# FROM can be -i or -w, than the file will be from the index or worktree,
+# respectively. The caller should than ensure that HEAD is TOPIC, to make sense.
cat_file()
{
- arg="$1"
- case "$arg" in
- '(w):'*)
- arg=$(echo "$arg" | tail --bytes=+5)
- cat "$arg"
- return
+ path="$1"
+ case "${2-}" in
+ -w)
+ cat "$root_dir/${path#*:}"
;;
- '(i):'*)
+ -i)
# ':file' means cat from index
- arg=$(echo "$arg" | tail --bytes=+5)
- git cat-file blob ":$arg"
+ git cat-file blob ":${path#*:}"
+ ;;
+ '')
+ git cat-file blob "$path"
;;
*)
- git cat-file blob "$arg"
+ die "Wrong argument to cat_file: '$2'"
+ ;;
esac
}
--
1.7.1.1067.g5aeb7
^ permalink raw reply related
* [Bug 29833] radeon crashes kicad when using modeset
From: bugzilla-daemon @ 2010-10-08 7:57 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-29833-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=29833
--- Comment #12 from Fabio Varesano <fabio.varesano@gmail.com> 2010-10-08 00:57:43 PDT ---
I did what Fabio suggested above. I'm not sure on how to verify that I'm
actually running the gallium driver. This is my Xorg log:
http://sprunge.us/ZYiK
However, running with the gallium driver I now get this:
[fabio@gamma ~]$ pcbnew
The program 'pcbnew' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
(Details: serial 88834 error_code 9 request_code 136 minor_code 8)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Any idea? How can I break on the gdk_x_error() function?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [patch 2/2] ARM: mach-shmobile: Add zboot support for SuperH Mobile ARM
From: Simon Horman @ 2010-10-08 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101008075726.236142425@vergenet.net>
An embedded and charset-unspecified text was scrubbed...
Name: arm-mach-shmbobile-Add-zboot-support-for-SuperH-Mobile-ARM-board.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101008/3aea7557/attachment.ksh>
^ permalink raw reply
* [patch 1/2] ARM: Add zboot support for SuperH Mobile ARM
From: Simon Horman @ 2010-10-08 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101008075726.236142425@vergenet.net>
An embedded and charset-unspecified text was scrubbed...
Name: arm-mach-shmbobile-Add-zboot-support-for-SuperH-Mobile-ARM-framework.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101008/ab062c81/attachment.ksh>
^ permalink raw reply
* [patch 0/2] ARM: mach-shmobile: Add zboot support for SuperH Mobile ARM
From: Simon Horman @ 2010-10-08 7:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this short patch series by Kuninori Morimoto adds
zboot support to mach-shmobile.
^ permalink raw reply
* Re: [ath5k-devel] Race condition in CRDA calls?
From: Bruno Randolf @ 2010-10-08 7:57 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Lukáš Turek, ath5k-devel@lists.ath5k.org,
linux-wireless
In-Reply-To: <AANLkTik7ckoex4pP1IkY0Vx1j-S4k0WVV62h7Sn4uGCx@mail.gmail.com>
hello!
sorry to revive an old thread, but i finally found the time to continue on
this. i can reproduce the regdomain intersection problem fairly regularly now.
it happens on slow boards (soekris net4826), with more than one ath5k card,
especially under high load. unfortunately this seems to be the case when
OpenWRT loads, but i can also trigger it by bombarding it with traffic (iperf
UDP) on the ethernet device, so the IRQ and SIRQ loads together are around
50%.
On Thu June 17 2010 14:05:32 Luis R. Rodriguez wrote:
> I provided verbose instructions what can be done to further debug this.
the following output mixes kernel log output on the serial and iw event. it's
a little messed up (lines cut) but i think you can see what's going on:
root@RMR1:/# config.sh reload kernel; iw event -t &
(the config.sh schript only reloads the mac80211, cfg80211 and ath module)
cfg80211: Calling CRDA to update world regulatory domain
root@RMR1:/# cfg80211: World regulatory domain updated:
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
(2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
(2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
(5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
1284335098.343222: phy #0: regulatory domain change: set to world roaming by
the wireless core upon initiat
root@RMR1:/# insmod /lib/modules/2.6.32.10/ath5k.ko
ath5k 0000:00:0e.0: registered as 'phy0'
ath5k phy0: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
ath5k 0000:00:0f.0: registered as 'phy1'
cfg80211: Calling CRDA for country: JP
ath5k phy1: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
cfg80211: Calling CRDA for country: JP
root@RMR1:/# cfg80211: Current regulatory domain intersected:
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(2457000 KHz - 2472000 KHz @ 15000 KHz), (N/A, 2000 mBm)
(2457000 KHz - 2472000 KHz @ 15000 KHz), (N/A, 2000 mBm)
(2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(2474000 KHz - 2482000 KHz @ 8000 KHz), (N/A, 2000 mBm)
(2474000 KHz - 2482000 KHz @ 8000 KHz), (N/A, 2000 mBm)
(2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
1284335110.273907: phy #1: regulatory domain change: intersection used due to
a request made by a driver o1
cfg80211: Current regulatory domain intersected:
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(2457000 KHz - 2472000 KHz @ 15000 KHz), (N/A, 2000 mBm)
(2457000 KHz - 2472000 KHz @ 15000 KHz), (N/A, 2000 mBm)
(2457000 KHz - 2472000 KHz @ 15000 KHz), (N/A, 2000 mBm)
(2457000 KHz - 2472000 KHz @ 15000 KHz), (N/A, 2000 mBm)
(2457000 KHz - 2472000 KHz @ 15000 KHz), (N/A, 2000 mBm)
(2457000 KHz - 2472000 KHz @ 15000 KHz), (N/A, 2000 mBm)
(2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(2474000 KHz - 2482000 KHz @ 8000 KHz), (N/A, 2000 mBm)
(2474000 KHz - 2482000 KHz @ 8000 KHz), (N/A, 2000 mBm)
(2474000 KHz - 2482000 KHz @ 8000 KHz), (N/A, 2000 mBm)
(2474000 KHz - 2482000 KHz @ 8000 KHz), (N/A, 2000 mBm)
(2474000 KHz - 2482000 KHz @ 8000 KHz), (N/A, 2000 mBm)
(2474000 KHz - 2482000 KHz @ 8000 KHz), (N/A, 2000 mBm)
(2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
1284335114.847761: phy #1: regulatory domain change: intersection used due to
a request made by a driver o
here again, the output of iw event on a proper console:
root@RMR1:~# 1284335259.046129: phy #1: regulatory domain change: intersection
used due to a request made by a driver on phy1
1284335263.403515: phy #1: regulatory domain change: intersection used due to
a request made by a driver on phy1
interesting that phy #1 appears twice...
if there is no intersection problem it looks like this:
1284334386.775218: phy #0: regulatory domain change: set to JP by a driver
request on phy0
1284334387.020971: phy #1: regulatory domain change: set to JP by a driver
request on phy1
btw: udev is not in use.
any ideas how to further debug this?
bruno
^ permalink raw reply
* Re: rootfs as RAMDisk + Hypervisor: Cannot allocate memory
From: Jan Beulich @ 2010-10-08 7:56 UTC (permalink / raw)
To: Robyn Bachofer; +Cc: xen-devel
In-Reply-To: <AANLkTi=QzrdYCp57Bb0_=YHT0ZHw6brrGw5sAUTd73Tr@mail.gmail.com>
>>> On 08.10.10 at 09:38, Robyn Bachofer <r.bachofer@googlemail.com> wrote:
> Hello Jan,
>
> that's a good guess.
> I found your pasted line in mm/vmalloc.c, line 108.
> What can i do? A workaround is to change from ramdisk to nfs, but this is
> not fine.
> Or a way to "fix" this problem?
Since you posted to xen-devel (and not xen-users) I supposed you
would be able to do some work here. That's why I outlined potential
fixes (and the page table cleanup one shouldn't be more than a
couple of lines). If that's not the case, you'll need to talk someone
into doing this work for you.
Oh, actually I just thought of a possible workaround: Likely your
initrd is over 500Mb in size only in uncompressed form. If in
compressed form it's well below that size, you could either change
the compression type to anything but gzip (so that GrUB won't try
to expand it) or use "modulenounzip" instead of "module" in
grub.conf for specifying the initrd.
Jan
> 2010/10/7 Jan Beulich <JBeulich@novell.com>
>
>> >>> On 07.10.10 at 13:21, Robyn Bachofer <r.bachofer@googlemail.com>
>> wrote:
>> > [hostname ~]# modprobe iscsi_tcp
>> > Warning: at mm/vmalloc.c:108 vmap_page_range_noflush+0x22/0x2e2()
>> > Hardware name: IBM eServer BladeCenter HS21 -[7995A1G]-
>> > Pid: 2344, comm: modprobe Tainted: C W 2.6.32.23-pvops #2
>> > Call Trace:
>> > [<ffffffffxxxxxxxx>] ? warn_slowpath_common
>> > [<ffffffffxxxxxxxx>] ? vmap_page_range_noflush
>> > [<ffffffffxxxxxxxx>] ? map_vm_area
>> > [<ffffffffxxxxxxxx>] ? __vmalloc_area_node
>> > [<ffffffffxxxxxxxx>] ? load_module
>> > [<ffffffffxxxxxxxx>] ? do_page_fault
>> > [<ffffffffxxxxxxxx>] ? sys_init_module
>> > [<ffffffffxxxxxxxx>] ? sys_call_fastpath
>> > ---[ end trace xxxxxxxx ]---
>> > FATAL: Error inserting iscsi_tcp
>> > (/lib/modules/2.6.32.23-pvops/kernel/driver/scsi/iscsi_tcp.ko): Cannot
>> > allocate memory
>>
>> Can you match this to a source line? Namely, if it maps to
>>
>> if (WARN_ON(!pte_none(*pte)))
>>
>> in vmap_pte_range(), it would suggest there's some page table
>> cleanup missing after the initrd is no longer needed at its original
>> location (with the sizes you provided its quite certain that it runs
>> into the virtual address range used for modules). For native,
>> there's no mapping of the initrd following the kernel image (and
>> honestly I don't know why Xen specifies it as being mapped
>> there - if you had one of about 2G in size, Xen would refuse to
>> load your Dom0 altogether; perhaps time for another ELF note
>> indicating that the kernel can do without the initrd being
>> mapped into virtual space), so Xen kernels need to clean up
>> the left over page table entries, and apparently the pv-ops
>> code didn't inherit the respective XenoLinux bits.
>>
>> Jan
>>
>>
>
^ permalink raw reply
* RE: Configuration of nestedhvm
From: Dong, Eddie @ 2010-10-08 7:56 UTC (permalink / raw)
To: Keir Fraser; +Cc: Xen-devel, Dong, Eddie
In-Reply-To: <C8D482D4.256E2%keir@xen.org>
Keir Fraser wrote:
> On 08/10/2010 05:34, "Dong, Eddie" <eddie.dong@intel.com> wrote:
>
>> 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.
>
> What's the point when a per-domain config option is going to be
> implemented? You can then simply not configure nestedhvm for a domain
> you want to test without that capability? I suppose it makes your
> second patch make a bit more sense than it would in total isolation.
I want double-lock (AND) like other components such as IOMMU.
If the global switch is off, even per domain configuration is turned on, the final effect is "OFF".
The point here is to avoid manual mistake when the nested code is built in as formal release but targeting for pilot. Relying on HVM guest configuration only may cause the host crash or performance impact if the code has a bug and a guest enables nested virtualization feature.
This switch is mainly for developer only at least for now.
>
> I think patch#2 probably makes sense, but it should wait for the
> patch that actually implements the per-domain config option, and
> properly implements is_nestedhvm(), before going in.
Yes, I am waiting for the take of that patch from Chris as well, but for some reason it is not in yet :(
Either patch is taken first is fine. I can do the simple rebase.
>
> -- Keir
Thx, Eddie
^ permalink raw reply
* Re: [PATCH 16/18] fs: Make iunique independent of inode_lock
From: Christoph Hellwig @ 2010-10-08 7:55 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-17-git-send-email-david@fromorbit.com>
> + hlist_bl_for_each_entry(inode, node, &b->head, i_hash) {
> + if (inode->i_ino == ino && inode->i_sb == sb) {
wouldn't it be more natural to test the sb first here?
Otherwise looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v6 07/12] Add async PF initialization to PV guest.
From: Gleb Natapov @ 2010-10-08 7:54 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra, tglx, hpa, riel,
cl, mtosatti
In-Reply-To: <4CADC229.9040402@redhat.com>
On Thu, Oct 07, 2010 at 02:50:49PM +0200, Avi Kivity wrote:
> On 10/04/2010 05:56 PM, Gleb Natapov wrote:
> >Enable async PF in a guest if async PF capability is discovered.
> >
> >
> >+void __cpuinit kvm_guest_cpu_init(void)
> >+{
> >+ if (!kvm_para_available())
> >+ return;
> >+
> >+ if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF)&& kvmapf) {
> >+ u64 pa = __pa(&__get_cpu_var(apf_reason));
> >+
> >+ if (native_write_msr_safe(MSR_KVM_ASYNC_PF_EN,
> >+ pa | KVM_ASYNC_PF_ENABLED, pa>> 32))
>
> native_ versions of processor accessors shouldn't be used generally.
>
> Also, the MSR isn't documented to fail on valid input, so you can
> use a normal wrmsrl() here.
>
Kernel will oops on wrong write then. OK, why not.
> >+ return;
> >+ __get_cpu_var(apf_reason).enabled = 1;
> >+ printk(KERN_INFO"KVM setup async PF for cpu %d\n",
> >+ smp_processor_id());
> >+ }
> >+}
> >+
> >
> >+static int kvm_pv_reboot_notify(struct notifier_block *nb,
> >+ unsigned long code, void *unused)
> >+{
> >+ if (code == SYS_RESTART)
> >+ on_each_cpu(kvm_pv_disable_apf, NULL, 1);
> >+ return NOTIFY_DONE;
> >+}
> >+
> >+static struct notifier_block kvm_pv_reboot_nb = {
> >+ .notifier_call = kvm_pv_reboot_notify,
> >+};
>
> Does this handle kexec?
>
Yes.
> >+
> >+static void kvm_guest_cpu_notify(void *dummy)
> >+{
> >+ if (!dummy)
> >+ kvm_guest_cpu_init();
> >+ else
> >+ kvm_pv_disable_apf(NULL);
> >+}
>
> Why are you making decisions based on a dummy input?
>
> The whole thing looks strange. Use two functions?
>
What is so strange? Type of notification is passed as a parameter.
The code that does this is just under the function. I can rename
dummy to something else. Or make it two functions.
--
Gleb.
^ permalink raw reply
* [U-Boot] [PATCH V2 3/3] Kirkwood: Changes specific to ARM relocation support
From: Albert ARIBAUD @ 2010-10-08 7:54 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1286463519-19233-3-git-send-email-prafulla@marvell.com>
Le 07/10/2010 16:58, Prafulla Wadaskar a ?crit :
> All Kirkwood based boards are supported for this new implementation
> ref: docs/README.arm-relocation
>
> Signed-off-by: Prafulla Wadaskar<prafulla@marvell.com>
BTW, Wolfgang, is your offer to provide a branch to put ELF relocation
related changes still valid? Even periodically rebased against master
would be perfect... Otherwise I can set one up if you prefer.
Amicalement,
--
Albert.
^ permalink raw reply
* Re: [PATCH v6 07/12] Add async PF initialization to PV guest.
From: Gleb Natapov @ 2010-10-08 7:54 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra, tglx, hpa, riel,
cl, mtosatti
In-Reply-To: <4CADC229.9040402@redhat.com>
On Thu, Oct 07, 2010 at 02:50:49PM +0200, Avi Kivity wrote:
> On 10/04/2010 05:56 PM, Gleb Natapov wrote:
> >Enable async PF in a guest if async PF capability is discovered.
> >
> >
> >+void __cpuinit kvm_guest_cpu_init(void)
> >+{
> >+ if (!kvm_para_available())
> >+ return;
> >+
> >+ if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF)&& kvmapf) {
> >+ u64 pa = __pa(&__get_cpu_var(apf_reason));
> >+
> >+ if (native_write_msr_safe(MSR_KVM_ASYNC_PF_EN,
> >+ pa | KVM_ASYNC_PF_ENABLED, pa>> 32))
>
> native_ versions of processor accessors shouldn't be used generally.
>
> Also, the MSR isn't documented to fail on valid input, so you can
> use a normal wrmsrl() here.
>
Kernel will oops on wrong write then. OK, why not.
> >+ return;
> >+ __get_cpu_var(apf_reason).enabled = 1;
> >+ printk(KERN_INFO"KVM setup async PF for cpu %d\n",
> >+ smp_processor_id());
> >+ }
> >+}
> >+
> >
> >+static int kvm_pv_reboot_notify(struct notifier_block *nb,
> >+ unsigned long code, void *unused)
> >+{
> >+ if (code == SYS_RESTART)
> >+ on_each_cpu(kvm_pv_disable_apf, NULL, 1);
> >+ return NOTIFY_DONE;
> >+}
> >+
> >+static struct notifier_block kvm_pv_reboot_nb = {
> >+ .notifier_call = kvm_pv_reboot_notify,
> >+};
>
> Does this handle kexec?
>
Yes.
> >+
> >+static void kvm_guest_cpu_notify(void *dummy)
> >+{
> >+ if (!dummy)
> >+ kvm_guest_cpu_init();
> >+ else
> >+ kvm_pv_disable_apf(NULL);
> >+}
>
> Why are you making decisions based on a dummy input?
>
> The whole thing looks strange. Use two functions?
>
What is so strange? Type of notification is passed as a parameter.
The code that does this is just under the function. I can rename
dummy to something else. Or make it two functions.
--
Gleb.
--
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 1/1] omap: Ptr "isr_reg" tracked as NULL was dereferenced
From: Evgeny Kuznetsov @ 2010-10-08 7:49 UTC (permalink / raw)
To: ext Kevin Hilman, balbi
Cc: tony@atomide.com, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
zmc@lurian.net, a.j.buxton
In-Reply-To: <1286346802.24366.89.camel@ekuznets-lx-nokia>
On Wed, 2010-10-06 at 10:33 +0400, Evgeny Kuznetsov wrote:
> On Tue, 2010-10-05 at 08:01 -0700, ext Kevin Hilman wrote:
> > Felipe Balbi <balbi@ti.com> writes:
> >
> > > Hi,
> > >
> > > On Tue, Oct 05, 2010 at 03:42:10AM -0500, Evgeny Kuznetsov wrote:
> > >>+ if (!isr_reg) {
> > >>+ printk(KERN_ERR "FATAL: Incorrect GPIO method %i\n",
> > >>+ bank->method);
> > >>+ BUG();
> > >>+ }
> > >
> > > this could be simply:
> > >
> > > BUG_ON(!isr_reg);
> >
> > WARN_ON is better.
> >
> > A BUG() will panic the kernel and stop everything. This is not an error
> > condition that should prevent the entire kernel from running.
>
> 'isr_reg' is dereferenced later in code:
> ...
> isr_saved = isr = __raw_readl(isr_reg) & enabled;
> ...
> So this will stop kernel anyway.
> I just hoped to help in understanding of issue by log line. WARN_ON
> could be used for this.
>
> As a variant compilation error could be added, to prevent situation when
> kernel is incorrectly configured.
> E.g.:
> #if !defined(CONFIG_ARCH_OMAP1) &&
> !defined(CONFIG_ARCH_OMAP15XX) &&
> !defined(CONFIG_ARCH_OMAP16XX) &&
> !defined(CONFIG_ARCH_OMAP730) &&
> !defined(CONFIG_ARCH_OMAP850) &&
> !defined(CONFIG_ARCH_OMAP2) &&
> !defined(CONFIG_ARCH_OMAP3) &&
> !defined(CONFIG_ARCH_OMAP4)
>
> #error "Incorrect arch configuration"
> #endif
>
> But there are still cases when 'isr_reg' could have NULL value (if
> 'bank->method' is not equal to configured one).
>
> Regards,
> Evgeny
If 'isr_reg' is NULL then interrupt could not be handled. We may unmask
the GPIO bank interrupt to continue handle GPIO interrupts for other
lines. And exit handler to prevent kernel oops since 'isr_reg' is
dereferenced later in code(see my message above).
if (WARN_ON(!isr_reg)) {
desc->chip->unmask(irq);
return;
}
One thing I warn about that we could not clear edge sensitive
interrupts:
_enable_gpio_irqbank(bank, isr_saved & ~level_mask, 0);
_clear_gpio_irqbank(bank, isr_saved & ~level_mask);
_enable_gpio_irqbank(bank, isr_saved & ~level_mask, 1);
What do you think?
Evgeny.
^ permalink raw reply
* [U-Boot] Crash in env_relocate_spec() of env_mmc.c
From: Stefano Babic @ 2010-10-08 7:53 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AANLkTinsa4o3ipnZqqY-qLT1Kob2R1K2gBX2gSDKr8tx@mail.gmail.com>
Steve Sakoman wrote:
Hi Steve,
> I've been attempting to get the OMAP4 boards working post the ARM
> relocation changes.
>
> Panda was simple. The OMAP4430SDP is proving to be more challenging,
> as it freezes after printing the DRAM size message.
>
> Adding a few printfs revealed that the crash occurs in env_mmc.c's
> env_relocate_spec() routine.
>
> Has anyone else run into this issue? Any advice?
I tested, I can see the same issue. The main problem is that
mmc_initialize is not called before mmc_init() in arch/arm/lib/board.c
if relocation is active. In start_armboot it is called before.
The second problem I see is that env_relocate_spec should call
env_import() as already done by other environment (I checked with env_nand).
I can send a patch that at least on my target solves the problem. Could
you test it ?
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH 15/18] fs: introduce a per-cpu last_ino allocator
From: Christoph Hellwig @ 2010-10-08 7:53 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-16-git-send-email-david@fromorbit.com>
> +static unsigned int last_ino_get(void)
Shouldn't this be get_next_ino?
Otherwise looks okay for now.
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Alan Cox @ 2010-10-08 8:18 UTC (permalink / raw)
To: Daniel Walker
Cc: linux-kernel, Hyok S. Choi, Tony Lindgren, Jeff Ohlstein,
Greg Kroah-Hartman, Ben Dooks, Alan Cox, Kukjin Kim,
Mike Frysinger, Feng Tang, Tobias Klauser, Jason Wessel,
Philippe Langlais
In-Reply-To: <1286487718.23836.94.camel@c-dwalke-linux.qualcomm.com>
> > - Submit a driver that uses the existing allocated jtag major/minor only
>
> The driver does this already. It uses ttyJ* by default, and ttyS is an
> option ..
It didn't seem to be using the correct major/minor however ?
^ permalink raw reply
* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
From: Thomas Gleixner @ 2010-10-08 7:52 UTC (permalink / raw)
To: Dave Airlie; +Cc: LKML, Ingo Molnar, Jesse Barnes
In-Reply-To: <alpine.LFD.2.00.1010072329220.3354@localhost6.localdomain6>
On Thu, 7 Oct 2010, Thomas Gleixner wrote:
Oct 7 23:21:24 ionos kernel: Console: switching to colour VGA+ 80x25
> Oct 7 23:21:31 ionos kernel: drm: unregistered panic notifier
> Oct 7 23:21:31 ionos kernel: vga_switcheroo: disabled
> Oct 7 23:21:31 ionos kernel: [drm:drm_mm_takedown] *ERROR* Memory manager not clean. Delaying takedown
>
> That one scares me :)
>
> Oct 7 23:21:32 ionos kernel: BUG: unable to handle kernel paging request at 00000037362e313a
>
> We are again dereferencing a user space address.
Further debugging shows that the interrupt is torn down and the
vectors are cleared. On modprobe the irq is set up again and a
different vector is assigned.
The interrupt which comes in is going to the old vector. So something
is stale in the card.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 11/18] fs: Introduce per-bucket inode hash locks
From: Dave Chinner @ 2010-10-08 7:51 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <20101008073306.GD7831@lst.de>
On Fri, Oct 08, 2010 at 03:33:06AM -0400, Christoph Hellwig wrote:
> On Fri, Oct 08, 2010 at 04:21:25PM +1100, Dave Chinner wrote:
> > From: Nick Piggin <npiggin@suse.de>
> >
> > Protect the inod hash with a single lock is not scalable. Convert
>
> s/inod/inode/
>
> > p = &root->inode_tree.rb_node;
> > parent = NULL;
> >
> > - if (hlist_unhashed(&inode->i_hash))
> > + if (hlist_bl_unhashed(&inode->i_hash))
>
> Maybe introduce an inode_unhashed helper for this check which we're
> doing in quite a lot of places?
Ok, makes sense.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH 09/18] fs: rework icount to be a locked variable
From: Dave Chinner @ 2010-10-08 7:50 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-fsdevel, linux-kernel, chris.mason, linux-btrfs
In-Reply-To: <20101008072749.GB7831@lst.de>
On Fri, Oct 08, 2010 at 03:27:49AM -0400, Christoph Hellwig wrote:
> > index 2953e9f..9f04478 100644
> > --- a/fs/btrfs/inode.c
> > +++ b/fs/btrfs/inode.c
> > @@ -1964,8 +1964,14 @@ void btrfs_add_delayed_iput(struct inode *inode)
> > struct btrfs_fs_info *fs_info = BTRFS_I(inode)->root->fs_info;
> > struct delayed_iput *delayed;
> >
> > - if (atomic_add_unless(&inode->i_count, -1, 1))
> > + /* XXX: filesystems should not play refcount games like this */
> > + spin_lock(&inode->i_lock);
> > + if (inode->i_ref > 1) {
> > + inode->i_ref--;
> > + spin_unlock(&inode->i_lock);
> > return;
> > + }
> > + spin_unlock(&inode->i_lock);
>
> Yeah, all that i_count/i_ref mess in btrfs needs some serious work.
> Chris?
>
> > +
> > +/*
> > + * inode_lock must be held
> > + */
> > +void iref_locked(struct inode *inode)
> > +{
> > + inode->i_ref++;
> > +}
> > EXPORT_SYMBOL_GPL(iref_locked);
>
> I'm a big fan of _GPL exports, but adding this for a trivial counter
> increment seems a bit weird.
OK, will drop the _GPL.
>
> > int iref_read(struct inode *inode)
> > {
> > - return atomic_read(&inode->i_count);
> > + int ref;
> > +
> > + spin_lock(&inode->i_lock);
> > + ref = inode->i_ref;
> > + spin_unlock(&inode->i_lock);
> > + return ref;
> > }
>
> There's no need to lock a normal 32-bit variable for readers.
Ok, but will need a memory barrier instead?
>
> > + inode->i_ref--;
> > + if (inode->i_ref == 0) {
>
> if (--inode->i_ref == 0) {
>
> might be a bit more idiomatic.
OK.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH 14/18] fs: Protect inode->i_state with th einode->i_lock
From: Christoph Hellwig @ 2010-10-08 7:49 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-15-git-send-email-david@fromorbit.com>
On Fri, Oct 08, 2010 at 04:21:28PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> We currently protect the per-inode state flags with the inode_lock.
> Using a global lock to protect per-object state is overkill when we
> coul duse a per-inode lock to protect the state. Use the
> inode->i_lock for this, and wrap all the state changes and checks
> with the inode->i_lock.
>
> Based on work originally written by Nick Piggin.
> @@ -884,9 +897,9 @@ struct inode *new_inode(struct super_block *sb)
> inode = alloc_inode(sb);
> if (inode) {
> spin_lock(&inode_lock);
> - __inode_add_to_lists(sb, NULL, inode);
> inode->i_ino = ++last_ino;
> inode->i_state = 0;
> + __inode_add_to_lists(sb, NULL, inode);
> spin_unlock(&inode_lock);
> }
> return inode;
What's the point in doing this move?
> @@ -953,8 +966,8 @@ static struct inode *get_new_inode(struct super_block *sb,
> if (set(inode, data))
> goto set_failed;
>
> - __inode_add_to_lists(sb, b, inode);
> inode->i_state = I_NEW;
> + __inode_add_to_lists(sb, b, inode);
Same here.
Otherwise it looks good. But all this moving around of i_lock really
hurts my brain. I guess I'll need to review the placement on a tree
with the fully applied series again.
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [RFC PATCH] usb: makefile cleanup
From: matt mooney @ 2010-10-08 7:47 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-kbuild, Michal Marek
In-Reply-To: <20101006165004.GA25221@merkur.ravnborg.org>
On 18:50 Wed 06 Oct , Sam Ravnborg wrote:
> On Wed, Oct 06, 2010 at 12:51:41AM -0700, matt mooney wrote:
> > For all modules, change <module>-objs to <module>-y; remove
> > if-statements and replace with lists using the kbuild idiom; move
> > flags to the top of the file; and fix alignment while trying to
> > maintain the original scheme in each file.
> >
> > None of the dependencies are modified.
> >
> > Signed-off-by: matt mooney <mfm@muteddisk.com>
>
> Looks good. I agree with Michal's comment about
> moving the complexity from MAkefile to Kconfig.
> But I think that should be a follow-up patch.
>
> You can add my:
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> Two trivial comments...
> You can keep my ack independent of addressing these comments or not.
>
> Sam
>
> > diff --git a/drivers/usb/host/whci/Kbuild b/drivers/usb/host/whci/Kbuild
> > index 11e5040..26df013 100644
> > --- a/drivers/usb/host/whci/Kbuild
> > +++ b/drivers/usb/host/whci/Kbuild
> > @@ -3,7 +3,7 @@ obj-$(CONFIG_USB_WHCI_HCD) += whci-hcd.o
> > whci-hcd-y := \
> > asl.o \
> > debug.o \
> > - hcd.o \
> > + hcd.o \
> > hw.o \
> > init.o \
> > int.o \
>
> I would be good to loose the "\"
>
> > diff --git a/drivers/usb/wusbcore/Makefile b/drivers/usb/wusbcore/Makefile
> > index f0d8045..b3bd313 100644
> > --- a/drivers/usb/wusbcore/Makefile
> > +++ b/drivers/usb/wusbcore/Makefile
> > @@ -1,9 +1,11 @@
> > +ccflags-$(CONFIG_USB_WUSB_CBAF_DEBUG) := -DDEBUG
> > +
> > obj-$(CONFIG_USB_WUSB) += wusbcore.o
> > obj-$(CONFIG_USB_HWA_HCD) += wusb-wa.o
> > obj-$(CONFIG_USB_WUSB_CBAF) += wusb-cbaf.o
> >
> >
> > -wusbcore-objs := \
> > +wusbcore-y := \
> > crypto.o \
> > devconnect.o \
> > dev-sysfs.o \
> > @@ -14,11 +16,10 @@ wusbcore-objs := \
> > security.o \
> > wusbhc.o
> >
> > -wusb-cbaf-objs := cbaf.o
> > +wusb-cbaf-y := cbaf.o
> >
> > -wusb-wa-objs := wa-hc.o \
> > - wa-nep.o \
> > - wa-rpipe.o \
> > - wa-xfer.o
> > -
> > -ccflags-$(CONFIG_USB_WUSB_CBAF_DEBUG) := -DDEBUG
> > +wusb-wa-y := \
> > + wa-hc.o \
> > + wa-nep.o \
> > + wa-rpipe.o \
> > + wa-xfer.o
> This file could also benefit from loosing the excessive use of "\".
Maybe this should have been changed. A lot of the staging makefiles are doing
this.
-mfm
k
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Alan Cox @ 2010-10-08 8:13 UTC (permalink / raw)
To: Daniel Walker
Cc: Mike Frysinger, linux-kernel, Hyok S. Choi, Tony Lindgren,
Jeff Ohlstein, Greg Kroah-Hartman, Ben Dooks, Alan Cox,
Kukjin Kim, Feng Tang, Tobias Klauser, Jason Wessel,
Philippe Langlais
In-Reply-To: <1286486094.23836.59.camel@c-dwalke-linux.qualcomm.com>
> It is , what's to stop any userspace from using ttyS0 ? .. There's lots
> of binary userspaces in the embedded world, along with many strange
> usages ..
So you change your file system, whoopee.
And if your hypothetical user isn't able to do this then maybe instead of
trying to screw up the kernel for everyone they should ask an
undergraduate student who is smart enough to help them.
Alan
^ permalink raw reply
* Re: [PATCH 06/18] fs: Clean up inode reference counting
From: Dave Chinner @ 2010-10-08 7:46 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <20101008072051.GE23595@lst.de>
On Fri, Oct 08, 2010 at 03:20:51AM -0400, Christoph Hellwig wrote:
> On Fri, Oct 08, 2010 at 04:21:20PM +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> >
> > Lots of filesystem code open codes the act of getting a reference to
> > an inode. Factor the open coded inode lock, increment, unlock into
> > a function iref(). Then rename __iget to iref_locked so that nothing
> > is directly incrementing the inode reference count for trivial
> > operations.
> >
> > Originally based on a patch from Nick Piggin.
>
> > +++ b/fs/anon_inodes.c
> > @@ -111,10 +111,9 @@ struct file *anon_inode_getfile(const char *name,
> > path.mnt = mntget(anon_inode_mnt);
> > /*
> > * We know the anon_inode inode count is always greater than zero,
> > - * so we can avoid doing an igrab() and we can use an open-coded
> > - * atomic_inc().
> > + * so we can avoid doing an igrab() by using iref().
>
> I don't think there's a point keeping this comment.
OK.
>
> > @@ -297,7 +297,7 @@ static void inode_wait_for_writeback(struct inode *inode)
> >
> > /*
> > * Write out an inode's dirty pages. Called under inode_lock. Either the
> > - * caller has ref on the inode (either via __iget or via syscall against an fd)
> > + * caller has ref on the inode (either via iref_locked or via syscall against an fd)
>
> I'd say just drop the mentioning of how we got a reference to the inode,
OK.
> it's just too confusing in this context.
>
> > --- a/fs/inode.c
> > +++ b/fs/inode.c
> > @@ -313,11 +313,20 @@ static void init_once(void *foo)
> >
> > inode_init_once(inode);
> > }
> > +EXPORT_SYMBOL_GPL(iref_locked);
>
> I think the export is placed incorrectly here.
Fmeh - guilt has an annoying habit of applying patches silently
when there are context mismatches. I've fixed this mismatch about 5
times in the past 2 days, and it keeps creeping back in as I update
patches earlier in the series. I'll fix it up in the next pass.
> > +
> > +void iref(struct inode *inode)
> > +{
> > + spin_lock(&inode_lock);
> > + iref_locked(inode);
> > + spin_unlock(&inode_lock);
> > +}
> > +EXPORT_SYMBOL_GPL(iref);
>
>
> > +void iref_locked(struct inode *inode)
> > {
> > atomic_inc(&inode->i_count);
> > }
>
> Please add a kerneldoc comment for both exported functions.
OK.
> Also what's the point of taking inode_lock in iref when the only thing
> we do is an atomic_in? It's probably better only having iref for now
> and only introduce iref_locked once the non-atomic increment needs
> i_lock.
Because in the next couple of patches the atomic-ness goes away, and
the inode lock keeps everything "sane" until all the locking
conversion is completed.
> Also any chance to get an assert under a debug option the the reference
> count really is non-zero?
For iref()? Sure, but I think WARN_ON_ONCE() is better for the moment,
though.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
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.