* Re: [RFC] arch generic way to trigger unknown NMIs
From: Andi Kleen @ 2010-10-07 16:17 UTC (permalink / raw)
To: Don Zickus
Cc: Andi Kleen, mingo, fweisbec, robert.richter, gorcunov,
linux-kernel
In-Reply-To: <20101007154758.GA22385@redhat.com>
On Thu, Oct 07, 2010 at 11:47:58AM -0400, Don Zickus wrote:
> > > No I prefer a single one too, but there didn't seem to be a
> > > send_IPI_self() command, so I took the short route and sent it to
> > > everyone. :-(
> >
> > You're not sending it to everyone, everyone but you.
> >
> > Anyways for standard APIC send_IPI_cpu should be easy enough
> > to add. Standard NMI is usually to CPU #0 only.
>
> Would that still be x86 specific though? I could probably code that up,
> though I wonder if it would be accepted just for a test case.
The whole APIC interface is x86 specific.
"just a test case" is the wrong perspective.
Testing is important, if a feature is not tested it likely won't
work. That's especially important for anything error handling related.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* [U-Boot] Please pull u-boot-mpc85xx.git
From: Kumar Gala @ 2010-10-07 16:17 UTC (permalink / raw)
To: u-boot
The following changes since commit d6288664743cdd4824cb877ca424619c827c1256:
Merge branch 'master' of git://git.denx.de/u-boot-blackfin (2010-10-05 14:42:32 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-mpc85xx master
Emil Medve (1):
powerpc/corenet_ds: Various updates to initial env cfg
Haiying Wang (3):
mpc8569mds: fix CONFIG_ENV_SIZE
mpc8569mds: fix consuming long time while relocating code.
mpc8569mds: fix some ddr settings
Kim Phillips (1):
powerpc/85xx: fix rev.2 job queue LIODN error storm
Kumar Gala (2):
powerpc/85xx: Add support for 4th PCI controller on corenet_ds
powerpc/p4080: Add new CPC register - HDBCR0
Timur Tabi (3):
p1022ds: add audclk hwconfig setting to enable codec reference clock
fsl: verify writes to the MAC address EEPROM
fsl: add support for NXID v1 EEPROM format
arch/powerpc/cpu/mpc85xx/p4080_ids.c | 14 +++++--
arch/powerpc/include/asm/immap_85xx.h | 5 ++-
board/freescale/common/sys_eeprom.c | 44 ++++++++++++++++-----
board/freescale/corenet_ds/pci.c | 28 ++++++++++++-
board/freescale/mpc8569mds/ddr.c | 16 ++++++-
board/freescale/mpc8569mds/mpc8569mds.c | 26 ++++++++++++
board/freescale/mpc8569mds/tlb.c | 15 +++++--
board/freescale/p1022ds/p1022ds.c | 67 ++++++++++++++++++++++++++----
doc/README.fsl-hwconfig | 21 ++++++++++
include/configs/MPC8569MDS.h | 7 ++-
include/configs/P1022DS.h | 1 +
include/configs/corenet_ds.h | 23 ++++++++---
12 files changed, 225 insertions(+), 42 deletions(-)
create mode 100644 doc/README.fsl-hwconfig
^ permalink raw reply
* Re: Ceph, make (22nd-sept unstable) fails, and slow write issues.
From: Gregory Farnum @ 2010-10-07 16:17 UTC (permalink / raw)
To: DongJin Lee; +Cc: Sage Weil, ceph-devel
In-Reply-To: <AANLkTi=7DqSVaBp=dQgcH_B384QGP3vgdXUtGD=t5r6J@mail.gmail.com>
On Thu, Oct 7, 2010 at 3:48 AM, DongJin Lee <dongjin.lee@auckland.ac.nz> wrote:
>> Hmmm -- it looks like the scripts are split on whether you have
>> tcmalloc installed in your system, and I don't see any obvious issues
>> when I go over them. Do you have tcmalloc installed? Did you try a
>> "make clean; make" cycle?
>
> Sadly, I still get the error in some of other PCs.
> cosd.cc: In function ‘int main(int, const char**)’:
> cosd.cc:65: error: ‘IsHeapProfilerRunning’ was not declared in this scope
> cosd.cc:310: warning: ignoring return value of ‘int chdir(const
> char*)’, declared with attribute warn_unused_result
> make[2]: *** [cosd-cosd.o] Error 1
Hmmm. I just noticed that IsHeapProfilerRunning is actually the second
tcmalloc profiler function to get referenced in that #if block. Can
you comment out just that one line and let me know if that lets it
compile?
IsHeapProfilerRunning has been in the profiler since 2008, but the
prototype changed this year to return an int instead of a bool, so
maybe your installed libraries and header don't match?
-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] infiniband: uverbs: limit the number of entries
From: Jason Gunthorpe @ 2010-10-07 16:16 UTC (permalink / raw)
To: Dan Carpenter
Cc: Roland Dreier, Sean Hefty, Hal Rosenstock,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101007071610.GC11681@bicker>
On Thu, Oct 07, 2010 at 09:16:10AM +0200, Dan Carpenter wrote:
> If we don't limit cmd.ne then the multiplications can overflow. This
> will allocate a small amount of RAM successfully for the "resp" and
> "wc" buffers. The heap will get corrupted when we call ib_poll_cq().
I think you could cap the number of returned entries to
UVERBS_MAX_NUM_ENTRIES rather than return EINVAL. That might be more
compatible with user space..
Jason
--
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
* Re: [patch] infiniband: uverbs: limit the number of entries
From: Jason Gunthorpe @ 2010-10-07 16:16 UTC (permalink / raw)
To: Dan Carpenter
Cc: Roland Dreier, Sean Hefty, Hal Rosenstock,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101007071610.GC11681@bicker>
On Thu, Oct 07, 2010 at 09:16:10AM +0200, Dan Carpenter wrote:
> If we don't limit cmd.ne then the multiplications can overflow. This
> will allocate a small amount of RAM successfully for the "resp" and
> "wc" buffers. The heap will get corrupted when we call ib_poll_cq().
I think you could cap the number of returned entries to
UVERBS_MAX_NUM_ENTRIES rather than return EINVAL. That might be more
compatible with user space..
Jason
^ permalink raw reply
* Re: Aranym, more than 244MB FastRAM, garbled display
From: Petr Stehlik @ 2010-10-07 13:11 UTC (permalink / raw)
To: Michael Schmitz; +Cc: linux-m68k
In-Reply-To: <AANLkTi=ZrDoFPxFNZ3OKurvcrBuN3fS0gTvAeYpLQqCi@mail.gmail.com>
Michael Schmitz píše v Thu 07. 10. 2010 v 09:47 +0200:
> >>> Args = root=/dev/hda1 console=tty debug=par video=atafb:vga2
> >
> >>The problem starts happening as soon as FastRAM >= 512.
> >
> > I suspect atafb:vga2 reduces the amount of memory needed enough
> > for it to work.
>
> Certainly - 640x480@1bit isn't much. Even less than sthigh IIRC.
sthigh is 640x400@1bit, I believe, i.e. even less than vga2.
> I wonder why it does depend on FastRAM size, though. ST-RAM eaten up
> by page tables?
why anything is stored in ST-RAM? Besides there's 14 MB of ST-RAM on
ARAnyM, that should be plenty (compare with Falcon's 4 MB).
Petr
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network interface
From: Stephen Hemminger @ 2010-10-07 16:14 UTC (permalink / raw)
To: Narendra_K
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Jordan_Hargrave,
Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007142319.GB2641@libnet-test.oslab.blr.amer.dell.com>
On Thu, 7 Oct 2010 07:23:35 -0700
<Narendra_K@Dell.com> wrote:
> Hello,
>
> V1 -> V2:
>
> This patch addresses the scenario of buggy firmware/BIOS tables. The
> patch introduces a command line parameter 'no_netfwindex', passing which
> firmware provided index will not be used to derive 'eth' names. By
> default, firmware index will be used and the parameter can be used to
> work around buggy firmware/BIOS tables.
>
> Please find the patch below.
>
> From: Narendra K <narendra_k@dell.com>
> Subject: [PATCH] Use firmware provided index to register a network device
>
> This patch uses the firmware provided index to derive the ethN name.
> If the firmware provides an index for the corresponding pdev, the N
> is derived from the index.
>
> As an example, consider a PowerEdge R710 which has 4 BCM5709
> Lan-On-Motherboard ports,1 Intel 82572EI port and 4 82575GB ports.
> The system firmware communicates the order of the 4 Lan-On-Motherboard
> ports by assigning indexes to each one of them. This is available to
> the OS as the SMBIOS type 41 record(for onboard devices), in the field
> 'device type index'. It looks like below -
I agree with Greg. Provide the firmware index in sysfs for use
in udev userspace and let udev do the policy on the naming.
The firmware index could be missing, wrong, or interesting on only
some devices.
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network
From: Stephen Hemminger @ 2010-10-07 16:14 UTC (permalink / raw)
To: Narendra_K
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Jordan_Hargrave,
Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007142319.GB2641@libnet-test.oslab.blr.amer.dell.com>
On Thu, 7 Oct 2010 07:23:35 -0700
<Narendra_K@Dell.com> wrote:
> Hello,
>
> V1 -> V2:
>
> This patch addresses the scenario of buggy firmware/BIOS tables. The
> patch introduces a command line parameter 'no_netfwindex', passing which
> firmware provided index will not be used to derive 'eth' names. By
> default, firmware index will be used and the parameter can be used to
> work around buggy firmware/BIOS tables.
>
> Please find the patch below.
>
> From: Narendra K <narendra_k@dell.com>
> Subject: [PATCH] Use firmware provided index to register a network device
>
> This patch uses the firmware provided index to derive the ethN name.
> If the firmware provides an index for the corresponding pdev, the N
> is derived from the index.
>
> As an example, consider a PowerEdge R710 which has 4 BCM5709
> Lan-On-Motherboard ports,1 Intel 82572EI port and 4 82575GB ports.
> The system firmware communicates the order of the 4 Lan-On-Motherboard
> ports by assigning indexes to each one of them. This is available to
> the OS as the SMBIOS type 41 record(for onboard devices), in the field
> 'device type index'. It looks like below -
I agree with Greg. Provide the firmware index in sysfs for use
in udev userspace and let udev do the policy on the naming.
The firmware index could be missing, wrong, or interesting on only
some devices.
^ permalink raw reply
* [U-Boot] [PATCH v2 0/6] Add ARM flat device tree support
From: John Rigby @ 2010-10-07 16:14 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AANLkTi=pWR=UnByG0gGiqA4dK++5HA5XQCQo8Cfn9XUK@mail.gmail.com>
On Thu, Oct 7, 2010 at 10:11 AM, John Rigby <john.rigby@linaro.org> wrote:
> There have been no NACK's to this and one Tested-by, so can this
> series go into 2010.12?
>
> Thanks,
> John
>
Apologies in advance for the top post.
^ permalink raw reply
* [U-Boot] U-boot debug with BDI3000
From: Andreas Bießmann @ 2010-10-07 16:14 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20101007074924.0693828089@theia.denx.de>
Dear sywang,
Am 07.10.2010 um 09:49 schrieb sywang:
> Hi,
>
> Does anyone have a working BDI2000/3000 configuration for CN5010 dev.board?
Yes I have one, but not on-hand currently. Will have a look for it tomorrow or on monday.
> I need it to have DDR and NOR flash support so that I can flash a new
> bootloader into NOR.
AFAIR it is enough to setup bootbus for correct sizes. TLB is not necessary to get access to NOR cause this is already setup by reset. It is not as fast as it could be but you have at least access to NOR and erase/prog works.
regards
Andreas Bie?mann
^ permalink raw reply
* Re: Context settings after ssh login
From: Daniel J Walsh @ 2010-10-07 16:11 UTC (permalink / raw)
To: Chad Sellers; +Cc: imsand, Justin P. Mattock, selinux
In-Reply-To: <C8D3542D.BAC90%csellers@tresys.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/07/2010 10:40 AM, Chad Sellers wrote:
> On 10/6/10 3:29 AM, "imsand@puzzle.ch" <imsand@puzzle.ch> wrote:
>
>>> On 10/05/2010 11:43 PM, imsand@puzzle.ch wrote:
>>>>> On 10/05/2010 06:38 AM, imsand@puzzle.ch wrote:
>>>>>>> On 10/04/2010 11:30 PM, imsand@puzzle.ch wrote:
>>>>>>>>> On 10/04/2010 01:03 AM, imsand@puzzle.ch wrote:
>>>>>>>>>> Hello
>>>>>>>>>>
>>>>>>>>>> I'm working on SUSE SLES11SP1 and encounter the following problem.
>>>>>>>>>> Setting the context of the User after ssh login doesn't work if
>>>>>>>>>> the
>>>>>>>>>> SELinux Username and the Linux Username aren't identical.
>>>>>>>>>>
>>>>>>>>>> --------------
>>>>>>>>>> Here is an example (SElinux User=mat_u, Linux User=mat_u):
>>>>>>>>>> Oct 4 09:41:54 testsrv.example sshd[15829]: Accepted
>>>>>>>>>> keyboard-interactive/pam for mat_u from 131.102.233.125 port 54714
>>>>>>>>>> ssh2
>>>>>>>>>> Oct 4 09:41:54 testsrv.example sshd[15829]:
>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>> Open Session
>>>>>>>>>> Oct 4 09:41:54 testsrv.example sshd[15829]:
>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>> Open Session
>>>>>>>>>> Oct 4 09:41:54 testsrv.example sshd[15829]:
>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>> Username= mat_u SELinux User = user_u Level= (null)
>>>>>>>>>> Oct 4 09:41:54 testsrv.example sshd[15829]:
>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>> set mat_u security context to user_u:user_r:user_t
>>>>>>>>>> Oct 4 09:41:54 testsrv.example sshd[15829]:
>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>> set mat_u key creation context to user_u:user_r:user_t
>>>>>>>>>> ---
>>>>>>>>>> mat_u@testsrv.example:~> id
>>>>>>>>>> uid=6575(mat_u) gid=100(users)
>>>>>>>>>> groups=16(dialout),33(video),100(users)
>>>>>>>>>> context=mat_u:staff_r:staff_t
>>>>>>>>>> mat_u@testsrv.example:~> newrole -r sysadm_r
>>>>>>>>>> mat_u@testsrv.example:~> id
>>>>>>>>>> uid=6575(mat_u) gid=100(users)
>>>>>>>>>> groups=16(dialout),33(video),100(users)
>>>>>>>>>> context=mat_u:sysadm_r:sysadm_t
>>>>>>>>>> --------------------
>>>>>>>>>>
>>>>>>>>>> So, this is okey. The user's context after login is
>>>>>>>>>> "mat_u:staff_r:staff_t"
>>>>>>>>>>
>>>>>>>>>> But, if the Linux User is different from the SELinux User, the
>>>>>>>>>> default
>>>>>>>>>> user's will be chosen instead.
>>>>>>>>>>
>>>>>>>>>> Here is the example (SELinux User=mat_u, Linux User=mat):
>>>>>>>>>> ---------------------
>>>>>>>>>> Oct 4 09:46:22 testsrv.example sshd[16185]: Accepted
>>>>>>>>>> keyboard-interactive/pam for mat from 131.102.233.125 port 54726
>>>>>>>>>> ssh2
>>>>>>>>>> Oct 4 09:46:22 testsrv.example sshd[16185]:
>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>> Open Session
>>>>>>>>>> Oct 4 09:46:22 testsrv.example sshd[16185]:
>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>> Open Session
>>>>>>>>>> Oct 4 09:46:22 testsrv.example sshd[16185]:
>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>> Username= mat SELinux User = mat_u Level= (null)
>>>>>>>>>> Oct 4 09:46:22 testsrv.example sshd[16185]:
>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>> set mat security context to mat_u:staff_r:staff_t
>>>>>>>>>> Oct 4 09:46:22 testsrv.example sshd[16185]:
>>>>>>>>>> pam_selinux(sshd:session):
>>>>>>>>>> set mat key creation context to mat_u:staff_r:staff_t
>>>>>>>>>> ---
>>>>>>>>>> mat_u@testsrv.example:~> id
>>>>>>>>>> uid=6575(mat) gid=100(users)
>>>>>>>>>> groups=16(dialout),33(video),100(users)
>>>>>>>>>> context=user_u:user_r:user_t
>>>>>>>>>>
>>>>>>>>>> mat_u@testsrv.example:~> newrole -r sysadm_r
>>>>>>>>>> user_u:sysadm_r:sysadm_t is not a valid context
>>>>>>>>>> ---------------------
>>>>>>>>>>
>>>>>>>>>> As you can see, the pam_selinux module recognizes that the new
>>>>>>>>>> context
>>>>>>>>>> should be "mat_u:staff_r:staff_t", but for some reason the real
>>>>>>>>>> context
>>>>>>>>>> is
>>>>>>>>>> user_u:user_r:user_t. Changing the context with newrole doesn't
>>>>>>>>>> work
>>>>>>>>>> either...
>>>>>>>>>>
>>>>>>>>>> The user mappings should be okey:
>>>>>>>>>> ------
>>>>>>>>>> semanage user -l | grep mat
>>>>>>>>>> mat_u staff_r sysadm_r
>>>>>>>>>> testsrv.example:~ # semanage login -l | grep mat
>>>>>>>>>> mat
>>>>>>>>>> -------
>>>>>>>>>>
>>>>>>>>>> Any idea out there? Do I miss something?
>>>>>>>>>> kind regards
>>>>>>>>>> Matthias
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> This message was distributed to subscribers of the selinux mailing
>>>>>>>>>> list.
>>>>>>>>>> If you no longer wish to subscribe, send mail to
>>>>>>>>>> majordomo@tycho.nsa.gov
>>>>>>>>>> with
>>>>>>>>>> the words "unsubscribe selinux" without quotes as the message.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> you can specify the context in
>>>>>>>>> /etc/selinux/policy/contexts/users/whatroleyouused
>>>>>>>>> (under sshd) I normally set user_r:user_t:s0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Justin P. Mattock
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> This message was distributed to subscribers of the selinux mailing
>>>>>>>>> list.
>>>>>>>>> If you no longer wish to subscribe, send mail to
>>>>>>>>> majordomo@tycho.nsa.gov
>>>>>>>>> with
>>>>>>>>> the words "unsubscribe selinux" without quotes as the message.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The file looks like:
>>>>>>>> cat /etc/selinux/refpolicy/contexts/users/mat_u
>>>>>>>> system_r:local_login_t staff_r:staff_t sysadm_r:sysadm_t
>>>>>>>> system_r:remote_login_t staff_r:staff_t
>>>>>>>> system_r:sshd_t staff_r:staff_t sysadm_r:sysadm_t
>>>>>>>> system_r:crond_t staff_r:cronjob_t
>>>>>>>> system_r:xdm_t staff_r:staff_t
>>>>>>>> staff_r:staff_su_t staff_r:staff_t
>>>>>>>> staff_r:staff_sudo_t staff_r:staff_t
>>>>>>>> sysadm_r:sysadm_su_t sysadm_r:sysadm_t
>>>>>>>> sysadm_r:sysadm_sudo_t sysadm_r:sysadm_t
>>>>>>>>
>>>>>>>> So, theoretical this should be okey, isn't it?
>>>>>>>> And as you can see in the log from above (set mat key creation
>>>>>>>> context
>>>>>>>> to
>>>>>>>> mat_u:staff_r:staff_t) it "tries" to switch to staff but for some
>>>>>>>> reason
>>>>>>>> it doesn't work..
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> if your sshd'ing and the context is staff_r:staff_t then it's
>>>>>>> correct,
>>>>>>> I
>>>>>>> usually change this to user_r:user_t just cause I'm paranoid.
>>>>>>> Also there is some options that you can set in /etc/pam.d to do other
>>>>>>> checks etc..
>>>>>>>
>>>>>>> Justin P. Mattock
>>>>>>>
>>>>>> no it's not and that't the problem:)
>>>>>> If I sshd'ing with mat_u it's always "user_r:user_t" even
>>>>>> "staff_r:staff_t" is specified (see above). But it's correct if the
>>>>>> selinux and linux users are named equaly (mat in the example).
>>>>>> It seems that something with the context settings and usermapping
>>>>>> isn't
>>>>>> correct. Do you see the problem?
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> Somewhere in the policy it is set to default to user_r for sshd, I dont
>>>>> think there is a boolean(but could be wrong)for that feature. maybe
>>>>> it's
>>>>> reading the default_contexts file which is set to use user_r:user_t
>>>>> instead of reading mat_u for sshd(staff_r:staff_t)
>>>>>
>>>>> Justin P. Mattock
>>>>>
>>>>>
>>>> Unfortunately I can't see a rule doing this. The curious thing is, that
>>>> it
>>>> works if the selinux user and the linux user are equivalent (both
>>>> mat_u).
>>>> But it does NOT work if it is mat (linux user) and mapped to mat_u
>>>> (selinux user).
>>>>
>>>>
>>>
>>>
>>> hmm.. something seems configured wrong, what OS are you using? do you
>>> have semanage login/user -l set up correctly?
>>>
>>> over here I build the policy from git, normally edit policy/users (add)
>>> gen_user(name,system_u, sysadm_r staff_r user_r, s0, s0 -
>>> mls_systemhigh, mcs_allcats)
>>>
>>> then after the policy is built and installed/loaded I do
>>> semanage login -a -s name name (create name in contexts/users)
>>> (or skip the above and just use semanage -a -s user_u name)
>>>
>>> seems sshd works with the given context I specify(user_r) then if I want
>>> to add more options I adjust /etc/pam.d/*
>>>
>>> Justin P. Mattock
>>>
>> Thanks for your reply.
>> I'm using SLES 11 SP1. It wouldn't be the first bug regarding SELinux on
>> this distro... ;)
>> Here is what I've done so far.
>> - Downloaded the latest reference policy from tresys
>> - Compiled and installed it on my sles 11.1
>> - Add selinux user mat_u: "semanage user -R "staff_r system_r" -P user -a
>> mat_u"
>> - Add linux user mat: "useradd mat"
>> - Set password for mat: "passwd mat"
>> - User mapping: "semanage login -s mat_u -a mat"
>> - add security context for mat_u by copying staff_u's context
>> "cp /etc/selinux/refpolicy/contexts/user/staff_u
>> /etc/selinux/refpolicy/contexts/user/mat_u"
>> - set boolean for sysadm ssh login to true: "setsebool -P ssh_sysadm_login
>> on"
>>
>> Do you know good debug options for tracing where it stucks?
>>
> When debugging login-type programs figuring out the context to transition
> to, there are a couple of simple useful utilities in libselinux/utils. These
> are getconlist and getdefaultcon. Most distros won't install these (as
> they're just debugging tools), but you can build them yourself out of the
> tree.
>
> getconlist will print out the contexts returned by
> get_ordered_context_list(), which are all the reachable contexts. This could
> tell you if the problem is that the context you're trying to transition to
> is for some reason unreachable.
>
> getdefaultcon can tell you (in verbose mode) the default seuser and level
> returned by getseuserbyname() and the default context returned by
> get_default_context_with_rolelevel()/get_default_context_with_level(). If
> the seuser is wrong, then you know something's going wrong in
> getseuserbyname().
>
> I hope that helps.
>
> Thanks,
> Chad Sellers
>
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>
>
We ship them in fedora as selinuxconlist and selinuxdefcon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkyt8UkACgkQrlYvE4MpobPw+wCfa8sf3A8+xhnMmdz2z3/vuJOM
TYsAn1s18NmE9caf5MpCt312RO2Wh/BI
=N+E/
-----END PGP SIGNATURE-----
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* [U-Boot] [PATCH v2 0/6] Add ARM flat device tree support
From: John Rigby @ 2010-10-07 16:11 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1285775292-15060-1-git-send-email-john.rigby@linaro.org>
There have been no NACK's to this and one Tested-by, so can this
series go into 2010.12?
Thanks,
John
On Wed, Sep 29, 2010 at 9:48 AM, John Rigby <john.rigby@linaro.org> wrote:
> This is the third submission of this patch series. ?The first
> was an RFC and I received lots of comments that I addressed
> in the second for which I got no feedback.
>
> This version fixes some issues I found in testing on a hacked
> Beagle kernel with enough device tree functionality to verify
> that u-boot is able to pass a device tree.
>
> Patch summary:
> ?1-4 are fixes/clean up to existing code
> ?3 needs testing on nios and microblaze
> ?5 actually adds the ARM FDT support
> ?6 enables FDT support for omap3_beagle
>
> John Rigby (6):
> ?fdt_relocate: fix fdt size and endian bugs
> ?FDT: Add fixup support for multiple banks of memory
> ?FDT: only call boot_get_fdt from generic code
> ?boot: change some arch ifdefs to feature ifdefs
> ?ARM: add flat device tree support
> ?ARM: enable device tree for beagle
>
> ?arch/arm/include/asm/config.h ? ? | ? ?2 +
> ?arch/arm/lib/bootm.c ? ? ? ? ? ? ?| ?137 ++++++++++++++++++++++++++++++++----
> ?arch/m68k/include/asm/config.h ? ?| ? ?3 +
> ?arch/microblaze/lib/bootm.c ? ? ? | ? 12 +---
> ?arch/nios2/lib/bootm.c ? ? ? ? ? ?| ? ?8 +--
> ?arch/powerpc/include/asm/config.h | ? ?3 +
> ?arch/sparc/include/asm/config.h ? | ? ?1 +
> ?common/cmd_bootm.c ? ? ? ? ? ? ? ?| ? ?4 +-
> ?common/fdt_support.c ? ? ? ? ? ? ?| ? 86 ++++++++++++-----------
> ?common/image.c ? ? ? ? ? ? ? ? ? ?| ? 18 +++--
> ?include/configs/omap3_beagle.h ? ?| ? ?9 +++
> ?include/fdt_support.h ? ? ? ? ? ? | ? ?1 +
> ?include/image.h ? ? ? ? ? ? ? ? ? | ? ?9 ++-
> ?13 files changed, 210 insertions(+), 83 deletions(-)
>
>
^ permalink raw reply
* Re: PATCH [0/4] perf: clean-up of power events API
From: Pierre Tardy @ 2010-10-07 16:10 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Mathieu Desnoyers, Thomas Renninger, Jean Pihet,
linux-trace-users, linux-pm, linux-perf-users, mingo, arjan, rjw,
linux-omap, Peter Zijlstra, Kevin Hilman, Steven Rostedt,
Frank Eigler, Masami Hiramatsu, Thomas Gleixner, Andrew Morton,
Linus Torvalds, Tejun Heo
In-Reply-To: <20101007155816.GA5351@nowhere>
> I did told you that it would be better you make PyTimeChart use the perf
> scripting facilities, it handles all the above things + it would
> avoid you to handle a lot of things.
Actually, perf scripting facility is already supported by pytimechart
but does not make it that easier to maintain.
event name changes => must update, event fields added/removed => must update
>
> Now it's up to you, but don't count on us to make the ascii formatting
> a stable ABI.
I'm not against adding 1 line in pytimechart each time there is some
change in ascii formatting
>
>
>> actually, over all the events pytimechart supports, only power traces
>> are stable...
>
>
> Now one problem is that we have really broken the workqueue tracepoints
> in this release. I thought nobody was using them so we could
> refactor this tracepoint subsystem, my bad.
No problem. I'll update pytimechart whenever someone sends me traces
that does not work (I'm okay with pre 2.6.31 traces too...)
Regards,
Pierre
^ permalink raw reply
* Re: PATCH [0/4] perf: clean-up of power events API
From: Pierre Tardy @ 2010-10-07 16:10 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Thomas Gleixner, Andrew Morton, Peter Zijlstra, Linus Torvalds,
mingo, Jean Pihet, Steven Rostedt, linux-perf-users,
linux-trace-users, Frank Eigler, Mathieu Desnoyers,
Masami Hiramatsu, Tejun Heo, linux-pm, linux-omap, arjan
In-Reply-To: <20101007155816.GA5351@nowhere>
> I did told you that it would be better you make PyTimeChart use the perf
> scripting facilities, it handles all the above things + it would
> avoid you to handle a lot of things.
Actually, perf scripting facility is already supported by pytimechart
but does not make it that easier to maintain.
event name changes => must update, event fields added/removed => must update
>
> Now it's up to you, but don't count on us to make the ascii formatting
> a stable ABI.
I'm not against adding 1 line in pytimechart each time there is some
change in ascii formatting
>
>
>> actually, over all the events pytimechart supports, only power traces
>> are stable...
>
>
> Now one problem is that we have really broken the workqueue tracepoints
> in this release. I thought nobody was using them so we could
> refactor this tracepoint subsystem, my bad.
No problem. I'll update pytimechart whenever someone sends me traces
that does not work (I'm okay with pre 2.6.31 traces too...)
Regards,
Pierre
^ permalink raw reply
* Re: Linux 2.6.36-rc7
From: Tvrtko Ursulin @ 2010-10-07 16:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
In-Reply-To: <AANLkTi=LsBNU+O2hqZUcM2nYM_ze6qPq3thwSZBMtY_v@mail.gmail.com>
On Wednesday 06 Oct 2010 22:45:13 Linus Torvalds wrote:
[snip]
> And yes, that's probably as exciting as it gets, which is just fine by
> me. This should be the last -rc, I'm not seeing any reason to keep
> delaying a real release. There was still more changes to
> drivers/gpu/drm than I really would have hoped for, but they all look
> harmless and good. Famous last words.
Hi Linus,
Please see http://marc.info/?l=linux-kernel&m=128618485204253&w=2
I have sent this proposed bugfix several times now but no one is picking it up
and Eric seems to have disappeared. It would be suboptimal to release 2.6.36
with a core fanotify feature non-functional.
Thanks,
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
^ permalink raw reply
* Re: [doesn't work] JFFS2: Dynamically choose inocache hash size
From: Daniel Drake @ 2010-10-07 16:09 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linux-mtd
In-Reply-To: <OFB9367F81.DD135AF9-ONC12577B5.00550D41-C12577B5.00557990@transmode.se>
On 7 October 2010 16:33, Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> Does #define INOCACHE_HASHSIZE <something bigger> work?
Yes. Tested for years as value 1024 in OLPC builds.
> if so I would guess something is using inocache_hashsize before
> it is initialized.
Me too. But it's initialized early, at the same time as inocache_list.
And all users of inocache_hashsize use the list at the same time. So
if that were as obvious as it sounds, we'd be seeing bigger problems.
Thanks for your input!
Daniel
^ permalink raw reply
* Re: [PATCH 5/7] Add MCI card support to barebox
From: Juergen Beisert @ 2010-10-07 16:00 UTC (permalink / raw)
To: barebox
In-Reply-To: <20101007153713.GH28242@pengutronix.de>
Sascha Hauer wrote:
> On Thu, Oct 07, 2010 at 03:24:16PM +0200, Juergen Beisert wrote:
> > This adds the basic framework to handle MCI cards in barebox.
> >
> > Signed-off-by: Juergen Beisert <jbe@pengutronix.de>
> > ---
> > drivers/Kconfig | 1 +
> > drivers/Makefile | 1 +
> > drivers/mci/Kconfig | 30 ++
> > drivers/mci/Makefile | 1 +
> > drivers/mci/mci-core.c | 1308
> > ++++++++++++++++++++++++++++++++++++++++++++++++ include/mci.h |
> > 230 +++++++++
> > 6 files changed, 1571 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/mci/Kconfig
> > create mode 100644 drivers/mci/Makefile
> > create mode 100644 drivers/mci/mci-core.c
> > create mode 100644 include/mci.h
>
> This whole patch looks quite good.
> Please add some linebreaks in mci-core.c. I don't want strict 80
> character lines, but some lines are really long.
>
> [snip]
>
> > +static int mci_probe(struct device_d *mci_dev)
> > +{
> > + struct mci *mci;
> > + int rc;
> > +
> > + mci = xzalloc(sizeof(struct mci));
> > + mci_dev->priv = mci;
> > +
> > +#ifdef CONFIG_MCI_STARTUP
> > + /* if enabled, probe the attached card immediately */
> > + rc = mci_card_probe(mci_dev);
> > + if (rc == -ENODEV) {
> > + /*
> > + * If it fails, add the 'probe' parameter to give the user
> > + * a chance to insert a card and try again. Note: This may fail
> > + * systems that rely on the MCI card for startup (for the
> > + * persistant environment for example)
> > + */
> > + rc = add_mci_parameter(mci_dev);
> > + if (rc != 0) {
> > + pr_err("Failed to add 'probe' parameter to the MCI device\n");
> > + goto on_error;
> > + }
> > + }
> > +#endif
> > +
> > +#ifndef CONFIG_MCI_STARTUP
>
> #else instead?
>
> > + /* add params on demand */
> > + rc = add_mci_parameter(mci_dev);
> > + if (rc != 0) {
> > + pr_err("Failed to add 'probe' parameter to the MCI device\n");
> > + goto on_error;
> > + }
> > +#endif
> > +
> > + return rc;
> > +
> > +on_error:
> > + free(mci);
> > + return rc;
> > +}
> > +
>
> [snip]
>
> > +
> > +/** host information */
> > +struct mci_platformdata {
> > + struct device_d *hw_dev; /**< the host MCI hardware device */
> > + unsigned voltages;
> > + unsigned host_caps; /**< Host's interface capabilities, refer MMC_VDD_*
> > and FIXME */ + unsigned f_min; /**< host interface lower limit */
> > + unsigned f_max; /**< host interface upper limit */
> > + unsigned clock; /**< Current clock used to talk to the card */
> > + unsigned bus_width; /**< used data bus width to the card */
> > +
> > + int (*init)(struct device_d*, struct device_d*); /**< init the host
> > interface */ + void (*set_ios)(struct device_d*, struct device_d*,
> > unsigned, unsigned); /**< change host interface settings */ + int
> > (*send_cmd)(struct device_d*, struct mci_cmd*, struct mci_data*); /**<
> > handle a command */ +};
>
> I prefer this struct named mci_host, this seems to match better what it
> actually is.
Hmm, no, its not a "host". It is the MMC/SD card instance. The host is more
the interface, isn't it (at least for me)?
> For the convenience of drivers set init/set_ios/send_cmd
> functions should be passed a pointer to the mci_host, not the device,
> because that's what they actually registered. I already prepared a patch
> for this, I'll send it in a seperate mail.
I tried to layering the devices:
disk_device -> knows how to handle disk drives and partition tables
|
mci_device -> knows how to probe and manage MMC/SD cards
|
hw_device -> knows how to transfer data
Most functions in the hw_device layer do not need access to any other
structure data than their own device (okay, there is a exception). So, I
tried to keep it simple.
jbe
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | Phone: +49-8766-939 228 |
Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [Qemu-devel] Re: [PATCH 5/6] Switch migrate_set_speed() to take an 'o' argument rather than a float.
From: Paolo Bonzini @ 2010-10-07 16:03 UTC (permalink / raw)
To: Jes.Sorensen; +Cc: qemu-devel, armbru
In-Reply-To: <1286463710-28262-6-git-send-email-Jes.Sorensen@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 926 bytes --]
On 10/07/2010 05:01 PM, Jes.Sorensen@redhat.com wrote:
> From: Jes Sorensen<Jes.Sorensen@redhat.com>
>
> Signed-off-by: Jes Sorensen<Jes.Sorensen@redhat.com>
> ---
> hmp-commands.hx | 2 +-
> migration.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index 81999aa..95bdb91 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -754,7 +754,7 @@ ETEXI
>
> {
> .name = "migrate_set_speed",
> - .args_type = "value:f",
> + .args_type = "value:o",
> .params = "value",
> .help = "set maximum speed (in bytes) for migrations",
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Is this still accurate?
Alternatively, you said it's a mess to distinguish the defaults on the
command line and the monitor, but is it harder than the attached patch?
Paolo
[-- Attachment #2: strtosz.patch --]
[-- Type: text/plain, Size: 2960 bytes --]
diff --git a/cutils.c b/cutils.c
index 012eb11..4a9ce0f 100644
--- a/cutils.c
+++ b/cutils.c
@@ -289,13 +289,13 @@ int fcntl_setfl(int fd, int flag)
* End pointer will be returned in *end, if end is valid.
* Return -1 on error.
*/
-ssize_t strtosz(const char *nptr, char **end)
+ssize_t strtosz(const char *nptr, char **end, int default_shift)
{
ssize_t retval = -1;
- int64_t tmpval;
+ int64_t tmpval, mul;
char *endptr;
int mul_required = 0;
- double val, mul = 1;
+ double val;
endptr = (char *)nptr + strspn(nptr, " 0123456789");
if (*endptr == '.') {
@@ -308,15 +308,14 @@ ssize_t strtosz(const char *nptr, char **end)
goto fail;
switch (*endptr++) {
+ case 0:
+ case ' ':
+ mul = (1ULL << default_shift);
+ break;
case 'K':
case 'k':
mul = 1 << 10;
break;
- case 0:
- case ' ':
- if (mul_required) {
- goto fail;
- }
case 'M':
case 'm':
mul = 1ULL << 20;
@@ -333,6 +332,9 @@ ssize_t strtosz(const char *nptr, char **end)
goto fail;
}
+ if (mul == 1 && mul_required) {
+ goto fail;
+ }
tmpval = (val * mul);
if (tmpval > ~(size_t)0)
goto fail;
diff --git a/monitor.c b/monitor.c
index 6678fb5..0d04b27 100644
--- a/monitor.c
+++ b/monitor.c
@@ -3713,7 +3713,7 @@ static const mon_cmd_t *monitor_parse_command(Monitor *mon,
break;
}
}
- val = strtosz(p, &end);
+ val = strtosz(p, &end, 0);
if (val < 0) {
monitor_printf(mon, "invalid size\n");
goto fail;
diff --git a/qemu-common.h b/qemu-common.h
index 0a062d4..cabd8f8 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -153,7 +153,7 @@ time_t mktimegm(struct tm *tm);
int qemu_fls(int i);
int qemu_fdatasync(int fd);
int fcntl_setfl(int fd, int flag);
-ssize_t strtosz(const char *nptr, char **end);
+ssize_t strtosz(const char *nptr, char **end, int default_shift);
/* path.c */
void init_paths(const char *prefix);
diff --git a/vl.c b/vl.c
index 6043fa2..ae4d6f3 100644
--- a/vl.c
+++ b/vl.c
@@ -735,7 +735,7 @@ static void numa_add(const char *optarg)
node_mem[nodenr] = 0;
} else {
ssize_t sval;
- sval = strtosz(option, NULL);
+ sval = strtosz(option, NULL, 20);
if (sval < 0) {
fprintf(stderr, "qemu: invalid numa mem size: %s\n", optarg);
exit(1);
@@ -2162,7 +2162,7 @@ int main(int argc, char **argv, char **envp)
case QEMU_OPTION_m: {
ssize_t value;
- value = strtosz(optarg, NULL);
+ value = strtosz(optarg, NULL, 20);
if (value < 0) {
fprintf(stderr, "qemu: invalid ram size: %s\n", optarg);
exit(1);
^ permalink raw reply related
* Re: [PATCH v6 04/12] Add memory slot versioning and use it to provide fast guest write interface
From: Gleb Natapov @ 2010-10-07 16:03 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: Avi Kivity, Gleb Natapov, kvm, linux-mm, linux-kernel, mingo,
a.p.zijlstra, tglx, hpa, riel, cl
In-Reply-To: <20101007154248.GA30949@amt.cnet>
On Thu, Oct 07, 2010 at 12:42:48PM -0300, Marcelo Tosatti wrote:
> On Thu, Oct 07, 2010 at 12:00:13PM +0200, Avi Kivity wrote:
> > On 10/06/2010 10:08 PM, Gleb Natapov wrote:
> > >> Malicious userspace can cause entry to be cached, ioctl
> > >> SET_USER_MEMORY_REGION 2^32 times, generation number will match,
> > >> mark_page_dirty_in_slot will be called with pointer to freed memory.
> > >>
> > >Hmm. To zap all cached entires on overflow we need to track them. If we
> > >will track then we can zap them on each slot update and drop "generation"
> > >entirely.
> >
> > To track them you need locking.
> >
> > Isn't SET_USER_MEMORY_REGION so slow that calling it 2^32 times
> > isn't really feasible?
>
> Assuming it takes 1ms, it would take 49 days.
>
We may fail ioctl when max value is reached. The question is how much slot
changes can we expect from real guest during its lifetime.
> > In any case, can use u64 generation count.
>
> Agree.
Yes, 64 bit ought to be enough for anybody.
--
Gleb.
^ permalink raw reply
* Re: Headphone jack and auto-mute of speak output
From: David Henningsson @ 2010-10-07 16:03 UTC (permalink / raw)
To: alsa-devel
In-Reply-To: <AANLkTim-R=FGHo-CxT=gxysisTRT3T35pyrfu7HscKAQ@mail.gmail.com>
On 2010-10-07 15:43, Raymond Yau wrote:
> 2010/10/7 Davyd McColl<davydm@gmail.com>
>
>> Good day
>>
>> I'm new to this list (though I've done some searching, I'm sure I could
>> have
>> missed something), so please bear with me.
>>
>> I filed a bug report recently against Ubuntu with respect to the problem
>> I'm
>> experiencing (as per the subject: jacking in my headphones doesn't mute the
>> speaker output) and was informed that the decision had been made upstream
>> as
>> a design intention. I was linked off to:
>>
>> http://mailman.alsa-project.org/pipermail/alsa-devel/2010-August/030071.html
>> with respect to the thread on this topic. I'd like to raise it again
>> though,
>> perhaps as a configurable feature, for the following reasons:
>>
>
> Enable auto-muting in model=auto only for devices with HP and speakers.
>
> http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=2a2ed0dfc9ec44a899c7d4672f73f2c045099118;hp=299f293b3428ae6d73406642cd7d41f08d524c83
>
>
> if the bios set your laptop 's speaker as line out , you need to implement a
> new model for your laptop ,
Can't you just override the pin config (via user_pin_configs in sysfs,
or a patch file) in this case?
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
^ permalink raw reply
* Re: [PATCH v6 04/12] Add memory slot versioning and use it to provide fast guest write interface
From: Gleb Natapov @ 2010-10-07 16:03 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: Avi Kivity, Gleb Natapov, kvm, linux-mm, linux-kernel, mingo,
a.p.zijlstra, tglx, hpa, riel, cl
In-Reply-To: <20101007154248.GA30949@amt.cnet>
On Thu, Oct 07, 2010 at 12:42:48PM -0300, Marcelo Tosatti wrote:
> On Thu, Oct 07, 2010 at 12:00:13PM +0200, Avi Kivity wrote:
> > On 10/06/2010 10:08 PM, Gleb Natapov wrote:
> > >> Malicious userspace can cause entry to be cached, ioctl
> > >> SET_USER_MEMORY_REGION 2^32 times, generation number will match,
> > >> mark_page_dirty_in_slot will be called with pointer to freed memory.
> > >>
> > >Hmm. To zap all cached entires on overflow we need to track them. If we
> > >will track then we can zap them on each slot update and drop "generation"
> > >entirely.
> >
> > To track them you need locking.
> >
> > Isn't SET_USER_MEMORY_REGION so slow that calling it 2^32 times
> > isn't really feasible?
>
> Assuming it takes 1ms, it would take 49 days.
>
We may fail ioctl when max value is reached. The question is how much slot
changes can we expect from real guest during its lifetime.
> > In any case, can use u64 generation count.
>
> Agree.
Yes, 64 bit ought to be enough for anybody.
--
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
* [PATCH] jffs2: Fix serious write stall due to erase
From: Joakim Tjernlund @ 2010-10-07 16:01 UTC (permalink / raw)
To: linux-mtd; +Cc: Joakim Tjernlund
Drop the alloc_sem before erasing flash in
jffs2_garbage_collect_pass().
Otherwise writes are put on hold until the erase
has finised.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
I am fairly sure it is safe to unlock the alloc_sem before
calling jffs2_erase_pending_blocks(). Extra confirmation
would be great though.
This problem was introduced in 2.6.35
fs/jffs2/gc.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/jffs2/gc.c b/fs/jffs2/gc.c
index f5e96bd..b5f7175 100644
--- a/fs/jffs2/gc.c
+++ b/fs/jffs2/gc.c
@@ -218,13 +218,14 @@ int jffs2_garbage_collect_pass(struct jffs2_sb_info *c)
if (!list_empty(&c->erase_complete_list) ||
!list_empty(&c->erase_pending_list)) {
spin_unlock(&c->erase_completion_lock);
+ mutex_unlock(&c->alloc_sem);
D1(printk(KERN_DEBUG "jffs2_garbage_collect_pass() erasing pending blocks\n"));
- if (jffs2_erase_pending_blocks(c, 1)) {
- mutex_unlock(&c->alloc_sem);
+ if (jffs2_erase_pending_blocks(c, 1))
return 0;
- }
+
D1(printk(KERN_DEBUG "No progress from erasing blocks; doing GC anyway\n"));
spin_lock(&c->erase_completion_lock);
+ mutex_lock(&c->alloc_sem);
}
/* First, work out which block we're garbage-collecting */
--
1.7.2.2
^ permalink raw reply related
* [PATCHv5] ARM: imx: Add iram allocator functions
From: Dinh.Nguyen at freescale.com @ 2010-10-07 16:00 UTC (permalink / raw)
To: linux-arm-kernel
From: Dinh Nguyen <Dinh.Nguyen@freescale.com>
Add IRAM(Internal RAM) allocation functions using GENERIC_ALLOCATOR.
The allocation size is 4KB multiples to guarantee alignment. The
idea for these functions is for i.MX platforms to use them
to dynamically allocate IRAM usage.
Applies on 2.6.36-rc7
Signed-off-by: Dinh Nguyen <Dinh.Nguyen@freescale.com>
Reviewed-by: Amit Kucheria <amit.kucheria@canonical.com>
---
arch/arm/plat-mxc/Kconfig | 4 ++
arch/arm/plat-mxc/Makefile | 1 +
arch/arm/plat-mxc/include/mach/iram.h | 41 ++++++++++++++++++
arch/arm/plat-mxc/iram_alloc.c | 74 +++++++++++++++++++++++++++++++++
4 files changed, 120 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-mxc/include/mach/iram.h
create mode 100644 arch/arm/plat-mxc/iram_alloc.c
diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
index 6785db4..0e99bb4 100644
--- a/arch/arm/plat-mxc/Kconfig
+++ b/arch/arm/plat-mxc/Kconfig
@@ -110,4 +110,8 @@ config ARCH_MXC_AUDMUX_V1
config ARCH_MXC_AUDMUX_V2
bool
+config IRAM_ALLOC
+ bool
+ select GENERIC_ALLOCATOR
+
endif
diff --git a/arch/arm/plat-mxc/Makefile b/arch/arm/plat-mxc/Makefile
index 78d405e..1ddfb13 100644
--- a/arch/arm/plat-mxc/Makefile
+++ b/arch/arm/plat-mxc/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_MXC_TZIC) += tzic.o
obj-$(CONFIG_IMX_HAVE_IOMUX_V1) += iomux-v1.o
obj-$(CONFIG_ARCH_MXC_IOMUX_V3) += iomux-v3.o
+obj-$(CONFIG_IRAM_ALLOC) += iram_alloc.o
obj-$(CONFIG_MXC_PWM) += pwm.o
obj-$(CONFIG_USB_EHCI_MXC) += ehci.o
obj-$(CONFIG_MXC_ULPI) += ulpi.o
diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
new file mode 100644
index 0000000..f7edd45
--- /dev/null
+++ b/arch/arm/plat-mxc/include/mach/iram.h
@@ -0,0 +1,41 @@
+/*
+ * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+#include <linux/errno.h>
+
+#ifdef CONFIG_IRAM_ALLOC
+
+int __init iram_init(unsigned long base, unsigned long size);
+void *iram_alloc(unsigned int size, unsigned long *dma_addr);
+void iram_free(unsigned long dma_addr, unsigned int size);
+
+#else
+
+static inline int __init iram_init(unsigned long base, unsigned long size)
+{
+ return -ENOMEM;
+}
+
+static inline void *iram_alloc(unsigned int size, unsigned long *dma_addr)
+{
+ return NULL;
+}
+
+static inline void iram_free(unsigned long base, unsigned long size) {}
+
+#endif
diff --git a/arch/arm/plat-mxc/iram_alloc.c b/arch/arm/plat-mxc/iram_alloc.c
new file mode 100644
index 0000000..8f75a32
--- /dev/null
+++ b/arch/arm/plat-mxc/iram_alloc.c
@@ -0,0 +1,74 @@
+/*
+ * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/genalloc.h>
+#include <mach/iram.h>
+
+static unsigned long iram_phys_base;
+static void __iomem *iram_virt_base;
+static struct gen_pool *iram_pool;
+
+static inline void __iomem *iram_phys_to_virt(unsigned long p)
+{
+ p = iram_virt_base + (p - iram_phys_base);
+ return p;
+}
+
+void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
+{
+ if (!iram_pool)
+ return NULL;
+
+ *dma_addr = gen_pool_alloc(iram_pool, size);
+ pr_debug("iram alloc - %dB at 0x%p\n", size, (void *)*dma_addr);
+ if (!*dma_addr)
+ return NULL;
+ return iram_phys_to_virt(*dma_addr);
+}
+EXPORT_SYMBOL(iram_alloc);
+
+void iram_free(unsigned long addr, unsigned int size)
+{
+ if (!iram_pool)
+ return;
+
+ gen_pool_free(iram_pool, addr, size);
+}
+EXPORT_SYMBOL(iram_free);
+
+int __init iram_init(unsigned long base, unsigned long size)
+{
+ iram_phys_base = base;
+
+ iram_pool = gen_pool_create(PAGE_SHIFT, -1);
+ if (!iram_pool)
+ return -ENOMEM;
+
+ gen_pool_add(iram_pool, base, size, -1);
+ iram_virt_base = ioremap(iram_phys_base, size);
+ if (!iram_virt_base)
+ return -EIO;
+
+ pr_debug("i.MX IRAM pool: %ld KB at 0x%p\n", size / 1024, iram_virt_base);
+ return 0;
+}
--
1.6.0.4
^ permalink raw reply related
* [PATCHv5] ARM: imx: Add iram allocator functions
From: Dinh.Nguyen @ 2010-10-07 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arm-kernel, linux, s.hauer, u.kleine-koenig,
valentin.longchamp, daniel, grant.likely, bryan.wu, amit.kucheria,
xiao-lizhang, Dinh Nguyen
From: Dinh Nguyen <Dinh.Nguyen@freescale.com>
Add IRAM(Internal RAM) allocation functions using GENERIC_ALLOCATOR.
The allocation size is 4KB multiples to guarantee alignment. The
idea for these functions is for i.MX platforms to use them
to dynamically allocate IRAM usage.
Applies on 2.6.36-rc7
Signed-off-by: Dinh Nguyen <Dinh.Nguyen@freescale.com>
Reviewed-by: Amit Kucheria <amit.kucheria@canonical.com>
---
arch/arm/plat-mxc/Kconfig | 4 ++
arch/arm/plat-mxc/Makefile | 1 +
arch/arm/plat-mxc/include/mach/iram.h | 41 ++++++++++++++++++
arch/arm/plat-mxc/iram_alloc.c | 74 +++++++++++++++++++++++++++++++++
4 files changed, 120 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-mxc/include/mach/iram.h
create mode 100644 arch/arm/plat-mxc/iram_alloc.c
diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
index 6785db4..0e99bb4 100644
--- a/arch/arm/plat-mxc/Kconfig
+++ b/arch/arm/plat-mxc/Kconfig
@@ -110,4 +110,8 @@ config ARCH_MXC_AUDMUX_V1
config ARCH_MXC_AUDMUX_V2
bool
+config IRAM_ALLOC
+ bool
+ select GENERIC_ALLOCATOR
+
endif
diff --git a/arch/arm/plat-mxc/Makefile b/arch/arm/plat-mxc/Makefile
index 78d405e..1ddfb13 100644
--- a/arch/arm/plat-mxc/Makefile
+++ b/arch/arm/plat-mxc/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_MXC_TZIC) += tzic.o
obj-$(CONFIG_IMX_HAVE_IOMUX_V1) += iomux-v1.o
obj-$(CONFIG_ARCH_MXC_IOMUX_V3) += iomux-v3.o
+obj-$(CONFIG_IRAM_ALLOC) += iram_alloc.o
obj-$(CONFIG_MXC_PWM) += pwm.o
obj-$(CONFIG_USB_EHCI_MXC) += ehci.o
obj-$(CONFIG_MXC_ULPI) += ulpi.o
diff --git a/arch/arm/plat-mxc/include/mach/iram.h b/arch/arm/plat-mxc/include/mach/iram.h
new file mode 100644
index 0000000..f7edd45
--- /dev/null
+++ b/arch/arm/plat-mxc/include/mach/iram.h
@@ -0,0 +1,41 @@
+/*
+ * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+#include <linux/errno.h>
+
+#ifdef CONFIG_IRAM_ALLOC
+
+int __init iram_init(unsigned long base, unsigned long size);
+void *iram_alloc(unsigned int size, unsigned long *dma_addr);
+void iram_free(unsigned long dma_addr, unsigned int size);
+
+#else
+
+static inline int __init iram_init(unsigned long base, unsigned long size)
+{
+ return -ENOMEM;
+}
+
+static inline void *iram_alloc(unsigned int size, unsigned long *dma_addr)
+{
+ return NULL;
+}
+
+static inline void iram_free(unsigned long base, unsigned long size) {}
+
+#endif
diff --git a/arch/arm/plat-mxc/iram_alloc.c b/arch/arm/plat-mxc/iram_alloc.c
new file mode 100644
index 0000000..8f75a32
--- /dev/null
+++ b/arch/arm/plat-mxc/iram_alloc.c
@@ -0,0 +1,74 @@
+/*
+ * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/genalloc.h>
+#include <mach/iram.h>
+
+static unsigned long iram_phys_base;
+static void __iomem *iram_virt_base;
+static struct gen_pool *iram_pool;
+
+static inline void __iomem *iram_phys_to_virt(unsigned long p)
+{
+ p = iram_virt_base + (p - iram_phys_base);
+ return p;
+}
+
+void __iomem *iram_alloc(unsigned int size, unsigned long *dma_addr)
+{
+ if (!iram_pool)
+ return NULL;
+
+ *dma_addr = gen_pool_alloc(iram_pool, size);
+ pr_debug("iram alloc - %dB@0x%p\n", size, (void *)*dma_addr);
+ if (!*dma_addr)
+ return NULL;
+ return iram_phys_to_virt(*dma_addr);
+}
+EXPORT_SYMBOL(iram_alloc);
+
+void iram_free(unsigned long addr, unsigned int size)
+{
+ if (!iram_pool)
+ return;
+
+ gen_pool_free(iram_pool, addr, size);
+}
+EXPORT_SYMBOL(iram_free);
+
+int __init iram_init(unsigned long base, unsigned long size)
+{
+ iram_phys_base = base;
+
+ iram_pool = gen_pool_create(PAGE_SHIFT, -1);
+ if (!iram_pool)
+ return -ENOMEM;
+
+ gen_pool_add(iram_pool, base, size, -1);
+ iram_virt_base = ioremap(iram_phys_base, size);
+ if (!iram_virt_base)
+ return -EIO;
+
+ pr_debug("i.MX IRAM pool: %ld KB@0x%p\n", size / 1024, iram_virt_base);
+ return 0;
+}
--
1.6.0.4
^ permalink raw reply related
* Re: PATCH [0/4] perf: clean-up of power events API
From: Frederic Weisbecker @ 2010-10-07 15:58 UTC (permalink / raw)
To: Pierre Tardy
Cc: Mathieu Desnoyers, Thomas Renninger, Jean Pihet,
linux-trace-users, linux-pm, linux-perf-users, mingo, arjan, rjw,
linux-omap, Peter Zijlstra, Kevin Hilman, Steven Rostedt,
Frank Eigler, Masami Hiramatsu, Thomas Gleixner, Andrew Morton,
Linus Torvalds, Tejun Heo
In-Reply-To: <AANLkTikT4xsh7iCQDX8ksewJwC-BeFov=Ab7iYo+hDmO@mail.gmail.com>
On Thu, Oct 07, 2010 at 05:23:43PM +0200, Pierre Tardy wrote:
> On Thu, Oct 7, 2010 at 5:08 PM, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
> > [ Adding a few more CCs, since this discussion is about a tracepoint
> > userspace ABI policy, which is a topic of general interest. ]
>
> To add a little more comment, this is not the first time that
> tracepoints ABI changes. You can look at pytimechart sourcecode:
> http://gitorious.org/pytimechart/pytimechart/blobs/master/timechart/ftrace.py
>
> from 2.6.31 which is the first kernel I support,
>
> sched_switch: 'task %s:%d [%d] ==> %s:%d [%d]',
> changed to:
> sched_switch: 'prev_comm=%s prev_pid=%d prev_prio=%d prev_state=%s
> ==> next_comm=%s next_pid=%d next_prio=%d',
>
> workqueue_execution: 'thread=%s
> func=%s\\+%s/%s','thread','func','func_offset','func_size'),
> changed to:
> workqueue_execution: 'thread=%s func=%s','thread','func'),
>
Seems to be only formatting changes, but no field has been removed and
no tracepoint has been renamed, etc...
So these are no stable ABI changes because the formatting can be changed
anytime. We want that flexibility and it stands on top of the per event
"format" files.
Tools are not supposed to read ascii formatted traces from trace/trace_pipe
files. Instead they need to read binary traces from trace_pipe_raw files
and look at the format file to know how to format this.
This is why we have these format files: to let tools adapt with changes
like format change or fields added.
And we have a library in perf and trace-cmd that let you
- request a field value in a raw trace, by its name. So the field doesn't
need to have a stable offset in the trace.
- request ascii format info, so that if ascii format changes, the tool
adapt.
- record binary traces, much more leightweight for the writer (kernel)
and for the reader (user).
I did told you that it would be better you make PyTimeChart use the perf
scripting facilities, it handles all the above things + it would
avoid you to handle a lot of things.
Now it's up to you, but don't count on us to make the ascii formatting
a stable ABI.
> actually, over all the events pytimechart supports, only power traces
> are stable...
Now one problem is that we have really broken the workqueue tracepoints
in this release. I thought nobody was using them so we could
refactor this tracepoint subsystem, my bad.
workqueue_execution has become workqueue_execution_start and
workqueue_execution_end. workqueue_insertion is going to
suffer a similar split.
workqueue_creation and workqueue_destruction have disappear but
I can probably restore them, but for the rest, what should we do?
I really feel uncomfortable with this tracepoint/ABI problem....
Mathieu suggested we start a user library that could handle these
changes when they are really necessary.
Thoughts?
(Adding Tejun in Cc).
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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
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.