These flags are defined in kernel/sched/sched.h and are used when enabling/disabling migration for a task in core.c. I haven't been able to determine what SCA is short for from looking at the code or patch notes.
I spent two hours trying to dig it up from kernel's Git history and it seems the first apparition of this prefix starts from commit 9cfc3e18adb0362533e911bf3ce6ec8c821cfccc, which says :
sched: Massage set_cpus_allowed()
Thread a u32 flags word through the set_cpus_allowed () callchain.
This will allow adding behavioural tweaks for future users.
I believe this is what it means.
Related
Using uClinux we have one of two flash devices installed, a 1GB flash or a 2GB flash.
The only way I can think of solving this is to somehow get the device ID - which is down the in the device driver code, for me that is in:
drivers/mtd/devices/m25p80.c
I have been using the command mtdinfo (which comes from mtdutils binaries, derived from mtdinfo.c/h). There is various information stored in here about the flash partitions including flash type 'nor' eraseblock size '65536', etc. But nothing that I can identify the chip with.
Its not very clear to me how I can get information from "driver-land" into "user-land". I am looking at trying to extend the mtdinfo command to print more information but there are many layers...
What is the best way to achieve this?
At the moment, I have found no easy way to do this without code changes. However I have found an easy code change (probably a bit of a hack) that allows me to get the information I need:
In the relevant file (in my case drivers/mtd/devices/m25p80.c) you can call one of the following:
dev_err("...");
dev_alert("...");
dev_warn("...");
dev_notice("...");
_dev_info("...");
Which are defined in include/Linux/device.h, so they are part of the Linux driver interface so you can use them from any driver.
I found that the dev_err() and devalert() both get printed out "on screen" during run time. However all of these device messages can be found in /var/log/messages. Since I added messages in the format: dev_notice("JEDEC id %06x\n", jedecid);, I could find the device ID with the following command:
cat /var/log/messages | grep -i jedec
Obviously using dev_err() ordev_alert() is not quite right! - but dev_notice() or even _dev_info() seem more appropriate.
Not yet marking this as the answer since it requires code changes - still hoping for a better solution if anyone knows of one...
Update
Although the above "solution" works, its a bit crappy - certainly will do the job and good enough for mucking around. But I decided that if I am making code changes I may as well do it properly. So I have now implemented changes to add an interface in sysfs such that you can get the flash id with the following command:
cat /sys/class/m25p80/m25p80_dev0/device_id
The main function calls required for this are (in this order):
alloc_chrdev_region(...)
class_create(...)
device_create(...)
sysfs_create_group(...)
This should give enough of a hint for anyone wanting to do the same, though I can expand on that answer if anyone wants it.
so my friend asked me to write my own implementation for above function NVIC_Enable_IRQ(CAN1_RX0_IRQn); to enable can reception interrupt.
initially i thought its impossible to right such implementation ..
could anybody please explain me like the register associated with NVIC where i directly go and change the required value ,so that there is no need of implementation of above function and CAN reception interrupt is enabled.
this line NVIC_EnableIRQ(CAN1_RX0_IRQn); i copied from example code given in stm32f example code of CAN
Everything that starts with NVIC_ is part of the CMSIS library supplied by ARM to set up the ARM core (which is independent of the MCU manufacturer). You don't really want to mess with them, so you'd better use them.
In the CMSIS core_cm4.h (for a cortex M4), you can find:
__STATIC_INLINE void NVIC_EnableIRQ(IRQn_Type IRQn)
{
NVIC->ISER[(((uint32_t)(int32_t)IRQn) >> 5UL)] = (uint32_t)(1UL << (((uint32_t)(int32_t)IRQn) & 0x1FUL));
}
Now, if you don't want to call NVIC_EnableIRQ or if you don't want to use the CMSIS, well good luck, you need to read the ARM core documentation to check which addresses you need to modify. The ARM core documentation can be found on the ARM or Keil website. For example, you might find those links useful for the Cortex M4:
https://www.arm.com/products/processors/cortex-m/cortex-m4-processor.php
http://www.keil.com/dd/docs/datashts/arm/cortex_m4/r0p1/dui0553a_cortex_m4_dgug.pdf
Rfid Readers perform switches between antennas while using multiple antennas. Reader runs one antenna while others sleeping and switches one by one. It makes it fast so running one antenna at a time doesn't matter. According to my observations, the time for every switch is 1 second.
(After sometime I realised this 1 second is only for Motorola FX7500. Most other readers do it the right way, light fast like in miliseconds)
That is what I know so far.
Now, in my specific application I need this procedure to run faster, like 200ms instead of 1s.
Is this value changeable? If so, which message and parameter in LLRP can modify this value?
Actually the 1 second problem is with MotorolaFX7500 reader. By examining LLRP messages that Motorola's own library generates between FC7500, I discovered there are vendor specific parameters that can be used via custom extensions fields of LLRP. These params and settings can be found in Motorola Readers' software guide. This switch time is one of these vendor specific parameters, it's not a parameter of generic LLRP. A piece of code generating LLRP message including the custom extension with the proper format, solved my issue.
I am trying to measure certain hardware events on a (Intel Xeon) machine with multiple (physical) processors. Specifically, I wish to know how many requests are issued for reading 'offcore' data.
I found the OFFCORE_REQUESTS hardware event in Intels documentation and it gives the event descriptor 0xB0 and for data demands, the additional mask 0x01.
Would it then be correct to tell perf to record the event 0xB1 (i.e. 0xB0 | 0x01) and to call it as:
perf record -e r0B1 ./mytestapp someargs
Or is this incorrect?
Because perf report shows no output for events entered like this.
The perf documentation is rather sparse in this area, apart from a tutorial entry which does not say which event it was (though this one works for me), or how it was encoded...
Any help is greatly appreciated.
Ok, so I guess I figured it out.
For the the Intel machine I use, the format is as follows:
<umask><eventselector> where both are hexadecimal values. The leading zeros of the umask can be dropped, but not for the event selector.
So for the event 0xB0 with the mask 0x01 I can call:
perf record -e r1B0 ./mytestapp someargs
I could not manage to find the exact parsing of it in the perf kernel code (any kernel hacker here?), but I found these sources:
A description of the use of perf with raw events in the c't magazine 13/03 (subscription required), which describes some raw events with their description from the Intel Architecture Software Developers Manuel (Vol 3b)
A patch on the kernel mailing list, discussing the proper way to document it. It specified that the pattern above was "... was x86 specific and imcomplete at that"
(Updated) The man page of newer versions shows an example on Intel machines: man perf-list
Update:
As pointed out in the comments (thank you!), the libpfm translator can be used to obtain the proper event descriptor. The website linked in the comments (Bojan Nikolic: How to monitor the full range of CPU performance events), discovered by user 'osgx' explains it in further detail.
It seems you can use as well:
perf record -e cpu/event=0xB1,umask=0x1/u ./mytestapp someargs
I don't know where this syntax is documented.
You can probably use the other arguments (edge, inv, cmask) as well.
There are several libraries which can be helpful to work with raw PMU events.
perf's own wiki https://perf.wiki.kernel.org/index.php/Tutorial#Events recommends perf list --help man page for info about raw events encoding. And modern perf versions will list raw events as part of perf list output ("... if linked against the libpfm4 library, provides some short description of the events."). perf list --details will also print raw ids and masks of events.
Bojan Nikolic has "How to monitor the full range of CPU performance events" blog article about libpfm4 (perfmon2) lib usage to encode raw events for perf with help of showevtinfo and check_events tools, which are provided with the same library.
There is also perf python wrapper ocperf which accepts intel's event names. It is written by Andi Kleen (Intel Open Source Technology Center) as part of pmu-tools set of utilities (LWN post from 2013, event lists by intel at https://download.01.org/perfmon/). There is a demo of ocperf (2011) http://halobates.de/modern-pmus-yokohama.pdf:
ocperf
•Perf wrapper to support Intel specific events
•Allows symbolic events and some additional events
ocperf record -a −e offcore_response.any_data.remote_dram_0 sleep 10
PAPI library also has tool to explore raw events with some descriptions - papi_native_avail.
What is the procedure for generating the Initial Sequence Numbers (ISN)
in LINUX tcp/ip protocol. I know the procedure for ISN generation in
the LINUX kernels 2.4 to 2.6 that are described in pages 7 & 8 of
Embedding Covert Channels into TCP/IP. I have searched for similar
procedures in later kernels, but to my dismay I couldn't find any. I understand that much details may not be available for obvious reasons related to security. As I'm verifying the possibilities of implementing a similar steganography scheme(as described in the link) in the later Linux kernels, I am badly in need of some information. Any help is appreciated.
Read my answer here:
Most efficient way to manipulate ISN numbers in TCP headers
This algorithm is used on the latest kernel TCP Stack (3.5).
EDIT : See image below to see all concerned kernels versions
EDIT2 : See the sources of the kernel for older versions of the function secure_tcp_sequence_number:
Kernel 2.4.22
Kernel 2.6.30
Kernel 2.6.39
Kernel 3.0
Kernel 3.1 : (MD5 has replaced half-MD4)
After more careful reading of RFC6528 and RFC1948 I came to a conclusion that the algorithm for generating Initial Sequence Numbers(ISNs) as specified in RFC1948 :
ISN = M + F(LocalIP, LocalPort, RemoteIP, RemotePort, Secretkey)
has not changed. Instead, the algorithm which was proposed by Bellovin S.M in RFC1948 is formally specified and taken into the Standards Track(as per RFC2119) in RFC6528 which was written together by Bellovin S.M and Gont. F.. As the now obsolete RFC1948 can't be used in any documentations, RFC6528 has replaced it.
But as pointed out in the answer to my original question MD5 has replaced half-MD4 as the Hash Function from kernels 3.1. This is completely justified by RFC6528 as it did give the flexibility to change F() which is the Pseudo-Random function.
(Please have a look at the links for more details).
Update to previous answers so that to represent current state (2019 and Linux kernel 5.1.3) because algorithm to generate ISNs in the kernel was changed again to be more secure.
secure_tcp_seq now uses SipHash (add–rotate–xor) functions to generate ISN based on initial secret key, source and destination IP address and port. I suppose this change was related to hash collision vulnerability resulted in hash flooding attacks.