* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-01 21:53 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <20110201214211.GB31105@redhat.com>
On Tue, 2011-02-01 at 23:42 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 01, 2011 at 01:32:35PM -0800, Shirley Ma wrote:
> > On Tue, 2011-02-01 at 23:24 +0200, Michael S. Tsirkin wrote:
> > > My theory is that the issue is not signalling.
> > > Rather, our queue fills up, then host handles
> > > one packet and sends an interrupt, and we
> > > immediately wake the queue. So the vq
> > > once it gets full, stays full.
> >
> > >From the printk debugging output, it might not be exactly the case.
> The
> > ring gets full, run a bit, then gets full, then run a bit, then
> full...
>
> Yes, but does it get even half empty in between?
Sometimes, most of them not half of empty in between. But printk slow
down the traffics, so it's not accurate. I think your patch will improve
the performance if it signals guest when half of the ring size is
empty.
But you manage signal by using TX bytes, I would like to change it to
half of the ring size instead for signaling. Is that OK?
Shirley
^ permalink raw reply
* RE: Bootable Raid-1
From: Leslie Rhorer @ 2011-02-01 21:53 UTC (permalink / raw)
To: naira; +Cc: linux-raid
In-Reply-To: <4D487CA4.2030502@faccat.br>
> -----Original Message-----
> From: Naira Kaieski [mailto:naira@faccat.br]
> Sent: Tuesday, February 01, 2011 3:36 PM
> To: lrhorer@satx.rr.com
> Cc: linux-raid@vger.kernel.org
> Subject: Re: Bootable Raid-1
>
> Hi,
>
> My metadata is 0.90...
>
> My Partitions:
> /dev/sda1 1 122 979933+ fd Linux raid
> autodetect
> /dev/sda2 * 123 134 96390 fd Linux raid
> autodetect
> /dev/sda3 135 19457 155211997+ fd Linux raid
> autodetect
I recall reading very recently (it might have even been today) that
Linux RAID Autodetect partitions can cause problems. I have mine set to
simply "Linux":
Disk /dev/sda: 500 GB, 500105249280 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 50 401593 83 Linux
/dev/sda2 51 40000 320890342 83 Linux
/dev/sda3 40001 60801 167076000 83 Linux
> Disk /dev/md1: 1003 MB, 1003356160 bytes
> 2 heads, 4 sectors/track, 244960 cylinders
> Units = cylinders of 8 * 512 = 4096 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00000000
>
> Disk /dev/md1 doesn't contain a valid partition table
>
> Disk /dev/md2: 98 MB, 98631680 bytes
> 2 heads, 4 sectors/track, 24080 cylinders
> Units = cylinders of 8 * 512 = 4096 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00000000
>
> Disk /dev/md2 doesn't contain a valid partition table
>
> Disk /dev/md3: 158.9 GB, 158936989696 bytes
> 2 heads, 4 sectors/track, 38802976 cylinders
> Units = cylinders of 8 * 512 = 4096 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0xc4036374
>
> Disk /dev/md3 doesn't contain a valid partition table
>
>
> I created the array with the command:
> mdadm --create --verbose --assume-clean --metadata=0.90 /dev/md3
> --level=1 --raid-devices=2 /dev/sda3 missing
>
> # cat /proc/mdstat
> Personalities : [raid1]
> md3 : active raid1 sda3[0]
> 155211904 blocks [2/1] [U_]
>
> md2 : active raid1 sda2[0]
> 96320 blocks [2/1] [U_]
>
> md1 : active raid1 sda1[0]
> 979840 blocks [2/1] [U_]
>
> # mdadm -D --scan
> ARRAY /dev/md1 metadata=0.90 UUID=e905069f:43e2eaa4:e090bcab:b1d9c206
> ARRAY /dev/md2 metadata=0.90 UUID=d259ec4f:1c63d0b1:e090bcab:b1d9c206
> ARRAY /dev/md3 metadata=0.90 UUID=030d5ded:82314c21:e090bcab:b1d9c206
>
> On dmesg:
> [ 2349.760155] md: bind<sda1>
> [ 2349.762677] md/raid1:md1: active with 1 out of 2 mirrors
> [ 2349.762720] md1: detected capacity change from 0 to 1003356160
> [ 2349.765307] md1: unknown partition table
> [ 2363.059235] md: bind<sda2>
> [ 2363.061089] md/raid1:md2: active with 1 out of 2 mirrors
> [ 2363.061129] md2: detected capacity change from 0 to 98631680
> [ 2363.065812] md2: unknown partition table
> [ 2372.302358] md: bind<sda3>
> [ 2372.304614] md/raid1:md3: active with 1 out of 2 mirrors
> [ 2372.304663] md3: detected capacity change from 0 to 158936989696
> [ 2372.308395] md3: unknown partition table
>
> My kernel config:
> CONFIG_MD=y
> CONFIG_BLK_DEV_MD=y
> CONFIG_MD_AUTODETECT=y
> CONFIG_MD_RAID1=y
>
> # mdadm --examine /dev/sda3
> /dev/sda3:
> Magic : a92b4efc
> Version : 0.90.00
> UUID : 030d5ded:82314c21:e090bcab:b1d9c206 (local to host dns)
> Creation Time : Tue Feb 1 19:03:30 2011
> Raid Level : raid1
> Used Dev Size : 155211904 (148.02 GiB 158.94 GB)
> Array Size : 155211904 (148.02 GiB 158.94 GB)
> Raid Devices : 2
> Total Devices : 1
> Preferred Minor : 3
>
> Update Time : Tue Feb 1 19:18:56 2011
> State : clean
> Active Devices : 1
> Working Devices : 1
> Failed Devices : 1
> Spare Devices : 0
> Checksum : 64a5bec0 - correct
> Events : 7
>
>
> Number Major Minor RaidDevice State
> this 0 8 3 0 active sync /dev/sda3
>
> 0 0 8 3 0 active sync /dev/sda3
> 1 1 0 0 1 faulty removed
>
> I format the md* devices and copy file with rsync, alter the grub and
> fstab to boot md devices but on boot i have fail to boot md3 as rootfs
>
> Atenciosamente,
> Naira Kaieski
>
>
>
> Em 1/2/2011 18:43, Leslie Rhorer escreveu:
> >> I have read several articles on the internet and researched in the
> >> messages list, but I'm still having trouble configuring a raid level 1
> >> array that is bootable.
> >>
> >> I configured a server some time agowith Gentoo Linux, Kernel
> >> 2.6.28-hardened-r9, mdadm - v3.0 and 2 IDE hard drives, this is working
> >> correctly. For this installation iused as a basis for consultation
> >> Article http://en.gentoo-wiki.com/wiki/Migrate_to_RAID
> >>
> >> Now, I want to use two SATA drives in raid level 1,
> >>
> >> Now i have Gentoo Linux with kernel 2.6.36-hardened-r6 and mdadm -
> >> v3.1.4 and the instructions of Article dont work. The kernel was
> >> configured with support for disks raid autodetect and supported the
> raid
> >> level 1. But in the logs of dmesg does not run the auto-detection of
> the
> >> disks to the array, so in the boot when mounting the root device /
> >> dev/md2 the system can not find the device.
> >>
> >> When I run mdadm - auto-detect the array are found somewhere but still
> >> displays message indicating that the raid device is not a valid
> >> partition table.
> >>
> >> How can you configure a raid level 1 with bootable disks / dev / sda
> and
> >> / dev / sdb?
> >> I want three partitions:
> >> /dev/md1 - swap - /dev/sda1, /dev/sdb1
> >> /dev/md2 - boot - /dev/sda2, /dev/sdb2
> >> /dev/md3 - / - /dev/sda3, /dev/sdb3
> >>
> >> I am using grub as bootloader.
> > This is very similar to my boot configuration on my two servers. I
> > suspect your problem is the metadata. What version of superblock are
> you
> > using for /dev/md2? GRUB2 does not recognize a version 1.x superblock.
> > Since the boot images are quite small, and don't require an array of
> many
> > disks, there is nothing wrong with the 0.90 superblock, however. If
> your
> > /dev/md2 array is not a 0.9 version superblock, try converting it. Here
> is
> > my configuration from one of the servers:
> >
> > ARRAY /dev/md0 level=raid6 num-devices=10 metadata=01.2 name=Backup:0
> > UUID=431244d6:45d9635a:e88b3de5:92f30255
> > ARRAY /dev/md1 level=raid1 num-devices=2 metadata=0.90
> > UUID=4cde286c:0687556a:4d9996dd:dd23e701
> > ARRAY /dev/md2 level=raid1 num-devices=2 metadata=01.2 name=Backup:2
> > UUID=d45ff663:9e53774c:6fcf9968:21692025
> > ARRAY /dev/md3 level=raid1 num-devices=2 metadata=01.2 name=Backup:3
> > UUID=51d22c47:10f58974:0b27ef04:5609d357
> >
> > Where md0 is a large (11T) data array, md1 is boot, md2 is root, and
> > md3 is swap. The partitioning layout of the boot drives is the same as
> > yours.
> >
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Junio C Hamano @ 2011-02-01 21:53 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, git
In-Reply-To: <20110201014807.GA2722@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Jan 31, 2011 at 07:29:54PM -0500, Nicolas Pitre wrote:
>
>> > Yes, we do suck at rename following. The problem is that it is partially
>> [...]
>> This is no excuse not to do proper source tree reorganization.
>
> I think this is the crux of our disagreement. I don't agree that your
> proposal is any way more "proper" than what is there now. Leaving the
> rename issue aside (i.e., if we were starting a new project), I would
> still be slightly against a src/ directory. I find them annoying.
>
> But I don't care _that_ much, and I would rather not waste either of our
> time debating it more. I would much rather you spend your time on
> pack v4. :)
I am with you, both counts on this topic. I don't necessarily agree that
having sources at the top-level is bad, I don't want to see Nico wasting
his time arguing, and I do see some value in the proposal that gives us an
opportunity for dogfooding (but we already have done so with builtin/ and
it was not all that annoying---I think the timing was rather good and the
tree was semi-quiescent).
Ehh, that makes it not "both" but "two and half" counts ;-).
As long as the new directories are named sanely (one of the things I
detest is abbreviated uppercase silliness like "Src", "Lib"), I am fine
with the proposal. Also I have a mild preference to keep build-products
next to the source (i.e. no separate "obj" directory).
^ permalink raw reply
* Re: Network performance with small packets
From: Michael S. Tsirkin @ 2011-02-01 21:56 UTC (permalink / raw)
To: Shirley Ma
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <1296597185.26937.829.camel@localhost.localdomain>
On Tue, Feb 01, 2011 at 01:53:05PM -0800, Shirley Ma wrote:
> On Tue, 2011-02-01 at 23:42 +0200, Michael S. Tsirkin wrote:
> > On Tue, Feb 01, 2011 at 01:32:35PM -0800, Shirley Ma wrote:
> > > On Tue, 2011-02-01 at 23:24 +0200, Michael S. Tsirkin wrote:
> > > > My theory is that the issue is not signalling.
> > > > Rather, our queue fills up, then host handles
> > > > one packet and sends an interrupt, and we
> > > > immediately wake the queue. So the vq
> > > > once it gets full, stays full.
> > >
> > > >From the printk debugging output, it might not be exactly the case.
> > The
> > > ring gets full, run a bit, then gets full, then run a bit, then
> > full...
> >
> > Yes, but does it get even half empty in between?
>
> Sometimes, most of them not half of empty in between. But printk slow
> down the traffics, so it's not accurate. I think your patch will improve
> the performance if it signals guest when half of the ring size is
> empty.
>
> But you manage signal by using TX bytes,
There are flags for bytes, buffers and packets.
Try playing with any one of them :)
Just be sure to use v2.
>I would like to change it to
> half of the ring size instead for signaling. Is that OK?
>
> Shirley
>
>
Sure that is why I made it a parameter so you can experiment.
--
MST
^ permalink raw reply
* Re: [PATCH v2] IB/qib: add thresholds to VendorPortCounters PMA operation
From: Ira Weiny @ 2011-02-01 21:56 UTC (permalink / raw)
To: Mike Marciniszyn
Cc: Roland Dreier, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ralph.campbell-h88ZbnxC6KDQT0dZR+AlfA@public.gmane.org,
tom.elken-h88ZbnxC6KDQT0dZR+AlfA@public.gmane.org,
hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org,
todd.rimmer-h88ZbnxC6KDQT0dZR+AlfA@public.gmane.org
In-Reply-To: <20110201142348.9826.83896.stgit-hIFRcJ1SNwcXGO8/Qfapyjg/wwJxntczYPYVAmT7z5s@public.gmane.org>
On Tue, 1 Feb 2011 06:23:48 -0800
Mike Marciniszyn <mike.marciniszyn-h88ZbnxC6KDQT0dZR+AlfA@public.gmane.org> wrote:
> The patch has been reworked so that the fields used are no longer reserved.
>
> The QLogic PMA has a vendor specific capability. We are using the top
> 2 bits of the CapabilityMask2 to indicate the behavior is available.
>
> By not setting the bit 2 in the CapabilityMask, we are indicating that
> other PMA clients should ignore CapabilityMask2.
I'm confused, does this mean you never plan to support any capabilities which
will be indicated in CapabilityMask2?
There are only 2 bits left in CapabilityMask at this time, with a proposal
already submitted to use one of them.
I think it would be better to suggest to the IBTA to either A) reserve some
bits for vendor specific use in CapabilityMask2 or better yet B) suggest this
as a standard use of those bits.
Another option, if you don't want this included as part of the standard is to
use the Vendor specific class to communicate this information.
Am I missing something?
Ira
>
> As such no other tools should be confused by our setting of the 2 bits
> (because they should not look in CapabilityMask2 anyway).
>
> We purposely do not set the PortXmitWait CapabilityMask bit, this
> driver does not implement that capability.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ira Weiny
Math Programmer/Computer Scientist
Lawrence Livermore National Lab
925-423-8008
weiny2-i2BcT+NCU+M@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Bug 32888] [r600g] GL_EXT_texture_compression_s3tc support
From: bugzilla-daemon @ 2011-02-01 21:57 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-32888-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=32888
--- Comment #1 from Tobias Jakobi <liquid.acid@gmx.net> 2011-02-01 13:57:45 PST ---
wine also kind of requires this extension, since s3tc is mandatory for Direct3D
translation inside the wined3d layer.
--
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
* Re: Odd "data used" reporting behavior by ceph -w
From: Jim Schutt @ 2011-02-01 21:57 UTC (permalink / raw)
To: Gregory Farnum; +Cc: ceph-devel@vger.kernel.org
In-Reply-To: <AANLkTinJ6RWM6L9hF6yJ5KYEs3qYEwvY0EaZFCcHL-t1@mail.gmail.com>
On Tue, 2011-02-01 at 14:44 -0700, Gregory Farnum wrote:
> On Tue, Feb 1, 2011 at 1:31 PM, Jim Schutt <jaschut@sandia.gov> wrote:
> > I've just lightly tested current stable branch, commit 0f3198e8c63.
> >
> > For me both problems seem to still exist.
> Well that's a bummer.
>
> > I'm running 4 osds per host on 4 hosts, 1 mon, 1 mds, 64 clients.
> >
> > For me a "ls" on the file system root from one of
> > the clients still doesn't complete until the dd commands
> > running on each client complete.
> >
> > Also, it is still true for me if I truncate all the files
> > to zero from one of the clients, then write them again,
> > one file per client, that second set of writes goes very
> > slow.
> >
> > Am I maybe testing the wrong commit?
> Nope, that commit should do it.
>
> What version of the client software are you running?
I'm running
1f0324caef from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+
a3f5274e53 from git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git
+
90ba60990b from git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-work.git
I actually run that kernel on both clients and servers, FWIW.
I haven't updated my remotes for a few days, so
I can run anything newer that you need me to run.
> I'll have to look
> over the change logs to see if maybe there are changes in there that
> would impact this as well. Also my test environment is smaller than
> yours; I'll endeavor to look this over again on a larger one with more
> clients and see if I can spot any extra interactions causing problems.
OK, great.
-- Jim
> -Greg
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" 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] e2fsprogs: Fix how we treat user-spcified filesystem size
From: Greg Freemyer @ 2011-02-01 21:57 UTC (permalink / raw)
To: Andreas Dilger; +Cc: Lukas Czerner, linux-ext4, tytso
In-Reply-To: <140BFB14-31E6-4E76-B1DA-5CD8F54FDD5B@dilger.ca>
On Tue, Feb 1, 2011 at 3:37 PM, Andreas Dilger <adilger@dilger.ca> wrote:
> On 2011-02-01, at 12:18, Lukas Czerner wrote:
>> +Optionally, the
>> +.I filesystem-size
>> +parameter may be suffixed by one of the following the units
>> +designators: 'b', 's', 'K', 'M', or 'G',
>> +for blocks count, 512 byte sectors, kilobytes, megabytes, or gigabytes,
>> +respectively.
>
> My reading of parse_num_blocks() shows that 'T' is also accepted as a suffix for terabytes, which I was otherwise going to suggest be added, since this is the normal size for filesystems today. It might be worthwhile _briefly_ mentioning here that these are binary/power-of-two values and not decimal values, instead of the rant further below.
>
> Minor technical nit - the proper metric value is lower-case 'k' for kilo, though the upper-case 'M', 'G', and 'T' are correct for mega-, giga-, and terabytes.
<pedantic>
If they are powers of 2, they are: kibibytes, mebibytes, gibibytes,
and tebibytes.
See the chart on the right of: http://en.wikipedia.org/wiki/Kibibyte
Many linux tools have already moved to these names and abbreviations.
(TiB not TB, etc.)
<\pedantic>
Greg
--
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
* [PATCH v8] mac80211: Optimize scans on current operating channel.
From: greearb @ 2011-02-01 21:59 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
This should decrease un-necessary flushes, on/off channel work,
and channel changes in cases where the only scanned channel is
the current operating channel.
* Removes SCAN_OFF_CHANNEL flag, uses SDATA_STATE_OFFCHANNEL
and is-scanning flags instead.
* Add helper method to determine if we are currently configured
for the operating channel.
* Do no blindly go off/on channel in work.c Instead, only call
appropriate on/off code when we really need to change channels.
* Consolidate ieee80211_offchannel_stop_station and
ieee80211_offchannel_stop_beaconing, call it
ieee80211_offchannel_stop_vifs instead.
* Accept non-beacon frames when scanning on operating channel.
* Scan state machine optimized to minimize on/off channel
transitions. Also, when going on-channel, go ahead and
re-enable beaconing. We're going to be there for 200ms,
so seems like some useful beaconing could happen.
* Grab local->mtx earlier in __ieee80211_scan_completed_finish
so that we are protected when calling hw_config(), etc.
* Pass probe-responses up the stack if scanning on local
channel, so that mlme can take a look.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v8: Fix patch description w/regard to accepting non-beacon
frames while scanning on channel.
And, ensure scan_channel is NULL in the scan-finish logic.
This is basically insurrance against bugs in the scan
state machine. I have not seen the WARNings hit in my
testing.
:100644 100644 c47d7c0... 50ceb67... M net/mac80211/ieee80211_i.h
:100644 100644 09a2744... 6684b9e... M net/mac80211/main.c
:100644 100644 b4e5267... 5400da6... M net/mac80211/offchannel.c
:100644 100644 7185c93... 030c3e9... M net/mac80211/rx.c
:100644 100644 f246d8a... b48ce0d... M net/mac80211/scan.c
:100644 100644 ffc6749... 5f8b4a6... M net/mac80211/tx.c
:100644 100644 36305e0... 3c8ece9... M net/mac80211/work.c
net/mac80211/ieee80211_i.h | 13 +++++---
net/mac80211/main.c | 51 ++++++++++++++++++++++++++---
net/mac80211/offchannel.c | 48 +++++++--------------------
net/mac80211/rx.c | 12 ++-----
net/mac80211/scan.c | 75 ++++++++++++++++++++++++++++---------------
net/mac80211/tx.c | 3 +-
net/mac80211/work.c | 54 +++++++++++++++++++++++++------
7 files changed, 163 insertions(+), 93 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c47d7c0..50ceb67 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -654,8 +654,6 @@ struct tpt_led_trigger {
* well be on the operating channel
* @SCAN_HW_SCANNING: The hardware is scanning for us, we have no way to
* determine if we are on the operating channel or not
- * @SCAN_OFF_CHANNEL: We're off our operating channel for scanning,
- * gets only set in conjunction with SCAN_SW_SCANNING
* @SCAN_COMPLETED: Set for our scan work function when the driver reported
* that the scan completed.
* @SCAN_ABORTED: Set for our scan work function when the driver reported
@@ -664,7 +662,6 @@ struct tpt_led_trigger {
enum {
SCAN_SW_SCANNING,
SCAN_HW_SCANNING,
- SCAN_OFF_CHANNEL,
SCAN_COMPLETED,
SCAN_ABORTED,
};
@@ -1147,8 +1144,14 @@ void ieee80211_rx_bss_put(struct ieee80211_local *local,
struct ieee80211_bss *bss);
/* off-channel helpers */
-void ieee80211_offchannel_stop_beaconing(struct ieee80211_local *local);
-void ieee80211_offchannel_stop_station(struct ieee80211_local *local);
+/**
+ * Returns true if we are logically configured to be on
+ * the operating channel AND the hardware-conf is currently
+ * configured on the operating channel. Compares channel-type
+ * as well.
+ */
+bool ieee80211_cfg_on_oper_channel(struct ieee80211_local *local);
+void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local);
void ieee80211_offchannel_return(struct ieee80211_local *local,
bool enable_beaconing);
void ieee80211_hw_roc_setup(struct ieee80211_local *local);
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 09a2744..6684b9e 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -98,6 +98,39 @@ static void ieee80211_reconfig_filter(struct work_struct *work)
ieee80211_configure_filter(local);
}
+/* Return true if we are logically configured to be on
+ * the operating channel AND the hardware-conf is currently
+ * configured on the operating channel.
+ */
+bool ieee80211_cfg_on_oper_channel(struct ieee80211_local *local)
+{
+ struct ieee80211_channel *chan, *scan_chan;
+ enum nl80211_channel_type channel_type;
+
+ /* This logic needs to match logic in ieee80211_hw_config */
+ if (local->scan_channel) {
+ chan = local->scan_channel;
+ channel_type = NL80211_CHAN_NO_HT;
+ } else if (local->tmp_channel) {
+ chan = scan_chan = local->tmp_channel;
+ channel_type = local->tmp_channel_type;
+ } else {
+ chan = local->oper_channel;
+ channel_type = local->_oper_channel_type;
+ }
+
+ if (chan != local->oper_channel ||
+ channel_type != local->_oper_channel_type)
+ return false;
+
+ /* Check current hardware-config against oper_channel. */
+ if ((local->oper_channel != local->hw.conf.channel) ||
+ (local->_oper_channel_type != local->hw.conf.channel_type))
+ return false;
+
+ return true;
+}
+
int ieee80211_hw_config(struct ieee80211_local *local, u32 changed)
{
struct ieee80211_channel *chan, *scan_chan;
@@ -110,21 +143,27 @@ int ieee80211_hw_config(struct ieee80211_local *local, u32 changed)
scan_chan = local->scan_channel;
+ /* If this off-channel logic ever changes, ieee80211_on_oper_channel
+ * may need to change as well.
+ */
offchannel_flag = local->hw.conf.flags & IEEE80211_CONF_OFFCHANNEL;
if (scan_chan) {
chan = scan_chan;
channel_type = NL80211_CHAN_NO_HT;
- local->hw.conf.flags |= IEEE80211_CONF_OFFCHANNEL;
- } else if (local->tmp_channel &&
- local->oper_channel != local->tmp_channel) {
+ } else if (local->tmp_channel) {
chan = scan_chan = local->tmp_channel;
channel_type = local->tmp_channel_type;
- local->hw.conf.flags |= IEEE80211_CONF_OFFCHANNEL;
} else {
chan = local->oper_channel;
channel_type = local->_oper_channel_type;
- local->hw.conf.flags &= ~IEEE80211_CONF_OFFCHANNEL;
}
+
+ if (chan != local->oper_channel ||
+ channel_type != local->_oper_channel_type)
+ local->hw.conf.flags |= IEEE80211_CONF_OFFCHANNEL;
+ else
+ local->hw.conf.flags &= ~IEEE80211_CONF_OFFCHANNEL;
+
offchannel_flag ^= local->hw.conf.flags & IEEE80211_CONF_OFFCHANNEL;
if (offchannel_flag || chan != local->hw.conf.channel ||
@@ -231,7 +270,7 @@ void ieee80211_bss_info_change_notify(struct ieee80211_sub_if_data *sdata,
if (changed & BSS_CHANGED_BEACON_ENABLED) {
if (local->quiescing || !ieee80211_sdata_running(sdata) ||
- test_bit(SCAN_SW_SCANNING, &local->scanning)) {
+ test_bit(SDATA_STATE_OFFCHANNEL, &sdata->state)) {
sdata->vif.bss_conf.enable_beacon = false;
} else {
/*
diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c
index b4e5267..5400da6 100644
--- a/net/mac80211/offchannel.c
+++ b/net/mac80211/offchannel.c
@@ -95,55 +95,33 @@ static void ieee80211_offchannel_ps_disable(struct ieee80211_sub_if_data *sdata)
ieee80211_sta_reset_conn_monitor(sdata);
}
-void ieee80211_offchannel_stop_beaconing(struct ieee80211_local *local)
+void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local)
{
struct ieee80211_sub_if_data *sdata;
+ /*
+ * notify the AP about us leaving the channel and stop all
+ * STA interfaces.
+ */
mutex_lock(&local->iflist_mtx);
list_for_each_entry(sdata, &local->interfaces, list) {
if (!ieee80211_sdata_running(sdata))
continue;
- /* disable beaconing */
+ if (sdata->vif.type != NL80211_IFTYPE_MONITOR)
+ set_bit(SDATA_STATE_OFFCHANNEL, &sdata->state);
+
+ /* Check to see if we should disable beaconing. */
if (sdata->vif.type == NL80211_IFTYPE_AP ||
sdata->vif.type == NL80211_IFTYPE_ADHOC ||
sdata->vif.type == NL80211_IFTYPE_MESH_POINT)
ieee80211_bss_info_change_notify(
sdata, BSS_CHANGED_BEACON_ENABLED);
- /*
- * only handle non-STA interfaces here, STA interfaces
- * are handled in ieee80211_offchannel_stop_station(),
- * e.g., from the background scan state machine.
- *
- * In addition, do not stop monitor interface to allow it to be
- * used from user space controlled off-channel operations.
- */
- if (sdata->vif.type != NL80211_IFTYPE_STATION &&
- sdata->vif.type != NL80211_IFTYPE_MONITOR) {
- set_bit(SDATA_STATE_OFFCHANNEL, &sdata->state);
- netif_tx_stop_all_queues(sdata->dev);
- }
- }
- mutex_unlock(&local->iflist_mtx);
-}
-
-void ieee80211_offchannel_stop_station(struct ieee80211_local *local)
-{
- struct ieee80211_sub_if_data *sdata;
-
- /*
- * notify the AP about us leaving the channel and stop all STA interfaces
- */
- mutex_lock(&local->iflist_mtx);
- list_for_each_entry(sdata, &local->interfaces, list) {
- if (!ieee80211_sdata_running(sdata))
- continue;
-
- if (sdata->vif.type == NL80211_IFTYPE_STATION) {
- set_bit(SDATA_STATE_OFFCHANNEL, &sdata->state);
+ if (sdata->vif.type != NL80211_IFTYPE_MONITOR) {
netif_tx_stop_all_queues(sdata->dev);
- if (sdata->u.mgd.associated)
+ if ((sdata->vif.type == NL80211_IFTYPE_STATION) &&
+ sdata->u.mgd.associated)
ieee80211_offchannel_ps_enable(sdata);
}
}
@@ -181,7 +159,7 @@ void ieee80211_offchannel_return(struct ieee80211_local *local,
netif_tx_wake_all_queues(sdata->dev);
}
- /* re-enable beaconing */
+ /* Check to see if we should re-enable beaconing */
if (enable_beaconing &&
(sdata->vif.type == NL80211_IFTYPE_AP ||
sdata->vif.type == NL80211_IFTYPE_ADHOC ||
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 7185c93..030c3e9 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -409,16 +409,10 @@ ieee80211_rx_h_passive_scan(struct ieee80211_rx_data *rx)
if (likely(!(status->rx_flags & IEEE80211_RX_IN_SCAN)))
return RX_CONTINUE;
- if (test_bit(SCAN_HW_SCANNING, &local->scanning))
+ if (test_bit(SCAN_HW_SCANNING, &local->scanning) ||
+ test_bit(SCAN_SW_SCANNING, &local->scanning))
return ieee80211_scan_rx(rx->sdata, skb);
- if (test_bit(SCAN_SW_SCANNING, &local->scanning)) {
- /* drop all the other packets during a software scan anyway */
- if (ieee80211_scan_rx(rx->sdata, skb) != RX_QUEUED)
- dev_kfree_skb(skb);
- return RX_QUEUED;
- }
-
/* scanning finished during invoking of handlers */
I802_DEBUG_INC(local->rx_handlers_drop_passive_scan);
return RX_DROP_UNUSABLE;
@@ -2766,7 +2760,7 @@ static void __ieee80211_rx_handle_packet(struct ieee80211_hw *hw,
local->dot11ReceivedFragmentCount++;
if (unlikely(test_bit(SCAN_HW_SCANNING, &local->scanning) ||
- test_bit(SCAN_OFF_CHANNEL, &local->scanning)))
+ test_bit(SCAN_SW_SCANNING, &local->scanning)))
status->rx_flags |= IEEE80211_RX_IN_SCAN;
if (ieee80211_is_mgmt(fc))
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index f246d8a..b48ce0d 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -212,6 +212,13 @@ ieee80211_scan_rx(struct ieee80211_sub_if_data *sdata, struct sk_buff *skb)
if (bss)
ieee80211_rx_bss_put(sdata->local, bss);
+ /* If we are scanning on-channel, pass the pkt on up the stack so that
+ * mlme can make use of it
+ */
+ if (ieee80211_cfg_on_oper_channel(sdata->local)
+ && (channel == sdata->local->oper_channel))
+ return RX_CONTINUE;
+
dev_kfree_skb(skb);
return RX_QUEUED;
}
@@ -293,15 +300,28 @@ static void __ieee80211_scan_completed_finish(struct ieee80211_hw *hw,
bool was_hw_scan)
{
struct ieee80211_local *local = hw_to_local(hw);
+ bool ooc;
+
+ mutex_lock(&local->mtx);
+ ooc = ieee80211_cfg_on_oper_channel(local);
+
+ if (was_hw_scan || !ooc) {
+ if (WARN_ON(local->scan_channel))
+ local->scan_channel = NULL;
+ ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
+ }
- ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
if (!was_hw_scan) {
+ bool ooc2;
ieee80211_configure_filter(local);
drv_sw_scan_complete(local);
- ieee80211_offchannel_return(local, true);
+ ooc2 = ieee80211_cfg_on_oper_channel(local);
+ /* We should always be on-channel at this point. */
+ WARN_ON(!ooc2);
+ if (ooc2 && (ooc != ooc2))
+ ieee80211_offchannel_return(local, true);
}
- mutex_lock(&local->mtx);
ieee80211_recalc_idle(local);
mutex_unlock(&local->mtx);
@@ -398,14 +418,10 @@ static int ieee80211_start_sw_scan(struct ieee80211_local *local)
drv_sw_scan_start(local);
- ieee80211_offchannel_stop_beaconing(local);
-
local->leave_oper_channel_time = 0;
local->next_scan_state = SCAN_DECISION;
local->scan_channel_idx = 0;
- drv_flush(local, false);
-
ieee80211_configure_filter(local);
ieee80211_queue_delayed_work(&local->hw,
@@ -544,7 +560,21 @@ static void ieee80211_scan_state_decision(struct ieee80211_local *local,
}
mutex_unlock(&local->iflist_mtx);
- if (local->scan_channel) {
+ next_chan = local->scan_req->channels[local->scan_channel_idx];
+
+ if (ieee80211_cfg_on_oper_channel(local)) {
+ /* We're currently on operating channel. */
+ if ((next_chan == local->oper_channel) &&
+ (local->_oper_channel_type == NL80211_CHAN_NO_HT))
+ /* We don't need to move off of operating channel. */
+ local->next_scan_state = SCAN_SET_CHANNEL;
+ else
+ /*
+ * We do need to leave operating channel, as next
+ * scan is somewhere else.
+ */
+ local->next_scan_state = SCAN_LEAVE_OPER_CHANNEL;
+ } else {
/*
* we're currently scanning a different channel, let's
* see if we can scan another channel without interfering
@@ -560,7 +590,6 @@ static void ieee80211_scan_state_decision(struct ieee80211_local *local,
*
* Otherwise switch back to the operating channel.
*/
- next_chan = local->scan_req->channels[local->scan_channel_idx];
bad_latency = time_after(jiffies +
ieee80211_scan_get_channel_time(next_chan),
@@ -578,12 +607,6 @@ static void ieee80211_scan_state_decision(struct ieee80211_local *local,
local->next_scan_state = SCAN_ENTER_OPER_CHANNEL;
else
local->next_scan_state = SCAN_SET_CHANNEL;
- } else {
- /*
- * we're on the operating channel currently, let's
- * leave that channel now to scan another one
- */
- local->next_scan_state = SCAN_LEAVE_OPER_CHANNEL;
}
*next_delay = 0;
@@ -592,9 +615,7 @@ static void ieee80211_scan_state_decision(struct ieee80211_local *local,
static void ieee80211_scan_state_leave_oper_channel(struct ieee80211_local *local,
unsigned long *next_delay)
{
- ieee80211_offchannel_stop_station(local);
-
- __set_bit(SCAN_OFF_CHANNEL, &local->scanning);
+ ieee80211_offchannel_stop_vifs(local);
/*
* What if the nullfunc frames didn't arrive?
@@ -617,15 +638,13 @@ static void ieee80211_scan_state_enter_oper_channel(struct ieee80211_local *loca
{
/* switch back to the operating channel */
local->scan_channel = NULL;
- ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
+ if (!ieee80211_cfg_on_oper_channel(local))
+ ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
/*
- * Only re-enable station mode interface now; beaconing will be
- * re-enabled once the full scan has been completed.
+ * Re-enable vifs and beaconing.
*/
- ieee80211_offchannel_return(local, false);
-
- __clear_bit(SCAN_OFF_CHANNEL, &local->scanning);
+ ieee80211_offchannel_return(local, true);
*next_delay = HZ / 5;
local->next_scan_state = SCAN_DECISION;
@@ -641,8 +660,12 @@ static void ieee80211_scan_state_set_channel(struct ieee80211_local *local,
chan = local->scan_req->channels[local->scan_channel_idx];
local->scan_channel = chan;
- if (ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL))
- skip = 1;
+
+ /* Only call hw-config if we really need to change channels. */
+ if ((chan != local->hw.conf.channel) ||
+ (local->hw.conf.channel_type != NL80211_CHAN_NO_HT))
+ if (ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL))
+ skip = 1;
/* advance state machine to next channel/band */
local->scan_channel_idx++;
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index ffc6749..5f8b4a6 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -257,7 +257,8 @@ ieee80211_tx_h_check_assoc(struct ieee80211_tx_data *tx)
if (unlikely(info->flags & IEEE80211_TX_CTL_INJECTED))
return TX_CONTINUE;
- if (unlikely(test_bit(SCAN_OFF_CHANNEL, &tx->local->scanning)) &&
+ if (unlikely(test_bit(SCAN_SW_SCANNING, &tx->local->scanning)) &&
+ test_bit(SDATA_STATE_OFFCHANNEL, &tx->sdata->state) &&
!ieee80211_is_probe_req(hdr->frame_control) &&
!ieee80211_is_nullfunc(hdr->frame_control))
/*
diff --git a/net/mac80211/work.c b/net/mac80211/work.c
index 36305e0..3c8ece9 100644
--- a/net/mac80211/work.c
+++ b/net/mac80211/work.c
@@ -924,18 +924,39 @@ static void ieee80211_work_work(struct work_struct *work)
}
if (!started && !local->tmp_channel) {
- /*
- * TODO: could optimize this by leaving the
- * station vifs in awake mode if they
- * happen to be on the same channel as
- * the requested channel
- */
- ieee80211_offchannel_stop_beaconing(local);
- ieee80211_offchannel_stop_station(local);
+ bool ooc = ieee80211_cfg_on_oper_channel(local);
+ bool tmp_chan_changed = false;
+ bool ooc2;
+ if (local->tmp_channel)
+ if ((local->tmp_channel != wk->chan) ||
+ (local->tmp_channel_type != wk->chan_type))
+ tmp_chan_changed = true;
local->tmp_channel = wk->chan;
local->tmp_channel_type = wk->chan_type;
- ieee80211_hw_config(local, 0);
+ /*
+ * Leave the station vifs in awake mode if they
+ * happen to be on the same channel as
+ * the requested channel.
+ */
+ ooc2 = ieee80211_cfg_on_oper_channel(local);
+ if (ooc != ooc2) {
+ if (ooc2) {
+ /* went off operating channel */
+ ieee80211_offchannel_stop_vifs(local);
+ ieee80211_hw_config(local, 0);
+ } else {
+ /* went on channel */
+ ieee80211_hw_config(local, 0);
+ ieee80211_offchannel_return(local,
+ true);
+ }
+ } else if (tmp_chan_changed)
+ /* Still off-channel, but on some other
+ * channel, so update hardware.
+ */
+ ieee80211_hw_config(local, 0);
+
started = true;
wk->timeout = jiffies;
}
@@ -1011,9 +1032,20 @@ static void ieee80211_work_work(struct work_struct *work)
}
if (!remain_off_channel && local->tmp_channel) {
+ bool ooc = ieee80211_cfg_on_oper_channel(local);
local->tmp_channel = NULL;
- ieee80211_hw_config(local, 0);
- ieee80211_offchannel_return(local, true);
+ /* If tmp_channel wasn't operating channel, then
+ * we need to go back on-channel.
+ * NOTE: If we can ever be here while scannning,
+ * or if the hw_config() channel config logic changes,
+ * then we may need to do a more thorough check to see if
+ * we still need to do a hardware config. Currently,
+ * we cannot be here while scanning, however.
+ */
+ if (ieee80211_cfg_on_oper_channel(local) && !ooc) {
+ ieee80211_hw_config(local, 0);
+ ieee80211_offchannel_return(local, true);
+ }
/* give connection some time to breathe */
run_again(local, jiffies + HZ/2);
}
--
1.7.2.3
^ permalink raw reply related
* 2.6.38-rc3 regression on parisc: segfaults
From: Meelis Roos @ 2011-02-01 22:00 UTC (permalink / raw)
To: linux-parisc, Linux Kernel list
I have been testing devel kernels on SMP L1000 successfully until
2.6.38-rc2-00324-g70d1f36 included. The testing means booting the new
kernel and running aptitude to update to current debian unstable.
Now I tried 2.6.38-rc3 and got a crash from aptitude on 2 out of 2
tries. Maybe aptitude was broken inbetween but it looks like a kernel
bug. Retried 2.6.38-rc2-00324-g70d1f36 and that seemed to work fine so
it's more likely a kernel problem.
What additional information can I provide?
[ 74.590000]
[ 74.590000] do_page_fault() pid=979 command='aptitude' type=15 address=0x0000002d
[ 74.590000]
[ 74.590000] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[ 74.590000] PSW: 00000000000001001111111100001111 Not tainted
[ 74.590000] r00-03 000000ff0004ff0f 000000004027b5ac 00000000405df23b 000000004067e884
[ 74.590000] r04-07 000000004067c860 000000004067e6d0 000000004067e880 00000000c014b7d0
[ 74.590000] r08-11 0000000000000001 0000000000000001 000000004067c860 0000000041b082c8
[ 74.590000] r12-15 000000004067e730 000000004067e6d0 000000004067c860 000000004067c860
[ 74.590000] r16-19 000000004067c860 000000004067e060 0000000000000000 000000004067c860
[ 74.590000] r20-23 0000000000000229 0000000000000000 0000000000000000 0000000000000000
[ 74.590000] r24-27 fffffffffffffff5 ffffffffffffffd3 000000004067e730 00000000004227a4
[ 74.590000] r28-31 000000000000002d 0000000000000000 00000000c014b8c0 00000000402688db
[ 74.590000] sr00-03 0000000000228800 0000000000228800 0000000000000000 0000000000228800
[ 74.590000] sr04-07 0000000000228800 0000000000228800 0000000000228800 0000000000228800
[ 74.590000]
[ 74.590000] VZOUICununcqcqcqcqcqcrmunTDVZOUI
[ 74.590000] FPSR: 00001000001000100010000000000000
[ 74.590000] FPER1: 00000000
[ 74.590000] fr00-03 0822200000000000 0000000000000000 0000000000000000 0000000000000000
[ 74.590000] fr04-07 0000000a00000000 0000000000000000 0000000000000000 0000000000000000
[ 74.590000] fr08-11 0000000000000000 00000000406cf120 00000000401563e8 00000000404c59d8
[ 74.590000] fr12-15 000000000804000f 000000000800000f 00000000401563e8 00000000ffc60460
[ 74.590000] fr16-19 00000000406cf120 0000000040639d54 0000000000000046 0000000040599294
[ 74.590000] fr20-23 00000000ffc60348 00000000406dd920 0000000000000038 4038000000000000
[ 74.590000] fr24-27 0000000000000000 0000000000000000 3ff0000000000000 412e848c00000000
[ 74.590000] fr28-31 0000000040599250 00000000ffc60357 00000000ffc60357 00000000405dfba8
[ 74.590000]
[ 74.590000] IASQ: 0000000000228800 0000000000228800 IAOQ: 00000000405df25b 00000000405df25f
[ 74.590000] IIR: 0f80108b ISR: 0000000000228800 IOR: 000000000000002d
[ 74.590000] CPU: 0 CR30: 00000000fe050000 CR31: 0000000000008020
[ 74.590000] ORIG_R28: 0000000000000080
[ 74.590000] IAOQ[0]: 00000000405df25b
[ 74.590000] IAOQ[1]: 00000000405df25f
[ 74.590000] RP(r2): 00000000405df23b
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* [Bug 33825] New: [r600g, wine] sync/fenc GL extension missing
From: bugzilla-daemon @ 2011-02-01 22:00 UTC (permalink / raw)
To: dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=33825
Summary: [r600g, wine] sync/fenc GL extension missing
Product: DRI
Version: DRI CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: liquid.acid@gmx.net
Hello,
I noticed that r600g currently neither implements NV_fence nor ARB_sync. Wine
needs at least one of these extensions (I think ARB_sync is preferred) to
emulate event queries for Direct3D.
Currently this results in lots of errors:
err:d3d:wined3d_event_query_test Event query created despite lack of GL support
err:d3d:IWineD3DEventQueryImpl_GetData The GL event query failed, returning
D3DERR_INVALIDCALL
So this is more a feature request...
Greets,
Tobias
--
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
* Re: [PATCH 2/4] elfutils: add a missing depedancy
From: Richard Purdie @ 2011-02-01 22:00 UTC (permalink / raw)
To: Nitin A Kamble; +Cc: poky
In-Reply-To: <406a52d39863e35b5013c23b886e885d44a83e32.1296560850.git.nitin.a.kamble@intel.com>
On Tue, 2011-02-01 at 03:57 -0800, Nitin A Kamble wrote:
> From: Nitin A Kamble <nitin.a.kamble@intel.com>
>
> while implementing the mklibs optimization, found out that an executable from
> elfutils package, viz eu-findtextrel is dynamically linked to libbz2.so
> library. But the poky-image-minimal did not have that library.
> adding the depedency to the bzip2 to get that library for eu-fundtextrel
> executable.
>
> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> ---
> meta/recipes-devtools/elfutils/elfutils_0.148.bb | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/meta/recipes-devtools/elfutils/elfutils_0.148.bb b/meta/recipes-devtools/elfutils/elfutils_0.148.bb
> index 44b3c52..14060e6 100644
> --- a/meta/recipes-devtools/elfutils/elfutils_0.148.bb
> +++ b/meta/recipes-devtools/elfutils/elfutils_0.148.bb
> @@ -5,8 +5,9 @@ LICENSE = "GPLv2 with exceptions"
> LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3\
> file://EXCEPTION;md5=570adcb0c1218ab57f2249c67d0ce417"
> DEPENDS = "libtool zlib"
> +RDEPENDS = "bzip2"
There should be a package name here, e.g. RDEPENDS_${PN}.
Also, why is the shlibs code not picking up the dependency
automatically? Is it dlopen'd?
Cheers,
Richard
^ permalink raw reply
* [PATCH 1/2] omap3|4: opp: make omapx_opp_init non-static
From: Kevin Hilman @ 2011-02-01 22:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294260576-20237-2-git-send-email-nm@ti.com>
Nishanth Menon <nm@ti.com> writes:
> omap3 and omap4 opp_init should be made non-static to allow
> for platform specific opp table tweaking. making these static
> conflicts with the definition in pm.h(global) as well.
> we include pm.h as well to ensure that there are no such prototype
> conflicts with actual implementation in the future.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Thanks, queuing for 2.6.39 (branch: for_2.6.39/pm-misc)
Kevin
> ---
> arch/arm/mach-omap2/opp3xxx_data.c | 3 ++-
> arch/arm/mach-omap2/opp4xxx_data.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/opp3xxx_data.c b/arch/arm/mach-omap2/opp3xxx_data.c
> index 0486fce..fd3a1af 100644
> --- a/arch/arm/mach-omap2/opp3xxx_data.c
> +++ b/arch/arm/mach-omap2/opp3xxx_data.c
> @@ -21,6 +21,7 @@
> #include <plat/cpu.h>
>
> #include "omap_opp_data.h"
> +#include "pm.h"
>
> static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
> /* MPU OPP1 */
> @@ -88,7 +89,7 @@ static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
> /**
> * omap3_opp_init() - initialize omap3 opp table
> */
> -static int __init omap3_opp_init(void)
> +int __init omap3_opp_init(void)
> {
> int r = -ENODEV;
>
> diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-omap2/opp4xxx_data.c
> index a11fa56..f0e9939 100644
> --- a/arch/arm/mach-omap2/opp4xxx_data.c
> +++ b/arch/arm/mach-omap2/opp4xxx_data.c
> @@ -22,6 +22,7 @@
> #include <plat/cpu.h>
>
> #include "omap_opp_data.h"
> +#include "pm.h"
>
> static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
> /* MPU OPP1 - OPP50 */
> @@ -42,7 +43,7 @@ static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
> /**
> * omap4_opp_init() - initialize omap4 opp table
> */
> -static int __init omap4_opp_init(void)
> +int __init omap4_opp_init(void)
> {
> int r = -ENODEV;
^ permalink raw reply
* Re: [PATCH 1/3 v2] call_function_many: fix list delete vs add race
From: Paul E. McKenney @ 2011-02-01 22:00 UTC (permalink / raw)
To: Milton Miller
Cc: Peter Zijlstra, akpm, Anton Blanchard, xiaoguangrong, mingo,
jaxboe, npiggin, rusty, efault, torvalds, benh, linux-kernel
In-Reply-To: <smp-call-function-list-race-fix-v2@mdm.bga.com>
On Tue, Feb 01, 2011 at 01:12:18AM -0600, Milton Miller wrote:
> Peter pointed out there was nothing preventing the list_del_rcu in
> smp_call_function_interrupt from running before the list_add_rcu in
> smp_call_function_many. Fix this by not setting refs until we
> have gotten the lock for the list. Take advantage of the wmb in
> list_add_rcu to save an explicit additional one.
Finally getting a chance to give this full attention...
I don't know how to do this patch-by-patch, so I applied these
three patches to mainline and looked at the result. This probably
gets some comments that are irrelevant to these patches, but so it
goes.
Starting with smp_call_function_many():
o The check for refs is redundant:
/* some callers might race with other cpus changing the mask */
if (unlikely(!refs)) {
csd_unlock(&data->csd);
return;
}
The memory barriers and atomic functions in
generic_smp_call_function_interrupt() prevent the callback from
being reused before the cpumask bits have all been cleared, right?
Furthermore, csd_lock() contains a full memory barrier that pairs
with the full memory barrier in csd_unlock(), so if csd_lock()
returns, we are guaranteed to see the effects of all accesses
to the prior incarnation of this structure.
Yes, there might be another CPU that got a pointer to this
callback just as another CPU removed it. That CPU will see
the callback as having their bit of the CPU mask zero until
we set it, and they will further see ->refs as being zero
until we set it. And we don't set ->refs until after we
re-insert the callback.
So I we can drop this "if" statement entirely.
o The smp_mb() below look extraneous. The comment in
generic_exec_single() agrees -- it says that the IPI
code is required to impose ordering. Besides,
there is a lock in arch_send_call_function_ipi_mask(),
and in conjunction with the unlock below, this makes
a full memory barrier. So I believe that we can drop
the smp_mb() shown below. (But not the comment!!!)
raw_spin_unlock_irqrestore(&call_function.lock, flags);
/*
* Make the list addition visible before sending the ipi.
* (IPIs must obey or appear to obey normal Linux cache
* coherency rules -- see comment in generic_exec_single).
*/
smp_mb();
/* Send a message to all CPUs in the map */
arch_send_call_function_ipi_mask(data->cpumask);
Next up: generic_smp_call_function_interrupt()
o Shouldn't the smp_mb() at the top of the function be supplied
in arch-specific code for those architectures that require it?
o So, the check for the current CPU's bit in the mask...
o If the bit is clear, then we are looking at an callback
that this CPU already processed or that was not intended
for this CPU in the first place.
Of course, this callback might be reused immediately
after we do the check. In that case, there should
be an IPI waiting for us shortly. If the IPI beat
the callback to us, that seems to me to be a bug
in the architecture rather than in this code.
o If the bit is set, then we need to process this callback.
IRQs are disabled, so we cannot race with ourselves
-- our bit will remain set until we clear it.
The list_add_rcu() in smp_call_function_many()
in conjunction with the list_for_each_entry_rcu()
in generic_smp_call_function_interrupt() guarantees
that all of the field except for ->refs will be seen as
initialized in the common case where we are looking at
an callback that has just been enqueued.
In the uncommon case where we picked up the pointer
in list_for_each_entry_rcu() just before the last
CPU removed the callback and when someone else
immediately recycled it, all bets are off. We must
ensure that we see all initialization via some other
means.
OK, so where is the memory barrier that pairs with the
smp_rmb() between the ->cpumask and ->refs checks?
It must be before the assignment to ->cpumask. One
candidate is the smp_mb() in csd_lock(), but that does
not make much sense. What we need to do is to ensure
that if we see our bit in ->cpumask, that we also see
the atomic decrement that previously zeroed ->refs.
But some third CPU did that atomic decrement, which
brings transitivity into play, which leads me to believe
that this smp_rmb() might need to be upgraded to a
full smp_mb().
o After we verify that the ->refs field is non-zero, we pick
up the ->csd.func and ->csd.info fields, but with no intervening
memory barrier. There needs to be at least an smp_rmb()
following the test of the ->refs field. Since there is
no transitivity required, smp_rmb() should do the trick.
If this seems unnecessary, please keep in mind that there
is nothing stopping the compiler and the CPU from reordering
the statements in smp_call_function_many() that initialize
->csd.func, ->csd.info, and ->cpumask.
In contrast, given the suggested smp_rmb(), we are guaranteed
of the identity of the callback from the time we test ->refs
until the time someone calls csd_unlock(), which cannot precede
the time that we atomically decrement ->refs.
o It seems silly to pick up the ->csd.func field twice. Why
not use the local variable?
o The cpumask_test_and_clear_cpu() and the atomic_dec_return()
are both atomic operations that return values, so they act
as full memory barriers.
The cpumask_test_and_clear_cpu() needs to be atomic despite
the identity guarantee because CPUs might be concurrently
trying to clear bits in the same word.
Here is the corresponding (untested) patch.
Thoughts?
Thanx, Paul
------------------------------------------------------------------------
smp_call_function: additional memory-order tightening.
The csd_lock() and csd_unlock() interaction guarantees that the
smp_call_function_many() function sees the results of interactions
with prior incarnations of the callback, so the check is not needed.
Instead, tighter memory ordering is required in the companion
generic_smp_call_function_interrupt() function to ensure proper
interaction with partially initialized callbacks.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/kernel/smp.c b/kernel/smp.c
index 064bb6e..4c8b005 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -209,13 +209,19 @@ void generic_smp_call_function_interrupt(void)
if (!cpumask_test_cpu(cpu, data->cpumask))
continue;
- smp_rmb();
+ smp_mb(); /* If we see our bit set above, we need to see */
+ /* all the processing associated with the prior */
+ /* incarnation of this callback. */
if (atomic_read(&data->refs) == 0)
continue;
+ smp_rmb(); /* If we see non-zero ->refs, we need to see all */
+ /* other initialization for this incarnation of */
+ /* this callback. */
+
func = data->csd.func; /* for later warn */
- data->csd.func(data->csd.info);
+ func(data->csd.info);
/*
* If the cpu mask is not still set then func enabled
@@ -492,12 +498,6 @@ void smp_call_function_many(const struct cpumask *mask,
cpumask_clear_cpu(this_cpu, data->cpumask);
refs = cpumask_weight(data->cpumask);
- /* some callers might race with other cpus changing the mask */
- if (unlikely(!refs)) {
- csd_unlock(&data->csd);
- return;
- }
-
/*
* We reuse the call function data without waiting for any grace
* period after some other cpu removes it from the global queue.
@@ -527,8 +527,9 @@ void smp_call_function_many(const struct cpumask *mask,
* Make the list addition visible before sending the ipi.
* (IPIs must obey or appear to obey normal Linux cache
* coherency rules -- see comment in generic_exec_single).
+ * The unlock above combined with the lock in the IPI
+ * code covers this requirement.
*/
- smp_mb();
/* Send a message to all CPUs in the map */
arch_send_call_function_ipi_mask(data->cpumask);
^ permalink raw reply related
* Re: [PATCH 1/2] omap3|4: opp: make omapx_opp_init non-static
From: Kevin Hilman @ 2011-02-01 22:01 UTC (permalink / raw)
To: Nishanth Menon; +Cc: l-o, l-a, Tony, Koen Kooi
In-Reply-To: <1294260576-20237-2-git-send-email-nm@ti.com>
Nishanth Menon <nm@ti.com> writes:
> omap3 and omap4 opp_init should be made non-static to allow
> for platform specific opp table tweaking. making these static
> conflicts with the definition in pm.h(global) as well.
> we include pm.h as well to ensure that there are no such prototype
> conflicts with actual implementation in the future.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Thanks, queuing for 2.6.39 (branch: for_2.6.39/pm-misc)
Kevin
> ---
> arch/arm/mach-omap2/opp3xxx_data.c | 3 ++-
> arch/arm/mach-omap2/opp4xxx_data.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/opp3xxx_data.c b/arch/arm/mach-omap2/opp3xxx_data.c
> index 0486fce..fd3a1af 100644
> --- a/arch/arm/mach-omap2/opp3xxx_data.c
> +++ b/arch/arm/mach-omap2/opp3xxx_data.c
> @@ -21,6 +21,7 @@
> #include <plat/cpu.h>
>
> #include "omap_opp_data.h"
> +#include "pm.h"
>
> static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
> /* MPU OPP1 */
> @@ -88,7 +89,7 @@ static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
> /**
> * omap3_opp_init() - initialize omap3 opp table
> */
> -static int __init omap3_opp_init(void)
> +int __init omap3_opp_init(void)
> {
> int r = -ENODEV;
>
> diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-omap2/opp4xxx_data.c
> index a11fa56..f0e9939 100644
> --- a/arch/arm/mach-omap2/opp4xxx_data.c
> +++ b/arch/arm/mach-omap2/opp4xxx_data.c
> @@ -22,6 +22,7 @@
> #include <plat/cpu.h>
>
> #include "omap_opp_data.h"
> +#include "pm.h"
>
> static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
> /* MPU OPP1 - OPP50 */
> @@ -42,7 +43,7 @@ static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
> /**
> * omap4_opp_init() - initialize omap4 opp table
> */
> -static int __init omap4_opp_init(void)
> +int __init omap4_opp_init(void)
> {
> int r = -ENODEV;
^ permalink raw reply
* [PATCH v2 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
From: Kevin Hilman @ 2011-02-01 22:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294414873-22447-1-git-send-email-nm@ti.com>
Nishanth Menon <nm@ti.com> writes:
> OMP3630 silicon can enable higher frequencies only depending on the board
> characteristics meeting the recommended standards, and has to be selectively
> toggled.
>
> Beagle XM uses 3730 variant and the board design allows enabling 800MHz and
> 1GHz OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz
> safely. For the moment, we tweak the default table to allow for 800Mhz OPP
> usage.
>
> Reported-by: Koen Kooi <koen@beagleboard.org>
> Tested-by: Koen Kooi <koen@beagleboard.org>
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Thanks, queuing for 2.6.39 (branch: for_2.6.39/pm-misc)
Kevin
> ---
> v2: fixed issue when !mh || !dh, updated commit message to point on rationale
> for board specific tweaking
> v1: http://marc.info/?t=129426060900008&r=1&w=2
> arch/arm/mach-omap2/board-omap3beagle.c | 50 +++++++++++++++++++++++++++++++
> 1 files changed, 50 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
> index 6c12760..7dc0397 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -23,6 +23,7 @@
> #include <linux/gpio.h>
> #include <linux/input.h>
> #include <linux/gpio_keys.h>
> +#include <linux/opp.h>
>
> #include <linux/mtd/mtd.h>
> #include <linux/mtd/partitions.h>
> @@ -44,10 +45,12 @@
> #include <plat/gpmc.h>
> #include <plat/nand.h>
> #include <plat/usb.h>
> +#include <plat/omap_device.h>
>
> #include "mux.h"
> #include "hsmmc.h"
> #include "timer-gp.h"
> +#include "pm.h"
>
> #define NAND_BLOCK_SIZE SZ_128K
>
> @@ -556,6 +559,52 @@ static struct omap_musb_board_data musb_board_data = {
> .power = 100,
> };
>
> +static void __init beagle_opp_init(void)
> +{
> + int r = 0;
> +
> + /* Initialize the omap3 opp table */
> + if (omap3_opp_init()) {
> + pr_err("%s: opp default init failed\n", __func__);
> + return;
> + }
> +
> + /* Custom OPP enabled for XM */
> + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
> + struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
> + struct omap_hwmod *dh = omap_hwmod_lookup("iva");
> + struct device *dev;
> +
> + if (!mh || !dh) {
> + pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
> + __func__, mh, dh);
> + return;
> + }
> + /* Enable MPU 1GHz and lower opps */
> + dev = &mh->od->pdev.dev;
> + r = opp_enable(dev, 800000000);
> + /* TODO: MPU 1GHz needs SR and ABB */
> +
> + /* Enable IVA 800MHz and lower opps */
> + dev = &dh->od->pdev.dev;
> + r |= opp_enable(dev, 660000000);
> + /* TODO: DSP 800MHz needs SR and ABB */
> + if (r) {
> + pr_err("%s: failed to enable higher opp %d\n",
> + __func__, r);
> + /*
> + * Cleanup - disable the higher freqs - we dont care
> + * about the results
> + */
> + dev = &mh->od->pdev.dev;
> + opp_disable(dev, 800000000);
> + dev = &dh->od->pdev.dev;
> + opp_disable(dev, 660000000);
> + }
> + }
> + return;
> +}
> +
> static void __init omap3_beagle_init(void)
> {
> omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> @@ -579,6 +628,7 @@ static void __init omap3_beagle_init(void)
> omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
>
> beagle_display_init();
> + beagle_opp_init();
> }
>
> MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
^ permalink raw reply
* Re: [PATCH v2 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
From: Kevin Hilman @ 2011-02-01 22:01 UTC (permalink / raw)
To: Nishanth Menon; +Cc: l-o, l-a, Tony, Koen Kooi, Aaro
In-Reply-To: <1294414873-22447-1-git-send-email-nm@ti.com>
Nishanth Menon <nm@ti.com> writes:
> OMP3630 silicon can enable higher frequencies only depending on the board
> characteristics meeting the recommended standards, and has to be selectively
> toggled.
>
> Beagle XM uses 3730 variant and the board design allows enabling 800MHz and
> 1GHz OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz
> safely. For the moment, we tweak the default table to allow for 800Mhz OPP
> usage.
>
> Reported-by: Koen Kooi <koen@beagleboard.org>
> Tested-by: Koen Kooi <koen@beagleboard.org>
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Thanks, queuing for 2.6.39 (branch: for_2.6.39/pm-misc)
Kevin
> ---
> v2: fixed issue when !mh || !dh, updated commit message to point on rationale
> for board specific tweaking
> v1: http://marc.info/?t=129426060900008&r=1&w=2
> arch/arm/mach-omap2/board-omap3beagle.c | 50 +++++++++++++++++++++++++++++++
> 1 files changed, 50 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
> index 6c12760..7dc0397 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -23,6 +23,7 @@
> #include <linux/gpio.h>
> #include <linux/input.h>
> #include <linux/gpio_keys.h>
> +#include <linux/opp.h>
>
> #include <linux/mtd/mtd.h>
> #include <linux/mtd/partitions.h>
> @@ -44,10 +45,12 @@
> #include <plat/gpmc.h>
> #include <plat/nand.h>
> #include <plat/usb.h>
> +#include <plat/omap_device.h>
>
> #include "mux.h"
> #include "hsmmc.h"
> #include "timer-gp.h"
> +#include "pm.h"
>
> #define NAND_BLOCK_SIZE SZ_128K
>
> @@ -556,6 +559,52 @@ static struct omap_musb_board_data musb_board_data = {
> .power = 100,
> };
>
> +static void __init beagle_opp_init(void)
> +{
> + int r = 0;
> +
> + /* Initialize the omap3 opp table */
> + if (omap3_opp_init()) {
> + pr_err("%s: opp default init failed\n", __func__);
> + return;
> + }
> +
> + /* Custom OPP enabled for XM */
> + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
> + struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
> + struct omap_hwmod *dh = omap_hwmod_lookup("iva");
> + struct device *dev;
> +
> + if (!mh || !dh) {
> + pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
> + __func__, mh, dh);
> + return;
> + }
> + /* Enable MPU 1GHz and lower opps */
> + dev = &mh->od->pdev.dev;
> + r = opp_enable(dev, 800000000);
> + /* TODO: MPU 1GHz needs SR and ABB */
> +
> + /* Enable IVA 800MHz and lower opps */
> + dev = &dh->od->pdev.dev;
> + r |= opp_enable(dev, 660000000);
> + /* TODO: DSP 800MHz needs SR and ABB */
> + if (r) {
> + pr_err("%s: failed to enable higher opp %d\n",
> + __func__, r);
> + /*
> + * Cleanup - disable the higher freqs - we dont care
> + * about the results
> + */
> + dev = &mh->od->pdev.dev;
> + opp_disable(dev, 800000000);
> + dev = &dh->od->pdev.dev;
> + opp_disable(dev, 660000000);
> + }
> + }
> + return;
> +}
> +
> static void __init omap3_beagle_init(void)
> {
> omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> @@ -579,6 +628,7 @@ static void __init omap3_beagle_init(void)
> omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
>
> beagle_display_init();
> + beagle_opp_init();
> }
>
> MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
^ permalink raw reply
* [Patch 2/4] hfsplus: Skip cleanup on early mount failures
From: Chuck Ebbert @ 2011-02-01 21:41 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-kernel
In-Reply-To: <20110201162802.2dd07201@katamari>
hfsplus: Skip cleanup on early mount failures
If we don't assign s_fs_info until later we can skip cleanup code
when handling very early failures.
Signed-Off-By: Chuck Ebbert <cebbert@redhat.com>
--- vanilla-2.6.38-rc2-git9.orig/fs/hfsplus/super.c
+++ vanilla-2.6.38-rc2-git9/fs/hfsplus/super.c
@@ -344,14 +344,13 @@ static int hfsplus_fill_super(struct sup
if (!sbi)
return -ENOMEM;
- sb->s_fs_info = sbi;
mutex_init(&sbi->alloc_mutex);
mutex_init(&sbi->vh_mutex);
hfsplus_fill_defaults(sbi);
if (!hfsplus_parse_options(data, sbi)) {
printk(KERN_ERR "hfs: unable to parse mount options\n");
- err = -EINVAL;
- goto cleanup;
+ kfree(sbi);
+ return -EINVAL;
}
/* temporarily use utf8 to correctly find the hidden dir below */
@@ -359,10 +358,12 @@ static int hfsplus_fill_super(struct sup
sbi->nls = load_nls("utf8");
if (!sbi->nls) {
printk(KERN_ERR "hfs: unable to load nls for utf8\n");
- err = -EINVAL;
- goto cleanup;
+ kfree(sbi);
+ return -EINVAL;
}
+ sb->s_fs_info = sbi;
+
/* Grab the volume header */
if (hfsplus_read_wrapper(sb)) {
if (!silent)
^ permalink raw reply
* [Patch 1/4] hfsplus: Don't leak buffer on error
From: Chuck Ebbert @ 2011-02-01 21:41 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-kernel
In-Reply-To: <20110201162802.2dd07201@katamari>
hfsplus: Don't leak buffer on error
Signed-Off-By: Chuck Ebbert <cebbert@redhat.com>
--- vanilla-2.6.38-rc2-git9.orig/fs/hfsplus/part_tbl.c
+++ vanilla-2.6.38-rc2-git9/fs/hfsplus/part_tbl.c
@@ -134,7 +134,7 @@ int hfs_part_find(struct super_block *sb
res = hfsplus_submit_bio(sb->s_bdev, *part_start + HFS_PMAP_BLK,
data, READ);
if (res)
- return res;
+ goto out;
switch (be16_to_cpu(*((__be16 *)data))) {
case HFS_OLD_PMAP_MAGIC:
@@ -147,7 +147,7 @@ int hfs_part_find(struct super_block *sb
res = -ENOENT;
break;
}
-
+out:
kfree(data);
return res;
}
^ permalink raw reply
* [Patch 0/4] Fix error handling in hfsplus mount failure paths
From: Chuck Ebbert @ 2011-02-01 21:28 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-kernel
hfsplus can generate NULL pointer exceptions when a user attempts
to mount an invalid filesystem. In some paths it also leaks memory.
This series attempts to fix some of the most obvious problems.
^ permalink raw reply
* [Patch 3/4] hfsplus: Clear volume header pointers on failure
From: Chuck Ebbert @ 2011-02-01 21:45 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-kernel
In-Reply-To: <20110201162802.2dd07201@katamari>
hfsplus: Clear volume header pointers on failure
The next patch will use NULL volume header to determine whether
to flush the superblock. Also fix two failure cases so they
clear the headers before exiting.
Signed-Off-By: Chuck Ebbert <cebbert@redhat.com>
--- vanilla-2.6.38-rc2-git9.orig/fs/hfsplus/wrapper.c
+++ vanilla-2.6.38-rc2-git9/fs/hfsplus/wrapper.c
@@ -167,7 +167,7 @@ reread:
break;
case cpu_to_be16(HFSP_WRAP_MAGIC):
if (!hfsplus_read_mdb(sbi->s_vhdr, &wd))
- goto out;
+ goto out_free_backup_vhdr;
wd.ablk_size >>= HFSPLUS_SECTOR_SHIFT;
part_start += wd.ablk_start + wd.embed_start * wd.ablk_size;
part_size = wd.embed_count * wd.ablk_size;
@@ -179,7 +179,7 @@ reread:
* (should do this only for cdrom/loop though)
*/
if (hfs_part_find(sb, &part_start, &part_size))
- goto out;
+ goto out_free_backup_vhdr;
goto reread;
}
@@ -230,8 +230,10 @@ reread:
out_free_backup_vhdr:
kfree(sbi->s_backup_vhdr);
+ sbi->s_backup_vhdr = NULL;
out_free_vhdr:
kfree(sbi->s_vhdr);
+ sbi->s_vhdr = NULL;
out:
return error;
}
^ permalink raw reply
* [Patch 4/4] hfsplus: Check for NULL volume header in put_super()
From: Chuck Ebbert @ 2011-02-01 21:56 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-kernel
In-Reply-To: <20110201162802.2dd07201@katamari>
hfsplus: Check for NULL volume header in put_super()
If volume header is null there is not much to do in put_super().
Signed-Off-By: Chuck Ebbert <cebbert@redhat.com>
--- vanilla-2.6.38-rc2-git9.orig/fs/hfsplus/super.c
+++ vanilla-2.6.38-rc2-git9/fs/hfsplus/super.c
@@ -237,7 +237,10 @@ static void hfsplus_put_super(struct sup
if (!sb->s_fs_info)
return;
- if (!(sb->s_flags & MS_RDONLY) && sbi->s_vhdr) {
+ if (!sbi->s_vhdr)
+ goto out_unload_nls;
+
+ if (!(sb->s_flags & MS_RDONLY)) {
struct hfsplus_vh *vhdr = sbi->s_vhdr;
vhdr->modify_date = hfsp_now2mt();
@@ -253,6 +256,7 @@ static void hfsplus_put_super(struct sup
iput(sbi->hidden_dir);
kfree(sbi->s_vhdr);
kfree(sbi->s_backup_vhdr);
+out_unload_nls:
unload_nls(sbi->nls);
kfree(sb->s_fs_info);
sb->s_fs_info = NULL;
^ permalink raw reply
* Re: Early crash (was: Re: module: show version information for built-in modules in sysfs)
From: Geert Uytterhoeven @ 2011-02-01 22:03 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Rusty Russell, linux-kernel@vger.kernel.org, Linux/m68k
In-Reply-To: <20110201210944.GA12348@dtor-ws.eng.vmware.com>
On Tue, Feb 1, 2011 at 22:09, Dmitry Torokhov <dtor@vmware.com> wrote:
> On Tue, Feb 01, 2011 at 12:33:29PM -0800, Geert Uytterhoeven wrote:
>> On Mon, Jan 24, 2011 at 11:59, Linux Kernel Mailing List
>> <linux-kernel@vger.kernel.org> wrote:
>> > Gitweb: http://git.kernel.org/linus/e94965ed5beb23c6fabf7ed31f625e66d7ff28de
>>
>> > module: show version information for built-in modules in sysfs
>> >
>> > Currently only drivers that are built as modules have their versions
>> > shown in /sys/module/<module_name>/version, but this information might
>> > also be useful for built-in drivers as well. This especially important
>> > for drivers that do not define any parameters - such drivers, if
>> > built-in, are completely invisible from userspace.
>> >
>> > This patch changes MODULE_VERSION() macro so that in case when we are
>> > compiling built-in module, version information is stored in a separate
>> > section. Kernel then uses this data to create 'version' sysfs attribute
>> > in the same fashion it creates attributes for module parameters.
>>
>> This commit causes the crash below on m68k (ARAnyM).
>> Reverting this commit and its dependency
>> 3b90a5b292321b2acac3921f77046ae195aef53f
>> ("module: fix linker error for MODULE_VERSION when !MODULE and CONFIG_SYSFS=n")
>> makes it boot again.
>>
>
> Hi Geert,
>
> Does the follwing help by any chance?
>
> From d6fd4a6e0fc2d3f0a74962d4a6f663a46d230ecd Mon Sep 17 00:00:00 2001
> diff --git a/arch/m68knommu/kernel/vmlinux.lds.S b/arch/m68knommu/kernel/vmlinux.lds.S
> index ef33213..47e15eb 100644
> --- a/arch/m68knommu/kernel/vmlinux.lds.S
> +++ b/arch/m68knommu/kernel/vmlinux.lds.S
The crash happened on m68k with MMU, not m68knommu.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: PCI passthrough issue
From: Jean Baptiste Favre @ 2011-02-01 22:04 UTC (permalink / raw)
To: xen-devel
In-Reply-To: <1296577389.13091.288.camel@zakaz.uk.xensource.com>
Le 01/02/2011 17:23, Ian Campbell a écrit :
> On Tue, 2011-02-01 at 15:38 +0000, Jean Baptiste Favre wrote:
>> OK, just found it:
>> after domU boot:
>> - log in
>> - ping -s 86 10.0.0.1 (fails)
>> - rmmod sky2
>> - modprobe sky2 copybreak=0 (no packet copied)
>> - ping -s 86 10.0.0.1 (works)
>>
>> So it's clearly related to that option.
>
> Awesome!
>
>> Now the question: what am I supposed to do ?
>
> I think the next step is to try and reproduce on native 32 bit, with RAM
> artificially limited via the mem= kernel command in option, this will
> let us determine if this is a generic issue or is somehow Xen specific.
OK, so I'll install a 32bits Debian Squeeze with 2.6.37 32bits kernel to
check it.
> The main difference caused by the copybreak option is that for larger
> frames (i.e. always when copybreak==0) it hits a code path which uses
> pci_map_single and pci_map_page to access the received data. When len <
> copybreak it takes a path which uses pci_dma_sync_single_for_cpu, so it
> seems like the later path is broken somehow. If the issue does turn out
> to be related to Xen then I think that points to the swiotlb code.
>
> I assume you are not seeing "rx mapping error" in your domU dmesg? Did
> you post a full guest console log at some point? Comparing the logs for
> the 256MB, 398MB and 512MB guest RAM case might be useful.
No sure I've ever posted that logs. But I can redo my tests :)
> Konrad, is there some way to force swiotlb use even for native to make
> the native test cases more relevant? Or is there some other direction we
> should try first?
>
>> It seems that adding this options in /etc/modprobe.d/sky2.conf does not
>> work, neither using /etc/modules
>
> That will be a userspace issue in your distro, perhaps with openwrt they
> are not expected to work that way.
All tests were done with Debian. As the module is included in initramfs
and not on domU, since I've no kernel installed in the domU, module is
loaded before system FS, so /etc/modprobe.d/sky2.conf is not taken into
account.
I think that the best solution here is to compile kernel with static
sky2 driver inclusion and use kernel commandline to pass sky2 copybreak
option.
Regards,
JB
^ permalink raw reply
* Re: [patch 28/28] posix clocks: Introduce dynamic clocks
From: Thomas Gleixner @ 2011-02-01 22:04 UTC (permalink / raw)
To: john stultz; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <1296596987.3336.83.camel@work-vm>
On Tue, 1 Feb 2011, john stultz wrote:
> On Tue, 2011-02-01 at 13:52 +0000, Thomas Gleixner wrote:
> > plain text document attachment
> > (posix-clocks-introduce-dynamic-clocks.patch)
> > From: Richard Cochran <richardcochran@gmail.com>
> >
> > This patch adds support for adding and removing posix clocks. The
> > clock lifetime cycle is patterned after usb devices. Each clock is
> > represented by a standard character device. In addition, the driver
> > may optionally implement custom character device operations.
> >
> > The posix clock and timer system calls listed below now work with
> > dynamic posix clocks, as well as the traditional static clocks.
> > The following system calls are affected:
> >
> > - clock_adjtime (brand new syscall)
> > - clock_gettime
> > - clock_getres
> > - clock_settime
> > - timer_create
> > - timer_delete
> > - timer_gettime
> > - timer_settime
> >
> > [ tglx: Adapted to the posix-timer cleanup. Moved clock_posix_dynamic
> > to posix-clock.c and made all referenced functions static ]
>
> I sort of worry about the naming collision with the term posix-clock, as
> this is just one type of posix clock (I suspect most folks think of a
> posix clock as the clockid passed to the existing posix api).
Well that's kernel internal and not the posix-timer syscalls.
> Could we maybe use posix-dynclock or posix-fdclock or something? I know
> its already been changed from clkdev, so sorry for being finicky here
> and not catching this earlier.
I'm fine with the name as is and it's well documented.
Thanks,
tglx
^ 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.