2.6.24-rc3-mm2 - Kernel

This is a discussion on 2.6.24-rc3-mm2 - Kernel ; On Wed, Nov 28, 2007 at 01:40:36PM -0800, Andrew Morton wrote: > On Wed, 28 Nov 2007 23:01:31 +0300 > Alexey Dobriyan wrote: > > > Reliably spams dmesg with end_request() horrors. This happens when git > > starts checking ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 47

Thread: 2.6.24-rc3-mm2

  1. Re: 2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error

    On Wed, Nov 28, 2007 at 01:40:36PM -0800, Andrew Morton wrote:
    > On Wed, 28 Nov 2007 23:01:31 +0300
    > Alexey Dobriyan wrote:
    >
    > > Reliably spams dmesg with end_request() horrors. This happens when git
    > > starts checking out linux tree to fresh ext2 partition. Disk is several
    > > month old and there were no prolems with, say, 2.6.24-rc3:


    Could you try reverting 6f5391c283d7fdcf24bf40786ea79061919d1e1d and see
    if the problem still exists?

    --
    Intel are signing my paycheques ... these opinions are still mine
    "Bill, look, we understand that you're interested in selling us this
    operating system, but compare it to ours. We can't possibly take such
    a retrograde step."
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: named + capset = EPERM [Was: 2.6.24-rc3-mm2]


    --- Jiri Slaby wrote:

    > On 11/28/2007 12:41 PM, Andrew Morton wrote:
    > >

    >

    ftp://ftp.kernel.org/pub/linux/kerne....6.24-rc3-mm2/
    > [...]
    > > +capabilities-introduce-per-process-capability-bounding-set.patch

    >
    > A regression against -mm1. This patch breaks bind (9.5.0-18.a7.fc8):
    > capset(0x19980330, 0,
    >

    {CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET _BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
    >

    CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_ BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
    > 0}) = -1 EPERM (Operation not permitted)
    >
    > $ grep SEC .config
    > CONFIG_SECCOMP=y
    > # CONFIG_NETWORK_SECMARK is not set
    > CONFIG_RPCSEC_GSS_KRB5=m
    > # CONFIG_RPCSEC_GSS_SPKM3 is not set
    > # CONFIG_SECURITY is not set
    > # CONFIG_SECURITY_FILE_CAPABILITIES is not set
    >
    > probably this hunk?:
    > @@ -133,6 +119,12 @@ int cap_capset_check (struct task_struct
    > /* incapable of using this inheritable set */
    > return -EPERM;
    > }
    > + if (!!cap_issubset(*inheritable,
    > + cap_combine(target->cap_inheritable,
    > + current->cap_bset))) {
    > + /* no new pI capabilities outside bounding set */
    > + return -EPERM;
    > + }
    >
    > /* verify restrictions on target's new Permitted set */
    > if (!cap_issubset (*permitted,


    I can see that the value for CAP_LAST_CAP is not right in
    include/linux/capability.h, but I don't know if that is the
    only problem. I should have a patch (unless someone beats me to it)
    later today.


    Casey Schaufler
    casey@schaufler-ca.com
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: 2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error

    On Wed, 28 Nov 2007 16:14:21 -0700
    Matthew Wilcox wrote:

    > On Wed, Nov 28, 2007 at 01:40:36PM -0800, Andrew Morton wrote:
    > > On Wed, 28 Nov 2007 23:01:31 +0300
    > > Alexey Dobriyan wrote:
    > >
    > > > Reliably spams dmesg with end_request() horrors. This happens when git
    > > > starts checking out linux tree to fresh ext2 partition. Disk is several
    > > > month old and there were no prolems with, say, 2.6.24-rc3:

    >
    > Could you try reverting 6f5391c283d7fdcf24bf40786ea79061919d1e1d and see
    > if the problem still exists?
    >


    That's not completely trivial..

    I did a hand-made revert against 2.6.24-rc3-mm2 (below) but some other patch
    in there causes:

    drivers/scsi/scsi_lib.c: In function 'scsi_blk_pc_done':
    drivers/scsi/scsi_lib.c:1251: error: 'struct scsi_cmnd' has no member named 'request_bufflen'


    --- a/drivers/scsi/scsi.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    +++ a/drivers/scsi/scsi.c
    @@ -59,7 +59,6 @@
    #include
    #include
    #include
    -#include
    #include
    #include
    #include
    @@ -379,8 +378,9 @@ void scsi_log_send(struct scsi_cmnd *cmd
    scsi_print_command(cmd);
    if (level > 3) {
    printk(KERN_INFO "buffer = 0x%p, bufflen = %d,"
    - " queuecommand 0x%p\n",
    + " done = 0x%p, queuecommand 0x%p\n",
    scsi_sglist(cmd), scsi_bufflen(cmd),
    + cmd->done,
    cmd->device->host->hostt->queuecommand);

    }
    @@ -667,12 +667,6 @@ void __scsi_done(struct scsi_cmnd *cmd)
    blk_complete_request(rq);
    }

    -/* Move this to a header if it becomes more generally useful */
    -static struct scsi_driver *scsi_cmd_to_driver(struct scsi_cmnd *cmd)
    -{
    - return *(struct scsi_driver **)cmd->request->rq_disk->private_data;
    -}
    -
    /**
    * scsi_finish_command - cleanup and pass command back to upper layer
    * @cmd: the command
    @@ -685,8 +679,6 @@ void scsi_finish_command(struct scsi_cmn
    {
    struct scsi_device *sdev = cmd->device;
    struct Scsi_Host *shost = sdev->host;
    - struct scsi_driver *drv;
    - unsigned int good_bytes;

    scsi_device_unbusy(sdev);

    @@ -712,13 +704,7 @@ void scsi_finish_command(struct scsi_cmn
    "Notifying upper driver of completion "
    "(result %x)\n", cmd->result));

    - good_bytes = scsi_bufflen(cmd);
    - if (cmd->request->cmd_type != REQ_TYPE_BLOCK_PC) {
    - drv = scsi_cmd_to_driver(cmd);
    - if (drv->done)
    - good_bytes = drv->done(cmd);
    - }
    - scsi_io_completion(cmd, good_bytes);
    + cmd->done(cmd);
    }
    EXPORT_SYMBOL(scsi_finish_command);

    diff -puN drivers/scsi/scsi_error.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d drivers/scsi/scsi_error.c
    --- a/drivers/scsi/scsi_error.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    +++ a/drivers/scsi/scsi_error.c
    @@ -1697,6 +1697,7 @@ scsi_reset_provider(struct scsi_device *

    scmd->scsi_done = scsi_reset_provider_done_command;
    memset(&scmd->sdb, 0, sizeof(scmd->sdb));
    + scmd->done = NULL;

    scmd->cmd_len = 0;

    diff -puN drivers/scsi/scsi_lib.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d drivers/scsi/scsi_lib.c
    --- a/drivers/scsi/scsi_lib.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    +++ a/drivers/scsi/scsi_lib.c
    @@ -944,6 +944,7 @@ void scsi_end_bidi_request(struct scsi_c

    scsi_finalize_request(cmd, 1);
    }
    +EXPORT_SYMBOL(scsi_io_completion);

    /*
    * Function: scsi_io_completion()
    @@ -1238,6 +1239,18 @@ static struct scsi_cmnd *scsi_get_cmd_fr
    return cmd;
    }

    +static void scsi_blk_pc_done(struct scsi_cmnd *cmd)
    +{
    + BUG_ON(!blk_pc_request(cmd->request));
    + /*
    + * This will complete the whole command with uptodate=1 so
    + * as far as the block layer is concerned the command completed
    + * successfully. Since this is a REQ_BLOCK_PC command the
    + * caller should check the request's errors value
    + */
    + scsi_io_completion(cmd, cmd->request_bufflen);
    +}
    +
    int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev, struct request *req)
    {
    struct scsi_cmnd *cmd;
    @@ -1285,6 +1298,7 @@ int scsi_setup_blk_pc_cmnd(struct scsi_d
    cmd->transfersize = req->data_len;
    cmd->allowed = req->retries;
    cmd->timeout_per_command = req->timeout;
    + cmd->done = scsi_blk_pc_done;
    return BLKPREP_OK;
    }
    EXPORT_SYMBOL(scsi_setup_blk_pc_cmnd);
    diff -puN drivers/scsi/scsi_priv.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d drivers/scsi/scsi_priv.h
    --- a/drivers/scsi/scsi_priv.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    +++ a/drivers/scsi/scsi_priv.h
    @@ -68,7 +68,6 @@ extern int scsi_maybe_unblock_host(struc
    extern void scsi_device_unbusy(struct scsi_device *sdev);
    extern int scsi_queue_insert(struct scsi_cmnd *cmd, int reason);
    extern void scsi_next_command(struct scsi_cmnd *cmd);
    -extern void scsi_io_completion(struct scsi_cmnd *, unsigned int);
    extern void scsi_run_host_queues(struct Scsi_Host *shost);
    extern struct request_queue *scsi_alloc_queue(struct scsi_device *sdev);
    extern void scsi_free_queue(struct request_queue *q);
    diff -puN drivers/scsi/sd.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d drivers/scsi/sd.c
    --- a/drivers/scsi/sd.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    +++ a/drivers/scsi/sd.c
    @@ -86,19 +86,6 @@ MODULE_ALIAS_SCSI_DEVICE(TYPE_DISK);
    MODULE_ALIAS_SCSI_DEVICE(TYPE_MOD);
    MODULE_ALIAS_SCSI_DEVICE(TYPE_RBC);

    -static int sd_revalidate_disk(struct gendisk *);
    -static int sd_probe(struct device *);
    -static int sd_remove(struct device *);
    -static void sd_shutdown(struct device *);
    -static int sd_suspend(struct device *, pm_message_t state);
    -static int sd_resume(struct device *);
    -static void sd_rescan(struct device *);
    -static int sd_done(struct scsi_cmnd *);
    -static void sd_read_capacity(struct scsi_disk *sdkp, unsigned char *buffer);
    -static void scsi_disk_release(struct class_device *cdev);
    -static void sd_print_sense_hdr(struct scsi_disk *, struct scsi_sense_hdr *);
    -static void sd_print_result(struct scsi_disk *, int);
    -
    static DEFINE_IDR(sd_index_idr);
    static DEFINE_SPINLOCK(sd_index_lock);

    @@ -253,7 +240,6 @@ static struct scsi_driver sd_template =
    .shutdown = sd_shutdown,
    },
    .rescan = sd_rescan,
    - .done = sd_done,
    };

    /*
    @@ -520,6 +506,12 @@ static int sd_prep_fn(struct request_que
    SCpnt->timeout_per_command = timeout;

    /*
    + * This is the completion routine we use. This is matched in terms
    + * of capability to this function.
    + */
    + SCpnt->done = sd_rw_intr;
    +
    + /*
    * This indicates that the command is ready from our end to be
    * queued.
    */
    @@ -898,13 +890,13 @@ static struct block_device_operations sd
    };

    /**
    - * sd_done - bottom half handler: called when the lower level
    + * sd_rw_intr - bottom half handler: called when the lower level
    * driver has completed (successfully or otherwise) a scsi command.
    * @SCpnt: mid-level's per command structure.
    *
    * Note: potentially run from within an ISR. Must not block.
    **/
    -static int sd_done(struct scsi_cmnd *SCpnt)
    +static void sd_rw_intr(struct scsi_cmnd * SCpnt)
    {
    int result = SCpnt->result;
    unsigned int xfer_size = scsi_bufflen(SCpnt);
    @@ -925,7 +917,7 @@ static int sd_done(struct scsi_cmnd *SCp
    SCSI_LOG_HLCOMPLETE(1, scsi_print_result(SCpnt));
    if (sense_valid) {
    SCSI_LOG_HLCOMPLETE(1, scmd_printk(KERN_INFO, SCpnt,
    - "sd_done: sb[respc,sk,asc,"
    + "sd_rw_intr: sb[respc,sk,asc,"
    "ascq]=%x,%x,%x,%x\n",
    sshdr.response_code,
    sshdr.sense_key, sshdr.asc,
    @@ -997,7 +989,7 @@ static int sd_done(struct scsi_cmnd *SCp
    break;
    }
    out:
    - return good_bytes;
    + scsi_io_completion(SCpnt, good_bytes);
    }

    static int media_not_present(struct scsi_disk *sdkp,
    diff -puN drivers/scsi/sr.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d drivers/scsi/sr.c
    --- a/drivers/scsi/sr.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    +++ a/drivers/scsi/sr.c
    @@ -78,7 +78,6 @@ MODULE_ALIAS_SCSI_DEVICE(TYPE_WORM);

    static int sr_probe(struct device *);
    static int sr_remove(struct device *);
    -static int sr_done(struct scsi_cmnd *);

    static struct scsi_driver sr_template = {
    .owner = THIS_MODULE,
    @@ -87,7 +86,6 @@ static struct scsi_driver sr_template =
    .probe = sr_probe,
    .remove = sr_remove,
    },
    - .done = sr_done,
    };

    static unsigned long sr_index_bits[SR_DISKS / BITS_PER_LONG];
    @@ -221,12 +219,12 @@ out:
    }

    /*
    - * sr_done is the interrupt routine for the device driver.
    + * rw_intr is the interrupt routine for the device driver.
    *
    - * It will be notified on the end of a SCSI read / write, and will take one
    + * It will be notified on the end of a SCSI read / write, and will take on
    * of several actions based on success or failure.
    */
    -static int sr_done(struct scsi_cmnd *SCpnt)
    +static void rw_intr(struct scsi_cmnd * SCpnt)
    {
    int result = SCpnt->result;
    int this_count = scsi_bufflen(SCpnt);
    @@ -299,7 +297,12 @@ static int sr_done(struct scsi_cmnd *SCp
    }
    }

    - return good_bytes;
    + /*
    + * This calls the generic completion function, now that we know
    + * how many actual sectors finished, and how many sectors we need
    + * to say have failed.
    + */
    + scsi_io_completion(SCpnt, good_bytes);
    }

    static int sr_prep_fn(struct request_queue *q, struct request *rq)
    @@ -434,6 +437,12 @@ static int sr_prep_fn(struct request_que
    SCpnt->timeout_per_command = timeout;

    /*
    + * This is the completion routine we use. This is matched in terms
    + * of capability to this function.
    + */
    + SCpnt->done = rw_intr;
    +
    + /*
    * This indicates that the command is ready from our end to be
    * queued.
    */
    diff -puN include/scsi/scsi_cmnd.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d include/scsi/scsi_cmnd.h
    --- a/include/scsi/scsi_cmnd.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    +++ a/include/scsi/scsi_cmnd.h
    @@ -41,6 +41,7 @@ struct scsi_cmnd {
    struct list_head list; /* scsi_cmnd participates in queue lists */
    struct list_head eh_entry; /* entry for the host eh_cmd_q */
    int eh_eflags; /* Used by error handlr */
    + void (*done) (struct scsi_cmnd *); /* Mid-level done function */

    /*
    * A SCSI Command is assigned a nonzero serial_number before passed
    @@ -121,6 +122,7 @@ extern struct scsi_cmnd *__scsi_get_comm
    extern void scsi_put_command(struct scsi_cmnd *);
    extern void __scsi_put_command(struct Scsi_Host *, struct scsi_cmnd *,
    struct device *);
    +extern void scsi_io_completion(struct scsi_cmnd *, unsigned int);
    extern void scsi_finish_command(struct scsi_cmnd *cmd);
    extern void scsi_req_abort_cmd(struct scsi_cmnd *cmd);

    diff -puN include/scsi/scsi_driver.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d include/scsi/scsi_driver.h
    --- a/include/scsi/scsi_driver.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    +++ a/include/scsi/scsi_driver.h
    @@ -15,7 +15,6 @@ struct scsi_driver {
    struct device_driver gendrv;

    void (*rescan)(struct device *);
    - int (*done)(struct scsi_cmnd *);
    };
    #define to_scsi_driver(drv) \
    container_of((drv), struct scsi_driver, gendrv)
    diff -puN include/scsi/sd.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d include/scsi/sd.h
    --- a/include/scsi/sd.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    +++ a/include/scsi/sd.h
    @@ -48,6 +48,19 @@ struct scsi_disk {
    };
    #define to_scsi_disk(obj) container_of(obj,struct scsi_disk,cdev)

    +static int sd_revalidate_disk(struct gendisk *disk);
    +static void sd_rw_intr(struct scsi_cmnd * SCpnt);
    +static int sd_probe(struct device *);
    +static int sd_remove(struct device *);
    +static void sd_shutdown(struct device *dev);
    +static int sd_suspend(struct device *dev, pm_message_t state);
    +static int sd_resume(struct device *dev);
    +static void sd_rescan(struct device *);
    +static void sd_read_capacity(struct scsi_disk *sdkp, unsigned char *buffer);
    +static void scsi_disk_release(struct class_device *cdev);
    +static void sd_print_sense_hdr(struct scsi_disk *, struct scsi_sense_hdr *);
    +static void sd_print_result(struct scsi_disk *, int);
    +
    #define sd_printk(prefix, sdsk, fmt, a...) \
    (sdsk)->disk ? \
    sdev_printk(prefix, (sdsk)->device, "[%s] " fmt, \
    _

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: named + capset = EPERM [Was: 2.6.24-rc3-mm2]

    Quoting Casey Schaufler (casey@schaufler-ca.com):
    >
    > --- Jiri Slaby wrote:
    >
    > > On 11/28/2007 12:41 PM, Andrew Morton wrote:
    > > >

    > >

    > ftp://ftp.kernel.org/pub/linux/kerne....6.24-rc3-mm2/
    > > [...]
    > > > +capabilities-introduce-per-process-capability-bounding-set.patch

    > >
    > > A regression against -mm1. This patch breaks bind (9.5.0-18.a7.fc8):
    > > capset(0x19980330, 0,
    > >

    > {CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET _BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
    > >

    > CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_ BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
    > > 0}) = -1 EPERM (Operation not permitted)
    > >
    > > $ grep SEC .config
    > > CONFIG_SECCOMP=y
    > > # CONFIG_NETWORK_SECMARK is not set
    > > CONFIG_RPCSEC_GSS_KRB5=m
    > > # CONFIG_RPCSEC_GSS_SPKM3 is not set
    > > # CONFIG_SECURITY is not set
    > > # CONFIG_SECURITY_FILE_CAPABILITIES is not set
    > >
    > > probably this hunk?:
    > > @@ -133,6 +119,12 @@ int cap_capset_check (struct task_struct
    > > /* incapable of using this inheritable set */
    > > return -EPERM;
    > > }
    > > + if (!!cap_issubset(*inheritable,
    > > + cap_combine(target->cap_inheritable,
    > > + current->cap_bset))) {
    > > + /* no new pI capabilities outside bounding set */
    > > + return -EPERM;
    > > + }


    That shouldn't be it, since you can't lower cap_bset since
    CONFIG_SECURITY_FILE_CAPABILITIES=n.

    > >
    > > /* verify restrictions on target's new Permitted set */
    > > if (!cap_issubset (*permitted,

    >
    > I can see that the value for CAP_LAST_CAP is not right in
    > include/linux/capability.h, but I don't know if that is the


    Alas, that doesn't seem likely to be it either, since cap_valid() and
    therefore CAP_LAST_CAP are only used when tweaking the cap_bset.

    > only problem. I should have a patch (unless someone beats me to it)
    > later today.


    Oh, sorry, after I sent the patch to fix that inline, I never sent it
    as a separate patch.

    I'll resend it to lkml right now.

    thanks,
    -serge
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: named + capset = EPERM [Was: 2.6.24-rc3-mm2]

    Quoting Serge E. Hallyn (serue@us.ibm.com):
    > Quoting Casey Schaufler (casey@schaufler-ca.com):
    > >
    > > --- Jiri Slaby wrote:
    > >
    > > > On 11/28/2007 12:41 PM, Andrew Morton wrote:
    > > > >
    > > >

    > > ftp://ftp.kernel.org/pub/linux/kerne....6.24-rc3-mm2/
    > > > [...]
    > > > > +capabilities-introduce-per-process-capability-bounding-set.patch
    > > >
    > > > A regression against -mm1. This patch breaks bind (9.5.0-18.a7.fc8):
    > > > capset(0x19980330, 0,
    > > >

    > > {CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET _BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
    > > >

    > > CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_ BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
    > > > 0}) = -1 EPERM (Operation not permitted)
    > > >
    > > > $ grep SEC .config
    > > > CONFIG_SECCOMP=y
    > > > # CONFIG_NETWORK_SECMARK is not set
    > > > CONFIG_RPCSEC_GSS_KRB5=m
    > > > # CONFIG_RPCSEC_GSS_SPKM3 is not set
    > > > # CONFIG_SECURITY is not set
    > > > # CONFIG_SECURITY_FILE_CAPABILITIES is not set
    > > >
    > > > probably this hunk?:
    > > > @@ -133,6 +119,12 @@ int cap_capset_check (struct task_struct
    > > > /* incapable of using this inheritable set */
    > > > return -EPERM;
    > > > }
    > > > + if (!!cap_issubset(*inheritable,
    > > > + cap_combine(target->cap_inheritable,
    > > > + current->cap_bset))) {
    > > > + /* no new pI capabilities outside bounding set */
    > > > + return -EPERM;
    > > > + }

    >
    > That shouldn't be it, since you can't lower cap_bset since
    > CONFIG_SECURITY_FILE_CAPABILITIES=n.


    Hmm, but sure enough that appears to be it.

    Still trying to figure out why.

    thanks,
    -serge
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: named + capset = EPERM [Was: 2.6.24-rc3-mm2]

    Quoting Serge E. Hallyn (serue@us.ibm.com):
    > Quoting Serge E. Hallyn (serue@us.ibm.com):
    > > Quoting Casey Schaufler (casey@schaufler-ca.com):
    > > >
    > > > --- Jiri Slaby wrote:
    > > >
    > > > > On 11/28/2007 12:41 PM, Andrew Morton wrote:
    > > > > >
    > > > >
    > > > ftp://ftp.kernel.org/pub/linux/kerne....6.24-rc3-mm2/
    > > > > [...]
    > > > > > +capabilities-introduce-per-process-capability-bounding-set.patch
    > > > >
    > > > > A regression against -mm1. This patch breaks bind (9.5.0-18.a7.fc8):
    > > > > capset(0x19980330, 0,
    > > > >
    > > > {CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET _BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
    > > > >
    > > > CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_ BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
    > > > > 0}) = -1 EPERM (Operation not permitted)
    > > > >
    > > > > $ grep SEC .config
    > > > > CONFIG_SECCOMP=y
    > > > > # CONFIG_NETWORK_SECMARK is not set
    > > > > CONFIG_RPCSEC_GSS_KRB5=m
    > > > > # CONFIG_RPCSEC_GSS_SPKM3 is not set
    > > > > # CONFIG_SECURITY is not set
    > > > > # CONFIG_SECURITY_FILE_CAPABILITIES is not set
    > > > >
    > > > > probably this hunk?:
    > > > > @@ -133,6 +119,12 @@ int cap_capset_check (struct task_struct
    > > > > /* incapable of using this inheritable set */
    > > > > return -EPERM;
    > > > > }
    > > > > + if (!!cap_issubset(*inheritable,
    > > > > + cap_combine(target->cap_inheritable,
    > > > > + current->cap_bset))) {
    > > > > + /* no new pI capabilities outside bounding set */
    > > > > + return -EPERM;
    > > > > + }

    > >
    > > That shouldn't be it, since you can't lower cap_bset since
    > > CONFIG_SECURITY_FILE_CAPABILITIES=n.

    >
    > Hmm, but sure enough that appears to be it.
    >
    > Still trying to figure out why.


    No. Seriously. You're kidding me.

    Patch attached

    Thanks for spotting this, Jiri. I don't know where I introduced this
    since I thought all my tests had passed...

    thanks,
    -serge

    From 70d5da610fdbd66a36886c01e27b7fb11d2de044 Mon Sep 17 00:00:00 2001
    From: sergeh@us.ibm.com
    Date: Wed, 28 Nov 2007 16:16:23 -0800
    Subject: [PATCH 1/1] capabilities: correct logic at capset_check

    Fix typo at capset_check introduced with capability bounding set
    patch.

    Signed-off-by: sergeh@us.ibm.com
    ---
    security/commoncap.c | 2 +-
    1 files changed, 1 insertions(+), 1 deletions(-)

    diff --git a/security/commoncap.c b/security/commoncap.c
    index c25ad09..503e958 100644
    --- a/security/commoncap.c
    +++ b/security/commoncap.c
    @@ -119,7 +119,7 @@ int cap_capset_check (struct task_struct *target, kernel_cap_t *effective,
    /* incapable of using this inheritable set */
    return -EPERM;
    }
    - if (!!cap_issubset(*inheritable,
    + if (!cap_issubset(*inheritable,
    cap_combine(target->cap_inheritable,
    current->cap_bset))) {
    /* no new pI capabilities outside bounding set */
    --
    1.5.1

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared

    On Wednesday 28 November 2007 19:43:45 Andrew Morton wrote:
    > > I guess all architectures except x86 are currently broken because they
    > > reference the old sys_timerfd function.

    >
    > None of them were broken in my testing and I'm unsure why powerpc broke
    > here.


    PowerPC is unique in that it actually relies on the declarations
    in include/{linux,asm}/syscalls.h to be present, because the
    spu_syscall_table is generated from C code, not from assembly.
    One reason why I did this was to be sure to find this exact
    type of problem at compile-time, not at link time.

    Arnd <><
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: 2.6.24-rc3-mm2


    > +per-zone-and-reclaim-enhancements-for-memory-controller-take-3-add-scan_global_lru-macro.patch
    > +per-zone-and-reclaim-enhancements-for-memory-controller-take-3-nid-zid-helper-function-for-cgroup.patch
    > +per-zone-and-reclaim-enhancements-for-memory-controller-take-3-per-zone-active-inactive-counter.patch
    > +per-zone-and-reclaim-enhancements-for-memory-controller-take-3-calculate-mapper_ratio-per-cgroup.patch
    > +per-zone-and-reclaim-enhancements-for-memory-controller-take-3-calculate-active-inactive-imbalance-per-cgroup.patch
    > +per-zone-and-reclaim-enhancements-for-memory-controller-take-3-remember-reclaim-priority-in-memory-cgroup.patch
    > +per-zone-and-reclaim-enhancements-for-memory-controller-take-3-remember-reclaim-priority-in-memory-cgroup-fix.patch
    > +per-zone-and-reclaim-enhancements-for-memory-controller-take-3-remember-reclaim-priority-in-memory-cgroup-fix-2.patch
    > +per-zone-and-reclaim-enhancements-for-memory-controller-take-3-calculate-the-number-of-pages-to-be-scanned-per-cgroup.patch
    > +per-zone-and-reclaim-enhancements-for-memory-controller-take-3-modifies-vmscanc-for-isolate-globa-cgroup-lru-activity.patch
    > +per-zone-and-reclaim-enhancements-for-memory-controller-take-3-modifies-vmscanc-for-isolate-globa-cgroup-lru-activity-fix.patch
    > +per-zone-and-reclaim-enhancements-for-memory-controller-take-3-per-zone-lru-for-cgroup.patch
    > +per-zone-and-reclaim-enhancements-for-memory-controller-take-3-per-zone-lock-for-cgroup.patch
    >
    > cgroup memeory controller updates
    >

    I noticed CONFIG_NUMA + CONFIG_CGROUP_MEM_CONT + CONFIG_SLUB cannot boot because of my patch.
    (SLAB is ok.)
    I'll post workaround soon.

    Sorry,
    -Kame


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: 2.6.24-rc3-mm2 (bugfix for memory cgroup per-zone-struct allocation.)

    On Thu, 29 Nov 2007 12:23:29 +0900
    KAMEZAWA Hiroyuki wrote:
    > I noticed CONFIG_NUMA + CONFIG_CGROUP_MEM_CONT + CONFIG_SLUB cannot boot because of my patch.
    > (SLAB is ok.)
    > I'll post workaround soon.
    >

    ==
    This is a fix. tested on my ia64/NUMA box both on SLAB/SLUB.
    This patch fixes kmalloc_node() is called against node-without-memory.

    It's better to add memory hotplug callback for supporing possible nodes
    (memory hotplug) but here just uses kmalloc().

    Should be revisited later.

    Signed-off-by: KAMEZAWA Hiroyuki

    mm/memcontrol.c | 14 ++++++++++++--
    1 file changed, 12 insertions(+), 2 deletions(-)

    Index: linux-2.6.24-rc3-mm2/mm/memcontrol.c
    ================================================== =================
    --- linux-2.6.24-rc3-mm2.orig/mm/memcontrol.c
    +++ linux-2.6.24-rc3-mm2/mm/memcontrol.c
    @@ -1117,8 +1117,18 @@ static int alloc_mem_cgroup_per_zone_inf
    struct mem_cgroup_per_node *pn;
    struct mem_cgroup_per_zone *mz;
    int zone;
    -
    - pn = kmalloc_node(sizeof(*pn), GFP_KERNEL, node);
    + /*
    + * This routine is called against possible nodes.
    + * But it's BUG to call kmalloc() against offline node.
    + *
    + * TODO: this routine can waste much memory for nodes which will
    + * never be onlined. It's better to use memory hotplug callback
    + * function.
    + */
    + if (node_state(node, N_HIGH_MEMORY))
    + pn = kmalloc_node(sizeof(*pn), GFP_KERNEL, node);
    + else
    + pn = kmalloc(sizeof(*pn), GFP_KERNEL);
    if (!pn)
    return 1;


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions

    Hi Andrew,

    While running file system stress on nfs and cifs mounted partitions, the machine
    drops to xmon

    1:mon> e
    cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
    pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
    lr: c0000000001074d0: .vfs_link+0x204/0x298
    sp: c000000080a9fb00
    msr: 8000000000009032
    dar: 280
    dsisr: 40010000
    current = 0xc0000000c8e6f670
    paca = 0xc000000000512c00
    pid = 2848, comm = fsstress
    1:mon> t
    [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
    [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
    [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
    --- Exception: c00 (System Call) at 000000000ff1bdfc
    SP (ffeaed10) is in userspace
    1:mon> r
    R00 = c0000000001074d0 R16 = 0000000000000000
    R01 = c000000080a9fb00 R17 = 0000000000000000
    R02 = c00000000060c380 R18 = 0000000000000000
    R03 = 0000000000000000 R19 = 0000000000000000
    R04 = 0000000000000004 R20 = 0000000000000000
    R05 = 0000000000000000 R21 = 0000000000000000
    R06 = 0000000000000000 R22 = 0000000000000000
    R07 = 0000000000000000 R23 = 0000000000000004
    R08 = 0000000000000000 R24 = 0000000000000280
    R09 = 0000000000000000 R25 = fffffffffffff000
    R10 = 0000000000000001 R26 = c000000082827790
    R11 = c0000000003963e8 R27 = c0000000828275a0
    R12 = d000000000deec78 R28 = 0000000000000000
    R13 = c000000000512c00 R29 = c00000007b18fcf0
    R14 = 0000000000000000 R30 = c0000000005bc088
    R15 = 0000000000000000 R31 = 0000000000000000
    pc = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
    lr = c0000000001074d0 .vfs_link+0x204/0x298
    msr = 8000000000009032 cr = 24000882
    ctr = c0000000003963e8 xer = 0000000000000000 trap = 300
    dar = 0000000000000280 dsisr = 40010000


    The gdb output shows

    0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
    103 * fsnotify_create - 'name' was linked in
    104 */
    105 static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
    106 {
    107 inode_dir_notify(inode, DN_CREATE);
    108 inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
    109 dentry->d_inode);
    110 audit_inode_child(dentry->d_name.name, dentry, inode);
    111 }
    112



    --
    Thanks & Regards,
    Kamalesh Babulal,
    Linux Technology Center,
    IBM, ISTL.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions

    On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal wrote:

    > Hi Andrew,
    >
    > While running file system stress on nfs and cifs mounted partitions, the machine
    > drops to xmon
    >
    > 1:mon> e
    > cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
    > pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
    > lr: c0000000001074d0: .vfs_link+0x204/0x298
    > sp: c000000080a9fb00
    > msr: 8000000000009032
    > dar: 280
    > dsisr: 40010000
    > current = 0xc0000000c8e6f670
    > paca = 0xc000000000512c00
    > pid = 2848, comm = fsstress
    > 1:mon> t
    > [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
    > [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
    > [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
    > --- Exception: c00 (System Call) at 000000000ff1bdfc
    > SP (ffeaed10) is in userspace
    > 1:mon> r
    > R00 = c0000000001074d0 R16 = 0000000000000000
    > R01 = c000000080a9fb00 R17 = 0000000000000000
    > R02 = c00000000060c380 R18 = 0000000000000000
    > R03 = 0000000000000000 R19 = 0000000000000000
    > R04 = 0000000000000004 R20 = 0000000000000000
    > R05 = 0000000000000000 R21 = 0000000000000000
    > R06 = 0000000000000000 R22 = 0000000000000000
    > R07 = 0000000000000000 R23 = 0000000000000004
    > R08 = 0000000000000000 R24 = 0000000000000280
    > R09 = 0000000000000000 R25 = fffffffffffff000
    > R10 = 0000000000000001 R26 = c000000082827790
    > R11 = c0000000003963e8 R27 = c0000000828275a0
    > R12 = d000000000deec78 R28 = 0000000000000000
    > R13 = c000000000512c00 R29 = c00000007b18fcf0
    > R14 = 0000000000000000 R30 = c0000000005bc088
    > R15 = 0000000000000000 R31 = 0000000000000000
    > pc = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
    > lr = c0000000001074d0 .vfs_link+0x204/0x298
    > msr = 8000000000009032 cr = 24000882
    > ctr = c0000000003963e8 xer = 0000000000000000 trap = 300
    > dar = 0000000000000280 dsisr = 40010000
    >
    >
    > The gdb output shows
    >
    > 0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
    > 103 * fsnotify_create - 'name' was linked in
    > 104 */
    > 105 static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
    > 106 {
    > 107 inode_dir_notify(inode, DN_CREATE);
    > 108 inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
    > 109 dentry->d_inode);
    > 110 audit_inode_child(dentry->d_name.name, dentry, inode);
    > 111 }
    > 112
    >


    If it is reproducible can you please try reverting
    inotify-send-in_attrib-events-when-link-count-changes.patch?
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: 2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error

    On Thu, Nov 29 2007 at 1:36 +0200, Andrew Morton wrote:
    > On Wed, 28 Nov 2007 16:14:21 -0700
    > Matthew Wilcox wrote:
    >
    >> On Wed, Nov 28, 2007 at 01:40:36PM -0800, Andrew Morton wrote:
    >>> On Wed, 28 Nov 2007 23:01:31 +0300
    >>> Alexey Dobriyan wrote:
    >>>
    >>>> Reliably spams dmesg with end_request() horrors. This happens when git
    >>>> starts checking out linux tree to fresh ext2 partition. Disk is several
    >>>> month old and there were no prolems with, say, 2.6.24-rc3:

    >> Could you try reverting 6f5391c283d7fdcf24bf40786ea79061919d1e1d and see
    >> if the problem still exists?
    >>

    >
    > That's not completely trivial..
    >
    > I did a hand-made revert against 2.6.24-rc3-mm2 (below) but some other patch
    > in there causes:
    >
    > drivers/scsi/scsi_lib.c: In function 'scsi_blk_pc_done':
    > drivers/scsi/scsi_lib.c:1251: error: 'struct scsi_cmnd' has no member named 'request_bufflen'
    >

    That would be the bidi patches. You need to use scsi_bufflen(cmd) instead of
    cmd->request_bufflen. (See below)
    Do you need that I send a patch?

    >
    > --- a/drivers/scsi/scsi.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    > +++ a/drivers/scsi/scsi.c
    > @@ -59,7 +59,6 @@
    > #include
    > #include
    > #include
    > -#include
    > #include
    > #include
    > #include
    > @@ -379,8 +378,9 @@ void scsi_log_send(struct scsi_cmnd *cmd
    > scsi_print_command(cmd);
    > if (level > 3) {
    > printk(KERN_INFO "buffer = 0x%p, bufflen = %d,"
    > - " queuecommand 0x%p\n",
    > + " done = 0x%p, queuecommand 0x%p\n",
    > scsi_sglist(cmd), scsi_bufflen(cmd),
    > + cmd->done,
    > cmd->device->host->hostt->queuecommand);
    >
    > }
    > @@ -667,12 +667,6 @@ void __scsi_done(struct scsi_cmnd *cmd)
    > blk_complete_request(rq);
    > }
    >
    > -/* Move this to a header if it becomes more generally useful */
    > -static struct scsi_driver *scsi_cmd_to_driver(struct scsi_cmnd *cmd)
    > -{
    > - return *(struct scsi_driver **)cmd->request->rq_disk->private_data;
    > -}
    > -
    > /**
    > * scsi_finish_command - cleanup and pass command back to upper layer
    > * @cmd: the command
    > @@ -685,8 +679,6 @@ void scsi_finish_command(struct scsi_cmn
    > {
    > struct scsi_device *sdev = cmd->device;
    > struct Scsi_Host *shost = sdev->host;
    > - struct scsi_driver *drv;
    > - unsigned int good_bytes;
    >
    > scsi_device_unbusy(sdev);
    >
    > @@ -712,13 +704,7 @@ void scsi_finish_command(struct scsi_cmn
    > "Notifying upper driver of completion "
    > "(result %x)\n", cmd->result));
    >
    > - good_bytes = scsi_bufflen(cmd);
    > - if (cmd->request->cmd_type != REQ_TYPE_BLOCK_PC) {
    > - drv = scsi_cmd_to_driver(cmd);
    > - if (drv->done)
    > - good_bytes = drv->done(cmd);
    > - }
    > - scsi_io_completion(cmd, good_bytes);
    > + cmd->done(cmd);
    > }
    > EXPORT_SYMBOL(scsi_finish_command);
    >
    > diff -puN drivers/scsi/scsi_error.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d drivers/scsi/scsi_error.c
    > --- a/drivers/scsi/scsi_error.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    > +++ a/drivers/scsi/scsi_error.c
    > @@ -1697,6 +1697,7 @@ scsi_reset_provider(struct scsi_device *
    >
    > scmd->scsi_done = scsi_reset_provider_done_command;
    > memset(&scmd->sdb, 0, sizeof(scmd->sdb));
    > + scmd->done = NULL;
    >
    > scmd->cmd_len = 0;
    >
    > diff -puN drivers/scsi/scsi_lib.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d drivers/scsi/scsi_lib.c
    > --- a/drivers/scsi/scsi_lib.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    > +++ a/drivers/scsi/scsi_lib.c
    > @@ -944,6 +944,7 @@ void scsi_end_bidi_request(struct scsi_c
    >
    > scsi_finalize_request(cmd, 1);
    > }
    > +EXPORT_SYMBOL(scsi_io_completion);
    >
    > /*
    > * Function: scsi_io_completion()
    > @@ -1238,6 +1239,18 @@ static struct scsi_cmnd *scsi_get_cmd_fr
    > return cmd;
    > }
    >
    > +static void scsi_blk_pc_done(struct scsi_cmnd *cmd)
    > +{
    > + BUG_ON(!blk_pc_request(cmd->request));
    > + /*
    > + * This will complete the whole command with uptodate=1 so
    > + * as far as the block layer is concerned the command completed
    > + * successfully. Since this is a REQ_BLOCK_PC command the
    > + * caller should check the request's errors value
    > + */
    > + scsi_io_completion(cmd, cmd->request_bufflen);

    + scsi_io_completion(cmd, scsi_bufflen(cmd));

    > +}
    > +
    > int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev, struct request *req)
    > {
    > struct scsi_cmnd *cmd;
    > @@ -1285,6 +1298,7 @@ int scsi_setup_blk_pc_cmnd(struct scsi_d
    > cmd->transfersize = req->data_len;
    > cmd->allowed = req->retries;
    > cmd->timeout_per_command = req->timeout;
    > + cmd->done = scsi_blk_pc_done;
    > return BLKPREP_OK;
    > }
    > EXPORT_SYMBOL(scsi_setup_blk_pc_cmnd);
    > diff -puN drivers/scsi/scsi_priv.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d drivers/scsi/scsi_priv.h
    > --- a/drivers/scsi/scsi_priv.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    > +++ a/drivers/scsi/scsi_priv.h
    > @@ -68,7 +68,6 @@ extern int scsi_maybe_unblock_host(struc
    > extern void scsi_device_unbusy(struct scsi_device *sdev);
    > extern int scsi_queue_insert(struct scsi_cmnd *cmd, int reason);
    > extern void scsi_next_command(struct scsi_cmnd *cmd);
    > -extern void scsi_io_completion(struct scsi_cmnd *, unsigned int);
    > extern void scsi_run_host_queues(struct Scsi_Host *shost);
    > extern struct request_queue *scsi_alloc_queue(struct scsi_device *sdev);
    > extern void scsi_free_queue(struct request_queue *q);
    > diff -puN drivers/scsi/sd.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d drivers/scsi/sd.c
    > --- a/drivers/scsi/sd.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    > +++ a/drivers/scsi/sd.c
    > @@ -86,19 +86,6 @@ MODULE_ALIAS_SCSI_DEVICE(TYPE_DISK);
    > MODULE_ALIAS_SCSI_DEVICE(TYPE_MOD);
    > MODULE_ALIAS_SCSI_DEVICE(TYPE_RBC);
    >
    > -static int sd_revalidate_disk(struct gendisk *);
    > -static int sd_probe(struct device *);
    > -static int sd_remove(struct device *);
    > -static void sd_shutdown(struct device *);
    > -static int sd_suspend(struct device *, pm_message_t state);
    > -static int sd_resume(struct device *);
    > -static void sd_rescan(struct device *);
    > -static int sd_done(struct scsi_cmnd *);
    > -static void sd_read_capacity(struct scsi_disk *sdkp, unsigned char *buffer);
    > -static void scsi_disk_release(struct class_device *cdev);
    > -static void sd_print_sense_hdr(struct scsi_disk *, struct scsi_sense_hdr *);
    > -static void sd_print_result(struct scsi_disk *, int);
    > -
    > static DEFINE_IDR(sd_index_idr);
    > static DEFINE_SPINLOCK(sd_index_lock);
    >
    > @@ -253,7 +240,6 @@ static struct scsi_driver sd_template =
    > .shutdown = sd_shutdown,
    > },
    > .rescan = sd_rescan,
    > - .done = sd_done,
    > };
    >
    > /*
    > @@ -520,6 +506,12 @@ static int sd_prep_fn(struct request_que
    > SCpnt->timeout_per_command = timeout;
    >
    > /*
    > + * This is the completion routine we use. This is matched in terms
    > + * of capability to this function.
    > + */
    > + SCpnt->done = sd_rw_intr;
    > +
    > + /*
    > * This indicates that the command is ready from our end to be
    > * queued.
    > */
    > @@ -898,13 +890,13 @@ static struct block_device_operations sd
    > };
    >
    > /**
    > - * sd_done - bottom half handler: called when the lower level
    > + * sd_rw_intr - bottom half handler: called when the lower level
    > * driver has completed (successfully or otherwise) a scsi command.
    > * @SCpnt: mid-level's per command structure.
    > *
    > * Note: potentially run from within an ISR. Must not block.
    > **/
    > -static int sd_done(struct scsi_cmnd *SCpnt)
    > +static void sd_rw_intr(struct scsi_cmnd * SCpnt)
    > {
    > int result = SCpnt->result;
    > unsigned int xfer_size = scsi_bufflen(SCpnt);
    > @@ -925,7 +917,7 @@ static int sd_done(struct scsi_cmnd *SCp
    > SCSI_LOG_HLCOMPLETE(1, scsi_print_result(SCpnt));
    > if (sense_valid) {
    > SCSI_LOG_HLCOMPLETE(1, scmd_printk(KERN_INFO, SCpnt,
    > - "sd_done: sb[respc,sk,asc,"
    > + "sd_rw_intr: sb[respc,sk,asc,"
    > "ascq]=%x,%x,%x,%x\n",
    > sshdr.response_code,
    > sshdr.sense_key, sshdr.asc,
    > @@ -997,7 +989,7 @@ static int sd_done(struct scsi_cmnd *SCp
    > break;
    > }
    > out:
    > - return good_bytes;
    > + scsi_io_completion(SCpnt, good_bytes);
    > }
    >
    > static int media_not_present(struct scsi_disk *sdkp,
    > diff -puN drivers/scsi/sr.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d drivers/scsi/sr.c
    > --- a/drivers/scsi/sr.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    > +++ a/drivers/scsi/sr.c
    > @@ -78,7 +78,6 @@ MODULE_ALIAS_SCSI_DEVICE(TYPE_WORM);
    >
    > static int sr_probe(struct device *);
    > static int sr_remove(struct device *);
    > -static int sr_done(struct scsi_cmnd *);
    >
    > static struct scsi_driver sr_template = {
    > .owner = THIS_MODULE,
    > @@ -87,7 +86,6 @@ static struct scsi_driver sr_template =
    > .probe = sr_probe,
    > .remove = sr_remove,
    > },
    > - .done = sr_done,
    > };
    >
    > static unsigned long sr_index_bits[SR_DISKS / BITS_PER_LONG];
    > @@ -221,12 +219,12 @@ out:
    > }
    >
    > /*
    > - * sr_done is the interrupt routine for the device driver.
    > + * rw_intr is the interrupt routine for the device driver.
    > *
    > - * It will be notified on the end of a SCSI read / write, and will take one
    > + * It will be notified on the end of a SCSI read / write, and will take on
    > * of several actions based on success or failure.
    > */
    > -static int sr_done(struct scsi_cmnd *SCpnt)
    > +static void rw_intr(struct scsi_cmnd * SCpnt)
    > {
    > int result = SCpnt->result;
    > int this_count = scsi_bufflen(SCpnt);
    > @@ -299,7 +297,12 @@ static int sr_done(struct scsi_cmnd *SCp
    > }
    > }
    >
    > - return good_bytes;
    > + /*
    > + * This calls the generic completion function, now that we know
    > + * how many actual sectors finished, and how many sectors we need
    > + * to say have failed.
    > + */
    > + scsi_io_completion(SCpnt, good_bytes);
    > }
    >
    > static int sr_prep_fn(struct request_queue *q, struct request *rq)
    > @@ -434,6 +437,12 @@ static int sr_prep_fn(struct request_que
    > SCpnt->timeout_per_command = timeout;
    >
    > /*
    > + * This is the completion routine we use. This is matched in terms
    > + * of capability to this function.
    > + */
    > + SCpnt->done = rw_intr;
    > +
    > + /*
    > * This indicates that the command is ready from our end to be
    > * queued.
    > */
    > diff -puN include/scsi/scsi_cmnd.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d include/scsi/scsi_cmnd.h
    > --- a/include/scsi/scsi_cmnd.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    > +++ a/include/scsi/scsi_cmnd.h
    > @@ -41,6 +41,7 @@ struct scsi_cmnd {
    > struct list_head list; /* scsi_cmnd participates in queue lists */
    > struct list_head eh_entry; /* entry for the host eh_cmd_q */
    > int eh_eflags; /* Used by error handlr */
    > + void (*done) (struct scsi_cmnd *); /* Mid-level done function */
    >
    > /*
    > * A SCSI Command is assigned a nonzero serial_number before passed
    > @@ -121,6 +122,7 @@ extern struct scsi_cmnd *__scsi_get_comm
    > extern void scsi_put_command(struct scsi_cmnd *);
    > extern void __scsi_put_command(struct Scsi_Host *, struct scsi_cmnd *,
    > struct device *);
    > +extern void scsi_io_completion(struct scsi_cmnd *, unsigned int);
    > extern void scsi_finish_command(struct scsi_cmnd *cmd);
    > extern void scsi_req_abort_cmd(struct scsi_cmnd *cmd);
    >
    > diff -puN include/scsi/scsi_driver.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d include/scsi/scsi_driver.h
    > --- a/include/scsi/scsi_driver.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    > +++ a/include/scsi/scsi_driver.h
    > @@ -15,7 +15,6 @@ struct scsi_driver {
    > struct device_driver gendrv;
    >
    > void (*rescan)(struct device *);
    > - int (*done)(struct scsi_cmnd *);
    > };
    > #define to_scsi_driver(drv) \
    > container_of((drv), struct scsi_driver, gendrv)
    > diff -puN include/scsi/sd.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d include/scsi/sd.h
    > --- a/include/scsi/sd.h~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
    > +++ a/include/scsi/sd.h
    > @@ -48,6 +48,19 @@ struct scsi_disk {
    > };
    > #define to_scsi_disk(obj) container_of(obj,struct scsi_disk,cdev)
    >
    > +static int sd_revalidate_disk(struct gendisk *disk);
    > +static void sd_rw_intr(struct scsi_cmnd * SCpnt);
    > +static int sd_probe(struct device *);
    > +static int sd_remove(struct device *);
    > +static void sd_shutdown(struct device *dev);
    > +static int sd_suspend(struct device *dev, pm_message_t state);
    > +static int sd_resume(struct device *dev);
    > +static void sd_rescan(struct device *);
    > +static void sd_read_capacity(struct scsi_disk *sdkp, unsigned char *buffer);
    > +static void scsi_disk_release(struct class_device *cdev);
    > +static void sd_print_sense_hdr(struct scsi_disk *, struct scsi_sense_hdr *);
    > +static void sd_print_result(struct scsi_disk *, int);
    > +
    > #define sd_printk(prefix, sdsk, fmt, a...) \
    > (sdsk)->disk ? \
    > sdev_printk(prefix, (sdsk)->device, "[%s] " fmt, \
    > _
    >
    > -

    Boaz
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions

    On Thu 29-11-07 17:27:08, Kamalesh Babulal wrote:
    > Andrew Morton wrote:
    > > On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal wrote:
    > >
    > >> Hi Andrew,
    > >>
    > >> While running file system stress on nfs and cifs mounted partitions, the machine
    > >> drops to xmon
    > >>
    > >> 1:mon> e
    > >> cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
    > >> pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
    > >> lr: c0000000001074d0: .vfs_link+0x204/0x298
    > >> sp: c000000080a9fb00
    > >> msr: 8000000000009032
    > >> dar: 280
    > >> dsisr: 40010000
    > >> current = 0xc0000000c8e6f670
    > >> paca = 0xc000000000512c00
    > >> pid = 2848, comm = fsstress
    > >> 1:mon> t
    > >> [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
    > >> [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
    > >> [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
    > >> --- Exception: c00 (System Call) at 000000000ff1bdfc
    > >> SP (ffeaed10) is in userspace
    > >> 1:mon> r
    > >> R00 = c0000000001074d0 R16 = 0000000000000000
    > >> R01 = c000000080a9fb00 R17 = 0000000000000000
    > >> R02 = c00000000060c380 R18 = 0000000000000000
    > >> R03 = 0000000000000000 R19 = 0000000000000000
    > >> R04 = 0000000000000004 R20 = 0000000000000000
    > >> R05 = 0000000000000000 R21 = 0000000000000000
    > >> R06 = 0000000000000000 R22 = 0000000000000000
    > >> R07 = 0000000000000000 R23 = 0000000000000004
    > >> R08 = 0000000000000000 R24 = 0000000000000280
    > >> R09 = 0000000000000000 R25 = fffffffffffff000
    > >> R10 = 0000000000000001 R26 = c000000082827790
    > >> R11 = c0000000003963e8 R27 = c0000000828275a0
    > >> R12 = d000000000deec78 R28 = 0000000000000000
    > >> R13 = c000000000512c00 R29 = c00000007b18fcf0
    > >> R14 = 0000000000000000 R30 = c0000000005bc088
    > >> R15 = 0000000000000000 R31 = 0000000000000000
    > >> pc = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
    > >> lr = c0000000001074d0 .vfs_link+0x204/0x298
    > >> msr = 8000000000009032 cr = 24000882
    > >> ctr = c0000000003963e8 xer = 0000000000000000 trap = 300
    > >> dar = 0000000000000280 dsisr = 40010000
    > >>
    > >>
    > >> The gdb output shows
    > >>
    > >> 0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
    > >> 103 * fsnotify_create - 'name' was linked in
    > >> 104 */
    > >> 105 static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
    > >> 106 {
    > >> 107 inode_dir_notify(inode, DN_CREATE);
    > >> 108 inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
    > >> 109 dentry->d_inode);
    > >> 110 audit_inode_child(dentry->d_name.name, dentry, inode);
    > >> 111 }
    > >> 112
    > >>

    > >
    > > If it is reproducible can you please try reverting
    > > inotify-send-in_attrib-events-when-link-count-changes.patch?

    >
    > Hi Andrew,
    >
    > reverting the patch inotify-send-in_attrib-events-when-link-count-changes.patch, the
    > bug is not reproduced.

    OK, thanks for testing. I was trying to reproduce the problem locally but
    without success so far - I guess it's either NFS or CIFS which makes the
    problem appear. I'll investigate more.

    Honza
    --
    Jan Kara
    SUSE Labs, CR
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions

    Andrew Morton wrote:
    > On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal wrote:
    >
    >> Hi Andrew,
    >>
    >> While running file system stress on nfs and cifs mounted partitions, the machine
    >> drops to xmon
    >>
    >> 1:mon> e
    >> cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
    >> pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
    >> lr: c0000000001074d0: .vfs_link+0x204/0x298
    >> sp: c000000080a9fb00
    >> msr: 8000000000009032
    >> dar: 280
    >> dsisr: 40010000
    >> current = 0xc0000000c8e6f670
    >> paca = 0xc000000000512c00
    >> pid = 2848, comm = fsstress
    >> 1:mon> t
    >> [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
    >> [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
    >> [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
    >> --- Exception: c00 (System Call) at 000000000ff1bdfc
    >> SP (ffeaed10) is in userspace
    >> 1:mon> r
    >> R00 = c0000000001074d0 R16 = 0000000000000000
    >> R01 = c000000080a9fb00 R17 = 0000000000000000
    >> R02 = c00000000060c380 R18 = 0000000000000000
    >> R03 = 0000000000000000 R19 = 0000000000000000
    >> R04 = 0000000000000004 R20 = 0000000000000000
    >> R05 = 0000000000000000 R21 = 0000000000000000
    >> R06 = 0000000000000000 R22 = 0000000000000000
    >> R07 = 0000000000000000 R23 = 0000000000000004
    >> R08 = 0000000000000000 R24 = 0000000000000280
    >> R09 = 0000000000000000 R25 = fffffffffffff000
    >> R10 = 0000000000000001 R26 = c000000082827790
    >> R11 = c0000000003963e8 R27 = c0000000828275a0
    >> R12 = d000000000deec78 R28 = 0000000000000000
    >> R13 = c000000000512c00 R29 = c00000007b18fcf0
    >> R14 = 0000000000000000 R30 = c0000000005bc088
    >> R15 = 0000000000000000 R31 = 0000000000000000
    >> pc = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
    >> lr = c0000000001074d0 .vfs_link+0x204/0x298
    >> msr = 8000000000009032 cr = 24000882
    >> ctr = c0000000003963e8 xer = 0000000000000000 trap = 300
    >> dar = 0000000000000280 dsisr = 40010000
    >>
    >>
    >> The gdb output shows
    >>
    >> 0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
    >> 103 * fsnotify_create - 'name' was linked in
    >> 104 */
    >> 105 static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
    >> 106 {
    >> 107 inode_dir_notify(inode, DN_CREATE);
    >> 108 inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
    >> 109 dentry->d_inode);
    >> 110 audit_inode_child(dentry->d_name.name, dentry, inode);
    >> 111 }
    >> 112
    >>

    >
    > If it is reproducible can you please try reverting
    > inotify-send-in_attrib-events-when-link-count-changes.patch?


    Hi Andrew,

    reverting the patch inotify-send-in_attrib-events-when-link-count-changes.patch, the
    bug is not reproduced.

    --
    Thanks & Regards,
    Kamalesh Babulal,
    Linux Technology Center,
    IBM, ISTL.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions

    Jan Kara wrote:
    > On Thu 29-11-07 17:27:08, Kamalesh Babulal wrote:
    >> Andrew Morton wrote:
    >>> On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal wrote:
    >>>
    >>>> Hi Andrew,
    >>>>
    >>>> While running file system stress on nfs and cifs mounted partitions, the machine
    >>>> drops to xmon
    >>>>
    >>>> 1:mon> e
    >>>> cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
    >>>> pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
    >>>> lr: c0000000001074d0: .vfs_link+0x204/0x298
    >>>> sp: c000000080a9fb00
    >>>> msr: 8000000000009032
    >>>> dar: 280
    >>>> dsisr: 40010000
    >>>> current = 0xc0000000c8e6f670
    >>>> paca = 0xc000000000512c00
    >>>> pid = 2848, comm = fsstress
    >>>> 1:mon> t
    >>>> [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
    >>>> [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
    >>>> [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
    >>>> --- Exception: c00 (System Call) at 000000000ff1bdfc
    >>>> SP (ffeaed10) is in userspace
    >>>> 1:mon> r
    >>>> R00 = c0000000001074d0 R16 = 0000000000000000
    >>>> R01 = c000000080a9fb00 R17 = 0000000000000000
    >>>> R02 = c00000000060c380 R18 = 0000000000000000
    >>>> R03 = 0000000000000000 R19 = 0000000000000000
    >>>> R04 = 0000000000000004 R20 = 0000000000000000
    >>>> R05 = 0000000000000000 R21 = 0000000000000000
    >>>> R06 = 0000000000000000 R22 = 0000000000000000
    >>>> R07 = 0000000000000000 R23 = 0000000000000004
    >>>> R08 = 0000000000000000 R24 = 0000000000000280
    >>>> R09 = 0000000000000000 R25 = fffffffffffff000
    >>>> R10 = 0000000000000001 R26 = c000000082827790
    >>>> R11 = c0000000003963e8 R27 = c0000000828275a0
    >>>> R12 = d000000000deec78 R28 = 0000000000000000
    >>>> R13 = c000000000512c00 R29 = c00000007b18fcf0
    >>>> R14 = 0000000000000000 R30 = c0000000005bc088
    >>>> R15 = 0000000000000000 R31 = 0000000000000000
    >>>> pc = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
    >>>> lr = c0000000001074d0 .vfs_link+0x204/0x298
    >>>> msr = 8000000000009032 cr = 24000882
    >>>> ctr = c0000000003963e8 xer = 0000000000000000 trap = 300
    >>>> dar = 0000000000000280 dsisr = 40010000
    >>>>
    >>>>
    >>>> The gdb output shows
    >>>>
    >>>> 0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
    >>>> 103 * fsnotify_create - 'name' was linked in
    >>>> 104 */
    >>>> 105 static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
    >>>> 106 {
    >>>> 107 inode_dir_notify(inode, DN_CREATE);
    >>>> 108 inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
    >>>> 109 dentry->d_inode);
    >>>> 110 audit_inode_child(dentry->d_name.name, dentry, inode);
    >>>> 111 }
    >>>> 112
    >>>>
    >>> If it is reproducible can you please try reverting
    >>> inotify-send-in_attrib-events-when-link-count-changes.patch?

    >> Hi Andrew,
    >>
    >> reverting the patch inotify-send-in_attrib-events-when-link-count-changes.patch, the
    >> bug is not reproduced.

    > OK, thanks for testing. I was trying to reproduce the problem locally but
    > without success so far - I guess it's either NFS or CIFS which makes the
    > problem appear. I'll investigate more.
    >
    > Honza


    Hi Jan,

    I was running file system stress parallely on NFS and CIFS mounted partitions.


    --
    Thanks & Regards,
    Kamalesh Babulal,
    Linux Technology Center,
    IBM, ISTL.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions

    On Thu 29-11-07 17:27:08, Kamalesh Babulal wrote:
    > Andrew Morton wrote:
    > > On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal wrote:
    > >
    > >> Hi Andrew,
    > >>
    > >> While running file system stress on nfs and cifs mounted partitions, the machine
    > >> drops to xmon
    > >>
    > >> 1:mon> e
    > >> cpu 0x1: Vector: 300 (Data Access) at [c000000080a9f880]
    > >> pc: c0000000001392c8: .inotify_inode_queue_event+0x50/0x158
    > >> lr: c0000000001074d0: .vfs_link+0x204/0x298
    > >> sp: c000000080a9fb00
    > >> msr: 8000000000009032
    > >> dar: 280
    > >> dsisr: 40010000
    > >> current = 0xc0000000c8e6f670
    > >> paca = 0xc000000000512c00
    > >> pid = 2848, comm = fsstress
    > >> 1:mon> t
    > >> [c000000080a9fbd0] c0000000001074d0 .vfs_link+0x204/0x298
    > >> [c000000080a9fc70] c00000000010b6e0 .sys_linkat+0x134/0x1b4
    > >> [c000000080a9fe30] c00000000000872c syscall_exit+0x0/0x40
    > >> --- Exception: c00 (System Call) at 000000000ff1bdfc
    > >> SP (ffeaed10) is in userspace
    > >> 1:mon> r
    > >> R00 = c0000000001074d0 R16 = 0000000000000000
    > >> R01 = c000000080a9fb00 R17 = 0000000000000000
    > >> R02 = c00000000060c380 R18 = 0000000000000000
    > >> R03 = 0000000000000000 R19 = 0000000000000000
    > >> R04 = 0000000000000004 R20 = 0000000000000000
    > >> R05 = 0000000000000000 R21 = 0000000000000000
    > >> R06 = 0000000000000000 R22 = 0000000000000000
    > >> R07 = 0000000000000000 R23 = 0000000000000004
    > >> R08 = 0000000000000000 R24 = 0000000000000280
    > >> R09 = 0000000000000000 R25 = fffffffffffff000
    > >> R10 = 0000000000000001 R26 = c000000082827790
    > >> R11 = c0000000003963e8 R27 = c0000000828275a0
    > >> R12 = d000000000deec78 R28 = 0000000000000000
    > >> R13 = c000000000512c00 R29 = c00000007b18fcf0
    > >> R14 = 0000000000000000 R30 = c0000000005bc088
    > >> R15 = 0000000000000000 R31 = 0000000000000000
    > >> pc = c0000000001392c8 .inotify_inode_queue_event+0x50/0x158
    > >> lr = c0000000001074d0 .vfs_link+0x204/0x298
    > >> msr = 8000000000009032 cr = 24000882
    > >> ctr = c0000000003963e8 xer = 0000000000000000 trap = 300
    > >> dar = 0000000000000280 dsisr = 40010000
    > >>
    > >>
    > >> The gdb output shows
    > >>
    > >> 0xc0000000001076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
    > >> 103 * fsnotify_create - 'name' was linked in
    > >> 104 */
    > >> 105 static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
    > >> 106 {
    > >> 107 inode_dir_notify(inode, DN_CREATE);
    > >> 108 inotify_inode_queue_event(inode, IN_CREATE, 0, dentry->d_name.name,
    > >> 109 dentry->d_inode);
    > >> 110 audit_inode_child(dentry->d_name.name, dentry, inode);
    > >> 111 }
    > >> 112
    > >>

    > >
    > > If it is reproducible can you please try reverting
    > > inotify-send-in_attrib-events-when-link-count-changes.patch?

    >
    > Hi Andrew,
    >
    > reverting the patch inotify-send-in_attrib-events-when-link-count-changes.patch, the
    > bug is not reproduced.

    OK, it's a problem with CIFS. Its cifs_hardlink() function doesn't call
    d_instantiate() and thus returns a dentry with d_inode set to NULL. I'm not
    sure if such behavior is really correct but anyway, attached is a new
    version of the patch which should handle it gracefully. Kamalesh, can you
    please give it a try? Thanks.

    Honza
    --
    Jan Kara
    SUSE Labs, CR
    ---

    Currently, no notification event has been sent when inode's link count
    changed. This is inconvenient for the application in some cases:
    Suppose you have the following directory structure
    foo/test
    bar/

    and you watch test. If someone does "mv foo/test bar/", you get event
    IN_MOVE_SELF and you know something has happened with the file "test".
    However if someone does "ln foo/test bar/test" and "rm foo/test" you get no
    inotify event for the file "test" (only directories "foo" and "bar" receive
    events).
    Furthermore it could be argued that link count belongs to file's metadata
    and thus IN_ATTRIB should be sent when it changes.
    The following patch implements sending of IN_ATTRIB inotify events when
    link count of the inode changes, i.e., when a hardlink to the inode is
    created or when it is removed. This event is sent in addition to all the
    events sent so far. In particular, when a last link to a file is removed,
    IN_ATTRIB event is sent in addition to IN_DELETE_SELF event.

    Signed-off-by: Jan Kara

    diff --git a/fs/namei.c b/fs/namei.c
    index 3b993db..c1839d1 100644
    --- a/fs/namei.c
    +++ b/fs/namei.c
    @@ -2188,6 +2188,7 @@ int vfs_unlink(struct inode *dir, struct dentry *dentry)

    /* We don't d_delete() NFS sillyrenamed files--they still exist. */
    if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED)) {
    + fsnotify_link_count(dentry->d_inode);
    d_delete(dentry);
    }

    @@ -2360,7 +2361,7 @@ int vfs_link(struct dentry *old_dentry, struct inode *dir, struct dentry *new_de
    error = dir->i_op->link(old_dentry, dir, new_dentry);
    mutex_unlock(&old_dentry->d_inode->i_mutex);
    if (!error)
    - fsnotify_create(dir, new_dentry);
    + fsnotify_link(dir, old_dentry->d_inode, new_dentry);
    return error;
    }

    diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
    index 2bd31fa..d4b7c4a 100644
    --- a/include/linux/fsnotify.h
    +++ b/include/linux/fsnotify.h
    @@ -92,6 +92,14 @@ static inline void fsnotify_inoderemove(struct inode *inode)
    }

    /*
    + * fsnotify_link_count - inode's link count changed
    + */
    +static inline void fsnotify_link_count(struct inode *inode)
    +{
    + inotify_inode_queue_event(inode, IN_ATTRIB, 0, NULL, NULL);
    +}
    +
    +/*
    * fsnotify_create - 'name' was linked in
    */
    static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
    @@ -103,6 +111,20 @@ static inline void fsnotify_create(struct inode *inode, struct dentry *dentry)
    }

    /*
    + * fsnotify_link - new hardlink in 'inode' directory
    + * Note: We have to pass also the linked inode ptr as some filesystems leave
    + * new_dentry->d_inode NULL and instantiate inode pointer later
    + */
    +static inline void fsnotify_link(struct inode *dir, struct inode *inode, struct dentry *new_dentry)
    +{
    + inode_dir_notify(dir, DN_CREATE);
    + inotify_inode_queue_event(dir, IN_CREATE, 0, new_dentry->d_name.name,
    + inode);
    + fsnotify_link_count(inode);
    + audit_inode_child(new_dentry->d_name.name, new_dentry, dir);
    +}
    +
    +/*
    * fsnotify_mkdir - directory 'name' was created
    */
    static inline void fsnotify_mkdir(struct inode *inode, struct dentry *dentry)
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: 2.6.24-rc3-mm2

    On Nov 28, 2007 12:41 PM, Andrew Morton wrote:
    >
    > ftp://ftp.kernel.org/pub/linux/kerne....6.24-rc3-mm2/
    >
    > - All patches against subsystem trees were recently sent to the relevant
    > maintainers. Many (probably most) were ignored. I don't know why this
    > happens.
    >
    > - First bug report: after ten minutes happily compiling kernels my
    > 2.6.24-rc3-mm2 x86_64 box spontaneously rebooted.


    The problem I reported againts 2.6.24-rc3-mm1, that the time is not
    connected to the IO-APIC is gone, 2.6.24-rc3-mm2 boots for me.
    But after ~1h of usage I got two different crashes on my x86_64 box.

    I hope, the CC's are correct...

    First crash:

    [ 1116.083651] Unable to handle kernel NULL pointer dereference at
    0000000000000378 RIP:
    [ 1116.089216] [] ether1394_dg_complete+0x28/0xa0
    [ 1116.097883] PGD 51880067 PUD 4a08b067 PMD 0
    [ 1116.102232] Oops: 0000 [1] SMP
    [ 1116.105423] last sysfs file:
    /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
    [ 1116.113344] CPU 0
    [ 1116.115393] Modules linked in: radeon drm nfsd exportfs w83792d
    ipv6 tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx
    tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg
    videobuf_core btcx_risc tveeprom videodev v4l2_common usbhid
    v4l1_compat i2c_nforce2 hid pata_amd sg
    [ 1116.142687] Pid: 509, comm: khpsbpkt Not tainted 2.6.24-rc3-mm2 #1
    [ 1116.148956] RIP: 0010:[] []
    ether1394_dg_complete+0x28/0xa0
    [ 1116.157857] RSP: 0000:ffff81007ee71e80 EFLAGS: 00010282
    [ 1116.163225] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
    [ 1116.170457] RDX: ffff810051509480 RSI: 0000000000000000 RDI: ffff8100525a41c0
    [ 1116.177676] RBP: ffff81007ee71eb0 R08: 0000000000000000 R09: 0000000000000001
    [ 1116.184882] R10: ffffffff80952570 R11: 0000000000000001 R12: ffff8100525a41c0
    [ 1116.192110] R13: ffff81004a035d00 R14: 0000000000000001 R15: ffff8100525a41c0
    [ 1116.199324] FS: 00002abffda7a6f0(0000) GS:ffffffff807d4000(0000)
    knlGS:0000000000000000
    [ 1116.207512] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    [ 1116.213314] CR2: 0000000000000378 CR3: 000000004a193000 CR4: 00000000000006e0
    [ 1116.220538] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 1116.227757] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [ 1116.234971] Process khpsbpkt (pid: 509, threadinfo
    FFFF81007EE70000, task FFFF81007EE4E000)
    [ 1116.243409] Stack: ffff81007ee71e90 ffff810051509cc0
    ffff8100525a41c0 0000000000000000
    [ 1116.251538] 0000000000000001 0000000000000000 ffff81007ee71ee0
    ffffffff8047cea3
    [ 1116.259063] ffff81007ee71ec8 ffff81007ee71ef0 ffffffff8046d690
    0000000000000000
    [ 1116.266372] Call Trace:
    [ 1116.269045] [] ether1394_complete_cb+0xb3/0xd0
    [ 1116.275203] [] hpsbpkt_thread+0x0/0x140
    [ 1116.280753] [] hpsbpkt_thread+0xbb/0x140
    [ 1116.286402] [] kthread+0x4d/0x80
    [ 1116.291341] [] child_rip+0xa/0x12
    [ 1116.296374] [] restore_args+0x0/0x30
    [ 1116.301675] [] kthread+0x0/0x80
    [ 1116.306534] [] child_rip+0x0/0x12
    [ 1116.311548]
    [ 1116.313052] INFO: lockdep is turned off.
    [ 1116.317032]
    [ 1116.317032] Code: 4c 8b a0 78 03 00 00 4d 8d b4 24 d0 00 00 00 4c
    89 f7 e8 21
    [ 1116.326198] RIP [] ether1394_dg_complete+0x28/0xa0
    [ 1116.332729] RSP
    [ 1116.336264] CR2: 0000000000000378
    [ 1116.339681] Unable to handle kernel NULL pointer dereference at
    0000000000000000 RIP:
    [ 1116.345219] [] kmem_cache_alloc_node+0x63/0x90
    [ 1116.353823] PGD 51880067 PUD 4a08b067 PMD 0
    [ 1116.358163] Oops: 0000 [2] SMP
    [ 1116.361156] last sysfs file:
    /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
    [ 1116.369269] CPU 0
    [ 1116.371307] Modules linked in: radeon drm nfsd exportfs w83792d
    ipv6 tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx
    tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg
    videobuf_core btcx_risc tveeprom videodev v4l2_common usbhid
    v4l1_compat i2c_nforce2 hid pata_amd sg
    [ 1116.398316] Pid: 509, comm: khpsbpkt Tainted: G D 2.6.24-rc3-mm2 #1
    [ 1116.405279] RIP: 0010:[] []
    kmem_cache_alloc_node+0x63/0x90
    [ 1116.414143] RSP: 0000:ffffffff80859ae0 EFLAGS: 00010046
    [ 1116.414145] RAX: 0000000000000000 RBX: ffff810001006780 RCX: ffffffff8052e079
    [ 1116.426733] RDX: 00000000ffffffff RSI: 0000000000000000 RDI: ffffffff807e7e80
    [ 1116.426735] RBP: ffffffff80859b00 R08: 00000000000005e0 R09: 000000000000ffc1
    [ 1116.441159] R10: 0000000000000001 R11: ffff81007ed5e3e0 R12: 00000000ffffffff
    [ 1116.441161] R13: 0000000000000020 R14: 0000000000000020 R15: ffffffff807e7e80
    [ 1116.455559] FS: 00002abffda7a6f0(0000) GS:ffffffff807d4000(0000)
    knlGS:0000000000000000
    [ 1116.455561] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    [ 1116.469540] CR2: 0000000000000000 CR3: 000000004a193000 CR4: 00000000000006e0
    [ 1116.469542] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 1116.483948] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [ 1116.483950] Process khpsbpkt (pid: 509, threadinfo
    FFFF81007EE70000, task FFFF81007EE4E000)
    [ 1116.499601] Stack: ffffffff80859b10 00000000000005e0
    00000000ffffffff 0000000000000609
    [ 1116.507739] ffffffff80859b40 ffffffff8052e079 0000000080859b50
    00000000000005e0
    [ 1116.515065] ffff81007ee25010 00000000000005e0 ffff81007ee25010
    ffff81007ee93000
    [ 1116.521078] Call Trace:
    [ 1116.521079]
    -> Here ends the output from the serial console


    I then change the network from ether1394 to a real network card, but
    this also crashed:
    [ 602.464580] ------------[ cut here ]------------
    [ 602.469250] kernel BUG at lib/list_debug.c:33!
    [ 602.473731] invalid opcode: 0000 [1] SMP
    [ 602.477828] last sysfs file:
    /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
    [ 602.485751] CPU 0
    [ 602.487808] Modules linked in: radeon drm nfsd exportfs w83792d
    ipv6 tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx
    tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg
    videobuf_core btcx_risc tveeprom videodev usbhid v4l2_common
    v4l1_compat hid sg pata_amd i2c_nforce2
    [ 602.515102] Pid: 7452, comm: nfsv4-svc Not tainted 2.6.24-rc3-mm2 #1
    [ 602.521554] RIP: 0010:[] []
    __list_add+0x54/0x60
    [ 602.529491] RSP: 0018:ffff81007ad25dc0 EFLAGS: 00010282
    [ 602.534864] RAX: 0000000000000088 RBX: ffff81007c5cdc00 RCX: 0000000000000003
    [ 602.542092] RDX: ffff81007d29e000 RSI: 0000000000000001 RDI: ffffffff807590c0
    [ 602.549312] RBP: ffff81007ad25dc0 R08: 0000000000000001 R09: 0000000000000000
    [ 602.556536] R10: ffff810080061d48 R11: 0000000000000001 R12: ffff81007ed09f00
    [ 602.563765] R13: ffff81007ed09f38 R14: ffff81007ed09f38 R15: ffff81007c528100
    [ 602.571002] FS: 00007ff7d66326f0(0000) GS:ffffffff807d4000(0000)
    knlGS:0000000000000000
    [ 602.579200] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [ 602.585012] CR2: 0000000005584118 CR3: 000000007c46a000 CR4: 00000000000006e0
    [ 602.592243] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 602.599480] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [ 602.606710] Process nfsv4-svc (pid: 7452, threadinfo
    FFFF81007AD24000, task FFFF81007D29E000)
    [ 602.615340] Stack: ffff81007ad25e00 ffffffff805be18e
    ffff81007ed09f08 ffff81007c528100
    [ 602.623496] ffff81007c5cdc00 ffff81007ad78000 ffff8100625abc00
    ffff81007c528110
    [ 602.631011] ffff81007ad25e10 ffffffff805be287 ffff81007ad25ee0
    ffffffff805befcc
    [ 602.638327] Call Trace:
    [ 602.640997] [] svc_xprt_enqueue+0x1ae/0x250
    [ 602.646916] [] svc_xprt_received+0x17/0x20
    [ 602.652744] [] svc_recv+0x39c/0x840
    [ 602.657950] [] svc_send+0xaf/0xd0
    [ 602.662977] [] default_wake_function+0x0/0x10
    [ 602.669066] [] nfs_callback_svc+0x7a/0x130
    [ 602.674894] [] trace_hardirqs_on_thunk+0x35/0x3a
    [ 602.681261] [] trace_hardirqs_on+0xbf/0x160
    [ 602.687176] [] child_rip+0xa/0x12
    [ 602.692189] [] restore_args+0x0/0x30
    [ 602.697499] [] nfs_callback_svc+0x0/0x130
    [ 602.703231] [] child_rip+0x0/0x12
    [ 602.708257]
    [ 602.709777] INFO: lockdep is turned off.
    [ 602.713748]
    [ 602.713748] Code: 0f 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 8b 16
    48 89 e5 e8
    [ 602.722915] RIP [] __list_add+0x54/0x60
    [ 602.728500] RSP
    [ 602.732058] Kernel panic - not syncing: Aiee, killing interrupt handler!

    Both times the system hung with Caps Lock and Scroll Lock where blinking.

    Torsten
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: 2.6.24-rc3-mm2

    On Thu, 29 Nov 2007 21:58:16 +0100
    "Torsten Kaiser" wrote:

    > On Nov 28, 2007 12:41 PM, Andrew Morton wrote:
    > >
    > > ftp://ftp.kernel.org/pub/linux/kerne....6.24-rc3-mm2/
    > >
    > > - All patches against subsystem trees were recently sent to the relevant
    > > maintainers. Many (probably most) were ignored. I don't know why this
    > > happens.
    > >
    > > - First bug report: after ten minutes happily compiling kernels my
    > > 2.6.24-rc3-mm2 x86_64 box spontaneously rebooted.

    >
    > The problem I reported againts 2.6.24-rc3-mm1, that the time is not
    > connected to the IO-APIC is gone, 2.6.24-rc3-mm2 boots for me.


    whew. That was a nasty one - it's good that it went away.

    > But after ~1h of usage I got two different crashes on my x86_64 box.


    Nice, thanks. By finding these now you (hopefully) saved a whole lot of
    people a whole lot of grief a couple months from now.

    > I hope, the CC's are correct...


    Bruce works on NFS things too.

    > First crash:
    >
    > [ 1116.083651] Unable to handle kernel NULL pointer dereference at
    > 0000000000000378 RIP:
    > [ 1116.089216] [] ether1394_dg_complete+0x28/0xa0
    > [ 1116.097883] PGD 51880067 PUD 4a08b067 PMD 0
    > [ 1116.102232] Oops: 0000 [1] SMP
    > [ 1116.105423] last sysfs file:
    > /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
    > [ 1116.113344] CPU 0
    > [ 1116.115393] Modules linked in: radeon drm nfsd exportfs w83792d
    > ipv6 tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx
    > tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg
    > videobuf_core btcx_risc tveeprom videodev v4l2_common usbhid
    > v4l1_compat i2c_nforce2 hid pata_amd sg
    > [ 1116.142687] Pid: 509, comm: khpsbpkt Not tainted 2.6.24-rc3-mm2 #1
    > [ 1116.148956] RIP: 0010:[] []
    > ether1394_dg_complete+0x28/0xa0
    > [ 1116.157857] RSP: 0000:ffff81007ee71e80 EFLAGS: 00010282
    > [ 1116.163225] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
    > [ 1116.170457] RDX: ffff810051509480 RSI: 0000000000000000 RDI: ffff8100525a41c0
    > [ 1116.177676] RBP: ffff81007ee71eb0 R08: 0000000000000000 R09: 0000000000000001
    > [ 1116.184882] R10: ffffffff80952570 R11: 0000000000000001 R12: ffff8100525a41c0
    > [ 1116.192110] R13: ffff81004a035d00 R14: 0000000000000001 R15: ffff8100525a41c0
    > [ 1116.199324] FS: 00002abffda7a6f0(0000) GS:ffffffff807d4000(0000)
    > knlGS:0000000000000000
    > [ 1116.207512] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    > [ 1116.213314] CR2: 0000000000000378 CR3: 000000004a193000 CR4: 00000000000006e0
    > [ 1116.220538] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    > [ 1116.227757] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    > [ 1116.234971] Process khpsbpkt (pid: 509, threadinfo
    > FFFF81007EE70000, task FFFF81007EE4E000)
    > [ 1116.243409] Stack: ffff81007ee71e90 ffff810051509cc0
    > ffff8100525a41c0 0000000000000000
    > [ 1116.251538] 0000000000000001 0000000000000000 ffff81007ee71ee0
    > ffffffff8047cea3
    > [ 1116.259063] ffff81007ee71ec8 ffff81007ee71ef0 ffffffff8046d690
    > 0000000000000000
    > [ 1116.266372] Call Trace:
    > [ 1116.269045] [] ether1394_complete_cb+0xb3/0xd0
    > [ 1116.275203] [] hpsbpkt_thread+0x0/0x140
    > [ 1116.280753] [] hpsbpkt_thread+0xbb/0x140
    > [ 1116.286402] [] kthread+0x4d/0x80
    > [ 1116.291341] [] child_rip+0xa/0x12
    > [ 1116.296374] [] restore_args+0x0/0x30
    > [ 1116.301675] [] kthread+0x0/0x80
    > [ 1116.306534] [] child_rip+0x0/0x12
    > [ 1116.311548]
    > [ 1116.313052] INFO: lockdep is turned off.
    > [ 1116.317032]
    > [ 1116.317032] Code: 4c 8b a0 78 03 00 00 4d 8d b4 24 d0 00 00 00 4c
    > 89 f7 e8 21
    > [ 1116.326198] RIP [] ether1394_dg_complete+0x28/0xa0
    > [ 1116.332729] RSP
    > [ 1116.336264] CR2: 0000000000000378
    > [ 1116.339681] Unable to handle kernel NULL pointer dereference at
    > 0000000000000000 RIP:
    > [ 1116.345219] [] kmem_cache_alloc_node+0x63/0x90
    > [ 1116.353823] PGD 51880067 PUD 4a08b067 PMD 0
    > [ 1116.358163] Oops: 0000 [2] SMP
    > [ 1116.361156] last sysfs file:
    > /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
    > [ 1116.369269] CPU 0
    > [ 1116.371307] Modules linked in: radeon drm nfsd exportfs w83792d
    > ipv6 tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx
    > tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg
    > videobuf_core btcx_risc tveeprom videodev v4l2_common usbhid
    > v4l1_compat i2c_nforce2 hid pata_amd sg
    > [ 1116.398316] Pid: 509, comm: khpsbpkt Tainted: G D 2.6.24-rc3-mm2 #1
    > [ 1116.405279] RIP: 0010:[] []
    > kmem_cache_alloc_node+0x63/0x90
    > [ 1116.414143] RSP: 0000:ffffffff80859ae0 EFLAGS: 00010046
    > [ 1116.414145] RAX: 0000000000000000 RBX: ffff810001006780 RCX: ffffffff8052e079
    > [ 1116.426733] RDX: 00000000ffffffff RSI: 0000000000000000 RDI: ffffffff807e7e80
    > [ 1116.426735] RBP: ffffffff80859b00 R08: 00000000000005e0 R09: 000000000000ffc1
    > [ 1116.441159] R10: 0000000000000001 R11: ffff81007ed5e3e0 R12: 00000000ffffffff
    > [ 1116.441161] R13: 0000000000000020 R14: 0000000000000020 R15: ffffffff807e7e80
    > [ 1116.455559] FS: 00002abffda7a6f0(0000) GS:ffffffff807d4000(0000)
    > knlGS:0000000000000000
    > [ 1116.455561] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    > [ 1116.469540] CR2: 0000000000000000 CR3: 000000004a193000 CR4: 00000000000006e0
    > [ 1116.469542] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    > [ 1116.483948] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    > [ 1116.483950] Process khpsbpkt (pid: 509, threadinfo
    > FFFF81007EE70000, task FFFF81007EE4E000)
    > [ 1116.499601] Stack: ffffffff80859b10 00000000000005e0
    > 00000000ffffffff 0000000000000609
    > [ 1116.507739] ffffffff80859b40 ffffffff8052e079 0000000080859b50
    > 00000000000005e0
    > [ 1116.515065] ffff81007ee25010 00000000000005e0 ffff81007ee25010
    > ffff81007ee93000
    > [ 1116.521078] Call Trace:
    > [ 1116.521079]
    > -> Here ends the output from the serial console
    >


    Yep, looks like a genuine 1394 bug.

    >
    > I then change the network from ether1394 to a real network card, but
    > this also crashed:
    > [ 602.464580] ------------[ cut here ]------------
    > [ 602.469250] kernel BUG at lib/list_debug.c:33!
    > [ 602.473731] invalid opcode: 0000 [1] SMP
    > [ 602.477828] last sysfs file:
    > /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
    > [ 602.485751] CPU 0
    > [ 602.487808] Modules linked in: radeon drm nfsd exportfs w83792d
    > ipv6 tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx
    > tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg
    > videobuf_core btcx_risc tveeprom videodev usbhid v4l2_common
    > v4l1_compat hid sg pata_amd i2c_nforce2
    > [ 602.515102] Pid: 7452, comm: nfsv4-svc Not tainted 2.6.24-rc3-mm2 #1
    > [ 602.521554] RIP: 0010:[] []
    > __list_add+0x54/0x60
    > [ 602.529491] RSP: 0018:ffff81007ad25dc0 EFLAGS: 00010282
    > [ 602.534864] RAX: 0000000000000088 RBX: ffff81007c5cdc00 RCX: 0000000000000003
    > [ 602.542092] RDX: ffff81007d29e000 RSI: 0000000000000001 RDI: ffffffff807590c0
    > [ 602.549312] RBP: ffff81007ad25dc0 R08: 0000000000000001 R09: 0000000000000000
    > [ 602.556536] R10: ffff810080061d48 R11: 0000000000000001 R12: ffff81007ed09f00
    > [ 602.563765] R13: ffff81007ed09f38 R14: ffff81007ed09f38 R15: ffff81007c528100
    > [ 602.571002] FS: 00007ff7d66326f0(0000) GS:ffffffff807d4000(0000)
    > knlGS:0000000000000000
    > [ 602.579200] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    > [ 602.585012] CR2: 0000000005584118 CR3: 000000007c46a000 CR4: 00000000000006e0
    > [ 602.592243] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    > [ 602.599480] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    > [ 602.606710] Process nfsv4-svc (pid: 7452, threadinfo
    > FFFF81007AD24000, task FFFF81007D29E000)
    > [ 602.615340] Stack: ffff81007ad25e00 ffffffff805be18e
    > ffff81007ed09f08 ffff81007c528100
    > [ 602.623496] ffff81007c5cdc00 ffff81007ad78000 ffff8100625abc00
    > ffff81007c528110
    > [ 602.631011] ffff81007ad25e10 ffffffff805be287 ffff81007ad25ee0
    > ffffffff805befcc
    > [ 602.638327] Call Trace:
    > [ 602.640997] [] svc_xprt_enqueue+0x1ae/0x250
    > [ 602.646916] [] svc_xprt_received+0x17/0x20
    > [ 602.652744] [] svc_recv+0x39c/0x840
    > [ 602.657950] [] svc_send+0xaf/0xd0
    > [ 602.662977] [] default_wake_function+0x0/0x10
    > [ 602.669066] [] nfs_callback_svc+0x7a/0x130
    > [ 602.674894] [] trace_hardirqs_on_thunk+0x35/0x3a
    > [ 602.681261] [] trace_hardirqs_on+0xbf/0x160
    > [ 602.687176] [] child_rip+0xa/0x12
    > [ 602.692189] [] restore_args+0x0/0x30
    > [ 602.697499] [] nfs_callback_svc+0x0/0x130
    > [ 602.703231] [] child_rip+0x0/0x12
    > [ 602.708257]
    > [ 602.709777] INFO: lockdep is turned off.
    > [ 602.713748]
    > [ 602.713748] Code: 0f 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 8b 16
    > 48 89 e5 e8
    > [ 602.722915] RIP [] __list_add+0x54/0x60
    > [ 602.728500] RSP
    > [ 602.732058] Kernel panic - not syncing: Aiee, killing interrupt handler!
    >
    > Both times the system hung with Caps Lock and Scroll Lock where blinking.
    >


    And one in NFS.

    Thanks!
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [BUG] 2.6.24-rc3-mm2 soft lockup while running tbench

    On Wed, 28 Nov 2007 20:03:22 +0530
    Kamalesh Babulal wrote:

    > Hi Andrew,
    >
    > while running tbench on the powerpc with 2.6.24-rc3-mm2 softlock up occurs
    >
    > BUG: soft lockup - CPU#0 stuck for 11s! [tbench:12183]
    > NIP: c0000000000ac978 LR: c0000000000acff0 CTR: c00000000005c648
    > REGS: C00000076F0F3200 TRAP: 0901 Not tainted (2.6.24-rc3-mm2-autotest)
    > MSR: 8000000000009032 CR: 44000482 XER: 00000000
    > TASK = C00000076F4BC000[12183] 'tbench' THREAD: C00000076F0F0000 CPU: 0
    > NIP [c0000000000ac978] .get_page_from_freelist+0x1cc/0x754
    > LR [c0000000000acff0] .__alloc_pages+0xb0/0x3a8
    > Call Trace:
    > [c00000076f0f3480] [c00000076f0f3560] 0xc00000076f0f3560 (unreliable)
    > [c00000076f0f3590] [c0000000000acff0] .__alloc_pages+0xb0/0x3a8
    > [c00000076f0f3680] [c0000000000ce2e4] .alloc_pages_current+0xa8/0xc8
    > [c00000076f0f3710] [c0000000000ac6ec] .__get_free_pages+0x20/0x70
    > [c00000076f0f3790] [c0000000000d75c8] .__kmalloc_node_track_caller+0x60/0x148
    > [c00000076f0f3840] [c0000000002c22b0] .__alloc_skb+0x98/0x184
    > [c00000076f0f38f0] [c000000000306cd8] .tcp_sendmsg+0x1fc/0xe24
    > [c00000076f0f3a10] [c0000000002b963c] .sock_sendmsg+0xe4/0x128
    > [c00000076f0f3c10] [c0000000002ba4ec] .sys_sendto+0xd4/0x120
    > [c00000076f0f3d90] [c0000000002df2f8] .compat_sys_socketcall+0x148/0x214
    > [c00000076f0f3e30] [c00000000000872c] syscall_exit+0x0/0x40
    > Instruction dump:
    > 720b0001 eb970000 40820070 72000002 4182000c e8bc0000 48000018 72080004
    > 4182000c e8bc0008 48000008 e8bc0010 7f83e378 7de407b4 7e078378
    >


    hm. Beats me. Does the machine recover OK?
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: 2.6.24-rc3-mm2 (bugfix for memory cgroup per-zone-struct allocation.)

    On Thu, 2007-11-29 at 14:24 +0900, KAMEZAWA Hiroyuki wrote:
    > On Thu, 29 Nov 2007 12:23:29 +0900
    > KAMEZAWA Hiroyuki wrote:
    > > I noticed CONFIG_NUMA + CONFIG_CGROUP_MEM_CONT + CONFIG_SLUB cannot boot because of my patch.
    > > (SLAB is ok.)
    > > I'll post workaround soon.
    > >

    > ==
    > This is a fix. tested on my ia64/NUMA box both on SLAB/SLUB.
    > This patch fixes kmalloc_node() is called against node-without-memory.
    >
    > It's better to add memory hotplug callback for supporing possible nodes
    > (memory hotplug) but here just uses kmalloc().
    >
    > Should be revisited later.
    >
    > Signed-off-by: KAMEZAWA Hiroyuki
    >
    > mm/memcontrol.c | 14 ++++++++++++--
    > 1 file changed, 12 insertions(+), 2 deletions(-)
    >
    > Index: linux-2.6.24-rc3-mm2/mm/memcontrol.c
    > ================================================== =================
    > --- linux-2.6.24-rc3-mm2.orig/mm/memcontrol.c
    > +++ linux-2.6.24-rc3-mm2/mm/memcontrol.c
    > @@ -1117,8 +1117,18 @@ static int alloc_mem_cgroup_per_zone_inf
    > struct mem_cgroup_per_node *pn;
    > struct mem_cgroup_per_zone *mz;
    > int zone;
    > -
    > - pn = kmalloc_node(sizeof(*pn), GFP_KERNEL, node);
    > + /*
    > + * This routine is called against possible nodes.
    > + * But it's BUG to call kmalloc() against offline node.
    > + *
    > + * TODO: this routine can waste much memory for nodes which will
    > + * never be onlined. It's better to use memory hotplug callback
    > + * function.
    > + */
    > + if (node_state(node, N_HIGH_MEMORY))
    > + pn = kmalloc_node(sizeof(*pn), GFP_KERNEL, node);
    > + else
    > + pn = kmalloc(sizeof(*pn), GFP_KERNEL);
    > if (!pn)
    > return 1;
    >
    >


    This worked for me. Can boot 24-rc3-mm2 [if I turn off async scsi scan,
    that is--not related to mem controller].

    Just FYI, on my ia64 platform, with NODES_SHIFT == 8 [RHEL & SLES ship
    with 10, I believe], the size of the mem_cgroup structure is ~10KB.

    Lee

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast