I am using signalfd() to monitor the death of child processes created by my process. If I kill a child process with a signal, parent gets a read event on the signal fd with signalfd_siginfo structure populated. It has a field ssi_code which is set to the signal number the child received (for example 9 if I sent SIGKILL to the child).
Can I rely on this behavior always ? All versions of Linux kernel where signalfd is supported has the same usage for this field ?
Note: If the child calls exit() then the code passed to exit is populated in ssi_code.
man page of signalfd states :
The format of the signalfd_siginfo structure(s) returned by read(2)s from a signalfd file descriptor is as follows:
struct signalfd_siginfo {
uint32_t ssi_signo; /* Signal number */
int32_t ssi_errno; /* Error number (unused) */
int32_t ssi_code; /* Signal code */
uint32_t ssi_pid; /* PID of sender */
uint32_t ssi_uid; /* Real UID of sender */
int32_t ssi_fd; /* File descriptor (SIGIO) */
uint32_t ssi_tid; /* Kernel timer ID (POSIX timers)
uint32_t ssi_band; /* Band event (SIGIO) */
uint32_t ssi_overrun; /* POSIX timer overrun count */
uint32_t ssi_trapno; /* Trap number that caused signal */
int32_t ssi_status; /* Exit status or signal (SIGCHLD) */
int32_t ssi_int; /* Integer sent by sigqueue(2) */
uint64_t ssi_ptr; /* Pointer sent by sigqueue(2) */
uint64_t ssi_utime; /* User CPU time consumed (SIGCHLD) */
uint64_t ssi_stime; /* System CPU time consumed (SIGCHLD) */
uint64_t ssi_addr; /* Address that generated signal
(for hardware-generated signals) */
uint8_t pad[X]; /* Pad size to 128 bytes (allow for
additional fields in the future) */
};
It seems clear : ssi_signo contains the signal number. It says about ssi_code that :
Not all fields in the returned signalfd_siginfo structure will be valid for a specific signal; the set of valid fields can be determined
from the value returned in the ssi_code field. This field is the
analog of the siginfo_t si_code field; see sigaction(2) for details.
See sigaction man page for more details about this code which is not the signal number.
Related
Using the latest sources from apple's open source repo I have derived the following structure for the "stat" struct (in go syntax):
type timespec struct {
tv_sec int32
tv_nsec uint32
}
type stat64 struct {
st_dev int32 /* [XSI] ID of device containing file */
st_mode uint16 /* [XSI] Mode of file (see below) */
st_nlink uint16 /* [XSI] Number of hard links */
st_ino uint64 /* [XSI] File serial number */
st_uid uint32 /* [XSI] User ID of the file */
st_gid uint32 /* [XSI] Group ID of the file */
st_rdev int32 /* [XSI] Device ID */
st_atimespec timespec /* time of last access */
st_mtimespec timespec /* time of last data modification */
st_ctimespec timespec /* time of last status change */
st_birthtimespec timespec /* time of file creation(birth) */
st_size int64 /* [XSI] file size, in bytes */
st_blocks int64 /* [XSI] blocks allocated for file */
st_blksize int32 /* [XSI] optimal blocksize for I/O */
st_flags uint32 /* user defined flags for file */
st_gen uint32 /* file generation number */
st_lspare int32 /* RESERVED: DO NOT USE! */
st_qspare [2]int64 /* RESERVED: DO NOT USE! */
}
but in practice it turns out st_size has an offset of 96 bytes instead of the 60 shown above. What's the cause of this discrepancy and how can this be seen from the original source code?
On OS X, both fields of struct timespec are long, which is 64-bit in the usual LP64 convention. Therefore, sizeof(struct timespec) == 16 (you can check this yourself), and it is aligned on a 64-bit boundary, giving you an offset of 96 for st_size.
I want to use the write sycall for copying a struct
from userspace to kernel.
In both user and kernel space, the struct is defined as
struct packet{
unsigned char packet[256];
int length;
}__attribute__ ((packed));
User space uses a local variable of type struct packet and passes it to the write syscall.
struct packet p;
/* ... (fill in data) */
printf("packet.length: %d\n",packet.length); /* looks correct */
result = write(uartFD, &p, sizeof(struct packet));
The kernel side looks like this, checking for correct length is done, just removed from example.
/* write syscall */
ssize_t packet_write(
struct file *file_ptr,
const char __user *user_buffer,
size_t count, loff_t *position)
{
struct packet p;
int retval;
if (copy_from_user((void*)&p, user_buffer, sizeof(struct packet))){
retval = -EACCES;
goto err;
}
/* looks wrong - different numbers like 96373062 or 96373958 */
printk("packet length: %d\n",p.length);
The opposite direction using read sycall is working as expected:
/* read syscall */
struct packet p;
/* ... (fill in data) */
copy_to_user(user_buffer, (void*)&p, sizeof(struct packet));
/* userspace */
read(uartFD, (void*)&packet, sizeof(struct packet));
What am I doing wrong with write syscall?
(Posted on behalf of the OP).
This is solved - it was my own silly. Both copying an integer and an unsigned char buffer separately was working, so it had to be something about the struct.
One site was packed, the other was not... reusing old code...
I am new to SCSI Programming and hence sorry for asking basic question. I sent SCSI Inquiry command to a Tape Device through 6 byte CDB
ccb = (Exec_IO_CCB *)( buffer + header_size );
ccb->ccb_length = sizeof(Exec_IO_CCB);
ccb->cam_opcode = 0x1;
ccb->connect_id = 0;
ccb->sense_buf_ptr = (long)(header_size + ccb->ccb_length);
ccb->sense_buf_length = MAX_SENSE_LEN;
ccb->time_out = CAM_TIMEOUT;
ccb->cdb_length = 6;
/* For INQUIRY sets cam_flags and cdb[0] */
ccb->cam_flags = NO_DATA;
ccb->cdb[0] = INQUIRY; /* 0x12 SCSI Opcode for Inquiry Command */
ccb->cdb[1] = 0;
ccb->cdb[2] = 0;
ccb->cdb[3] = 0;
ccb->cdb[4] = 3200;
ccb->cdb[5] = 0;
The SCSI Command is successful . How do i capture the output of INQUIRY command so that i can get
Vendor ID / Product ID ??
I have declared the Execute I/O SCSI buffer as follows
typedef struct {
long ccb_address; /* Address of this CCB */
short ccb_length; /* CAM Control Block Length */
char cam_opcode; /* CAM Operation Code */
char status; /* CAM Status */
long connect_id; /* Connect ID - no fields supported */
long cam_flags; /* CAM Flags */
long pd_pointer; /* Peripheral driver pointer */
long next_ccb_ptr; /* Next CCB Pointer */
long req_map_info; /* Request mapping information */
long call_on_comp; /* Callback on completion */
long data_buf_ptr; /* Data Buffer Pointer */
long data_xfer_length; /* Data transfer length */
long sense_buf_ptr; /* Sense information buffer pointer */
char sense_buf_length; /* Sense information buffer length */
char cdb_length; /* Command Descriptor Block (CDB) **
** length */
short num_sg_entries; /* Number of scatter/gather entries */
long vendor_unique; /* Vendor Unique field */
char scsi_status; /* SCSI status */
char auto_resid; /* Auto sense residual length */
short reserved; /* Reserved */
long resid_length; /* Residual length */
char cdb[12]; /* Command Descriptor Block (CDB) */
long time_out; /* Time-out value */
long msg_buf_ptr; /* Message buffer pointer */
short msg_buf_length; /* Message buffer length */
short vu_flags; /* Vendor-unique flags */
char tag_queue_act; /* Tagged Queue action */
char tag_id; /* Tag ID (target only) */
char init_id; /* Initiator ID (target only) */
char reserved2; /* Reserved */
} Exec_IO_CCB;
This structure will never capture SCSI Output ?
I have declared the Inquiry Structure as follows . But I am not sure how Inquire command will
populate Inquiry_Data structure data ??
typedef struct {
short data_valid; /* Flag that indicates whether or not the */
/* structure has been filled in with */
/* inquiry data from the device. */
byte periph_qual;
byte periph_dev_type;
byte rmb;
byte iso_version;
byte ecma_version;
byte ansi_version;
byte resp_data_format;
byte rel_adr;
byte sync;
byte linked;
byte cmd_que;
byte sft_rst;
char vendor_id[9];
char prod_id[17];
char prod_rev[5];
char reserved;
} Inquiry_Data;
The first thing that you have assigned a short to cdb[4], but cdb[4] is a byte. The assignment probably put a 0 there since the compiler would truncate. Since bytes 3 and 4 are the allocation length you have told the target not to send anything. Maybe you ment to assign 32 to cdb[4]; but since your Inquiry_Data structure is 44 bytes you probably want to assign 44 to cdb[4].
struct i2c_algorithm has function pointer template for master_xfer for i2c bus implementation. Where can I find the default function routine of master_xfer in linux kernel source.?
Please someone guide me..
What master_xfer is set to depends on your platform and bus. Look under drivers/i2c/busses/ to find where this function pointer is set. Note that it could be set to NULL.
An example of where it is set is in drivers/i2c/busses/i2c-pxa.c:
static const struct i2c_algorithm i2c_pxa_algorithm = {
.master_xfer = i2c_pxa_xfer,
.functionality = i2c_pxa_functionality,
};
Also look at include/linux/i2c.h:
struct i2c_algorithm {
/* If an adapter algorithm can't do I2C-level access, set master_xfer
to NULL. If an adapter algorithm can do SMBus access, set
smbus_xfer. If set to NULL, the SMBus protocol is simulated
using common I2C messages */
/* master_xfer should return the number of messages successfully
processed, or a negative value on error */
int (*master_xfer)(struct i2c_adapter *adap, struct i2c_msg *msgs,
int num);
int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr,
unsigned short flags, char read_write,
u8 command, int size, union i2c_smbus_data *data);
/* To determine what the adapter supports */
u32 (*functionality) (struct i2c_adapter *);
};
:
* An i2c_msg is the low level representation of one segment of an I2C
* transaction. It is visible to drivers in the #i2c_transfer() procedure,
* to userspace from i2c-dev, and to I2C adapter drivers through the
* #i2c_adapter.#master_xfer() method.
*
There is i2c-gpio.c file in /driver/i2c/busses/. In that we are filling master_xfer function with bit_xfer. It does bit banging implementation.
Since the pages are stored in address_space within each inode, how does the background page cache flush thread know all dirty pages?
They're all in one place:
struct bdi_writeback {
struct backing_dev_info *bdi; /* our parent bdi */
unsigned int nr;
unsigned long last_old_flush; /* last old data flush */
unsigned long last_active; /* last time bdi thread was active */
struct task_struct *task; /* writeback thread */
struct timer_list wakeup_timer; /* used for delayed bdi thread wakeup */
struct list_head b_dirty; /* dirty inodes */
struct list_head b_io; /* parked for writeback */
struct list_head b_more_io; /* parked for more writeback */
spinlock_t list_lock; /* protects the b_* lists */
};
b_dirty is the list you're looking for.
For some information on how the flushing happens, take a look in here. The code is kind of complex though. To summarize (alot), consider that in the default configuration data written to disk will sit in memory until either a) they're more than 30 seconds old, or b) the dirty pages have consumed more than 10% of the active, working memory.
On the x86 platform the OS must inspect its page table entries to find the pages that are dirty. There's a special, dirty, bit in them that's set by the CPU automatically during memory writes. There must be some code that scans the PTEs for dirty=1.