NetBSD Problem Report #50462

From dholland@netbsd.org  Mon Nov 23 08:48:07 2015
Return-Path: <dholland@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 5BD57A6712
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 23 Nov 2015 08:48:07 +0000 (UTC)
Message-Id: <20151123084807.24AAB14A1EF@mail.netbsd.org>
Date: Mon, 23 Nov 2015 08:48:07 +0000 (UTC)
From: dholland@netbsd.org
Reply-To: dholland@netbsd.org
To: gnats-bugs@gnats.NetBSD.org
Subject: there is no test coverage for UFS long symlinks
X-Send-Pr-Version: 3.95

>Number:         50462
>Category:       kern
>Synopsis:       there is no test coverage for UFS long symlinks
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 23 08:50:00 +0000 2015
>Originator:     David A. Holland
>Release:        current
>Organization:
>Environment:
System: NetBSD valkyrie 7.99.1 NetBSD 7.99.1 (VALKYRIE) #17: Wed Oct 14 03:21:03 EDT 2015  dholland@valkyrie:/usr/src/sys/arch/amd64/compile/VALKYRIE amd64
Architecture: x86_64
Machine: amd64
>Description:

In ufs-related filesystems newer than sometime in the 80s, symlink
text that can be stuffed into the direct/indirect block pointer space
in the inode is kept there and not in a separate block.

This is great and all, but it means that symlinks longer than this
limit use a variety of different code paths and these are not
exercised in the regression tests. It turned out tonight that one of
these in LFS has had a broken assertion since March.

>How-To-Repeat:

>Fix:

Add some more cases to t_vnops.c. Note that for LFS64 and FFSv2 a
large symlink needs to be more than 120 bytes, and preferably more
than 136.

Home	PR Database Search