barrier()
Pranay Kumar Srivastava
Pranay.Shrivastava at hcl.com
Mon Feb 25 03:21:05 EST 2013
> -----Original Message-----
> From: kernelnewbies-
> bounces+pranay.shrivastava=hcl.com at kernelnewbies.org
> [mailto:kernelnewbies-
> bounces+pranay.shrivastava=hcl.com at kernelnewbies.org] On Behalf Of
> kernelnewbies-request at kernelnewbies.org
> Sent: Monday, February 25, 2013 12:55 PM
> To: kernelnewbies at kernelnewbies.org
> Subject: Kernelnewbies Digest, Vol 27, Issue 52
>
> Send Kernelnewbies mailing list submissions to
> kernelnewbies at kernelnewbies.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> or, via email, send a message with subject or body 'help' to
> kernelnewbies-request at kernelnewbies.org
>
> You can reach the person managing the list at
> kernelnewbies-owner at kernelnewbies.org
>
> When replying, please edit your Subject line so it is more specific than "Re:
> Contents of Kernelnewbies digest..."
>
>
> Today's Topics:
>
> 1. Re: atomic operations (Valdis.Kletnieks at vt.edu)
> 2. valid address space ? (Abu Rasheda)
> 3. Re: valid address space ? (Abu Rasheda)
> 4. barrier() (Shraddha Kamat)
> 5. Re: test jiffies on ARM SMP board (bill4carson)
> 6. Re: test jiffies on ARM SMP board (bill4carson)
> 7. Re: atomic operations (Kumar amit mehta)
> 8. (Prasad Lakshman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 24 Feb 2013 18:24:21 -0500
> From: Valdis.Kletnieks at vt.edu
> Subject: Re: atomic operations
> To: richard -rw- weinberger <richard.weinberger at gmail.com>
> Cc: Shraddha Kamat <sh2008ka at gmail.com>, kernelnewbies
> <kernelnewbies at kernelnewbies.org>
> Message-ID: <6017.1361748261 at turing-police.cc.vt.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> On Sun, 24 Feb 2013 11:50:14 +0100, richard -rw- weinberger said:
> > On Sun, Feb 24, 2013 at 10:42 AM, Shraddha Kamat <sh2008ka at gmail.com>
> wrote:
> > > what is the relation between atomic operations and memory alignment ?
> > >
> > > I read from UTLK that "an unaligned memory access is not atomic"
> > >
> > > please explain me , I am not able to get the relationship between
> > > memory alignment and atomicity of the operation.
> >
> > Not all CPUs support unaligned memory access, such an access may cause
> > a fault which needs to be fixed by the kernel...
>
> There's a more subtle issue - an unaligned access can be split across a cache
> line boundary, requiring 2 separate memory accesses to do the read or write.
> This can result in CPU A fetching the first half of the variable, CPU B updating
> both halves, and then A fetching the second half of the now updated
> variable.. This can bite you even on CPUs that support unaligned accesses.
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 865 bytes
> Desc: not available
> Url :
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130
> 224/d2bc34b0/attachment-0001.bin
>
> ------------------------------
>
> Message: 2
> Date: Sun, 24 Feb 2013 19:24:10 -0800
> From: Abu Rasheda <rcpilot2010 at gmail.com>
> Subject: valid address space ?
> To: Linux Kernel List <kernelnewbies at kernelnewbies.org>
> Message-ID:
> <CACYKDtgw5+8HdSaKgVSN6S7qT-NkiQr=w-
> WdA0C+1DuigCDJ_g at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I am trying to dump some kernel data structure (walk e.g. task or file data
> structure on x86_64 arch). Sometime accessing through a pointer, pointer
> may not be NULL, but pointing to invalid address due to garbage value.
>
> What I am looking for is range of address which are valid for kernel data
> structure. Is it correct to say following address are valid ?
>
> - Bit 0 - 47 are considered
> - Between FFFF8000'00000000 through FFFFFFFF'FFFFFFFF
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130
> 224/bfaaacb1/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Sun, 24 Feb 2013 21:37:48 -0800
> From: Abu Rasheda <rcpilot2010 at gmail.com>
> Subject: Re: valid address space ?
> To: Linux Kernel List <kernelnewbies at kernelnewbies.org>
> Message-ID:
> <CACYKDth+Lv87TmJXGK8tWUmREhrkrT5t9-
> gyFtcAZH8SvtWKcA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Sunday, February 24, 2013, Abu Rasheda wrote:
>
> > I am trying to dump some kernel data structure (walk e.g. task or file
> > data structure on x86_64 arch). Sometime accessing through a pointer,
> > pointer may not be NULL, but pointing to invalid address due to
> > garbage value.
> >
> > What I am looking for is range of address which are valid for kernel
> > data structure. Is it correct to say following address are valid ?
> >
> > - Bit 0 - 47 are considered
> > - Between FFFF8000'00000000 through FFFFFFFF'FFFFFFFF
> >
>
> Will this cover all situations
>
> if (long_ptr > 0x1000)
> {
> tmp_long_ptr = ((long_ptr & 0x800000000000) ? (long_ptr |
> 0xffff800000000000) : (long_ptr & 0xFFFFFFFFFFFF)); printf("tmp_long_ptr
> :0x%llx\n", (long long int) tmp_long_ptr);
> if ((long_ptr == tmp_long_ptr) & (long_ptr >= 0x30000000))
> printf("valid 64 addr\n");
> }
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130
> 224/b8a6e457/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Mon, 25 Feb 2013 12:26:06 +0530
> From: Shraddha Kamat <sh2008ka at gmail.com>
> Subject: barrier()
> To: kernelnewbies <kernelnewbies at kernelnewbies.org>
> Message-ID: <1361775366.22170.27.camel at oc5268484881.ibm.com>
> Content-Type: text/plain; charset="UTF-8"
>
> #define barrier() asm volatile("" ::: "memory")
>
> What exactly volatile("" ::: "memory") doing here ?
> I was referring to gnu as (ver 2.14) manual but could not get much clue about
> this assembly construct - any pointers ?
[Pranay Kumar Srivastava] From the extended GCC inline assembly manual the last : begins the list of clobber registers so that GCC accidentally doesn't use them if you've used some of the registers. I looked upon this page http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html and its written here something about the special memory keyword. It goes something like the following
" If your assembler instructions access memory in an unpredictable fashion, add `memory' to the list of clobbered registers. This causes GCC to not keep memory values cached in registers across the assembler instruction and not optimize stores or loads to that memory. You also should add the volatile keyword if the memory affected is not listed in the inputs or outputs of the asm, as the `memory' clobber does not count as a side-effect of the asm. If you know how large the accessed memory is, you can add it as input or output but if this is not known, you should add `memory' "
There's also a nice small example on that page. I hope that helps.
Regards
P.K.S
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 25 Feb 2013 15:02:39 +0800
> From: bill4carson <bill4carson at gmail.com>
> Subject: Re: test jiffies on ARM SMP board
> To: kernelnewbies at kernelnewbies.org
> Message-ID: <512B0C8F.30402 at gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
>
>
> On 2013?02?21? 00:39, buyitian wrote:
> > i am confused about my test. in one device driver,
> > i put below code:
> >
> > printk("start to test test jiffies\n");
> >
> > local_irq_save(flags);
> >
> > jf1 = jiffies; // read jiffies first time
> >
> > // hold cpu for about 2 seconds(do some calculation)
> >
> > jf2 = jiffies; // read jiffies after 2 seconds
> >
> > local_irq_restore(flags);
> >
> > printk("jf1:%lu, jf2:%lu\n", jf1, jf2);
> >
> > and the output is as below:
> >
> > <4>[ 108.551124]start to test test jiffies
> > <4>[ 110.367604]jf1:4294948151, jf2:4294948151
> >
> > the jf1 and jf2 are the same value, although they are
> > read between 2 seconds interval, i think this is because
> > i disabled local interrupt.
> > but the printk timestamp is from 108.551124 to 110.367604,
> > which is about 2 seconds. and on my platform, printk timestamp
> > is got from the function read_sched_clock:
> > static u32 __read_mostly (*read_sched_clock)(void) =
> jiffy_sched_clock_read;
> >
> > and function jiffy_sched_clock_read() is to read from jiffies.
> >
> > it seems that the jiffies is frozen when local irq is disabled,
> > but after local_irq_restore(), the jiffies not only start
> > to run, but also recover the lost 2 seconds.
> >
> > is the jiffies updated from another cpu when irq is disabled on
> > local cpu?
> >
> > is there some internel processor interrupt between cpu1 and cpu0
> > after local irq is re-enabled so that jiffies recover the lost 2 seconds?
>
>
> 80 /*
> 81 * Event handler for periodic ticks
> 82 */
> 83 void tick_handle_periodic(struct clock_event_device *dev)
> 84 {
> 85 int cpu = smp_processor_id();
> 86 ktime_t next;
> 87
> 88 tick_periodic(cpu);
> 89
> 90 if (dev->mode != CLOCK_EVT_MODE_ONESHOT)
> 91 return;
> 92 /*
> 93 * Setup the next period for devices, which do not have
> 94 * periodic mode:
> 95 */
> 96 next = ktime_add(dev->next_event, tick_period);
> 97 for (;;) {
> 98 if (!clockevents_program_event(dev, next, ktime_get())) <--- once
> irq enabled, here we got -ETIME, then
> 99 return;
> 100 /*
> 101 * Have to be careful here. If we're in oneshot mode,
> 102 * before we call tick_periodic() in a loop, we need
> 103 * to be sure we're using a real hardware clocksource.
> 104 * Otherwise we could get trapped in an infinite
> 105 * loop, as the tick_periodic() increments jiffies,
> 106 * when then will increment time, posibly causing
> 107 * the loop to trigger again and again.
> 108 */
> 109 if (timekeeping_valid_for_hres())
> 110 tick_periodic(cpu); <---- here, we add missing
> jiffies
> 111 next = ktime_add(next, tick_period);
> 112 }
> 113 }
>
>
>
>
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
>
> --
> ?????????,??????????
>
> --bill
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 25 Feb 2013 15:04:32 +0800
> From: bill4carson <bill4carson at gmail.com>
> Subject: Re: test jiffies on ARM SMP board
> To: Russell King - ARM Linux <linux at arm.linux.org.uk>
> Cc: anish kumar <anish198519851985 at gmail.com>,
> linux-omap at vger.kernel.org, buyitian <buyit at live.cn>,
> linux-arm-kernel at lists.infradead.org,
> "kernelnewbies at kernelnewbies.org"
> <kernelnewbies at kernelnewbies.org>
> Message-ID: <512B0D00.3000403 at gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
>
>
> On 2013?02?21? 01:30, Russell King - ARM Linux wrote:
> > On Wed, Feb 20, 2013 at 10:54:41PM +0530, anish kumar wrote:
> >> On Thu, 2013-02-21 at 00:39 +0800, buyitian wrote:
> >>> i am confused about my test. in one device driver,
> >>> i put below code:
> >>>
> >>> printk("start to test test jiffies\n");
> >>>
> >>> local_irq_save(flags);
> >>>
> >>> jf1 = jiffies; // read jiffies first time
> >>>
> >>> // hold cpu for about 2 seconds(do some calculation)
> >>>
> >>> jf2 = jiffies; // read jiffies after 2 seconds
> >>>
> >>> local_irq_restore(flags);
> >>>
> >>> printk("jf1:%lu, jf2:%lu\n", jf1, jf2);
> >>>
> >>> and the output is as below:
> >>>
> >>> <4>[ 108.551124]start to test test jiffies
> >>> <4>[ 110.367604]jf1:4294948151, jf2:4294948151
> >>>
> >>> the jf1 and jf2 are the same value, although they are
> >>> read between 2 seconds interval, i think this is because
> >>> i disabled local interrupt.
> >>> but the printk timestamp is from 108.551124 to 110.367604,
> >>> which is about 2 seconds. and on my platform, printk timestamp
> >>> is got from the function read_sched_clock:
> >>> static u32 __read_mostly (*read_sched_clock)(void) =
> jiffy_sched_clock_read;
> >>>
> >>> and function jiffy_sched_clock_read() is to read from jiffies.
> >>>
> >>> it seems that the jiffies is frozen when local irq is disabled,
> >>> but after local_irq_restore(), the jiffies not only start
> >>> to run, but also recover the lost 2 seconds.
> >>>
> >>> is the jiffies updated from another cpu when irq is disabled on
> >>> local cpu?
> >>>
> >>> is there some internel processor interrupt between cpu1 and cpu0
> >>> after local irq is re-enabled so that jiffies recover the lost 2 seconds?
>
> >> I think it is because of the fact that some RTC registers keep the
> >
> > The RTC has nothing to do with this.
> >
> > As soon as the IRQs are allowed again (immediately after the
> > local_irq_restore()) the pending interrupt - including the timer
> > interrupt will be processed.
> >
> > At this point, because we read the clocksource, we can see that two
> > seconds have passed, and so we advance jiffies by the elapsed time.
>
> 80 /*
> 81 * Event handler for periodic ticks
> 82 */
> 83 void tick_handle_periodic(struct clock_event_device *dev)
> 84 {
> 85 int cpu = smp_processor_id();
> 86 ktime_t next;
> 87
> 88 tick_periodic(cpu);
> 89
> 90 if (dev->mode != CLOCK_EVT_MODE_ONESHOT)
> 91 return;
> 92 /*
> 93 * Setup the next period for devices, which do not have
> 94 * periodic mode:
> 95 */
> 96 next = ktime_add(dev->next_event, tick_period);
> 97 for (;;) {
> 98 if (!clockevents_program_event(dev, next, ktime_get())) <--- once
> irq enabled, here we got -ETIME, then
> 99 return;
> 100 /*
> 101 * Have to be careful here. If we're in oneshot mode,
> 102 * before we call tick_periodic() in a loop, we need
> 103 * to be sure we're using a real hardware clocksource.
> 104 * Otherwise we could get trapped in an infinite
> 105 * loop, as the tick_periodic() increments jiffies,
> 106 * when then will increment time, posibly causing
> 107 * the loop to trigger again and again.
> 108 */
> 109 if (timekeeping_valid_for_hres())
> 110 tick_periodic(cpu); <---- here, we add missing
> jiffies
> 111 next = ktime_add(next, tick_period);
> 112 }
> 113 }
>
>
> >
> > This means printk() sees that the two seconds have passed. But because
> > you're reading from jiffies within the interrupt disabled region, that
> > code can't see the missed ticks.
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>
> --
> ?????????,??????????
>
> --bill
>
>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 24 Feb 2013 23:15:31 -0800
> From: Kumar amit mehta <gmate.amit at gmail.com>
> Subject: Re: atomic operations
> To: Peter Teoh <htmldeveloper at gmail.com>
> Cc: Shraddha Kamat <sh2008ka at gmail.com>, kernelnewbies
> <kernelnewbies at kernelnewbies.org>
> Message-ID: <20130225071531.GA3434 at gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Feb 24, 2013 at 08:53:20PM +0800, Peter Teoh wrote:
> > Another good article on atomicty and data sizes:
> >
> > http://www.ibm.com/developerworks/library/pa-atom/
> >
> > On Sun, Feb 24, 2013 at 8:50 PM, Peter Teoh <htmldeveloper at gmail.com>
> wrote:
> >
> > > in simple terms, any operation, in terms assembly instructions, which can
> > > be executed in ONE instruction, is "atomic", because, just like an atom, it
> > > cannot be broken up into parts. any instructions that is longer than one,
> > > for eg, TWO instruction, is NOT atomic, because in BETWEEN the first and
> > > 2nd instruction, something like an interrupt can come in, and affect the
> > > values of the operand when it is passed from instruction one to second
> > > instruction. To save me from reiteration:
> > >
> > > http://www.ibm.com/developerworks/library/pa-dalign/ (search for
> > > "atomicity").
> > >
> > > http://stackoverflow.com/questions/381244/purpose-of-memory-
> alignment
> > >
> > > http://lwn.net/Articles/260832/
> > >
> > > http://www.songho.ca/misc/alignment/dataalign.html
> > >
> > >
> > >
> http://www.cis.upenn.edu/~palsetia/cit595s08/Lectures08/alignmentOrderi
> ng.pdf
> > >
> > > Essentially, atomicity and non-alignment become problematic when u
> tried
> > > to to read using non-byte addressing mode with non-aligned address.
> > >
> > > On Sun, Feb 24, 2013 at 5:42 PM, Shraddha Kamat
> <sh2008ka at gmail.com>wrote:
> > >
> > >> what is the relation between atomic operations and memory alignment
> ?
> > >>
> > >> I read from UTLK that "an unaligned memory access is not atomic"
> > >>
> > >> please explain me , I am not able to get the relationship between
> > >> memory alignment and atomicity of the operation.
> It seems for this same reason, every objects of a struct page is organized as
> double word.
> <snip from linux/mm_types.h>
> * The objects in struct page are organized in double word blocks in
> * order to allows us to use atomic double word operations on portions
> * of struct page. That is currently only used by slub but the arrangement
> * allows the use of atomic double word operations on the flags/mapping
> * and lru list pointers also.
> <snip from linux/mm_types.h>
>
> -Amit
>
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 25 Feb 2013 12:54:32 +0530
> From: Prasad Lakshman <prasad.bl.emb at gmail.com>
> To: kernelnewbies at kernelnewbies.org
> Message-ID:
> <CALZm36W4+mzBfv3JrQq5uLRSiuo=tqb-
> nijna6Lx9FrBXGSivg at mail.gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> Hi ,
> I am trying to implement own system call in Linux. Kernel version I
> chose is 3.5.7
>
> I am following the steps from Linux Kernel Development 3rd edition.
> I got two problems with the implementation.
> 1.while trying to modify the code in kernel , there is no entry.S file
> for Intel x86 32 bit architecture. (my be i am missing some thing.)
> 2.while I am compiling user application with gcc I am getting
>
> error: unknown type name ?helloworld?
>
> my application is as follows
>
> #define __NR_helloworld 367
> __syscall0(long, helloworld)
>
> int main ()
> {
> printf("The helloworld system call is\n";
> helloworld();
> return 0;
> }
>
>
> I looked at Link [blog.163.com] which is given by Wanny but i could
> not find the solution,I could not locate syscall_table_32.s in my
> Linux source.
>
> Please help me in identifying the entry.S file for Intel x86 32 bit
> architecture in 3.5.7 kernel version sources,where i can make an entry
> for my system call into system call table.
>
> Help me in resolving error: unknown type name ?helloworld? in my
> application.
>
>
>
> ------------------------------
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
> End of Kernelnewbies Digest, Vol 27, Issue 52
> *********************************************
::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.
----------------------------------------------------------------------------------------------------------------------------------------------------
More information about the Kernelnewbies
mailing list