* Re: [LTP] facing issue "TBROK : nobody not in /etc/passwd"
From: Garrett Cooper @ 2010-02-16 7:30 UTC (permalink / raw)
To: vishwanath govind; +Cc: ltp-list
In-Reply-To: <4b9fdcd01002152325w6bee8349t173c6f0afd935070@mail.gmail.com>
On Mon, Feb 15, 2010 at 11:25 PM, vishwanath govind
<vishwa.hochihally@gmail.com> wrote:
> I have initramfs file system built using Busybox-1.16.0 and didn't setup the
> ldap/nis. I have few files in /etc like passwd,group and syslogd conf
> files.But getpwnam() should search local repository(/etc/passwd file) and
> returns a pointer to a struct passwd, correct?. Do i really need to setup
> ldap/NIS to make it work getpwnam() funtion? The device i am using has
> memory restriction to add more stuff to filesystem and its very minimal. So
> please guide me what are the minimal things need to setup to get getpwnam()
> function working? Please correct me if i am wrong here.
>
> Regards
> Vishwa
>
> On Mon, Feb 15, 2010 at 1:48 PM, Garrett Cooper <yanegomi@gmail.com> wrote:
>>
>> On Sun, Feb 14, 2010 at 11:59 PM, vishwanath govind
>> <vishwa.hochihally@gmail.com> wrote:
>> > Yes, I checked this before, It return errorno "0". Somehow mknod02 won't
>> > display the errorno when it exit with "tst_brkm(TBROK, cleanup, "%s not
>> > in
>> > /etc/passwd", LTPUSER)" but I have similar tests return errorno 0. I see
>> > "nobody" user and uid/gid -99 is present in /etc/passwd file. Do I need
>> > to
>> > enable anything in KERNEL config or /etc?
>> >
>> > ============================log===============================
>> > <<<test_start>>>
>> > tag=nftw01 stime=1170483127
>> > cmdline="nftw01"
>> > contacts=""
>> > analysis=exit
>> > <<<test_output>>>
>> > nobody not found in /etc/passwd: No such file or directory
>> > <<<execution_status>>>
>> > initiation_status="ok"
>> > duration=0 termination_type=exited termination_id=1 corefile=no
>> > cutime=1 cstime=2
>> > <<<test_end>>>
>> > <<<test_start>>>
>> > tag=nftw6401 stime=1170483127
>> > cmdline="nftw6401"
>> > contacts=""
>> > analysis=exit
>> > <<<test_output>>>
>> > change_owner: nobody not found in /etc/passwd: No such file or directory
>> > <<<execution_status>>>
>> > initiation_status="ok"
>> > duration=0 termination_type=exited termination_id=1 corefile=no
>> > cutime=2 cstime=1
>> > <<<test_end>>>
>> > ==============================end==================================
>> > Regards
>> > Vishwa
>> >
>> > On Mon, Feb 15, 2010 at 12:50 PM, Garrett Cooper <yanegomi@gmail.com>
>> > wrote:
>> >>
>> >> On Sun, Feb 14, 2010 at 11:09 PM, vishwanath govind
>> >> <vishwa.hochihally@gmail.com> wrote:
>> >> > Garrett,
>> >> > Thanks for your quick reply. I am using "ltp-full-20091231".
>> >> > Regards
>> >> > Vishwa
>> >> >
>> >> > On Mon, Feb 15, 2010 at 12:33 PM, Garrett Cooper <yanegomi@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Sun, Feb 14, 2010 at 10:51 PM, vishwanath govind
>> >> >> <vishwa.hochihally@gmail.com> wrote:
>> >> >> >
>> >> >> > Hi,
>> >> >> > I am facing common issue which causing many of the LTP syscalls
>> >> >> > test
>> >> >> > cases
>> >> >> > to fail. I have taken mknod02 test to show this issue here.
>> >> >> > Definitely I
>> >> >> > am
>> >> >> > missing something out here, could you guys please point me to
>> >> >> > right
>> >> >> > direction? Please let me know if you need some more info/log
>> >> >> >
>> >> >> > ======================log================================
>> >> >> > # ls /etc
>> >> >> > group passwd
>> >> >> >
>> >> >> > # ./IDcheck.sh
>> >> >> > Checking for required user/group ids
>> >> >> > 'nobody' user id and group found.
>> >> >> > 'bin' user id and group found.
>> >> >> > 'daemon' user id and group found.
>> >> >> > Users group found.
>> >> >> > Sys group found.
>> >> >> > Required users/groups exist.
>> >> >> >
>> >> >> > # cat /etc/passwd
>> >> >> > root:x:0:0:root::
>> >> >> > nobody:x:99:99:nobody::
>> >> >> > bin:x:1:1:bin::
>> >> >> > daemon:x:2:2:daemon::
>> >> >> >
>> >> >> > #uname -a
>> >> >> > Linux (none) 2.6.29 #4 PREEMPT Thu Feb 11 23:37:46 PST 2010 armv6l
>> >> >> > GNU/Linux
>> >> >> >
>> >> >> > # ./mknod02
>> >> >> > mknod02 1 TBROK : nobody not in /etc/passwd
>> >> >>
>> >> >> What version of LTP is this?
>> >>
>> >> That's a lousy diagnostic, as any one of the following errors could be
>> >> the culprit:
>> >>
>> >> ERRORS
>> >> 0 or ENOENT or ESRCH or EBADF or EPERM or ...
>> >> The given name or uid was not found.
>> >>
>> >> EINTR A signal was caught.
>> >>
>> >> EIO I/O error.
>> >>
>> >> EMFILE The maximum number (OPEN_MAX) of files was open already
>> >> in the calling process.
>> >>
>> >> ENFILE The maximum number of files was open already in the
>> >> system.
>> >>
>> >> ENOMEM Insufficient memory to allocate passwd structure.
>> >>
>> >> ERANGE Insufficient buffer space supplied.
>> >>
>> >> What are the permissions on the file and is there any way where you
>> >> could grab the latest copy of the file from git and try that out (the
>> >> patch is available at:
>>
>> Nope... you sure your ldap / nis isn't busted?
No.. heh. I was just wondering if you had it partially setup but
it was broken somehow.
Do you have an alternative means of checking, like with perl,
python, etc? Do you need to update your shadow password db setup?
Thanks,
-Garrett
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply
* Re: [PATCH v2 1/4] Refactoring: remove duplicated code from builtin-send-pack.c and transport.c
From: Jeff King @ 2010-02-16 7:29 UTC (permalink / raw)
To: Michael Lukashov; +Cc: git
In-Reply-To: <1266276411-5796-2-git-send-email-michael.lukashov@gmail.com>
On Mon, Feb 15, 2010 at 11:26:47PM +0000, Michael Lukashov wrote:
> diff --git a/builtin-fetch.c b/builtin-fetch.c
> index 8654fa7..d3b9d8a 100644
> --- a/builtin-fetch.c
> +++ b/builtin-fetch.c
> [...]
> @@ -224,7 +224,7 @@ static int update_local_ref(struct ref *ref,
>
> if (!hashcmp(ref->old_sha1, ref->new_sha1)) {
> if (verbosity > 0)
> - sprintf(display, "= %-*s %-*s -> %s", SUMMARY_WIDTH,
> + sprintf(display, "= %-*s %-*s -> %s", TRANSPORT_SUMMARY_WIDTH,
> "[up to date]", REFCOL_WIDTH, remote,
> pretty_ref);
If you are refactoring, can all of these fetch lines just call
print_ref_status, which handles the summary width stuff itself? The push
and fetch formats are meant to be quite similar.
-Peff
^ permalink raw reply
* Re: [patch -mm 8/9 v2] oom: avoid oom killer for lowmem allocations
From: David Rientjes @ 2010-02-16 7:29 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: KAMEZAWA Hiroyuki, Andrew Morton, Rik van Riel, Nick Piggin,
Andrea Arcangeli, Balbir Singh, Lubos Lunak, linux-kernel,
linux-mm
In-Reply-To: <20100216142856.72F4.A69D9226@jp.fujitsu.com>
On Tue, 16 Feb 2010, KOSAKI Motohiro wrote:
> No current user? I don't think so.
>
> int bio_integrity_prep(struct bio *bio)
> {
> (snip)
> buf = kmalloc(len, GFP_NOIO | __GFP_NOFAIL | q->bounce_gfp);
>
> and
>
> void blk_queue_bounce_limit(struct request_queue *q, u64 dma_mask)
> {
> (snip)
> if (dma) {
> init_emergency_isa_pool();
> q->bounce_gfp = GFP_NOIO | GFP_DMA;
> q->limits.bounce_pfn = b_pfn;
> }
>
>
>
> I don't like rumor based discussion, I like fact based one.
>
The GFP_NOIO will prevent the oom killer from being called, it requires
__GFP_FS.
I can change this to invoke the should_alloc_retry() logic by testing for
!(gfp_mask & __GFP_NOFAIL), but there's nothing else the page allocator
can currently do to increase its probability of allocating pages; the
memory compaction patchset might be particularly helpful for these types
of scenarios.
^ permalink raw reply
* Re: [patch -mm 8/9 v2] oom: avoid oom killer for lowmem allocations
From: David Rientjes @ 2010-02-16 7:29 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: KAMEZAWA Hiroyuki, Andrew Morton, Rik van Riel, Nick Piggin,
Andrea Arcangeli, Balbir Singh, Lubos Lunak, linux-kernel,
linux-mm
In-Reply-To: <20100216142856.72F4.A69D9226@jp.fujitsu.com>
On Tue, 16 Feb 2010, KOSAKI Motohiro wrote:
> No current user? I don't think so.
>
> int bio_integrity_prep(struct bio *bio)
> {
> (snip)
> buf = kmalloc(len, GFP_NOIO | __GFP_NOFAIL | q->bounce_gfp);
>
> and
>
> void blk_queue_bounce_limit(struct request_queue *q, u64 dma_mask)
> {
> (snip)
> if (dma) {
> init_emergency_isa_pool();
> q->bounce_gfp = GFP_NOIO | GFP_DMA;
> q->limits.bounce_pfn = b_pfn;
> }
>
>
>
> I don't like rumor based discussion, I like fact based one.
>
The GFP_NOIO will prevent the oom killer from being called, it requires
__GFP_FS.
I can change this to invoke the should_alloc_retry() logic by testing for
!(gfp_mask & __GFP_NOFAIL), but there's nothing else the page allocator
can currently do to increase its probability of allocating pages; the
memory compaction patchset might be particularly helpful for these types
of scenarios.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Simplified iWARP Consumer Library
From: Philip Frey @ 2010-02-16 7:28 UTC (permalink / raw)
To: Or Gerlitz; +Cc: bmt-OA+xvbQnYDHMbYB6QlFGEg, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4B7A2CF8.1070002-smomgflXvOZWk0Htik3J/w@public.gmane.org>
Dear all,
I was made aware of the fact that the general-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org mailinglist
was deprecated and that my initial post about the iWARP library did not reach
you. (The general list is still linked on openfabrics.org without a notice of it
being deprecated.)
Please, find below a copy of the original message.
"Dear all,
throughout the course of my PhD, I have written a number of user applications
based on the OFED verbs. After some time, I realized that many programming tasks
are repetitive (particularly the connection management) and started to wrap them.
This eventually led to a slim, shared library called libiwarp which includes all
the basic primitives of RDMA-based communication, implemented as wrappers around
libibverbs. Throughout various research projects, the library has turned out to
be quite useful especially for people who are not familiar with all the details
of the OFED verbs (like master students that only have 6 months to complete
their projects or people that simply want to play around with iWARP and run a
few simple tests).
We have shown, by experiment, that the overhead induced by the wrappers is
negligible, yet it simplifies writing RDMA-based applications significantly.
Furthermore, as the library does not replace the OFED verbs, it does not impose
any restrictions with regard to the original functionality. Whenever there is
something missing in the libiwarp, you can always use the interface provided by
the OFED verbs.
As I am now in the process of finishing my work, I was wondering whether there
is an interest in the OpenFabrics community for such a library which provides a
simplified interface for the OFED verbs. If there is, I would be glad to share
my source code with you.
Many thanks for your consideration and best regards,
Philip"
Or Gerlitz wrote:
> Philip Frey wrote:
>> as announced last week (on general-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org) [...] I
>> would be very interested in your feedback!
> The general list isn't functional since last fall, as of such, your
> announcement wasn't seen by any of the non directly CCed recipients...
> can you please resend it here (linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)?
>
> Or.
>
> --
> 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
--
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: crypto_shash_update & CRYPTO_TFM_REQ_MAY_SLEEP
From: Herbert Xu @ 2010-02-16 7:27 UTC (permalink / raw)
To: Dmitry Kasatkin; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <4B7A43A6.6090409@nokia.com>
On Tue, Feb 16, 2010 at 09:05:10AM +0200, Dmitry Kasatkin wrote:
> Hi,
>
> How is it possible to wait for completion here?: shash.c
>
> shash_compat_digest()
> {
> ....
> data = crypto_kmap(sg_page(sg), 0);
> err = crypto_shash_digest(desc, data + offset, nbytes, out);
> crypto_kunmap(data, 0);
> ....
> }
>
> It happens as single operation/call.
Well you'd do it as an ahash algorithm, not shash.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [LTP] facing issue "TBROK : nobody not in /etc/passwd"
From: vishwanath govind @ 2010-02-16 7:25 UTC (permalink / raw)
To: Garrett Cooper; +Cc: ltp-list
In-Reply-To: <364299f41002150018p1a6888b6r4cb95731deffcd0b@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4640 bytes --]
I have initramfs file system built using Busybox-1.16.0 and didn't setup the
ldap/nis. I have few files in /etc like passwd,group and syslogd conf
files.But getpwnam() should search local repository(/etc/passwd file) and
returns a pointer to a *struct passwd*, correct?. Do i really need to setup
ldap/NIS to make it work getpwnam() funtion? The device i am using has
memory restriction to add more stuff to filesystem and its very minimal. So
please guide me what are the minimal things need to setup to get getpwnam()
function working? Please correct me if i am wrong here.
Regards
Vishwa
On Mon, Feb 15, 2010 at 1:48 PM, Garrett Cooper <yanegomi@gmail.com> wrote:
> On Sun, Feb 14, 2010 at 11:59 PM, vishwanath govind
> <vishwa.hochihally@gmail.com> wrote:
> > Yes, I checked this before, It return errorno "0". Somehow mknod02 won't
> > display the errorno when it exit with "tst_brkm(TBROK, cleanup, "%s not
> in
> > /etc/passwd", LTPUSER)" but I have similar tests return errorno 0. I see
> > "nobody" user and uid/gid -99 is present in /etc/passwd file. Do I need
> to
> > enable anything in KERNEL config or /etc?
> >
> > ============================log===============================
> > <<<test_start>>>
> > tag=nftw01 stime=1170483127
> > cmdline="nftw01"
> > contacts=""
> > analysis=exit
> > <<<test_output>>>
> > nobody not found in /etc/passwd: No such file or directory
> > <<<execution_status>>>
> > initiation_status="ok"
> > duration=0 termination_type=exited termination_id=1 corefile=no
> > cutime=1 cstime=2
> > <<<test_end>>>
> > <<<test_start>>>
> > tag=nftw6401 stime=1170483127
> > cmdline="nftw6401"
> > contacts=""
> > analysis=exit
> > <<<test_output>>>
> > change_owner: nobody not found in /etc/passwd: No such file or directory
> > <<<execution_status>>>
> > initiation_status="ok"
> > duration=0 termination_type=exited termination_id=1 corefile=no
> > cutime=2 cstime=1
> > <<<test_end>>>
> > ==============================end==================================
> > Regards
> > Vishwa
> >
> > On Mon, Feb 15, 2010 at 12:50 PM, Garrett Cooper <yanegomi@gmail.com>
> wrote:
> >>
> >> On Sun, Feb 14, 2010 at 11:09 PM, vishwanath govind
> >> <vishwa.hochihally@gmail.com> wrote:
> >> > Garrett,
> >> > Thanks for your quick reply. I am using "ltp-full-20091231".
> >> > Regards
> >> > Vishwa
> >> >
> >> > On Mon, Feb 15, 2010 at 12:33 PM, Garrett Cooper <yanegomi@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Sun, Feb 14, 2010 at 10:51 PM, vishwanath govind
> >> >> <vishwa.hochihally@gmail.com> wrote:
> >> >> >
> >> >> > Hi,
> >> >> > I am facing common issue which causing many of the LTP syscalls
> test
> >> >> > cases
> >> >> > to fail. I have taken mknod02 test to show this issue here.
> >> >> > Definitely I
> >> >> > am
> >> >> > missing something out here, could you guys please point me to right
> >> >> > direction? Please let me know if you need some more info/log
> >> >> >
> >> >> > ======================log================================
> >> >> > # ls /etc
> >> >> > group passwd
> >> >> >
> >> >> > # ./IDcheck.sh
> >> >> > Checking for required user/group ids
> >> >> > 'nobody' user id and group found.
> >> >> > 'bin' user id and group found.
> >> >> > 'daemon' user id and group found.
> >> >> > Users group found.
> >> >> > Sys group found.
> >> >> > Required users/groups exist.
> >> >> >
> >> >> > # cat /etc/passwd
> >> >> > root:x:0:0:root::
> >> >> > nobody:x:99:99:nobody::
> >> >> > bin:x:1:1:bin::
> >> >> > daemon:x:2:2:daemon::
> >> >> >
> >> >> > #uname -a
> >> >> > Linux (none) 2.6.29 #4 PREEMPT Thu Feb 11 23:37:46 PST 2010 armv6l
> >> >> > GNU/Linux
> >> >> >
> >> >> > # ./mknod02
> >> >> > mknod02 1 TBROK : nobody not in /etc/passwd
> >> >>
> >> >> What version of LTP is this?
> >>
> >> That's a lousy diagnostic, as any one of the following errors could be
> >> the culprit:
> >>
> >> ERRORS
> >> 0 or ENOENT or ESRCH or EBADF or EPERM or ...
> >> The given name or uid was not found.
> >>
> >> EINTR A signal was caught.
> >>
> >> EIO I/O error.
> >>
> >> EMFILE The maximum number (OPEN_MAX) of files was open already
> >> in the calling process.
> >>
> >> ENFILE The maximum number of files was open already in the system.
> >>
> >> ENOMEM Insufficient memory to allocate passwd structure.
> >>
> >> ERANGE Insufficient buffer space supplied.
> >>
> >> What are the permissions on the file and is there any way where you
> >> could grab the latest copy of the file from git and try that out (the
> >> patch is available at:
>
> Nope... you sure your ldap / nis isn't busted?
> -Garrett
>
[-- Attachment #1.2: Type: text/html, Size: 6794 bytes --]
[-- Attachment #2: Type: text/plain, Size: 254 bytes --]
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
[-- Attachment #3: Type: text/plain, Size: 155 bytes --]
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply
* RE: [PATCH 5/6] Mailbox: sleeping function called from invalid context fix
From: Guzman Lugo, Fernando @ 2010-02-16 7:25 UTC (permalink / raw)
To: Hiroshi DOYU; +Cc: linux-omap@vger.kernel.org
In-Reply-To: <20100215.154846.212385655.Hiroshi.DOYU@nokia.com>
Hi,
>-----Original Message-----
>From: Hiroshi DOYU [mailto:Hiroshi.DOYU@nokia.com]
>Sent: Monday, February 15, 2010 7:49 AM
>To: Guzman Lugo, Fernando
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 5/6] Mailbox: sleeping function called from invalid
>context fix
>
>Hi Fernando,
>
>From: "ext Guzman Lugo, Fernando" <x0095840@ti.com>
>Subject: [PATCH 5/6] Mailbox: sleeping function called from invalid context
>fix
>Date: Sat, 13 Feb 2010 02:42:16 +0100
>
>> From e06b2716824f225747c4dc83ed2623d0160ae132 Mon Sep 17 00:00:00 2001
>> From: Fernando Guzman Lugo <x0095840@ti.com>
>> Date: Fri, 29 Jan 2010 17:12:24 -0600
>> Subject: [PATCH] Mailbox: sleeping function called from invalid context
>fix
>>
>> This patch fixes this bug:
>> BUG: sleeping function called from invalid context
>> Inside omap2_mbox_startup is called clk_get_sys that can sleep,
>> therefore omap2_mbox_startup can sleep but it is call in an atomic
>> context . So the spinlock is change for a semaphore.
>
>"mboxes_lock" is used to maintain the global list of mailbox
>instances, which belong to a single mailbox H/W module, but they are
>logical channels from S/W perspective. Both "->ops->startup()" and
>"->ops->shutdown()" are being executed against the above single H/W
>module, and a mailbox H/W module is totally __independent__ of the
>registration of logical mailboxes, which are (un)registered with
Yes, they are independent of each other, and can be executed at the same time. I am agreed with your patch; that should be the right solution, so you can drop my patch.
Thanks and regards,
Fernando.
>"omap_mbox_(un)register()". IOW, a mbox instance can be registered at
>anytime(before/after) H/W initialization. This H/W initialization is
>taken care of by "mbox_configured" variable. So I might think that the
>right solution is to introduce a new mutex lock __just for__ h/w
>configuration as below:
>
> Modified arch/arm/plat-omap/mailbox.c
>diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
>index 8e90633..19530de 100644
>--- a/arch/arm/plat-omap/mailbox.c
>+++ b/arch/arm/plat-omap/mailbox.c
>@@ -32,6 +32,7 @@ static struct omap_mbox *mboxes;
> static DEFINE_RWLOCK(mboxes_lock);
>
> static int mbox_configured;
>+static DEFINE_MUTEX(mbox_configured_lock);
>
> /* Mailbox FIFO handle functions */
> static inline mbox_msg_t mbox_fifo_read(struct omap_mbox *mbox)
>@@ -247,16 +248,16 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
> struct omap_mbox_queue *mq;
>
> if (likely(mbox->ops->startup)) {
>- write_lock(&mboxes_lock);
>+ mutex_lock(&mbox_configured_lock);
> if (!mbox_configured)
> ret = mbox->ops->startup(mbox);
>
> if (unlikely(ret)) {
>- write_unlock(&mboxes_lock);
>+ mutex_unlock(&mbox_configured_lock);
> return ret;
> }
> mbox_configured++;
>- write_unlock(&mboxes_lock);
>+ mutex_unlock(&mbox_configured_lock);
> }
>
> ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED,
>@@ -302,12 +303,12 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
> free_irq(mbox->irq, mbox);
>
> if (unlikely(mbox->ops->shutdown)) {
>- write_lock(&mboxes_lock);
>+ mutex_lock(&mbox_configured_lock);
> if (mbox_configured > 0)
> mbox_configured--;
> if (!mbox_configured)
> mbox->ops->shutdown(mbox);
>- write_unlock(&mboxes_lock);
>+ mutex_unlock(&mbox_configured_lock);
> }
> }
^ permalink raw reply
* Re: git fetch origin hanging in 1.7.0
From: Jeff King @ 2010-02-16 7:24 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Kevin Menard, Ilari Liusvaara, git
In-Reply-To: <20100216151821.994ace31.rctay89@gmail.com>
On Tue, Feb 16, 2010 at 03:18:21PM +0800, Tay Ray Chuan wrote:
> > That fixes the problem for me, but I am totally clueless about this
> > code. Do all transports have a git_transport_data (if so, then why is it
> > a void pointer?).
>
> It is void so that it can be any struct - for example,
> git_transport_data, bundle_transport_data. That way, transport->data
> can point to any transport-specific data, while keeping the compiler
> satisfied at compile-time.
OK, I figured it was something like that. In that case, your fix looks
like the right thing to do (and it fixes my test case).
Thanks.
> -- >8 --
> Subject: [PATCH] transport: add got_remote_refs flag
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* install problem with attr-2.4.44
From: Steffen Sledz @ 2010-02-16 7:22 UTC (permalink / raw)
To: openembedded-devel
Install stage for attr-2.4.44 fails for me with:
| make -C attr install
| make[1]: Entering directory `/home/DRESEARCH/production/METABUILD/20100215190003-hydraip-build-7715/OE/tmp.5/work/armv5te-angstrom-linux-gnueabi/attr-2.4.44-r1/attr-2.4.44/attr'
| ../include/install-sh -o production -g domain users -m 755 -d /home/DRESEARCH/production/METABUILD/20100215190003-hydraip-build-7715/OE/tmp.5/work/armv5te-angstrom-linux-gnueabi/attr-2.4.44-r1/image/usr/bin
| cp: cannot stat `users': No such file or directory
The actual problem seems to be the unquoted group name 'domain users'.
But why should be files installed in
tmp.5/work/armv5te-angstrom-linux-gnueabi/attr-2.4.44-r1/image/usr/bin
with host system groups rights?
Steffen
^ permalink raw reply
* Re: [patch] mm: add comment about deprecation of __GFP_NOFAIL
From: Nick Piggin @ 2010-02-16 7:23 UTC (permalink / raw)
To: David Rientjes
Cc: KAMEZAWA Hiroyuki, Andrew Morton, Rik van Riel, Andrea Arcangeli,
Balbir Singh, Lubos Lunak, KOSAKI Motohiro, linux-kernel,
linux-mm
In-Reply-To: <alpine.DEB.2.00.1002152300580.2745@chino.kir.corp.google.com>
On Mon, Feb 15, 2010 at 11:03:50PM -0800, David Rientjes wrote:
> On Tue, 16 Feb 2010, KAMEZAWA Hiroyuki wrote:
>
> > I hope no 3rd vendor (proprietary) driver uses __GFP_NOFAIL, they tend to
> > believe API is trustable and unchanged.
> >
>
> I hope they don't use it with GFP_ATOMIC, either, because it's never been
> respected in that context. We can easily audit the handful of cases in
> the kernel that use __GFP_NOFAIL (it takes five minutes at the max) and
> prove that none use it with GFP_ATOMIC or GFP_NOFS. We don't need to add
> multitudes of warnings about using a deprecated flag with ludicrous
> combinations (does anyone really expect GFP_ATOMIC | __GFP_NOFAIL to work
> gracefully)?
You don't need to add warnings, just don't break existing working
combinations and nobody has anything to complain about.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [patch] mm: add comment about deprecation of __GFP_NOFAIL
From: Nick Piggin @ 2010-02-16 7:23 UTC (permalink / raw)
To: David Rientjes
Cc: KAMEZAWA Hiroyuki, Andrew Morton, Rik van Riel, Andrea Arcangeli,
Balbir Singh, Lubos Lunak, KOSAKI Motohiro, linux-kernel,
linux-mm
In-Reply-To: <alpine.DEB.2.00.1002152300580.2745@chino.kir.corp.google.com>
On Mon, Feb 15, 2010 at 11:03:50PM -0800, David Rientjes wrote:
> On Tue, 16 Feb 2010, KAMEZAWA Hiroyuki wrote:
>
> > I hope no 3rd vendor (proprietary) driver uses __GFP_NOFAIL, they tend to
> > believe API is trustable and unchanged.
> >
>
> I hope they don't use it with GFP_ATOMIC, either, because it's never been
> respected in that context. We can easily audit the handful of cases in
> the kernel that use __GFP_NOFAIL (it takes five minutes at the max) and
> prove that none use it with GFP_ATOMIC or GFP_NOFS. We don't need to add
> multitudes of warnings about using a deprecated flag with ludicrous
> combinations (does anyone really expect GFP_ATOMIC | __GFP_NOFAIL to work
> gracefully)?
You don't need to add warnings, just don't break existing working
combinations and nobody has anything to complain about.
^ permalink raw reply
* Re: Fatal error running status in new repo
From: Jeff King @ 2010-02-16 7:21 UTC (permalink / raw)
To: Jacob Helwig; +Cc: Ping Yin, Johan Herland, git
In-Reply-To: <20100216062422.GC10296@vfb-9.home>
On Mon, Feb 15, 2010 at 10:24:22PM -0800, Jacob Helwig wrote:
[in an empty repo]
> $ GIT_TRACE=1 git status
> trace: built-in: git 'status'
> # On branch master
> #
> # Initial commit
> #
[...]
> trace: run_command: 'git-submodule' 'summary' '--cached' '--for-status' '--summary-limit' '-1' 'HEAD'
[...]
> trace: built-in: git 'rev-parse' '-q' '--verify' 'HEAD^0'
> warning: ignoring dangling symref HEAD.
[...]
> trace: built-in: git 'diff-index' '--cached' '--raw' 'HEAD' '--' 'HEAD'
> fatal: bad revision 'HEAD'
The patch I just posted elsewhere in the thread fixes the "ignoring
dangling symref" message. The "bad revision 'HEAD'" comes from
diff-index. But as you can see, that diff-index invocation is somewhat
bogus.
It looks like this code (git-submodule.sh:556-562):
if rev=$(git rev-parse -q --verify "$1^0")
then
head=$rev
shift
else
head=HEAD
fi
is meant to guess whether the argument is a revision or a file limiter,
and if the latter, assume HEAD was meant. Which obviously breaks down
when the argument is HEAD and it is invalid. The patch below seems to
fix it for me, but I have no idea if I am breaking something else.
Can somebody more clueful about the submodule script take a look?
-Peff
---
diff --git a/git-submodule.sh b/git-submodule.sh
index 664f217..4332992 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -555,10 +555,12 @@ cmd_summary() {
if rev=$(git rev-parse -q --verify "$1^0")
then
head=$rev
shift
+ elif test "$1" = "HEAD"; then
+ return
else
head=HEAD
fi
if [ -n "$files" ]
^ permalink raw reply related
* Re: [patch -mm 4/9 v2] oom: remove compulsory panic_on_oom mode
From: Nick Piggin @ 2010-02-16 7:20 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Rik van Riel, KAMEZAWA Hiroyuki, Andrea Arcangeli,
Balbir Singh, Lubos Lunak, KOSAKI Motohiro, linux-kernel,
linux-mm
In-Reply-To: <alpine.DEB.2.00.1002152252310.2745@chino.kir.corp.google.com>
On Mon, Feb 15, 2010 at 10:59:26PM -0800, David Rientjes wrote:
> On Tue, 16 Feb 2010, Nick Piggin wrote:
>
> > What is the point of removing it, though? If it doesn't significantly
> > help some future patch, just leave it in. It's not worth breaking the
> > user/kernel interface just to remove 3 trivial lines of code.
> >
>
> Because it is inconsistent at the user's expense, it has never panicked
> the machine for memory controller ooms, so why is a cpuset or mempolicy
> constrained oom conditions any different?
Well memory controller was added later, wasn't it? So if you think
that's a bug then a fix to panic on memory controller ooms might
be in order.
> It also panics the machine even
> on VM_FAULT_OOM which is ridiculous,
Why?
> the tunable is certainly not being
> used how it was documented
Why not? The documentation seems to match the implementation.
> and so given the fact that mempolicy
> constrained ooms are now much smarter with my rewrite and we never simply
> kill current unless oom_kill_quick is enabled anymore, the compulsory
> panic_on_oom == 2 mode is no longer required. Simply set all tasks
> attached to a cpuset or bound to a specific mempolicy to be OOM_DISABLE,
> the kernel need not provide confusing alternative modes to sysctls for
> this behavior. Before panic_on_oom == 2 was introduced, it would have
> only panicked the machine if panic_on_oom was set to a non-zero integer,
> defining it be something different for '2' after it has held the same
> semantics for years is inappropriate.
Well it was always defined in the documentation that it should be 0
or 1. Just that the limit wasn't enforced. I agree that's not ideal,
but anyway the existing and documented 0/1/2 has been there for 3 years
and so now removing the 2 is even worse.
> There is just no concrete example
> that anyone can give where they want a cpuset-constrained oom to panic the
> machine when other tasks on a disjoint set of mems can continue to do
> work and the cpuset of interest cannot have its tasks set to OOM_DISABLE.
But this is changing the way the environment is required to set up. So
a kernel upgrade can break previously working setups. We don't do this
without really good reason.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [patch -mm 4/9 v2] oom: remove compulsory panic_on_oom mode
From: Nick Piggin @ 2010-02-16 7:20 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Rik van Riel, KAMEZAWA Hiroyuki, Andrea Arcangeli,
Balbir Singh, Lubos Lunak, KOSAKI Motohiro, linux-kernel,
linux-mm
In-Reply-To: <alpine.DEB.2.00.1002152252310.2745@chino.kir.corp.google.com>
On Mon, Feb 15, 2010 at 10:59:26PM -0800, David Rientjes wrote:
> On Tue, 16 Feb 2010, Nick Piggin wrote:
>
> > What is the point of removing it, though? If it doesn't significantly
> > help some future patch, just leave it in. It's not worth breaking the
> > user/kernel interface just to remove 3 trivial lines of code.
> >
>
> Because it is inconsistent at the user's expense, it has never panicked
> the machine for memory controller ooms, so why is a cpuset or mempolicy
> constrained oom conditions any different?
Well memory controller was added later, wasn't it? So if you think
that's a bug then a fix to panic on memory controller ooms might
be in order.
> It also panics the machine even
> on VM_FAULT_OOM which is ridiculous,
Why?
> the tunable is certainly not being
> used how it was documented
Why not? The documentation seems to match the implementation.
> and so given the fact that mempolicy
> constrained ooms are now much smarter with my rewrite and we never simply
> kill current unless oom_kill_quick is enabled anymore, the compulsory
> panic_on_oom == 2 mode is no longer required. Simply set all tasks
> attached to a cpuset or bound to a specific mempolicy to be OOM_DISABLE,
> the kernel need not provide confusing alternative modes to sysctls for
> this behavior. Before panic_on_oom == 2 was introduced, it would have
> only panicked the machine if panic_on_oom was set to a non-zero integer,
> defining it be something different for '2' after it has held the same
> semantics for years is inappropriate.
Well it was always defined in the documentation that it should be 0
or 1. Just that the limit wasn't enforced. I agree that's not ideal,
but anyway the existing and documented 0/1/2 has been there for 3 years
and so now removing the 2 is even worse.
> There is just no concrete example
> that anyone can give where they want a cpuset-constrained oom to panic the
> machine when other tasks on a disjoint set of mems can continue to do
> work and the cpuset of interest cannot have its tasks set to OOM_DISABLE.
But this is changing the way the environment is required to set up. So
a kernel upgrade can break previously working setups. We don't do this
without really good reason.
^ permalink raw reply
* Re: git fetch origin hanging in 1.7.0
From: Tay Ray Chuan @ 2010-02-16 7:18 UTC (permalink / raw)
To: Jeff King; +Cc: Kevin Menard, Ilari Liusvaara, git
In-Reply-To: <20100216063959.GC2169@coredump.intra.peff.net>
Hi,
On Tue, 16 Feb 2010 01:39:59 -0500
Jeff King <peff@peff.net> wrote:
> I can reproduce the bug with:
>
> $ mkdir foo && (cd foo && git init)
> $ git clone foo bar
> Initialized empty Git repository in /home/peff/bar/.git/
> warning: You appear to have cloned an empty repository.
> $ cd bar && git fetch
>
> which hangs on a pipe read(). It bisects to 61b075b (Support taking over
> transports, 2009-12-09) from Ilari (cc'd). It looks like we get the
> empty ref list once in get_remote_heads, and then try to get it again
> and hang.
I agree with the diagnosis. With gdb, I find that program execution
hangs on the packet_read_line() call in connect.c::get_remote_heads().
> diff --git a/transport.c b/transport.c
> index ad25b98..e6f9464 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -1010,7 +1010,8 @@ int transport_push(struct transport *transport,
>
> const struct ref *transport_get_remote_refs(struct transport *transport)
> {
> - if (!transport->remote_refs)
> + struct git_transport_data *data = transport->data;
> + if (!data->got_remote_heads)
> transport->remote_refs = transport->get_refs_list(transport, 0);
>
> return transport->remote_refs;
NAK. This will only work if the given transport is git://. (My take
below.)
> That fixes the problem for me, but I am totally clueless about this
> code. Do all transports have a git_transport_data (if so, then why is it
> a void pointer?).
It is void so that it can be any struct - for example,
git_transport_data, bundle_transport_data. That way, transport->data
can point to any transport-specific data, while keeping the compiler
satisfied at compile-time.
-- >8 --
Subject: [PATCH] transport: add got_remote_refs flag
tranport.c::transport_get_remote_refs() used to check
transport->remote_refs to determine whether transport->get_refs_list()
should be invoked.
However, transport->remote_refs could evaluate to false (eg. if it is
NULL), causingo transport->get_refs_list() to be invoked unnecessarily.
Introduce a flag, transport->got_remote_refs, and make
tranport.c::transport_get_remote_refs() check this flag rather than
evaluating transport->remote_refs.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
transport.c | 5 ++++-
transport.h | 6 ++++++
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/transport.c b/transport.c
index 3846aac..08e4fa0 100644
--- a/transport.c
+++ b/transport.c
@@ -918,6 +918,7 @@ struct transport *transport_get(struct remote *remote, const char *url)
if (!remote)
die("No remote provided to transport_get()");
+ ret->got_remote_refs = 0;
ret->remote = remote;
helper = remote->foreign_vcs;
@@ -1079,8 +1080,10 @@ int transport_push(struct transport *transport,
const struct ref *transport_get_remote_refs(struct transport *transport)
{
- if (!transport->remote_refs)
+ if (!transport->got_remote_refs) {
transport->remote_refs = transport->get_refs_list(transport, 0);
+ transport->got_remote_refs = 1;
+ }
return transport->remote_refs;
}
diff --git a/transport.h b/transport.h
index 7cea5cc..1cca13b 100644
--- a/transport.h
+++ b/transport.h
@@ -20,6 +20,12 @@ struct transport {
const struct ref *remote_refs;
/**
+ * Indicates whether the remote_refs member has been set. Set by
+ * transport.c::transport_get_remote_refs().
+ */
+ unsigned got_remote_refs : 1;
+
+ /**
* Returns 0 if successful, positive if the option is not
* recognized or is inapplicable, and negative if the option
* is applicable but the value is invalid.
--
1.7.0.1.gcd472.dirty
--
Cheers,
Ray Chuan
^ permalink raw reply related
* Re: [PATCH 1/2] mac80211: Drop protected data frames that have not been decrypted
From: Johannes Berg @ 2010-02-16 7:18 UTC (permalink / raw)
To: Benoit PAPILLAULT; +Cc: Gábor Stefanik, linux-wireless
In-Reply-To: <4B79CC6B.5000905@free.fr>
On Mon, 2010-02-15 at 23:36 +0100, Benoit PAPILLAULT wrote:
> Just for my own understanding. It seems the implementation has 2
> different code path :
> - "real" monitor mode which is handled right after ieee80211_rx() so
> it
> is not affected
> - "cook" monitor mode which is handled as part of the RX handlers.
>
> BTW, why do we have 2 different code path? I'm sure I missed something
>
> obvious here.
cooked monitor reports only usable, decrypted frames that the kernel
didn't know how to handle.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: Add HT IE to IBSS beacons and probe responses.
From: Johannes Berg @ 2010-02-16 7:17 UTC (permalink / raw)
To: Benoit PAPILLAULT; +Cc: linux-wireless
In-Reply-To: <4B79CB71.1000509@free.fr>
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
On Mon, 2010-02-15 at 23:32 +0100, Benoit PAPILLAULT wrote:
> You are referring to "we need nl80211/cfg80211 changes" I guess. Could
>
> you elaborate a bit on this? I'm still new to mac80211. Could you tell
>
> me what needs to be changed and where I can start ? iw source code ?
> is
> cfg80211 the source code under net/wireless ?
Yes cfg80211 is most of net/wireless/.
Is it not obvious to you that in order to use HT with IBSS you need to
have a way to configure the IBSS to use HT?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [RFC] [PATCH 1/1] OMAP3: PM: Add cpuidle C-state description information
From: Eduardo Valentin @ 2010-02-16 7:16 UTC (permalink / raw)
To: ext Kevin Hilman
Cc: \"Kristo Tero (Nokia-D/Tampere)\", Linux-OMAP,
Eduardo Valentin
From: Eduardo Valentin <eduardo.valentin@nokia.com>
Add a basic description information for each cpuidle C-state.
The info contains only which state the MPU, NEON and CORE
power domains should reach when the C-state is selected.
Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
---
arch/arm/mach-omap2/cpuidle34xx.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 1cfa5a6..50fe9ab 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -339,6 +339,7 @@ struct cpuidle_driver omap3_idle_driver = {
*/
int __init omap3_idle_init(void)
{
+ const char *pd_states[4] = {"OFF", "RET", "INA", "ON "};
int i, count = 0;
struct omap3_processor_cx *cx;
struct cpuidle_state *state;
@@ -367,6 +368,9 @@ int __init omap3_idle_init(void)
if (cx->type == OMAP3_STATE_C1)
dev->safe_state = state;
sprintf(state->name, "C%d", count+1);
+ sprintf(state->desc, "MPU=%s NEON=%s CORE=%s",
+ pd_states[cx->mpu_state], pd_states[cx->mpu_state],
+ pd_states[cx->core_state]);
count++;
}
--
1.6.5.7.g9ecb2
^ permalink raw reply related
* [U-Boot] [STATUS] i.MX / Freescale ARM custodian needed
From: Jason Liu @ 2010-02-16 7:11 UTC (permalink / raw)
To: u-boot
In-Reply-To: <loom.20100213T013307-158@post.gmane.org>
2010/2/13 Paul Kline <paul.kline@freescale.com>:
> Detlev Zundel <dzu <at> denx.de> writes:
>
>>
>> Hi Stefano,
>>
>> > I do not know how you plan the next step, but please feel free to ask me
>> > how can I help.
>>
>> Well, we are just packaging one of those stylish "custodian hats" which
>> you will be likely to wear a lot in the foreseeable future and send it
>> off to you :)
>>
>> No honestly, as I do not see any negative reaction, there is no reason
>> why you should not get the job. ?So maybe ask Fred Fan again if it is ok
>> to take over his git repo and then we will install your ssh key there so
>> you can update it.
>>
>> Cheers and thanks!
>> ? Detlev
>>
> Hi Stefano and Detlev,
>
> When Fred Fan informed us he was leaving Freescale, we identified another
> developer from Freescale's U-Boot development team who we planned to propose
> as Fred's replacement as custodian for the Freescale i.MX ARM processors.
> However, we were slow proposing this replacement--our apologies.
>
> We appreciate Stefano volunteering to serve as Fred's replacement and we will
> be happy to work with him in his role as new custodian for the Freescale i.MX
> processors. ?However, if Stefano volunteered because no one else was stepping
> forward, then we would also be willing to have our developer serve as Fred's
> replacement in the custodian's role. ?Either way sounds good to Freescale.
>
> Thanks again to Stefano for volunteering.
>
> Regards,
> Paul Kline
> Manager, i.MX Linux Board Support Packages
> Freescale Semiconductor
>
As Paul said, I will be the proposed one to server as I.MX uboot
custodian for the next step. I'm
willing to work with any volunteered to maintain the I.MX uboot and
support it well. As you know, the time is Chinese new year and I have
very limitted access to the network. I will back on this weekend.
Thanks Stefano and Detlev for help in this time.
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply
* Re: crypto_shash_update & CRYPTO_TFM_REQ_MAY_SLEEP
From: Dmitry Kasatkin @ 2010-02-16 7:05 UTC (permalink / raw)
To: ext Herbert Xu; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <20100216065844.GA28436@gondor.apana.org.au>
Hi,
How is it possible to wait for completion here?: shash.c
shash_compat_digest()
{
....
data = crypto_kmap(sg_page(sg), 0);
err = crypto_shash_digest(desc, data + offset, nbytes, out);
crypto_kunmap(data, 0);
....
}
It happens as single operation/call.
Thanks,
Dmitry
ext Herbert Xu wrote:
> On Tue, Feb 16, 2010 at 08:36:08AM +0200, Dmitry Kasatkin wrote:
>
>> Hi,
>>
>> we have HW accelerator which can be accessed without DMA.
>> CPU just sequentially writes data to the port and then reads result.
>>
>
> Well if that's the case then you definitely don't need anything
> other than kmap_atomic. You should be able to map it atomically,
> write the data out, unmap it, and then wait for the completion.
>
> Non-atomic kmaps should be avoided if at all possible.
>
> Cheers,
>
^ permalink raw reply
* Re: [PATCH 01/12] mm: Document /proc/pagetypeinfo
From: KOSAKI Motohiro @ 2010-02-16 7:05 UTC (permalink / raw)
To: Mel Gorman
Cc: kosaki.motohiro, Andrea Arcangeli, Christoph Lameter, Adam Litke,
Avi Kivity, David Rientjes, linux-kernel, linux-mm
In-Reply-To: <1265976059-7459-2-git-send-email-mel@csn.ul.ie>
> The memory compaction patches add details to pagetypeinfo that are not
> obvious and need to be documented. In preparation for this, document
> what is already in /proc/pagetypeinfo.
>
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Looks nicer.
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> ---
> Documentation/filesystems/proc.txt | 45 +++++++++++++++++++++++++++++++++++-
> 1 files changed, 44 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
> index 0d07513..1829dfb 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -430,6 +430,7 @@ Table 1-5: Kernel info in /proc
> modules List of loaded modules
> mounts Mounted filesystems
> net Networking info (see text)
> + pagetypeinfo Additional page allocator information (see text) (2.5)
> partitions Table of partitions known to the system
> pci Deprecated info of PCI bus (new way -> /proc/bus/pci/,
> decoupled by lspci (2.4)
> @@ -584,7 +585,7 @@ Node 0, zone DMA 0 4 5 4 4 3 ...
> Node 0, zone Normal 1 0 0 1 101 8 ...
> Node 0, zone HighMem 2 0 0 1 1 0 ...
>
> -Memory fragmentation is a problem under some workloads, and buddyinfo is a
> +External fragmentation is a problem under some workloads, and buddyinfo is a
> useful tool for helping diagnose these problems. Buddyinfo will give you a
> clue as to how big an area you can safely allocate, or why a previous
> allocation failed.
> @@ -594,6 +595,48 @@ available. In this case, there are 0 chunks of 2^0*PAGE_SIZE available in
> ZONE_DMA, 4 chunks of 2^1*PAGE_SIZE in ZONE_DMA, 101 chunks of 2^4*PAGE_SIZE
> available in ZONE_NORMAL, etc...
>
> +More information relevant to external fragmentation can be found in
> +pagetypeinfo.
> +
> +> cat /proc/pagetypeinfo
> +Page block order: 9
> +Pages per block: 512
> +
> +Free pages count per migrate type at order 0 1 2 3 4 5 6 7 8 9 10
> +Node 0, zone DMA, type Unmovable 0 0 0 1 1 1 1 1 1 1 0
> +Node 0, zone DMA, type Reclaimable 0 0 0 0 0 0 0 0 0 0 0
> +Node 0, zone DMA, type Movable 1 1 2 1 2 1 1 0 1 0 2
> +Node 0, zone DMA, type Reserve 0 0 0 0 0 0 0 0 0 1 0
> +Node 0, zone DMA, type Isolate 0 0 0 0 0 0 0 0 0 0 0
> +Node 0, zone DMA32, type Unmovable 103 54 77 1 1 1 11 8 7 1 9
> +Node 0, zone DMA32, type Reclaimable 0 0 2 1 0 0 0 0 1 0 0
> +Node 0, zone DMA32, type Movable 169 152 113 91 77 54 39 13 6 1 452
> +Node 0, zone DMA32, type Reserve 1 2 2 2 2 0 1 1 1 1 0
> +Node 0, zone DMA32, type Isolate 0 0 0 0 0 0 0 0 0 0 0
> +
> +Number of blocks type Unmovable Reclaimable Movable Reserve Isolate
> +Node 0, zone DMA 2 0 5 1 0
> +Node 0, zone DMA32 41 6 967 2 0
> +
> +Fragmentation avoidance in the kernel works by grouping pages of different
> +migrate types into the same contiguous regions of memory called page blocks.
> +A page block is typically the size of the default hugepage size e.g. 2MB on
> +X86-64. By keeping pages grouped based on their ability to move, the kernel
> +can reclaim pages within a page block to satisfy a high-order allocation.
> +
> +The pagetypinfo begins with information on the size of a page block. It
> +then gives the same type of information as buddyinfo except broken down
> +by migrate-type and finishes with details on how many page blocks of each
> +type exist.
> +
> +If min_free_kbytes has been tuned correctly (recommendations made by hugeadm
> +from libhugetlbfs http://sourceforge.net/projects/libhugetlbfs/), one can
> +make an estimate of the likely number of huge pages that can be allocated
> +at a given point in time. All the "Movable" blocks should be allocatable
> +unless memory has been mlock()'d. Some of the Reclaimable blocks should
> +also be allocatable although a lot of filesystem metadata may have to be
> +reclaimed to achieve this.
> +
> ..............................................................................
>
> meminfo:
> --
> 1.6.5
>
^ permalink raw reply
* Re: [PATCH 01/12] mm: Document /proc/pagetypeinfo
From: KOSAKI Motohiro @ 2010-02-16 7:05 UTC (permalink / raw)
To: Mel Gorman
Cc: kosaki.motohiro, Andrea Arcangeli, Christoph Lameter, Adam Litke,
Avi Kivity, David Rientjes, linux-kernel, linux-mm
In-Reply-To: <1265976059-7459-2-git-send-email-mel@csn.ul.ie>
> The memory compaction patches add details to pagetypeinfo that are not
> obvious and need to be documented. In preparation for this, document
> what is already in /proc/pagetypeinfo.
>
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Looks nicer.
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> ---
> Documentation/filesystems/proc.txt | 45 +++++++++++++++++++++++++++++++++++-
> 1 files changed, 44 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
> index 0d07513..1829dfb 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -430,6 +430,7 @@ Table 1-5: Kernel info in /proc
> modules List of loaded modules
> mounts Mounted filesystems
> net Networking info (see text)
> + pagetypeinfo Additional page allocator information (see text) (2.5)
> partitions Table of partitions known to the system
> pci Deprecated info of PCI bus (new way -> /proc/bus/pci/,
> decoupled by lspci (2.4)
> @@ -584,7 +585,7 @@ Node 0, zone DMA 0 4 5 4 4 3 ...
> Node 0, zone Normal 1 0 0 1 101 8 ...
> Node 0, zone HighMem 2 0 0 1 1 0 ...
>
> -Memory fragmentation is a problem under some workloads, and buddyinfo is a
> +External fragmentation is a problem under some workloads, and buddyinfo is a
> useful tool for helping diagnose these problems. Buddyinfo will give you a
> clue as to how big an area you can safely allocate, or why a previous
> allocation failed.
> @@ -594,6 +595,48 @@ available. In this case, there are 0 chunks of 2^0*PAGE_SIZE available in
> ZONE_DMA, 4 chunks of 2^1*PAGE_SIZE in ZONE_DMA, 101 chunks of 2^4*PAGE_SIZE
> available in ZONE_NORMAL, etc...
>
> +More information relevant to external fragmentation can be found in
> +pagetypeinfo.
> +
> +> cat /proc/pagetypeinfo
> +Page block order: 9
> +Pages per block: 512
> +
> +Free pages count per migrate type at order 0 1 2 3 4 5 6 7 8 9 10
> +Node 0, zone DMA, type Unmovable 0 0 0 1 1 1 1 1 1 1 0
> +Node 0, zone DMA, type Reclaimable 0 0 0 0 0 0 0 0 0 0 0
> +Node 0, zone DMA, type Movable 1 1 2 1 2 1 1 0 1 0 2
> +Node 0, zone DMA, type Reserve 0 0 0 0 0 0 0 0 0 1 0
> +Node 0, zone DMA, type Isolate 0 0 0 0 0 0 0 0 0 0 0
> +Node 0, zone DMA32, type Unmovable 103 54 77 1 1 1 11 8 7 1 9
> +Node 0, zone DMA32, type Reclaimable 0 0 2 1 0 0 0 0 1 0 0
> +Node 0, zone DMA32, type Movable 169 152 113 91 77 54 39 13 6 1 452
> +Node 0, zone DMA32, type Reserve 1 2 2 2 2 0 1 1 1 1 0
> +Node 0, zone DMA32, type Isolate 0 0 0 0 0 0 0 0 0 0 0
> +
> +Number of blocks type Unmovable Reclaimable Movable Reserve Isolate
> +Node 0, zone DMA 2 0 5 1 0
> +Node 0, zone DMA32 41 6 967 2 0
> +
> +Fragmentation avoidance in the kernel works by grouping pages of different
> +migrate types into the same contiguous regions of memory called page blocks.
> +A page block is typically the size of the default hugepage size e.g. 2MB on
> +X86-64. By keeping pages grouped based on their ability to move, the kernel
> +can reclaim pages within a page block to satisfy a high-order allocation.
> +
> +The pagetypinfo begins with information on the size of a page block. It
> +then gives the same type of information as buddyinfo except broken down
> +by migrate-type and finishes with details on how many page blocks of each
> +type exist.
> +
> +If min_free_kbytes has been tuned correctly (recommendations made by hugeadm
> +from libhugetlbfs http://sourceforge.net/projects/libhugetlbfs/), one can
> +make an estimate of the likely number of huge pages that can be allocated
> +at a given point in time. All the "Movable" blocks should be allocatable
> +unless memory has been mlock()'d. Some of the Reclaimable blocks should
> +also be allocatable although a lot of filesystem metadata may have to be
> +reclaimed to achieve this.
> +
> ..............................................................................
>
> meminfo:
> --
> 1.6.5
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [patch] mm: add comment about deprecation of __GFP_NOFAIL
From: David Rientjes @ 2010-02-16 7:03 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Andrew Morton, Rik van Riel, Nick Piggin, Andrea Arcangeli,
Balbir Singh, Lubos Lunak, KOSAKI Motohiro, linux-kernel,
linux-mm
In-Reply-To: <20100216102626.5f6f0e11.kamezawa.hiroyu@jp.fujitsu.com>
On Tue, 16 Feb 2010, KAMEZAWA Hiroyuki wrote:
> I hope no 3rd vendor (proprietary) driver uses __GFP_NOFAIL, they tend to
> believe API is trustable and unchanged.
>
I hope they don't use it with GFP_ATOMIC, either, because it's never been
respected in that context. We can easily audit the handful of cases in
the kernel that use __GFP_NOFAIL (it takes five minutes at the max) and
prove that none use it with GFP_ATOMIC or GFP_NOFS. We don't need to add
multitudes of warnings about using a deprecated flag with ludicrous
combinations (does anyone really expect GFP_ATOMIC | __GFP_NOFAIL to work
gracefully)?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [patch] mm: add comment about deprecation of __GFP_NOFAIL
From: David Rientjes @ 2010-02-16 7:03 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Andrew Morton, Rik van Riel, Nick Piggin, Andrea Arcangeli,
Balbir Singh, Lubos Lunak, KOSAKI Motohiro, linux-kernel,
linux-mm
In-Reply-To: <20100216102626.5f6f0e11.kamezawa.hiroyu@jp.fujitsu.com>
On Tue, 16 Feb 2010, KAMEZAWA Hiroyuki wrote:
> I hope no 3rd vendor (proprietary) driver uses __GFP_NOFAIL, they tend to
> believe API is trustable and unchanged.
>
I hope they don't use it with GFP_ATOMIC, either, because it's never been
respected in that context. We can easily audit the handful of cases in
the kernel that use __GFP_NOFAIL (it takes five minutes at the max) and
prove that none use it with GFP_ATOMIC or GFP_NOFS. We don't need to add
multitudes of warnings about using a deprecated flag with ludicrous
combinations (does anyone really expect GFP_ATOMIC | __GFP_NOFAIL to work
gracefully)?
^ 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.