karthick18

/*
 * Simple power-of-2 Allocate only mem-group for use with scatter-gather lists with read-write protection 
 * on the objects allocated from the memory group.
 */

#include<stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <assert.h>

karthick18

#define _GNU_SOURCE /*for CPU affinity macros/routine*/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <ctype.h>
#include <assert.h>
#include <sched.h>
/*
 * poor mans profiler. cpu tsc for x86 though would be skewed with cpufreq sched,etc.
 * but still better for approximations.

karthick18

Single-line version of pattern:

(?i)\b((?:[a-z][\w-]+:(?:/{1,3}|[a-z0-9%])|www\d{0,3}[.]|[a-z0-9.\-]+[.][a-z]{2,4}/)(?:[^\s()<>]+|\(([^\s()<>]+|(\([^\s()<>]+\)))*\))+(?:\(([^\s()<>]+|(\([^\s()<>]+\)))*\)|[^\s`!()\[\]{};:'".,<>?«»“”‘’]))


Extended version of same pattern:

(?xi)
\b
(							# Capture 1: entire matched URL

karthick18

/*
 * DONT USE strncpy
 * Compile with -m32 if on x86_64
 * Moral of the story: If you have large buffers to be strncpy'ed,
 * dont use it and use a strncat by zeroing off the first byte in the destination. which is
 * atleast 2x faster based on the bytes left to be zeroed by strncpy to the destination.
 * In short, dont use strncpy :-)
 */
#define _GNU_SOURCE
#include <stdio.h>

karthick18

int main()
{
	__asm__(";foo");
	char a[1024] = {0,};
	__asm__(";end");
/*
# 4 "x.c" 1
        ;foo
# 0 "" 2
        leal    12(%esp), %ebx

karthick18

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <pthread.h>

typedef struct pthread_rwlock_wrapper
{
    pthread_rwlock_t rwlock;
    pthread_spinlock_t spinlock;

karthick18

/*
 * The below code is an effort to reproduce a kernel panic. (not successful yet)
 * Trying hard to reproduce a kernel panic in my laptop(SMP dual-core T7100, 4gig ram) running 2.6.36-rc8 (linus-git) 
 * The panic is consistently reproducible with our distributed product runtime and log directories 
 * mount binded to a USB drive in my laptop(ext4).
 * The trick is to pull the USB drive (ejecting) while our processes are up.
 * It always crashes the kernel in __mark_inode_dirty while trying to resolve a write protect page fault in our log server process 
 * which flushes from shared memory to disk (in this case, the disk was mount binded to the USB drive)
 * The panic is a result of the inodes backing device marker becoming NULL (probably the inode flag check in __mark_inode_dirty: fs/fs-writeback.c: 978) for skipping an inode based on its state needs to be fixed. 
 * But can check that only if I am able to reproduce the issue through a     

karthick18

/*
 * The below code is an effort to reproduce a kernel panic in __mark_inode_dirty triggered by a USB device pull
 * while in the middle of writes to the disk. The issue is _consistently_ reproducible with our product runtime
 * and log directories mount-binded to the USB drive and ejecting the USB drive while they are running.
 * My 4 and a half yr old daughter has to be credited with reproducing the issue since I first observed the
 * panic when she mercilessly pulled the USB cable while I was working :) After that, I have been trying hard
 * to isolate the issue outside our product code without much success. 
 * The below code is an effort to reproduce an ext4 uninterruptibe task hang by trying
 * to create many mmapped files from child processes logging to a USB backing storage and forcefully ejecting
 * the USB drive in the middle of such writes. This code is a variant of another unsuccessful kernel-panic test code

karthick18

/*
 * A simple on-demand based mmap alloc-only proof-of-concept to just check out the possibilities of having a 
 * single giant MAP_FIXED allocation for a process that may not need to call free at all and just work with a
 * contiguous allocation space 
 *
 * A mmap contiguous hole space is reserved with a PROT_READ and then individual pages overridden with 
 * PROT_WRITE on page faults in sigsegv handler which mmaps the faulting address space.
 *
 * As a test, a 1 GIG file is created and then read into the memory allocated from the contiguous vma which is a
 * brain-dead linear allocator from the address space as there are no requirements to free memory here.

karthick18

CC := gcc
CFLAGS := -Wall -g -std=c99
LD_LIBS := -lpthread 
ARCH := $(shell uname)
BLOCK_SIZE := 1m
ifeq ("$(strip $(ARCH))", "Linux")
	LD_LIBS += -lrt
	BLOCK_SIZE := 1M
endif
SRCS := prsort.c